在网络负载均衡器 + 目标组后面运行 SSH 的 AWS ECS 服务使用 CodeDeploy 部署缓慢

Posted 2023-03-10

【中文标题】在网络负载均衡器 + 目标组后面运行 SSH 的 AWS ECS 服务使用 CodeDeploy 部署缓慢

【英文标题】：AWS ECS service running SSH behind Network Load Balancer + Target Group slow to deploy with CodeDeploy

【发布时间】：2019-06-11 07:27:20

【问题描述】：

我有一个服务于 SSH 进程的 ECS 服务。我正在通过 CodeDeploy 为该服务部署更新。我注意到，与使用 CodePipeline 同时部署相同图像的其他服务相比，该服务的部署速度要慢得多。该服务的不同之处在于它在 NLB 之后（其他的不是 LB 或在 ALB 之后）。

服务设置为 1 个容器，部署 200%/100%，因此服务会启动 1 个新容器，确保它是健康的，然后删除旧容器。我看到的是：

新容器以Initial 状态启动 3 分钟后，新容器变为Healthy。旧货柜进入Draining 2 多分钟后，Old Container 完成 Draining 并停止

因此部署需要 5-7 分钟，主要是等待运行状况检查或耗尽。但是，我很确定 SSH 启动得非常快，并且我在目标组上进行了以下设置，这应该会使事情变得相对快速：

正确端口上的 TCP 健康检查 健康/不健康阈值：2 间隔：10s 注销延迟：10s ECS Docker 停止自定义超时：65s

所以从 SSH 到旧容器被终止的最短时间是：

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

这是 115 秒，比观察到的 5-7 分钟要少很多。其他服务需要 1-3 分钟，而 LB/Target Group 的时间安排没有那么激进。

任何想法为什么我的 NLB 背后的服务似乎在这些生命周期转换中循环缓慢？

【参考方案1】：

你在这里没有做错任何事；这似乎只是该产品的（当前）限制。

我最近注意到 NLB 背后的 ECS 服务在注册/可用时间方面存在类似的延迟，因此决定进行探索。我创建了一个简单的 javascript TCP 回显服务器并将其设置为 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 秒.他们确认这种行为是已知的，但没有提供解决时间或减少服务可用性延迟的策略。

很遗憾，这无助于解决您的问题，但至少您可以知道自己没有做错任何事情。

【讨论】：

感谢您确认我没有遗漏任何内容。花了这么长时间令人失望，但至少它得到了证实。

我看到了同样的问题，在第一次运行状况检查进入之前，替换任务在目标组状态“初始”中闲置了 120 秒。除了这个 SO 问题，似乎为零网上有关这方面的信息。您有没有 @bjcube 或 eric-m-johnson 从 AWS 那里听到有关它的任何更新，或者找到任何缓解它的方法？

AWS 继续不提供解决方案的预计到达时间，也没有提供解决该问题的建议。除了尽量减少 NLB 的使用之外，我在这里没有找到任何解决方案。