Module 5: 장애 원인 분석 통합 프레임워크

1

Incident Timeline 구성법

타임라인 기반 분석은 장애 발생 시 가장 먼저 해야 할 작업입니다. 시간 축으로 이벤트를 정렬하면 배포, 설정 변경, 지표 변화, 알람 발생 사이의 인과관계가 명확히 드러납니다.

타임라인 구성 요소

시간 (UTC 기준)

모든 이벤트의 시간 기준 통일

이벤트 유형

알람, 배포, 설정 변경, 사용자 보고

지표 변화

메트릭 스파이크 / 드롭

조치

누가 무엇을 했는지

예시 타임라인

시간 (UTC)	이벤트	출처
10:15	배포 v2.3.1 시작	CD Pipeline
10:18	배포 완료, 롤아웃 100%	ArgoCD
10:22	RUM p99 응답시간 200ms → 1.2s	Datadog RUM
10:25	API 5xx 에러율 0.1% → 5.3%	Datadog APM
10:27	RDS CPUUtilization 40% → 92%	CloudWatch
10:28	PagerDuty 알람 발생	PagerDuty
10:30	온콜 엔지니어 확인	Slack
10:35	원인 파악: 새 쿼리 N+1 문제	Performance Insights
10:40	롤백 시작	ArgoCD
10:43	롤백 완료, 지표 정상화	All

타임라인의 핵심은 '이벤트 간 인과관계'를 드러내는 것입니다. 배포 → 지표 변화 → 알람의 순서가 보이면 원인을 빠르게 특정할 수 있습니다. 위 예시에서 배포(10:18) 직후 RUM p99가 급증(10:22)했고, 이어서 API 에러율과 RDS CPU가 상승한 것으로 보아 새 배포 버전에 문제가 있음을 즉시 알 수 있습니다.

2

지표 간 상관관계 분석

장애 분석에서 가장 중요한 것은 증상에서 원인으로의 추적입니다. 사용자가 경험하는 문제(프론트엔드)부터 시작해서 백엔드, 인프라 순서로 위에서 아래로 원인을 찾아가는 3-Layer 모델을 사용합니다.

3-Layer 상관 분석 모델

1

Layer 1: 프론트엔드 (Datadog RUM)

p99 응답시간, 에러율, CWV (Core Web Vitals)

2

Layer 2: 백엔드 (Datadog APM)

API 레이턴시, 에러율, 처리량 (Throughput)

3

Layer 3: 인프라 (CloudWatch + K8s)

RDS CPU, Pod Memory, Node 상태, IOPS

상관관계 패턴 테이블

프론트엔드 증상	백엔드 원인	인프라 원인
RUM p99 스파이크	API 레이턴시 증가	RDS CPU 급증 / Slow Query
JS Error 급증	API 5xx 증가	Pod CrashLoopBackOff / OOMKill
페이지 로드 실패	API 타임아웃	DB 커넥션 풀 고갈
CLS 증가	API 응답 불일치	RDS Replica Lag
LCP 증가	정적 리소스 지연	CDN/Storage 병목

Tip: 항상 '위에서 아래로' 추적하세요. 사용자가 경험한 증상(RUM) → 백엔드 원인(APM) → 인프라 근본 원인(CloudWatch/K8s) 순서로 진행합니다. 거꾸로 인프라부터 보면 정작 사용자에게 영향이 없는 false alarm에 시간을 낭비할 수 있습니다. 예를 들어 RDS CPU가 90%라도 사용자 경험에 영향이 없다면 P2 이하로 분류할 수 있습니다.

3

5가지 실전 장애 시나리오 워크스루

실제 프로덕션 환경에서 자주 발생하는 5가지 장애 시나리오를 통해 분석 프로세스를 익혀봅시다. 각 시나리오는 증상 → 타임라인 → 원인 분석 → 해결 → 예방 조치 구조로 정리되어 있습니다.

A

DB 커넥션 풀 고갈

증상

API 응답 타임아웃 급증, RUM 에러율 5%+, 사용자 "로그인이 안 돼요" 문의 급증

원인

슬로우 쿼리가 커넥션을 장시간 점유 → 새 요청이 커넥션을 얻지 못함 → 타임아웃

지표 경로

RUM 에러 → APM timeout → RDS DatabaseConnections = max_connections (100/100)

해결

1. 슬로우 쿼리 kill (Performance Insights에서 확인)
2. 인덱스 추가하여 쿼리 최적화
3. 커넥션 풀 타임아웃 설정 (30초 → 10초)

예방 조치

• 커넥션 풀 사용률 모니터링 알람 (> 80%)
• Slow query log 활성화 및 주기적 리뷰
• EXPLAIN으로 배포 전 쿼리 성능 검증

B

K8s Node Memory Pressure → Pod Eviction

증상

간헐적 502 에러, 특정 서비스 Pod가 주기적으로 재시작

원인

DaemonSet 업데이트로 노드 메모리 사용 증가 → MemoryPressure 발생 → BestEffort QoS Pod 퇴거

지표 경로

RUM 간헐적 에러 → APM 특정 Pod 실패 → Node MemoryPressure Event

해결

1. DaemonSet 리소스 limits 설정 (메모리 제한)
2. 퇴거된 Pod의 QoS를 Guaranteed로 변경 (requests = limits)
3. 노드 증설 또는 메모리 업그레이드

예방 조치

• Node Memory 알람 (> 85%)
• 모든 프로덕션 Pod에 requests/limits 명시 (Guaranteed QoS)
• DaemonSet 업데이트 전 메모리 영향 평가

C

RDS Replica Lag → 데이터 불일치

증상

"학습 완료했는데 진도가 안 올라가요" CS 접수, 사용자 데이터 불일치 신고

원인

대량 배치 작업으로 Primary 쓰기 부하 → Replica Lag 30초+ → 읽기 API가 오래된 데이터 반환

지표 경로

CS 접수 → 읽기 API 확인 → Replica 사용 확인 → ReplicaLag 30s

해결

1. Critical 읽기(쓰기 직후 읽기)는 Primary로 라우팅
2. 배치 작업 시간대 조정 (트래픽 낮은 새벽으로)
3. 배치 작업 쓰기 속도 throttling

예방 조치

• ReplicaLag 알람 (> 5s)
• 쓰기 후 읽기 패턴에 Primary 강제 지정 (read-after-write consistency)
• Replica 인스턴스 스펙 업그레이드

D

HPA 스케일 한계 → CPU Throttling → p99 급증

증상

점진적 p99 증가, 특정 시간대(10시, 피크)에 악화

원인

HPA maxReplicas(10) 도달 → 추가 스케일 불가 → 각 Pod CPU throttling 발생

지표 경로

RUM p99 증가 → APM 레이턴시 패턴 → K8s HPA (10/10) → CPU throttling

해결

1. HPA maxReplicas 상향 (10 → 20)
2. Node 추가 (Cluster Autoscaler)
3. CPU limits 상향 또는 제거 (throttling 방지)

예방 조치

• HPA 여유도 모니터링 (current/max ratio > 80% 알람)
• 피크 시간 대비 사전 스케일 (Scheduled HPA)
• CPU throttling 메트릭 모니터링

E

IOPS Burst Credit 소진 → 전체 서비스 저하

증상

점진적 전체 서비스 성능 저하, 특정 시점(14:00)부터 급격히 악화

원인

gp2 볼륨의 Burst Credit 소진 → 기본 IOPS(300)로 제한 → 모든 쿼리 지연

지표 경로

전체 서비스 지연 → RDS ReadLatency/WriteLatency 급증 → DiskQueueDepth 증가 → BurstBalance = 0

해결

1. gp3로 변경 (기본 3,000 IOPS, Burst Credit 불필요)
2. 또는 io2로 IOPS 프로비저닝 (안정적 성능 보장)
3. 대량 읽기/쓰기 작업 분산

예방 조치

• BurstBalance 모니터링 (< 20% 알람)
• 모든 프로덕션 RDS를 gp2 → gp3 마이그레이션
• IOPS 사용량 추세 분석 및 적정 볼륨 타입 선택

패턴 인식의 중요성

위 5가지 시나리오를 반복적으로 학습하면, 실제 장애 상황에서 증상만 보고도 "아, 이건 시나리오 C 패턴이네"라고 빠르게 인식할 수 있습니다. 패턴 인식 능력은 경험이 쌓일수록 강화되며, 평균 복구 시간(MTTR)을 크게 단축시킵니다.

4

Runbook 작성법

Runbook은 장애 대응 절차서입니다. 누구나 따라할 수 있도록 구조화된 문서로, 신규 엔지니어도 온콜 상황에서 즉시 대응할 수 있게 합니다.

Runbook 템플릿

# [서비스명] [장애유형] Runbook

## 트리거 조건
- 어떤 알람이 발생했을 때 이 Runbook을 실행하는지

## 심각도 판단
- P1 (전체 서비스 중단): 즉시 에스컬레이션
- P2 (부분 장애): 30분 내 해결 시도
- P3 (성능 저하): 업무 시간 내 해결

## 진단 단계
1. [첫 번째 확인 사항] - 명령어/URL 포함
2. [두 번째 확인 사항]
3. [분기 판단] - A이면 → Step 4a, B이면 → Step 4b

## 조치 단계
- [조치 1]: 롤백 / 스케일업 / 설정 변경
- [조치 2]: ...

## 확인 단계
- 지표가 정상으로 돌아왔는지 확인
- 사용자 영향이 해소되었는지 확인

## 에스컬레이션
- 15분 내 해결 안 되면 → 시니어 엔지니어
- 30분 내 해결 안 되면 → 팀 리드

실전 예시: API 응답 타임아웃 Runbook

# [밀당영어] API 응답 타임아웃 Runbook

## 트리거 조건
- Datadog APM p99 레이턴시 > 3초 for 5분
- PagerDuty 알람: "API Timeout Spike"

## 심각도 판단
- 에러율 > 5%: P1 (즉시 대응)
- 에러율 1-5%: P2 (30분 내 해결)
- 에러율 < 1%: P3 (모니터링)

## 진단 단계
1. Datadog APM에서 어느 엔드포인트가 느린지 확인
   https://app.datadoghq.com/apm/services/api-service
2. RDS Performance Insights에서 슬로우 쿼리 확인
   https://console.aws.amazon.com/rds/performance-insights
3. 커넥션 풀 사용률 확인
   CloudWatch → RDS → DatabaseConnections

## 조치 단계
- **시나리오 A: 슬로우 쿼리 발견**
  1. 쿼리 ID 복사 → RDS 콘솔에서 KILL
  2. 해당 쿼리 코드 위치 파악 (APM Trace)
  3. 임시 조치: 해당 엔드포인트 rate limiting
  4. 근본 해결: 인덱스 추가 (DBA 협의)

- **시나리오 B: 커넥션 풀 고갈**
  1. kubectl scale deployment api-service --replicas=20
  2. RDS 커넥션 풀 max_connections 증가 (100 → 200)
  3. 애플리케이션 재시작

## 확인 단계
- Datadog APM p99 < 500ms로 회복
- 에러율 < 0.1%
- #incident-channel에 "해결 완료" 메시지

## 에스컬레이션
- 15분 내 미해결 → @senior-engineer Slack 멘션
- 30분 내 미해결 → @team-lead 전화

좋은 Runbook의 핵심: 새로 입사한 엔지니어도 따라할 수 있을 정도로 구체적이어야 합니다. 명령어는 복사-붙여넣기 가능하게, URL은 직접 클릭 가능하게, 판단 기준은 수치로 명확하게 작성하세요. "적절히 판단하여" 같은 모호한 표현은 피해야 합니다.

5

Post-mortem 문화

Post-mortem은 장애 발생 후 근본 원인을 분석하고 재발 방지 대책을 수립하는 프로세스입니다. 핵심은 "누가 잘못했는가?"가 아니라 "왜 이것이 가능했는가?"를 묻는 것입니다.

Blameless Post-mortem

사람이 아닌 시스템/프로세스의 문제에 초점을 맞춥니다.

잘못된 질문

"누가 실수했는가?"

개인 비난, 책임 전가, 방어적 태도 유발

올바른 질문

"왜 이 실수가 가능했는가?"

시스템 개선, 프로세스 보완, 학습 문화

5 Whys 기법

"왜?"를 반복적으로 물어 근본 원인(Root Cause)을 찾는 분석 기법입니다.

1

왜 서비스가 다운됐나?

→ DB 커넥션 풀 고갈

2

왜 커넥션 풀이 고갈됐나?

→ 슬로우 쿼리가 커넥션을 장시간 점유

3

왜 슬로우 쿼리가 발생했나?

→ 인덱스 없이 대용량 테이블 풀 스캔

4

왜 인덱스가 없었나?

→ 코드 리뷰에서 쿼리 성능 검증 없음

5

왜 쿼리 성능 검증이 없었나?

→ CI/CD에 EXPLAIN 자동 검사 미포함

Action Item

CI/CD에 EXPLAIN 자동 검증 단계 추가 (담당: DevOps팀, 기한: 2주)

Post-mortem 문서 구조

항목	내용
제목	간결한 장애 설명 (예: "API 타임아웃으로 인한 서비스 장애")
날짜/시간	장애 발생~복구 시간 (UTC 기준)
영향 범위	영향받은 사용자 수, 서비스, 매출 손실 추정치
타임라인	시간순 이벤트 기록 (배포, 알람, 조치)
근본 원인	5 Whys 분석 결과 및 시스템적 취약점
해결 조치	즉각 해결한 방법 (롤백, 스케일업 등)
Action Items	재발 방지를 위한 구체적 태스크 (담당자, 기한 명시)
교훈	잘한 점, 개선할 점, 팀이 배운 것

Tip: Post-mortem은 비난이 아니라 학습을 위한 것입니다. 장애는 시스템을 개선하는 가장 좋은 기회입니다. "실수를 한 사람"이 아니라 "실수를 가능하게 한 시스템"을 고치면, 같은 장애가 반복되지 않습니다. 모든 Action Item은 담당자와 기한을 명시하고, 다음 회고에서 완료 여부를 반드시 확인하세요.

퀴즈

학습한 내용을 확인해봅시다. 5문제를 모두 풀어보세요.