分散トレーシング（ぶんさんトレーシング、）は、複数のサービスやサーバーにまたがって処理される1つのリクエストが、どの経路をたどり、どこでどれだけの時間を要したかを1本の記録として追跡する手法である。マイクロサービスのように処理が多数のサービスへ分散する構成では、リクエストはさまざまなサービスを通過して完了し、その記録はコンテナやサーバーレス環境などさまざまな場所に分かれて存在しうる。分散トレーシングは、リクエストごとに共通の識別子を与えてサービス間で引き回し、分散した処理の記録を1本の流れとして再構成することで、「分散トランザクションのどこで何が起きたか」を理解できるようにする。オブザーバビリティ（可観測性）を支えるログ・メトリクス・トレースの3本柱のうち、トレースに相当する。2010年にGoogleが公表した論文「Dapper」を出発点として発展し、現在はOpenTelemetryやW3Cの仕様によって標準化が進んでいる。
仕組み トレースとスパン トレースは、リクエストがアプリケーションの中をたどる経路の全体を表すデータであり、その構成単位をスパンと呼ぶ。1つのスパンはデータベースへの問い合わせや他サービスの呼び出しといった1区間の処理を表し、名前・開始と終了の時刻・親スパンの識別子などを持つ。親を持たない最初のスパンはルートスパンと呼ばれ、処理全体の始点と終点を示す。スパンは入れ子にできるため、1つのトレースはスパンの親子関係からなる木構造として構成される。各スパンには属性を付加でき、たとえばeコマースのシステムで買い物かごに商品を追加する操作のスパンには、利用者のID・商品のID・かごのIDを記録できる。
コンテキスト伝播 サービスをまたいで1本のトレースを組み立てるには、ある処理がどのトレースのどのスパンの続きであるかという情報（コンテキスト）を呼び出し先へ引き渡す必要がある。この仕組みをコンテキスト伝播（context propagation）と呼び、プロセスやネットワークの境界を越えて因果関係の情報を構築する役割を担う。実装上は、トレースIDとスパンIDをHTTPヘッダーなどのメタデータに載せて転送する。
このヘッダーの形式はWorld Wide Web Consortium（W3C）が「Trace Context」として標準化し、traceparentとtracestateの2つを定義している。2020年2月6日にW3C勧告となり、2021年11月23日に編集上の更新を反映した版が勧告となった。OpenTelemetryの既定の伝播方式もこの仕様に従う。
サンプリング すべてのリクエストのトレースを保存するとデータ量と費用が大きくなるため、実運用では一部だけを記録するサンプリングが併用される。記録の可否を処理の開始時点で決める方式は簡便で効率的とされ、処理の完了後に内容を見て決める方式はエラーや異常に遅いトレースを選んで残せる。商用サービスでも抽出率の制御機能が提供されている。
歴史 2010年、Googleは社内の大規模な分散トレーシング基盤に関する論文「Dapper」を公表し、後の分散トレーシングツールの設計に影響を与えた。2012年、TwitterはDapper論文の基本部分を実装したZipkinをオープンソースとして公開した。2015年にUberが開発したJaegerは、2017年9月にCloud Native Computing Foundation（CNCF）の育成段階のプロジェクトとなり、2019年10月にはKubernetes・Prometheusなどに続く7番目の卒業プロジェクトとなった。
アプリケーションに計測用のコードを組み込む作業（計装）の標準化では、トレース用APIを定めるOpenTracing（2016年10月にCNCF参加）と、Googleの計測ライブラリから生まれたOpenCensus（2018年1月にオープンソース公開）が並立し、開発者にどちらを選ぶべきかという混乱が生じていた。両者は2019年5月に統合されてOpenTelemetryとして発足し、特定の監視製品に依存しない計装が可能になった。
活用 主な用途は次の3つである。
障害の切り分け — 経路上の各サービスでの処理結果が1本のトレースに記録されるため、どのサービスのどの呼び出しで失敗したのかを特定できる。トレースをログやメトリクスと関連付けて根本原因の特定を早める運用も行われる。 ボトルネックの特定 — 各スパンが所要時間を持つため、応答が遅い原因となっている区間を見つけられる。一部のリクエストだけが他より時間を要する理由や、遅延が時間とともに増えているかどうかを調べる用途に用いられる。 サービス間の依存関係の可視化 — 収集したトレースから、どのサービスがどのサービスを呼び出しているかを図として描き出せる。Amazon Web ServicesのX-Rayはこれをトレースマップと呼び、ボトルネックや遅延の急増の発見に用いると説明している。
Kubernetesなどのコンテナ環境では、処理を担う実体がオートスケールによって動的に増減するため、リクエストの追跡はいっそう難しくなる。
主なツール・サービス オープンソースでは、Zipkinがトレースデータの収集・保存・検索と経路の可視化を行い、JaegerがCNCFの卒業プロジェクトとして開発されている。大規模向けのトレース保存基盤であるGrafana Tempoは、トレースの検索やスパンからのメトリクス生成に対応する。OpenTelemetryは特定製品に依存しない計装の枠組みで、これらの基盤や商用サービスへトレースを送出できる。
商用では次のようなサービスがある。
Datadog APM — ブラウザやモバイルアプリからバックエンドのサービス・データベースまでを対象とした分散トレーシングを提供する。 New Relic — 分散システムを通過するリクエストの追跡と監視を行う。 Dynatrace — 分散トレースの取得と分析の機能を提供する。 AWS X-Ray — Amazon Web Servicesのサービス。リクエストのデータを収集してトレースマップを生成する。 Google Cloud Trace — Google Cloudのサービス。受信リクエストの処理時間や、処理中に実行された操作の所要時間を計測する。
脚注
参考文献
関連項目 オブザーバビリティ OpenTelemetry アプリケーション性能管理 AIOps マイクロサービス