# Localizing Faults in Cloud Systems > [!abstract] 概要 > 大規模なコモディティハードウェアのクラスタを活用することで、クラウドはソフトウェアシステムの運用コストを最適化する大きな機会を提供するが、ソフトウェアアプリケーションの信頼性に大きな影響を及ぼす。アプリケーションがクラウド実行環境を制御できないことは、障害を注入した重い訓練に依存して信頼性の問題に対処する最先端の手法の適用性を大きく制限する。本論文では、正例のみの訓練に依拠し、したがってクラウドシステムの制約下で動作できる軽量な障害箇所特定手法 LOUD を提案する。LOUD は機械学習とグラフ理論に基づく。正常な実行のみで機械学習モデルを訓練し、正例のみの訓練から生じる不正確さを、機械学習の出力をグラフ理論のアルゴリズムで精緻化することで補償する。本論文の実験結果は、LOUD が軽量な正例のみの訓練だけで高い精度で障害箇所を特定できることを裏付ける。 ## 論文情報 - 著者: [[Leonardo Mariani]]、[[Cristina Monni]]、[[Mauro Pezzé]]、[[Oliviero Riganelli]]、[[Rui Xin]](ミラノ・ビコッカ大学、スイス・イタリア語圏大学 USI) - 公開: arXiv:1803.00356 [cs.SE]、2018-03-01。掲載媒体はICST'18。 - 評価対象: OpenStack 上の IMS 実装 ClearWater(注入障害 108 ケース) - 提案手法名: [[LOUD]] ## 概要 クラウド上の障害箇所特定は、障害を注入した訓練データに頼ると、多数のマシンの所有者が分かれ、システムが変化し続けるクラウドでは現実的でない。LOUD は正常実行の KPI(主要業績指標に相当するメトリクス)だけで訓練する。IBM ITOA-PI が作る KPI ベースラインとグレンジャー因果グラフから、異常 KPI だけを残した伝播グラフを実行時に作り、グラフ中心性の上位 20 KPI で最頻のリソースを障害リソースとして返す。PageRank が最良で、CPU hog と memory leak では高い精度を示し、オーバーヘッドは CPU 2.63%、メモリ 1.91% である。 ## 問題設定 - 障害の予測・箇所特定手法の多くは、障害注入を伴う長い訓練に依存する。複数種の障害を、所有者の異なる複数マシンへ注入し、システム進化のたびに繰り返すのは高価で、ほとんど適用できない。 - 正例のみで訓練した異常検知モデルは偽陽性が多い。実行時に最初に異常になったノードを選ぶ方式は、正常時にも異常が出ること、最初の異常が間接的な影響であることが多いことから成立しない。 - 目標は、正例のみの訓練で、障害を起こしているリソース(ホスト・VM・アプリケーション)を特定することである。障害予測器の後段で動かし、予測が出たときに箇所を特定する構成を想定する。 ## 提案手法 論理構成は「オフライン」と「オンライン」の 2 相からなる(Figure 1)。 ![[_attachments/arxiv-1803.00356/fig01-loud-approach.png]] - **KPI**: メトリクス M と監視対象リソース R の対 ⟨M, R⟩。時間順の系列として扱う。プローブで定期的に採取する。 - **Data Analytics(オフライン)**: 正常実行データから、KPI ごとのベースラインモデル(季節性を考慮した平均と許容変動幅)と、KPI 間の因果グラフを作る。因果グラフは有向重み付きで、辺 a→b の重み w は、グレンジャー検定に基づいて a が b と相関する確率を表す。訓練は数週間にわたる初期訓練と、新データが得られるたびの再訓練からなる。実装には IBM ITOA-PI を使う。 - **Data Analytics(オンライン)**: KPI 値がベースラインの許容変動を外れるか、因果関係が崩れたとき、その KPI を異常と報告する。 - **KPI Analysis**: 因果グラフから異常 KPI とそれらの直接の辺だけを残した最大連結部分グラフを、伝播グラフとする。時刻ごとに作り直す(Figure 2)。 ![[_attachments/arxiv-1803.00356/fig02-causality-propagation-graph.png]] - **Localization**: 障害予測をトリガとして起動する。前提は、障害リソースが時間とともに強く相関した異常を増やしながら、直接・間接に接続したリソースへ伝播することである。伝播グラフのノードを中心性指標でスコア付けし、上位 20 KPI のうち最頻のリソースを障害リソースとして出す。最頻リソースが定まらなければ箇所を示さない。 - **中心性指標**: 次数中心性は異常の拡散を捉えないため、媒介中心性と近接中心性は最短路に基づき全体構造を反映しないため、除外した。採用は固有ベクトル中心性、非後戻り(non-backtracking)中心性、HITS(ハブ・オーソリティ)、PageRank(テレポート確率 α = 0.85)の 4 系統(5 指標)である。固有ベクトル中心性は少数のハブにスコアが集中する「凝縮」現象を起こすため、その補正として非後戻り中心性を用いる。べき乗法で計算するため、途中で打ち切り、再開して精度を上げられる(Figure 3)。 ![[_attachments/arxiv-1803.00356/fig03-centrality-ranking.png]] ## 新規性 - 障害注入なしの正例のみの訓練で箇所特定を成立させる点。 - 異常 KPI 間の時間的相関をグレンジャー因果グラフで表し、伝播グラフとして異常の拡散を明示的に扱う点。 - 誤検知を含む異常集合から障害に関連する異常を選ぶために、グラフ中心性指標(特に PageRank)を使う点。 - 異なる種類の障害・リソースに対する実験的評価。 ## 実験設定 - **テストベッド**: OpenStack Icehouse 上の 8 台(コントローラ 1、ネットワーク 1、コンピュート 6、KVM)で、IMS の ClearWater(Bono、Sprout、Homestead、Homer、Ralf、Ellis の 6 VM)を稼働(Figure 4)。負荷は SIPp で生成し、週・日のパターン(平日が休日より多く、9 時と 19 時にピーク)を再現した。 ![[_attachments/arxiv-1803.00356/fig04-testbed-architecture.png]] - **KPI**: OS レベル 300 KPI(コンピュート 6、VM 6 のそれぞれで 25 KPI)とアプリケーションレベル 162 KPI(SNMPv2c)の計 462 KPI を毎分採取する。訓練は正常条件で 2 週間、ITOA-PI の既定(5 分集約)を使う。 - **注入障害**: packet loss、memory leak、CPU hog。重大度の増え方は線形・指数・ランダムの 3 パターン。Chaos Monkey を改造して注入した。Bono、Sprout、Homestead の 3 リソースに、各設定を 4 回繰り返し、3 × 3 × 3 × 4 = 108 ケースである。 - **評価指標**: 障害注入後の各時刻での適合率・再現率・F1。TP はその時刻の箇所特定が正解、FP は誤り、FN は最頻リソースが定まらず箇所を出せなかった場合。 - **リサーチクエスチョン**: RQ1 中心性指標の選択は精度に影響するか。RQ2 障害リソースの種類・障害種別・活性化パターンは有効性に影響するか。RQ3 クラウド環境へのオーバーヘッドはどれほどか。 ## 実験結果 - **RQ1**: PageRank が全障害種別でほぼ全時間帯にわたり他の指標を上回る(Figure 5)。著者は、異常が非一様に広がる可能性を符号化するテレポートの概念が、クラウドでの異常の拡散に適合するためと解釈している。以降は PageRank に固定した。 ![[_attachments/arxiv-1803.00356/fig05-f1-per-index.png]] - **難しさの順序**: どの指標でも packet loss が最難、memory leak がそれに次ぎ、CPU hog が最易である。局所化の質は時間とともに単調に向上するとは限らない。CPU hog だけが向上し、packet loss と memory leak は上昇後に低下する。異常の拡散が広がりすぎ、システムが常時出すノイズ異常に埋もれるためと解釈されている。ITOA-PI は最初の 20 分は異常を計算しないため、その間の F1 は 0 である。 - **RQ2、障害種別**(Figure 6): packet loss は F1 が高くなるまで約 65 分かかり(最初の ITOA-PI 異常から約 40 分)、安定せず、再現率が適合率より高い。memory leak は適合率が常に高く、活性化から離れると再現率が下がる。すなわち、特定できたときは正確である。CPU hog は適合率・再現率とも高い。 ![[_attachments/arxiv-1803.00356/fig06-pagerank-per-fault.png]] - **RQ2、活性化パターン**(Figure 7): 3 パターンで傾向が似ており、成長率への依存は小さい。線形とランダムでは安定し、指数では長期でわずかに低下する。 ![[_attachments/arxiv-1803.00356/fig07-pagerank-per-pattern.png]] - **RQ2、リソース**(Figure 8): 全リソースで高精度だが、Homestead はやや不安定である。Homestead の障害を Sprout と誤ることがある。KPI 数が Sprout 92 に対して Homestead 71 と偏り、相互作用の強い 2 者で KPI 数の多い側にスコアが寄ると推測されている(正規化や均等化は今後の課題)。 ![[_attachments/arxiv-1803.00356/fig08-pagerank-per-resource.png]] - **RQ3**: 監視対象リソースの CPU 使用率が平均 2.63%、メモリ使用率が平均 1.91% 増加した。分析は独立マシンで行うため、追加の負荷はプローブだけである。 ## 考察 - 著者は、LOUD の有効性が、障害注入を含む訓練を要する競合手法(例: Sauvanaud らの Random Forest 手法)と同水準であり、正例のみの訓練で実現している点を強調する。 - 妥当性への脅威として、障害注入戦略(Chaos Monkey と複数の活性化パターンで緩和)、プロトタイプ構成と障害種別の限定(ClearWater のみで、複数テストベッドでの再実験は高価)、スケーラビリティ未検証(ITOA-PI と PageRank の性質から可能と推測)を挙げる。 - 関連研究の整理は、レイテンシ解析(CloudDiag、DARC)、データ分析(PeerWatch、PerfCompass)、機械学習(UBL、POD-Diagnosis)、グラフベース(構造依存のグラフを使う手法)に分ける。著者は、構造依存のグラフは間接的な影響を見落としうるが、LOUD は監視された KPI 間の因果を使うとする。同時期のグラフ系 RCA との比較は [[@2018__CCGrid__CloudRanger - Root Cause Identification for Cloud Native Systems]] を参照。 ## 強み / 弱点・課題 - 強み: 障害注入なしの訓練で運用できる。プローブ以外は独立マシンで動く。中心性指標をべき乗法で計算でき、途中打ち切りができる。指標比較(RQ1)と障害種別・パターン・リソース別の分解が明示的である。 - 弱点・課題: - 評価は単一のテストベッド(ClearWater)、3 種の障害、3 つのリソースに限られる。 - 箇所特定の質が時間とともに劣化する(packet loss と memory leak)。 - KPI 数の偏りによるバイアス(Homestead 対 Sprout)がある。 - 最頻リソースが定まらないときは箇所を出さない(再現率の低下要因)。 - ITOA-PI(商用製品)に依存し、最初の 20 分は異常が出ない。 - 「異常は増え強く相関する」という仮定は、著者自身が今回の実験結果から得た経験則としており、一般性は未検証である。 - 評価は障害注入後の各時刻に対する F1 であり、既存手法との直接の再現実験は行っていない。 ## 出典 - Mariani, Monni, Pezzé, Riganelli, Xin, "Localizing Faults in Cloud Systems", arXiv:1803.00356, 2018.