プロビジョンドキャパシティとオンデマンドキャパシティ

DynamoDBでは、スループットを読み取りキャパシティユニット（RCU）と書き込みキャパシティユニット（WCU）で測定します。1 RCUでは、最大4 KBのアイテムに対して、1秒あたり1回の強い整合性読み取り（または2回の結果整合性読み取り）が可能です。1 WCUでは、最大1 KBのアイテムに対して、1秒あたり1回の書き込みが可能です。

アイテムが大きい場合、コストは比例して増加します。10 KBの書き込みには10 WCU、10 KBの強い整合性読み取りには3 RCU（ceil(10/4) = 3）が必要です。キャパシティユニットを理解することは、コストの見積もりやProvisionedThroughputExceededExceptionによるスロットリングエラーの診断に不可欠です。

Provisioned Capacityモードでは、テーブルでサポートするRCUとWCUの正確な数を指定します。DynamoDBはそのスループットを確保し、実際に使用したかどうかにかかわらず料金を請求します。アプリケーションがプロビジョンドキャパシティを超えると、リクエストはスロットリングされ、ProvisionedThroughputExceededExceptionが返されます。

プロビジョンドモードは、予測可能で安定したトラフィックのワークロードに適しています。ユニット単位のコストはOn-Demandモードより低く、さらにDynamoDB Reserved Capacity（1年または3年の契約で最大76%割引）を購入してコストを削減できます。

On-Demandモードでは、キャパシティプランニングなしで、DynamoDBがあらゆるレベルのトラフィックに対応できるよう自動的にスケールします。実際に消費したリクエスト単位（読み取りリクエストユニット（RRU）と書き込みリクエストユニット（WRU））ごとに料金を支払います。管理が必要なプロビジョンドキャパシティはなく、プロビジョンド上限によるスロットリングも発生しません。

On-Demandモードは、予測不能または急増するワークロード、新しいテーブルでトラフィックが不明な場合、アクセス頻度の低い開発・テスト環境に適しています。リクエスト単位のコストはプロビジョンドより高いため、安定した高スループットのワークロードではプロビジョンドモードのほうが経済的です。

コンソールまたはCLIを使用して、テーブルをProvisionedモードとOn-Demandモードの間でいつでも切り替えられます。ただし、モードを切り替えられるのは24時間に1回だけです。On-Demandに切り替えた後も、テーブルは以前のプロビジョンドキャパシティのピーク値を初期スループットレベルとして保持します。これにより、すでにトラフィックが多い場合でも、直ちにスロットリングされるのを防げます。

よくある戦略は、トラフィックパターンが不明な初期リリース時にはOn-Demandを使用し、トラフィックが予測可能になったらAuto Scaling付きのProvisionedに切り替えて、コストを削減する方法です。

DynamoDBのAuto Scalingは、実際のトラフィックに応じてプロビジョンドRCUとWCUを自動的に調整します。目標使用率（例：70%）と、最小・最大キャパシティの範囲を定義します。Application Auto Scalingのポリシーがテーブルの消費キャパシティを監視し、目標使用率を維持するようプロビジョンドキャパシティを調整します。

Auto Scalingは継続的なトラフィックの変化に対応しますが、スケールアップには数分かかることがあります。急激なトラフィックのスパイクへの対応は得意ではないため、その場合は手動で事前にキャパシティを確保するか、On-Demandモードを使用してください。

DynamoDBは、未使用のプロビジョンドキャパシティを最大5分間分、バーストキャパシティとして保持します。テーブルのトラフィックが一時的にプロビジョンドレベルを超えると、DynamoDBはバーストプールからキャパシティを使用し、スロットリングなしで追加のリクエストを処理します。バーストプールを使い切ると、それ以降の超過リクエストはスロットリングされます。

バーストキャパシティは短期的なバッファであり、適切なキャパシティプランニングの代わりにはなりません。ConsumedReadCapacityUnitsとConsumedWriteCapacityUnitsのCloudWatchメトリクスを監視し、ワークロードが継続的にバーストキャパシティを消費していることを検知したら、プロビジョンドスループットを適切に調整してください。

プロビジョンドキャパシティを超え、バーストも使い果たすと、DynamoDBはProvisionedThroughputExceededExceptionを返します。AWS SDKには、指数バックオフとジッターを使用した組み込みのリトライロジックがあり、スロットリングされたリクエストを自動的に再試行します。

スロットリングを診断するには、SystemErrorsとThrottledRequestsのCloudWatchメトリクスを確認します。テーブル全体の使用率が低いにもかかわらず、特定のパーティションキーでスロットリングが発生している場合は、ホットパーティションの問題です。パーティションキーを再設計する、ソートキーを追加する、または書き込みシャーディングを使用してください。

Provisionedモードのキャパシティを見積もるには、次の計算を行います。

• ピーク時の1秒あたりの書き込み数 × 平均アイテムサイズ / 1 KB（切り上げ） = 必要なWCU
• ピーク時の1秒あたりの読み取り数 × 平均アイテムサイズ / 4 KB（切り上げ） = 必要なRCU（強い整合性）。結果整合性の場合は半分
• バーストを使い切る前にスパイクを吸収できるよう、ピーク値に20～30%の余裕を追加

例：2 KBのアイテムを毎秒1,000件書き込む場合、2,000 WCUが必要です。8 KBのアイテムを毎秒5,000件、結果整合性で読み取る場合、ceil(8/4) × 5,000 / 2 = 5,000 RCUが必要です。

DynamoDB Reserved Capacityでは、1年または3年の期間で一定数のRCUとWCUを購入できます。前払いすることで、On-Demand料金と比べて最大76%の大幅な割引を受けられます。Reserved Capacityは、リージョン内のすべてのプロビジョンドテーブルに適用され、時間単位の料金に自動的に反映されます。

Reserved CapacityはProvisionedモードにのみ適用され、On-Demandモードでは使用できません。1～3年先まで自信を持って予測できる、安定した予測可能なワークロードに最適なコスト削減策です。

SAA-C03のキャパシティモードに関する問題では、次の判断ガイドを使用してください。

• On-Demand：予測不能なトラフィック、新しいアプリケーション、アクセス頻度の低い環境、バースト性のワークロード、キャパシティ管理を完全になくしたい場合
• Provisioned：一貫して予測可能なトラフィック、コスト重視、キャパシティ管理が可能、Reserved Capacityの割引対象にしたい場合
• Provisioned + Auto Scaling：予測可能なベースラインにある程度の変動があり、手動変更なしで自動調整したい場合

試験では、'spiky'、'unpredictable'、'minimal operational overhead'などのキーワードはOn-Demandを、'steady traffic'や'cost optimisation'はProvisionedを示します。

DynamoDBのAdaptive Capacityは、使用率の低いパーティションからホットパーティションへスループットをリアルタイムに自動再配分します。あるパーティションキーが割り当てられた割合を超えるトラフィックを受けている場合、テーブル全体のキャパシティを超えない範囲で、アダプティブキャパシティが使用率の低いパーティションからスループットを借りて、負荷の高いパーティションに割り当てます。

アダプティブキャパシティは常に有効で、設定は必要ありません。アクセスパターンにある程度の偏りがある場合、ホットパーティションによるスロットリングを軽減します。ただし、極端に偏ったワークロード（例：1つのパーティションキーにトラフィックの90%が集中する場合）には不十分です。パーティションキーを再設計するか、書き込みシャーディングを使用する必要があります。

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

このレッスンでは、Provisionedモードは固定のRCU/WCUを設定し、予測可能なワークロードを低コストで処理できること、On-Demandモードは自動的にスケールし、予測不能なトラフィックに対応できる一方でリクエスト単位の料金が高いこと、そしてAuto Scalingは目標使用率に基づいてプロビジョンドキャパシティを調整することを学びました。次は、別のクエリパターンに対応するGlobal Secondary IndexとLocal Secondary Indexについて説明します。