Amazon DynamoDBのキャパシティモードと読み書き性能

Amazon DynamoDBでは、テーブルとインデックスの読み込み・書き込み性能をどのように用意し、その利用に対してどのように課金するかをキャパシティモードで選択します。需要の見通しが立ちにくいアプリケーションでは要求量に応じるオンデマンドを、通常時の負荷を見積もりやすく利用率も高く保てるワークロードではプロビジョンドを検討できます。

たとえば、イベント受付サービスでは、平常時は一定数の申込みを処理していても、受付開始時刻に読み書きが集中することがあります。平均的な負荷だけで設定を決めるのではなく、ピークの予測可能性、要求の増え方、未使用キャパシティに対する費用、スロットリングの許容度を合わせて判断します。

キャパシティモードの選択

観点	オンデマンド	プロビジョンド
キャパシティの指定	読み書きキャパシティを事前に指定せず、要求に応じてサービスが対応する	読み込み・書き込みのキャパシティを設定する
課金の考え方	実行した読み書き要求の量を基準にする	設定したキャパシティを利用時間に応じて課金する
向いているワークロード	需要が予測しにくい、新規で使用量が分からない、利用に大きな変動がある	需要が比較的予測可能で、必要キャパシティを計画できる
運用上の考慮	キャパシティ値の調整は不要だが、リクエスト量が増えれば料金も増える	使用量に合わせて設定しないと、過剰な設定による費用や不足によるスロットリングが起きる

オンデマンドは「無制限の処理能力を常に保証する」という意味ではありません。急なトラフィック増加やテーブルの直近の利用状況によっては、要求がスロットリングされる可能性があります。トラフィックの予測が難しい場合にキャパシティ設定の負担を減らす選択肢ですが、アプリケーション側のリトライ設計、負荷の観測、ピークに備えた計画は引き続き必要です。

プロビジョンドは、キャパシティをあらかじめ設定して要求を受け付ける方法です。使用量を予測できる場合に費用を計画しやすく、オートスケーリングを組み合わせれば利用状況に合わせて設定を調整できます。ただし、設定した量を使い切らなくてもキャパシティに対する料金が発生し、必要量を超える要求はスロットリングの対象になります。

キャパシティユニットと計算の基礎

プロビジョンドモードでは、**読み込みキャパシティユニット（RCU）と書き込みキャパシティユニット（WCU）**で性能を表します。RCUは1秒あたりの読み込み能力、WCUは1秒あたりの書き込み能力を示します。計算ではアイテムサイズを一定の単位で切り上げるため、アイテムがわずかに境界を超えただけでも必要量が増えることがあります。

オンデマンドモードでは、プロビジョンドのように毎秒のRCU/WCUを設定しません。代わりに、読み込みリクエストユニット（RRU）と書き込みリクエストユニット（WRU）を使って、リクエストごとの消費量を扱います。計算の単位は似ていますが、プロビジョンドは設定した毎秒の容量、オンデマンドは実行した要求量に対する課金という違いがあります。

読み込み

最大4KBのアイテムを1回読み込む場合、強い整合性読み込みは1 RCU、結果整合性読み込みは0.5 RCU、トランザクション読み込みは2 RCUを消費します。これは1秒あたりの要求として処理する場合の目安です。4KBを超えるアイテムは4KB単位で切り上げ、1秒に処理する読み込み回数に応じて必要な容量を計算します。

最大4KBのアイテムを1秒間に1回読む	プロビジョンドで消費するRCU	オンデマンドで消費するRRU
強い整合性読み込み	1	1
結果整合性読み込み	0.5	0.5
トランザクション読み込み	2	2

たとえば、アイテムサイズが5KBの受付記録を1秒に1回読み込む場合、サイズは4KBの読み込み単位2つに切り上げます。そのため、強い整合性なら2 RCU、結果整合性なら1 RCU、トランザクション読み込みなら4 RCUが必要です。オンデマンドでは同じサイズと整合性の組み合わせがRRUの消費量になります。

読み込み時の整合性は、必要な最新性とキャパシティ消費の両方に関わります。結果整合性読み込みは、直前の書き込みがすぐ反映されない場合がある代わりに、同じサイズの強い整合性読み込みより少ないユニットで処理できます。強い整合性読み込みはテーブルとローカルセカンダリインデックスで利用できますが、グローバルセカンダリインデックスでは利用できません。常に最新の書き込み結果を必要とするのか、短い遅延を許容できるのかをアクセスパターンごとに決めます。

書き込み

書き込みはアイテムサイズを1KB単位で切り上げます。プロビジョンドモードでは1KBまでのアイテムを書き込むごとに1 WCUを消費し、トランザクション書き込みは同じサイズの通常書き込みの2倍を消費します。オンデマンドでは同じ考え方をWRUで数えます。

1KBまでのアイテムを1秒間に1回書く	プロビジョンドで消費するWCU	オンデマンドで消費するWRU
通常の書き込み	1	1
トランザクション書き込み	2	2

前述の5KBの受付記録を書き込む場合、通常の書き込みには5 WCU、トランザクション書き込みには10 WCUが必要です。サイズが1KBを少しでも超えるアイテムは、次の1KB単位に切り上げます。

読み込みには強い整合性または結果整合性を選ぶ仕組みがありますが、書き込みでは同じ選択をしません。強い整合性は読み込み結果の新しさを指定するオプションです。書き込みの後に最新値を確認したい場合は、その読み込みでサポート対象のテーブルまたはインデックスに対して強い整合性読み込みを選びます。

計算時に確認すること

• アイテムサイズはキー属性だけでなく、属性名や属性値などを含むアイテム全体で見積もる。
• 読み込みは4KB単位、書き込みは1KB単位で切り上げる。
• トランザクション処理は通常の処理より多くのキャパシティを必要とする。
• 必要キャパシティはサイズだけでなく、1秒あたりの要求数と読み込みの整合性に応じて計算する。
• クエリやスキャンでは、返却されたデータ量ではなく読み込まれたアイテムなどに基づいてキャパシティが消費される場合がある。フィルターで結果を減らしても、読み込みコストが同じ割合で減るとは限らない。

実際の請求には、キャパシティモードのほか、テーブルとインデックスの設定、バックアップ、データ転送などが関係することがあります。料金の単価はリージョンや利用条件で変わるため、固定額ではなくAmazon DynamoDBの料金ページで最新情報を確認します。

プロビジョンドキャパシティのオートスケーリング

プロビジョンドモードでは、AWS Application Auto Scalingの仕組みを使って、テーブルやグローバルセカンダリインデックスの読み書きキャパシティを自動調整できます。スケーリングの最小値と最大値、目標使用率を設定すると、DynamoDBはCloudWatchの使用状況を基にキャパシティを増減させます。

固定値だけを使う場合、実際の使用量が少なければ設定キャパシティの一部が余り、使用量が設定値に近づきすぎれば、要求の一部がスロットリングされる可能性があります。オートスケーリングは、定めた範囲で設定を需要に近づけ、余剰を抑えつつ不足を減らすための仕組みです。最小値と最大値を適切に設けることが前提となります。

オートスケーリングは、リクエストが到着するたびに容量を即座に増やす仕組みではありません。メトリクスの観測とスケーリング処理には時間がかかるため、負荷が急に跳ね上がると新しい設定が適用される前にキャパシティを使い切ることがあります。突発的な要求増加が予想されるときは、ピークに備えた余裕を設定する、負荷を段階的に立ち上げる、リトライを実装する、または需要変動の性質に応じてオンデマンドを選ぶなど、別の備えも検討します。

キャパシティ不足とスロットリング

プロビジョンドモードで使用量が設定キャパシティを超えると、要求がスロットリングされることがあります。利用者側から見ると読み書きの失敗や遅延として現れるため、アプリケーションの再試行方針とCloudWatchメトリクスを確認します。短い一時的な制限には指数バックオフを含む再試行が有効なことがありますが、継続的な不足をリトライだけで解消することはできません。設定キャパシティ、オートスケーリングの上限、キーに集中するアクセス、需要予測を確認して原因を解消します。

使用率の高まりに合わせてオートスケーリングが容量を増やしても、要求量の上昇に追従できない時間が生じる場合があります。オートスケーリングを有効にしたことだけで容量不足が起きないと考えず、平常時とピーク時の両方を監視し、最大値が想定ピークに達していないかも確認します。

試験での選択の考え方

問題文に示された状況	検討する選択
利用量がまだ分からず、需要も予測しにくい	読み書き要求に応じるオンデマンドモード
安定した負荷を予測でき、キャパシティを計画したい	プロビジョンドモード
プロビジョンドの利用量が時間帯で変化する	最小値・最大値と目標使用率を定めたオートスケーリング
突然のアクセス集中でオートスケーリングの反映が間に合わない	ピークに向けた余裕の確保、負荷の段階化、再試行設計、または負荷特性に合ったモード
読み込み時に書き込み直後の最新値が必要	対応するテーブルまたはローカルセカンダリインデックスで強い整合性読み込みを使う
同じサイズの読み込みでキャパシティ消費を抑えたい	許容可能な場合は結果整合性読み込みを検討する

プロビジョンドは「利用率が高くても料金が一定」という意味ではなく、設定したキャパシティを基準に課金されます。利用率が低いと余剰分の費用が生じ、設定が需要を下回るとスロットリングのリスクがあります。オンデマンドは要求量に応じてキャパシティ管理を簡略化しますが、要求が増えた分だけ料金も増加します。どちらもアクセスパターンと運用要件を踏まえて選びます。

AWS公式ドキュメント

• DynamoDBの読み込み/書き込みキャパシティモード
• 読み込みおよび書き込みオペレーション
• DynamoDBの読み込みおよび書き込みキャパシティユニットの計算
• DynamoDBのオートスケーリング
• DynamoDBの料金

関連トピック

• Amazon DynamoDBの基本とデータモデル
• DynamoDBのキー設計・インデックス・キャパシティ（SAA）
• DynamoDBの整合性・ストリーム・グローバルテーブル・バックアップ（SAA）