分散トレースシステムは、複数のアプリケーション、サービス、データベース、そしてプロキシなどのミドルウェアをまたぐリクエストを、最初から最後までトレースできます。これにより、システム内で何が起こっているかをより深く理解することができます。トレースシステムは、既知の各ステップと、各ステップにおけるリクエストの所要時間をグラフィカルに表示します。 ユーザーはこれらの表示を使用して、システムのどの部分で遅延や障害が発生しているかを判断できます。リクエストが失敗した場合、運用担当者と開発担当者は、バイナリ探索木などを用いて問題箇所を特定するなど、システム全体をテストすることなく、問題の原因を正確に特定できます。開発の反復作業においては、追跡システムはパフォーマンスの変化を引き起こす可能性のある潜在的な要因も特定できます。異常な動作の警告を通じてパフォーマンスの低下を自動的に検出することは、顧客から指摘されるよりも常に効果的です。 このトラッキングはどのように機能しますか？各リクエストには一意のIDが割り当てられ、通常はリクエストヘッダーに挿入されます。このIDは対応するトランザクションを一意に識別します。トランザクションは一般的に…と呼ばれます。トレース「痕跡」とは、物質全体を表す抽象的な概念です。それぞれの「痕跡」は…で構成されています。ユニット「ユニット」とは、サービス呼び出しやデータベースリクエストなど、リクエスト内で実行される実際の操作を表すコンポーネントです。各「ユニット」には固有のIDが付与されます。「ユニット」の下にサブユニットを作成でき、サブユニットは複数の親「ユニット」を持つことができます。 トランザクション（またはトレース）が実行されると、トレースシステムのプレゼンテーション層で検索できます。プレゼンテーション層として使用できるツールはいくつかあり、後ほど詳しく説明しますが、まずは次の図をご覧ください。これは、Istioウォークスルーのビデオチュートリアルで紹介したJaegerインターフェースで、1つのトレース内に複数のユニットが表示されています。この図を見れば、トランザクションをより明確かつ深く理解できることがわかります。 このデモではIstioに組み込まれたOpenTracing実装を使用しているため、トレースデータを取得するためにアプリケーションコードを変更する必要さえありませんでした。また、OpenTracingと互換性のあるJaegerも使用しました。 では、OpenTracing とは一体何でしょうか? 詳しく見てみましょう。 オープントレーシングAPIZipkinから派生した仕様であるOpenTracingは、クロスプラットフォームの互換性を実現することを目的としています。アプリケーションにトレース機能を追加し、トレースデータを分散トレースシステムに送信するためのベンダー中立的なAPIを提供しています。OpenTracing仕様に従って作成されたライブラリは、OpenTracing対応のあらゆるシステムで使用できます。この標準を採用しているオープンソースツールには、Zipkin、Jaeger、Appdashなどがあります。DatadogやInstanaといった有料ツールもOpenTracingを使用しています。OpenTracingの普及を考えると、この傾向は今後も続くと予想されます。 オープンセンサスOpenTracingについては既に説明しましたが、OpenCensusとは一体何でしょうか？検索結果によく出てきますが、これはOpenTracingとは全く異なる規格なのでしょうか、それとも補完的な競合規格なのでしょうか？ この質問への答えは、誰に質問するかによって異なります。まずは私の理解の範囲内で違いを説明しましょう。OpenCensusはより包括的、あるいはむしろすべてを網羅しています。OpenTracingは、あらゆるプログラミング言語やトレースシステムにオープンな実装を提供するのではなく、オープンAPIと仕様の構築に重点を置いています。OpenCensusは仕様だけでなく、プログラミング言語や接続プロトコルの実装も提供しています。さらに、単なるトレース機能にとどまらず、分散トレースシステムでは一般的にカバーされていない追加のメトリクスも導入しています。 OpenCensusを使用すると、アプリケーションを実行しているホスト上のトレースデータを表示できるだけでなく、中央アグリゲータにデータをエクスポートするためのプラグ可能なエクスポーターシステムも備えています。現在、OpenCensusチームが提供するエクスポーターには、Zipkin、Prometheus、Jaeger、Stackdriver、Datadog、SignalFxなどがありますが、誰でもエクスポーターを作成できます。 私の意見では、両者には多くの共通点があり、どちらが優れているというわけではありません。重要なのは、それぞれが何を行い、何を行わないかを理解することです。OpenTracingは主に仕様であり、具体的な実装や任意の設計は他者が担当します。OpenCensusは、ローカルコンポーネントに対してより任意で包括的なソリューションを提供しますが、他のシステムからのリモート集約は依然として必要です。 オプションツールジプキンZipkinは、この種のツールとしては最も初期のものの一つでした。Googleは2010年に自社のトレースシステムであるDapperを紹介する論文を発表し、Twitterはこれを基盤としてZipkinを開発しました。ZipkinはJavaで開発されており、スケーラブルなストレージバックエンドとしてCassandraまたはElasticsearchを採用しています。これらのオプションは、ほとんどの企業のニーズを満たすものです。ZipkinはJava 6をサポートし、Twitterのシステムで普及しているThriftバイナリ通信プロトコルも採用しています。Thriftは現在Apacheプロジェクトとしてホストされています。 このシステムは、レポーター（クライアント）、データコレクター、クエリサービス、そしてウェブインターフェースで構成されています。Zipkinは、トレースの進行状況を受信者に通知するために、トランザクションコンテキストを含むトレースIDのみを送信するため、本番環境でも安全に使用できます。各クライアントによって収集されたデータは、非同期的にデータコレクターに送信されます。コレクターはこれらのデータユニットをデータベースに保存し、ウェブインターフェースは、このデータをユーザーにとって使いやすい形式で表示します。クライアントは、HTTP、Kafka、Scribeの3つの方法でコレクターにデータを送信できます。 Zipkinコミュニティは、Zipkinと互換性のあるJavaクライアント実装であるBraveも提供しています。Braveは依存関係がないため、プロジェクトの速度が低下したり、社内標準と互換性のないライブラリで煩雑になったりすることはありません。Brave以外にも、多くのZipkinクライアント実装があります。ZipkinはOpenTracing標準と互換性があるため、これらの実装は他の分散トレースシステムでも使用できます。Springフレームワークの人気分散トレースコンポーネントであるSpring Cloud Sleuthは、Zipkinと互換性があります。 イェーガーUber発のJaegerは比較的新しいプロジェクトで、CNCF（Cloud Native Computing Foundation）がインキュベータとしてホストしています。JaegerはGo言語で開発されているため、サーバーへの依存関係のインストールや、開発言語に対応したインタープリタや仮想マシンのオーバーヘッドを心配する必要はありません。Zipkinと同様に、JaegerはCassandraとElasticsearchを使用したスケーラブルなストレージバックエンドもサポートしています。また、JaegerはOpenTracing標準にも完全に準拠しています。 JaegerのアーキテクチャはZipkinに似ており、クライアント（レポーター）、データコレクター、クエリサービス、そしてウェブインターフェースを備えています。ただし、各サーバー上で実行されるプロキシも含まれており、ローカルデータの集約を担います。プロキシはUDP接続を介してデータを受信し、バッチ処理を行ってデータコレクターに送信します。コレクターはThrift形式でデータを受信し、CassandraまたはElasticsearchに保存します。クエリサービスはデータベースに直接アクセスし、必要な情報をウェブインターフェースに提供します。 デフォルトでは、Jaeger クライアントはすべての追跡データを収集せず、データの 0.1% (1000 分の 1) のみをサンプリングします。ほとんどのシステムでは、すべての追跡データを保持して送信するのは多すぎるでしょう。ただし、この値はエージェントの設定によって調整でき、クライアントはエージェントから設定を取得します。このサンプリングは完全にランダムではなく、改善されています。Jaeger は確率的サンプリングを使用して、新しいトラックをサンプリングするかどうかを推測します。適応型サンプリングはすでにロードマップに含まれており、意思決定に役立つ追加のコンテキストを追加することで、サンプリングアルゴリズムを改善します。 アプリダッシュAppdashもJaegerと同様にGo言語で書かれた分散トレースシステムです。Appdashは、GoogleのDapperとTwitterのZipkinをベースにSourcegraphによって開発されました。Appdashと同様にOpentracing標準をサポートしていますが、これは後から追加されたものであり、デフォルトのコンポーネントとは異なるコンポーネントに依存しているため、リスクと複雑さが増しています。 Appdashのアーキテクチャは、大まかに言えば、クライアント、ローカルコレクター、リモートコレクターの3つの部分から構成されています。ドキュメントが限られているため、このアーキテクチャの説明はシステムテストとソースコードレビューに基づいています。コードを記述する際には、Appdashクライアントを追加する必要があります。AppdashはPython、Golang、Rubyの実装を提供していますが、OpenTracingライブラリはAppdashのOpenTracing実装で使用できます。クライアントはセルデータを収集し、ローカルコレクターに送信します。ローカルコレクターはデータを中央のAppdashサーバーに送信します。中央のAppdashサーバーは独自のローカルコレクターを実行し、このローカルコレクターは他のすべてのノードのリモートコレクターとして機能します。 |
