복제 세트 멤버와 샤딩 노드의 리소스 할당 비교

MongoDB 리소스 계획은 단일 복제 세트에서 샤드 클러스터로 전환할 때 급격히 변화합니다. 두 가지 주요 아키텍처가 이러한 목표를 용이하게 합니다: 복제 세트와 샤드 클러스터. 둘 다 프로덕션 등급의 MongoDB 배포에 필수적이지만, 기본 리소스 할당 전략은 크게 다르며 인프라 설계와 비용에 직접적인 영향을 미칩니다.

복제 세트는 전체 데이터 세트와 대부분의 쓰기 압력을 하나의 프라이머리에 집중시킵니다. 샤드 클러스터는 데이터를 샤드 복제 세트에 분산하지만, 용량과 모니터링이 필요한 mongos 라우터와 구성 서버가 추가됩니다.

MongoDB 배포 전략 이해

리소스 할당에 들어가기 전에 복제 세트와 샤드 클러스터의 각 구성 요소 역할을 간략히 요약하겠습니다.

복제 세트: 고가용성 및 데이터 중복

MongoDB 복제 세트는 동일한 데이터 세트를 유지하는 mongod 인스턴스 그룹입니다. 이는 고가용성과 데이터 중복을 제공합니다. 복제 세트는 일반적으로 다음으로 구성됩니다:

프라이머리 노드: 모든 쓰기 작업을 수신하는 유일한 노드입니다. 모든 변경 사항을 작업 로그(oplog)에 기록합니다. 주어진 시간에 복제 세트에는 하나의 프라이머리만 있을 수 있습니다.
세컨더리 노드: 프라이머리의 oplog를 복제하고 이러한 변경 사항을 자체 데이터 세트에 적용하여 데이터 일관성을 보장합니다. 세컨더리 노드는 읽기 기본 설정에 따라 읽기 작업을 제공할 수 있으며, 현재 프라이머리를 사용할 수 없게 되면 프라이머리로 선출될 수 있습니다.
아비터 노드: 프라이머리를 결정하기 위한 선거에 참여하지만 데이터를 저장하지 않습니다. 아비터는 최소한의 리소스를 소비하며, 다른 데이터 보유 멤버를 배포할 수 없을 때 투표를 추가하는 데 사용될 수 있습니다. 모든 선거 문제를 방지하지는 않으며 드물게 사용해야 합니다.

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

샤딩은 여러 머신에 데이터를 분산하는 MongoDB의 방법입니다. 이를 통해 단일 복제 세트가 처리할 수 없는 대규모 데이터 세트와 높은 처리량 작업을 처리하기 위한 수평적 확장이 가능합니다. 샤드 클러스터는 여러 주요 구성 요소로 구성됩니다:

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

복제 세트 멤버를 위한 리소스 할당

복제 세트 멤버의 리소스 요구 사항은 역할과 전체 워크로드에 따라 크게 다릅니다.

프라이머리 노드

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

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

세컨더리 노드

세컨더리 노드는 프라이머리에서 데이터를 복제하고 읽기 요청을 제공하여 프라이머리를 오프로드할 수 있습니다. 특히 읽기를 처리하는 경우 리소스 요구 사항이 프라이머리와 유사한 경우가 많습니다.

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

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

아비터 노드

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

CPU: 매우 낮음. 아비터는 선거 프로토콜과 관련된 최소한의 계산을 수행합니다.
RAM: 매우 낮음. 기본 mongod 프로세스 오버헤드 및 선거 상태에 필요한 메모리만 있으면 됩니다.
스토리지: 매우 낮음. 최소한의 구성 및 로그 파일만 저장하며 데이터 파일은 없습니다.

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

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

샤드 클러스터는 각각 고유한 리소스 프로필을 가진 추가 구성 요소를 도입하여 보다 분산되고 복잡한 리소스 할당 전략을 이끌어냅니다.

Mongos (쿼리 라우터)

mongos 인스턴스는 상태 비저장 라우팅 프로세스입니다. 데이터를 저장하지 않지만 샤드 간 작업을 조정합니다.

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

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

구성 서버 (구성 서버 복제 세트 - CSRS)

구성 서버는 샤드 클러스터 운영에 중요하며 클러스터 상태에 대한 메타데이터를 저장합니다. 항상 복제 세트(CSRS)로 배포됩니다.

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

경고: 구성 서버의 성능과 가용성은 가장 중요합니다. 성능 저하가 발생하면 전체 샤드 클러스터가 마비될 수 있습니다. 안정적이고 성능이 뛰어난 인프라로 프로비저닝하십시오.

샤드 멤버 (데이터 보유 복제 세트)

각 샤드는 자체 포함된 복제 세트로, 클러스터 전체 데이터의 하위 집합을 저장합니다. 따라서 각 샤드 내의 프라이머리, 세컨더리 및 아비터 노드에 대한 리소스 요구 사항은 본질적으로 독립형 복제 세트와 유사하지만 보유한 데이터 부분에 맞게 조정됩니다.

CPU: 프라이머리는 높음, 세컨더리는 중간에서 높음. 각 샤드의 프라이머리는 해당 데이터 하위 집합에 대한 모든 쓰기와 잠재적으로 읽기를 처리합니다. 요구 사항은 해당 특정 샤드로 라우팅되는 워크로드에 비례합니다.
RAM: 프라이머리 및 세컨더리에 중요. 각 샤드의 mongod는 저장하는 데이터의 워킹 세트에 비례하여 WiredTiger 캐시에 충분한 RAM이 필요합니다. 이는 데이터 세그먼트 내 성능에 중요합니다.
스토리지: 프라이머리 및 세컨더리에 높은 IOPS 및 처리량. 독립형 복제 세트와 유사하게 샤드 데이터 하위 집합에 대한 쓰기, 읽기 및 복제를 처리하려면 빠른 스토리지가 필요합니다. 용량은 샤드의 데이터 부분과 그 증가분에 충분해야 합니다.

주요 차이점: 개별 샤드 복제 세트는 독립형 복제 세트와 유사한 요구 사항을 가지지만, 전체 샤드 클러스터는 전체 데이터와 워크로드를 여러 복제 세트에 분산합니다. 즉, 모든 샤드의 리소스 합계는 단일 수직 확장 복제 세트보다 훨씬 더 큽니다.

리소스 할당 비교: 복제 세트 vs. 샤드 클러스터

기능	복제 세트 (독립형)	샤드 클러스터
목적	고가용성, 데이터 중복, 중간 규모 확장	수평적 확장, 매우 큰 데이터 세트, 높은 처리량
총 노드	일반적으로 3개의 데이터 보유 멤버; 필요한 경우에만 아비터	3개의 구성 서버 + N개의 샤드 복제 세트(일반적으로 각각 3+ 멤버) + M개의 Mongos 인스턴스
CPU	프라이머리가 모든 쓰기 CPU를 처리합니다. 세컨더리가 읽기 CPU를 처리합니다. 아비터는 최소입니다.	`mongos`, 구성 서버 및 여러 샤드 프라이머리에 분산됩니다. 전체 총 CPU가 더 높습니다.
RAM	프라이머리 및 세컨더리는 전체 워킹 세트에 대한 RAM이 필요합니다.	각 샤드 프라이머리/세컨더리는 워킹 세트의 하위 집합에 대한 RAM이 필요합니다. 구성 서버는 메타데이터에 대한 RAM이 필요합니다. 전체 총 RAM이 더 높습니다.
스토리지	프라이머리 및 세컨더리는 전체 데이터 세트에 대한 용량과 IOPS가 필요합니다.	각 샤드 프라이머리/세컨더리는 데이터 세트의 하위 집합에 대한 용량과 IOPS가 필요합니다. 구성 서버는 중간 정도의 IOPS/용량이 필요합니다. 전체 총 스토리지가 더 높습니다.
병목 현상	쓰기용 프라이머리 노드; 단일 머신의 리소스 제한.	모든 구성 요소(`mongos`, 구성 서버 또는 개별 샤드)가 과소 프로비저닝되면 병목 현상이 발생할 수 있습니다.
복잡성	설정 및 관리가 상대적으로 간단합니다.	계획, 배포 및 관리가 훨씬 더 복잡합니다.
비용	중간 규모 확장에 대해 낮은 인프라 비용.	더 많은 인스턴스와 분산 특성으로 인해 더 높은 인프라 비용.

실용적인 고려 사항 및 모범 사례

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

요점

워킹 세트, 쓰기 속도 및 스토리지가 하나의 데이터 보유 노드 클래스에 편안하게 맞는 경우 복제 세트를 사용하십시오. 수평적 확장이 필요할 때 샤딩으로 전환하되, 샤드 복제 세트, 구성 서버, 라우터, 네트워크 용량 및 더 많은 운영 테스트와 같은 추가 구성 요소에 대한 예산을 책정하십시오.