Thundering Herd 문제 이해하기: 분산 시스템에서 Stampede 억제
Source: Dev.to
번역을 진행하려면 번역이 필요한 전체 텍스트를 제공해 주시겠어요? 텍스트를 알려주시면 한국어로 번역해 드리겠습니다.
The Thundering Herd Problem
인기 있는 가게가 오전 9시 정각에 문을 연다고 상상해 보세요. 수백 명의 고객이 밖에 줄을 서서 동시에 몰려 들어가며 계산원을 압도하고 혼란을 초래합니다.
분산 시스템에서도 동시에 너무 많은 요청이 공유 자원에 몰릴 때 같은 일이 발생할 수 있습니다—이를 Thundering Herd Problem이라고 부릅니다.
Diagram
NORMAL OPERATION (Cache Hit) THUNDERING HERD (Cache Miss Stampede)
Fast path Failure path
┌─────────────┐ ┌─────────────┐
│ Clients │ │ Clients │
│ 10k users │ │ 10k users │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
┌─────▼─────┐ Cache Hit ┌──────────────┐ ▼
│ App Server│◄──────────────│ Redis Cache │ ┌──────▼──────┐
│ Node 1 │ │ key=product1 │ │ 10k Cache │
└─────┬─────┘ │ TTL=60s │ │ MISSES │
│ └──────┬───────┘ └──────┬──────┘
│ Cache Miss │ │
▼ ▼ ▼
┌─────▼─────┐ ┌──────────────┐ ┌──────────────┐
│ App Server│ │ Database │ │ Database │
│ Node 2 │◄─── 1 Query ────│ 1 Query Only │ │ 10k Queries! │
└─────┬─────┘ │ Returns Data│ │ CPU=1000% │
│ └──────┬───────┘ └──────────────┘
│ │ 💥 OVERLOAD
└──────────┬─────────────────┘
│
┌────▼────┐
│Cache Set│ ← Serves all 10k clients
└─────────┘Thundering Herd 문제란?
Thundering Herd 문제는 다수의 클라이언트 또는 프로세스가 동시에 동일한 공유 자원(예: 데이터베이스 또는 캐시)을 경쟁할 때 발생합니다. 이는 시스템을 압도하는 갑작스러운 트래픽 급증을 초래합니다. 점진적인 부하 증가와 달리, herd는 동기화된 폭발이며—수백만 건의 요청에서 캐시 키가 정확히 같은 시점에 만료되는 것을 생각해 보세요.
Where It Commonly Occurs
| Component | Typical Scenario |
|---|---|
| Caching systems | 인기 있는 캐시 항목이 동시에 만료되어 대량 백엔드 조회를 트리거합니다. |
| Databases | 여러 앱 서버가 캐시 미스 후 DB를 강타합니다. |
| Load balancers | 다른 곳에서 장애가 발생할 때 요청이 단일 정상 노드에 몰립니다. |
| Lock acquisition | 프로세스가 중요한 섹션의 뮤텍스를 놓고 경쟁합니다. |
In a typical app architecture:
- 클라이언트가 앱 서버에 질의합니다.
- 서버는 먼저 Redis(또는 다른 캐시)를 확인합니다.
- Cache hit? 즉시 제공합니다.
- Cache miss? DB에서 가져와 캐시를 재채우고, 그 후 제공합니다.
실제 사례: 캐시 만료 급증
Netflix가 새로운 인기 프로그램을 출시한다고 가정해 보겠습니다. 수백만 명의 사용자가 60초 TTL로 캐시된 에피소드 데이터를 요청합니다. TTL이 만료되면:
Normal: Cache serves 10k req/s at ~1 ms latency
Expiry: 10k DB queries at ~100 ms each → 5‑10× overload결과: 데이터베이스 연결이 고갈되고, 지연 시간이 초 단위로 급증하며, 연쇄적인 장애가 전체 애플리케이션에 영향을 미칩니다. 인도에서 IPL 티켓 판매 시나 블랙프라이데이 전자상거래 급증 시에도 유사한 스파이크가 발생합니다.
정상 트래픽 급증 vs. 천둥 무리 현상
| Aspect | Normal Traffic Spike | Thundering Herd |
|---|---|---|
| Cause | 유기적 성장 (마케팅, 이벤트) | 동기화된 이벤트 (TTL 만료, 크론 작업) |
| Pattern | 점진적 증가 | 즉각적인 폭발 |
| Impact | 자동 스케일링으로 대응 가능 | 스케일링된 용량조차 압도 |
| Duration | 분‑시간 | 초 (하지만 파괴적) |
| Key difference | 예측 가능하고 분산됨 | 예측 가능하지만 동기화되어, 작은 취약성 창을 확대해 장애로 이어짐 |
분산 시스템에서 위험한 이유
Clients → App → DB overload → Timeouts → Retries → More DB load → 💥- 증폭 – 캐시 미스 1회 → N DB 쿼리 (여기서 N = 동시 클라이언트 수).
- 꼬리 지연 – 가장 느린 DB 쿼리가 모두를 차단합니다.
- 연쇄 실패 – 과부하된 DB가 애플리케이션을 느리게 만들고 → 타임아웃이 증가 → 재시도 폭풍이 발생합니다.
- 자동 스케일링 지연 – 트래픽 급증이 새 인스턴스가 가동되기엔 너무 짧습니다.
- 멀티 리전 설정에서는 한 지역의 급증이 전 세계에 파급될 수 있습니다.
시스템 영향 분석
CPU 과부하
- 갑작스러운 스레드 폭발이 스케줄러를 뒤흔들고, 컨텍스트 전환이 급증합니다.
데이터베이스 부담
- 연결 풀 고갈; 쿼리 대기열이 급증 → 타임아웃이 연쇄적으로 발생합니다.
캐시 비효율성
- 스탬피드 상황에서는 캐시가 무용지물이 됩니다—아예 캐시가 없는 것보다 더 나쁩니다!
지연 시간 폭발
- P99 지연 시간이 100배까지 상승하여 사용자가 세션을 포기하게 됩니다.
예방 기술
- Stale‑While‑Revalidating – 하나의 요청만 캐시를 새로 고치고, 다른 요청은 오래된 데이터를 제공하고 결과를 재사용합니다.
- Mutex (Distributed Lock) – 락(예: Redis
SETNX)을 사용하여 오직 하나의 요청만 DB에 접근하도록 합니다. - Jitter on TTL –
TTL = base + random(0, maxJitter)로 동기화된 만료를 방지합니다. - Probabilistic Early Computation – 접근 빈도나 만료 시점에 가까운 정도에 따라 핫 키를 미리 갱신합니다.
- Rate Limiting – 키/사용자당 요청 수를 제한하여 백엔드 과부하를 방지합니다.
- Circuit Breaker / Bulkhead – 실패한 구성 요소를 격리하고, 대량 요청이 전파되기 전에 부하를 차단합니다.
- Cache Warm‑up – 중요한 키를 만료되기 전에 미리 채워두어(예: 트래픽이 적은 시간대에) 성능 저하를 방지합니다.
캐시 워밍
- 트래픽 급증이나 배포 전에 핫 키를 미리 로드합니다.
실제 장애 사례: Facebook의 2010년 캐시 스탬피드가 해결되기까지 몇 시간이 걸렸습니다 –
The Day Facebook Died – A Cache‑Stampede Horror Story That Changed Tech Forever
최종 생각
Thundering Herd는 “대규모 작업”을 적절한 보호 장치 없이 정전으로 바꿔 놓습니다.
이 패턴들을 마스터하세요—계단식 TTL + 결합 + 백오프.
다음에 캐시가 만료될 때 기억하세요: 한 마리 소는 괜찮지만, 무리는 치명적입니다.