ECSのサービスのデプロイをもうちょっと速くしたいなぁ

2023-12-17追記：気になることがあって続きを書いた

bufferings.hatenablog.com

2023-12-17追記ここまで

こんな風にECSに入ってくるところにNLBを置いていて、サービスtoサービスの呼び出しにもNLBを挟んでいるような構成を考える。

デフォルトのNLBの設定だとターゲットグループに対する登録や登録解除にかかる時間がとても長いので、↓このトリさんの書いてくれている対応を（自分のアプリケーションの特性に合わせて）あてるのは必須。

それでもNLBのターゲットグループに対する登録と登録解除で数分かかってしまうため、アプリケーションのデプロイに10分ぐらいかかってしまう。

↓このあたりを読んでも、NLB周りで時間がかかるのは避けられなさそう。

https://github.com/kubernetes-sigs/aws-load-balancer-controller/issues/1834#issuecomment-781530724

でも、デプロイに10分は長いなぁ、5分以内に収めたいなぁという気持ち。欲を言えば3分以内。

ECS Service Connectを使うとどうなる？

じゃあ、サービスtoサービスの呼び出しにNLBを使うのをやめて、1年前に発表されたECS Service Connectを使うと、こうなるかな。

入口のNLBのところは変えたくないので、そこにはNginxを立ててプロキシする。アプリケーションへのアクセスはネームスペース経由になる。中身は確認してないけどEnvoyのサイドカーがデプロイされるらしい。

こうするとアプリケーションのデプロイ時にはNLBに対する登録と登録解除がいらなくなるので、数分速くなる。

Nginxの部分はNLBにつながってるので、そこのデプロイには変わらず10分くらいかかるだろうけど、そこはあんまり更新がないという想定。バージョンアップやセキュリティアップデートくらいかな。

簡単に確認

そんなことを頭の中で想像してみたので、実際に動くのかなぁと思ってウェブコンソールから手でポチポチして環境を作って遊んでみた。NginxからApp1への呼び出しはECS Service Connectを使うとこんな感じで書けて便利だった。

proxy_pass http://app1-80-tcp.my-ecs-cluster:80;

デプロイにはecspressoを使って、かかった時間はこんな感じだった。

NLBにつながってるアプリのデプロイ

❯ \time ecspresso deploy
...
      524.80 real         0.28 user         0.13 sys

NLBにつながってないアプリのデプロイ

❯ \time ecspresso deploy
...
      273.19 real         0.14 user         0.09 sys

こんな構成にできたらアプリケーションのデプロイを5分以内にはできそう。Drainingに2,3分かかってるっぽいから、そこがもう少し速くできたら3分以内には終わりそうなんだけどなー。いまのところ、ECS（Fargate）だとこれくらいまでかな。

面白かった！

（ツイートTypoしてた。sugar。）