はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon DynamoDB 関連の知識をまとめました。
DynamoDB は NoSQL のサーバーレスデータベースとして、容量モードの選択、DAX によるキャッシュ、Global Tables によるマルチリージョン展開など、多角的に出題されます。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
DynamoDB の特徴
- NoSQL（Key-Value / Document）
- ミリ秒レイテンシー
- サーバーレス（インフラ管理不要）
- 水平スケール
- アイテムサイズ上限: 400KB
Capacity Modes
| モード | 用途 | 課金 |
|---|---|---|
| On-Demand | 予測不能なトラフィック、急激なスパイク、新規テーブル | 使った分だけ（pay-per-request） |
| Provisioned（Auto Scaling 付き） | 予測可能なトラフィック、段階的な増加 | プロビジョニング容量ベース |
「急激なスパイク」には On-Demand を選びます。Auto Scaling は反応に遅延があるため、急激なスパイクには間に合わない場合があります。
DAX（DynamoDB Accelerator）
- DynamoDB 専用のインメモリキャッシュ
- DynamoDB API と完全互換 → コード変更が最小
- ミリ秒 → マイクロ秒 に高速化
- ホットパーティション問題を解消
- ElastiCache Redis でも代替可能だが、実装がはるかに複雑
Global Tables
- マルチリージョン、マルチライター（各リージョンで読み書き可能）
- レプリケーションレイテンシー: 通常1秒未満
- フルマネージド（カスタムレプリケーション不要）
- Aurora Global Database との違い: マルチライター対応（Aurora は書き込みがプライマリのみ）
Deletion Protection
- テーブル削除自体をブロック（予防的）
- 設定するだけ → 運用負荷ゼロ
Point-in-Time Recovery（PITR）
- 秒単位の粒度で過去35日間の任意時点に復元
- 継続的・自動的にバックアップ
- 誤書き込み・誤削除からの保護に最適
TTL（Time To Live）
- アイテムに有効期限（Unix timestamp）を設定
- 期限切れアイテムを自動削除（追加コストなし）
- データ保持ポリシーの実装に最適
DynamoDB の制約
- アイテムサイズ上限 400KB（20MB のドキュメントは格納不可）
- DAX なしの DynamoDB 単体はインメモリではない
試験で問われる設計パターン
キャッシュ・パフォーマンス系
DynamoDB キャッシュ → DAX
シナリオ: DynamoDB に対する読み取りが頻繁で、レスポンスタイムを改善したいです。コード変更は最小限にしたい場合、どのキャッシュサービスが最適でしょうか？
正解: DAX（DynamoDB 用）+ CloudFront（S3 用）
- DAX = DynamoDB API 互換でコード変更最小
- ElastiCache Redis でも可能だが実装が複雑
DynamoDB ホットパーティション + リファクタリング最小 → DAX
シナリオ: スポーツアプリで人気アスリートのページにアクセスが集中し、ホットパーティション問題が発生しています。RCU を増加しても解決しません。リファクタリングを最小限にして解決するにはどうすべきでしょうか？
正解: DynamoDB DAX
- DAX はホットキーをキャッシュして負荷を分散
- ElastiCache はコード変更が大きい
- Global Tables はレプリケーション用（ホットパーティション対策ではない）
- RCU 増加ではホットパーティション問題は解決しない
容量モード系
予測不能トラフィック + 急激なスパイク → On-Demand
シナリオ: 新しく立ち上げるサービスで、トラフィックパターンが予測できません。急激なスパイクにも対応したい場合、どの容量モードが適切でしょうか？
正解: DynamoDB On-Demand Capacity Mode
- Auto Scaling は反応遅延があり、急激なスパイクに不向き
- On-Demand は即座にキャパシティを割り当て
- 新規テーブル（パターン不明）にも On-Demand が推奨
グローバル展開系
マルチリージョン + 1秒未満の書き込み + グローバル同期 → Global Tables
シナリオ: グローバルに展開するアプリケーションで、各リージョンから1秒未満の書き込みレイテンシーが必要です。データはリージョン間で自動同期させたいです。どのサービスが最適でしょうか？
正解: DynamoDB Global Tables
- マルチリージョン、マルチライター
- Aurora Global DB は書き込みがプライマリリージョンのみ
- RDS Cross-Region Read Replica は読み取り専用
DynamoDB グローバル HA + コスト効率 → Global Tables + Provisioned + Auto Scaling
シナリオ: DynamoDB をグローバルに展開して高可用性を確保しつつ、コスト効率も重視したいです。どの構成が最適でしょうか？
正解: Global Tables + Provisioned Capacity + Auto Scaling
- Global Tables はネイティブレプリケーション
- DAX はローカルキャッシュ（グローバル同期ではない）
- Streams + Lambda によるカスタムレプリケーションは運用負荷が大きい
データ保護系
テーブルの誤削除防止 → Deletion Protection
シナリオ: 運用チームが誤って DynamoDB テーブルを削除してしまうリスクがあります。最も運用負荷の低い防止策はどれでしょうか？
正解: DynamoDB Deletion Protection
- 予防的（削除自体をブロック）
- PITR は復旧手段（削除防止ではない）
- Lambda による自動復旧は運用負荷が大きい
破損データの復旧 → PITR
シナリオ: アプリケーションのバグにより DynamoDB のデータが破損しました。破損前の状態に戻すにはどうすべきでしょうか？
正解: DynamoDB PITR
- 秒単位の粒度で過去35日間の任意時点に復元
- On-Demand Backup は事前に取得している必要がある
- Streams はカスタムコードが必要
- Global Tables は破損データもレプリケートしてしまう
サービス選択系
NoSQL + ミリ秒レイテンシー + 水平スケール + サーバーレス → DynamoDB
シナリオ: NoSQL でミリ秒レイテンシー、水平スケール、サーバーレスという要件をすべて満たすデータベースはどれでしょうか？
正解: Amazon DynamoDB
- ElastiCache = キャッシュ（メイン DB ではない）
- RDS = リレーショナル（NoSQL 要件に不適）
- Neptune = グラフ DB（Key-Value には不適）
ドキュメントサイズが 20MB → DynamoDB は不可
シナリオ: 20MB のドキュメントを保存する必要があります。DynamoDB は使えるでしょうか？
正解: 使えません。DynamoDB のアイテムサイズ上限は 400KB です。この場合は S3 をドキュメントストアとして使います。
おわりに
DynamoDB は「NoSQL + サーバーレス」の代表的なサービスであり、SAA でも頻出です。「急激なスパイク → On-Demand」「ホットパーティション → DAX」「マルチリージョン書き込み → Global Tables」「400KB 制限」という判断パターンを押さえておけば、ほとんどの問題に対応できます。
間違いや補足があればぜひコメントで教えてください。