以前の記事の通り、Datadogを使っていてAWSメトリクスを取得するには方法は2つあります。今回はしばらくAWS CloudWatch Metric Stream方式を運用した結果、それぞれの方法を改めて評価し直しました。合わせて公式ドキュメントにないコスト的な課題についてもメモです。

AWSメトリクスを取得する2つの方法

DatadogはAWSメトリクスを取得するために2つの方法を提供しています。

1つはDatadogのAWSアカウントとインテグレーションして、AWS CloudWatchのメトリクスをGetMetricDataAPIを使って取得する方法です。AWSとDatadogを連携すると自動的に実行されるので、意識していないとこの方法です。この方式を便宜上PULL方式と呼びます。

もう1つはAWS CloudWAtch EventStreamからFirehoseへ送り、FirehoseからDatadogにAPI送信する方法です。ユーザーが能動的にAWSアカウントにEventStreamとFirehoseを設定する必要があります。この方式を便宜上PUSH方式と呼びます。

取得方法の違いはDatadogの示している図が分かりやすいでしょう。AWS INTEGRATION CRAWLERSはPULL方式、KINESIS METRICS INTAKE APIがPUSH方式です。

Amazon Data Firehoseを使用したAWS CloudWatchメトリクスストリーム

PUSH方式にする動機

PULL方式をPUSH方式に切り替える動機は、おそらく反映されるまでの時間でしょう¹。PULL方式では基本5分インターバルですが、多くの場合10分前後まで遅延が広がる傾向にあります。これに対してPUSH方式は、Firehoseのバッチ粒度次第ですがおおむね3-5分程度で反映されます。より高速にメトリクスを反映させたい人向けにDatadogが提供しているのがPUSH方式です。

PULL方式とPUSH方式の切り替え

PULL方式からPUSH方式への切り替えは、KINESIS METRICS INTAKE APIが叩かれたかでDatadogが自動的に切り替わります。PUSH方式からPULL方式に戻すときは、CloudWatch Metric StreamとKinesis Firhoseを停止するだけでOKです。

PUSH方式にできているかは、DatadogがPUSH方式を検知するとAWS Integration画面で表示されるのでここを確認するといいでしょう。

なお、切り替えタイミングでDatadogのAWSメトリクスは欠落や重複が生じます。地味に困る。

PULL方式とPUSH方式の違い

コストの違い

PUSH方式ではCloudWatchのGetMetricDataAPIを使用します。Cost ExplorerではGMD-Metricsという名前で記録されます。リージョン別にコストがかかるものの、結局のところ料金はGMD-Metricsが支配的であるはずです。

PULL方式ではCloudWatch EventStreamを使用します。Cost ExplorerではMetricStreamUsageという名前で記録されます。Firehoseも使っていますが、ほとんどのケースで誤差レベルのコストしかかからないはずので無視してもいいでしょう。料金はMetricStreamUsageが支配的であるはずです。

コストがどうなるか予想するため料金単価を見てみましょう。一見するとメトリクスストリームは1/3程度と安いように見えますが、実際はそうでもありません。コストページに書かれている通り、1つのメトリクスでも4つ統計がくわえられ5つのメトリクス更新としてカウントされます。このため、何も考えずMetricStreamを使うと、PULL方式の1.5倍程度のコストがかかることになります。実際、PUSH方式でDatadogに送るとPULL方式よりとれるメトリクスが増えています。

CloudWatch Metric Streams の料金は、更新されたメトリクスの件数に基づきます。メトリクスの更新には、4 つのデフォルト統計 (最小、最大、サンプル数、合計) が含まれます。特定のメトリクスに対して要求された 5 つの統計を追加するごとに、追加のメトリクス更新として料金が発生します。

方式	API名	費用
PULL方式	GetMetricData	USD 0.01/リクエストされた 1,000 個のメトリクス
PUSH方式	メトリクストリーム	USD 0.003/1,000 メトリクス更新

料金表に出ない違いとして、AWS利用状況次第ですが、PULL方式は月のN日カスタムメトリクス無料枠が適用される可能性もあります。適用されるとPUSH方式はPULL方式の1.5倍以上のコストがかかることになります。特にCloudWatch利用が少ないアカウント程、PULL方式の方が安くなるでしょう。

メトリクス絞り込み方法の違い

PULL/PUSH方式どちらもメトリクスのボリュームでコストが変わるであろうことは簡単にイメージできます。送信するリージョンとメトリクスは必要なものだけに絞り込むことが重要です。

PULL方式はDatadogのAWSインテグレーションの設定でメトリクスやリージョンを絞り込むことができます。Web UIで設定できるので、試行錯誤が簡単なので魅力です。

PUSH方式はCloudWatch EventStreamの設定でメトリクスを絞り込むことができます。IaCで展開していたとしても割とめんどくさいのは難点です。CloudWatch EventStreamの設定は、メトリクスを絞り込むためにFilterPatternを設定する必要があります。これがなかなか難しいです。メトリクス名によるフィルタリングサポートはありますが、AWSコンソールとにらめっこしつつ設定することになるでしょう。

方式	設定方法	難易度
PULL方式	Datadog Web UI設定	簡単
PUSH方式	CloudWatch EventStreamの設定	難しい

構築方法の違い

どちらもDatadogがCloudFormationテンプレートを提供しています。ただ、TerraformやPulumiで構築するならCloudFormationを呼び出すか、スクラッチで書きましょう。

個人的に試した感じだと、CloudFormationテンプレートを使った構築は簡単です。ただ、TerraformやPulumiからCloudFormationStackを呼び出す構成だと、構築後に妙な差分やエラーが出てしんどい思いをしました。このため、私はスクラッチで両方書き起こしています。

現在の評価

しばらく運用した結論は、PULL方式で十分な場合はPULL方式を使うのがいいでしょう。特にCloudWatchのメトリクスが少ないアカウントでPUSH方式に切り替えると思いがけないコストがかかります²。どうしても高速に取得する必要がある場合はPUSH方式を使うのがいいでしょうが、その場合でもメトリクスはちゃんと絞り込みましょう。

個人的にはPULL方式でいいならそのままで良いかな。

まとめ

運用してみないと分かりにくいコストや切り替え時の課題がありました。今も運用していますが、PUSH方式は満足するほど良いかというとPULL方式で十分効果があるので悩ましいものを感じます。どこまで即時性がほしいか次第ですが、AWS自体のトラブルよりアプリケーションのトラブルを先に検知するほうが重要なんじゃないかなぁと感じます。

AWSの障害や状況は、アプリケーションの体験悪化を裏付ける指標に過ぎないので。