- <https://www.iot.ipsj.or.jp/symposium/iots2021-program/> - 発表20分質疑応答10分 - 11月26日（金）10:30~ ## To-Do - [x] 序盤の流れの再考 - [x] 要件導出 - [x] 既存手法との比較 - [x] 入力要件の整理 - [x] 背景の配置整理 - [x] データセットの課題 配置整理 - [x] データセットの作成手順 図解 - [x] ラベリングの要件整理 - [x] 評価指標ブラッシュアップ - [x] 実験の設定 図解 - [x] 第一設計基準 和文 - [ ] 未来への道筋 (optional) [[AIOpsアプローチのプロダクション環境での半自動評価]] - [ ] 発表練習 20minに収まるか - [ ] 実装：故障注入スケジューリング部分のみ示す (optioal) - [ ] Sock Shop ## アウトライン - IT運用にAIを適用して改善できないかを研究をしている - AIの推論性能を評価したり、推論性能をあげるために学習したり データセット が重要 - どんなデータセットをどう作るか、という類似の例がすくない研究 ### はじめに (5分) - クラウド上のシステムの複雑化と管理負担の増加 - [[AIOps]]で解決 - 評価用のデータセットとその課題 - 企業はプライバシーやセキュリティの問題で商用環境のデータを公開しづらい。 - 公開データセットと非公開データセット - [[2021__ESEC-FSE__An Empirical Investigation of Practical Log Anomaly Detection for Online Service Systems|LogAD]]の研究では、1~2種類の異常パターンにしか対応できない - [[Loghub]], [[2021__VLDB__Exathlon - A Benchmark for Explainable Anomaly Detection over Time Series]] - 多数の異常パターンに対応したい - しかし、あらゆる異常パターンを内包したデータセットを公開するのは無理がある - データセットの動的生成システム - 完全なデータセットを作成するのではなく、動的にデータセットを生成する - 動的なデータセット生成の難しさ - どのようにして、異常を含むデータを自動で作成するのか？ - 機械学習分野では、データセットには文脈理解のためのラベルが付与されるが、動的生成されるデータセットごとに手動でラベル付与することは手間がかかりすぎる - [[データラベリング]] - 本研究の貢献 1. 異常検知・原因分析の既存文献からデータセットの要件を導出 2. 動的なデータセット生成のための2つの設計基準の提案 - 故障を注入するためのスケジューリングとデータ管理 - データラベリングのための分類手法を提案 3. 実験の結果、分類手法の正解率が85%を達成 ### 2. 関連研究と要件の導出 (5分) - 要件の導出 - データの種別 - メトリック: 時系列の数値データ 7 - イベント: システムイベントに関する高度に構造化されたデータ - ログ: 構造化されていない文字列のログ 3 - トレース: リクエストの実行経路のグラフ 2 - データセット作成手順 - マイクロサービスのデモアプリ ケーションを構築 - そのアプリケーションに対して， 実験者が意図的に故障を注入 - (1) マイクロサービスのデモアプリケーションを構築し，(2) そのアプリケーションに対して， 実験者が意図的に故障を注入し，(3) 故障が注入された前後の期間の運用データを取得する - 対象アプリケーション - [[Sock Shop]] - [[TrainTicket]] - [[Pymicro]] - 故障の種類 - 計算機リソースに関する故障 - マイクロサービス間リクエストの成否・遅延 - マイクロサービス特有の故障 - ラベリングの動機 - データセットの「汚さ」 - 故障注入の結果、システム全体異常 or 部分異常 or 異常なしになるかがわからない - 故障注入期間以外に、異常が混在している可能性がある - 「汚さ」が推論性能の評価結果に影響 - 目視で「異常なし」が真の正解でも、「異常あり」を正答と判定 - 故障注入と関係ない異常を検知しても正答したと判定 - ラベリング：データ分析モデルの学習や評価のために、文脈を提供するプロセス - 「汚さ」のラベリングにより、推論性能を正確に評価したい - データセット作成の課題 - 自動で異常を発生させる必要がある - [[Fault Injection]]と呼ばれるテクニックが必要 - [[Chaos Engineering]] ツール - 目的の差異から、データの採取や管理などの機能がない - 新たなシステムが必要 ### 3. 提案システム (5分) - データセットの要件 - OSSとして公開中 ### 4. 評価 (4分) - 評価項目 - 第一設計基準：「入力となる条件に対応するデータセットが出力されたか？」 - 故障注入とデータ計測の条件の網羅な組み合わせに対する(FOUND_INSIDE_ANOMALYに手動で分類された系列数) / (全選択系列数) - 第二設計基準：「自動で付与したラベルはどの程度正確か？」 - 手動によるラベル付けを正解としたときの正確度（Accuracy） - 実験の設定 - Sock Shopを構成する8種類のコンテナに対して，CPU過負荷とメモリリークの故障を、5回ずつ注入した（計90回の故障注入） - データ取得の間隔は15秒 - スロットの時間範囲を30分 - 第一の設計基準の評価 - 第二の設計基準の評価 - 考察 - 研究の限界 - 対象アプリケーションは固定にならざるをえない ### 5. まとめと今後の課題 (1分) - まとめ - マイクロサービスの異常検知・原因分析の手法を効率よく検証するために、動的にデータセットを生成するシステムMeltriaを提案 - 故障注入のスケジューリング，故障とデータの対応管理 - 統計学の経験則によるデータセットのラベル付けの自動化 - 分類手法の正確度は85% - 誤分類の要因は，変動が小さいケース - 自動ラベリングの正確性は、ヒューマンエラーを含む手動ラベリングと同等程度であることが望ましい - 今後の課題 - リアルアプリケーションへAIOpsを導入する際に自動で評価できるようになることを目指す ## メモ - [[AIOpsアプローチのプロダクション環境での半自動評価]] ## 発表練習 1. 「はじめに」が6分程度 - ラベリングの説明していないけど、どうするか