Observability가 필요한 이유
한 줄 정의
Observability는 시스템 외부에서 관찰 가능한 신호를 통해 내부 상태와 장애 원인을 추론할 수 있게 만드는 능력이다.
실무에서 왜 문제 되는가
- 장애가 발생한 뒤 로그가 부족하면 원인을 추측하게 된다.
- API가 느린지, DB가 느린지, 외부 API가 느린지 구분하지 못하면 복구가 늦어진다.
- 사용자 영향이 있는데도 알림이 없으면 장애를 고객 문의로 알게 된다.
- 지표가 많아도 의사결정에 연결되지 않으면 운영에 도움이 되지 않는다.
- 장애 분석이 개인 경험에 의존하면 같은 문제가 반복된다.
동작 원리
- 서비스가 요청을 처리하면서 로그, 메트릭, 트레이스를 남긴다.
- 메트릭으로 이상 징후와 영향 범위를 빠르게 확인한다.
- 트레이스로 요청이 어느 구간에서 느려졌는지 확인한다.
- 로그로 구체적인 입력, 상태, 예외, 의사결정 근거를 확인한다.
- 원인을 좁힌 뒤 조치하고, 재발 방지를 위해 계측과 알림을 보완한다.
실무 판단 기준
| 질문 | 먼저 볼 신호 | 이유 |
|---|---|---|
| 장애인가 | SLI, error rate, latency | 사용자 영향을 판단한다 |
| 어디가 느린가 | trace, dependency latency | 지연 구간을 나눈다 |
| 왜 실패했나 | error log, exception, event log | 실패 조건을 확인한다 |
| 얼마나 퍼졌나 | endpoint, region, instance metric | 영향 범위를 좁힌다 |
| 재발할 수 있나 | saturation, queue, retry metric | 구조적 원인을 확인한다 |
자주 나는 실수
- 로그만 많이 남기고 메트릭과 트레이스를 준비하지 않는다.
- 평균 latency만 보고 장애 영향을 과소평가한다.
- 모든 이벤트를 알림으로 만들어 알림 피로를 만든다.
- request id 없이 로그를 남겨 한 요청의 흐름을 추적하지 못한다.
- 장애 후 계측 보완 없이 코드 수정만 하고 끝낸다.
확인 방법
- 테스트: 장애 상황을 가정해 어떤 지표와 로그로 원인을 찾을 수 있는지 점검한다.
- 로그: request id, endpoint, user 영향 없는 식별자, 예외 원인을 확인한다.
- 메트릭: latency, traffic, error, saturation을 확인한다.
- 트레이스: DB, Redis, 외부 API, queue 구간 시간이 분리되는지 확인한다.
장점과 한계
| 장점 | 한계 |
|---|---|
| 장애 원인을 빠르게 좁힌다 | 계측 설계와 운영 비용이 든다 |
| 성능 개선 근거를 제공한다 | 잘못된 지표는 잘못된 판단을 만든다 |
| 장애 회고와 재발 방지에 도움이 된다 | 모든 문제를 자동으로 설명하지는 않는다 |
짧은 예제
증상:
- 주문 생성 API p95 2초 초과
확인:
- 메트릭: error rate 정상, latency 증가
- 트레이스: 외부 결제 API 구간에서 1.7초 사용
- 로그: retry 2회 발생
판단:
- 애플리케이션 로직보다 외부 의존성 지연과 retry 정책을 먼저 확인한다.핵심 요약
Observability는 장애 원인을 추측하지 않고 증거로 좁히기 위한 준비다.
메트릭은 장애 여부와 영향 범위를 빠르게 보여준다.
트레이스는 요청이 어느 구간에서 시간을 쓰는지 보여준다.
로그는 실패 조건과 의사결정 근거를 확인하게 해준다.
좋은 운영은 장애 후 계측과 알림을 함께 개선한다.
꼬리 질문
- Monitoring과 Observability의 차이는 무엇인가?
- 로그, 메트릭, 트레이스는 각각 어떤 질문에 답하는가?
- 장애 후 계측을 보완해야 하는 이유는 무엇인가?