前回のメトリクスから、一件の旅へ
前回のS-03では、応答時間やエラー率といったメトリクスで、システム全体の傾向を数値として観測しました。しかしメトリクスは、全体が遅くなってきたことは教えてくれても、その一件がどこで詰まったのかまでは教えてくれません。この講義では、一つのリクエストの旅そのものを追いかけるトレースを学びます。これは、P-10で手作業として行った不具合の切り分けを、記録の力で自動化する道具にあたります。
このスライドのポイント
- S-03: メトリクスで「全体の傾向」を数値として観測した
- メトリクスは「全体が遅い」は見せても「その一件がどこで詰まったか」までは示さない
- この講義の役割: 一つのリクエストの旅そのものを追うトレースを学ぶ
- 位置づけ: P-10でやった手作業の切り分けを、記録の力で自動化する道具
トレースの定義とリクエストID
トレースとは、一つのリクエストが通った経路と、各区間にかかった所要時間を記録し、追跡する仕組みです。ここで言う経路とは、D-03で学んだリクエストが、画面からAPI、データベース、外部APIへと進む道のりのこと。P-10で見た七つの層を、実際のリクエストがどの順に、どれだけの時間で通ったかを写し取ります。実現の基本になるのがリクエストIDです。リクエストが入口に届いた瞬間に一意のIDを発番し、そのリクエストが残す全てのログに同じIDを刻みます。後からそのIDで検索すれば、一件のリクエストの全行程が時系列で並ぶ、という仕組みです。
このスライドのポイント
- トレース＝一つのリクエストが通った経路と、各区間の所要時間を記録・追跡する仕組み
- 経路＝D-03のリクエストが、画面→API→データベース→外部APIと進む道のり（P-10の7層に対応）
- 実現の基本はリクエストID: 入口で一意のIDを発番する
- そのIDを、リクエストが残す全ログ（S-02）に同じ値で刻む
- 後からIDで検索すれば、一件の全行程が時系列で並ぶ
なぜ必要か——当てずっぽうの最適化を防ぐ
トレースがないと、何に困るのでしょうか。この操作だけ妙に遅い、という相談を受けたとき、遅さの原因がデータベースなのか、外部APIなのか、区間ごとの内訳が見えません。すると、当てずっぽうで手を入れることになります。前回までのメトリクスは全体の傾向は見せてくれますが、一件の内訳までは分解しません。結果として、P-10でやった手作業の切り分けを、遅いという声が上がるたびに毎回繰り返す羽目になります。
このスライドのポイント
- トレースがないと「この操作だけ遅い」の原因区間（DBか外部APIか）が見えない
- 内訳が見えないまま手を入れる＝当てずっぽうになる
- メトリクスは全体の傾向を見せるが、一件の内訳までは分解しない
- 結果: P-10の手作業の切り分けを、遅いという声が上がるたびに毎回繰り返す
一つのリクエストの行程図
トレースの中心にあるのは、一つのリクエストの行程図です。横一列に区間を並べ、それぞれの所要時間を棒の長さで表します。たとえば画面で五十ミリ秒、APIで二十ミリ秒、そしてデータベースで八百ミリ秒、という具合です。こうして並べると、全体の時間のうちどの区間が大半を占めているかが、棒の長さで一目でわかります。長い棒こそが、まず手を入れるべき区間だと教えてくれます。
このスライドのポイント
- 中心にあるのは、一件のリクエストの行程図
- 横に区間を並べ、それぞれの所要時間を棒の長さで表す
- 例: 画面 50ms → API 20ms → DB 800ms → 外部API 60ms
- 全体のうちどの区間が大半を占めるかが、棒の長さで一目でわかる
- 長い棒こそ、まず手を入れるべき区間
経費アプリ「申請一覧が遅い」の調査
経費アプリで考えてみましょう。公開後、申請一覧の表示が遅い、という声が上がりました。トレースを見ると、データベースの区間だけで全体の九割の時間を使っていました。原因はここだと特定できたので、L-10で学んだインデックスの出番だと、観測から対策へまっすぐつながります。E-10で学んだ計算量の話や、L-10のインデックスの効果が、実測データで裏づけられる瞬間です。感覚ではなく数字が、直すべき場所を指し示してくれます。
このスライドのポイント
- 経費アプリ公開後、「申請一覧の表示が遅い」という声
- トレースを見ると、DB区間だけで全体の約9割の時間
- 原因が特定できたので、L-10のインデックスの出番——観測から対策へ直結
- E-10の計算量、L-10のインデックスの効果が、実測データで裏づけられる瞬間
技術サンプルカード
サンプルを見ましょう。種別は図解、目的は一件のリクエストの区間ごとの時間を可視化することです。上の区間バーでは、データベースの棒だけが飛び抜けて長く、そこが遅い区間だと即座にわかります。下の図は、同じリクエストIDが各層のログを貫いている様子です。前回のS-02で、構造化ログにrequest_idという項目を入れておきました。入口で発番したそのIDを全ログに刻んでおけば、後からIDで検索するだけで、一件の全行程が時系列で並びます。AIには、リクエストIDの発番と全ログへの伝搬を、遅い区間を特定できる形で実装してほしいと頼みます。
混同しやすい概念——メトリクスとトレース
混同しやすいのが、メトリクスとトレースの役割です。前回のメトリクスは、全体が遅いを捉える道具で、システム全体の傾向を見ます。対してトレースは、この操作の、この区間が遅いを捉える道具で、一件のリクエストの内訳に踏み込みます。同じ遅さを見ていても、見ているズームの倍率が違うのです。実際の障害対応では、まずメトリクスで全体の異変に気づき、次にトレースで詰まった区間まで降りていく、という順で両方を行き来します。
バイブコーディングでの確認点
バイブコーディングでの確認点です。性能を改善したいとき、AIにいきなり速くしてと頼みたくなります。しかしその前に、まずどの区間が遅いのかを計測してと頼んでください。計測なき最適化は当てずっぽうです。遅い場所を確かめないまま手を入れても、当たるかどうかは運任せになります。これはN-10で学んだトレードオフの判断にも通じます。何かを速くする代わりに何かを犠牲にする、その判断を下すにも、まず計測した数字が要ります。
このスライドのポイント
- 性能改善をAIに頼む前に、まず「どの区間が遅いかを計測して」と頼む
- 計測なき最適化は当てずっぽう——遅い場所を確かめずに手を入れても運任せ
- N-10のトレードオフ判断にも、まず計測した数字が要る
- AIへの質問例: 「改善に入る前に、どの区間が遅いかを計測して示してください」
一問一答とまとめ
最後に一問一答です。問い。一つのリクエストの全行程を、ログから引き出す鍵は何でしょうか。……答えは、リクエストIDです。入口で一意のIDを発番し、全てのログに同じIDを刻んでおくことが鍵になります。三十秒でまとめます。トレースは、一件のリクエストが通った経路と区間ごとの所要時間を追う仕組みで、リクエストIDがそれを支えます。全体はメトリクス、一件はトレース、と使い分け、計測してから直すのが鉄則です。次回のS-05では、異常を人に知らせる仕組みとして、監視・アラート・エスカレーションへ進みます。関連資料は、ログ設計入門と、エラー解決プロンプト50です。
このスライドのポイント
- 一問一答: 一つのリクエストの全行程をログから引き出す鍵は？ → リクエストID（入口で発番し全ログに刻む）
- 30秒まとめ: トレースは経路と区間ごとの所要時間を追う仕組み。リクエストIDが支える。全体はメトリクス、一件はトレース。計測してから直す
- 次回: S-05 監視・アラート・エスカレーション
- 関連資料: 「ログ設計入門」「エラー解決プロンプト50」
