試験Tips

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

頻出ポイント

1. Athena基本概念

出題パターン:
  「S3のデータをSQLで分析したい」

正解アプローチ:
  - Amazon Athena使用
  - サーバーレス
  - S3データ直接クエリ
  - 標準SQL対応

キーワード:
  ✅ S3データ分析 → Athena
  ✅ サーバーレスSQL → Athena
  ✅ アドホッククエリ → Athena
  ❌ データウェアハウス → Redshift

2. データ形式とコスト

シナリオ:
  「Athenaクエリのコスト削減」

正解:
  Parquet/ORC:
    - 列指向フォーマット
    - 高圧縮率
    - スキャン量削減
    - 10倍以上のコスト削減可能

  圧縮:
    - GZIP / SNAPPY
    - ストレージコスト削減
    - スキャン量削減

よくある間違い:
  ❌ CSV非圧縮
  ❌ JSON直接利用
  ✅ Parquet + SNAPPY圧縮

3. パーティション

問題:
  「大量データのクエリを高速化」

回答:
  パーティション活用:
    - データを論理分割
    - スキャン範囲限定
    - クエリ高速化・コスト削減

  例:
    s3://bucket/data/year=2024/month=01/

    SELECT * FROM logs
    WHERE year='2024' AND month='01'
    → 該当パーティションのみスキャン

キーワード:
  - パーティション
  - WHERE句で指定
  - スキャン量削減

4. Glue Data Catalog

シナリオ:
  「Athenaでテーブル定義管理」

正解:
  Glue Data Catalog:
    - メタデータストア
    - テーブル・スキーマ定義
    - パーティション管理

  Glue Crawler:
    - 自動スキーマ推測
    - パーティション検出
    - 定期実行

統合:
  - Athena
  - Redshift Spectrum
  - EMR

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

高度なシナリオ

1. 大規模データレイク設計

要件:
  「ペタバイト級データレイクの分析基盤」

設計:
  ストレージ層:
    S3:
      - 階層化（Standard / IA / Glacier）
      - ライフサイクルポリシー
      - パーティション構造最適化

  カタログ層:
    Glue Data Catalog:
      - 統一メタデータ管理
      - Crawler自動化
      - バージョン管理

  クエリ層:
    Athena:
      - アドホック分析
      - ワークグループ分離

    Redshift Spectrum:
      - 大規模集計
      - S3 + Redshift統合

  可視化層:
    QuickSight:
      - SPICE高速化
      - ダッシュボード

  セキュリティ:
    Lake Formation:
      - 一元管理
      - 列・行レベル制御
      - 監査ログ

最適化:
  - Parquet + Snappy
  - 適切なパーティション粒度
  - ファイルサイズ128MB以上
  - コンパクション定期実行

2. マルチアカウント分析

要件:
  「複数アカウントのログを一元分析」

アーキテクチャ:
  各アカウント:
    - ログ → S3（アカウント固有）
    - S3レプリケーション → 中央アカウント

  中央アカウント:
    S3:
      - 全ログ集約
      - account_id パーティション

    Glue Data Catalog:
      - リソース共有（RAM）
      - クロスアカウントアクセス

    Athena:
      - 横断クエリ
      - アカウント別集計

セキュリティ:
  - バケットポリシー
  - IAMロール委任
  - Lake Formation権限
  - 暗号化（KMS）

3. 準リアルタイム分析

要件:
  「ストリーミングデータの準リアルタイム分析」

設計:
  データ収集:
    Kinesis Firehose:
      - データ収集
      - S3配信（60秒バッファ）
      - Parquet変換（Lambda）

  カタログ更新:
    Glue Crawler:
      - 5分毎実行
      - パーティション自動追加

    または:
      Lambda:
        - S3イベント
        - ADD PARTITION実行

  クエリ:
    Athena:
      - 最新データクエリ
      - ワークロード分離

  可視化:
    QuickSight:
      - 自動リフレッシュ
      - リアルタイムダッシュボード

レイテンシ:
  - データ到着: 1〜2分
  - クエリ可能: 2〜5分
  - 十分な多くのユースケース

4. コスト最適化戦略

大規模環境:
  データ変換:
    - CSV → Parquet（CTAS）
    - 10倍以上のコスト削減
    - 一度の投資で継続的削減

  パーティション最適化:
    - 適切な粒度（日次推奨）
    - クエリパターン分析
    - 不要パーティション削除

  ファイル統合:
    - 小ファイル問題解消
    - 128MB以上維持
    - Glue ETL定期実行

  クエリ最適化:
    - SELECT *禁止
    - ワークグループ制限設定
    - Prepared Statements活用

  ワークグループ管理:
    - 部門別分離
    - BytesScannedCutoff設定
    - コスト配分タグ

計算例:
  Before（CSV）:
    10TB × $5/TB = $50/クエリ

  After（Parquet + パーティション）:
    1TB × $5/TB = $5/クエリ

  削減率: 90%

5. フェデレーテッドクエリ戦略

要件:
  「S3・RDS・DynamoDB横断分析」

設計:
  Data Source Connector:
    Lambda:
      - RDS接続
      - DynamoDB接続
      - 外部API接続

    VPC設定:
      - RDSアクセス
      - Secrets Manager統合

  Athena:
    - 複数ソースJOIN
    - 統一SQLインターフェース

  クエリ例:
    履歴（S3） + 最新（RDS）
    イベント（S3） + ユーザー（DynamoDB）

パフォーマンス考慮:
  - S3データをメインに
  - 外部データは補完的に
  - 適切なフィルタリング
  - 結果キャッシュ

よくある間違い

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

❌ 誤り:
  「Athenaはリアルタイム分析」

✅ 正解:
  - アドホックquery
  - 準リアルタイム可能（数分）
  - バッチ分析向き

  真のリアルタイム:
    - Kinesis Data Analytics
    - OpenSearch
    - Redshift（Streaming Ingestion）

間違い 2: 料金の誤解

❌ 誤り:
  「Athenaはデータ量で課金」

✅ 正解:
  課金対象:
    - スキャンされたデータ量
    - $5.00 / 1TB

  課金されない:
    - ストレージ（S3課金）
    - クエリ数
    - テーブル数

  削減方法:
    - Parquet/ORC
    - パーティション
    - 圧縮
    - 列指定（SELECT *避ける）

間違い 3: データ更新の誤解

❌ 誤り:
  「Athenaはデータ更新可能」

✅ 正解:
  - Athenaは読み取り専用
  - INSERT / UPDATE / DELETE不可

  データ更新方法:
    - S3でファイル追加・削除
    - CTAS で新テーブル作成
    - Glue ETLで変換

間違い 4: パーティションの誤解

❌ 誤り:
  「パーティション多いほど高速」

✅ 正解:
  過剰なパーティション:
    - メタデータ管理コスト
    - クエリ計画時間増加
    - 小ファイル問題

  適切な粒度:
    - 日次または時間
    - クエリパターン考慮
    - 100〜1000個推奨

間違い 5: Redshift との使い分け誤解

❌ 誤り:
  「Athenaは全ての分析に最適」

✅ 正解:
  Athena:
    - アドホック分析
    - 不定期クエリ
    - S3ベース
    - サーバーレス

  Redshift:
    - 定期的な大量クエリ
    - 複雑な集計
    - 低レイテンシ必要
    - データウェアハウス

  Redshift Spectrum:
    - 両方の利点
    - Redshift + S3

試験対策チェックリスト

基本概念

• Athena基本機能理解
• サーバーレスの意味
• S3直接クエリの仕組み
• 料金体系（スキャン量課金）

データ最適化

• Parquet/ORC メリット
• パーティション設計
• 圧縮形式
• ファイルサイズ最適化

統合

• Glue Data Catalog役割
• Glue Crawler機能
• QuickSight統合
• フェデレーテッドクエリ

高度な機能（SAP）

• Lake Formation統合
• マルチアカウント設計
• CTAS活用
• 大規模最適化戦略

セキュリティ

• IAMポリシー
• 暗号化設定
• ワークグループ制御
• 列・行レベルセキュリティ

まとめ

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

SAA:

• Athena = S3データをSQLで分析
• Parquet/ORC でコスト削減
• パーティションで高速化
• Glue Data Catalog でメタデータ管理
• サーバーレス・従量課金

SAP:

• 大規模データレイク設計
• マルチアカウント分析基盤
• フェデレーテッドクエリ戦略
• コスト最適化（10倍削減可能）
• Lake Formation統合
• Redshift / OpenSearch との使い分け
• 準リアルタイム分析パターン