130. MongoDB 아키텍처 — ReplicaSet/Sharding/Mongos

핵심 인사이트 (3줄 요약)

• 본질: MongoDB의 ReplicaSet은 자동 장애 조치(Automatic Failover)를 제공하는 고가용성 단위이며, Sharding은 이 ReplicaSet을 기반으로 데이터를 수평 분산하여 무제한 확장을 실현한다.
• 가치: Mongos 라우터가 클라이언트에게 단일 엔드포인트를 제공하여 샤딩 복잡성을 추상화하며, WiredTiger 스토리지 엔진의 문서 수준 잠금으로 높은 동시성을 보장한다.
• 판단 포인트: 샤드 키 선택이 성능의 90%를 결정하며, 카디널리티(Cardinality)가 낮거나 단조 증가하는 키는 핫스팟(Hot Spot)을 유발하므로 복합 샤드 키를 설계해야 한다.

Ⅰ. 개요 및 필요성

MongoDB 아키텍처 3대 구성 요소

WiredTiger 스토리지 엔진 특징

┌────────────────────────────────────────────────────┐
│          WiredTiger 스토리지 엔진 (기본값)            │
├────────────────────────────────────────────────────┤
│  ■ 잠금 수준: 문서(Document) 수준 — 행 잠금보다 세밀   │
│  ■ 압축: Snappy/zlib/zstd 지원 (스토리지 50~80% 절감)│
│  ■ MVCC: 읽기/쓰기 충돌 없음                        │
│  ■ 캐시: 기본 50% RAM 할당 (wiredTigerCacheSizeGB)  │
│  ■ 저널: 100ms 간격 Journaling (내구성 보장)         │
└────────────────────────────────────────────────────┘

📢 섹션 요약 비유

MongoDB 아키텍처는 대형 물류 센터와 같다. ReplicaSet은 각 창고의 자동 백업 시스템이고, Sharding은 물건을 여러 창고에 나눠 보관하는 분산 저장이며, Mongos는 어느 창고에 뭐가 있는지 알고 배송 경로를 안내하는 물류 AI다.

Ⅱ. 아키텍처 및 핵심 원리

ReplicaSet 구조 및 장애 조치

┌──────────────────────────────────────────────────────────┐
│                 MongoDB ReplicaSet 구조                   │
│                                                          │
│  ┌─────────────┐    복제     ┌─────────────┐             │
│  │  Primary    │ ──────────→ │ Secondary 1 │             │
│  │  (읽기/쓰기) │             │  (읽기 가능) │             │
│  └─────────────┘             └─────────────┘             │
│         │                          │                     │
│         │  복제                    │                     │
│         ↓                          ↓                     │
│  ┌─────────────┐          ┌──────────────┐               │
│  │ Secondary 2 │          │   Arbiter    │               │
│  │ (읽기 가능) │          │ (투표만, 데이터 │              │
│  └─────────────┘          │  저장 안 함)  │               │
│                            └──────────────┘               │
│                                                          │
│  ■ 장애 조치(Failover) 과정:                              │
│    1. Primary 다운 감지 (heartbeat 실패)                  │
│    2. Secondaries + Arbiter 투표 (과반수 득표)             │
│    3. 새 Primary 선출 (보통 10~30초)                      │
│    4. 클라이언트 자동 재연결                               │
└──────────────────────────────────────────────────────────┘

Sharding 전체 구조

┌────────────────────────────────────────────────────────────┐
│                  MongoDB Sharding 아키텍처                  │
│                                                            │
│  [Application]                                             │
│       │                                                    │
│       ↓                                                    │
│  ┌──────────────────────────────────┐                      │
│  │     Mongos (Query Router)        │  ← 여러 개 배치 가능  │
│  └──────────────────────────────────┘                      │
│       │ 샤드 키 기반 라우팅                                   │
│       ├────────────────┬───────────────┐                   │
│       ↓                ↓               ↓                   │
│  ┌─────────┐     ┌─────────┐    ┌─────────┐               │
│  │ Shard 1 │     │ Shard 2 │    │ Shard 3 │               │
│  │(RSset1) │     │(RSset2) │    │(RSset3) │               │
│  │ Chunk   │     │ Chunk   │    │ Chunk   │               │
│  │ 0~33%  │     │ 34~66%  │    │ 67~100% │               │
│  └─────────┘     └─────────┘    └─────────┘               │
│       ↑                ↑               ↑                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │         Config Servers (ReplicaSet)                 │   │
│  │   샤드 메타데이터: 청크 범위, 샤드 위치 정보 저장        │   │
│  └─────────────────────────────────────────────────────┘   │
└────────────────────────────────────────────────────────────┘

샤드 키 전략 비교

MongoDB 인덱스 유형

📢 섹션 요약 비유

샤드 키 선택은 도서관 도서 분류 방법을 정하는 것과 같다. '가나다순 첫 글자'로만 분류하면 'ㄱ'으로 시작하는 책이 너무 많아 한 선반이 터진다(핫스팟). '주제+저자'의 복합 분류가 균형 잡힌 분산을 만든다.

Ⅲ. 비교 및 연결

ReplicaSet vs Sharding 목적 차이

읽기 선호도(Read Preference) 설정

primaryPreferred   : 주로 Primary, 없으면 Secondary
secondary          : Secondary 전용 (분석 쿼리)
secondaryPreferred : 주로 Secondary
nearest            : 네트워크 지연 최소 노드

📢 섹션 요약 비유

ReplicaSet은 똑같은 복사본을 3개 만드는 복사기이고, Sharding은 큰 문서를 3등분해서 각각 다른 서랍에 넣는 파일링 시스템이다. 복사기는 하나를 잃어도 괜찮게 하고, 파일링 시스템은 서랍 하나가 꽉 차지 않게 한다.

Ⅳ. 실무 적용 및 기술사 판단

배포 아키텍처 결정 트리

데이터 볼륨 < 1TB / 쓰기 TPS < 10K?
        │
   YES ─┼─ NO ──→ Sharding 도입 필요
        │         (최소 3 Shard × ReplicaSet)
        ↓
단순 ReplicaSet (1 Primary + 2 Secondary)
        │
읽기 부하 높음? ──YES──→ Secondary 읽기 분산 + ReadPreference
        │
       NO
        ↓
기본 구성 유지, 모니터링 기반 단계적 확장

운영 체크리스트

📢 섹션 요약 비유

MongoDB 운영은 교통 관제와 같다. 평소에는 Mongos(교통 AI)가 쿼리를 최적 경로로 안내하고, 사고(노드 장애) 시에는 자동으로 우회로(페일오버)를 찾는다. 청크 밸런서는 야간에 조용히 도로 공사를 해서 낮에는 항상 원활한 소통을 유지한다.

Ⅴ. 기대효과 및 결론

대규모 배포 사례 성능 지표

결론

MongoDB의 ReplicaSet-Sharding 이중 구조는 고가용성과 무제한 확장을 동시에 달성하는 현존 최선의 문서형 DB 아키텍처다. 그러나 샤드 키 선택 실수는 수정 비용이 극히 높으므로 초기 데이터 접근 패턴 분석에 충분한 시간을 투자해야 한다. 기술사 시험에서는 ReplicaSet 선출 메커니즘, 샤드 키 핫스팟 문제, Mongos 역할이 단골 출제 포인트다.

📢 섹션 요약 비유

MongoDB 아키텍처 설계는 도시 건설 계획과 같다. 처음에 도로(샤드 키)를 잘못 놓으면 나중에 뜯어고치는 비용이 엄청나다. 처음부터 교통 흐름(쿼리 패턴)을 고려해 넓은 도로(높은 카디널리티 샤드 키)를 설계하면, 도시가 아무리 커져도 원활하게 확장된다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

[문서 지향 DB (Document-Oriented DB)]
    │
    ▼
[WiredTiger 스토리지 엔진 — MVCC]
    │
    ▼
[레플리카 셋 (Replica Set) — 자동 장애 조치]
    │
    ▼
[샤딩 (Sharding) — 수평 확장]
    │
    ▼
[Atlas (클라우드 MongoDB) — 서버리스 Document DB]

MongoDB 아키텍처가 단일 노드에서 복제와 샤딩을 거쳐 완전 관리형 클라우드 서비스로 발전한 흐름이다.

👶 어린이를 위한 3줄 비유 설명

1. ReplicaSet은 같은 책을 3권 인쇄해두는 것 — 한 권이 찢어져도 나머지 두 권으로 계속 읽을 수 있어요.
2. Sharding은 두꺼운 백과사전을 ㄱ~ㅇ, ㅈ~ㅎ으로 나눠 다른 선반에 두는 것 — 선반 하나가 무거워지지 않아요.
3. Mongos는 "내가 찾는 글자가 어느 선반에 있는지" 알려주는 안내원 — 덕분에 우리는 어느 선반에 뭐가 있는지 몰라도 돼요.