Recommended
More Related Content
Similar to 教師なし学習によるMackerelの異常検知機能について 〜設計/運用/評価の観点から〜
Similar to 教師なし学習によるMackerelの異常検知機能について 〜設計/運用/評価の観点から〜 (20)
More from syou6162
More from syou6162 (20)
Recently uploaded
Recently uploaded (9)
教師なし学習によるMackerelの異常検知機能について 〜設計/運用/評価の観点から〜
- 2. 自己紹介 • id:syou6162(本名: 吉田康久) • 専門は自然言語処理や機械学習 • 3年前にはてなに転職 – アプリケーションエンジニア – Mackerel/はてなブックマーク 2
- 6. サーバー監視初心者の場合 • 例: アプリケーションエンジニア • クラウドを使うようになって、サーバーも自分 で立てるようになった – しかし、サーバー監視はよく分からない • 本質的にはアプリケーションコードの開発に 集中したい 6
- 7. サーバー監視玄人の場合 • インフラ周りの知識が豊富、何を監視すれば いいか経験的に知っている • 見なければいけないサービスも多く、多忙な ことも • 監視ルールを一度設定すれば終わり、では なく定期的にメンテナンスする必要がある 7
- 8. 機械学習による監視のサポート • 以下を実現したい – インフラの知識があまりなくても、低コストで監視ルー ルが作れる – 人間が列挙するには困難な複数の条件を考慮した 監視ができる • 機械学習による異常検知機能でユーザーをサ ポートしたい! • 3/1にロール内異常検知としてβリリース 8
- 13. その他の問題設定 • 1次元の数値データの問題設定を紹介した • 実際の問題設定はもっと多様 – 数値データではない場合 • 例: ログやイベントデータ(クレジットカードの不正利用) – 多次元の場合 • 例: cpu/memory/disk/interfaceなど • Mackerelでは多次元の数値データに対する外れ 値検出をメインターゲットとした 13
- 14. アラートの具体例 14
- 15. アラートの具体例 15 • ユーザーは細かい設定をする必要がない • ロール内のどのサーバーが異常か分かる • サーバーのどのメトリックが異常か分かる が特徴
- 16. アラートの具体例 16 • このような教師データを事前に集めるのは困難 • ユーザーによって障害の基準が異なる • 障害事例は極めて少ない • 以降では教師なし学習を前提に話します
- 21. ロール内異常検知の要件 • モデルが軽量(メモリ面、速度面) • 検知の根拠が分かる • 検知漏れより誤検知を減らすことを重視 21 • システム運用がしやすいアルゴリズム選定 • 教師なし学習をどうやって手懐けるか • システム評価をどうやっているか の観点からお話します
- 22. ロール内異常検知の要件 • モデルが軽量(メモリ面、速度面) • 検知の根拠が分かる • 検知漏れより誤検知を減らすことを重視 22
- 23. 一般的な機械学習 例: カテゴリ判定の場合 23 判定用APIサーバー URL 1 URL 2 URL 3 URL 4 • 全体でモデルが一個〜 数個しか存在しない • それらを頑張って チューニングする • モデルはメモリ上に事 前に展開しておく Model
- 24. ロール内異常検知の場合 24 判定用APIサーバー Host 1: Role A Host 2: Role B Host 3: Role A Host 4: Role C Model A Model B Model C • 大量のモデルの学習が低 コストにできる必要がある • メモリ上にモデル持ってお くのは困難 – ロール毎にモデルが存在 • リクエストがある度にモデ ルをロード – 判定はリアルタイム – 低latencyが必須
- 26. メモリ面、速度面、コスト面の心配が 少ない混合ガウス分布を選択 • 混合ガウス分布の学習は必要な計算リソースが比 較的少なくて済む – ちなみに学習はAWS Batchでやっています • ロールによらずモデルサイズの上限が分かる – 見積りにくい/ロール毎にlatencyが大きく異なると困る – 混合数で上限が簡単に見積れる • 根拠を出す際にも混合ガウス分布を選択したことが 生きた(後述) 26
- 27. ロール内異常検知の要件 • モデルが軽量(メモリ面、速度面) • 検知の根拠が分かる • 検知漏れより誤検知を減らすことを重視 27
- 29. 解釈可能な機械学習 29 ref: h?ps://github.com/marcotcr/lime h?ps://www.slideshare.net/SatoshiHara3/ss-126157179 • LIMEやSHAPが主流 – 元のモデルを近似した解 釈可能なモデルを学習 • ロール内異常検知は混 合ガウス分布がベース なのでシンプルにできる
- 31. ロール内異常検知の要件 • モデルが軽量(メモリ面、速度面) • 検知の根拠が分かる • 検知漏れより誤検知を減らすことを重視 31
- 33. 誤検知の例 33
- 38. システムの評価(手動) • 実際に起きたアラートを人手でアノテーション – アラート自体と根拠のそれぞれ • 誤報率を時系列でトラッキング • アノテーションを元に誤報の原因を探る、効果の 大きい施策を次のバージョンで導入 – 導入後は再度アノテーションして評価 • 割とどろ臭く頑張ってる 38
- 39. 人手でアノテーション 39
- 41. 参考文献 • 検討した他のアルゴリズム – h?ps://www.yasuhisay.info/entry/ mackerel_anomaly_detecPon_at_pycon_mini_osaka • ディレクター視点でのプロジェクトマネイジメント – https://mackerel.io/ja/blog/entry/ 2019/05/17/120025 41
- 42. 補足資料 42
- 43. サポート/検証観点での再現性 • ユーザーからの問い合わせがあれば回答 • 改善施策前後での判定結果の差分を見たい • 手元での学習/判定の再現性を重視 43
- 44. ロール毎に過去のモデルを保存 44 Role A Role B Role C 2019/05/01 version 1 version 1 version 1 2019/05/15 version 2 version 1 version 1 2019/05/30 version 2 Version 2 Version 2 • ロール毎に30日前までのモデルを保存 • 過去の任意のモデルを使って、任意の時点 での判定結果を手元で再現可能なスクリプト を用意している
- 45. 過去のモデル/判定結果の再現性を担保 45 Role A Role B Role C 2019/05/01 version 1 version 1 version 1 2019/05/15 version 2 version 1 version 1 2019/05/30 version 2 Version 2 Version 2 • ロール毎に30日前までのモデルを保存 • 過去の任意のモデルを使って、任意の時点 での判定結果を手元で再現可能なスクリプト を用意している 例1: 5/5に発生したアラート、もう ちょっと理由が知りたい。手元で再現 してもう少し詳しく分析してくれない? 例2: 5/25に発生したアラート、以前の バージョンだと発生しなかった気がする。 以前のバージョンで試して欲しい
- 46. 専門家の知恵を入れて特徴量選択 46 異常検知と変化検知より引用 • このカイ2乗分布の期待値 はM、分散は2M(Mは特 徴量の次元数)。 • 次元数が高すぎると精度 が悪化する • 障害対応に詳しいSRE(ドメ インエキスパート)にどのメ トリックは削れそうか相談