如何检测ECS Fargate任务自动缩放事件及解决缩容时任务未完成被终止问题

一、扩缩容类生命周期事件的检测方法 #

因为Fargate没有EC2 Auto Scaling那种内置的生命周期钩子能力，可以通过以下组合方案拿到和LifeCycleHook等价的事件信号，不需要侵入容器内部逻辑：

• 通过EventBridge内置事件源捕获全链路伸缩信号
  • 配置Application Autoscaling事件源，直接捕获基于SQS队列长度触发的扩缩容决策动作，包括触发阈值、任务数变动值、预计终止的任务范围元数据，事件推送延迟稳定在10s以内
  • 配置ECS事件源，捕获任务状态变更事件，精准区分任务进入STOPPING状态的触发原因：是自动缩容发起、手动操作触发，还是应用自身异常崩溃，直接关联对应任务ID
• 利用Fargate本地元数据端点做本地状态匹配
  • 容器内的应用可定期访问任务自带的本地元数据接口（固定IP段169.254.170.2），拉取当前任务的集群、服务归属、启动时间等元数据，配合上述捕获的伸缩事件做本地匹配，即可精准识别当前任务是否处于待缩容的范围

这套组合方案的事件粒度和时效性，和EC2原生的生命周期钩子能力基本等价，不需要额外搭建旁路系统就能拿到触发信号。

二、缩容时未完成任务被异常终止的落地方案 #

所有方案都严格匹配业务约束：不设置固定的任务处理超时，适配单任务1~10分钟不等的不确定处理时长，从根源避免任务未完成就被强制终止的问题。

• 方案1：SQS动态可见性窗口 + 优雅退出拦截（改造量最小，适配现有架构）
  • 调整SQS消息的可见性逻辑：应用拉取到业务消息后，立刻动态设置该消息的可见性窗口为大于最长处理时长的值（比如最长10分钟就设为11~12分钟），不用在队列层面配置固定的全局可见性超时。就算任务被提前强制终止，正在处理的消息在可见性窗口到期后会自动重新入队，不会出现业务数据丢失
  • 容器内增加SIGTERM信号监听逻辑：Fargate在终止任务前会先给容器发送该信号，应用收到信号后立刻停止从SQS拉取新消息，循环等待当前正在处理的任务执行完成后再主动退出进程
  • 调整ECS服务的stopTimeout参数为略大于最长业务处理时长的值：这个参数的作用是Fargate发送SIGTERM后，给应用留足进程退出的缓冲时间，之后才会发送SIGKILL强制终止，并不是给正在运行的业务任务设置强制超时阈值，完全符合“无法预估任务实际完成时长、不使用任务超时配置”的业务规范
• 方案2：伸缩事件联动主动拦截（缩容效率更高）
  • 把EventBridge捕获到的缩容事件推送到Lambda函数，拿到本次缩容计划终止的所有任务ID列表
  • Lambda针对每个待终止任务，临时调整服务的负载分布，给待终止任务的流量权重降为0，暂停给这类任务分配新的SQS消息拉取权限
  • 等应用完成当前正在处理的业务任务、主动上报“可安全终止”的状态后，再触发正式的任务终止流程，整个等待过程没有固定时长上限，完全匹配任务时长不确定的场景
• 方案3：ECS原生任务保护能力适配（侵入性最低）
  • 应用在开始处理长时长业务任务前，调用ECS原生的任务保护API，给自己所在的任务临时开启缩容保护
  • 自动缩容流程在执行终止动作时，会自动跳过所有开启了保护的任务，等应用完成当前业务处理后，再主动关闭对应任务的保护开关，缩容流程即可正常推进
  • 因为保护的开关是应用根据自身实际任务进度动态设置的，没有固定的超时限制，完全适配单任务处理时长不确定的要求

实操提醒：配置基于SQS队列长度的自动扩缩容时，一定要加足够长的缩容冷却时间（建议15~30分钟），避免因为队列瞬时波动触发频繁缩容，增加不必要的任务终止等待开销

内容的提问来源于stack exchange，提问作者I. Ahmed