導入
DynamoDB単体でも高速ですが、SAAでは「さらに要件を満たすための周辺機能」の理解も問われます。キャッシュ、変更検知、マルチリージョン展開の3つを見ていきます。
説明
DAX（DynamoDB Accelerator） は、DynamoDB専用のインメモリキャッシュです。DynamoDB自体もミリ秒台で応答しますが、DAXを前段に置くとさらにマイクロ秒単位まで短縮できます。読み取りが極端に集中するホットキーの負荷を吸収するのに使います。
DynamoDB Streams は、テーブルへの変更（挿入・更新・削除）を時系列で記録するストリームです。Lambda関数をトリガーして、変更をリアルタイムに他システムへ連携できます（例：注文が追加されたら通知を送る、集計テーブルを更新する）。
Global Tables は、DynamoDBのマルチリージョン・マルチアクティブレプリケーション機能です。複数リージョンの同じテーブルに、どこからでも書き込め、双方向に自動同期されます。RDSのリードレプリカ（読み取り専用）とは異なり、どのリージョンでも書き込み可能な点が特徴です。
その他、TTL（Time To Live） で不要になった項目（セッション情報、期限切れデータなど）を自動削除でき、ストレージコストと管理の手間を削減できます。
flowchart TD
App["アプリ"] -->|"読み取り集中"| DAX["DAX (マイクロ秒キャッシュ)"] --> DDB["DynamoDBテーブル"]
DDB -->|"変更を検知"| Streams["DynamoDB Streams"] --> Lambda["Lambda関数"]
DDB <-->|"双方向レプリケーション"| DDB2["別リージョンのテーブル<br/>(Global Tables)"]
いつRDSでなくDynamoDBか：スキーマが柔軟に変化する／超高速な単純キー検索が中心／トラフィックが桁違いにスケールする／サーバーレスアーキテクチャと親和させたい、といった要件ではDynamoDB。複雑な結合・トランザクション・アドホックなSQLクエリが必要ならRDS/Auroraを選びます。
具体例
オンラインゲームのバックエンドで、DynamoDBの3つの高度機能がそれぞれの課題を解きます。
- 課題：世界ランキングの表示にアクセスが殺到し、同じ項目を何百万回も読む → DAX。DynamoDBの前に置くインメモリキャッシュで、応答をミリ秒からマイクロ秒へ。ホットキーの読み取り負荷を吸収する。
- 課題：新しいハイスコアが登録されたら、フォロワーに通知したい → DynamoDB Streams ＋ Lambda。テーブルへの変更をStreamsが検知し、Lambdaを起動して通知処理を走らせる。アプリ本体に通知ロジックを埋め込まず、疎結合に。
- 課題：日本と欧州、どちらのプレイヤーも自国リージョンへ低遅延で書き込みたい → Global Tables。複数リージョンで双方向・マルチアクティブに書き込め、自動同期される。RDSのリードレプリカ（読み取り専用）と違い、どのリージョンでも書けるのが決定的な差。
加えて、期限切れセッションはTTLで自動削除しストレージを節約。「読み取り爆速化＝DAX、変更を起点に処理＝Streams＋Lambda、複数リージョンで書き込み＝Global Tables」は定番の3点セットです。
読んでみよう
「DynamoDBの読み取りをさらに高速化したい」→ DAX。「変更をトリガーに他処理を動かしたい」→ Streams＋Lambda。「複数リージョンで低レイテンシーな書き込みが必要」→ Global Tables。この3点セットの使い分けはSAAの定番出題です。