AWS步骤扩展可添加比配置更多的任务

问题描述

我正在尝试通过添加逐步扩展策略来扩展ECS任务的数量。当跨步阈值策略超过阈值时,将在队列参数NumberNumberOfMessagesVisible上触发它。

缩放策略定义如下

scale-up-task-on-queue: ApproximateNumberOfMessagesVisible > 10
Policy type: Step scaling
For alarm: some-alarm-name
Take the action:
Add 2 tasks when 10 < ApproximateNumberOfMessagesVisible < 15
Add 2 tasks when 15 <= ApproximateNumberOfMessagesVisible < 20
Add 2 tasks when 20 <= ApproximateNumberOfMessagesVisible 

我从1个任务开始,我在队列中张贴了大约60条-70条消息以触发警报。我理想地期望它具有1 + 2 + 2 + 2 = 7个任务计数,但是我看到任务计数上升到15-16。可能会发生什么?

解决方法

几件事。

  1. 它不会触发所有3个步骤并添加6。它将根据度量值选择一个步骤。因此,如果指标值是60,它将执行+2(因为这是为“ 20

  2. 正如@Marcin在评论中提到的那样,警报将在保持警报状态的每一分钟继续触发缩放策略。因此,一旦冷却时间结束,策略将继续增加任务计数,直到警报不再处于警报状态或达到最大大小为止。增加冷却时间或确保您的任务将SQS消息设置为从队列中删除时不可见,这将对此有所帮助。我可以想到的一个问题是,冷却时间将应用于整个ECS服务,因此也有可能阻止CPU扩展策略添加任务。

将度量标准值分开设置可能会有所帮助。这样,如果第一步被触发,并且您将其设置为+1,它将添加1个任务。然后,如果紧接着有更多消息进入第二步(配置为+2),它将仅添加1个任务(因为冷却时间仍然有1个)。 https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-step-scaling-policies.html

相关问答

依赖报错 idea导入项目后依赖报错,解决方案:https://blog....
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下...
错误1:gradle项目控制台输出为乱码 # 解决方案:https://bl...
错误还原:在查询的过程中,传入的workType为0时,该条件不起...
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct...