3.3標準
ユーザープロファイルをユーザーIDで取得・更新するサービスを設計する。各リクエストは単一項目を対象とし、テーブル結合や複雑な集計は行わない。
トラフィックが予測しにくく、ミリ秒単位の応答と自動的な水平スケールが必要である。
最も適切なデータベースはどれか。
× 不正解
結合を必要としないキー・バリューアクセスで、予測不能な高トラフィックを低レイテンシーに処理するにはDynamoDBを選ぶ。
詳細解説
誤りAmazon Redshiftへ保存し、毎回SQL集計してプロフィールを返す
Redshiftは分析用データウェアハウスであり、単一項目の高頻度OLTP参照とミリ秒応答の主データストアには適さない。
誤りAmazon S3へJSONを保存し、各リクエストでオブジェクト全体を読み込む
S3はオブジェクトストレージであり、頻繁な単一項目の更新・低レイテンシーのキー参照をデータベースとして提供しない。
誤りAmazon Auroraへ正規化テーブルを作成し、常時稼働の大きなインスタンスへ固定する
Auroraはリレーショナル処理へ適するが、予測不能なキー・バリュー負荷を自動水平スケールする要件に対して、固定サイズの構成は過剰または不足になりやすい。
正しいAmazon DynamoDBを使用し、ユーザーIDをパーティションキーにする
DynamoDBはキー・バリュー／ドキュメントのアクセスパターンに適し、パーティションキーによる単一項目アクセスを大規模かつ低レイテンシーでスケールできる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
Amazon DynamoDBのキー・バリューアクセス、パーティションキー、オンデマンドまたは自動スケールの公式説明を確認する。
参考にした公式資料
確認できる内容
データモデル、アクセスパターン、レイテンシー、負荷の予測可能性からデータベースエンジンを選択できる。
理解のポイント
- Amazon DynamoDB
- パーティションキー
- キー・バリューアクセス
確認時の注意
- 確認環境:
- AWS公式SAA-C03ガイドと各サービスの公式ドキュメントで現行仕様を確認する。
基礎のおさらい
データモデルとクエリ
結合や複雑な集計が不要で単一項目をキーで読むなら、リレーショナル表よりキー・バリューモデルが適合しやすい。
負荷の予測可能性
トラフィックが読めない場合は、固定インスタンスの容量計画ではなく需要に応じて拡張する方式を比較する。
問題IDAWS-SAA-152
確認環境Ubuntu 24.04 / GNU tools
最終技術確認2026-08-31
誤り・権利侵害を報告