自己紹介
皆様初めまして、エンジニアとしての勉強記録をアウトプットするべく、Qiitaに記事をこれから週1,2で掲載していきたいと思います。勉強方針も定まっておりません。クラウド、データ分析、開発、BIツール、マネジメント系、、、、とりあえず、1年間続けることを目標にし、それ以降はまた考えます。
初回ですが、あまり準備をしておりません、done is better than perfect.ということで、ひとまず今回はChatGPTに質問した回答と、それに対する解釈を載せます。
今回はAWS Glue とlambdaでレイヤーを一緒にするためには？をChatGPTに質問してました。
ChatGPT:
いい質問です 👍
AWS Glue と AWS Lambda で「同じレイヤー（共通ライブラリ）」を使いたい — つまり「同じコード・依存パッケージを両方で共有したい」場合、いくつか注意点があります。
以下で、わかりやすく手順と考え方をまとめます。
✅ 前提理解
AWS Lambda は「レイヤー (Lambda Layer)」を追加できます。
→ /opt ディレクトリにライブラリが展開されます。
AWS Glue は「ジョブ用 Python ライブラリ」として .whl / .zip 形式の依存ファイルをアップロードできます。
→ --extra-py-files オプションやコンソールの「Python ライブラリパス」で指定。
両者とも「Python パッケージを外部から読み込む」という意味では同じですが、フォルダ構成と互換性が違います。
💡 アプローチ1：同じソースから「2種類のアーカイブ」を生成する
共通ライブラリをローカルで作成
例: my_lib というPythonパッケージを作る
my_lib/
init.py
utils.py
ビルド環境をDockerやローカルで合わせる
GlueジョブでPython 3.9を使うなら、LambdaもPython 3.9ランタイムを選ぶ。
（例：python3.9 環境でpip install）
2種類のパッケージを生成する
(1) Lambda Layer 用
mkdir -p python
pip install -t python my_lib/
zip -r layer.zip python
(2) Glue ジョブ用
cd my_lib
python setup.py bdist_wheel
layer.zip → Lambda Layerにアップロード
dist/my_lib-0.1-py3-none-any.whl → Glueジョブの「Pythonライブラリ」欄に登録
👉 両者は中身が同じなので、同一バージョンのライブラリを共有できます。
💡 アプローチ2：S3に共通ライブラリを置き、GlueもLambdaもS3から読み込む
共通パッケージをS3にアップロード
s3://my-bucket/libraries/my_lib.zip
Glueジョブ設定
「Pythonライブラリパス」に上記S3パスを指定
例: s3://my-bucket/libraries/my_lib.zip
Lambda関数設定
コード内で S3 からダウンロード & sys.path に追加：
import boto3, sys, os, zipfile, tempfile
s3 = boto3.client('s3')
with tempfile.TemporaryDirectory() as tmpdir:
zip_path = os.path.join(tmpdir, 'my_lib.zip')
s3.download_file('my-bucket', 'libraries/my_lib.zip', zip_path)
with zipfile.ZipFile(zip_path, 'r') as z:
z.extractall(tmpdir)
sys.path.insert(0, tmpdir)
import my_lib
これでGlueと同じライブラリを動的ロード可能です。
💡 アプローチ3：Dockerイメージベースで統一する（発展形）
Lambda も Glue も 「コンテナイメージ」 ベースで実行可能です。
同じ Dockerfile をもとに
aws lambda create-function --package-type Image
aws glue create-job --command {"ScriptLocation":"...","PythonVersion":"3"} --execution-class FLEX ...
として共通イメージを利用する。
こうすると「依存ライブラリ・Pythonバージョン・設定すべて統一」できます。
企業のDataOpsやETL基盤では、この方法が最も確実です。
🧭 おすすめまとめ
方法 難易度 保守性 特徴
① レイヤー＋whlを別々に作る ★★ ★★★★ 最もシンプルで確実
② S3から動的ロード ★★★ ★★ 柔軟だが起動遅延あり
③ Dockerイメージ共通化 ★★★★ ★★★★★ 大規模運用向け（本格派）
まとめ
色々提案してくれるのがありがたいですよね。
個人的には2が分かりやすそうだと思ったのですが、その分実行が遅くなるとのことで注意ですね。
正直現段階ではどの方法が良いのか判断がつかないので動かしてみないことにはなんとも言えないですね。
この時どの方法を取るかは人それぞれ好みが別れそうですね。
あまり今回の記事は誉められたものではないでしょうが、記事投稿のハードルを自分の中で下げたくて今回このような形でも投稿することにします。でないといつまで経っても投稿が出来なさそうでしたので。それでは。