Fire Engine

化学の修士号→消防士→ITエンジニア(2016年11月〜)

機械学習モデルの局所的な解釈に着目したシステムにおける異常の原因診断手法の構想

著者 鶴田 博文, 坪内 佑樹
所属 さくらインターネット株式会社 さくらインターネット研究所
研究会 第8回WebSystemArchitecture研究会

1. はじめに

インターネットを介して利用するシステムの大規模化に伴い,システムの構成要素数の増大や,構成要素間の関係性の複雑化が進んでいる. そのため,システムの性能に異常が発生したときに,システムの状態を示す指標であるメトリックをシステム管理者が網羅的に目視することや,メトリック間の関係性を把握することができず,システムの異常原因を特定することが難しくなっている.

この問題を解決するために,深層学習などの機械学習モデルを用いて,システムの異常の原因を診断する手法が提案されている[1,2]. これらの手法は,システム管理者が異常の根本原因を絞り込むために活用することが期待できる. しかし,原因診断を行うためには,事前に機械学習モデルの学習が必要であり,それに加えて定期的なモデルの更新も必要であるため,それらに伴う課題が存在する. 課題として,まずモデルの学習と更新に伴う計算コストがかかることが挙げられる. 次に,モデルの入力となる分析対象のメトリックを事前に指定する必要があるため,より原因に近いメトリックが診断結果から除外される可能性がある.

事前にモデルの学習が不要であり,異常発生を起点にその原因を診断できる手法として,統計的因果探索を用いた手法が提案されている[3,4]. これらの手法は,因果グラフにより異常の伝搬経路を特定できることに加え,異常発生時のみしか計算コストを要しないことが利点として挙げられる. しかし,既存手法であるMicroscope[3]やAutoMAP[4]は,分析対象のメトリックを事前に指定しておく必要があることが課題である.

本発表では,事前にモデルの学習や対象メトリックの指定を必要とせず,機械学習モデルの局所的な解釈手法であるSHAP[5]を用いてシステムの異常の原因を診断する手法の検討を行う.

2. 機械学習モデルの局所的な解釈

近年,深層学習をはじめとする機械学習モデルは様々な分野へ応用が進んでいる. 一方,機械学習モデルはその計算過程が複雑であるため,人間が動作を理解することができないブラックボックスとなることが問題視されており,機械学習モデルの解釈性についての研究が注目されている[6].

局所的な解釈は,特定の入力に対するモデルの予測や判断の根拠を提示することであり,代表的な手法としてLIME[7]やSHAP[5]が挙げられる. これらの手法は,予測や判断の根拠となった特徴量を提示する手法である. 例えば,病気になるリスクを予測する機械学習モデルがあったとして,ある人物がリスクが高いと予測されたとする. LIMEやSHAPではその根拠となる特徴量(例えば,体重,血圧など)を予測への寄与の度合いとともに提示する.

局所的な解釈手法は,特に画像認識の分野で数多くの研究が報告されているが,異常の原因診断においてもその有用性が示されつつある[8-10]. 例えば,SHAP等を用いてPCA[8]やオートエンコーダ[9],変分オートエンコーダ[10]などによる異常検知の結果の解釈が,他の手法と比較して,原因の特定精度が高い,もしくは人間の直感に近い解釈を与えるなどの報告がされている.

3. 提案する原因診断手法

「1. はじめに」で述べた通り,既存の深層学習などの機械学習モデルを用いた原因診断手法[1,2]では,原因診断のために用いるモデルを事前に学習し,定期的に更新する必要があるため,そのための計算コストがかかることや,分析対象となるメトリックをシステム管理者が事前に指定しておく必要があることが課題である. 一方,統計的因果探索を用いた原因診断手法[3,4]では,事前にモデルの学習を必要としないが,既存手法では分析対象のメトリックを事前に指定しておく必要がある. この場合,システム管理者が選定したメトリクスの中に異常の根本原因となるメトリックが含まれず,診断結果から原因メトリックが除外される可能性がある. そこで提案手法では,事前にモデルの学習や対象メトリックの指定を必要としない原因診断手法の検討を行う. 提案手法の概要図を以下に示す.

f:id:hirotsuru314:20210530220928p:plain
図1 提案手法の概要図

提案手法は,異常発生後にその原因を診断するための手法であり,異常を検知するためには,Service Level Objective(SLO)やメトリックごとに設定した閾値などを用いることを想定している. また,提案手法は,異常発生時にシステム管理者に原因診断結果を提示し,システム管理者がシステムを異常状態から復旧するための作業を支援することを目指している. そのため,診断結果を提示するまでの時間が短いことが望まれる. この要件を満たすための提案手法の工夫や実際の実行時間の評価は後述する.

提案手法は以下の三つのステップから構成される.

Step 1:メトリックのフィルタリング

提案手法では,事前に分析対象となるメトリックを指定する必要がないため,異常発生後に対象メトリックを選定できる. そのため,異常発生時にほとんど変動がないメトリックなど,その異常への関連の可能性が低いものをフィルタリングできる. メトリックのフィルタリングは,原因診断の精度の向上と後続のステップの実行時間の短縮に有効である.

異常への関連性が低いメトリックをフィルタリングする手法の一つとして,以前の我々の研究成果であるTSifter[11]の活用を検討する. TSifterは,定常性の検定および階層的クラスタリングを用いて迅速に異常に関連するメトリックを絞り込む次元削減手法である.

Step 2:モデルの学習

提案手法では,異常発生後に観測データからモデルを学習するため,高速に学習可能なモデルを用いる必要がある. 本発表では,モデルとして,主成分分析(PCA)[12]の利用を検討する.(今後,非線形のモデル等に拡張
する予定) PCAを用いた異常検知では,観測データに対する次元削減により正常部分空間を求め,テストデータと正常部分空間との距離を異常スコアとする. 提案手法では,PCAで算出される異常スコアを異常検知ではなく,検知後の原因診断に用いることを想定している.

Step 3:異常への貢献度の計算

提案手法では,異常の原因診断を行うために,各メトリックの異常への貢献度を計算する. 貢献度の計算には,協力ゲーム理論のShapley Valueに基づくSHAPを採用した. いくつかのSHAPのアルゴリズムの中でも,あらゆる機械学習モデルに適用可能であるKernel SHAPを採用している.

4. 評価

4.1 実験環境

ベンチマークアプリケーション

実験環境として,Google Kubernetes Engine(GKE)上にマイクロサービスのベンチマークアプリケーションである Sock Shop[13]を構築した. Sock Shopを構成する11コンテナからcAdvisorを用いてCPU使用率などのメトリックを5秒おきに収集した.

異常注入

Sock Shopアプリケーションに対して,擬似的な負荷を生成するために,Locust[14]を利用した. Locustによる負荷を生成している間に,システムの異常を模倣するために,特定のコンテナ(user-dbコンテナ)にstress-ngコマンドを用いてCPU負荷を注入した.

ベースライン手法

原因診断のベースライン手法として,Gaussian Based Thresholding(GBT)を用いた. GBTを用いた原因診断は,学習データの平均値とテストデータの平均値の差分が大きい順番に異常への貢献度が高いとする単純な手法である.

4.2 異常の原因診断

Sock Shopを構成する11のコンテナから取得したメトリック数の合計は601であった. そこからTSifterを用いてメトリックのフィルタリングを行った結果,メトリック数が72まで削減された. 今回の実験条件において,異常の原因となるuser-dbコンテナのメトリックは,フィルタリング後に5つのメトリックが残っており,そのグラフを描いたものが下の図である. 各メトリクスは標準化している.

f:id:hirotsuru314:20210525141228p:plain
図2 user-dbコンテナのメトリック

図2から横軸が190あたりからメトリックが大きく変動しているのがわかるが,これは実際にstress-ngコマンドでCPU負荷をかけた時間帯に相当する. メトリックは,20分間に相当する240点を取得しており,前述の通りフィルタリング後の特徴量数は72であるため,分析対象のデータは,72×240の多次元時系列データとなる. このデータを10分間隔で区切って,前半の120点を学習データ,後半の120点を異常を診断するテストデータとして分割する. この場合,異常を検知した時,直近10分間とそれ以前とのメトリックのずれを分析していることになる. 今回は学習データとテストデータの分割を手動で設定しているが,その分割方法をデータから適応的に決定することは今後の課題とする.

下の図は,一つのタイムステップ(図2の横軸が200の点)における異常への貢献度をSHAPにより求め,その結果を可視化したものである.

f:id:hirotsuru314:20210525141352p:plain
図3 SHAPによる解釈(force plot)

横軸は,PCAにより求めた異常スコアである. 学習データの異常スコアのベース値が0.99程度であるのに対し,テストデータでは異常スコアが1.42まで増大している. 図3は,その異常スコアの増大への特徴量の貢献度を可視化したものである. 赤色で示されているものが異常スコアが増大する方向に押し上げている特徴量を示している. 特徴量名は「c-(コンテナ名)_(メトリック名)」となっている. この結果から,図2の横軸が200の時点において,user-dbコンテナのCPUのメトリックが異常に最も寄与していると解釈しており,user-dbコンテナのネットワーク関連のメトリックが次に貢献度が大きくなっている.

次に,下図はテストデータの120タイムステップのSHAPによる解釈の結果をまとめたsummary plotと呼ばれるものであり,異常への貢献度が大きいものから順に10つのメトリックを上から並べたものである.

f:id:hirotsuru314:20210525141634p:plain
図4 SHAPによる解釈(summary plot)

図3と同様に,図4においても,user-dbコンテナのCPUおよびネットワーク関連のメトリックが大きな貢献度を示している. 本実験における異常は,user-dbコンテナにstress-ngコマンドを用いてCPU負荷を注入したものである. そのため,本実験条件において,SHAPによる解釈は,実際の異常の根本原因と一致した結果を与えている.

一方,ベースライン手法であるGBTベースの原因診断では,提案手法と異なる診断結果が得られた. GBTによる解釈,すなわち学習データとテストデータの平均値の差分が大きい順にメトリックを並べた結果は以下の通りである.

c-carts_fs_usage_bytes
c-orders_fs_usage_bytes
c-carts-db_memory_rss
c-carts-db_memory_working_set_bytes
c-orders-db_memory_rss
c-catalogue_fs_usage_bytes
c-user-db_cpu_user_seconds_total
c-user-db_memory_working_set_bytes
c-front-end_cpu_cfs_throttled_seconds_total
c-user-db_network_transmit_packets_total

本実験における根本原因であるuser-dbのCPUのメトリックは異常への貢献度が7番目となっていた. GBTによる解釈では,正常時でも分散が大きいメトリックが,偶発的に学習データとテストデータの平均値の差分が大きくなった場合,それを異常による変動と見分けることができない. 一方,PCAでは正常時の分散の大きさを考慮しているので,本実験では結果的に正しい解釈を与えられているのではないかと考えている.

本実験の異常パターンにおいては,提案手法で採用しているSHAPの方がベースライン手法よりも良い原因診断の結果を与えることがわかった. 一方,本実験は一つの異常パターンのみを対象としているため,提案手法の有用性を示すためには,より広範な異常パターンに対して評価を行う必要があると考える. しかし,単純な平均値の逸脱により異常を解釈するベースライン手法と協力ゲーム理論に基づくSHAPによる解釈が異なる結果を与えうることは大変興味深い結果である. 今後はより広範な障害パターンに対しての評価を進めていく予定である.

4.3 実行時間

異常の原因診断では,その診断結果をシステム管理者が見たのちに異常状態からの復旧のための対応を行うことを想定しているため,診断結果を出すまでの時間は短いことが望まれる. そこで,提案手法において原因診断の結果を出すまでの時間を評価した.

下の表は提案手法の実行時間の結果を実行ステップごとに示したものである. この結果は,図4のsummary plotを計算する際の実行時間である.

実行時間(s)
Step 1:フィルタリング(TSifter) 1.78
Step 2:PCAの学習 0.02
Step 3:SHAPの計算 62
合計 64

提案手法の実行時間は64 sであり,SHAPの計算が支配的であることがわかった. SHAPの計算にはSHAPの提案者らが開発しているPython製のライブラリ[15]を用いた. また,summary plotでは120のタイムステップにおけるSHAPの計算が実行されるため,今回は8コアサーバで並列処理している.

提案手法が実用的なシステムに有効かどうかを議論するためには,システムの規模(分析対象のメトリック数)を変化させた際の実行時間について評価する必要がある. 提案手法の実行時間は,対象となるメトリック数の増大とともに長くなるため,本実験条件より大規模なシステムへ対応するためには,SHAPの計算の高速化が課題となる. SHAPの計算時間の改善策として,並列数を大きくすることや,shapライブラリ[15]の計算時間を改善することなどを考えている.

5. 今後の展望

まず,提案手法の有用性を示すためには広範な異常パターンに対して評価を行う必要があると考える. そのため,異常の注入やメトリックの取得などを自動化した実験環境を構築し,広範な異常パターンに対して原因診断の精度を定量的に評価する予定である.

次に,対象とするシステムが大規模化した際に,提案手法が実用に耐えうるかを検証する. そのために,メトリック数が増大した場合の原因診断の計算時間の評価を行う.

最後に,今回の採用したPCAは,線形かつ時系列の情報を考慮していない単純なモデルであるため,今後,
非線形のモデルや時系列に対応したモデルを採用し,その有効性を検証する予定である.

スライド

speakerdeck.com

参考文献

[1] A Deep Neural Network for Unsupervised Anomaly Detection and Diagnosis in Multivariate Time Series Data

[2] Detecting and Localizing Anomalies in Container Clusters Using Markov Models

[3] Microscope: Pinpoint Performance Issues with Causal Graphs in Micro-service Environments

[4] AutoMAP: Diagnose Your Microservice-based Web Applications Automatically

[5] A Unified Approach to Interpreting Model Predictions

[6] Peeking Inside the Black-Box: A Survey on Explainable Artificial Intelligence (XAI)

[7] "Why Should I Trust You?": Explaining the Predictions of Any Classifier

[8] Shapley Values of Reconstruction Errors of PCA for Explaining Anomaly Detection

[9] Explaining Anomalies Detected by Autoencoders Using SHAP

[10] On Anomaly Interpretation via Shapley Values

[11] TSifter:マイクロサービスにおける性能異常の迅速な診断に向いた時系列データの次元削減手法

[12] Principal component analysis

[13] Sock Shop A Microservices Demo Application

[14] LOCUST: An open source load testing tool

[15] slundberg/shap