AWS
ECS
ALB

AWS ALBのターゲットグループの登録解除の遅延は本当に遅延しているのか

グッドモーニング。いがりです。

今日はタイトル通り、AWS Application Load Balancer(以降、ALB)のターゲットグループの登録解除の遅延の挙動を調べてみました。

もともと、調べようと思ったきっかけは、現在ECS(Fargate)を使っていて、デプロイツールに ecs-deploy を使用していて、このデプロイ時間を短くしようと思ったことからです。

ecs-deployはこちら

Image from Gyazo

まず、デプロイ(ローリングアップデート)時のALBは何をしているのか、まとめました。


ECS(Fargate) の ローリングアップデート でのALBの挙動

ざっくりいうと、新しいインスタンスを立てて、ALBを用いてインスタンスが立ったら新しいインスタンスにパケットを流そう!ということです。。。

簡単な図にしてみました。


1.デプロイ前

Image from Gyazo

ロードバランサーがFargateインスタンスに対してパケットを流しています


2.デプロイ中

Image from Gyazo

デプロイ中。新しいFargateインスタンスが立ちました。


3.デプロイ後①

Image from Gyazo

ALBが新しいインスタンスが立ったことをチェックして、新しいインスタンスにパケットを流し始めます。


4.デプロイ②

Image from Gyazo

使わなくなった古いFargateインスタンスが消えます。

このようにしてローリングアップデートが行われます。ここで登録解除の遅延という概念が登場します。


登録解除の遅延とは

AWSにはこのような記述が。


ターゲットの登録解除中に未処理のリクエストが完了するまで待つ時間。この時間中、ターゲットの状態はストリーミングになります。


ここでいう、ターゲット(ターゲットグループ)とは、Fargateインスタンスのことです。

なので、ターゲットの登録とはどのインスタンスにパケットを流すかを決定することですね。

Image from Gyazo

登録されているターゲットに、矢印のようにアクセスが流れます。

この記述から推測するに、未処理のリクエストがすべて完了したら、遅延の時間を待たずに登録を解除するのでしょうか。🤔

それとも、遅延時間が最後まで経過するまで待ってから登録を解除するのでしょうか。🤔

また、公式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]

と見ることができるでしょうか。👀

線形に増加しているようです。なるほど。

デプロイ時間は遅延時間に比例して伸びるようです。


まとめ

デプロイ時間は登録解除の遅延時間に線形に伸びる

なので、ローリングアップデートをしているシステムで、デプロイ時間を短くしたい場合は、この遅延時間を短くする必要がありそうです。