# CausalBench [[IBM Research]] の [[Saurabh Jha]]・[[Jesus Rios]]・[[Naoki Abe]]・[[Frank Bagehorn]]・[[Larisa Shwartz]] が DSN-S 2024 で発表したマイクロサービスベンチマーク。介入的因果学習(interventional causal learning)を障害箇所特定に適用する際の実世界上の課題を意図的に表面化させるために設計されている。 ## アーキテクチャ 9 つのマイクロサービス(ノード A〜I と Redis ノード D)で構成される。 - **ノード A**: 入口ノード。すべてのリクエストのハブ - **ノード B**: ノード A から呼び出し。ノード C・E へのルート - **ノード C**: ノード B から呼び出し。ノード E へのルート - **ノード D**: Redis サービス(唯一のステートフルノード)。ノード H・I・F が接続 - **ノード E**: ノード C または B から呼び出し。100 リクエストに 1 回 info ログ出力 - **ノード F**: 無限ループでノード D のカウンタを監視。カウンタが 1 超で G を呼び出す - **ノード G**: ノード F から呼び出される - **ノード H**: ノード A から呼び出し。D のカウンタをインクリメント - **ノード I**: ノード A から呼び出し。D の別カウンタをインクリメント **すべてのノード**(D を除く)はステートレス。Flask ベースの Python Web サービスで、ポートと API を公開する。小さな計算タスク(ランダム文字列の base64 エンコード)を実行する。 ## 設計意図 ### なぜ新しいベンチマークを作ったか 実際の本番アプリケーション(IBM 内部)の知見を凝縮させているが、機密性からそのまま公開できない。一般的な OSS ベンチマーク(Robot-Shop 等)は §III の 3 課題を意図的に表面化する設計になっていない。 ### 各課題をどう露出するか 1. **Metric Invariance の破れ**: ノード E が「100 リクエストに 1 回 info ログを書く」という設計により、B への障害注入時に「msg rate」では E がオミッション障害として観測され、「CPU 使用率」では E の挙動が異なる。同一介入でもメトリクスによって異なる因果集合が生まれる。 2. **交絡変数(Load Invariance の破れ)**: ノード F がノード D を介してノード H・I と間接的に連結されている。C が障害を起こすと A 上の待ち行列変化で I への間接的な負荷変化が生じ、F→G 経路にも影響が及ぶ。外部負荷を固定しても内部負荷分布が変わることを示す。 3. **障害伝播の多経路性**: A→B→C→E と A→B→E の 2 経路が B を共有することで、B への障害が C 経由と直接の 2 経路で E に影響する。 ## 評価結果 Jha et al. (DSN-S 2024)による提案手法での評価: - 1× 負荷: **正解率 1.00 / 情報量 0.82** - 4× 負荷: **正解率 0.84 / 情報量 0.80** 先行手法 [Wang+ AAAI 2022](error rate のみ使用)は情報量 0.54 程度に留まる。 ## 関連 - 論文: [[@2024__DSN-S__Fault Localization Using Interventional Causal Learning for Cloud-Native Applications]] - 開発元: [[IBM Research]] - 開発者: [[Saurabh Jha]] / [[Jesus Rios]] / [[Naoki Abe]] / [[Frank Bagehorn]] / [[Larisa Shwartz]] - 概念: [[介入的因果学習]] / [[Fault Localization]] / [[障害注入]]