Recommended
More Related Content
Similar to Mackerel Anomaly Detection at PyCon mini Osaka
Similar to Mackerel Anomaly Detection at PyCon mini Osaka (20)
More from syou6162
More from syou6162 (20)
Mackerel Anomaly Detection at PyCon mini Osaka
- 2. 自己紹介 • id:syou6162(本名: 吉田康久) • 前職: NTTコミュニケーション科学基礎研究所 – 自然言語処理や機械学習の研究に従事(4年) • 2年前にはてなに転職 – はてなブックマーク – サーバー管理/監視システムMackerel 2
- 4. アジェンダ • サーバー監視の困り事 • 異常検知とは? • 異常検知の代表的なアルゴリズム • 異常検知システムを支えるアーキテクチャ 4
- 5. 想定しているリスナー • 簡単な機械学習はやったことがある • 異常検知はやったことがないが、興味がある • 機械学習システムのアーキテクチャに興味が ある 5
- 6. 話さないこと • 機械学習とは? • 異常検知の最先端研究の話題 • 機械学習関連の組織的な取り組み – hCp://www.yasuhisay.info/entry/ 2018/02/19/122000 6
- 7. アジェンダ • サーバー監視の困り事 • 異常検知とは? • 異常検知の代表的なアルゴリズム • 異常検知システムを支えるアーキテクチャ 7
- 10. 例1: アプリケーションエンジニア • 普段はWebアプリケーションのコードを書く • クラウドを使うようになって、サーバーも自分で 立てるようになった • しかし、サーバー監視はあまり分からない… • サーバー監視を勉強すればよいが、本質的には アプリケーションコードの開発に集中したい! 10
- 11. 例2: インフラエンジニア • インフラ周りの知識が豊富、何を監視すれば いいか経験的に知っている • 見なければいけないサービスも多く、多忙 • サービスの成熟度合いによって、アラートの 閾値のメンテナンスをする必要がある – そのコストを減らしたい! 11
- 12. 機械学習による異常検知 • 以下を実現したい – インフラの知識があまりなくても – 低コストで監視ルールが作れて – 自動的にルールが更新される • 機械学習による異常検知機能を提供しよう! 12
- 13. アジェンダ • サーバー監視の困り事 • 異常検知とは? • 異常検知の代表的なアルゴリズム • 異常検知システムを支えるアーキテクチャ 13
- 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 より引用
- 19. その他の問題設定 • 1次元の数値データの問題設定を紹介した • 実際の問題設定はもっと多様 – 数値データではない場合 • 例: ログやイベントデータ(クレジットカードの不正利用) – 多次元の場合 • 例: cpu/memory/disk/interfaceなど • Mackerelでは多次元の数値データに対する外れ 値検出をメインターゲットとした 19
- 20. アジェンダ • サーバー監視の困り事 • 異常検知とは? • 異常検知の代表的なアルゴリズム • 異常検知システムを支えるアーキテクチャ 20
- 21. 異常検知の代表的な手法 • ホテリングのT2法 • 混合ガウス分布モデル • 近傍法 • 部分空間法による変化検知 • 疎構造学習による異常検知 21 シンプル 高機能/複雑
- 22. ガウス分布に基づく方法(ラベルあり) 22 異常時(y=1)の分布 正常時(y=0)の分布 • 異常時のラベルが手に入る 場合、正常時と異常時の密 度比から判定ができる • p(x|y=1, D) / p(x|y=0, D)が 閾値を越えたら異常と判定 • デメリット: 異常時のデータ が必ずしも手に入るとは限 らない CPU使用率 確 率
- 23. ラベルなしの場合(ホテリングのT2法) 23 異常と判定 正常と判定 • 異常時のラベルが手に 入らない場合、正常時 の確率密度から判定 • - p(x|y=0, D)が閾値を越 えたら異常と判定 • メリット: 計算が簡単 CPU使用率 確 率
- 24. 混合ガウス分布に基づく異常検知 • ガウス分布一つでは多峰性に対応できない – 例: 休日/平日、昼間/夜間 • K個のガウス分布の混合で対応 – ref: sklearn.mixture.GaussianMixture 24 memory 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース1 異常と判定されるケース2 cpu
- 25. 近傍法に基づく異常検知 • 自分との距離がε以内にあるデータ点数をNとする – N < k以下であれば異常と判定 • 通常のk近傍法では誤検知が多い。カーネルを使って 距離学習するかLocal Outlier Factorなどが実用的 – ref: sklearn.neighbors.LocalOutlierFactor 25 • メリット: ガウス分布に従わない データにも適用可能 • デメリット – 学習データを全て持つ必要がある – kやεの設定にセンシティブ k=3の場合 正常と判定 異常と判定 ε ε
- 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. 疎構造学習に基づく異常検知 • 異常検知を行なうだけでなく、どの変数がおかしいか教えて欲しい – 例: サーバー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. 再掲: 異常検知の代表的な手法 • ホテリングのT2法 • 混合ガウス分布モデル • 近傍法 • 部分空間法による変化検知 • 疎構造学習による異常検知 28 シンプル 高機能/複雑
- 29. Mackerelで求められる要件(1) • [できるとよい]学習の計算時間/使用メモリ – 少ないほうが望ましいが、定期的な更新で十分。多少は 許容できる • [必須]予測時の即時性 – メトリックが送られてからすぐに異常検知ができる • [必須]予測時に省メモリであること – ユーザー毎にモデルが存在するため、メモリを大量に使う モデルは使えない(例: 近傍法) • [必須]多峰性への対応 – サーバー負荷は平日/週末、昼間/夜間で変化する 29
- 30. Mackerelで求められる要件(2) • [必須]定期的にモデルが更新されること – サービスの状態は変化する • [必須]細かくチューニングしなくてもある程度精度が出る – チューニング用のラベル付きデータが必ずしも手に入るわけで はない – ハイパーパラメータが多いモデルは採用しにくい • [できるとよい]変化検知 – 変化点が分かるとサーバースペックの見直しのきっかけができ るが、必須ではない • [できるとよい]どの変数が異常か説明可能 – どの変数が異常か分かると障害対応への初動も早くできるが、 グラフを見れば人間はある程度分かる 30
- 31. 即時性 計算時間 メモリ量 多峰性 チューニン グが容易 変化検知 説明性 ホテリングの T2法 ○ ○ ○ × ○ × × 混合ガウス 分布 ○ △ ○ ○ ○ × × 近傍法 △ △ × ○ △ ○ × 特異 スペクトル変換 × × △ × △ ○ × 疎構造学習 ○ × △ ○ △ ○ ○ 異常検知の手法とMackerelでの要件 31
- 32. 採用:混合ガウス分布による異常検知 • 約20次元のシステムメトリックに限定して学習及び予測 – 不必要な次元が多数存在すると、正確な異常検知が難しい – ユーザー毎に自動的に特徴量選択はまだまだ難しい 32 cpu memory 休日や夜間等比較的 負荷の低いケース 平日を中心とした比較的 負荷の高いケース 異常と判定されるケース1 異常と判定されるケース2
- 34. アジェンダ • サーバー監視の困り事 • 異常検知とは? • 異常検知の代表的なアルゴリズム • 異常検知システムを支えるアーキテクチャ 34
- 37. 高頻度かつ不定期な学習が必要 37 はてなブログ DB App Proxy はてな ブックマーク DB App Proxy 異常検知モデル1 異常検知モデル2 異常検知モデル3 異常検知モデル4 異常検知モデル5 異常検知モデル6 • スパム検知などの機械 学習ではモデルが1つ あればよい • 異常検知ではロール毎 にモデルが必要 – 同じ名前のロールでも サービスが異なれば傾 向が異なる • ジョブキューシステムを 自前で管理したくない
- 38. AWS Batchについて • フルマネージド型バッチ処理サービス(ジョブキュー) • 裏側にECSのクラスタが存在し、ジョブが投入されるとEC2イ ンスタンスを自動起動。ジョブが終了したらEC2インスタンス も終了 – 学習ジョブの流量は変動するため必要なインスタンス数も変動 38 RetryやTimeoutについても AWS Batchが面倒を見てくれる
- 39. Mackerelの時系列DBについて: 既存の時系列DBの問題点 • 以前はOSSの時系列DBであるGraphiteを使用 • 問題点: – コスト面。高性能なデバイスが必要 – データロスト耐性の低さ – 古いデータは丸められてしまい、生データが見れなく なる – 例: 1分粒度でデータが投稿されていても、10日前の データは5分粒度に丸められてしまう 39
- 40. 異常検知は生データが大事! • 荒い粒度のデータしか学習で使えない場合、生データの多峰 性を根本的に学習できない – 誤検知が発生しやすくなってしまう • アルゴリズムだけでなく生データを貯蓄する術も重要! 40 生データ(細かい粒度) 5分平均(荒い粒度) 生データから 学習した確率分布 荒い粒度で 学習した確率分布 時刻 CPU 使用率
- 41. 参考: Mackerelの時系列DBにおける 各種ストレージの使い分け 41 容量単価 スケーラビリティ レイテンシ 古いメトリック 新しいメトリック あまり参照されない 頻繁に参照される 保持コスト 読み書きコスト S3 DynamoDB Redis hCps://speakerdeck.com/itchyny/serverlessconf-tokyo-2017 より
- 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. まとめ • なぜ機械学習を用いた異常検知が必要か – 監視に未経験でもできる/詳しい人の手間を減らす • 代表的な異常検知のアルゴリズム – 様々なアルゴリズムがある中でサービス要求に合う混合 ガウス分布による異常検知を選択 • 異常検知システムを支えるアーキテクチャ – 誤検知を少なくするためには、荒い粒度ではなく生データ が重要。独自の時系列DBを構築 – AWS Batchで高頻度かつ不定期な学習ジョブに対応 43
- 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