AWS Elastic Beanstalkのデプロイメントポリシーについて

AWS Elastic Beanstalkのデプロイメントポリシー(デプロイ方法の種類)はここに書かれていますが、機械翻訳なのか品質が酷く大変分かりにくいので、メモしておきます。

バッチとは

デプロイメントポリシーを説明する前に、バッチについて説明しておく。 Elastic Beanstalkの設定画面やドキュメントにバッチという単語がでてきて最初は分かりづらいと思う。(ここでのバッチはバッチサーバーのバッチではなく、1束/1郡/1まとまり といった意味)

まずElastic Beanstalkはデプロイメントポリシーにローリング(Rolling)もしく追加バッチとローリング(Rolling with additional batch)を選択すると、以下のバッチサイズというのが設定できる。 ここで指定した割合を現在のインスタンス数をかけたものがバッチになる。たとえば10インスタンスあって、バッチサイズ30%だとしたら、バッチ=3インスタンスになる。割り切れない場合は切り捨てになるのでたとえば10インスタンスあってバッチサイズ25%だとしたら、バッチは2インスタンスになる。

デプロイ種類

1回にすべて(All at once)

• デプロイの流れ
  • 同時に全ての既存インスタンスにデプロイをする。
• 注意点
  • それぞれのインスタンスはデプロイが実行される間、短時間だがサービス停止状態になる
  • 古いアプリケーションと新しいアプリケーションが混在する時間が存在する

ローリング(Rolling)

• デプロイの流れ
  • まずバッチサイズ分のインスタンスがLBからデタッチされ、デプロイをする
  • ヘルスチェックが通れば、そのバッチがLBに再アタッチされる。
  • 全てのインスタンスにデプロイがされるまで LBからデタッチ⇒デプロイ⇒ヘルスチェックOKならLBに再アタッチ を繰り返す
• 注意点
  • デタッチされている間はリクエストを受け付けるインスタンス数はバッチサイズ分減る。
  • 古いアプリケーションと新しいアプリケーションが混在する時間が存在する

追加バッチとローリング(Rolling with additional batch)

ローリング(Rolling)と違って最初にバッチサイズ 分のインスタンスを追加するので、リクエストを受け付けるインスタンスの数は減らない。そのため本番環境では一番このデプロイメントポリシーが選ばれると思う。

• デプロイの流れ
  • バッチサイズ 分のインスタンスを追加作成&そのインスタンスにデプロイ実行
  • バッチサイズ 分のインスタンスがLBからデタッチされ、デプロイが実行される。
  • デプロイが終わりヘルスチェックが通れば、次のバッチサイズ分のインスタンスが同様にLBからデタッチされデプロイされ..を繰り返す
  • 最後に追加作成分のインスタンスをshutdownする。(起動時刻が古いインスタンスからshutdownされている気がする)
• 注意点
  • 古いアプリケーションと新しいアプリケーションが混在する時間が存在する

変更不可(Immutable)

• デプロイの流れ
  • まず1台インスタンスを立ち上げ、デプロイをする。
  • ヘルスチェックが通れば 現在のインスタンス数-1 分新たにインスタンスを立ち上げ、デプロイする
  • 全部のヘルスチェックが通れば、古いのをshutdownしていく
• 注意点
  • 古いアプリケーションと新しいアプリケーションが混在する時間が存在する

デプロイ時間

デプロイ種類ごとにデプロイ時間が変わってきます。 ここをを見てもらえば分かりますが、以下のような順で 1回にすべて(All at once)が一番デプロイが速いです。

1回にすべて(All at once) < ローリング(Rolling) < 追加バッチとローリング(Rolling with additional batch) < 変更不可(Immutable)

古いアプリケーションと新しいアプリケーションが混在する時間をなくしたい

結局どのデプロイメントポリシーを選んでも古いアプリケーションと新しいアプリケーションが混在する時間は存在する。 もし古いアプリケーションと新しいアプリケーションが混在する時間をなくしたいなら、ここに書いてある、Blue-Green Deploymentを行う必要がある。