# Identifying Bad Software Changes via Multimodal Anomaly Detection for Online Service Systems ## 論文情報 - **著者**: Nengwen Zhao, Junjie Chen, Zhaoyang Yu, Honglin Wang, Jiesong Li, Bin Qiu, Hongyu Xu, Wenchi Zhang, Kaixin Sui, [[Dan Pei]] - **掲載誌**: ESEC/FSE '21 (29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering), Athens, Greece, 2021-08-23 - **DOI**: https://doi.org/10.1145/3468264.3468543 - **所属**: [[Tsinghua University]] / BNRist, Tianjin University, [[BizSeer]], [[China Guangfa Bank]] - **GitHub**: https://github.com/FSEwork/SCWarn ## アブストラクト(日本語訳) 大規模オンラインサービスシステムにおいて、ソフトウェア変更は不可避かつ頻繁に行われる。新たなコードや設定を投入することで変更がインシデントを誘発しユーザ体験を損なう場合がある。そのため、エンジニアが不正変更(bad software changes)を特定してインシデントの影響を抑え、システム信頼性を向上させることが不可欠である。 本論文では、不正変更の理解を深めるべく、大規模商業銀行の実世界データに基づく初の実証研究を実施した。定量分析の結果、インシデントの約 50.4% が変更に起因し、主な原因はコード欠陥・設定エラー・リソース競合・ソフトウェアバージョンであることが判明した。定性分析では、異種多ソースデータを扱う現行の変更検知手法が十分でないことも示された。 これらの知見をもとに、不正変更を正確かつ迅速に特定し解釈可能なアラートを生成する新手法 **SCWarn** を提案する。核心的アイデアは、マルチモーダル学習によって異種多ソースデータから異常を検知することである。2 データセット・10 種の不正変更パターンによる評価で、SCWarn は平均 F1 スコア 0.95 を達成し既存手法をすべて上回り、MTTD を 20.4〜60.7% 削減した。 ## 概要 大規模オンラインサービス系(金融機関・EC・検索エンジン等)はソフトウェア変更を日常的に行うが、テスト環境と本番環境の乖離(クラスタ規模・複雑な依存関係・リソース競合・予期しない負荷)から変更が障害を引き起こすケースが後を絶たない。Google SRE の経験では障害の約 70% が変更に関連するとされている。 本研究は変更後のモニタリング(post-change monitoring)に焦点を当て、展開後に不正変更を迅速に特定して先手を打つアプローチを提案する。 ## 問題設定 大規模商業銀行(5 サービス・2 年間のインシデント/変更チケット)を対象とした実証研究で 3 つの研究課題を設定した。 - **RQ1: インシデントのうちソフトウェア変更に起因する割合は?** → 39〜64%（平均 50.4%）がソフトウェア変更に起因。Pearson 相関係数 0.57(変更数とインシデント数の中程度の正の相関)。 - **RQ2: 不正変更の根本原因と異常挙動の分類は?** → 5 種類の根本原因: コード欠陥(38%)・設定エラー(31%)・ソフトウェアバージョン不適合(11%)・リソース競合(12%)・その他(9%)。異常挙動はビジネス KPI・マシン KPI・ログの 3 種類に及ぶ。 - **RQ3: 現行の変更検知手法は十分か?** → 3σ ルールをビジネス KPI 単独に適用する現行手法は不十分。他データソースの異常シグナル見落とし・期待変動(予期されたリソース変化)の誤検知・単純統計手法の限界の 3 問題を確認。 ## 提案手法 [[SCWarn]] は 4 ステップで構成される。 ### ステップ 1: データ準備 3 種類の監視データを統一時系列に変換する。 - ビジネス KPI(レスポンスタイム・成功率など): そのまま時系列として利用 - マシン KPI(CPU 使用率・JVM ヒープ領域など): そのまま時系列として利用 - ログ: Drain アルゴリズムでテンプレート化し、テンプレートごとの出現頻度カウントを時系列化(n + 2 系列: n テンプレート + 全ログ数 + 新規テンプレートログ数) ### ステップ 2: マルチモーダル異常検知 LSTM を各データソースの時系列に適用し、その後中間融合(intermediate fusion)で多ソースの相関を学習する。 アーキテクチャ構成: - ビジネス KPI/マシン KPI/ログそれぞれに LSTM(シーケンス長 10、隠れ層サイズ 128)と全結合層を適用 - 共有表現層で 3 モダリティの結合表現を学習 - 2 つの全結合層で最終予測値を出力 - 損失関数は各モダリティの MSE の合計 教師なし学習: 変更前 2 週間の正常データで学習し、学習データの異常スコア分布に基づく閾値(k-σ 則)を設定する。 ### ステップ 3: アラート生成と分析レポート - **閾値選択**: 連続 α ポイント(α=3)が閾値を超えた場合にアラートを生成(一過性ノイズを除外) - **解釈可能なレポート**: 変更チケット情報・リアルタイムのヘルススコア・異常上位 k データソースのランキングをウェブ画面で提供 ### ステップ 4: アクション決定 ナレッジベース(期待変動と対応するデータ挙動のペア)を照合し、正常変更に伴う「異常だが想定内」の挙動(リソース拡張後の CPU 低下など)を除外する。未知シナリオは人間が確認して知識ベースを更新。ロールバック等の保護アクションを実施。 ## 新規性 - **大規模実証研究**: 商業銀行 5 サービス 2 年間のインシデント/変更チケットに基づく不正変更の初の大規模実証研究 - **マルチモーダル融合**: ビジネス KPI・マシン KPI・ログの 3 種類のデータを中間融合で統合し、異種多ソースデータの相関を教師なしで学習 - **シナリオ特化設計**: 変更後の「非一過性異常」の特性に合わせた連続アラーティング戦略と、「異常だが想定内」の変動を除外するナレッジベース機構 ## 実験設定 - **ベンチマークシステム**: Train-Ticket(30 超マイクロサービスの鉄道予約システム)および E-commerce(alibaba/eCommerceSearchBench) - **データセット**: Dataset A(121 件不正変更 + 96 件正常変更)、Dataset B(125 件不正変更 + 98 件正常変更) - **障害種別**: 10 種類を注入(F1〜F4: コード欠陥、F5〜F8: 設定エラー、F9: バージョン不適合、F10: CPU リソース競合) - **収集ツール**: KPI を Prometheus + InfluxDB、ログを Logstash + Elasticsearch で収集 - **比較手法**: Gandalf・Funnel・Lumos(ベースライン 3 種)、各種単一ソース/マルチソース異常検知アルゴリズム - **評価指標**: Precision/Recall/F1-score と MTTD(平均検知時間, 分単位) ## 実験結果 **RQ4: SCWarn の変更識別性能** | 手法 | Dataset A F1 | Dataset A MTTD | Dataset B F1 | Dataset B MTTD | |---|---|---|---|---| | SCWarn | 0.93 | 5.1 分 | 0.97 | 2.3 分 | | Gandalf | 0.79 | 6.2 分 | 0.87 | 3.1 分 | | Funnel | 0.73 | 14.0 分 | 0.81 | 6.4 分 | | Lumos | 0.78 | 10.0 分 | 0.82 | 10.0 分 | 平均 F1 = 0.95、MTTD 平均 3.7 分(Funnel 比 63.7% 短縮、Lumos 比 63.7% 短縮)。 **RQ5: マルチモーダル LSTM の有効性** 各単一ソース手法(Donut/B-LSTM/LSTM-NDT/OmniAnomaly/DeepLog)や multimodal AE/M-LSTM と比較。マルチモーダル LSTM が最高性能(平均 F1 0.95)。Wilcoxon signed-rank test で M-LSTM との有意差確認(p=0.0416、効果量 0.6860)、multimodal AE との有意差も確認(p=0.0019、効果量 0.8388)。 **RQ6: 時間効率** 訓練時間は数分(Donut/OmniAnomaly/DeepLog より大幅に短い)、オンライン検知時間は 1 秒未満でリアルタイム性を確保。 **RQ7: パラメータ感度** k(閾値係数)は 1 が最適。α(連続ポイント数)は 3 が精度・MTTD のバランスが良い。 ## 考察 ### 成功事例(ユーザスタディ) 12 名のエンジニアによる非公式評価で 4 ケースが紹介された。 - **Case I**: データベーステーブルにインデックスなしの全表スキャンを SCWarn が 23 分前に検知(Gandalf より 12 分早い)。データベースメトリクス(ロック待ち・CPU 使用率)とミドルウェアメトリクス(JDBC コネクションプール)から発見。 - **Case II**: コード欠陥による頻繁な fullGC を SCWarn が 5.6 時間前に検知。GC ログと JVM メトリクス(ヒープ・GC カウント)が手掛かり。レポートがエンジニアの 5 分以内の根本原因特定を可能に。 - **Case III**: サービス A・B が同一サーバを共有する効率ボトルネックを 57 分前に発見。 - **Case IV**: 遅い SQL 文が引き起こすデータベース異常を 6 分前に検知。 エンジニアが評価した点: (1) 精度・速度の向上、(2) マルチソースによる包括的な情報、(3) 解釈可能なレポートによる診断効率化(Grafana/Kibana の手動確認を 5〜20 分省略)。 ### 教訓 - **汎用性**: ほぼ全システムが KPI とログを保有するため、銀行外の環境にも適用可能 - **人間関与の不可避性**: エンジニアのドメイン知識(期待変動の判断・緊急アクションの決定)は完全自動化では代替困難 - **マルチソース融合の横断応用**: インシデント診断・インシデント予測・トレース異常検知など他タスクへの展開可能性 ## 強み・弱点・課題 ### 強み - 実際の商業銀行データに基づいた初の大規模実証研究 - マルチモーダル LSTM が単一ソース/等価融合手法を一貫して上回る - 解釈可能なレポートと期待変動フィルタによる実用性の高さ - Train-Ticket・E-commerce の 2 ベンチマークで検証されたコードが公開済み ### 弱点・限界 - 「サイレントインシデント」(モニタリングデータに異常が現れない障害)は検知不可 - 大規模本番展開は 1 サービスに留まり、フルスケール検証は将来課題 - 実験の障害注入は合成的でシンプル(現実の複雑な障害とのギャップ) - 変更ごとに 2 週間の正常データが必要(新システムへの適用困難) ### 課題 - Open-set の障害種別への対応 - コールドスタート時の適用方法の検討 - 変更規模・頻度が異なる他業種・他規模システムへの汎用化検証 ## 関連 - 概念: [[ソフトウェア変更管理]] / [[マルチモーダル障害診断]] / [[異常検知]] / [[インシデント管理]] / [[AIOps]] / [[根本原因分析]] / [[ログパース]] - エンティティ: [[SCWarn]] / [[Dan Pei]] / [[Nengwen Zhao]] / [[BizSeer]] / [[China Guangfa Bank]] / [[Train-Ticket]] / [[Tsinghua University]] - 関連 MOC: [[LLM4SRE - MOC]]