# MicroIRC: Instance-level Root Cause Localization for Microservice Systems > [!abstract] 概要 > マイクロサービスアーキテクチャは Web アプリケーション開発において普及が進んでいる。しかし、相互接続したマイクロサービスの複雑さ、長いサービス呼び出し連鎖、サービス状態の動的変化、そして多数のサービス配備ノードにより、障害の根本原因を特定することは困難である。さらに、各マイクロサービスが複数のインスタンスを持つ場合があり、マイクロサービストポロジと障害種別が動的に変化する中でインスタンスレベルの障害を迅速かつ効果的に特定することは難しい。この課題に対処するため、本論文では MicroIRC(Instance-level Root Cause for Microservices)を提案する。MicroIRC は、インスタンスレベルで根本原因を箇所特定するとともに、新しい種別の異常への適応における頑健性を持つ、新しいメトリクスベース手法である。まず、マイクロサービスシステムメトリクスの時系列特徴から異なる根本原因種別を適合させるためにグラフニューラルネットワーク(MetricSage)を訓練する。次に、マイクロサービスシステムの異種重み付きトポロジ(HWT)を構築し、パーソナライズドランダムウォークを実行して根本原因候補を特定する。これらの候補と異常時間ウィンドウ内のリアルタイムメトリクスをグラフニューラルネットワークに入力し、ランク付けされた根本原因リストを生成する。4 つの実世界データセットで行った実験により、MicroIRC がインスタンスレベルでマイクロサービスの根本原因を精確に箇所特定できることが実証された。上位 5 件の返却結果に対する適合率は 93.1% に達する。さらに、最先端手法と比較して、サービスレベルの根本原因箇所特定精度を 17% 以上、インスタンスレベルの精度を 11.5% 以上改善できる。また、複数インスタンスや新しい障害種別が登場するシナリオにおいても頑健性を示す。 ## 論文情報 - **タイトル**: MicroIRC: Instance-level Root Cause Localization for Microservice Systems - **著者・所属**: Yuhan Zhu, Jian Wang\*, Bing Li\* (武漢大学 コンピュータ科学学院), Yuqi Zhao, Zekun Zhang, Yiming Xiong (武漢大学), Shiping Chen ([[CSIRO Data61]], オーストラリア) - **媒体**: Elsevier プレプリント(査読前) - **発表年**: 2026 年(推定) - **SSRN**: https://ssrn.com/abstract=4655009 - **コード**: https://github.com/WHU-AISE/MicroIRC.git ## 概要 MicroIRC は、マイクロサービスシステムにおけるインスタンスレベルの根本原因箇所特定を実現する手法である。時系列メトリクス特徴を学習するグラフニューラルネットワーク(MetricSage)と、リアルタイムトポロジを活用した異種重み付きトポロジ(HWT)上のパーソナライズドランダムウォークを組み合わせることで、従来手法が苦手とするインスタンス粒度での箇所特定と新種障害への頑健性を同時に達成する。4 データセット平均で PR@5 = 93.1%、サービスレベル Acc 最高 0.945 を記録し、SOTA 比でそれぞれ 17%・11.5% 以上の改善を示した。 ## 問題設定 **背景**: マイクロサービスシステムでは各マイクロサービスが複数インスタンスを持つ(Kubernetes によるスケーリング)。既存の根本原因箇所特定手法はサービスレベルに留まりインスタンスを特定できない。また DejaVu 等の機械学習手法は新しい障害種別に脆弱(新種 10% 混入で精度 -28%)。 **入力**: - リアルタイムのサービス呼び出しデータ - マルチレベルのメトリクス: サービスレベル(応答時間)、インスタンスレベル(CPU・メモリ・ネットワーク・QPS・成功率)、ホストレベル(CPU・メモリ・ネットワーク) **出力**: ランク付けされた根本原因リスト $R$。各エントリはインスタンス/サービスノード $r_i$ と障害種別 $a_j$ のペア。 **前提**: Kubernetes 上のマイクロサービスシステム。カオスエンジニアリングによる障害注入履歴データを訓練に使用。 ## 提案手法 MicroIRC は 3 ステップで構成される。 ### ステップ 1: メトリクスモデリングと MetricSage 訓練 **MetricSage** は GraphSage に着想を得たグラフ畳み込みニューラルネットワーク。時系列サンプリング点をノードとしてグラフ化し、異常時間ウィンドウ内の時系列特徴をグローバル(システム全体)とローカル(異常サービスと複数インスタンス間)の両方でとらえる。 - 各時刻 $t_l$ のサンプリング点がエンコーダを経てノード特徴 $\mathbf{v}_{t_l}$ となる - 同一異常時間ウィンドウ内のノードを時系列順に接続することでエッジ $E$ を定義 - 近傍集約を固定回数 $k$ 繰り返すグラフ畳み込みで特徴 $\mathbf{M}_v^k$ を計算 - 障害種別分類を教師ありで学習し、特徴重み付け用モデル $M(\cdot, \cdot)$ を得る ### ステップ 2: 異種重み付きトポロジ(HWT)の構築 リアルタイムのサービス呼び出しデータからシステム呼び出しトポロジグラフ $G(V, E)$ を構築し、Birch クラスタリングアルゴリズムで異常検知を行う。障害が検出されると、サービス・インスタンス・ホストの 3 種ノードを含む**異種サービストポロジグラフ** $G(V, E)$ を構築し、各エッジに**最大相関値**(Maximum Correlation, MC)を重みとして付与する。 $MC(n_v, n_w) = \begin{cases} \text{Bias} & n_v, n_w \in \mathcal{S} \text{ かつ異常辺} \\ \max(\text{corr}(\mathbf{S}_t^{n_v}, \mathbf{SI}_t^{n_w})) & n_v \in \mathcal{S}, n_w \in \mathcal{I} \\ \max(\text{corr}(\mathbf{N}_t^{n_v}, \mathbf{SI}_t^{n_w})) & n_v \in \mathcal{N}, n_w \in \mathcal{I} \end{cases}$ ### ステップ 3: 細粒度の根本原因箇所特定 重み付き障害サブグラフ $G(V, E, W)$ 上でパーソナライズドランダムウォークを実行し、根本原因候補セット $RC$ を生成する。パーソナライゼーション配列はインスタンスノードに対して対応するサービスとの MC 値、サービスノードにはそのインスタンス群の平均 MC 値を割り当てる。 最後に候補セット $RC$ とリアルタイムメトリクス $\mathbf{X}_{in-time}$ を MetricSage に入力して細分割重み $SW$ を得て、最終ランキング $R = RC \times SW$ を算出する。これにより根本原因種別の同定も同時に行う。 ## 新規性 | 軸 | 既存手法 | MicroIRC | |---|---|---| | 箇所特定粒度 | サービスレベルが主流 | インスタンスレベル | | トポロジ | サービス間依存グラフのみ | サービス・インスタンス・ホスト 3 層の HWT | | 新種障害への対応 | DejaVu は 10% 混入で -28% 精度低下 | 比較的頑健(ランダムウォーク + GNN の組み合わせ) | | メトリクス特徴抽出 | GAT 等で集約 | 時系列サンプリング点をノードとするグラフ畳み込み | CausIL はインスタンスレベルを考慮するが因果グラフ推定が過敏で辺が増殖しやすく、重みの不均一分布により PR@1 が大幅に低下する。MicroIRC は HWT の相関重みとランダムウォークの組み合わせで安定した精度を実現する。 ## 実験設定 **環境**: Apple M1, 16G RAM(効率性評価)、Kubernetes クラスタ(Ubuntu 20.04/16.04、マスター 16 コア 64GB、ノード合計 8〜24 コア 28〜128GB) **データセット**: | データセット | 障害クラス数 | サンプル数 | メトリクス種別数 | サンプリング間隔 | |---|---|---|---|---| | A (DejaVu 公開データ) | 22 | 1,415,766 | 418 | 60s | | B (DejaVu 公開データ) | 18 | 1,538,658 | 496 | 60s | | C (Online Boutique) | 17 | 1,165,956 | 146 | 5s | | D (CCF AIOps Challenge 2022) | 18 | 1,006,962 | 146 | 60s | **ベースライン**: - **インスタンスレベル**: DejaVu, CausIL - **サービスレベル**: DejaVu, DyCause, MicroRCA, CloudRanger, MonitorRank **評価指標**: PR@K(Top-K 再現率)、AVG@N(PR@1〜5 の平均)、Acc(ランキング位置ベース精度) ## 実験結果 **図1: メモリ障害発生時の RPS 変化(インスタンス数別)** **Figure 1: RPS over time during memory failure by instance count** ![[_attachments/2026_Zhu_Microirc_Instance_Level_Root_Cause/fig1a-rps-instance-failure-impact.png]] (図1a. インスタンス数(1〜4)にかかわらず、障害発生時に RPS が大幅低下する。スケールアップは根本原因特定の代替にならないことを示す。) **インスタンスレベル比較(RQ1)**: - MicroIRC 平均: PR@1 = 0.773、PR@3 = 0.874、PR@5 = 0.931 - DejaVu との比較: PR@1 で +11.5%、PR@3 で +13.4%、PR@5 で +16.7% - CausIL はデータセット A で PR@1 = 0.184 と大幅に劣る **サービスレベル比較**: データセット C・D で全手法を 17〜55% 上回る Acc を達成。 **アブレーション(RQ2)**: MetricSage なしの MicroIRC に対して、MetricSage ありで PR@1 +56.76%、PR@3 +50.5%、PR@5 +41.1% の大幅改善。 **新種障害への頑健性(RQ3)**: 訓練時の障害種別割合 0.8・0.6・0.4 すべての条件で MicroIRC が DejaVu を大幅上回る。例: データセット C で割合 0.8 のとき PR@1〜3〜5 でそれぞれ +28.35%・+38.35%・+41.65%。 **効率性(RQ4)**: MicroIRC の処理時間の 90% 以上をランダムウォーク段が占める(細分割段は 5〜9%)。トポロジ規模増大に伴い差が僅かに拡大するが、大幅な優位性を考慮すればトレードオフは許容可能。 ## 考察 - HWT へのインスタンスレベルメトリクス導入が精度向上の主因。データセット C・D(HWT 使用)の結果がデータセット A・B(インスタンス+ホストのみ)より顕著に優れる。 - ランダムウォーク段が一貫して処理時間の 90% 超を占め、大規模トポロジでのスケーラビリティが今後の課題。 - 異常時間ウィンドウは 10 分が最適。小さすぎると異常波形を捉えられず、大きすぎると正常データが混入する。 ## 強み / 弱点・課題 **強み**: - インスタンスレベルという細粒度の根本原因箇所特定を実現し、実際の SRE 対応(どのポッドに介入するか)に直結する - 新種障害に対してランダムウォーク + GNN の組み合わせが頑健性を発揮する - リアルタイムのトポロジを使用するため、インスタンスのスケールアップ/ダウンに対応できる **弱点・課題**: - 大規模マイクロサービスシステムでは訓練効率が低下(グローバルメトリクス次元を特徴次元として使用するため) - 異常時間ウィンドウ内のトポロジ動的変化(インスタンスの頻繁な再起動)には非対応 - MetricSage は単一異常根本原因を想定し、複数同時根本原因には未対応 - ハイパーパラメータ(時間ウィンドウ・隣接サンプリング数)の手動調整が必要 ## 関連 - [[グラフベースRCA]] — 本論文の中核手法(HWT + パーソナライズドランダムウォーク) - [[グラフニューラルネットワーク]] — MetricSage の基盤技術 - [[マイクロサービスアーキテクチャ]] — 対象システム - [[根本原因分析]] — 上位概念 - [[障害注入]] — 実験でのデータ収集手法(Chaos Mesh 使用) - [[Wuhan University]] / [[CSIRO Data61]] — 著者所属機関