本記事は The VictoriaMetrics Observability Blog の記事を翻訳し転載しています。

概要

Airbnbが従来のレガシーなメトリクス環境から、OpenTelemetry、OTLP、OpenTelemetry Collector、およびvmagentを中心に据えた、モダンなオブザーバビリティ（可観測性）パイプラインへと移行した事例を紹介します。本記事では、Airbnbが膨大なパイプラインのメトリクス量をどのように処理したのか、ストレージへ格納する前に高カーディナリティ（データの多様性）をどう削減したのか、そしてスケールを容易にするためにストリーミング集計をどう活用したのかを解説します。

Airbnbのエンジニアリングが桁違いの規模で運用されていることは広く知られていますが、今回構築された大規模メトリクスパイプラインはその事実を改めて証明するものとなりました。これは「規模の拡大」と「効率性の向上」を両立させた極めて稀な成功例です。彼らはオープンソースコンポーネントを用いてオブザーバビリティスタックを刷新し、コストを10分の1に削減しました。現在、Airbnbは単一の本番環境クラスターで毎秒1億サンプル以上のデータを処理しています。

十分な規模に達したオブザーバビリティは、研究に値するシステム設計の課題となります。本記事では、Airbnbがどのようにしてこの仕組みを構築したのか、なぜ集計が必要不可欠だったのか、そしてなぜvmagentがパズルを完成させる最後のピースとなったのかを詳しく見ていきます。 

StatsDからOpenTelemetryへ

Airbnbの従来のメトリクススタックは、アプリケーション層のStatsDライブラリ、中間層の独自フォーク版Veneur、そして末端のベンダー製バックエンドで構成されていました。チームはメトリクスの量とカーディナリティを制御するため、すでにVeneurの独自フォークにカスタム集計機能を組み込んでいました。 

彼らがOpenTelemetry Protocol（OTLP）への移行を決めた理由は、それがCNCFが支援するオープンソースかつベンダーニュートラルなプロトコルであり、新しいPrometheusベースのストレージやオープンスタンダードの思想と完全に一致していたためです。

移行は段階的に進められました。まずデータ収集部分を先行させ、すべてのメトリクスを新しいパイプラインに流し込むことで、どこにボトルネックがあるかを浮き彫りにしました。 

具体的には「デュアルエミッター（二重送信）」構成を採用しました。レガシーシステムには従来のStatsDを残しつつ、新しい推奨経路としてOpenTelemetry Collectorを配置し、その後ろに集計パイプラインを繋ぎました。これにより、チームは大きな摩擦を起こすことなく移行を進め、ソリューションの検証を行うことができました。 

Veneurからvmagentへのリプレイス

Airbnbのオブザーバビリティスタックにおいて、ストレージに保存する前段階での「集計処理」は核心となる部分でした。これがなければ、instance（インスタンス）やhostname（ホスト名）といったラベルがバックエンドに過大な負荷をかけてしまうからです。従来は、重要度の低いラベルを集計するために、独自に保守していたVeneurのフォーク版に依存していました。

新しいオブザーバビリティスタックでメトリクスを最適に集計するため、さまざまなオープンソースの選択肢が検討されましたが、以下のような理由で却下されました。

• Veneurの維持： すでに継続的な運用保守の負担となっており、Prometheusのプロトコルやデータモデルに対応させるための書き直しが必要になるため、負担がさらに増すことが目に見えていました。
• Prometheusのレコーディングルール： ルールを適用するには、一般的にまず生の時系列データをインジェスト（取り込み）する必要があるため、生データを最初に入れないというAirbnbの方針に反していました。
• Vector や m3aggregator： どちらのオプションも、Airbnbのユースケースに対しては複雑すぎると判断されました。

最終的に、AirbnbはVictoriaMetricsの vmagent を選択しました。チームは選定理由を以下のように述べています。

「vmagentはPrometheusメトリクスのストリーミング集計をサポートしています。シャーディングにも対応しているため、水平スケールが可能です。ドキュメントは非常にユーザーフレンドリーで、セットアップも容易です。コードベースが小さく（約1万行）、コードの理解や必要に応じた修正が簡単です」 

ストリーミング集計とは？

ストリーミング集計とは、データがパイプラインを通過する際、流れの中で受信サンプルをリアルタイムに処理する仕組みです。すべての生の時系列データをそのままストレージに書き込むのではなく、集計ルールごとにメモリ上の小さな状態（ステート）を保持します。そして新しいサンプルが到着するたびにその状態を更新し、設定された一定の間隔（インターバル）の終わりに、集計された結果のみをバックエンドにフラッシュ（送信）します。

ストリーミング集計が必要とされる理由は、高カーディナリティのデータはストレージ、メモリ、CPUのコストを著しく高めるためです。ストリーミング集計では、主要なシグナル（データの傾向）を維持しつつ、重要度の低いラベルを削ぎ落とすことで、データの「忠実度」を意図的に下げるアプローチを取ります。

たとえば、[instance] ラベルを含めずにカウンターを集計する場合、vmagentは各インスタンスのラベルを削除して複数のサンプルを結合し、値を集計された形で保持することができます。

単にラベルや時系列そのものを破棄するだけの「リラベリング（再ラベル付け）」とは異なり、集計処理では「複数の入力時系列を、意味のある1つの出力時系列へと統合」することができます。 

このアプローチのトレードオフは、「インスタンスごとのリクエスト数」といった粒度の細かいクエリを実行できなくなる点です。しかし、「全体で何件のリクエストを処理したか」という、ビジネスにおいて最も重要となる高いレイヤーの問いには引き続き答えることができます。つまり、インスタンス単位の可視性は失われますが、全体の集計値は維持されます。

ストリーミング集計は多くの出力関数をサポートしているため、メトリキスの種類や得たい結果に応じて、サンプルの結合方法をコントロールできます。

この機能は、シングルノード版のVictoriaMetricsおよびvmagentでサポートされており、vmagentでは起動時の -streamAggr.config フラグで設定ファイルを指定することで有効化できます。 

Airbnbの集計パイプライン

Airbnbは、自社の集計パイプラインを2つのvmagent層に分割しました。

1. 第1層： ステートレスなルーター。集計によって削除されるラベル以外のすべてのラベルを基準にシャーディング（分散処理）を行います。
2. 第2層： ステートフルなアグリゲーター。届いた時系列データを追跡し、集計を行います。

たとえば、以下の2つのサンプルが集計パイプラインに入ってきたとします。

• counter{service="search", region="us-east-1", host="node-7", instance="pod-a"} 10
• counter{service="search", region="us-east-1", host="node-1", instance="pod-f"} 12 

この例では、有用なディメンション（次元）である service と region は残し、カーディナリティを削減するために instance と host を集計によって削除します。 

シャーディングを担当する第1層のvmagentには、-remoteWrite.shardByURL.ignoreLabels=instance,host という設定を施し、シャーディングキーから instance と host のラベルを除外します。これにより、同じ service と region を持つメトリクスが必ず同一のアグリゲーターにルーティングされ、正しい集計結果が得られるようになります。 

※この「シャーディング時に特定のラベルを無視する」というアイデアは、AirbnbのシニアソフトウェアエンジニアであるEugene Ma氏が、新しいパイプラインの構築中に提案したものです。

集計により、instance や host などの高カーディナリティなラベルが削除され、データは counter{service="search", region="us-east-1"} 22 のように集約されて出力されます。

Airbnbは、vmagentがオープンソースで構造がシンプルであったため、このプロジェクトで独自にカスタマイズ（フォーク）して活用しました。このアプローチにより、同社は単一の本番環境クラスターですべてのメトリクスを集計するという目標を達成し、現在では数百個のvmagentアグリゲーターPodを運用して毎秒1億以上のサンプルを取り込んでいます。

まとめ

Airbnbの事例は、適切なオープンソース技術を選択し、それを利用・カスタマイズすることで、大規模なトラフィック下でも効率的なオブザーバビリティを維持できることを示しています。vmagentは、信頼性とシンプルさを兼ね備え、大規模データ処理のニーズに最適でした。

この移行は、従来のベンダーに依存した環境から、高効率でスケール可能な現代的なスタックへと進化を遂げた好例です。

よくある質問（FAQ）

Q. OTLPとは何ですか？

A. OTLP（OpenTelemetry Protocol）は、OpenTelemetryがテレメトリーデータを転送するために使用する標準プロトコルです。

Q. AirbnbはOpenTelemetry Collectorをどのように使用しましたか？

A. 従来のStatsDシステムと並行して新しい収集経路として導入し、安全かつ段階的な移行を実現しました。

Q. パイプラインメトリクスとは何ですか？

A. ストレージ格納前に、収集・ルーティング・集計といった処理を経てバックエンドに届くメトリクスです。集計がないと、instance や host などのラベルが膨大なカーディナリティ（データ量）を生み出し、システムに過負荷をかけるリスクがあります。

Q. vmagentは大規模なテレメトリーパイプラインにどう貢献しますか？

A. 効率的なメトリクスの収集、ルーティング、処理能力を提供します。ストリーミング集計機能により、重要なシグナルを維持しながら、バックエンドへ保存する前にデータ量（カーディナリティ）を効果的に削減します。

Q. なぜ大規模なOpen Telemetryメトリクスにおいてストリーミング集計が重要になるか？

A. 大規模な環境においてOpenTelemetryメトリクスのストリーミング集計が重要となる理由は、高カーディナリティなラベルがストレージ、メモリ、CPUの使用量を急激に増加させるためです。vmagentを活用することで、データがストレージに到達する前に重要度の低いラベルを集計してバックエンド負荷を軽減しつつ、サービスやリージョンごとの総リクエスト数など有用な上位シグナルを維持できます。

著者： Pablo Fernandez
原文：How Airbnb Built a High-Volume Metrics Pipeline with OpenTelemetry and vmagent