AWS Glue

解決する課題

複数のデータソース（S3上のログ、RDB、DWHなど）を集めて分析できる形に整える「データ統合」は、抽出・変換・ロード（ETL）の処理基盤を自前で組むと、サーバーの調達、ジョブの実行管理、スキーマの把握、スケーリングに多くの工数がかかります。AWS Glue はこれらを肩代わりします。

• 散在するデータのスキーマと所在を自動で発見・カタログ化する
• ETL/ELT 処理をサーバーレスで実行し、クラスタやサーバーを管理しない
• 処理量に応じてリソースが自動でスケールする
• カタログを Athena や Redshift Spectrum、EMR と共有し、データレイク全体の共通メタデータにできる

定期的なデータ変換パイプライン、データレイクのカタログ整備、分析前のデータクレンジングなどに向きます。

主要概念と用語

• データカタログ（Data Catalog）: テーブルのスキーマ（列名・型・データの場所）を保持する中央メタデータストア。Athena や EMR など複数サービスから参照される
• データベース / テーブル: カタログ内の論理的な入れ物とスキーマ定義。実データは元の場所（S3 など）に残る
• クローラ（Crawler）: データソースを走査してスキーマを推論し、カタログにテーブルを自動作成・更新する仕組み
• 分類子（Classifier）: ファイル形式やスキーマの判定ルール。組み込みのほかカスタム定義も可能
• ETL ジョブ: 抽出・変換・ロードを行う処理本体。Spark ベースのジョブや、軽量データ向けの Python シェルジョブなどがある
• DynamicFrame: スキーマが揺らぐ半構造化データも扱える、Glue 独自のデータ構造（Spark の DataFrame に相当）
• トリガー / ワークフロー: ジョブやクローラの実行をスケジュールやイベントで連鎖させる仕組み
• Glue Studio: ジョブを視覚的に作成・編集できる GUI
• データ品質（Data Quality）: カタログのデータに対し品質ルールを定義・評価する機能

仕様・制限・クォータ

• サーバーレスで動作し、ETL ジョブの計算リソースはジョブ実行時に自動で確保・解放される
• Spark ジョブの処理能力は DPU（Data Processing Unit） という単位で割り当てられ、ジョブごとに台数を指定する
• S3、各種 RDB、DWH、ストリームなど多様なソースに接続でき、VPC 内のデータソースへは接続定義を介してアクセスする
• カタログ内のデータベース・テーブル・パーティション数などにサービスクォータがあり、必要に応じて引き上げを申請できる
• データカタログは Athena、Redshift Spectrum、EMR など他サービスの共通メタデータとして利用できる
• 具体的な上限値や単価は変動するため、利用時に公式の最新情報を確認する

内部の仕組み

Glue は大きく「カタログ化」と「ETL 実行」の2つの役割を持ちます。

• クローラがデータソースを走査し、分類子でフォーマットとスキーマを推論して、カタログにテーブルとパーティションを登録・更新する。実データは移動せず、メタデータだけが作られる
• ETL ジョブは、内部でマネージドな Apache Spark 環境（または Python シェル環境）を起動し、ソースから読み取り、変換し、ターゲットへ書き出す。Spark ジョブでは半構造化データを扱いやすい DynamicFrame を中心に処理を記述できる
• ジョブの計算リソースはユーザーがクラスタを管理せず、AWS 側で確保・スケール・解放される
• トリガーやワークフローでクローラとジョブを連結し、依存関係のあるパイプラインを構築できる

設計パターン / ベストプラクティス

• カタログを単一の真実とする: クローラで自動更新し、Athena・EMR・Redshift Spectrum から同じテーブル定義を共有する
• 列指向フォーマットへ変換: ETL の出力を Parquet や ORC など列指向にし、後段の分析のスキャン量と料金を抑える
• パーティション設計: 日付などのキーでフォルダ分割し、クローラのパーティション認識と後段の絞り込みを効かせる
• ブックマークの活用: ジョブブックマークで処理済みデータを記録し、増分のみを処理して再処理を避ける
• 小ファイルの統合: 大量の小ファイルはオーバーヘッドになるため、適切なサイズへまとめる
• 権限管理は Lake Formation と連携: データレイクの細粒度アクセス制御はカタログ単体ではなく Lake Formation で集中管理する

運用・監視

• CloudWatch でジョブの実行メトリクス（実行時間、DPU 使用、失敗数など）を監視する
• ジョブのログとエラーは CloudWatch Logs に出力され、失敗ジョブの原因調査に使う
• ジョブの再試行回数やタイムアウトを設定し、一時的な失敗を吸収しつつ暴走を防ぐ
• トリガー / ワークフローで実行を自動化し、依存ジョブの順序や失敗時の挙動を管理する
• クローラのスケジュール実行でスキーマ変更を継続的にカタログへ反映する
• API 操作の監査は CloudTrail で行う

コスト

• 課金は主に ETL ジョブやクローラの実行時間（Spark ジョブは割り当てた DPU と実行時間）に対する従量制で、待機中のコストは発生しにくい
• データカタログの保存オブジェクト数やリクエスト数に対しても料金が発生する場合がある
• ジョブブックマークで増分処理にし、無駄な再処理を減らすほど安くなる
• 出力を圧縮・列指向フォーマット化すると、後段の Athena などのコストも下げられる
• 変動する具体的な単価は公式の料金ページで確認する

セキュリティ

• アクセス制御は IAM で行い、ジョブ実行ロールやカタログへの権限を最小権限に絞る
• データは保存時暗号化（S3/カタログ、鍵は KMS）と転送時の TLS で保護する
• VPC 内のデータソースへは接続定義経由でプライベートに到達し、必要に応じてセキュリティグループで通信を絞る
• 接続に使う認証情報は直書きせず、Secrets Manager などで安全に管理する
• データレイク全体の列・行レベルの細粒度アクセス制御は Lake Formation と組み合わせて実現する

Well-Architected の観点

• 運用上の優秀性: サーバー管理が不要で、クローラとトリガーによりカタログ化とパイプラインを自動化できる
• コスト最適化: 実行した分だけの従量課金、ジョブブックマークによる増分処理、待機コストの排除
• パフォーマンス効率: 自動スケールと列指向フォーマット・パーティションによる後段処理の効率化
• セキュリティ: 最小権限の IAM、暗号化、Secrets Manager と Lake Formation による認証情報・アクセス管理

試験で問われるポイント

関連サービス・比較

クラスタ型のビッグデータ基盤 Amazon EMR とよく比較されます。クラスタを制御したい大規模・反復処理は EMR、運用を最小化したいサーバーレス ETL は Glue が向きます。

ハンズオン / CLI例

# カタログ用のデータベースを作成
aws glue create-database \
  --database-input "Name=mydb"

# S3を走査してスキーマをカタログ化するクローラを作成
aws glue create-crawler \
  --name my-s3-crawler \
  --role AWSGlueServiceRole-demo \
  --database-name mydb \
  --targets '{"S3Targets":[{"Path":"s3://my-data-bucket/raw/"}]}'

# クローラを実行（完了後、mydb にテーブルが作成される）
aws glue start-crawler --name my-s3-crawler

# 作成されたテーブル一覧を確認
aws glue get-tables --database-name mydb \
  --query "TableList[].Name"