SAA データレイク設計の頻出パターン｜貯める・取り込む・カタログ・クエリ・統制を要件で即断する
AWS SAA-C03 で問われるデータレイク設計は「S3 に貯めれば完成」ではない。ストレージ（S3 ゾーン設計）・取り込み（Firehose/DataSync/Glue）・カタログ（Glue Data Catalog）・クエリ（Athena/Redshift Spectrum）・統制（Lake Formation）の5層を、要件文のキーワードから1つずつ埋める設計問題だ。本記事は無数に見えるデータレイク構成をこの5評価軸に畳み、頻出パターンを分解する。最頻出の罠——データレイク＝S3 だけと思い込む・パーティションと列指向を忘れて Athena のスキャン料金が爆発する・Lake Formation と IAM/バケットポリシーの役割を取り違える・Redshift 未導入なのに Spectrum を選ぶ——を反射で回避できる型に落とし込む。結論は「まず S3 のゾーンと形式で土台を決め、取り込み・カタログ・クエリ・統制を用途で足す」こと。読み終えれば、分析ワークロードの設問で選択肢を迷わず絞れるようになる。
「多様なデータを S3 に集めて、SQL で分析できるようにしたい」——SAA-C03 でこの手の設問を読んだとき、S3・Glue・Athena・Lake Formation・Redshift Spectrum・Kinesis が選択肢に散らばって手が止まるなら、それはデータレイクを「S3 にファイルを置くこと」だと捉えているサインだ。 データレイクはコスト最適化（ドメイン4）・高パフォーマンス（ドメイン3）・セキュア設計（ドメイン1）を横断する頻出テーマで、単体サービスより「組み合わせ」で問われる。攻略の鍵はシンプルで、構成を「①貯める（S3 ゾーン設計）②取り込む（ingestion）③カタログ化（Glue）④クエリ（Athena / Redshift Spectrum）⑤統制（Lake Formation）」の5層に分けて読むことだ。とくにストレージ層は、データ形式・パーティション・ゾーンという3要素がコストとパフォーマンスの選択肢を一意に決める。本記事では、この5評価軸で頻出パターンを分解し、要件文のキーワードから正解を反射で引ける型に落とし込む。読み終えれば、分析ワークロードが絡むどの設問でも選択肢を迷わず絞れるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：データレイクは「貯める → 取り込む・カタログ・クエリ・統制」を足す
- 評価軸1：貯める（S3 ゾーン設計と列指向・パーティション）
- 評価軸2：取り込む（Firehose・DataSync・Glue の切り分け）
- 評価軸3：カタログ化（Glue Data Catalog と Crawler）
- 評価軸4：クエリ（Athena と Redshift Spectrum の使い分け）
- 評価軸5：統制（Lake Formation と IAM の役割分担）
- 要件キーワード → 正解サービス 早見表
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：データレイクは「貯める → 取り込む・カタログ・クエリ・統制」を足す
データレイク設計の設問は、1つの正解サービスを選ぶのではなく、5層それぞれに正解を1つずつ割り当てる構造で解く。土台は必ず S3 で、その上に取り込み・カタログ・クエリ・統制を要件で積み上げる。
最大の誤解は「データレイク＝ S3 バケットを作ること」だ。S3 は貯める土台にすぎず、カタログ（何がどこにあるか）と統制（誰が何を見られるか）がなければ「使えるデータレイク」にはならない。SAA はこの「S3 だけでは足りない」を突く設問を好む。
2. 評価軸1：貯める（S3 ゾーン設計と列指向・パーティション）
データレイクのストレージは、単一バケットにファイルを放り込むのではなく、データの成熟度で「ゾーン」に分けるのが定石だ。典型は3層。
- Raw（生データ）ゾーン：アプリ・ログ・CDC・パートナー連携から届いた無加工データ。原本として保持する。
- Cleansed（整形）ゾーン：重複除去・型変換・欠損処理を施した中間データ。
- Curated（分析用）ゾーン：分析・BI が直接読む、Parquet などの列指向にした最終データ。
このゾーン設計の上で、SAA が繰り返し問う2つのコスト・パフォーマンス最適化がある。
| 評価項目 | CSV / JSON | Parquet / ORC（列指向） 推奨 |
|---|---|---|
| クエリ時のスキャン量 | 全カラム読む（多い） | 必要カラムだけ（少ない） |
| 圧縮効率 | 低い | 高い |
| Athena のコスト | 高い | 低い |
| 取り込み直後の可読性 | ◎ そのまま読める | △ 変換が必要 |
| 分析用途（推奨） | × | ◎ |
ストレージクラスの最適化も頻出だ。Raw ゾーンの原本はアクセス頻度が下がるため、S3 のライフサイクルポリシーで Glacier 系へ自動移行するとコストが下がる。S3 設計問題の頻出パターンと合わせて押さえておきたい。
3. 評価軸2：取り込む（Firehose・DataSync・Glue の切り分け）
データを S3 に「どう入れるか」は、**データの性質（ストリームか、バッチか、移行か）**で一意に決まる。
- リアルタイムのストリーミング → Amazon Kinesis Data Firehose。バッファリングして S3 へ自動配信し、途中で Parquet へ変換もできる。「ニアリアルタイムで S3 に配信」「フルマネージドで運用不要」なら Firehose。細かい制御やコンシューマー分岐が要れば Kinesis Data Streams。
- オンプレミスからの大量バッチ・継続同期 → AWS DataSync（ファイル/オブジェクトの転送）。DB そのものの移行は DMS。詳細は オンプレ → AWS 移行のサービス選定。
- 取り込みと同時に整形・変換したい → AWS Glue の ETL ジョブ。サーバーレスで Raw → Cleansed → Curated の変換パイプラインを組める。大規模な Spark 処理が要れば Amazon EMR。
4. 評価軸3：カタログ化（Glue Data Catalog と Crawler）
S3 に貯めただけのデータは「どんなテーブルで、どんなスキーマか」を機械が知らない。これを解決するのが AWS Glue Data Catalog で、データレイクの中央メタストア（テーブル定義・スキーマ・パーティション情報の一元管理）として機能する。
- Glue Crawler が S3 を走査してスキーマとパーティションを自動検出し、Data Catalog にテーブルを登録する。
- Athena・Redshift Spectrum・EMR は、この Data Catalog を「唯一の真実の源（source of truth）」として参照する。つまり カタログを1つ作れば、複数のクエリエンジンが同じスキーマを共有できる。
5. 評価軸4：クエリ（Athena と Redshift Spectrum の使い分け）
S3 のデータに SQL を投げる方法は主に2つ。既存の Redshift があるか、ワークロードがアドホックかで切り分ける。
| 評価項目 | Amazon Athena 推奨 | Redshift Spectrum |
|---|---|---|
| サービス形態 | 独立したサーバーレス | Redshift の拡張機能 |
| クラスター管理 | 不要（完全サーバーレス） | Redshift クラスターが必要 |
| 得意なワークロード | アドホック・探索的な軽いクエリ | ウェアハウスと S3 の結合・重い分析 |
| 前提 | なし（すぐ使える） | 既存 Redshift 利用者 |
| 課金 | スキャン量 約$5/TB | スキャン量 約$5/TB＋Redshift 費用 |
判断は要件文のキーワードで速い。「サーバーレスで、インフラ管理なしに S3 を SQL 分析」なら Athena。「既存の Redshift データウェアハウスと S3 のデータを JOIN したい」「すでに Redshift を運用している」なら Redshift Spectrum。Redshift を導入していないのに Spectrum を選ぶのは典型的な誤答で、クラスター費用が無駄に乗る。BI 可視化まで問われれば Amazon QuickSight が続く。
6. 評価軸5：統制（Lake Formation と IAM の役割分担）
データレイクのアクセス制御で SAA が最も突くのが、Lake Formation と IAM/バケットポリシーの役割の違いだ。
- IAM / S3 バケットポリシー：バケットやプレフィックス単位の「粗い」アクセス制御。「このバケットを読めるか」までしか表現できない。
- AWS Lake Formation：Glue Data Catalog を通じて、データベース・テーブル・列・行・セル単位のきめ細かなアクセス制御を提供する。IAM の権限モデルを補強する、データレイク専用の許可プレーンだ。
セキュリティは多層防御（defence in depth）が基本で、IAM・Lake Formation のきめ細かな制御・S3 バケットポリシーの最終防壁・保存/転送時の暗号化を重ねる。監査は Lake Formation の CloudTrail ログで担保する。セキュア設計ドメインの考え方がそのまま効く領域だ。
7. 要件キーワード → 正解サービス 早見表
| 評価項目 | 要件キーワード | 正解サービス / 判断 |
|---|---|---|
| ストリーミングをニアリアルタイムで S3 へ | Kinesis Data Firehose | — |
| 取り込み時に整形・変換したい | AWS Glue ETL | — |
| スキーマを自動検出しカタログ化 | Glue Crawler + Data Catalog | — |
| サーバーレスで S3 を SQL 分析 | Amazon Athena | — |
| 既存 Redshift と S3 を結合 | Redshift Spectrum | — |
| クエリコスト／スキャン量を下げたい | Parquet 化＋パーティション | — |
| 列・行・タグ単位のアクセス制御 | AWS Lake Formation（LF-Tags） | — |
| オンプレの大量データを移行 | AWS DataSync / DMS | — |
8. 次のアクション チェックリスト
- データレイク設問を「貯める・取り込む・カタログ・クエリ・統制」の5層に分解して読む癖をつける
- 「クエリコスト低減＝ Parquet/ORC 化＋パーティション」を反射で出せるようにする
- 「ストリーミング＝ Firehose」「変換＝ Glue」「移行＝ DataSync/DMS」を取り込み層で区別する
- Athena（アドホック・サーバーレス）と Redshift Spectrum（既存 Redshift 結合）を前提条件で切り分ける
- 「列・行・タグ単位の制御＝ Lake Formation」、IAM/バケットポリシーは粗い制御、と役割を固定する
- コスト最適化・高パフォーマンスドメインと横断で復習する
9. 関連記事
- AWS S3 完全ガイド：オブジェクトストレージの仕組み — データレイクの土台となるストレージ
- SAA：S3 設計問題の頻出パターン10選 — ゾーン設計・ライフサイクルの実戦
- AWS Glue で ETL 自動化 — カタログ化と変換パイプラインの中核
- Amazon Athena の使い方と料金 — サーバーレスな S3 クエリのコスト構造
- Redshift Spectrum で S3 を直接クエリ — ウェアハウスと S3 の結合
- Amazon Redshift とは？データウェアハウスの基本 — Spectrum の前提サービス
- Kinesis Data Firehose の使い方 — ストリーミング取り込みの第一候補
- Amazon Kinesis Data Streams 完全ガイド — きめ細かいストリーム制御
- Amazon EMR（ビッグデータ処理）の基本 — 大規模 Spark 分析
- SAA：オンプレミス → AWS 移行のサービス選定 — DataSync/DMS との切り分け
- SAA 試験範囲：4ドメイン詳細解説 — ドメイン1〜4の全体像
10. 関連サイト
AWS 公式
- AWS のデータレイクと分析（公式）
- AWS Lake Formation とは（公式ドキュメント）
- AWS Lake Formation（公式）
- AWS Glue（公式）
- Amazon Athena（公式）
- Amazon S3（公式）
- Athena のパーティション（公式ドキュメント）
- AWS でデータレイクを構築する（ホワイトペーパー）
- AWS Certified Solutions Architect – Associate（公式）