Amazon CloudWatch Metrics Insights アラームによるアラームライフサイクルの最適化

動的に変化するリソース群全体を、簡単に監視しアラームを設定するのに苦労していませんか？利用料がかかっている不要な大量のアラームが存在し、把握できなくなっていませんか？増減するリソースに合わせて、自動的に調整されるアラームを簡単に作成する方法を探してますか？

このブログでは、使用されなくなった AWS リソースにアラームが発生するリスクや新しい AWS リソースが監視されないままになるリスクが軽減するために、Amazon CloudWatch を使用した推奨されるコスト効率の高い方法について説明します。

この方法により、古くなったり、廃止されたメトリクスやリソースに関するアラーム、有効性は低いが料金を支払わなければならないアラームが存在してしまうリスクが軽減され、さらに、CloudWatch ダッシュボードの視認性が悪くなるといったリスクが軽減されます。Metrics Insights クエリを使用して作成されたアラームは、そのシンプルさと単一の定義により、集計アラームに対する運用のオーバーヘッドやコストが低くなります。また、AWSリソースの出入りに応じて自動的に調整されるため、アラームが滞留するリスクが低減されます。

以前のブログでは、価値の低いアラームを特定して削除する方法に関する自動化ソリューションを紹介しました。このブログでは、動きの速い環境を一貫して監視し、異常が検出されたときに警告する動的アラームを設定する方法について説明します。

Amazon CloudWatch Metrics Insights アラームを使用すると、標準的な SQL クエリを使用して、動的に変化するリソース群全体のアラームを 1 つのアラーム設定で可能にします。CloudWatch Metrics Insights は、高速で柔軟な SQL ベースのクエリを提供します。CloudWatch アラームと Metrics Insights クエリを組み合わせることで、動きの速い環境を一貫して監視し、異常が検出されたときにアラートを出す動的アラームを設定できるようになります。

一般的なユースケース

ここでは、リソースの変化にすばやく対応するためにアラームが必要な場合と、アラームを手動で管理するのが困難な場合の 2 つの一般的なユースケースについて説明します。どちらのユースケースでも、Metrics Insights クエリでアラームすることがどのように役立つのかをご紹介します。

１つ目のユースケースでは、アカウント内の任意の Amazon DynamoDB テーブルへのリクエストが、そのテーブルにプロビジョニングされた読み込みキャパシティーユニットを超え、スロットリングイベントが発生したときにアラームがトリガーされます。2つ目のユースケースでは、アカウント内のいずれかの Amazon ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラームがトリガーされます。

ユースケース１. DynamoDB スロットリングの検出

アカウントのすべての DynamoDB テーブルの読み取りスロットルイベントを監視する一般的なユースケースを考えてみましょう。これは、DynamoDB がプロビジョニングした量よりも大量の読み取りリクエストを受け取った場合に発生します。これにより、アプリケーションが応答しなくなったり、新しいユーザーやトランザクションがブロックされたりする可能性があります。

この監視を実装する一般的な方法の1つは、Metric Math を使用して個々の「ReadThrottleEvents」メトリクスを集約し、その Metric Math の結果をアラームすることです。

この方法の注意点は、たとえば、新しい DynamoDB テーブルが追加された場合、Metric Math は自動的に更新されないため、新しい DynamoDB テーブルを見逃したり、新しく追加されたリソースのエラーを見逃したりするリスクがあることです。ここで、ユーザーは手動で Metric Math を更新し、新しい DynamoDB テーブルのメトリクススを追加する必要があります。同様に、DynamoDB テーブルが削除された場合は、Metric Math を手動で更新する必要があります。さらに、1 つの Metric Math で許可される量よりも多くのメトリクスを集約する必要がある場合は、Metric Math に基づくアラームを 1 つではなく 2 つ作成する必要があります。

Metrics Insights アラームでは、複数のリソースを監視するMetrics Insights クエリを使用してアラームを設定できます。新しいリソースが追加されたり、既存のリソースが削除されたりしても心配する必要はありません。上記の例では、新しい DynamoDB テーブルが追加されると、Metrics Insights アラームは、ユーザーが手動で操作することなく、変更に動的に適応することができます。

ユースケース２. ECS クラスターの 5XX エラーへの対応

アカウント内のいずれかの ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラートを受け取りたい、別のユースケースを考えてみましょう。

そのための一般的な方法では、まず ECS クラスターごとに報告された個々の「HttpCode_Target_5xx_Count」メトリクスを集計する Metric Math を作成し、この Metric Math の結果に対して、アラームを設定する必要があります。

この方法の注意点は、たとえば、新しい ECS クラスターが追加された場合、Metric Math が自動的に更新されないため、新しく追加されたリソースのエラーを見逃してしまう危険性があることです。ここで、ユーザーは手動で Metric Math を更新し、新しい ECS クラスターによって報告されたメトリクスを追加する必要があります。同様に、ECS クラスターが削除されると、Metric Math を手動で更新する必要があります。

Metrics Insights アラームでは、複数のリソースを監視する Metrics Insights クエリを使用してアラームを設定できます。新しいリソースが起動したり、既存のリソースが削除されたりしても心配する必要はありません。上記の例では、新しい ECS クラスターが追加されると、Metrics Insights アラームは変更に対して動的に適応するため、ユーザーによる手動操作は必要とせずに、アラームがしきい値を超えた場合にアラートを送信できます。

図 1. Metrics Insights – Query Builder

ソリューション概要

このソリューションでは、前述のユースケースに対応する Metrics Insights アラームが作成されます。Metrics Insights アラーム「DDBReadThrottleAlarm」を「ReadThrottleEvents」メトリクスを監視してアラームするようにプロビジョニングします。また、「ECSTarget5XXAlarm」を「HTTPCode_Target_5XX_Count」メトリクスを監視してアラームするようにプロビジョニングします。以下の AWS CloudFormation テンプレートの起動時にアラームが発生するにしきい値を設定できます。このソリューションでは、アラームが発生した場合に通知する SNS トピックも用意されており、起動プロセスの一部としてメールアドレスを設定できます。このソリューションは、お客様のユースケースに関連する他の AWS サービスやメトリクスにも拡張できます。

ソリューションのデプロイ

このソリューションと関連リソースは、AWS CloudFormation テンプレートとしてお客様の AWS アカウントにデプロイできます。

前提条件

このチュートリアルでは、次の前提条件を満たす必要があります。

AWS アカウントを保有していること。
Amazon DynamoDB テーブルと Amazon ECS クラスターが存在していること。

CloudFormation テンプレートは何をデプロイしますか？

CloudFormation テンプレートは、以下のリソースを AWS アカウントにデプロイします。

Amazon CloudWatch Metrics Insights アラーム
- DDBReadThrottleAlarm – 「ReadThrottleEvents 」メトリクスを監視し、アカウント内の任意の DynamoDB テーブルで読み取りスロットリングイベントが生成されたときにアラートを出します。
- ECSTarget5XXAlarm – HTTPCode_Target_5XX_Count メトリクスを監視し、アカウント内のいずれかの ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラートを出します。
- この CloudFormation テンプレートは、任意のメトリクスを使用するように変更できます。
Amazon SNS トピック
- AlarmNotificationTopic – アラームがトリガーされたときにメール通知を送信します。

CloudFormation テンプレートをデプロイする方法

yaml ファイルをダウンロードします。
AWS アカウントの CloudFormation コンソールに移動します。
「スタックの作成」を選択します。
「テンプレートの準備完了」を選択し、「テンプレートファイルのアップロード」を選択します。「ファイルの選択」で先ほどダウンロードした yaml ファイルを選択します。
「次へ」を選択します。
スタックに名前を付けます (最大長 30 文字)。
パラメータ「EmailToNotifyForAlarms」にはアラームを通知するメールアドレスを入力します。パラメータ「DDBReadThrottleThreshold」と「ECSTarget5XXThreshold」にはユースケースに基づいてそれぞれのアラームのしきい値を入力します。
「送信」を選択します。
スタックの作成が完了するまでお待ちください。

コスト

このソリューションの利用に関連するコストは、アカウントとリージョンの DynamoDB テーブルの数と ECS クラスターの数によって異なります。Metrics Insights のクエリアラームには、クエリによって分析されるメトリクススごとに料金が発生します。料金の詳細については、Amazon CloudWatch 料金表ページを参照してください。また、通知料金の詳細については、Amazon SNS の料金ページを参照してください。

クリーンアップ

CloudWatch Metrics Insights のアラームと関連リソースを保持する必要がなくなった場合は、AWS コンソールの CloudFormation に移動し、スタックを選択し (デプロイ時につけた名前)、「削除」を選択します。そのスタックによって作成されたリソースはすべて削除されます。

これらの CloudWatch Metrics Insights アラームを再び追加したい場合は、いつでも CloudFormation yaml からスタックを再作成できます。

結論

このソリューションを使用すると、1つのアラームで、一瞬のうちに発生するリソース増減に対するアラーム設定を動的に調整し、数千ものリソースを監視できる価値の高いアラームを作成できます。CloudWatch Metrics Insights アラームはシンプルかつ単一の定義であるため、お客様はアラームの運用メンテナンスを行って、古くなったり廃止されたメトリクススやアラームをクリーンアップする必要がなくなります。

著者について

翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文はこちらです。

Amazon Web Services ブログ