論文メモ Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
January 23, 2021分散トレーシングシステムDapperをGoogle社内で開発、デプロイ、運用した知見がまとめられている。 運用期間は2年にわたる。 Dapperをもとに、TwitterはZipkinを、UberはJaegerを開発した。 Dapper以前に開発されたMagpieやX-Traceとの違いは、サンプリングされたリクエストのみをトレースし負荷を下げるられたり、少数の共通ライブラリだけを測定対象したりする点にある。
一般に、トレーシングの実現手段は、アノテーションを使うかどうか大別できる。 アノテーションを使わない場合、リクエストの相関関係を回帰分析で推定しトレースを見つける。 トレースの検出精度を上げるには多くのリクエストが必要になる。 アノテーションを使う場合、コードを修正しなければならないが、開発者がトレースの精度を保証できる。
Dapperは前者の手法をとり、アノテーションによるトレーシングの機能はオプションの位置にある。 Google社におけるトレーシング対象の分散システムは、サブシステム間で共通のスレッドモデル、制御フロー、RPCライブラリを使用している。 Dapperは、このサブシステム間の共通性を仮定し、これらのライブラリに限定してトレースを収集する。 測定範囲を限定することで、アノテーションを不要にし、測定のオーバーヘッドを抑える。
スレッドがトレース対象のリクエストを処理するとき、Dapperは、スレッドのローカルストレージにトレース情報を保存する。 トレース情報には、トレースやサブシステムでの経過時間に対するIDなどが含まれる。 この情報をtrace contextという。 スレッドが非同期にリクエストを処理するときは、Dapperは、リクエストを受けたスレッドから、コールバックのスレッドに、trace contextを伝達する。 trace contextは、RPCを介してサブシステム間で伝達される。 なお、W3CはHTTPによる分散トレーシングのためのtrace contextの規格のドラフトを発表している。
論文をこちらからダウンロードできます。