AWS Glue

1. 概要

AWS Glue は、データの抽出・変換・ロード（ETL）を行うためのフルマネージドなサーバーレスデータ統合サービス。

データ分析の世界では、データはさまざまなソース（データベース、ログ、SaaS アプリケーション等）に散在しており、そのままでは分析に使えない。Glue はこの「データを集めて、整えて、分析基盤に投入する」というパイプライン全体を構築・運用するためのサービスである。

Glue の核となる機能は大きく 2 つある。

• Data Catalog（データカタログ） — データソースのスキーマやロケーションなどのメタデータを一元管理するリポジトリ。Athena、Redshift Spectrum、EMR など他の AWS サービスからも参照できるため、AWS のデータ分析基盤における「メタデータのハブ」として機能する
• ETL エンジン — Apache Spark ベースのサーバーレスな分散処理エンジン。サーバーのプロビジョニングやクラスタ管理なしに、大量データの変換処理を実行できる

責任共有モデルにおける位置づけ

Glue はサーバーレスサービスに分類される。インフラの管理（サーバーのプロビジョニング、パッチ適用、スケーリング）はすべて AWS が担当する。ユーザーが責任を持つのは、ETL スクリプトのロジック、Data Catalog のアクセス制御（IAM ポリシー、リソースポリシー）、データそのもののセキュリティ（暗号化設定）である。

2. ユースケース

• データレイクを構築したいとき — S3 にさまざまなソースのデータを集約し、Data Catalog でスキーマを管理する。Crawler で自動的にスキーマを検出できるため、新しいデータソースを追加するたびに手動でスキーマ定義をする手間が省ける
• データウェアハウスへのロード前にデータを変換・クレンジングしたいとき — 不要なカラムの削除、データ型の変換、NULL 値の補完、重複レコードの排除などの前処理を、Spark ベースのジョブでスケーラブルに実行できる
• 複数のデータソースを結合・統合したいとき — RDS、DynamoDB、S3、JDBC 接続可能な外部 DB など異なるソースからデータを取得し、1 つのデータセットに統合する
• 定期的なバッチ ETL パイプラインを構築したいとき — ワークフロー機能やスケジューラ（EventBridge / cron 式）を使って、毎日・毎時の定期実行パイプラインを構築できる
• Athena や Redshift Spectrum で S3 のデータにクエリしたいとき — Data Catalog にテーブル定義を登録することで、SQL による分析が可能になる。Glue を直接使わなくても、Data Catalog の恩恵を受けるケースは多い

3. 基本概念

4. アーキテクチャ概要

代表構成（データレイク ETL パイプライン）

以下は、複数のデータソースから S3 データレイクにデータを集約し、分析基盤から参照する典型的な構成。Glue Crawler がソースのスキーマを検出し、Glue Job がデータを変換して分析用のフォーマット（Parquet 等）で S3 に書き出す。Athena や Redshift Spectrum は Data Catalog のテーブル定義を通じてデータにクエリする。

[データソース群]
  ├── RDS (MySQL / PostgreSQL)
  ├── DynamoDB
  └── S3 (CSV / JSON ログ)
         ↓
[Glue Crawler] ── スキーマ検出 ──→ [Glue Data Catalog]
         ↓                                ↑ 参照
[Glue ETL Job] ── 変換・クレンジング      │
         ↓                                │
[S3 データレイク (Parquet)]               │
         ↓                                │
[Athena / Redshift Spectrum] ─────────────┘
         ↓
[QuickSight (BI ダッシュボード)]

構成図生成プロンプト: 上記構成をアーキテクチャ図として作成する場合、以下のプロンプトを画像生成 AI や draw.io 等で使用できる。 「AWS アーキテクチャ図。左側にデータソース群（RDS、DynamoDB、S3 の CSV/JSON）を配置。中央に Glue Crawler と Glue ETL Job を配置し、上部に Glue Data Catalog を配置。Crawler からカタログへの矢印と、ETL Job から S3 データレイク（Parquet フォーマット）への矢印を描く。右側に Athena と Redshift Spectrum を配置し、Data Catalog を参照する矢印を描く。最右に QuickSight のダッシュボードアイコンを配置。全体を VPC の枠で囲まず、サーバーレスであることを示す。」

設計ポイント

• Data Catalog は「一度作ったら他のサービスから使い回す」ことを前提に設計する — Athena、Redshift Spectrum、EMR のいずれも同じ Data Catalog を参照できる。テーブル定義の命名規則やパーティション設計を最初に統一しておくことが重要
• S3 のパーティション設計が分析パフォーマンスに直結する — s3://bucket/year=2026/month=03/day=22/ のように日時でパーティション分割すると、クエリ時に必要なデータだけをスキャンでき、コストと速度の両方で大きな差が出る
• データフォーマットは Parquet を基本とする — 列指向フォーマットのため、特定カラムのみを読み込むクエリで大幅に I/O を削減できる。CSV と比較して 10〜100 倍のクエリ性能差が出ることもある

5. 主要機能

ETL ジョブ

Glue の中核機能。データの変換処理を実行するサーバーレスジョブ。

Spark ジョブでは、Glue 独自の DynamicFrame API が利用できる。Spark の DataFrame と互換性がありつつ、スキーマの不整合（同じカラムに異なる型が混在する場合）に柔軟に対応できる点が特徴。

Glue Studio

ビジュアル ETL エディタ。ドラッグ＆ドロップで ETL パイプラインを構築できるため、コードを書かずにデータ変換のフローを作成できる。裏では自動的に PySpark コードが生成される。

プロトタイプの作成や単純な変換処理には有用だが、複雑なロジックやパフォーマンスチューニングが必要な場合はコードベースのジョブの方が制御しやすい。

Crawler

データソースを自動スキャンし、スキーマ（カラム名、データ型）を推定して Data Catalog にテーブル定義を登録する。対応ソースは S3、JDBC（RDS、Redshift 等）、DynamoDB、MongoDB など。

Crawler はスキーマの変更も検知できる。カラムの追加や型の変更があった場合、設定に応じてテーブル定義を自動更新する。

Data Catalog

AWS 全体のメタデータリポジトリ。以下の特徴がある。

• Apache Hive Metastore 互換のインターフェースを持つため、既存の Hive エコシステムのツールからも参照可能
• テーブル定義にパーティションキーを設定すると、クエリエンジン（Athena 等）がパーティションプルーニング（不要なパーティションの読み飛ばし）を自動で行う
• リソースポリシーと IAM ポリシーの組み合わせで、テーブル単位のアクセス制御が可能

Data Quality

テーブルデータの品質チェック機能。DQDL（Data Quality Definition Language）というルール記述言語で「カラム X の NULL 率が 5% 以下」「カラム Y の値が特定の範囲内」といった品質ルールを定義し、ジョブの一部として自動的に検証できる。

Glue Schema Registry

Apache Avro や JSON Schema のスキーマをバージョン管理するサービス。Kafka や Kinesis Data Streams と連携し、プロデューサーとコンシューマー間でスキーマの互換性を保証する。

6. 料金体系

Glue はサーバーレスのため、基本的に「使った分だけ」の課金だが、課金単位がコンポーネントごとに異なる。

主な課金要素

見落としがちなコスト

• ジョブの DPU 数の過剰割り当て — デフォルトで Spark ジョブには 10 DPU が割り当てられる。小〜中規模のデータ処理では 2〜5 DPU で十分な場合が多く、デフォルトのまま実行するとコストが不必要に膨らむ
• Crawler の高頻度実行 — Crawler も DPU 時間で課金されるため、毎時間実行するとそれだけでコストが発生する。データソースの更新頻度に合わせて適切なスケジュールを設定する
• 開発エンドポイント（レガシー） — 旧来の開発エンドポイントは起動中ずっと DPU 課金が発生する。現在は Glue Studio のノートブックや Glue Interactive Sessions を使う方がコスト効率が良い
• S3 のストレージとリクエスト料金 — ETL ジョブの入出力で発生する S3 への読み書きコストは Glue の料金には含まれない。大量データを処理する場合は S3 側のコストも考慮が必要

7. 比較・選定指針

「データ変換や統合を行いたい」場合に Glue を選ぶべきかどうか、類似サービスと比較する。

Glue を選ぶ判断基準

以下のいずれかに該当する場合は Glue が適している。

• S3 データレイクを中心としたアーキテクチャで、Data Catalog によるメタデータ管理が必要
• サーバレスで ETL パイプラインを運用したい（クラスタ管理を避けたい）
• Athena や Redshift Spectrum と連携して分析基盤を構築する
• データ量が数 GB 〜 TB 規模で、Spark の分散処理が必要

Glue vs EMR の判断

Glue と EMR は共に Spark を実行できるが、設計思想が異なる。

• Glue: サーバーレスですぐに使い始められる。ジョブ単位で DPU を割り当てるため、断続的な ETL 処理に適している。ただし、Spark のバージョンやライブラリの自由度は EMR に劣る
• EMR: クラスタを自分で構成する。Spark のバージョン選択、カスタムライブラリのインストール、細かいクラスタ設定が可能。常時稼働のデータ処理基盤や、高度なチューニングが必要な場合に適している

8. 運用・監視

主要メトリクス（CloudWatch）

ログ

Spark UI の活用: ジョブ設定で --enable-spark-ui true と --spark-event-logs-path s3://... を指定すると、Spark UI のログが S3 に保存される。Glue コンソールから Spark UI を起動して、ステージごとの実行計画やデータスキュー（偏り）を可視化できる。パフォーマンス調査の際に非常に有用。

運用ツール

• CloudWatch Alarms — ジョブの実行時間やエラー率にアラームを設定し、異常時に SNS 通知を送信する
• EventBridge — ジョブの状態変化（SUCCEEDED / FAILED / TIMEOUT）をイベントとして検知し、後続処理のトリガーや通知に活用する
• AWS Glue DataBrew — データの探索・プロファイリング・クレンジングに特化したビジュアルツール。ジョブ開発前のデータ理解に役立つ

9. トラブルシューティング

問題：ジョブが OutOfMemoryError で失敗する

原因:

• 処理データ量に対して DPU の割り当てが不足している
• データスキュー（特定のパーティションにデータが偏っている）が発生し、一部のワーカーにメモリ負荷が集中している
• ブロードキャスト結合で大きなテーブルをメモリに載せようとしている

確認手順:

1. CloudWatch Logs のエラーログで OOM が発生しているステージを特定する
2. Spark UI でステージごとのシャッフルサイズとタスクの処理時間分布を確認する
3. データスキューがある場合は、repartition でデータを均等に分散させる
4. DPU 数を増やして再実行する（2 DPU → 5 DPU → 10 DPU と段階的に増やす）
5. 根本的にデータ量が大きい場合は、入力データをパーティション単位で分割して処理する（日別処理など）

問題：Crawler がスキーマを正しく認識しない

原因:

• CSV ファイルにヘッダ行がない、またはヘッダの区切り文字がデータと異なる
• 同じ S3 パス配下に異なるフォーマットのファイルが混在している
• ファイルの文字エンコーディングが UTF-8 でない

確認手順:

1. Crawler のログ（CloudWatch Logs）でスキーマ推定結果を確認する
2. S3 パスに意図しないファイル（中間ファイル、一時ファイル等）が含まれていないか確認する
3. Crawler の設定で除外パターン（_temporary/** 等）を追加する
4. スキーマの自動推定がうまくいかない場合は、Crawler に頼らず手動でテーブル定義を作成する

問題：ジョブの実行が遅い

原因:

• DPU 数が不足しており並列度が低い
• 入力データが CSV 形式で列指向でないため、不要なカラムも全て読み込んでいる
• Shuffle が大量に発生している（JOIN や GROUP BY で大量のデータ移動が起きている）
• 小さなファイルが大量にある（Small Files Problem）

確認手順:

1. Spark UI でボトルネックのステージを特定する
2. 入力データのフォーマットを確認する。CSV であれば Parquet に変換することで大幅に高速化できる
3. S3 上のファイル数とサイズを確認する。1 ファイルあたり 100 MB〜1 GB が目安。小さなファイルが大量にある場合は事前に結合する（coalesce / repartition）
4. ジョブブックマークが有効な場合、増分処理で入力データ量を削減できているか確認する
5. DPU 数を増やして効果を測定する

問題：ジョブブックマークが機能しない（同じデータを重複処理する）

原因:

• ジョブブックマークが有効化されていない
• データソースが S3 で、ファイルのタイムスタンプが変更されている（ファイルの上書き更新）
• 入力パスの指定方法がブックマーク非対応のパターンになっている

確認手順:

1. ジョブの設定でブックマークが Enable になっているか確認する
2. S3 ソースの場合、ファイルが追記方式（新規ファイル追加）になっているか確認する。上書き更新はブックマークで追跡できない
3. from_catalog または from_options メソッドで transformation_ctx パラメータが正しく指定されているか確認する（ブックマークの識別子として使われる）

10. 実装例

AWS CLI

# Crawler の作成
aws glue create-crawler \
  --name my-s3-crawler \
  --role GlueServiceRole \
  --database-name my_database \
  --targets '{"S3Targets": [{"Path": "s3://my-bucket/raw-data/"}]}'

# Crawler の実行
aws glue start-crawler --name my-s3-crawler

# Data Catalog のテーブル一覧を取得
aws glue get-tables --database-name my_database

# ジョブの実行
aws glue start-job-run \
  --job-name my-etl-job \
  --arguments '{"--input_path":"s3://my-bucket/raw-data/","--output_path":"s3://my-bucket/processed/"}'

# ジョブの実行状態を確認
aws glue get-job-run \
  --job-name my-etl-job \
  --run-id jr_xxxxxxxxxxxxx

Terraform

# Data Catalog データベース
resource "aws_glue_catalog_database" "analytics" {
  name = "analytics_db"
}

# Crawler
resource "aws_glue_crawler" "raw_data" {
  name          = "raw-data-crawler"
  database_name = aws_glue_catalog_database.analytics.name
  role          = aws_iam_role.glue.arn
  schedule      = "cron(0 1 * * ? *)" # 毎日 1:00 UTC

  s3_target {
    path = "s3://${aws_s3_bucket.data_lake.bucket}/raw/"
  }

  schema_change_policy {
    update_behavior = "UPDATE_IN_DATABASE"
    delete_behavior = "LOG"
  }
}

# ETL ジョブ
resource "aws_glue_job" "etl" {
  name     = "raw-to-parquet"
  role_arn = aws_iam_role.glue.arn

  command {
    name            = "glueetl"
    script_location = "s3://${aws_s3_bucket.scripts.bucket}/etl/transform.py"
    python_version  = "3"
  }

  default_arguments = {
    "--job-bookmark-option"   = "job-bookmark-enable"
    "--enable-spark-ui"       = "true"
    "--spark-event-logs-path" = "s3://${aws_s3_bucket.logs.bucket}/spark-ui/"
    "--TempDir"               = "s3://${aws_s3_bucket.temp.bucket}/glue-temp/"
  }

  number_of_workers = 5
  worker_type       = "G.1X"
  glue_version      = "4.0"

  tags = {
    Environment = "production"
  }
}

# ワークフロー（Crawler → Job のパイプライン）
resource "aws_glue_workflow" "daily_etl" {
  name = "daily-etl-pipeline"
}

resource "aws_glue_trigger" "start_crawler" {
  name          = "start-crawler"
  type          = "SCHEDULED"
  schedule      = "cron(0 1 * * ? *)"
  workflow_name = aws_glue_workflow.daily_etl.name

  actions {
    crawler_name = aws_glue_crawler.raw_data.name
  }
}

resource "aws_glue_trigger" "start_job" {
  name          = "start-job-after-crawler"
  type          = "CONDITIONAL"
  workflow_name = aws_glue_workflow.daily_etl.name

  predicate {
    conditions {
      crawler_name = aws_glue_crawler.raw_data.name
      crawl_state  = "SUCCEEDED"
    }
  }

  actions {
    job_name = aws_glue_job.etl.name
  }
}

11. アンチパターン

12. 参考リンク

• AWS Glue 公式ドキュメント
• AWS Glue API リファレンス
• AWS CLI Glue リファレンス
• AWS Glue の料金
• AWS Black Belt - AWS Glue
• AWS Glue ベストプラクティス