AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

データエンジニア-アソシエイト

正解 D問題

分野2：データストアの管理タスクステートメント2.1：データストアの選択

1 2 3 4

前の問題

問題文と選択肢

ある家電量販チェーンのデータ分析チームは、全店舗の POS 取引データを蓄積する Amazon Redshift クラスターを新規に構築します。同社は購入済みのリザーブドノードを活用するため、ノードタイプを選択するプロビジョンドクラスター構成を前提としています。データ量は季節キャンペーンのたびに急増するため、ストレージ容量だけを柔軟に拡張したい一方、クエリを実行するコンピューティングリソースは需要に応じて別々にスケールできる構成にしたいと考えています。また、ノード障害が発生した場合も自動的に復旧し、運用チームの手動対応を最小限にしたいと考えています。

これらの要件を最も適切に満たす構成はどれですか。

Amazon Redshift Serverless を採用し、クエリの実行状況に応じて自動的にキャパシティを調整する
DC2 ノードで固定サイズのクラスターを構築し、ストレージが不足した際は手動でノードを追加する
Redshift クラスターの前段に Amazon ElastiCache for Redis を配置し、クエリ結果をキャッシュしてノード障害の影響を緩和する
RA3 ノードタイプと Redshift Managed Storage を採用し、コンピューティングとストレージを独立してスケーリングできるようにする

解説頻出度★★★★★

この問題は、「プロビジョンドクラスター前提 × ストレージだけ伸ばしたい × コンピューティングは別にスケール × ノード障害の自動復旧」の要件で、RA3 ノード＋ Redshift Managed Storage を選べるかがポイント

A. Amazon Redshift Serverless を採用し、クエリの実行状況に応じて自動的にキャパシティを調整する

Amazon Redshift Serverless もコンピューティングとストレージが分離され、ノードの管理も不要という点では要件に近い構成です。
しかし本問は購入済みのリザーブドノードを活用するプロビジョンドクラスター構成が前提と明示されており、ノードタイプを選択しないサーバーレスはこの前提を満たしません（リザーブドノードの料金も適用できません）。
「サーバーレスかプロビジョンドか」は問題文の前提で決まる部分であり、前提が固定されている以上、ここでの解答にはなりません。

B. DC2 ノードで固定サイズのクラスターを構築し、ストレージが不足した際は手動でノードを追加する

DC2 ノードタイプはローカル SSD にデータを保持する構成で、コンピューティングとストレージが一体です。ストレージが足りなくなればノードを追加するしかなく、必要のないコンピューティングまで一緒に増やして課金されます。
「固定サイズのクラスター」「手動でノードを追加」という記述は、ストレージだけを柔軟に拡張したい・運用の手動対応を最小限にしたいという要件に真っ向から反します。
DC2 は圧縮後 1 TB 未満の小規模データセットで最も低コストに高性能を得たい場合の選択肢であり、季節ごとにデータが急増する本問には向きません。

C. Redshift クラスターの前段に Amazon ElastiCache for Redis を配置し、クエリ結果をキャッシュしてノード障害の影響を緩和する

Amazon ElastiCache for Redis はキーバリューアクセスを高速化するキャッシュであり、データウェアハウスの集計クエリ結果を汎用的にキャッシュする仕組みではありません（Redshift 自体にも結果キャッシュがあります）。
キャッシュを前段に置いてもストレージ容量の拡張にもコンピューティングの独立スケールにも寄与しません。
ノード障害時にキャッシュに残った古い結果を返せたとしても、それはクラスターの復旧ではなく、要件の「自動的に復旧」を満たしません。

正解

D. RA3 ノードタイプと Redshift Managed Storage を採用し、コンピューティングとストレージを独立してスケーリングできるようにする

RA3 ノードタイプは Redshift Managed Storage (RMS) を使い、各ノードのローカル SSD をホットデータのキャッシュとして使いながら、容量を超えたデータは自動的に Amazon S3 にオフロードします。これによりコンピューティング (ノード数) とストレージを別々にスケールし、別々に支払えるようになります。
季節キャンペーンでデータ量が増えてもノードを増やす必要はなく、使用したマネージドストレージ分だけ課金されます。クエリ性能が必要になったときだけノード数を変更すればよく、要件の分離スケーリングにそのまま合致します。
さらにデータの実体が RMS 側にあるため、ノード障害時の自動的なノード置き換え・データ復旧も高速で、運用チームの手動対応を最小限にできます。

これだけ覚える（記憶フック）
ストレージとコンピューティングを分けたいなら RA3 + マネージドストレージ。DC2 は両者が固定でセット。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
リザーブドノードを活用するプロビジョンドクラスター前提	ノードタイプを選択する構成が前提。サーバーレスはこの前提から外れる →選択肢（A）を消す
ストレージ容量だけを柔軟に拡張したい	Redshift Managed Storage なら容量超過分が自動的に S3 へオフロードされ、使った分だけ課金される →選択肢（D）が正解
コンピューティングは需要に応じて別々にスケールしたい	DC2 はローカル SSD 一体型でストレージとコンピューティングが不可分。容量のためだけにノードを増やす羽目になる →選択肢（B）を消す
ノード障害時も自動的に復旧し、手動対応を最小限にしたい	RA3 はデータの実体が RMS にあるためノードの置き換えと復旧が速い。キャッシュを挟んでも復旧にはならない →選択肢（C）を消す／選択肢（D）が正解

ひっかけポイント

選択肢 A の Redshift Serverless は技術的には分離スケーリングを実現するが、本問はプロビジョンドクラスター（リザーブドノード活用）が前提と明記されている。前提条件を読み飛ばすと引っかかる
「固定サイズ」「手動でノードを追加」という文言は、要件（柔軟な拡張・手動対応の最小化）と正反対であることに気づけば DC2 の選択肢は即座に消せる
ElastiCache を前段に置く構成は一見「性能改善」に見えるが、Redshift の分析クエリ結果を汎用キャッシュする仕組みではなく、ストレージ拡張にも障害復旧にも無関係
RA3 の本質は「大きいノード」ではなくRedshift Managed Storage によるストレージの切り離し。ノードタイプ名ではなく何が分離されるかで覚える

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「クラスターの利用は不定期で、アイドル時間が長い。管理も一切したくない」	Amazon Redshift Serverless が正解軸に（RPU 単位の従量課金）。
「圧縮後 1 TB 未満の小さなデータセットを最小コストで高速に分析したい」	DC2 ノードタイプが正解になり得る。
「別部門のクラスターからデータをコピーせずに共有したい」	データ共有 (Redshift data sharing) が正解軸に（RA3／Serverless が前提）。
「S3 の大量データをロードせずに直接クエリしたい」	Redshift Spectrum（または Amazon Athena）が正解軸に。

AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

A. Amazon Redshift Serverless を採用し、クエリの実行状況に応じて自動的にキャパシティを調整する

B. DC2 ノードで固定サイズのクラスターを構築し、ストレージが不足した際は手動でノードを追加する

C. Redshift クラスターの前段に Amazon ElastiCache for Redis を配置し、クエリ結果をキャッシュしてノード障害の影響を緩和する

D. RA3 ノードタイプと Redshift Managed Storage を採用し、コンピューティングとストレージを独立してスケーリングできるようにする

前の問題

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報