オープンソースの分散トレーシングプラットフォームであるJaegerのバージョン2がリリースされた。このリリースには、JaegerとそのコンポーネントをOpenTelemetryフレームワークに取り込むという、重要なアーキテクチャの変革が含まれている。
Jaeger v2のもっとも注目すべき変化は、アーキテクチャ的にOpenTelemetry Collectorフレームワークの中に位置づけられるようになったことだ。JaegerとOpenTelemetry Collectorは以前、一部のコードと機能を共有していたが、バージョン2.0ではCollectorのアーキテクチャを完全に取り入れ、より合理的で拡張可能なプラットフォームを作り出している。
新バージョンはまた、バージョン1.0の複数の別々のバイナリに置き換えて、単一のバイナリとして提供される。単一のバイナリを使うことで、コンテナイメージはより軽量化され(40MBから30MBに減少)、Jaegerコンポーネント間の多くのコマンドラインパラメータの不整合も取り除かれた。Jaegerとそのコンポーネントは、単一のYAML設定ファイルで自由に有効にできるようになった。
Jaeger v2には他にもいくつかの重要な改良点がある。
-
**ネイティブなOpenTelemetry処理:**古いバージョンのJaegerでOTLP (OpenTelemetry Protocol)データフォーマットを使うには、中間の変換ステップを追加する必要があった。一方で、v2では現在はOTLPデータフォーマットがネイティブにサポートされている。
-
**高度なサンプリング技術:**Jaegerは伝統的にヘッドベースのサンプリングをサポートしていたが、今回のアップデートでは、以前OpenTelemetryに提供されたサンプラーを通じて、テールベースのサンプリング機能も導入している。
-
**拡張されたエコシステムへのアクセス:**ユーザーは、スパンをメトリックに変換するコネクタやテレメトリ処理ツールなど、多くの既存のOpenTelemetry Collector拡張機能を現在は使用できるようになっている。
-
**柔軟なストレージ実装:**Jaegerのストレージ層は抽象化として実装されている。これは、クエリ機能とエクスポート機能の両方が、専用の実装なしで外部ストレージと相互作用できることを意味する。バッチエクスポートも現在は可能になり、ClickHouseのようなバックエンドとのパフォーマンスが向上している。
新バージョンは、これまでのすべてのストレージバックエンドをサポートし、完全な後方互換性を維持している。また、中間キューとしてKafkaのサポートを導入し、コレクター、インジェスター、クエリーコンポーネントを含む様々なデプロイメントの役割の設定を提供する。
v2リリースに向けて公開された投稿の中で、Yuri Shkuro氏とJonah Kowall氏は、変更の技術的な進化についてより詳しく述べている。JaegerチームとOpenTelemetry Collectorチームがいかに緊密に協力してきたかについて、彼らは、プロジェクトをより緊密にすることが以前からの目標だったと語る。この連携は、Jaegerでメンテナンスするコードが少なくなることを意味する。両プロジェクトの緊密な連携によってJaegerは将来への対応力を得ている。そしてJaegerがOpenTelemetryの推奨トレーシングシステムとして新たな地位を得た。
Shkuro氏とKowall氏は、Jaeger v2のリリースは、OpenTelemetry Collectorフレームワークの周りにJaegerをリベースする3回目の試みであり、この試みは3つの重要な要因のおかげで成功したと説明している。
-
古いバージョンとのコマンドラインの互換性を壊す。
-
OpenTelemetry Collectorのコードをライブラリとしてインポートする。
-
Jaeger v1のコードをv2で再利用するためのアダプターを構築する。
彼らは、Jaeger v2のアーキテクチャは標準的なOpenTelemetry Collectorを忠実に反映しており、テレメトリ処理のためにレシーバー、プロセッサー、エクスポーターを含むパイプラインを利用していると彼らは説明している。また、直接的なテレメトリ処理以外の機能拡張も組み込まれており、JaegerチームはCollectorフレームワークに対して特定の設計適応を行っている。
Mediumの投稿では、CNCFアンバサダーのDotan Horovits氏がJaeger v2の新技術についてShkuro氏にインタビューしている。
Horovits氏とShkuro氏は、歴史的な背景を説明しながら、Jaegerが当初は完全なSDKとエージェント機能を提供していたが、段階的に独自のSDKを廃止し、OpenTelemetry SDKに置き換えることで、どのようにOpenTelemetryエコシステムに適応してきたかについて話している。彼らはまた、Jaegerエージェントがどのように非推奨になり、OpenTelemetryコレクターに取って代わられるかについても話している。
インタビューではさらに、KafkaやRedisのような複数のソースからの、より柔軟なデータルーティングや、OpenTelemetry Builderフレームワークが、さらなるダイナミックな拡張の可能性を開くことについても言及されている。Horovits氏はまた、Jaegerのv2リリースのスピードも称賛している。Shkuro氏は、「多くの人が取り組んでいない中、1年以内にV2を完成させることができたのは、ビッグバンではなく、段階的な変更だったからだ...全てを再構築しよう」と説明している。
Jaegerのメンテナーは、2025年に向けてのマイルストーンについても詳しく述べている。これらは下記を含むものである。
-
OpenTelemetryオペレータのネイティブサポート
-
Helmチャートの開発
-
ClickHouseを公式ストレージバックエンドとして追加する。
-
OpenTelemetryデータでネイティブに動作するようにユーザーインターフェースを改善する。
Jaeger v2に対するコミュニティの反応はポジティブだが、一部のコメント者はUIの改善については控えめなコメントもある。
Jaeger V2の展開は、非常に重要で、OpenTelemetryへの大きなコミットメントです。
シングル・バイナリのデプロイとネイティブのOTLPのサポートは素晴らしいタッチです。しかしながら、約束されたUIの改善がどのように展開されるかを見てみる必要があります。
現在は、Jaeger 2.0が利用可能になり、簡単にデプロイできるようになっている。CNCFのアナウンスでは、getting startedのページが推奨されている。