こんにちは🐱 技術課の山本です。
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 で対応可能です。
オンデマンドモードは使用したユニット数に応じた課金になるため、継続的に一定数のリクエストがある場合には料金が増加しがちです。
一定数のリクエストが続くことが予想できる時
プロビジョンドモードが向いていると言えそうです。
Auto Scaling も不要そうです。
そのほか注意点
オンデマンドモードに切り替えた後にプロビジョンドモードに戻した場合、次にオンデマンドモードに切り替えるためには 24 時間待つ必要があります。そのため、オンデマンドモード時の事前ウォーミングには時間がかかります。参考:「オンデマンドキャパシティモードのテーブルの事前ウォーミング」
プロビジョンドモードを使用する場合には、「リザーブドキャパシティ」という前払いによる割引なども受けることが可能ですので、長期利用する場合には検討する余地があります。
余談
週末は山梨県大月市の山をトレランしました。
登り切って、甲府盆地越しに見える南アルプスの山々を見ながら、ぼーっと過ごした時間は感無量でした。
山本 哲也 (記事一覧)
カスタマーサクセス部のエンジニア。2024 Japan AWS Top Engineers に選んでもらいました。
今年の目標は Advanced Networking – Specialty と Machine Learning - Specialty を取得することです。
山を走るのが趣味です。今年の目標は 100 km と 100 mile を完走することです。 100 km は Gran Trail みなかみで完走しました。残すは OSJ koumi 100 で 100 mile 走ります。実際には 175 km らしいです。「草 100 km / mile」 もたまに企画します。
基本的にのんびりした性格です。座右の銘は「いつか着く」