KOEN
Read Original
#Backend

OpenTelemetry와 vmagent를 이용한 고대역폭 메트릭 파이프라인 구축

OpenTelemetry와 vmagent를 이용한 고대역폭 메트릭 파이프라인 구축
01

Summary

초당 1억 건의 메트릭 정복! Airbnb가 OTLP와 vmagent로 완성한 차세대 파이프라인

StatsD에서 OpenTelemetry로의 대전환과 VictoriaMetrics를 활용한 비용 효율적 집계 전략

이 아티클은 Airbnb가 구형 StatsD 인프라를 OpenTelemetry 기반의 현대적인 Prometheus 생태계로 마이그레이션하며 겪은 기술적 해결책을 다룹니다. 성능 효율과 데이터 정확성이라는 두 마리 토끼를 잡기 위해 vmagent를 활용한 분산 집계와 독창적인 제로 인젝션 기법을 도입한 사례를 심도 있게 설명합니다.

  • 01StatsD 대비 OTLP 도입을 통한 메트릭 처리 CPU 사용량 90% 절감
  • 02vmagent의 2단계 샤딩 구조를 통한 초당 1억 TPS 규모의 무중단 집계 달성
  • 03Prometheus의 고질적인 카운터 과소 집계 문제를 해결한 'Zero Injection' 기법
  • 04고부하 환경 최적화를 위한 Delta vs Cumulative Temporality의 전략적 선택
  • 05VictoriaMetrics 오픈소스 기여를 통한 엔터프라이즈급 히스토그램 기능 확장

RECOMMENDATION

대규모 분산 환경에서 관측성(Observability) 비용과 데이터 정확도 사이에서 고민하는 SRE 및 백엔드 엔지니어들에게 필독을 권합니다. 특히 Prometheus 도입 후 카운터 값이 부정확하게 느껴진다면 이들의 제로 인젝션 기법이 실질적인 해답이 될 것입니다.

The Problem

Airbnb는 기존 StatsD/Veneur 기반 시스템의 높은 CPU 부하와 패킷 손실 문제를 해결하고, Prometheus 기반의 새로운 저장소로 이전하면서 대규모 트래픽과 데이터 정확성을 유지해야 하는 과제에 직면했습니다. 특히 드물게 발생하는 카운터 데이터가 누락되어 실제보다 적게 집계되는 현상이 주요 기술적 난제였습니다.

The Solution

OpenTelemetry(OTLP)로의 점진적 전환을 위해 듀얼 라이트 전략을 채택하고, VictoriaMetrics의 vmagent를 활용한 2계층(Router/Aggregator) 스트리밍 집계 아키텍처를 도입했습니다. 또한, 집계 계층에서 첫 샘플 대신 '0'을 먼저 주입하는 Zero Injection 기법을 통해 Prometheus의 rate() 계산 오류를 해결했습니다.

The Result

메트릭 처리용 CPU 점유율을 10%에서 1% 미만으로 대폭 절감했으며, 초당 1억 개 이상의 샘플을 처리하는 규모로 확장성을 확보했습니다. 이를 통해 인프라 운영 비용을 획기적으로 낮추고 고카디널리티 메트릭의 정확도를 높였습니다.

Trade-off

메모리 절감을 위해 일부 고부하 서비스에 델타 템포럴리티(Delta Temporality)를 적용함에 따라 장애 발생 시 데이터 손실(Gap)이 발생할 수 있는 위험을 감수했습니다. 또한, Zero Injection 도입으로 인해 첫 번째 카운트가 한 주기 지연되어 반영되는 현상이 나타납니다.

03

Key Concepts

Concept · 01

vmagent

VictoriaMetrics에서 제공하는 경량 메트릭 수집기로, 소량의 자원으로 스트리밍 집계와 샤딩을 지원합니다.

  • 본문에서 Router와 Aggregator 계층으로 나뉘어 대규모 메트릭을 실시간 집계하고 카디널리티를 축소하는 데 활용되었습니다.
Concept · 02

Zero Injection

Prometheus의 누적 카운터가 시작되는 시점에 의도적으로 '0' 값을 먼저 주입하여 rate() 함수가 누락 없이 변화를 감지하게 만드는 기법입니다.

  • Sparse Counters(드물게 발생하는 데이터)의 정확도를 높이기 위해 집계 계층에서 첫 플러시 시점에 강제로 0을 전송하도록 구현되었습니다.
Concept · 03

Delta Temporality

이전 리포트 이후의 증분(Delta) 데이터만 전송하는 방식으로, 전체 상태를 유지하지 않아 메모리 사용량이 적습니다.

  • 메모리 부하가 심한 고카디널리티 서비스의 안정성을 확보하기 위해 OTLP 설정에서 선택적으로 적용되었습니다.