はじめに
medeluでは独自のデータ分析基盤を構築してデータ分析を行い、お客様のビジネス課題解決を支援しております。
今回は「サーバーレスETL」を利用するための検証プロセスをご紹介します。
目次
1. 現状の課題と対策

図1:medelu データ分析基盤の構成
業務: 分析対象のインダストリはファッション・食品が中心です。マスタデータとなるアイテムの入れ替えが激しく、トランザクションも日々増加する中で、迅速なデータ分析と施策提案が必要となります。そのため、データ分析には柔軟で機動性の高い対応が求められます。
システム:現状はローカル環境でデータを手動加工し、AWS S3にアップロードしてAthenaに連携しています。データの可視化はTableauを利用しています。
現状の課題: ローカル環境でデータ加工を行っていることから属人化が進み、作業自体とそのナレッジ共有に時間を要しています。作業を自動化して、属人化を解消することが課題です。
対策:「サーバーレスETL」を利用して、開発・運用の負荷を抑えながらデータ分析を効率化します。上図「③データ加工」の箇所を中心に検討していきます。
2. テクノロジー・アセスメントの進め方
テクノロジー・アセスメントは、新技術導入に際する影響調査・比較検討・技術評価のことを指します。
今回はサーバレスETLを導入するために、①調査サービス候補選定、②サービス内容の比較、③実機検証、④コスト試算、の順にプロセスを進めました。
2-1. サービス候補の選定
既にAWSを利用中であるため、AWSのETLサービスからGlueとLambdaを選定しました。
- AWS Glue(フルマネージドETLサービス)
- AWS Lambda(イベント駆動型FaaS)
GlueとLambdaのサービス内容をとりまとめ、比較検討していきます。
2-2. サービス内容の比較
GlueとLambdaの比較は下表の通りです。
比較サービス | AWS Glue | AWS Lambda |
---|---|---|
主な用途 | 多量のデータ処理を効率よく実行 | 少量のデータ処理を素早く実行 |
開発言語 | Python, Scala (PySpark, Glue) | Java, Go, PowerShell, Node.js, C#, Python, Ruby |
実行時間の制約 | 10,080分間(7日間) | 15分間 |
プログラミング難度 | 高/データエンジニア向け | 中/開発者ならば利用可能 |
スケーラビリティ | 自動スケール | 関数を追加作成して並列実行 |
費用 | 実行時間 + 処理データ量 | 実行時間 + 関数呼び出し回数 |
Lambdaの実行時間は最大15分間の制約があり、実機検証の確認ポイントとなります。
2-3. 実機検証
AWS上で「S3上のCSV 読み込み → 加工 → parquet出力」のサンプルコードを作成して比較しました。サンプルコードは以下の通りです。
# AWS Glue Sample code
import sys
from awsglue.context import GlueContext
from awsglue.job import Job
from awsglue.transforms import SelectFields
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
# 初期化
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
# Jobインスタンス生成
job = Job(glueContext)
job.init(args['JOB_NAME'], args)
# S3からCSVを読み込み
input_path = "s3://your-bucket/input/"
df = glueContext.create_dynamic_frame.from_options(
connection_type="s3",
connection_options={"paths": [input_path]},
format="csv",
format_options={"withHeader": True}
)
# データ加工処理
processed_df = SelectFields.apply(df, paths=["id", "name", "created_at"])
# S3へParquetを出力
output_path = "s3://your-bucket/output/"
glueContext.write_dynamic_frame.from_options(
frame=processed_df,
connection_type="s3",
connection_options={"paths": [output_path]},
format="parquet"
)
job.commit()
# AWS Lambda Sample code
import boto3
import pandas as pd
import io
s3 = boto3.client('s3')
BUCKET = 'your-bucket'
INPUT_KEY = 'input/data.csv'
OUTPUT_KEY = 'output/result.parquet'
def lambda_handler(event, context):
# S3からCSVを読み込み
obj = s3.get_object(Bucket=BUCKET, Key=INPUT_KEY)
df = pd.read_csv(io.BytesIO(obj['Body'].read()))
# データ加工処理
processed_df = df[['id', 'name', 'created_at']]
# Parquet形式に変換
out_buffer = io.BytesIO()
processed_df.to_parquet(out_buffer, index=False, engine='pyarrow')
# ParquetをS3へアップロード
s3.put_object(
Bucket=BUCKET,
Key=OUTPUT_KEY,
Body=out_buffer.getvalue(),
ContentType='application/octet-stream'
)
return {
'statusCode': 200,
'body': 'OK'
}
実運用を想定して600万レコードのサンプルデータを投入したところ、実行時間はLambda:約3分、Glue:約5分となりました。
15分制限以内で完了したため、Lambdaで対応可能な見込みが立ちました。Glueは起動に時間を要することから、データの素早い処理に関してはLambdaに適正を感じました。
プログラミング難度の観点から、PySpark, Glue のライブラリは固有の書き方が必要となり、習熟に時間を要することが予期されます。
2-4. コスト試算
今回の想定データ量ではLambdaのほうがやや安価でした。また、実機確認においても、Lambdaは無料枠内に収まり、Glueは利用後すぐに料金が発生しました。
3. まとめ
テクノロジー・アセスメントの結果を踏まえて、medeluでは「Lambdaをメイン、Glueをサブ」というハイブリッド運用を採用する方針を決定しました。
Lambdaをメインとして開発を進め、処理時間15 分超が見込まれる場合にGlueを利用します。ハイブリッド運用により、サーバレスETL基盤の効率的な稼働とコスト最適化を両立します。
今後は、ジョブフローの自動化、システムモニタリング強化、外部とのシームレスなデータ共有、に取り組みます。
サーバレスETLを活用して迅速かつ効率的なデータ分析基盤を構築することにより、お客様にとって価値のあるデータ、ナレッジ、インサイトを提供してまいります。
4. 参考情報
AWS アーキテクチャアイコン https://aws.amazon.com/jp/architecture/icons/
AWS Glue https://aws.amazon.com/jp/glue/
AWS Lambda https://aws.amazon.com/jp/lambda/