概要
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/