ある企業がAWS SAMを使ってLambda関数をデプロイしている。デプロイ後に本番トラフィックの一部を新バージョンに切り替えたところ、新バージョンで発生したエラーが原因でSAMが自動ロールバックを実行した。しかし、ロールバック後も一部のリクエストでエラーが継続していた。その原因として最も可能性が高いものはどれか。
- A. Lambda関数のプロビジョニング済み同時実行数（Provisioned Concurrency）が新バージョンに設定されていたため、ロールバック後も新バージョンのインスタンスが維持されていた
- B. ロールバックはCloudFormationスタックのみを旧状態に戻すが、Lambdaエイリアスはロールバックされないため、エイリアスが引き続き新バージョンを参照していた
- C. SAMのロールバックはS3にアップロードされたコードパッケージを旧バージョンに戻すため、Lambdaが旧バージョンを再ダウンロードする間の遅延でエラーが継続した
- D. SAMのロールバックはLambdaエイリアスの向き先を旧バージョンに戻すだけであり、進行中のリクエストはキャンセルされないため、ロールバック時点で新バージョンを実行中だったコンテナが残っていた可能性がある
解答と解説を見る
正解: D
SAMのDeploymentPreferenceによるロールバックはCodeDeployがLambdaエイリアスのバージョンポインタを旧バージョン番号に切り替えることで実現する。エイリアスの更新は即座に有効になるが、ロールバック実行時点でLambdaの実行環境（コンテナ）上で新バージョンを処理中だったリクエストはそのまま処理が継続されるため、一時的にエラーが続くことがある。Lambda関数は各実行環境がリクエストを処理し終えるまで強制終了されないという特性がある。CはLambdaのロールバックがS3からコードを再ダウンロードする仕組みではないため誤りである。Bはロールバック時にLambdaエイリアスも正しくロールバックされるため誤りである。AのProvisioned Concurrencyは新バージョンへの設定を明示的に削除しない限り残るが、エイリアスが旧バージョンを指せば本番トラフィックは旧バージョンに向くため、主要因としては考えにくい。ロールバック後の一時的なエラー継続は新バージョン実行中リクエストの完了待ちが主因である。
📚 関連サービスの解説: AWS Lambda