2

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

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

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

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

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

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

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

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

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

4

1 回答 1

4

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

我最近注意到 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 秒。他们确认这种行为是已知的，但没有提供解决时间或减少服务可用性延迟的策略。

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

于 2019-02-16T17:27:17.340 回答