「なんだか遅い」と言われて調べたものの、ログを端から追っても原因にたどり着けなかった。そんな経験はありませんか。
つまずいているのは調べ方ではなく、見ている記録の形かもしれません。この記事では、サービスをまたいだ処理の「どこで時間を使ったのか」を見えるようにする分散トレーシングと、その標準になったOpenTelemetry(オープンテレメトリー)を、入社1〜3年目の方に向けて整理します。
先に結論です。分散トレーシングとは、1回のリクエストが通った経路と、区間ごとの所要時間を、1本の記録としてつなげて見る仕組みです。ログが「点」の記録なら、トレースは「線」の記録だと考えるとつかみやすくなります。
分散トレーシングとは?ログとの違いは「1本につながっているか」
分散トレーシングは、1回のリクエストを1本の線として記録する仕組みです。
ログは、アプリやシステムで起きた出来事を1件ずつ書き残したものです。1台のサーバーで完結する処理なら、それだけでも十分に追えます。ところが今のシステムは、Webサーバー・認証・データベース・外部APIと、いくつもの部品に分かれています。部品がそれぞれログを出すので、同じリクエストの記録が何台にも散らばってしまいます。
たとえば注文の登録に800ミリ秒かかったとします。ログを1台ずつ見ても、わかるのは「遅かった」ことだけです。トレースで見ると、認証に70ミリ秒、データベースの照会に550ミリ秒、画面の組み立てに90ミリ秒、というように区間ごとに分解されます。これはRustのアプリからAWSのX-Rayへトレースを送る事例でも示されている見方です(参考リンク1)。
宅配便の追跡番号を思い浮かべると近いかもしれません。荷物が今どの営業所にあり、どこで一晩止まっていたのかが、1つの番号で追える。あの感覚です。
つまりログは「何が起きたか」、トレースは「どこで時間を使ったか」を答えるものです。どちらかで置きかえられるものではなく、両方が要ります。
なぜOpenTelemetryが分散トレーシングの標準になったのか
OpenTelemetryが広がったのは、計測の作り方をそろえて、送り先をあとから選べるようにするためです。
監視の道具はいくつもあり、以前はそれぞれ専用の仕組みでアプリに計測を埋め込んでいました。道具を乗り換えるたびに、アプリのコードを書き直す羽目になります。OpenTelemetryは、その計測の部分を共通の規格にそろえる取り組みです。アプリ側は共通の形で記録を出し、どこへ送るかは設定で切り替えます。
実際にAWSでも、X-Ray専用のSDKとデーモンが2026年2月25日にメンテナンスモードへ入りました。公式のサポートタイムラインには、メンテナンスモードの期間中にAWSが出すのは「セキュリティ上の問題に対応するリリースのみ」で、新機能の追加は行われないと明記されています(執筆時点では、この期間の終了日は「N/A」＝未定として公開されています)(公式のサポートタイムライン／AWS Cloud Operations Blog)。特定のサービス専用ではなく、共通規格の側へ寄せていく流れです。
読み替えると、いま自分の現場でX-Ray専用のSDKを使っているなら、新しい機能はもう来ない前提で、OpenTelemetryへの移行を計画に入れておく時期だということです。AWSは移行ガイドを言語別に用意していて、X-Rayの用語(セグメント、サブセグメント)がOpenTelemetryの用語(スパン)にどう対応するかの対照表も公式に載っています。これから覚えるなら、止まるほうではなく残るほうから覚えたほうが得です。
新社会人にとっての利点は、覚えたことが無駄になりにくい点です。会社が使う監視ツールは、転職や案件の変更で簡単に変わります。共通規格の考え方を先に押さえておけば、道具が変わっても土台は残ります。
分散トレーシングの中身は「トレースID」と「スパン」
仕組みの中心にあるのは、次の3つです。
- トレースID: 1回のリクエストにつく通し番号。宅配便の追跡番号にあたる
- スパン: 区間1つ分の記録。開始と終了の時刻、名前を持つ
- 親子関係: そのスパンがどのスパンの中で起きたかを示す情報
別々のサーバーで動く処理を1本にまとめるには、同じ番号を持ち回るしかありません。HTTPのヘッダーに載せて次のサービスへ渡す、という地味な受け渡しがそれにあたります。
そしてこの引き回しは、思ったよりよく外れます。Go言語の例では、スパンはcontextという値に入って関数から関数へ渡ります。contextを渡さない呼び出しをすると、そこで生まれたスパンは親を見失い、別のトレースとして独り立ちしてしまいます。その結果、データベースの呼び出しだけが別トレースになり、「1リクエストで何本のSQLが走ったのか」が見えなくなります(参考リンク2)。
参考リンク2の記事では、ビルドのときにコードへフックを入れる方法と、処理の単位ごとに現在のスパンを覚えておく仕組みを組み合わせ、contextが無いときでも親子がつながるようにしています。裏を返せば、トレースが途中で切れているときは、たいてい引き回しのどこかが切れているということです。
分散トレーシングは「全部入れる」と続かない
ここからは、導入する側の視点で現実的な線引きを書きます。最初から全部の処理を計測しようとすると、たいてい続きません。理由は3つあります。保存の料金は送った量にほぼ比例すること、全リクエストを送るとデータが多すぎて逆に読めなくなること、そして計測用のコードが本体のコードを埋めてしまうことです。
そこで、順番として次の3つを基準にすると失敗しにくくなります。
- 入口と出口から入れる: 外から来るリクエストの受け口と、外への呼び出し(データベース・外部API)だけを先に計測する。時間の大半はこの境目で使われている
- サンプリングを最初に決める: 全部ではなく一定の割合だけを送る設定のこと。「通常は数%、エラーは必ず送る」といった決め方が現実的
- ログにトレースIDを載せる: 既存のログに番号を1つ足すだけで、トレースとログを行き来できる。手間に対する効果がいちばん大きいのはここ
逆に、最初から全社の全サービスを計測する計画は、費用の話で止まりがちです。「全部が見える」より「入口とデータベースが見える」を先に取るほうが、実際の障害対応では効きます。
分散トレーシングで新社会人が最初にやる3つ
読んで終わりにしないために、手を動かす順番も書いておきます。
- 手元のアプリに、スパンを1本だけ入れてみる。まずは処理全体を囲うだけで構いません
- そのアプリのログに、トレースIDを出す。既存のログ形式に項目を1つ足すだけです
- 表示画面で1本のリクエストを開き、いちばん長い区間を読む。X-RayやJaeger、Grafanaなどが使われます
この3つを通すと、「なんだか遅い」という言葉を「どの区間が何ミリ秒」に置きかえられるようになります。障害対応の場で使える言葉が1つ増える、という言い方のほうが近いかもしれません。
まとめ:分散トレーシングは「遅い」を数字で話せる言葉にする
- 分散トレーシングは、1回のリクエストの経路と区間ごとの時間を1本につないで見る仕組み。ログの「点」に対して、トレースは「線」
- OpenTelemetryは計測の共通規格。AWSもX-Ray専用SDKからの移行を案内しており、覚えたことが道具を変えても残る
- 始めるなら入口とデータベースだけ。ログにトレースIDを載せるところからが、いちばん効率がいい
次にやることは1つです。担当しているシステムのログを開いて、トレースIDにあたる項目があるか探してみてください。見つからなければ、それを足すのが最初の一歩になります。
あわせて読みたい
監視とサーバーレスの基礎をおさえておくと、トレースの読み方も早く身につきます。
コメント
コメント一覧 （2件）
[…] 海外製のライブラリやAIが出力したサンプルコードは、英語入力を前提にしていることがあります。そのまま取り込むと、日本語環境でだけ壊れます。しかもこの種の不具合は、例外も発生せずログにも残りません。「たまに勝手に送信される」という曖昧な報告だけが上がってきます。ログを見ても原因がわからない種類の問題と同じで、当たりをつける知識がないと調査は長引きます。 […]
[…] とくに2つ目は現場でよく効きます。処理時間が10倍に伸びたという相談の原因が、実は一時ファイルへの書き出しだった、という場面は珍しくありません。壊れているのではなく、逃げ道に切り替わって粘っている状態です。そこまで分かれば、上限を増やすのか、対象を絞るのかを落ち着いて選べます。どこで時間が消えているかを追う方法は、分散トレーシングの記事でも触れました。 […]