샤딩

1. 샤딩 (Sharding) 개요

데이터를 여러 서버(Shard)에 나누어 저장하여 처리량과 저장 용량을 확장하는 방식입니다. (수평적 확장)

• Shards: 시스템 데이터의 일부를 가진 개별 서버 혹은 레플리카 셋.
• Config Servers: 각 데이터가 어느 샤드에 있는지 위치 정보를 담고 있는 메타데이터 저장소. (반드시 레플리카 셋이어야 함)
• Query Router (mongos): 애플리케이션의 요청을 받아 적절한 샤드로 전달.

2. 샤드 키 (Shard Key)

데이터를 나누는 기준이 되는 필드입니다. 한 번 정하면 변경이 매우 어려우므로 신중히 선택해야 합니다.

• Ranged Sharding (범위 기반): 특정 필드의 값 범위를 기준으로 샤드 할당. 범위 쿼리에 유리.
• Hashed Sharding (해시 기반): 필드 값을 해시화하여 균등하게 분산. 특정 값의 집중(Hotspot) 방지.

3. 청크 (Chunk) 및 밸런서 (Balancer)

• Chunk: 샤드 내에서 연속된 데이터의 덩어리 (기본 64MB).
• Balancer: 샤드 간 청크 수가 불균형할 때 백그라운드에서 데이터를 이동시키는 프로세스.

4. 실습 명령어

// 샤딩 클러스터 상태 확인
sh.status()
 
// 특정 데이터베이스 샤딩 활성화
sh.enableSharding("myDB")
 
// 특정 컬렉션 샤딩 설정 (해시 기반 예시)
sh.shardCollection("myDB.users", { _id: "hashed" })
 
// 밸런서 상태 확인
sh.getBalancerState()

5. 시험 팁 (Certification Tips)

• 샤딩을 하더라도 데이터셋이 작고 읽기 위주라면 오히려 오버헤드가 발생할 수 있습니다.
• Shard Key Cardinality: 중복값이 적은 필드를 선택해야 데이터가 고르게 분산됩니다.
• Config 서버가 죽으면 클러스터 전체가 멈출 수 있으므로 반드시 레플리카 셋으로 안정성을 확보해야 합니다.

6. 베스트 프랙티스

• 쿼리 성능을 위해 대부분의 쿼리에 샤드 키가 포함되도록 설계하세요 (Targeted Query). 샤드 키가 없으면 모든 샤드를 뒤지는 Broadcast Query가 발생하여 성능이 저하됩니다.
• 쓰기가 집중되는 Hotspot을 피하기 위해 Timestamp 필드를 샤드 키로 쓸 경우 반드시 Hashed Sharding을 고려하세요.