# Fault Localization Using Interventional Causal Learning for Cloud-Native Applications **出典**: DSN-S 2024 (54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks - Supplemental Volume) **著者**: [[Saurabh Jha]] / [[Jesus Rios]] / [[Naoki Abe]] / [[Frank Bagehorn]] / [[Larisa Shwartz]] (すべて [[IBM Research]] 所属) **DOI**: 10.1109/DSN-S60304.2024.00040 --- ## 概要 クラウドネイティブアプリケーションに対して、介入ベースの因果学習(interventional causal learning)を用いた障害箇所特定手法を実装・評価した実践報告論文。既存の介入的因果学習を障害箇所特定へ適用する際に成立しない 3 つの前提を明示化し、それらを表面化させるマイクロベンチマーク [[CausalBench]] を開発し、前提違反を克服する方法論を提案した。既存手法 [Wang+ AAAI 2022] および [Ikram+ NeurIPS 2022 = RCD] を正確さと情報量の両面で大幅に上回った。 --- ## 背景と動機 ### 問題設定 クラウドネイティブアプリケーションは数百〜数千のマイクロサービスから構成される。あるマイクロサービスの障害は連鎖的に他のサービスへ伝播し、トランザクション障害を引き起こす。障害のあるマイクロサービス(faulty microservice)を迅速に特定する障害箇所特定が、緩和のための急務となる。 分散トレーシングは一部の障害クラスを箇所特定するが、すべてのアプリケーションがトレースをサポートするわけではなく、オミッション障害(omission fault: ソフトウェアプロセスやチャネルが期待された動作を行わない障害)は手動調査が必要となる。 ### 先行研究の分類 - **観測・履歴データのみ使用する手法**: 未知の障害や負荷・環境変化への頑健性が低い - **ドメイン知識ベース(トポロジ等)の手法**: 大規模アプリケーションではトポロジ取得が困難で、コードの業務ロジックに由来する因果関係は捉えられない - **介入ベース手法**: 理論上、前提が成立すれば収束が保証される。ただし前提が実際には破れる --- ## §III: 前提と現実の乖離(Challenges) ### A. 障害伝播グラフはメトリクスによって異なる(Metric Invariance の破れ) > [!important] 前提の誤り > 既存手法の多くは「誤り伝播グラフはアプリケーションロジック(コード)にのみ依存する」と仮定する。実際には観測するメトリクスの種類も同様に重要である。 **図1**: 同じアプリケーションでも「エラーログ数」と「API リクエスト受信数」を観測メトリクスとして使うと、推定される因果グラフが異なる。 ![[_attachments/957000a141/image-003-001.png]] 例: Pattern 1(すべてステートレス、A→B→C→E)でノード B に障害注入 - エラーログ数で見ると: ノード A にエラーログが出る、ノード C へのリクエストが減少 - リクエスト数で見ると: オミッション障害(ノード E がリクエスト受信なしになる)を捕捉できる **含意**: 単一の因果グラフではなく、メトリクスごとに異なる因果集合(causal set)が存在する。 ### B. メトリクス充足性(Metric Sufficiency)の問題 **単一メトリクス**では不十分: 異なるメトリクスは異なる誤り伝播経路を明らかにする。 **全メトリクスの結合分布**も問題: 識別可能性(distinguishability)が低下し、どのサービスが障害元かを区別できなくなる。 例: A→B→C (B が障害)と A→B→C (C が障害)の両ケースで、全メトリクス結合では A・B・C のすべてが異常を示し、区別不可能になる。 ### C. 介入は負荷分布を変化させる(Intervention-Load Dependency) 因果性の文献では、交絡変数(confounder)が因果グラフ学習を乱すことが知られている。代表的な交絡変数は負荷(リクエスト数・パス)。 > [!important] 実証的知見 > 障害注入(介入)自体が負荷の定常状態分布を変化させる。ノード C が障害を起こすと、ノード A の待ち行列が速く処理され、ノード I へのリクエストが増加する——外部負荷を固定しているにもかかわらず。 **図2**: 交絡変数は介入に依存する。負荷をモデル化しないと、交絡因果エッジが生まれ、箇所特定の正確さが大幅に低下する。 --- ## §IV: 設計方針と方法論 ### 設計原則 1. アプリケーションのアーキテクチャ・ランタイム・技術に非依存 2. コードへのアクセスなし 3. ブラックボックスメトリクス(コンソールログ・CPU 使用率等)のみを監視 ![[_attachments/957000a141/image-005-001.png]] ### A. 障害注入器とデータ収集器 IBM が開発した障害注入プラットフォーム([Frank Bagehorn+ ASE 2022])を使用。Kubernetes の service 設定を操作し "http-service-unavailable" 障害を注入。1 度に 1 マイクロサービスへ注入し 10 分間実行。 ### B. 介入的因果学習(Algorithm 1) 各マイクロサービス $s$ に障害を順に注入し、各メトリクス $M$ に対して「障害注入時のメトリクス分布」と「正常時の分布」を Kolmogorov-Smirnov(KS)検定で比較。分布シフトが検出されたサービス $s'$ を因果集合 $C(s, M)$ に追加。 $C(s, M) = \{s' \mid \text{分布} D_s(M, s') \neq D_0(M, s')\}$ この手法では、すべてのメトリクスに対して「どのマイクロサービスが影響を受けたか」という生の情報のみを収集し、コンファウンダー除去の複雑な条件付けを回避する。 ### C. 障害箇所特定(Algorithm 2: 多数決ヒューリスティック) 本番環境でのテレメトリ $D(M, s)$ と正常時のテレメトリ $D_0(M, s)$ を比較し、異常なサービス集合 $A(M)$ を検出する。各メトリクス $M$ は「因果集合 $C(s^*, M)$ が $A(M)$ に最も近い」サービス $s^*$ へ投票する。最多票のサービスを根本原因と予測。 $\text{vote target} = \arg\max_s |A(M) \cap C(M, s)|$ ### メトリクス設計: 独立/依存メトリクスと派生メトリクス - **独立メトリクス**: 外部要因に支配されるもの(受信リクエスト数 等)。交絡の原因となる - **依存メトリクス**: 独立メトリクスに影響を受けるもの(CPU 使用率 等) - **派生メトリクス**: 依存メトリクスを独立メトリクスで割ることで交絡と相関を除去する 例: 「ログ数 / リクエスト数」= リクエストあたりのログ数。負荷変化の影響を除いた純粋なメトリクス。 --- ## §V: 実験設定 ### テストベッド Kubernetes クラスタ上に 2 つのマイクロサービスアプリを構築。 - **CausalBench**: 9 マイクロサービス(IBM 独自開発。§III の課題を表面化させるよう設計) - **Robot-Shop**: 12 マイクロサービス(Instana 提供のオープンソース e コマースアプリ) 負荷生成には Locust を使用。10 ユーザー、各 userflow のスループット 50 リクエスト/秒。 ### CausalBench の設計 [[CausalBench]] は §III で特定した課題を意図的に表面化させるマイクロベンチマーク。 **アーキテクチャ**: - ノード A: 入口ノード(すべてのリクエストのハブ) - 経路 (a): A→B→C→E (ステートレス連鎖) - 経路 (b): A→B→E (ショートカット) - 経路 (c): A→H→D(Redis, ステートフル)→F(ポーリングデーモン)→G - 経路 (d): A→I→D(Redis) - ノード D のみステートフル(Redis サービス)。F は無限ループでカウンタ監視 **設計意図**: ノード E は「I am okay!」ログを 100 リクエストに 1 回だけ書き込む(オミッション障害の検出をテスト)。ノード F は別パスの影響を間接的に受けるポーリング機構(交絡変数の実証用)。 --- ## §VI: 結果 ### 正解率と情報量 情報量(informativeness) = $(n - x) / (n - 1)$。$n$ は総マイクロサービス数、$x$ は予測された根本原因集合のサイズ。値が 1.0 なら単一のサービスへの予測。 | アプリ | 負荷 | 正解率 | 情報量 | |---|---|---|---| | CausalBench | 1× | 1.00 | 0.82 | | CausalBench | 4× | 0.84 | 0.80 | | Robot-shop | 1× | 1.00 | 0.80 | | Robot-shop | 4× | 0.81 | 0.88 | **学習は 1× 負荷**、**テストは 1× と 4× 負荷**の 2 条件で評価。先行研究 [23][24] は負荷変化をまたいだ評価を行っていなかった。 4× 負荷での若干の正解率低下は、交絡・相関の除去手法が完全ではないことを示す。 ### メトリクスの役割(Table II) 派生メトリクス(derived metrics)の有効性: | | 生メトリクス(msg rate) | 生(cpu) | 生(全) | 派生(msg rate) | 派生(cpu) | 派生(全) | |---|---|---|---|---|---|---| | CausalBench | 0.54 | 0.60 | 0.73 | 0.62 | 0.70 | **0.80** | | Robot-shop | 0.58 | 0.51 | 0.66 | 0.60 | 0.64 | **0.88** | (情報量での比較。先行研究 [23] は error rate のみで CausalBench 0.54 程度の性能) **主な観察**: 1. 単一メトリクスは不十分 2. 生メトリクスの全体使用は、相関・交絡で多数決が偏り情報量が低下 3. 派生メトリクスが交絡と相関を除去し最高性能を達成 ### メトリクスごとの因果集合の相違 - msg rate での B への介入 → 因果集合: {B, A, E}(E は B の障害でリクエストが止まり info ログが出なくなる = オミッション障害) - CPU 使用率での B への介入 → 因果集合: {B, C, E} 単一の因果グラフを仮定する Ψ-FCI アルゴリズムは、このメトリクス依存性に対処できない。 --- ## 関連研究との比較 | 手法 | メトリクス | 交絡対処 | 負荷変化評価 | |---|---|---|---| | Wang+ AAAI 2022 [23] | error rate のみ | なし | なし | | Ikram+ NeurIPS 2022 [24] = RCD | 複数メトリクス | なし | なし | | **本論文** | 派生メトリクス(複数) | 派生メトリクスで対処 | あり(1× vs 4×) | --- ## 貢献まとめ 1. 介入的因果学習の 3 つの限定前提の特定(Metric Invariance / Metric Sufficiency / Load Invariance) 2. [[CausalBench]] の開発(9 マイクロサービス、上記課題を表面化する設計) 3. 派生メトリクス + KS 検定 + 多数決ヒューリスティックによる方法論の提案 4. CausalBench と Robot-Shop での評価(先行手法を正解率・情報量で上回る) --- ## 関連 - 概念: [[Fault Localization]] / [[介入的因果学習]] / [[因果推論ベースRCA]] / [[因果発見]] / [[障害注入]] - エンティティ: [[CausalBench]] / [[IBM Research]] / [[Saurabh Jha]] / [[Jesus Rios]] / [[Naoki Abe]] / [[Frank Bagehorn]] / [[Larisa Shwartz]] - 参照先: [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]](IBM Research の FSF: 分散トレーシングベース障害箇所特定) ## 出典 - DSN-S 2024 本文 (`.raw/papers/957000a141.pdf`)