Amazon Web Services ブログ
Amazon Aurora MySQL から Amazon S3 Tables に Apache Iceberg 形式でデータを抽出する
本記事は 2026 年 3 月 23 日 に公開された「Extract data from Amazon Aurora MySQL to Amazon S3 Tables in Apache Iceberg format」を翻訳したものです。
Amazon Aurora MySQL-Compatible Edition でデータを管理していて、分析や機械学習 (ML)、サービス横断のクエリに活用できるモダンなレイクハウス形式で利用可能にしたい、という方は多いのではないでしょうか。
組織では分析の実行、ML モデルの構築、複数ソースのデータの結合が必要になることがよくあります。こうしたワークロードはリソースを大量に消費し、トランザクションデータベースで直接実行するのは現実的ではありません。Aurora MySQL のデータを Amazon S3 Tables に Apache Iceberg 形式で抽出すれば、本番データベースのパフォーマンスに影響を与えずに分析クエリをオフロードでき、分析に最適化されたフルマネージドの Iceberg テーブルストアにデータを保存できます。オープンな Apache Iceberg 標準に基づく Amazon Simple Storage Service (Amazon S3) Tables のデータは、Amazon Athena、Amazon Redshift Spectrum、Apache Spark などのエンジンから追加のデータコピーなしでクエリできます。さらに、データレイクに既に存在する他のデータセットとリレーショナルデータを組み合わせることで、より充実したクロスドメインのインサイトを得られます。
Apache Iceberg と Amazon S3 Tables
Apache Iceberg は、ACID トランザクション、スキーマの進化、タイムトラベル機能を提供する、広く採用されているオープンテーブル形式です。複数のエンジンが同一データセットに対して同時に処理できるため、オープンレイクハウスアーキテクチャの構築で広く選ばれています。
Amazon S3 Tables は、分析ワークロード向けに設計された専用のフルマネージド Apache Iceberg テーブルストアです。セルフマネージドの Iceberg テーブルと比較して、クエリパフォーマンスが最大 3 倍、1 秒あたりのトランザクション数が最大 10 倍に向上します。また、データの自動コンパクションと参照されていないファイルの自動削除により、ストレージとパフォーマンスが最適化されます。
本記事では、Amazon Aurora MySQL Serverless v2 からテーブルを抽出し、AWS Glue を使って Amazon S3 Tables に Apache Iceberg 形式で書き込む、エンドツーエンドの自動化ソリューションの構築方法を紹介します。インフラ全体を 1 つの AWS CloudFormation スタックでデプロイします。
課題
AWS は Amazon Aurora から Amazon Redshift や Amazon SageMaker AI へのゼロ ETL 統合を提供しており、分析や機械学習ワークロード向けにシームレスなデータフローを実現しています。
しかし、Amazon Aurora と Amazon S3 Tables 間にはまだネイティブな ゼロ ETL 統合がありません。そのため、レイクハウスアーキテクチャに Amazon S3 Tables を活用しようとする組織は、以下のような課題に直面します。
- Amazon Aurora からデータを抽出し Apache Iceberg 形式に変換する ETL パイプラインの構築
- プライベートサブネットの Amazon Aurora データベースにアクセスするための AWS Glue ジョブのネットワークとセキュリティの設定
- ソースデータベース、ETL パイプライン、ターゲットテーブルストアのプロビジョニングの調整
- ネイティブな自動化なしでのエンドツーエンドワークフローの管理
ソリューション概要
このソリューションでは、Amazon Aurora MySQL Serverless v2 のリレーショナルデータベーステーブルを AWS Glue 5.0 で Amazon S3 Tables に Apache Iceberg 形式で抽出する処理を自動化します。すぐに試せるように CloudFormation テンプレートを用意しています。このテンプレートでインフラのプロビジョニング、サンプルデータのロード、ETL パイプラインの設定がすべて完了します。独自のシナリオに合わせてテンプレートをカスタマイズできます。

サンプルデータ
このソリューションでは TICKIT サンプルデータベースを使用します。Amazon Redshift のドキュメントで使われているよく知られたデータセットで、架空のチケット販売システムを 7 つの相互関連テーブル (users、venue、category、date、event、listing、sales) でモデル化しています。データセットは Amazon Redshift 入門ガイドに記載のとおり、一般公開されています。
ソリューションのフロー
前述のアーキテクチャ図に示したソリューションのフローは以下のとおりです。
- AWS Lambda 関数が TICKIT サンプルデータセット (Amazon Redshift ドキュメントで使用されている架空のチケット販売システム) をパブリックな Amazon S3 バケットからステージング用 S3 バケットにダウンロードします。
- 2 番目の Lambda 関数が PyMySQL (Python の MySQL クライアントライブラリ) を使用し、
LOAD DATA LOCAL INFILEでステージング済みデータファイルを Aurora MySQL Serverless v2 データベースにロードします。 - AWS Glue ジョブがネイティブな MySQL 接続で Aurora MySQL から 7 つの TICKIT テーブルを読み取り、SigV4 認証を使って S3 Tables REST カタログエンドポイント経由で Amazon S3 Tables に Apache Iceberg 形式で書き込みます。
- 移行されたデータは Amazon Athena で S3 Tables に対してクエリできます。
このソリューションは以下の主要コンポーネントで構成されます。
- TICKIT サンプルデータセット (users、venue、category、date、event、listing、sales テーブル) を格納するソースリレーショナルデータベースとしての Amazon Aurora MySQL Serverless v2
- Aurora MySQL データベースの認証情報を安全に保存する AWS Secrets Manager
- パブリックな redshift-downloads S3 バケットからダウンロードした TICKIT サンプルデータファイルのステージング用 Amazon S3 バケット
- PyMySQL を使って Aurora MySQL にデータをロードする AWS Lambda 関数
- Aurora MySQL からテーブルを読み取り S3 Tables に Apache Iceberg 形式で書き込む AWS Glue 5.0 ジョブ (PySpark)
- 移行された Iceberg テーブルのターゲットストレージとしての Amazon S3 Tables
- プライベートサブネットと Amazon S3、S3 Tables、AWS Glue、Secrets Manager、AWS Security Token Service (AWS STS)、CloudWatch Logs、CloudFormation 用の VPC エンドポイントを備えた Amazon VPC
このアーキテクチャの主な利点は以下のとおりです。
- 完全自動化されたセットアップ: 1 つの CloudFormation スタックでインフラのプロビジョニング、サンプルデータのロード、ETL パイプラインの設定が完了します。
- サーバーレスでコスト効率に優れた構成: Aurora MySQL Serverless v2 と AWS Glue はどちらも需要に応じてスケールし、アイドル時のコストを最小限に抑えます。
- Apache Iceberg テーブル形式: データは Apache Iceberg 形式で保存され、ACID トランザクション、スキーマの進化、タイムトラベルクエリが利用できます。
- ネットワーク分離と認証情報管理: リソースはプライベートサブネット内で VPC エンドポイント経由で動作し、データベース認証情報は AWS Secrets Manager で管理されます。
- 拡張可能なパターン: 同じアプローチを他のリレーショナルデータベース (PostgreSQL、SQL Server) や AWS Glue がサポートする他のターゲット形式にも適用できます。
前提条件
この手順を進めるには AWS アカウントが必要です。まだ AWS アカウントをお持ちでない場合は作成してください。CloudFormation スタックのデプロイには約 30〜45 分かかり、Amazon S3 Tables、AWS CloudFormation、Apache Iceberg、AWS Glue、Amazon Aurora に関する基本的な知識が必要です。このソリューションは AWS のコストが発生します。主なコスト要因は AWS Glue ETL ジョブの実行 (DPU 時間あたりの課金、データ量に比例) と Amazon S3 Tables のストレージおよびリクエスト料金です。不要になったらリソースをクリーンアップしてください。
CloudFormation パラメータ
CloudFormation スタックのデプロイ前に以下のパラメータを設定できます。
| パラメータ | 説明 | デフォルト値 | 必須 |
| S3TableBucketName | 作成する (既存のものを使用する場合はその) S3 Tables バケット名 | はい | |
| DatabaseName | Aurora MySQL の初期データベース名 | tickit | いいえ |
| MasterUsername | Aurora MySQL のマスターユーザー名 | admin | いいえ |
| VpcCidr | VPC の CIDR ブロック | 10.1.0.0/16 | いいえ |
| S3TableNamespace | S3 Tables の Namespace | tickit | いいえ |
実装ウォークスルー
以下の手順で実装を進めます。ゼロからエンドツーエンドのソリューションをデプロイしてテストする手順です。すでに一部のコンポーネントを実行している場合は、該当するステップに進んでください。ソリューション全体は aws-samples リポジトリの sample-to-write-aurora-mysql-to-s3tables-using-glue も参照できます。
ステップ 1: CloudFormation スタックのデプロイ
CloudFormation テンプレート scripts/aurora-mysql-to-s3tables-stack.yaml を AWS マネジメントコンソールまたは AWS Command Line Interface (AWS CLI) でデプロイします。S3 Tables バケット名を指定すると、スタックが自動的に作成します (既存のバケットがある場合はそれを使用します)。
AWS マネジメントコンソール(推奨)でデプロイする場合、AWS CloudFormation コンソールに移動して CloudFormation テンプレートを使用します。AWS CLI でデプロイする場合は、まずテンプレートを S3 バケットにアップロードします (テンプレートはインライン ‐‐template-body の 51,200 バイト制限を超えるため)。その後スタックを作成します。
スタックは以下を自動的に実行します。
- S3 Tables バケットの作成 (既存の場合はそのまま使用)
- プライベートサブネットと VPC エンドポイントを含む VPC の作成
- Aurora MySQL Serverless v2 クラスターのプロビジョニング
- パブリックな Amazon S3 バケットから TICKIT サンプルデータのダウンロード
- PyMySQL を使った Lambda 関数による Aurora MySQL へのサンプルデータのロード
- S3 Tables に Iceberg 形式でデータを移行する Glue ジョブの作成
注記: S3 Tables バケットはスタック削除時にも保持され、データが保護されます。
ステップ 2: Aurora MySQL データの確認
CloudFormation スタックから AuroraClusterEndpoint、DatabaseName、SecretArn の値を取得してメモします。Amazon Aurora コンソールの Query Editor に移動し、CloudFormation スタックの値を入力して接続できます。Amazon Aurora DB クラスターへの接続で好みの方法を選択することもできます。
AWS CLI でスタック出力を取得するには以下を実行します。
次の SQL コマンドでデータロードを確認します。
ステップ 3: Glue ジョブの実行
AWS Glue コンソールに移動し、左パネルの Data Integration and ETL から ETL jobs を選択します。AWS Glue ジョブ mysql-tickit-to-iceberg-job を選択して Run job をクリックし実行を開始します。AWS CLI で ETL ジョブを開始することもできます。
AWS Glue ジョブは 7 つの TICKIT テーブルそれぞれに対して以下の処理を実行します。
- ネイティブな MySQL Glue 接続で Aurora MySQL からテーブルを読み取り
- Spark DataFrame に変換
- USING ICEBERG 句を指定した CREATE TABLE IF NOT EXISTS で S3 Tables Namespace に Iceberg テーブルを作成
- INSERT INTO (テーブルが既に存在する場合は INSERT OVERWRITE) でデータを挿入
- レコード数の検証とサンプルデータの表示
ステップ 4: 結果の確認
AWS Glue ジョブの完了後、Amazon S3 コンソールに移動して S3 Table バケットにテーブルが作成されたことを確認します。Buckets の Table buckets を選択し、S3 Table バケットを選びます。AWS CLI でも確認できます。
tickit Namespace のテーブルを選択し、Preview をクリックしてデータを確認します。

Amazon Athena で移行されたテーブルに対してクエリを実行し、データを検証することもできます。
リソースのクリーンアップ
不要になったリソースは忘れずにクリーンアップし、不必要な料金の発生を防いでください。
CloudFormation コンソールでスタックを検索し、Delete を選択します。AWS CLI でも削除できます。
S3 Tables バケットはデフォルトで保持されます。削除する場合は Amazon S3 コンソールまたは AWS CLI で Table バケットを個別に削除してください。ステージング用 S3 バケットはスタック削除時に自動的に空にされて削除されます。
まとめ
本記事では、Amazon Aurora MySQL Serverless v2 からデータを抽出し、AWS Glue 5.0 を使って Amazon S3 Tables に Apache Iceberg 形式で書き込む方法を紹介しました。AWS Glue のネイティブな Iceberg サポートと S3 Tables REST カタログエンドポイントを活用することで、リレーショナルデータベースとモダンなレイクハウスストレージ形式の間のギャップを埋められます。CloudFormation でパイプライン全体を自動化することで、複数環境へのセットアップと展開を迅速に行えます。
AWS Glue と Amazon S3 Tables は今後も進化を続けるため、この自動化された移行パターンを維持しながら将来の機能強化を活用できます。
ご質問やご提案がありましたら、コメントをお寄せください。
著者について
この記事は、Solutions Architect の Shinya Sugiyama が翻訳を担当しました。