콘텐츠로 이동

샤딩 (Sharding)

단일 서버로는 감당이 안 되는 규모(대량 데이터·쓰기 부하)에 도달하면, MongoDB 는 샤딩으로 데이터를 여러 노드(샤드)에 분산합니다. 이번 장은 샤딩의 구성 요소와 샤드 키 선택이 왜 중요한지를 데이터스케쳐스 실무 관점에서 정리합니다.

샤딩 구성

  • 샤드(Shard): 실제 데이터를 나눠 저장하는 노드. 보통 복제셋(replica set)으로 구성해 고가용성.
  • Config 서버: 샤드 메타데이터(어느 데이터가 어느 샤드에 있는지) 저장.
  • 라우터(mongos): 클라이언트 요청을 올바른 샤드로 라우팅.

데이터는 샤드 키 값(또는 해시)의 범위를 청크(chunk) 단위로 나눠 여러 샤드에 분산됩니다.

샤드 키가 핵심

샤드 키는 데이터가 어떻게 흩어질지를 결정하므로 가장 중요한 설계 단위입니다.

  • 균등 분산: 카디널리티가 낮은 키(예: 단순 boolean)나 액세스가 편중된 키는 특정 샤드에 몰려(hot spot) 부하가 쏠립니다.
  • 쿼리 패턴 맞춤: 자주 쓰는 쿼리가 샤드 키를 포함하면 라우터가 해당 샤드 몇 개만 방문(targeted)해 효율적이고, 샤드 키가 없으면 전체 샤드를 스캔(collect)해야 합니다.
  • 해시 샤딩("hashed")은 범위 샤딩 대비 균등 분산에 유리하지만, 범위 쿼리는 샤드 전반을 거칩니다.

데이터스케쳐스 실무 관점

  • 대규모 이벤트/로그 저장: 행사·이벤트 데이터가 폭발적으로 늘어날 때, 샤드 키를 테넌트(id)+시간 등 쿼리 패턴과 맞는 조합으로 잡아 균등 분산·타깃 쿼리를 노립니다.
  • 마이그레이션 주의: 샤드 키는 샤딩 활성화 후 변경이 어렵습니다(5.0부터 reshard 지원). 데이터가 커지기 전에 신중히 설계하세요.
  • 복제(고가용성)와 샤딩(스케일 아웃)은 목적이 다르므로, 먼저 복제로 HA를 확보하고 샤딩은 정말 필요한 수평 확장 시점에 도입하는 게 일반적입니다.

확인 필요

  • 샤드 키·zone/범위 배치 세부는 MongoDB 버전에 따라 다르므로, 사용 버전 공식 문서를 재확인하세요. (확인 필요)

더 알아보기