Apache Arrow を用いた OpenTelemetry Protocol でテレメトリートラフィックを 10 分の 1 に削減
Blog posts are not updated after publication. This post is more than a year old, so its content may be outdated, and some links may be invalid. Cross-verify any information before relying on it.
Apache Arrow を用いた OpenTelemetry Protocol を発表できることを大変嬉しく思います。 これは、分析アプリケーション開発に使用されるカラム指向メモリフォーマットである Apache Arrow をベースにしています。 この統合により、圧縮後のテレメトリーデータトラフィックを 10 分の 1 に削減でき、Zstandard（zstd） 圧縮を有効にした既存の OpenTelemetry Protocol（OTLP）の最良構成と比較して 40% の改善を実現します。 その結果、この新しいプロトコルは、インターネット経由でテレメトリーデータを転送するための最適な選択肢となります。 また、このプロトコルをサポートする新しいレシーバー/エクスポーターのペアが opentelemetry-collector-contrib リポジトリでリリースされたことも発表します。 大量のテレメトリーデータを扱う状況で OTLP プロトコルを補完するよう設計されたこのプロトコルは、2 年間にわたって議論と開発が行われてきました。 これは F5、ServiceNow Cloud Observability、そして OpenTelemetry コミュニティの多くの技術リーダーの協力によるものです（寄贈を参照）。 圧縮の効果は大きく、大半のワークロードで 40% の圧縮効率改善 を示し、属性を共有するマルチバリエイトメトリクスを含むワークロードではさらに大きな改善が見られます。 Apache Arrow を用いた OpenTelemetry Protocol の統合の特筆すべき点は、そのシームレスな適応性です。 一般的なデプロイメントでは、Apache Arrow を用いた OpenTelemetry Protocol の導入に大きな変更は必要ありません。 ユーザーは、わずかに設定を調整した新しいバージョンの OpenTelemetry Collector を再デプロイするだけです。
この新しいプロトコルは、テレメトリーデータ処理の今後の進歩の基盤となり、最新のテレメトリーバックエンドとの統合を促進します。
なぜ新しいプロトコルが必要なのか
テレメトリーデータの増加は否定しようがなく、急速に進んでいます。 この急増はいくつかの要因によるものです。
- デバイスとセンサーの増加
- モノリシックなアプリケーションデプロイメントから、コンテナやサーバーレス関数のようなより細かな形態への移行
- データ駆動型および AI 駆動型テクノロジーへの依存の増加
テレメトリーデータがますます分散するにつれて、ワークロードはロケーションに依存しなくなり、データセンター、クラウド、エッジにまたがるようになります。 この分散により、インターネットを介したテレメトリー転送の最適化がより一層求められるようになります。 エコシステムが変化するにつれて、テレメトリーパイプラインのコンポーネントをエンドツーエンドで最適化し整合させる必要性がより高まっています。
ここで登場するのが、Apache Arrow を用いた OpenTelemetry Protocol です。 この増大する需要に応えるために作られたソリューションです。
従来、テレメトリーデータ量が中程度だった頃は、ワイヤ上での表現が大きな問題になることはありませんでした。 そのようなデータは通常、さまざまなシリアライゼーションフレームワークを使用して構造化オブジェクトとしてカプセル化されていました。 最近まで、OpenTelemetry は主に JSON、またはより一般的には protobuf ベースのバイナリフォーマットをメトリクス、ログ、トレースに対してサポートしていました。 特に protobuf を選択した場合、ネットワーク上で少量から中量の複雑なテレメトリーオブジェクトを送信する際に、シンプルさ、データ表現効率、パフォーマンスのバランスが良好です。
しかしバックエンド側では、圧縮率、データ取得、処理効率を最適化するために、通常このデータはカラム形式で保存されます（行指向とカラム指向のデータ表現の比較は図 1 を参照）。 パイプライン全体でエンドツーエンドのカラム表現に移行することで、テレメトリー転送とバックエンドの間のインターフェイスが合理化されます。 さらに、テレメトリーデータ送信に必要なネットワーク帯域幅が削減されます。 Apache Arrow を用いた OpenTelemetry Protocol は、メトリクス、ログ、トレースにこのカラム表現を利用し、ネットワーク費用の大幅な削減を実現します。
図 1: メモリ表現：行指向とカラム指向のデータ
OTel エンティティのバッチ送信をさらに最適化するために、この新しいプロトコルは gRPC ストリームを使用してディクショナリエンコーディングを効率的に活用します。 バッチ間のテキストデータの多くは冗長であり、属性名と値は頻繁に繰り返されます。 Apache Arrow はディクショナリエンコーディングをサポートしており、ストリーム指向のプロトコルにより、連続するバッチ間でディクショナリのデルタのみを送信できます。 これらの技術により、プロトコルの圧縮性が向上します。
もう1つの非効率な領域は、OTel データモデルがマルチバリエイトメトリクスを扱う方法です。 現在、共有属性を持つメトリクスのバッチを、属性を冗長に複製することなく送信するための合理的なアプローチがありません。 特定のシナリオでは、この冗長性がネットワーク帯域幅と全体的なリソース使用率の両方に過度な負担をかけます。 新しく設計されたプロトコルは、マルチバリエイトメトリクスの改善された表現を提供することで、この問題に対処します。 特定のシナリオでは、クライアント側の変更なしに、OTLP と比較して最大7倍の圧縮改善を確認しています。 将来のクライアント SDK では、この改善をシームレスに提供するように実装される可能性があり、アプリケーションにとってさらに良い結果をもたらす可能性があります。
以下のヒートマップは、バッチサイズと接続時間（ストリームあたりのバッチ数で表される）のさまざまな組み合わせについて、この新しいプロトコルと OTLP（両方とも zstd で圧縮）の間の追加的な圧縮改善率を示しています。 ここで使用されているデータは、本番環境でキャプチャされたスパンのトラフィックからのものです。 ほとんどの場合、改善は大きなものです。 OTLP+zstd と比較した改善が、中程度のバッチサイズ（たとえば、バッチあたり 100 および 1000 スパン）でより顕著であることは注目に値します。 これにより、バッチングによる追加のレイテンシーを最小限に抑える必要があるシナリオでも、このプロトコルが有効であることがわかります。 マイクロバッチ（たとえば、バッチあたり 10 スパン）で Arrow スキーマのオーバーヘッドが問題になるシナリオはほとんどなく、カラム表現の利点が無視できるほどになることもありません。 それ以外のケースでは、この初期オーバーヘッドは最初の数バッチの後ですぐに相殺されます。 カラム構成は圧縮にも適しています。 非常に大きなバッチサイズの場合、圧縮ウィンドウが十分に大きければ zstd は優れた性能を発揮しますが、その場合でも新しいプロトコルは優位性を保ちます。 前述のとおり、マルチバリエイトメトリクスを主に含むトラフィックでは、これらの圧縮改善はさらに大きくなる可能性があります。
進歩はここで終わりではありません。 このプロジェクトの次のフェーズでは、カラムレイアウトを活用して、新しい Arrow ベースのパイプラインをネイティブにサポートする拡張された OpenTelemetry Collector アーキテクチャ内で、データ処理速度を大幅に向上させることを目指しています。 概念実証の結果に基づき、この更新された Collector では少なくとも 1 桁のデータ処理速度の改善を見込んでいます。
これらの非効率と不整合のさまざまな原因が、既存の OpenTelemetry Protocol の代替として新しい Apache Arrow を用いた OpenTelemetry Protocol をサポートする根拠です。 この新しいカラム表現にApache Arrow プロジェクトを活用するという決定には、多くの利点があります。 Apache Arrow は非常に効率的で、データベースやデータストリーム処理の分野で広く採用されています。 その豊富なエコシステムには、Parquet ブリッジから DataFusion のようなクエリエンジンまで、強力なライブラリやツールが揃っています。 これらのリソースにより、革新的な機能の導入が迅速化され、Apache Arrow への移行が進む最新のデータパイプラインと OpenTelemetry をより密接に連携させることができます。
このプロトコルの仕様については OTEP 0156 を参照してください。 エンコード/デコード機能のリファレンス実装は open-telemetry/otel-arrow で確認できます。
デプロイメントで Apache Arrow を用いた OpenTelemetry Protocol をどのように活用できるか
このプロジェクトの最初のフェーズでは、2 つの Collector 間の通信を最適化することが主な目標です。 これは、テレメトリートラフィックが 1 つまたは複数の Collector を経由してからインターネットを介してバックエンドに中継される構成でよく見られます。 Apache Arrow を用いた OpenTelemetry Protocol は元の OTLP よりも複雑であるため、2 つの Collector 間に限定することで、より達成しやすい目標となり、より広いエコシステムへの潜在的な影響を軽減できます。 既存のクライアント SDK、プロセッサー、レシーバー、エクスポーターはシームレスに動作し続けます。 2 つの Collector 間のエクスポーターとレシーバーのみを再設定する必要があります。 即座の効果として、ネットワーク帯域幅が削減され、ネットワークコストの直接的な節約につながります（メトリクスで最大 7 倍、ログとトレースで 2 倍）。 このデプロイメントの詳細な説明については、Collector のビルドをクリックしてください。
よくあることですが、すべてに適した万能のソリューションはありません。 リソースが限られているデプロイメントや、生成されるテレメトリーが少ない場合は、OTLP ベースの標準的な Collector を引き続き使用すべきです。 さらに、Apache Arrow を用いた OpenTelemetry Protocol は、カラム表現の恩恵を十分に受けるために、双方向 gRPC ストリームと一定程度のバッチングをサポートする必要があります。 これにより、特定のシナリオではこのソリューションが適さない場合があります。 また、プロジェクトのこのフェーズでは、Collector の CPU およびメモリ使用量がわずかに増加することが予想される点にも注意が必要です。 これは、OTLP オブジェクトから Apache Arrow を用いた OpenTelemetry Protocol のオブジェクトへの自動変換のオーバーヘッドによるものです。 ただし、このオーバーヘッドはプロジェクトの次のフェーズで完全に解消される予定です。
ユーザーを大切にしているため、エラーを減らしリグレッションのリスクを軽減するバリデーションフレームワークを開発しました。 テレメトリーデータジェネレーターを使用して、OTLP と Apache Arrow を用いた OpenTelemetry Protocol 間の変換、つまりエンコードとデコードのプロセスをテストしました。 さらに、ジェネレーターが生成した元の OTLP リクエストと、エンコード/デコードプロセス後の OTLP リクエストを意味的に比較するための柔軟なコンパレーターも導入しました。 このアプローチにより、多数のエッジケースに対処し、いくつかの重大なバグを修正することができました。 潜在的な問題の原因を特定するために、2 つの異なるレベルで評価を行いました。 1 つ目は、Collector の統合とネットワーク通信をバイパスして、コアのエンコード/デコードメカニズムと直接やり取りする基盤レベルです。 2 つ目は、Collector レベルで、ネットワークのやり取りを含むパイプライン全体の包括的なレビューを行いました。
不正な形式の（意図的かどうかに関わらず）Apache Arrow を用いた OpenTelemetry Protocol のメッセージに対するデコード手法の堅牢性を強化するために、デコード前に Apache Arrow を用いた OpenTelemetry Protocol のメッセージに意図的に異常を注入しました。 目的は、無効な入力に遭遇した際にデコード手法がクラッシュするのではなく、エラーメッセージで応答することを確認することでした。
これらの自動化されたプロセスに加えて、ServiceNow Cloud Observability はさまざまなステージング環境に実験的な Collector をデプロイするというさらなる措置を講じました。 これは、実際のトラフィックに対する Collector の動作とプロトコルの回復力を評価するためでした。 これらのデプロイメントにより、自動バリデーションフレームワークの改善につながっただけでなく、ベンチマーク結果も裏付けられました。
リグレッションや問題の特定と対処に尽力してきましたが、実世界のシナリオは複雑で多様であることを認識しています。 そのため、最も影響の少ない環境から始めて、さまざまなデプロイメント状況やトラフィック負荷でこの新しいプロトコルを評価することをコミュニティに奨励しています。 皆さまのデプロイメントとフィードバックは、このプロジェクトのさらなる強化に役立ちます。
このテストフェーズを促進するために、ファイルエクスポーターも改良し、データを匿名化して圧縮形式で保存できるようにしました。 バグや非効率の原因を特定するために、この匿名化されたトラフィックの分析と再生を可能にするツールも開発しました。 このアプローチは最近、特定のトラフィックに対して使用する最適な Arrow スキーマを定義するロジックの改善において重要な役割を果たしました。 本番環境での実験中に、100 万スパンを超えた後に圧縮率が低下することに気づきました。 分析の結果、問題の原因を特定し、この種の低下がもはや発生しないようにプロトコルを調整することができました（この PR を参照）。
今後の展望
今後は、エコシステム全体に Apache Arrow を用いた OpenTelemetry Protocol を完全に統合することに注力する予定です。 提案されている開発項目は以下のとおりです（必ずしも優先順位の順ではありません）。
- Apache Arrow を用いた OpenTelemetry Protocol とマルチバリエイトメトリクスをネイティブにサポートするスキーマファーストクライアント SDK ジェネレーターの開発： テレメトリーの大量生成を行うシナリオの最適化を目的としています。
- Collector への新しいパイプラインタイプの導入： Apache Arrow を用いた OpenTelemetry Protocol のメッセージを消費および/または生成するために特別に設計された、新世代のレシーバー、プロセッサー、エクスポーターを導入します。 コンポーネント間の通信を合理化することで、データ処理効率の向上が期待されます。 OTLP との相互変換やテレメトリーバッチのシリアライゼーション/デシリアライゼーションがバイパスされるため、大幅な高速化が見込まれます。
- Apache Arrow エコシステムの SIMD ベースデータ処理エンジンの活用： テレメトリーデータ処理をさらに高速化し、データ処理機能の範囲を拡大します。
- Parquet エクスポーターの追加の検討： Apache Arrow と Apache Parquet 間の既存のブリッジにより実現可能です。
- より広いコミュニティにより、特定のテレメトリーバックエンドとの統合を改善する、より合理化されたエクスポーターの開発も期待されています。
まとめ
この新しいプロトコルがコミュニティによってテストおよびベンチマークされることを楽しみにしています。 これは OpenTelemetry コミュニティにとって重要なマイルストーンであり、さらにエキサイティングな開発が今後に控えています。
OpenTelemetry と Apache Arrow の統合の詳細に関心のある方は、Apache Arrow Blog に掲載されたこれらの 2 つの記事をお読みいただくことをお勧めします [1, 2]。 OTel のメトリクス、ログ、トレースという階層的で動的なオブジェクトを効果的に表現するためのさまざまなアプローチの紹介が掲載されています。
雇用主である F5 と ServiceNow Cloud Observability がこのプロジェクトの推進と実行を許可してくださったことに感謝いたします。 また、多くの OTel 技術リーダーの貴重なご支援にも感謝いたします。