執筆者
M.N.
システムの背景
弊社が、
受託開発・保守をしているシステムのうち、とあるサービスでは一部機能でAWSのlambdaを使用しています。
主にCognito連携やSNS連携のインターフェースなど、複雑なロジックの絡まない一部の機能のみ、lambdaでの実装となっています。
余談ですが、このシステムではフロントエンドにVue2、バックエンドにPHP7.4を使用しており、こちらのバージョンアップ作業も必要なことが判明しています…。
現状の課題
使用状況
使用しているlambda関数は20個ほどですが、その全てがnode12ランタイムとなっていました。
問題点
EOLでセキュリティアップデートの対象外となる等の問題以前に、AWSの仕様上、サポートされていないランタイムはデプロイができないため、改修などもできない状況です。
バージョンアップ
経緯
自分のアサイン前からのシステムであるため、開発時点でnode12はとっくにEOLを迎えていたはずですが、lambda関数で使用している機能は簡易的なロジックのものばかりのため、ローンチから数年の間で1回も改修が入らなかったのでしょう。
改修が入っていればメンテナンスされていたはず……。
過ぎたことを嘆いても仕方が無いので、lambdaのバージョンアップを実施することになりました。
作業の全体像
01 バージョン変更に伴う影響範囲調査
02 AWSコンソール上でのバージョンアップ作業
03 影響があったコードの改修
04 本番リリース時の切り戻し手順策定
05 本番リリース
作業フローごとに、実施した内容
バージョン変更に伴う影響範囲調査
ほぼ全ての関数がnode12ランタイムだったため、12から2025年8月時点で最新のnode22ランタイムにする想定で、影響範囲の調査を実施しました。
主にやっていたことは、インターネット上で先人の知恵を拝借するか、ChatGPTに調査させて情報源を確認して裏取りするかで、特に変わったことはしていないため、調査方法についての仔細は割愛します。
調査結果
調査の結果、ソースコードの修正が必要な改修はaws-sdkの利用箇所に絞っても問題なさそうだと判断しました。
・node12ランタイム
aws-sdk v2系がプリインストール
・node22ランタイム
プリインストールなし
元々の、
node12ランタイムではaws-sdk v2系がプリインストールされているのに対し、22ではプリインストールなし、かつaws-sdk v2自体も2025年9月8日でサポート終了予定だったため、aws-sdkの使用箇所をv3に変更する必要もありました。
そこで、
関数ごとにaws-sdkの使用／未使用を分類し、aws-sdkを使用している関数には改修を入れる想定でスケジュールを組みました。
それ以外は、
特に大がかりな修正が必要な個所はありませんでした。
もちろんnode12と22の間での構文変更やパッケージの依存関係など、色々な変更はあるのですが、それほど複雑なロジックは無く影響のあるパッケージも利用していませんでした。
確認した限りでは、
そのままでも動きそうだったため、一旦動かしてみて、挙動を確認する方針としました。
AWSコンソール上でのバージョンアップ作業
このサービスでは開発環境、検証環境、本番環境の3環境が存在するため、全環境でバージョンアップを実施する必要がありました。
・開発環境
そのまま開発用
・検証環境
主にクライアントの確認用で使用
・本番環境
実運用環境
課題と対応
開発環境については改修途中でエラーが発生しても問題は無いのですが、別の機能開発等でも利用しており自分以外の開発者が機能の実装中だったため、長期間機能が使えなくなる事態は避けたいと考えました。
ただ、長年未対応であったので既にサポートが切れているため、一度バージョンアップしてしまうと前のバージョンへの切り戻しができない問題があったため、下記のような方法で切り戻しを可能にしました。
切り戻し可能な実装手順
新しいlambda関数を作成
➤新しいlambda関数をnode22で作成し、コードを元のソースコードと同じ実装にする
設定を合わせる
➤設定等も元の関数に合わせる
呼び出し元を変更
➤呼び出し元で指定している関数を新しい関数に変更する
切り戻し手順
➤問題があった場合は呼び出し元の指定を元の関数に戻す
こちらの方法で、新しい関数の検証をしつつ、他機能の開発に影響無く作業を進めることができました。
