# DynamoDB のスループットキャパシティ
このセクションでは、DynamoDB テーブルで使用できる 2 つのスループットモードの概要と、アプリケーションに適したキャパシティモードを選択する際の考慮事項について説明します。テーブルのスループットモードによって、テーブルのキャパシティの管理方法が決まります。また、スループットモードによって、テーブルの読み込みおよび書き込みオペレーションに対する課金方法も決まります。Amazon DynamoDB では、さまざまなワークロード要件に対応するために、テーブルの**オンデマンド**モードと**プロビジョンド**モードを使い分けることができます。
**Topics**
+ [オンデマンドモード](#capacity-mode-on-demand)
+ [プロビジョニングモード](#capacity-mode-provisioned)
+ [DynamoDB オンデマンドキャパシティモード](on-demand-capacity-mode.md)
+ [DynamoDB プロビジョンドキャパシティモード](provisioned-capacity-mode.md)
+ [DynamoDB ウォームスループットについて](warm-throughput.md)
+ [DynamoDB バーストキャパシティとアダプティブキャパシティ](burst-adaptive-capacity.md)
+ [DynamoDB でキャパシティモードを切り替える際の考慮事項](bp-switching-capacity-modes.md)
## オンデマンドモード
Amazon DynamoDB オンデマンドモードは、データベース管理を簡素化し、顧客の最も要求の厳しいアプリケーションをサポートするように自動的にスケールするサーバーレススループットオプションです。DynamoDB オンデマンドを使用すると、キャパシティプランニング、使用状況のモニタリング、スケーリングポリシーの設定を気にせずにテーブルを作成できます。DynamoDB オンデマンドは、読み込みおよび書き込みリクエストの料金が従量制であるため、使用した分だけを支払います。オンデマンドモードのテーブルでは、アプリケーションで実行することが予測される読み込みおよび書き込みスループットを指定する必要はありません。
オンデマンドモードは、ほとんどの DynamoDB ワークロードで推奨されるデフォルトのスループットオプションです。DynamoDB は、スループット管理とスケーリングのあらゆる側面を処理し、小規模から始めて 1 秒あたり数百万のリクエストにスケールできるワークロードをサポートします。テーブルのスループットキャパシティを管理することなく、必要に応じて DynamoDB テーブルの読み取りと書き込みを行うことができます。詳細については、「[DynamoDB オンデマンドキャパシティモード](on-demand-capacity-mode.md)」を参照してください。
## プロビジョニングモード
プロビジョンドモードでは、アプリケーションに必要な 1 秒あたりの読み込みと書き込みの回数を指定する必要があります。プロビジョニングしたキャパシティの実際に消費した量ではなく、プロビジョニングした時間単位の読み込みおよび書き込みキャパシティに基づいて課金されます。これにより、コストの予測可能性を得るため、定義されたリクエストレート以下に維持されるように DynamoDB を制御することができます。
予測可能な増加を伴う安定したワークロードがあり、アプリケーションのキャパシティ要件を確実に予測できる場合は、プロビジョンドキャパシティの使用を選択できます。詳細については、「[DynamoDB プロビジョンドキャパシティモード](provisioned-capacity-mode.md)」を参照してください。
# DynamoDB オンデマンドキャパシティモード
Amazon DynamoDB オンデマンドは、キャパシティプランニングを行わずに、最も要求の厳しいワークロードに合わせて自動的にスケールする、真のサーバーレスデータベースエクスペリエンスを提供します。オンデマンドでは、セットアッププロセスを簡素化し、キャパシティの管理とモニタリングを排除し、高速の自動スケーリングを提供します。リクエストごとの支払い料金では、実際に使用したスループットに対してのみ料金を支払うため、アイドル状態のキャパシティについて心配する必要はありません。読み取りまたは書き込みリクエストごとに課金されるため、コストは実際の使用量を直接反映します。
オンデマンドモードを選択すると、DynamoDB は、前に到達したトラフィックレベルまで拡張または縮小して、ワークロードを即座に受け入れることができるようにします。ワークロードのトラフィックレベルが新しいピークに達すると、DynamoDB はスループット要件の増加に合わせて自動的にスケーリングします。オンデマンドモードは、小規模から始めて 1 秒あたり数百万のリクエストにスケールできる最新のサーバーレスアプリケーションの構築を簡素化するため、デフォルトかつ推奨されるスループットオプションです。オンデマンドテーブルをスケールアウトすると、将来的にはスロットリングなしで、同じスループットをすぐに再び達成できます。テーブルへのトラフィックをゼロにする場合、オンデマンドではスループットに対して課金されません。オンデマンドモードのスケーリングプロパティの詳細については、「[初期スループットとスケーリングのプロパティ](#on-demand-capacity-mode-initial)」を参照してください。
オンデマンドモードを使用するテーブルは、同じ 1 桁ミリ秒のレイテンシー、サービスレベルアグリーメント (SLA)、DynamoDB プロビジョンドモードが提供しているセキュリティを実現します。
**注記**
デフォルトでは、DynamoDB は意図しない過剰な使用から保護します。アカウント内のすべてのテーブルでテーブルレベルの読み取りおよび書き込みスループット制限の 40,000 を超えてスケールするには、このクォータの引き上げをリクエストできます。デフォルトのテーブルのスループットクォータを超えるスループットリクエストはスロットリングされます。詳細については、「[スループットのデフォルトクォータ](ServiceQuotas.md#default-limits-throughput)」を参照してください。
オプションで、個別のオンデマンドテーブルやグローバルセカンダリインデックスに対して 1 秒あたりの読み込み/書き込み (またはその両方) の最大スループットを設定することもできます。スループットを設定することで、テーブルレベルの使用量とコストを制限し、不注意によるリソース消費量の急増を防ぎ、過剰な使用をなくして予測可能なコスト管理を行うことができます。テーブルの最大スループットを超えるスループットリクエストはスロットリングされます。テーブル別の最大スループットは、アプリケーションの要件に基づいていつでも変更できます。詳細については、「[オンデマンドテーブルの DynamoDB 最大スループット](on-demand-capacity-mode-max-throughput.md)」を参照してください。
開始するには、オンデマンドモードを使用するテーブルを作成または更新します。詳細については、「[DynamoDB テーブルの基本的なオペレーション](WorkingWithTables.Basics.md)」を参照してください。
24 時間のローリングウィンドウで、テーブルをプロビジョンドキャパシティモードからオンデマンドモードに最大 4 回切り替えることができます。テーブルは、オンデマンドモードからプロビジョンドキャパシティモードにいつでも切り替えることができます。
読み込みおよび書き込みキャパシティモードの詳細については、「[DynamoDB でキャパシティモードを切り替える際の考慮事項](bp-switching-capacity-modes.md)」を参照してください。オンデマンドテーブルクォータについては、「[読み取り/書き込みスループット](ServiceQuotas.md#default-limits-throughput-capacity-modes)」を参照してください。
**Topics**
+ [読み取りリクエスト単位と書き込みリクエスト単位](#read-write-request-units)
+ [初期スループットとスケーリングのプロパティ](#on-demand-capacity-mode-initial)
+ [オンデマンドテーブルの DynamoDB 最大スループット](on-demand-capacity-mode-max-throughput.md)
## 読み取りリクエスト単位と書き込みリクエスト単位
DynamoDB では、アプリケーションがテーブルに対して実行する読み込みと書き込みに対して、読み込みリクエストユニットと書き込みリクエストユニットに基づいて課金します。****
1 つの読み込みリクエストユニットは、最大サイズが 4 KB の項目に対する 1 秒あたり 1 回の強力な整合性のある読み込み、または 1 秒あたり 2 回の結果整合性のある読み込みを表します。**DynamoDB の読み込み整合性モデルの詳細については「[DynamoDB の読み取り整合性](HowItWorks.ReadConsistency.md)」を参照してください。
1 つの書き込みリクエストユニットは、最大サイズが 1 KB の項目に対する 1 秒あたり 1 回の書き込みオペレーションを表します。**
読み込みユニットと書き込みユニットの消費方法の詳細については、「[DynamoDB の読み込みと書き込みのオペレーション](read-write-operations.md)」を参照してください。
## 初期スループットとスケーリングのプロパティ
オンデマンドキャパシティーモードを使用する DynamoDB テーブルは、アプリケーションのトラフィックボリュームに自動的に対応します。新しいオンデマンドテーブルでは、1 秒あたり最大 4,000 回の書き込みと 1 秒あたり最大 12,000 回の読み込みを維持できます。オンデマンドキャパシティーモードは、テーブルにおける前のピークトラフィックの最大 2 倍まで瞬時に対応します。例えば、アプリケーションのトラフィックパターンが 1 秒あたり 25,000～50,000 回の強力な整合性のある読み込みの範囲で変動し、1 秒あたり 50,000 回の読み込みが前回のトラフィックのピークであったとします。オンデマンドキャパシティモードは、1 秒あたり最大 100,000 回の読み込みの持続的なトラフィックに即座に対応します。アプリケーションが 1 秒あたり 100,000 回の読み込みのトラフィックを維持する場合、このピークが新たに前回のピークとなります。この前回のピークにより、後続のトラフィックは 1 秒あたり最大 200,000 回の読み込みに到達できます。
1 つのテーブルで前回のピークの 2 倍を超えるピークがワークロードで発生した場合、DynamoDB は、トラフィックボリュームの増加に合わせて、キャパシティの割り当てを自動的に増加します。このキャパシティの割り当てにより、ワークロードでスロットリングが発生しなくなります。ただし、30 分以内に前のピークの 2 倍を超えた場合、スロットリングが発生する可能性があります。例えば、アプリケーションのトラフィックパターンが 1 秒あたり 25,000～50,000 回の強力な整合性のある読み込みの範囲で変動し、1 秒あたり 50,000 回の読み込みが前回到達したトラフィックのピークであったとします。1 秒あたり 100,000 回を超える読み込みを駆動する前に、テーブルを事前ウォーミングするか、少なくとも 30 分間にわたってトラフィックの増加の間隔を空けることをお勧めします。事前ウォーミングの詳細については、「[DynamoDB ウォームスループットについて](warm-throughput.md)」を参照してください。
ワークロードのピークトラフィックが前のピークの 2 倍以内である場合、DynamoDB は 30 分間のスロットリング制限を行いません。ピークトラフィックが前のピークの 2 倍を超える場合は、前のピークから 30 分後にこの増加が発生することを確認してください。
# オンデマンドテーブルの DynamoDB 最大スループット
オンデマンドテーブルの場合、オプションで、個々のテーブルおよび関連するグローバルセカンダリインデックス (GSI) の 1 秒あたりの読み込みまたは書き込み (または両方) の最大スループットを指定できます。オンデマンドの最大スループットを指定すると、テーブルレベルの使用量とコストを制限できます。デフォルトでは、最大スループットの設定は適用されません。オンデマンドのスループットレートは、アカウント内のすべてのテーブルでテーブルレベルの読み取りおよび書き込みスループットに対する 40,000 の [AWS サービスクォータ](ServiceQuotas.md#default-limits-throughput)によって制限されます。必要に応じて、サービスクォータの引き上げをリクエストできます。
オンデマンドテーブルの最大スループットを設定すると、指定した最大量を超えるスループットリクエストはスロットリングされます。テーブルレベルのスループット設定は、アプリケーションの要件に応じていつでも変更できます。
オンデマンドテーブルの最大スループットを使用することでメリットを得られる一般的なユースケースの例は以下のとおりです。
+ **スループットのコスト最適化** — オンデマンドテーブルの最大スループットを使用すると、コスト予測可能性と管理可能性を高めることができます。さらに、トラフィックパターンと予算が異なるワークロードをサポートするために、オンデマンドモードを使用する柔軟性も高まります。
+ **過剰な使用からの保護** – 最大スループットを設定することで、オンデマンドテーブルに対する最適化されていないコードや不正なプロセスに伴う読み込みや書き込みの消費量の偶発的な急増を防止できます。このテーブルレベルの設定により、組織は特定の期間にわたる過剰なリソースの消費を防止できます。
+ **ダウンストリームサービスの保護** — 顧客アプリケーションには、サーバーレステクノロジーと非サーバーレステクノロジーを含めることができます。サーバーレスアーキテクチャは、需要に合わせて迅速にスケールできます。ただし、固定キャパシティを持つダウンストリームコンポーネントでは、対応できなくなる場合があります。オンデマンドテーブルに最大スループット設定を実装すると、複数のダウンストリームコンポーネントに対する大量のイベントの伝播に伴う予期しない副作用を防止できます。
オンデマンドモードの最大スループットは、新規および既存の単一リージョンのテーブル、グローバルテーブル、GSI に対して設定できます。最大スループットは、Amazon S3 ワークフローからのテーブルの復元時とデータのインポート時にも設定できます。
オンデマンドテーブルの最大スループット設定を指定するには、[DynamoDB コンソール](https://console.aws.amazon.com/dynamodb/)、[AWS CLI](AccessingDynamoDB.md#Tools.CLI)、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html)、または [DynamoDB API](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/Welcome.html) を使用できます。
**注記**
オンデマンドテーブルの最大スループットは、ベストエフォートベースで適用されるため、保証されたリクエストの上限としてではなく、目標として考える必要があります。[バーストキャパシティ](burst-adaptive-capacity.md#burst-capacity)により、ワークロードが、指定した最大スループットを一時的に超える場合があります。**場合によっては、DynamoDB がバーストキャパシティを使用して、テーブルの最大スループット設定を超える読み込みや書き込みに対応します。**バーストキャパシティーにより、スロットリングされていた可能性のある読み込みまたは書き込みリクエストが成功します。
**Topics**
+ [オンデマンドモードの最大スループットを使用する際の考慮事項](#consideration-use-max-throughput-ondemand)
+ [リクエストのスロットリングと CloudWatch メトリクス](#max-throughput-ondemand-request-throttle)
## オンデマンドモードの最大スループットを使用する際の考慮事項
オンデマンドモードでテーブルの最大スループットを使用する場合、次の考慮事項が適用されます。
+ オンデマンドテーブルまたはテーブル内のグローバルセカンダリインデックスごとに読み込みと書き込みの最大スループットを個別に設定し、特定の要件に基づいてアプローチを微調整できます。
+ Amazon CloudWatch を使用して、DynamoDB テーブルレベルの使用状況メトリクスをモニタリングおよび把握し、オンデマンドモードの適切な最大スループット設定を決定できます。詳細については、「[DynamoDB のメトリクスとディメンション](metrics-dimensions.md)」を参照してください。
+ 1 つのグローバルテーブルレプリカで読み込みや書き込み (または両方) の最大スループット設定を指定すると、同じ最大スループット設定がすべてのレプリカテーブルに自動的に適用されます。データが適切にレプリケートされるように、グローバルテーブル内のレプリカテーブルとセカンダリインデックスの書き込みスループット設定が同じであることが重要です。詳細については、「[グローバルテーブルのベストプラクティス](globaltables-bestpractices.md)」を参照してください。
+ 読み込みまたは書き込みの最大スループットとして指定できる最小値は、1 秒あたり 1 つのリクエストユニットです。
+ 指定する最大スループットは、オンデマンドテーブルまたはテーブル内の個別のグローバルセカンダリインデックスで使用できるデフォルトのスループットクォータより小さくする必要があります。
## リクエストのスロットリングと CloudWatch メトリクス
アプリケーションがオンデマンドテーブルに設定した読み込みまたは書き込みの最大スループットを超えると、DynamoDB はリクエストのスロットリングを開始します。DynamoDB は、読み込みや書き込みをスロットリングすると、発信者に `ThrottlingException` を返します。その後、必要に応じて適切なアクションを実行できます。例えば、テーブルの最大スループット設定を増加または無効化したり、リクエストを再試行する前に短い間待ったりできます。
テーブルまたはグローバルセカンダリインデックスに設定した最大スループットのモニタリングを簡素化するために、CloudWatch はメトリクスとして [OnDemandMaxReadRequestUnits](metrics-dimensions.md#OnDemandMaxReadRequestUnits) と [OnDemandMaxWriteRequestUnits](metrics-dimensions.md#OnDemandMaxWriteRequestUnits) を提供しています。
# DynamoDB プロビジョンドキャパシティモード
Amazon DynamoDB で新しいプロビジョンドテーブルを作成する場合は、テーブルの*プロビジョンドスループットキャパシティ*を指定する必要があります。これは、テーブルがサポートできる読み込みおよび書き込みスループットの量です。プロビジョニングしたキャパシティの実際に消費した量ではなく、プロビジョニングした時間単位の読み込みおよび書き込みキャパシティに基づいて課金されます。
アプリケーションのデータとアクセス要件が変わると、テーブルのスループット設定の調整が必要になる場合があります。Auto Scaling を使用すると、トラフィックの変更に応じて、テーブルのプロビジョンドキャパシティーを自動的に調整できます。DynamoDB 自動スケーリングは、[Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) で[スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)を使用します。DynamoDB で自動スケーリングを設定するには、ターゲット使用率に加えて、読み取りおよび書き込みキャパシティの最小レベルと最大レベルを設定します。Application Auto Scaling は、メトリクスとターゲットから逸脱したときにスケーリングイベントをトリガーする CloudWatch アラームを作成および管理します。Auto Scaling は、テーブルのアクティビティをモニタリングし、事前設定されたしきい値に基づいてキャパシティ設定を調整します。消費されたキャパシティが、設定したターゲット使用率を 2 分間連続して超過すると、自動スケーリングがトリガーされます。CloudWatch アラームは、自動スケーリングをトリガーする前に、最大数分の短い遅延を伴う場合があります。詳細については、「[DynamoDB Auto Scaling によるスループットキャパシティの自動管理](AutoScaling.md)」を参照してください。
DynamoDB Auto Scaling を使用している場合、スループット設定は実際のワークロードに応じて自動的に調整されます。[UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) オペレーションを使用して、テーブルのスループットキャパシティを手動で調整することもできます。例えば、既存のデータストアから新しい DynamoDB テーブルにデータをバルクロードする必要がある場合などに便利です。大容量の書き込みスループットを設定したテーブルを作成し、データのバルクロードが完了してからこの設定を削減ですることができます。
**注記**
デフォルトでは、DynamoDB は意図しない過剰な使用から保護します。アカウント内のすべてのテーブルでテーブルレベルの読み取りおよび書き込みスループット制限の 40,000 を超えてスケールするには、このクォータの引き上げをリクエストできます。デフォルトのテーブルのスループットクォータを超えるスループットリクエストはスロットリングされます。詳細については、「[スループットのデフォルトクォータ](ServiceQuotas.md#default-limits-throughput)」を参照してください。
24 時間のローリングウィンドウで、テーブルをプロビジョンドキャパシティモードからオンデマンドモードに最大 4 回切り替えることができます。テーブルは、オンデマンドモードからプロビジョンドキャパシティモードにいつでも切り替えることができます。
読み込みおよび書き込みキャパシティモードの詳細については、「[DynamoDB でキャパシティモードを切り替える際の考慮事項](bp-switching-capacity-modes.md)」を参照してください。
**Topics**
+ [読み取りキャパシティユニットと書き込みキャパシティユニット](#read-write-capacity-units)
+ [初期スループット設定の選択](#choosing-initial-throughput)
+ [DynamoDB 自動スケーリング](#ddb-autoscaling)
+ [DynamoDB Auto Scaling によるスループットキャパシティの自動管理](AutoScaling.md)
+ [DynamoDB リザーブドキャパシティ](reserved-capacity.md)
## 読み取りキャパシティユニットと書き込みキャパシティユニット
プロビジョンドモードテーブルでは、スループット要件を*キャパシティユニット*の数で指定します。キャパシティユニットは、アプリケーションが 1 秒あたりに読み込みまたは書き込みを行う必要があるデータの量を表します。これらの設定は必要に応じて後から変更できます。また、DynamoDB Auto Scaling を有効化して自動的に変更することもできます。
最大サイズ 4 KB の項目の場合、1 つの読み込みキャパシティユニット (RCU) は、1 秒あたり 1 回の強力な整合性のある読み込み、または 1 秒あたり 2 回の結果整合性のある読み込みを表します。**DynamoDB の読み込み整合性モデルの詳細については「[DynamoDB の読み取り整合性](HowItWorks.ReadConsistency.md)」を参照してください。
1 つの書き込みキャパシティユニット (WCU) は、最大サイズが 1 KB の項目の場合、1 秒あたり 1 回の書き込みを表します。**さまざまな読み込みおよび書き込みオペレーションの詳細については、「[DynamoDB の読み込みと書き込みのオペレーション](read-write-operations.md)」を参照してください。
## 初期スループット設定の選択
アプリケーションごとにデータベースの読み込みおよび書き込みの要件は異なります。DynamoDB テーブルの初期スループット設定を決定する際は、以下の点を考慮してください。
+ **予想される読み込みおよび書き込みリクエストレート** — 1 秒あたりに実行する必要がある読み込みおよび書き込みの数を推定する必要があります。
+ **項目のサイズ** — 一部の項目は小さいため、読み込みや書き込みには 1 つのキャパシティユニットを使用できます。項目のサイズが大きくなると、複数のキャパシティーユニットが必要になります。テーブルに追加する項目の平均サイズを見積もることで、テーブルのプロビジョニングされたスループットに対する正確な設定を指定できます。
+ **読み込みの整合性要件** — 読み込みキャパシティユニットは、強力な整合性のある読み込みオペレーションに基づいており、結果整合性のある読み込みの 2 倍のデータベースリソースを消費します。アプリケーションが強力な整合性のある読み込みを要求するか、またはこの要件を緩和して結果的に整合性のある読み込み行うかどうかを決定する必要があります DynamoDB での読み込みオペレーションは、デフォルトでは結果整合性のある読み込みです。必要に応じて、これらのオペレーションに強力な整合性のある読み込みをリクエストできます。
例えば、テーブルから 1 秒あたり 80 項目を読み込むとします。項目のサイズは 3 KB で、強力な整合性のある読み込みが必要です。このシナリオでは、読み込みごとに 1 つのプロビジョニングされた読み込みキャパシティユニットが必要です。この数を決定するには、オペレーションの項目サイズを 4 KB で割ります。次に、以下の例に示すように、最も近い整数に切り上げます。
+ 3 KB / 4 KB = 0.75、または **1** つの読み込みキャパシティユニット
したがって、テーブルから 1 秒あたり 80 項目を読み込むには、次の例に示すように、テーブルのプロビジョニングされた読み込みスループットを 80 個の読み込みキャパシティユニットに設定します。
+ 1 読み込み容量単位/項目 x 80 読み込み/秒 = **80** 読み込み容量単位
次に、テーブルに 1 秒あたり 100 項目を書き込み、各項目のサイズが 512 バイトであるとします。この場合、書き込みごとに 1 つのプロビジョニングされた書き込みキャパシティユニットが必要です。この数を決定するには、オペレーションの項目サイズを 1 KB で割ります。次の例に示すように、結果を最も近い整数に切り上げます。
+ 512 バイト/1 KB = 0.5 または **1** つの書き込みキャパシティユニット
テーブルに 1 秒あたり 100 項目を書き込むには、テーブルのプロビジョニングされた書き込みスループットを 100 個の書き込みキャパシティユニットに設定します。
+ 1 書き込み容量単位/項目 x 100 書き込み/秒 = **100** 書き込み容量単位
## DynamoDB 自動スケーリング
DynamoDB 自動スケーリングでは、テーブルとグローバルセカンダリインデックスのプロビジョニングされたスループットキャパシティを自動的に管理します。読み込みおよび書き込みのキャパシティーユニットの範囲 (上限と下限) と、また、その範囲内で目標使用率を定義します。DynamoDB Auto Scaling では、アプリケーションのワークロードが増減しても、ターゲットの使用率が維持されます。
DynamoDB Auto Scaling では、急激なトラフィック増加をリクエストのスロットリングなしに処理するために、テーブルまたはグローバルセカンダリインデックスのプロビジョンされた読み込み容量と書き込み容量を増やすことができます。ワークロードが減ると、DynamoDB Auto Scaling はスループットを低下させ、未使用のプロビジョンされた容量に料金が発生しないようにします。
**注記**
AWS マネジメントコンソール を使用してテーブルまたはグローバルセカンダリインデックスを作成すると、デフォルトで DynamoDB オートスケーリングが有効になります。
Auto Scaling の設定は、コンソール、AWS CLI、またはいずれかの AWS SDK を使用していつでも管理できます。詳細については、「[DynamoDB Auto Scaling によるスループットキャパシティの自動管理](AutoScaling.md)」を参照してください。
### 使用率
使用率は、プロビジョニングキャパシティを超過しているかどうかを判断するのに役立ちます。超過している場合は、テーブルのキャパシティを減らしてコストを削減する必要があります。逆に、プロビジョニングキャパシティを下回っているかどうかを判断するのにも役立ちます。この場合、予期しないトラフィック増によりリクエストがスロットリングされる可能性を防ぐため、テーブルのキャパシティを増やす必要があります。詳細については、「[Amazon DynamoDB auto scaling: Performance and cost optimization at any scale](https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/)」を参照してください。
DynamoDB 自動スケーリングを使用している場合は、ターゲット使用率も設定する必要があります。自動スケーリングでは、この使用率をターゲットとして使用し、キャパシティを上下に調整します。ターゲット使用率は 70% に設定することをお勧めします。詳細については、「[DynamoDB Auto Scaling によるスループットキャパシティの自動管理](AutoScaling.md)」を参照してください。
# DynamoDB Auto Scaling によるスループットキャパシティの自動管理
多くのデータベースワークロードは本質的に循環的なものであり、前もって予測することが困難なものもあります。例えば、日中の時間帯に大部分のユーザーがアクティブなソーシャルネットワーキングアプリがあるとします。データベースは日中のアクティビティを処理できる必要がありますが、夜間のスループットに同じレベルは必要ありません。別の例としては、予想以上に急速に普及した新しいモバイルゲームアプリが挙げられます。ゲームがあまりに人気になると、利用可能なデータベースリソースを超過し、パフォーマンスが低下して顧客が不満を感じるようになります。この種のワークロードでは多くの場合、手動介入によってデータベースリソースを使用レベルに応じて上下させる必要があります。
Amazon DynamoDB Auto Scaling は AWS Application Auto Scaling サービスを使用し、実際のトラフィックパターンに応じてプロビジョンドスループット性能をユーザーに代わって動的に調節します。これにより、テーブルまたはグローバルセカンダリインデックス (GSI) では、読み取りと書き込みのプロビジョンドキャパシティを増やし、スロットリングなしでトラフィックの急増に対処できます。ワークロードが減ると、Application Auto Scaling はスループットを低下させ、未使用のプロビジョンされた容量に料金が発生しないようにします。
**注記**
AWS マネジメントコンソール を使用してテーブルまたはグローバルセカンダリインデックスを作成すると、デフォルトで DynamoDB Auto Scaling が有効になります。Auto Scaling の設定はいつでも変更できます。詳細については、「[AWS マネジメントコンソール と DynamoDB Auto Scaling の使用](AutoScaling.Console.md)」を参照してください。
テーブルまたはグローバルテーブルレプリカを削除しても、関連するスケーラブルターゲット、スケーリングポリシー、または CloudWatch アラームが共に自動的に削除されることはありません。
Application Auto Scaling を使用して、テーブルまたはグローバルセカンダリインデックスの*スケーリングポリシー*を作成します。スケーリングポリシーは、テーブルまたはインデックスの読み込みキャパシティまたは書き込みキャパシティ (またはその両方) およびプロビジョニングされたキャパシティユニット設定をスケーリングするかどうかを指定します。
スケーリングポリシーには、*ターゲット使用率* (ある時点で消費したプロビジョン済みスループットの割合) も含まれます。Application Auto Scaling は*のターゲット追跡*アルゴリズムを使用して、実際のワークロードに応じてテーブル (インデックス) のプロビジョンスループットを上下に調整することで、実際の容量使用率がターゲット使用率に、またはその近くに留まるようにします。
DynamoDB は、消費されたプロビジョンドスループットを 1 分間出力します。消費されたキャパシティが、設定したターゲット使用率を 2 分間連続して超過すると、自動スケーリングがトリガーされます。CloudWatch アラームは、自動スケーリングをトリガーする前に、最大数分の短い遅延を伴う場合があります。この遅延により、CloudWatch メトリクスの正確な評価が保証されます。消費されたスループットのスパイク間隔が 1 分を超えると、自動スケーリングはトリガーされない場合があります。同様に、15 個の連続するデータポイントがターゲット使用率を下回ると、スケールダウンイベントが発生する場合があります。いずれの場合も、自動スケーリングのトリガー後に、[UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) API が呼び出されます。テーブルやインデックスのプロビジョンドキャパシティの更新には、数分かかる場合があります。この間に、テーブルの前のプロビジョンドキャパシティを超えるリクエストはスロットリングされます。
**重要**
侵害するデータポイントの数を調整して、基礎となるアラームをトリガーすることはできません (ただし、現在の数は将来変更される可能性があります)。
読み取りおよび書き込み容量に対して、Auto Scaling ターゲット使用率の値を 20% から 90% の間で設定できます。
**注記**
テーブルに加え、DynamoDB Auto Scaling はグローバルセカンダリインデックスもサポートします。すべてのグローバルセカンダリインデックスは、基本テーブルとは別に、固有のプロビジョンドスループット性能を持ちます。グローバルセカンダリインデックスのスケーリングポリシーを作成すると、Application Auto Scaling がインデックスのプロビジョンされたスループット設定を調整し、実際の使用率がターゲット使用率と同じか近い値で維持されるようになります。
## DynamoDB Auto Scaling の仕組み
**注記**
DynamoDB Auto Scaling の簡単な使用方法については、[AWS マネジメントコンソール と DynamoDB Auto Scaling の使用](AutoScaling.Console.md) を参照してください。
次の図表は、DynamoDB Auto Scaling によるテーブルのスループットキャパシティの管理方法について、高レベルの概要を示しています。
![\[DynamoDB Auto Scaling は、需要に合わせてテーブルのスループットキャパシティを調整します。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/auto-scaling.png)
次のステップは、前の図に示された Auto Scaling のプロセスをまとめたものです。
1. DynamoDB テーブルの Application Auto Scaling ポリシーを作成します。
1. DynamoDB は、消費された容量メトリクスを Amazon CloudWatch に公開します。
1. テーブルの消費された容量が一定期間中にターゲット使用率を超える（または下回る）と、Amazon CloudWatch はアラームをトリガーします。コンソールでアラームを表示し、Amazon Simple Notification Service (Amazon SNS) を使用して通知を受け取ることができます。
1. CloudWatch アラームは、Application Auto Scaling をコールしてスケーリングポリシーを評価します。
1. Application Auto Scaling は `UpdateTable` リクエストを発行し、テーブルのプロビジョンされたスループットを調整します。
1. DynamoDB は `UpdateTable` リクエストを処理してテーブルのプロビジョンドスループット性能を動的に増減し、ターゲット使用率に近づけます。
DynamoDB Auto Scaling の仕組みを理解するため、`ProductCatalog` という名前のテーブルがあると仮定します。テーブルにはまれにデータがバルクロードされます。そのため、書き込みアクティビティが頻繁に生じることはありません。ただし、時間で変化する高度な読み込みアクティビティが生じています。`ProductCatalog` の Amazon CloudWatch メトリクスをモニタリングすることにより、テーブルに 1,200 ユニットの読み込み容量が必要である (アクティビティのピーク時に DynamoDB が読み込みリクエストをスロットリングしないため) と判断します。さらに、読み込みトラフィックが最も低い時点で、`ProductCatalog` には最少で 150 ユニットの読み込みキャパシティが必要です。スロットリングの防止の詳細については、「[Amazon DynamoDB でのスロットリングのトラブルシューティング](TroubleshootingThrottling.md)」を参照してください。
読み込みキャパシティ 150～1,200 ユニットの範囲内で、`ProductCatalog` に適したターゲット使用率 70% を決定します。*ターゲット使用率*は、プロビジョンされた容量単位に対して消費された容量単位の割合がパーセンテージで示されます。Application Auto Scaling は、ターゲット追跡アルゴリズムを使用して、`ProductCatalog` のプロビジョンされた読み込み容量が必要に応じて調整され、使用率が 70% またはその近くに留まるようにします。
**注記**
DynamoDB Auto Scaling は、実際のワークロードの増減が数分間維持された場合にのみ、プロビジョンされたスループット設定を変更します。アプリケーションオートスケーリングターゲット追跡アルゴリズムはターゲット使用率を選択した値の付近に長期に渡って維持しようとします。
アクティビティの急激かつ短時間の上昇は、テーブルに組み込まれたバーストキャパシティで対応されます。詳細については、「[バーストキャパシティ](burst-adaptive-capacity.md#burst-capacity)」を参照してください。
`ProductCatalog` テーブルの DynamoDB Auto Scaling を有効にするには、スケーリングポリシーを作成します。このポリシーでは、以下を指定します。
+ 管理するテーブルまたはグローバルセカンダリインデックス
+ 管理するキャパシティタイプ (読み込みキャパシティまたは書き込みキャパシティ)
+ プロビジョニングされたスループット設定の上下の境界
+ ターゲット使用率
スケーリングポリシーを作成すると、Application Auto Scaling はユーザーに代わって Amazon CloudWatch アラームのペアを作成します。各ペアはプロビジョニングされたスループット設定の上下の境界を示します。CloudWatch アラームは、テーブルの実際の使用率が一定期間ターゲット使用率を逸脱したときにトリガーされます。
いずれかの CloudWatch アラームがトリガーされると、Amazon SNS は通知を送信します (有効にしている場合)。その後 CloudWatch アラームは Application Auto Scaling をコールし、`ProductCatalog` テーブルのプロビジョン容量を必要に応じて調整するように DynamoDB に通知します。
スケーリングイベント中、AWS Config は記録された設定項目ごとに課金されます。スケーリングイベントが発生すると、読み取り/書き込み自動スケーリングイベントごとに 4 つの CloudWatch アラームが作成されます。ProvisionedCapacity アラーム: ProvisionedCapacityLow、ProvisionedCapacityHigh、および ConsumedCapacity アラーム: AlarmHigh、AlarmLow です。その結果、合計 8 つのアラームが生成されます。そのため、AWS Config は、スケーリングイベントごとに 8 つの設定項目を記録します。
**注記**
また、DynamoDB のスケーリングを特定の時間に実行するようにスケジュールすることもできます。基本的な手順については、[こちら](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html)を参照してください。
## 使用に関する注意事項
DynamoDB Auto Scaling の使用を開始する前に、以下を確認する必要があります。
+ DynamoDB Auto Scaling は、自動スケーリングポリシーに従って、読み込み容量や書き込み容量を必要に応じて増加させます。[Amazon DynamoDB のクォータ](ServiceQuotas.md) で説明されているように、すべての DynamoDB クォータは有効です。
+ DynamoDB Auto Scaling により、プロビジョンされたスループット設定を手動で変更できなくなることはありません。これらの手動調整が、DynamoDB Auto Scaling に関連する既存の CloudWatch アラームに影響することはありません。
+ 1 つ以上のグローバルセカンダリインデックスを持つテーブルの DynamoDB Auto Scaling を有効にする場合、これらのインデックスに Auto Scaling を均等に適用することをお勧めします。これにより、テーブルの書き込みと読み取りのパフォーマンスが向上し、スロットリングを回避できます。 auto scaling を有効にするには、AWS マネジメントコンソール で **[Apply same settings to global secondary indexes]** (グローバルセカンダリインデックスに同じ設定を適用する) を選択します。詳細については、「[既存のテーブルでの DynamoDB Auto Scaling の有効化](AutoScaling.Console.md#AutoScaling.Console.ExistingTable)」を参照してください。
+ テーブルまたはグローバルテーブルレプリカを削除しても、関連するスケーラブルターゲット、スケーリングポリシー、または CloudWatch アラームが共に自動的に削除されることはありません。
+ 既存のテーブルの GSI を作成する場合、その GSI の Auto Scaling は有効になりません。GSI を構築している間は、容量を手動で管理する必要があります。GSI のバックフィルが完了し、アクティブステータスに達すると、Auto Scaling は通常どおり動作します。
# AWS マネジメントコンソール と DynamoDB Auto Scaling の使用
AWS マネジメントコンソール を使用して新しいテーブルを作成すると、Amazon DynamoDB Auto Scaling はデフォルトでそのテーブルに対して有効になります。コンソールを使用して、既存テーブルの Auto Scaling の有効化、Auto Scaling 設定の変更、Auto Scaling の無効化を行うこともできます。
**注記**
スケールインおよびスケールアウトのクールダウン時間の設定など、より高度な特徴については、AWS Command Line Interface (AWS CLI) を使用して DynamoDB Auto Scaling を管理します。詳細については、「[AWS CLI を使用した DynamoDB Auto Scaling の管理](AutoScaling.CLI.md)」を参照してください。
**Topics**
+ [開始する前に: DynamoDB Auto Scaling のアクセス許可をユーザーに付与する](#AutoScaling.Permissions)
+ [Auto Scaling を有効にした新しいテーブルの作成](#AutoScaling.Console.NewTable)
+ [既存のテーブルでの DynamoDB Auto Scaling の有効化](#AutoScaling.Console.ExistingTable)
+ [コンソールでの Auto Scaling アクティビティの表示](#AutoScaling.Console.ViewingActivities)
+ [DynamoDB Auto Scaling 設定の変更または無効化](#AutoScaling.Console.Modifying)
## 開始する前に: DynamoDB Auto Scaling のアクセス許可をユーザーに付与する
AWS Identity and Access Management (IAM) の場合、AWS マネージドポリシー `DynamoDBFullAccess` は、DynamoDB コンソールを使用するために必要なアクセス許可を提供します。ただし、DynamoDB Auto Scaling の場合、ユーザーには追加アクセス許可が必要です。
**重要**
自動スケーリング対応のテーブルを削除するには、`application-autoscaling:*` アクセス許可が必要です。AWS マネージドポリシー `DynamoDBFullAccess` には、必要なアクセス許可が含まれています。
DynamoDB コンソールアクセスと DynamoDB Auto Scaling 用にユーザーを設定するには、ロールを作成し、そのロールに **AmazonDynamoDBFullAccess** ポリシーを追加します。次に、ロールをユーザーに割り当てます。
## Auto Scaling を有効にした新しいテーブルの作成
**注記**
DynamoDB Auto Scaling では、ユーザーに代わって Auto Scaling アクションを実行する、サービスリンクロール (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) の存在を必要とします。このロールは自動的に作成されます。詳細については、「Application Auto Scaling ユーザーガイド」の「[Application Auto Scaling 用のサービスリンクロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。**
**Auto Scaling を有効にして新しいテーブルを作成するには**
1. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/) で DynamoDB コンソールを開きます。
1. [**Create table**] を選択します。
1. **[テーブルを作成]** ページで、**テーブル名**とプライマリキーの詳細を入力します。
1. **[デフォルト設定]** を選択すると、新しいテーブルで自動スケーリングが有効になります。
それ以外の場合は、**[設定をカスタマイズ]** を選択し、以下の操作を実行してテーブルのカスタム設定を指定します。
1. **[テーブルクラス]** で、デフォルト設定である **[DynamoDB 標準]** を選択したままにします。
1. **[読み取り/書き込みキャパシティーの設定]** で、デフォルト設定の **[プロビジョンド]** を選択したままにして、以下の操作を行います。
1. **[読み取りキャパシティー]** で、**[自動スケーリング]** が **[オン]** に設定されていることを確認します。
1. **[書き込みキャパシティー]** で、**[自動スケーリング]** が **[オン]** に設定されていることを確認します。
1. **[読み取りキャパシティー]** と **[書き込みキャパシティー]** で、テーブルに必要なスケーリングポリシーと、オプションでテーブルのすべてのグローバルセカンダリインデックスを設定します。
+ **最小キャパシティーユニット** - Auto Scaling 範囲の下限を入力します。
+ **最大キャパシティーユニット** - Auto Scaling 範囲の上限を入力します。
+ **ターゲット使用率** — テーブルの目標使用率を入力します。
**注記**
新しいテーブルのグローバルセカンダリインデックスを作成する場合、作成時のインデックスの容量は、ベーステーブルの容量と同じになります。インデックスの容量は、テーブルの作成後にテーブルの設定で変更できます。
1. **[テーブルの作成]** を選択します。これにより、指定した自動スケーリングパラメータを使用してテーブルが作成されます。
## 既存のテーブルでの DynamoDB Auto Scaling の有効化
**注記**
DynamoDB Auto Scaling では、ユーザーに代わって Auto Scaling アクションを実行する、サービスリンクロール (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) の存在を必要とします。このロールは自動的に作成されます。詳細については、「[Application Auto Scaling 用のサービスリンクロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。
**既存のテーブルに対して DynamoDB Auto Scaling を有効にするには**
1. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/) で DynamoDB コンソールを開きます。
1. コンソールの左側のナビゲーションペインで、[**テーブル**] を選択します。
1. 自動スケーリングを有効にするテーブルを選択し、以下の操作を行います。
1. **[追加の設定]** タブを選択します。
1. **[読み取りキャパシティー]** セクションで、**[編集]** を選択します。
1. **[キャパシティーモード]** セクションで、**[プロビジョンド]** を選択します。
1. **[テーブルのキャパシティー]** セクションで、**[読み込みキャパシティー]**、**[書き込みキャパシティー]**、または両方に対して、**[自動スケーリング]** を **[オン]** に設定します。これらのそれぞれについて、テーブルに必要なスケーリングポリシーを設定し、オプションでテーブルのすべてのグローバルセカンダリインデックスを設定します。
+ **最小キャパシティーユニット** - Auto Scaling 範囲の下限を入力します。
+ **最大キャパシティーユニット** - Auto Scaling 範囲の上限を入力します。
+ **ターゲット使用率** — テーブルの目標使用率を入力します。
+ **[すべてのグローバルセカンダリインデックスに同じキャパシティー読み取り/書き込みキャパシティー設定を使用する]** - グローバルセカンダリインデックスがベーステーブルと同じ Auto Scaling ポリシーを使用するかどうかを選択します。
**注記**
最高のパフォーマンスを実現するには、[**すべてのグローバルセカンダリインデックスに同じ読み取り/書き込み容量設定を適用する**] を有効にすることをお勧めします。このオプションを使用すれば、DynamoDB Auto Scaling は、ベーステーブル上のすべてのグローバルセカンダリインデックスを均一にスケーリングできます。これには、既存のグローバルセカンダリインデックスと、将来このテーブル用に作成するその他のインデックスが含まれます。
このオプションを有効にすると、個々のグローバルセカンダリインデックスにスケーリングポリシーを設定できなくなります。
1. すべての設定が正しいことを確認したら、[**保存**] を選択します。
## コンソールでの Auto Scaling アクティビティの表示
アプリケーションがテーブルへの読み込みおよび書き込みトラフィックを送ると、DynamoDB Auto Scaling はテーブルのスループット設定を動的に変更します。Amazon CloudWatch は、すべての DynamoDB テーブルとセカンダリインデックスについて、プロビジョニングされた容量、消費された容量、スロットルイベント、レイテンシー、およびその他のメトリクスを追跡します。
DynamoDB コンソールでこれらのメトリクスを表示するには、操作するテーブルを選択し、**[モニタリング]** タブを選択します。テーブルメトリクスのカスタマイズ可能なビューを作成するには、[**CloudWatch ですべてを表示**] を選択します。
## DynamoDB Auto Scaling 設定の変更または無効化
AWS マネジメントコンソール を使用して、DynamoDB Auto Scaling 設定を変更できます。これを行うには、テーブルの **[追加設定]** タブに移動し、**[読み取り/書き込みキャパシティー]** セクションで **[編集]** を選択します。これらの設定の詳細については、「[既存のテーブルでの DynamoDB Auto Scaling の有効化](#AutoScaling.Console.ExistingTable)」をご参照ください。
# AWS CLI を使用した DynamoDB Auto Scaling の管理
AWS マネジメントコンソール を使用する代わりに、AWS Command Line Interface (AWS CLI) を使用して、Amazon DynamoDB Auto Scaling を管理できます。このセクションのチュートリアルでは、DynamoDB Auto Scaling を管理するために AWS CLI をインストールして設定する方法を示します。このチュートリアルでは、以下の作業を行います。
+ `TestTable` という DynamoDB テーブルの作成 初期スループット設定では、読み込み容量単位数が 5、書き込み容量単位が 5 です。
+ `TestTable` 用アプリケーションの Auto Scaling ポリシーを作成します。このポリシーでは、プロビジョニングされた書き込みキャパシティに対する消費された書き込みキャパシティの割合を 50% に維持することを目指します。このメトリクスの範囲は 5～10 書き込みキャパシティユニットです。(Application Auto Scaling では、この範囲を超えるスループットを調整することはできません)。
+ Python プログラムを実行して、書き込みトラフィックを `TestTable` に送ります。目標比率が一定期間 50% を超えると、Application Auto Scaling は DynamoDB に通知して `TestTable` のスループットを上方に調整して、50% の目標使用率を維持します。
+ DynamoDB が `TestTable` のプロビジョンされた書き込み容量を正常に調整したことを確認します。
**注記**
また、DynamoDB のスケーリングを特定の時間に実行するようにスケジュールすることもできます。基本的な手順については、[こちら](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html)を参照してください。
**Topics**
+ [開始する前に](#AutoScaling.CLI.BeforeYouBegin)
+ [ステップ 1: DynamoDB テーブルを作成する](#AutoScaling.CLI.CreateTable)
+ [ステップ 2: スケーラブルなターゲットを登録する](#AutoScaling.CLI.RegisterScalableTarget)
+ [ステップ 3: スケーリングポリシーを作成する](#AutoScaling.CLI.CreateScalingPolicy)
+ [ステップ 4: 書き込みトラフィックを TestTable に送る](#AutoScaling.CLI.DriveTraffic)
+ [ステップ 5: Application Auto Scaling アクションを表示する](#AutoScaling.CLI.ViewCWAlarms)
+ [(オプション) ステップ 6: クリーンアップする](#AutoScaling.CLI.CleanUp)
## 開始する前に
チュートリアルを開始する前に、以下のタスクを完了します。
### AWS CLI をインストールする
まだ AWS CLI をインストールして設定していない場合は、インストールして設定する必要があります。これを行うには、*AWS Command Line Interface のユーザーガイド*の手順に従います。
+ [ のインストールAWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ [ の設定AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)
### Python のインストール
このチュートリアルの一部では、Python プログラムを実行する必要があります ([ステップ 4: 書き込みトラフィックを TestTable に送る](#AutoScaling.CLI.DriveTraffic) を参照)。まだインスタンスしていない場合は、[Python をダウンロード](https://www.python.org/downloads)できます。
## ステップ 1: DynamoDB テーブルを作成する
このステップでは、AWS CLI を使用して `TestTable` を作成します。プライマリキーは、`pk` (パーティションキー) と `sk` (ソートキー) で構成されます。これらの属性はいずれも、`Number` 型になります。初期スループット設定では、読み込み容量単位数が 5、書き込み容量単位が 5 です。
1. 以下の AWS CLI コマンドを使用してターゲットを作成します。
```
aws dynamodb create-table \
--table-name TestTable \
--attribute-definitions \
AttributeName=pk,AttributeType=N \
AttributeName=sk,AttributeType=N \
--key-schema \
AttributeName=pk,KeyType=HASH \
AttributeName=sk,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5
```
1. テーブルのステータスを確認するには、次のコマンドを使用します。
```
aws dynamodb describe-table \
--table-name TestTable \
--query "Table.[TableName,TableStatus,ProvisionedThroughput]"
```
ステータスが `ACTIVE` になったら、テーブルは使用できる状態になります。
## ステップ 2: スケーラブルなターゲットを登録する
次に、Application Auto Scaling を使用して、テーブルの書き込み容量をスケーラブルなターゲットとして登録します。これにより、Application Auto Scaling は、*TestTable* にプロビジョンされた書き込み容量を調整できますが、容量単位は 5～10 の範囲内に限られます。
**注記**
DynamoDB Auto Scaling では、ユーザーに代わって Auto Scaling アクションを実行する、サービスリンクロール (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) の存在を必要とします。このロールは自動的に作成されます。詳細については、*Application Auto Scaling ユーザーガイド*の「[Application Auto Scaling のサービスにリンクされたロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)」を参照してください。
1. 次のコマンドを入力して、スケーラブルなターゲットを登録します。
```
aws application-autoscaling register-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--min-capacity 5 \
--max-capacity 10
```
1. 次のコマンドを使用して登録を確認します。
```
aws application-autoscaling describe-scalable-targets \
--service-namespace dynamodb \
--resource-id "table/TestTable"
```
**注記**
グローバルセカンダリインデックスに対してスケーラブルターゲットを登録することもできます。たとえば、グローバルセカンダリインデックス (「test-index」) の場合、リソース ID とスケーラブルディメンションの引数は適切に更新されます。
```
aws application-autoscaling register-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable/index/test-index" \
--scalable-dimension "dynamodb:index:WriteCapacityUnits" \
--min-capacity 5 \
--max-capacity 10
```
## ステップ 3: スケーリングポリシーを作成する
このステップでは、`TestTable` のスケーリングポリシーを作成します。ポリシーでは、Application Auto Scaling がテーブルのプロビジョンされたスループットを調整できる詳細と、その場合に実行するアクションを定義します。このポリシーは、前のステップで定義したスケーラブルターゲットに関連付けます (`TestTable` テーブルの容量単位を書き込みます)。
ポリシーには、次の要素が含まれます。
+ `PredefinedMetricSpecification` — Application Auto Scaling が調整できるメトリクス。DynamoDB の場合、次の値が `PredefinedMetricType` の有効な値です。
+ `DynamoDBReadCapacityUtilization`
+ `DynamoDBWriteCapacityUtilization`
+ `ScaleOutCooldown` — プロビジョンされたスループットを増加させる各 Application Auto Scaling イベント間の最小時間 (秒単位)。このパラメータを使用すると、Application Auto Scaling は、実際のワークロードに応じてスループットを継続的に増加させますが、積極的に増加させることはできません。`ScaleOutCooldown` のデフォルトの設定は 0 です。
+ `ScaleInCooldown` — プロビジョンされたスループットを低下させる各 Application Auto Scaling イベント間の最小時間 (秒単位)。このパラメータを使用すると、Application Auto Scaling はスループットを徐々に、予測どおりに低下させることができます。`ScaleInCooldown` のデフォルトの設定は 0 です。
+ `TargetValue` — Application Auto Scaling は、プロビジョンされた容量に対する消費容量の比率がこの値またはその近くに留まるようにします。`TargetValue` をパーセンテージとして定義します。
**注記**
`TargetValue` がどのように機能するかをさらに理解するために、書き込み容量単位が 200 で、プロビジョンされたスループット設定を持つテーブルがあるとします。このテーブルのスケーリングポリシーを作成することにしました。`TargetValue` は 70% です。
ここで、実際の書き込みスループットが 150 容量単位になるように、テーブルへの書き込みトラフィックを駆動し始めたとします。消費とプロビジョンの比率は現在 (150/200)、つまり 75% です。この比率は目標を超えているため、Application Auto Scaling はプロビジョンされた書き込み容量を 215 に増やし、比率が (150/215)、つまり 69.77% になるようにします。これは、可能な限り `TargetValue` に近いですが、超えないようにしてください。
`TestTable` の場合、`TargetValue` を 50% に設定します。Application Auto Scaling は、テーブルのプロビジョンされたスループットを 5～10 容量単位の範囲内で調整し ([ステップ 2: スケーラブルなターゲットを登録する](#AutoScaling.CLI.RegisterScalableTarget) を参照)、プロビジョンされた消費量とプロビジョンされた比率が 50% またはそれに近いままになるようにします。`ScaleOutCooldown` と `ScaleInCooldown` の値を 60 秒に設定します。
1. 次の内容で、`scaling-policy.json` というファイルを作成します。
```
{
"PredefinedMetricSpecification": {
"PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
},
"ScaleOutCooldown": 60,
"ScaleInCooldown": 60,
"TargetValue": 50.0
}
```
1. 次の AWS CLI コマンドを使用してポリシーを作成します。
```
aws application-autoscaling put-scaling-policy \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--policy-name "MyScalingPolicy" \
--policy-type "TargetTrackingScaling" \
--target-tracking-scaling-policy-configuration file://scaling-policy.json
```
1. 出力では、Application Auto Scaling が 2 つの Amazon CloudWatch アラームを作成したことに注意してください。スケーリング目標範囲の上限と下限に対応します。
1. 以下の AWS CLI コマンドを使用して、スケーリングポリシーの詳細を表示します。
```
aws application-autoscaling describe-scaling-policies \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--policy-name "MyScalingPolicy"
```
1. 出力で、ポリシー設定が [ステップ 2: スケーラブルなターゲットを登録する](#AutoScaling.CLI.RegisterScalableTarget) と [ステップ 3: スケーリングポリシーを作成する](#AutoScaling.CLI.CreateScalingPolicy) からの仕様と一致することを確認します。
## ステップ 4: 書き込みトラフィックを TestTable に送る
これで、`TestTable` にデータを書き込むことでスケーリングポリシーをテストできます。これを行うには、Python プログラムを実行します。
1. 次の内容で、`bulk-load-test-table.py` というファイルを作成します。
```
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table("TestTable")
filler = "x" * 100000
i = 0
while (i < 10):
j = 0
while (j < 10):
print (i, j)
table.put_item(
Item={
'pk':i,
'sk':j,
'filler':{"S":filler}
}
)
j += 1
i += 1
```
1. プログラムを実行するには、次のコマンドを入力します。
`python bulk-load-test-table.py`
`TestTable` のプロビジョンされた書き込み容量は非常に低いため (5 書き込み容量単位)、書き込みスロットリングが原因でプログラムが停止することがあります。これは想定される動作です。
次のステップに進む間、プログラムを実行し続けます。
## ステップ 5: Application Auto Scaling アクションを表示する
このステップでは、ユーザーに代わって開始された Application Auto Scaling アクションを表示します。また、Application Auto Scaling が `TestTable` のプロビジョンされた書き込み容量を更新したことを確認します。
1. 次のコマンドを入力して、Application Auto Scaling アクションを表示します。
```
aws application-autoscaling describe-scaling-activities \
--service-namespace dynamodb
```
Python プログラムの実行中に、このコマンドを時折再実行します。(スケーリングポリシーが呼び出されるまで数分かかります。) 結果的に、次のような出力が表示されます。
```
...
{
"ScalableDimension": "dynamodb:table:WriteCapacityUnits",
"Description": "Setting write capacity units to 10.",
"ResourceId": "table/TestTable",
"ActivityId": "0cc6fb03-2a7c-4b51-b67f-217224c6b656",
"StartTime": 1489088210.175,
"ServiceNamespace": "dynamodb",
"EndTime": 1489088246.85,
"Cause": "monitor alarm AutoScaling-table/TestTable-AlarmHigh-1bb3c8db-1b97-4353-baf1-4def76f4e1b9 in state ALARM triggered policy MyScalingPolicy",
"StatusMessage": "Successfully set write capacity units to 10. Change successfully fulfilled by dynamodb.",
"StatusCode": "Successful"
},
...
```
これは、Application Auto Scaling が DynamoDB に `UpdateTable` リクエストを発行したことを示しています。
1. DynamoDB がテーブルの書き込み容量を増やしたことを確認するには、次のコマンドを入力します。
```
aws dynamodb describe-table \
--table-name TestTable \
--query "Table.[TableName,TableStatus,ProvisionedThroughput]"
```
`WriteCapacityUnits` は `5` から `10` にスケーリングされている必要があります。
## (オプション) ステップ 6: クリーンアップする
このチュートリアルでは、いくつかのリソースを作成しました。これらのリソースが不要になった場合は、削除できます。
1. `TestTable` のスケーリングポリシーを削除します。
```
aws application-autoscaling delete-scaling-policy \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--policy-name "MyScalingPolicy"
```
1. スケーラブルなターゲットを登録解除します。
```
aws application-autoscaling deregister-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits"
```
1. `TestTable` テーブルを削除します。
```
aws dynamodb delete-table --table-name TestTable
```
# AWS SDK を使用した Amazon DynamoDB テーブルでの Auto Scaling の設定
AWS マネジメントコンソール と AWS Command Line Interface (AWS CLI) を使用するほかに、Amazon DynamoDB Auto Scaling とやり取りするアプリケーションを作成することもできます。このセクションには、この機能をテストするために使用できる 2 つの Java プログラムが含まれています。
+ `EnableDynamoDBAutoscaling.java`
+ `DisableDynamoDBAutoscaling.java`
## テーブルの Application Auto Scaling の有効化
次のプログラムは、DynamoDB テーブル (`TestTable`) の Auto Scaling ポリシーをセットアップする例を示しています。プログラムの流れは次のようになります。
+ `TestTable` のスケーラブルなターゲットとして書き込みキャパシティユニットを登録します。このメトリクスの範囲は 5～10 書き込みキャパシティーユニットです。
+ スケーラブルなターゲットを作成したら、次にターゲットの追跡設定を作成します。このポリシーでは、プロビジョニングされた書き込みキャパシティに対する消費された書き込みキャパシティの割合を 50% に維持することを目指します。
+ 次に、ターゲットの追跡設定に基づいてスケーリングポリシーを作成します。
**注記**
テーブルまたはグローバルテーブルレプリカを手動で削除しても、関連するスケーラブルターゲット、スケーリングポリシー、または CloudWatch アラームは自動的には削除されません。
------
#### [ Java v2 ]
```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.PolicyType;
import software.amazon.awssdk.services.applicationautoscaling.model.PredefinedMetricSpecification;
import software.amazon.awssdk.services.applicationautoscaling.model.PutScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalingPolicy;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.MetricType;
import software.amazon.awssdk.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
import java.util.List;
/**
* Before running this Java V2 code example, set up your development environment, including your credentials.
*
* For more information, see the following documentation topic:
*
* https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
*/
public class EnableDynamoDBAutoscaling {
public static void main(String[] args) {
final String usage = """
Usage:
\s
Where:
tableId - The table Id value (for example, table/Music).
roleARN - The ARN of the role that has ApplicationAutoScaling permissions.
policyName - The name of the policy to create.
""";
if (args.length != 3) {
System.out.println(usage);
System.exit(1);
}
System.out.println("This example registers an Amazon DynamoDB table, which is the resource to scale.");
String tableId = args[0];
String roleARN = args[1];
String policyName = args[2];
ServiceNamespace ns = ServiceNamespace.DYNAMODB;
ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
.region(Region.US_EAST_1)
.build();
registerScalableTarget(appAutoScalingClient, tableId, roleARN, ns, tableWCUs);
verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
configureScalingPolicy(appAutoScalingClient, tableId, ns, tableWCUs, policyName);
}
public static void registerScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, String roleARN, ServiceNamespace ns, ScalableDimension tableWCUs) {
try {
RegisterScalableTargetRequest targetRequest = RegisterScalableTargetRequest.builder()
.serviceNamespace(ns)
.scalableDimension(tableWCUs)
.resourceId(tableId)
.roleARN(roleARN)
.minCapacity(5)
.maxCapacity(10)
.build();
appAutoScalingClient.registerScalableTarget(targetRequest);
System.out.println("You have registered " + tableId);
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
// Verify that the target was created.
public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceIds(tableId)
.build();
DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
// Configure a scaling policy.
public static void configureScalingPolicy(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs, String policyName) {
// Check if the policy exists before creating a new one.
DescribeScalingPoliciesResponse describeScalingPoliciesResponse = appAutoScalingClient.describeScalingPolicies(DescribeScalingPoliciesRequest.builder()
.serviceNamespace(ns)
.resourceId(tableId)
.scalableDimension(tableWCUs)
.build());
if (!describeScalingPoliciesResponse.scalingPolicies().isEmpty()) {
// If policies exist, consider updating an existing policy instead of creating a new one.
System.out.println("Policy already exists. Consider updating it instead.");
List polList = describeScalingPoliciesResponse.scalingPolicies();
for (ScalingPolicy pol : polList) {
System.out.println("Policy name:" +pol.policyName());
}
} else {
// If no policies exist, proceed with creating a new policy.
PredefinedMetricSpecification specification = PredefinedMetricSpecification.builder()
.predefinedMetricType(MetricType.DYNAMO_DB_WRITE_CAPACITY_UTILIZATION)
.build();
TargetTrackingScalingPolicyConfiguration policyConfiguration = TargetTrackingScalingPolicyConfiguration.builder()
.predefinedMetricSpecification(specification)
.targetValue(50.0)
.scaleInCooldown(60)
.scaleOutCooldown(60)
.build();
PutScalingPolicyRequest putScalingPolicyRequest = PutScalingPolicyRequest.builder()
.targetTrackingScalingPolicyConfiguration(policyConfiguration)
.serviceNamespace(ns)
.scalableDimension(tableWCUs)
.resourceId(tableId)
.policyName(policyName)
.policyType(PolicyType.TARGET_TRACKING_SCALING)
.build();
try {
appAutoScalingClient.putScalingPolicy(putScalingPolicyRequest);
System.out.println("You have successfully created a scaling policy for an Application Auto Scaling scalable target");
} catch (ApplicationAutoScalingException e) {
System.err.println("Error: " + e.awsErrorDetails().errorMessage());
}
}
}
}
```
------
#### [ Java v1 ]
プログラムでは、有効な Application Auto Scaling サービスリンクロールの Amazon リソースネーム (ARN) を指定する必要があります。(例: `arn:aws:iam::122517410325:role/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`。) 次のプログラムの `SERVICE_ROLE_ARN_GOES_HERE` を実際の ARN に置き換えます。
```
package com.amazonaws.codesamples.autoscaling;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClientBuilder;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.MetricType;
import com.amazonaws.services.applicationautoscaling.model.PolicyType;
import com.amazonaws.services.applicationautoscaling.model.PredefinedMetricSpecification;
import com.amazonaws.services.applicationautoscaling.model.PutScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
import com.amazonaws.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
public class EnableDynamoDBAutoscaling {
static AWSApplicationAutoScalingClient aaClient = (AWSApplicationAutoScalingClient) AWSApplicationAutoScalingClientBuilder
.standard().build();
public static void main(String args[]) {
ServiceNamespace ns = ServiceNamespace.Dynamodb;
ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
String resourceID = "table/TestTable";
// Define the scalable target
RegisterScalableTargetRequest rstRequest = new RegisterScalableTargetRequest()
.withServiceNamespace(ns)
.withResourceId(resourceID)
.withScalableDimension(tableWCUs)
.withMinCapacity(5)
.withMaxCapacity(10)
.withRoleARN("SERVICE_ROLE_ARN_GOES_HERE");
try {
aaClient.registerScalableTarget(rstRequest);
} catch (Exception e) {
System.err.println("Unable to register scalable target: ");
System.err.println(e.getMessage());
}
// Verify that the target was created
DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceIds(resourceID);
try {
DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(dsaResult);
System.out.println();
} catch (Exception e) {
System.err.println("Unable to describe scalable target: ");
System.err.println(e.getMessage());
}
System.out.println();
// Configure a scaling policy
TargetTrackingScalingPolicyConfiguration targetTrackingScalingPolicyConfiguration = new TargetTrackingScalingPolicyConfiguration()
.withPredefinedMetricSpecification(
new PredefinedMetricSpecification()
.withPredefinedMetricType(MetricType.DynamoDBWriteCapacityUtilization))
.withTargetValue(50.0)
.withScaleInCooldown(60)
.withScaleOutCooldown(60);
// Create the scaling policy, based on your configuration
PutScalingPolicyRequest pspRequest = new PutScalingPolicyRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID)
.withPolicyName("MyScalingPolicy")
.withPolicyType(PolicyType.TargetTrackingScaling)
.withTargetTrackingScalingPolicyConfiguration(targetTrackingScalingPolicyConfiguration);
try {
aaClient.putScalingPolicy(pspRequest);
} catch (Exception e) {
System.err.println("Unable to put scaling policy: ");
System.err.println(e.getMessage());
}
// Verify that the scaling policy was created
DescribeScalingPoliciesRequest dspRequest = new DescribeScalingPoliciesRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(dspRequest);
System.out.println("DescribeScalingPolicies result: ");
System.out.println(dspResult);
} catch (Exception e) {
e.printStackTrace();
System.err.println("Unable to describe scaling policy: ");
System.err.println(e.getMessage());
}
}
}
```
------
## テーブルの Application Auto Scaling の無効化
次のプログラムは、前述のプロセスを元に戻します。Auto Scaling ポリシーを削除し、スケーラブルなターゲットを登録解除します。
------
#### [ Java v2 ]
```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;
/**
* Before running this Java V2 code example, set up your development environment, including your credentials.
*
* For more information, see the following documentation topic:
*
* https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
*/
public class DisableDynamoDBAutoscaling {
public static void main(String[] args) {
final String usage = """
Usage:
\s
Where:
tableId - The table Id value (for example, table/Music).\s
policyName - The name of the policy (for example, $Music5-scaling-policy).
""";
if (args.length != 2) {
System.out.println(usage);
System.exit(1);
}
ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
.region(Region.US_EAST_1)
.build();
ServiceNamespace ns = ServiceNamespace.DYNAMODB;
ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
String tableId = args[0];
String policyName = args[1];
deletePolicy(appAutoScalingClient, policyName, tableWCUs, ns, tableId);
verifyScalingPolicies(appAutoScalingClient, tableId, ns, tableWCUs);
deregisterScalableTarget(appAutoScalingClient, tableId, ns, tableWCUs);
verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
}
public static void deletePolicy(ApplicationAutoScalingClient appAutoScalingClient, String policyName, ScalableDimension tableWCUs, ServiceNamespace ns, String tableId) {
try {
DeleteScalingPolicyRequest delSPRequest = DeleteScalingPolicyRequest.builder()
.policyName(policyName)
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
appAutoScalingClient.deleteScalingPolicy(delSPRequest);
System.out.println(policyName +" was deleted successfully.");
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
// Verify that the scaling policy was deleted
public static void verifyScalingPolicies(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalingPoliciesRequest dscRequest = DescribeScalingPoliciesRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
DescribeScalingPoliciesResponse response = appAutoScalingClient.describeScalingPolicies(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
public static void deregisterScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
try {
DeregisterScalableTargetRequest targetRequest = DeregisterScalableTargetRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
appAutoScalingClient.deregisterScalableTarget(targetRequest);
System.out.println("The scalable target was deregistered.");
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceIds(tableId)
.build();
DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
}
```
------
#### [ Java v1 ]
```
package com.amazonaws.codesamples.autoscaling;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
public class DisableDynamoDBAutoscaling {
static AWSApplicationAutoScalingClient aaClient = new AWSApplicationAutoScalingClient();
public static void main(String args[]) {
ServiceNamespace ns = ServiceNamespace.Dynamodb;
ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
String resourceID = "table/TestTable";
// Delete the scaling policy
DeleteScalingPolicyRequest delSPRequest = new DeleteScalingPolicyRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID)
.withPolicyName("MyScalingPolicy");
try {
aaClient.deleteScalingPolicy(delSPRequest);
} catch (Exception e) {
System.err.println("Unable to delete scaling policy: ");
System.err.println(e.getMessage());
}
// Verify that the scaling policy was deleted
DescribeScalingPoliciesRequest descSPRequest = new DescribeScalingPoliciesRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(descSPRequest);
System.out.println("DescribeScalingPolicies result: ");
System.out.println(dspResult);
} catch (Exception e) {
e.printStackTrace();
System.err.println("Unable to describe scaling policy: ");
System.err.println(e.getMessage());
}
System.out.println();
// Remove the scalable target
DeregisterScalableTargetRequest delSTRequest = new DeregisterScalableTargetRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
aaClient.deregisterScalableTarget(delSTRequest);
} catch (Exception e) {
System.err.println("Unable to deregister scalable target: ");
System.err.println(e.getMessage());
}
// Verify that the scalable target was removed
DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceIds(resourceID);
try {
DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(dsaResult);
System.out.println();
} catch (Exception e) {
System.err.println("Unable to describe scalable target: ");
System.err.println(e.getMessage());
}
}
}
```
------
# DynamoDB リザーブドキャパシティ
標準の[テーブルクラス](HowItWorks.TableClasses.md)を使用するプロビジョンドキャパシティテーブルの場合、DynamoDB は読み込みおよび書き込みキャパシティ用にリザーブドキャパシティを購入する機能を提供しています。リザーブドキャパシティの購入は、割引料金と引き換えに、契約期間中のプロビジョニングされたスループットキャパシティの最小量に対して支払う契約です。
**注記**
レプリケートされた書き込みキャパシティユニット (rWCU) に対しては、リザーブドキャパシティを購入できません。リザーブドキャパシティは、キャパシティを購入したリージョンにのみ適用されます。リザーブドキャパシティは、DynamoDB 標準-IA テーブルクラスまたはオンデマンドキャパシティモードを使用するテーブルでも使用できません。
リザーブドキャパシティは、100 個の WCU または 100 個の RCU の割り当て単位で購入します。最小のリザーブドキャパシティは、100 個のキャパシティユニット (読み込みまたは書き込み) です。DynamoDB リザーブドキャパシティは、1 年間のコミットメント、または限定リージョンでの 3 年間のコミットメントとして提供されます。1 年契約では標準料金から最大 54%、3 年契約では標準料金から最大 77% の割引を受けることができます。購入方法と購入時期の詳細については、[「Amazon DynamoDB リザーブドキャパシティ](https://aws.amazon.com/dynamodb/reserved-capacity/)」を参照してください。
**注記**
AWS マネジメントコンソールを使用して、書き込みキャパシティーユニット (WCU) と読み取りキャパシティユニット (RCU) を合わせて最大 1,000,000 のリザーブドキャパシティユニットを購入できます。1 回の購入で 1,000,000 を超えるプロビジョンドキャパシティユニットを購入する場合、またはアクティブなリザーブドキャパシティがあり、追加のリザーブドキャパシティの購入によってアクティブなプロビジョンドキャパシティユニットの合計が 1,000,000 を超える場合は、「[Amazon DynamoDB リザーブドキャパシティ](https://aws.amazon.com/dynamodb/reserved-capacity/)」の「リザーブドキャパシティの購入方法」セクションに記載されているプロセスに従います。
DynamoDB リザーブドキャパシティを購入すると、1 回限りの一部前払い料金を支払うことで、コミットしたプロビジョンド使用量を割引時間料金で利用できます。実際の使用量に関係なく、コミットしたプロビジョンド使用量全体に料金を支払うため、コスト削減は使用量と密接に関連します。購入したリザーブドキャパシティを超えてプロビジョニングしたキャパシティには、標準のプロビジョンドキャパシティの料金が請求されます。読み込みキャパシティーユニットおよび書き込みキャパシティーユニットを事前に予約することで、プロビジョニングされたキャパシティーコストの大幅なコスト削減を実現できます。
リザーブドキャパシティを販売またはキャンセルしたり、別のリージョンやアカウントに移管したりすることはできません。
# DynamoDB ウォームスループットについて
*ウォームスループット*とは、DynamoDB テーブルが瞬時にサポートできる読み取りおよび書き込みオペレーションの数を指します。これらの値は、すべてのテーブルとグローバルセカンダリインデックス (GSI) でデフォルトで使用でき、履歴の使用に基づいてスケーリングされた量を表します。オンデマンドモードを使用している場合、またはプロビジョンドスループットをこれらの値に更新した場合、アプリケーションはこれらの値まで即座にリクエストを発行できます。
DynamoDB は、使用量が増えるとウォームスループット値を自動的に調整します。これらの値は、必要に応じて事前に増やすこともできます。これは、製品のローンチや販売などの今後のピークイベントに特に役立ちます。計画されたピークイベントで、DynamoDB テーブルへのリクエストレートが 10 倍、100 倍、またはそれ以上増加する可能性がある場合、現在のウォームスループットが予想されるトラフィックを処理するのに十分かどうかを評価できるようになりました。そうでない場合は、スループット設定や[請求モード](capacity-mode.md)を変更せずにウォームスループット値を増やすことができます。このプロセスはテーブルの*事前ウォーミング*と呼ばれ、テーブルがすぐにサポートできるベースラインを設定できます。これにより、アプリケーションは、発生した瞬間からより高いリクエストレートを処理できます。一度増やすと、ウォームスループット値を減らすことはできません。
読み取りオペレーション、書き込みオペレーション、またはその両方のウォームスループット値を増やすことができます。この値は、新規および既存の単一リージョンテーブル、グローバルテーブル、GSI で増やすことができます。グローバルテーブルの場合、この機能は[バージョン 2019.11.21 (現行)](GlobalTables.md) で使用でき、設定したウォームスループット設定はグローバルテーブル内のすべてのレプリカテーブルに自動的に適用されます。いつでも事前ウォーミングできる DynamoDB テーブルの数に制限はありません。事前ウォーミングを完了する時間は、設定した値と、テーブルまたはインデックスのサイズによって異なります。事前ウォーミングの同時リクエストを送信できます。これらのリクエストはテーブルオペレーションを妨げません。そのリージョンのアカウントのテーブルまたはインデックスクォータ制限まで、テーブルを事前ウォーミングできます。[Service Quotas コンソール](https://console.aws.amazon.com/servicequotas)を使用して現在の制限を確認し、必要に応じて引き上げます。
ウォームスループット値は、デフォルトですべてのテーブルとセカンダリインデックスで無料で使用できます。ただし、これらのデフォルトのウォームスループット値をプロアクティブに増やしてテーブルを事前ウォーミングすると、それらのリクエストに対して課金されます。詳細については、「[Amazon DynamoDB 料金](https://aws.amazon.com/dynamodb/pricing/)」を参照してください。
ウォームスループットの詳細については、以下のトピックを参照してください。
**Topics**
+ [DynamoDB テーブルの現在のウォームスループットを確認する](check-warm-throughput.md)
+ [既存の DynamoDB テーブルのウォームスループットを増やす](update-warm-throughput.md)
+ [ウォームスループットが高い新しい DynamoDB テーブルを作成する](create-table-warm-throughput.md)
+ [さまざまなシナリオでの DynamoDB ウォームスループットについて](warm-throughput-scenarios.md)
# DynamoDB テーブルの現在のウォームスループットを確認する
テーブルまたはインデックスの現在のウォームスループット値を確認するには、次の AWS CLI および AWS コンソールの手順を使用します。
## AWS マネジメントコンソール
DynamoDB コンソールを使用して DynamoDB テーブルのウォームスループットを確認するには:
1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。
1. 左のナビゲーションペインで、[テーブル] を選択します。
1. **[テーブル]** ページで、目的のテーブルを選択します。
1. **[追加の設定]** を選択して、現在のウォームスループット値を表示します。この値は、1 秒あたりの読み取り単位と 1 秒あたりの書き込み単位として表示されます。
## AWS CLI
次の AWS CLI の例は、DynamoDB テーブルのウォームスループットを確認する方法を示しています。
1. DynamoDB テーブルで `describe-table` オペレーションを実行します。
```
aws dynamodb describe-table --table-name GameScores
```
1. 次のようなレスポンスが表示されます。`WarmThroughput` 設定は、`ReadUnitsPerSecond` および `WriteUnitsPerSecond` として表示されます。ウォームスループット値が更新されている場合、`Status` は `UPDATING` になり、新しいウォームスループット値が設定されている場合は、`ACTIVE` になります。
```
{
"Table": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "ACTIVE",
"CreationDateTime": 1726128388.729,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 0,
"WriteCapacityUnits": 0
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"BillingModeSummary": {
"BillingMode": "PAY_PER_REQUEST",
"LastUpdateToPayPerRequestDateTime": 1726128388.729
},
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "ACTIVE",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 0,
"WriteCapacityUnits": 0
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000,
"Status": "ACTIVE"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000,
"Status": "ACTIVE"
}
}
}
```
# 既存の DynamoDB テーブルのウォームスループットを増やす
DynamoDB テーブルの現在のウォームスループット値を確認したら、次のステップで値を更新できます。
## AWS マネジメントコンソール
DynamoDB コンソールを使用して DynamoDB テーブルのウォームスループット値を確認するには:
1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。
1. 左のナビゲーションペインで、[テーブル] を選択します。
1. **[テーブル]** ページで、目的のテーブルを選択します。
1. **[ウォームスループット]** フィールドで、**[編集]** を選択します。
1. **[ウォームスループットを編集]** ページで、**[ウォームスループットを増やす]** を選択します。
1. **[1 秒あたりの読み取りユニット]** と **[1 秒あたりの書き込みユニット]** を調整します。これら 2 つの設定は、テーブルが即座に処理できるスループットを定義します。
1. **[保存]** を選択します。
1. リクエストの処理が完了すると、**[ウォームスループット]** フィールドで **[1 秒あたりの読み取りユニット]** と **[1 秒あたりの書き込みユニット]** が更新されます。
**注記**
ウォームスループット値の更新は非同期タスクです。更新が完了すると、`Status` は `UPDATING` から `ACTIVE` に変わります。
## AWS CLI
次の AWS CLI の例は、DynamoDB テーブルのウォームスループット値を更新する方法を示しています。
1. DynamoDB テーブルで `update-table` オペレーションを実行します。
```
aws dynamodb update-table \
--table-name GameScores \
--warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
--global-secondary-index-updates \
"[
{
\"Update\": {
\"IndexName\": \"GameTitleIndex\",
\"WarmThroughput\": {
\"ReadUnitsPerSecond\": 88,
\"WriteUnitsPerSecond\": 77
}
}
}
]" \
--region us-east-1
```
1. 次のようなレスポンスが表示されます。`WarmThroughput` 設定は、`ReadUnitsPerSecond` および `WriteUnitsPerSecond` として表示されます。ウォームスループット値が更新されている場合、`Status` は `UPDATING` になり、新しいウォームスループット値が設定されている場合は、`ACTIVE` になります。
```
{
"TableDescription": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "ACTIVE",
"CreationDateTime": 1730242189.965,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 20,
"WriteCapacityUnits": 10
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "ACTIVE",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 50,
"WriteCapacityUnits": 25
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 50,
"WriteUnitsPerSecond": 25,
"Status": "UPDATING"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12300,
"WriteUnitsPerSecond": 4500,
"Status": "UPDATING"
}
}
}
```
## AWS SDK
次の SDK の例は、DynamoDB テーブルのウォームスループット値を更新する方法を示しています。
------
#### [ Java ]
```
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.DynamoDbException;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndexUpdate;
import software.amazon.awssdk.services.dynamodb.model.UpdateGlobalSecondaryIndexAction;
import software.amazon.awssdk.services.dynamodb.model.UpdateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;
...
public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
final Long writeUnitsPerSecond) {
return WarmThroughput.builder()
.readUnitsPerSecond(readUnitsPerSecond)
.writeUnitsPerSecond(writeUnitsPerSecond)
.build();
}
public static void updateDynamoDBTable(DynamoDbClient ddb,
String tableName,
Long tableReadUnitsPerSecond,
Long tableWriteUnitsPerSecond,
String globalSecondaryIndexName,
Long globalSecondaryIndexReadUnitsPerSecond,
Long globalSecondaryIndexWriteUnitsPerSecond) {
final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableReadUnitsPerSecond, tableWriteUnitsPerSecond);
final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexReadUnitsPerSecond, globalSecondaryIndexWriteUnitsPerSecond);
final GlobalSecondaryIndexUpdate globalSecondaryIndexUpdate = GlobalSecondaryIndexUpdate.builder()
.update(UpdateGlobalSecondaryIndexAction.builder()
.indexName(globalSecondaryIndexName)
.warmThroughput(gsiWarmThroughput)
.build()
).build();
final UpdateTableRequest request = UpdateTableRequest.builder()
.tableName(tableName)
.globalSecondaryIndexUpdates(globalSecondaryIndexUpdate)
.warmThroughput(tableWarmThroughput)
.build();
try {
ddb.updateTable(request);
} catch (DynamoDbException e) {
System.err.println(e.getMessage());
System.exit(1);
}
System.out.println("Done!");
}
```
------
#### [ Python ]
```
from boto3 import resource
from botocore.exceptions import ClientError
def update_dynamodb_table_warm_throughput(table_name, table_read_units, table_write_units, gsi_name, gsi_read_units, gsi_write_units, region_name="us-east-1"):
"""
Updates the warm throughput of a DynamoDB table and a global secondary index.
:param table_name: The name of the table to update.
:param table_read_units: The new read units per second for the table's warm throughput.
:param table_write_units: The new write units per second for the table's warm throughput.
:param gsi_name: The name of the global secondary index to update.
:param gsi_read_units: The new read units per second for the GSI's warm throughput.
:param gsi_write_units: The new write units per second for the GSI's warm throughput.
:param region_name: The AWS Region name to target. defaults to us-east-1
"""
try:
ddb = resource('dynamodb', region_name)
# Update the table's warm throughput
table_warm_throughput = {
"ReadUnitsPerSecond": table_read_units,
"WriteUnitsPerSecond": table_write_units
}
# Update the global secondary index's warm throughput
gsi_warm_throughput = {
"ReadUnitsPerSecond": gsi_read_units,
"WriteUnitsPerSecond": gsi_write_units
}
# Construct the global secondary index update
global_secondary_index_update = [
{
"Update": {
"IndexName": gsi_name,
"WarmThroughput": gsi_warm_throughput
}
}
]
# Construct the update table request
update_table_request = {
"TableName": table_name,
"GlobalSecondaryIndexUpdates": global_secondary_index_update,
"WarmThroughput": table_warm_throughput
}
# Update the table
ddb.update_table(**update_table_request)
print("Table updated successfully!")
except ClientError as e:
print(f"Error updating table: {e}")
raise e
```
------
#### [ Javascript ]
```
import { DynamoDBClient, UpdateTableCommand } from "@aws-sdk/client-dynamodb";
async function updateDynamoDBTableWarmThroughput(
tableName,
tableReadUnits,
tableWriteUnits,
gsiName,
gsiReadUnits,
gsiWriteUnits,
region = "us-east-1"
) {
try {
const ddbClient = new DynamoDBClient({ region: region });
// Construct the update table request
const updateTableRequest = {
TableName: tableName,
GlobalSecondaryIndexUpdates: [
{
Update: {
IndexName: gsiName,
WarmThroughput: {
ReadUnitsPerSecond: gsiReadUnits,
WriteUnitsPerSecond: gsiWriteUnits,
},
},
},
],
WarmThroughput: {
ReadUnitsPerSecond: tableReadUnits,
WriteUnitsPerSecond: tableWriteUnits,
},
};
const command = new UpdateTableCommand(updateTableRequest);
const response = await ddbClient.send(command);
console.log(`Table updated successfully! Response: ${response}`);
} catch (error) {
console.error(`Error updating table: ${error}`);
throw error;
}
}
```
------
# ウォームスループットが高い新しい DynamoDB テーブルを作成する
DynamoDB テーブルを作成するときに、以下の手順に従ってウォームスループット値を調整できます。これらのステップは、[グローバルテーブル](GlobalTables.md)または[セカンダリインデックス](SecondaryIndexes.md)を作成する場合にも適用されます。
## AWS マネジメントコンソール
コンソールを使用して DynamoDB テーブルを作成し、ウォームスループット値を調整するには:
1. AWS マネジメントコンソール にサインインして DynamoDB コンソール ([https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)) を開きます。
1. **[テーブルの作成]** を選択します。
1. **[テーブル名]**、**[パーティションキー]**、**[ソートキー] (オプション)** を選択します。
1. **[テーブル設定]** セクションで **[設定をカスタマイズ]** を選択します。
1. **[ウォームスループット]** フィールドで、**[ウォームスループットを増やす]** を選択します。
1. **[1 秒あたりの読み取りユニット]** と **[1 秒あたりの書き込みユニット]** を調整します。これら 2 つの設定は、テーブルが即座に処理できる最大スループットを定義します。
1. 残りのテーブルの詳細を追加し、**[テーブルの作成]** を選択します。
## AWS CLI
次の AWS CLI の例は、カスタマイズされたウォームスループット値を使用して DynamoDB テーブルを作成する方法を示しています。
1. `create-table` オペレーションを実行して、次の DynamoDB テーブルを作成します。
```
aws dynamodb create-table \
--table-name GameScores \
--attribute-definitions AttributeName=UserId,AttributeType=S \
AttributeName=GameTitle,AttributeType=S \
AttributeName=TopScore,AttributeType=N \
--key-schema AttributeName=UserId,KeyType=HASH \
AttributeName=GameTitle,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=20,WriteCapacityUnits=10 \
--global-secondary-indexes \
"[
{
\"IndexName\": \"GameTitleIndex\",
\"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
\"Projection\":{
\"ProjectionType\":\"INCLUDE\",
\"NonKeyAttributes\":[\"UserId\"]
},
\"ProvisionedThroughput\": {
\"ReadCapacityUnits\": 50,
\"WriteCapacityUnits\": 25
},\"WarmThroughput\": {
\"ReadUnitsPerSecond\": 1987,
\"WriteUnitsPerSecond\": 543
}
}
]" \
--warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
--region us-east-1
```
1. 次のようなレスポンスが表示されます。`WarmThroughput` 設定は、`ReadUnitsPerSecond` および `WriteUnitsPerSecond` として表示されます。ウォームスループット値が更新されている場合、`Status` は `UPDATING` になり、新しいウォームスループット値が設定されている場合は、`ACTIVE` になります。
```
{
"TableDescription": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "CREATING",
"CreationDateTime": 1730241788.779,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 20,
"WriteCapacityUnits": 10
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "CREATING",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 50,
"WriteCapacityUnits": 25
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 1987,
"WriteUnitsPerSecond": 543,
"Status": "UPDATING"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12345,
"WriteUnitsPerSecond": 4567,
"Status": "UPDATING"
}
}
}
```
## AWS SDK
次の SDK の例は、カスタマイズされたウォームスループット値を使用して DynamoDB テーブルを作成する方法を示しています。
------
#### [ Java ]
```
import software.amazon.awscdk.services.dynamodb.ProjectionType;
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.CreateTableResponse;
import software.amazon.awssdk.services.dynamodb.model.CreateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.KeySchemaElement;
import software.amazon.awssdk.services.dynamodb.model.KeyType;
import software.amazon.awssdk.services.dynamodb.model.ProvisionedThroughput;
import software.amazon.awssdk.services.dynamodb.model.Projection;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndex;
import software.amazon.awssdk.services.dynamodb.model.AttributeDefinition;
import software.amazon.awssdk.services.dynamodb.model.ScalarAttributeType;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;
...
public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
final Long writeUnitsPerSecond) {
return WarmThroughput.builder()
.readUnitsPerSecond(readUnitsPerSecond)
.writeUnitsPerSecond(writeUnitsPerSecond)
.build();
}
private static AttributeDefinition buildAttributeDefinition(final String attributeName,
final ScalarAttributeType scalarAttributeType) {
return AttributeDefinition.builder()
.attributeName(attributeName)
.attributeType(scalarAttributeType)
.build();
}
private static KeySchemaElement buildKeySchemaElement(final String attributeName,
final KeyType keyType) {
return KeySchemaElement.builder()
.attributeName(attributeName)
.keyType(keyType)
.build();
}
public static void createDynamoDBTable(DynamoDbClient ddb,
String tableName,
String partitionKey,
String sortKey,
String miscellaneousKeyAttribute,
String nonKeyAttribute,
Long tableReadCapacityUnits,
Long tableWriteCapacityUnits,
Long tableWarmReadUnitsPerSecond,
Long tableWarmWriteUnitsPerSecond,
String globalSecondaryIndexName,
Long globalSecondaryIndexReadCapacityUnits,
Long globalSecondaryIndexWriteCapacityUnits,
Long globalSecondaryIndexWarmReadUnitsPerSecond,
Long globalSecondaryIndexWarmWriteUnitsPerSecond) {
// Define the table attributes
final AttributeDefinition partitionKeyAttribute = buildAttributeDefinition(partitionKey, ScalarAttributeType.S);
final AttributeDefinition sortKeyAttribute = buildAttributeDefinition(sortKey, ScalarAttributeType.S);
final AttributeDefinition miscellaneousKeyAttributeDefinition = buildAttributeDefinition(miscellaneousKeyAttribute, ScalarAttributeType.N);
final AttributeDefinition[] attributeDefinitions = {partitionKeyAttribute, sortKeyAttribute, miscellaneousKeyAttributeDefinition};
// Define the table key schema
final KeySchemaElement partitionKeyElement = buildKeySchemaElement(partitionKey, KeyType.HASH);
final KeySchemaElement sortKeyElement = buildKeySchemaElement(sortKey, KeyType.RANGE);
final KeySchemaElement[] keySchema = {partitionKeyElement, sortKeyElement};
// Define the provisioned throughput for the table
final ProvisionedThroughput provisionedThroughput = ProvisionedThroughput.builder()
.readCapacityUnits(tableReadCapacityUnits)
.writeCapacityUnits(tableWriteCapacityUnits)
.build();
// Define the Global Secondary Index (GSI)
final KeySchemaElement globalSecondaryIndexPartitionKeyElement = buildKeySchemaElement(sortKey, KeyType.HASH);
final KeySchemaElement globalSecondaryIndexSortKeyElement = buildKeySchemaElement(miscellaneousKeyAttribute, KeyType.RANGE);
final KeySchemaElement[] gsiKeySchema = {globalSecondaryIndexPartitionKeyElement, globalSecondaryIndexSortKeyElement};
final Projection gsiProjection = Projection.builder()
.projectionType(String.valueOf(ProjectionType.INCLUDE))
.nonKeyAttributes(nonKeyAttribute)
.build();
final ProvisionedThroughput gsiProvisionedThroughput = ProvisionedThroughput.builder()
.readCapacityUnits(globalSecondaryIndexReadCapacityUnits)
.writeCapacityUnits(globalSecondaryIndexWriteCapacityUnits)
.build();
// Define the warm throughput for the Global Secondary Index (GSI)
final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexWarmReadUnitsPerSecond, globalSecondaryIndexWarmWriteUnitsPerSecond);
final GlobalSecondaryIndex globalSecondaryIndex = GlobalSecondaryIndex.builder()
.indexName(globalSecondaryIndexName)
.keySchema(gsiKeySchema)
.projection(gsiProjection)
.provisionedThroughput(gsiProvisionedThroughput)
.warmThroughput(gsiWarmThroughput)
.build();
// Define the warm throughput for the table
final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableWarmReadUnitsPerSecond, tableWarmWriteUnitsPerSecond);
final CreateTableRequest request = CreateTableRequest.builder()
.tableName(tableName)
.attributeDefinitions(attributeDefinitions)
.keySchema(keySchema)
.provisionedThroughput(provisionedThroughput)
.globalSecondaryIndexes(globalSecondaryIndex)
.warmThroughput(tableWarmThroughput)
.build();
CreateTableResponse response = ddb.createTable(request);
System.out.println(response);
}
```
------
#### [ Python ]
```
from boto3 import resource
from botocore.exceptions import ClientError
def create_dynamodb_table_warm_throughput(table_name, partition_key, sort_key, misc_key_attr, non_key_attr, table_provisioned_read_units, table_provisioned_write_units, table_warm_reads, table_warm_writes, gsi_name, gsi_provisioned_read_units, gsi_provisioned_write_units, gsi_warm_reads, gsi_warm_writes, region_name="us-east-1"):
"""
Creates a DynamoDB table with a warm throughput setting configured.
:param table_name: The name of the table to be created.
:param partition_key: The partition key for the table being created.
:param sort_key: The sort key for the table being created.
:param misc_key_attr: A miscellaneous key attribute for the table being created.
:param non_key_attr: A non-key attribute for the table being created.
:param table_provisioned_read_units: The newly created table's provisioned read capacity units.
:param table_provisioned_write_units: The newly created table's provisioned write capacity units.
:param table_warm_reads: The read units per second setting for the table's warm throughput.
:param table_warm_writes: The write units per second setting for the table's warm throughput.
:param gsi_name: The name of the Global Secondary Index (GSI) to be created on the table.
:param gsi_provisioned_read_units: The configured Global Secondary Index (GSI) provisioned read capacity units.
:param gsi_provisioned_write_units: The configured Global Secondary Index (GSI) provisioned write capacity units.
:param gsi_warm_reads: The read units per second setting for the Global Secondary Index (GSI)'s warm throughput.
:param gsi_warm_writes: The write units per second setting for the Global Secondary Index (GSI)'s warm throughput.
:param region_name: The AWS Region name to target. defaults to us-east-1
"""
try:
ddb = resource('dynamodb', region_name)
# Define the table attributes
attribute_definitions = [
{ "AttributeName": partition_key, "AttributeType": "S" },
{ "AttributeName": sort_key, "AttributeType": "S" },
{ "AttributeName": misc_key_attr, "AttributeType": "N" }
]
# Define the table key schema
key_schema = [
{ "AttributeName": partition_key, "KeyType": "HASH" },
{ "AttributeName": sort_key, "KeyType": "RANGE" }
]
# Define the provisioned throughput for the table
provisioned_throughput = {
"ReadCapacityUnits": table_provisioned_read_units,
"WriteCapacityUnits": table_provisioned_write_units
}
# Define the global secondary index
gsi_key_schema = [
{ "AttributeName": sort_key, "KeyType": "HASH" },
{ "AttributeName": misc_key_attr, "KeyType": "RANGE" }
]
gsi_projection = {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [non_key_attr]
}
gsi_provisioned_throughput = {
"ReadCapacityUnits": gsi_provisioned_read_units,
"WriteCapacityUnits": gsi_provisioned_write_units
}
gsi_warm_throughput = {
"ReadUnitsPerSecond": gsi_warm_reads,
"WriteUnitsPerSecond": gsi_warm_writes
}
global_secondary_indexes = [
{
"IndexName": gsi_name,
"KeySchema": gsi_key_schema,
"Projection": gsi_projection,
"ProvisionedThroughput": gsi_provisioned_throughput,
"WarmThroughput": gsi_warm_throughput
}
]
# Define the warm throughput for the table
warm_throughput = {
"ReadUnitsPerSecond": table_warm_reads,
"WriteUnitsPerSecond": table_warm_writes
}
# Create the DynamoDB client and create the table
response = ddb.create_table(
TableName=table_name,
AttributeDefinitions=attribute_definitions,
KeySchema=key_schema,
ProvisionedThroughput=provisioned_throughput,
GlobalSecondaryIndexes=global_secondary_indexes,
WarmThroughput=warm_throughput
)
print(response)
except ClientError as e:
print(f"Error creating table: {e}")
raise e
```
------
#### [ Javascript ]
```
import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";
async function createDynamoDBTableWithWarmThroughput(
tableName,
partitionKey,
sortKey,
miscKeyAttr,
nonKeyAttr,
tableProvisionedReadUnits,
tableProvisionedWriteUnits,
tableWarmReads,
tableWarmWrites,
indexName,
indexProvisionedReadUnits,
indexProvisionedWriteUnits,
indexWarmReads,
indexWarmWrites,
region = "us-east-1"
) {
try {
const ddbClient = new DynamoDBClient({ region: region });
const command = new CreateTableCommand({
TableName: tableName,
AttributeDefinitions: [
{ AttributeName: partitionKey, AttributeType: "S" },
{ AttributeName: sortKey, AttributeType: "S" },
{ AttributeName: miscKeyAttr, AttributeType: "N" },
],
KeySchema: [
{ AttributeName: partitionKey, KeyType: "HASH" },
{ AttributeName: sortKey, KeyType: "RANGE" },
],
ProvisionedThroughput: {
ReadCapacityUnits: tableProvisionedReadUnits,
WriteCapacityUnits: tableProvisionedWriteUnits,
},
WarmThroughput: {
ReadUnitsPerSecond: tableWarmReads,
WriteUnitsPerSecond: tableWarmWrites,
},
GlobalSecondaryIndexes: [
{
IndexName: indexName,
KeySchema: [
{ AttributeName: sortKey, KeyType: "HASH" },
{ AttributeName: miscKeyAttr, KeyType: "RANGE" },
],
Projection: {
ProjectionType: "INCLUDE",
NonKeyAttributes: [nonKeyAttr],
},
ProvisionedThroughput: {
ReadCapacityUnits: indexProvisionedReadUnits,
WriteCapacityUnits: indexProvisionedWriteUnits,
},
WarmThroughput: {
ReadUnitsPerSecond: indexWarmReads,
WriteUnitsPerSecond: indexWarmWrites,
},
},
],
});
const response = await ddbClient.send(command);
console.log(response);
} catch (error) {
console.error(`Error creating table: ${error}`);
throw error;
}
}
```
------
# さまざまなシナリオでの DynamoDB ウォームスループットについて
DynamoDB ウォームスループットを使用する際に直面する可能性のあるさまざまなシナリオを次に示します。
**Topics**
+ [ウォームスループットと不均等なアクセスパターン](#warm-throughput-scenarios-uneven)
+ [プロビジョニングされたテーブルのウォームスループット](#warm-throughput-scenarios-provisioned)
+ [オンデマンドテーブルのウォームスループット](#warm-throughput-scenarios-ondemand)
+ [最大スループットが設定されたオンデマンドテーブルのウォームスループット](#warm-throughput-scenarios-max)
## ウォームスループットと不均等なアクセスパターン
テーブルのウォームスループットは 1 秒あたり 30,000 読み取りユニット、1 秒あたり 10,000 書き込みユニットですが、これらの値に達する前に読み取りまたは書き込みでスロットリングが発生する可能性があります。これは、ホットパーティションが原因である可能性があります。DynamoDB は実質的に無制限のスループットをサポートするようにスケーリングを続けることができますが、個々のパーティションは 1 秒あたり 1,000 書き込みユニットと 1 秒あたり 3,000 読み取りユニットに制限されています。アプリケーションがテーブルのパーティションのごく一部にトラフィックを大量に誘導する場合、テーブルのウォームスループット値に達する前でもスロットリングが発生する可能性があります。シームレスなスケーラビリティを確保し、ホットパーティションを回避するために、[DynamoDB のベストプラクティス](bp-partition-key-design.md)に従うことをお勧めします。
## プロビジョニングされたテーブルのウォームスループット
ウォームスループットが 1 秒あたり 30,000 読み込みユニット、1 秒あたり 10,000 書き込みユニットであるものの、現在のプロビジョンドスループットが 4,000 RCU、8,000 WCU であるプロビジョニング済みテーブルを考えてみましょう。プロビジョンドスループット設定を更新することで、テーブルのプロビジョンドスループットを 30,000 RCU または 10,000 WCU まで即座にスケールできます。プロビジョンドスループットをこれらの値を超えて増やすと、新しいピークスループットが確立されるため、ウォームスループットは自動的に新たなより高い値に調整されます。例えば、プロビジョンドスループットを 50,000 RCU に設定すると、ウォームスループットは 1 秒あたり 50,000 読み込みユニットに増加します。
```
"ProvisionedThroughput":
{
"ReadCapacityUnits": 4000,
"WriteCapacityUnits": 8000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
## オンデマンドテーブルのウォームスループット
新しいオンデマンドテーブルは、1 秒あたり 12,000 読み取りユニット、1 秒あたり 4,000 書き込みユニットのウォームスループットから始まります。テーブルは、これらのレベルまで持続するトラフィックに即座に対応できます。リクエストが 1 秒あたり 12,000 読み込みユニットまたは 1 秒あたり 4,000 書き込みユニットを超えると、ウォームスループットは自動的により高い値に調整されます。
```
"WarmThroughput":
{
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000
}
```
## 最大スループットが設定されたオンデマンドテーブルのウォームスループット
ウォームスループットが 1 秒あたり 30,000 読み込みユニットであるものの、[最大スループット](on-demand-capacity-mode-max-throughput.md)が 5,000 読み込みリクエストユニット (RRU) に設定されているオンデマンドテーブルを考えてみましょう。このシナリオでは、テーブルのスループットは、設定した最大 5,000 RRU に制限されます。この最大値を超えるスループットリクエストはスロットリングされます。ただし、テーブル別の最大スループットは、アプリケーションのニーズに基づいていつでも変更できます。
```
"OnDemandThroughput":
{
"MaxReadRequestUnits": 5000,
"MaxWriteRequestUnits": 4000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
# DynamoDB バーストキャパシティとアダプティブキャパシティ
スループット例外に伴うスロットリングを最小限に抑えるために、DynamoDB は*バーストキャパシティ*を使用して使用量のスパイクを処理します。DynamoDB は、*アダプティブキャパシティ*を使用して、アクセスパターンの不均衡に対応できるようにします。
## バーストキャパシティ
DynamoDB は、*バーストキャパシティ*により、スループットプロビジョニングに柔軟性をもたらします。利用可能なスループットを使い切っていない場合、DynamoDB は、キャパシティの未使用分を、後のスループットの*バースト*に備えて留保しておき、使用量のスパイクに対応します。バーストキャパシティーにより、スロットリングされていた可能性のある読み込みまたは書き込みリクエストが成功します。
現在、DynamoDB は、未使用の読み込みおよび書き込みキャパシティを最大 5 分 (300 秒) 保持します。読み込みまたは書き込みアクティビティのバーストが発生した場合、これらの余分なキャパシティユニットをすばやく消費できます。これは、テーブルに定義した 1 秒あたりのプロビジョンドスループットキャパシティよりも高速です。
また、DynamoDB はバックグラウンドメンテナンスやその他のタスクのために予告なしにバーストキャパシティを消費する場合があります。
これらのバーストキャパシティの詳細は将来変更される可能性があります。
## アダプティブキャパシティ
DynamoDB では、[パーティション](HowItWorks.Partitions.md)間にデータを自動的に分散します。これらは、AWS クラウドの複数のサーバーに保存されます。読み込みおよび書き込みアクティビティは常に均等に分散できるとは限りません。データアクセスが不均等の場合は、他のパーティションと比較して、「ホット」パーティションに大容量の読み書きトラフィックが送信されることがあります。パーティションの読み込みおよび書き込みオペレーションは個別に管理されるため、単一のパーティションが 3,000 を超える読み込みオペレーションまたは 1,000 を超える書き込みオペレーションを受け取ると、スロットリングが発生します。アダプティブキャパシティーでは、さらに多くのトラフィックを受け取るパーティションのスループットキャパシティーを自動的に増加させます。
不均等なアクセスパターンに対応できるように、DynamoDB アダプティブキャパシティを使用することで、スロットリングすることなく、アプリケーションでホットパーティションに対して読み書きを継続できます。ただし、トラフィックは、プロビジョニングされた合計容量またはパーティションの最大容量を超えないものとします。アダプティブキャパシティでは、さらに多くのトラフィックを受け取るパーティションのスループットキャパシティを自動的かつ瞬時に増加させます。
次の図は、アダプティブキャパシティの機能を示しています。このテーブルの例のプロビジョニングでは、4 つのパーティション間で 400 WCU が均等に共有されることで、各パーティションで 1 秒間に最大 100 WCU を維持できます。パーティション 1、2、3 はそれぞれ、50 WCU/秒の書き込みトラフィックを受け取ります。パーティション 4 は 150 WCU/秒の書き込みトラフィックを受け取ります。このホットパーティションは、未使用のバーストキャパシティがある場合でも書き込みトラフィックを受け入ることができます。しかし、最終的には 1 秒間に 100 WCU を超えるトラフィックのスロットリングとなります。
DynamoDB アダプティブキャパシティは、パーティション 4 のキャパシティを増大して応答するため、このパーティションはスロットリングされることなく、150 WCU/秒のより高いワークロードを維持できます。
![\[アダプティブキャパシティは、スロットリングを避けるために、トラフィックがより多いパーティション 4 のスループットを自動的に増やします。\]](http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/images/adaptive-capacity.png)
アダプティブキャパシティはすべての DynamoDB テーブルで自動的に有効化されます。追加料金はありません。アダプティブキャパシティを明示的に有効化または無効化する必要はありません。
### アクセス頻度の高い項目を分離する
お使いのアプリケーションが 1 つ以上の項目に偏った高いトラフィックを送る場合、アクセス頻度の高い項目が同一パーティション内に存在しないように、アダプティブキャパシティによってパーティションのバランスが再調整されます。アクセス頻度の高い項目を分離することで、ワークロードが単一のパーティションのスループットクォータを超えることから生じるリクエストのスロットリングの可能性が低くなります。ソートキーの単調な増減によって追跡されるトラフィックが項目のコレクションでない限り、項目のコレクションをソートキー別にセグメントに分割することもできます。
アプリケーションから単一の項目に大量のトラフィックが一貫して送信される場合、アダプティブキャパシティはデータを再調整して、そのアクセス頻度の高い単一の項目のみをパーティションに含めることがあります。この場合、DynamoDB では、単一項目のプライマリキーに対して、最大 3,000 RCU および 1,000 WCU のパーティションのスループットを提供できます。アダプティブキャパシティでは、テーブルに[ローカルセカンダリインデックス](LSI.md)がある場合、テーブルの複数のパーティション間で項目コレクションを分割しません。
# DynamoDB でキャパシティモードを切り替える際の考慮事項
DynamoDB テーブルを作成する場合、オンデマンドまたはプロビジョンドキャパシティモードのいずれかを選択する必要があります。
24 時間のローリングウィンドウで、テーブルをプロビジョンドキャパシティモードからオンデマンドモードに最大 4 回切り替えることができます。テーブルは、オンデマンドモードからプロビジョンドキャパシティモードにいつでも切り替えることができます。
**Topics**
+ [プロビジョンドキャパシティモードからオンデマンドキャパシティモードへの切り替え](#switch-provisioned-to-ondemand)
+ [オンデマンドキャパシティモードからプロビジョンドキャパシティモードへの切り替え](#switch-ondemand-to-provisioned)
## プロビジョンドキャパシティモードからオンデマンドキャパシティモードへの切り替え
プロビジョンドモードでは、予想されるアプリケーションのニーズに基づいて読み込みおよび書き込みキャパシティを設定します。テーブルをプロビジョニングモードからオンデマンドモードに更新するときは、アプリケーションで実行することが予測される読み込みおよび書き込みスループットを指定する必要はありません。DynamoDB オンデマンドは、読み込みおよび書き込みリクエストの料金が従量制であるため、使用した分だけを支払います。これにより、コストとパフォーマンスのバランスを簡単に取ることができます。オプションで、個々のオンデマンドテーブルおよび関連するグローバルセカンダリインデックスの読み込みや書き込み (または両方) の最大スループットを設定して、コストと使用量を制限し続けることができます。特定のテーブルやインデックスの最大スループットの設定の詳細については、「[オンデマンドテーブルの DynamoDB 最大スループット](on-demand-capacity-mode-max-throughput.md)」を参照してください。
プロビジョンドキャパシティモードからオンデマンドキャパシティモードに切り替えると、DynamoDB は、テーブルやパーティションの構造にいくつかの変更を行います。この処理には数分かかることもあります。切り替え期間中、テーブルは以前にプロビジョニングされた書き込みキャパシティーユニットおよび読み込みキャパシティーユニットの両方と整合性のあるスループットを提供します。
### オンデマンドキャパシティモードの初期スループット
最近、既存のテーブルをオンデマンドキャパシティモードに初めて切り替えた場合、テーブルがオンデマンドキャパシティモードを使用してトラフィックを以前に処理していなくても、テーブルは次に示す以前のピーク設定を持ちます。
考えられるシナリオの例を以下に示します。
+ **4,000 の WCU と 12,000 の 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 の読み込みユニット/秒を維持できます。
### 自動スケーリング設定
テーブルをプロビジョニングモードからオンデマンドモードに更新すると、以下のようになります。
+ コンソールを使用している場合、Auto Scaling 設定 (ある場合) がすべて削除されます。
+ AWS CLI または AWS SDK を使用している場合、Auto Scaling 設定はすべて保持されます。これらの設定は、テーブルをもう一度プロビジョニングされた請求モードに更新すると適用できます。
### [DynamoDB コンソール](https://console.aws.amazon.com/dynamodb)でのキャパシティモードの一括編集
[DynamoDB コンソール](https://console.aws.amazon.com/dynamodb)を使用して、複数のテーブルを一括編集して、プロビジョンドキャパシティモードからオンデマンドキャパシティモードに切り替えることができます。キャパシティモードを一括編集するには。
1. DynamoDB コンソールで **[テーブル]** ページに移動します。
1. オンデマンドキャパシティモードに更新するテーブルのチェックボックスをオンにします。
1. **[アクション]** を選択し、**[オンデマンドキャパシティモードへの更新]** を選択します。
この一括オペレーションにより、各テーブルを個別に更新することなく、複数のテーブルをオンデマンドキャパシティモードに効率的に切り替えることができます。
## オンデマンドキャパシティモードからプロビジョンドキャパシティモードへの切り替え
オンデマンドキャパシティーモードからプロビジョンドキャパシティーモードに戻すと、テーブルは、テーブルがオンデマンドキャパシティーモードに設定されたときに到達した前のピークと整合性のあるスループットを提供します。
### 容量の管理
テーブルをオンデマンドモードからプロビジョニングモードに更新するときは、以下の点を考慮に入れてください。
+ AWS CLI または AWS SDK を使用している場合、Amazon CloudWatch を使用して消費履歴 (`ConsumedWriteCapacityUnits` および `ConsumedReadCapacityUnits` メトリクス) を参照し、新しいスループット設定を決定することで、テーブルおよびグローバルセカンダリインデックスのプロビジョンされた適切な容量設定を選択します。
**注記**
グローバルテーブルからプロビジョニングモードに切り替える場合、すべてのリージョンレプリカにわたって基本テーブルおよびグローバルセカンダリインデックスの最大消費量を調べた上で、新しいスループット設定を決定します。
+ オンデマンドモードからプロビジョンドモードに戻す場合は、移行中にテーブルまたはインデックスのキャパシティを処理できるように、最初のプロビジョンドユニットを十分高い値に設定してください。
### Auto Scaling の管理
テーブルをオンデマンドモードからプロビジョニングモードに更新すると、以下のようになります。
+ コンソールを使用する場合は、以下のデフォルトで自動スケーリングを有効にすることをお勧めします。
+ 目標使用率: 70%
+ プロビジョニングされた最小キャパシティー: ユニット 5 個
+ プロビジョニングされた最大キャパシティー: リージョンの最大値
+ AWS CLI または SDK を使用している場合、前の Auto Scaling 設定 (ある場合) が保持されます。