CloudWatch の 1 分メトリクスと 5 分メトリクスはなぜ存在するのか - 監視粒度とコストのトレードオフ
CloudWatch の基本モニタリング (5 分) と詳細モニタリング (1 分) が分かれている技術的・経済的理由、メトリクスの保持期間の段階的な集約、カスタムメトリクスの高解像度モードを解説します。
5 分間隔がデフォルトである理由
EC2 の基本モニタリングは 5 分間隔でメトリクスを収集します。なぜ 1 分ではなく 5 分なのでしょうか。理由は 2 つあります。第 1 に、データ量とストレージコストです。AWS は数百万台の EC2 インスタンスのメトリクスを収集しています。1 分間隔にすると 5 分間隔の 5 倍のデータポイントが生成され、ストレージコストと処理コストが 5 倍になります。基本モニタリングを無料で提供するには、5 分間隔が経済的に合理的なラインです。第 2 に、ほとんどのワークロードでは 5 分間隔で十分だからです。CPU 使用率やネットワークトラフィックのトレンドを把握するには、5 分間隔のデータで十分です。Auto Scaling のスケーリング判断も、5 分間隔のメトリクスで適切に動作します。ただし、スパイク的な負荷の検出や、レイテンシに敏感なワークロードの監視では、5 分間隔では粒度が粗すぎます。30 秒間の CPU スパイクは、5 分間の平均値に埋もれて検出できません。このようなケースでは、詳細モニタリング (1 分間隔) を有効にする必要があります。
メトリクスの保持期間と段階的な集約
CloudWatch のメトリクスデータは永久に保持されますが、解像度は時間の経過とともに段階的に低下します。1 秒間隔のデータポイントは 3 時間保持されます。1 分間隔のデータポイントは 15 日間保持されます。5 分間隔のデータポイントは 63 日間保持されます。1 時間間隔のデータポイントは 455 日 (約 15 ヶ月) 保持されます。この段階的な集約は、ストレージ効率と長期トレンド分析のバランスを取る設計です。直近 3 時間は秒単位の詳細なデータで障害調査ができ、過去 15 ヶ月は時間単位のデータでキャパシティプランニングができます。この集約ルールを知らないと、「昨日の 1 分間隔のデータが見えるのに、先月のデータは 5 分間隔でしか見えない」という現象に困惑します。長期間にわたって高解像度のデータを保持したい場合は、CloudWatch Metrics Streams で S3 にデータをエクスポートし、Athena で分析する方法があります。
カスタムメトリクスの高解像度モード
CloudWatch のカスタムメトリクスは、デフォルトで 1 分間隔ですが、高解像度モード (High-Resolution) を使用すると 1 秒間隔でデータポイントを送信できます。PutMetricData API の StorageResolution パラメータを 1 に設定するだけです。高解像度メトリクスは、リアルタイム性が求められるユースケースで威力を発揮します。たとえば、API のレスポンスタイムを 1 秒間隔で監視すれば、数秒間のレイテンシスパイクを即座に検出できます。1 分間隔では、60 秒間の平均値に平滑化されてスパイクが見えなくなります。ただし、高解像度メトリクスにはコストの考慮が必要です。カスタムメトリクスの料金は 1 メトリクスあたり月額 0.30 USD (最初の 10,000 メトリクスまで) で、解像度による料金差はありません。しかし、PutMetricData API の呼び出し回数が増えるため、API 料金 (1,000 リクエストあたり 0.01 USD) が増加します。1 秒間隔で 1 ヶ月間メトリクスを送信すると、約 260 万リクエスト (月額約 26 USD) になります。1 分間隔なら約 4.3 万リクエスト (月額約 0.43 USD) です。この 60 倍のコスト差を考慮し、高解像度が本当に必要なメトリクスだけに適用してください。
アラームの評価期間と M of N 設定
CloudWatch アラームは、メトリクスが閾値を超えた場合に通知を送信する機能ですが、評価ロジックには知っておくべき細かい仕様があります。アラームの評価期間 (Period) は、メトリクスのデータポイントを集約する時間幅です。評価期間を 5 分に設定すると、5 分間の平均値 (または最大値、最小値、合計値) が閾値と比較されます。「M of N」設定 (Datapoints to Alarm) は、直近 N 回の評価期間のうち M 回以上閾値を超えた場合にアラームを発火する設定です。たとえば「3 of 5」に設定すると、直近 5 回の評価期間のうち 3 回以上閾値を超えた場合にアラームが ALARM 状態になります。この設定により、一時的なスパイクによる誤報 (False Positive) を抑制できます。見落としがちなのは、メトリクスのデータポイントが欠落した場合の挙動です。EC2 インスタンスが停止すると CPU メトリクスが送信されなくなり、データポイントが欠落します。デフォルトでは、欠落したデータポイントは「missing」として扱われ、アラームの状態遷移に影響しません。TreatMissingData パラメータで、欠落を「breaching」(閾値超過) や「notBreaching」(閾値以内) として扱うよう変更できます。
CloudWatch の料金が予想外に高くなるパターン
CloudWatch の料金で最も見落とされがちなのは、GetMetricData API の呼び出し料金です。CloudWatch ダッシュボードを開くたびに、表示されているすべてのメトリクスに対して GetMetricData API が呼び出されます。10 個のウィジェットに各 5 メトリクスを表示するダッシュボードを、自動更新 (1 分間隔) で 8 時間表示し続けると、1 日あたり約 24,000 リクエストが発生します。GetMetricData の料金は 1,000 メトリクスリクエストあたり 0.01 USD なので、このダッシュボードだけで月額約 7 USD です。ダッシュボードが 10 個あれば月額 70 USD です。もう一つの高額パターンは、CloudWatch Logs のデータ取り込みです。Lambda 関数や ECS タスクのログが大量に出力されると、取り込み料金 (0.50 USD/GB) が急増します。DEBUG レベルのログを本番環境で有効にしたまま放置すると、月額数百ドルのログ料金が発生することがあります。対策として、ログレベルの適切な設定、ログの保持期間の短縮 (デフォルトは無期限)、CloudWatch Logs のサブスクリプションフィルターで必要なログだけを S3 にエクスポートする方法があります。監視設計とコスト最適化を体系的に学ぶには、専門書籍 (Amazon)が参考になります。