MongoDB 샤딩(Sharding) 완벽 가이드

샤딩이 필요한 시점

• 단일 노드 디스크/메모리 한계에 근접.
• 쓰기 처리량이 수직 확장으로 감당되지 않음.
• 특정 컬렉션이 지속적으로 핫스팟을 유발.

샤딩은 "빨라지는 기능"이 아니라 "용량과 처리량 한계를 넘기기 위한 구조"입니다.

구성 요소

• mongos: 라우터. 클라이언트 요청을 적절한 샤드로 전달.
• shard replica set: 실제 데이터 저장.
• config server replica set: chunk/메타데이터 저장.

샤드 키 선택 기준

좋은 샤드 키는 세 조건을 동시에 만족해야 합니다.

• 높은 카디널리티
• 균등 분산
• 실제 쿼리 패턴과의 정합성

전략 비교

전략	장점	단점	적합한 케이스
Hashed	분산이 균등함	범위 조회 비효율	랜덤 조회 중심
Ranged	범위 조회 효율	시간축 핫스팟 위험	시계열/정렬 조회
Compound	유연한 분산 설계	설계/운영 복잡도 증가	복합 조건 조회

최소 구성 절차

// 1) 샤딩 활성화
sh.enableSharding("mydb")

// 2) 컬렉션 샤딩
sh.shardCollection("mydb.orders", { customerId: "hashed" })

쿼리 효율 관점

• Targeted Query: 샤드 키가 포함되어 특정 샤드만 조회.
• Scatter-Gather: 샤드 키가 없어 모든 샤드를 조회.

운영 비용 차이가 크므로, 주요 API는 샤드 키를 쿼리에 포함하도록 계약을 잡아야 합니다.

운영 중 자주 터지는 문제

• 단조 증가 키(createdAt 단일 키)로 특정 샤드에 쓰기 집중.
• chunk 분할/이동이 피크 시간과 겹쳐 지연 급증.
• 샤드 키 변경 불가 제약을 늦게 인지해 마이그레이션 비용 폭발.

운영 체크리스트

• sh.status()와 getShardDistribution()을 정기 확인.
• 밸런서 작업 시간대를 트래픽 저점으로 제한.
• 샤드 키 후보를 실제 트래픽으로 리허설 후 결정.
• 다중 샤드 트랜잭션 사용 비율을 모니터링.

요약

MongoDB 샤딩의 성공 여부는 기술 스택이 아니라 샤드 키에서 결정됩니다. 초기 설계에서 쿼리 패턴과 키 분포를 함께 검증해야 장기 운영 비용을 줄일 수 있습니다.