traceとは何か? 分散リクエストトレーシングの解説

traceは、単一のリクエストや操作がシステムのコンポーネントを移動する際の全行程を記録し、個々のspanから縫い合わされます。

多くのサービスから成るシステムでは、単一のユーザー操作がその十数個に触れることがあります。traceはその一つの操作を最後まで追い、時間がどこで費やされ、エラーがどこで発生したかを示します。tracingは、metricやlogだけでは各部分がどうつながるかを示せない分散システムのために特に構築されたオブザーバビリティのシグナルです。

traceが表すもの

traceは、一つのリクエストがシステムを伝播する際の完全な記録です。エントリポイントで始まり、すべてのdownstreamの呼び出しを追い、各ホップでタイミングと結果を捕捉します。その結果は、何が、どの順序で起き、各部分がどれだけかかったかを正確に示す操作のツリーです。

traceはspanから成る

trace内の各作業単位はspanです。データベースクエリやHTTP呼び出しのような、名前付きで時間の計られた操作です。spanはネストして親子ツリーを形成し、trace IDを共有するため、一つの絵に組み立てられます。したがってtraceは、そのIDを共有するすべてのspanの集まりです。

コンテキスト伝播

tracingが機能するのは、各サービスがtraceのコンテキスト(通常はtrace IDと親のspan ID)を、呼び出す次のサービスへ、通常はリクエストヘッダーで渡すからです。この伝播が、traceがプロセスやネットワークの境界を越え、切り離された断片ではなく一つの一貫した記録であり続けることを可能にします。

traceが明らかにすること

traceは、レイテンシやエラーが実際にどこで発生するかを見つけるのに優れています。全体として遅いリクエストは、一つのdownstreamの呼び出しを待っているのかもしれません。traceはそれがどれかを示します。flame graphとして可視化されると、traceはクリティカルパスを明白にし、調査をボトルネックへ直接向けます。

CI/CDにおけるtrace

同じ考えがpipelineに適用されます。pipelineの実行をtraceとして、各jobやステップをspanとしてモデル化すると、buildが実時間をどこで費やすかのflame graphビューが得られます。それにより、遅いpipelineが一つのステージ、キュー時間、あるいは積み重なる多くの小さなステップのいずれに支配されているかが明らかになります。

重要なポイント

traceは、サービスをまたぐ一つのリクエストをend-to-endで記録します。
trace IDを共有するネストされたspanから組み立てられます。
コンテキスト伝播により、traceがプロセス境界を越えられます。
pipelineをtraceして、build時間がどこへ行くかを明らかにできます。