こんにちは。
id:skozawa です。秋が短くなって寂しいこの頃です。
こちらの記事は Gunosy Advent Calendar 2024 の 1 日目の記事です。昨年最後の記事は koid の生成系 AI を活用した開発者支援でした。今年もよろしくお願いいたします。
さて、本記事では CloudWatch Metric Streams を導入して CloudWatch のコストを削減した話をしたいと思います。
背景
Gunosy ではサーバー監視に主に Datadog を利用しています。 AWS のマネージドサービスのメトリクスの監視にも利用しており、Datadog の AWS Integration を利用しています。 Datadog の費用よりも CloudWatch メトリクス収集の費用が大きくかかっているプロダクトがあったため、CloudWatch メトリクス収集の費用を見直せないか検討することにしました。
2 種類のメトリクス収集方法
メトリクス収集には CloudWatch API を利用する方法と CloudWatch Metric Streams を利用する方法の 2 種類があります。 CloudWatch API (GetMetricData) は 1000 件のメトリクスごとに 0.01 ドルの費用が発生し、CloudWatch Metric Streams では 1,000 メトリクスごとに 0.003 ドルの費用が発生します。 これまでは CloudWatch API を利用していたため、CloudWatch Metric Streams を利用してコスト削減できないか検討します。
| 方法 | 収集間隔 | 費用 |
|---|---|---|
| CloudWatch API | 10 分毎 | $0.01/1000 メトリクス |
| CloudWatch Metrics Streams | 2〜3 分 | $0.003/1,000 メトリクス |
上記の費用だけをみると、CloudWatch Metric Streams を利用することでコスト削減になるように見えます。 しかし、Studyplus さんのブログに書いてあるように、実際には CloudWatch Metric Streams では送られるメトリクス量が増えるため、CloudWatch Metric Streams を使う方がコストが高くなってしまいます。
Datadog の役割を整理する
CloudWatch Metric Streams を単に導入するだけではコストが上がってしまうことがわかりました。 そこで、Datadog に期待する役割を整理し、Datadog には AWS マネージドサービスの主要メトリクスの監視と異常検知を任せることにしました（CloudWatch Alarm を使う選択もありますが、監視の役割を Datadog に集約させたい）。 こうすることで、CloudWatch Metric Streams で全てのメトリクスを収集する必要がなくなります。
コスト削減のために Datadog の役割を限定したものの、チームでは元々 AWS のコンソールからメトリクスを見る習慣があったので、この変更は問題なく受け入れられました。
CloudWatch Metric Streams の利用
CloudWatch Metric Streams を導入し、監視をしているメトリクスに制限します。 「選択されたメトリクス」と「選択した統計」で必要なメトリクスのみを送るように設定します。
メトリクスを制限することで全てのメトリクスを送るより、メトリクスの量が 1/10 程度になりました。
コスト効果
もともと利用していた CloudWatch API のコスト (APN1-CW:GMD-Metrics) が CloudWatch Metric Streams のコスト (APN1-CW:MetricStreamUsage) に切り替わり、メトリクスを制限することで、85%程度コストが下げることができました。 監視しているメトリクスは全て送られているため、期待する機能要件は維持しつつ、コストを大幅に下げることができました。
まとめ
CloudWatch メトリクスを Datadog で監視する場合にかかるコストを下げるために、CloudWatch Metric Streams の導入とメトリクスの制限を行い、コスト削減する方法を紹介しました。
明日の Gunosy Advent Calendar 2024 では、森田さんが難しい問題を分割して LLM で解くやり方についてお話します。お楽しみに！
