観測できないものは直せない — 分散トレーシングの現在
要点
- 分散トレーシングは、一つのリクエストが複数のサービスをまたぐ経路を一本の線として追える仕組みである。
- 2010年のGoogleの論文「Dapper」が、この分野の実務的な土台を作った。
- CNCFのOpenTelemetryは、計測の方法をベンダー横断で標準化しようとする動きである。
- ただし計測には負荷とコストが伴い、すべてを記録するのではなく標本化が前提になる。
「観測できないものは直せない」。運用の世界でしばしば口にされるこの言葉は、分散システムの時代にいっそう重みを増した。一つの画面表示の裏で、十も二十ものサービスが連鎖して呼び出される構造では、どこで遅延が生まれたかを、もはや勘では特定できない。背景で何が起きているかを見えるようにする——その営みの中心にあるのが分散トレーシングだ。
一本の線として追う
単一のプログラムなら、処理を上から下へたどれば原因に行き着く。だが処理が複数のサービスに分かれ、ネットワーク越しに呼び合うようになると、その線は途切れる。あるサービスのログを見ても、その手前と後ろで何が起きていたかは別のログにある。全体像が、誰の手元にも揃わない。
分散トレーシングは、リクエストに一意の識別子を付け、それを通過する各サービスへ引き継がせることで、ばらばらのログを一本の線につなぎ直す。これにより、ある画面が遅かったとき、その遅延が決済サービスで生まれたのか、在庫サービスで生まれたのかを、経路として可視化できる。これは自動化された流れが失敗したときに「どこで止まったか」を追う課題と、同じ根を持つ。
Dapperという起点
この分野の実務的な出発点は、2010年にSigelmanらが発表したGoogleの論文「Dapper」にある。同論文は、巨大な分散システムを運用するなかで、リクエストの経路を低い負荷で追跡する仕組みをどう設計したかを記述した。重要だったのは、計測のためにアプリケーションのコードを大幅に書き換えずに済ませる、という現実への配慮である。
Dapperが後続に与えた影響は大きい。今日広く使われるトレーシングの語彙——リクエスト全体を表すトレース、その中の個々の処理区間を表すスパン——の多くは、この系譜に連なっている。背景を見えるようにする道具立てが、ここで形を得た。
標準化への動き
もっとも、計測の方法がベンダーごとにばらばらでは、道具を乗り換えるたびにコードを書き直すことになる。この摩擦を減らそうとするのが、CNCF（Cloud Native Computing Foundation）のOpenTelemetryである。計測のためのAPIとデータ形式を共通化し、どの監視製品にもデータを送れるようにする。観測の語彙を、特定の製品から切り離す試みだ。
一方で、標準化は万能の解ではない。共通化された枠組みは、最大公約数になりがちで、個別製品の細やかな機能を取りこぼすこともある。それでも、観測の土台が一社に縛られないことの価値は大きい。乗り換えの自由は、長く運用するシステムにとって保険になる。
すべては記録できない
分散トレーシングには、見落とされがちな代償がある。すべてのリクエストの経路を漏れなく記録すれば、その記録自体が膨大な負荷とコストを生む。背景を見るための計測が、背景を重くしては本末転倒だ。だから現実には、一定の割合だけを抽出して記録する標本化が前提になる。
ここに観測の逆説がある。見えるようにするほど、見ることのコストが増える。何を記録し、何を捨てるかという判断が、運用の質を左右する。観測できないものは直せない。だが、すべてを観測しようとすれば、観測そのものが新たな問題になる。分散トレーシングが教えるのは、可視性とは無償ではなく、どこに光を当てるかを選び続ける営みだ、ということである。
出典
- Sigelman et al.「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」（Google, 2010年）
- OpenTelemetry（CNCF）公式ドキュメント