概要

DynamoDBのキャパシティユニット計算は、コスト最適化とパフォーマンス設計の要です。結果整合性読み取りと強い整合性読み取りでRCU消費量が2倍異なる理由や、WCUの計算ロジックを具体例とともに解説します。実務で使える計算式と注意点を紹介します。

目次

はじめに
読み取り整合性モデルの理解
RCU（Read Capacity Unit）の計算方法
WCU（Write Capacity Unit）の計算方法
実践的な計算シミュレーション
ベストプラクティスと注意点
終わりに
参考文献・参考サイト

1. はじめに

DynamoDBを本番環境で運用する際、キャパシティユニットの正確な計算は避けて通れません。過剰にプロビジョニングすればコストが無駄になり、不足すればスロットリングが発生してユーザー体験を損ないます。

本記事では、RCU（読み取りキャパシティユニット）とWCU（書き込みキャパシティユニット）の計算方法を、具体的な数値例を用いて解説します。特に、結果整合性読み取りと強い整合性読み取りの違いが、なぜRCU消費量に2倍の差を生むのか、その技術的背景も含めて理解を深めていきましょう。

2. 読み取り整合性モデルの理解

DynamoDBには2つの読み取り整合性モデルがあります。この違いを理解することが、RCU計算の第一歩です。

2.1 DynamoDBのデータレプリケーション

DynamoDBは同一リージョン内の3つのアベイラビリティーゾーンに自動的にデータをレプリケーションします。この仕組みにより高可用性を実現していますが、3箇所への複製には時間差が生じます。

2.2 結果整合性読み取り（Eventually Consistent Read）

結果整合性のある読み込みは、すべての読み取りオペレーションのデフォルトの読み込み整合性モデルです。最近完了した書き込みオペレーションの結果が応答に反映されない場合があります。

特徴：

デフォルトの読み取りモード
3箇所のレプリカのうち、どこから読み取るかは不定
書き込み直後に読み取ると、古いデータが返る可能性がある
通常1秒以内にすべてのコピーの整合性が取れます
RCU消費量が半分（4KB/秒・2回）

たとえるなら、3つの図書館に同じ本の最新版を配送する際、配送中は古い版が置かれている図書館があるイメージです。どの図書館で借りるかは選べないため、運が悪いと古い版を手にする可能性があります。

2.3 強い整合性読み取り（Strongly Consistent Read）

ConsistentReadをtrueに設定すると、DynamoDBは、成功した以前のすべての書き込みオペレーションからの更新を反映した、最新データを含む応答を返します。

特徴：

オプションで指定する必要がある（ConsistentRead=True）
必ず最新のデータが取得できる
内部的には複数のレプリカを確認して整合性を保証
RCU消費量が2倍（4KB/秒・1回）
グローバルセカンダリインデックス（GSI）では利用不可

2.4 なぜRCU消費量が2倍になるのか

DynamoDBは、書き込み時に3箇所のうち2箇所に成功した時点で書き込み完了（HTTP 200）を返します。強い整合性読み取りでは、複数のレプリカから値を読み取り、一致すればその値を、一致しなければもう1箇所の値も読んで2箇所に書き込まれている値を返します。

この複数ノードへのアクセスと検証プロセスが、RCU消費量を2倍にする理由です。データの正確性を保証するためのトレードオフと言えます。

3. RCU（Read Capacity Unit）の計算方法

3.1 RCUの基本定義

整合性モデル	4KBあたりの処理能力	RCU消費量
結果整合性読み取り	1秒間に2回	1RCU
強い整合性読み取り	1秒間に1回	2RCU（結果整合性の2倍）

3.2 計算式

結果整合性読み取りの場合：

必要なRCU = ⌈アイテムサイズ / 4KB⌉ × 読み取り回数/秒 / 2

強い整合性読み取りの場合：

必要なRCU = ⌈アイテムサイズ / 4KB⌉ × 読み取り回数/秒

※ ⌈ ⌉は切り上げを表します

3.3 具体的な計算例

例1：2KBのアイテムを結果整合性で100回/秒読み取る

ステップ1：アイテムサイズの単位計算
⌈2KB / 4KB⌉ = ⌈0.5⌉ = 1単位

ステップ2：RCU計算
1単位 × 100回/秒 / 2 = 50RCU

例2：8KBのアイテムを強い整合性で50回/秒読み取る

ステップ1：アイテムサイズの単位計算
⌈8KB / 4KB⌉ = 2単位

ステップ2：RCU計算
2単位 × 50回/秒 = 100RCU

例3：5KBのアイテムを結果整合性で200回/秒読み取る（端数の切り上げ）

ステップ1：アイテムサイズの単位計算
⌈5KB / 4KB⌉ = ⌈1.25⌉ = 2単位

ステップ2：RCU計算
2単位 × 200回/秒 / 2 = 200RCU

重要：4KBを1バイトでも超えると、2単位とカウントされます。これはコスト最適化の観点から非常に重要です。

例4：同じ5KBのアイテムを強い整合性で読み取る場合

ステップ1：アイテムサイズの単位計算
⌈5KB / 4KB⌉ = 2単位

ステップ2：RCU計算
2単位 × 200回/秒 = 400RCU

結果整合性（200RCU）と比較して、ちょうど2倍の400RCUが必要になります。

4. WCU（Write Capacity Unit）の計算方法

4.1 WCUの基本定義

1WCUは、最大1KBのアイテムを1秒間に1回書き込む能力を提供します。読み取りと異なり、書き込みには整合性モデルの選択肢はありません。

アイテムサイズ	書き込み回数/秒	必要なWCU
1KB以下	1回	1WCU
2KB	1回	2WCU
1KB	100回	100WCU

4.2 計算式

必要なWCU = ⌈アイテムサイズ / 1KB⌉ × 書き込み回数/秒

4.3 具体的な計算例

例1：0.5KBのアイテムを100回/秒書き込む

ステップ1：アイテムサイズの単位計算
⌈0.5KB / 1KB⌉ = 1単位

ステップ2：WCU計算
1単位 × 100回/秒 = 100WCU

1KB未満のアイテムでも1WCUとしてカウントされる点に注意が必要です。

例2：3.5KBのアイテムを50回/秒書き込む

ステップ1：アイテムサイズの単位計算
⌈3.5KB / 1KB⌉ = 4単位

ステップ2：WCU計算
4単位 × 50回/秒 = 200WCU

例3：10KBのアイテムを20回/秒書き込む

ステップ1：アイテムサイズの単位計算
⌈10KB / 1KB⌉ = 10単位

ステップ2：WCU計算
10単位 × 20回/秒 = 200WCU

5. 実践的な計算シミュレーション

5.1 ユースケース別の必要キャパシティ

以下は、典型的なアプリケーションシナリオでの計算例です。

ユースケース	アイテムサイズ	読み取り	書き込み	整合性	必要RCU	必要WCU
ユーザープロフィール照会	2KB	500回/秒	10回/秒	結果整合性	250	20
在庫管理システム	1KB	100回/秒	50回/秒	強い整合性	100	50
ログ記録	5KB	10回/秒	1000回/秒	結果整合性	10	5000
リアルタイムゲームスコア	0.5KB	2000回/秒	500回/秒	強い整合性	2000	500

5.2 コスト試算（東京リージョン）

東京リージョン（ap-northeast-1）のプロビジョンドモードにおける料金は、1RCUあたり0.0001484USD/時間、1WCUあたり0.000742USD/時間です（2024年時点）。

計算例：在庫管理システム（100RCU、50WCU）

月間時間数 = 24時間 × 30.5日 = 732時間

RCUコスト = 100RCU × 0.0001484USD/時間 × 732時間 
         = 10.86USD/月

WCUコスト = 50WCU × 0.000742USD/時間 × 732時間 
         = 27.17USD/月

合計 = 38.03USD/月（約5,700円、1ドル=150円換算）

重要な注意点：

プロビジョンドモードでは、実際の使用量に関わらず、設定したキャパシティ分の料金が発生します
使用パターンが予測可能な場合、オンデマンドモードよりもコストを抑えられます
毎月25RCU・25WCUまでは無料枠が適用されます（アカウント・リージョンごと）

6. ベストプラクティスと注意点

6.1 キャパシティの適切な設計

アイテムサイズの最適化：

4KBと5KBの境界に注意：5KBのアイテムは4KBのアイテムの2倍のRCUを消費します
1KBと1.1KBの境界に注意：1.1KBのアイテムは1KBのアイテムの2倍のWCUを消費します
大きなデータはS3に保存し、DynamoDBにはパスのみ格納する設計を検討しましょう

整合性モデルの使い分け：

デフォルトは結果整合性（コスト半分）を使用
以下の場合のみ強い整合性を検討：
- 金融取引など、絶対に最新データが必要な場合
- 書き込み直後の読み取りで整合性が必須の場合
- 在庫数など、古いデータが業務に影響する場合

6.2 バースト対応とオートスケーリング

DynamoDBにはバーストキャパシティという仕組みがあり、短時間の急激なアクセス増に対応できます。ただし、これに頼らず、Auto Scalingの設定を推奨します。

最小キャパシティ: 予測される最低使用量
最大キャパシティ: 予測される最大使用量の1.5倍程度
目標使用率: 70%（スロットリングを避けつつコストを抑える）

6.3 コスト最適化のヒント

不要なテーブルの削除：AWS CDKでデフォルト作成されたテーブルは5RCU/5WCUが設定され、使用していなくても月額約3.2USDのコストが発生します
GSIの最小化：GSIもテーブルと独立してキャパシティを消費します
リザーブドキャパシティの活用：1年または3年のコミットで最大76%のコスト削減が可能
CloudWatch監視：実際の消費量を定期的に確認し、過剰プロビジョニングを避ける

6.4 制限事項の理解

グローバルセカンダリインデックス（GSI）では強い整合性読み取りはサポートされていません。GSIを使用したクエリでは、必ず結果整合性読み取りになります。

また、ネットワークの遅延または停止があった場合、強い整合性読み取りではHTTP 500エラーが返される可能性があります。このため、アプリケーション側でリトライロジックを実装することが重要です。

7. 終わりに

本記事では、DynamoDBのキャパシティユニット（RCU/WCU）の計算方法を、結果整合性と強い整合性の違いを含めて解説しました。

重要なポイントのまとめ：

結果整合性読み取りは強い整合性の半分のコスト（4KB/秒・2回 vs 4KB/秒・1回）
強い整合性は複数レプリカの確認により2倍のRCUを消費
書き込みは整合性モデルの選択肢なし（1WCU = 1KB/秒・1回）
アイテムサイズの境界値（4KB、1KB）を意識した設計が重要
実際の使用量を監視し、継続的に最適化

次のステップ

CloudWatch Metricsの設定：ConsumedReadCapacityUnits / ConsumedWriteCapacityUnitsを監視
Auto Scalingの導入：トラフィックパターンに応じた自動調整
DynamoDB Contributorを試す：パーティションキーごとの詳細分析
オンデマンドモードの検討：予測困難なワークロードの場合

DynamoDBの適切なキャパシティ設計は、パフォーマンスとコストの両立につながります。本記事の計算方法を活用し、最適な運用を実現してください。

8. 参考文献・参考サイト

AWS公式ドキュメント：

「DynamoDB の読み取り整合性」AWS Documentation, https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html
「Amazon DynamoDB pricing for provisioned capacity」AWS, https://aws.amazon.com/dynamodb/pricing/provisioned/
「Amazon DynamoDB - AWS 料金体系の仕組み」AWS Documentation, https://docs.aws.amazon.com/ja_jp/whitepapers/latest/how-aws-pricing-works/amazon-dynamodb.html

参考記事：

小西秀和「AWSサーバーレスサービスのオンデマンドモードの特徴・比較・まとめ・プロビジョニングモードとの違い－DynamoDB、Kinesis Data Streams－」NRIネットコムBlog, 2024年6月26日, https://tech.nri-net.com/entry/summary_of_on-demand_mode
「DynamoDBの強い整合性読み取り」IT技術で仕事を減らしたい！, 2024年12月21日, https://timesaving.hatenablog.com/entry/2024/12/21/150000
「DynamoDBの料金を最適化しよう【初級編】」DevelopersIO, https://dev.classmethod.jp/articles/optimize-costs-of-dynamodb/