ETL処理をAWS Lambda+AWS Step Functions構成で実現したケース

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

レビュー投稿日の情報になります

アスエネ株式会社 / Kido Haruhi

チームリーダー / テックリード

最終更新日2025/12/24投稿日2026/01/06

ツールの利用規模	ツールの利用開始時期	事業形態
10名以下	2025年9月	B to B

アーキテクチャ

軽量な要件であったため、LambdaとStep Functions構成を中心としたアーキテクチャとしました
データ参照における権限の観点からプロダクトの DB とは分離したデータ参照経路を取る方針としました新たに RDS を構築・運用するコストを抑えるため、ユーザーがアップロードしたファイルは S3 に格納し、処理後のデータを Athena 経由で Tableau から参照する構成を採用しました

クライアントが保有する業務データを活用して CO₂ 排出量を可視化したいというニーズはありましたが、実際の業務データは非構造な形式も多く、より多様なデータの可視化を実現するため、非構造データの活用を模索していました

より多様なデータを可視化対象とするために、非構造データを構造化し、算出・分析・可視化までを一連で扱える仕組みの導入検討を進めることになりました

今回のデータ活用で求められていたのは、次のような要件でした

これらを踏まえ、

という点で、Lambda＋Step Functions 構成が合致していたため、採用しました

Lambda は At Least Once（最低一回実行） の実行モデルであるため、

同じ処理が複数回実行されても、結果が破綻しない設計が求められました。

という特性上、

再実行時に重複データが生成されないことなどを常に意識する必要がありました

そのため、処理単位ごとに一意な識別子を持たせるといった点を、設計段階で慎重に詰めるようにしました

処理要件にフィットする構成として、以下の観点から Lambda＋Step Functions を採用する判断に至ったことを上長へ共有しました

外部 API が行単位・同期処理であるという前提に対し、処理を小さな単位に分解し、Lambda を短時間・単一責務に限定できる構成が自然に適合していたこと
実行制御・リトライ・エラー分岐を Step Functions 側で管理することで、行単位での成功／失敗を可視化でき、再実行や障害調査を含めた運用・トラブルシュートがシンプルになること

また、AWS サポートからも「本ユースケースであれば Lambda＋Step Functions でも十分成立する」という見解を得られている点と、 Lambda＋Step Functions 構成であれば社内ナレッジが存在することも補足しました。

初期構築のしやすさだけでなく、あとから困らないかという観点は重要でした
- エラーが出たとき、どこで止まったか分かるか
- 再実行したとき、意図しない副作用が出ないか
- こうした点を重視すると、実行制御や状態を「構成として表現できる」仕組みは大きな助けになると思います
今回の要件では、 Lambda＋Step Functionsの構成で実現が可能でしたが、より大規模データを一括処理するETLや長時間バッチがあり制限時間などの懸念がある場合、Glue など別の選択肢も検討した方が良いかもしれません

アスエネ株式会社 / Kido Haruhi

チームリーダー / テックリード