핵심 원칙
장애 진단은 추측이 아니라 정상 상태와 현재 상태의 차이를 좁혀 가는 과정이다
같은 느림 현상도 실행 계획 변경, 락 대기, 시간대 부하처럼 달라진 지점이 다르면 조치도 달라집니다.
먼저 고정할 기준
시작 시점
언제부터 느려졌는지 먼저 고정해야 전후 상태를 비교할 수 있습니다.
영향 범위
전체 서비스인지, 일부 SQL인지 구분해야 병목 위치를 잘못 잡지 않습니다.
재검증
조치 뒤 같은 지표를 다시 비교해야 원인과 효과가 확정됩니다.
1 기준선
정상일 때 값을 묶어 둔다
장애 시점의 숫자만 보면 과잉 대응하기 쉽습니다. 평소 상태를 같이 봐야 변화가 보입니다.
지표
평소 응답 시간, TPS, 대기 이벤트
대상
영향받은 서비스, 세션, SQL 범위
2 변화 비교
지금 무엇이 달라졌는지 본다
원인은 보통 한 지점에서 드러납니다. 현재 상태를 기준선과 나란히 놓고 차이가 나는 축을 찾습니다.
실행 계획
통계 정보 갱신 뒤 접근 경로가 바뀌었는가
대기 상태
락, I/O, CPU 대기가 특정 세션에 몰렸는가
시간대 부하
배치나 대량 작업이 같은 시간대에 겹쳤는가
3 원인 확정
원인별로 대응이 갈린다
느리다는 결과는 같아도 원인이 다르면 조치가 달라집니다. 증상이 아니라 바뀐 상태를 기준으로 대응합니다.
계획 변경
실행 계획 확인, 힌트 적용, 통계 재수집
시간대 병목
배치 스케줄, 락 경합, I/O 피크 분리
자주 보이는 변화 신호
증상 → 달라진 상태 → 첫 확인 순서로 보면 진단이 빨라집니다.
| 증상 | 달라진 상태 | 첫 확인 |
|---|---|---|
| 갑작스러운 Slow Query 증가 | 통계 정보 갱신 뒤 실행 계획이 바뀜 | 실행 계획 확인 후 필요하면 통계 재수집 |
| 특정 시간대만 성능 저하 | 배치 작업, 락 경합, I/O 집중이 같은 시간대에 겹침 | 해당 시간대의 대기 이벤트와 작업 스케줄 확인 |