MackerelのAWSインテグレーション利用時にどのぐらいCloudWatchリクエストが発生するのか確認してみた
はじめに
清水です。監視サービスMackerelではCloudWatch APIを使って収集したメトリックスを監視するAWSインテグレーションという機能があります。このAWSインテグレーション利用時にどのぐらいのCloudWatchリクエストが発生しているのかを確認してみました。
ことの発端はMackerelのAWSインテグレーションを導入したとある環境のAWS利用費のなかで、CloudWatchの料金が目についたことです。飛び抜けて高いわけではないのですが月間で$10を超えている状況、気になって詳細を確認してみるとCloudWatchのRequestsでの料金であることがわかります。「$0.01 per 1,000 requests」と記載がある項目で、一月に1,000,000リクエスト以上発生していました。さらに詳しく確認してみると毎日一定数のリクエストがあり、一定の利用費が発生している状況です。
この毎日一定のCloudWatchリクエスト・利用費が発生しているという点から、監視サービスとして利用しているMackerelからのリクエストが気になりました。AWSインテグレーションを利用しており、各サービスのメトリックはMackerel側にも連携されている状況です。このリクエストはどのぐらいの量になるのか、調べてみると「5分ごと、取得対象となるメトリックの数だけAWSのAPIをコールしている」ことがわかりました。実際に取得対象となるメトリック数を元に計算してみると、MackerelからのCloudWatchリクエストが発生していたCloudWatchの利用料金のほとんどを占めていたことが確認できました。本エントリではこのMackerelからのCloudWatchリクエスト数の確認方法についてまとめています。なお使用している監視サービスからMackerelを題材としていますが、同様の外部監視サービスでも同じようにCloudWatchリクエストが発生する点に注意しましょう。
MackerelのAWSインテグレーション利用時のメトリックごとのCloudWatchリクエスト数
MackerelのAWSインテグレーション利用時にどのぐらいのCloudWatchリクエストを行っているのか確認していきます。まずMackerelのドキュメントには、AWSインテグレーション利用時に「5分ごとに取得対象となるメトリックの数だけAWSのAPIをコール」することが記載されています。
5分ごとに取得対象となるメトリックの数だけAWSのAPIをコールして値を取得します。
取得対象となるメトリックの数については監視対象となるリソースやAWSインテグレーション設定により異なります。こちらの詳細に付いては後述するとして、まずはこの「AWSのAPIをコール」する部分を確認しておきましょう。具体的にどのAPIをコールしているかの記載は確認できませんでしたが、CloudWatchのメトリックからデータを取得している、という点からGetMetricStatisticsやGetMetricDataなどの呼び出しであることが推測できます。
こちらはMackerelのAWSインテグレーションの際に設定するIAMロールの権限からも推測ができます。例えば監視対象にEC2が含まれている場合はAWSマネージドポリシーの「AmazonEC2ReadOnlyAccess」をアタッチします。このポリシーにはCloudWatchまわりの権限として、ListMetrics、GetMetricStatistics、Describe*の3種が付与されています。この中で実際にメトリックのデータを取得するのAPIとしてはGetMetricStatisticsとなるかと思います。RDSの場合も同様で、アタッチする「AmazonRDSReadOnlyAccess」マネージドポリシーにCloudWatchのGetMetricStatistics権限が付与されています。
実際にこのメトリックのデータ取得のAPI呼び出しがCloudTrailのイベント記録から確認できればよかったのですが、以下のように5分ごとにMackerelからデータ取得らしき動きは確認できるものの、メトリック取得系のイベント記録は確認できません。
調べてみるとGetMetricStatistics、GetMetricDataなどのAPI呼び出しはCloudTrailに記録されれないということでした。
そのため具体的に呼び出しているAPIは確認できていませんが、本エントリではGetMetricStatisticsの呼び出しと仮定します。このGetMetricStatisticsについては東京リージョンの料金で 1,000リクエストあたり$0.01 が発生するものです。（このGetMetricStatisticsAPIを使用しているメトリック数ぶん、5分ごとに呼び出した回数ならびに料金と、実際に発生しているリクエスト数、料金がほぼ一致していることから、具体的なAPI名の確認はできていませんが、このAPIもしくは同様の料金が発生するAPIであると断定しています。）
「5分ごとにAPI呼び出しリクエストを行っている」ということから、メトリック単位での月間の呼び出し回数、料金を確認しておきましょう。1時間では60分÷5分で12回のリクエストとなります。また1ヶ月を730時間とすると、12回×730時間で8,760回が1月あたりのメトリックごとのAPIコール数となります。（なお「1ヶ月を730時間」についてはAWS Pricing Calculatorの計算方法をベースにしています。）
この8,760回のAPIコールについて、先ほど述べたようにGetMetricStatistics（ないし同様の料金が発生する）リクエストとして東京リージョンの料金を計算すると、8,760回÷1,000リクエスト×$0.01で$0.0876となります。
8,760回/メトリック/月$0.0876/メトリック/月
なお、以降本エントリでは上記のとおり東京リージョンの料金を前提とします。また無料利用枠については考慮しないものとします。
監視サービスごとのメトリック数とリクエスト数を確認
メトリック単位での月間のリクエスト数ならびにCloudWatchリクエストで発生する料金が確認できました。続いて監視するAWSサービスごとに、取得するメトリック数を確認して月間リクエスト数ならびに発生する料金を確認していきます。なおMackerelのAWSインテグレーション利用時には取得するメトリックを限定することできます。こちらについて詳細は後述しますが、まずは収集できるすべてのメトリックを指定した場合をまとめます。
EC2に対するCloudWatchリクエスト数
まずはEC2です。EC2では最大で21個のメトリックが収集されます。
APIコール数は8,760回×21個で、合計183,960回となります。またこの回数をCloudWatchリクエスト数として扱うと、183,960回÷1,000リクエスト×0.01USDで1.8396USDが料金として発生します。
183,960回/EC2インスタンス/月$1.8396/EC2インスタンス/月
RDSに対するCloudWatchリクエスト数
続いてRDSについてのCloudWatchリクエスト数の確認です。RDSの場合、各エンジンごとに最大取得メトリック数が異なります。
一例として最も取得数が大きいもの、Aurora MySQLの43個で確認してみましょう。APIコール数は8,760回×43個で合計376,680回となります。CloudWatchリクエスト料金は376,680回÷1,000リクエスト×0.01USDで3.7668USDです。
376,680回/Aurora MySQLインスタンス/月$3.7668/Aurora MySQLインスタンス/月
Auroraは監視対象がインスタンスごとになりますので、2台のインスタンスによるMulti-AZ構成（1台のライターインスタンス、1台のリーダーインスタンス）の場合は倍のリクエスト数、料金となります。
AuroraではないRDS MySQLは最大取得メトリック数が19個です。Aurora MySQLと倍以上違いますね。当然リクエスト数、料金も同じように違ってきます。APIコール数は8,760回×19個で合計166,440回、CloudWatchリクエスト料金は166,440回÷1,000リクエスト×0.01USDで1.6644USDです
166,440回/RDS MySQLインスタンス/月$1.6644/RDS MySQLインスタンス/月
ALBに対するCloudWatchリクエスト数
ALBについては18 + 13 × (ターゲットグループ数)が取得メトリックの最大数となります。ターゲットグループが1つであれば31個、2つであれば44個というぐあいですね。
まずターゲット数が1つの場合を確認してみましょう。APIコール数は8,760回×31個で合計271,560回となります。CloudWatchリクエスト料金は271,560回÷1,000リクエスト×0.01USDで2.7156USDです。
271,560回/1つのターゲットグループを持つALB/月$2.7156/1つのターゲットグループを持つALB/月
ターゲットグループが2つの場合も確認してみます。APIコール数は8,760回×44個で合計385,440回、CloudWatchリクエスト料金は385,440回÷1,000リクエスト×0.01USDで3.8544USDです。
385,440回/2つのターゲットグループを持つALB/月$3.8544/2つのターゲットグループを持つALB/月
一般的なWebサイト構成でのトータルCloudWatchリクエスト数
監視サービスごとのメトリック数とリクエスト数のとして、EC2、RDS、そしてALBを確認してみました。RDSであれば利用エンジン、ALBであればターゲットグループ数によりメトリック数は大きく異なります、ほかサービスの取得メトリック数も含めて、詳細はMackerelのドキュメントを確認しましょう。
ここでは、本エントリで確認したEC2、RDS、ALBから、一例として一般的なWebサイト構成でのトータルのリクエスト数を確認してみます。
構成として以下を想定しました。
- ALB （ターゲットグループは1つ）
- 2台のEC2による冗長構成
- RDS Aurora MySQLをMuti-AZ配置（インスタンスは計2台）
確認してきたとおり、ALBは31個、EC2はインスタンスごと21個（合計42個）、RDS Aurora MySQLもインスタンスごと43個（合計86個）のメトリックとなります。各リソースを合算すると159個のメトリックとなります。ここから月間のAPIコール数、CloudWatchリクエスト料金を確認してみます。
8,760回 × 159個 = 1,392,840回1,392,840回 ÷ 1,000 × $0.01 = $13.9284
APIコール数（CloudWatchリクエスト数）としては1,000,000回オーバー、料金としても$10を超えておよそ$14ほどとなることがわかりました。
CloudWatchリクエスト数はインスタンスタイプによらない
あくまで一例ですが、一般的なWebサイト構成で場合によってはCloudWatchリクエスト数が1,000,000回オーバー、料金としても$10を超えるケースがあることが確認できました。これらはインスタンスタイプによらず、CloudWatchのリクエスト数と料金が発生する点に注意しましょう。
AWS利用費の見積もり方法として、データ転送料金など利用してみないと具体的にわかりにくい項目については、インスタンスなどから計算できる料金の例えば10%などとしておく、というように概算で見積もる場合があるかと思います。CloudWatch全体の利用料としてもこれらと同様の考えでいいのかな、と個人的には考えていました。
しかし監視サービスを利用する場合、ほぼ固定費でCloudWatchのリクエスト費用が発生します。特にインスタンスタイプが小さめの場合、インスタンス以外の料金として一定の割合を概算費用としておく、という計算を行うと、この監視サービスによるCloudWatchリクエスト費用が特に大きく影響してくるかと思います。費用を大きく超えないように概算を出す必要がある場合など、これら監視サービスにより発生するCloudWatchの利用費はあらかじめ固定費として算出しておくのも手なのかな、と思いました。
MackerelのAWSインテグレーション利用時の取得メトリックの制限
ここまで確認してきたリクエスト数は、MackerelのAWSインテグレーション利用時に収集できるすべてのメトリックスを指定したケースとなります。MackerelではAWSインテグレーションの設定の1つとして、取得するメトリックスの指定が可能です。CloudWatchリクエストによる料金をどうしても抑えたい、などの場合には取得メトリックの指定を検討することもできるかと思います。なお取得するメトリックを制限することでMackerel自体の利用費の削減にもつながります。
まとめ
MackerelのAWSインテグレーション利用時のCloudWatchリクエスト量、リクエスト料について確認してみました。メトリックあたりでは一月で8,760回のリクエスト、料金としては$0.0876となりますが、監視対象のシステム構成や取得するメトリック数によって、一月のCloudWatch料金が$10を超えるケースも出てくるかと思います。またインスタンスタイプによらず一定量のCloudWatchリクエストが発生する点にも注意しましょう。
そして今回は監視サービスとしてMackerelを使用した例になりますが、例えばDatadogなどほかAWSと連携できる監視サービスについても、同様のCloudWatch APIを介してメトリックを収集する仕組みかと思います。外部監視サービスを利用する際には、このようなCloudWatchリクエストが発生する点をしっかりと把握しておきましょう。
![[Amazon FSx for NetApp ONTAP] SnapMirror relationshipのHealthをCloudWatchメトリクスにPUTしてみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
