# AutoDebugger: Efficient Root Cause Analysis for Anomaly Jobs Navigation: [[根本原因分析]] | [[データベース自律診断]] | [[Sparkジョブ異常診断]] | [[AIOps]] > [!abstract] 概要 > 今日のクラウド環境の複雑なインフラにおいて、Spark ジョブの性能問題を分析することは難しい課題である。本論文では、Spark ジョブの実行時異常の理解を促進し、自動トリアージを支援するツール AutoDebugger を紹介する。AutoDebugger は機械学習アルゴリズムと白箱予測モデルを組み合わせ、Spark Metrics Service と統合することで包括的な分析パイプラインを実現する。AutoDebugger は性能上の外れ値を効率的に特定し、徹底的な根本原因分析を行う。特に、AutoDebugger は既存の RCA アルゴリズムを改善し、10 倍以上の高速化を実現した。実験により、AutoDebugger が実世界の Microsoft Fabric Spark ジョブにおける異常の根本原因を精確に特定し、スケーラビリティと準リアルタイム分析能力を確保することが検証された。 ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | AutoDebugger: Efficient Root Cause Analysis for Anomaly Jobs (Extended Abstracts) | | 著者 | Fathelrahman Ali (Google)、Yiwen Zhu、Lie Jiang、Zhen Li、Manting Li、Kun Huang、Lijing Lin、Xiaolei Liu、Long Tian、Subru Krishnan (Microsoft) | | 掲載 | VLDB Workshop AIDB 2025 (Applied AI for Database Systems and Applications) | | ページ数 | 5 (Extended Abstract) | | 公開 | 2025 年 | ## 概要 AutoDebugger は Microsoft Fabric 環境の Spark ジョブを対象とした自動根本原因分析ツールである。Fabric では 1 週間に 850 件以上の定期 Spark ジョブが実行され、そのうち 100 件以上が異常を示した(平均実行時間の 10,000% 超を記録するものも存在)。こうした異常の手動トリアージは低速かつ誤りが多い。 本システムは以下の 3 つの貢献をまとめる。 1. **ドメイン知識の組み込み**: メトリクス間の具体的な関係を分析に反映する。 2. **HybridRCA の開発**: 従来の RCA アルゴリズムに対して 10 倍以上のレイテンシ改善を達成する新アルゴリズム。 3. **本番展開**: Microsoft Fabric のすべてのリージョンで展開済みであり、多くのユーザーに利用されている。 ## 問題設定 ### 対象 同一の Spark Job Definition (SJD) またはノートブックから繰り返し実行される定期ジョブ(Recurrent Job)において、実行時間が期待値を大幅に超えた異常インスタンスの根本原因を特定する問題を扱う。 形式的には: - 観測対象変数 $X_0$(例: ジョブ実行時間) - 因果グラフ $G$ 上の各ノード $u \in V$に対し、帰属スコア $S_G(u \to X_0)$ を計算する - 直接原因の集合 $\Phi$ について: $\sum_{u \in \Phi} S_G(u \to X_0) = E^*[X_0] - E[X_0]$ ### 課題 Fabric 環境では以下 4 つの困難がある。 - **分散ログ**: ログが分散・断片化しており、人手での探索が現実的でない。 - **効率要件**: ジョブ完了直後に準リアルタイムで分析する必要があり、高レイテンシは許容できない。 - **ラベルデータ不足**: 根本原因ラベル付きデータが入手できないため、教師あり分類モデルが使えない。 - **特徴相関**: 40 件以上のメトリクスに対して黒箱予測器は精度が出ない。 ## 提案手法 ### Spark Metrics Service (SMS) SMS は Spark リスナーを実装し、メトリクスを収集・後処理して Cosmos DB に格納する(図1)。Fabric Spark ジョブ向けに読み込み時間・割り当てコア数・シャッフル時間など 40 件以上のメトリクスを提供する。 ![[wiki/sources/_attachments/AIDB25_4/fig1-spark-metrics-service-architecture.png]] *図1: Spark Metrics Service のエンドツーエンドアーキテクチャ。Metrics Listener(Spark ドライバー)が Azure Storage にメトリクスを収集し、Cosmos DB に保存して Metrics Service が API 経由でクライアントに提供する。* ### HybridRCA アルゴリズム 従来の介入テストベース RCA(do-calculus 適用)は $O(2^N)$ の計算量を要し、40 件以上の変数では 1 ジョブあたり約 100 秒かかる。HybridRCA は「分割統治」アプローチを do-calculus に適用し、この問題を解消する。 **因果グラフ構造(図2)**: ドメイン知識と SMS メトリクスから構築した有向因果グラフ。ReadRows → ReadBytes → ReadTime → IOTime → ExecutionTime → ApplicationRunTime → TotalDuration などの連鎖が含まれる。 ![[wiki/sources/_attachments/AIDB25_4/fig2-causal-graph-metrics.png]] *図2: Fabric Spark メトリクスのサブセットにおける因果関係。ShuffleTime と IOTime が顕著ノード(prominent node)として識別される。* #### グラフ分解 **顕著ノード(Prominent Node)**: 親ノードへの寄与を兄弟ノードから独立して分離できる特殊なノード。この独立性がグラフ分割の接合点となる。 分解手順: 1. グラフ $G$ を $G_1$($Y_0$ のサブグラフを除き $Y_0$ をリーフとして置き換えた残部)と $G_2$($Y_0$ をルートとするサブグラフ)に分割する。 2. $G_1$ と $G_2$ でそれぞれ独立に RCA を実行する。 3. 帰属スコアを結合規則で合成する: - $X_1, ..., X_c, Y_0$ については: $S_G(u \to X_0) = S_{G_1}(u \to X_0)$ - $Y_1, ..., Y_e$ については: $S_G(u \to X_0) = S_{G_2}(u \to Y_0) \times \frac{S_{G_1}(Y_0 \to X_0)}{E^*(Y_0) - E(Y_0)}$ #### 時間計算量の改善 - 元の手法: $O(2^N)$($N$ = 変数数) - HybridRCA: $O(\sum_i 2^{n_i})$($n_i$ = 各サブグラフのノード数) 変数間に線形関係があれば自然にサブグラフが小さく分割され、最大の恩恵を得られる。 ## 新規性 1. **白箱モデルとドメイン知識の統合**: 決定論的関係(ReadRows → ReadBytes)や線形関係(CPUTime、ExecutorComputingTime、OverheadTime)を利用して $O(2^N)$ の一部を $O(1)$ や分割統治に置き換える。 2. **顕著ノードによるグラフ分解**: 「独立に寄与分離できるノード」を軸に大規模な因果グラフを管理可能なサブグラフへ分解する。 3. **実本番展開**: Microsoft Fabric の全リージョンに展開された検証済みシステム。ラベルなしで稼働する点が実用上の重要な特性。 ## 実験設定 ### 本番ワークロード評価 - 実 Fabric 定期ジョブグループ 30 件以上、2,000 件超のジョブインスタンスを対象。 - 各ジョブグループは 50 件以上のインスタンスを持ち、少なくとも 1 件の異常を含む。 ### 合成シナリオ評価 以下 5 シナリオを網羅する合成異常データジェネレータを開発した。 | シナリオ | 内容 | |---|---| | エグゼキュータ縮小 | 8 エグゼキュータ → 3 に削減 | | エグゼキュータ拡大 | 3 エグゼキュータ → 8 に拡大 | | クエリ変動 | 同クエリが日ごとに微変化 | | データ量増大 | 100 GB → 1,000 GB のデータ拡大 | | データ量縮小 | 1,000 GB → 100 GB のデータ縮小 | ## 実験結果 ![[wiki/sources/_attachments/AIDB25_4/fig4-rca-results-recurrent-jobs.png]] *図4: 定期ジョブグループにおける根本原因分析の結果分布(対数スケール)。最も多く検出された根本原因はアイドル時間の増大(ユーザーエラー・プロビジョニング遅延に起因)。* | 指標 | 従来手法 | HybridRCA | |---|---|---| | 平均 RCA 時間(1 異常ジョブあたり) | 147 秒 | 12 秒 | | 速度改善 | — | **約 12 倍** | | スコア寄与率 5% 超の根本原因ランキング | — | 一致(元の do-calculus と同等) | | 平均誤差 | — | 0.4% | | 最大絶対誤差 | — | 5% | 合成シナリオ 5 件すべてで正しい根本原因を一貫して特定した。 ## 考察 - **主要根本原因はアイドル時間**: 本番データでは長いアイドル時間が支配的で、ユーザーエラーとプロビジョニング遅延が主因とされた。 - **ラベルなし実運用の重要性**: ラベル付き訓練データを要さない設計が大規模本番展開を可能にした核心である。 - **将来方向**: 顕著ノードの定義拡張(より細粒度な分解)・他のグラフベース RCA 手法への汎化・自律データベースシステムへの組み込み(根本原因シグナルを適応制御ループに送り込む)を計画する。 - **構造学習との統合**: NOTEARS や FCI などを用いた因果グラフの自動構築を将来課題とする。 ## 強み - 10 倍超の高速化を精度をほぼ落とさずに実現した実装済みシステム。 - ラベルデータ不要で本番展開可能。 - Microsoft Fabric 全リージョンで稼働済みという強い実証。 - ドメイン知識(決定論的・線形関係)の組み込みが効率と精度の両立を支える設計。 ## 弱点・課題 - 5 ページの Extended Abstract であり、理論的証明・アブレーション実験・ベースライン比較の詳細は限定的。 - 因果グラフをドメイン知識で手動構築しており、新環境への適用には専門家の関与が必要。 - 合成シナリオの多様性は限定的(5 種類のみ)。 - 評価が Microsoft Fabric Spark 限定であり、他のクラウドプラットフォームへの汎化は未検証。 ## 出典 - (Source: [[.raw/papers/AIDB25_4.pdf]]) - Fathelrahman Ali ほか, "AutoDebugger: Efficient Root Cause Analysis for Anomaly Jobs," VLDB Workshop AIDB 2025.