分散トレーシングに必要なトレースコンテキストのフォーマットはNew Relicも参加し標準化が進んでいます。また、New Relic APM Agentとしてのサポートも行われます。その相互運用性について、2020年2 月5日に投稿された「Announcing New Relic Support for W3C Trace Context: Now Available in New Relic APM」の抄訳にてご紹介します。
分散トレーシングは、高度に分散されたマイクロサービスアプリケーションを扱う開発者にとって不可欠なツールになっており、複数のマイクロサービスを横断するイベントの相互作用を追跡することができます。しかし、すべてのトレースツールが、トレースをサービスからサービスへと受け渡す際に、HTTPヘッダを介してコンテキスト情報を渡す同じ方法を採用しているわけではありません。この標準化の欠如が、相互に互換性のないヘッダフォーマットの混在を招いており、組織内の開発チームが独自のトレースツールを選択する際に問題になることがあります。
W3C Trace Context は、最新の高度に分散されたアプリケーションを扱う開発者が分散トレーシングをより簡単に実装し、信頼性を高め、最終的にはより価値のあるものにするための標準規格です。この標準は、開発者が異なる分散トレーシングソリューションのツールを使用してサービスを計測するユースケースを大幅に簡素化します。W3C Trace Context標準に準拠したすべてのトレーサーとエージェントがトレースに参加できるようになりました。トレースデータをルートサービスからターミナルサービスに至るまで伝搬させることができます。
New Relicは約2年前からW3C Trace Context Working Groupに参加しており、標準規格の定義や承認プロセスを支援してきました。W3C Trace Context仕様は2月6日に「勧告」ステータスに到達しましたが、この度、この規格が完全に批准されることを見越して、サポートを開始したことを発表することができ、大変嬉しく思っています。
以下のNew Relic APMエージェントでサポートしています：
- Java 5.1.0以降
- Python 5.5以降
- Go 3.1.0以降
- Node.js 6.4以降
- Ruby 6.9.0以降
- PHP 9.8以降
- .NET 8.27以降
（New RelicオープンソースElixirエージェントのサポートも追加しました。New Relic BrowserエージェントのTrace Contextサポートも間もなく追加されます。）
開始するには、エージェントを適切なバージョンに更新するだけです。（下位互換性については後で説明します。）
ここからは、New Relicプラットフォーム内での分散トレーシングと可観測性における標準化の意味について説明しましょう。
今日の分散トレーシングの問題
すべての分散トレーシングツールは、パフォーマンスを特定し診断するために必要な他の情報と一緒に、トレースの各ステップを正しい順序で「相関」させる方法を必要とします。これには以下が含まれます。
- トレース全体に一意な ID を割り当てる
- トレースの各ステップに一意の ID を割り当てる
- そのコンテキスト情報を HTTP ヘッダのセットとしてエンコードする
- トレースがアプリケーション環境を通過する際に、ヘッダとエンコードされたコンテキストを 1 つのサービスから次のサービスに渡す (または伝播する)
詳細について、トレースの定義を確認し、New Relicの分散トレーシングについてもご覧ください。
以前は、分散トレーシングツールはそれぞれ独自のカスタムヘッダーとコンテキストフォーマットを使用していました。例えば、ZipkinではB3フォーマットを使用していましたが、New Relicでは独自のフォーマットを開発していました。これは、トレースコンテキストヘッダのほとんどが単一のトレースツールで監視されているサービス間を移動する場合や、ヘッダが単一の組織のネットワークやミドルウェアインフラストラクチャを超えて伝播することがほとんどない場合には問題にはなりませんでした。
そして、前述したように、今日では多くの開発チームが独自のトレースツールを使用していて、相互に互換性のないヘッダフォーマットを残していることが珍しくありません。トレースツールが、自分が理解できないトレースコンテキストヘッダを受信すると、通常はヘッダを削除するため、それに伴うトレースは途切れてしまいます。また、トレースコンテキストヘッダは、プロキシ、サービスメッシュ、メッセージングシステムなどのミドルウェアの境界を横断する可能性がこれまで以上に高くなっています。これらのデバイスの中には、プロプライエタリなヘッダをそのまま渡すものもありますが、ヘッダを落としてトレースが途切れてしまうものも多いです。
W3Cトレースコンテキスト：可観測性の障壁を打破する
W3C Trace Contextは、4つの重要なテレメトリータイプの1つであるトレースのベンダー間での相互運用を可能にします。これは、New RelicのオープンインストルメンテーションイニシアチブやAPI、Telemetry SDK、exporterのリリースと連動しており、ベンダーとオープンソースツール間の相互運用を求めるお客様のニーズに対応しています。
W3C Trace Contextは、New Relicの分散トレーシングツールが、他のベンダーのエージェントを使って計測されたサービスを、トレースが壊れるリスクなしにトレースしたり、プロキシやAPIゲートウェイなどのサードパーティコンポーネントを確実にトレースしたりできるようにするための有用かつ重要な方法です。同時に、W3C Trace Context はオープンソースのトレーサーにも同じ利点を与え、お客様はいつでも、あらゆるソースからのトレースされたテレメトリーを組み込むことができ、高度に分散されたアプリケーション環境に渡ってトレースを実装することができます。これにより、Trace Context はオブザーバビリティの将来にとって重要であり非常に歓迎すべき技術となります。
機能的には、W3C Trace Context は、サービス間のコンテキスト相関情報を伝播するための標準化されたコンテキスト HTTP ヘッダのペアを定義しています。
traceparentヘッダには、すべての分散トレーシングモデルがコンテキストを定義して伝播するのに必要な、トレースID、親ID、サンプルフラグと言ったデータ要素を含んでいます。tracestateヘッダは、ベンダー固有のコンテキストデータを保持しますが、これは通常特定のトレースツールに関連した追加機能や最適化をサポートするために使われます。
この共通のコンテキスト伝搬のフォーマットは、標準に準拠した他のトレース計測ツールでのトレース伝搬を可能にします。また、標準のトレースヘッダフォーマットは、ミドルウェアベンダがトレースヘッダの伝搬をサポートしたり、フレームワークベンダがトレース計測ツールを組み込んだりする際の障壁を取り除きます。
サービスのインストルメンテーションにNew Relicエージェント以外のツールを使用する必要がある場合やそうしたい場合でも、当社のプラットフォームでトレースを取得したい場合があるでしょう。そうできるように、ほとんどのベンダーやオープンソースのインストルメンテーションツールがW3C Trace Contextをサポートしていると見込んでいます。OpenTelemetryは、業界全体の可観測性に必要な計測ツールを標準化する上で、最も重要なゲームチェンジャーの一つとなっています。
標準が成熟するにつれ、他のヘッダフォーマットを使用しているトレーサーや計測ツールはすべて W3C Trace Context を採用し、既存の計測ツールを W3C Trace Context に変換してマルチベンダートレースに参加できるようにするためのツールやシムが増えていくことを期待しています。
最終的には、より柔軟性が増し、可観測性の障壁が減ることになるでしょう。
New RelicでのW3Cトレースコンテキストの動作
New Relic プラットフォーム上でW3C Trace Context が どのように動作するかについては、2 つのシナリオがあります。
- シナリオ1：一部分のトレースデータがNew Relicに送信される場合
- シナリオ2：すべてのトレースデータがNew Relicに送信される場合
両方を見てみましょう。
シナリオ1：一部分のトレースデータがNew Relicに送信される場合
トレースデータがすべてNew Relicに送られている場合、分散トレーシングUIで完全なエンドツーエンドのトレースを観察することができます。しかし、トレースデータの一部が別のトレースサービスに送られていたり、どこにも送られていない場合は、そのデータを探すためにあちこち探し回る必要があるかもしれません。しかし、W3C Trace Context を使用すると、トレース ID を使用して、そのトレースに関連する他のデータを見つけることができます。
たとえば、上記のようなシナリオでは、おそらくスパンが欠落しているトレースがあります。New Relicの分散トレーシングUIはトレースにギャップがあることを示しますが、周囲のスパンを使用して、トレースの合計時間を計算したり、他のトラブルシューティングを実行したりできます。
シナリオ2：すべてのトレースデータがNew Relicに送信される場合
オープンソースのトレーサーを使用していて、そのトレースをNew Relicに送信したい場合のために、New RelicはOpenCensusやOpenTelemetryなどの一般的なオープンソースのモニタリングツール用のエクスポートツールを作成しました。エクスポータはTelemetry SDKを使用して作成しました。これはオープンソースのAPIクライアントライブラリ集で、トレースデータをNew Relicプラットフォームに送信するためのものです。
このシナリオでは、Service 2 のトレースデータを収集している OpenTelemetry トレーサー用のエクスポーターを使用して、他のエクスポーターの使用をやめることなく、そのデータを New Relic に送信することができます。
エクスポーターがNew Relicに完全なトレースのデータを持つことを許可する呼び出しフローの例。
下位互換性はどのように機能しますか？
W3C Trace Context をサポートする New Relic APM エージェントは、W3C Trace Context ヘッダー形式と New Relic ヘッダー形式の両方を受け入れて出力することができます。この新しいエージェントは後方互換性もあります。つまり、古いエージェントと共存しても引き続き動作するため、トレースコンテキストは古いリリースのNew Relicエージェントと新しいリリースのNew Relicエージェントのサービス間で伝搬されます。
場合によっては、トレースに関与するサービスが New Relic エージェント以外のものでインスツルメンテーションされていることもあるでしょう。その計測ツールが W3C Trace Context に準拠している限り、トレースの一部として W3C Trace Context をサポートしている New Relic エージェントのバージョンを使用することができ、トレースが確実に伝搬されることを保証します。
古いNew Relicエージェントと新しいNew Relicエージェントが混在しているトレースや、W3C Trace Contextに準拠しているNew Relic以外のインストゥルメンテーションを使用している場合でも、トレースは伝搬されます。W3C Trace Context に準拠した New Relic エージェントが、W3C Trace Context 以前の New Relic エージェントに隣接していることを確認するだけです。W3C Trace Context をサポートする New Relic エージェントは、New Relic プロプライエタリなトレースコンテキストの「トランスレータ」として機能します。
例えば、このトレースには OpenTelemetry エージェント、W3C 準拠のエージェント、非準拠のエージェントが含まれていますが、依然としてトレースコンテキストは伝搬されています:
New Relicエージェントは常にW3Cトレースヘッダフォーマットを受け入れて送信します。オプションとして、エージェントの設定ファイルでNew Relicトレースヘッダフォーマットを無効にすることができます。New Relicフォーマットを無効にする方法についてはドキュメントを参照してください。
また、下位互換性の詳細と制限については、New Relicの分散トレーシングのドキュメントを参照してください。
単なる別の退屈なプロトコル以上のものとして
我々は、W3C Distributed Tracing Working Groupの一員として、業界全体の同僚と密接に協力して、この仕様を最終的な批准に至るまで導いてきました。私たちは皆、この仕様を実装できることを非常に楽しみにしています。
New RelicはW3Cグループにコミットしており、今後もオープンスタンダードとシームレスに連携する快適なインストルメンテーションソリューションを提供していきます。また、分散トレーシングのユースケースのサポートを追加し、ユーザーがDevOpsのライフサイクル全体を通して可観測性を向上させることができるようにしていきます。
それまでの間、W3C Trace Context とオープンソースのエクスポート機能をどのように活用しているのか、皆様からのご意見をお待ちしています。GitHubにあるエクスポータの仕様レポジトリにメッセージを送ってください。
エージェントをアップグレードして、今すぐオープンな New Relic One プラットフォームを使い始めましょう
観測可能性のためにオープンで接続されたプログラム可能なプラットフォームが必要な理由について、もっと知りたい方はこちらまで。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
