Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

教師なし学習によるMackerelの異常検知機能について 〜設計/運用/評価の観点から〜

Machine Learning Casual Talks #10での登壇資料です

https://mlct.connpass.com/event/125316/

  • Login to see the comments

教師なし学習によるMackerelの異常検知機能について 〜設計/運用/評価の観点から〜

  1. 1. 教師なし学習による Mackerelの異常検知機能について 〜設計/運用/評価の観点から〜 Machine Learning Casual Talks #10 id:syou6162
  2. 2. 自己紹介 •  id:syou6162(本名: 吉田康久) •  専門は自然言語処理や機械学習 •  3年前にはてなに転職 – アプリケーションエンジニア – Mackerel/はてなブックマーク 2
  3. 3. h?ps://mackerel.io/ja/ Mackerel: SaaS型の サーバー監視/管理 サービス Agentがサーバーの メトリックを収集、 グラフで可視化 3
  4. 4. 4 サービス/ロール毎に監視ルール設定 静的な閾値によるアラートの発報 サービス/ロールでホストを 分かりやすくグルーピング はてな ブックマーク DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 はてなブログ DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 例: CPUの使用率が90% 越えたらCriPcalアラート
  5. 5. サーバー監視の困り事 •  サーバー監視初心者の場合 •  サーバー監視玄人の場合 5
  6. 6. サーバー監視初心者の場合 •  例: アプリケーションエンジニア •  クラウドを使うようになって、サーバーも自分 で立てるようになった – しかし、サーバー監視はよく分からない •  本質的にはアプリケーションコードの開発に 集中したい 6
  7. 7. サーバー監視玄人の場合 •  インフラ周りの知識が豊富、何を監視すれば いいか経験的に知っている •  見なければいけないサービスも多く、多忙な ことも •  監視ルールを一度設定すれば終わり、では なく定期的にメンテナンスする必要がある 7
  8. 8. 機械学習による監視のサポート •  以下を実現したい –  インフラの知識があまりなくても、低コストで監視ルー ルが作れる –  人間が列挙するには困難な複数の条件を考慮した 監視ができる •  機械学習による異常検知機能でユーザーをサ ポートしたい! •  3/1にロール内異常検知としてβリリース 8
  9. 9. 代表的な問題設定1: 外れ値検知 9 仲間から外れている 以降のスライドの図は h?ps://qiita.com/kenmatsu4/items/68e48a00aaebf338bedc より生成 時刻 メモリ 使用量
  10. 10. 代表的な問題設定2: 時系列的な外れ値検知 10 横軸でシャッフルすると 検知できない 時刻
  11. 11. 代表的な問題設定3: 変化検知 11 値のずれというより観測値の振舞いが 変化。周期が短かくなっている 時刻
  12. 12. 代表的な問題設定4:異常部位検出 12 心電図データ。外れ値と変化点が 同時に起きている 時刻
  13. 13. その他の問題設定 •  1次元の数値データの問題設定を紹介した •  実際の問題設定はもっと多様 –  数値データではない場合 •  例: ログやイベントデータ(クレジットカードの不正利用) –  多次元の場合 •  例: cpu/memory/disk/interfaceなど •  Mackerelでは多次元の数値データに対する外れ 値検出をメインターゲットとした 13
  14. 14. アラートの具体例 14
  15. 15. アラートの具体例 15 •  ユーザーは細かい設定をする必要がない •  ロール内のどのサーバーが異常か分かる •  サーバーのどのメトリックが異常か分かる が特徴
  16. 16. アラートの具体例 16 •  このような教師データを事前に集めるのは困難 •  ユーザーによって障害の基準が異なる •  障害事例は極めて少ない •  以降では教師なし学習を前提に話します
  17. 17. 前提: どの単位でモデルを学習するか 17 はてな ブックマーク DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 はてなブログ DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02
  18. 18. 全てのサーバー? 18 はてな ブックマーク DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 はてなブログ DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 Model 様々な役割のサーバが 混在しているため 学習が難しい。誤検知も 多い
  19. 19. 単一のホスト? 19 はてな ブックマーク DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 はてなブログ DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 学習は容易に。 同じようなデータ集合が あるならば、データが増 えたほうが精度が出る Model 1 Model 2 Model 3 Model 4 Model 5 Model 6 Model 7 Model 8 Model 9 Model 10 Model 11 Model 12
  20. 20. ロール毎にモデルを作る 20 はてな ブックマーク DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 はてなブログ DB App Proxy DB_01 DB_02 App_01 App_02 Proxy_01 Proxy_02 同じような動きをするホ ストがまとまっているた め、学習が容易。 単一ホストで学習するよ りも多くの学習データが 使えるため精度向上も 望める Model 1 Model 2 Model 3 Model 4 Model 5 Model 6
  21. 21. ロール内異常検知の要件 •  モデルが軽量(メモリ面、速度面) •  検知の根拠が分かる •  検知漏れより誤検知を減らすことを重視 21 •  システム運用がしやすいアルゴリズム選定 •  教師なし学習をどうやって手懐けるか •  システム評価をどうやっているか の観点からお話します
  22. 22. ロール内異常検知の要件 •  モデルが軽量(メモリ面、速度面) •  検知の根拠が分かる •  検知漏れより誤検知を減らすことを重視 22
  23. 23. 一般的な機械学習 例: カテゴリ判定の場合 23 判定用APIサーバー URL 1 URL 2 URL 3 URL 4 •  全体でモデルが一個〜 数個しか存在しない •  それらを頑張って チューニングする •  モデルはメモリ上に事 前に展開しておく Model
  24. 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が必須
  25. 25. どういったモデルを選ぶか •  GAN/AEを使った異常検知手法もあるが… – 多くの計算リソースが必要 – 定期的にロール毎に再学習をする必要があるた め、低コストで学習できることは重要 •  近傍法に基づいた手法(LOFなど) – 学習コストは低いが、予測時にモデルをロード(= 学習データをロード)するため、latencyが大きい 25
  26. 26. メモリ面、速度面、コスト面の心配が 少ない混合ガウス分布を選択 •  混合ガウス分布の学習は必要な計算リソースが比 較的少なくて済む –  ちなみに学習はAWS Batchでやっています •  ロールによらずモデルサイズの上限が分かる –  見積りにくい/ロール毎にlatencyが大きく異なると困る –  混合数で上限が簡単に見積れる •  根拠を出す際にも混合ガウス分布を選択したことが 生きた(後述) 26
  27. 27. ロール内異常検知の要件 •  モデルが軽量(メモリ面、速度面) •  検知の根拠が分かる •  検知漏れより誤検知を減らすことを重視 27
  28. 28. 検知の根拠が分かる •  障害時には携帯などから何がおかしくなって いそうかぱっと分かると便利 28 サーバーの「何が」異常 かも気になる!
  29. 29. 解釈可能な機械学習 29 ref: h?ps://github.com/marcotcr/lime h?ps://www.slideshare.net/SatoshiHara3/ss-126157179 •  LIMEやSHAPが主流 –  元のモデルを近似した解 釈可能なモデルを学習 •  ロール内異常検知は混 合ガウス分布がベース なのでシンプルにできる
  30. 30. 条件付き確率から根拠を提示 •  どのメトリックが特に異常かを条件付き確率 から算出できる – ガウス分布の条件付き分布もガウス分布 •  混合ガウス分布のモデル一つで異常判定も 根拠提示もできる – モデルの管理コスト、ロード時間を削減できる 30
  31. 31. ロール内異常検知の要件 •  モデルが軽量(メモリ面、速度面) •  検知の根拠が分かる •  検知漏れより誤検知を減らすことを重視 31
  32. 32. 検知漏れより誤検知を削減を重視 •  検知漏れと誤検知は基本的にトレードオフ – ロール内異常検知では誤検知削減を重視 – 機械学習以外の監視ルールでカバーできるため •  教師あり学習と比較すると、人間が挙動を制御 するのは難しい – ロール内異常検知は教師なし学習 – ちょっとした変化ではアラートが鳴らないで欲しい、と いった制御はしたい 32
  33. 33. 誤検知の例 33
  34. 34. 誤検知の例 34 メモリ使用量の変化がほとんど ない(=分散がゼロに近い状態)
  35. 35. 誤検知の例 35 使用メモリ量が数十Mb増加。 人間にとっては何でもない変化だが、 異常検知は反応してしまっていた…
  36. 36. 事前分布で人間の直感と合うように •  「このメトリックはこれくらいは変動し得る」とい う人間の知識を、分散の事前分布として導入 – 誤検知が起こりにくいように大きめの値に設定 36 データから決まる尤度 分散パラメータの事前分布。 これを通じて、人間の知識 をモデルに取り入れる
  37. 37. システムの評価(自動) •  以下の数値をダッシュボードにまとめて評価 – 監視されているサーバー数 – muteされている監視ルール数 – 発報されたアラート数 – ロール内異常検知と同時刻に起きた他の監視 (例: ログ監視)によるアラート数 – latency、使用しているcpu/memoryなどなど 37
  38. 38. システムの評価(手動) •  実際に起きたアラートを人手でアノテーション –  アラート自体と根拠のそれぞれ •  誤報率を時系列でトラッキング •  アノテーションを元に誤報の原因を探る、効果の 大きい施策を次のバージョンで導入 –  導入後は再度アノテーションして評価 •  割とどろ臭く頑張ってる 38
  39. 39. 人手でアノテーション 39
  40. 40. まとめ •  3月にβリリースしたMackerelのロール内異常 検知について紹介 •  運用/評価/設計の観点での工夫を紹介 – モデルが軽量(メモリ面、速度面) – 検知の根拠が分かる – 検知漏れより誤検知を減らすことを重視 40
  41. 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. 補足資料 42
  43. 43. サポート/検証観点での再現性 •  ユーザーからの問い合わせがあれば回答 •  改善施策前後での判定結果の差分を見たい •  手元での学習/判定の再現性を重視 43
  44. 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. 過去のモデル/判定結果の再現性を担保 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. 専門家の知恵を入れて特徴量選択 46 異常検知と変化検知より引用 •  このカイ2乗分布の期待値 はM、分散は2M(Mは特 徴量の次元数)。 •  次元数が高すぎると精度 が悪化する •  障害対応に詳しいSRE(ドメ インエキスパート)にどのメ トリックは削れそうか相談

×