分散追跡システムの4つの機能モジュールがどのように連携するか

[[313778]]

分散トレースにおける主要なアーキテクチャ上の決定と、各要素がどのように組み合わされるかについて学習します。

10 年前まで、分散トレースを真剣に研究していたのは、基本的に学者と大手インターネット企業の少数の人々だけでした。マイクロサービスは、今や、それを採用するあらゆる組織にとって必須の要件となっています。その理由は十分に立証されています。マイクロサービスは予期せず失敗することが多く、分散トレースはそれらの失敗を記述して診断する最良の方法だからです。

とはいえ、分散トレースを自分のアプリケーションに統合し始めると、人によって「分散トレース分散トレース” は異なる意味を持ちます。さらに、トレース エコシステムには、類似した機能を実行する重複するプロジェクトが多数存在します。この記事では、分散トレース システム内の 4 つの (潜在的に) 独立した機能ブロックを紹介し、それらがどのように連携するかについて説明します。

分散トレース: メンタルモデル

追跡に使用されるメンタルモデルのほとんどは、Google の Dapper 論文から来ています。 OpenTracing でも同様の用語が使用されているため、このプロジェクトから次の用語を借用します。

トレース

• 追跡トレース: 分散システム内で物事が実行されるプロセスの説明。
• スパンスパン: ワークフローの一部を表す、名前が付けられたスケジュールされたアクション。スパンは、キーと値のタグだけでなく、特定のスパンのインスタンスに添付されたきめ細かいタイムスタンプ付きの構造化ログも受け入れることができます。
• スパンコンテキストスパンコンテキスト: ネットワークまたはメッセージ バスを介してサービスからサービスに渡されるものも含め、分散トランザクションのトレース情報を伝送します。スパン コンテキストには、トレース識別子、スパン識別子、およびトレース システムが下流のサービスに伝播するために必要なその他のデータが含まれます。

この考え方の詳細を知りたい場合は、OpenTracing の技術仕様を参照してください。

4つの機能モジュール

アプリケーション層分散トレース システムの観点から見ると、最新のソフトウェア システム アーキテクチャは次のようになります。

トレース

現代のソフトウェア システムのコンポーネントは、次の 3 つのカテゴリに分類できます。

• アプリケーションとビジネス ロジック: コード。
• 広く共有されているライブラリ: 他の人のコード
• 広く共有されるサービス：他者のインフラ

これら 3 つのカテゴリのコンポーネントには、監視アプリケーション用の分散トレース システムの設計を推進するさまざまな要件があります。最終的なデザインは、次の 4 つの重要な部分で構成されました。

• 追跡および検出APIトレース計測API : アプリケーションコードを装飾する
• ラインプロトコルワイヤープロトコル: RPC リクエストでアプリケーションデータと一緒に送信するためのルール
• データプロトコルデータプロトコル: 分析システムに非同期情報（帯域外）を送信するためのプロビジョニング
• 分析システム分析システム: 追跡データを処理するためのデータベースとインタラクティブなユーザーインターフェイス

このコンセプトをより深く説明するために、この設計を推進する詳細を掘り下げていきます。私からのアドバイスが欲しいだけなら、以下の上位 4 つの解決策に進んでください。

要件、詳細、説明

アプリケーション コード、共有ライブラリ、共有サービスの動作は大きく異なるため、それらをインストルメントする要求の動作に大きな影響を与えます。

アプリケーションコードとビジネスロジックを計測する

特定のマイクロサービスでは、マイクロサービス開発者が記述するコードの大部分はアプリケーションまたはビジネス ロジックです。コードのこのセクションでは、特定の領域の操作を指定します。通常、これには、そもそも新しいタイプのマイクロサービスの作成を正当化する、特別な独自のロジックが含まれます。ほぼ定義上、このコードは通常、複数のサービス間で共有されることはありません。

つまり、それについてまだ知っておく必要があり、何らかの方法でそれを検出する必要もあるということです。一部の監視・追跡分析システムでは、ブラックボックスプロキシブラックボックスエージェント一部のシステムではコードを自動的にインストルメンテーションしますが、他のシステムでは明示的なホワイトボックス インストルメンテーション ツールを使用することを好みます。後者の場合、トレース API を抽象化すると、マイクロサービス アプリケーション コードにとってより実用的ないくつかの利点が得られます。

• 抽象 API を使用すると、インストルメンテーション コードを書き直すことなく、新しい監視ツールに切り替えることができます。クラウド サービス プロバイダー、ベンダー、監視テクノロジを変更する必要がある場合もありますが、移植性のないインストルメンテーション コードが大量に存在すると、プロセスに大きなオーバーヘッドと手間がかかります。
• このツールには、生産監視以外にも興味深い用途があることがわかりました。既存のプロジェクトでは、同じトレース ツールを使用して、テスト ツール、分散デバッガー、「カオス エンジニアリング」フォールト インジェクター、およびその他のメタアプリケーションを駆動します。
• しかし、もっと重要なのは、アプリケーション コンポーネントを共有ライブラリに抽出するとどうなるかということです。上記の内容から、次のことが結論付けられます。

共有ライブラリの検出

ほとんどのアプリケーションに表示されるユーティリティ コード (ネットワーク要求、データベース呼び出し、ディスク書き込み、スレッド、同時実行管理などの処理) は通常、一般的なものであり、特定のアプリケーションに固有のものではありません。このコードはライブラリとフレームワークにパッケージ化され、多くのマイクロサービスにロードされ、さまざまな環境にデプロイできます。

実際の違いは、コードを共有すると他の人がユーザーになるという点です。ほとんどのユーザーは、依存関係や操作スタイルが異なります。この共有コードを使用しようとすると、いくつかの一般的な問題に気付くでしょう。

• テストを書くには API が必要です。ただし、ライブラリにはどの分析システムを使用しているかはわかりません。選択肢は複数あり、同じアプリケーションで実行されるすべてのライブラリは互換性のない選択を行うことはできません。
• これらのパッケージはすべてのネットワーク処理コードをカプセル化するため、リクエスト ヘッダーからスパン コンテキストを挿入および抽出するタスクは、多くの場合、RPC ライブラリを指します。ただし、共有ライブラリは、各アプリケーションがどのトレース プロトコルを使用しているかを認識する必要があります。
• 最後に、競合する依存関係をユーザーに強制して使用させないようにする必要があります。ほとんどのユーザーは、依存関係や操作スタイルが異なります。 gRPC を使用する場合でも、バインドされる gRPC バージョンは同じですか?したがって、ライブラリにトレース用に同梱されている監視 API は依存関係がないものでなければなりません。

したがって、共有ライブラリ コードをインストルメント化するには、(a) 依存関係がなく、(b) ワイヤ プロトコルに依存せず、(c) 一般的なベンダーや分析システムで動作する抽象 API が要件となるはずです。

検出共有サービス

最後に、サービス全体 (またはマイクロサービスのコレクション) が十分に汎用的であるため、多くの独立したアプリケーションで使用できる場合もあります。これらの共有サービスは、キャッシュ サーバー、メッセージ キュー、データベースなど、サード パーティによってホストおよび管理されることがよくあります。

アプリケーション開発者の観点からは、共有サービスは本質的にブラック ボックスであることを理解することが非常に重要です。アプリケーション監視を共有サービスに挿入することはできません。それどころか、ホスティング サービスでは通常、独自の監視ソリューションが実行されます。

4つの解決策

したがって、抽象トレース API は、ライブラリがデータを出力し、スパン コンテキストを挿入/抽出するのに役立ちます。標準のワイヤ プロトコルはブラック ボックス サービスが相互に接続するのに役立ち、標準のデータ形式は個別の分析システムがデータを統合するのに役立ちま す。これらの問題に対する有望な解決策をいくつか見てみましょう。

トレース API: OpenTracing プロジェクト

ご覧のとおり、アプリケーション コードをインストルメント化するにはトレース API が必要です。このインストルメンテーションを、スパン コンテキストの挿入と抽出を実行するほとんどの共有ライブラリに拡張するには、API をいくつかの重要な方法で抽象化する必要があります。

OpenTracing プロジェクトは、主にライブラリ開発者の問題を解決することを目的としています。 OpenTracing は、ベンダーに依存しないトレース API であり、多くの監視システムから急速にサポートを獲得しています。つまり、ライブラリにネイティブの OpenTracing インストルメンテーションが組み込まれている場合、アプリケーションの起動時に監視システムが接続されると、トレースが自動的に開始されます。

個人的な話ですが、10 年以上にわたってオープンソース ソフトウェアの作成、リリース、運用に携わってきた者として、OpenTracing プロジェクトに取り組んで、この可観測性のパズルを最終的に解決できたことは非常に満足のいくことです。

API に加えて、OpenTracing プロジェクトでは計測機能のリストが継続的に管理されており、その一部はここで確認できます。リンターを寄稿したり、独自の OSS ライブラリをローカルでテストしたり、単に質問したりして参加したい場合は、Gitter で私たちに挨拶してください。

行プロトコル: HTTP ヘッダー トレース コンテキスト

監視システムを相互運用し、ある監視システムから別の監視システムに切り替える際の移行の問題を軽減するには、スパン コンテキストを伝播するための標準のワイヤ プロトコルが必要です。

w3c 分散トレース コンテキスト コミュニティ グループがこの標準に取り組んでいます。現在、標準 HTTP ヘッダーのセットの開発に重点が置かれています。仕様の最新ドラフトはここからご覧いただけます。グループについて質問がある場合は、メーリング リストと Gitter チャット ルームで回答を得ることができます。

（LCTT翻訳注：この記事はもともと2018年5月に公開されたもので、コミュニティは現在では異なる進歩を遂げている可能性があります）

データ プロトコル (まだです!!)

ブラック ボックス サービスの場合、追跡プログラムをインストールしたり、プログラムと対話したりすることが不可能な場合は、システムからデータをエクスポートするためのデータ プロトコルが必要です。

このデータ形式とプロトコルの開発は現在初期段階にあり、主に w3c 分散トレース コンテキスト ワーキング グループのコンテキストで行われています。標準データ スキーマでは、RPC 呼び出し、データベース ステートメントなどの高レベルの概念を定義することに特別な注意が払われます。これにより、トレース システムは利用可能なデータの種類について推測できるようになります。 OpenTracing プロジェクトも、一連の標準ラベルを定義することでこの問題に対処しています。この 2 つの取り組みを相乗的に機能させることが計画されています。

現時点では中間的な立場があることに注意してください。コンパイルやコード変更を行ないたくないアプリケーション開発者が操作する「ネットワーク デバイス」の場合、動的リンクによってこれを回避できます。主な例としては、Envoy や NGINX などのサービス メッシュとプロキシがあります。この場合、OpenTracing 互換のトレーサーを共有オブジェクトとしてコンパイルし、実行時に実行可能ファイルに動的にリンクすることができます。現在、C++ OpenTracing API がこのオプションを提供しています。 JAVA 用の OpenTracing トレーサー パーサーも開発中です。

これらのソリューションは、動的リンクをサポートし、アプリケーション開発者によって展開されるサービスに適しています。しかし、長期的には、標準データ プロトコルによって問題がより広範囲に解決される可能性があります。

分析システム: トレースデータから洞察を抽出するサービス

最後に、現在では十分な追跡および監視ソリューションが存在することを述べておく必要があります。 OpenTracing と互換性があることがわかっている監視システムのリストはここにありますが、他にも多くのオプションがあります。皆さんにはソリューションを研究することをお勧めします。また、ソリューションを比較する際に、この記事で紹介したフレームワークが役立つことを願っています。監視システムをその運用特性に基づいて評価することに加えて (UI とその機能が気に入るかどうかは言うまでもありません)、上記の 3 つの重要な側面、それらの相対的な重要性、そして興味のある追跡システムがそれらのソリューションをどのように提供するかを考慮してください。

結論は

結局のところ、各部分の重要性は、あなたが誰であるか、そしてどのようなシステムを構築しているかによって大きく異なります。たとえば、オープンソース ライブラリの作成者は OpenTracing API に非常に興味を持っていますが、サービス開発者はトレース コンテキスト仕様にもっと興味を持っています。ある部分が他の部分よりも重要であると言う場合、通常は「ある部分は他の部分よりも私にとって重要です」という意味になります。

しかし、事実は、分散トレースが現代のシステムを監視するために不可欠になっているということです。これらのシステムのブロックを構築する際には、「可能な限り分離する」という古いアプローチが依然として適用されます。分散監視システムのようなシステム間システムを構築する場合、柔軟性と前方互換性を維持するための最善の方法は、コンポーネントを明確に分離することです。

読んでいただきありがとうございます！これで、独自のアプリケーションに追跡サービスを実装する準備が整いました。ここでは、各部分が何について言及されているのか、またそれらがどのように連携するのかを理解するためのガイドを紹介します。