AWSでの効率的なデータ処理を考える〜ETLサービス選定あれこれ〜

はじめに

データの収集・変換・保存といったETL（Extract, Transform, Load）処理はデータ基盤を構築するうえでの要となる要素です。
AWSでETLを実現するには様々な選択肢があり、ユースケースや要件に応じて最適なサービス選定が必要となります。

今回はAWSでETL処理を実現する際に候補となる主要なサービス（Lambda、GLue、EMR）の特徴とユースケースと選定方法を紹介します。

AWSでのETL構成における代表的なサービス

AWSでは以下の3サービスがETLの中核を担います。
これ以外にも様々なサービスがありますが、こちらをベースに検討することが多いと思います。

サービス	特徴
AWS Lambda	軽量処理向きのサーバレス実行環境。小規模でリアルタイムなETLに強み。
AWS Glue	フルマネージドなETLサービス。Spark/Pythonベースの柔軟なジョブ設計が可能。
Amazon EMR	Hadoop/Spark等をフルカスタマイズ可能なクラスタ型処理環境。大規模バッチ処理向き。

AWSの代表的なETLサービス概要

AWS Lambda

みなさんおなじみのAWS Lambdaです。
このサービスはご存じの通り、サーバレスのコンピューティングサービスです。
いわゆるETL専用のサービスではありませんが、コードベースで処理を記述できるため、軽量なETL処理やイベントドリブンなデータパイプラインの構築に利用されます。

特徴

• サーバレスでスケーラブル。
• 実行時間単位で課金されるため、小規模バッチを構成する場合にコスト効率が高い。
• S3トリガーなどと組み合わせたリアルタイム処理が可能。

注意事項

• 最大実行時間が15分で制限される。
• メモリ・CPUに上限あり、大量データや複雑処理には不向き。

ユースケース

• 小規模なETL処理。
• ファイルの前処理（CSV→Parquetなど）。
• S3イベントトリガーなど他のAWSサービスと連携した処理（イベントドリブン処理）。

AWS Glue

ETLといえば最初に思いつくサービスがAWS Glueです。
AWS Glueは、ETLに特化したフルマネージドサービスです。
Sparkベースの分散処理エンジンで、GUIベースのワークフロー設計やPythonベースのカスタマイズも可能です。

特徴

• サーバレスでSparkベースの分散処理による大規模データに対応。
• データカタログやジョブブックマーク等の便利機能を有する。
• ジョブスケジューラ、トリガー、Glue StudioなどGUI操作も充実。
• Spark/Python Shellベースで柔軟なETLジョブ記述が可能。

注意事項

• チューニングが限定的。
• 起動遅延や費用に注意が必要。
  ※意外と高いので、油断すると思いのほか料金がかかっていたりします。

ユースケース

• スケールアウトが必要な中〜大規模なデータ変換処理（数GB〜数TB）。
• 大量ファイルの一括変換や複数データソースを統合する場合。
• IcebergやHudiといった形式との連携を前提とする場合。

Amazon EMR

Glueの次にETLで候補となるのが、Amazon EMRです。
EMRは、HadoopやSparkなどのOSSをベースとしたビッグデータ処理基盤を構築できるマネージドサービスです。

特徴

• クラスター構成を柔軟に制御可能（Spark以外も選択可）。
• 詳細なチューニング・パフォーマンス最適化が可能。
• Icebergを含むOSSとの親和性が高い。

注意事項

• セットアップ・運用負荷が高い。
• コスト管理が難しい。

ユースケース

• フルカスタムなデータ処理基盤を構築したい場合。
• 大量データをもとにした長時間バッチジョブ。
• Iceberg/Hudi/Delta Lake との統合基盤。

AWS Glueの周辺機能

AWS Glueには様々な周辺機能が存在します。
これらのサービスはGlue専用ではなく、他のサービスからも使用することが可能です。
この機能を組み合わせることでAWS上でより柔軟なデータパイプラインを実現できます。

サービス	概要
Glue Job（Spark / Python Shell）	本格的なETLや小規模スクリプト処理に使い分け可能。
Glue Studio	ノーコードでジョブ作成・可視化できるUI。
Glue Catalog	S3上のメタデータを管理するデータカタログ。
Glue Data Quality	データの検証・スコア化により、パイプラインの品質管理を支援。
Glue Crawler	S3上のデータからスキーマを自動抽出し、Catalogへ登録。
Glue Workflow	複数ジョブの制御を可能にするワークフロー機能。

Apache Icebergとの連携方法

近年、Apache Icebergのようなオープンテーブルフォーマット（OTF）が注目されています。
OTFを活用する場合、データの更新性やトランザクション性、ACID準拠といった要件を満たす構成が求められています。
AWSでもGlue、EMR、AthenaなどでIcebergをサポートしています。

Lambda × Iceberg

Lambdaを使用する場合、PyIcebergを使用します。
接続方法はいくつかありますが、Glue Catalog経由で操作するパターンとIceberg REST Endpointを使用して操作するパターンがあります。

Glue Catalog経由

Glue Catalogを経由する場合は、過去書いた記事を参考にしていただければと思います。

https://zenn.dev/penginpenguin/articles/77d4a9b1e90e3a

Iceberg REST Endpoint

こちらはAWS Glueが提供するIceberg RESTエンドポイント（Iceberg REST Catalog API仕様準拠）をPyIcebergから利用する方式です。
Apache Iceberg REST仕様で規定されたAPIオペレーションに対応しているというのがポイントです。
AWSの資料やブログでも使われることが増えているので、基本的にはこちらを採用するほうがいいと思います。
Glue Catalog経由との比較については別記事でまとめたいと思います。

https://aws.amazon.com/jp/blogs/news/accelerate-lightweight-analytics-using-pyiceberg-with-aws-lambda-and-an-aws-glue-iceberg-rest-endpoint/

2つのアクセス方式については下記の記事でまとめました。
https://zenn.dev/penginpenguin/articles/e44880aaa2d5e3

Glue × Iceberg

GlueではではIcebergテーブルの読み書きがサポートされています。
https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/iceberg-glue.html

以前、書いた記事でGlueからIcebergへの書き込みをまとめているので、こちらも参考にしていただければと思います。
https://zenn.dev/penginpenguin/articles/bedb295e9dbe45

下記のように"--datalake-formats": "iceberg"を指定するだけで活用可能です。

{
  "--conf": "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions",
  "--datalake-formats": "iceberg"
}

EMR × Iceberg

EMRもGlueと同様にIcebergを公式サポートしています。SparkSQLやHiveから利用可能です。

https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/apache-iceberg-on-aws/iceberg-emr.html

下記のようにクラスターを次の分類で設定するだけで活用可能です。

[{
    "Classification": "iceberg-defaults",
    "Properties": {
        "iceberg.enabled": "true"
    }
}]

ETL構成の選定基準

上記代表的なETLサービスから選定を行う場合の基準は様々な観点がありますが、下記の観点で行うことが多いです。

観点	Lambda	Glue	EMR
データ量	小～中	中～大	大規模
複雑性	低	中	高
処理時間	短時間	数分～数十分	数十分～数時間
起動頻度	高頻度	定期	定期
コスト	安価	中程度	高い（特に常時稼働とした場合）

Big Data is Dead? 選定基準の再考

ETL構成の選定基準をまとめましたが、MotherDuckのエンジニアによる 「Big Data is Dead」 という記事で、従来のビッグデータ至上主義からの脱却を示唆しています。

ポイントは以下です。

• 多くの企業は実際にはそれほど大量のデータを持っておらず、多くのユースケースでは、大規模分散処理を必要としない。
• 「スモールデータ」に適した処理基盤のほうが開発効率・コスト効率が高い。
• DuckDBやPyArrowなどのローカル/サーバレス処理の価値が高まっている。

これを踏まえるとDuckDBやMotherDuckのような軽量・シンプルな分析基盤が有効な場面が多く、AWSでも今後は「とりあえずEMR」や「Glueで一括処理」ではなく、データ規模・更新頻度・運用コストに応じて最小構成で最大効果を得る設計が求められます。
例えば、Lambda + DuckDBやGlue Python Shellのような軽量かつ最小構成で始めることも考えられます。
とはいえ、基本は下記の構成をベースにデータ量や処理の複雑さに応じて選定いただくのがいいかと思います。

条件	構成
小規模、イベント駆動	Lambda + DuckDB
中規模、柔軟な構成	Glue
大規模、並列分散処理	EMR

ジョブ構成と起動パターンの比較

先ほど紹介した各サービスはETLジョブとして活用することが多いと思います。
ジョブのトリガとして活用可能なサービスは下記のようなものがあります。
ジョブの特性や要件に応じて選定いただければと思います。

トリガー方式	メリット	使用例
Amazon EventBridge	定期実行が簡単	毎時/毎日実行
S3イベント	データ到着時トリガー	ファイルアップロード時
AWS Step Functions	条件分岐やリトライに強い	複雑なフロー制御
Amazon MWAA / Airflow	DAGで依存関係管理が柔軟	日次バッチ連携
JP1 / 他の外部スケジューラ	既存システムとの統合が可能、営業日や祝日等日本の商習慣に合わせた実行が可能	基幹バッチとの連携

その他のETL処理に使えるAWSサービス

今回は概要程度にとどめますが、その他ETL処理に使えるサービスは下記のようなものがあります。
Amazon MWAAやAWS Step Functionsを使ったオーケストレーションは使う機会が多いと思います。

サービス	用途例・特徴
Amazon MWAA	ETLジョブの高度なオーケストレーション。Airflow DAGベースで定義し、GlueやLambdaと連携可能。
AWS Step Functions	ETL処理をサーバレスで段階的に構成可能。GlueやLambdaを連携可能。
AWS Batch	大規模バッチ処理に対応。機械学習やデータ変換に適している。
Amazon ECS	コンテナベースETLの実行環境として活用可能。
Amazon EC2	ETLの実行環境として活用可能。

もしかすると、昔から稼働しているシステムだとEC2で処理を実行していることも多いと思います。
長期間稼働しているシステムの場合、データ量の増加や、様々な要件変更により、別サービスのほうが最適となる場合もあります。
どこかのタイミングで見直すことも重要な判断になりますので、一度点検してもいいかもしれません。

まとめ

本記事ではAWSでETL構成を考えるうえで中心となるLambda、Glue、EMRについてそれぞれの特性やApache Icebergとの連携方法を紹介しました。
加えて、近年のデータ基盤トレンドに応じた「軽量ETL」の考え方や、その他のサービスも紹介しました。

ETL処理はデータ量や、処理の複雑性、コスト、運用保守の負荷など様々な観点での設計判断が求められます。
ETLだからGlueと短絡的に判断するのではなく、要件や特性に応じてサービスを選定いただければと思います。
今回の記事がAWSでのETLサービス選定の参考になれば幸いです。