Beanstalkはデプロイ時にELB連携してる?ローリングデプロイとは

Beanstalkでデプロイした場合、デプロイ作業時にELB(ターゲットグループ)がどのような挙動をしているのか確認してみました。
目的は、

  • デプロイ中のEC2にユーザーがアクセスしてしまう可能性があるか?
  • デプロイ中にELB(ターゲットグループ)のアクセス制御(トラフィックコントロール)が入っているか

を確認しました。

環境・前提条件

Beanstalkでの「ローリンング更新とデプロイ」の設定は以下のように設定されています。

  • デプロイメントポリシーは「ローリング」
  • ローリング更新のタイプは「ヘルスに基づくローリング」

他にも、デプロイ時間を考慮した「時間にもとづくローリング」も設定可能でした。

結論、ローリングデプロイはELB(ターゲットグループ)連携してデプロイ中のユーザーアクセスが来ないような制御をしている

以下、デプロイ中に確認したターゲットグループのEC2ステータス遷移

では、上記デプロイメントポリシーで「アプロードとデプロイ」を実施してみます。

デプロイが実行されたことを確認し、beanstalkのターゲットグループのターゲット画面を確認します。

1、デプロイ対象の一台目EC2がdrainingされる。ターゲットグループからデプロイ対象が外される。

「ローリンング更新とデプロイ」 の設定どおり、EC2一台ずつデプロイが実施されていることがわかります。
デプロイ対象のEC2はターゲットグループ上、unhealthyになるわけではなくdraining(外される)操作がされていることがわかります。


2、デプロイ中も AutoScalingのもう一台のEC2はhealthyのまま

デプロイ中のEC2はターゲットグループから外され(制御が入らないとターゲットから外れずにunused等のステータスになる)ますが、
別のもう一台のhealthyのEC2がありますのでユーザーはアクセスできます。
AutoScalingの最低台数は今回2台なのですが、EC2が無くなったターミネートされたわけでは無いので、ターゲットグループからは見えませんがEC2の台数自体は変わっていません。

3、デプロイが終わるとまたターゲットグループに追加される

デプロイが完了すると、先ほどターゲットグループから外されたEC2が再びターゲットグループに追加され、intialステータスになっていることがわかります。

4、ターゲットグループでステータスがhealthyになると次のEC2がデプロイ対象となる。これの繰り返し(ローリング)

Beanstalkで作成した場合は、デプロイ時にターゲットグループにデプロイ制御が入ることがわかりました。
なかなかここまで作りこむのは大変なので、便利ではありますね!

違いを知るためにBeanstalkのAutoScalingグループを違うターゲットグループに追加してデプロイ時の挙動を見てみると

結果、ずっとステータスはhealthyのままでした。
つまり、デプロイ中のEC2にユーザーがアクセスしに行ってしまいます。

デプロイ中にユーザーアクセスがあると、もちろんケースによってはエラー(レスポンスコード500番台)が帰ることになります。
BeanstalkのAutoScalingグループのターゲットグループは変更しない方がデプロイを考えると良いですね(逆に、ターゲットグループに紐づくALBを変えるのは問題はなさそうでした。Beanstalkの「環境の再構築」等をしなければですけど)

参考:

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です