CodeDeploy + ALBでEC2に1台ずつデプロイする #AWS

はじめに

CodeDeployはALBを使って、複数台あるEC2を順次

振り分け停止
デプロイ実施
振り分け再開

する、といったデプロイ方法を取ることが可能です。

これを試してみたところ、想像していたよりもデプロイに時間がかかってしまいました。

また、ターゲットグループの設定を見直すことで処理時間を短縮できるので、その点も含めて記事化しています。

1. 構成

ALB
EC2インスタンス * 2

ALBのターゲットグループでは、以下の通り2台のEC2インスタンスを登録しています。

この2台がCodeDeployのデプロイ対象です。

2. CodeDeployのデプロイグループの設定

ALBを使ったデプロイでのCodeDeployの設定です。

2.1. デプロイタイプ

デプロイタイプはインプレースとしました。既存のEC2インスタンスに新しいアプリケーションをデプロイします。

なお、Blue/Greenだと、新しくEC2インスタンスを起動し、そこに新しいアプリケーションをデプロイします。

2.2. デプロイ設定

デプロイ設定はCodeDeployDefault.OneAtATimeとしました。これは1台ずつデプロイを行う設定です。

他には、1度に全台デプロイする設定や、1度に半分の台数にデプロイする設定などがあります。

CodeDeploy でデプロイ設定を使用する - AWS CodeDeploy

余談

なお、1度に全台デプロイする設定CodeDeployDefault.AllAtATOnceとALBを組み合わせると、全台をターゲットグループから削除してしまうので、この設定を組み合わせる意味は無さそうです。

👇2台ともデプロイが開始されている！？

👇ターゲットグループにEC2インスタンスが1つもない。。。

2.3. ロードバランサー

ロードバランサーは、有効にするにチェックを入れ、ALBを選択します。

また、ターゲットグループも、先ほどのものを選択します。

以上で準備は完了です。

3. デプロイの実施(1回目)

3.1. デプロイの開始

CodeDeployによるデプロイを開始します。

2台あるEC2インスタンスのうち、1台目のデプロイが進行中となりました。

もう1台は保留中となっています。

ここでターゲットグループを見ると、(先ほどの画面とEC2インスタンスの並びが上下逆なのでわかりづらいですが)1台目のステータスがdrainingとなったことを確認できました。

3.2. ALBを使った場合のデプロイのイベント

1台目のデプロイ状況をさらに詳しく見るため、View eventsへ進みます。

イベントがずらっと並んでいますが、ロードバランサーを使う場合はそうでない場合よりもイベントが増えます。

以下はAWS公式ドキュメントからの引用ですが、トラフィックの停止や再開に関するイベントが最初と最後に増えています(以下の図ではClassic load blancerとありますがALBも同様)。

AppSpec の「hooks」セクション - AWS CodeDeploy

3.3. BlockTrafficイベントとAllowTrafficイベント

さて、ALBを使うことで増えたイベントのBlockTrafficですが、何とこちらに5分31秒もかかってしまいました。

さらに終盤のAllowTrafficイベントでは2分30秒かかりました。

1台のEC2インスタンスのデプロイに8分30秒以上がかかっています。

ALBが賢く振り分けの停止・再開をやってはくれていますが、これは少し長い。。。

4. ターゲットグループの設定変更

デプロイにかかる時間を短縮するため、こちらの記事(AWS CodeDeployの速度改善(ALB))を参考にターゲットグループの設定変更を行いました。

4.1. ヘルスチェック間隔の短縮

ターゲットグループ > ヘルスチェックタブ > ヘルスチェックの編集で以下の通り、変更しました。

タイムアウト: 5秒 -> 4秒(タイムアウトは間隔の秒数未満である必要があるため)
間隔: 30秒 -> 5秒(最小値)

元々の設定

変更後の設定

4.2. 登録解除の遅延の短縮

ターゲットグループ > 説明タブ > 属性で以下の通り、変更しました。

登録解除の遅延: 300秒 -> 10秒

元々の設定

変更後の設定

登録解除の遅延とは

登録解除の遅延(Deregistration Delay)は、対象のEC2を振り分け停止(ターゲットグループから削除)するにあたり、未処理のリクエストやアクティブな接続が無かったとしても必ず待機する時間のことで、このデフォルトが300秒であるためにCodeDeployのBlockTrafficイベントが長期化しているようです。

Elastic Load Balancing は、登録解除するターゲットへのリクエストの送信を停止します。デフォルトでは、Elastic Load Balancing 登録解除プロセスを完了する前に 300 秒待って、ターゲットへ処理中のリクエストが完了するのを助けることができます。
(略)
登録解除するターゲットに未処理のリクエストやアクティブな接続がない場合は、Elastic Load Balancing は登録解除の遅延時間が経過するのを待たずに、即時登録解除プロセスを完了します。ただし、ターゲットの登録解除が完了しても、ターゲットのステータスは、登録解除の遅延が経過するまで draining と表示されます。

登録解除の遅延 - AWS公式

5. デプロイの実施(2回目)

以下の通り、大幅に短縮されました。

BlockTraffic: 5分31秒 -> 25秒
AllowTraffic: 2分30秒 -> 30秒

となっています。

デプロイ処理全体で見ると、これだけの変化がありました。

ビフォー

アフター

ALBの要件にもよりますが、CodeDeployでALBを利用したデプロイを行う場合は、ターゲットグループの設定も見直した方が良さそうです。