레플리카 셋 멤버와 샤딩 노드의 리소스 할당 비교

MongoDB는 데이터 영속성, 고가용성 및 확장성을 위한 강력한 솔루션을 제공합니다. 이러한 목표를 달성하는 데 도움이 되는 두 가지 주요 아키텍처는 레플리카 셋(Replica Sets)과 샤드 클러스터(Sharded Clusters)입니다. 둘 다 프로덕션급 MongoDB 배포에 필수적이지만, 기본 리소스 할당 전략은 크게 다르며, 이는 인프라 설계와 비용에 직접적인 영향을 미칩니다.

이 문서는 다양한 MongoDB 구성 요소에 필요한 하드웨어 요구 사항—특히 CPU, RAM 및 저장소—를 자세히 비교합니다. 레플리카 셋 내의 프라이머리, 세컨더리 및 아비터 노드의 요구 사항을, 샤드 클러스터 내의 mongos 쿼리 라우터, 구성 서버(Config Servers) 및 개별 샤드 멤버의 개별적인 요구 사항과 대조하여 살펴봅니다. 이러한 차이점을 이해하는 것은 정보에 입각한 인프라 구성 결정을 내리고 MongoDB 배포를 위한 최적의 성능, 확장성 및 비용 효율성을 보장하는 데 중요합니다.

MongoDB 배포 전략 이해

리소스 할당을 자세히 알아보기 전에, 레플리카 셋과 샤드 클러스터의 각 구성 요소 역할을 간략하게 요약해 보겠습니다.

레플리카 셋: 고가용성 및 데이터 중복성

MongoDB 레플리카 셋은 동일한 데이터 셋을 유지하는 mongod 인스턴스 그룹입니다. 이는 고가용성과 데이터 중복성을 제공합니다. 레플리카 셋은 일반적으로 다음으로 구성됩니다.

• 프라이머리 노드 (Primary Node): 모든 쓰기 작업을 수신하는 유일한 노드입니다. 작업 로그(oplog)에 모든 변경 사항을 기록합니다. 주어진 시간에 레플리카 셋에는 하나의 프라이머리만 존재할 수 있습니다.
• 세컨더리 노드 (Secondary Nodes): 프라이머리의 oplog를 복제하고 자체 데이터 셋에 이러한 변경 사항을 적용하여 데이터 일관성을 보장합니다. 세컨더리 노드는 읽기 기본 설정(read preference settings)에 따라 읽기 작업을 처리할 수 있으며, 현재 프라이머리를 사용할 수 없게 되면 프라이머리로 선출될 수 있습니다.
• 아비터 노드 (Arbiter Node): 프라이머리를 결정하기 위한 선거에 참여하지만 데이터를 저장하지 않습니다. 아비터는 최소한의 리소스를 사용하며, 선거 시 동점(tie-breaking) 상황을 방지하기 위해 레플리카 셋에서 홀수의 투표 멤버를 제공하는 데 사용됩니다.

샤드 클러스터: 수평적 확장성

샤딩(Sharding)은 데이터를 여러 시스템에 분산하는 MongoDB의 방식입니다. 이를 통해 단일 레플리카 셋이 처리할 수 없는 대규모 데이터 셋과 높은 처리량 작업을 처리하기 위한 수평적 확장이 가능해집니다. 샤드 클러스터는 몇 가지 주요 구성 요소로 구성됩니다.

• Mongos (쿼리 라우터): 클라이언트 애플리케이션과 샤드 클러스터 간의 인터페이스 역할을 합니다. 쿼리를 적절한 샤드로 라우팅하고, 결과를 집계하며, 연결을 관리합니다.
• 구성 서버 (Config Servers - CSRS): 어떤 데이터 범위가 어떤 샤드에 상주하는지에 대한 정보를 포함하여 클러스터의 메타데이터('샤드 맵')를 저장합니다. 구성 서버는 고가용성을 위해 레플리카 셋(구성 서버 레플리카 셋 - CSRS)으로 배포됩니다.
• 샤드 (Shards): 각 샤드는 클러스터 데이터의 하위 셋을 보유하는 자체적인 레플리카 셋입니다. 데이터는 샤드 키(shard key)를 기반으로 이들 샤드에 분산됩니다.

레플리카 셋 멤버를 위한 리소스 할당

레플리카 셋 멤버의 리소스 요구 사항은 역할과 전체 워크로드에 따라 크게 달라집니다.

프라이머리 노드

프라이머리 노드는 모든 쓰기 작업을 처리하고 일반적으로 대부분의 읽기 작업을 처리하므로 레플리카 셋에서 가장 중요하고 리소스 집약적인 멤버입니다.

• CPU: 높음. 쓰기 중심의 워크로드, 복잡한 집계 파이프라인, 인덱싱 작업, 그리고 많은 동시 연결을 처리하려면 상당한 CPU 성능이 필요합니다. 애플리케이션이 문서를 자주 업데이트하거나 집중적인 쿼리를 수행하는 경우 프라이머리의 CPU가 빠르게 병목 현상이 될 수 있습니다.
• RAM: 매우 중요. MongoDB의 WiredTiger 스토리지 엔진은 캐시를 위해 RAM에 크게 의존합니다. 프라이머리는 디스크 I/O를 최소화하기 위해 자주 액세스하는 데이터와 인덱스를 메모리에 유지할 수 있을 만큼 충분한 RAM이 필요합니다. 일반적인 권장 사항은 작업 셋(애플리케이션이 활발하게 사용하는 데이터 및 인덱스)과 일부 버퍼를 포함하기에 충분한 RAM을 할당하는 것입니다.
• 저장소 (Storage): 높은 IOPS 및 처리량. 저널링을 포함하여 모든 쓰기 작업은 프라이머리의 디스크에 도달합니다. 쓰기 대기 시간이 병목 현상이 되는 것을 방지하기 위해 높은 IOPS(초당 입/출력 작업 수)를 가진 빠른 저장소(SSD/NVMe)가 필수적입니다. 용량은 전체 데이터 셋과 그 성장에 충분해야 하며, oplog 공간도 포함해야 합니다.

세컨더리 노드

세컨더리 노드는 프라이머리로부터 데이터를 복제하고 읽기 요청을 처리하여 프라이머리의 부하를 분산시킬 수 있습니다. 특히 읽기 작업을 처리하는 경우 리소스 요구 사항은 프라이머리와 유사한 경우가 많습니다.

• CPU: 보통에서 높음. CPU 사용량은 복제 속도와 읽기 워크로드에 따라 달라집니다. 세컨더리가 상당 부분을 담당하는 경우, CPU 요구 사항은 프라이머리에 근접할 수 있습니다. 주로 복제 및 장애 조치(failover)를 위한 경우 CPU 사용량은 낮아지지만, oplog 항목을 효율적으로 적용하는 데 여전히 중요합니다.
• RAM: 매우 중요. 프라이머리와 마찬가지로 세컨더리는 WiredTiger 캐시를 유지하며, 과도한 디스크 I/O 없이 oplog 항목을 효율적으로 적용하고 읽기를 처리하기 위해 작업 셋을 보관할 수 있는 충분한 RAM이 필요합니다. 장애 조치 시 일관된 성능을 위해 세컨더리의 캐시는 이상적으로 프라이머리의 캐시를 미러링해야 합니다.
• 저장소 (Storage): 높은 IOPS 및 처리량. 세컨더리는 oplog 항목 적용을 통해 프라이머리의 쓰기 속도를 따라잡아야 합니다. 이 역시 높은 I/O 성능을 요구합니다. 전체 데이터 사본을 저장하므로 용량은 프라이머리와 동일해야 합니다.

팁: 세컨더리 노드가 프라이머리와 유사하게 프로비저닝되도록 보장하십시오. 이는 세컨더리가 프라이머리가 될 때 원활한 장애 조치와 일관된 성능을 보장합니다.

아비터 노드

아비터는 선거 참여만을 위한 경량 노드입니다. 데이터를 저장하거나 읽기/쓰기 작업을 처리하지 않습니다.

• CPU: 매우 낮음. 아비터는 선거 프로토콜과 관련된 최소한의 컴퓨팅만 수행합니다.
• RAM: 매우 낮음. 기본적인 mongod 프로세스 오버헤드 및 선거 상태를 위한 메모리만 필요합니다.
• 저장소 (Storage): 매우 낮음. 최소한의 구성 및 로그 파일만 저장하며, 데이터 파일은 없습니다.

경고: 아비터 노드에서 애플리케이션이나 다른 데이터베이스 프로세스를 실행하지 마십시오. 이는 선거 가용성을 보장하고 리소스 경합을 방지하기 위한 전용의 최소 인스턴스여야 합니다.

샤딩 구성 요소를 위한 리소스 할당

샤드 클러스터는 추가 구성 요소를 도입하며, 각 구성 요소는 고유한 리소스 프로파일을 가지므로, 보다 분산되고 복잡한 리소스 할당 전략이 필요합니다.

Mongos (쿼리 라우터)

mongos 인스턴스는 상태가 없는(stateless) 라우팅 프로세스입니다. 데이터를 저장하지 않지만 샤드 전반의 작업을 조정합니다.

• CPU: 보통에서 높음. CPU 사용량은 클라이언트 연결 수, 라우팅되는 쿼리의 복잡성(예: mongos가 결합해야 하는 조인, 집계) 및 전체 쿼리 처리량에 따라 증가합니다. 더 많은 mongos 인스턴스를 추가하여 높은 부하를 처리할 수 있습니다.
• RAM: 보통. 주로 연결 관리, 구성 서버의 메타데이터 캐싱(샤드 맵) 및 임시 집계 버퍼에 사용됩니다. 데이터를 보유하는 노드만큼 중요하지는 않지만, 충분한 RAM은 스와핑을 방지하고 빠른 응답 시간을 보장합니다.
• 저장소 (Storage): 매우 낮음. 로그만 저장됩니다. 로컬 SSD로도 대개 충분합니다.

팁: 최적의 성능을 위해 네트워크 지연 시간을 최소화하도록 애플리케이션 서버 가까이에 mongos 인스턴스를 배포하십시오.

구성 서버 (Config Server Replica Set - CSRS)

구성 서버는 클러스터 상태에 대한 메타데이터를 저장하므로 샤드 클러스터 운영에 매우 중요합니다. 이들은 항상 레플리카 셋(CSRS)으로 배포됩니다.

• CPU: 보통. 청크 마이그레이션, 샤드 리밸런싱 또는 빈번한 메타데이터 업데이트 중에 CPU 사용량이 급증할 수 있습니다. 데이터를 보유하는 프라이머리만큼 높지는 않지만, 일관된 성능이 필수적입니다.
• RAM: 보통에서 높음. 중요한 클러스터 메타데이터를 메모리에 유지하기에 충분한 RAM이 필요합니다. 메타데이터의 크기는 샤드, 청크 및 데이터베이스의 수에 따라 달라집니다. RAM이 부족하면 클러스터 성능과 안정성이 심각하게 저하될 수 있습니다.
• 저장소 (Storage): 보통의 IOPS 및 용량. 메타데이터 크기는 일반적으로 사용자 데이터보다 작지만, 샤드 맵 및 기타 클러스터 상태 정보에 대한 업데이트가 빈번할 수 있으므로 적절한 I/O 성능이 필요합니다. 용량은 증가하는 메타데이터와 oplog를 수용해야 합니다.

경고: 구성 서버의 성능과 가용성은 무엇보다 중요합니다. 성능 저하는 전체 샤드 클러스터를 마비시킬 수 있습니다. 고도로 신뢰할 수 있고 성능이 뛰어난 인프라로 구성 서버를 프로비저닝하십시오.

샤드 멤버 (데이터 보유 레플리카 셋)

각 샤드는 클러스터 전체 데이터의 하위 셋을 저장하는 자체적인 레플리카 셋입니다. 따라서 각 샤드 내의 프라이머리, 세컨더리 및 아비터 노드에 대한 리소스 요구 사항은 독립형 레플리카 셋의 특성과 유사하지만, 이들이 보유하는 데이터의 부분에 맞춰 조정됩니다.

• CPU: 프라이머리는 높음, 세컨더리는 보통에서 높음. 각 샤드의 프라이머리는 해당 데이터 하위 셋에 대한 모든 쓰기 및 잠재적인 읽기를 처리합니다. 요구 사항은 해당 특정 샤드로 라우팅되는 워크로드에 비례합니다.
• RAM: 프라이머리와 세컨더리 모두 매우 중요. 각 샤드의 mongod는 저장하는 데이터의 작업 셋에 비례하여 WiredTiger 캐시를 위한 충분한 RAM이 필요합니다. 이는 데이터 세그먼트 내 성능에 중요합니다.
• 저장소 (Storage): 프라이머리와 세컨더리 모두 높은 IOPS 및 처리량. 독립형 레플리카 셋과 마찬가지로, 샤드 데이터 하위 셋에 대한 쓰기, 읽기 및 복제를 처리하기 위해 빠른 저장소가 필요합니다. 용량은 샤드의 데이터 부분과 그 성장에 충분해야 합니다.

주요 차이점: 개별 샤드 레플리카 셋은 독립형 레플리카 셋과 유사한 요구 사항을 가지지만, 전체 샤드 클러스터는 총 데이터와 워크로드를 여러 레플리카 셋에 분산합니다. 이는 모든 샤드의 리소스 총합이 단일, 수직적으로 확장된 레플리카 셋보다 훨씬 더 클 것임을 의미합니다.

리소스 할당 비교: 레플리카 셋 vs. 샤드 클러스터

실제 고려 사항 및 모범 사례

• 워크로드 분석: 애플리케이션의 읽기/쓰기 패턴, 데이터 증가 예상, 쿼리 복잡성을 철저히 이해하십시오. 이것이 리소스 계획에서 가장 중요한 단일 요소입니다.
• 모니터링이 핵심: 모든 MongoDB 구성 요소(CPU, RAM, 디스크 I/O, 네트워크, WiredTiger 캐시 사용량, oplog 지연, 쿼리 시간과 같은 데이터베이스 메트릭)에 대한 포괄적인 모니터링을 구현하십시오. 이는 병목 현상을 식별하고 선제적인 확장을 가능하게 합니다.
• 네트워크 성능: 샤드 클러스터의 경우, mongos, 구성 서버 및 샤드 간의 네트워크 지연 시간과 대역폭이 중요합니다. 샤드 간 통신 및 데이터 밸런싱 작업은 열악한 네트워크 성능으로 인해 큰 영향을 받을 수 있습니다.
• 전용 리소스: 프라이머리, 세컨더리 또는 샤드 멤버 등 각 mongod 프로세스는 전용 하드웨어 또는 전용 가상 머신에서 실행되어야 합니다. 리소스 경합을 방지하기 위해 애플리케이션 서버 또는 다른 데이터베이스 인스턴스와 함께 배치하는 것을 피하십시오.
• 클라우드 vs. 온프레미스: 클라우드 제공업체는 리소스를 쉽게 확장할 수 있는 유연성을 제공합니다. 그러나 선택한 인스턴스 유형이 IOPS 및 처리량 요구 사항(특히 저장소 집약적인 작업의 경우)을 충족하는지 확인하십시오.
• 테스트 및 벤치마킹: 프로덕션 환경에 투입하기 전에 항상 실제 워크로드를 사용하여 계획된 인프라를 테스트하십시오. 이는 리소스 할당 가정을 검증하는 데 도움이 됩니다.

결론

레플리카 셋과 샤드 클러스터 중에서 선택하고 이후 리소스를 할당하는 것은 전적으로 애플리케이션의 규모, 성능 요구 사항 및 예산에 따라 달라집니다. 레플리카 셋은 고가용성과 데이터 중복성을 제공하며, 많은 애플리케이션에 적합하며, 프라이머리와 세컨더리가 전체 데이터 셋의 워크로드를 처리할 수 있도록 보장하는 데 리소스 할당의 초점을 맞춥니다.

샤딩은 상당한 운영 복잡성과 더 높은 인프라 비용을 발생시키지만, 대규모 데이터 셋과 극한의 처리량을 위한 비할 데 없는 수평적 확장성을 제공합니다. 이는 각 구성 요소(mongos, 구성 서버 및 개별 샤드 레플리카 셋)가 고유한 하드웨어 요구 사항을 가진 별개의 역할을 수행한다는 점을 이해하고, 리소스 할당에 대한 보다 미묘한 접근 방식을 요구합니다. 강력하고 성능이 우수한 MongoDB 환경을 보장하기 위해서는 신중한 계획, 지속적인 모니터링 및 철저한 테스트가 두 배포 전략 모두에 필수적입니다.