読み取り/書き込みキャパシティモード - Amazon DynamoDB

読み取り/書き込みキャパシティモード

Amazon DynamoDB には、テーブルで読み込みおよび書き込みを処理するための読み込み/書き込み容量モードが 2 つあります。

  • オンデマンド

  • プロビジョニング済み (デフォルト、無料利用枠の対象)

読み取り/書き込みキャパシティーモードは、読み取りおよび書き込みスループットの課金方法と容量の管理方法を制御します。読み取り/書き込みキャパティーモードは、テーブルを作成するときに設定できます。後で変更することもできます。

セカンダリインデックスは、基本テーブルから読み取り/書き込み容量モードを継承します。詳細については、「読み込み/書き込みキャパシティモードの変更時の考慮事項」を参照してください。

次の動画では、テーブル容量モードの概要を紹介します。

DynamoDB テーブルのコストを最適化するためのベストプラクティスの詳細については、「DynamoDB テーブルのコストの最適化」を参照してください。

オンデマンドモード

Amazon DynamoDB オンデマンドは、容量計画なしで 1 秒あたりに数千ものリクエストを処理できる柔軟な請求オプションです。DynamoDB オンデマンドには、読み取りおよび書き込みリクエストのリクエストごとの支払い料金が用意されているため、使用した分だけ課金されます。

オンデマンドモードを選択すると、DynamoDB は、前に到達したトラフィックレベルまで拡張または縮小して、ワークロードを即座に受け入れることができるようにします。ワークロードのトラフィックレベルが新しいピークに達すると、DynamoDB はワークロードに対応するように迅速に対応します。オンデマンドモードを使用するテーブルは、同じ 1 桁ミリ秒のレイテンシー、サービスレベルアグリーメント (SLA) のコミットメント、DynamoDB が既に実現しているセキュリティを提供します。オンデマンドは、新しいテーブルと既存のテーブルの両方に選択できるだけでなく、コードを変更せずに既存の DynamoDB API を引き続き使用することができます。

以下の条件のいずれかに該当する場合、オンデマンドモードは適切なオプションです。

  • 不明なワークロードを含む新しいテーブルを作成する。

  • アプリケーションのトラフィックが予測不可能です。

  • わかりやすい従量課金制の支払いを希望する。

リクエストレートは、DynamoDB スループットのデフォルトテーブルクォータによってのみ制限されますが、リクエストに応じて上げることができます。詳細については、「スループットのデフォルトクォータ」を参照してください。

オンデマンドの使用を開始するには、テーブルを作成または更新してオンデマンドモードを使用できます。詳細については、「DynamoDB テーブルの基本的なオペレーション」を参照してください。

テーブルは 24 時間に 1 回オンデマンドモードに切り替えることができます。オンデマンド形式でのテーブルの作成は、24 時間以内に開始されます。テーブルはいつでもプロビジョニングされたキャパシティモードに戻すことができます。読み込み/書き込みキャパシティモードを切り替えるときに考慮すべき問題については、「読み込み/書き込みキャパシティモードの変更時の考慮事項」を参照してください。

読み取りリクエスト単位と書き込みリクエスト単位

オンデマンドモードのテーブルでは、アプリケーションで実行することが予測される読み込みおよび書き込みスループットを指定する必要はありません。DynamoDB では、読み込みリクエスト単位と書き込みリクエスト単位に関して、アプリケーションがテーブルに対して実行する読み込みと書き込みに対して料金が請求されます。

DynamoDB 読み込みリクエストは、強力な整合性、結果整合性、またはトランザクションのいずれかになります。

  • 4 KB 以下の項目の強力な整合性のある読み込みリクエストには、1 つの読み込みリクエストユニットが必要です。

  • 4 KB 以下の項目の結果整合性のある読み込みリクエストには、2 分の 1 の読み込みリクエストユニットが必要です。

  • 4 KB 以下の項目のトランザクション読み込みリクエストには、2 つの読み込みリクエストユニットが必要です。

4 KB より大きい項目を読み込む必要がある場合、DynamoDB には追加の読み込みリクエストユニットが必要です。必要な読み込みユニットの最大数は、項目のサイズと、結果整合性のある読み込みまたは強力な整合性のある読み込みが必要かどうかによって異なります。たとえば、項目のサイズが 8 KB の場合、1 回の強力な整合性のある読み込みを維持するには読み込みリクエストユニットが 2 個、結果整合性のある読み込みを選択した場合は読み込みリクエストユニットが 1 個、またはトランザクション読み込みリクエストには読み込みリクエストユニットが 4 個必要です。

DynamoDB 読み込み整合性モデルの詳細については「読み込み整合性」を参照してください。

重要

存在しない項目に対して読み取りオペレーションを実行すると、前述の説明のように、DynamoDB は引き続き読み込みスループットを消費します。

1 つの書き込みリクエスト単位は、最大サイズが 1 KB の項目について 1 回の書き込みを表します。1 KB より大きい項目を書き込む必要がある場合、DynamoDB は追加の書き込みリクエストユニットを消費する必要があります。トランザクション書き込みリクエストでは、1 KB までの項目を 1 回書き込むのに書き込みリクエストユニットが 2 個必要です。必要な書き込みリクエストユニットの合計数は、項目サイズに応じて異なります。たとえば、項目のサイズが 2 KB の場合、1 回の書き込みリクエストを維持するには書き込みリクエストユニットが 2 個、またはトランザクション書き込みリクエストには書き込みリクエストユニットが 4 個必要です。

詳細な価格設定例と料金計算ツールを使用したコストの見積もりについては、「Amazon DynamoDB 料金表」を参照してください。

ピークトラフィックとスケーリングプロパティ

オンデマンドキャパシティーモードを使用する DynamoDB テーブルは、アプリケーションのトラフィックボリュームに自動的に対応します。オンデマンドキャパシティーモードは、テーブルにおける前のピークトラフィックの最大 2 倍まで瞬時に対応します。たとえば、アプリケーションのトラフィックパターンにおいて、強力な整合性のある読み込みが 1 秒あたり 25,000 ~ 50,000 回の間で変化し、前のトラフィックピークの読み込みが 1 秒あたり 50,000 回の場合、オンデマンドキャパシティーモードは維持されているトラフィックである 1 秒あたり最大 100,000 回の読み取りに瞬時に対応します。アプリケーションが 1 秒あたり 100,000 回の読み込みのトラフィックを維持する場合、そのピークは新しい前のピークになり、その後のトラフィックは 1 秒あたり最大 200,000 回の読み込みに到達することができます。

テーブルにおける前のピークの 2 倍以上が必要な場合、DynamoDB はトラフィックボリュームが増加する自動的に多くの容量を割り当て、ワークロードがスロットリングされないようにします。ただし、30 分以内に前のピークの 2 倍を超えた場合、スロットリングが発生する可能性があります。たとえば、アプリケーションのトラフィックパターンにおいて、強力な整合性のある読み込みが 1 秒あたり 25,000 ~ 50,000 回の間で変化し、前に到達したトラフィックピークの読み込みが 1 秒あたり 50,000 回の場合、1 秒あたり 100,000 回を超える読み込みまで上げる前に 30 分以上トラフィック増加の間隔をあけることが DynamoDB により推奨されます。

オンデマンドキャパシティモードの初期スループット

既存のテーブルを最近初めてオンデマンドキャパシティーモードに切り替えた場合や、オンデマンドキャパシティーモードが有効な新しいテーブルを作成した場合、テーブルがオンデマンドキャパシティーモードを使用して以前にトラフィックを処理していなくても、テーブルの前のピーク設定は以下のようになります。

考えられるシナリオの例を以下に示します。

  • 100 WCU と 100 RCU に設定されたプロビジョニングテーブル。このテーブルを初めてオンデマンドに切り替えると、DynamoDB は、少なくとも 4,000 書き込みユニット/秒、12,000 読み取りユニット/秒を即座に維持できるようにスケールアウトします。

  • 8,000 WCU と 24,000 RCU に設定されたプロビジョニングテーブル。このテーブルをオンデマンドに切り替えても、常時少なくとも 8,000 書き込みユニット/秒、24,000 読み取りユニット/秒を維持できます。

  • 8,000 WCU と 24,000 RCU で構成されたプロビジョニングテーブルで、持続的に 6,000 書き込みユニット/秒、18,000 読み取りユニット/秒を消費しました。このテーブルをオンデマンドに切り替えても、少なくとも 8,000 書き込みユニット/秒、24,000 読み取りユニット/秒を維持できます。以前のトラフィックにより、このテーブルはスロットリングなしではるかに高いレベルのトラフィックを維持できる可能性があります。

  • テーブルは、以前は 10,000 WCU と 10,000 RCU でプロビジョニングされていましたが、現在は 10 RCU と 10 WCU でプロビジョニングされています。このテーブルをオンデマンドに切り替えても、少なくとも 10,000 書き込みユニット/秒、10,000 読み取りユニット/秒を維持できます。

読み込み/書き込みキャパシティモードの切り替え時のテーブルの動作

テーブルをプロビジョンドキャパシティーモードからオンデマンドキャパシティーモードに切り替えると、DynamoDB はテーブルおよびパーティションの構造にいくつかの変更を加えます。この処理には数分かかることもあります。切り替え期間中、テーブルは以前にプロビジョニングされた書き込みキャパシティーユニットおよび読み込みキャパシティーユニットの両方と整合性のあるスループットを提供します。オンデマンドキャパシティーモードからプロビジョンドキャパシティーモードに戻すと、テーブルは、テーブルがオンデマンドキャパシティーモードに設定されたときに到達した前のピークと整合性のあるスループットを提供します。

オンデマンドキャパシティモードのテーブルの事前ウォーミング

オンデマンドキャパシティモードでは、リクエストがテーブルで前に到達したピークの最大 2 倍まで急増することがあります。リクエストが 30 分以内にデフォルトキャパシティまたは以前に達したピークリクエストレートの 2 倍を超えて急増した場合、スロットリングが発生する可能性があることに注意してください。解決策の 1 つは、予想されるスパイクのピークキャパシティまでテーブルを事前ウォーミングすることです。

テーブルを事前ウォーミングするには、次の手順を実行します。

  1. アカウントの制限をチェックし、プロビジョニングモードで必要なキャパシティに到達できることを確認します。

  2. 既に存在するテーブルやオンデマンドモードで新しいテーブルを事前ウォーミングする場合は、予想されるピークの少なくとも 24 時間前に、このプロセスを開始します。オンデマンドモードとプロビジョニングモードを切り替えることができるのは 24 時間に 1 回だけです。

  3. 現在オンデマンドモードになっているテーブルを事前ウォーミングするには、プロビジョニングモードに切り替えてテーブルがアクティブになるまで待ちます。その後に次のステップに進みます。

    プロビジョニングモードの新しいテーブル、または既にプロビジョニングモードが 24 時間続いている新しいテーブルを事前ウォーミングする場合は、待たずに次のステップに進むことができます。

  4. テーブルの書き込みスループットを目的のピーク値に設定し、その値を数分間維持します。オンデマンドに切り替えるまでは、この大量のスループットによるコストが発生します。

  5. オンデマンドキャパシティモードに切り替えます。これにより、プロビジョニングされたスループットキャパシティ値が維持されるはずです。

プロビジョニングモード

プロビジョニングモードを選択した場合、アプリケーションに必要な 1 秒あたりの読み込みと書き込みの回数を指定します。Auto Scaling を使用すると、トラフィックの変更に応じて、テーブルのプロビジョンドキャパシティーを自動的に調整できます。これにより、コストの予測可能性を得るため、定義されたリクエストレート以下に維持されるように DynamoDB を制御することができます。

以下の条件のいずれかに該当する場合、プロビジョニングモードは適切なオプションです。

  • アプリケーションのトラフィックが予測可能である。

  • トラフィックが一定した、または徐々に増加するアプリケーションを実行する。

  • キャパシティーの要件を予測してコストを管理できる。

読み取りキャパシティユニットと書き込みキャパシティユニット

プロビジョニングモードのテーブルでは、読み取りキャパシティユニット (RCU) と書き込みキャパシティユニット (WCU) の観点でスループットキャパシティを指定できます。

  • 1 つの読み込み容量単位は、最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込みを表します。トランザクション読み込みリクエストでは、4 KB までの項目を 1 秒あたりに 1 回読み込むのに読み込み容量単位が 2 個必要です。4 KB より大きい項目を読み込む必要がある場合、DynamoDB は追加の読み込み容量単位を消費する必要があります。必要な読み込みキャパシティーユニットの最大数は、項目のサイズと、結果整合性のある読み込みまたは強力な整合性のある読み込みが必要かどうかによって異なります。たとえば、項目のサイズが 8 KB の場合、1 秒あたり 1 回の強力な整合性のある読み込みを維持するには読み込みキャパシティーユニットが 2 個、結果整合性のある読み込みを選択した場合は読み込みキャパシティーユニットが 1 個、またはトランザクション読み込みリクエストには読み込みキャパシティーユニットが 4 個必要です。詳細については、「読み込みでのキャパシティユニットの消費」を参照してください。

    注記

    DynamoDB 読み込み整合性モデルの詳細については、「読み込み整合性」 を参照してください。

  • 1 つの書き込み容量単位は、最大サイズが 1 KB の項目について、1 秒あたり 1 回の書き込みを表します。1 KB より大きい項目を書き込む必要がある場合、DynamoDB は追加の書き込み容量単位を消費する必要があります。トランザクション書き込みリクエストでは、1 KB までの項目を 1 秒あたり 1 回書き込むのに書き込み容量単位が 2 個必要です。必要な書き込みキャパシティーユニットの合計数は、項目サイズに応じて異なります。たとえば、項目のサイズが 2 KB の場合、1 秒あたり 1 回の書き込みリクエストを維持するには書き込みキャパシティーユニットが 2 個、またはトランザクション書き込みリクエストには書き込みキャパシティーユニットが 4 個必要です。詳細については、「書き込みでのキャパシティユニットの消費」を参照してください。

重要

オンデマンドテーブルで DescribeTable を呼び出すと、読み込みキャパシティーユニットと書き込みキャパシティーユニットが 0 に設定されます。

アプリケーションでこれより大きな項目の読み込みまたは書き込みが行われると (上限は 400 KB の最大項目サイズである DynamoDB)、消費される容量単位がさらに増えます。

たとえば、6 個の読み込みキャパシティーユニットと 6 個の書き込みキャパシティーユニットを使用してプロビジョニング済みテーブルを作成したとします。これらの設定により、アプリケーションで次のことが可能になります。

  • 1 秒あたり 24 KB までの強力な整合性のある読み込みを実行します (4 KB x 6 読み込み容量単位)。

  • 1 秒あたり 48 KB までの結果的に整合性のある読み込みを実行する (2 倍の読み込みスループット)

  • 1 秒あたり 12 KB までのトランザクション読み込みリクエストを実行する

  • 1 秒あたり 6 KB までの書き込みを実行します (1 KB x 6 書き込み容量単位)。

  • 1 秒あたり 3 KB までのトランザクション書き込みリクエストを実行する

詳細については、「DynamoDB のプロビジョンされた容量テーブルの設定の管理」を参照してください。

プロビジョニングされたスループットとは、テーブルまたはインデックスでアプリケーションが消費できるキャパシティーの上限です。テーブルまたはインデックスでプロビジョニングされたスループットキャパシティを超過したアプリケーションは、リクエストスロットリングの対象になります。

スロットリングは、アプリケーションで大量のキャパシティーユニットが消費されるのを防ぎます。リクエストがスロットリングされると、そのリクエストは HTTP 400 コード (Bad Request) と ProvisionedThroughputExceededException で失敗します。AWS SDK には、スロットリングされたリクエストを再試行するための組み込みサポートがあります (「エラーの再試行とエクスポネンシャルバックオフ」を参照)。そのため、このロジックを自身で記述する必要はありません。スロットリングの問題を解決する方法の詳細については、「Amazon DynamoDB テーブルがスロットリングされるのはなぜですか?」を参照してください。

AWS Management Consoleを使用すると、プロビジョニングされたスループットと実際のスループットをモニタリングしたり、必要に応じてスループットの設定を変更したりできます。

詳細な価格設定例と料金計算ツールを使用したコストの見積もりについては、「Amazon DynamoDB 料金表」を参照してください。

DynamoDB オートスケーリング

DynamoDB Auto Scaling では、テーブルとグローバルセカンダリインデックスのスループット容量が自動的に管理されます。読み込みおよび書き込みのキャパシティーユニットの範囲 (上限と下限) と、また、その範囲内で目標使用率を定義します。DynamoDB Auto Scaling では、アプリケーションのワークロードが増減しても、ターゲットの使用率が維持されます。

DynamoDB Auto Scaling では、急激なトラフィック増加をリクエストのスロットリングなしに処理するために、テーブルまたはグローバルセカンダリインデックスのプロビジョンされた読み込み容量と書き込み容量を増やすことができます。ワークロードが減ると、DynamoDB Auto Scaling はスループットを低下させ、未使用のプロビジョンされた容量に料金が発生しないようにします。

注記

AWS Management Console を使用してテーブルまたはグローバルセカンダリインデックスを作成すると、デフォルトで DynamoDB オートスケーリングが有効になります。

Auto Scaling の設定は、コンソール、AWS CLI、またはいずれかの AWS SDK を使用していつでも管理できます。

詳細については、「DynamoDB Auto Scaling によるスループットキャパシティの自動管理」を参照してください。

リザーブドキャパシティ

Amazon DynamoDB 料金」で説明しているように、DynamoDB のお客様は、DynamoDB 標準テーブルクラスを使用するリザーブドキャパシティを事前に購入できます。リザーブドキャパシティでは、1 回限りの前払い料金を支払い、期間中、プロビジョニングされた最小使用レベルを支払う契約を結びます。リザーブドキャパシティは、時間ごとのリザーブドキャパシティ料金で請求されます。読み込みキャパシティーユニットおよび書き込みキャパシティーユニットを事前に予約することで、プロビジョニングされたキャパシティーコストの大幅なコスト削減を実現できます。リザーブドキャパシティを超えてプロビジョニングしたキャパシティには、標準のプロビジョンされたキャパシティの料金が請求されます。

リザーブドキャパシティ割引は、リザーブドキャパシティを購入したアカウントに最初に適用されます。未使用のリザーブドキャパシティ割引は、同じ AWS 組織内の他のアカウントに購入アカウントとして適用されます。請求情報とコスト管理コンソールの [Preferences] (設定) ページで、リザーブドインスタンスの共有の割引を無効化することができます。詳細については、「リザーブドインスタンスと Savings Plans の割引共有の無効化」を参照してください。

注記

リザーブドキャパシティは、レプリケーションされた書き込みキャパシティユニットでは使用できません。リザーブドキャパシティは、購入したリージョンにのみ適用されます。リザーブドキャパシティは、DynamoDB 標準-IA テーブルクラスまたはオンデマンドキャパシティモードを使用するテーブルでも使用できません。

リザーブドキャパシティーを管理するには、[DynamoDB console] (DynamoDB コンソール) に移動し、[Reserved Capacity] (リザーブドキャパシティー) を選択します。

注記

ユーザーにリザーブドキャパシティの表示または購入を禁止する一方で、コンソールの他の部分にはアクセスを許可できます。詳細については、「Amazon DynamoDB の Identity and Access Management」の「リザーブドキャパシティの提供タイプを購入するためのアクセス許可」を参照してください。

特定の料金の詳細については、「Amazon DynamoDB の料金表」を参照してください。