AmazonOpenSearchサービス （Amazon Elasticsearch Serviceの後継）は、ストリーミングデータの異常をリアルタイムで識別できる、高性能の統合された異常検出エンジンをサポートしています。 昨年、リリースしました 高カーディナリティ異常検出（HCAD） 個々のエンティティの異常を検出します。 1.1リリースでは、安定した予測可能なパフォーマンスでXNUMX万のエンティティを監視できるようになりました。 非HCADシングルストリームソリューションとは対照的に、HCADは最も簡単に説明できます。 シングルストリーム検出器では、集約エンティティの異常を検出します。 たとえば、シングルストリーム検出器を使用して、すべてのIPアドレスにわたる集約されたトラフィックをふるいにかけ、異常なスパイクが発生したときにユーザーに通知できるようにすることができます。 ただし、多くの場合、個々のホストやIPアドレスなどのエンティティの異常を特定する必要があります。 各エンティティは異なるベースラインで動作する可能性があります。つまり、時系列の分布（マグニチュード、トレンド、季節性などのパラメーターで測定）が異なります。 ベースラインが異なると、単一のモノリシックモデルを使用して異常を検出するのが不正確になります。 HCADは、異常検出モデルをエンティティに合わせてカスタマイズすることで、シングルストリーム検出器とは一線を画しています。

HCADのユースケースの例は次のとおりです。

• モノのインターネット –冷蔵庫の温度を継続的に追跡し、食品や医薬品の寿命が危険にさらされている温度をユーザーに警告します。これにより、ユーザーはそれらを回避するための対策を講じることができます。 各エンティティには、それを説明する特定のカテゴリフィールドがあり、カテゴリフィールドはそれらのエンティティの特性と考えることができます。 冷蔵庫のシリアル番号は、冷蔵庫を一意に識別するカテゴリフィールドです。 単一のモデルを使用すると、周囲温度が異なる可能性があるため、多くの誤警報が発生します。 米国シアトルの冬の間は5°Cの気温が普通ですが、冬の間の熱帯の場所でのそのような気温は異常である可能性があります。 また、ユーザーは冷蔵庫のドアを数回開けて、温度の急上昇を引き起こす可能性があります。 スパイクの期間と頻度は、ユーザーの行動によって異なります。 HCADは、気温データを地域とユーザーにグループ化して、さまざまな地域の気温とユーザーの行動を検出できます。
• セキュリティ –認証ログでの失敗したログイン試行の増加を識別する侵入検知システム。 ユーザー名とホストIPは、ホストからアクセスするユーザーを決定するために使用されるカテゴリフィールドです。 ハッカーはブルートフォースによってユーザーパスワードを推測する可能性があり、同じホストIP上のすべてのユーザーが標的にされるとは限りません。 失敗したログインカウントの数は、特定の時刻における特定のユーザーのホストによって異なります。 HCADは、各ホストのユーザーごとに代表的なベースラインを作成し、ベースラインの変更に適応します。
• IT運用 –アクセストラフィックの監視 破片 分散サービスで。 シャードIDはカテゴリフィールドであり、エンティティはシャードです。 最新の分散システムは通常、互いにリンクされたシャードで構成されています。 シャードで停止が発生すると、依存するシャードのトラフィックが大幅に増加します。 嵐を再試行する。 影響を受けるシャードの数は限られているため、増加を見つけるのは困難です。 たとえば、関連するシャードのトラフィックは通常のレベルの64倍にもなる可能性がありますが、すべてのシャードの平均トラフィックはわずかな一定の係数（2未満）で増加する可能性があります。

完全性とスケーラビリティを実現しながら、HCADをリアルタイムでパフォーマンスの高いものにすることは、手ごわい課題です。

• 完全 –すべてまたはできるだけ多くのエンティティをモデル化します。
• スケーラビリティ – 水平および垂直スケーリング モデルの忠実度を変更せずに。 つまり、マシンをスケールアップまたはスケールアウトするときに、異常検出器はモデルを単調に追加できます。 HCADは、シングルストリーム検出の場合と同じモデルを使用し、エンティティの時系列に対して同じ回答を提供します。
• 性能 –システムリソースの使用への影響が少なく、全体的なスループットが高い。

Amazon OpenSearch ServiceでのHCADの最初のリリースは、パフォーマンスと完全性およびスケーラビリティを交換しました。異常検出器は、エンティティの数を1,000に制限しました。 設定を変更できます plugins.anomaly_detection.max_entities_per_query 間隔ごとに監視対象エンティティの数を増やします。 ただし、このような変更には無視できないコストが発生し、クラスターの不安定性への扉が開かれます。 各エンティティは、メモリを使用してモデルをホストし、ディスクI / Oを使用してモデルのチェックポイントと異常結果を読み書きし、メタデータの保守とモデルのトレーニングと推論にCPUサイクルを使用し、削除されたモデルとメタデータにガベージコレクションを実行します。 エンティティが多いほど、リソースの使用量も多くなります。 さらに、HCADは、複数のカテゴリフィールド（Amazon OpenSearch Service 1.1でリリースされた機能）をサポートするときに、エンティティの組み合わせ爆発に見舞われる可能性があります。 カテゴリフィールドのジオロケーションが1,000つしかない検出器を想像してみてください。 ジオロケーションには1,000の可能な値があります。 1個の許可された値を持つ別のカテゴリフィールド積を追加すると、検出器にXNUMX万個のエンティティが与えられます。

HCADの次のバージョンでは、完全性とスケーラビリティの向上に多大な努力を払いました。 私たちのアプローチは、クラスターのサイズを正しくキャプチャし、メモリ内モデルのホスティングとディスク上のモデルの読み込みを組み合わせたものです。 パフォーマンスメトリクスは、HCADがかなりのコストでクラスターを飽和させず、他のタスクのための十分な余地を残していることを示しています。 その結果、HCADは10分でXNUMX万のエンティティを分析し、さまざまなパターンで異常にフラグを立てることができます。 この投稿では、HCADがXNUMX万のエンティティを分析する方法と、改善の背後にある技術的な実装について説明します。

ドメインのサイズを設定する方法

モデル管理はトレードオフです。すべての間隔でモデルをリロード、使用、停止、保存するディスクベースのソリューションは、メモリを節約しますが、オーバーヘッドが高く、拡張が困難です。 メモリベースのソリューションは、オーバーヘッドが低く、スループットが高くなりますが、通常、メモリ要件が増加します。 モデルを可能な限りメモリ内でホストする適応メカニズムを実装することで、トレードオフを活用します（クラスター設定で上限を設定） plugins.anomaly_detection.model_max_size_percent）、最高のパフォーマンスで必要とされる場合。 モデルがメモリに収まらない場合は、ディスクからモデルをロードして、追加のモデルリクエストを処理します。

可能な限りメモリを使用することで、HCADのスケーラビリティが向上します。 したがって、HCADに十分なメモリを提供するために、クラスタのサイズを正しく設定することが重要です。 クラスタのサイズを決定する際に考慮すべき主な要因は次のとおりです。

• すべての検出器の合計エンティティ数の合計 –検出器の合計エンティティ数は、カテゴリフィールドのカーディナリティです。 複数のカテゴリフィールドがある場合、その数は、データに存在するこれらのフィールドの値のすべての一意の組み合わせをカウントします。 カーディナリティは次の方法で決定できます カーディナリティ集約 AmazonOpenSearchサービスで。 検出器がシングルストリーム検出器の場合、カテゴリフィールドが定義されていないため、エンティティの数はXNUMXつです。
• ヒープサイズ – Amazon OpenSearch Serviceは、RAMの50％をヒープ用に確保します。 インスタンスタイプのヒープサイズを決定するには、以下を参照してください。 AmazonOpenSearchサービス
  価格設定。 たとえば、r5.2xlargeホストには64GBのRAMがあります。 したがって、ホストのヒープサイズは32GBです。
• 異常検出（AD）の最大メモリパーセンテージ – ADは、デフォルトでヒープの最大10％を使用できます。 クラスター設定を介してパーセンテージをカスタマイズできます plugins.anomaly_detection.model_max_size_percent。 次の更新により、ADは前述の設定を介してヒープの半分を使用できるようになります。

PUT /_cluster/settings
{ "persistent": { "plugins.anomaly_detection.model_max_size_percent": "0.5" }
}

• エンティティのメモリ内モデルサイズ –エンティティのメモリ内モデルのサイズは、 シングルサイズ、機能の数、およびAmazon OpenSearchServiceのバージョンは常に改善されています。 同じソフトウェアバージョンの同じ検出器構成のすべてのエンティティモデルは、同じサイズです。 サイズを取得する安全な方法は、本番クラスターを作成する前に、実験クラスターの同じ検出器構成でプロファイルAPIを実行することです。 次の場合、検出器fkzfBX0BHok1ZbMqLMduの各エンティティモデルのサイズは470,491バイトです。

次のプロファイルリクエストを入力します。

GET /_plugins/_anomaly_detection/detectors/fkzfBX0BHok1ZbMqLMdu/_profile/models

次の応答があります。

{ ...{ "model_id": "fkzfBX0BHok1ZbMqLMdu_entity_GOIubzeHCXV-k6y_AA4K3Q", "entity": [{ "name": "host", "value": "host141" }, { "name": "process", "value": "process54" } ], "model_size_in_bytes": 470491, "node_id": "OcxBDJKYRYKwCLDtWUKItQ" } ...
}

• 結果インデックスのストレージ要件 –リアルタイム検出器は、異常な結果と異常でない結果の両方を含め、インデックス圧力が高くない場合に可能な限り検出結果を保存します。 インデックス作成の圧力が高い場合、異常な結果と異常でない結果のランダムなサブセットを保存します。 OpenSearchダッシュボードは、異常な結果のコンテキストとして非異常な結果を採用し、時間の関数として結果をプロットします。 さらに、ADは、結果を生成してから構成可能な日数の間、生成されたすべての結果の履歴を保存します。 この結果の保持期間はデフォルトで30日であり、クラスター設定を介して調整可能です plugins.anomaly_detection.ad_result_history_retention_period。 1日あたりに生成されるデータの量に保持期間を掛けて、結果を保存するのに十分なディスク容量を確保する必要があります。 たとえば、間隔ごとに10万のエンティティを持つ1分間隔の検出器に対して1万の結果ドキュメントを生成する検出器について考えてみます。 144つのドキュメントのサイズは約4,320KBです。 これは30日あたり約10GBで、1日間の保存期間後は8,640GBになります。 合計ディスク要件には、シャードコピーの数も掛ける必要があります。 現在、ADは、ノードごとにXNUMXつのプライマリシャード（最大XNUMX）と、初めて呼び出されたときにXNUMXつのレプリカを選択します。 レプリカの数がXNUMXであるため、すべてのシャードにはXNUMXつのコピーがあり、この例では、XNUMX万のエンティティの合計ディスク要件はXNUMXGBに近くなります。
• 異常検出のオーバーヘッド – ADは、履歴分析と内部操作のためにメモリオーバーヘッドを発生させます。 モデルの実行を中断しないように、オーバーヘッド用に20％多くのメモリを予約することをお勧めします。

必要な数のデータノードを導出するため D、最初にエンティティモデルの数の式を導出する必要があります N ノードがメモリ内でホストできること。 定義する S_i 検出器のエンティティモデルサイズになります i。 ヒープサイズのインスタンスタイプを使用する場合 H ここで、最大ADメモリの割合は P, N ADメモリの許容量をすべての検出器の最大エンティティモデルサイズで割った値に等しくなります。

必要なデータノード数を考慮します D の関数として N。 で示しましょう C_i 検出器の合計エンティティ数 i。 与えられた n 検出器、それは次のようになります：

ADが追加の20％のメモリオーバーヘッドを必要とするという事実は、式に1.2を掛けることで表されます。 ceil関数は、引数以上の最小の整数を表します。

たとえば、r5.2xlarge アマゾン エラスティック コンピューティング クラウド （Amazon EC2）インスタンスには64 GBのRAMがあるため、ヒープサイズは32GBです。 許可されたヒープサイズの最大半分を使用するようにADを構成します。 471つのHCAD検出器があり、そのモデルサイズはそれぞれ403KBと500,000KBです。 各検出器に対して36エンティティをホストするには、次の計算に従ってXNUMXデータノードクラスターが必要です。

また、十分なディスク容量があることを確認する必要があります。 最終的に、39 TBの5.2ノードのr3xlargeクラスター（36つのプライマリノードと4のデータノード）を使用しました。 Amazon Elastic Blockストア （EBS）各ノードのストレージ。

検出器のエンティティ数が不明な場合はどうなりますか？

検出器のエンティティ数を知るのが難しい場合があります。 履歴データを確認し、カーディナリティを推定できます。 しかし、将来を正確に予測することは不可能です。 一般的なガイドラインは、計画中にバッファメモリを割り当てることです。 適切に使用されると、バッファメモリは小さな変更の余地を提供します。 変更が重要な場合、HCADは水平方向にスケールインおよびスケールアウトできるため、データノードの数を調整できます。

アクティブなエンティティの数が変化している場合はどうなりますか？

次のXNUMXつの図から明らかなように、作成されるエンティティの総数は、アクティブなエンティティの数よりも多くなる可能性があります。 のエンティティの総数 HTTPログデータセット 2か月以内に2万ですが、各エンティティは平均して2回しか表示されません。 タイムボックス化された間隔内のアクティブなエンティティの数は、XNUMX万よりはるかに少ないです。 次の図は、HTTPログデータセットからのIPアドレスのネットワークサイズの時系列の例を示しています。

　 KPIデータセット また、同様の動作を示します。エンティティは、エンティティアクティビティのバースト中に短時間で表示されることがよくあります。

ADは、データパターンの包括的な画像を作成するために大きなサンプルサイズを必要とするため、均一にサンプリングできる高密度の時系列に適しています。 ADは、先行するバースト動作がしばらく続き、少なくとも400ポイントを提供できる場合でも、モデルをトレーニングして予測を生成できます。 ただし、トレーニングはより困難になり、データがまばらになるにつれて予測精度は低くなります。

この場合、エンティティの総数に応じてメモリを事前に割り当てるのは無駄です。 エンティティの総数ではなく、間隔内の最大のアクティブなエンティティを考慮する必要があります。 を使用して概数を取得できます date_histogram カーディナリティ集約パイプライン、および代表的な期間中のソート。 host-cloudwatchのインデックスを作成していて、10日間で10分間隔内にアクティブなホストの最大数を確認したい場合は、次のクエリを実行できます。

GET /host-cloudwatch/_search?size=0
{ "query": { "range": { "@timestamp": { "gte": "2021-11-17T22:21:48", "lte": "2021-11-27T22:22:48" } } }, "aggs": { "by_10m": { "date_histogram": { "field": "@timestamp", "fixed_interval": "10m" }, "aggs": { "dimension": { "cardinality": { "field": "host" } }, "multi_buckets_sort": { "bucket_sort": { "sort": [{ "dimension": { "order": "desc" } }], "size": 1 } } } } }
}

クエリ結果は、1,000分間隔で最大約XNUMXのホストがアクティブであることを示しています。

{ ... "aggregations": { "by_10m": { "buckets": [{ "key_as_string": "2021-11-17T22:30:00.000Z", "key": 1637188200000, "doc_count": 1000000, "dimension": { "value": 1000 } }] } } ...
}

HCADには、モデルを保存し、各モデルの最終アクセスのタイムスタンプを維持するためのキャッシュがあります。 モデルごとに、1時間ごとのジョブが非アクティブの時間をチェックし、非アクティブの時間が1時間を超える場合はモデルを無効にします。 時間単位のチェックのタイミングとキャッシュ容量に応じて、モデルがキャッシュされる経過時間は異なります。 キャッシュ容量が期限切れでないすべてのモデルを保持するのに十分な大きさでない場合、モデルを削除するために最も使用頻度の低い（LFU）キャッシュポリシーを採用し（これについては後のセクションで詳しく説明します）、それらの無効化されたモデルのキャッシュ時間2時間未満です。 モデルの最終アクセス時刻が毎時チェックの直後にリセットされた場合、次の毎時チェックが発生しても、モデルは期限切れになりません。 次のXNUMX時間ごとのチェックが来ると、モデルの有効期限がさらにXNUMX時間かかる場合があります。 したがって、最大キャッシュ時間はXNUMX時間です。

検出器であるアクティブエンティティの上限 i 観察できるのは：

この方程式には次のパラメータがあります。

• A_i は、検出器iの間隔ごとのアクティブエンティティの最大数です。 前のクエリから番号を取得します。
• 120は2時間の分数です。 △T_i 検出器iの間隔を分単位で示します。 ceil関数は、引数以上の最小の整数を表します。 ceil（120÷ΔT_i) モデルがキャッシュされる間隔の最大数を指します。

したがって、私たちは説明する必要があります B_i サイジング式で：

サイジング計算フローチャート

データノードの数を計算する定義があれば、次のフローチャートを使用して、さまざまなシナリオで意思決定を行うことができます。

クラスターが縮小されている場合はどうなりますか？

クラスターの規模が小さい場合、ADはより頻繁で最近のエンティティを優先します。 ADは、メモリ内キャッシュでモデルをホストせずに、ディスクからオンデマンドでモデルをロードすることにより、追加のエンティティに対応するために最善を尽くします。 モデルをオンデマンドでロードするということは、オーバーヘッドが非常に高いすべての間隔でモデルをリロード-使用-停止-保存することを意味します。 オーバーヘッドは主に、モデル推論のコストではなく、ネットワークまたはディスクI / Oに関係しています。 したがって、私たちは着実に制御された方法でそれを行いました。 システムリソースの使用量が多くなく、十分な時間があれば、HCADは追加のエンティティの処理を終了する場合があります。 そうでなければ、HCADは必ずしも他の方法で見つけることができるすべての異常を見つけるとは限りません。

例：1万のエンティティの分析

次の例では、XNUMX万のエンティティを分析するための検出器を設定する方法を学習します。

データを取り込む

スケーラビリティと完全性の向上の評価では、10万のエンティティに対して1億のドキュメントを生成しました。 各エンティティには、ランダムに注入された異常を伴う正弦波時系列があります。 このヒントの助けを借りて 役職、インデックスhost-cloudwatchを作成し、ドキュメントをクラスターに取り込みました。 host-cloudwatchは、ホスト内のプロセスによるCPUおよびJVMガベージコレクション（GC）の経過時間を記録します。 インデックスマッピングは次のとおりです。

{ ... "mappings": { "properties": { "@timestamp": { "type": "date" }, "cpuTime": { "type": "double" }, "jvmGcTime": { "type": "double" }, "host": { "type": "keyword" }, "process": { "type": "keyword" } } } ...
}

検出器を作成する

検出器を作成する前に、次の要素を考慮してください。

• 監視するインデックス –インデックス名、エイリアス、またはパターンのグループを使用できます。 ここでは、最後のステップで作成したhost-cloudwatchインデックスを使用します。
• タイムスタンプフィールド –検出器は時系列データを監視します。 提供されたインデックスの各ドキュメントは、タイムスタンプに関連付けられている必要があります。 この例では、@ timetampフィールドを使用します。
• フィルタ –フィルターは、特定の条件に基づいて分析するデータを選択します。 フィルタの例の400つは、後でHTTPリクエストログからステータスコード4のリクエストを選択します。 HTTPステータスコードの5xxおよびXNUMXxxクラスは、要求がエラーで返されることを示します。 次に、エラー要求の数の異常検出器を作成できます。 実行中の例では、すべてのデータを分析するため、フィルターは使用されません。
• カテゴリフィールド –すべてのエンティティには、それを説明する特定の特性があります。 カテゴリフィールドは、これらの特性のカテゴリを提供します。 Amazon OpenSearch Service 1.1の時点で、エンティティは最大XNUMXつのカテゴリフィールドを持つことができます。 ここでは、プロセスとホストフィールドを指定することにより、特定のホストの特定のプロセスを監視します。
• 検出器間隔 –検出器の間隔は、通常、アプリケーションによって定義されます。 間隔内でデータを集約し、集約されたデータに対してモデルを実行します。 前述のように、ADは、均一にサンプリングできる高密度の時系列に適しています。 少なくとも、ほとんどの間隔にデータがあることを確認する必要があります。 また、検出器の間隔が異なると、遅延と精度の間で異なるトレードオフが必要になります。 間隔が長いと、長期および短期のワークロードの変動が滑らかになるため、ノイズが発生しにくくなり、検出の遅延が大きくなる可能性があります。 間隔が短いと検出が速くなりますが、異常ではなく予想されるワークロードの変動が見つかる場合があります。 さまざまな間隔で時系列をプロットし、ノイズを減らしながら関連する異常を維持する間隔を観察できます。 この例では、デフォルトの10分間隔を使用します。
• 特徴 –機能は、監視対象データから抽出された集計値です。 モデルに送られ、異常の程度を測定します。 フィーチャの形成は、監視するフィールドを選択するだけでなく、フィールドデータをメトリックとして要約する集計関数にすることもできます。 minやaverageなどの一連の関数を提供します。 スクリプトを介してランタイムフィールドを使用することもできます。 この例では、average関数を介して集約されたガベージコレクションの時間フィールドに関心があります。
• ウィンドウ遅延 –取り込みの遅延。 値が正しく構成されていない場合、検出器は、遅延データがクラスターに到着する前にデータを分析する可能性があります。 事前にすべてのデータを取り込んだため、この場合、ウィンドウ遅延は0です。

私たちの検出器の構成は、10分ごとに平均ガベージコレクション処理時間を集計し、さまざまなホスト上のプロセスの粒度で平均を分析します。 このような検出器を作成するためのAPIリクエストは次のとおりです。 合理化されたものを使用することもできます UI 検出器を作成して開始します。

POST _plugins/_anomaly_detection/detectors
{ "name": "detect_gc_time", "description": "detect gc processing time anomaly", "time_field": "@timestamp", "indices": [ "host-cloudwatch" ], "category_field": ["host", "process"], "feature_attributes": [{ "feature_name": "jvmGcTime average", "feature_enabled": true, "importance": 1, "aggregation_query": { "gc_time_average": { "avg": { "field": "jvmGcTime" } } } }], "detection_interval": { "period": { "interval": 10, "unit": "MINUTES" } }, "schema_version": 2
}

最初のトレーニングが完了すると、1万のエンティティのすべてのモデルがメモリに保存され、数時間後に検出器の間隔ごとに1万の結果が生成されます。 キャッシュ内のアクティブなモデルの数を確認するには、プロファイルAPIを実行します。

GET /_plugins/_anomaly_detection/detectors/fkzfBX0BHok1ZbMqLMdu/_profile/models

次の応答があります。

{ ... "model_count": 1000000
}

結果検索APIを呼び出すことにより、検出器間隔（この場合は10分）ごとに生成される結果の数を確認できます。

GET /_plugins/_anomaly_detection/detectors/results/_search
{ "query": { "range": { "execution_start_time": { "gte": 1636501467000, "lte": 1636502067000 } } }, "track_total_hits": true
}

次の応答があります。

{ ... "hits": { "total": { "value": 1000000, "relation": "eq" }, ... } ...
}

OpenSearchダッシュボードは、最も深刻な、または最も多くの異常を生成している上位のエンティティの説明を提供します。

色付きのセルを選択して、その特定の期間内に発生した異常の詳細を確認できます。

影付きの領域で、異常グレード、信頼度、および対応する機能を表示できます。

モニターを作成する

作成できます 警告モニター 次のスクリーンショットに示すように、定義された異常検出器に基づいて異常を通知します。

異常グレードと信頼度を使用してトリガーを定義します。 異常グレードと信頼度はどちらも0から1の間の値です。

異常グレードは、異常の重大度を表します。 グレードが1に近いほど、重大度は高くなります。 0グレードは、対応する予測が異常ではないことを意味します。

信頼度は、モデルに十分な一意の実世界のデータポイントが含まれるように、エンティティのモデルが十分なデータを観察したかどうかを測定します。 あるモデルの信頼値が別のモデルの信頼値よりも大きい場合、最初のモデルの異常により多くのデータが観測されています。

忠実度の高いアラートを受信するため、成績のしきい値を0に、信頼度のしきい値を0.99に設定しました。

モニターを作成する最後のステップは、通知に何を含めるかについてのアクションを追加することです。 検出器の例では、ホスト内の特定のプロセスで異常を検出します。 通知メッセージには、エンティティIDが含まれている必要があります。 この例では、ctx.results.0.hits.hits.0._source.entityを使用してエンティティIDを取得します。

検出器に基づくモニターは、最大勾配異常を抽出し、構成された勾配と信頼度のしきい値に基づいてアラートをトリガーします。 次に、アラートメッセージの例を示します。

Attention Monitor detect_cpu_gc_time2-Monitor just entered alert status. Please investigate the issue.
- Trigger: detect_cpu_gc_time2-trigger
- Severity: 1
- Period start: 2021-12-08T01:01:15.919Z
- Period end: 2021-12-08T01:21:15.919Z
- Entity: {0={name=host, value=host107}, 1={name=process, value=process622}}

モニター定義メソッドを次のように変更することにより、抽出クエリとトリガー条件をカスタマイズできます。 抽出クエリモニター 対応するクエリと条件を変更します。 ここに クエリできるすべての異常結果インデックスフィールドの説明です。

評価

このセクションでは、HCADの適合率、再現率、および全体的なパフォーマンスを評価します。

適合率と再現率

評価しました 適合率と再現率 前述のように、正弦波データに対して。 このような評価は、リアルタイム処理のコンテキストでは簡単ではありません。これは、各検出器間隔（例では10分）中にエンティティごとに100つのポイントしか使用できないためです。 すべてのポイントの処理には時間がかかります。 代わりに、スクリプトで処理を早送りすることにより、リアルタイム処理をシミュレートしました。 結果は平均0.12回の実行です。 標準偏差は約XNUMXです。

線形補間を使用したコールドスタートの効果を含む、合成データの全体的な平均精度は0.57です。 リコールは0.61です。 変換が適用されていないことに注意してください。 変換によってこれらの数値が改善される可能性があります。 トレーニング用の補間されたコールドスタートデータにより、精度は0.09で、最初の0.34ポイントのリコールは300です。 モデルがより多くの実際のデータを観察するにつれて、数値は増加します。 さらに5,000の実際のデータポイントの後、適合率と再現率はそれぞれ0.57と0.63に向上します。 正確な数値はデータの特性によって異なることを繰り返します。異なるベンチマークまたは検出構成では、他の数値が使用されます。 さらに、欠測データがない場合、HCADモデルの忠実度はシングルストリーム検出器の忠実度と同じになります。

性能

取り込みや検索トラフィックなしで、アイドル状態のクラスターでHCADを実行しました。 などの指標 JVMメモリの負荷 次のスクリーンショットに示すように、各ノードのCPUはセーフゾーン内に十分に収まっています。 JVMメモリの負荷は23〜39％の間で変化します。 CPUはほとんどが約1％で、65時間ごとに最大XNUMX％のスパイクがあります。 内部のXNUMX時間ごとのメンテナンスジョブは、数十万のモデルチェックポイントの節約、未使用のモデルのクリア、および内部状態の簿記の実行による急増を説明できます。 ただし、これは将来の改善になる可能性があります。

製品の導入

次に、HCADの完全性とスケーラビリティに密接に関係する技術的作業の詳細について説明します。

RCF2.0

Amazon OpenSearch Service 1.1では、 ランダムカットフォレストライブラリ（RCF）2.0。 RCFは、データをさまざまなバウンディングボックスに分割することに基づいています。 以前のRCFバージョンでは、バウンディングボックスがメモリに保持されていました。 ただし、リアルタイム検出器は、新しいデータポイントを処理するときにバウンディングボックスのみを使用し、ほとんどの場合、バウンディングボックスを休止状態にします。 RCF 2.0では、必要に応じてこれらのバウンディングボックスを再作成できるため、対応する入力を処理するときにバウンディングボックスがメモリに存在します。 オンデマンドレクリエーションにより、メモリオーバーヘッドが2.0倍削減されたため、ノード内で26倍の数のモデルのホスティングをサポートできます。 さらに、RCF20はシリアル化モジュールを刷新します。 新しいモジュールは、XNUMX分のXNUMXのディスク容量を使用して、モデルをXNUMX倍高速にシリアル化および逆シリアル化します。

ページネーション

機能の集約に関しては、用語集約を使用したトップヒットの取得から、複合集約を介したページ付けに切り替えました。 1万のエンティティで生成されたデータセットを使用して、複数のページ付けの実装を評価しました。 各エンティティには40つのドキュメントがあります。 実験の構成は、データノード、プライマリシャード、およびカテゴリフィールドの数によって異なります。 複合クエリは、すべての場合に最速ではない場合でも、平均して最も安定している（XNUMX秒）ため、正しい選択であると考えています。

高価な操作を償却する

HCADは、多くのエンティティがディスクからのチェックポイントの読み取りなどの要求をほぼ同時に行う、雷鳴の群れのトラフィックに直面する可能性があります。 そのため、ペントアップリクエストをバッファリングするためにさまざまなキューを作成します。 これらのキューは、少量の制限された量の作業を着実に実行することにより、高価なコストを償却します。 したがって、HCADは予測可能なパフォーマンスと可用性を大規模に提供できます。

インメモリキャッシュ

HCADは、メモリ要件が構成されたメモリサイズよりも大きいエンティティを処理するためのキャッシュにアピールします。 最初は、使用頻度の低いキャッシュを試しましたが、実行時にスラッシングが発生しました HTTPログのワークロード：100分間隔の検出器が1個あり、検出器ごとに数百万のエンティティがあるため、7時間以内にキャッシュヒットがほとんど発生しませんでした（数百）。 モデルをメモリに出し入れするCPUサイクルを常に浪費していました。 原則として、ヒットとミスの比率が3：1よりも悪い場合は、モデルにすばやくアクセスするためのキャッシュを検討する価値はありません。

代わりに、ヘビーヒッターの近似を含めるように拡張された、修正されたLFUキャッシングに目を向けました。 A 減衰カウント キャッシュ内のモデルごとに維持されます。 キャッシュ内のモデルの減衰カウントは、モデルにアクセスすると増分されます。 減衰カウントが最小のモデルは、使用頻度が最も低いモデルです。 キャッシュが容量に達すると、新しいエンティティの頻度が最も使用頻度の低いエンティティよりも小さくない場合、キャッシュは最も使用頻度の低いモデルを無効にして削除します。 ヘビーヒッター近似と従来のLFUの間のこの接続により、より頻繁で最近のモデルをメモリ内でスティッキーにし、キャッシュヒットの確率が低いモデルを段階的に廃止することができます。

フォールトトレランス

回復不能なメモリ状態は制限されており、モデルの十分な情報がクラッシュの回復力のためにディスクに保存されます。 クラッシュが検出された後、モデルは別のホストで回復されます。

高性能

HCADは非同期I / Oに基づいて構築されています。ネットワーク呼び出しやディスクアクセスなどのすべてのI / O要求は非ブロッキングです。 さらに、モデルの分散は、コンシステントハッシュリングを使用してクラスター全体でバランスが取られます。

まとめ

HCADを拡張して、計算の忠実度を変更することなく、スケーラビリティと完全性を向上させました。 これらの改善の結果として、OpenSearchドメインのサイズを決定し、HCADを使用して1分間で10万のエンティティを監視する方法を紹介しました。 HCADの詳細については、を参照してください。 異常検出ドキュメント.

この投稿についてフィードバックがある場合は、 以下のコメントセクション。 この投稿について質問がある場合は、新しいスレッドを開始してください。 機械学習フォーラム.