1.1 Workload와 latency budget
성능 문제를 “CPU가 높다”로 시작하면 정상적인 사용량도 장애처럼 보입니다. 먼저 사용자가 기다리는 작업을 정의합니다. API 요청, batch, checkpoint, backup처럼 작업마다 처리량과 허용 latency가 다릅니다.
네 가지 질문
- 단위 시간에 몇 건이 들어오는가?
- 한 건이 완료되기까지 얼마나 걸리는가?
- 동시에 처리 중인 작업은 몇 개인가?
- 실패와 retry가 실제 부하를 얼마나 증폭하는가?
Little's Law를 이용해 안정 상태에서 concurrency를 대략 계산합니다.
동시 작업 수 ≈ 초당 처리량 × 평균 응답 시간
500 TPS에서 평균 응답 시간이 20ms라면 평균 동시 작업은 약 10개입니다. 응답 시간이 200ms로 늘면 유입량이 같아도 100개가 쌓입니다. connection 수 증가는 원인이 아니라 latency 증가의 결과일 수 있습니다.
시간 budget 분해
애플리케이션 응답 시간을 다음처럼 나눠 기록합니다.
Database execution이 짧아도 pool 대기가 길 수 있고, PostgreSQL 내부 시간은 짧아도 packet loss로 client가 늦게 받을 수 있습니다. 하나의 평균값보다 p50, p95, p99와 timeout 비율을 함께 봅니다.
실전 기록
장애 분석을 시작할 때 다음 표를 채웁니다.
| 항목 | 정상 | 문제 시간 |
|---|---|---|
| 요청률 | ||
| p95 latency | ||
| error와 timeout 비율 | ||
| DB active session | ||
CPU PSI some | ||
storage await |
이 표가 이후 명령의 방향을 정합니다. 자원 사용률 하나만으로 병목을 확정하지 않습니다.