MySQL을 확장할 때 언제 파티셔닝(partitioning)을, 언제 샤딩(sharding)을 선택하는가?

Question

IT Interview Practice · Accepted Answer

둘 다 큰 테이블을 분할하지만, 그 층위가 다릅니다. **파티셔닝**은 하나의 테이블을 **단일 MySQL 서버 내부의** 여러 파일로 분할합니다. **샤딩**은 데이터를 **여러 독립적인 서버로** 분할합니다. 파티셔닝은 한 파일에 담기엔 너무 큰 테이블에 도움이 되고, 샤딩은 한 대의 머신에 담기엔 너무 큰 워크로드에 도움이 됩니다.

## 파티셔닝 (단일 서버)

```sql
CREATE TABLE events (
  id BIGINT, created_at DATETIME, payload JSON,
  PRIMARY KEY (id, created_at)          -- partition key must be in every unique key
) PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION p2026 VALUES LESS THAN (2027)
);
-- Queries filtering on created_at hit ONE partition (partition pruning);
-- dropping old data is an instant ALTER TABLE ... DROP PARTITION p2024.
```

시계열 데이터와 손쉬운 아카이빙에 훌륭하지만, 여전히 한 대의 서버입니다 — 전체 CPU, RAM, 쓰기 처리량이 늘어나지는 않습니다.

## 샤딩 (여러 서버)

**샤드 키(shard key)**(예: `user_id`)를 선택하고 해시나 범위로 각 행을 샤드에 라우팅합니다:

```
shard = hash(user_id) % N
  user 42 -> shard 2 (server B)     user 99 -> shard 0 (server A)
```

- **장점** — 쓰기, 저장 공간, 연결 수가 거의 선형적으로 확장됩니다.
- **단점** — 샤드 간 JOIN과 트랜잭션이 어렵거나 불가능하고, 잘못된 샤드 키는 핫스팟을 만들며, 서버를 추가할 때의 **리샤딩(resharding)**이 고통스럽습니다. 카디널리티가 높고 고르게 분포하는 키를 고르고, 모든 샤드로 팬아웃해야 하는 쿼리는 피하세요.

## 작업 순서

더 저렴한 방법부터 소진하세요: 인덱싱, 쿼리 튜닝, 읽기 레플리카, 캐싱, 그다음이 파티셔닝입니다. 단일 프라이머리가 더 이상 **쓰기** 볼륨을 감당할 수 없을 때만 샤딩을 선택하세요 — 운영 복잡도에서 가장 큰 도약이기 때문입니다.

## 왜 중요한가

확장 결정은 대체로 되돌릴 수 없고 비용이 큽니다. 파티셔닝은 단일 서버의 조직화 도구인 반면 샤딩은 분산 시스템에 대한 약속(샤드 키와 샤드 간 비용을 수반)이라는 것을 알면, 팀이 성급하게 샤딩하거나 파티셔닝이 해결할 수 없는 쓰기 처리량 한계를 파티셔닝으로 해결하려 기대하는 일을 막을 수 있습니다.

파티셔닝 (단일 서버)

샤딩 (여러 서버)

작업 순서

왜 중요한가

관련 질문