😽
AWS Elastic Beanstalkのデプロイ方式まとめ
AWS DVA取得目指して勉強中です。
練習問題でElastic Beanstalkのデプロイ方式についての問題があってわからなかった&公式ドキュメントの説明が若干散らばってる感じだったので、まとめてみます。
デプロイ方式まとめ
- All ato once
- 最も迅速であり、サービスが短期間停止してもとにかく早く終えたい場合に選ぶ。
- 新しいバージョンを書くインスタンスにデプロイし、ウェブプロキシまたはAppサーバーを再起動する
- Rolling
- ダウンタイムを回避する代わりにデプロイ時間は長くなる
- 一度に1バッチのインスタンスにデプロイ
- 該当バッチをロードバランサーからデタッチし、新バージョンをデプロイ後に再アタッチ。ヘルスチェックのURLから200が返ったら、トラフィックをそのインスタンスへ送るようにする。バッチ内のインスタンスが(拡張ヘルスチェックが設定されていればそれも含めて)全て正常だったら次のバッチを処理。
- ほとんどの帯域幅はデプロイ全体で保持される
- Rolling with additional batch
- Rollingよりさらにデプロイ時間が長くなる代わりに、デプロイ全体で確実に同じ帯域幅を保持する。
- インスタンスの追加バッチを起動し、ローリングデプロイを行う
- Immutable
- 既存のインスタンスを更新するのではなく、常に新しいインスタンスにデプロイする
- 低速だが、ロールバックが迅速かつ安全。
- 一時的なAutoScallingグループを作成し、その中に新規設定で単一のインスタンスをデプロイ。これは元のAutoScallingグループの全インスタンスと共にトラフィックを処理する。この新しいインスタンスがヘルスチェックに合格した場合、元のAutoScalling内のインスタンス数と一致するように追加のインスタンスを起動。それらも全てヘルスチェックに合格すれば、元のAutoScallingグループに転送し、一時的なAutoScallingグループと古いインスタンスを終了する。
- 新しいインスタンスがリクエストを正しく処理していることを確認するため、拡張ヘルスレポートが必要。
- Traffic splitting
- Canaryデプロイ。
- 低速
- トラフィックの一部を使用して新しいバージョンのヘルスをテストしながら、残りのトラフィックを古いあアプリケーションバージョンで処理され続ける場合
- 一時的なAutoScallingグループを作成し、その中に新規設定で一連のインスタンスをデプロイ。ロードバランサーに、トラフィックのうち特定の割合を新しいインスタンスに転送するよう指示。その後、設定された期間、新しい一連のインスタンスのヘルスを追跡。ここまで問題がなければ、残りのトラフィックを新しいインスタンスにシフト。それらのインスタンスを元のAutoScallingグループにアタッチして、古いインスタンスを置き換える。最後に、古いインスタンスを終了し、一時的なAutoScallingグループを削除する。
なお、Blue-Greenデプロイのオプションはなく、必要な場合は手動で新しい環境を作ってデプロイした上で、概要ページで「環境URLのスワップ」を行う。
互換性がないプラットフォームバージョンに更新する場合や、Elastic Beanstalkののインプレース更新によるわずかな利用不可時間も強要できない場合にはBlue-Greenデプロイが必要となる。
参考にした公式Doc
- https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html
- https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/environmentmgmt-updates-immutable.html
感想
BlueGreenデプロイのオプションはないんですね。
あと、2種類のRollingの違い、Immutableがcanaryデプロイというのは覚えておきたいです。
Discussion