안녕하세요! 오늘은 모니터링 시스템, 특히 프로메테우스(Prometheus)와 같은 시스템에서 자주 사용되는 두 가지 중요한 메트릭 타입, 히스토그램(Histogram)과 서머리(Summary)의 결정적인 차이점에 대해 알아보려고 합니다.
둘 다 요청 지연 시간(request latency)이나 응답 크기(response size)와 같은 값의 분포를 측정하는 데 사용되지만, 동작 방식에는 아주 중요한 차이가 있습니다. 바로 어디서 계산이 이루어지느냐 하는 점이죠! 🤔
🚀 핵심 차이점: 계산의 주체
결론부터 말씀드리자면, 둘의 가장 큰 차이점은 다음과 같습니다.
- 히스토그램 (Histogram): 데이터 수집 및 계산이 서버 측(Server-side)에서 이루어집니다. 🖥️
- 서머리 (Summary): 데이터 계산이 클라이언트 측(Client-side)에서 이루어집니다. 💻
이 간단한 차이가 왜 그렇게 중요할까요? 지금부터 자세히 파헤쳐 보겠습니다.
🖥️ 히스토그램 (Histogram): 서버의 힘을 빌리자!
히스토그램은 클라이언트(여러분의 애플리케이션)가 관찰한 값을 그대로 서버(예: 프로메테우스 서버)로 전송하는 방식입니다.
어떻게 동작하나요?
- 클라이언트 (애플리케이션) 💻: 요청이 들어올 때마다 응답 시간(예: 150ms)을 측정합니다.
- 측정값 전송: 이 150ms라는 값을 서버로 그냥 보냅니다. 클라이언트는 복잡한 계산을 하지 않아요!
- 서버 (프로메테우스) 🖥️: 서버는 미리 정의된 '버킷(bucket)'을 가지고 있습니다. 예를 들어, (0-100ms, 100-200ms, 200-300ms, ...) 와 같은 구간들이죠.
- 서버에서 계산: 서버는 클라이언트로부터 받은 150ms 값을 보고 '100-200ms' 버킷의 카운트를 1 증가시킵니다.
- 분위수 계산: 수집된 모든 버킷의 데이터를 기반으로 서버가 직접 백분위수(Quantile, 예: 99%, 95%)를 추정하여 계산합니다.
장점 👍
- 낮은 클라이언트 부하: 클라이언트는 단순히 측정값만 보내면 되므로, CPU나 메모리 부담이 거의 없습니다. 가볍고 빨라요! 🕊️
- 유연한 집계(Aggregation): 여러 클라이언트(인스턴스)에서 수집된 데이터를 서버에서 합산하여 전체 서비스의 분위수를 계산할 수 있습니다. A서버의 99% + B서버의 99%가 아닌, (A+B)서버 전체의 99%를 알 수 있죠. 이것이 히스토그램의 가장 강력한 장점입니다! 💯
- 자유로운 쿼리: 수집된 데이터를 바탕으로 서버에서 다양한 조건으로 쿼리하고 분석하기 용이합니다.
단점 👎
- 정확도 한계: 미리 정의된 버킷을 사용하기 때문에, 백분위수 계산이 정확한 값이 아닌 근사치입니다. 버킷의 범위가 넓을수록 오차는 커질 수 있습니다.
💻 서머리 (Summary): 클라이언트가 직접 해결한다!
서머리는 클라이언트(애플리케이션)가 직접 분위수를 계산한 후, 그 결과값을 서버로 전송하는 방식입니다.
어떻게 동작하나요?
- 클라이언트 (애플리케이션) 💻: 일정 시간 동안 들어온 모든 요청의 응답 시간 값들을 자체적으로 저장하고 있습니다. (예: [120ms, 150ms, 90ms, 210ms, ...])
- 자체 계산: 클라이언트는 이 데이터들을 바탕으로 직접 분위수(예: 99%는 210ms, 50%는 135ms)를 정확하게 계산합니다.
- 결과 전송: 계산이 완료된 결과값(quantile="0.99", value="210")을 서버로 전송합니다.
장점 👍
- 높은 정확도: 클라이언트가 직접 모든 측정값을 가지고 계산하므로, 백분위수 값이 매우 정확합니다. ✅
- 직관적인 결과: 내가 원하는 분위수(p50, p90, p99 등)를 명확하게 설정하고 확인할 수 있습니다.
단점 👎
- 높은 클라이언트 부하: 모든 측정값을 일정 시간 동안 메모리에 보관하고, 분위수를 계산해야 하므로 CPU와 메모리 사용량이 높습니다. 😥
- 집계(Aggregation) 불가능: 각 클라이언트가 이미 계산을 끝낸 결과를 서버로 보내기 때문에, 여러 클라이언트의 데이터를 합쳐 전체 서비스의 분위수를 계산할 수 없습니다. (A서버의 99%와 B서버의 99%를 평균 내는 것은 통계적으로 의미가 없습니다.) ❌
🎯 한눈에 보는 비교표
구분히스토그램 (Histogram)서머리 (Summary)
| 계산 위치 | 서버 측 🖥️ | 클라이언트 측 💻 |
| 클라이언트 부하 | 낮음 (Low) 🕊️ | 높음 (High) 🐘 |
| 데이터 집계 | 가능 (Possible) ✅ | 불가능 (Impossible) ❌ |
| 분위수 정확도 | 근사치 (Approximate) | 정확함 (Accurate) |
| 주요 사용처 | 전반적인 서비스 지표 (ex: API 응답 시간) | 개별 인스턴스의 정확한 성능 측정 |
✨ 그래서 뭘 써야 할까요?
- 대부분의 경우, 히스토그램을 추천합니다. 🚀 마이크로서비스 아키텍처처럼 여러 인스턴스가 실행되는 환경에서는 전체 서비스의 성능을 파악하는 것이 중요합니다. 히스토그램은 데이터를 유연하게 집계할 수 있어 SLO/SLA를 측정하고 전반적인 서비스 상태를 모니터링하는 데 훨씬 유용합니다.
- 서머리는 특별한 경우에 사용하세요. 🎯 정확한 분위수 계산이 반드시 필요하고, 여러 인스턴스 간의 데이터 집계가 중요하지 않은 경우에 적합합니다. 예를 들어, 단일 배치(batch) 작업의 실행 시간 분포를 정확하게 알고 싶을 때 유용할 수 있습니다.
이제 히스토그램과 서머리의 차이점이 명확하게 이해되셨나요? 모니터링 시스템을 구축할 때 여러분의 상황에 맞는 올바른 메트릭 타입을 선택하여 더 효과적인 관찰 가능성(Observability)을 확보하시길 바랍니다!
'클라우드 > prometheus' 카테고리의 다른 글
| 프로메테우스(Prometheus) on() vs ignoring(): 벡터 매칭의 두 얼굴 🎭 (0) | 2025.10.12 |
|---|---|
| 🚀 골든 쿠버스트로넛을 향한 여정 (6/15): PCA 합격, 모니터링의 신세계를 맛보다! (feat. PromQL과의 사투) (0) | 2025.10.12 |
| 프로메테우스 성능 저하의 주범? 라벨(Label) 똑똑하게 사용하는 방법 🧐 (0) | 2025.10.11 |
| Prometheus 모범 사례: 올바른 메트릭과 레이블 설계하기 🚀 (0) | 2025.10.11 |
| 🧐 프로메테우스, '이렇게' 써야 전문가! 애플리케이션 모니터링 베스트 프랙티스 (0) | 2025.10.11 |
