AWS LambdaでLambda Layersを使う場合、環境変数のPYTHONPATHは使っちゃダメという話
サーバーレス開発部＠大阪の岩田です。 先日遭遇したAWS Lambdaの一風変わったエラーについてご紹介します。
結論
まず結論から。
LambdaのランタイムにPythonを選択し、かつLambda Layersの機能を利用する場合Lambdaの環境変数にPYTHONPATHを設定しないで下さい。
レイヤー内に配置したPythonのモジュールが読み込めなくなります。
処理概要と発生したエラー
今回エラーが発生したコードです。
import os
import sys
import Crypto
import json
def lambda_handler(event, context):
...略
マネジメントコンソールからテストを実行するとこんなエラーが発生しました。
{
"errorMessage": "Unable to import module 'lambda_function'"
}
どうもLambdaの初期化処理の中でCryptoモジュールが読み込めていないようです。 Cryptoモジュールはレイヤーの中に詰め込んでおり、レイヤーとLambda Functionの紐付けも正しく行えています。
なぜエラーが・・・？？
原因切り分け
ここからエラーの原因を切り分けていきます。
レイヤーの作成ミスを疑う
まずレイヤーの作成ミスを疑いました。 原因切り分けのために新しく1からLambda Functionを作成し、同じレイヤーを紐付けてCryptoモジュールをimportしましたが、こちらは問題ありませんでした。 レイヤーではなくLambda Functionの方に問題がありそうです。
PYTHONPATHを疑う
Lambda Functionの設定を隅々まで見渡したところモジュールのimportに影響しそうな設定として、環境変数PYTHONPATHが指定されているのを発見しました。
試しに環境変数PYTHONPATHを削除してからテストイベントを実行すると、モジュールのimportエラーが解消されました！！
元々PYTHONPATHには/var/task/vendor:/var/runtimeが指定されていたのですが、なぜこれがレイヤーに影響を？？
PYTHONPATHの確認
Lambda実行環境に自動で設定されるPYTHONPATHの値を自分で上書いているのが原因と考えました。本来はPYTHONPATHが/var/runtime:/opt/python:/opt/python/lib/python3.6/site-packagesのように設定されるべきところLambda Functionの設定で明示的に指定したことでPYTHONPATHから
- /opt/python
- /opt/python/lib/python3.6/site-packages
が欠落したのでは？？という仮説です。
確認のためにLambda Functionの設定から環境変数PYTHONPATHを削除した状態だとPYTHONPATHの値がどうなるのか確認してみます。
import os
import sys
print(os.environ['PYTHONPATH'])
import Crypto
import json
def lambda_handler(event, context):
...略
環境変数PYTHONPATHの中身を出力するコードを追加しています。このコードを実行したところ、環境変数PYTHONPATHには/var/runtimeが設定されていました。正常に実行できるパターンでもPYTHONPATHにレイヤーのパスが設定されている訳ではないようです。
環境変数PYTHONPATHの有無によるsys.pathの比較
このままだと何故環境変数PYTHONPATHを削除することでエラーが解消したのか分かりません。
もう少し詳細を調査してみます。
import os
import sys
print(sys.path)
import Crypto
import json
def lambda_handler(event, context):
...略
Cryptoモジュールをimportする直前にprintでsys.pathの中身を出力するコードを追加しました。
上記のコードを実行し、環境変数PYTHONPATHありの場合と無しの場合それぞれでsys.pathの
中身を比較してみます。
PYTHONPATH無し
まずはエラーが発生しないPYTHONPATH無しバージョンです。
['/var/task', '/opt/python/lib/python3.6/site-packages', '/opt/python', '/var/runtime', '/var/runtime/awslambda', '/var/lang/lib/python36.zip', '/var/lang/lib/python3.6', '/var/lang/lib/python3.6/lib-dynload', '/var/lang/lib/python3.6/site-packages', '/opt/python/lib/python3.6/site-packages']
PYTHONPATH有り
次にエラーが発生したPYTHONPATHありバージョンのログです。
['/var/task', '/var/runtime/awslambda', '/var/runtime', '/var/lang/lib/python36.zip', '/var/lang/lib/python3.6', '/var/lang/lib/python3.6/lib-dynload', '/var/lang/lib/python3.6/site-packages']
sys.pathから
- /opt/python/lib/python3.6/site-packages
- /opt/python
が消えてしまいました！！
考察
これまでの調査結果から推測するとPythonで書いたLambda Functionの初期化処理は、環境変数PYTHONPATHがセットされていない場合に限りsys.pathのモジュール検索パスに/opt以下のパスを追加するようです。この結果レイヤーに配置したモジュールがLambda Functionから読み込めるようになるのです。
と、いうわけで、、、
Lambda Layersの機能を使う場合Lambda Functionの環境変数にPYTHONPATHを設定するのはやめましょう！！
まとめ
Lambda Layers利用時の一風変わったエラーについてご紹介しました。
なぜ環境変数PYTHONPATHをセットするとsys.pathのモジュール検索パスに/opt/以下のパスが追加されないのでしょうか？
興味のある方はLambda実行環境をハックしてLambdaのbootstrap処理を追いかけてみると面白いかもしれません。
Lambda実行環境をハックする方法は自己責任の元Googleさんにお尋ね下さい。
![[アップデート] AWS Lambda で Python 3.13 ランタイムがサポートされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-484d8afca1cbe50513cd4d6738af2960/fa0838fa40f247093d532945fc785e88/aws-lambda)
