Elastic Beanstalk で運用する EC サイトの新バージョンをデプロイする際に、デプロイ中もリクエストを処理するキャパシティを一切落とさず、問題発生時には現行バージョンに即座にロールバックできることが必須要

Question

Elastic Beanstalk で運用する EC サイトの新バージョンをデプロイする際に、デプロイ中もリクエストを処理するキャパシティを一切落とさず、問題発生時には現行バージョンに即座にロールバックできることが必須要件です。最も適切なデプロイポリシーはどれですか？

Accepted Answer

正解: Immutable デプロイで別フリートの新インスタンスをヘルスチェック後に既存インスタンスと置き換えるため、問題時は新インスタンスを即座に削除してロールバックする。Immutable デプロイは同一環境内に別フリートを立ち上げてから切り替えるため、デプロイ中もキャパシティが維持され、問題時は新インスタンスを削除するだけで即座にロールバックできる。

Answer

All at once デプロイで全インスタンスを一斉に新バージョンへ切り替え、問題発生時は CloudWatch アラームを検知後に手動でロールバックを実施する — All at once はデプロイ中に全インスタンスが同時に切り替わるためダウンタイムが発生し、キャパシティが一時的にゼロになる要件違反が生じる。

Answer

Rolling with additional batch でキャパシティを維持しながら段階的にバージョンを更新し、新旧バッチを混在させながら切り替えを進める — Rolling with additional batch はキャパシティを維持できるが、問題発生時のロールバックには旧バージョンの再デプロイが必要で即座のロールバック要件を満たさない。

Answer

新しい Elastic Beanstalk 環境を別途プロビジョニングして URL スワップで切り替えるブルー/グリーン構成を採用し、問題時は旧環境へのスワップバックでロールバックする — ブルー/グリーンデプロイは完全な環境の重複が必要でコストが高く、Immutable デプロイと比較してリソース効率と運用複雑性の面で劣る。

解説