📈

DynamoDBメトリクスの見方とキャパシティ調整のコツ(平均・合計・サンプル数)

に公開

かなり基本的なところですが、DynamoDBを扱う上で、消費したキャパシティの適切なモニタリングとコントロールは重要なので、見る時のちょっとしたメモです。

あるDynamoDB Tableの消費読み取りキャパシティが、ある時のリリースを境に合計は増加、平均は減少しました。一体何が起きたのでしょうか?

雑に考えると、平均と合計には正の相関があり、合計が増えれば平均も増えるように思います。ですが上記は逆の挙動を示しています。
結論から言うと、一つ一つのリクエストが消費するキャパシティは小さくなったものの、リクエストの頻度(回数)が劇的に増えたため、結果としてシステム全体の合計キャパシティが増大した という状況を表しています。

メトリクスの統計の意味

合計

「合計」メトリクスは、単位時間にDynamoDBが消費した読み取りキャパシティユニットの総量です。
合計が増加しているということは、実際に消費された総量が増加したことを意味します。これが実態を表しています。

平均

「平均」メトリクスは以下の式で計算されます。

\text{平均} = \frac{\text{合計 (Sum)}}{\text{サンプル数 (SampleCount)}}

合計を「サンプル数」で割った値となるため、サンプル数が大きければ小さくなり、サンプル数が小さければ大きくなることがわかります。
「サンプル数」とは、単位時間にメトリクス( ConsumedReadCapacityUnits など)のデータが観測・記録された回数です。つまり、DynamoDBに対する読み取り/書き込みリクエスト数とほぼ同義になります。

そのため冒頭に挙げたように、合計が増加しているのに平均が減少した場合というのは、サンプル数が増加していることになります。

実際に何をどう見ていくとよいのか?

2024年にオンデマンドキャパシティモードの料金が値下げしたこともあり、積極的にプロビジョンドモードを使う理由も薄れつつありますが、プロビジョンドモードの場合は無駄なく必要なキャパシティを確保しておくことがコストやスループット観点で重要です。
実際によく見ているポイントを3つまとめました。

確保したプロビジョンドキャパシティの量がちょうどよいか?

以下の2つを並べて比較することで、確保したキャパシティと、実際に消費したキャパシティに関して、同じ条件での比較が可能になります(期間が5分間の場合)

  • ProvisionedReadCapacityUnits の最大(または合計)
  • 数式を使用し、 ConsumedReadCapacityUnits の合計 / 300 の値

ポイントは合計を300で割っていることです。
前述の通り平均ではサンプル数によって数値がバラついてしまうので、合計を時間で割ることにより、単位時間ごとの消費キャパシティを計算させています。

上記は読み取りの場合ですが、書き込みも同様です。

(参考にした記事)[小ネタ] DynamoDBのキャパシティユニットをCloudWatchで見るときのコツ | Developers.IO

確保しているキャパシティが十分かどうか?

ReadProvisionedThroughputThrottleEventsWriteProvisionedThroughputThrottleEvents を確認し、スロットルが頻発している場合や慢性的に0以上になっている場合は、そもそものキャパシティが不足している可能性が高いです。

DynamoDBには「バーストキャパシティ」という仕組みがあり、直近の使い切っていない余剰分のキャパシティを貯金しておき、バースト(スパイク)時に消費する(切り崩す)ことができます。ですのでちょっとした一時的にキャパシティが不足するだけであれば問題はありません。
私たちのシステムでは、全体の消費キャパシティに対し、大きなスパイクが発生することが起こりにくいので、スロットルの発生は0になるよう、キャパシティを設定しています。

なお、スロットルに関しては今年のアップデートでより細かいメトリクスを取得できるようになりました。元々は ReadThrottleEvents / WriteThrottleEvents という形でスロットルの発生有無しかわからなかったのですが、切り分けがしやすくなっています。

https://aws.amazon.com/jp/blogs/database/enhanced-throttling-observability-in-amazon-dynamodb/

リリースやその他の事象に伴うキャパシティの変化・傾向を確認するには?

絶対量であれば ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits の「合計」を見るのがよいでしょう。
リクエスト回数を含めた分析については「合計」だけでなく「平均」や「サンプル数」と比べて分析するのがよいでしょう。

まとめ

DynamoDBメトリクスの見方とキャパシティ調整のコツ(平均・合計・サンプル数)でした。

CloudWatchメトリクスではデフォルトの統計が「平均」になりますが、DynamoDBのキャパシティを見る場合「合計」をうまく活用することがポイントで少し癖があるかなと思いますので、参考になれば幸いです。

株式会社キャリオット

Discussion