대규모 metrics pipeline을 StatsD에서 OpenTelemetry / Prometheus로 옮기기

Airbnb는 기존 StatsD + Veneur + 벤더 저장소 구조에서 벗어나, OpenTelemetry Protocol(OTLP) 과 Prometheus 기반 저장소 로 옮기는 전환을 진행했다.

먼저 내부 서비스에는 OTLP 를 권장하고, OSS 워크로드에는 Prometheus 를 우선하며, 레거시 경로만 StatsD(DogStatsD) 로 남겼다. 이 과정에서 OpenTelemetry Collector 를 중간 허브로 사용했고, 약 40% 의 서비스가 공유 metrics 라이브러리를 통해 StatsD와 OTLP를 동시에 전송(dual-write) 하도록 바꿨다.

전환 효과도 분명했다.

• JVM 프로파일 기준 metrics 처리 CPU 비중이 10% 미만에서 1% 미만 으로 감소
• UDP 기반 StatsD보다 패킷 손실에 강한 OTLP 로 안정성 개선
• 중간의 StatsD-to-OTLP 변환 단계 를 제거
• Prometheus 환경에서 exponential histograms 같은 기능을 더 온전히 활용

다만 초고트래픽 서비스에서는 OTLP를 켠 뒤 메모리 압박, GC 증가, heap 성장 이 발생했다. 원인은 초고카디널리티 메트릭과 높은 발행량이었고, 일부 서비스에는 delta temporality 를 적용해 인프로세스 상태 부담을 줄였다. 이 설정은 모든 서비스에 필요한 것은 아니었고, 극단적으로 많은 샘플을 내는 서비스에만 제한적으로 사용했다.

집계 단계에서는 기존 Veneur 방식 대신 vmagent 를 선택했다. 이유는 다음과 같다.

• streaming aggregation 지원
• sharding 으로 수평 확장 가능
• 문서가 간단하고 이해하기 쉬움
• 코드베이스가 작아 수정과 운영이 용이함

구조는 router / aggregator 의 2단계로 구성됐다. router는 라벨 일부를 제외하고 consistent hashing으로 샤딩하고, aggregator는 counter를 합산하며 상태를 유지한다. Kubernetes StatefulSet의 안정적인 네트워크 ID를 활용해 router가 고정된 aggregator 목록을 바라보는 단순한 방식으로, 추가 서비스 디스커버리 의존성을 피했다. 이 파이프라인은 내부 커스터마이징을 거쳐 native histogram 지원 과 Mimir-style multitenancy 도 넣었고, 일부 변경은 upstream에 기여했다.

결과적으로 단일 프로덕션 클러스터가 수백 개 aggregator 로 확장됐고, 초당 1억 샘플 이상 을 처리했다. 비용은 10배 수준으로 절감 됐고, 중앙집중형 집계층이 생기면서 문제가 있는 instrumentation을 차단하거나, 필요 시 raw metrics를 임시로 다시 내보내는 같은 운영상의 유연성도 얻었다.

마지막으로, Prometheus 전환 뒤에는 sparse counter undercount 문제가 드러났다. 생성 직후 한 번만 증가하고 재시작되는 카운터는 rate() 계산 전에 증가분이 사라질 수 있었고, 특히 저빈도이지만 고차원적인 비즈니스 메트릭에서 문제가 컸다. 해결책으로는 호출부를 일일이 고치는 대신 집계층에서 zero injection 을 적용했다. 즉, 어떤 counter를 처음 flush할 때는 실제 값 대신 0을 먼저 내보내고, 다음 flush부터 정상 값을 내보내도록 해 Prometheus counter semantics와 맞췄다. 이 방식은 사용자에게 보이지 않으면서도 저카운트 문제를 원천에서 해결했다.

요약하면, 이 글은 Airbnb가 StatsD 중심의 대규모 metrics 시스템을 OTLP + Prometheus + vmagent 기반으로 전환 하면서, 성능·비용·정확성 문제를 각각 어떻게 풀었는지 보여주는 실전 사례다.