【DynamoDBの役割（パフォーマンス最適化）】
目次
🔍 1. 結論
💎 一言でいうと Amazon DynamoDB は、データ量がGBからTB、PBに増えようと、「常に1桁ミリ秒（数ミリ秒）の超低レイテンシで応答し続ける」 ことが保証された高性能NoSQLデータベースです。
- キャパシティ設計は「プロビジョンド」と「オンデマンド」から選べる。
- 読み取り性能を極限まで高める（ミリ秒からマイクロ秒へ）には、専用キャッシュ DAX を使う。
📈 2. SAAで出やすいポイント
- キャパシティモードの選択:
- プロビジョンド: トラフィックが予測可能な場合。Auto Scalingと組み合わせてコストを最適化する。
- オンデマンド: 突然バズるなど、トラフィックが全く読めない場合（スパイク）。事前の容量設計なしに数千〜数万リクエスト/秒まで一瞬で自動対応する。
- DynamoDB Accelerator (DAX): DynamoDBの前に置くフルマネージドのインメモリキャッシュクラスター。これを使うと、読み取り応答速度が「1桁ミリ秒（0.00x秒）」から 「マイクロ秒（0.00000x秒）」 まで高速化されます。アプリのコードを変更せずに導入できるのが特徴。
- パーティションキー設計: 高性能を引き出すには、特定のキーにアクセスが集中（ホットパーティション）しないよう、均等に分散されるキー設計が求められます。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑う機能・構成 |
|---|---|
| ⚡ 「1桁ミリ秒のレイテンシ」「どんなにスケールしても遅延が変わらない」 | Amazon DynamoDB |
| 🚀 「DynamoDBの読み取りをさらに高速化」「マイクロ秒のレイテンシ」 | DynamoDB Accelerator (DAX) |
| 📈 「事前の容量予測が不可能なトラフィックの急増」 | DynamoDB オンデマンドキャパシティモード |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「DynamoDBをキャッシュするために ElastiCache for Redis を導入する」 → 間違いではありませんが、DynamoDB専用で「コード変更を最小限にしたい」という要件なら DAX が圧倒的に正解になりやすいです。 – 「複雑なJOINクエリを高速化するためにDynamoDBを使う」 → DynamoDBはNoSQLなのでJOINはできません。複雑なクエリの高速化なら、RDSのチューニングやRedshiftを検討します。
💡 5. 覚え方
🧠 暗記ショートカット – DynamoDB = 「巨大な図書館の超優秀な司書」。 – 本が何万冊に増えようが、タイトル（キー）さえ言えば「1ミリ秒」で持ってくる。 – DAX = 「司書の机の上のメモ帳」。よく聞かれる本はメモしてあるので「1マイクロ秒（ミリの1000分の1）」で答えられる。
📚 6. 関連サービス
| アイコン | サービス名 | 高性能化における違い |
|---|---|---|
| 🚀 | DynamoDB DAX | DynamoDB専用。アプリのコード書き換えが不要（API互換） |
| ⚡ | Amazon ElastiCache | RDSなど様々なDBのキャッシュに使える汎用インメモリDB。コード改修が必要 |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: NoSQLデータベースのパフォーマンス最適化、DAXの要件学習時
- 関連ノート候補:
AWS_SAA_DynamoDB_DAX,AWS_SAA_NoSQL_vs_RDB
8. HTMLファイル名:
AWS_高性能設計_DynamoDB.html
