# OTel-Arrow フェーズ 2: 効率的なトランスポートから効率的なテレメトリーパイプラインへ

LLMS index: [llms.txt](/llms.txt)

---

OTel-Arrow の[フェーズ 1](https://github.com/open-telemetry/otel-arrow/blob/c6ed105cab28e537bf5c2c81a97e9b63677d3cff/docs/phase1-overview.md) では、OTAP（OpenTelemetry Arrow Protocol）を OpenTelemetry 向けの効率的なトランスポートプロトコルとして確立しました。
Apache Arrow は、構造化データをシステム間で効率的に移動・処理するために設計された、言語非依存の列指向インメモリフォーマットです。
テレメトリーを OpenTelemetry データモデルとの互換性を維持しつつ、大幅に低いネットワークオーバーヘッドで転送できることを実証しました。

[フェーズ 2](/blog/2025/otel-arrow-phase-2/) では異なる問いを立てました。
Arrow をネットワーク上だけでなく、パイプラインが内部的に扱うデータ表現としても使ったらどうなるのか、という問いです。

テレメトリーの量は急速に増加しており、その背景には OpenTelemetry の幅広い導入、より豊富な計装、そしてよりダイナミックな AI やエージェントベースのワークロードがあります。
この規模になると、属性の削除、フィールドのリネーム、メタデータの追加、シグナルのルーティングといった一般的なパイプライン操作は、できるだけコストが低いことが求められます。
これらの操作の多くは単純で反復的です。
プロセッサーがあるレコードの属性に対して処理を行う場合、同じバッチ内の多くのレコードに対しても同じ属性への処理が行われることが多いのです。

このパターンは列指向の表現とよく適合します。
テレメトリーをコンパクトな Arrow バッチに保ったまま、プロセッサーが属性のリネーム、データのエンリッチメント、シグナルのルーティングを行えれば、パイプラインは各変換にかかる周辺処理を削減し、CPU とメモリをより効率的かつ予測可能に使用できます。
OTAP は、テレメトリーの増加という次のフェーズにおいて、OpenTelemetry パイプラインをより効率的に運用する上で重要な役割を果たせると考えています。

## Arrow パスを検証するためのデータフローエンジン {#a-dataflow-engine-built-to-test-the-arrow-path}

このアイデアを探るため、OTel-Arrow Dataflow Engine を構築しました。
これは OTAP をパイプライン内の主要なデータ表現として設計した Rust ランタイムです。
OTAP ストリームをエンドツーエンドで受信・送信でき、[OTLP](/docs/specs/otlp/)（OpenTelemetry Protocol）も別のファーストクラスのデータパスとしてサポートしています。

このデュアルパス設計により、同じランタイム内で 2 つのモードを比較できます。
テレメトリーを Arrow レコードバッチのまま保持する OTAP ダイレクトパスと、明示的な境界で OTLP と OTAP 間の変換を行う OTLP 互換パスです。
結果は明確です。
テレメトリーが OTAP パス上にエンドツーエンドで留まると、トランスポートと処理のコストが大幅に低下します。

OpenTelemetry Collector は、OpenTelemetry パイプラインのための広く利用されている汎用的な実装です。
そのパイプラインモデルは OTLP 形式のインメモリデータ構造を中心に構築されており、柔軟で OpenTelemetry データモデルと密接に整合していますが、大量のバッチ処理には比較的コストがかかります。
本研究の目的は、異なる設計ポイントを検証することです。
OTAP を主要なデータ表現とし、OTLP 互換性を明示的な境界で処理するテレメトリーデータプレーンの構築です。

Dataflow Engine は [NUMA フレンドリー](https://www.kernel.org/doc/html/v4.18/vm/numa.html)な、[コアごとのスレッド、シェアードナッシング](https://seastar.io/shared-nothing/)アーキテクチャを採用しています。
バウンデッドチャネルとデータ構造を重視し、ホットパスでの同期を回避し、パイプラインを通じて配信確認を伝搬し、管理 API を通じたライブパイプラインの再構成をサポートしています。

ベンチマークでは、2 つのパイプラインデータ表現のコストを比較しています。
Collector が使用する OTLP 形式のオブジェクトモデルと、Dataflow Engine が使用する OTAP 表現です。
また、Arrow ベースの処理、変換境界の削減、バウンデッドな実行、明示的なフロー制御といったランタイム設計上の選択についても評価しています。

以下の図では、DFE は OTel-Arrow Dataflow Engine を、Collector は OpenTelemetry Collector 実装を指します。

## ベンチマークのハイライト {#benchmark-highlights}

フェーズ 2 のベンチマークは、3 つの実践的な問いに答えるために設計されました。

- テレメトリーを Arrow 表現のまま保持することで、実際のパイプライン処理がより低コストになるのか、それとも OTAP はネットワーク上でのみ有効なのか。
- もしそうなら、ランタイムアーキテクチャ自体が、より多くの CPU コアを割り当てたときにその効率性を線形にスケールさせ維持できるのか。
- 同じリソース量を使用した場合、OTAP ストリームは OTLP ストリームと比較してどの程度のスループット向上をもたらすのか。

完全なベンチマークマトリクスは[インタラクティブなベンチマークサイト](https://open-telemetry.github.io/otel-arrow/compare/)で利用できます。
ここでは、最も重要な結果をまとめた 3 つの要約図に焦点を当てます。
インタラクティブサイトでは、追加のレート、バッチサイズ、圧縮設定、メモリの動作、ネットワーク使用量、飽和マーカー、使用されたテスト構成を含む完全なビューを提供しています。

### ベンチマークのコンテキスト {#benchmark-context}

ベンチマークでは、意図的にシンプルな変換操作を使用しています。
`exception.type` を `exception.kind` にリネームするような、ログ属性のリネームです。

この種の作業は OpenTelemetry パイプラインで頻繁に行われます。
チームはセマンティック規約の移行時に属性をリネームしたり、バックエンドへのデータ送信前にフィールドを正規化したり、環境メタデータを追加したり、ルーティング、ガバナンス、エンリッチメントのためにテレメトリーを準備したりします。
個々の操作はコストが低いはずですし、実際にそうであることも多いのです。
しかし、コストの大部分は実際の変換そのものではなく、その周辺のデコード、オブジェクトの走査、メモリ割り当て、エンコード処理にあることが少なくありません。

変換ベンチマークの大部分は、16 コア、118 GiB RAM を搭載した Intel Xeon Platinum 8581C システム上で、Debian GNU/Linux 12 を使用して実行されました。
完全な環境の詳細については[インタラクティブなベンチマークウェブサイト](https://open-telemetry.github.io/otel-arrow/compare/)を参照してください。
これらのテストでは、テスト対象のパイプラインに _1 コア_ を割り当て、残りのコアはトラフィックジェネレーターとシミュレートされたバックエンドに使用しました。
コアは配置を安定させ、コンポーネント間の干渉を減らすためにピニングしました。
スケーリングおよび飽和テストでは、64 コア、2 ソケットの Intel Xeon 8358 システム（1024 GiB RAM）を使用しました。
バックプレッシャーの構成方法を含む完全な実験セットアップについては、[ベンチマークのドキュメント](https://github.com/open-telemetry/otel-arrow/blob/c6ed105cab28e537bf5c2c81a97e9b63677d3cff/docs/benchmarks.md)を参照してください。

## 結果 1: OTAP は処理コストを低く保ち、バックプレッシャーが過負荷を抑制する {#result-1-otap-keeps-processing-cheap-while-backpressure-bounds-overload}

![リネームルールの増加に伴う OTAP 変換の低い増分 CPU コスト、大きなバッチサイズでの低い CPU 使用率、過負荷時のバウンデッドメモリを示す 3 つのベンチマーク要約](3-takeaways.svg)

図 1: 変換ルール数に対する感度、バッチサイズの動作、過負荷時の動作を示す変換ベンチマークの要約。

上の図は、変換ベンチマークから得られた 3 つの重要な観察結果をまとめています。

最初の観察結果は、リネームアクションの追加が Dataflow Engine にほとんど増分コストを与えないことを示しています。
200K ログ/秒、1 ログエントリあたり約 300 バイトの条件で、ネイティブ OTAP パスはリネームアクション数が 1 から 4 に増加しても CPU 使用率が 6.4% から 6.6% に変わるだけです。
DFE OTLP パスは、テレメトリーをまず OTLP からデコードし OTAP 指向の内部表現に変換する必要があるため、よりコストがかかります。
しかし、その変換コストを支払った後は、追加のリネームアクションによる CPU の増加はごくわずかです。

OTel Collector OTLP パスは、現行の Collector を表しています。
OTLP proto のデコードに高い初期コストを支払い、さらに操作ごとに 3.75% の CPU を消費し、4 つの操作後には合計 92.5% の CPU となります。

2 つ目の観察結果は、400K ログ/秒で大きなバッチがすべてのパスの CPU コストを削減する一方、OTAP パスが最も大きな恩恵を受けることを示しています。
1 バッチあたり 256 ログの 21% CPU から、1 バッチあたり 4096 ログでは 7.8% CPU に低下します。
これは、コンパクトな列指向バッチ表現として期待される動作です。

3 つ目の観察結果は、エンジンの過負荷時の動作に関するものです。
この図は、512 MiB のメモリ制限を設定した Collector OTLP パスを示しています。
この値は、このシナリオで約 300 MiB を使用する Dataflow Engine OTLP パスと同じ範囲にメモリ予算を保つために選択されました。
この設定では、飽和状態で Collector のメモリが急激に増加し、受信スループットが低下します。
Collector のメモリ制限を高くすると、受信スループットは向上します。
2 倍の飽和状態では、2048 MiB の制限で約 544K ログ/秒を受信できるのに対し、512 MiB の制限では約 128K ログ/秒にとどまります。
しかし、平均メモリは約 1.3 GiB に上昇します。
高い制限により、Collector は CPU が飽和している間により多くの処理をメモリに保持できますが、これは受信スループットを改善する一方で過負荷コストの大部分をメモリ使用量に転嫁します。
Dataflow Engine はバックプレッシャーを適用することで、過負荷時でもメモリをバウンデッドに保ち、過負荷をメモリに吸収させるのではなく可視化します。

これらの結果を総合すると、2 つの補完的な効果が示されています。
OTAP は処理コストを低く保ちバッチ処理から大きな恩恵を受ける一方、Dataflow Engine のバウンデッドな実行モデルはバックプレッシャーを適用することで過負荷時の動作をより予測可能にします。

次の 2 つの結果では、2 つの問いを分離しています。
まず、テレメトリーが OTLP 経由で入力される場合に Dataflow Engine ランタイムがスケールするかどうか、次に、同じランタイムがネイティブ OTAP パスに留まれる場合にどれだけ多くのスループットが得られるか、という問いです。

## 結果 2: スケーリングはほぼ線形を維持 {#result-2-scaling-stays-close-to-linear}

![OTLP 取り込みにおける 1 コアから 16 コアまでの Dataflow Engine の測定スピードアップと理想的な線形スケーリングを比較するチャート。16 コアで 14.6 倍に到達](otlp-scaling.svg)

図 2: 1 コアから 16 コアまでの測定スピードアップと理想的な線形スケーリングを比較する OTLP スケーリングテスト。

2 つ目の図は、Dataflow Engine が利用可能な CPU コアをどの程度効率的に使用するかを示しています。
コアごとのスレッド、シェアードナッシングアーキテクチャは、ホットパスでの同期プリミティブを回避するため、追加のコアは最小限の調整オーバーヘッドで追加のスループットに変換されます。
このテストでは、テレメトリーは OTLP として入力されるため、各バッチは処理前にデコードおよび変換される必要があります。
これは、理想的な Arrow のみのワークロードではなく、現実的な変換コスト下でのスケーリングを示すための意図的な選択です。
それでも、エンジンは 16 コアで 14.6 倍のスピードアップに達し、理想的な 16 倍のラインに近く、全体で 1.91M ログ/秒を達成しています。
1 コアでスループット N を処理できる場合、16 コアでは 16N に近いスループットが得られます。
運用者にとって、これは垂直スケーリングが効果的であることを意味します。
これは、ほとんどのパイプラインが既に依存している水平スケーリングを補完する利点です。

この結果は、ランタイムの問いとプロトコルの問いを分離しています。
このテストでは、テレメトリーは OTLP として入力され、処理前にデコードおよび変換される必要があります。
その変換コストがあっても、バウンデッドなフロー制御を備えたコアごとのスレッド、シェアードナッシングアーキテクチャは、割り当てられた CPU コアを効果的に使用できています。
運用者にとっての実践的な結果は垂直スケーリングです。
より多くのコアがより多くのスループットに変換され、効率の損失は限定的です。

## 結果 3: OTAP は同じランタイムでより高いスループットを提供 {#result-3-otap-provides-higher-throughput-on-the-same-runtime}

![Dataflow Engine 上のコア数ごとの OTAP と OTLP のスループットを比較するチャート。OTAP パスはおよそ 10〜20 倍のスループットを達成](otap-scaling.svg)

図 3: OTel-Arrow Dataflow Engine 上の OTAP パスと OTLP パスのスループット比較。

3 つ目の図は、同じ Dataflow Engine 上の同じコア数で OTAP と OTLP のスループットを比較しています。
入力と出力の両方が OTAP の場合、エンジンは変換コストを支払いません。
テレメトリーは取り込みから処理、エクスポートまで Arrow ネイティブの表現のまま保持されます。
入力が OTLP の場合、エンジンは処理前に各バッチをデコードおよび変換し、出力時に再度変換する必要があります。
この変換境界が 2 つのパスの差のすべてであり、これを取り除くことで OTAP パスは OTLP パスの約 **10〜20 倍のスループット** を達成します（コア数により異なる）。
1 コアでは、OTAP パスが 2.47M ログ/秒に達するのに対し、OTLP パスは 121K ログ/秒で、20 倍をやや上回ります。

この結果は、OTLP 変換境界を取り除く効果を示しています。
OTAP は重い OTLP トランスコーディングを回避し、Arrow ネイティブエンジンがデータをより直接的に処理できるようにします。
8 コアの OTAP 実行は負荷ジェネレーターの限界に達しており、推定される完全飽和スループットは約 16M ログ/秒であるため、理想的なスケーリングにさらに近づく余地があります。

## 主要な知見 {#key-takeaways}

これら 3 つのベンチマーク要約は、フェーズ 2 の主要な方向性を支持しています。
OTAP はテレメトリーの表現コストを削減します。
OTel-Arrow Dataflow Engine は処理を通じてその利点を維持し、コア間でスケールさせ、過負荷時の動作を可視的かつ制御可能に保ちます。
本番のテレメトリーパイプラインにとって、その予測可能性は生のスループットと同じくらい重要です。
OTAP は操作あたりのコストが低いだけでなく、同じハードウェア上で大幅に高いスループットも実現します。

これらの比較は、ここで示された特定のベンチマークパスと構成の測定値として解釈すべきであり、すべての Collector デプロイに対する普遍的な主張ではありません。
完全なベンチマークマトリクスは[インタラクティブなベンチマークサイト](https://open-telemetry.github.io/otel-arrow/compare/)で利用可能で、生のチャートと構成の詳細を確認できます。

## Arrow がコストモデルを変える理由 {#why-arrow-changes-the-cost-model}

ベンチマーク結果は、シリアライゼーションの回避だけではありません。
テレメトリー処理のコストモデルにおける、より深い変化を示しています。

行指向の OTLP ベースパスでは、テレメトリーは protobuf バイト列として到着します。
これらのバイト列のデコードにより、各テレメトリーレコードがリソース、スコープ、個々のシグナルレコードにまたがるヒープ割り当てのオブジェクトグラフとして具体化されます。
プロセッサーはこれらのオブジェクトを走査・変更し、再エンコードにより結果をバイト列に戻します。
入力時のすべてのメモリ割り当ては、出力時にガベージとなります。
属性のリネームのようなバッチ全体に一様な操作では、そのメモリ割り当てとガベージコレクションの負荷が変換自体を上回ることがあります。
これは特定の実装に依存しない、行指向処理の構造的コストです。

OTAP ネイティブパスでは、テレメトリーは Arrow レコードバッチのまま保持できます。
プロセッサーは、メモリの局所性に優れ割り当てが少ない、コンパクトな列指向バッチ表現に対して操作できます。
繰り返し値はより自然にグループ化され、圧縮はより有利なレイアウトで処理でき、プロセッサーは操作が列指向モデルに適合する場合に Arrow カーネル、辞書エンコーディング、ベクトル化実行を活用できます。

つまり、OTAP はネットワーク上のバイト数を削減するだけではありません。
より大きな可能性は、テレメトリーデータプレーン内部のオーバーヘッドを削減することにあります。

## 現在の成熟度 {#current-maturity-level}

OTel-Arrow Dataflow Engine は、多くの重要な機能が現実的な環境で使用可能な成熟度に達しています。
しかし、外部ユーザー向けの本番安定化されたプラットフォームというよりは、インキュベーション段階のプロジェクトと表現するほうがより正確です。

プロジェクトは、構成フォーマット、API、コンポーネントインターフェイス、運用セマンティクスを含め、まだ発展途上です。
現段階では、これらの外部公開面に対する安定性や後方互換性の保証はありません。

ユーザーは、このエンジンを評価、ベンチマーク、フィードバックを通じた改善の対象として扱うべきです。
実環境での使用は制御された実験に限定すべきであり、本番ワークロードへの使用は現段階では推奨されません。

## 結論 {#conclusion}

OTAP は、単なるコンパクトなネットワークフォーマットではありません。
テレメトリーがトランスポートとパイプライン処理を通じて Apache Arrow データモデル内に留まることで、パイプラインは繰り返しのデシリアライゼーション、オブジェクトの再構築、メモリ割り当て、コピー、再シリアライゼーションを回避し、ベクトル化処理やより高い圧縮率への道を開きます。

バウンデッドなランタイム設計に基づくアーキテクチャと組み合わせることで、この表現はネットワーク効率、CPU 消費、メモリ使用量、負荷下の安定性、制御された再構成といった複数の側面にわたる改善を実現します。
テレメトリー量が増加し続け、オブザーバビリティパイプラインがバックエンドにデータが到達する前により多くの処理を実行することが期待される中で、Arrow ネイティブパスが OpenTelemetry にとって重要な方向性であると考えるのはこのためです。

OpenTelemetry コミュニティから、ランタイムセマンティクス、運用モデル、処理 API、パイプラインの保証、OTAP ネイティブ処理パターンに関するフィードバックを特に歓迎します。
また、ベンチマークのアイデア、実環境のパイプライン設計、スループット、効率、メモリの動作、過負荷の処理を大幅に改善する構成についても関心があります。
これらを活用して、私たちの前提に挑戦し、テレメトリーパイプラインのパフォーマンスとスケーラビリティの水準を引き上げたいと考えています。

[otel-arrow](https://github.com/open-telemetry/otel-arrow/discussions) GitHub プロジェクトのディスカッション、[#otel-arrow](https://cloud-native.slack.com/archives/C07S4Q67LTF) Slack チャネル、または関連する OpenTelemetry [SIG ミーティング - Arrow](https://github.com/open-telemetry/community/tree/fa6a4b68cf63438b760419124b0abfbe4ae238ed#sig-arrow) にご参加ください。
コントリビューションを歓迎しています。
大規模なコントリビューションの場合は、実装作業を始める前に [GitHub イシュー](https://github.com/open-telemetry/otel-arrow/issues)を開くこと、および変更がアーキテクチャ、セマンティクス、またはより広いエコシステムの統合に影響する場合は SIG のディスカッションで早期のフィードバックを得ることを強く推奨します。