グラフベースRCA - yuuk1's Digital Garden

# グラフベースRCA ## 定義グラフベース RCA(Graph-based Root Cause Analysis)は、システムコンポーネント間の依存関係・アラーム・イベントをグラフ G = (V, E) として表現し、グラフ上のスコアリングや伝播アルゴリズムによって根本原因となるコンポーネントを特定する手法群の総称。先行研究(MonitorRank, CloudRanger, AutoMAP 等)がサービス間の依存グラフ上でランダムウォークを用いてきた流れの一環として位置づけられる([[根本原因分析]] §横断的知見参照)。 Grano([[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]])はこの系譜において、**論理・物理の二層トポロジを統合した異常グラフ**と、**アラームの IDF スコアリング + 信頼度スコア伝播**という独自のアルゴリズムを提案した点で位置づけられる。 ## 横断的知見 - **論理・物理 2 層のトポロジ統合が偽陽性低減に寄与する**: Grano は Keyspace/Shard/Replica(論理)と Zone/Rack/Host/Pod(物理)の両階層をノードとして統合した異常グラフを構築することで、「どのコンポーネントが根本原因に近いか」を物理的なインフラ上での実際の影響伝播を踏まえて評価できるようにした。先行研究の多くがサービス依存グラフ上のサービスノードのみを扱うのに対し、物理層を含めることで「同一ホスト上の別コンポーネントが根本原因」という障害クラスへの対応が可能になる。(Source: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §2.1, §3 Step 1) - **IDF(逆頻度)型アラームスコアリングが「全体的なノイズアラーム」の影響を構造的に下げる**: Grano の Alarm Edge Score は $s_{e(a,c)} = \sigma_{e(a,c)} \log(|C|/|C_a|)$ と定義され、多くのコンポーネントで発火しているアラームほど個々のコンポーネントへの関連度が低いと評価する。これは情報検索の TF-IDF と同じ直観をグラフの辺スコアリングに移植したものであり、広域的なスパイク(例: メンテナンス起因の大規模アラーム)が RCA スコアに与える影響を抑制する設計として機能する。(Source: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §3 Step 2) - **MonitorRank・CloudRanger のランダムウォーク系と Grano のスコア伝播系は「グラフ上の拡散」という設計を共有しながら、伝播のダイナミクスが異なる**: MonitorRank(Kim+ SIGMETRICS 2013)は異常コンポーネントとの相関に比例した遷移確率のパーソナライズドランダムウォークを採用し、CloudRanger(Wang+ CCGrid 2018)は PC アルゴリズム因果グラフ + 二次ランダムウォークで拡張した。Grano はランダムウォークでなく決定論的なスコア伝播($p_c$ 計算)を採用しており、各ノードが「隣接ノードの平均スコアを γ 倍して受け取る」という乗算型伝播で連結成分末端(Zone・Keyspace)まで伝播させる。(Source: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] §3 Step 4; [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]]; [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]]) - **クラウドインフラ(物理デバイス層)向けグラフ RCA は「歴史的障害知識 + 現在の物理接続性」の時空間統合が鍵**: BSODiag(Duan+ arXiv 2025)は Alibaba Cloud クラウドインフラ(IDC・クラウドネットワーク・クラウドサーバーの 3 ドメイン)向けのイベント原因グラフ方式。Grano が「論理・物理 2 層トポロジ + IDF スコアリング」を採用したのに対し、BSODiag は (1) 歴史的障害データから Apriori で掘り出した **障害知識グラフ $G_f$**(信頼度スコア)と (2) CMDB から取得した **現在のデバイス物理接続性**(距離スコア)を組み合わせた時空間相関強度 $w_{ij} = \exp(p_{ij}.\text{conf}) \cdot \text{dist}(e_i, e_j)$ を辺重みとして定義する。これにより「過去に高頻度で共起した障害ペア」と「現在の物理的隣接性」の両方を根拠として根本原因を推定できる。アブレーション実験で両方の除去が性能低下を引き起こすことが確認された(図7)。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §IV-B〜C, §V-D) - **インスタンスレベル RCA には「サービス・インスタンス・ホスト」の 3 層異種グラフが必要で、サービスグラフのみでは不十分**: MicroIRC([[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]])の HWT(Heterogeneous Weighted Topology)は、サービスノード・インスタンスノード・ホストノードの 3 種を統合した重み付き異種グラフを構築し、パーソナライズドランダムウォークを実行する。既存手法(MicroRCA・CloudRanger・MonitorRank)がサービスノードのみのグラフ上でランダムウォークを行うのに対し、MicroIRC はインスタンスノードにサービスメトリクスとの最大相関値(MC)を辺重みとして付与し、同一サービスの複数インスタンス間を識別する。データセット C・D では HWT の使用により、インスタンス+ホストのみのトポロジ(データセット A・B)に対して大幅な精度向上を示した。(Source: [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]] §3.2.2) - **パーソナライズドランダムウォーク + 機械学習モデルの 2 段階設計が新種障害への頑健性と精度を両立させる**: MicroIRC は (1) HWT 上のパーソナライズドランダムウォークで候補セットを生成し、(2) 候補セットと時系列メトリクスを GraphSage ベースの MetricSage に入力して最終スコアを算出するという 2 段構成を採用する。DejaVu(GAT による特徴適合+失敗依存グラフ)が新種障害 10% 混入で精度 -28% となるのに対し、MicroIRC は訓練障害種別割合を 0.4 まで減らしても安定した性能を維持する。ランダムウォーク段が「既存トポロジ構造の活用」、MetricSage 段が「リアルタイムメトリクスの学習」を担当することで、各段の役割分離が頑健性の源泉となっている。(Source: [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]] §4.7) - **マルチアトリビュート・パーソナライズドランダムウォーク(MAPR)は「時刻優先度 × アウタージとの距離」で初期スコアを定義する**: BSODiag の MAPR は Grano の決定論的スコア伝播と MonitorRank の確率的ランダムウォークの中間的アプローチで、ノードのパーソナライズスコアを $u_i = \exp(-t) \cdot \text{dist}(e_i, e_o)$ で初期化する。$\exp(-t)$ は時刻が早い障害に高スコアを与え、$\text{dist}(e_i, e_o)$ はアウタージノードとの物理的近さを加味する。2 つのドメイン知識(「根本原因は早く発生する」「根本原因は影響範囲が広い」)をランダムウォーク初期条件に組み込んだ設計。(Source: [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] §IV-C2) ## 未解決の問い - Grano の RCR スコア伝播は「接続コンポーネントの平均スコアの γ 倍」という単純な集約を採用しているが、物理・論理の 2 層トポロジが混在するとき、層をまたぐ辺の重み付けはどう設計すべきか。異なる粒度の階層を同一グラフに混在させると「Zone ノードが常に高スコアを受け取る」という構造バイアスが生じないか。 - IDF スコアリングは「よく発火するアラームは重要度が低い」という仮定に依存するが、本番障害において広域的に発火するアラームが実際の根本原因を示すケース(例: 共通インフラ障害)は IDF によって過小評価される可能性がある。この「広域アラームが根本原因」というケースにどう対処するか。 - Grano は first-level の検知モデルとして密度ベースクラスタリング・加法分解予測・指数平滑化の 3 種を採用しているが、それぞれの検知精度がグラフ層の RCR 精度にどの程度影響するか。BARO が「異常検知時刻のずれへの非感度設計」で頑強性を得た([[根本原因分析]] §横断的知見)ことと対比して、Grano は第 1 段階の偽陽性をどこまで IDF とスコア伝播で吸収できるか。 - Grano は 2019 年時点でグラフデータベースに依存した設計をとるが、数千のホスト・数百万のメトリクスで異常グラフがどの程度まで拡大するか。グラフ構築と伝播アルゴリズムの計算コストのスケーラビリティは定量評価されていない。 - BSODiag の障害知識グラフは Apriori ベースの頻度マイニングに依存しているが、障害パターンが進化するクラウド環境で知識グラフを継続的に更新するための増分学習機構はどう設計するか。新規障害種別(初見パターン)は知識グラフにない場合どう扱うか。 - グラフ RCA の適用範囲をマイクロサービス(論理依存グラフ)とクラウドインフラ(物理接続グラフ)の両方にまたがって統合するとき、グラフの結合方法と伝播ルールをどう標準化するか。 - MicroIRC の HWT では MC(最大相関値)を辺重みとして使用するが、メトリクス間の相関と実際の障害因果関係の乖離(「相関 ≠ 因果」問題)が辺重みの歪みを生じさせるリスクをどう軽減するか。 - MicroIRC の MetricSage + パーソナライズドランダムウォーク 2 段構成は、大規模マイクロサービスシステムではランダムウォーク段が 90% 以上の処理時間を占めボトルネックになる。サービストポロジのスケールに合わせてランダムウォークの計算量を削減する方法はあるか(例: 部分グラフの事前剪定、近似ランダムウォーク)。 ## 関連 - 親概念: [[根本原因分析]] - 兄弟概念: [[サービス依存グラフ]] / [[因果推論ベースRCA]] / [[クラウドインフラ障害診断]] - 関連ソース: [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]] / [[@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]] / [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]] / [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]] - 関連 structures: `structures/` の MOC(例: AIOps.MOC.md) ## 出典 - [[@2019__VLDB__GRANO - Interactive Graph-based Root Cause Analysis for Cloud-Native Distributed Data Platform]](§2 システムアーキテクチャ、§3 グラフベース RCR の 5 ステップ) - [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]](MonitorRank の伝播設計) - [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]](PC アルゴリズム + 二次ランダムウォーク) - [[@2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Applications Automatically]](3 種ランダムウォーク) - [[@2025__arXiv__BSODiag - A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems]](§IV-B 時空間障害相関、§IV-C MAPR・PPI) - [[@2026__Elsevier__MicroIRC - Instance-level Root Cause Localization for Microservice Systems]](§3.2.2 HWT 構築、§3.2.3 パーソナライズドランダムウォーク + MetricSage 細分割、§4.5〜4.7 実験比較)