F5は、Apache Arrowを使用したOpenTelemetryのフェーズ2でMicrosoftと協業します。

Apache Arrow を使用した OpenTelemetry のフェーズ 1 は、野心的な目標を掲げて開始されました。 このフェーズでは、OpenTelemetry Protocol (OTLP) に革新を導入することで、テレメトリ データ転送がこれまでにないほど最適化されました。 圧縮率は標準の OTLP プロトコルと比較して 30% ～ 70% 向上し、今後の作業の基礎となる注目すべき成果となりました。

しかし、フェーズ 1 は氷山の一角にすぎませんでした。 これにより、OpenTelemetry と Apache Arrow を組み合わせることの威力が証明され、OpenTelemetry パイプライン全体を高性能な列指向データ処理の強力なツールに変えるという、さらに大きなミッションの基盤が整いました。

フェーズ 2 では、F5 と Microsoft は、Golang コレクター用の Rust パイプラインを構築することを目標に、Rust と Apache Arrow を活用した完全にネイティブな OpenTelemetry パイプラインを開発することで、パフォーマンスの最適化をさらに進めています。 これにより、CPU 使用率、メモリ効率、スループット、レイテンシが劇的に改善され、より効率的なデータ処理エコシステムの実現に貢献します。

私たちの目標は、最適なデータ圧縮、データ処理の高速化、最新の列指向の観測性との効率的な統合のバランスをとることでもあり、この取り組みを、主に圧縮のみに焦点を当てた STEF などの他のプロジェクトとは一線を画しています。 

Rust に「全力で取り組む」という決定は、技術コミュニティの間で興奮と多少の論争を巻き起こしました。 結局のところ、OpenTelemetry の Collector プロジェクトは伝統的に Golang を使用して構築されています。 では、なぜ Rust なのでしょうか?

Rust と Apache Arrow は、データ処理の世界では親友のような存在です。 両方のテクノロジーは深く補完し合うため、Rust はフェーズ 2 の開発に最適な選択肢となります。 以下にいくつかの理由を挙げます。 

• ガベージ コレクターなしのメモリの安全性とパフォーマンス: Rust はメモリの安全性を重視しているため、データ パイプラインが堅牢かつ安全であり、データ破損やセグメンテーション エラーなどのリスクが最小限に抑えられます。 これを Rust のパフォーマンス特性 (低オーバーヘッド、ゼロコストの抽象化) と組み合わせると、Apache Arrow が採用している高速で大量のテレメトリ データを効率的に処理するのに最適です。
• 列指向データ処理: Apache Arrow は、ゼロコピー、列指向のデータ処理の事実上のフレームワークです。 これは最新のデータ レイク全体で広く採用されており、Parquet、Delta Lake、Iceberg などのシステムをサポートしています。 Arrow とのネイティブ統合により、Apache DataFusion や Arrow 対応データ レイクなどの強力な分析エンジンとシームレスかつ効率的にデータを交換できるようになります。
• ゼロコピーデザイン: Apache Arrow のゼロコピーパラダイムは、直接メモリアクセスを重視する Rust の考え方と見事に一致しています。 これらのテクノロジを組み合わせることで、シリアル化とデシリアル化のオーバーヘッドが排除され、CPU サイクルを無駄にすることなく大規模なデータ ストリームを効率的に処理できるようになります。
• 繁栄するエコシステム： Apache Arrow を中心とした Rust エコシステムは活況を呈しています。 フェーズ 2 で Rust を選択することで、F5 と Microsoft はこの活気あるコミュニティを活用し、Apache DataFusion などの強力なライブラリやフレームワークとの統合を実現します。 これらの接続により、新しいapplications、特に分析や機械学習に使用される大規模なデータ レイクとの統合が可能になります。 このプロジェクトはまだ初期段階ですが、すでに観測可能性に重点を置いたデータベースを専門とする複数の企業から関心を集めています。

Rust と Apache Arrow を活用した OpenTelemetry with Apache Arrow は、単にパフォーマンス メトリックに取り組むだけでなく、テレメトリとデータ エコシステム全体でのより広範な導入の基盤を整えます。

テレメトリ パイプラインがデータ レイクにシームレスに埋め込まれ、列指向の分析プラットフォームへの直接接続が提供される世界を想像してみてください。 このエンドツーエンドのゼロコピー パイプラインにより、テレメトリ データが本番環境から下流のシステムにシームレスに流れるようになり、OpenTelemetry 内ではこれまで想像もできなかった統合が可能になります。

組み込み可能性を保護し、厳格なメモリ制御を優先し、コアごとのスレッドランタイムサポートを有効にすることで、フェーズ2では、このRustベースのパラダイムが期待を上回るだけでなく、開発者と企業の両方がアクセスし続けることを保証します。

Rust に関する話題があるにもかかわらず、フェーズ 2 は Golang を放棄することを意味するものではありません。 実際、F5 と Microsoft は、Go パイプラインと Rust パイプライン間の互換性を確保するために慎重な措置を講じています。 Golang で記述されたアダプターと既存の OpenTelemetry Collector コンポーネントは引き続きサポートおよびメンテナンスされます。 これにより相互運用性が確保され、組織は単一の言語に縛られることなく、ワークフローに最適なツールセットを選択できるようになります。

この統一的なアプローチは、エコシステムを分裂させるのではなく成長させるという OpenTelemetry の取り組みと一致しています。 このコラボレーションにより、相互接続されたワークフローの一部として Rust と Go のパイプラインをブリッジすることで、多様なユーザー ベースが OpenTelemetry にアクセスし続けることが保証されます。

OpenTelemetry ガバナンス委員会は、より広範な OpenTelemetry エコシステム内での調和を維持しながら Rust ベースのイノベーションを探求することの重要性を認識し、フェーズ 2 を承認しました。 「Beaubourg」ライブラリのような F5 からの貢献は、すでに構築するための強力な基盤を提供しています。

F5 と Microsoft がこの取り組みで協力することで、パフォーマンスを最適化するだけでなく、テレメトリの世界に刺激的な可能性への扉を開くことになります。 このイノベーションへの投資は、オープンソース テレメトリ システムの最先端を維持し続けるという OpenTelemetry の取り組みを物語っています。