DynamoDBの整合性・ストリーム・グローバルテーブル・バックアップ（SAA）
読み取り整合性、DAX、StreamsとLambda、順序の誤解、グローバルテーブル、オンデマンドバックアップとPITR、エクスポートまで試験の誤答パターンと対比して厚く整理します。
このページの狙い
DynamoDB の読み取り整合性、ストリーム、グローバルテーブル、バックアップは、それぞれが独立したサービスのように見えて、実際は一貫したデータライフサイクル設計の上で組み合わされます。ここでは API のオプション、順序の保証範囲、複製と整合性のトレードオフ、バックアップ種別の違いを、誤答パターンと対比して厚くします。
公式ドキュメント（入口）
- 読み取りの整合性
- DynamoDB Streams
- グローバルテーブル
- オンデマンドバックアップと PITR
- テーブルのエクスポートと S3（分析連携の文脈で触れることがある）
読み取り整合性（強い／結果）
| 種類 | イメージ | 典型トレードオフ |
|---|---|---|
| 結果整合性（デフォルト） | 書き込み反映が読み取りに即座に見えないことがある | レイテンシー・スループットと相性が良いことが多い |
| 強い整合性の読み取り | 直前の書き込み結果が反映されたことを確認してから返す | コストとレイテンシーが増えうる |
試験では「常に最新が読めるのがデフォルト」と断定する文面が誤答になりやすいです。最新が必須ならオプション指定という発想に寄せます。
シナリオで固定する
- 在庫の残数を読んだ直後に購入ボタンを押す UI … 直前の書き込み（在庫減）が読み取りに反映されている必要があるなら、強い整合性読み取りや条件付き更新の文脈が出ます。
- ソーシャルの「いいね数」が1〜2秒遅れてよい … 結果整合性でも許容される要件になりやすいです。
DynamoDB Accelerator（DAX）との関係
DAX は読み取りをマイクロ秒級に寄せるキャッシュ層です。試験で効くのは次の対比です。
- ElastiCache: 汎用キャッシュ。アプリ側でキー設計・シリアライズ・無効化を担うことが多い。
- DAX: DynamoDB 互換 API。ホットな読み取りをアプリ変更少なめで加速しやすい。
DAX はキャッシュであるため、「強一貫が絶対に常時保証される」と短絡的に読まないようにします。ヒット／ミス、TTL、クラスタ構成が読み取りの見え方に関わります（DAX の概要）。
DynamoDB Streams（深掘り）
テーブル上の変更イベントのキャプチャです。用途は大きく次に分かれます。
- Lambda トリガ … 更新に応じた非同期処理（通知、集計、別テーブルへの投影）。
- データ連携 … 下流システムへの CDC 的伝搬、検索インデックスの更新。
- グローバルテーブル以外のクロスリージョン連携 … 要件に応じてストリーム消費側で実装、という文脈。
レコードのイメージ
ストリームレコードには NEW／OLD イメージのような概念があり、どの属性を残すかはテーブルのストリーム設定で決まります。試験では「最小限の属性だけを残してコストを抑える」設計が正解になりやすいです。
順序に関する誤答（ここを落とす）
- 同一パーティションキーに対する変更の順序は、運用設計上 扱いやすい 説明がなされます。
- 異なるパーティションキーのイベント同士では、受信順が前後しうる、という注意が教材に現れます。
したがって「ストリーム上の全イベントは常に厳密なグローバル順序」と読むと誤答になりやすいです。
Lambda との組み合わせで効く論点
- バッチサイズと 並列化（シャード単位）でスループットが変わる。
- 失敗時のリトライと デッドレタキュー（DLQ）の設計が、再処理の冪等性とセットで問われる。
- 部分的な失敗（バッチの一部だけ失敗）の扱いは、イベントソースマッピングの設定とセットで公式を確認。
グローバルテーブル（マルチリージョン）
複数リージョンにレプリカテーブルを持ち、近傍のリージョンに書き込みできる構成です。試験では次の対比が出ます。
- 低遅延の近傍書き込み（グローバルユーザー向け）
- 災害復旧（BCP） … プライマリ障害時に別リージョンへ昇格するストーリー
誤答の型
- 「グローバルテーブルだから、世界中どこから読んでも常に単一リージョンの強一貫読み取りと同じ」→ 短絡。複製遅延と衝突解決の話が別途必要。
- 「レプリカを増やしても転送料が一切かからない」→ 誤りになりやすい。レプリケーション転送は料金設計の理解が問われます。
詳細は グローバルテーブル の最新説明に従ってください。
バックアップと復元
| 方式 | 用途のイメージ | 試験で効くポイント |
|---|---|---|
| オンデマンドバックアップ | リリース前など任意タイミングのフルバックアップ | 長期アーカイブや監査提出単位 |
| ポイントインタイムリカバリ（PITR） | 継続バックアップを有効化し、過去の任意時点へ戻す | 誤削除・悪性更新の巻き戻し |
| エクスポート（S3） | 分析基盤へのバルク連携 | PITR とは別系統の用途として区別 |
「PITR なら無制限に過去へ」など期間の誇張が誤答になります。最新の保持期間は バックアップとリストア を参照してください。
AWS Backup との関係
組織単位でバックアップを統制したい場合、AWS Backup と組み合わせる文脈が出ます（AWS Backup）。
ElastiCache とのユースケース近接
どちらも高速ですが、DynamoDB はマネージド NoSQL DB、ElastiCache はキャッシュです。
| 要件 | 寄り先 |
|---|---|
| セッションやホットキーの一時退避 | ElastiCache |
| 永続の主記録、監査に耐える保存 | DynamoDB または RDB |
| DynamoDB の読み取りをさらに速く（互換 API） | DAX |
関連トピック
重要ポイント
- ▸デフォルトの読み取りは結果整合性側の挙動として扱われ、強い整合性読み取りはAPIオプション。最新必読要件とセットで読む
- ▸ストリームはCDCや非同期連携に強いが、全イベントの厳密なグローバル順序と短絡的に捉えない
- ▸グローバルテーブルはマルチリージョンの書き込みとDRに効くが、整合性モデルは単一テーブルの強一貫読み取りと同一視しない
- ▸PITRは継続バックアップを有効化し復元ウィンドウ内の時点へ。期間や粒度は公式の最新説明に従う
- ▸DynamoDBは主記録、ElastiCacheはキャッシュ。セッションだけキャッシュ等の二段構えが定石
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
RDS / Aurora / ElastiCache に関連するトピックを続けて確認できます。