ある企業がAPI GatewayのREST APIとLambdaで構成されたAPIを本番環境に運用している。新機能のデプロイ時に問題が発生した場合に即座にロールバックできるようにしたい。また、新バージョンを全トラフィックに適用する前に5%のトラフィックで動作検証を行いたい。最小の設定変更でこれらの要件を同時に満たすデプロイ方式として最も適切なものはどれか。
- A. API Gatewayのステージ変数にバージョン番号を格納し、Lambda関数内でバージョン番号を読んで処理を分岐させる
- B. CodeDeployのLambdaデプロイタイプ(Canary10Percent5Minutes等)を使い、新Lambdaバージョンへのトラフィックを段階的に移行する
- C. 新バージョン用に別のAPI GatewayエンドポイントをデプロイしてRoute 53のWRR(重み付きルーティング)で5%を新エンドポイントに向ける
- D. API Gatewayにカナリアリリース設定を行い、新バージョンへのトラフィック割合(5%)とLambdaのエイリアスを組み合わせる
解答と解説を見る
正解: B
AWS CodeDeployはLambda関数のデプロイにおいてカナリアリリースとリニアシフトをネイティブにサポートしている。Canary10Percent5Minutesなどの事前定義デプロイ設定を使うと、最初に10%のトラフィックを新Lambdaバージョンに向け、5分後に問題がなければ残り90%を切り替えるという動作が自動化される。5%のカナリアにはCanary5Percent30Minutesなどを使う。重要なのは、CloudWatchアラームと統合してロールバック条件を自動化できる点であり、問題検知時の即時ロールバックも設定ベースで実現できる。選択肢DはAPI Gatewayカナリアとエイリアスの組み合わせも有効なアプローチだが、API Gatewayカナリアはステージのデプロイバージョン管理に関するものであり、Lambdaのバージョン切り替えはエイリアスのルーティング設定で別途管理が必要になるため、CodeDeployによる統合管理の方が設定変更が少なく、自動ロールバックとの統合も容易である。選択肢Aのコード内分岐はバージョン管理ロジックをビジネスロジックに混入させる悪い実践である。選択肢CのRoute 53 WRRはAPIエンドポイント全体の分散には使えるが、同一API内でのLambdaバージョン間のトラフィック分割に使う設計は不自然であり、2つのAPI定義の二重管理が必要になる。
📚 関連サービスの解説: AWS CodeDeploy ・ AWS Lambda