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)
- デプロイの流れ
- 注意点
追加バッチとローリング(Rolling with additional batch)
ローリング(Rolling)
と違って最初にバッチサイズ 分のインスタンスを追加するので、リクエストを受け付けるインスタンスの数は減らない。そのため本番環境では一番このデプロイメントポリシーが選ばれると思う。
- デプロイの流れ
- 注意点
- 古いアプリケーションと新しいアプリケーションが混在する時間が存在する
変更不可(Immutable)
- デプロイの流れ
- 注意点
- 古いアプリケーションと新しいアプリケーションが混在する時間が存在する
デプロイ時間
デプロイ種類ごとにデプロイ時間が変わってきます。 ここをを見てもらえば分かりますが、以下のような順で 1回にすべて(All at once)が一番デプロイが速いです。
1回にすべて(All at once) < ローリング(Rolling) < 追加バッチとローリング(Rolling with additional batch) < 変更不可(Immutable)
古いアプリケーションと新しいアプリケーションが混在する時間をなくしたい
結局どのデプロイメントポリシーを選んでも古いアプリケーションと新しいアプリケーションが混在する時間は存在する。 もし古いアプリケーションと新しいアプリケーションが混在する時間をなくしたいなら、ここに書いてある、Blue-Green Deploymentを行う必要がある。