グッドモーニング。いがりです。
今日はタイトル通り、AWS Application Load Balancer（以降、ALB）のターゲットグループの登録解除の遅延の挙動を調べてみました。
もともと、調べようと思ったきっかけは、現在ECS(Fargate)を使っていて、デプロイツールに ecs-deploy を使用していて、このデプロイ時間を短くしようと思ったことからです。
ecs-deployはこちら
まず、デプロイ（ローリングアップデート）時のALBは何をしているのか、まとめました。
ECS(Fargate) の ローリングアップデート でのALBの挙動
ざっくりいうと、新しいインスタンスを立てて、ALBを用いてインスタンスが立ったら新しいインスタンスにパケットを流そう！ということです。。。
簡単な図にしてみました。
1.デプロイ前
ロードバランサーがFargateインスタンスに対してパケットを流しています
2.デプロイ中
デプロイ中。新しいFargateインスタンスが立ちました。
3.デプロイ後①
ALBが新しいインスタンスが立ったことをチェックして、新しいインスタンスにパケットを流し始めます。
4.デプロイ②
使わなくなった古いFargateインスタンスが消えます。
このようにしてローリングアップデートが行われます。ここで登録解除の遅延という概念が登場します。
登録解除の遅延とは
AWSにはこのような記述が。
ターゲットの登録解除中に未処理のリクエストが完了するまで待つ時間。この時間中、ターゲットの状態はストリーミングになります。
ここでいう、ターゲット（ターゲットグループ）とは、Fargateインスタンスのことです。
なので、ターゲットの登録とはどのインスタンスにパケットを流すかを決定することですね。
登録されているターゲットに、矢印のようにアクセスが流れます。
この記述から推測するに、未処理のリクエストがすべて完了したら、遅延の時間を待たずに登録を解除するのでしょうか。🤔
それとも、遅延時間が最後まで経過するまで待ってから登録を解除するのでしょうか。🤔
また、公式Docsにはこのようにあります。
Elastic Load Balancing は、登録解除するターゲットへのリクエストの送信を停止します。デフォルトでは、Elastic Load Balancing 登録解除プロセスを完了する前に 300 秒待って、ターゲットへ処理中のリクエストが完了するのを助けることができます。Elastic Load Balancing が待機する時間を変更するには、登録解除の遅延値を更新します。
お。後者なのかな。
もし後者であれば、遅延の時間を短くすればデプロイ時間は短縮するはず。
今回は、小さな実験をして、遅延時間とecs-deployの時間の関係性を調べてみました。
実験： 遅延時間とecs-deployの時間の関係性
動作環境
・ECS(Fargate)にRuby on Railsアプリをのせている
・ecs-deployからローリングアップデートをさせる
・アプリに30秒ごとのヘルスチェック以外のアクセスはしない
やること
遅延時間を30秒間隔で0秒から120秒まで増やしていく実験を行い、遅延時間とecs-deployでかかる時間を調べる。
結果
表にしました。
| 遅延時間(sec) | ecs-deployの処理時間(sec) |
|---|---|
| 0 | 162 |
| 30 | 191 |
| 60 | 203 |
| 90 | 234 |
| 120 | 275 |
考察
およそ、
(ecs-deployの処理時間) = (遅延時間) + 160 [sec]
と見ることができるでしょうか。👀
線形に増加しているようです。なるほど。
デプロイ時間は遅延時間に比例して伸びるようです。
まとめ
デプロイ時間は登録解除の遅延時間に線形に伸びる
なので、ローリングアップデートをしているシステムで、デプロイ時間を短くしたい場合は、この遅延時間を短くする必要がありそうです。