AWS オブザーバビリティの向上 – Amazon CloudWatch アラームの力を引き出そう

通常、組織はAWS サービスを活用してワークロードのオブザーバビリティと運用の優秀性を高めています。しかし、多くの場合、オブザーバビリティメトリクスが提供されたときのチームが取るべき対応は不明確であり、どのメトリクスに対処が必要で、どのメトリクスがノイズにすぎないかを理解することは難しい場合があります。たとえば、アラームがトリガーされるまで 10 分以上かかる場合、根本的な問題を軽減するためにチームが取れる対処が遅れてしまいます。この問題への理想的な解決策は、ネットワークの障害を防ぐために、オブザーバビリティメトリクスからアラームの起動までの時間を短縮することです。実装やアーキテクチャの制限により、メトリクスデータは常に CloudWatch に 2 分の遅れで取り込まれるため、アラームが起動しない可能性があります。

Amazon CloudWatch アラームを使用して AWS リソースを監視し、メトリクスが事前に定義されたしきい値を超えたときに自動的にアクションを実行していますか？メトリクスに対してアラームを設定したり、ログに対してアラームを設定したりし、アラームを組み合わせ、アラームがトリガーされたときに特定のアクションを実行していますか？メトリクス数式、Metrics Insights クエリ、または別のリソースのデータソースに基づいてアラームを作成する必要があるユースケースがある場合、このブログはアラームの作成、管理、大規模な利用におけるベストプラクティスを理解するのに役立ちます。

このブログでは、一般的なアラームの推奨使用例について説明し、データ欠損シナリオや、アラームが発報するまでの時間を短くするための構成など、具体的な使用例についても詳しく説明します。

このブログでは、以下の内容を取り上げます。

すべての Amazon CloudWatch アラームの設定に適用される一般的なアラームの推奨事項
既存のアラームの調整
データが欠落している場合の推奨アラーム設定
より早い警告のための推奨アラーム設定
Metric Insights アラームを使用した動的アラームの作成
価値の低いアラームのクリーンアップ

アラームの推奨事項

CloudWatch アラームを素早く設定し、モニタリングのベストプラクティスに従うには、CloudWatch コンソールの Alarm recommendations を使用します。CloudWatch は、他の AWS サービスによって公開されるメトリクスに対して設定することを推奨されるアラームの推奨事項を提供しています。これらの推奨事項は、モニタリングのベストプラクティスに従うためにアラームを設定する必要があるメトリクスを特定するのに役立ちます。推奨事項には、設定するアラームのしきい値も示されています。これらの推奨事項に従うことで、AWS インフラストラクチャの重要なモニタリングを見落とすことがなくなります。
CloudWatch コンソールのメトリクスのセクションで、推奨アラームのフィルタを選択できます。また、コンソールを使用して、推奨アラームの定義をインフラストラクチャとしてコード化したものをダウンロードし、このコードを使用して AWS CloudFormation、AWS CLI、または Terraform でアラームを作成することができます。図 1 は、CloudWatch メトリクスのコンソール画面で利用可能な推奨アラームのフィルタを示しています。

Figure 1: Alarm recommendations in CloudWatch Metrics console

図 1. CloudWatch Metrics コンソールのアラームに関する推奨事項

アラームの調整

アラームを作成するときは、期間、評価期間 (N)、アラームを発生させるデータポイント数 (M) の設定を指定して、CloudWatch がアラームの状態を変更するタイミングを評価できるようにします。M/N 設定の主な利点は、すべての ‘N’ データポイントではなく、’M’ データポイントでアラームの状態の変更を評価できることです。M/N 設定を使えば、状態の変更に考慮されるデータポイント数を決められます。ただし、アラームの状態を計算するには常に N 個のデータポイントが必要です。この期間内のデータポイント数が N 未満の場合、アラームは欠落データの扱いの設定に従って、不足分のデータポイントを補います。

図 2. CloudWatch アラームの評価

M/N 設定は、メトリクスが CloudWatch に遅延して受信された場合でも、アラームの誤った遷移を防ぎます。遅延したメトリクスは、メトリクスデータが正確に反映されない恐れがあります。この誤った遷移は、M/N 設定によって防ぐことができます。そのため、3/3 ではなく 2/3 のように M < N を設定することをお勧めします。ほとんどの場合、最新のデータポイントにはメトリクスの遅延の問題があります。そのため、M の設定を使用して、最新のデータポイントを除外できます。

例えば、次のような設定のアラームを考えてみましょう。

指標: MyMetric 
 Threshold: >50 
 Period: 60(sec)
統計値: SUM 
 Evaluation Period: 3 
 M / N: 2 / 3

この例では、アラームに戻される可能性のあるウィンドウは次のとおりです。

1) [12, 13, 40, 50, 60, 90, 10, 20] ==> 設定された数 (3) より多くのデータポイントがあっても、アラームは最新の N 個のデータポイントを使用して状態の判断を試みます。この場合、N は 3 です。アラームは最新の 3 つのデータポイント 90、10、20 を確認します。ここでは、アラームが実行されるには、2 つのデータポイントが閾値を超えている必要がありますが、1 つのデータポイントしか閾値を超えていません。

2) [12, 13, 40, 50, 60, 90, 100, 20] ==> 最新の 3 つのデータポイントのうち 2 つが閾値を超えているため、 ALARM 状態になります。

M 個を超えるデータポイントがブリーチ (breach) した場合、アラームは ALARM 状態に遷移します。

データが欠落している場合のアラームの設定

欠落データの扱いの設定は、サービスがダウンしてデータポイントを CloudWatch に公開できない場合の遅延時に、アラームが ALARM 状態に移行するまでの時間に大きな影響を与えます。各アラームについて、CloudWatch に欠落データ (TMD) ポイントを notBreaching、breaching、ignore、missing のいずれとして扱うかを指定できます。デフォルトの動作は missing です。欠落データ機能は、欠落データの動作が危険を示す場合は欠落データを breaching として扱うべきであるなど、さまざまなシナリオで役立ちます。欠落データを気にしない場合は、欠落データを notBreaching または ignore として設定することもできます。アラームの状態を判断するためには一定数のデータポイント(N 個)が必要ですが、実際にはデータポイントの個数が N に満たない x 個の場合、欠落データの扱い設定に従い、残りの N – x 個のデータポイントを仮想的に補完し、アラームの状態を判断します。

より早く警告するためのアラームの設定

より正確なアラームをより早期に検知したい場合、これが出来ない一般的な根本原因はデータ欠損です。つまり、メトリクスのデータポイントが常に遅れているため、または送信元のサービス/アプリ/リソースがダウンしているためにアラームで受信されない場合です。メトリクスデータが常に遅延して CloudWatch に取り込まれるため、アラームの遅延が発生する可能性があります。これにより、その期間の評価がすでに完了した後にメトリクスデータポイントがバックフィルされ、バックフィルされたデータポイントが閾値を超えていてもアラームが発生しません。

Metric Mathを使用すれば、アラーム自体で欠落データを処理できます。Metrics Math (FILL、repeat) を使えば、最後の値を繰り返すことができ、データが遅延する場合に便利です。Metrics Math (FILL、breaching value) を使えば、ダウンタイムの際にアラームをより早く反応させることができます。

これらに対処するための推奨構成を含むいくつかのユースケースを見てみましょう。

ユースケース１

EC2 インスタンスがダウンしているため、データポイントが一部欠損している場合。アラーム設定は以下のとおりです。

Metric: EC2/CPUUtilization 
 Threshold: >80 
 Period: 60(sec)
 Statistic: AVG 
 Evaluation Period: 3 
 M / N: 2 / 3 
 Treat Missing Data : Breaching

上記の設定の場合、TMD が「Breaching」に設定されていても、アラームが ALARM 状態に移行するまでに 7 分かかります。インシデントの早期検知と復旧は、ビジネスとエンドユーザー体験にとって重要なため、この遅延は重要なワークロードには適さない可能性があります。

ソリューション: データポイントが欠落している場合に ALARM 状態への移行を早めるために、Metrics Math (FILL、breaching value) を使用することをお勧めします。たとえば、Metrics Math の FILL(m1,90) は、CPUUtilization メトリクスの欠落値を 90 に埋める式です。上記の TMD オプションではアラームが ALARM 状態に移行するのに 7 分かかるのに対し、この設定では 2 分しかかかりません。

Metric: EC2/CPUUtilization ## FILL(m1,90)
 Threshold: >80 
 Period: 60(sec)
 Statistic: AVG 
 Evaluation Period: 3 
 M / N: 2 / 3 
 Treat Missing Data: Breaching

ユースケース 2:

EC2 インスタンスに閾値を超えるデータポイントがあるが、通知が遅れアラーム状態に移行するのに時間がかかりすぎる場合。

Metric: EC2/CPUUtilization ## FILL(m1, REPEAT)
Threshold: >80
Period: 60(sec)
Statistic: AVG
Evaluation Period: 3
M / N : 2 / 3
Treat Missing Data: Breaching

上記の設定では、TMD を「Breaching」に設定しても、アラームが ALARM 状態に遷移するまでに 7 分かかります。これは重要なワークロードには適さない可能性があります。

ソリューション: 違反データポイントがある場合に ALARM 状態への移行を速めるため、Metrics Math (FILL(m1, REPEAT)) を使用することをお勧めします。たとえば、Metrics Math FILL(m1, REPEAT) は、CPUUtilization メトリクスの違反値で埋めます。上記の TMD オプションではアラームが ALARM 状態に移行するのに 7 分かかりますが、この設定では 2 分しかかかりません。

ユースケース 3:

メトリクスデータが常に 2 分の遅延を伴って CloudWatch に取り込まれているため、アラームが発動することが無い場合。

ソリューション: このような状況では、M/N を高く設定すると役立ちます。たとえば、M/N を 3/5 ではなく 3/7 に設定すると、2 分後にバックフィルされる遅延データポイントを考慮しやすくなります。

上記のすべてのユースケースソリューションは、AWS CloudFormation または AWS Cloud Development Kit (CDK) / Terraform を使用して、Metrics Mathとアラーム作成が自動化されるので、大規模に実装できます。

Metric Insights アラームを使用した動的アラーム

SQL クエリを使って、アカウント間の動的なリソースフリート全体に対して Metrics Insights アラームを単一のアラームで設定できます。Amazon CloudWatch Metrics Insights アラームをアカウント間で CloudWatch アラームと Metrics Insights クエリを組み合わせることで、高速に変化する環境を一貫してモニタリングし、異常が検出されたときにアラートを発する動的なアラームを設定できるようになります。Metrics Insights アラームの一般的な使用例としては、アカウント内の Amazon DynamoDB テーブルへのリクエストがそのテーブルのプロビジョンド読み取りキャパシティユニットを超え、スロットリングが発生したときにアラームをトリガーしたり、アカウント内の Amazon ECS クラスターが HTTP 5XX レスポンスコードを生成したときにアラームをトリガーすることがあります。これらのユースケースは、アラームライフサイクルを最適化するために自動化できます。

価値の低いアラームのクリーンアップ

価値の低い、または構成ミスのある CloudWatch アラームを削除すると、CloudWatch アラームの費用を削減できます。AWS リージョン全体で数千の Amazon CloudWatch アラームがある場合でも、リージョン全体で価値の低いアラームや構成ミスのあるアラームを素早く特定できます。アラームの削除を自動化することで、価値の低いアラームや構成ミスのあるアラームを削除し、コストを削減できます。

まとめ

このブログでは、CloudWatch アラームを使用した信頼性の高いモニタリングのための重要なヒントと戦略について学びました。アラームの推奨事項の一般的なユースケースを説明し、欠落データのシナリオや警告を早期に発する設定など、具体的なユースケースについて詳しく説明しました。

詳細は、AWS Observability ベストプラクティス、AWS One Observability ワークショップ、AWS re:Invent Observability 動画を参照してください。

著者について

本記事は、Elevating Your AWS Observability: Unlocking the Power of Amazon CloudWatch Alarms を翻訳したものです。翻訳はテクニカルアカウントマネージャーの日平が担当しました。

Amazon Web Services ブログ