시스템이 대규모화 되었을 때 인프라 분산 전략에 대한 회고록

나는 이전에 SI로 개발자 직업을 시작해서 대략 8년정도 일했다.
조금 더 일찍 그 세계를 나왔으면 좋았겠지만... 나름 그 세계에 종사하면서 엔터프라이즈 환경의 DB분산 환경을 접할 수 있었고
아직은 그런게 없지만 나중에 내가 그러한 환경을 구축하려고 했을 때 희미한 기억을 더듬어 가며 이 글이 도움이 될 수 있었으면 하는 바램으로 정리를 하게 되었다.

나는 서버구축 전문가가 아니라 SW개발자이기 때문에 인프라의 심층적인 부분까지는 잘 모르지만 대략 이러한 방향으로 가야 한다는 윤곽정도 될 것 같다.
보통 소규모의 서비스를 운영할때 보통 서버 이중화와 DB서버를 하나 구축하고 redis를 활용해 DB의 부하를 줄이는 방향으로 구축할 것이다.

그런데 서비스에 사용자가 늘어나고, 트래픽이 증가하고, 데이터는 계속 늘어나고 있는 상황, 이제는 좀 더 규모를 키울 필요가 생긴다면?
굵직굵직한 sql문을 찍어내고 수시로 insert와 update, delete도 일어나야 하는데 부하가 심해서 더 이상 버틸 수 없는 상황이라면?

시스템이 엔터프라이즈의 방향으로 가야 할 필요가 있다고 보고 대규모 시스템 구축을 구민 중이라면 명심해야 할 3가지를 정리해보았다.

1.시스템 AP서버 및 DB서버를 이중화 하였는가?
하나의 서버에 부하가 걸려 장애가 발생하면 다른 서버가 지탱하여 전체 시스템이 멈추는 것을 방지하도록 이중화 설계를 염두해 둘 필요가 있다.
또한 DB 서버를 readonly와 writeonly로 이중화 정책을 수립되었는지 점검해보자. 한 DB에 싱글로 사용했을 때보다 부하가 많이 감소할 것이다.

(출처:https://travislife.tistory.com/47)

2.대용량 데이터 및 통계 데이터활용을 위한 테이블 설계에 복합키(인덱스)를 적절하게 사용하여 설계되었는가?
관계형 데이터베이스에서 테이블 설계는 절대적이다. 하나의 테이블에 기본키만 달랑 있다면? 그 테이블을 통계를 활용할때 특정 조건에 따라 데이터를 서치를 할 것이고 풀스캔이 발생하여 응답시간이 느려지는 경험을 했다면?
이때 정말 인덱스를 활용한 테이블 설계를 해야 할 필요가 있는 것이다. 인덱스는 비유를 들자면 굵직한 백과사전에서 내가 필요한 정보를 찾으려고 할때 빨리 찾을 수 있도록 해주는 책갈피와 같다. 책갈피를 끼워 놓으면 전체내용을 다 쫓아가며 내가 필요한 정보를 가지고 올 필요 없이 책갈피를 끼운 곳을 찾아 한방에 내가 원하는 정보를 찾는 것과 같다. 대용량 데이터일수록 인덱스는 필수적이며 연관있는 필수 칼럼을 가지고 복합키로 설계하는 것을 권장하는 바이다.
그러나 아무리 인덱스가 좋다고 해서 남발해서 사용해서는 안된다. read에서는 인덱스가 강력한 기능을 갖지만 write에는 취약한 편이므로 수시로 데이터가 변경되는 업무에는 권장하지 않는다.
자세한 내용은 다른 블로그에서 잘 정리했을 테니 검색해서 알아보자. 패스~

(출처:https://tecoble.techcourse.co.kr/post/2021-09-18-db-index/)

3.업무별 / 사용량에 따른 DB 분산화 전략을 고려하고 있는가?
이것은 위에 두가지 전략으로도 부하를 겪고 있을때 쓸 수 있는 최후의 카드가 아닐까 한다. 왠만해서는 여기까지는 갈 필요가 없겠지만, 서비스에 사용자가 많이 몰리게 되면서 걷잡을 수 없다면?
그렇다. 이제는 대규모 시스템 운영을 고려할 필요가 있다.
하나의 서비스에서 유독 사용량이 많은 파트가 있지 않은가? 그 부분이 서버에 부하냐 DB에 부하냐에 따라 서로 분리되고 독립된 서버를 구축할 필요가 있다.
예를 들어, 내가 대학교 학사정보 시스템을 구축한다면, 이것은 백프로 엔터프라이즈 급이고 각 업무에 따라 독립된 서버와 DB를 구축하여 부하를 분산시킬 필요가 있다.
그것은 학과별, 교과목별, 장학별, 성적처리별, 동아리별, 도서관 시스템별, 대학교안에서 업무를 보는 행정별... 정말 규모가 크기 때문에 서버와 DB를 분산하고 SSO로 통합로그인을 채택하는 방안등
각 파트에 따른 인프라를 분산 시키고 서로 유연하게 연동할 수 있는 전략을 세워야 할 것이다.

굳이 AP서버에 부하가 많이 오지 않는다면 하나 또는 이중화된 서버에서 DB커넥션을 다중으로 연결하여 필요한 DB를 가져오고 쓰는 방향으로 구축하더라도 괜찮다면 그렇게 하면 되는 것이다.

지금까지 SI를 해오면서 실제로 엔터프라이즈 급에서 실무에 투입했을때 많이 구축된 방식이고 SI가 redis없이 쿼리와 plsql만으로 모든 프로세스를 구축하더라도 DB가 뻗지 않는 것은, 이러한 큰 인프라 구축이 뒷받침되었기 때문이다.

(출처:https://m.blog.naver.com/wlgh0637/221527597918)

SW 개발자가 코딩만 잘하면 됐지. 이런 것까지 알아야 되나? 싶지만, 이런 잡지식이 바로 코딩에 녹아들게 되고, 머니머니해도, 백엔드 개발자라면 실무에서 성능이슈와 부하이슈는 결국 따라오게 마련인데 이러한 이슈를 어떻게 극복할지에 대해서는 필수로 알아야 하지만, 실무 경력이 많은 사람들 외에는 아무도 알려주지 않는다.
사실 이렇게 소개를 했지만, 이러한 방법은 SI에서 주로 해오던 방식이고 redis를 제외하고 구축했을때 이야기이기 때문에 개발자는 많은 공부와 신기술에 눈 떠 있어야 하겠다.

(난 결국 앱개발로 갈아탔다... 엉망진창 풀스택...)

혹시나 이분야에 대해서 더욱 전문적인 지식과 혹시 내가 잘 못 설명한 부분이 있다면 양해를 바라고 교정해 준다면 수정할 부분은 수정할 계획이니 많은 의견을 주길 바란다.

---

이 글은 제 Tistory 블로그에 처음 게시(2022-12-02)된 글입니다.