서버 100대 늘렸는데 왜 안 빨라지나 — Scale-out 함정 6가지

"사용자가 늘었어요. 서버 N대로 늘리면 되죠?" — 면접 화이트보드에서 가장 흔한 발언. 실제 production에서는 단순 horizontal scale로 안 풀리는 함정이 6가지 있습니다.

1. Single DB 병목

App 10대로 늘리면 NGINX는 부하 분산 OK. 하지만 모든 트래픽이 같은 MySQL로 가면 DB max_connections / cpu / disk IOPS 한계로 막힙니다.

시뮬: scale-out-single-db. App 10대 + 10,000 RPS 실측: DB CPU 88%(피크 90%대)인데 App은 32%로 논다. 해결 단계: read replica → cache → write sharding → CQRS.

2. Cold Cache Spike

Black Friday — instance 10배 scale-out → 새 instance 모두 cache empty. 평소 hit 95%가 30%로 떨어집니다. 10초 실측: DB가 받는 건수가 2,454건 → 34,691건, 14배 폭증(DB CPU 2%→25%).

시뮬: scale-out-cold-cache. 해결: pre-warm (hot key 미리 채움) / canary rollout (트래픽 1% → 10%) / multi-tier cache (local + remote).

3. Microservice Chain Latency

5 service chain, 홉당 편도 5ms. 1,000 RPS 실측: 서비스 카드는 전부 CPU 53~56%로 한가하고 드롭도 0인데, e2e는 p50 127.7ms · p99 142.1ms다. 인터넷 왕복 40ms + 사내 홉 6개 왕복 60ms = 100ms가 "가는 시간" — 즉 지연의 78%는 어느 서비스 카드에도 안 찍힌다.

시뮬: scale-out-chain-latency. 해결: parallel call (Promise.all) / GraphQL aggregator / hedged request / chain 단축 (modular monolith).

4. Session Sticky 깨짐

App x3에 in-memory session. LB round-robin이라 user 다음 요청이 다른 instance로 가면 session 없음 → logout. 새 instance 추가만으로도 발생.

시뮬: scale-out-session-sticky는 App 3대가 외부 Redis 세션 저장소를 공유하는 구성 예시다 (엔진은 사용자별 세션·instance affinity를 모델링하지 않으므로 세션 유실 자체는 재현하지 않는다). 해결: sticky session (HAProxy cookie) / 외부 Redis store / JWT stateless. 현대 표준은 JWT + 짧은 TTL + refresh token.

5. Connection Pool Exhaustion

App 20대 × HikariCP 50 = 1000 connection. DB max_connections 200이면 800개 거부. App scale-out 시 pool 크기 × instance 수가 DB max를 넘으면 곧장 장애.

시뮬: scale-out-pool-exhaustion. 해결: connection pooler middleware (PgBouncer / proxysql / managed DB proxy) — app 5000 conn → DB 100 conn 멀티플렉싱.

6. Cascading Failure

Downstream(External Gateway) 30% 실패 + 500ms 지연. 1,500 RPS 실측: 성공률 5.7%, p50 7,481ms. 먼저 마르는 건 스레드 200개가 아니라 그 앞의 아웃바운드 HTTP 클라이언트 풀 60(App 3대 × 기본 20)이다 — 호출 하나가 0.5초 이상 풀을 붙잡으니 통과 상한이 60 ÷ 0.5s ≈ 120 RPS로 잘리고 (실측 완료 81 RPS), 그동안 App CPU는 0%다. 공용 아웃바운드 자원 하나가 마르면 그 노드로 가는 모든 트래픽이 같이 죽는다 — "한 service 죽으면 전체 다운"의 실체다.

시뮬: scale-out-cascading. 해결 — Resilience4j 풀세트:

• Timeout: 호출자가 deadline 내 포기
• Circuit Breaker: 실패율 임계 시 fast-fail
• Bulkhead: thread pool 격리
• Retry + jitter: transient 실패만 재시도
• Fallback: 실패 시 cached 응답 / default 값

결론

Horizontal scale은 toolbox의 한 가지일 뿐. 위 6 함정 중 어느 하나라도 해결 안 된 채로 instance만 늘리면 자원만 낭비합니다.

제대로 된 답: 부하 늘면 먼저 측정 → 병목 찾기 → 그 병목 해결 (cache / replica / sharding / CB). instance 늘리는 건 마지막.