Tempo 컴포넌트 리소스 할당
Grafana Tempo를 “한 덩어리”로 보면 병목이 숨는다. 컴포넌트별 워크로드 특성을 기준으로 리소스 할당 전략을 정리한다.
핵심 개념
Grafana Tempo는 분산 추적 백엔드로, 여러 마이크로서비스로 구성된다. 리소스 튜닝의 핵심은 쓰기 경로와 조회 경로를 분리하여 각 경로의 병목 컴포넌트에 자원을 집중하는 것이다.
- 쓰기 경로: Distributor → Ingester(버퍼링/flush) → Object Storage
- 조회 경로: Query Frontend → Querier → (Object Storage + Ingester)
비교·분석
컴포넌트별 특성 및 리소스 전략
| 컴포넌트 | 역할 | CPU 특성 | 메모리 특성 | 스케일링 |
|---|---|---|---|---|
| Distributor | 스팬 수신 → Ingester 라우팅 | moderate (해싱/파싱) | 낮음 (버퍼 외) | HPA CPU 기반 수평 확장 |
| Ingester | 배칭 → 인덱싱 → 스토리지 flush | flush 시 스파이크 | 높음 (블록 메모리 적재) | HPA CPU 기반, 종료 시 flush 보장 |
| Querier | 블록 읽기 → 쿼리 실행 | 높음 (디시리얼라이즈/필터) | 대량 조회 시 피크 | 커스텀 지표(큐 길이) 기반 HPA |
| Query Frontend | 쿼리 분배 → 결과 머지 | 낮음 | 낮음 | 낮은 리소스로 충분 |
| Compactor | 블록 압축/중복 제거/만료 삭제 | 압축 시 일시 피크 | 처리 블록 크기 비례 | 단일 인스턴스 운영 |
| Metrics Generator | 스팬 → 메트릭 추출 | 중간 | 중간 (수백 MB~2GB) | Ingester 수에 맞춰 조정 |
핵심 병목 컴포넌트: Ingester
- 메모리:
max_block_bytes: 64MiB설정이라도 동시 다중 트레이스로 실제 사용량은 더 큼. OOM 방지를 위해 충분한 request 필요 (예: 14Gi request, 16Gi limit). - CPU: flush 시 Parquet 압축·블룸 필터 생성으로 burst 발생. request는 기본 처리량에 맞추고 limit는 무제한 고려.
- 종료: scale-in 시 미 flush 데이터 보호를 위해
terminationGracePeriodSeconds: 300이상 설정.
핵심 병목 컴포넌트: Querier
- CPU: Parquet 블록 디시리얼라이즈 + 필터 조건 검사로 연산량이 크다. CPU limit 없이 운영하여 동시 쿼리를 빠르게 처리.
- 메모리: 평상시 유휴이나 대량 조회 시 피크. request와 limit에 여유를 둔다.
- 스케일링: Grafana 권고에 따라 Prometheus나 Queue 길이 등 커스텀 지표로 HPA 트리거.
실무 적용
- 자원 집중 대상: Ingester와 Querier에 충분한 자원과 적절한 autoscaling 정책을 우선 적용한다.
- QoS 트레이드오프: CPU limit 제거 시 QoS가 Burstable이 되므로, 성능과 안정성 사이에서 선택이 필요하다.
- 모든 컴포넌트를 동일 정책으로 묶는 것은 피한다: 운영은 단순해지지만 병목이 숨어 비용과 지연이 커질 수 있다.