試験Tips

SAA（ソリューションアーキテクト アソシエイト）

頻出ポイント

1. Glue基本概念

出題パターン:
  「S3データをETL処理してAthenaで分析したい」

正解アプローチ:
  - AWS Glue使用
  - Crawler でスキーマ検出
  - ETL Job で変換
  - Data Catalog でメタデータ管理
  - Athena で分析

キーワード:
  ✅ サーバーレスETL → Glue
  ✅ スキーマ自動検出 → Glue Crawler
  ✅ メタデータ管理 → Glue Data Catalog

2. Data Catalog

シナリオ:
  「Athena・Redshift Spectrum・EMRで統一メタデータ」

正解:
  Glue Data Catalog:
    - 一元化メタデータストア
    - 複数サービスで共有
    - 自動スキーマ管理

統合サービス:
  - Amazon Athena
  - Redshift Spectrum
  - Amazon EMR
  - AWS Glue ETL

3. Crawler

問題:
  「S3の新規データを自動的にテーブル化」

回答:
  Glue Crawler:
    - 自動スキーマ推測
    - パーティション自動検出
    - スケジュール実行
    - Data Catalog更新

設定:
  - S3パス指定
  - スケジュール設定
  - データベース指定

4. ジョブブックマーク

シナリオ:
  「日次で新規データのみ処理したい」

正解:
  ジョブブックマーク:
    - 増分処理実現
    - 処理済みデータ追跡
    - 重複処理防止
    - コスト削減

使い方:
  - ジョブ作成時に有効化
  - S3ファイル名ソート順
  - JDBCは列値ベース

SAP（ソリューションアーキテクト プロフェッショナル）

高度なシナリオ

1. 大規模ETLパイプライン

要件:
  「ペタバイト級データの日次ETL処理」

設計:
  データソース:
    - 複数S3バケット
    - RDS（マスターデータ）
    - DynamoDB（トランザクション）

  Glue Crawler:
    - 各ソースでCrawler
    - 夜間スケジュール実行
    - スキーマバージョン管理

  Glue ETL Jobs:
    並列処理:
      - ソース毎にジョブ分割
      - Step Functions オーケストレーション
      - 依存関係管理

    最適化:
      - ジョブブックマーク
      - パーティションプルーニング
      - 適切なWorker設定
      - G.2X（大規模データ）

  データ変換先:
    - S3 Data Lake（Parquet）
    - Redshift（DWH）
    - DynamoDB（集計結果）

  監視:
    - CloudWatch Alarms
    - SNS通知
    - Glue Data Quality

パフォーマンス:
  - DPU最適化（100 DPU）
  - 並列度調整
  - ファイルサイズ最適化
  - 圧縮（Snappy）

2. ストリーミングETL

要件:
  「Kinesisからリアルタイムデータ処理」

設計:
  データフロー:
    Kinesis Data Streams
      ↓
    Glue Streaming ETL
      - Spark Structured Streaming
      - ウィンドウ集計
      - データエンリッチメント
      ↓
    出力先:
      - S3（長期保存）
      - DynamoDB（最新値）
      - Kinesis Data Streams（下流処理）

  チェックポイント:
    - S3バケット
    - 障害回復
    - Exactly-once semantics

  スケーリング:
    - Worker数自動調整
    - Kinesis シャード連携
    - バックプレッシャー対応

レイテンシ:
  - 数秒〜数十秒
  - マイクロバッチ処理
  - ウィンドウサイズ調整

3. データレイク統合戦略

要件:
  「複数アカウントのデータレイク統合分析」

設計:
  各アカウント:
    S3バケット:
      - データ保存
      - クロスアカウント権限

    Glue Crawler:
      - ローカルカタログ作成

  中央アカウント:
    Lake Formation:
      - 統合Data Catalog
      - リソース共有（AWS RAM）
      - 細かいアクセス制御

    Glue ETL:
      - クロスアカウントアクセス
      - データ統合処理

    Athena / Redshift Spectrum:
      - 横断分析

セキュリティ:
  - IAMロール委任
  - Lake Formation権限
  - 列・行レベル制御
  - KMS暗号化
  - CloudTrail監査

4. データ品質管理

要件:
  「データ品質の自動チェックと改善」

アーキテクチャ:
  データ受信:
    S3（生データ）
      ↓
    EventBridge
      ↓
    Lambda
      - 基本検証
      - メタデータ抽出
      ↓

  品質チェック:
    Glue DataBrew:
      - データプロファイリング
      - 統計分析
      - 異常検出
      ↓

    評価:
      - 品質スコア計算
      - しきい値判定
      ↓

  処理分岐:
    合格:
      → Glue ETL（本処理）

    不合格:
      → DLQ（Dead Letter Queue）
      → SNS通知
      → 手動確認

品質ルール:
  - NULL値率
  - データ型整合性
  - 値の範囲
  - ユニーク性
  - 参照整合性

5. コスト最適化戦略

大規模環境:
  DPU最適化:
    分析:
      - CloudWatch Metrics
      - Spark UI
      - CPU/メモリ使用率

    調整:
      - 過剰プロビジョニング削減
      - Worker数最適化
      - Worker typeの適切な選択

  ジョブ統合:
    Before:
      - 10個の小ジョブ
      - 各2 DPU、30分
      - コスト: 10×2×0.5×$0.44 = $4.4

    After:
      - 1個の統合ジョブ
      - 10 DPU、1時間
      - コスト: 10×1×$0.44 = $4.4

    メリット:
      - オーケストレーション簡素化
      - 起動コスト削減

  ジョブブックマーク:
    - 全件処理削減
    - 増分処理でDPU削減
    - 実行時間短縮

  Data Catalog:
    - 不要テーブル削除
    - パーティション整理
    - 100万オブジェクト管理

計算例（月間）:
  ETL Job:
    - 100 DPU × 8時間/日 × 30日
    - 100×8×30×$0.44 = $10,560

  最適化後:
    - 50 DPU × 4時間/日 × 30日
    - 50×4×30×$0.44 = $2,640

  削減: 75%

よくある間違い

間違い 1: リアルタイム性の誤解

❌ 誤り:
  「Glue ETLはリアルタイム処理」

✅ 正解:
  標準ETL:
    - バッチ処理
    - 分単位〜時間単位

  Streaming ETL:
    - 準リアルタイム
    - 数秒〜数十秒
    - マイクロバッチ

  真のリアルタイム:
    - Kinesis Data Analytics
    - Lambda

間違い 2: Crawler の誤解

❌ 誤り:
  「Crawlerはデータ変換もする」

✅ 正解:
  Crawler機能:
    - スキーマ検出のみ
    - メタデータ作成
    - パーティション検出

  データ変換:
    - ETL Job使用
    - DataBrew使用
    - Crawlerは変換しない

間違い 3: DPUの誤解

❌ 誤り:
  「DPU多いほど常に高速」

✅ 正解:
  適切なDPU:
    - データ量依存
    - 処理内容依存
    - 過剰は無駄

  スケーリング限界:
    - I/O バウンド
    - 小データでは効果薄
    - ボトルネック特定重要

間違い 4: ジョブブックマークの誤解

❌ 誤り:
  「ジョブブックマークは全データソース対応」

✅ 正解:
  対応:
    - S3（ファイルベース）
    - JDBC（列ベース）

  非対応:
    - DynamoDB
    - MongoDB
    - カスタムソース

  代替:
    - カスタム実装
    - タイムスタンプ管理

間違い 5: Glue vs EMR の誤解

❌ 誤り:
  「Glueは常にEMRより優れている」

✅ 正解:
  Glue適用:
    - 標準的なETL
    - サーバーレス希望
    - 運用負荷削減
    - 中小規模

  EMR適用:
    - カスタマイズ必要
    - 複雑な処理
    - 継続的な大規模処理
    - コスト効率（大規模時）

  使い分け:
    - 要件に応じて選択
    - 併用も可能

試験対策チェックリスト

基本概念

• Glue主要コンポーネント理解
• Data Catalog役割
• Crawler機能
• ETL Job基本

ETL処理

• ジョブブックマーク
• 変換操作理解
• PySpark基礎
• ストリーミングETL

統合

• Athena統合
• Redshift統合
• S3データソース
• JDBC接続

高度な機能（SAP）

• Lake Formation統合
• 大規模ETL設計
• データ品質管理
• コスト最適化

運用

• DPU設定
• モニタリング
• エラーハンドリング
• セキュリティ

まとめ

試験で押さえるべき重要ポイント:

SAA:

• Glue = サーバーレスETL
• Data Catalog = 統一メタデータ
• Crawler = 自動スキーマ検出
• ジョブブックマーク = 増分処理
• Athena/Redshift統合

SAP:

• 大規模ETLパイプライン設計
• ストリーミングETL実装
• Lake Formation統合
• データ品質管理戦略
• コスト最適化（75%削減可能）
• マルチアカウント統合
• Glue vs EMR の適切な使い分け