CloudWatch API で PutMetricData を呼び出すときに、スロットリングを回避する方法を教えてください。

簡単な説明

CloudWatch で PutMetricData API 呼び出しのエラー「400 ThrottlingException」を受け取るとき、以下のメッセージも受け取ります。

<ErrorResponse xmlns="http://monitoring.amazonaws.com/doc/2010-08-01/">
  <Error>
    <Type>Sender</Type>
    <Code>Throttling</Code>
    <Message>Rate exceeded</Message>
  </Error>
  <RequestId>2f85f68d-980b-11e7-a296-21716fd2d2e3</RequestId>
</ErrorResponse>

サービスのパフォーマンスを向上させるため、CloudWatch は AWS リージョンに基づいて各 AWS アカウントのリクエストを調整します。現在の PutMetricData API リクエストクォータについては、「CloudWatch サービスクォータ」を参照してください。

注意: リージョン内の PutMetricData API へのすべての呼び出しは、最大許容リクエストレートにカウントされます。このカウントには、カスタムアプリケーションまたはサードパーティアプリケーションからの呼び出しが含まれます。このようなアプリケーションの例としては、CloudWatch エージェント、AWS コマンドラインインターフェイス (AWS CLI)、AWS マネジメントコンソールなどがあります。

解決方法

次の方法で、呼び出しレートを下げ、API スロットリングを回避することをお勧めします。

• 短時間に複数回 API コールを行うのではなく、全体を通して API コール回数を均等にします。1 分の分解能でデータを利用する必要がある場合、そのメトリクスを出力するのにまるまる 1 分あります。変化に富んだタイミングでデータポイントを送信するには、ジッター (ランダム化した遅延) を使用します。
• できるだけ多くのメトリクスを、1 つの API 呼び出しにまとめます。例えば、1 つの PutMetricData 呼び出しには、1,000 個のメトリクスと 150 個のデータポイントを含めることができます。StatisticSet などの事前に集計されたデータセットを使用して、集約されたデータポイントを公開することもできます。これにより、1 秒あたりの PutMetricData 呼び出しの数が減ります。
• エクスポネンシャルバックオフとジッターで呼び出しを再試行します。

---

関連情報

CloudWatch API リファレンス