# クリティカルパス分析 ## 定義 クリティカルパス分析は、分散トレース上でエンドツーエンドレイテンシを実際に支配する RPC/処理区間を特定し、ユーザー影響の大きい遅延やエラーを優先的に扱う手法である。マイクロサービスでは全 RPC エラーがユーザー影響を持つわけではないため、単純な件数ではなくクリティカルパス上にあるかが重要になる。 ## 横断的知見 - [[CRISP]] は Uber の大規模マイクロサービスにクリティカルパス分析を適用し、下流診断や最適化対象の優先順位づけを高速化した。([[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]]) - Uber の RPC エラー分析は、エラーの 29.35% が非致命的でエンドユーザーに影響しないことを示し、クリティカルパス上のエラーかどうかを区別する必要を示した。([[@2024__PACMCAS__The Tale of Errors in Microservices]]) - [[分散トレーシング]] の価値は、全呼び出しを記録することだけでなく、どの呼び出しがユーザー影響の経路にあるかを推定できる点にある。 - **クリティカルパス分析の対象グラフが「実行時に動的に決まる呼び出しグラフ(マイクロサービス)」から「静的に宣言されたDAG(CI/CD)」へ拡張されると、分析の難所が変わる**: CRISP([[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]])や Tale of Errors([[@2024__PACMCAS__The Tale of Errors in Microservices]])が対象とするマイクロサービスのRPCコールグラフは、リクエストごとに実行時のルーティング・並行呼び出しによって形が変わるため、クリティカルパスの特定自体に統計的推定が必要になる。一方 [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] が扱うCI/CDのDAG(prebuildジョブへの依存関係など)は、ワークフロー定義ファイルに静的に宣言されるため、グラフ構造の特定自体は自明であり、真の難所は「どのジョブの高速化が全体時間に効くか(React・Go・Rustの並列ビルド例でGoを高速化しても全体時間が変わらない)」という直感に反する見極めに移る。同じ「クリティカルパス」という語でも、動的グラフでは構造推定が、静的DAGでは寄与度推定が主な技術的難所になるという違いが、CI/CDへの適用によって明確になる。(Source: [[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]], [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]) - **「クイック&ダーティ」な目視でのクリティカルパス把握が、CRISPの形式的アルゴリズムと並ぶ実務手法として存在する**: CRISP はUberのマイクロサービスに対しグラフアルゴリズムでクリティカルパスを厳密に計算するのに対し、[[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] は、分散トレーシングのウォーターフォールビュー上でスパンの並行度とその合計時間を目視で可視化するだけで「クイック&ダーティにクリティカルパスの見当をつけられる」という、より軽量な実務手法を紹介する。Honeycombはこれを既存のトレーシング機能への自動計装だけで済ませ、専用アルゴリズムの実装を必要としない。厳密な計算(CRISP)と目視のヒューリスティック(Honeycomb)という2つの手法が、同じ「クリティカルパスの特定」という目的に対して精度と導入コストのトレードオフの両端に位置づけられる。(Source: [[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]], [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]) - **本番の失敗事例が「単純な逐次モデル」という誤ったメンタルモデルの実害を具体的に示す**: 本ページのCRISP・第20章はいずれもクリティカルパスを正しく特定する手法(グラフアルゴリズム・目視ヒューリスティック)を論じるのに対し、[[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]](Fin/Intercom)は「クリティカルパスを特定できない」場合に何が起きるかを本番の失敗事例として記録する。エンジニアは分散トレースを「各トランザクションが前段の完了を待って開始する」という単純な逐次モデルで捉えており、個々のコンポーネントを最適化しても顧客体感のtime to first tokenは改善しなかった。実際には並行処理が重なり合っており、どの処理がユーザーへのトークン返却を真にブロックしているか(クリティカルパス上にあるか)を判別できなかったためである。Finはトランザクションスパンに制御フローの受け渡し箇所を示す低レベルテレメトリを付与した新しいトレースを一から構築して初めて、「何が遅いか」だけでなく「なぜ遅いか」に答えられるようになった。これは、クリティカルパス分析が単なる分析上の最適化ではなく、誤ったメンタルモデルのままでは最適化の労力そのものが顧客体験の改善に結びつかないという、より根本的な失敗モードを回避する手段であることを示す。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]]) - **クリティカルパス分析の対象グラフが LLM 訓練の反復スケジュールへ広がると、グラフの出所が「実行時観測からの推定」から「訓練設定からの決定論的再構築」へ変わる**: CRISP・第18章(CI/CD)の対比では動的グラフ(構造推定が難所)と静的DAG(寄与度推定が難所)という区別が立ったが、[[MEGATRACE]]([[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]], ICDCS 2026)が対象とする LLM 訓練の反復依存グラフはさらに異なる第三の位置を占める。訓練は TP/PP/DP という並列化設定と 1F1B スケジュールに従い各ランクが決定論的かつ周期的に計算・通信を繰り返すため、MEGATRACE はグラフ構造を実行時のトレースから推定するのではなく、訓練パラメータから Forward/Backward 計算ブロックを頂点とする DAG として**決定論的に再構築**する。CI/CD の静的 DAG(ワークフロー定義ファイルから自明に得られる)に近いが、CI/CD が「どのジョブの高速化が全体に効くか」という寄与度推定を難所とするのに対し、LLM 訓練のクリティカルパス分析は「パイプラインバブルに吸収されて無害な局所的遅延(S1・S2・S4)」と「実際にエンドツーエンドのスローダウンに寄与する遅延(S3・S5・S6)」を分離するという、バブル構造に固有の難所を持つ。ハング検知(halt point の到達不能を検出)とスローダウン検知(履歴期待値からの逸脱がクリティカルパス上か否かを判定)の両方にこの決定論的 DAG を再利用する点も、CRISP のような都度推定型のアプローチと異なる。(Source: [[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]], [[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]], [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]) - **クリティカルパス分析が、分散訓練の診断画面から改善効果の予測と再実行へ接続される**: [[Zoomer]] は PyTorch 実行トレースと rank 間タイムラインから最長の実行経路を特定し、改善効果の大きい箇所へ注力する。[[MEGATRACE]] が訓練スケジュールから DAG を再構築してハング／スローダウンを局所化するのに対し、Zoomer はこの分析を GPU／CPU／メモリ／通信のボトルネック検知、自動洞察、最適化ノートブック、提案設定でのジョブ再実行へつなぐ運用側の実装例である。(Source: [[@2025__EngineeringAtMeta__Zoomer - Powering AI Performance at Meta's Scale Through Intelligent Debugging and Optimization]], [[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]]) - **オンライン LLM 推論では、クリティカルパス分析が CPU/GPU の異なる実行層を結ぶ**: マイクロサービス向け CRISP はリクエストの RPC グラフからエンドツーエンド遅延を支配する経路を特定する。StriaTrace は同じ考え方を vLLM の EngineCore・GPUWorker・GPU カーネルへ適用し、メイン推論スレッドの停止や rank 間ストラグラーが GPU カーネルの空白として現れることを利用する。分散サービスの RPC 経路から、LLM 推論のホスト処理・集合通信・カーネル実行まで、クリティカルパスの対象が層横断的に深くなる。(Source: [[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]], [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]]) ## 未解決の問い - LLM 推論のクリティカルパス上でない GPU カーネルや補助スレッドをどこまで捨てても、まれな障害の根本原因を見逃さないか。 - CI/CDのDAG(静的に宣言されたジョブ依存関係)におけるクリティカルパス特定は、マイクロサービスの動的呼び出しグラフに対して開発されたCRISPのようなアルゴリズムをそのまま転用できるか、それとも静的性を前提とした専用の(より単純な)手法で十分か。 - サンプリングされたトレースだけでクリティカルパスを推定すると、希少だが重要な経路を取り逃がさないか。 - Finの事例は低レベルスパンテレメトリの手動設計によってクリティカルパスを特定したが、CRISPのような形式的アルゴリズムやHoneycombの目視ヒューリスティックを、LLMエージェントの投機的並行処理(先行リクエストのような)を含むトレースに適用した場合、同じ精度で機能するか。投機的だが結果的に使われない処理(無駄になった先行リクエスト)は、クリティカルパス分析上どう扱うべきか。 - クリティカルパス上ではない非致命的エラーを、将来のリスクや capacity waste としてどう扱うべきか。 - LLM エージェントの RCA に、クリティカルパス制約をどのようにツール/プロンプトとして渡すべきか。 - MEGATRACE の決定論的 DAG 再構築(訓練パラメータからの静的導出)は、MoE のようにエキスパート並列で通信パターンが動的に変わる訓練(トークンごとに宛先が変わる AllToAll)にも適用できるか。動的なルーティングは 1F1B の周期性・決定性という前提を崩すため、CRISP のような実行時推定へ回帰する必要が生じるか。 ## 関連 - 概念: [[分散トレーシング]] / [[非致命的RPCエラー]] / [[Fault Localization]] / [[根本原因分析]] / [[マイクロサービスコールグラフ]] / [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] / [[パフォーマンスエンジニアリング]] / [[GenAI オブザーバビリティ]] / [[LLM学習モニタリング]] - ソース: [[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]] / [[@2024__PACMCAS__The Tale of Errors in Microservices]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]] / [[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]] - エンティティ: [[Honeycomb.io]] / [[Fin]] / [[Intercom]] / [[MEGATRACE]] ## 出典 - [[@2022__USENIX ATC__CRISP - Critical Path Analysis of Large-Scale Microservice Architectures]] - [[@2024__PACMCAS__The Tale of Errors in Microservices]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]]("Using the Correct Observability Signals, Together"、トレーシングでのクリティカルパスの目視把握) - [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]]("And Thus, 'Time to First Token' Was Born": 低レベルスパンテレメトリによるクリティカルパス特定の本番事例) - [[@2026__ICDCS__MEGATRACE - Troubleshooting Hang and Slowdown in Large-scale LLM Training Clusters]](§III-C Asynchronous Analysis: 訓練スケジュールからの決定論的 DAG 再構築とクリティカルパス分析によるハング・スローダウン局所化)