10억 사용자를 위해 데이터베이스를 어떻게 샤딩(shard)하시겠습니까?

Question

IT Interview Practice · Accepted Answer

**거의 모든 쿼리에 존재하고 부하를 고르게 분산하는** key로 샤딩하십시오 — 보통 hash된 `user_id` — 그리고 리샤딩(resharding)과 cross-shard 쿼리를 첫날부터 계획하십시오. 10억 사용자는 하나의 노드에 맞지도, 성능이 나지도 않습니다. row를 여러 데이터베이스에 나누고 각 쿼리를 그것을 소유한 shard로 라우팅합니다.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Shard key 선택 — 되돌리기 어려운 결정

**높은 cardinality, 고른 분산, 대부분의 쿼리에 존재**하는 key를 고르십시오. `user_id`가 보통 이깁니다: 사용자 범위 쿼리("내 프로필, 내 주문")는 정확히 하나의 shard를 칩니다. 나쁜 key(예: `country`)는 핫스팟을 만듭니다 — 한 shard가 인도 전체를 보유하고 다른 shard는 놀고 있습니다.

## Hash vs range

- **Hash 샤딩**(`shard = hash(user_id) % N`): 고르게 분산되어 핫스팟을 제거하지만 — range 쿼리("지난주 생성된 사용자")는 모든 shard에 scatter-gather해야 합니다.
- **Range 샤딩**(`user_id 0–1M → shard 0`): range를 로컬로 유지하고 리샤딩을 쉽게 만들지만, 핫스팟 위험이 있습니다(가장 최근 사용자가 모두 마지막 shard에 몰림).
- 흔한 답변: **고른 부하를 위한 hash**에 더해, 전체를 rehash하지 않고 range를 이동할 수 있도록 **lookup/directory 테이블**을 두는 것.

## 리샤딩 — 필요하기 전에 계획하라

`% N`은 함정입니다: shard 하나를 추가하면 거의 모든 key가 remap됩니다. **consistent hashing** 또는 **virtual buckets**(key → 4096 논리 버킷 → 물리 shard 매핑)를 사용하십시오. shard 분할은 전체 keyspace가 아니라 bucket만 이동시킵니다. **Vitess**(YouTube/Slack 사용) 같은 도구는 cutover와 함께 라이브 리샤딩을 자동화합니다.

## Cross-shard 쿼리

shard key로 키잉되지 않은 모든 것은 고통스럽습니다: 전역 "top posts" 쿼리는 모든 shard로 팬아웃하고 병합합니다. **역정규화**하거나 cross-cutting read를 위한 별도의 index/search store(Elasticsearch)를 유지하여 완화하십시오.

## 면접 관점

면접관은 당신이 shard-key 선택이 **준영구적(semi-permanent)**임을 이해하는지, 그리고 **리샤딩과 cross-shard join**을 고민했는지 — 프로덕션에서 물어뜯는 두 가지 — 파고듭니다. 좋은 답변: "user_id로 샤딩한다." 훌륭한 답변: consistent hashing, hot-shard 완화, 그리고 shard 간 분산 트랜잭션은 아예 피하는 게 최선이라는 사실을 언급합니다.

**흔한 함정:** 고정된 N으로 `hash % N`을 쓰는 것 — 향후 성장을 전체 데이터 마이그레이션으로 만듭니다.

## 트레이드오프 및 실패 모드

- **cross-shard ACID 상실:** shard 간 저렴한 join/트랜잭션이 없습니다. saga를 쓰거나 역정규화하십시오.
- **Hot shard:** 바이럴 사용자. 서브샤딩하거나 그 엔티티를 캐시하십시오.
- **재분산 위험:** 라이브 마이그레이션은 cutover 전에 이중 write하고 검증해야 합니다.
- **운영 비용:** N개 shard × replica = 모니터링, 백업, failover할 데이터베이스가 많아집니다.

Shard key 선택 — 되돌리기 어려운 결정

Hash vs range

리샤딩 — 필요하기 전에 계획하라

Cross-shard 쿼리

면접 관점

트레이드오프 및 실패 모드

관련 질문