2018년 6월 4일 ObjectRocket.com/blog에 최초 게시됨
확장(Scaling)이라는 단어를 물고기의 비늘을 벗기는 것으로 정의할 수도 있지만, 데이터베이스 분야에서 확장이란 스토리지, 디스크, RAM, CPU, 연산 능력, 네트워크 등 추가적인 리소스 요구 사항에 맞춰 시스템을 늘려갈 수 있는 능력을 의미합니다.
확장이 필요한 시점은 어떻게 알 수 있을까?
오늘날 애플리케이션이 입소문을 타며 사용자가 폭발적으로 증가하는 등, 데이터 급성장과 빠른 사용자 유입은 흔한 일이 되었습니다. 이런 상황이 오면 초기 환경은 순식간에 한계에 도달하게 됩니다. 성장은 물리적인 데이터 저장 공간의 부족, 성능 저하, 그리고 더 많은 리소스(CPU, RAM, 네트워크 또는 이 모든 것의 조합)에 대한 필요성에서 비롯됩니다. 성장에 미리 대비하는 계획형 접근과, 작은 성능 저하가 보이기 시작할 때 확장하는 대응형 접근 중 선택할 수 있습니다.
선제적(Proactive) 확장
미리 확장을 계획할 때 일반적으로 나타나는 패턴은 크게 두 가지입니다.
- 대규모 마케팅 캠페인이 예정되어 있어 고객 수나 데이터량이 크게 증가할 것으로 예상되는 경우
- 애플리케이션이나 비즈니스가 계절적 주기를 가지는 경우(예: 크리스마스 쇼핑 시즌, 새해 결심 시즌 등), 활동량 증가와 함께 대용량 데이터가 지속적으로 축적되는 경우
MongoDB 인스턴스의 확장 시점을 판단하는 방법에 대한 자세한 내용은 관련 포스트를 참고하세요.
대응적(Reactive) 확장
병목 현상을 겪고 있고 앞으로도 계속 성장할 것으로 예상된다면, 이제 확장을 고민해야 할 때입니다.
위험 신호로는 다음과 같은 문제들이 있습니다.
- 사용자 경험 쿼리 응답 시간 증가
- 로그인 시간 지연
- 요청 및 서버 응답 멈춤 현상
- 개발자들의 데이터베이스 관련 불만
- 서버 응답 속도 저하
- 호스트 부하 증가
- 메모리 부족(Out-of-memory) 오류
- 예기치 않은 선거(election) 발생
- 로그에 에러 기록 증가
이러한 징후들이 보이기 시작하면, 수요를 감당하고 고객 이탈을 막기 위해 확장을 시작해야 합니다.
확장은 수직(vertical)으로(scale up) 할 수도 있고 수평(horizontal)으로(scale out) 할 수도 있습니다.
수직 확장(Scale Up)
흔히 말하는 빅 아이언(Big Iron) 방식으로, 하나의 강력한 머신에 많은 리소스(CPU 코어, 높은 클럭 속도, 대용량 RAM, 스토리지)를 탑재하는 방법입니다. 수직 확장의 가장 큰 장점은 아키텍처 복잡도가 낮아지고 관리해야 할 호스트 수가 줄어든다는 점입니다. 유지보수 담당 인력이 없는 환경에서 특히 유용합니다.
현재 수직 확장에 활용할 수 있는 방법은 다양합니다. 더 좋은 범용 하드웨어, 저렴해진 디스크와 스토리지, 향상된 스토리지 옵션, 값싸진 메모리, 개선된 소프트웨어, 그리고 페일오버와 장애 상황을 더 안정적으로 처리할 수 있는 네트워킹 기술 등이 그 예입니다.
많은 애플리케이션과 요구 사항에 수직 확장이 적합하며, 우리는 다음 섹션에서 다룰 레플리카 세트(Replica Set) 구성을 권장합니다. 다만 더 큰 규모의 레플리카 세트를 운영할 때는 수직 확장의 숨은 비용을 염두에 두어야 합니다. 환경이 계속 빠르게 성장한다면 끊임없이 더 큰 머신으로 마이그레이션하거나 추가 리소스를 투입해야 하고, 어느 순간에는 그것조차 불가능한 지점에 도달할 수 있습니다. 또한 단일 대형 호스트의 업그레이드 주기는 수평 확장 환경에 비해 효율이 떨어진다는 점도 고려해야 합니다. 지속적인 성장이 예상된다면 수직 확장을 계속할지, 아니면 수평 확장으로 전환하는 것이 이득일지 신중히 판단해야 합니다.
수평 확장(Scale Out)
샤딩(Sharding)이 바로 수평 확장입니다. 샤딩은 데이터를 여러 노드에 분산 저장하여 부하와 처리 프로세스를 여러 호스트에 나눕니다. 복제는 프라이머리-레플리카(Primary-Replica) 모델로 처리되며, 필요에 따라 노드를 추가할 수 있습니다.
로드 밸런서가 데이터 청크(chunk)들을 노드들의 디스크에 분배합니다.
이렇게 하면 읽기·쓰기 작업을 여러 머신에 분산시켜 처리 용량을 늘릴 수 있으며, 한 대의 머신에 읽기/쓰기 요청이 몰리는 상황을 피할 수 있습니다. 다행히 최근 몇 차례 릴리스를 거치면서 밸런서 기능이 크게 개선되었습니다. 수평 확장은 MongoDB®의 내장 샤딩 기능을 활용하고, 저렴한 범용 하드웨어를 사용함으로써 얻는 이점도 있습니다.
수평 확장 시에는 물리적 또는 가상 호스트를 통해 리소스를 추가합니다.
- 물리적 – 저렴한 범용 하드웨어를 다수 확보
- 가상 – VM이나 클라우드를 통해 CPU 코어 또는 노드 추가
- 네트워킹 – 로드 밸런서, mongoS® 프로세스 추가 등
개선된 로드 밸런싱 기술(하드웨어 및 소프트웨어)을 활용하면 트래픽을 필요한 곳으로 효율적으로 분배할 수 있습니다.
MongoDB에서 레플리카 세트로 확장을 구현하는 방법
MongoDB는 하나의 프라이머리(Primary)와 두 개의 세컨더리(Secondary)로 구성된 대형 레플리카 세트를 사용해 수평 확장을 구현할 수 있습니다. 각 노드는 하트비트 통신으로 상태(up/down)를 확인하며, 세컨더리에서는 오퍼레이션 로그(oplog)를 통해 복제가 이루어집니다.
수평 확장: 레플리카 세트 vs 샤딩?
샤딩의 트레이드오프는 전체적인 복잡도가 증가한다는 점입니다. 하지만 샤딩은 유지보수를 단순화하는 이점도 제공합니다. 롤링 업그레이드가 가능하고, 인덱스 빌드 같은 특정 작업을 샤드와 노드 전반에 걸쳐 동시에 병렬로 수행할 수 있습니다. 다음은 대형 레플리카 세트와 샤딩 클러스터의 비교입니다.
| 레플리카 세트 | 샤딩 |
|---|---|
| 구성이 단순함 | 전문 지식 필요 |
| 광범위한 데이터 세트에 걸친 읽기 작업이 많음 (scatter-gather 회피) | 쓰기·업데이트 작업이 많음 (결과를 위해 정확한 샤드로 직접 접근) |
| 데이터는 많지만 활동 빈도는 낮음 | 데이터량도 많고 활동량도 많음 |
| 디스크 등 일반적인 리소스 위주로 추가 필요 | 디스크, RAM, CPU, 쓰기 범위 등 모든 리소스가 더 많이 필요 |
ObjectRocket의 관리형 MongoDB를 선택해야 하는 이유
Rackspace ObjectRocket은 전문성을 의미합니다. 우리는 처음부터 대규모 MongoDB 관리를 해왔으며, 대형 레플리카 세트 지원은 물론, 대형 샤딩 MongoDB 클러스터 지원을 가장 먼저 제공한 업체 중 하나입니다. 우리의 엔지니어와 DBA들은 다른 공급업체에서는 좀처럼 접하기 어려운 매우 복잡한 장애 상황들을 경험하고 극복해 온 실력을 갖추고 있습니다.
마케팅 기술 분야(모바일 애널리틱스, 미디어, 이메일 캠페인, 모바일 광고 사기 탐지, 디지털 미디어)의 최대 규모 고객들은 다른 곳에서는 보지 못했거나 해결 방법을 모르는 버그에 자주 직면합니다. 수많은 고객으로부터 발생하는 수십억 건의 메시지와 문서, 수천 개의 대형·소형 캠페인—우리 플랫폼은 이 모든 것을 호스팅합니다.
우리가 제공하는 서비스는 다음과 같습니다.
- 인프라
- 스토리지
- IOPS
- 네트워크
- 손색없는 최고의 실무형 지원. 24×7 언제나 올바른 대응.
플랜과 가격 정보를 확인해 보세요.
우리는 완전히 견고한 구성의 클라우드 솔루션을 제공하기 위해 노력하며, 세컨더리를 가상 볼륨에만 프로비저닝하지 않습니다. 이를 통해 선거(election)가 발생했을 때 프라이머리가 세컨더리용으로만 프로비저닝된 성능이 떨어지는 호스트에 배치되어 발생할 수 있는 성능 문제를 예방합니다.
확장에 대한 설명은 여기까지입니다. MongoDB 인스턴스의 확장 시점 판단 방법, 샤딩 팁, 최적의 샤드 키 선택 방법 등에 대해 더 자세히 알아보세요.
Rackspace DBA 서비스에 대해 자세히 알아보세요.
피드백 탭을 통해 의견을 남기거나 질문할 수 있습니다. 또한 Sales Chat을 클릭하여 지금 바로 상담을 시작할 수 있습니다.