AWS Lambda関数をメンテナンスしやすくするためのTips
Lambda関数の構成・設定にちょっとした工夫を加えておくだけで、ランタイムEOL対応などのメンテナンスが楽になります。手軽に実践できるTipsをまとめました。
目次
はじめに
最近、AWS Lambdaの関数ランタイムのメンテナンスを行いました。 Ruby 3.2やNode.js 20.xのEOLに対応するというものです。
この作業を通じて感じたのは、Lambda関数の構成・設定にちょっとした工夫を加えておくだけで、こうしたメンテナンスが楽になるということです。
Lambda関数はちょっとした処理のために手軽に作成できるのが魅力です。 一方で、こうした関数で作成後に継続的な機能追加が行われることは少なく、メンテナンスはほとんどEOL対応のみというケースも珍しくありません。 そのため、Docker化してCI/CDを整備したり、Terraformで管理したりするのはやや大げさにも感じられます。 （この記事ではサーバーレスアプリケーションのように継続的に開発するケースはあまり想定していません。）
この記事では、楽に設定できる割にメンテナンス時の安全性や効率が大きく向上する小技をまとめました。
バージョンを発行してエイリアスに紐づける
AWS マネジメントコンソール上で特に意識せずに関数を設定すると、$LATESTがそのまま本番稼働することになります。
$LATESTは常に最新のデプロイ済みコードを指す特殊なバージョンです。
この状態だと、ランタイムや関数コードの変更が即座に本番環境へ反映されてしまうため、メンテナンスがかなりやりづらくなります。
バージョンを発行すると、その時点のコードと設定がイミュータブルな状態として保存されます。 そのため、本番環境ではバージョンを指定して稼働させた方が安全です。 ただし、バージョンを直接指定する方式だと、トリガー設定などをバージョン発行のたびにやり直す必要があり、手間がかかります。
そこでエイリアスを活用します。 エイリアスを作成し、トリガーなどの関数周りの設定をエイリアスに行えば、紐づけるバージョンを切り替えるだけでデプロイが完了します。
環境変数を活用する
時には複数の環境（本番/ステージングなど）で同じ関数コードを使いたいケースがあります。 この場合、環境ごとに変わるコードを、「ここ1行を変えるだけだし」と直接変更して済ませたくもなってしまいます。
しかし、コード変更が必要になった際に、環境ごとの差分がどこにあったかを覚えているとは限りません。 そのためきちんと環境変数を活用して、コードを一切変更せずに環境を切り替えられるようにしておくのが無難です。
ただしLambdaの場合、秘匿情報をそのまま環境変数に設定するのはセキュリティ上好ましくありません。 秘匿情報はAWS Secrets ManagerやSSM Parameter Store（SecureString）に保存し、関数コードから取得する形にするのが適切です。
テストイベントを作成する
他サービスと連携する関数のテストをローカルで書こうとすると、モックが多くなってしまいます。 そのため、ローカルでの自動テスト整備はやりづらく、費用対効果に疑問を感じることもあります。
こうした場合でも、テストイベントを作成して動作確認フローを整えておくだけで、メンテナンスがかなりやりやすくなります。
さらに、テスト手順を記述したREADME.mdを関数コードに含めたり、テスト手順ドキュメントへのリンクをコード上にコメントとして残したりすると、メンテナンス時に迷わずに済みます。
おわりに
本記事で紹介した設定はいずれも工数が軽く、既存関数への追加も比較的やりやすいものばかりです。 関数作成時やメンテナンス時にぜひ取り入れてみてください。