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

2026-05-14·10분·

scale-outpitfallsopsproduction

단순 horizontal scale로 풀 수 없는 문제들. Single DB 병목, Cold cache spike, Microservice chain latency, Session sticky, Connection pool, Cascading failure. 각자 시뮬로 확인.

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

1. Single DB 병목

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

시뮬: scale-out-single-db. DB CPU 100%, App들은 idle. 해결 단계: read replica → cache → write sharding → CQRS.

2. Cold Cache Spike

Black Friday — instance 10배 scale-out → 새 instance 모두 cache empty. 평소 hit 95%가 30%로 떨어집니다. DB 부하 7배 폭증.

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

3. Microservice Chain Latency

5 service chain. 각자 p99 50ms. 전체 p99? ~200ms. 곱 비슷한 수치 (tail latency 누적).

시뮬: 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. 해결: 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 service 30% 실패 + 500ms 지연 → caller thread 응답 대기로 점유 → thread pool 가득 → 정상 트래픽도 거부 → upstream cascading. 한 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 늘리는 건 마지막.

🧪 시뮬레이터에서 직접 확인

이 글의 시나리오는 시뮬레이터 안에서 즉시 실행할 수 있습니다. 노브를 만지며 결과 변화 관찰.

시뮬레이터 열기 →

← 블로그 목록

4. Session Sticky 깨짐

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

시뮬: scale-out-session-sticky. 해결: 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

시뮬: 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 늘리는 건 마지막.