지난 블로그 글에서는 MongoDB 확장이 필요한 시점을 다루었습니다. 이번 글에서는 MongoDB를 실제로 확장하는 방법에 초점을 맞춰 살펴보겠습니다.
MongoDB 3.0 버전부터 WiredTiger가 기본 스토리지 엔진으로 도입되면서, MongoDB는 두 가지 확장 방식을 제공하게 되었습니다. 바로 수직적 확장(Scale-Up)과 수평적 확장(Scale-Out)입니다. 두 방식 모두 자세히 살펴볼 가치가 충분합니다.
수직적 확장(Scale-Up)
수직적 확장은 CPU의 개수와 종류, RAM 용량, 디스크 공간 등 컴퓨팅 자원 자체를 늘리는 방식입니다. WiredTiger 환경에서 수직적 확장을 진행할 때는 병목 지점이 되는 자원이 무엇인지(CPU, RAM, 디스크 공간 또는 이들의 조합) 먼저 정확히 파악해야 합니다.
WiredTiger RAM 관련 주의사항
할당된 RAM이 1GB 미만일 경우, WiredTiger는 일반적으로 256MB 또는 사용 가능한 RAM의 50% 중 하나를 기본값으로 사용합니다. 따라서 더 많은 RAM을 할당하려면 WiredTiger 캐시 크기를 반드시 재조정해야 합니다.
수평적 확장(Scale-Out)
수평적 확장은 일반적으로 서버를 추가하는 방식으로 네트워크 전반에 컴퓨팅 자원을 분산하는 방법입니다. 노드가 추가될 때 데이터를 여러 노드에 분산하기 위해 MongoDB는 샤딩(Sharding)이라 불리는 데이터베이스 아키텍처를 활용합니다. 샤딩은 키 범위(key range)를 사용해 데이터를 분할하고, 이를 여러 데이터베이스 인스턴스에 배분합니다.
샤딩 인프라 구축하기
샤딩 구성을 설정하는 데 필요한 물리적 구성 요소는 다음과 같습니다.
- Mongos: 쿼리 라우터 역할을 수행합니다.
- Config 서버: 샤딩 메타데이터를 보관합니다.
- Data 노드: 실제 데이터를 저장합니다.
물리적 구성 요소에 대한 더 자세한 정보는 MongoDB 개요 문서를 참고하시기 바랍니다.
샤드 키(Shard Key) 정의하기
물리적인 샤딩 인프라 구축을 마쳤다면, 이제 논리적인 측면으로 초점을 옮길 차례입니다. 샤드 키란 MongoDB가 데이터를 분할할 때 사용하는 컬렉션 내의 특정 필드를 의미하며, 다행히 Mongo에서는 이러한 키를 직접 정의할 수 있습니다.
샤드 키로 적용할 필드를 선정하는 절차는 다음과 같습니다.
- 샤딩 대상 컬렉션 식별: 크기가 200MB를 초과하고 데이터가 고르게 분산될 수 있는 컬렉션이 샤딩의 좋은 후보입니다.
- 적절한 샤드 키 생성 및 설계: 샤드 키를 만들 때 아래의 권장 사항과 질문들을 반드시 고려하세요.
- 애플리케이션이 데이터베이스와 상호작용하는 방식에 대한 깊이 있는 이해를 확보합니다.
- 애플리케이션이 읽기 위주인지, 쓰기 위주인지, 아니면 양쪽이 균형 잡혀 있는지 판단합니다.
- 데이터베이스에 대해 가장 중요한 작업은 무엇인가요? 예를 들어 애플리케이션이 대량의 데이터를 기록하더라도, 실제로 가장 중요한 작업은 100ms 이내에 데이터를 반환하는 쿼리일 수 있습니다.
- 주간 및 월간 데이터 증가 패턴은 어떻게 예상되나요?
- 느린 쿼리처럼 반드시 해결해야 할 문제 영역이 있나요?
- 애플리케이션은 하루, 주, 월, 연도 중 특정 시기에 트래픽이 집중되나요? 아니면 항상 일정하게 바쁜가요?
이러한 사항들을 충분히 조사한 후에는 더욱 세부적인 분석을 시작할 수 있습니다. 다음 블로그 글에서는 우리 시스템에 맞는 올바른 샤드 키를 찾는 방법을 다룰 예정이니 많은 기대 부탁드립니다.