在网络负载均衡器+目标组后面运行SSH的AWS服务使用CodeDeploy缓慢部署
我有一个为SSH进程服务的ECS服务。我正在通过CodeDeploy部署对此服务的更新。我注意到，与使用CodePipeline同时部署相同映像的其他服务相比，该服务的部署速度要慢得多。这种服务的不同之处在于它在北草坪会议大楼后面(其他服务不是LB或ALB后面)。
服务被设置为一个容器，部署200%/100%，这样服务就会产生一个新的容器，确保它是健康的，然后删除旧的容器。我看到的是：
- 新容器以
Initial状态启动 - 3+几分钟后，新容器变成了
Healthy。旧集装箱进入Draining - 2+几分钟后，旧容器完成
Draining并停止
因此，部署需要5-7分钟，主要是等待健康检查或排水。但是，我非常确定SSH启动得非常快，并且我在目标组上有以下设置，这些设置应该会使事情变得比较快：
- 正确端口上的TCP健康检查
- 健康/不健康阈值:2
- 间隔: 10s
- 销毁延迟: 10s
- ECS码头停止自定义超时:65
因此，从SSH到旧容器终止的最短时间是：
- 用于TCP健康检查的2*10=20s转到健康
- 码头停工前延迟注销登记的10s
- 65秒用于码头停工超时
现在是115秒，这比观察到的5-7分钟要少得多.其他服务需要1-3分钟，而LB/目标组的时间在那里几乎没有那么有侵略性。
你知道为什么我在北草坪会议大楼后面的服务在这些生命周期转换中似乎很慢吗？
回答 1
Stack Overflow用户
发布于 2019-02-16 17:27:17
您在这里没有做错任何事情；这似乎只是该产品的一个(当前)限制。
最近，我注意到ECS服务在北草坪会议大楼后面的注册/可用时间也出现了类似的延迟，并决定探索。我创建了一个简单的Javascript TCP回送服务器，并将其设置为北草坪会议大楼后面的ECS服务(ECS服务计数为1)。与您一样，我使用了TCP健康检查，其健康/不健康阈值为2，间隔/注销注册延迟为10秒。
在初始部署成功并且服务可以通过北草坪会议大楼到达之后，我想知道在基础实例完全失败时恢复服务需要多长时间。为了模拟，我通过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后面的一个简单的快递应用程序进行了同样的测试，ECS启动服务和ALB报告健康之间的差距是10-15秒。我们测试北草坪会议大楼的最佳结果是从服务停止到完全可用的3.5分钟。
我通过支持案例与AWS分享了这些发现，特别要求澄清为什么在北草坪会议大楼开始健康检查服务之前有一个持续的120秒间隔，以及为什么我们总是看到从健康检查开始到服务可用性之间的90到120秒。他们证实，这种行为是已知的，但没有提供解决问题的时间或减少服务可用性延迟的策略。
不幸的是，这无助于解决你的问题，但至少你知道你没有做错什么。
https://stackoverflow.com/questions/54230124
复制相似问题
腾讯云开发者
