デプロイをzappaで1年間運用した所感
概要
zappaは、wsgiアプリケーションのAWS Lambdaへのpython製CLIデプロイツールです。
少ない記述でAPIGateway,Lambda等をデプロイでき、手軽にデプロイしたいときはAWS SAMやServerless Frameworkより便利だと感じます。
実際に開発環境〜本番環境のデプロイをzappaで1年間ほど運用したのですが、その中で得られた所感をまとめようと思います。
環境
- zappa: v0.54.1
- APIGateway,Lambda,EventBridgeイベントルールのデプロイに利用
🤗良い
APIGateway含むデプロイ設定の記載が簡単
SAMでAPIGatewayのデプロイ設定書くと結構面倒だと感じるのですが、zappaだとapigateway_enabled: trueと設定するだけでデプロイできるので、とても簡単です。
CORS設定もcors: trueで設定できたりと、デプロイは非常にスピーディです。
豊富なパラメータ
zappaには様々なパラメータがありますが、個人的に特に便利だと感じているパラメータをいくつか抜粋します。
keep_warm
コールドスタート対策のパラメータです。
trueにすることで定期的にLambdaをinvokeするEventBridgeルールを作成できます。
slim_handler
コンテナやレイヤーを利用しない場合Lambdaのデプロイサイズ上限は50MB(zip圧縮後)ですが、このslim_handlerを有効にすることでそれ以上のサイズをzappaでデプロイできます。
仕組みとしてはこちらで説明されている通り、ライブラリなど一部を分離しS3に保存 > Lambda実行時にS3からローカルディスクにダウンロードして実行とすることで、全体としてはサイズの大きなパッケージを扱えるようになっています。コールドスタート対策ができていれば動作遅延もほとんど感じません。
しかしLambdaローカルディスクにダウンロードする仕組みのため、/tmpの512MB制限を超えるパッケージは扱えないので注意が必要です。
zappa tailが便利
Lambdaの該当のロググループをtailしてくれるコマンドですが、不具合調査時や検証時のログを頻繁に見る状況だと便利に感じました。
デプロイしてログストリーム開き直して...と繰り返すのはちょっと大変なんですよね...。
😭いまいち...
ローカル実行機能が無い
sam local start-apiやsls local invokeといったローカル起動コマンドがないため、自力で別途スクリプトを書いたりする必要があります。
デプロイ設定ファイルに書いた環境変数をローカル起動時にも利用したかったりすると思いますが、zappa_settings.jsonのaws_environmentsから気合いで読み込んだりしないといけないです。
SSMパラメータストアやSecretsManagerに対応していない
DB接続情報など秘匿情報はパラメータストアやSecretsManagerに保存しておいて、SAMやSLSの設定ファイル上でそれを参照することを行うことも多いと思いますが、zappaは未対応となっております。
そのため、自作スクリプトでパラメータストアから取得した値でzappa_settings.jsonの値を置換・デプロイといった方法などを取る必要があります。
1ステージ1関数
zappaは設定ファイルに複数stage記述できますが、stageにつき設定できる関数は1つです。
同じstage名でAPIと別でLambdaで動くバッチを用意したいなど関数を複数作成したい場合は、別途設定ファイルを作成することとなり設定ファイルの量が増えていきます。
（もしstage内に複数関数定義できる方法ご存知の方いらっしゃいましたら、ぜひご教示いただきたいです...！）
まとめ
zappaは他デプロイツールでの面倒をいい感じにラップしてくれており、APIGatewayとLambdaのデプロイならば最速な気がします。
その反面融通が効かない部分やローカル実行に難があるなど、プロジェクトとチームの拡大が進むと苦しくなってきそうです。
プロトタイプはzappaで手軽に、本腰入れて商用開発は他デプロイツールで。みたいな棲み分けが良さそうだなというのが個人の所感です。
ここまで読んでくださり、ありがとうございました。
良いデプロイライフを！
Discussion