## Memo
- スイッチとWebアプリケーションサーバから得られたデータセットで評価されている。
## Memo with LLM
https://claude.ai/chat/f1dc8528-1a57-462e-b415-a2f43460d9ae
### 論文情報
- **論文のタイトル**: Causal AI-based Root Cause Identification: Research to Practice at Scale - A technical and formal exploration
- **著者と所属**:
- Saurabh Jha (IBM Research)
- Ameet Rahane (IBM Instana)
- Laura Shwartz (IBM)
- Marc Palaci-Olgun (IBM Instana)
- Frank Bagehorn (IBM Research)
- Jesus Rios (IBM Research)
- Dan Stingaciu (IBM Instana)
- Ragu Kattinakere (IBM Instana)
- Debasish Banerjee (Guild Systems Inc., 元IBM)
- **カンファレンス/ジャーナル名**: 記載なし（テクニカルレポートまたはプレプリント）
- **発表年**: 2025年
### 論文概要
この論文は、分散システムにおける障害の根本原因特定のための因果AI手法について述べている。従来の分散トレーシングだけでは不十分な複雑な本番環境において、Pearlの因果推論フレームワークとBeta-Binomial推論を組み合わせた理論的基盤を持つ手法を提案し、IBM Instanaでの実装と実運用での有効性を実証している。
### 詳細解説
#### 問題設定
**入力データ**:
- 分散システムの各リクエストタイプ $R_j$ に対する成功/失敗の観測データ
- システムコンポーネント間の依存関係グラフ
- 各リクエストタイプの総試行回数 $n_j$ と成功回数 $Y_{R_j}$
**出力**:
- 各コンポーネント $C_i$ の健全性確率 $\theta_i$ の事後分布
- 障害確率に基づくコンポーネントのランキング
- 根本原因の候補リスト
**必要なデータ**:
- 分散トレーシングデータ（リクエストの成功/失敗情報）
- システムトポロジー情報（サービス間の依存関係）
- インフラストラクチャコンポーネントの配置情報
#### 提案手法
提案手法は以下の3つの主要コンポーネントから構成される：
**1. 構造因果モデル（[[構造的因果モデル|SCM]]）の簡約化**
各コンポーネント $C_i$ の健全性状態を $X_i \in \{0,1\}$ （0=故障, 1=正常）として表現し、リクエストタイプ $R_j$ の成功確率を以下のように定義：
$\gamma_j = P(Y_{R_j} = 1) = \prod_{\theta_i \in DependsOn(R_j)} \theta_i$
これはAND制約を表し、依存するすべてのコンポーネントが正常でなければリクエストが失敗することを意味する。
**2. Beta-Binomial推論モデル**
各コンポーネント $C_i$ の健全性確率 $\theta_i$ にBeta事前分布を設定：
$\theta_i \sim Beta(\alpha_i, \beta_i)$
観測されたリクエスト成功回数にBinomial尤度を適用：
$Y_{R_j} \sim Binomial(n_j, \gamma_j)$
この共役性により、事後分布も Beta分布となり、効率的な更新が可能：
$\theta_i|Y_{R_j} \sim Beta(\alpha_i', \beta_i')$
ここで、$\alpha_i' = \alpha_i + \#successes_i$, $\beta_i' = \beta_i + \#failures_i$
**3. 空間微分観測可能性の原理**
異なる障害は異なるリクエストタイプの失敗パターンを生成するという原理に基づき、観測された失敗パターンから根本原因を特定する。例えば、Example Systemにおいて：
- サービスBの障害: $R_1$ のみ影響
- ホスト $N_1$ の障害: $R_1, R_2, R_3$ すべてに影響
#### 新規性
**従来手法との比較**:
1. **相関ベース手法**: 多くのAPMツールは単純な相関係数や機械学習モデルを使用するが、「相関は因果関係を意味しない」という根本的な問題がある
2. **パターンマッチング手法**: 事前定義されたパターンに依存するため、新しい環境や変化するシステムに適応できない
3. **異常検知ベース**: 単純な異常検知は偽陽性を多く生成し、「イベントストーム」を引き起こす可能性がある
**本手法の新規性**:
- Pearlの因果推論フレームワークの厳密な適用
- do-calculusを用いた仮想的介入による因果関係の推定
- 訓練データを必要としない理論的に根拠のあるアプローチ
- リアルタイム推論が可能な計算効率（標準的なPythonライブラリより約1000倍高速）
#### 実験設定
**評価環境**:
- 内部の大規模分散システム環境
- 外部顧客環境（複数の複雑度レベル）
- Sterling Order Management System (OMS)環境
- WebSphere Application ServerとDB2データベースを含む環境
**評価指標**:
- 根本原因特定の精度（正確性）
- 平均復旧時間（MTTR）の短縮率
- 偽陽性の発生率
- アルゴリズムの収束時間
**比較対象**:
- 従来の手動トラブルシューティング手法
- [[Prometheus]]と[[Grafana]]を使用した従来の監視手法
- 単一トレース分析による手法
#### 実験結果
**定量的結果**:
1. **根本原因特定精度**: 約90%の症例で正確な根本原因特定に成功（本番スケールの企業アプリケーションでの内部実験）
2. **[[MTTR]]短縮効果**: 少なくとも80%のMTTR短縮を達成
3. **具体的事例での比較**:
- **事例1（ネットワークスイッチ障害）**:
- 従来手法: 12時間以上
- 提案手法: 5分未満で特定
- **事例2（WebSphere Application Server障害）**:
- 従来手法: DB2データベースを誤って特定
- 提案手法: WASインスタンスのスレッドプール枯渇を正確に特定
**Example Systemでの実証例**:
観測データが以下の場合：
- $R_1$: 300リクエスト中60成功（20%成功率）
- $R_2$: 200リクエスト中40成功（20%成功率）
- $R_3$: 500リクエスト中100成功（20%成功率）
Beta(0.1, 0.1)事前分布から開始し、アルゴリズムは以下に収束：
- $\mu_{N_1} \approx 0.10$ （最も疑わしい）
- $\mu_A, \mu_B, \mu_C \approx 0.95$
- $\mu_{N_2} \approx 0.90$
この結果は、すべてのリクエストタイプが $N_1$ に依存し、高い失敗率を示していることと一致している。
**制限事項**:
- 十分なテレメトリデータが利用できない場合、確実性の欠如により根本原因を表示しない場合がある
- 連続メトリクス（CPU使用率、メモリ使用量）は現在のモデルでは考慮されていない
## Abstract
現代のアプリケーションは、複数のモジュール、チーム、データセンターにまたがる大規模な分散システムとして構築されています。堅牢なエンジニアリングと回復戦略にもかかわらず、障害やパフォーマンス問題は不可避であり、重大なサービス中断を引き起こし、エンドユーザーに影響を及ぼすリスクがあります。システム信頼性を確保し、重要なサービス指標を維持するためには、迅速かつ正確な根本原因の特定が不可欠です。当社は、相関関係ではなく因果関係を重視した新たな因果関係に基づく根本原因特定（RCI）アルゴリズムを開発しました。このアルゴリズムは、IBM Instana-bridging研究に統合され、大規模な実践に適用されており、現在、エンタープライズ顧客によって生産環境で利用されています。「因果関係AI」を活用することで、Instanaは従来のアプリケーションパフォーマンス管理（APM）ツールと一線を画し、ほぼリアルタイムで問題を特定します。本論文では、Instanaの高度な障害診断機能について、RCIアルゴリズムの理論的基盤と実践的な実装の両面から解説します。実際の事例を通じて、当社の因果関係に基づくアプローチが、現在の複雑なシステム環境において信頼性とパフォーマンスを向上させる方法を示します。