マイクロサービスコールグラフ

# マイクロサービスコールグラフ ## 定義マイクロサービスコールグラフとは、ユーザーリクエスト 1 件を起点として発生するマイクロサービス間のすべての呼び出しを有向グラフで表したものである。エントリポイントマイクロサービス(UM)がユーザーからリクエストを受け取り、その処理のために下流マイクロサービス(DM)を順次または並列に呼び出す。各呼び出しは(TraceID, rpcID, UM, DM, インターフェース, RT, 通信パラダイム)のタプルとして計装・記録される。Alibaba クラスタの実測トレース分析(Luo et al., SoCC 2021)が大規模本番環境での初の包括的な特性解析を行った。コールグラフの通信パラダイムは 3 種類に分類される。 - **RPC(遠隔手続き呼び出し)**: 双方向の同期通信。DM は UM に結果を返す必要がある(76% を占める) - **MQ(メッセージキュー)**: 一方向の非同期通信。UM は第三者エンティティにメッセージを投入し、DM が後で取り出す(23%) - **IP(プロセス間通信)**: 主に stateless と stateful マイクロサービス間で発生(1%) コールグラフのノードはサービスタイプで分類される: stateless サービス、stateful サービス(DB・Memcached)。Stateless サービスはさらに blackhole(DM なし)・relay(必ず DM を呼ぶ)・normal(確率的に DM を呼ぶ)に分かれる。 ## 横断的知見 - Alibaba 実測(SoCC 2021)で判明したコールグラフの 4 つの固有特性は、既存の学術ベンチマーク(DeathStarBench・μSuite・Acme Air)が本番環境を代表しないことを定量的に示した。(1)ヘビーテール分布: グラフサイズが Burr 分布に従い 10% 超が 40 ノード超、(2)ツリー状拡散: 大半のノードが in-degree 1、(3)ホットスポット: 5% のマイクロサービスが 90% 以上のサービスに共用、(4)動的トポロジー: 同一サービスが 9 クラス超の異なる位相を示す(Source: [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) - 分散トレーシングの計装によって収集したコールグラフデータは、障害箇所特定([[Fault Localization]])・根本原因分析([[根本原因分析]])・マルチモーダル障害診断([[マルチモーダル障害診断]])の入力として広く使われている。トレースの量・粒度・コスト効率のトレードオフが各診断手法の設計を左右する(Source: [[@2021__SoCC__Characterizing Microservice Dependency and Performance]], [[分散トレーシング]] 横断知見) - コールグラフのトポロジーが RT に直接影響するという知見(同一クラスタ内 RT の安定性が 90% 超でイントラ/インタークラスタ比 < 0.6)は、トポロジー認識型スケジューラの必要性を裏づける。RT の変動を説明するためにコールグラフを利用する研究と、コールグラフを入力として RT を予測する研究の 2 方向がある(Source: [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) - グラフ深さが大きくなると通信パラダイムが変化し、深い階層では Memcached ヒット率が低下して DB 通信の割合が増える。一方、MQ の割合も増加し、非同期化が RT を補償する設計が自然に生まれていることが示唆される(Source: [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) - **「Death Star graph」という用語自体が [[DeathStarBench]] suite の命名起源**: [[@2019__ASPLOS__An Open-Source Benchmark Suite for Cloud and IoT Microservices]] は Social Network・Media・E-commerce・Banking・Swarm の各サービスをマイクロサービス依存グラフとして可視化し、その「中心ノードから無数の依存が放射状に伸びる」形が映画 Star Wars の Death Star 兵器に似ることから suite に DeathStarBench と命名された。Alibaba 実測の「ツリー状拡散・ホットスポット」(Luo+ SoCC 2021)が本番で観測されるのに対し、DeathStarBench はそのトポロジを意図的に学術ベンチに固定化したことに自覚的(脚注1)。これは Luo+ が批判した「学術ベンチが本番を代表しない」という主張の同じ図形を、ベンチ側はあえて単純化のためにデザイン選択したことを示す。(Source: [[@2019__ASPLOS__An Open-Source Benchmark Suite for Cloud and IoT Microservices]], [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) - **TrainTicketTrace が実証した n+1 selects パターンは「コールグラフのbreadth/depth 異常」として測定可能**: [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]] が分散トレースで観測した `GET /admintravel/findAll/{id}` の breadth 30/depth 9 と breadth 35/depth 9 のトレースは、n+1 selects(1 つの集約 query を多数の個別 query に分解する反パターン)の典型的痕跡。Alibaba(Luo+ 2021)の「最頻 breadth は 1/2/3」観察と並べると、**breadth 30+ は明らかに反パターン由来の異常値**として識別できる。これはコールグラフの statistical baseline(中央値・四分位)を baseline にして outlier 検出を組み込めば、設計上の問題を可視化する道具になることを示す。(Source: [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]], [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) - **コールグラフは RCA パイプラインの「ランダムウォーク基盤」として 10 年間一貫して利用されてきた**: MonitorRank（Kim+ SIGMETRICS 2013）がサービス依存グラフ上のパーソナライズドランダムウォーク（相関比例遷移確率）で RCA を定式化して以来、CloudRanger（CCGrid 2018）は PC 構築グラフ + 二次ランダムウォ��ク、AutoMAP（WWW 2020）は異常行動グラフ + 前方/自己/後方ランダムウォーク、ε-Diagnosis（WWW 2019）はコールグラフ上のスパン分解 + ε統計量でテイルレイテンシ異常を診断する。いずれもコールグラフを「ノード間遷移のインフラ」として使い、遷移確率の設計が手法の差別化要因となっている。Alibaba SoCC 2021 が報告した「ヘビーテール・ホットスポット」特性は、ランダムウォーク系手法がホットスポットノードに過度に訪問する失敗モードを示唆する。(Source: [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]], [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]], [[@2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Applications Automatically]], [[@2019__WWW__ε-Diagnosis - Unsupervised and Real-time Diagnosis of Small-window Long-tail Latency in Large-scale Microservice Platforms]], [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) - **コールグラフとレイテンシグラフは「ほぼ逆向き」だが、非同期呼び出しという除外ルールで両者は体系的に乖離する**: Lohse et al. (AAAI 2025 AICT) は Robot Shop で「コールグラフの逆向きをレイテンシグラフの近似として使う場合、非同期呼び出しが含まれるため本来ないはずの辺が混入する」と定式化した。実験では真のレイテンシグラフをこの近似で代替したSVRより、発見したレイテンシグラフを使ったSVRの方が一貫した性能を示した。これはAlibaba SoCC 2021(Luo+ 2021)が記録した「MQ(非同期) = コールグラフの23%」という実測値と合わせると、本番環境ではコールグラフ逆向きとレイテンシグラフの不一致がさらに深刻になる可能性を示す。(Source: [[@2025__AAAI Workshop AICT__Causal Discovery for Cloud Microservice Architectures]], [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) - **「コールグラフを因果グラフの事前知識として使う」パラダイムと「因果グラフをデータから発見する」パラダイムが並立し始めた**: CIRCA (KDD 2022)・RCD (NeurIPS 2022) はコールグラフをドメイン知識として使い因果グラフを制約するが、Lohse et al. はコールグラフをゴールドスタンダードとせずデータから因果グラフを発見し、コールグラフ逆向きはあくまで「近似的な正解」として評価基準に使った。この対比は「コールグラフをどの役割に置くか(制約か評価基準か)」という設計選択を浮き彫りにする。(Source: [[@2025__AAAI Workshop AICT__Causal Discovery for Cloud Microservice Architectures]], [[@2022__KDD__Causal Inference-Based Root Cause Analysis for Online Service Systems with Intervention Recognition]], [[@2022__NeurIPS__Root Cause Analysis of Failures in Microservices through Causal Discovery]]) - **TORAI(FSE 2026)は、コールグラフ構築そのものを迂回することで「blind spot(未計装サービス)によるコールグラフの不完全性」問題を解消する——Alibaba 実測が定量化したコールグラフの偏り(ヘビーテール・ホットスポット)とは異なる、計装カバレッジという別の欠落軸を提起する**: 本ページの既存知見はコールグラフの「トポロジー特性」(ヘビーテール分布・ツリー状拡散・ホットスポット・動的トポロジー、Luo+ SoCC 2021)に焦点を当ててきたが、これらは全サービスが計装済みであることを前提とする。TORAI は代表的な RCA ベンチマーク 3 種のコールグラフ計装率を実測し、Online Boutique(11 中 7 サービスのみ計装)・Train Ticket(64 中 27 サービスのみ計装)・Sock Shop(0% 計装)という「そもそもコールグラフを完全に構築できない」現実を定量化した。これは Alibaba 実測が示した「動的トポロジー」(同一サービスが 9 クラス超の異なる位相を示す)とは異なる、「そもそも観測できないノードが存在する」という計装カバレッジの欠落軸であり、コールグラフに依存する RCA 手法(CIRCA・RCD の一部設定、Nezha 等)は原理的にこの欠落を埋められない。TORAI はコールグラフを構築せず severity ベクトルの欠損補完で対処することで、この問題を回避する。(Source: [[@2021__SoCC__Characterizing Microservice Dependency and Performance]], [[@2026__FSE__TORAI - Multi-source Root Cause Analysis for Blind Spots in Microservice Service Call Graph]]) - **コールグラフの「計装カバレッジ」欠落(TORAI が定量化した blind spot)を、構築層で先回りして塞ぐ非侵入手法が本 wiki に接続された**: 本ページの既存知見は「構築済みコールグラフの統計的性質」(ヘビーテール・ホットスポット・動的トポロジー、Luo+ SoCC 2021)と「未計装サービスによるコールグラフの不完全性」(TORAI, FSE 2026)という 2 つの分析側の問題を扱ってきたが、いずれも「コールグラフをどう構築するか」自体は所与としている。[[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]](博士論文 Ch.3)が提案するカーネル内フロー束ねは、アプリケーションコード改変を要さずカーネルの TCP/UDP ソケット操作から直接コールを捕捉するため、TORAI が実測した「Sock Shop は計装率 0%」のような blind spot が原理的に生じにくい——計装対象を選択的に追加する仕組みではなく、カーネルを通過する全 TCP/UDP フローを対象とするためである。ただしこの非侵入性は無条件の解決策ではなく、パケット転送(NAT)型リレー越しの依存は本手法でも検出できない(§3.5.2)という別種の blind spot を残す。「アプリ層の計装カバレッジ欠落」と「カーネル層でも埋まらないネットワーク層の不可視性」は異なる原因を持つ 2 種類の blind spot として区別する必要がある。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]], [[@2026__FSE__TORAI - Multi-source Root Cause Analysis for Blind Spots in Microservice Service Call Graph]]) - **「継続的構築」という時間軸の要求が、Alibaba 実測の動的トポロジー特性と接続する**: Luo+ SoCC 2021 は「同一サービスが 9 クラス超の異なる位相を示す」動的トポロジーを実測したが、これはコールグラフが静的な一度きりの成果物ではなく継続的に更新され続けるべきことを示唆する。博士論文 Ch.3 はこの要求に対し、1 秒間隔の周期的ポーリングで低 CPU オーバーヘッド(2.2% 未満)を保ちながらコールグラフを継続構築する具体的な実装を与える。ただし Ch.3 の評価は単一時点でのオーバーヘッド測定にとどまり、Luo+ が観測した「動的トポロジーへの追従精度」(グラフ更新がトポロジー変化にどの程度の遅延で追いつくか)は測定されていない。(Source: [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]], [[@2021__SoCC__Characterizing Microservice Dependency and Performance]]) ## 未解決の問い - コールグラフのトポロジークラス(9 種超)に応じた動的スケジューリングは、静的設定より有意に RT を改善できるか？実測ベースの検証が必要 - ホットスポットマイクロサービス(上位 5%)の障害は他サービスに比べてどれだけ広範囲に RT 劣化を伝播させるか？ホットスポット認識型 SLO 設計の基礎となるトレード計算が未整備 - 強結合依存ペアのインターフェース統合(単一マイクロサービス化)は、実際に通信オーバーヘッドを有意に削減し、かつ開発のルーズ結合メリットを損なわないか？ - 確率的グラフ生成モデルが未対応の「ノードの複数グラフ間共有」問題をどう定式化するか。集約呼び出しトレースを活用したノードマッチングの設計が開かれている - 異なるクラウドプロバイダ(Google Cloud・AWS・Azure)のマイクロサービスでも同じ 4 特性(ヘビーテール・ツリー状・ホットスポット・動的)が観測されるか？単一プロバイダ結果の一般化可能性 - TrainTicketTrace のように EvoMaster の自動探索で得られたトレース集合と、Alibaba(Luo+ 2021)の人間ユーザ起点のトレースは、breadth/depth 分布で同じヘビーテールを示すか? 探索手法の違い(systematic exploration vs 実利用パターン)はコールグラフ統計を歪めるか([[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]]) - DeathStarBench の Death Star graph(学術ベンチの単純化されたトポロジ)と Alibaba 実測(Luo+ 2021)・Meta 実測([[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]])の本番グラフの**距離**を定量化する graph distance / topology embedding 指標は何が適切か? 既存ベンチが本番からどれだけ離れているかを 1 つの数値で示せる枠組みはあるか ## 関連 - 概念: [[分散トレーシング]] / [[テレメトリ]] / [[Fault Localization]] / [[根本原因分析]] / [[AIOps]] / [[マルチモーダル障害診断]] / [[トレースサンプリング]] / [[因果推論ベースRCA]] / [[限定観測可能性]] / [[ネットワーク依存性発見]] / [[eBPF]] - エンティティ: [[Alibaba Group]] / [[Shutian Luo]] / [[Chengzhong Xu]] / [[DeathStarBench]] / [[Online-Boutique]] / [[Sock Shop]] / [[Train-Ticket]] / [[go-conntracer-bpf]] - 関連構造: `structures/LLM4SRE - MOC.md` ## 出典 - [[@2021__SoCC__Characterizing Microservice Dependency and Performance]] — Luo et al., SoCC 2021: Alibaba 本番クラスタのトレース分析 - [[@2026__FSE__TORAI - Multi-source Root Cause Analysis for Blind Spots in Microservice Service Call Graph]] — Pham et al., FSE 2026: Online Boutique/Sock Shop/Train Ticket のコールグラフ計装率を実測し、blind spot(未計装サービス)がコールグラフ依存 RCA を無効化することを示した - [[@2025__PhD__Scaling Telemetry Workloads in Cloud Applications - Chapter 3 Efficient TCP-UDP Socket-based Instrumentation in Kernel for Continuous Construction of Network Call Graphs]] — カーネル内フロー束ねによる非侵入・低オーバーヘッドの継続的コールグラフ構築