# Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases ## 論文情報 | 項目 | 内容 | |---|---| | 掲載誌 | PVLDB, Vol.13, No.8, pp.1176–1189, 2020 | | DOI | https://doi.org/10.14778/3389133.3389136 | | 主著者所属 | Tsinghua University / Alibaba Group / Nankai University | | 主要システム | [[iSQUAD]](Intermittent Slow QUery Anomaly Diagnoser) | | 評価環境 | Alibaba OLTP Database（本番）| ## 概要(アブストラクト訳) クラウドデータベースの市場拡大に伴い、スロークエリの検知と排除はサービス安定性の観点で極めて重要である。先行研究は SQL の書き方が悪い等、内的要因に起因するスロークエリの最適化に注力してきた。本研究では、それとは異なる種類のスロークエリ——外的・断続的な性能問題(データベース層・マシン層)に起因し、他のスロークエリより危険な可能性がある——を発見し、**間欠的遅延クエリ(Intermittent Slow Queries, iSQ)**と命名する。 iSQ の根本原因を診断することは困難だが非常に有益なタスクである。本論文では、最小限の人間介入で iSQ の根本原因を診断するフレームワーク **[[iSQUAD]]** を提案する。アノマリ抽出(Anomaly Extraction)、依存関係浄化(Dependency Cleansing)、タイプ指向パターン統合クラスタリング(TOPIC)、ベイズ事例モデル(BCM)の 4 コンポーネントから成る。Alibaba OLTP Database の実データで評価した結果、iSQ 根本原因診断の平均 F1 スコア 80.4% を達成し、既存手法 DBSherlock を 49.2% 上回った。 ## 問題設定 ### iSQ の定義 SQL クエリ Q の第 $t$ 回実行 $Q_t$（観測実行時間 $X_t$）は以下を満たすとき iSQ と定義される: $X_t > z \text{ かつ } P(X_i > z) < \varepsilon$ - $z$: スロークエリ閾値(Alibaba では 1 秒) - $\varepsilon$: iSQ 確率閾値(Alibaba では 0.01) - $T$: 最近の実行回数($10^4$) すなわち、実行時間が閾値を超えるが、それが常態ではない(確率的に稀)なクエリが iSQ である。iSQ はスロークエリ全体の約 1% にすぎないが、Alibaba では 1 日数万件発生する。 ### クラウドデータベースにおける iSQ の困難さ 1. **発生頻度の増加**: 複数 DB インスタンスが同一物理マシン上で動作し、インスタンス間でリソース競合が起きやすい 2. **根本原因の多様性**: インスタンスマイグレーション・容量拡張・ストレージ分離(storage decoupling)等、クラウド固有の複雑なインフラが原因候補 3. **規模の大きさ**: 多数の DB インスタンスが存在し、iSQ の発生件数が膨大 ### 観察から得た 4 つの洞察 DBA の障害記録から以下を観察した: 1. **KPI スキャンが必要**: DBA は数百の KPI から症状を探す必要がある。KPI は 8 種類に分類(インスタンス側: CPU・I/O・ワークロード・TCP RT・メモリ、物理マシン側: CPU・I/O・ネットワーク、合計 59 本) 2. **異常タイプが重要**: 同一セットの KPI が異常でも異常タイプ(スパイク上昇・スパイク下降・レベルシフト上昇・レベルシフト下降・void)が異なれば根本原因が違う 3. **KPI 相関**: 複数 KPI が連動して異常化する(単方向・双方向の伝播) 4. **類似症状 = 類似根本原因**: 同一根本原因のクラス内では KPI の症状パターンが類似する ![[_attachments/p1176-ma/fig4-isq-cases.png]] *図: 間欠的遅延クエリの 2 典型ケース。ケース 1: 同一物理マシン上の 2 インスタンスで I/O リソース競合。ケース 2: フラッシュセール起因の CPU スパイク。* ### 3 つの技術的課題 | 課題 | 内容 | 既存手法の限界 | |---|---|---| | **異常多様性** | KPI 異常タイプを区別する必要があるが、従来の異常検知は正常/異常の二値のみ | dSPOT・iSST 等は異常タイプを返せない | | **ラベリングオーバーヘッド** | iSQ を 1 件ずつラベリングするのは現実的でない | テストベッド再現は大規模クラウドでは不可 | | **解釈性** | DBA は黒箱モデルを信用しない; 証拠の提示が必要 | 決定木は入力の微小変化で精度が崩れる | ## 提案手法: iSQUAD ![[_attachments/p1176-ma/fig5-isquad-framework.png]] *図: iSQUAD フレームワーク全体図。オフライン(クラスタリング+説明)とオンライン(根本原因診断+更新)の 2 段階構成。* ### 全体構成 iSQUAD はオフラインとオンラインの 2 ステージで動作する: - **オフライン(クラスタリング & 説明)**: 過去の iSQ データを投入 → Anomaly Extraction → Dependency Cleansing → TOPIC クラスタリング → BCM で代表事例抽出 → DBA がクラスタにラベリング - **オンライン(根本原因診断 & 更新)**: 新着 iSQ を受信 → Anomaly Extraction → Dependency Cleansing → クラスタとの類似度照合 → 根本原因を返す(既知クラスタなら即時、未知なら新クラスタ生成して DBA へ) ### コンポーネント 1: Anomaly Extraction(異常抽出) iSQ 発生時刻を起点として、前後 1 時間の KPI セグメントを収集し、5 秒サンプリングで異常タイプを判定する: - **スパイク検知**: ロバスト閾値法(Robust Threshold)——中央値 + MAD を使い、コーシー分布に従う。F1=98.7%、実行時間 0.19 秒/件 - **レベルシフト検知**: T 検定(T-Test)——前後の分布を 30 分窓で比較。F1=92.6%、実行時間 0.23 秒/件 いずれも比較手法(dSPOT: 81%/15.11 秒、iSST: 60.7%/6.06 秒)を精度・速度の両面で大幅に上回る。 ### コンポーネント 2: Dependency Cleansing(依存関係浄化) KPI ペア間の依存を信頼度(Confidence)で評価し、従属 KPI のアラートを除去することで KPI アノマリの独立性を保証する: $\text{confidence}(A \rightarrow B) = \frac{|A \cap B|}{|A|}$ 例: インスタンスの `docker.cpu-usage` が異常のとき物理マシンの `cpu.usage` も必ず異常になる（信頼度 ≈ 1）場合、後者を除去してインスタンス側のみを保持する。DBSherlock が使う相互情報量(MI)と比較して F1=95.24% と高い(MI: F1=57.14%)。 ### コンポーネント 3: TOPIC クラスタリング ![[_attachments/p1176-ma/fig6-topic-similarity.png]] *図: TOPIC の KPI タイプ別類似度計算。CPU・I/O・ネットワーク・ワークロード等のタイプごとに単純一致係数(SMC)を計算し、二乗平均で統合する。* iSQ の「パターン」(各 KPI の正常/異常タイプの組み合わせ)を定義し、KPI タイプを考慮した類似度を使ってクラスタリングする: $S_{ij} = \sqrt{\frac{\sum_{t=1}^{T} |k_{it}, k_{jt}|^2}{T}}$ ここで $|k_{it}, k_{jt}|$ は KPI タイプ $t$ における単純一致係数(Simple Matching Coefficient)。I/O の KPI が 15 本で CPU が 2 本でも、タイプ単位で正規化するため不均衡な支配を防ぐ。 KD 木を使って最近傍を探索し、類似度閾値 $\sigma$ を超える場合に統合する $O(n \log n)$ アルゴリズム。実験では $\sigma = 0.67$ のとき最適な 10 クラスタが得られた。階層クラスタリング・K-means・DBSCAN を全指標で上回る。 ### コンポーネント 4: Bayesian Case Model(BCM) クラスタごとに代表的な iSQ(プロトタイプ事例)と、診断に重要な KPI のサブセット(特徴部分空間)を抽出し、DBA に提示する。BCM の要件に合わせて、連続値の KPI タイムラインを Anomaly Extraction で離散化した異常タイプに変換した上で入力する。 BCM による KPI の削減率は平均 35.5%。ユーザー調査(DBA 46 名、初級/中級/上級 別)でラベリング正解率が平均 18.7% 向上した(上級 DBA では 84.4% vs 62.2%)。 ## 実験設定 - **データセット**: Alibaba OLTP Database の本番 iSQ データ 3 セット(1 日分 × 1 + 1 週間分 × 2)、合計 319 件を DBA がラベリング(1 週間かけて) - **分割**: 55% オフライン学習(174 件)、45% オンライン評価(145 件) - **根本原因**: 10 種類(表 2) - **評価指標**: F1 スコア、重み付き平均 F1、クラスタリング精度、正規化相互情報量(NMI) - **比較手法**: DBSherlock(SIGMOD 2016) | 根本原因 | オフライン | オンライン | |---|---|---| | インスタンス CPU 集中ワークロード | 27.6% | 34.5% | | ホスト I/O ボトルネック | 17.2% | 17.2% | | インスタンス I/O 集中ワークロード | 0.9% | 15.8% | | 同居スロー SQL | 8.6% | 9.0% | | CPU & I/O 集中ワークロード | 8.1% | 4.8% | | ホスト CPU ボトルネック | 7.5% | 4.1% | | ホストネットワークボトルネック | 6.9% | 4.1% | | 外部オペレーション | 6.9% | 3.5% | | データベース内部問題 | 3.4% | 3.5% | | 不明 | 2.9% | 3.5% | ## 実験結果 ### iSQUAD 全体評価 | 手法 | 重み付き Precision | 重み付き Recall | 重み付き F1 | 処理時間(秒/クラスタ) | |---|---|---|---|---| | DBSherlock | 42.5% | 29.7% | 31.2% | 0.46 | | **iSQUAD** | **84.1%** | **79.3%** | **80.4%** | **0.38** | | 改善量 | +41.6% | +49.6% | **+49.2%** | +17.4% | DBSherlock が根本原因 #2(Host I/O Bottleneck)・#6(Host CPU Bottleneck)・#8(External Operations)・#10(Unknown)で極端に低い精度になるのに対し、iSQUAD は全 10 種類でロバストな性能を示す。 ### 各コンポーネントの有効性 - Anomaly Extraction を従来の異常検知(二値出力)に置換すると、クラスタリング精度 & NMI が約 50% 低下 - Dependency Cleansing を除去しても数%の低下 - よって Anomaly Extraction が最も重要なコンポーネント ### ケーススタディ ![[_attachments/p1176-ma/fig9-case-study-timeline.png]] *図: DB 障害のタイムライン。11:50 に iSQ バーストが発生。DBA 手動診断は 18 分を要したが、iSQUAD は 40 秒で「データベース内部問題」の根本原因を正しく出力した。* 本番投入結果: iSQUAD を使って DBA が 10 の根本原因を持つ数百件の iSQ を診断するのに 80 分かかり、従来の 1 件ずつの手動診断(319 件 × 7.5 分 = 約 2,400 分)と比較して **約 30 倍の高速化**を達成した。 ## 新規性と貢献 1. **iSQ という問題を初めて定式化**: 外的・間欠的性能問題を根本原因とするスロークエリを体系化した最初の研究 2. **Anomaly Extraction の導入**: 異常の有無(二値)ではなく異常タイプを判定することで、KPI パターンの表現力を高める 3. **TOPIC の提案**: KPI タイプを考慮した新しいクラスタリングアルゴリズム。ラベリングオーバーヘッドを削減 4. **BCM のデータベース診断への応用**: ケースベース推論をデータベースドメインに初適用。case-subspace 表現を DBA に提示する 5. **Alibaba 本番展開**: Alibaba OLTP Database へのプロトタイプ展開を実施し、診断速度 30 倍を達成 ## 考察 ### 強み - **解釈性と精度の両立**: BCM により DBA に「代表事例 + 重要 KPI」を提示し、解釈性を担保しながら F1=80.4% を達成 - **ラベリング効率**: クラスタ単位でラベリングするため、新種の iSQ が出現しない限り 1 度のラベリングで足りる - **汎用性**: 各種ビジネス(オンライン小売・物流・エンタープライズコラボレーション)のデータで評価。入力(iSQ ログ + KPI)は一般的なデータベースに適用可能 - **効率**: 処理時間 0.38 秒/クラスタで DBSherlock より 17.4% 高速 ### 弱点・課題 - **全ゼロパターンの未対応**: KPI が全て正常なのにスロークエリが出る iSQ(MySQL コアの問題等)は診断対象外 - **単一根本原因の前提**: 複数根本原因の同時発生はレアだという DBA の経験則に依拠。独立・従属根本原因の両方を扱う枠組みへの発展が課題 - **閾値のマニュアルチューニング**: Anomaly Extraction のパラメータ($\varepsilon$・$z$・$\sigma$)は経験的に設定。自動チューニングは将来課題 - **DBSherlock との比較のみ**: 他の RCA 手法(グラフベース・LLM ベース等)との比較が不足 - **自動修復なし**: 根本原因の特定まで。障害修復の自動化は将来作業として残る ## 関連 - 比較手法: [[DBSherlock]](SIGMOD 2016) - 後継研究: [[FluxInfer]]([[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]])・[[CauseRank]]([[@2022__CCGrid__Generic and Robust Performance Diagnosis via Causal Inference for OLTP Database Systems]]) - 概念: [[間欠的遅延クエリ]] / [[データベース自律診断]] / [[異常検知]] / [[根本原因分析]] - エンティティ: [[Minghua Ma]] / [[Dan Pei]] / [[Shenglin Zhang]] / [[iSQUAD]] / [[Alibaba Group]] ## 出典 - Minghua Ma et al., "Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases," PVLDB 13(8): 1176–1189, 2020. https://doi.org/10.14778/3389133.3389136