🪓 DB 샤딩(Sharding)이 필요한 이유 – 수평 확장과 비용 절감의 시작
데이터베이스(DB)는 서비스의 심장입니다.
하지만 데이터가 폭발적으로 늘어나면,
단일 DB는 성능·비용·안정성 모두에서 한계를 맞게 됩니다.
이때 등장하는 해결책이 바로 샤딩(Sharding)입니다.
🔰 1. 샤딩(Sharding)이란?
하나의 커다란 데이터셋을 여러 DB 서버에 나누어 저장하는 기법
- "Shard" = 파편, 조각
- 데이터를 여러 조각으로 나누어 서로 다른 서버에 분산 저장
- 수평 확장(Scale-out) 구조의 핵심
📦 2. 샤딩이 필요한 이유
1) 성능 문제
- 단일 DB에 모든 읽기·쓰기 요청이 집중 → 처리 속도 저하
- 쿼리 응답 시간이 늘어나고 트랜잭션 지연 발생
2) 용량 문제
- 저장 용량 한계 도달 (수백 GB~수 TB 이상)
- 인덱스 크기 증가로 조회 성능 저하
3) 비용 문제
- 고성능 서버(Scale-up)는 가격이 기하급수적으로 비쌈
- 여러 대의 중저가 서버로 나누는 것이 효율적
🧠 3. 샤딩 방식
| 방식 | 설명 | 예시 |
|---|---|---|
| Range Sharding | 키 값 범위별 분리 | ID 1~1,000,000 → DB1, 그 이후 → DB2 |
| Hash Sharding | 해시 함수로 균등 분배 | user_id % 4 → 0: DB1, 1: DB2... |
| Geo Sharding | 지역 기반 분리 | KR 데이터 → DB1, JP 데이터 → DB2 |
| Directory Sharding | 중앙 라우터가 결정 | 샤드 매핑 테이블로 위치 관리 |
📊 4. 샤딩 구조 예시
[Application]
↓
[Sharding Logic]
↓
┌────────┬────────┬────────┐
│ DB1 │ DB2 │ DB3 │
└────────┴────────┴────────┘- 애플리케이션에서 샤딩 로직 포함 (ORM, 미들웨어, DB Proxy)
- 각 DB는 전체 데이터의 일부만 저장
⚠️ 5. 샤딩의 단점과 주의점
| 단점 | 설명 |
|---|---|
| 쿼리 복잡도 | 여러 샤드에 걸친 조인, 검색이 어려움 |
| 운영 복잡성 | 샤드 추가·이동·병합 시 데이터 마이그레이션 필요 |
| 트랜잭션 문제 | 샤드 간 트랜잭션(XA) 구현이 복잡 |
| 데이터 불균형 | 특정 샤드에 데이터 몰리면 성능 저하 (Hot Spot) |
🏢 6. 실무 적용 사례
| 서비스 | 샤딩 기준 |
|---|---|
| 카카오톡 | 사용자 ID 기반 Hash Sharding |
| 배달의민족 | 주문 ID 기반 Range Sharding |
| 글로벌 게임 서버 | 지역(Region) 기반 Geo Sharding |
💡 7. 비용 관점에서 본 샤딩
- Scale-up (더 좋은 서버로 교체) → 성능 증가폭 대비 비용 급등
- Scale-out (서버 여러 대 추가) → 확장성 높고 비용 효율적
- AWS, GCP, Azure에서도 대규모 DB 서비스는 샤딩 구조 사용
✅ 8. 요약
샤딩은 성능 한계와 비용 문제를 동시에 해결하는 강력한 무기지만,
설계와 운영의 복잡성을 감수해야 합니다.
키포인트
- 대규모 트래픽·데이터 → 샤딩 고려 필수
- 샤딩 방식: Range, Hash, Geo, Directory
- 장점: 성능 향상, 수평 확장, 비용 절감
- 단점: 운영·쿼리·트랜잭션 복잡성
INTJ