Observability
Observability(관측 가능성)
처음엔 모니터링이랑 같은 말인 줄 알았는데 달랐다.
모니터링이랑 뭐가 다른가
모니터링: "CPU가 80%다" → 미리 정해둔 지표를 보는 것
Observability: "왜 저 요청만 느린 거지?" → 어떤 질문이든 데이터로 답할 수 있는 것
모니터링은 알고 있는 문제를 감지한다.
Observability는 모르는 문제도 찾아낼 수 있다.
세 기둥 (Three Pillars)
Observability는 세 가지로 구성된다.
| 기둥 | 형태 | 질문 | 도구 |
|---|---|---|---|
| Metrics | 시계열 숫자 | 얼마나? | Prometheus, Grafana |
| Logs | 이벤트 텍스트 | 무슨 일이? | ELK Stack, Loki |
| Traces | 요청 흐름 | 어디서? | Jaeger, Zipkin |
각각 어떤 상황에서 쓰는가
✅ Metrics
오류율, 응답시간, CPU 같은 수치를 추적할 때.
"이상하다"는 걸 가장 먼저 감지하는 역할이다.
✅ Logs
특정 오류가 왜 발생했는지 파악할 때.
"무슨 일이 있었는지" 상세하게 기록되어 있다.
✅ Traces
요청이 시스템을 통과하는 전체 경로와 구간별 시간을 보여준다.
사용자 요청 총 2,100ms
├─ API 서버 처리: 50ms
├─ DB 쿼리: 1,800ms ← 여기가 문제
└─ 외부 API 호출: 250ms
DB가 느린지, 외부 API가 느린지 딱 집어낼 수 있다.
장애 상황에서 세 개를 같이 쓰면
1단계 - Metrics로 감지: "오류율이 갑자기 5%로 올랐다"
2단계 - Logs로 원인 파악: "결제 서비스에서 timeout 에러 발생"
3단계 - Traces로 위치 특정: "외부 PG사 API 호출에서 3초씩 걸림"
세 개가 같이 있어야 장애를 빠르게 해결할 수 있다.
하나만 있으면 절반만 보이는 것과 같다.
Observability가 없으면
❌ 장애 발생
→ 어디가 문제인지 몰라서 코드 뒤짐
→ 로그 추가하고 재배포
→ 재현 시도
→ 틀리면 다시 반복
→ 수 시간 소요
Observability가 있으면 Metrics로 감지하고,
Logs로 원인 찾고, Traces로 위치 특정해서 수십 분 안에 해결된다.
MTTR(평균 복구 시간)이 극적으로 줄어든다.
정리
| 기둥 | 알 수 있는 것 | 알 수 없는 것 |
|---|---|---|
| Metrics만 있을 때 | 이상 징후 감지 | 왜, 어디서 문제인지 |
| Logs 추가 | 원인 파악 | 어느 구간인지 |
| Traces 추가 | 병목 위치까지 특정 | — |
👍