代码之家 › 专栏 › 技术社区 › Eric M. Johnson

在网络负载平衡器+目标组后面运行ssh的aws ecs服务使用codedeploy部署缓慢

nlb amazon-elb amazon-ecs

Eric M. Johnson · 技术社区 · 6 年前

我有一个服务于ssh进程的ecs服务。我正在通过codedeploy部署对此服务的更新。我注意到,与使用codepipeline同时部署相同映像的其他服务相比,此服务的部署速度要慢得多。与此服务的区别在于它位于NLB后面(其他服务不是LB或ALB后面)。

服务被设置为1个容器,部署了200%/100%,所以服务会打开1个新容器,确保它是健康的,然后删除旧容器。我看到的是:

新容器开始于 Initial 状态
3分钟后,新容器变为 Healthy . 旧集装箱进入 Draining
2分钟后,旧容器完成 排水 停止

因此部署需要5-7分钟,主要是等待运行状况检查或排出。不过,我很肯定ssh启动得很快,而且我在目标组上有以下设置,可以使事情相对快速:

正确端口上的TCP运行状况检查
健康/不健康阈值:2
间隔:10秒
解除注册延迟:10秒
ecs docker stop自定义超时:65s

因此,从ssh到终止旧容器的最短时间为:

2*10=20s,TCP健康检查转为健康
码头停靠前注销延迟10秒
Docker停止超时为65s

这是115秒,比观察到的5-7分钟要短得多。其他服务需要1-3分钟,LB/目标群体的时间安排在那里没有那么激进。

你知道为什么我在NLB后面的服务在这些生命周期转换中的循环很慢吗?

1 回复 | 直到 6 年前

bjcube 6 年前

您在这里没有做错任何事情;这似乎只是本产品的一个(当前)限制。

我最近注意到,在NLB后面的ECS服务的注册/可用性时间也出现了类似的延迟,并决定进行探索。我创建了一个简单的javascript tcp echo服务器,并将其设置为NLB后面的一个ecs服务(ecs服务计数为1)。像你一样,我使用了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秒的间隔。他们确认这种行为是已知的,但没有提供解决问题的时间或降低服务可用性延迟的策略。

不幸的是,这对解决您的问题没有多大帮助,但至少您可以知道您没有做错任何事情。