"테이블에 데이터가 1억 건 쌓이면 어떻게 하죠?" 서비스가 커지면 한 대의 데이터베이스 서버로는 저장도 처리도 버겁습니다. 샤딩(sharding)은 그 해법 중 하나로, 하나의 큰 데이터를 여러 서버에 나눠 담아 부하를 분산하는 기법입니다. 큰 도서관 책을 한 건물에 다 못 넣으니 지점 여러 곳에 나눠 보관하는 것과 같습니다. 어떤 지점에 어떤 책이 있는지 규칙만 정해두면 됩니다.
샤딩이 다른 확장과 다른 점
| 방식 | 무엇을 늘리나 | 한계 |
|---|---|---|
| 수직 확장(Scale-up) | 서버 한 대의 CPU·메모리 | 하드웨어 상한, 비용 급증 |
| 읽기 복제(Replica) | 읽기 처리량 | 쓰기는 여전히 한 곳 |
| 샤딩(수평 분할) | 서버 대수 자체 | 구현·운영 복잡도 |
읽기 복제는 같은 데이터를 여러 곳에 복사해 읽기만 분산합니다. 반면 샤딩은 데이터를 겹치지 않게 쪼개서 서버마다 다른 행을 담으므로, 쓰기 부하와 저장 용량까지 함께 분산됩니다.
샤드 키와 분할 전략
샤딩의 핵심은 "어떤 기준으로 나눌지"를 정하는 샤드 키(shard key) 입니다. 예를 들어 user_id를 샤드 키로 삼아 서버 4대에 나눈다면, 나머지 연산으로 위치를 결정할 수 있습니다.
shard 번호 = user_id % 4
user_id 1001 → 1001 % 4 = 1 → 샤드 1
user_id 1002 → 1002 % 4 = 2 → 샤드 2
user_id 2000 → 2000 % 4 = 0 → 샤드 0
분할 전략은 크게 세 가지입니다.
| 전략 | 방식 | 특징 |
|---|---|---|
| 해시(Hash) | 키를 해시해 분산 | 고르게 분산, 범위 조회 약함 |
| 범위(Range) | 값 구간으로 분할 | 범위 조회 쉬움, 한쪽 쏠림 위험 |
| 디렉터리(Directory) | 매핑 테이블로 지정 | 유연하나 매핑 관리 부담 |
해당 사용자의 데이터를 찾을 때는 같은 규칙을 적용해 올바른 샤드로 쿼리를 보냅니다.
-- user_id 1002의 주문은 샤드 2에서 조회
SELECT * FROM orders WHERE user_id = 1002;
샤딩의 비용
샤딩은 공짜가 아닙니다. 서로 다른 샤드에 흩어진 데이터를 합치는 조인이나 집계가 어려워지고, 여러 샤드에 걸친 트랜잭션은 보장하기 까다롭습니다. 또 샤드를 추가할 때 % 4가 % 5로 바뀌면 거의 모든 데이터를 재배치해야 합니다(이 문제를 줄이려 일관된 해싱을 씁니다). 그래서 샤딩은 수직 확장과 읽기 복제로 더 버틸 수 없을 때 마지막으로 고려하는 카드입니다.
요점 정리
- 샤딩은 데이터를 겹치지 않게 여러 서버로 쪼개 쓰기·저장까지 분산하는 수평 확장.
- 샤드 키와 분할 전략(해시·범위·디렉터리)이 어디에 저장할지 결정한다.
- 교차 샤드 조인·트랜잭션·재배치 비용이 크므로 다른 확장을 먼저 검토한다.
복제와 분할이 부하를 어떻게 다르게 나누는지, 샤드 키 설계가 왜 중요한지 직접 다뤄보는 실습은 데이터베이스 트랙에서 회원가입 없이 무료로 할 수 있습니다.