데이터를 여러 노드에 수평 분할해 저장하는 기법. 한 대가 감당 못 하는 규모를 나눈다.
복제와의 차이 — 반드시 구분
복제(Replication) 샤딩(Sharding)
┌──────┐ ┌──────┐ ┌───────┐ ┌───────┐
│ 전체 │ │ 전체 │ │ 1~1만 │ │1만~2만│
│ 사본 │ │ 사본 │ └───────┘ └───────┘
└──────┘ └──────┘ 각 노드가 일부만
각 노드가 전부
| 복제 | 샤딩 | |
|---|---|---|
| 각 노드 | 전체의 사본 | 일부만 |
| 확장되는 것 | 읽기 | 읽기 + 쓰기 + 용량 |
| 목적 | 가용성·읽기 분산 | 쓰기·용량 한계 돌파 |
쓰기가 한계면 복제로는 해결되지 않는다 — 모든 노드가 같은 쓰기를 다 받아야 하기 때문이다.
분할 방식
| 방식 | 규칙 | 장점 | 단점 |
|---|---|---|---|
| 범위 | id 1~1만 → A | 범위 조회 쉬움 | 핫스팟(최신 데이터가 한 샤드에 몰림) |
| 해시 | hash(id) % N | 균등 분산 | 노드 증설 시 대량 재배치 |
| 디렉터리 | 매핑 테이블 조회 | 유연 | 매핑 테이블이 단일 장애점 |
해시 방식의 재배치 문제
N=4 → N=5 로 늘리면 hash(key) % N 이 전부 달라져
- 거의 모든 데이터를 옮겨야 한다
→ 일관된 해싱(consistent hashing) 을 쓰면 노드 추가 시 1/N 만 이동한다. 링 위에 노드와 키를 배치해, 추가된 노드가 이웃 구간만 가져가는 방식이다.
무엇이 어려워지는가
① 크로스 샤드 조인이 사실상 불가능
- 주문은 샤드1, 회원은 샤드2 → JOIN 못 함
- 애플리케이션에서 두 번 조회해 합치거나, 회원 정보를 주문에 복사(반정규화)
② 분산 트랜잭션 두 샤드를 원자적으로 바꿀 수 없다 → Saga·최종 일관성으로 우회.
③ 전역 고유 ID 샤드마다 auto_increment를 쓰면 충돌한다 → Snowflake 등.
④ 리샤딩이 큰 공사 운영 중 재분할은 위험하고 오래 걸린다. 처음에 샤드 키를 잘 고르는 것이 결정적이다.
샤드 키 고르는 기준
- 고르게 분산되는가 — 편중되면 샤딩의 의미가 없다
- 대부분의 조회가 이 키를 포함하는가 — 없으면 모든 샤드를 뒤져야 한다(scatter-gather)
- 함께 조회되는 데이터가 같은 샤드에 모이는가 — 한 회원의 주문은 한 샤드에
면접 답변 골격
"샤딩은 마지막 수단입니다. 인덱스·쿼리 튜닝 → 캐시 → 읽기 복제 → 수직 확장을 먼저 하고, 쓰기 한계가 분명해질 때 샤딩합니다. 운영 복잡도가 크게 오르기 때문입니다."