> [!abstract] 概要(ESEC/FSE '20 abstract の日本語訳) > オンラインサービスシステムにおけるインシデントは、システム可用性を著しく低下させ、ユーザー体験を損なう可能性がある。サービス品質を保証し経済的損失を減らすために、インシデントの発生を事前に予測し、エンジニアが予防的な対策を講じられるようにすることが不可欠である。本研究では、効果的かつ解釈可能なインシデント予測手法 eWarn を提案する。eWarn は履歴データを活用し、リアルタイムのアラートデータに基づいてインシデントが近い将来発生するかどうかを予測する。具体的には、eWarn はまず、綿密な特徴量エンジニアリングを通じて、予兆アラートのパターンを表現する効果的な特徴集合(テキスト特徴と統計特徴を含む)を抽出する。インシデントの発生と無関係なノイズアラートの影響を減らすため、eWarn は次に multi-instance learning の定式化を組み込む。最後に、eWarn は機械学習によって分類モデルを構築し、最先端の説明技術(すなわち LIME)を用いて予測結果に関する解釈可能なレポートを生成する。このようにして、解釈可能なレポートを伴う早期警告シグナルをエンジニアに送信し、来たるインシデントの理解と対処を促進できる。ある大手商業銀行の 11 の実世界オンラインサービスシステムを対象とした広範な研究により、eWarn の有効性が実証され、最先端のアラートベースのインシデント予測手法およびインシデント予測の実務を上回る性能を示した。特に、我々は eWarn を2つの大手商業銀行に適用し、実運用からのいくつかの成功事例と教訓を共有した。 ## 論文情報 - タイトル: Real-Time Incident Prediction for Online Service Systems - 著者・所属: [[Nengwen Zhao]]([[Tsinghua University]]; BNRist)、[[Junjie Chen]](対応著者、College of Intelligence and Computing, [[Tianjin University]])、[[Zhou Wang]](BizSeer; Beijing University of Posts and Telecommunications)、[[Xiao Peng]]([[China EverBright Bank]])、[[Gang Wang]]([[China EverBright Bank]])、[[Yong Wu]]([[China EverBright Bank]])、[[Fang Zhou]]([[China EverBright Bank]])、[[Zhen Feng]]([[China EverBright Bank]])、[[Xiaohui Nie]]([[Tsinghua University]]; BNRist)、[[Wenchi Zhang]]([[BizSeer]])、[[Kaixin Sui]]([[BizSeer]])、[[Dan Pei]]([[Tsinghua University]]; BNRist) - 媒体: The 28th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering(ESEC/FSE '20)、2020-11-08〜13、Virtual Event, USA - DOI: 10.1145/3368089.3409672、12 ページ ## 概要 オンラインサービスシステムにおけるインシデント(計画外のサービス停止)を、軽量なアラートデータのみから実時間で予測する手法 eWarn を提案する論文。テキスト特徴・統計特徴によるアラートパターンの表現、multi-instance learning によるノイズアラート除去、XGBoost + SMOTE による分類、LIME による解釈可能なレポート生成の4段パイプラインで構成する。ある大手商業銀行(bank A、匿名化)の 11 実サービスシステムで最先端手法を上回る性能を示し、2行の実運用への適用結果も報告する。 ## 問題設定 入力はアラートデータ(時刻・テキスト内容・発生サーバー・サービス・重大度・種別などの属性を持つ、監視データ由来のルール違反通知)。出力は「近い将来インシデントが発生するか」の二値分類。moving time window で定式化し(Figure 1)、現在時刻 t を基準に観測窓 `[t-w, t]` のアラートデータから予測窓 `[t+t_l, t+t_l+t_p]` 内のインシデント発生有無を予測する。`t_l`(lead time)はエンジニアが早期警告を受けてから対処に必要な最小時間、`t_p`(prediction window size)は予測の有効期間。過去データにおいて予測窓内にインシデントがあれば観測窓は正例(omen window)、なければ負例(non-omen window)としてラベル付けする。moving window strategy を採るため1件のインシデントに対し `t_p/Δt` 個の連続した正例観測窓(隣接正ウィンドウ)が生じる。 ![[_attachments/ESEC-FSE2020-RealTimeIncidentPrediction/fig01-problem-formulation.png]] (Figure 1. 問題定式化。観測窓 `w`・lead time `t_l`・予測窓 `t_p` の3パラメータで時間軸を固定する。Source: Figure 1, §2.3) ## 提案手法 **アーキテクチャ**: eWarn は4段パイプラインからなる(Figure 2)。(1) 特徴量エンジニアリング(MIL 込み)、(2) MIL によるインスタンス単位の特徴集約、(3) 分類モデル構築(データ不均衡処理 + XGBoost)、(4) 解釈可能性分析(LIME)。訓練時は履歴アラートデータとインシデントチケットから訓練データを構築し、オンライン予測時は現在の観測窓のアラートから早期警告と解釈レポートを生成する。 ![[_attachments/ESEC-FSE2020-RealTimeIncidentPrediction/fig02-overview-architecture.png]] (Figure 2. eWarn の全体アーキテクチャ。Historical alert data + Incident tickets → Training data → Feature extraction → Feature aggregation(点線枠が MIL 適用範囲)→ Classifier → Early warning、および Online data → Prediction → Interpretable analysis のループ。Source: Figure 2, §3) - **テキスト特徴(§3.1.1)**: 観測窓内の全アラート内容をストップワード除去・トークン化した上で1つの文書とみなし、LDA(Latent Dirichlet Allocation)でトピック分布を学習する。各時間窓はトピック確率分布(K 次元ベクトル)として表現される。トピック数 K は coherence score に基づき決定する。TF-IDF・TextCNN・FastText ではなく LDA を選んだ理由は、(a) ニューラル手法は大規模訓練コーパスに依存し計算コストも高い、(b) ブラックボックスモデルからは解釈可能な洞察を得にくい、(c) TF-IDF は高次元特徴ベクトルを生成し次元の呪いを招く、という3点。 - **統計特徴(§3.1.2)**: (i) アラート件数(総数・重大度別・種別別)、(ii) 窓の時刻特徴(時刻・曜日・営業時間内か等)、(iii) アラート間隔(連続アラートの平均時間間隔)、(iv) その他(発報サーバー数・ソフトウェア変更期間中か)の4カテゴリ。銀行 B の手動ルール(Table 2)から着想を得た特徴群。 - **Multi-instance learning によるノイズ除去(§3.2)**: 観測窓を1つの bag、より細粒度なインスタンス窓(サイズ `t_i`)群を instance とみなす MIL(bag のラベルは「インスタンスのいずれかが正なら正」という仮定)を採用。正例 bag に含まれるインスタンスを Hierarchical Clustering でクラスタリングし、インスタンス数が多いクラスタほど omen instance(予兆的)である可能性が高いという観察に基づき、クラスタサイズに比例した重み `w_i = w_i' / Σw_j'`(`w_i' = n(c_{x_i})/n`)を各インスタンスに付与する(式(2))。bag 特徴はインスタンス特徴の重み付き和 `f_b = Σ(w_i × f_i)`(式(3))として集約する。クラスタリングアルゴリズム自体への依存は薄く、事前にクラスタ数を指定しなくてよい Hierarchical Clustering を選んだと説明する。 - **分類モデル構築(§3.3)**: インシデント発生頻度が低いため正負例が大きく不均衡(1:10 〜 1:100)。SMOTE(1:10 のオーバーサンプリング率)で不均衡を補正した上で、XGBoost(gradient boosting tree)で二値分類モデルを構築する。XGBoost を選んだ理由は高いスケーラビリティ・並列性・効率性・特徴選択能力。 - **解釈可能性分析(§3.4)**: LIME(Local Interpretable Model-agnostic Explanations)で個々の予測結果に対する特徴寄与度を算出し、予測確率・特徴寄与度・特徴値・トピックのキーワード一覧の4部構成でレポートを生成する(Figure 3)。最も寄与度が高い特徴(例: データベース関連トピック)はインシデントの根本原因のヒントになり得ると論じる。 ![[_attachments/ESEC-FSE2020-RealTimeIncidentPrediction/fig03-interpretable-report.png]] (Figure 3. 解釈可能レポートの例。① 予測確率(Neg 0.24 / Pos 0.76)、② 特徴寄与度(Topic#27 が最大)、③ 特徴値、④ トピックとキーワード(Topic#27 は Oracle・AAS・SQL・lock・connection 等、データベース関連語で構成)。Source: Figure 3, §3.4) ## 新規性 - 既存の予測手法の多くはディスク障害・ノード障害・スイッチ障害など**特定種別の障害**をログやメトリクスから予測する設計であり汎用性に欠ける上、1日あたり数十 TB のログ・数千超のメトリクスを処理するコストがかかる。eWarn は軽量なアラートデータのみを入力とし、汎用インシデントを予測対象とする。 - 唯一の同種先行研究 AirAlert(WWW 2019)はアラート種別の件数のみを特徴とし、ノイズアラートへの対処もない。本論文は「AirAlert のこの単純な特徴設計は本研究で有効でないことを実証した(§4.2)」と述べ、MIL によるノイズ除去とテキスト+統計の複合特徴設計で優位に立つと主張する。 - 銀行 A の現行実務(association rule mining、FP-Growth)は頻出する予兆アラートしか捉えられず、大半のインシデントに適用できない。銀行 B の実務(手動要約ルール)は概念ドリフトに追従できず保守コストが高い。eWarn はこれらの実務的限界を機械学習で置き換える。 ## 実験設定 - **データセット**: 大手商業銀行 A(1億人超のユーザーを持つ、数百のサービスシステムを含む)の 11 実サービスシステム(S1〜S11)。各システムにつき3年分のアラートデータとインシデントを提供された。観測窓内のアラート数が3件未満の窓は除外。訓練:検証:テスト = 6:2:2 に時系列順で分割。 | System | #Alerts | #Incidents | #Positive | #Negative | |---|---|---|---|---| | S1 | 18,821 | 173 | 524 | 8,460 | | S2 | 13,315 | 214 | 392 | 7,907 | | S3 | 14,211 | 59 | 322 | 4,014 | | S4 | 9,499 | 27 | 161 | 6,176 | | S5 | 9,592 | 48 | 165 | 7,886 | | S6 | 13,811 | 39 | 101 | 8,603 | | S7 | 6,766 | 46 | 272 | 3,310 | | S8 | 9,808 | 26 | 149 | 1,873 | | S9 | 8,770 | 72 | 510 | 6,196 | | S10 | 127,619 | 227 | 1,125 | 15,035 | | S11 | 69,999 | 148 | 1,012 | 13,057 | (Table 3. 11 システムのアラート数・インシデント数・正例/負例観測窓数。正負例比は 1:10〜1:100 と大きく不均衡。Source: Table 3, §4.1.1) - **比較対象**: (1) [[AirAlert]](WWW 2019、アラート種別件数のみを特徴に XGBoost で分類する最先端アラートベース手法)、(2) TF-IDF-LSTM(元は cluster failure をログから予測する手法を本問題に適合、TF-IDF テキスト特徴 + LSTM)、(3) FP-Growth(銀行 A の現行実務。予兆アラートの頻出パターンマイニング)。 - **評価指標**: precision・recall・F1-score。閾値は検証セット上で最良性能となるよう決定。偽陰性(見逃し)は偽陽性(誤警報の調査コスト)より遥かに深刻とし、recall を重視。加えてオフライン訓練時間・オンライン予測時間の効率も測定。 - **パラメータ**: `Δt=10min`(10分ごとに予測)、`w=60min`、`t_l=10min`、`t_i=10min`。トピック数はcoherence scoreに基づき決定。SMOTE のオーバーサンプリング率は1:10。TextCNN(埋め込み次元100、1D 畳み込みカーネルサイズ8・ストライド1、平均プーリングサイズ2・ストライド1、全結合層隠れ次元128)・FastText(cbow、窓サイズ5、単語ベクトル次元100)・DNN(全結合3層、隠れ次元128)は grid search + 検証セットでハイパーパラメータを決定、Adam(学習率0.01、30エポック)。実行環境: Ubuntu 18.04.1、24コア Intel Xeon E5-2620 v3 @2.40GHz、64GB メモリ。 ## 実験結果 **RQ1(全体性能、Table 4)**: eWarn は3手法すべてを平均で上回った。平均 F1 は eWarn 0.82、AirAlert 0.51、TF-IDF-LSTM 0.60、FP-Growth 0.10。eWarn の最良 F1 は 0.98(S6)。最悪 recall でも eWarn は 0.69 に対し AirAlert 0.24・TF-IDF-LSTM 0.31・FP-Growth は 0(ゼロ)。S3・S8 のように偶発的要因によるインシデントを含むシステムでは precision/recall とも相対的に低い。 | System | eWarn P/R/F | AirAlert P/R/F | TF-IDF-LSTM P/R/F | FP-Growth P/R/F | W/o MIL P/R/F | |---|---|---|---|---|---| | S1 | 0.86/0.82/0.84 | 0.46/0.82/0.59 | 0.93/0.73/0.82 | 0.08/0.05/0.06 | 0.36/0.80/0.50 | | S2 | 0.86/0.97/0.91 | 0.81/0.94/0.87 | 0.80/0.88/0.84 | 0.25/0.22/0.23 | 0.82/0.97/0.89 | | S3 | 0.61/0.83/0.70 | 0.41/0.24/0.31 | 0.23/0.76/0.35 | 0.05/0.09/0.07 | 0.50/0.67/0.57 | | S4 | 0.92/0.84/0.88 | 0.34/0.81/0.48 | 0.58/0.39/0.46 | 0.16/0.27/0.20 | 0.97/0.52/0.68 | | S5 | 0.75/0.86/0.80 | 0.34/0.29/0.32 | 0.14/0.31/0.19 | 0.12/0.25/0.17 | 0.71/0.39/0.51 | | S6 | 0.96/1.00/0.98 | 0.21/1.00/0.35 | 0.91/1.00/0.95 | 1.00/0.05/0.09 | 0.96/1.00/0.98 | | S7 | 0.73/0.71/0.72 | 0.65/0.53/0.59 | 0.67/0.73/0.69 | 0.00/0.00/0.00 | 0.36/0.76/0.49 | | S8 | 0.56/0.92/0.69 | 0.22/1.00/0.36 | 0.17/1.00/0.30 | 0.13/0.10/0.11 | 0.60/0.61/0.61 | | S9 | 0.92/0.98/0.95 | 0.53/1.00/0.69 | 0.92/0.98/0.95 | 0.03/0.02/0.02 | 0.91/0.98/0.95 | | S10 | 0.70/0.79/0.76 | 0.55/0.86/0.67 | 0.52/0.90/0.66 | 0.53/0.06/0.11 | 0.51/0.92/0.66 | | S11 | 0.81/0.69/0.75 | 0.28/0.57/0.37 | 0.25/0.52/0.34 | 0.01/0.06/0.01 | 0.41/0.53/0.46 | | **Average F1** | **0.82** | 0.51 | 0.60 | 0.10 | 0.66 | (Table 4. 11 システムの precision/recall/F1-score 比較。W/o MIL 列は MIL 除去時の eWarn 性能。Source: Table 4, §4.2, §4.3.1) 比較手法が劣る理由の分析: AirAlert はアラート種別件数のみに依存し複雑なアラードパターンを表現できずノイズ処理もない。TF-IDF-LSTM は語頻度ベースの TF-IDF で高次元特徴を作りがちで、eWarn の moving window 定式化が既に時間依存性を扱っているため LSTM の追加寄与が薄く計算コストのみ増える。FP-Growth は予兆パターンが複雑で単純な頻出アラートマッチングでは捉えられず、アラート属性(メトリック値・ポート・API 名・IP アドレス等)の多様性から頻出アラートの発見自体が困難。3手法いずれもノイズアラートの負の影響に対処していない。 **RQ2(コンポーネント寄与度)**: - MIL: 除去すると平均 F1 が 0.82→0.66 に低下(Table 4 の W/o MIL 列)。S6・S9 のようにノイズが少ないシステムでは差がほぼない。全体として MIL は平均約20%の F1 改善に寄与。 - 特徴エンジニアリング: テキスト特徴のみで平均 F1 0.69、統計特徴のみで 0.36(Table 5)。両方併用の 0.82 と比べいずれも劣り、テキスト特徴の方が統計特徴より強力。LDA(0.82)は TextCNN(0.48)・FastText(0.51)を大幅に上回る——アラート文はドメイン固有(IT 運用)かつ半構造化の短文であり、大規模コーパスに依存するニューラル手法には不向きなため。 | System | eWarn | Only Textual | Only Statistical | TextCNN | FastText | |---|---|---|---|---|---| | S1 | 0.84 | 0.62 | 0.51 | 0.54 | 0.57 | | S2 | 0.91 | 0.88 | 0.19 | 0.34 | 0.40 | | S3 | 0.70 | 0.48 | 0.30 | 0.37 | 0.43 | | S4 | 0.88 | 0.73 | 0.26 | 0.45 | 0.47 | | S5 | 0.80 | 0.57 | 0.41 | 0.50 | 0.53 | | S6 | 0.98 | 0.90 | 0.38 | 0.61 | 0.65 | | S7 | 0.72 | 0.69 | 0.44 | 0.56 | 0.52 | | S8 | 0.69 | 0.48 | 0.37 | 0.38 | 0.41 | | S9 | 0.95 | 0.84 | 0.29 | 0.42 | 0.48 | | S10 | 0.76 | 0.70 | 0.49 | 0.64 | 0.69 | | S11 | 0.75 | 0.68 | 0.35 | 0.47 | 0.45 | | **Average** | **0.82** | 0.69 | 0.36 | 0.48 | 0.51 | (Table 5. 特徴タイプ・テキスト特徴抽出手法別の F1 比較。Source: Table 5, §4.3.2) - 分類モデル構築: XGBoost は DNN・Random Forest(RF)を上回った(Figure 4)。RF も比較的良好で、特徴が木構造でよくモデル化できることを示唆。SMOTE を除去すると全システムで F1 が 0.04〜0.16 低下し、不均衡処理の寄与を確認した。 ![[_attachments/ESEC-FSE2020-RealTimeIncidentPrediction/fig04-f1-classifier-comparison.png]] (Figure 4. eWarn(XGBoost+SMOTE)・DNN・RF・W/o SMOTE の F1 比較(11 システム)。Source: Figure 4, §4.3.3) **RQ3(効率性)**: オフライン訓練時間は eWarn 9.07 分、AirAlert 3.86 分、TF-IDF-LSTM 32.30 分、FP-Growth 2.70 分。オンライン予測時間はいずれも1.13秒以下と小さい(eWarn 0.04秒)。TF-IDF-LSTM は訓練時間が著しく長く、モデル更新の頻度に制約が出る。 | Approach | Offline learning (min) | Online prediction (s) | |---|---|---| | eWarn | 9.07 | 0.04 | | AirAlert | 3.86 | 0.06 | | TF-IDF-LSTM | 32.30 | 1.13 | | FP-Growth | 2.70 | 0.04 | (Table 6. 平均処理時間比較。Source: Table 6, §4.4) **RQ4(予測窓サイズの影響)**: 予測窓サイズ `t_p` はラベリング品質を通じて性能に大きく影響する。S2 の最適 `t_p` は約70分、S8 は約90分とシステム間で異なる(Figure 5)。`t_p` が大きすぎると偽陽性ウィンドウが増え、小さすぎると陽性ウィンドウを取りこぼす。極端な例として `t_p → ∞` にすれば常にインシデント発生と予測して recall=1 を達成できてしまうが実用性がないと指摘する。 ![[_attachments/ESEC-FSE2020-RealTimeIncidentPrediction/fig05-prediction-window-size.png]] (Figure 5. 予測窓サイズ(分)と F1-score の関係。S2 は約70分、S8 は約90分でピークを取る。Source: Figure 5, §4.5) ## 考察 - eWarn の解釈可能レポートはインシデント予測だけでなく**インシデント診断**にも役立つと論じる。最も寄与度の高い特徴(例: データベース関連トピック)がインシデントの根本原因に近い低レベルコンポーネントを示唆し、診断の探索空間を絞り込む手がかりになる(Figure 6、Case I の例では「Oracle・AAS・SQL・lock」というキーワードからデータベース起因と推測できた)。 ![[_attachments/ESEC-FSE2020-RealTimeIncidentPrediction/fig06-prediction-diagnosis-relationship.png]] (Figure 6. インシデント予測とインシデント診断の関係を示す例(Case I)。予測(実線矢印)は低レベルのアラート(サーバー負荷・ネットワーク・I/O・データベースメトリクス等)からインシデント(サービス応答遅延)を予兆するのに対し、診断(点線矢印)は同じ低レベル情報を根本原因の特定に使う。Source: Figure 6, §5.1.2) - **成功事例**(§5.1.1、いずれも銀行 A・B への実運用適用から): (1) スロー SQL によるサービス応答時間の長期化(データベース関連アラートから予兆を検知)、(2) fullGC によるトランザクション頻繁失敗(リソースメトリクス・JVM GC ログアラートから予兆を検知)、(3) 予期しない急激な負荷によるサクセスレート低下(CPU 利用率アラートから予兆を検知)、(4) スケジュールタスクによるサーバハングアップ(I/O 待機時間・CPU 利用率アラートから予兆を検知)。 ## 強み / 弱点・課題 **強み**: - 汎用インシデントを軽量なアラートデータのみから予測でき、ログ・メトリクス直接処理に比べ計算コストが小さい。 - MIL によるノイズアラート抑制と LDA によるドメイン特化テキスト特徴抽出という、白箱(解釈可能)な設計選択を一貫させている。 - 実運用(2つの大手商業銀行)への適用と具体的成功事例を報告しており、実務的な有効性の裏付けがある。 **弱点・限界(§5.2, §5.3、著者自身の申告)**: - **予兆のないインシデントは予測できない**: 電源障害など突発的要因によるインシデントは原理的に予測困難。学習時には正例として扱われるため、ノイズラベルの一因となる(§5.3 の脅威分析)。 - **予測窓サイズの選定が性能を大きく左右**し、システムごとに最適値が異なるため、検証データを用いたチューニングが前提となる(汎用的な自動選定手法は本論文では未提示)。 - **対象システムが単一銀行(bank A)の 11 システムに限定**され、他業種・他企業への一般化可能性は限定的(著者は銀行 B への適用でこの脅威をある程度緩和したと主張するが、詳細な定量結果は示していない)。 - **モデルの継続更新**: 新しいアラート種別・新しい予兆パターンが継続的に生じる動的環境に対応するため、インクリメンタルな再訓練パイプラインを構築しているが、その詳細な評価(更新頻度・性能劣化度合い等)は論文内で定量的に示されていない。 ## 関連 - 概念: [[障害予測]] / [[アラート管理]] / [[AirAlert]] - ソース: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]](AirAlert 一次論文) / [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]](同著者グループのアラートストーム研究) / [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]] ## 出典 - 本文全 12 ページ(`.raw/papers/ESEC-FSE2020-RealTimeIncidentPrediction.txt`)を通読。Abstract は ESEC/FSE '20 の ACM 公式 abstract を一文ずつ和訳。Table 1-6・Figure 1-6 はすべて本文中に明記された数値・キャプションから引用。