1.自己紹介
はじめまして。プロトソリューションの木村と申します。
私は、2016年に入社して、初めはAndroidアプリ開発から業務に携わらせて頂き、PHP＋Oracle＋オンプレミスサーバーを用いたWEBシステムの運用保守業務、今年からPython＋AWSを使用するWEBシステムの運用保守業務を行っております。
Python、AWSを業務として扱うのは今回が初めてで、色々と苦労しながらも何とか進める事が出来ております。
今回の記事は、AWS LambdaのPythonランタイム3.6が廃止されるため、急ぎ対応を行った件について備忘録として記載しようと思います。
2.はじめに
・AWS LambdaのPythonランタイムについて
| 名前 | 識別子 | オペレーティングシステム | 非推奨化フェーズ 1 | 非推奨化フェーズ 2 |
|---|---|---|---|---|
| Python 3.6 | Python 3.6 | Amazon Linux | 2022 年 7 月 18 日 | 2022 年 8 月 17 日 |
・非推奨化フェーズ1について
対象のランタイムで新規作成が出来なくなります。
既に構築済みの関数に関しては、引き続き関数実行・関数更新が可能となります。
・非推奨化フェーズ2について
対象のランタイムで新規作成、関数更新が出来なくなります。
既に構築済みの関数は実行する事は出来ますが、更新する事が出来なくなります。
運用保守しているAPIがPython3.6ランタイムを使用しておりました。
非推奨化フェーズ2の関数更新が出来なくなるのは問題になるため、AWS Lambdaで利用出来る最新バージョンのPython3.9ランタイムまでバージョンアップを行いました。
今回の記事では、私が実施したアップデート手順と詰まった内容について記載します。
3.要約
- CodeBuildにPython3.9用のイメージが無かった。OSをAmazonLinux2、ランライム設定をPython3.9に設定する必要がある。
- Python3.8以降のAWS Lambdaの実行環境では一部の共有ライブラリが不足していた
4.実際に行ったライブラリアップデートの検証手順
1.EC2サーバー上でライブラリアップデートを検証
2.手動でAWS Lambda API-GateWayを構築してAPI検証
3.開発用のCodePipelineにソースプッシュして実開発環境で検証
4.本番環境のCodePipelineにソースプッシュして本番環境にリリース
開発といえど利用しているのが私以外にもおりましたので、なるべく既存環境に影響を与えないために上記の手順で検証を行いました。
5.AWS LambdaのPython3.9ランタイムについて
・AWS Lambdaの実行環境について
| 名前 | 識別子 | AWS SDK for Python | オペレーティングシステム | アーキテクチャ |
| Python 3.6 | Python 3.6 | boto3-1.20.32 botocore-1.23.32 | Amazon Linux | x86_64 |
| Python 3.9 | Python 3.9 | boto3-1.20.32 botocore-1.23.32 | Amazon Linux 2 | x86_64、arm64 |
ランタイム変更に合わせてAWS Lambdaの実行環境がAmazonLinuxからAmazonLinux2に変更されました。
更新するAPIは外部ライブラリを利用しており、Pythonのバージョンに合わせてアップデートが必要でした。
私はライブラリアップデートの事前検証のために、AmazonLinux2で動作するEC2インスタンスを新規で立ち上げ、このEC2インスタンス上でライブラリアップデートを検証を行い、正常にインストール、ユニットテストが実行される事を確認しました。
※ AmazonLinux2のイメージがDockerHub等で公開されております。こちらを利用した方が料金がかからないため、費用を抑えたい方はこちらを利用した方が良いと思われます。
6.AWS LambdaのPythonランタイム変更について
弊社のQiitaに記載しておりますので、是非ご確認いただければと思います。
7.ライブラリアップデートについて
・構成図について
開発者がCodeCommitにソースプッシュすることで、CodePipelineが動作してAWS Lambdaにデプロイ出来るような構成になっております。
CodeBuildでPythonの各種ライブラリインストールを行っており、
デプロイパッケージが生成されたらCloudFormationの変更スタックを作成して実行します。
初回ならAWS Lambda構築とデプロイ、次回以降ならデプロイのみを行います。
8.詰まった箇所について
前提が長くなりましたが、ここからが本題となります。
① CodeBuildのイメージについて
以前までは公式が提供していた以下のイメージを使用しておりました。
Python3.9用のイメージもあると思い、公式ページを調査しても上記イメージも含めて存在しませんでした。
そのため、公式ページを参照して別方法で対応を行いました。
対応内容
1．CodeBuildで使用するイメージにAmazonLinux2を選択する
2．buildspec.yamlのインストールフェーズでPython3.9ランタイムを設定する
上記の対応で想定していた環境を構築する事が出来ました。
② 不足する共有ライブラリについて
CodePipelineが正常終了してAWS Lambdaへのデプロイ完了後、テスト実行したら上記のエラーが発生しました。
libgomp.so.1
上記は共有ライブラリであり、実行環境に無いのは想定外のエラーとなりました。
調査するとAWS LambdaのAmazonLinux2実行環境には、様々な共有ライブラリが不足しているようです。
対応方法は調査すると様々な方法があるようですが、今回はAWS Lambdaレイヤーを使用しました。
今後バージョンアップ予定の他APIで同じライブラリを使用しているため、AWS Lambdaレイヤーで対応すると決めました。
※ AWS Lambdaレイヤーについて
AWS Lambdaレイヤーを利用するメリットは以下となります。
・よく利用するライブラリをまとめる事が出来る
・自作の共通処理をまとめる事が出来る
・一つ作成すれば他の関数にも設定する事が出来る
仮にですが機械学習などをよく利用される方は、Pandas,Numpy等をレイヤーとしてまとめて置く事で、それぞれのAWS Lambda関数に設定するソースに含める必要がなくなり、一つのレイヤーを設定する事で全関数に対応する事が出来るようになります。
対応内容
1．buildspec.yamlに共有ライブラリをまとめたzipファイルを生成してS3に格納する処理を追加
2．CloudFormationでリソース構築時にAWS Lambdaレイヤーも合わせて生成する設置を追加
① レイヤーソースをアップロードしたS3バケットを指定するパラメータ追加
② AWS Lambdaレイヤーを作成するフェーズを追加
③ AWS Lambdaにレイヤー設定を追加
上記を設定すると以下の画像のようにレイヤー設定が完了となります。
この状態で再度テスト実行すると以下のように正常終了となります。
※ 500エラーが返ってきておりますがパラメータを何も設定していないためとなります。
※ API Gateway経由でパラメータを付与して実際に実行すると正常終了します。
9.まとめ
Python3.6ランタイムからPython3.9ランタイムに変更すると、OSなどが変更されたため様々な所に影響が出ました。
既にPython3.6ランタイムの廃止日が過ぎておりますが、ご参考になれましたら幸いです。
