# Multivariate Log-based Anomaly Detection for Distributed Database Navigation: [[ログベース異常検知]] | [[異常検知]] | [[AIOps]] > **一文要約**: 分散型データベース固有の 11 種異常を注入した 216 GB データセットを構築し、多変量ログ(複数ノードのログを統合)による異常検知フレームワーク MultiLog を提案、既存手法を多ノード分類で約 12% 上回った。 ## アブストラクト(和訳) 分散型データベースは大規模クラウドシステムの基盤インフラである。分散 DB における異常検知はソフトウェア可用性の維持に不可欠だが、既存手法は主に Loghub を使って開発されており、分散 DB 固有の異常に対応したデータセットが存在しない。また、複数異常・複数ノードのログを含むデータセットも不在である。結果として、スタンドアロンシステム向けに設計されたモデルは分散 DB に適用できず、単一ノードの異常に基づいてクラスタ全体を異常と判定する一般的な手法は偽陽性率が高い。本論文は分散 DB のログが持つ固有の異常特性と多変量性を扱い、初の公開・包括的な多変量ログデータセット(216 GB、9 億レコード)を提供する。このデータセットを用いた広範な実証研究により、多変量ログデータで SOTA 手法の有効性を評価した。単一ノードのログだけでは正確な異常検知に不十分であるという知見に基づき、分散 DB 向け多変量ログベース異常検知手法 MultiLog を提案する。実験結果は MultiLog が既存 SOTA 手法を多ノード分類で約 12% 上回ることを示す。 ## 問題設定 ### 対象システム 分散型データベース(Google Spanner、Alibaba OceanBase、PingCAP TiDB、[[Apache IoTDB]])はクラウドシステムの基盤として広く普及している。Alibaba Cloud では断続的な低速クエリ(iSQ)が年間数十億ドルの損失をもたらし、Amazon の報告では 0.1 秒の遅延が 1% の売上損失につながる。([[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]] も同様の事例を扱う。) ### 既存手法の課題 既存のログベース異常検知モデルは Loghub 上で開発されており、以下の 3 つの課題がある: 1. **分散 DB ログデータセットの欠如**: Loghub に分散 DB 固有のデータセットがない。BGL・Thunderbird・HPC はスタンドアロン、Hadoop・Spark はフレームワーク、HDFS・Zookeeper はファイルシステムで、分散 DB の固有な障害特性を反映しない。 2. **複数異常・複数ノードのログが不在**: 公開データセットの多くは注入した異常の種類を開示せず、開示している場合も種類が限定的(Hadoop の「マシンダウン・ネットワーク切断・ディスク満杯」程度)。単一ノードのログのみで多ノード間の相互依存を捉えられない。 3. **分散 DB 向けモデルの不在**: 既存手法はクラスタ内の任意のノードが異常を示せばクラスタ全体を異常と見なす(Single-Point Classification)。これはリーダー/フォロワー構成を持つ分散 DB の実態と乖離し、偽陽性率が高い。  ## データセット構築 ### 分散 DB の異常タクソノミー 11 種の異常を 2 カテゴリに分類した(表 1): | カテゴリ | 番号 | 異常 | |---|---|---| | システム起因 | 1–6 | CPU 飽和・I/O 飽和・メモリ飽和・帯域制限・ネットワーク分断・マシンダウン | | データベース固有 | 7–11 | 同伴低速クエリ・エクスポート操作・インポート操作・高負荷コンパクション・過頻度ディスクフラッシュ | - **高負荷コンパクション**(No.10): LSM ベース DB のバックグラウンドタスク。CPU・メモリ消費が設定依存で大きく変動し書き込み停止の原因になる。 - **過頻度ディスクフラッシュ**(No.11): メモリ-ディスク間のインタラクション障害。フラッシュ間隔が短すぎるとディスクファイル生成頻度とパフォーマンスに悪影響。 ### 異常注入アーキテクチャ [[Apache IoTDB]] v1.2.2 を Docker 環境で実行(Intel Xeon Platinum 8260 × 4 コア・16 GB RAM・1.1 TB NVMe・OpenJDK 11)。 - **注入ツール**: No.1–6 は Chaos Mesh(クラウドネイティブのカオスエンジニアリングプラットフォーム)、No.7–9 は読み書きワークロードの動的調整、No.10–11 はデータベース設定のホット変更。 - **注入シナリオ**: 正常 → 注入 → 正常 のサイクルを繰り返し、各サイクルで異なる異常を注入。  ### データセット詳細 | シナリオ | 説明 | ログエントリ数 | サイズ | |---|---|---|---| | Single2Single | 単一異常、単一ノード注入 | 450,323,420 | 116.81 GB | | Single2Multi | 単一異常、複数ノード注入 | 245,215,090 | 47.35 GB | | Multi2Single | 複数異常、単一ノード注入 | 149,041,252 | 37.84 GB | | Multi2Multi | 複数異常、複数ノード注入 | 59,336,131 | 14.12 GB | 合計: 216 GB・9 億レコード。データセットリポジトリ: https://github.com/AIOps-LogDB/MultiLog-Dataset ## 実証研究 ### ログの 3 種類の情報 分散 DB の異常を特定するには、ログから 3 種類の情報を抽出する必要がある: 1. **系列データ(Sequential Data)**: ログエントリの順序情報。Drain3 でログをイベントテンプレートに変換し、固定サイズウィンドウで系列化。エクスポート・インポート操作(No.8・9)の検知に有効。 2. **定量データ(Quantitative Data)**: ウィンドウ内の各イベントテンプレートの出現頻度。過頻度ディスクフラッシュ(No.11)の検知に有効。 3. **意味データ(Semantic Data)**: ログイベントを自然言語文として扱い、文埋め込みベクトルに変換。データベース内部状態(「error」「too high」等)を活用した検知に有効。 ### 実証知見 - **影響ノードは自分の異常を検知しにくい**: エクスポート操作(No.8)を Node 1 に注入した場合、PLELog の Node 1 での精度は 39.68%(F1: 56.66%)に留まるのに対し、Node 6 は F1: 90.73% を達成した。これは、操作関連ログが影響ノードで出力されるが、パターンと頻度が低いため他ノードへの影響から周辺ノードが異常をより確実に検知できるためである。 - **Single-Point Classification では偽陽性が急増する**: 低速クエリ(No.7)を Node 1 に注入した場合、各ノードの F1 は 90% 超と高いが、Single-Point Classification ではクラスタ全体の F1 が RobustLog で 76.71%、LogAnomaly で 58.74% に急落する(再現率 100%・精度低下)。 - **単一ノードのみでは不十分、かつ Single-Point Classification だけでも不十分**: 複数ノードの情報を活用しながら、ノードごとの独立予測を超えた集約が必要。 ## 提案手法: MultiLog  ### アーキテクチャ概要 MultiLog は 2 段階で構成される: **段階 1: Standalone Estimation(独立ノード推定)** 各ノードのログから 5 つのサブプロセスで確率系列を生成: 1. **ログ解析・グルーピング**: Drain3 でログをイベントテンプレートに変換し、固定サイズウィンドウ $M$ で系列 $S_j$ を生成。 2. **系列埋め込み**: イベントを離散ベクトル $E_j = (e_{s_1}, e_{s_2}, \ldots, e_{s_M})$ として表現。 3. **定量埋め込み**: 系列 $S_j$ のカウントベクトル $C_j = (c_j(e_1), c_j(e_2), \ldots, c_j(e_n))$。 4. **意味埋め込み**: FastText(Common Crawl)で各単語を $d=300$ 次元ベクトルに変換し、TF-IDF で重み付き合計してセマンティックベクトル $V_j$ を生成。 5. **情報強化**: 3 種埋め込みそれぞれに対し、LSTM + セルフアテンションで長期依存性と重要情報を捉え、確率 $p \in \{0,1\}$ を出力。セルフアテンションのスコア: $\alpha_m = \exp(\text{score}(h_m, h_M)) / \sum_{m'} \exp(\text{score}(h_{m'}, h_M))$。 **段階 2: Cluster Classifier(クラスタ分類器)** 各ノードの確率系列 $P_i = [p_1, p_2, \ldots, p_{k_i}]$ を集約してクラスタ全体の異常判定を行う: 1. **オートエンコーダによる正規化**: ノードごとに異なる長さ $k_i$ を固定長 $\beta=128$ に切り詰め/パディングし、隠れ次元 $\mu=32$ の潜在表現 $Z_i$ にエンコード。MSELoss で標準化。 2. **メタ分類器**: 全ノードの潜在表現 $Z = [Z_1; Z_2; \ldots; Z_N]$ を結合し、隠れ層 + softmax 出力層のネットワークでクラスタのアノマリ/正常を判定。 ### 比較手法 - **Single-Point Classification**: 任意のノードが異常ならクラスタ全体を異常と判定。 - **Vote-Based Classification**: 多数決でクラスタ異常を判定。 - **Best-Node Classification**: 最高性能ノードのみで判定(理論的上限。実運用不可)。 ## 実験結果 ### 全体 F1 スコア(表 6) | データセット | PLELog Single | RobustLog Best | LogAnomaly Single | **MultiLog** | |---|---|---|---|---| | Single2Single | 43.98% | 98.83% | 93.40% | **98.91%** | | Single2Multi | 42.62% | 95.96% | 93.19% | **99.11%** | | Multi2Single | 38.94% | 98.54% | 95.96% | **99.75%** | | Multi2Multi | 48.80% | 97.42% | 88.35% | **99.82%** | ### Multi2Single・Multi2Multi の詳細(表 7) | データセット | 手法 | 適合率 | 再現率 | F1 | |---|---|---|---|---| | Multi2Single | PLELog | 24.18% | 100.00% | 38.94% | | Multi2Single | RobustLog | 24.18% | 100.00% | 38.94% | | Multi2Single | LogAnomaly | 95.88% | 96.05% | 95.96% | | Multi2Single | **MultiLog** | **99.88%** | **99.62%** | **99.75%** | | Multi2Multi | PLELog | 34.52% | 83.24% | 48.80% | | Multi2Multi | RobustLog | 49.96% | 100.00% | 66.63% | | Multi2Multi | LogAnomaly | 72.23% | 99.78% | 83.80% | | Multi2Multi | **MultiLog** | **99.88%** | **99.75%** | **99.82%** | **MultiLog の優位性は偽陽性の大幅削減**: 既存手法は再現率がほぼ 100% に達する一方で適合率が 24〜72% と低いが、MultiLog は適合率・再現率ともに約 99.9% を達成する。実運用での DBA の作業負荷を大幅に削減する。 ### Cluster Classifier のアブレーション  - Vote-Based: 適合率 100% だが再現率が Multi2Single で 26.76%、Multi2Multi で 39.31% と低く、異常の見逃しが多い。 - Single-Point Classification: F1 が Multi2Single で約 95%・Multi2Multi で約 93% に改善するが不十分。 - **Cluster Classifier**: 両データセットで F1 が 99% 超に到達。複数ノードの情報統合の有効性を実証。 ## 新規性と貢献 1. **初の分散 DB 向け多変量ログデータセット**: 216 GB・9 億レコード・11 異常種別・複数注入シナリオ(Single2Single/Single2Multi/Multi2Single/Multi2Multi)をオープンソース公開。 2. **包括的実証研究**: 単一ノードのみへの依存の問題と、Single-Point Classification の偽陽性問題を実証的に明らかにした。 3. **MultiLog**: LSTM+セルフアテンションで 3 種のノード内情報(系列・定量・意味)を統合する Standalone Estimation と、オートエンコーダ+メタ分類器によるクラスタ全体判定を組み合わせた手法。多ノード分類で SOTA を約 12% 上回る。 ## 考察 ### 強み - **偽陽性の大幅削減**: 既存手法の適合率問題(24〜72%)を約 99.9% の適合率で解決。実運用での DBA の負荷削減に直結。 - **多次元情報の統合**: 系列・定量・意味の 3 種の情報をすべて活用することで、単一情報源では検知できない異常をカバー。 - **分散 DB 固有の設計**: リーダー/フォロワー構成を前提に、ノード間の情報補完を活かした検知が可能。 - **初の特化データセット**: 11 種の異常を含む 216 GB の分散 DB ログデータセットは、今後の研究の基盤となる。 ### 弱点・限界 1. **教師あり手法**: ラベル付きデータが必要。教師なし手法(クラスタリング等)と組み合わせて適応可能だが、ラベル収集コストが課題。 2. **計算オーバーヘッドの増加**: ネットワーク越しのログ収集と多段処理のため、SOTA 手法より処理効率が低い。一部の異常タイプでインスタンス数が少ない場合は実用性が低下する可能性がある。 3. **実世界との乖離**: データセットは多様な注入異常を含むが、実運用の複雑さを完全には再現できていない。 4. **分散 DB 限定**: 本フレームワークは分散 DB に特化しており、一般的な分散システムへの直接適用には追加調整が必要。 ## 後継研究 本論文の後継として LogDB (2025, arXiv:2505.01676) が提案されており、同じ著者グループ([[Lingzhe Zhang]]・[[Tong Jia]]・[[Mengxi Jia]]・[[Ying Li]])が、本論文で構築したデータセットと知見をさらに発展させている。 ## 引用・参照 - **会議**: KDD 2024 (ACM SIGKDD、2024 年 8 月 25–29 日、バルセロナ) - **arXiv**: https://arxiv.org/abs/2406.07976 - **データセット**: https://github.com/AIOps-LogDB/MultiLog-Dataset - **主要引用**: iSQUAD([[@2020__PVLDB__Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases]])、Drain([[@2017__ICWS__Drain]])、LogAnomaly、RobustLog、PLELog - **国際助成**: 国家重点 R&D 研究基金(2021YFF0704202)