Amazon RedshiftとOLAP設計（SAA）

このページの狙い

Redshift は データウェアハウス（DWH）／OLAP の文脈で選ばれます。試験では OLTP との混同、S3 との境界、ネットワーク可観測性、スケール手段の取り違えが落とし穴です。ここでは クラスター役割から Spectrum／Serverless／運用までを厚くし、誤答パターンを明示します。

公式ドキュメント（入口）

• Redshift の概要
• Redshift Spectrum
• Redshift Serverless
• 拡張型 VPC ルーティング
• ワークロード管理（WLM）
• フェデレーションクエリ

OLTP と混同しない（最重要）

観点	OLTP（RDS／Aurora／DynamoDB）	Redshift
典型クエリ	短いトランザクション、行単位更新	大規模スキャン、集計、JOIN
データ鮮度	業務操作の最新性が重要	バッチ取り込み後の分析が主
設計の中心	正規化・制約・同時実行	ディストキー／ソートキー、WLM、テーブル設計
失敗の見え方	ユーザー操作が即座に失敗として返る	クエリがキューに滞留・タイムアウト

誤答の型（シナリオ）

1. 「在庫引当を Redshift のみでリアルタイム処理」→ OLTP 誤用。
2. 「Redshift に流し込む前に正規化しきれていない生ログを、そのまま唯一の真実にする」→ データガバナンスの話が別途必要。
3. 「Spectrum があれば S3 上のデータにトランザクション更新がそのまま効く」→ 誤解。Spectrum は クエリ実行の話であり、S3 の性質自体は変わりません。

クラスター構成の骨格（役割分担）

• リーダーノード（コーディネータ）: クライアント接続、クエリ計画、結果集約、メタデータ管理のイメージ。
• コンピュートノード: スライスに分割され、並列にスキャン・集計を実行。
• データの永続化のイメージ: コンピュート近傍の高速層と、長期・大容量は S3 側へオフロードする設計思想（RA3 のマネージドストレージは公式図解を参照）。

ノード数やファミリ名は更新が早いため、数値暗記より「リーダーがボトルネックになりうる」「コンピュートを増やすと並列度が上がる」 という因果を優先します。

RA3 と DC2（教材レベルの対比）

観点	DC2（Dense Compute）	RA3
始め方	比較的小さなデータセットで始めやすい、という説明が教材に出ることがある	データ増加が見込まれる大規模系の選択肢として語られることが多い
ストレージ	ローカル SSD に寄せた高性能、という説明	マネージドストレージとコンピュート分離の思想
試験の読み方	「未圧縮で小さいなら DC2」系の定型文	「ホットとコールドを分けてコスト最適化」系の定型文

廃止や改名が起こり得るため、最終判断は公式のノードタイプ一覧で確認してください。

Redshift Spectrum

Redshift クラスターから、ユーザー管理の S3 データを SQL で直接参照する拡張です。データレイク（S3）と DWH（Redshift）の橋渡しとして出題されます。

Athena との距離

• すでに Redshift を分析ハブにしているなら、Spectrum で レイクと倉庫を同じ SQL 文化でつなぐストーリーが強い。
• サーバレスで ad-hoc にだけ叩きたいなら Athena 寄りの要件になりやすい。

サイト内では S3の分析と監査 も参照してください。

Redshift Serverless

クラスター容量の事前固定を抑えて分析に専念する選択肢です。「運用を減らしてすぐ分析を始めたい」「断続的なクエリ」の文脈で選ばれます。プロビジョンドとのコスト比較は常時フル稼働かどうかで変わるため、設問全文を読みます。

拡張 VPC ルーティング（試験で効く）

有効化すると、クラスターとデータリポジトリ間の COPY／UNLOAD が VPC 内のルートに従うようになります。

効く論点

• VPC フローログでトラフィックを追跡しやすい（監査・調査）。
• プライベート接続（S3 のゲートウェイ／インターフェース、VPC エンドポイント）と組み合わせた閉域データ取り込みのストーリー。

ワークロード管理（WLM）と混雑

複数の利用者グループ（経営レポートと運用ダッシュボードなど）が同居すると、長時間クエリがキューを占有し、短いクエリが餓死する、という問題が教材に出ます。WLM は キューとスロットで優先度と並列度を調整する仕組みです。試験では Short query acceleration や 自動ワークロード管理のキーワードが補助的に出ることがあります（公式の最新機能名に従う）。

スケーリングと混雑（対比表）

手段	イメージ	向く負荷
ノード追加・タイプ変更	恒常的なデータ量・同時実行の増加	底上げされたベースライン
Concurrency Scaling	急な同時実行ピークを一時クラスタで吸収	スパイク

「常時 CPU が天井なのに Concurrency Scaling だけで永続的に解決」は設計として不十分になりやすいです。

データ連携（取り込みと出し）

取り込み（To Redshift）

• S3 からの COPY（フォーマット、圧縮、IAM 権限がセットで問われる）。
• Kinesis Data Firehose からのロード。
• Glue や DMS によるパイプライン。
• フェデレーションクエリで RDS／Aurora のオペレーショナルデータを参照し、DWH 側で結合する。

出し（From Redshift）

• UNLOAD で S3 へ抽出（下流の ML や別分析へ）。
• QuickSight で可視化。

セキュリティとコンプライアンス（入口）

保存時の KMS、転送の SSL、VPC 内配置、CloudWatch メトリクスとセットで「観測可能で閉域」な構成が正解になりやすいです。

関連トピック

• データベース選択の論点
• S3の分析と監査（Spectrum言及）
• RDSのバックアップとPITR（OLTP 側の正との対比）