執筆者
M.N.
前回の記事の続き
前回の復習
前回の記事でlambdaのランタイムをnode12から22に大規模バージョンアップをする話のAWS設定まで書いたので、今回は続きとして改修～本番リリースまでについての話をします。
バージョンアップ対応の作業内容
復習ですが、バージョンアップ対応では下記の作業を実施しました。
01 バージョン変更に伴う影響範囲調査
02 AWSコンソール上でのバージョンアップ作業
03 影響があったコードの改修
04 本番リリース時の切り戻し手順策定
05 本番リリース
影響があったコードの改修
影響範囲の調査でaws-sdkを使用している関数の方が作業内容が重そうだと判断したため、まずは開発環境で未使用の関数をアップグレードしてみました。
結果、ほぼほぼ問題無く動作しました。
次に、aws-sdkを使用している関数のバージョンアップを実施しましたが、当然エラーで動かなかったため、ソースコードの改修を実施しました。
aws-sdk v2とv3の主な違い
v2はすべての AWS サービスが aws-sdk パッケージにまとめられているのに対し、v3では個別に必要なサービスをインポートする必要があります。
メリット
単にコーディングするだけだと面倒に感じますが、これによって不要なパッケージのインポートが不要になり、バンドルサイズ(＝lambdaにアップロードされるコードサイズ)が小さくなるというメリットがあります。
コード改修の具体例
具体的には、下記のような改修をaws-sdkを使用している箇所ごとに実施しました。
aws-sdk v2
// インポート箇所
const AWS = require("aws-sdk");
const dynamodb = new AWS.DynamoDB({ apiVersion: '2012-08-10' });
// 使用箇所
await dynamodb.putItem({
Item: {アイテムのパラメータ},
TableName: "テーブル名"
}).promise();
↓変更後
aws-sdk v3
// インポート箇所
const { DynamoDBClient, PutItemCommand } = require("@aws-sdk/client-dynamodb");
const dynamodb = new DynamoDBClient({});
// 使用箇所
const command = new PutItemCommand(アイテムのパラメータ);
await dynamodb.send(command);
aws-sdkを使用している関数についても、v3の構文に変更することで、既存の関数と同じように動くことが確認できました。
aws-sdkのEOL対応も同時にできたので、対応時期としては良かったです。
本番リリース時の切り戻し手順策定
すべての関数の改修が完了後、検証環境までのアップグレード作業を実施し、クライアント様の確認を挟んで本番リリース実施日を決めました。
今回のlambdaに限らず、インフラのバージョンアップの際には何かあった場合に前のバージョンに戻せるように対応を進める必要があります。
ただ、今回は開発環境の対応の段階で、別関数として作成して呼び出し元の設定を切り替えるのみで戻せることがわかっていたため、実際の作業手順書に切り戻し方法を記載する程度でした。
構成の説明
①クライアント様からのリクエスト
②WAF
③APIゲートウェイ
④lambda関数が発火するフロー
認証で使用しているCognitoの拡張機能でlambdaトリガーから呼び出され
るフローの2つがあります。
APIゲートウェイからの呼び出し
SwaggerでAPI仕様をバックアップ前にエクスポートし、問題発生時にインポートすることでまとめて切り戻しができるようにしました。
Cognitoのトリガー
5つのみでそれほど時間がかからないため、切り戻し時は設定変更で対応することにしました。
本番リリース
本番リリースはメンテナンスモードで2時間程度のサービス停止をして実施しました。
リリース内容としてはサービスの停止をしなくても実施可能な範囲内でしたが、Cognitoを利用している都合上、ユーザーの認証機能に影響が出る可能性があるため、安全策をとってサービス利用の少ない夜間帯にリリースを実施しました。
1. リモートでの実施
通常のリリース時は基本的に社内での実施ですが、今回は時間の都合上、リモートでの実施となりました。
2. 事業部長待機
念のため事業部長にも待機いただいた状態でリリースを実施しました。
3. 作業完了
特に問題無く作業完了し、クライアント様の確認作業の完了後にメンテナンスモードを解除し、サービスを再稼働しました。
4. 経過観察
サービス再稼働後、1時間程度は事業部長とslackで雑談をしつつ、経過観察を実施しました。
残対応
ここまででバージョンアップ作業は完了ですが、残課題として古い関数の削除が残っています。
使用料金が発生するのは主にリクエスト時のため、呼び出されない関数が残っていても問題は無いですが、不要なものを残しておく必要もないため、前のバージョンに戻すことが無いとクライアント様が判断した段階で削除予定です。
まとめ
今回はnode12から22への変更かつ、aws-sdk v2からv3への変更のため、そこそこ時間がかかりました。
ただ、こまめにバージョンアップをしていれば切り戻しの問題などは発生しなかったため、インフラのバージョンの定期的な見直しは重要だと感じました。
