每次面对配置系统应如何扩展和扩展的任务时，我们都会决定哪种指标和策略将更有效。 我已经描述了 基于CPU的策略 以及它们可能面临的挑战。 但是，如果这不是一个选择，即该服务由几年前编写的旧应用程序表示，没有很好的文档记录等，而我们仍然想在Cloud中运行并自动扩展，该怎么办？
没有好的或坏的政策。 执行某些功能是有效的，还是无效的，并且适用性的水平可能会根据应用程序必须处理的负载，负载的性质（稳定，线性变化，周期性变化，随机），更改此负载的动态因素而有所不同，可靠性，提供所需的可用性，自动恢复功能以及其他功能。
通常的方法是使用基于CPU的指标。 对于存在大量并发客户端请求的高可用性应用程序，此指标可能无法有效反映实际负载，因为CPU利用率与请求/用户数量之间的关系可能是非线性的。 仍然可以使用基于CPU的自动缩放策略，基于并发的策略可能会使您的资源使用更加有效。
对于基于CPU的指标，最糟糕的情况是，由于某种原因，在负载实例下，如果CPU使用率仍处于正常水平，则无法响应运行状况检查。 在这种情况下，只要实例不响应运行状况检查，自动伸缩组就会从该组中删除该实例并终止该实例。 这将极大地影响已经承受巨大负载的系统。 为了处理这种情况，我们可以使用基于并发的指标。
在这里，您可以阅读有关基于并发的指标如何更有效的更多信息： 如何使用新的AWS ELB网络负载均衡器来赔钱
在谈论基于并发的度量标准时，经常会提到ActiveConnectionCount度量标准。 该指标仍然存在一个问题，使其不适用于自动缩放。 ActiveConnectionCount表示到负载均衡器的连接数，但未考虑目标实例的数量。 例如，您有一个“目标”策略跟踪“活动连接”计数到50个连接和5个实例正在运行。 在负载增加并且ActiveConnectionCount等于100个连接之后，Autoscaling组将添加更多实例。
假设横向扩展后有10个实例，仍然有100个连接。 如果负载是短暂的高峰，则此策略将有助于整理请求并缩小规模。 但是，如果增加的负载不是短期事件，该怎么办？ 并且假设1个实例能够处理10个连接，那么每100个连接中有10个实例就可以了。 但是就您的策略将尝试保持50个活动连接而言，它将再次扩展。 因此，在某些时候，您将最终获得策略实例运行数量所允许的最大值。
如果您的负载稳定且峰值持续时间不长，ActiveConnectionCount很有用。 如果要处理的情况是连接数可能稳定增长到正常数量的4倍，然后在几个小时后降低到正常水平-ActiveConnectionCount不是最佳选择。
所以我们想要的是每个目标的ActiveConnectionCount，而RequestPerTarget是一个非常类似于它的指标。 在大多数情况下，它使我们可以进行横向扩展和横向扩展。
现在回到一种情况，即一个实例由于负载过大而无法对运行状况检查做出响应，这恰好是在一段时间内仍将其视为现有目标，因此在峰值为正常值4倍的情况下，您可能有几个实例没有做出回应，但没有进行任何扩展来主动应对这种情况。
因此，RequestPerTarget是解决负载不断增加和下降的一个很好的指标。 至于尖峰，反应可能会有点慢，结果可能导致不必要的停机时间和错误。 您可以看到比较RequestPerTarget和HealthyHost指标。
因此，不仅要有每个目标的请求（某些目标可能会过载），还要有每个正常目标的请求或连接，这样会很有帮助，因此您可以主动指示某些实例过载并且很可能被自动伸缩组删除的情况。
在这种情况下，您可以创建一个策略来添加多个实例，并迅速减少负载，并弥补不正常实例的丢失（如果发生）。
资料来源：
先前发布在 https://georgiy.dev/aws-autoscaling-2.html
From: https://hackernoon.com/situation-when-concurrency-based-autoscaling-may-be-useful-mye83yp3