我有一个服务于SSH进程的ECS服务。我正在通过CodeDeploy将更新部署到该服务。我注意到，与使用CodePipeline同时部署相同映像的其他服务相比，部署此服务要慢得多。此服务的区别在于它位于NLB后面（其他都不是LB或ALB后面）。
该服务设置为1个容器，部署200％/ 100％，因此该服务将启动1个新容器，确保其健康，然后删除旧容器。我看到的是：
Initial状态启动Healthy。旧容器进入Draining Draining并停止因此，部署需要5到7分钟，主要是等待运行状况检查或排水。但是，我非常确定SSH的启动速度非常快，并且我在目标组上具有以下设置，这些设置可以使事情相对快速：
因此，从SSH到终止旧容器的最短时间为：
这是115秒，比观察到的5-7分钟要少得多。其他服务需要1-3分钟，而LB /目标组的时间安排在那方面并不那么积极。
有什么想法为什么我在NLB后面的服务在这些生命周期过渡中似乎很慢？
答案 0 :(得分：1)
您在这里没有做错任何事；这似乎只是该产品的（当前）限制。
我最近注意到NLB背后的ECS服务在注册/可用时间方面存在类似的延迟，因此决定进行探索。我创建了一个简单的Javascript TCP回显服务器，并将其设置为NLB（ECS服务计数为1）后面的ECS服务。像您一样，我使用了TCP健康检查，健康/不健康阈值为2，间隔/取消延迟为10秒。
在初始部署成功并且可以通过NLB访问该服务之后，我想了解在基础实例完全失败的情况下恢复服务需要花费多长时间。为了模拟，我通过ECS控制台终止了该服务。经过多次测试，我始终观察到类似于以下内容的时间轴（时间以秒为单位）：
0s: killed service
5s: ECS reports old service draining
Target Group shows service draining
ECS reports new service instance is started
15s: ECS reports new task is registered
Target Group shows new instance with status of 'initial'
135s: TCP healthcheck traffic from the load balancer starts arriving
for the service (as measured by tcpdump on the EC2 host running
the container)
225s: Target Group finally marks the service as 'healthy'
ECS reports service has reached a steady state
我使用ALB后面的一个简单Express应用程序执行了相同的测试，ECS启动服务与ALB报告运行状况良好之间的差距为10-15秒。从服务停止到完全可用，我们测试NLB的最佳结果是3.5分钟。
我通过支持案例与AWS分享了这些发现，特别是要求澄清为什么NLB开始对服务进行健康检查之前始终存在120秒的间隔，以及为什么我们在开始健康检查和服务可用性之间始终看到90-120秒。他们确认这种行为是已知的，但并未提供解决时间或减少服务可用性延迟的策略。
不幸的是，这对解决您的问题没有多大帮助，但至少您可以知道自己没有做错任何事情。