Elasticsearch Service で異常検出(Anomaly Detection)がサポートされました!!

2020.06.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

園部です。

Elasticsearch Service(以下 ES) で、プレビューとなっていた異常検出(Anomaly Detection)がサポートされました!

プレビュー時の情報を見ると、どういった仕組み(手法)であるかを窺い知ることができます。

ES も Anomaly Detection も絶賛学習中なので 「これはよい機会!」 と思い、各ドキュメント見ながら理解を深めながらやってみました!

結論としては最適な結果は得られませんでした。
機能の学習・手順の参考になればと思います。悔しい。。

ES リアルタイム異常検出とは?

まずは、今回のリリース情報から紐解いていきます。 さっそくわかったような...そうでないような...そんな気持ちになったので、キーワードとなりそうな部分を太字にしてみました。詳細を確認していきたいと思います!

この機能は、機械学習によりリアルタイムストリーミングデータの異常を検出し、変化する問題を特定して、即座の緩和を可能にします。 この新機能は、リアルタイムストリーミング向けの実証済みアルゴリズムであるランダムカットフォレスト (RCF、Random Cut Forests) に基づいて構築されています。また、ドメイン非依存型であるため、さまざまなログ分析アプリケーションに最適です。
(中略)
この新しい異常検出機能は、従来の検索機能の部分ではなく、ログ分析異常の原因となるデータやイベントに関するコンテキストを提供する、Kibana ユーザーインタフェイスを備えています。 そのため、機械学習に関する知識の有無にかかわらず、すべてのユーザーが簡単にこの機能を活用可能です。 異常検出は、外れ値の検出通知をトリガーするアラートと併用できます。

引用元: 上記リリースページ

リアルタイムストリーミングデータ, ログ分析アプリケーション

ストリーミングデータとは、絶え間なく継続的に作成されるデータです。 実際にどういったデータなのかを理解するには、下記の情報がとても参考になります。一部抜粋して記載します。

ストリーミングデータの例

輸送車両、産業機器、および農業機械のセンサーは、ストリーミングアプリケーションにデータを送信しています。アプリケーションは、パフォーマンスをモニタリングして事前に潜在的なエラーを検出し、交換部品を自動的に発注して機械のダウンタイムを防ぎます。

あるオンラインゲーム会社では、プレイヤーとゲームのインタラクションに関するストリーミングデータを収集して、それをゲームプラットフォームに供給しています。さらに、そのデータをリアルタイムで分析することで、プレイヤーを囲い込むためのインセンティブとダイナミックなエクスペリエンスを提供しています。

引用元: ストリーミングデータとは

今回の ES における異常検出は、従来からの Search 部分ではなく、近年多くのユースケースである収集されるデータ(ストリーミングデータ)に対して Application Monitoring, SIEM, Infrastructure Monitoring といった用途で分析を行うシーンに機械学習を適用することで、異常検出を行う機能です。

引用元: Amazon Elasticsearch Service

ランダムカットフォレスト (RCF、Random Cut Forests)

今回、機械学習で用いられるアルゴリズムは ランダムカットフォレスト(以下 RCF) となります。 この RCF については SageMaker ドキュメントでも紹介されています。

Amazon SageMaker ランダムカットフォレスト (RCF) は、データセット内の異常なデータポイントを検出する、教師なしのアルゴリズムです。
(中略)
各データポイントで、RCF は異常スコアを関連付けます。低スコア値であれば、データポイントは「通常」とみなされています。 高い値は、データ内に異常があることを示します。
引用元: ランダムカットフォレスト (RCF) アルゴリズム

ES 異常検出では異常スコアを anomaly grade として表記されています。 他にもいくつかの指標( confidence score )があります。詳細は Elasticserach のドキュメントに記載されています。

ランダムフォレストをはじめ、多くのアルゴリズムは一定の時間ベースでのバッチによるものでしたが RCF はデータが入力されるタイミングで更新を行いリアルタイムでストリーミングデータへの対応を可能としています。 RCF について詳細が確認したい方は、こちらの記事が良いかもしれません。(私には早かった...

Random Cut Forests

Kibana

今回のリアルタイム異常検出は Open Distro for Elasticsearch の機能として提供されています。AWS ドキュメントでも詳細は Open Distro for Elasticsearch - Anomaly Detection を確認することを案内されていますし AWS コンソール側での設定ではなく Kibana 上で設定することになります。

引用元: Anomaly Detection for Amazon Elasticsearch Service

外れ値の検出通知をトリガーするアラート

昨年リリースされているアラート機能を利用して、異常検出された際に通知を行うことも可能です。

利用に際して

  • Elasticsearch 7.4以降 が必須となります。
  • 追加料金なし
  • 東京リージョンも含む 22 のリージョンで利用可 ( 2020.06.04 時点)

やってみた

手元にちょうど良いストリーミングデータを生成するシステムがなく、、 今回は SIEM をイメージして CloudTrail データを CloudWatch Logs 経由で ES へエクスポートし、異常検出を設定していきたいと思います。CloudTrail Insights のようなものが出来れば最高なんですが...

事前準備

CloudTrail から CloudWatch Logs 経由で ES へエスクポートする部分については先人の知恵を拝借しながら準備します。

  • CloudTrail

  • CloudWatch

  • Elasticsearch Service

異常検出設定

データ(インデックス)の確認

Kibana へのアクセスは IP アドレスによる制限のみにして、アクセスします。

左フレーム >>> Discover を選択

Available fields で利用可能な field がデータタイプとともに表示されています。

AWS コンソールへのサインインに関する API コールを絞ってみます。 すると関連するイベントのみ表示されます。 普段は、スイッチロールでログインしているので、わざと直接コンソールへ誤ったユーザー情報でログインを試行しておきました。(Failure)

例えば ConsoleLogin = Failure が多いや signin イベント回数が多いなどの条件で、異常検出の設定を行ってみたいと思います。

Detector と Feature 作成

左フレームワーク >>> Open Distro for Elasticsearch Anomaly Detection Kibana plugin >>> Create detector を選択

名前は任意で入力します。

元データとなるソースは CloudTrail となるため cwl-* と入力します。 大量のデータから特定のものに絞り込む場合は Data filter でフィルタリングをかけます。

集計インターバルや遅延については今回はデフォルトとしますが、必要に応じて修正します。ドキュメントに詳細が記載されていますのでご参照ください。
Create を選択

続いて Feature を作成します。 Add feature を選択

名前は任意で入力します。

ここで、指標となる Field と集計方法を指定していくのですが... ちょっと想定外なことになりました。。 先ほど Kibana で確認したような field が存在せず データ型が number の Field のみとなっています。(ここは私の理解・設定が足らないのか、現在の仕様なのかが特定出来ませんでした...)

また 集計方法についてもドキュメントでは以下のように 5種類ですが4種類しか利用できないようです。(Custom expression で count を指定するとエラーに)

In this case, a feature is the field in your index that you to check for anomalies. A detector can discover anomalies across one or more features. You must choose an aggregation method for each feature: average(), count(), sum(), min(), or max(). The aggregation method determines what constitutes an anomaly.

引用: Open Distro for Elasticsearch - Anomaly Detection

IoT デバイスからのセンサーデータを JSON で受けて活用する場合や アプリケーションログデータ内のスコアなどであれば、ある程度既存の状態でも流用が可能かもしれませんが、やはり ES にデータをエクスポートする前に、データ定義やそこから何を検出するのかを予め設計・確認しておく重要さをあらためて実感しました、、猛省中

今回は、最後まで進むことを優先して、適当に選択を行い進めます。
Automatically start detector (Recommended) >>> Confirm を選択

初回検出が実行されます。データポイントと集計インターバルなどによりますが、ある程度時間がかかります。

結果

適切な feature を作成できない残念な結果となってしまいました。。

本来であれば、以下のような結果が表示されます。上段に直近のリアルタイムの結果が表示され、下段にて Anomaly grade や confidence score など異常の状況(異常度や結果の信頼)が表示されます。


引用: Open Distro for Elasticsearch - Anomaly Detection

Set up Alerts(上記サンプルでは既に設定しているので Edit と表示) からアラートの設定が可能です。

さいごに

最後の閉めが悪くなってしまいましたが、これも一つのやってみた結果(やってしまった)だと思って、よしとしたいなと... 綺麗な内容をご期待いただいて読んでくださった方には申し訳ないです(精進します)。

個人的にはリリース情報を見た時からは、ぐっと理解は進みましたが、使いこなせそうかと言われると疑問が残ります。。一回で理解できるほど浅い領域ではないと思うので、めげずにこれからも追って行きたいなと思います。

今月(2020/06/23)には AWS Black Belt Online Seminar で ES が登場するので、さっそく参加して理解を深めたいと思います!