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 Anomaly Detection at PyCon mini Osaka

3,924 views

Published on

PyCon mini OsakaでのMackerelの異常検知に関する発表です

Published in: Engineering
  • Be the first to comment

Mackerel Anomaly Detection at PyCon mini Osaka

  1. 1. Pythonを用いた 異常検知システム構築の裏側 PyCon mini Osaka id:syou6162 1
  2. 2. 自己紹介 •  id:syou6162(本名: 吉田康久) •  前職: NTTコミュニケーション科学基礎研究所 – 自然言語処理や機械学習の研究に従事(4年) •  2年前にはてなに転職 – はてなブックマーク – サーバー管理/監視システムMackerel 2
  3. 3. はじめに •  現在開発中の機能につき、リリース時には詳 細が変更されている可能性があります 3
  4. 4. アジェンダ •  サーバー監視の困り事 •  異常検知とは? •  異常検知の代表的なアルゴリズム •  異常検知システムを支えるアーキテクチャ 4
  5. 5. 想定しているリスナー •  簡単な機械学習はやったことがある •  異常検知はやったことがないが、興味がある •  機械学習システムのアーキテクチャに興味が ある 5
  6. 6. 話さないこと •  機械学習とは? •  異常検知の最先端研究の話題 •  機械学習関連の組織的な取り組み – hCp://www.yasuhisay.info/entry/ 2018/02/19/122000 6
  7. 7. アジェンダ •  サーバー監視の困り事 •  異常検知とは? •  異常検知の代表的なアルゴリズム •  異常検知システムを支えるアーキテクチャ 7
  8. 8. hCps://mackerel.io/ja/ Mackerel: SaaS型の サーバー監視/管理 サービス Agentがサーバーの メトリックを収集、 グラフで可視化 8
  9. 9. 9 サービス/ロール毎に監視ルール設定 静的な閾値によるアラートの発砲 メール/Slack/HipChat などへの通知をサポート サービス/ロールでホストを 分かりやすくグルーピング はてな ブックマーク 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
  10. 10. 例1: アプリケーションエンジニア •  普段はWebアプリケーションのコードを書く •  クラウドを使うようになって、サーバーも自分で 立てるようになった •  しかし、サーバー監視はあまり分からない… •  サーバー監視を勉強すればよいが、本質的には アプリケーションコードの開発に集中したい! 10
  11. 11. 例2: インフラエンジニア •  インフラ周りの知識が豊富、何を監視すれば いいか経験的に知っている •  見なければいけないサービスも多く、多忙 •  サービスの成熟度合いによって、アラートの 閾値のメンテナンスをする必要がある – そのコストを減らしたい! 11
  12. 12. 機械学習による異常検知 •  以下を実現したい – インフラの知識があまりなくても – 低コストで監視ルールが作れて – 自動的にルールが更新される •  機械学習による異常検知機能を提供しよう! 12
  13. 13. アジェンダ •  サーバー監視の困り事 •  異常検知とは? •  異常検知の代表的なアルゴリズム •  異常検知システムを支えるアーキテクチャ 13
  14. 14. 異常検知とは •  Grubbs, 1969 –  “An outlying observaon, or outlier, is one that appears to deviate markedly from other members of the sample in which it occurs.” •  Hawkins, 1980 –  “An observaon that deviates so much from other observaons as to arouse suspicion that is was generated by a different mechanism.” •  BarneC & Lewis, 1994 –  “An observaon (or subset of observaons) which appears to be inconsistent with the remainder of that set of data.” •  統一的な定義/見解はない 14 hCps://www.slideshare.net/shoheihido/deep-learning-lab-88299985 より引用
  15. 15. 代表的な問題設定1: 外れ値検知 15 仲間から外れている 以降のスライドの図は hCps://qiita.com/kenmatsu4/items/68e48a00aaebf338bedc より生成 時刻 メモリ 使用量
  16. 16. 代表的な問題設定2: 時系列的な外れ値検知 16 横軸でシャッフルすると 検知できない 時刻
  17. 17. 代表的な問題設定3: 変化検知 17 値のずれというより観測値の振舞いが 変化。周期が短かくなっている 時刻
  18. 18. 代表的な問題設定4:異常部位検出 18 心電図データ。外れ値と変化点が 同時に起きている 時刻
  19. 19. その他の問題設定 •  1次元の数値データの問題設定を紹介した •  実際の問題設定はもっと多様 –  数値データではない場合 •  例: ログやイベントデータ(クレジットカードの不正利用) –  多次元の場合 •  例: cpu/memory/disk/interfaceなど •  Mackerelでは多次元の数値データに対する外れ 値検出をメインターゲットとした 19
  20. 20. アジェンダ •  サーバー監視の困り事 •  異常検知とは? •  異常検知の代表的なアルゴリズム •  異常検知システムを支えるアーキテクチャ 20
  21. 21. 異常検知の代表的な手法 •  ホテリングのT2法 •  混合ガウス分布モデル •  近傍法 •  部分空間法による変化検知 •  疎構造学習による異常検知 21 シンプル 高機能/複雑
  22. 22. ガウス分布に基づく方法(ラベルあり) 22 異常時(y=1)の分布 正常時(y=0)の分布 •  異常時のラベルが手に入る 場合、正常時と異常時の密 度比から判定ができる •  p(x|y=1, D) / p(x|y=0, D)が 閾値を越えたら異常と判定 •  デメリット: 異常時のデータ が必ずしも手に入るとは限 らない CPU使用率 確 率
  23. 23. ラベルなしの場合(ホテリングのT2法) 23 異常と判定 正常と判定 •  異常時のラベルが手に 入らない場合、正常時 の確率密度から判定 •  - p(x|y=0, D)が閾値を越 えたら異常と判定 •  メリット: 計算が簡単 CPU使用率 確 率
  24. 24. 混合ガウス分布に基づく異常検知 •  ガウス分布一つでは多峰性に対応できない –  例: 休日/平日、昼間/夜間 •  K個のガウス分布の混合で対応 –  ref: sklearn.mixture.GaussianMixture 24 memory 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース1 異常と判定されるケース2 cpu
  25. 25. 近傍法に基づく異常検知 •  自分との距離がε以内にあるデータ点数をNとする –  N < k以下であれば異常と判定 •  通常のk近傍法では誤検知が多い。カーネルを使って 距離学習するかLocal Outlier Factorなどが実用的 –  ref: sklearn.neighbors.LocalOutlierFactor 25 •  メリット: ガウス分布に従わない データにも適用可能 •  デメリット –  学習データを全て持つ必要がある –  kやεの設定にセンシティブ k=3の場合 正常と判定 異常と判定 ε ε
  26. 26. 部分空間法による変化検知 •  時刻tの前後の区間で確率分布を計算。2つの確率分布間の 相違度(KLダイバージェンス)を異常度として計算 •  異常度が閾値を越えた場合、その点で変化が起こったと報告 –  ref: hCps://github.com/tsurubee/banpei wriCen in Python •  デメリット: 異常度の計算で特異値分解を使う(特異スペクトル 変換)ため、比較的計算時間がかかる 26 時刻 t p(x) p’(x) 異常度 = ∫p(x) log(p(x) / p’(x)) dx CPU 使用率
  27. 27. 疎構造学習に基づく異常検知 •  異常検知を行なうだけでなく、どの変数がおかしいか教えて欲しい –  例: サーバーAが異常、だけではなくCPUの使用率が通常と異なるまで教えて! •  変数間の関係をガウス分布に基づく対マルコフグラフで学習。得られた精 度行列と条件付き確率を用いて、異常度が計算できる •  R実装は存在(Pythonはまだない!) hCps://github.com/hoxo-m/sGMRFmix 27 変数iの異常度 = - log p(xi | x-i, D) cpu memory disk interface filesystem 疎構造学習を使うと変数 毎に異常度を計算できる ガウス分布を仮定すると条件付き 対数尤度も容易に計算できる。 混合分布を用いることで多峰性が 存在する場合でも対応できる [ICDM2016] cpu memory disk interface filesystem ホストが異常か分かるが、ど のメトリックが異常かは未知 混合ガウス分布 疎構造学習
  28. 28. 再掲: 異常検知の代表的な手法 •  ホテリングのT2法 •  混合ガウス分布モデル •  近傍法 •  部分空間法による変化検知 •  疎構造学習による異常検知 28 シンプル 高機能/複雑
  29. 29. Mackerelで求められる要件(1) •  [できるとよい]学習の計算時間/使用メモリ –  少ないほうが望ましいが、定期的な更新で十分。多少は 許容できる •  [必須]予測時の即時性 –  メトリックが送られてからすぐに異常検知ができる •  [必須]予測時に省メモリであること –  ユーザー毎にモデルが存在するため、メモリを大量に使う モデルは使えない(例: 近傍法) •  [必須]多峰性への対応 –  サーバー負荷は平日/週末、昼間/夜間で変化する 29
  30. 30. Mackerelで求められる要件(2) •  [必須]定期的にモデルが更新されること –  サービスの状態は変化する •  [必須]細かくチューニングしなくてもある程度精度が出る –  チューニング用のラベル付きデータが必ずしも手に入るわけで はない –  ハイパーパラメータが多いモデルは採用しにくい •  [できるとよい]変化検知 –  変化点が分かるとサーバースペックの見直しのきっかけができ るが、必須ではない •  [できるとよい]どの変数が異常か説明可能 –  どの変数が異常か分かると障害対応への初動も早くできるが、 グラフを見れば人間はある程度分かる 30
  31. 31. 即時性 計算時間 メモリ量 多峰性 チューニン グが容易 変化検知 説明性 ホテリングの T2法 ○ ○ ○ × ○ × × 混合ガウス 分布 ○ △ ○ ○ ○ × × 近傍法 △ △ × ○ △ ○ × 特異 スペクトル変換 × × △ × △ ○ × 疎構造学習 ○ × △ ○ △ ○ ○ 異常検知の手法とMackerelでの要件 31
  32. 32. 採用:混合ガウス分布による異常検知 •  約20次元のシステムメトリックに限定して学習及び予測 –  不必要な次元が多数存在すると、正確な異常検知が難しい –  ユーザー毎に自動的に特徴量選択はまだまだ難しい 32 cpu memory 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース1 異常と判定されるケース2
  33. 33. 実例 33 GWにとあるサーバーでfull GC が走り、負荷が一時的に上昇 cpu/memoryなど個別の ルールは指定していない。 ロールの指定のみ
  34. 34. アジェンダ •  サーバー監視の困り事 •  異常検知とは? •  異常検知の代表的なアルゴリズム •  異常検知システムを支えるアーキテクチャ 34
  35. 35. 異常検知のアーキテクチャ 時系列DB メトリック投稿 メトリックが異常か判定/結果を保存 学習済みパラメータを取得 学習データを取得 学習済み パラメータを保存 学習ジョブを投入 35 予測部 EC2 DynamoDB AWS Batch Agent Mackerel本体 学習部
  36. 36. 異常検知のアーキテクチャ 時系列DB メトリック投稿 メトリックが異常か判定/結果を保存 学習済みパラメータを取得 学習データを取得 学習済み パラメータを保存 学習ジョブを投入 36 EC2上で動く一般的なAPIサーバー。 FlaskとuWSGIを使用。詳細は省略 EC2 DynamoDB AWS Batch Agent Mackerel本体 メインで説明 メインで説明
  37. 37. 高頻度かつ不定期な学習が必要 37 はてなブログ DB App Proxy はてな ブックマーク DB App Proxy 異常検知モデル1 異常検知モデル2 異常検知モデル3 異常検知モデル4 異常検知モデル5 異常検知モデル6 •  スパム検知などの機械 学習ではモデルが1つ あればよい •  異常検知ではロール毎 にモデルが必要 –  同じ名前のロールでも サービスが異なれば傾 向が異なる •  ジョブキューシステムを 自前で管理したくない
  38. 38. AWS Batchについて •  フルマネージド型バッチ処理サービス(ジョブキュー) •  裏側にECSのクラスタが存在し、ジョブが投入されるとEC2イ ンスタンスを自動起動。ジョブが終了したらEC2インスタンス も終了 –  学習ジョブの流量は変動するため必要なインスタンス数も変動 38 RetryやTimeoutについても AWS Batchが面倒を見てくれる
  39. 39. Mackerelの時系列DBについて: 既存の時系列DBの問題点 •  以前はOSSの時系列DBであるGraphiteを使用 •  問題点: –  コスト面。高性能なデバイスが必要 –  データロスト耐性の低さ –  古いデータは丸められてしまい、生データが見れなく なる –  例: 1分粒度でデータが投稿されていても、10日前の データは5分粒度に丸められてしまう 39
  40. 40. 異常検知は生データが大事! •  荒い粒度のデータしか学習で使えない場合、生データの多峰 性を根本的に学習できない –  誤検知が発生しやすくなってしまう •  アルゴリズムだけでなく生データを貯蓄する術も重要! 40 生データ(細かい粒度) 5分平均(荒い粒度) 生データから 学習した確率分布 荒い粒度で 学習した確率分布 時刻 CPU 使用率
  41. 41. 参考: Mackerelの時系列DBにおける 各種ストレージの使い分け 41 容量単価 スケーラビリティ レイテンシ 古いメトリック 新しいメトリック あまり参照されない 頻繁に参照される 保持コスト 読み書きコスト S3 DynamoDB Redis hCps://speakerdeck.com/itchyny/serverlessconf-tokyo-2017 より
  42. 42. AWS Batchのモニタリング •  AWS Batchのジョブキューの状態と裏側で立ち上がるECSの状 態はMackerelプラグインでモニタリング可能 –  hCps://github.com/mackerelio/mackerel-plugin-aws-batch –  hCps://github.com/mackerelio/mackerel-plugin-aws-ecs •  成功/失敗の状態は取れないので、Cloudwatch Eventから slackで通知 42
  43. 43. まとめ •  なぜ機械学習を用いた異常検知が必要か –  監視に未経験でもできる/詳しい人の手間を減らす •  代表的な異常検知のアルゴリズム –  様々なアルゴリズムがある中でサービス要求に合う混合 ガウス分布による異常検知を選択 •  異常検知システムを支えるアーキテクチャ –  誤検知を少なくするためには、荒い粒度ではなく生データ が重要。独自の時系列DBを構築 –  AWS Batchで高頻度かつ不定期な学習ジョブに対応 43
  44. 44. 参考文献 •  “異常検知と変化検知” 井手剛,杉山将,講談社,2015 •  “入門 機械学習による異常検知 ── Rによる実践ガイド ──” 井手剛, コロナ社, 2015 •  [ICDM2016]“Sparse Gaussian Markov Random Field Mixtures for Anomaly Detecon” –  Tsuyoshi Ide, Ankush Khandelwal, Jayant Kalagnanam, Proceedings of the 2016 IEEE Internaonal Conference on Data Mining (ICDM 16, December 13-15, 2016, Barcelona, Spain), pp. 955-960. 44

×