[アップデート] AWS Glue 6.0 が一般提供開始、30% の価格削減と Apache Iceberg v3 サポートが追加されたので試してみました

[アップデート] AWS Glue 6.0 が一般提供開始、30% の価格削減と Apache Iceberg v3 サポートが追加されたので試してみました

AWS Glue 6.0 が一般提供開始となり、30% の価格削減と Apache Iceberg v3 サポートが追加されました。新機能は魅力的ですが、Spark 4.1 とのメジャーバージョンアップに伴う破壊的変更も多くあります。移行の判断ポイントと注意事項をまとめました。
2026.08.23

クラウド事業統括本部の石川です。AWS Glue 6.0 が一般提供(GA)となりました。30% の価格削減とあわせて、Apache Iceberg v3 の完全サポート、Apache Spark 4.1 系へのランタイム刷新が同時に提供されています。

コスト削減と新しいデータ型の両方が手に入る魅力的なアップデートですが、Apache Spark のメジャーバージョンアップに伴う破壊的変更も含まれています。移行を検討する際の判断材料としてご覧ください。Glue 6.0 の Glue ETL Job(Python)と Glue Interactive Session(Python)を試してみました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/08/aws-glue-6-0-price-reduction-iceberg-v3/

AWS Glue 6.0 アップデート内容

AWS Glue 6.0 の主な変更点は以下のとおりです。

  • 30% の価格削減
  • Apache Iceberg v3 の完全サポート(Iceberg 1.11.0)
  • Apache Hudi 1.1.1、Delta Lake 4.2.0 へのアップデート
  • ランタイムを Apache Spark 4.1.1、Python 3.13、Scala 2.13.17 へアップグレード
  • Spark Declarative Pipelines(SDP)による宣言的なパイプライン定義
  • Real-Time Mode ストリーミングによるサブ秒レイテンシー
  • Arrow-native Python UDF/UDTF による PySpark のパフォーマンス改善

30% の価格削減

今回のアップデートで最もインパクトが大きいのが価格削減です。AWS の発表では「30% の価格削減(30% price reduction)」と明記されています。大規模な ETL やバッチ処理を日常的に回している環境では、そのまま運用コストに効いてくる数字です。

課金体系そのものに変更はなく、1DPU $0.308/時の30% の価格削減されました。DPU 時間あたりの従量課金、1 秒単位の課金、1 分の最低課金時間という条件は従来どおりです。

  • $0.308 per DPU-hour for each Apache Spark or Spark Streaming job, billed per second with a 1-minute minimum (Glue version 6.0 and above)

https://aws.amazon.com/glue/pricing/

Apache Iceberg v3 の完全サポート

AWS Glue 6.0 では Apache Iceberg が 1.11.0 に更新され、Iceberg テーブル仕様のバージョン 3(format-version 3)に完全対応しました。追加された主な機能は以下のとおりです。

  • VARIANT データ型: 半構造化データを扱うためのデータ型です。variant shredding(自動シュレッディング)により、JSON のようなデータを内部的に列指向へ展開して読み取りを高速化します
  • ナノ秒精度のタイムスタンプ: 従来のマイクロ秒精度に加え、ナノ秒精度のタイムスタンプを保持できます
  • 地理空間データ型(Geometry / Geography): 位置情報を扱うワークロードをネイティブに表現できます
  • 柔軟なスキーマ進化: UNKNOWN データ型と DEFAULT 列値により、後方互換性を保ったままスキーマを変更しやすくなります

ここで 1 点補足しておきます。AWS の発表では Iceberg v3 の目玉として「削除ベクトル(deletion vectors)」も挙げられていますが、移行ガイドには、削除ベクトル(Puffin ファイルに Roaring Bitmap として格納される merge-on-read)と first-row-id メタデータによる行リネージ追跡は AWS Glue 5.1 以降ですでにサポート済みと明記されています。5.1 を利用中の方にとっては、6.0 での純粋な新規追加は VARIANT 型・ナノ秒タイムスタンプ・地理空間型・スキーマ進化まわりだと捉えるのが正確です。

ランタイムのアップグレード

AWS Glue 6.0 では、Spark エンジンとその周辺コンポーネントが大幅に更新されています。主な依存関係のバージョンは以下のとおりです。

依存関係 AWS Glue 6.0 AWS Glue 5.1 AWS Glue 5.0 AWS Glue 4.0
Java 17 17 17 8
Apache Spark 4.1.1 3.5.6 3.5.4 3.3.0-amzn-1
Hadoop 3.4.2 3.4.1 3.4.1 3.3.3-amzn-0
Scala 2.13.17 2.12.18 2.12.18 2.12
Python 3.13 3.11 3.11 3.10
Boto3 1.42.84 1.40.61 1.34.131 1.26
Arrow 18.3.0 12.0.1 12.0.1 7.0.0
AWS SDK for Java 2.44.6(v2 のみ) 2.35.5 2.29.52 1.12
Apache Iceberg 1.11.0 1.10.0 1.7.1 1.0.0
Apache Hudi 1.1.1 1.0.2 0.15.0 0.12.1
Delta Lake 4.2.0 3.3.2 3.3.0 2.1.0

Spark が 3.5 系から 4.1 系へ、Scala が 2.12 から 2.13 へと、いずれもメジャーバージョンをまたぐ更新である点に注目してください。後述する破壊的変更の多くは、この 2 つに起因します。

https://docs.aws.amazon.com/glue/latest/dg/migrating-version-60.html

開発生産性を高める新機能

Spark Declarative Pipelines(SDP)

SDP は、AWS Glue 6.0 から利用できる宣言的なパイプライン構築フレームワークです。YAML マニフェスト(spark-pipeline.yml)と SQL または Python の変換ファイルを用意すると、テーブル参照から DAG を推論して依存関係を解決し、独立したブランチを並列実行してくれます。読み取り・書き込み・カタログ登録・実行順序といった定型コードを書かずに済むのが利点です。

マニフェストには、出力先のデータベースや変換ファイルの場所を記述します。

name: my_analytics_pipeline
catalog: spark_catalog
database: analytics_db
storage: s3://my-bucket/pipeline-storage/
libraries:
  - glob:
      include: transformations/**

database は出力テーブルを登録するデータベース、storage はチェックポイントとメタデータを置く Amazon S3 パスです。両者は役割が異なる点に注意してください。

変換ファイルの中では、パイプラインの各処理段階の出力を「データセット」として定義します。SDP のデータセットには以下の 3 種類があり、どれを選ぶかで再計算の挙動が変わります。

  • ストリーミングテーブル: 前回実行以降の新規データのみを処理し、チェックポイントで状態を保持します。取り込みや CDC 向けです
  • マテリアライズドビュー: 実行のたびにフル再計算します。集計やレポート向けです(現行バージョンでは増分リフレッシュ非対応)
  • 一時ビュー: セッションスコープで永続化もカタログ登録もされません。中間処理向けです

たとえば SQL であれば、次のように書くだけでマテリアライズドビューが定義でき、bronze_salessilver_sales の依存関係は SDP が自動で解決します。

CREATE MATERIALIZED VIEW silver_sales AS
SELECT *, UPPER(region) as clean_region
FROM bronze_sales
WHERE amount > 0;

ジョブ側では --enable-spark-declarative-pipelinetrue に設定し、ScriptLocation にパイプライン定義の zip または Amazon S3 プレフィックスを指定します。

aws glue create-job \
  --name my-sdp-pipeline \
  --role arn:aws:iam::123456789012:role/MyGlueRole \
  --glue-version 6.0 \
  --worker-type G.1X --number-of-workers 2 \
  --command '{"Name":"glueetl","ScriptLocation":"s3://my-bucket/pipelines/my_pipeline.zip"}' \
  --default-arguments '{
      "--enable-spark-declarative-pipeline": "true",
      "--enable-glue-datacatalog": "true"
  }'

なお、ストリーミングテーブルで実行をまたぐ増分処理を行うには Iceberg テーブルが必要です(Hive 管理のストリーミングテーブルは非対応)。

もう 1 点、出力テーブルの保存先の指定でつまずきやすい箇所があります。SDP でテーブルを永続化するには、保存先となる Amazon S3 のパスを次のいずれかの方法で指定する必要があります。

  • spark.sql.warehouse.dir に S3 パスを設定する
  • 前述の YAML マニフェストの database フィールドで出力先データベースを指定し、その AWS Glue データベースの LocationUri に S3 パスを設定しておく

後者を選ぶ場合、対象のデータベースに LocationUri が設定されていないとテーブルを作成できません。マネジメントコンソールから作成した AWS Glue データベースは LocationUri が空のままになっていることが多いため、事前の確認をおすすめします。設定されていない場合は、以下のように保存先を明示して作成します。

aws glue create-database --database-input '{
  "Name":"my_pipeline_db",
  "LocationUri":"s3://my-bucket/warehouse/my_pipeline_db"
}'

Real-Time Mode ストリーミング

Spark Structured Streaming 向けの新しい実行モードで、エンドツーエンドのレイテンシーを 1 秒未満(サブ秒)まで短縮します。条件が合うワークロードではミリ秒レベルのレイテンシーも狙えます。

この「1 秒未満」は、既定のマイクロバッチモードの下限との対比で理解すると分かりやすいと思います。Micro Batch Modeは、インターバルごとにタスクを起動し、蓄積されたデータを読み取り、処理してチェックポイントをコミットし、タスクを終了する、という流れを繰り返します。この繰り返しのオーバーヘッドがあるため、最小レイテンシーは 1〜2 秒程度が下限になります。

一方の Real-Time Mode では、タスクを一度起動したらバッチウィンドウ(既定 5 分)の間は動かし続け、レコードが到着した端から処理します。データが溜まるのを待たないため、マイクロバッチの下限である 1〜2 秒を切れるという仕組みです。

利用には --enable-real-time-mode ジョブ引数での明示的なオプトインが必要で、forEachBatch ではなく writeStreamTrigger.RealTime を使います。ただし現時点では以下の制約があるため、適用できるワークロードはかなり限定されます。

  • ジョブタイプは Spark Streaming(gluestreaming)であること
  • ソースは Apache Kafka のみ(Amazon Kinesis は AWS Glue 6.0 の Real-Time Mode では非対応)
  • ステートレスな処理のみ(集計・結合・重複排除・ウィンドウ処理などのステートフル操作は非対応)
  • 言語は Scala のみ(PySpark 対応は Spark 4.2 まで待つ必要があります)
  • 出力モードは Update のみ(Append を指定すると OUTPUT_MODE_NOT_SUPPORTED になります)
  • Auto Scaling 非対応(固定ワーカー数で運用する)

もう 1 つ、運用上で見落とすと痛い挙動があります。タスクスロットがソースの全パーティションをカバーできない場合、割り当てられなかったパーティションはエラーにならずそのまま処理されません。ソーストピックの Kafka パーティション数以上のワーカーを固定で確保しておく必要があります。

集計処理を含む場合、ソースが Amazon Kinesis の場合、PySpark で書いている場合、forEachBatch や GlueContext のストリーミング API を使っている場合、Auto Scaling に頼りたい場合は、引き続きマイクロバッチモードを使うことになります。Kafka to Kafka のフィルタリングやルーティングのような、低レイテンシーが要件のステートレス変換が主なターゲットです。

その他の生産性向上機能

  • Arrow-native Python UDF/UDTF: Apache Arrow の列指向フォーマットをネイティブに利用し、Python ユーザー定義関数のパフォーマンスを改善します
  • Spark Connect for Interactive Sessions: Spark Connect プロトコル経由でシンクライアントから AWS Glue Interactive Sessions へ接続でき、リモート開発ワークフローに対応します
  • --python-virtual-env: 自前でビルドした Python 仮想環境を Spark ドライバー/エグゼキューターにアタッチでき、依存関係を完全にコントロールできます。既存ジョブを 6.0 に移行した際は、必要に応じて AWS Glue が仮想環境を自動生成します

対応リージョン

AWS Glue 6.0 は、すべての AWS 商用リージョン、AWS GovCloud (US)、AWS 中国リージョンで利用可能です。

移行時の注意点

ここからが実務上の本題です。AWS Glue 6.0 は Spark 4.1 と Scala 2.13 への移行を伴うため、既存ジョブがそのまま動くとは限りません。

破壊的変更

移行ガイドに記載されている破壊的変更は以下のとおりです。

  • ANSI モードがデフォルトで有効: Spark 4.1 では ANSI モードが既定で ON になります。整数のオーバーフロー、不正なキャスト、配列の範囲外アクセスなどが、これまでの NULL 返却から例外送出に変わります。従来の挙動に戻すには spark.sql.ansi.enabled=false を設定します
  • EMRFS の削除: S3 ファイルシステムは S3A のみになりました。com.amazon.ws.emr.hadoop.fs.EmrFileSystem は利用できません。s3:// パスは自動的に S3A を使用します。fs.s3.consistent.* などの EMRFS 固有設定は削除が必要です
  • AWS SDK for Java v1 の削除: v2(2.44.6)のみが利用可能です。com.amazonaws.services.* を import しているジョブは software.amazon.awssdk.services.* への移行が必要です。なお Python の boto3 はそのまま利用できます
  • Scala 2.12 から 2.13 へのアップグレード: Scala 2.12 でコンパイルしたカスタム JAR は動作しません。2.13.17 で再コンパイルが必要です。JavaConversions は削除されているため CollectionConverters へ、MutableListListBuffer へ置き換えます
  • Spark 4.1 の API 変更: SQLContext が削除されたため SparkSession を直接使用します。非推奨 API もいくつか削除されています
  • getResolvedOptions の挙動変更: 引数の前方一致(省略形)がデフォルトで無効(allow_abbrev=False)になりました。引数名は省略せずフルネームで指定するか、allow_abbrev=True を渡して従来の挙動に戻します
  • CreateSession API の検証強化: Interactive Sessions のセッションパラメーターに対する検証が追加され、これまで暗黙的に受け入れられていた設定がエラーになる場合があります

既知の制限事項

特に見落としやすいのが、Iceberg v3 まわりの制限です。

  • Iceberg v3 テーブルは Athena SQL から読み取れませんCannot read unsupported version 3 エラー)。Athena をはじめとする他エンジンとの互換性が必要な場合は、Iceberg v2 のまま運用します
  • Iceberg v3 の新データ型は Spark DataFrame でのみ利用可能です。DynamicFrame では動作しません
  • AWS Glue Studio の Visual ETL は Iceberg v3 の新データ型に非対応です。ビジュアル ETL で新機能を使いたい場合は、Amazon SageMaker Unified Studio への移行が推奨されています
  • VARIANT 列は FGAC(きめ細かなアクセスコントロール)に非対応です。データガバナンス要件がある環境では影響を確認してください
  • Iceberg のネイティブテーブル暗号化キー、および複数引数の transform は非対応です

BI ツールや他チームの分析基盤が Athena 経由で同じテーブルを参照しているケースは珍しくありません。「Glue 6.0 に上げたら Athena からクエリできなくなった」という事故を避けるため、Iceberg テーブルを新規作成する際の format-version の指定は特に注意が必要です。

移行チェックリスト

移行ガイドに記載されているチェックリストは以下のとおりです。

  • Scala
    • カスタム JAR を Scala 2.13.17 で再コンパイルする。JavaConversionsCollectionConverters に置き換える
  • Python
    • Python 3.13 互換にコードを更新する。impcgicgitb など削除されたモジュールの利用をやめる
    • boto3 の参照を 1.40 系から 1.42 系に更新する
  • Spark SQL
    • ANSI モードの影響をクエリごとに確認する。必要なら spark.sql.ansi.enabled=false を追加する
  • SDK
    • AWS SDK v1(com.amazonaws.*)の import を v2(software.amazon.awssdk.*)に置き換える
  • S3
    • EMRFS 固有の設定を削除する
  • 依存関係
    • --extra-jars を Scala 2.13 / Spark 4.1 向けにビルドしたものへ更新する

移行判断の目安

ここまでの内容を踏まえた移行判断の流れを整理すると、次のようになります。

移行を支援するツール

移行ガイドでは、既存の ETL ジョブを新しいバージョンへ引き上げる手段として Generative AI upgrades for Apache Spark(Spark Upgrades)が案内されています。ジョブのコードをスキャンしてアップグレード計画を生成し、検証実行まで自動化してくれる機能です。

ただし、Spark Upgrades のドキュメント側には、対象が PySpark ジョブに限られること、外部ライブラリに依存しないコードが前提であること、アカウントあたり同時実行は 10 ジョブまでといった制約や、対応バージョン範囲に関する記載があります。手元のジョブが対象になるかは、実行前にドキュメントで確認してください。

https://docs.aws.amazon.com/glue/latest/dg/upgrade-analysis.html

やってみた

利用方法

新規ジョブの場合は、作成時に Glue version として 6.0 を選択します。

  • コンソール: Spark 4.1.1, Python 3 (Glue Version 6.0) または Spark 4.1.1, Scala 2 (Glue Version 6.0) を選択
  • AWS Glue Studio: Glue 6.0 - Supports Spark 4.1.1, Scala 2, Python 3 を選択
  • API: CreateJobGlueVersion パラメーターに 6.0 を指定

既存ジョブの場合は、ジョブ設定の Glue version を 6.0 に変更するか、UpdateJob API の GlueVersion パラメーターに 6.0 を指定します。

AWSCLIのバージョンは、執筆時点最新の2.36.29です。

% aws --version
aws-cli/2.36.29 Python/3.14.6 Darwin/25.5.0 exe/arm64

Glue 6.0 の Glue ETL Job(Python)の例

Glue 6.0 の Glue ETL Job(Python)の例です。Glue Versionに Glue 6.0 - Supports Spark 4.1.1, Scala 2, Python 3 を選択します。

20260823-aws-glue-6-1

そのまま実行するとエラーになりました。原因は、ソースの実データがLake Foprmationのデータロケーションに登録されていないためです。権限付与します。

% aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/AWSGlueServiceRoleDefault --resource '{"Database":{"Name":"superstore"}}' --permissions DESCRIBE && aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/AWSGlueServiceRoleDefault --resource '{"Table":{"DatabaseName":"superstore","Name":"superstore_joined"}}' --permissions SELECT DESCRIBE

これまでと特に変わらず実行できました。

20260823-aws-glue-6-2

なお、AWS CLI で新規ジョブを作成する場合は、--glue-version6.0 を指定します。

aws glue create-job \
  --name glue6-etl-job \
  --role arn:aws:iam::123456789012:role/AWSGlueServiceRoleDefault \
  --glue-version 6.0 \
  --worker-type G.1X --number-of-workers 2 \
  --command '{"Name":"glueetl","ScriptLocation":"s3://my-bucket/scripts/my_job.py"}'

Glue Interactive Session(Python)の例

Interactive Sessionは、マネジメントコンソールから作成できないので、AWSCLIを用いて作成します。

% aws glue create-session \
  --id glue6-interactive-session \
  --role arn:aws:iam::123456789012:role/AWSGlueServiceRoleDefault \
  --command '{"Name":"glueetl","PythonVersion":"3"}' \
  --glue-version 6.0 \
  --number-of-workers 2 --worker-type G.1X \
  --idle-timeout 30
{
    "Session": {
        "Id": "glue6-interactive-session",
        "CreatedOn": "2026-08-22T23:56:58.593000+09:00",
        "Status": "PROVISIONING",
        "Role": "arn:aws:iam::123456789012:role/AWSGlueServiceRoleDefault",
        "Command": {
            "Name": "glueetl",
            "PythonVersion": "3"
        },
        "DefaultArguments": {},
        "Progress": 0.02,
        "MaxCapacity": 2.0,
        "GlueVersion": "6.0",
        "NumberOfWorkers": 2,
        "WorkerType": "G.1X",
        "ExecutionTime": 0.0,
        "DPUSeconds": 0.0,
        "IdleTimeout": 30,
        "SessionType": "LIVY"
    }
}

2DPU の Interactive Session が作成できました。

20260823-aws-glue-6-3

詳細は以下のとおりです。

20260823-aws-glue-6-4

最後に

AWS Glue 6.0 は、30% の価格削減、Apache Iceberg v3 の完全サポート、Apache Spark 4.1.1 へのランタイム刷新という 3 つの大きな変更を一度に含むリリースです。Spark Declarative Pipelines や Real-Time Mode といった、パイプライン開発そのものを変える機能も追加されました。

一方で、ANSI モードのデフォルト有効化、Scala 2.13 への移行、EMRFS と AWS SDK for Java v1 の削除など、既存ジョブに影響する破壊的変更も少なくありません。特に、Iceberg v3 テーブルを Athena SQL から読み取れない点は、下流の分析基盤ごと巻き込む可能性があるため事前確認が欠かせません。

まずは本番以外のジョブを 6.0 に切り替え、ANSI モードとカスタム JAR まわりの影響範囲を洗い出すところから始めるとスムーズです。コスト削減効果が大きいアップデートですので、この機会に移行を検討してみてはいかがでしょうか。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事