최근 Airbnb가 자사 관측성 플랫폼 개편 사례를 공개했습니다. 핵심은 간단합니다. 기존 StatsD 중심 구조를 버리고, OpenTelemetry와 Prometheus 계열 스택으로 갈아타며 초당 1억 개 이상의 샘플을 처리하는 파이프라인을 만들었다는 점입니다.1 이 이야기가 중요한 이유는, "오픈소스로 정말 대규모 메트릭 처리가 가능할까?"라는 질문에 꽤 강력한 답을 줬기 때문입니다.
Airbnb Prometheus 파이프라인이 주목받는 이유
Prometheus는 원래 다차원 라벨 기반 메트릭과 강력한 PromQL로 사랑받아 왔지만, 기본 단일 서버만으로는 초대형 환경에서 한계가 분명합니다.2 그래서 보통은 장기 저장소나 분산형 백엔드를 함께 붙입니다. Airbnb도 이 지점에서 Grafana Mimir 같은 확장형 저장소를 택했습니다. Mimir는 대규모 시계열 저장을 위해 설계됐고, 내부 테스트 기준 10억 개 활성 시계열까지 다룰 수 있다고 소개합니다.3
즉, 이번 사례의 진짜 포인트는 "Prometheus를 썼다"가 아닙니다. "Prometheus 생태계를 조합해 기업 규모에 맞는 형태로 재설계했다"에 더 가깝습니다. 작은 팀이 그대로 복제할 일은 없지만, 방향성은 많은 조직에 참고가 됩니다.
OpenTelemetry 전환이 가져온 성능과 운영 변화
Airbnb는 구형 StatsD와 자체 집계 계층을 유지하는 대신, OTLP와 OpenTelemetry Collector로 수집 경로를 현대화했습니다.1 특히 공용 메트릭 라이브러리를 업데이트해 기존 경로와 새 경로로 동시에 보내는 방식, 즉 듀얼 라이트를 활용한 점이 인상적입니다. 대규모 마이그레이션에서 "한 번에 갈아엎기"보다 훨씬 현실적인 전략이기 때문입니다.
성능 개선도 눈에 띕니다. JVM 서비스에서 메트릭 처리 CPU 비중이 10% 수준에서 1% 미만으로 줄었다고 합니다.1 UDP 기반 StatsD의 패킷 유실 위험도 줄였고, Prometheus 친화적인 히스토그램 처리도 더 자연스러워졌습니다.
다만 장점만 있었던 건 아닙니다. 고카디널리티 서비스에서는 메모리 압박과 GC 부담이 생겼고, 이를 delta temporality로 완화했습니다.1 여기서 얻을 교훈은 명확합니다. 관측성도 "많이 넣으면 무조건 좋다"가 아니라, 데이터 모델과 전송 방식이 비용 구조를 바꾼다는 것입니다.
고카디널리티 메트릭과 집계 설계가 승부처였다
Prometheus의 강점은 라벨입니다. 동시에 가장 무서운 지점도 라벨입니다. pod, hostname, region, currency 같은 값이 늘어나면 시계열 수가 폭발합니다.2 Airbnb는 예전 파이프라인에서 인스턴스 수준 라벨을 미리 뭉개 비용을 통제했고, 새 구조에서도 같은 문제가 다시 나타났습니다.1
이때 선택한 도구가 VictoriaMetrics의 vmagent였습니다. 이유는 스트리밍 집계, 수평 샤딩, 비교적 단순한 구조였습니다.1 라우터 계층이 특정 라벨을 제외하고 해시 기반으로 분산하고, 집계 계층이 메모리에서 누적값을 관리하는 2단 구조를 만든 것입니다. 쉽게 말해 "저장소에 넣기 전에 비싼 라벨을 정리하는 전처리 공장"을 세운 셈입니다.
이 접근은 다른 대형 사례와도 통합니다. Flipkart는 연합형 Prometheus 구조로 요약 메트릭을 위쪽으로 끌어올렸고, Shopify도 비용 문제를 해결하기 위해 오픈소스 관측성 스택으로 재편했습니다.4 방법은 달라도 메시지는 같습니다. 초대형 환경에서는 수집보다 "어디서 얼마나 집계할 것인가"가 더 중요합니다.
Prometheus 카운터 정확도 문제를 어떻게 풀었나
가장 흥미로운 대목은 정확도 이슈입니다. Prometheus의 counter는 누적값이고, 보통 rate()로 증가량을 계산합니다. 그런데 아주 드물게 발생하는 이벤트는 pod 재시작 타이밍에 따라 실제보다 적게 잡힐 수 있습니다.1 특히 라벨 조합이 많고 빈도가 낮은 비즈니스 메트릭이라면 꽤 치명적입니다.
Airbnb는 이 문제를 사용자가 PromQL로 매번 우회하게 두지 않았습니다. 대신 집계 계층에서 첫 flush 시점에 합성 zero를 넣는 방식으로 보정했습니다.1 꽤 영리한 해법입니다. 저장소나 대시보드가 아니라 파이프라인 중간에서 의미를 맞춘 것이니까요.
이 사례는 관측성의 본질을 다시 보여줍니다. 메트릭 플랫폼은 단순 저장소가 아니라, 데이터 의미를 지키는 시스템이어야 합니다. 숫자가 많아도 의미가 틀리면 대시보드는 그냥 예쁜 착시입니다.
시사점
Airbnb 사례는 "오픈소스가 저렴하다"는 단순한 이야기가 아닙니다. 올바른 수집 프로토콜, 고카디널리티 제어, 집계 계층 설계, 그리고 Prometheus 의미론에 대한 이해가 함께 있어야만 대규모 운영이 가능하다는 이야기입니다.
실무적으로는 세 가지를 기억하면 좋겠습니다. 먼저 마이그레이션은 듀얼 라이트처럼 검증 가능한 방식으로 하세요. 다음으로 고카디널리티는 저장 후 해결하지 말고, 가능한 한 앞단에서 줄이세요. 마지막으로 counter와 histogram의 의미를 팀이 정확히 이해해야 합니다. 관측성은 툴 설치보다 데이터 모델링이 더 중요합니다.
참고
1Airbnb discloses a billion-series Prometheus metrics pipeline
2Prometheus (software) - Wikipedia
4Airbnb Migrates High-Volume Metrics Pipeline to OpenTelemetry
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.