# 間欠的遅延クエリ ## 定義 間欠的遅延クエリ(Intermittent Slow Queries, iSQ)は、クラウドデータベースにおいて「通常は応答が速い SQL クエリが、断続的・偶発的に著しく遅延する」現象を指す。SQL クエリ $Q$ の第 $t$ 回実行 $Q_t$（観測実行時間 $X_t$）は以下を満たすとき iSQ と定義される: $X_t > z \text{ かつ } P(X_i > z) < \varepsilon$ ここで $z$ はスロークエリ閾値、$\varepsilon$ は iSQ 確率閾値(Alibaba OLTP Database では $z=1$ 秒、$\varepsilon=0.01$)。つまり、実行が遅くなること自体は稀(確率 1% 未満)だが、それが発生したときに閾値を超えるクエリが iSQ である。([[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]]) iSQ は、内的要因(SQL の書き方・インデックス不足)に起因する通常のスロークエリとは区別される。iSQ の原因は**外的・断続的な性能問題**(データベース層・マシン層)にある。具体的には: - 同一物理マシン上の複数 DB インスタンスによるリソース競合(CPU・I/O・ネットワーク) - インスタンスマイグレーション・容量拡張・ストレージ分離(storage decoupling) - 突発的なワークロードスパイク(フラッシュセール等) - データベースバックアップ等の外部オペレーションによる I/O 圧迫 ## iSQ の特性 - **割合は小さいが件数は多い**: Alibaba OLTP Database ではスロークエリ全体の約 1% だが、1 日に数万件発生する - **体感影響が大きい**: 平時は高速に返るクエリが突然遅延するため、エンドユーザーの体験を著しく損なう(ウェブページの読み込み遅延等) - **診断が困難**: 発生が断続的なため再現が難しく、DBA が 1 件を手動診断するのに数十分〜数時間を要する - **多様な根本原因**: Alibaba の実績では 10 種類の根本原因カテゴリ(CPU・I/O・ネットワークのボトルネック、外部オペレーション、データベース内部問題等)が確認されている ## 根本原因の分類(Alibaba OLTP Database の実績) | 根本原因 | 対処 | |---|---| | インスタンス CPU 集中ワークロード | インスタンス CPU のスケールアップ | | ホスト I/O ボトルネック | ホスト I/O のスケールアウト | | インスタンス I/O 集中ワークロード | インスタンス I/O のスケールアップ | | 同居スロー SQL | スロークエリのレート制限 | | CPU & I/O 集中ワークロード | 両方のスケールアップ | | ホスト CPU ボトルネック | ホスト CPU のスケールアウト | | ホストネットワークボトルネック | ネットワーク帯域の最適化 | | 外部オペレーション | 外部オペレーションのリソース制限 | | データベース内部問題 | DB の最適化 | | 不明 | さらなる診断と最適化 | ## 診断アプローチ: iSQUAD iSQ 診断の自動化フレームワークとして [[iSQUAD]] が提案されている。KPI の異常タイプを活用したクラスタリングとベイズ事例モデルを組み合わせ、DBA のラベリング負荷を削減しながら F1=80.4% の診断精度を達成した。詳細は [[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]] を参照。 ## 横断的知見 - **iSQ は「外部起因スロークエリ」として従来の SQL 最適化研究と補完的な関係にある**: 従来のスロークエリ研究はインデックス追加・SQL 書き換え等の内部最適化に注力してきたが、iSQ は外的な性能問題が原因であり、SQL レベルの対処では解決できない。クラウドデータベース特有の問題(マルチテナンシー・リソース共有・ストレージ分離)が iSQ 発生を構造的に増加させる。([[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]]) - **異常タイプの区別が診断精度の律速である**: 同一の KPI セットが異常であっても、スパイクかレベルシフトかで根本原因が異なる。従来の二値異常検知(正常/異常)では区別できず、iSQUAD が Anomaly Extraction を核心コンポーネントとして導入した理由がここにある。Anomaly Extraction を取り除くとクラスタリング精度が 50% 近く低下する実証がある。([[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]]) - **KPI 間の依存関係を除去しないと診断が歪む**: KPI は互いに相関しており、根本原因 KPI の異常が従属 KPI に伝播する。DBSherlock が相互情報量(MI)で依存除去を試みて F1=57.14% にとどまったのに対し、iSQUAD は Confidence ベースの連関規則学習で F1=95.24% を達成した。この差が最終的な診断精度の差に反映される。 ## 未解決の問い - クラウドデータベースの進化(サーバーレス化・コンテナ化・マネージドサービスの多様化)に伴い、iSQ の根本原因の分布はどう変化するか。Alibaba での 10 種類の分類は他のクラウドプロバイダや DB エンジン(PostgreSQL・Aurora 等)でも適切か。 - 全 KPI が正常なのに iSQ が発生する「全ゼロパターン」(MySQL コアの問題等)は、現在の KPI ベース診断の盲点である。ログやクエリ実行計画等の補助データを使った診断拡張が必要か。 - LLM を iSQ 診断に活用する場合、ベイズ事例モデルの「代表事例+重要 KPI」という提示形式より効果的な解釈インターフェースがあるか。[[データベース自律診断]] の最新の LLM ベース手法(D-Bot・DBAIOps)は iSQ 診断に適用できるか。 - iSQ の診断から修復(スケールアップ・レート制限等)までの自動化はどのように実現するか。iSQUAD は診断止まりで自動修復は将来課題として残っている。 ## 関連 - 親概念: [[データベース自律診断]] / [[AIOps]] - 主要システム: [[iSQUAD]] - 隣接概念: [[異常検知]] / [[根本原因分析]] - 主ソース: [[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]]