우아한테크코스 테코톡
몽이의 Metric
https://youtu.be/mAbG2bY2yiA?si=VF-TIimWAFTPL9rA
몽이의 Metric
- 몽이의 Metric
- 모니터링 대시보드는 왜 필요할까? — 메트릭(Metric)과 관찰 가능성(Observability)의 본질
- 메트릭의 3가지 타입
- Percentile(P50/P95/P99)의 중요성
- 왜 P99가 중요한가
- 실제 운영에서의 P99 활용
- Four Golden Signals
- Traffic이 중요한 이유
- API 흐름 비교도 가능하다
- 진짜 중요한 건 “교차 검증”
- 모니터링 대시보드의 진짜 역할
- 핵심 정리
- 마무리
모니터링 대시보드는 왜 필요할까? — 메트릭(Metric)과 관찰 가능성(Observability)의 본질
백엔드 개발을 하다 보면:
- Prometheus
- Grafana
- CloudWatch
- Datadog
같은 모니터링 도구를 반드시 만나게 된다.
그런데 처음 대시보드를 보면 대부분 이런 생각이 든다.
"차트가 너무 많은데 뭘 봐야 하지?"
혹은:
"CPU 사용률만 알람 오면 되는 거 아닌가?"
하지만 실제 운영 환경에서 모니터링은 단순히:
- CPU 보기
- 메모리 보기
- 서버 살아있는지 확인
수준이 아니다.
진짜 핵심은:
사용자 경험(User Experience)과
비즈니스 상태를 수치로 관찰하는 것
이다.
이번 글에서는 발표 내용을 기반으로:
- 왜 모니터링이 필요한지
- 메트릭(Metric)이 무엇인지
- 어떤 메트릭을 봐야 하는지
- P99와 트래픽이 왜 중요한지
를 정리해본다.
왜 모니터링이 필요할까
우리는 실제 운영 중인 서버를 직접 볼 수 없다.
즉:
서버 내부 상태는 눈에 보이지 않는다
그래서 필요한 것이 모니터링이다.
모니터링 도구는:
- 시스템 상태
- 성능 변화
- 병목 현상
- 장애 징후
를 지속적으로 관찰하게 해준다.
모니터링의 진짜 가치
모니터링의 핵심 가치는 크게 세 가지다.
1. 장애 원인 파악
문제가 발생했을 때:
왜 장애가 발생했는가
를 추적할 수 있다.
2. 문제 예방
CPU가 갑자기 치솟거나:
- 에러율 증가
- 응답 지연 증가
- 트래픽 급증
같은 징후를 미리 감지할 수 있다.
3. 미래 계획 수립
현재 시스템 상태를 기반으로:
- 오토 스케일링 필요 여부
- 캐싱 필요 여부
- DB 증설 필요 여부
같은 미래 계획을 세울 수 있다.
관찰 가능성(Observability)이란 무엇인가
모니터링에서 가장 중요한 개념은:
Observability
즉 관찰 가능성이다.
의미는:
외부 출력만으로
시스템 내부 상태를 이해할 수 있는 능력
이다.
Observability의 3요소
관찰 가능성을 구성하는 핵심 요소는:
| 요소 | 역할 |
|---|---|
| Logs | 원인 분석 |
| Metrics | 상태 추적 및 예방 |
| Traces | 요청 흐름 추적 |
이다.
메트릭(Metric)이란 무엇인가
메트릭은:
시간 흐름에 따라 측정되는 수치 데이터
다.
예를 들면:
- CPU 사용률
- 메모리 사용량
- API 요청 수
- 응답 시간
- 에러율
같은 값들이다.
왜 메트릭이 중요한가
많은 사람들이:
"CPU 알람만 받으면 되는 거 아닌가?"
라고 생각한다.
하지만 메트릭의 진짜 목적은:
사용자 경험을 측정하는 것
이다.
SLI와 SLO
메트릭은 단순 시스템 상태가 아니라:
- 사용자 경험
- 서비스 품질
을 측정하는 데 사용된다.
여기서 등장하는 개념이:
| 개념 | 의미 |
|---|---|
| SLI | 실제 서비스 수준 지표 |
| SLO | 목표 서비스 수준 |
이다.
예를 들어:
95% 사용자는
1초 안에 응답받아야 한다
같은 목표를 세울 수 있다.
메트릭의 3가지 타입
발표에서는 메트릭을:
- Gauge
- Counter
- Histogram
세 가지로 설명한다.
Gauge
Gauge는:
현재 순간의 상태
를 나타낸다.
예:
- CPU 사용률
- 메모리 사용량
- 현재 에러율
등이다.
Gauge 활용 예시
예를 들어:
에러율이 3%를 넘으면
사용자 경험이 나빠진다
라는 기준을 세울 수 있다.
즉 Gauge는:
현재 상태를 감시
하는 용도다.
Counter
Counter는:
계속 증가하는 값
이다.
예:
- API 호출 횟수
- 회원가입 수
- SMS 발송 수
등이다.
Counter가 중요한 이유
Counter는 시간이 지나도 감소하지 않는다.
그래서:
변화량 추적
에 매우 좋다.
예를 들어:
회원가입 수는 그대로인데
SMS 발송량만 급증
한다면:
- 중복 요청
- 잘못된 재시도
- 버그
가능성을 의심할 수 있다.
Histogram
Histogram은:
데이터 분포
를 나타낸다.
특히:
- 응답 시간
- 트랜잭션 시간
분석에 매우 중요하다.
왜 평균만 보면 위험할까
예를 들어:
- 대부분 사용자 → 1초
- 일부 사용자 → 20초
라면 평균값은 왜곡된다.
이걸:
Long Tail 문제
라고 한다.
Percentile(P50/P95/P99)의 중요성
그래서 등장하는 개념이:
Percentile
이다.
P50
전체 사용자 중 50% 기준.
즉 일반적인 사용자 경험이다.
P95
95% 사용자 기준.
상당수 사용자 경험을 반영한다.
P99
99% 사용자 기준.
거의 최악 상황 직전의 사용자 경험을 의미한다.
왜 P99가 중요한가
예를 들어:
P50 = 0.5초
P99 = 10초
라면:
일부 사용자는 심각하게 느린 경험
을 하고 있다는 뜻이다.
즉:
평균은 멀쩡하지만
실제 사용자 경험은 망가질 수 있음
을 의미한다.
실제 운영에서의 P99 활용
발표에서는 AI API 예시를 든다.
예:
P50 = 0.5초
P99 = 8초
라면:
- 일반 사용자는 괜찮음
- 일부 사용자는 심각한 지연
을 겪는다.
이 경우 고민할 수 있는 것:
- 비동기 처리
- 캐싱
- 요청 큐
- 타임아웃 최적화
등이다.
Four Golden Signals
Google SRE에서는 중요한 네 가지 신호를 제시한다.
Four Golden Signals
이다.
1. Latency
응답 지연 시간
2. Traffic
트래픽 양
3. Errors
에러율
4. Saturation
시스템 포화 상태
발표에서는 특히:
- Latency
- Traffic
을 중점적으로 다룬다.
Traffic이 중요한 이유
트래픽은:
얼마나 많은 요청이 들어오는가
를 의미한다.
Traffic 기반 분석
예를 들어:
결제 승인 API 트래픽 급증
상황이라면:
- 캐싱 필요?
- 비동기 처리 필요?
- DB 병목?
- Redis 도입 필요?
같은 고민이 가능하다.
API 흐름 비교도 가능하다
예를 들어:
결제 승인 요청은 많음
근데 결제 완료 요청은 적음
이라면:
중간 플로우 어딘가에서 실패 발생
을 추론할 수 있다.
진짜 중요한 건 “교차 검증”
모니터링은 단순히:
CPU 90%
보는 게 아니다.
진짜 중요한 건:
여러 메트릭을 연결해서 해석
하는 것이다.
예:
에러율 증가
→ 트래픽 증가
→ P99 증가
→ 특정 API 병목
이렇게 원인을 추론한다.
모니터링 대시보드의 진짜 역할
대시보드는 단순 차트 모음이 아니다.
진짜 역할은:
비즈니스 문제를 발견하는 것
이다.
즉:
- 사용자 경험 저하
- 병목 현상
- 비즈니스 장애
- 성능 저하
를 빠르게 발견하기 위한 도구다.
핵심 정리
모니터링의 본질은:
서버 상태 보기
가 아니다.
진짜 핵심은:
사용자 경험과
비즈니스 상태를
수치로 관찰하는 것
이다.
마무리
좋은 모니터링은 단순히:
- CPU 그래프
- 메모리 그래프
를 보는 것이 아니다.
진짜 좋은 모니터링은:
"왜 사용자가 느려졌는가"
를 설명할 수 있어야 한다.
그리고 그 중심에는:
Metric
이 존재한다.
