5편. 실전 운영 장애 사례 10선 + 장애 복구 플레이북

 

실전 운영 장애 사례 10선

🟦 5편. 실전 운영 장애 사례 10선 + 장애 복구 플레이북

운영 환경에서 장애는 절대 피할 수 없다.
문제는 장애를 얼마나 빨리 감지하고, 얼마나 빨리 정상화하느냐다.

이번 편에서는 실제 운영에서 반복적으로 발생했던 장애들을 유형별로 정리하고,
각 장애마다 즉시 대응할 수 있는 복구 플레이북(Playbook) 을 제공한다.

---

■ 1) 장애 유형 10선 — 가장 자주 터지는 실제 사례

---

🟦 장애 01 — DB Connection Pool 고갈 (HikariCP)

증상:

• API 응답 3~10초 증가
• Hikari: “Connection not available” 경고 반복

원인:

• 특정 쿼리 지연
• 풀 사이즈 부족
• 커넥션 누수(leak)

즉시 복구:

1. 모니터링에서 active connection 급증 확인
2. DB slow query 조회
3. 장애 구간 트래픽 우회 or scale-out

근본 조치:

• maxLifetime → DB wait_timeout 맞추기
• 커넥션 누수 로그 추가
• 문제 SQL 실행계획 튜닝

---

🟦 장애 02 — Redis 장애 (timeout, cluster failover)

증상:

• 인증 API 폭발
• 세션/토큰 다수 invalid 발생
• 캐시 조회 시간 타임아웃 증가

원인:

• Redis 단일 노드 부하 집중
• cluster failover
• slow command(MGET, KEYS 등)

즉시 복구:

• Redis client timeout 확대
• 임시로 캐시 사용 off (fallback)
• 장애 구간 데이터 캐시 flush

근본 조치:

• key 패턴 최적화
• TTL 정책 재설계
• 캐시 미스 대응 로직 적용(캐시 스탬피드 방지)

---

🟦 장애 03 — MQ(Kafka) Consumer Lag 폭주

증상:

• 메시지 처리 지연
• 배치성 기능이 수 시간 지연
• lag 수만~수십만 발생

원인:

• consumer 중 일부 인스턴스 죽음
• 처리 시간이 메시지 생성 속도를 못 따라감
• partition 불균형

즉시 복구:

• consumer scale-out
• 느린 partition만 재배치
• consumer group 재시작

근본 조치:

• 메시지 처리 로직 병렬화
• 파티션 재설계
• ack 모드 및 commit 정책 조정

---

🟦 장애 04 — WAS OOM(OutOfMemory) 발생 → 서비스 중단

증상:

• pod/container 재시작 반복
• GC pause 증가
• 메모리 누수 경고

원인:

• 대량 객체 메모리 축적
• 캐시 oversize
• Jackson/JSON huge payload

즉시 복구:

• 인스턴스 즉시 재기동
• 메모리 덤프 확보
• 장애 API 임시 차단

근본 조치:

• heap dump 분석
• 객체 라이프사이클 정리
• 캐시 크기 정책화
• DTO projection으로 직렬화 최소화

---

🟦 장애 05 — JVM Thread Pool 고갈 (Tomcat/Netty)

증상:

• API 호출이 무한 Pending
• thread count max 도달
• 503 or timeout 다량 발생

원인:

• Blocking IO 대량 발생
• DB 지연 → thread 장기 점유
• async thread pool misconfiguration

즉시 복구:

• thread dump 분석
• 폭주시킨 API 큐 차단
• 서버 인스턴스 scale-out

근본 조치:

• 비동기 전환
• connection pool, thread pool 사이즈 재설계
• DB 튜닝

---

🟦 장애 06 — 배치(Job) 무한 대기 / Deadlock

증상:

• 배치가 “RUNNING” 상태로 멈춤
• 다음 작업이 실행되지 않음
• DB lock wait 증가

원인:

• DB 트랜잭션 lock
• 스케줄링 충돌
• 중복 실행

즉시 복구:

• lock session kill
• 배치 작업 강제 종료
• 스케줄 간 충돌 시간대 조정

근본 조치:

• 배치 idempotent 설계
• chunk size 조정
• 분산락(Redis Lock) 도입

---

🟦 장애 07 — 외부 API 장애 → 우리 API까지 전파

증상:

• 외부 API timeout
• 우리 서버 thread 점유 증가
• 전체 응답 지연

원인:

• 회로 차단 미적용
• Connection timeout 과도하게 김
• retry 과도 발생

즉시 복구:

• timeout 즉시 줄이기
• fallback 활성화
• 외부 API 콜을 임시 차단

근본 조치:

• Resilience4j CircuitBreaker 적용
• retry, bulkhead, timeout 정책 정립
• 비동기/queue 방식 전환

---

🟦 장애 08 — 파일 업로드 저장소 장애 (NFS, S3)

증상:

• 업로드/다운로드 지연
• WAS thread 대기 증가
• time-wait 수 폭증

원인:

• 네트워크 지연
• 파일 서버 장애
• 대량 요청으로 IOPS 부족

즉시 복구:

• 업로드 기능 임시 중단
• 파일 서버 failover
• 캐싱된 파일로 대체 제공

근본 조치:

• 파일 CDN 분리
• 비동기 업로드로 아키텍처 개선
• pre-signed URL 활용

---

🟦 장애 09 — DB 스토리지 Full 또는 I/O 폭주

증상:

• insert/update 실패
• 테이블 lock
• write latency 급증

원인:

• 로그/백업 파일 누적
• stat/index file 폭증
• 장기간 배치로 인한 I/O 폭주

즉시 복구:

• 긴급 스토리지 확장
• 불필요한 로그 삭제
• index rebuild

근본 조치:

• 자동 purge 정책
• partition table 적용
• archive 테이블 분리

---

🟦 장애 10 — ALB/Nginx Rate Limit 또는 네트워크 장애

증상:

• 429 Too Many Requests
• 특정 구간 API만 타임아웃
• health check 실패

원인:

• 급격한 트래픽 증가
• 잘못된 rate limit 설정
• 네트워크 라우팅 장애

즉시 복구:

• rate limit 임시 완화
• 트래픽 일부를 서브 도메인으로 분리
• 인스턴스 scale-out

근본 조치:

• API 별 rate limit 정책화
• CDN 사용
• 네트워크 구간 장애 감시 자동화

---

■ 🔥 운영팀이 꼭 가져야 할 “장애 복구 플레이북(Playbook)”

운영 복구에는 정해진 순서가 있다.
모든 장애 현장에서 가장 빠르게 정상화하는 팀들의 공통 전략을 아래에 정리했다.

---

✔ 1단계 — 문제 감지 (Detection)

가장 중요한 기준은 지표 이상감지(alert) 이다.

• API latency
• DB connection usage
• CPU/Memory spike
• error rate
• Kafka consumer lag
• Redis ops count 변동

---

✔ 2단계 — 빠른 원인 단서 수집 (Gather Clues)

5분 안에 해야 할 행동:

● 1) thread dump

● 2) DB active session / slow query

● 3) redis/mq 지표

● 4) network latency

● 5) 최근 배포 여부

---

✔ 3단계 — 서비스 즉시 안정화 (Mitigation)

이 단계에서 “정상화 시간”이 갈린다.

• 트래픽 차단 or 리밋
• scale-out
• 장애 API 격리
• 특정 기능 강제 OFF
• 캐시 fallback 적용

운영팀이 가장 두려워하는 건 사용자 유입을 버티지 못해 전체 장애로 확대되는 상황이다.

---

✔ 4단계 — 근본 원인 제거 (Root Cause)

평상시에 해두지 않으면 불가능한 단계.

• 쿼리 튜닝
• 인덱스 재설계
• 캐시 정책 재정립
• thread pool 재설정
• 배치 구조 개선
• retry/circuit breaker 정책화

---

✔ 5단계 — 재발 방지 자동화 (Prevention)

운영팀의 트러블슈팅 레벨이 여기서 결정된다.

• SLA 기반 alert 재설계
• chaos engineering
• canary 배포
• 자동 rollback
• traffic shadowing
• 부하 테스트 정기화

---

■ 마무리

운영 장애는 누구에게나 발생하지만,
각 장애를 빠르게 복구하고 재발까지 막는 팀은 아주 드물다.

핵심은 다음 한 줄로 요약된다.

“장애는 준비된 팀에게는 단순한 이벤트이고, 준비되지 않은 팀에게는 재난이다.”

다음 편에서는 운영 장애 복구에 이어

“트래픽 급증에 버티는 시스템 설계 — 스케일링 전략 정리”

편으로 이어가겠다.

---

🔖 Tags

Java, SpringBoot, SpringPerformance, RealWorldTips, BackendEngineering, ProductionIssue, SystemDesign, ArchitecturePatterns, Database, Redis, Kafka, Resilience4j, DevOps, Troubleshooting, Playbook

🍃 Spring Boot 성능 튜닝 시리즈 (전 5편)

1. 1편 — 운영 서버에서 실제로 효과 본 방법
2. 2편 — Jackson 직렬화 튜닝: 숨은 CPU 병목 해결
3. 3편 — ThreadPool & Tomcat 튜닝: 트래픽 폭주 대응
4. 4편 — DB 성능 모니터링과 SQL 튜닝 사례
5. 5편 — 운영 장애 사례 10선 + 장애 복구 플레이북 (현재 글)