Elastic Beanstalkのデプロイポリシーまとめ
Elastic Beanstalkのデプロイポリシーまとめ
デベロッパーアソシエイトを勉強中です。
公式がこちらのページで説明していますが、 文章が分かりづらく、整理のために投稿します。 https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html
前提
- ELBが1つ
- ELBに4つのEC2インスタンスが紐付いている
ローリングの時に使用するバッチについて説明
設定の画面で、バッチサイズの割合を決めることができると思います。
その割合と、インスタンス数を掛け算したものが、 バッチのインスタンス数になります。
例 バッチサイズ:25% インスタンス数:4台 0.25(25%) × 4(台) = 1(台)
All at once(一度に全て)
説明
名前の通り、全てのEC2インスタンスに対して、 同時にデプロイを行います。
デメリット
短時間ではありますが、サービスが停止する時間があります。
それぞれのインスタンスで、デプロイ完了までの時間差が生まれ、 新旧アプリが混在する時間が存在します。
Rolling (ローリング)
説明
-
バッチサイズ分のインスタンスをデタッチします。
-
デタッチしたインスタンスに対して、デプロイをします。
-
デプロイしたインスタンスにヘルスチェックをかけ、問題なければELBにアタッチされます。
全てのインスタンスにデプロイされるまで、1~3を繰り返します。
デメリット
デタッチされている分、ELBで捌けるインスタンス数が減るので、パフォーマンスに影響が出る可能性がある。
新旧アプリが混在する時間が存在します。(All at onceより基本長い時間)
Rolling with additional batch (追加バッチによるローリング)
説明
-
バッチサイズ分のインスタンスを新規立ち上げ、デプロイを実行します。
-
ヘルスチェックをし、問題なければ、ELBにアタッチします。
-
2でアタッチした分、ELBからデタッチし、デプロイを実行
-
デプロイ済みのインスタンスをELBにアタッチします。
3~4を繰り返すことで、全てのインスタンスを更新します。
Rollingでは、一時的にリクインスタンスの数が減っていたが、 こちらでは、新規立ち上げするため、減りません。
実際の本番環境では、こちらが一番よく使われるみたいです。
デメリット
すごく短時間だが、EC2インスタンスの数が増え、料金がかかってしまう。
こちらも新旧アプリが混在する時間が存在します。
Immutable (変更不可)
説明
-
EC2インスタンス実際に稼働している分とを同じ数、用意し、そちらにデプロイします。
-
ヘルスチェックに通るかどうかを確認します。
-
問題なければ、EC2インスタンスを実際に稼働しているELBにアタッチします。
-
古いEC2インスタンスをデタッチし、終了させます。
デメリット
一時的に、EC2インスタンスの数が倍増し、費用がかかる。
こちらも新旧アプリが混在する時間が存在します。
新旧アプリが混在する時間をなくしたい場合
Blue-Green Deploymentを使いましょう。
Blue-Green Deploymentとは
Elastic Beanstalkのクローンを作成し、 そちらにデプロイをします。
動作に問題なければ、環境URLのスワップを行うことで、 新旧アプリが混在する時間がなくなります。
詳しくはこちら https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html
Discussion