はじめに
NTTドコモ情報システム部の山川と申します。 AWS LambdaでPython 3.7のサポート終了に伴って、リリース作業に多少の工夫が必要な状況になってしまった時の対応と学びについて共有します。
AWS LambdaでPython 3.7のサポート終了を迎え、ランタイムのアップデートを進める必要がありました。しかし、対応が遅れた結果、AWSの非推奨化フェーズ2を超えてしまい素直にランタイムを更新するだけだと、万が一の切り戻し作業ができない状況に直面しました。 ※切り戻しとはリリース作業後に問題が発生した際にリリース前の状態に戻すことを指す
AWS Lambdaのランタイム非推奨化フェーズ
AWS Lambdaランタイムの非推奨化は以下の2つのフェーズに分かれています。
非推奨化フェーズ1
- テクニカルサポートの対象外となる
- 既存の関数はソースコードの更新が可能だが、新規関数の作成は不可
非推奨化フェーズ2
- ソースコードの更新も不可
- サポートされているランタイムに移行した場合、元のランタイムへのロールバックは不可能
↑このように非推奨化フェーズ2に突入したPython3.7はランタイム編集の選択肢から消える
今回はフェーズ2に差し込んでしまったため「元のランタイムへのロールバックは不可能」によって、何も手を打たないと切り戻しができない状況になってしまい、お客様への影響を最小限にしたリリースが担保できない状況となってしまいました。
リリース作業のプロセス
素直にLambdaのランタイム更新を行うと切り戻しができないという問題の解決策として、今回のリリース作業は以下の3つのステップに分けて実施しました。 なお、今回の対象Lambdaは各種APIのエラー発生時に呼びだされ、Slack通知を行う「slackpost」というLambdaです。
Step 1: 新規Lambdaの作成と切り替え
- Python 3.11ランタイムを利用して新規Lambda関数（
slackpost_new）を作成 - 各種APIが呼び出す通知Lambdaの向き先を、既存Lambda（
slackpost）から新規Lambda（slackpost_new）に変更 - 既存Lambda（
slackpost）は残しておくことで、問題発生時に向き先を戻す形で切り戻しを可能に
Step 2: 既存Lambdaのランタイム変更と切り替え
- 既存Lambda（
slackpost）のランタイムをPython 3.7からPython 3.11に変更 - 各種APIの向き先を、新規Lambda（
slackpost_new）から既存Lambda（slackpost）に再度変更 - 問題が発生した場合、新規Lambdaに向き先を戻すことでStep 1の状態に切り戻せる構成を維持
Step 3: 新規Lambdaの削除
- Step 2で既存Lambdaに移行が完了した後、新規Lambda（
slackpost_new）を削除 備考 : Step 1の状態で運用を続けることも検討しましたが、既存資産の名称が変更されることを避けるため、最終的にStep 3まで実施しました
上記の手順でリリース作業を行うことで、問題発生時に切り戻しが可能かつこれまで使っていた資産をアップデートする形(≒フェーズ2に突入する前に正しいタイミングで対応した際の形)で、Lambdaのランタイム更新を終えることができました。
教訓と将来的に検討したい対策
以下は今回の対応を通じて得られた教訓と今後の対策です。
バージョンアップ対応の優先度管理
バージョンアップ対応は非推奨化フェーズ2に突入してしまうと、余計な検討時間とリリース作業が必要になり痛い目に合うことが分かりました
→軽い気持ちで後回しにしてはいけない
フェーズ2のラインはデッドと考え余裕を持ったリリース計画を立てるべきだと学びました
今後の対策の方向性
バージョンアップ対応はサービスを安全に提供し続けるために必要な対応ですが、影響範囲の調査等で意外と時間がかかってしまうため、後回しにしがちかと思います。優先順位の管理はもちろんですが、この調査が楽になる仕組みを導入することで、フェーズ2突入を防止する方向の検討をしたいと思っています。
おわりに
今回はLambdaのランタイム非推奨化フェーズ2に入ってしまった場合でも、切り戻し可能な安全なリリース方式の例を紹介しましたが、これは最後の手段だと思っていただけたらと思います。 大前提としてしっかりと期限内に非推奨化フェーズに入る前にバージョンアップ対応を終えることが一番になりますので、皆さんも同じ失敗をしないよう気を付けていただけたらと思います。
