Amazon CloudWatch を使用して、自動アラーム付き Amazon Elasticsearch Service ドメインの運用効率を向上させる

顧客は、複数の Amazon Elasticsearch Service (Amazon ES) ドメインを適切に作成および実行して、製品、注文、サポートドキュメントに対するビジネスユーザーの検索ニーズ、および増加している同様のニーズのサポートで成功しています。このサービスは、組織全体で頻繁に使用されています。これにより、ピーク時に 100% の容量で動作するドメインがいくつか発生し、ストレージスペースが不足し始めたドメインもありました。このように使用量が増えたため、テクニカルチームはサービスレベル契約を守れなくなる危険性がありました。彼らは私に支援を求めました。

この記事では、自動アラームを設定して、ドメインに注意が必要なときに警告する方法を示します。

ソリューションの概要

Amazon ES は、Elasticsearch の使いやすい API とリアルタイムの解析機能、ならびに本稼働ワークロードに必要な可用性、スケーラビリティ、セキュリティを提供する完全マネージド型のサービスです。このサービスは、他の多くのコンポーネントや AWS のサービスとの統合機能を組み込んでおり、これを使用する顧客は未加工データから実用的な洞察を素早く安全に得られます。

こうした他の統合サービスの 1 つは Amazon CloudWatch です。CloudWatch は、AWS クラウドリソースと、AWS 上で実行されるアプリケーションのためのモニタリングサービスです。CloudWatch を使って、メトリクスの収集と追跡、ログファイルの収集とモニタリング、アラームの設定を行い、AWS のリソースにおける変更に自動的に対応することができます。

CloudWatch は、Amazon ES のメトリクスを収集します。これらのメトリクスを使用して、Amazon ES ドメインの状態を監視し、システムリソースの使用率が高いことを通知するアラームを設定することができます。詳細については、Amazon Elasticsearch Service Metrics and Dimensions を参照してください。

メトリクスは自動的に収集されますが、それぞれのドメインの適切なレベルでこれらのメトリクスにアラームを設定する方法が欠けています。この記事には、Amazon ES 環境の現在の状態を評価し、AWS の推奨事項とベストプラクティスに従ってアラームを設定するサンプル Python コードが含まれています。

サンプルソリューションには 2 つのコンポーネントがあります。

es-check-cwalarms.py: この Python スクリプトは、指定されたアカウントおよびリージョンのすべての Amazon ES ドメインに対して、設定されている CloudWatch アラームをチェックします。
es-create-cwalarms.py: この Python スクリプトは、指定された単一のドメインに対して一連の CloudWatch アラームを設定します。

サンプルコードは amazon-es-check-cw-alarms GitHub リポジトリにもあります。これらのスクリプトは、「拡張機能とアダプテーション」のセクションで説明しているように、簡単に拡張または結合できます。

現在の状態を評価する

最初のスクリプト es-check-cwalarms.py は、特定のリージョンのすべての Amazon ES ドメインの設定とアラーム設定の概要を示すために使用します。このスクリプトは以下のパラメータをとります:

python es-checkcwalarms.py -h
使用方法: es-checkcwalarms.py [-h] [-e ESPREFIX] [-n NOTIFY] [-f FREE][-p PROFILE] [-r REGION]
Amazon Elasticsearch Service ドメインの推奨される CloudWatch アラーム (オプションで、特定のプレフィックスで始まるアラーム) のセットをチェックします。
オプションの引数:
  -h, --help   		このヘルプメッセージを表示して終了する
  -e ESPREFIX, --esprefix ESPREFIX	このプレフィクスで始まる Amazon Elasticsearch Service ドメインのみをチェックする。
  -n NOTIFY, --notify NOTIFY    CloudWatch アラームアクションのリスト。例、['arn:aws:sns:xxxx']
  -f FREE, --free FREE  アラームを発する最小空き容量 (MB)
  -p PROFILE, --profile PROFILE     使用する IAM プロファイル名
  -r REGION, --region REGION       ドメインの AWS リージョン。デフォルト: us-east-1

このスクリプトは、まず、指定されたリージョンのすべてのドメイン (または、オプションで、指定された接頭辞で始まるサブセットに限定) を識別します。その後、それぞれに対して一連のチェックを実行します。

スクリプトは、コマンドラインから実行することもできますし、スケジュールされた Lambda 関数として設定することもできます。たとえば、ある顧客の場合、定期的にスクリプトを実行して、すべてのドメインに対してアラームが正しく設定されているかどうか確認することが適切であると考えられました。さらに、一般的な変更である大規模なワークロードに対応するためにクラスターのサイズが大きくなるなどの設定の変更でアラームが更新される可能性があるため、この方法では、ドメイン構成が変更されたときにアラームの自動識別が適切に設定されなくなりました。

以下に示す出力は、アカウントの 1 つのドメインに対する出力です。

Starting checks for Elasticsearch domain iotfleet , version is 53
Iotfleet Automated snapshot hour (UTC): 0
Iotfleet Instance configuration: 1 instances; type:m3.medium.elasticsearch
Iotfleet Instance storage definition is: 4 GB; free storage calced to: 819.2 MB
iotfleet Desired free storage set to (in MB): 819.2
iotfleet WARNING: Not using VPC Endpoint
iotfleet WARNING: Does not have Zone Awareness enabled
iotfleet WARNING: Instance count is ODD.Best practice is for an even number of data nodes and zone awareness.
iotfleet WARNING: Does not have Dedicated Masters.
iotfleet WARNING: Neither index nor search slow logs are enabled.
iotfleet WARNING: EBS not in use.Using instance storage only.
iotfleet Alarm ok; definition matches.Test-Elasticsearch-iotfleet-ClusterStatus.yellow-Alarm ClusterStatus.yellow
iotfleet Alarm ok; definition matches.Test-Elasticsearch-iotfleet-ClusterStatus.red-Alarm ClusterStatus.red
iotfleet Alarm ok; definition matches.Test-Elasticsearch-iotfleet-CPUUtilization-Alarm CPUUtilization
iotfleet Alarm ok; definition matches.Test-Elasticsearch-iotfleet-JVMMemoryPressure-Alarm JVMMemoryPressure
iotfleet WARNING: Missing alarm!! ('ClusterIndexWritesBlocked', 'Maximum', 60, 5, 'GreaterThanOrEqualToThreshold', 1.0)
iotfleet Alarm ok; definition matches.Test-Elasticsearch-iotfleet-AutomatedSnapshotFailure-Alarm AutomatedSnapshotFailure
iotfleet Alarm: Threshold does not match: Test-Elasticsearch-iotfleet-FreeStorageSpace-Alarm Should be:  819.2 ; is 3000.0

出力メッセージは、以下のカテゴリに分類されます。

システム概要、情報提供: インスタンスタイプと数、ストレージ、自動スナップショット時間などを含む Amazon ES のバージョンと構成。
空きストレージ: 合計ストレージの 20% という推奨に基づいて、適切な空きストレージの量を計算します。
警告: このドメインに対して、守られていないベストプラクティス。(詳細については、参照。)
アラーム: 推奨されているセットに対して、現在このドメインに設定されている CloudWatch アラームの評価。

このスクリプトには、これらのメトリクスと統計のベストプラクティスに基づいて推奨される CloudWatch アラームの配列が含まれています。この配列を使用すると、現在のドメインの統計情報と設定に基づいて、コード内でアラームパラメータ (空き領域など) を更新できます。

特定のドメインに対して、スクリプトは各アラームが設定されているかどうかをチェックします。アラームが設定されている場合、値が配列 esAlarms の値と一致するかどうかをチェックします。上記の出力では、次の 3 つの状況が報告されています。

Alarm ok; definition matches (定義は一致).ドメインのアラーム設定は、配列の設定と一致しています。
Alarm: Threshold does not match (しきい値が一致しない). アラームは存在しますが、アラームをトリガーするしきい値が一致しません。
WARNING: Missing alarm!! (アラームがない！！) 推奨されるアラームがありません。

全体として、上のリストは、このドメインがベストプラクティスに適合する構成ではなく、推奨されるすべてのアラームを備えていないことを示しています。

アラームの設定

現在の状態のドメインに重要なアラームが欠けていることが分かったので、この状況を修正することができます。

スクリプトを示すために、us-west-2 に「ver」という名前の新しいドメインを設定します。1 つのノードと、10 GB の EBS ディスクを指定します。また、us-west-2 に「sendnotification」という名前で、E メールを送信する SNS トピックも作成します。

2 番目のスクリプト es-create-cwalarms.py をコマンドラインから実行します。このスクリプトは、指定された Amazon ES ドメイン「ver」に対して、必要な CloudWatch アラームを作成 (または更新) します。

python es-create-cwalarms.py -r us-west-2 -e test -c ver -n "['arn:aws:sns:us-west-2:xxxxxxxxxx:sendnotification']"
EBS enabled: True type: gp2 size (GB): 10 No Iops 10240  total storage (MB)
Desired free storage set to (in MB): 2048.0
Creating  Test-Elasticsearch-ver-ClusterStatus.yellow-Alarm
Creating  Test-Elasticsearch-ver-ClusterStatus.red-Alarm
Creating  Test-Elasticsearch-ver-CPUUtilization-Alarm
Creating  Test-Elasticsearch-ver-JVMMemoryPressure-Alarm
Creating  Test-Elasticsearch-ver-FreeStorageSpace-Alarm
Creating  Test-Elasticsearch-ver-ClusterIndexWritesBlocked-Alarm
Creating  Test-Elasticsearch-ver-AutomatedSnapshotFailure-Alarm
Successfully finished creating alarms!

最初のスクリプトと同様に、このスクリプトには、これらのメトリクスと統計のベストプラクティスに基づいて推奨される CloudWatch アラームの配列が含まれています。このアプローチによって、ユースケースに基づいてアラームを追加または変更することができます (詳細は以下を参照)。

スクリプトを実行した後、CloudWatch コンソールの [Alarms] に移動します。ドメインに設定されている一連のアラームが表示されます。

「ver」ドメインにはノードが 1 つしかないため、クラスターのステータスは黄色であり、そのアラームは「ALARM」状態です。アラームが発生したという通知は既に送信されています。

アラームがトリガーされたときの対応

アラームを設定したら、トリガーされたアラームに応じて、それぞれのアラームに対して実行する適切なアクションを指定する必要があります。アイデア、ガイダンス、およびサポートドキュメントの追加情報については、Get Started with Amazon Elasticsearch Service: Set CloudWatch Alarms on Key Metrics を参照してください。一般的なエラーと取るべき回復処置については、Handling AWS Service Errors を参照してください。

ほとんどの場合、アラームは作業負荷の増加のためにトリガーされます。考えられる対処は、着信の負荷を減らすのではなく、増加した負荷を処理できるようにシステムを再構成することです。バックエンドストア (Elasticsearch を含むシステムのカテゴリ) を再設定することは、システムが静止しているか負荷が軽い場合に最も効果的です。ゾーン認識の設定やディスクタイプの変更などの再設定により、Amazon ES が「処理中」状態になり、クライアントアクセスが中断される可能性があります。

データノードの数を増やすなどの他の変更により、Elasticsearch がシャードの移動を開始し、この間にこれらのシャードの検索パフォーマンスに影響を与える可能性があります。こうした処置は、本稼働の状況では検討する必要があります。同様の理由から、ベストプラクティスに一致するようにすべてのドメインをリセットするスクリプトの実行も推奨いたしません。

考慮されたアプローチが必要な変更を行うことを許可するレベルでアラームを設定することにより、負荷の高いワークロード中に再構成が必要になることを避けます。たとえば、週のピークが増大していることを確認した場合は、週の静穏な期間中に再構成することができます。

Elasticsearch は休止することなく再構成できますが、使用パターンに基づいて自動的に拡大縮小することはベストプラクティスではありません。他の AWS のサービスとは異なり、アラームがトリガーされたときに自動的にシステムを再構成する CloudWatch アクションを設定することをお勧めします。

ディスクの空きスペースが低下したり、ゼロになったりしてドメインが書き込みを拒否するなど、計画された再構成のアプローチが機能しない場合もあります。ビジネスが着信書き込みを引き続き受け入れるドメインに依存していて、データを削除することが選択肢ではない場合、チームは直ちに再構成を選択することができます。

拡張機能とアダプテーション

独自の環境またはワークロードに合わせて、スクリプトにコード化されているベストプラクティスを変更したい場合があります。アラートが生成されるが通常無視されるという状況は、必ず避けてください。すべてのアラートは、レビューと 1 つ以上のアクションを、即時または計画された日にトリガーする必要があります。以下は、異なるドメインに対して異なるアラームを設定することが必要になる一般的な状況のリストです。

開発/テストと本稼働
開発環境の設定とテスト環境の設定では、異なる設定ルールやアラームのセットが必要になることがあります。たとえば、本稼働環境ではゾーン認識や専用マスターを必要とするが、開発環境では必要ではない場合があります。あるいは、開発ではアラームが設定されていない可能性もあります。潜在的なピーク負荷を反映するテスト環境では、アラームが適切にトリガーされていることをテストで確認します。
異なるドメインの異なるワークロードまたは SLA
あるドメインでは超高速検索のパフォーマンスが要求され、別のドメインでは検索応答が遅くなっても許容される大量の読み込み負荷が発生する場合があります。これら 2 つのワークロードの応答が遅いことへの対処は異なる可能性があるため、これら 2 つのドメインのしきい値は異なるレベルに設定する可能性があります。この場合、高速検索ドメインでは「最大 CPU 使用率」が 100% で 1 分間続いた場合のアラームを追加し、もう一方のドメインでは 5 分間の平均が 60% を超えた場合にのみアラームをトリガーします。また、利用可能なディスクがすぐに満杯になる危険がある場合、取り込み負荷が大きいために必要なスペースを増やす必要性を反映するために、しきい値が高い「空きスペース」ルールを追加することもできます。
「通常」アラームと「緊急」アラーム
たとえば、ディスクの空き容量が合計容量の 25% に低下した場合、古いインデックスをクリーンアップするか、このドメインの次の静かな時間に再構成するなど、できるだけ早く対処する必要があることを示すアラームがトリガーされます。ただし、空き容量がクリティカルレベル (20% の空き容量) を下回ると、Amazon ES がドメインを読み取り専用に設定しないようにするために、すぐに対策を講ずる必要があります。同様に、「ClusterIndexWritesBlocked」アラームがトリガーされた場合、ドメインはすでに書き込みの受け入れを停止しているため、即時の対処が必要です。この場合、計画された再構成のために現在のワークロードを確認するために 1 つのしきい値でアラームがトリガーされるが、即時の対処が必要であることを示す「DefCon 3」アラームが別のしきい値で発生する場合、「laddered」アラームを設定することができます。

ここで提供されるサンプルスクリプトは、実際の環境やニーズに適応するための出発点です。

このスクリプトを 1 回実行すると、現在の状態が希望の状態からどのくらい離れているかを特定し、最初のアラームセットを作成することができます。これらのスクリプトを定期的に再実行することで、時間の経過による環境の変化を把握し、環境や構成の変更に対してアラームを調整できます。ある顧客は夜間に実行するように設定し、好みの設定に合わせてアラームを自動的に作成して更新しています。

不要なアラームの削除

CloudWatch の各アラームの料金は、月額約 0.10 USD です。不要なアラームは、CloudWatch コンソールの [Alarms] で削除できます。上記の「ver」ドメインを設定している場合は、引き続き課金されることを避けるために必ず削除してください。

結論

Amazon ES ドメインに対して CloudWatch アラームを適切に設定すると、最適ではないパフォーマンスを回避し、緊急になる前にワークロードの増大や構成の問題に対応することができます。この記事は、そうするための出発点です。Elasticsearch ドメインのパフォーマンスを気にする必要がないことを知って安心できると、ビジネスのための創造的なソリューションを構築し、顧客の問題を解決することに集中できます。

ご活用ください！

その他の参考資料

この記事が参考になった場合は、「Analyzing Amazon Elasticsearch Service Slow Logs Using Amazon CloudWatch Logs Streaming and Kibana」および「Get Started with Amazon Elasticsearch Service: How Many Shards Do I Need?」もぜひご覧ください。

著者について

Veronika Megler 博士は、アマゾンウェブサービスのシニアコンサルタントです。彼女は、顧客の革新的なビッグデータ、AI、ML プロジェクトの実装を担当し、AWS を使用する際の TTV (期待された効果が出るまでの時間) の向上を支援しています。

Amazon Web Services ブログ