DynamoDB のプロビジョンされた容量テーブルの設定の管理 - Amazon DynamoDB

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

DynamoDB のプロビジョンされた容量テーブルの設定の管理

Amazon DynamoDB でプロビジョンされたテーブルを新しく作成する場合は、プロビジョンドスループット性能を指定する必要があります。これは、テーブルがサポートできる読み込みおよび書き込みアクティビティの量です。DynamoDB はこの情報を使用して、スループット要件を満たすのに十分なシステムリソースを予約します。

注記

サーバーの容量設定、ストレージ、スループットを管理しなくてもよいように、代わりにオンデマンドモードのテーブルを作成できます。DynamoDB は、前に到達したトラフィックレベルまで拡張または縮小して、ワークロードを即座に受け入れることができるようにします。ワークロードのトラフィックレベルが新しいピークに達すると、DynamoDB はワークロードに対応するように迅速に対応します。詳細については、「オンデマンドモード」を参照してください。

オプションで、DynamoDB Auto Scaling によりテーブルのスループット容量を管理できます。ただし、この場合もテーブル作成時には読み込みおよび書き込み容量の初期設定を指定する必要があります。DynamoDB Auto Scaling はこれらの初期設定を開始点として使用した後、アプリケーションの要件に応じて設定を動的に調整します。詳細については、「DynamoDB Auto Scaling によるスループットキャパシティの自動管理」を参照してください。

アプリケーションデータとアクセス要件が変わると、テーブルのスループット設定を変更しなければならない場合があります。DynamoDB Auto Scaling を使用している場合、スループット設定は実際のワークロードに応じて自動的に調整されます。UpdateTable オペレーションを使用し、テーブルのスループットキャパシティーを手動で調整することもできます。既存のデータストアから新しい DynamoDB テーブルにデータをバルクロードする必要がある場合などに便利です。大容量の書き込みスループットを設定したテーブルを作成し、データのバルクロードが完了してからこの設定を削減ですることができます。

スループットの要件は容量単位、つまり、アプリケーションが読み込みと書き込みを行う必要がある 1 秒あたりのデータ量で指定します。これらの設定は必要に応じて後から変更できます。また、DynamoDB Auto Scaling を有効化して自動的に変更することもできます。

読み込みキャパシティユニット

1 つの読み込み容量単位は、最大サイズ 4 KB の項目について、1 秒あたり 1 回の強力な整合性のある読み込み、あるいは 1 秒あたり 2 回の結果整合性のある読み込みを表します。

注記

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

例えば、10 ユニットのプロビジョニングされた読み取りキャパシティーでテーブルを作成するとします。これにより、最大 4 KB の項目について、1 秒あたり 10 回の強い整合性のある読み込み、または 20 回の結果的に整合性のある読み込みを行えます。

4 KB を超える項目の読み込みには、より多くの読み込み容量単位を消費します。たとえば、8 KB (4 KB x 2) の項目の強い整合性のある読み込みは、2 ユニットの読み込み容量単位を消費します。同じ項目の結果的に整合性のある読み込みは、読み込みキャパシティーを 1 ユニットしか消費しません。

読み込みの項目サイズは、次の 4 KB の倍数に切り上げられます。たとえば、3,500 バイトの項目の読み込みは、4 KB の項目の読み込みと同じスループットを消費します。

読み込みでのキャパシティユニットの消費

DynamoDB 読み込みオペレーションが読み込み容量単位を消費する仕組みについて次に説明します。

  • GetItem — テーブルから単一の項目を読み込みます。GetItem が消費する容量単位の数を決定するには、項目のサイズを次の 4 KB 境界まで切り上げます。強力な整合性のある読み込みを指定した場合は、これが必要なキャパシティーユニットの数になります。結果的に整合性のある読み込み (デフォルト) の場合、この数を 2 で割ります。

    たとえば、3.5 KB の項目を読み取ると、DynamoDB は項目サイズを 4 KB まで切り上げます。10 KB の項目を読み取ると、DynamoDB は項目サイズを 12 KB まで切り上げます。

  • BatchGetItem — 1 つ以上のテーブルから最大 100 個の項目を読み込みます。DynamoDB はバッチの各項目を個別の GetItem リクエストとして処理するため、DynamoDB は各項目のサイズを次の 4 KB 境界にまず切り上げてから、合計サイズを計算します。この結果は、すべての項目の合計サイズと必ずしも同じではありません。たとえば、BatchGetItem が 1.5 KB の項目と 6.5 KB の項目を読み込むと、DynamoDB は、サイズを 8 KB(1.5 KB + 6.5 KB)ではなく、12 KB(4 KB + 8 KB)と算出します。

  • Query — 同じパーティションキーバリューを持つ複数の項目を読み込みます。返されるすべての項目は単一の読み込みオペレーションとして扱われ、DynamoDB はすべての項目の合計サイズを計算し、次の 4 KB 境界に切り上げます。たとえば、クエリの結果、合計サイズが 40.8 KB になる 10 項目が返されるとします。DynamoDB は、オペレーションの項目サイズを 44 KB に切り上げます。クエリの結果、64 バイトの項目が 1,500 項目返されると、累積サイズは 96 KB になります。

  • Scan— テーブルのすべての項目を読み込みます。DynamoDB は、スキャンによって返されるデータのサイズではなく、評価されるデータのサイズを考慮します。

存在しない項目に対して読み込みオペレーションを実行しても、DynamoDB ではやはりプロビジョンド読み込みスループットが消費されます。強力な整合性のある読み込みオペレーションでは、1 つの読み込み容量単位が消費されますが、結果整合性のある読み込みオペレーションでは、半分の読み込み容量単位が消費されます。

項目を返す任意のオペレーションで、属性のサブセットを取得するようリクエストできます。ただし、そうすることで項目サイズの計算に影響は生じません。また、QueryScan は、属性値の代わりに項目数を返します。項目数の取得には、同じ量の読み込みキャパシティーユニットが使用され、その結果は同じ項目サイズの計算の影響を受けます。これは、DynamoDB では、項目数を増加させるために各項目を読み込む必要があるからです。

読み込みオペレーションと読み込み整合性

前出の計算によって、強い整合性のある読み込みリクエストが仮定されます。結果整合性のある読み込みリクエストでは、このオペレーションによってキャパシティーユニットの半分のみが消費されます。結果整合性のある読み込みでは、合計項目サイズが 80 KB の場合、オペレーションによって 10 キャパシティーユニットのみが消費されます。

書き込みキャパシティユニット

1 つの書き込み容量単位は、最大サイズが 1 KB の項目について、1 秒あたり 1 回の書き込みを表します。

例えば、10 ユニットのプロビジョニングされた書き込みキャパシティーでテーブルを作成するとします。これにより、1 秒あたり最大でサイズが 1 KB の項目について、1 秒あたり 10 回の書き込みを行えます。

書き込みの項目サイズは、次の 1 KB の倍数に切り上げられます。たとえば、500 バイトの項目の書き込みは、1 KB の項目の書き込みと同じスループットを消費します。

書き込みでのキャパシティユニットの消費

DynamoDB 書き込みオペレーションが書き込み容量単位を消費する仕組みについて次に説明します。

  • PutItem— テーブルに単一の項目を書き込みます。同じプライマリキーを持つ項目がテーブル内に存在する場合、このオペレーションによって項目が置き換えられます。プロビジョニングされたスループットの消費量を算出する場合、重要な項目サイズは 2 つのうち大きい方となります。

  • UpdateItem— テーブル内の 1 つの項目を変更します。DynamoDB は更新の前後で実際の項目のサイズを考慮します。プロビジョニングされたスループットの消費は、これらの項目サイズの大きい方を反映しています。項目の属性の一部だけを更新した場合でも、UpdateItem は、プロビジョニングされたスループットの総量 ("前" の項目サイズと "後" の項目サイズで、より大きい方) を消費します。

  • DeleteItem — テーブルから単一の項目を削除します。プロビジョニングされたスループットの消費量は、削除された項目のサイズに基づいています。

  • BatchWriteItem — 1 つ以上のテーブルに最大 25 個の項目を書き込みます。DynamoDB は、バッチ内の各項目を個別の PutItem または DeleteItem リクエストとして処理します (更新はサポートされません)。このため、DynamoDB は各項目のサイズを 1 KB 境界にまず切り上げてから、合計サイズを計算します。この結果は、すべての項目の合計サイズと必ずしも同じではありません。たとえば、BatchWriteItem が 500 バイトと 3.5 KB の項目を書き込んだ場合、DynamoDB はサイズを、4 KB (500 bytes + 3.5 KB) ではなく、5 KB (1 KB + 4 KB) と計算します。

PutItemUpdateItem、および DeleteItem の各オペレーションでは、DynamoDB は項目のサイズを次の 1 KB に切り上げます。たとえば、1.6 KB の項目を入力または削除すると、DynamoDB は項目サイズを 2 KB まで切り上げます。

PutItemUpdateItemDeleteItem では、条件付き書き込みを行えます。ここでは、条件が true と評価される式を指定して、オペレーションが正常に実行されるようにします。式が false と評価された場合でも、DynamoDB はテーブルの書き込みキャパシティユニットを消費します。消費される量は、項目 (テーブル内の既存の項目または作成・更新しようとしている新しい項目) のサイズによって異なります。例えば、既存の項目が 300 KB で、作成または更新しようとしている新しい項目が 310 KB の場合、消費される書き込みキャパシティユニットは 310 KB の項目になります。

リクエストのスロットリングとバーストキャパシティ

テーブルがサポートできるよりも高いレートでアプリケーションが読み込みや書き込みを行うと、DynamoDB はこれらのリクエストのスロットリングを開始します。読み込みや書き込みをスロットリングした DynamoDB は、発信者に ProvisionedThroughputExceededException を返します。その後、アプリケーションは、リクエストの再試行前に短時間待機するなど、適切なアクションを実行できます。

注記

ソフトウェア開発には AWS SDKsを使用することをお勧めします。 AWS SDK は、スロットリングされたリクエストを再試行するための組み込みサポートを提供します。このロジックを自身で記述する必要はありません。詳細については、「エラーの再試行とエクスポネンシャルバックオフ」を参照してください。

DynamoDB コンソールにはテーブルの Amazon CloudWatch メトリクスが表示されるため、スロットリングされた読み込みリクエストと書き込みリクエストをモニタリングできます。過剰なスロットリングが発生した場合は、テーブルのプロビジョニングされたスループット設定を増加させることを検討する必要があります。

場合によっては、DynamoDB はバーストキャパシティを使用し、テーブルのスループット設定を超過する読み込みや書き込みに対応します。バーストキャパシティーにより、スロットリングされていた可能性のある読み込みまたは書き込みリクエストが成功します。詳細については、「バーストキャパシティを効率的に使用する」を参照してください。

リクエストのスロットリングとアダプティブキャパシティ

DynamoDB は、 AWS クラウド内の複数のサーバーに保存されているパーティション間でデータを自動的に分散します (詳細については、「」を参照してくださいパーティションとデータ分散)。読み書きアクティビティは常に均等に分散できるとは限りません。データアクセスが不均等の場合は、他のパーティションと比較して、「ホット」パーティションに大容量の読み書きトラフィックが送信されることがあります。アダプティブキャパシティーでは、さらに多くのトラフィックを受け取るパーティションのスループットキャパシティーを自動的に増加させます。詳細については、「DynamoDB アダプティブキャパシティを理解する」を参照してください。

初期スループット設定の選択

すべてのアプリケーションは、データベースの読み込みおよび書き込みについて異なる要件を持っています。DynamoDB テーブルの初期スループット設定を決定する際は、次を入力することを検討する必要があります。

  • 項目のサイズ。一部のサイズの小さい項目の読み込みや書き込みには、1 キャパシティーユニットで十分です。項目のサイズが大きくなると、複数のキャパシティーユニットが必要になります。テーブルに入る項目のサイズを見積もることにより、テーブルのプロビジョニングされたスループットの正確な設定を指定することができます。

  • 予測される読み込みおよび書き込みリクエストのレート。項目のサイズに加えて、1 秒あたりに必要な読み込みや書き込みの数を見積もる必要があります。

  • 読み込み整合性の要件。読み込みキャパシティーユニットは、強い整合性のある読み込みオペレーションに基づいています。ただし、このオペレーションでは、データベースリソースの消費量は結果整合性のある読み込みの 2 倍になります。アプリケーションが強力な整合性のある読み込みを要求するか、またはこの要件を緩和して結果的に整合性のある読み込み行うかどうかを決定する必要があります (DynamoDB での読み込みオペレーションは、デフォルトでは結果整合性があります。必要に応じて、これらのオペレーションに強力な整合性のある読み込みをリクエストできます)。

たとえば、テーブルから 1 秒あたり 80 項目を読み込むとします。項目のサイズは 3 KB で、強力な整合性のある読み込みが必要です。このシナリオでは、読み込みごとに 1 つのプロビジョニングされた読み込みキャパシティーユニットが必要です。この数を判断するには、次の例に示すようにオペレーションの項目サイズを 4 KB で除算し、次に最も近い整数に切り上げます。

  • 3 KB / 4 KB = 0.75、または 1 読み込み容量単位

このシナリオでは、テーブルのプロビジョニングされた読み込みスループットを 80 読み込みキャパシティーユニットに設定する必要があります。

  • 1 読み込み容量単位/項目 x 80 読み込み/秒 = 80 読み込み容量単位

ここで、テーブルに 1 秒あたり 100 項目を書き込み、項目のサイズが 512 バイトであるとします。このシナリオでは、書き込みごとに 1 つのプロビジョニングされた書き込みキャパシティーユニットが必要です。この数を判断するには、オペレーションの項目サイズを 1 KB で除算し、次に最も近い整数に切り上げます。

  • 512 バイト / 1 KB = 0.5 または 1

このシナリオでは、テーブルのプロビジョニングされた書き込みスループットを 100 書き込みキャパシティーユニットに設定する必要があります。

  • 1 書き込み容量単位/項目 x 100 書き込み/秒 = 100 書き込み容量単位

注記

プロビジョニングされたスループットについての推奨事項と関連トピックについては、「パーティションキーを効率的に設計し、使用するためのベストプラクティス」を参照してください。

スループット設定の変更

テーブルの DynamoDB Auto Scaling を有効化している場合は、スループット容量は実際の使用量に応じて動的に調整されます。手動による介入は必要ありません。

テーブルのプロビジョニングされたスループット設定は、 AWS Management Console または UpdateTableオペレーションを使用して変更できます。スループットの 1 日の増減については、「Amazon DynamoDB のサービス、アカウント、およびテーブルのクォータ」を参照してください。

スロットリング問題のトラブルシューティング

スロットリングに関連していると思われる問題のトラブルシューティングでは、まずスロットリングの原因が DynamoDB か、アプリケーションかを確認することが重要です。

一般的なシナリオと、その解決に役立つ手順を以下に示します。

DynamoDB テーブルには十分なプロビジョンド容量があるが、リクエストがスロットルされている。

これは、スループットが 1 分あたりの平均を下回っていても、1 秒あたりの使用可能な量を超えている場合に発生することがあります。DynamoDB は分レベルのメトリクスのみを に報告します。その後 CloudWatch、1 分間の合計として計算され、平均化されます。ただし、DynamoDB 自体のレート制限は 1 秒単位で適用されます。このため、その 1 分間の範囲でわずかな時間 (たとえば数秒未満) であっても、発生したスループットが多すぎると、その範囲の残りのリクエストが抑制される可能性があります。例えば、テーブルに 60 WCU がプロビジョニングされている場合、1 分で 3600 回の書き込みを実行できます。ただし、1 秒で 3600 個の WCU リクエストがすべて実行された場合、残りの時間にスロットリングが発生します。

このシナリオを解決する 1 つの方法は、API 呼び出しに多少のジッターとエクスポネンシャルバックオフを追加することです。詳細については、バックオフとジッターに関するこの投稿を参照してください。

自動スケーリングが有効になっているが、テーブルはまだスロットルされている。

これは、トラフィックでの突然のスパイク時に発生する可能性があります。Auto Scaling は、2 つのデータポイントが 1 分以内に設定されたターゲット使用率値を超えた場合にトリガーできます。したがって、消費された容量が 2 分間一貫してターゲット使用率を上回っているため、自動スケーリングが実行される可能性があります。ただし、スパイクが 1 分以上離れている場合、自動スケーリングがトリガーされないことがあります。同様に、15 個の連続するデータポイントが目標使用率を下回ると、スケールダウンイベントがトリガーされます。いずれの場合も、Auto Scaling がトリガーされると、 UpdateTable呼び出しが呼び出されます。テーブルまたはインデックスのプロビジョニングされた容量を更新するには、数分かかることがあります。この期間中、テーブルの以前のプロビジョニングされた容量を超えるリクエストはスロットリングされます。

つまり、自動スケーリングでは、DynamoDB テーブルをスケールアップするために、目標使用率値を超えている連続したデータポイントが必要です。このため、自動スケーリングは、スパイクのあるワークロードに対処するためのソリューションとしては推奨されません。詳細については、「テーブルの Auto Scaling 設定を評価する」を参照してください。

テーブルは「オンデマンド」キャパシティモードを使用しているが、まだスロットルされている。

DynamoDB は、オンデマンドテーブルの場合、トラフィック量が増加するにつれて、自動的に割り当てられる容量が増加します。アクセスがパーティション間で均等に分散され、テーブルが以前のピークトラフィックの 2 倍を超えない限り、テーブル全体はスロットルされません。ただし、30 分以内にトラフィック量が前のピークの 2 倍を超えると、スロットリングが発生する可能性があります。詳細については、OnDemand 「スケーリング」を参照してください。

ホットキーが原因でスロットリングの問題が発生している可能性がある。

DynamoDB では、高いカーディナリティを持たないパーティションキーによって、少数のパーティションのみをターゲットとする多くのリクエストが発生する可能性があります。生成される「ホットパーティション」が、1 秒あたり 3000 RCU または 1000 WCU のパーティション制限を超えると、スロットリングを引き起こす可能性があります。診断ツール Contributor Insights CloudWatch は、各テーブルの項目アクセスパターンの CCI グラフを提供することで、これをデバッグするのに役立ちます。このツールを使用すると、DynamoDB テーブルの最も頻繁にアクセスされるキーやその他のトラフィックの傾向を継続的に監視できます。 CloudWatch Contributor Insights の詳細については、「CCI」を参照してください。適切なホットキーを選択する方法の詳細については、「CloudWatch Contributor Insights for DynamoDB: 仕組み」を参照してください。

CloudWatch メトリクスを使用したスロットリングの調査

以下は、スロットリングイベント中に監視する DynamoDB メトリクスの一部です。これらは、スロットルされたリクエストを作成しているオペレーションを見つけ、根本的な問題を特定するのに役立ちます。

1。 ThrottledRequests

  • 1 つのスロットリングリクエストに複数のスロットリングイベントが含まれることがあるため、調べる対象のイベントの関連性が高くなる可能性があります。

    例えば、GSI を持つテーブル内の項目を更新する場合、テーブルへの書き込みと各インデックスへの書き込みという複数のイベントが発生します。これらのイベントの 1 つ以上がスロットリングされている場合でも、 は 1 つだけになります ThrottledRequest。

2。 ReadThrottleEvents

  • 1 つのテーブルまたは GSI のプロビジョニングされた RCU を超えるリクエストを監視します。

3。 WriteThrottleEvents

  • 1 つのテーブルまたは GSI のプロビジョニングされた WCU を超えるリクエストを監視します。

4。 OnlineIndexConsumedWriteCapacity

  • 新しい GSI をテーブルに追加するときに消費される WCU の数に注目します。GSI の ConsumedWriteCapacityUnits には、インデックスの作成中に消費される WCU は含まれません。

  • GSI の WCU の設定が低すぎると、バックフィルフェーズ中の書き込みアクティビティのスロットリングが発生することがあります。

5。 OnlineIndexThrottleEvents

  • 新しい GSI をテーブルに追加するときに発生する書き込みスロットリングイベントの数を確認します。

  • WCU の設定が低すぎてスロットルされていることが判明した場合、バックフィル中でも GSI の WCU 値を更新できます。

6. Provisioned Read/Write

  • テーブルまたは指定したグローバルセカンダリインデックスについて、指定した期間に消費された書き込み容量ユニットのプロビジョンド読み取りまたは書き込み容量ユニットの数。

  • デフォルトでは、TableName ディメンションはテーブルのみの ProvisionedReadCapacityUnits を返します。グローバルセカンダリインデックスのプロビジョンド読み取りまたは書き込み容量ユニットの数を表示するには、TableNameGlobalSecondaryIndexName の両方を指定する必要があります。

7. Consumed Read/Write

  • 指定された期間に消費された読み取りまたは書き込み容量ユニットの数。

DynamoDB CloudWatch メトリクスの詳細については、「メトリクスとディメンション」を参照してください。