[[SRE NEXT 2022]]での講演アウトライン。 [[SRE NEXT 2022 CFP]] ### AIOps研究録―SREのためのシステム障害の自動原因診断 作業的性質が強いタスクについては、これまでのソフトウェアによる自動化で解決できつつある。 大量にデータをみて経験から判断をくだすという、人間の認知処理をソフトウェアにより自動化したい。 1. 発表に対する期待値の合意（1分） - AIOpsの用語 - 統計や機械学習などのいわゆるデータサイエンス系の知識がほとんどない状態から、共同研究者（@tsurubee）の助けを借りてはじめた。 - 原因の診断は、定番手法やBig Techが成功した手法というのがまだない。当然、本研究でも、これでうまくいくという手法には至っていない。試行錯誤のための「プロセス」に着目する。 2. SREとAI (4分) - システム障害（インシデント）に関するSREのライフサイクル - 検知（Detection） - 原因の診断・局在化（Diagnosis/Localization） - 緩和（Mitigation） - 根本原因分析（Root Cause Analysis） - 根本対策の実行（Action Items） - 修復・根絶（Remediation） - AIOpsの貢献領域 - [AIOpsの研究動向と
AIOps向けデータセットの動的生成の研究 / Introducing AIOps and A Dynamic Datasets Generating System - Speaker Deck](https://speakerdeck.com/yuukit/introducing-aiops-and-a-dynamic-datasets-generating-system?slide=7) - AIOpsのどの領域に取り組むか？ - AIOpsで最初に連想するのは、障害の検知である。 - しかし、成熟したモニタリング基盤をもつ前提では、障害の発生に気づかないことはないのではないか？ - 障害発生後の、障害の原因はなにか？障害を収める手段は？ - 熟練のSREであっても、これらの問いに即座に回答することは難しいこともある 3. システム障害の原因を診断化（7分） - アラートストームとダッシュボード閲覧の[[認知負荷]]とその要因 - 障害の発生に気づいたときの様子 -> アラートストームの図 - 症状と原因の分離 - 症状と原因のそれぞれを同時に検知する狙いで、多数のメトリクスにアラート条件を設定しているからではないかと考えました。 - Alert symptoms, not causes. - そこで、2020年に思いついたアイディアは、バーンレートなどのサービスレベルの症状の悪化を示すメトリクスに対してのみアラートを通知することにした上で、アラートを起因として、メトリクスを統計解析することにより原因を診断する、というものでした。 - 症状の悪化に対しては、 - [[SREゴールデンシグナル]]/RED、SLOに基づくアラーティング - Chapter 6. Monitoring Distributed Systems, Beyer B, et, al., Site reliability engineering: How Google runs production systems. " O'Reilly Media, Inc."; 2016. - Chapter 5 "Alerting on SLOs", Beyer B, et al., The Site Reliability Workbook: Practical ways to implement SRE. O'Reilly Media, Inc."; 2018. - AIのどの領域の手法を使うのか？ - 確率・統計 / 古典的機械学習 / 深層学習 - 障害の検知であれば、正常時のデータを学習し、異常を検出する。 - [[2017__CCS__DeepLog - Anomaly Detection and Diagnosis from System Logs through Deep Learning|DeepLog]] - ディープニューラルネットの一種であるLSTMを用いて、正常時のログパターンを学習し、逸脱したパターンがあれば異常とする - DeepLogの発展編。 [[2020__ICWS__Root-Cause Metric Location for Microservice System via Log Anomaly Detection]] - 原因の診断では、症状が変化したかだけではなく、相関する大量のデータの中から原因を特定しなければならない。 - 障害発生時の多様なデータを学習する必要がある。 - この分野の難しさとして、企業がインシデントのデータを公開することに積極的ではないため、システム間をまたいで利用できるような学習モデルを構築しづらい。 - 異常が少ないため、教師あり学習が使いづらい。 - 初期の構想 - 原因を診断するには、TCP/UDP通信の依存関係データと、メトリクス間の相関分析を組み合わせれば、疑似相関を排除しながらメトリクス間の因果関係を推論できるのではないかと考えました。 - 既存研究の存在に気づく - 1メトリクスを1確率変数ノードとして因果構造を推定する。 - いずれもサービスレベルの低下を検知したのちに、原因診断処理が走る。 - 2014 [[2014__INFOCOM__CauseInfer―Automatic and distributed performance diagnosis with hierarchical causality graph in large distributed systems|CauseInfer]] - 各コンポーネントのTCPレイテンシとハードウェアリソース使用のメトリクス - TCPのサービス依存関係データの使用 - の2つから因果関係を推定 - 2018 [[2018__ICSOC__Microscope―Pinpoint Performance Issues with Causal Graphs in Micro-service Environments|Microscope]] - マイクロサービスアーキテクチャを対象 - 各マイクロサービスのレイテンシ - TCPのサービス依存関係データの使用 - 同居ホストの影響を考慮 - 発展 [[2020__WWW__AutoMAP - Diagnose Your Microservice-based Web Application|AutoMAP]], [[2020__IPCCC__FluxInfer―Automatic Diagnosis of Performance Anomaly for Online Database System|FluxInfer]] [[2019__ISSRE__FluxRank―A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]], [[2020__IWQoS__Localizing Failure Root Causes in a Microservice through Causality Inference|MicroCause]] - 統計的因果推論/因果探索分野の存在 - ベイジアンネットワーク [[PCアルゴリズム]] - 既存研究での未解決な領域を探る - 個々のメトリクスの時系列を確率変数とみなしたときに、変数を予め指定する必要がある。 - また、指定した変数に対して個別に適切な関数を選んだり、チューニングする必要がある手法もある。 - 仮設：大量のメトリクスを収集できるようになったにも関わらず、それらのメトリクスを見切れていないのではないか？ - とっかかりイシュー - 問題設定 - 種別が異なる、多変量時系列データ（メトリクス）に対して、 - メトリクスごとの分布や関数の仮定とチューニングなしで、 - 数分単位での実行時間で、 - オフラインでSREsが認識可能なレベルでの変化をもつ時系列を抽出する。 - ただし、短時間の系列 - 直近 n分までみればいい？ - 目標とするアウトプット。 4. 時系列解析・因果関係推定のためのモデルの構築と評価（25分） - 4.1. メトリクスの次元削減 - 2段階の次元削減 - 単変量時系列の異常性に着目 - 時系列の変動パターン - 最も単純な例：[[変動係数]] - 古典的な時系列の統計解析 - 定常性とその検定 - 偽陽性も偽陰性も両方ある。差分をとって定常。 - 統計的機械学習のアプローチ - 外れ値検知 - 正規分布を仮定する - ホテリングのT2理論 - ARモデル - 異常部位検出 - 継続中の異常がどこから開始したかは - 変化点検知 - オフライン [[2020__Signal-Processing__Selective review of offline change point detection methods]] - オンライン [[ChangeFinder]] [[特異スペクトル変換法]] - 外れ値検知と異常部位検出が必要となる。 - ARモデルのサンプル内予測 -> 適合しづぎる - ARモデルのサンプル外予測 -> 正常データの範囲を仮定 - オンライン検出系 - 特異スペクトル変換法 ウィンドウサイズをデータの半分に - 多変量時系列の類似性に着目 - サービス単位での時系列クラスタリング - クラスタを決めて、各クラスタの代表系列を決定。 - [[2015__Information Systems__Time-series clustering – A decade review]] - k-Shape 2015 SIGMOD - クラスタ数を予め指定する法と指定しない法がある - 事前には決まらないため、階層型クラスタリングを選択する。 - SBDの組み合わせ - 不採用 - フェーズ1で異常度の時系列を出力しているので、異常度の時系列に対するクラスタリング - 異常度が0より大きい値をすべて1とするバイナリ時系列に変換し、ハミング距離にあてることも検討。 - 実験の結果 - 4.2. 因果構造の推定（因果探索） - 次元削減後の多変量時系列に対して、素朴にPCアルゴリズムを適用する。 - 各メトリクスの変数を条件付き独立性検定によりエッジ削除 - 類似の変動を示す時系列間の偏相関により、疑似相関の誤判定するケースがあった。 - 時系列のラグに着目 因果の関係から -> - 4.3 学術的貢献を思案中 - [[Fault Localization向けの特徴量削減手法の調査]] - 因果グラフの構築とそのトラバースのための適切な前処理フレームワークを構築する - ChangeFinder論文に触発されている 5. AIOps研究の困難と将来 - やってみて難しかったこと - 実験に使えるような実環境データが入手しづらい -> Meltriaを開発 - 国内では、AIOpsに取り組んでいる人が少ないため、コミュニティで情報を共有しながらみんなで進んでいくことが難しい - AIOps分野の書籍が英語圏も含めて存在しない - データサイエンスの特定領域の知識だけでは完結しないため、学ぶことが大変でもありおもしろくもある - 将来 - 中期：システムごとの個別学習モデル - 統計・機械学習の各モデルをUNIXのようにパイプラインで組み合わせるアーキテクチャ - 長期：システムを横断したモノリスの巨大学習モデル - 実環境のうち、プロダクション環境のMELTデータと、システム障害の管理メタデータが入手できるようになると、複数のシステムにまたがってみられる共通のパターンを認識して、単一の巨大な学習モデルをみんなが使うことができる。 6. まとめ (1分) - SREのシステム障害のライフサイクルのうち、障害の緩和（Mitigation）に対する原因診断を自動化する研究を紹介した。 - 単独でAIOps研究をすすめる限界も感じ始めていて、コミュニティを育てていきたい。 - モニタリングSaaSのAIOps機能の使用感の共有など。 - システム障害（インシデント）の共有と、障害前後の運用データの共有。 - [[VOID]] 複雑なソフトウェアの運用に適応するために、AIにより人間の認知依存の処理が自動化される一方で、AIという別方向に複雑なソフトウェアが新たに構築される。この壮大なIronies of Automation（自動化の皮肉）を人類はどのように解決していくのかを当事者としてみていきたい。 メガクラウド企業がすべてをコントロールするのか、コントロールを明け渡して民主化していくのかはわからない。 SRE Lounge Slackに `#topic-aiops` 4/10まで。 想定ポモドーロ数 60 + 10 （録画） 4/3: 5 残り55 - [x] AIOpsの起源 - [x] AIOpsのどの領域に取り組むか？(Optional) - [x] AI領域のいずれの手法を使うのか？ (Optional) - [x] さらなる先行研究の整理 ログとかも - [x] 研究の問題設定 - [x] 次元削減手法の概観 - [x] ARモデルの予測誤差の整理 - [x] SBDのNOCとかの記述 - [x] PCアルゴリズムの課題改善 - [ ] PCMCI+の手法 (Optional) - [ ] 変化点開始の推定手法の記述 (Optional) - [x] モデル試行錯誤のまとめ - [x] 全体まとめ - [x] 話さなかったこと Meltria - [x] 将来の展望 - [x] データ共有コミュニティ インシデントの内容コミュニティ