我在 ELB 后面和 Auto Scaling 组中有两个 EC2 实例。放大政策如下：
CPUUtilization >= 70 持续 300 秒（添加一台服务器）
在进行 Atoscaling 活动时，现有实例上的负载已经达到 99%，并且正在断开连接。
有什么方法可以更有效地处理这个问题？
【问题讨论】：
标签： amazon-web-services autoscaling
Auto Scaling 的诀窍在于定义可以准确识别系统负载的警报。
CPU 利用率并不总是使用正确的衡量标准——您的应用程序可能只能处理有限数量的连接，它可能会占用 RAM，并且请求的类型也可能会有所不同。
一个好主意是在峰值负载期间密切监视您的系统，以确定一个准确的信号来识别繁忙时段（或者更好的是，帮助您预测即将到来的繁忙时段)。在您的各个实例上使用标准监控工具，例如监控可用内存、应用程序用户数、事务数等。
您可以使用常规监控工具，也可以编写将指标推送到 Amazon CloudWatch 的内容，这样您就可以超越 CloudWatch 通常提供的基本 CPU 和网络指标。您甚至可以使用负载均衡器的 延迟 指标在应用程序变慢时触发扩展（需要自定义代码）。
一旦您有可靠的信号来检测系统何时接近容量并需要横向扩展，您就可以专注于缩短添加新容量的时间。测量新实例启动并开始接受流量所需的时间。尝试通过使用完全配置的 AMI 而不是通过用户数据安装软件来减少启动时间。也许您可以删除或关闭实例上的服务以使其启动更快。尝试使用不同的 EBS 卷类型（例如，通用 SSD 可以爆发高达 3000 IOPS）和不同的实例类型。
甚至可能更早地向外扩展（例如 50%）——与改进的用户服务相比，额外费用可能很小。
您的目标应该是确保用户永远不会遇到服务缓慢或连接中断的情况。
【讨论】：
检查您的实例的状态是否正常。如果突然出现压倒性的流量，通常实例/容器实例会进入不健康/耗尽静态。
在这种情况下，设置一个自动扩展策略来检测被丢弃的最小数量的健康实例，并相应地将您的实例扩展至您的最小阈值的至少 50%。例如，一个运行 30 个健康实例的系统突然下降到 25 个，然后自动缩放到额外的 45 个实例，以便它可以处理这个突然的峰值。
稍后随着流量冷却下来，您对 CPU、内存等指标的缩减策略可以将这 45 个实例减少到所需的数量。
【讨论】：