あるSREチーム（SRE：Site Reliability Engineering、システムの信頼性を維持・向上させる専門チーム）は、ALB（Application Load Balancer）背後で稼働するWebアプリ

Question

あるSREチーム（SRE：Site Reliability Engineering、システムの信頼性を維持・向上させる専門チーム）は、ALB（Application Load Balancer）背後で稼働するWebアプリケーションの「5xxエラー率」（5xxレスポンス数÷総リクエスト数×100）が5%を超えた場合にアラームを発報する仕組みを構築したいと考えています。ALBはすでに `HTTPCode_Target_5XX_Count` と `RequestCount` の2つのメトリクスをCloudWatchに送信しています。最も運用負荷が低く、リアルタイム性の高い方法はどれですか？

Accepted Answer

正解: CloudWatch Metric Mathを使用して `HTTPCode_Target_5XX_Count / RequestCount * 100` という数式を定義し、その結果メトリクスに対してCloudWatchアラームを設定する。CloudWatch Metric Math（メトリクス数式）を使用すると、既存のCloudWatchメトリクスに対して四則演算や関数を適用した計算結果を新しいメトリクスとして扱い、そのメトリクスに直接CloudWatchアラームを設定できます。追加コード・Lambda・インフラ管理が一切不要で、コンソールまたはAPIから即座に構成可能なため、最も運用負荷が低くリアルタイム性も高い方法です。

選択肢B（Lambda + GetMetricData）Lambdaでカスタムメトリクスを送信する方法は機能しますが、Lambdaの管理・コスト・実行遅延が発生します。Metric Mathが利用できる場面では不必要な複雑さです。

選択肢CのCloudWatch Logs Insightsはアドホックなログクエリツールであり、リアルタイムのアラーム連携には適しません。Lambdaの追加管理も必要となります。

選択肢DのS3＋Athenaの構成は大規模バッチ分析や過去ログ調査向けであり、リアルタイムアラームには不向きで、遅延・運用コストともに大きくなります。

Answer

Lambda関数を1分ごとにスケジュール実行し、GetMetricData APIで両メトリクスを取得して割り算を行い、結果をPutMetricData APIでカスタムメトリクスとして送信してからアラームを設定する — Lambda + GetMetricDataでの実装は機能しますが、Lambdaの管理・コスト・実行遅延が発生し、Metric Mathが利用できる場面では不必要な複雑さです。

Answer

ALBのアクセスログをCloudWatch Logsに送信し、CloudWatch Logs InsightsでエラーレートのクエリをLambdaから定期実行してSNS通知する — CloudWatch Logs Insightsはアドホックなログクエリツールであり、リアルタイムアラーム連携に適さず、Lambda追加管理も必要になります。

Answer

ALBのアクセスログをS3バケットに出力し、Amazon AthenaでSQLクエリを定期実行してエラー率を計算し、結果をSNSで通知する — S3 + Athenaの構成は大規模バッチ分析向けで、リアルタイムアラームには不向き。遅延・運用コストともに大きくなります。

解説

解説