こんにちは🐱 技術課の山本です。

QA 案件で DynamoDB のキャパシティモードについて質問を受けまして、あんまりしっかり説明できなかったので、まとめることにしました。 DynamoDB には 2 つのキャパシティモードがあります。

オンデマンドモード
プロビジョニングモード

オンデマンドモードでは、DynamoDB テーブルへの読み取り・書き込みリクエストの数に応じて、自動でキャパシティを調整して応答します。

プロビジョニングモードでは、事前に秒間の読み取り・書き込みリクエスト数を設定し、静的にキャパシティを割り当てておきます。割り当て済みのキャパシティで応答できない場合はスロットリングエラーを返します。割り当てたキャパシティは後から停止なく変更可能です。
プロビジョニングモードには、AutoScaling 機能があります。読み取り・書き込みリクエスト数の最小値と最大値を設定しておくと、実際のリクエスト数に応じて設定した範囲内でキャパシティを調整します。

リクエスト数の予想ができない場合はオンデマンドモード、予想ができる場合はキャパシティを静的に設定するプロビジョンドモードを使用すると良さそうです。それぞれのモードを比較してみます。

オンデマンド・プロビジョンドの比較

料金の比較

オンデマンドモードでは、キャパシティを確保しないので、書き込み・読み込みリクエスト単位で請求が発生します。プロビジョンドモードでは割り当てたキャパシティに対して時間課金が発生します。
※下に記載する料金は執筆時のものです。
以下は、オンデマンドモードの東京リージョンでの書き込み・読み込みリクエスト料金です。( DynamoDB には他にもストレージ料金やバックアップ料金などがかかります。)

オンデマンドスループットタイプ	料金
書き込み要求単位 (WRU)	書き込み要求ユニット 100 万あたり 1.4269USD
読み出し要求単位 (RRU)	読み出し要求ユニット 100 万あたり 0.285USD

以下は、プロビジョンドモードの東京リージョンでの書き込み・読み込みリクエスト料金です。

プロビジョン済みスループットタイプ	時間あたりの料金
書き込みキャパシティーユニット (WCU)	0.000742USD/WCU
読み込みキャパシティーユニット (RCU)	0.0001484USD/RCU

以下の場合で大体同じくらいの料金になりそうです。

オンデマンドモードで書き込みと読み込みがそれぞれ 100 万ユニットあった場合、1.7119 USD
プロビジョンドモードで書き込みと読み込みのキャパシティーユニット数をそれぞれ 3 に設定した場合、1.922976 USD

同じ料金で処理できるユニット数の合計を考えると、プロビジョンドモードの方が多くなるでしょう。(プロビジョンドモードで書き込みと読み込みのキャパシティーユニット数をそれぞれ 3 に設定した場合、フルでキャパシティユニットを使い続けると、月に 1555 万ユニットくらい処理できるため。)
リクエスト数が瞬間的にキャパシティを超えて増加するようなことがないと予想できる場合には、プロビジョンドモードが安いでしょう。

ユニットとは
DynamoDB へのリクエストはユニット単位の課金になります。
DynamoDB テーブルにデータを読み書きする際に、オブジェクトサイズやリクエストの種別によって、必要なユニットの数が異なります。
以下の表に記載します。

読み取りに使用するユニット数

オブジェクトサイズ	結果整合性のある読み取り	強力な整合性のある読み取り	トランザクション読み取り
4 KB以下	0.5 ユニット	1 ユニット	2 ユニット
8 KB以下	1 ユニット	2 ユニット	4 ユニット

書き込みに使用するユニット数

オブジェクトサイズ	標準の書き込み	トランザクション書き込み
1 KB以下	1 ユニット	2 ユニット
2 KB以下	2 ユニット	4 ユニット

参考：プロビジョンドキャパシティの料金

使用するユニット数は実際に机上で計算するのも難しいので、テスト時などに CloudWatch のメトリクスを見るのが賢明かと思います。
1 分あたりの合計までしか出せないので、60 で割って 1 秒あたりのユニット数にしてあげる必要はあります。

メトリクス名
- ConsumedWriteCapacityUnits
- ConsumedReadCapacityUnits

参考：DynamoDB のメトリクスとディメンション - Amazon DynamoDB

下の図では「期間」を「1 分」にして、「統計」を「合計」にしています。

カーソルがあっているポイントは ConsumedWriteCapacityUnits が3077 、 ConsumedReadCapacityUnits が 371.5 です。
秒間だと、書き込みは 52 ユニット、読み取りは 6.2 ユニットほど使用しています。
同様のユニット使用が継続し、瞬間的なリクエスト増もない場合は、プロビジョンドモードが良さそうです。
手元の試算だと、プロビジョンドモードで考えた時は月間 60 ドル前後、オンデマンドモードでは月間 200 ドル前後になりました。結構違いますね。

プロビジョンドモードの料金計算
　最大時の約 2 倍のリクエスト数を処理するようにキャパシティを設定したと仮定します。

オンデマンドモードの料金計算
　秒間の書き込みは 52 ユニット、読み取りは 6 ユニットが 1 ヶ月継続したと仮定します。

もう少し広い期間で見てみましょう。

CloudWatch メトリクスを 1 週間分にしてみると、読み取りキャパシティが 191,185 になっている箇所があります。
秒間に直すと、3,800 程度です。3,800 は平均なので、最初の 1 秒が 10,000 などといった可能性もあります。
プロビジョンドモードで 3,800 〜 10,000 のユニットを確保しておくよりも、オンデマンドモードの方が安く済みそうです。
手元の試算だと、プロビジョンドモードで考えた時は月間 600 ドル前後、オンデマンドモードでは月間 10 ドル前後になりました。結構違いますね。

プロビジョンドモードの料金計算
　最大時の約 1.5 倍のリクエスト数を処理するようにキャパシティを設定したと仮定します。

オンデマンドモードの料金計算
　統計期間を 1 日にすると、1 日の合計使用ユニット数をもう少し正確に推計できます。　同じリクエスト数が 30 日続いたと仮定して算出しました。

予測できない瞬間的なスパイクがある時

オンデマンドモードでは、以前にあったリクエスト数ピークの 2 倍のリクエスト量に対応できます。
そこを超えるとスロットリングエラーになります。
また、事前にウォーミングアップしておくことも可能です。詳細は「オンデマンドキャパシティモードのテーブルの事前ウォーミング」を参照ください。

一方、プロビジョンドモードにはバーストクレジットという概念があり、直前の 5 分間で使用していないかった分のキャパシティを保持していて、使用することができます。参考：バーストキャパシティを効率的に使用する
そこを超えるとスロットリングエラーになります。
Auto Scaling を設定している場合、増減が数分間維持された場合にのみ、プロビジョンされたスループット設定を変更する仕組みになっています。そのため、瞬間的なスパイクには向いていません。Auto Scaling は内部的に CloudWatch Alarm を使用しているため、メトリクスの収集には 1 分以上かかるためです。参考：DynamoDB Auto Scaling によるスループットキャパシティの自動管理

オンデマンドモードが向いていると言えそうです。

決まった時間の瞬間的なスパイクがある時

基本的な比較は上の見出しと同じです。
「決まった時間」にスパイクするのであれば、バーストクレジットで対応できる可能性もあるため、プロビジョンドモードも選択肢にはなり得ます。
しかし、スパイク時のリクエスト量がバーストクレジットを上回ってくるとスロットリングエラーになります。
また、リクエストの最大数に合わせてキャパシティを設定しておくと、結果的にオンデマンドモードよりも料金が高くなります。
スパイク時のリクエスト量が予想できない場合は、オンデマンドモードが向いていると言えそうです。

リクエスト数の緩やかな増減が続くことが予想できる時

リクエスト数の予想ができ、数分単位で緩やかに増減し続ける場合には、プロビジョンドモードが向いていると言えそうです。 緩やかな増減には Auto Scaling で対応可能です。
オンデマンドモードは使用したユニット数に応じた課金になるため、継続的に一定数のリクエストがある場合には料金が増加しがちです。