트래픽이 100배 증가할 때 MySQL을 어떻게 확장하시겠습니까?

Question

IT Interview Practice · Accepted Answer

단계적으로 확장하십시오: **read는 read replica + 캐싱 먼저, 그다음 write는 샤딩(Vitess)** — 그리고 무엇보다 먼저 connection pooling을 추가하십시오, 그것이 가장 저렴한 10배이기 때문입니다. read와 write는 다르게 확장되므로 첫날부터 샤딩에 손대지 마십시오.

```text
        ┌─▶ Cache (Redis) ── hit ──▶ return
App ─▶ Pool(PgBouncer/ProxySQL)      miss ▼
        │                    ┌─▶ Read replica 1 ┐
        ├──── reads ─────────┼─▶ Read replica 2 ┼─ (async replication)
        │                    └─▶ Read replica N ┘
        └──── writes ──▶ Primary ──▶ (later) Vitess shards ─▶ Primary A / Primary B
```

## 0단계: connection pooling

모든 MySQL 연결은 메모리와 스레드를 소비합니다. 100배 트래픽에서는 CPU보다 훨씬 먼저 `max_connections`를 소진합니다. **ProxySQL**이나 **PgBouncer** 같은 pooler는 수천 개의 앱 연결을 수백 개의 DB 연결로 multiplex합니다. 재설계가 아니라 설정 변경입니다 — 먼저 하십시오.

## 1단계: read를 캐시하라

대부분의 워크로드는 read-heavy입니다(흔히 90% 이상). hot row — 사용자 프로필, 상품 페이지 — 를 위해 앞단에 **Redis**를 두십시오. cache hit는 MySQL을 절대 건드리지 않습니다. cache-aside를 사용하십시오: 캐시 read → miss → DB read → 캐시 채우기. 이것만으로 100배의 대부분을 흡수할 수 있습니다.

## 2단계: read replica

**async read replica**를 추가하고 SELECT는 replica로, write는 primary로 라우팅하십시오. 이는 read를 수평 확장합니다: N replica ≈ N배 read 용량. 함정은 **복제 지연(replication lag)**입니다 — replica가 밀리초~초 단위로 뒤처질 수 있으므로 read-your-own-writes에는 주의가 필요합니다(해당 사용자의 read를 primary로 라우팅하거나 캐시에서 읽기).

## 3단계: write를 샤딩하라

replica는 write에 도움이 되지 않습니다 — 모든 write는 여전히 단일 primary를 칩니다. write throughput이 한 대를 포화시키면 **샤딩**하십시오. **Vitess**(YouTube에서 개발)는 MySQL 앞에 위치하여 앱을 다시 쓰지 않고 샤딩, 쿼리 라우팅, 온라인 리샤딩을 수행합니다. 대부분의 쿼리가 single-shard로 유지되도록 `user_id`로 샤딩하십시오.

## 면접 관점

면접관은 **순서**를 봅니다: 즉시 샤딩하는 지원자는 replica/캐싱이 read 확장을 훨씬 저렴하게 해결한다는 것을 모른다는 것을 드러냅니다. 좋은 답변: "replica와 캐시를 추가한다." 훌륭한 답변: read 경로와 write 경로를 분리하고, replica의 비용으로 복제 지연을 짚으며, *write*가 — read가 아니라 — 병목일 때만 샤딩을 도입합니다.

**흔한 함정:** 실제 병목이 write throughput인데 "그냥 read replica를 추가한다"는 것. replica는 그것을 *악화*시킵니다(primary에 복제 부하가 더해짐).

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

- **복제 지연:** stale read. 중요한 read는 primary에 고정하거나 semi-sync 복제를 쓰십시오.
- **Cache stampede:** 만료 시 많은 miss가 동시에 DB를 칩니다 — lock이나 엇갈린 TTL을 쓰십시오.
- **샤딩 복잡성:** cross-shard join과 트랜잭션을 잃습니다. write가 강제할 때만 이 비용을 치르십시오.
- **Failover:** primary 사망 시 자동 승격(Orchestrator)이 필요합니다. stale하게 승격된 replica는 최근 write를 잃을 수 있습니다.

0단계: connection pooling

1단계: read를 캐시하라

2단계: read replica

3단계: write를 샤딩하라

면접 관점

트레이드오프 및 실패 모드

관련 질문