AutoScaling 目标追踪伸缩规则概述「建议收藏」

弹性伸缩目标追踪伸缩规则是弹性伸缩服务与云监控深度结合的产物，定义了更加稳定，精准，快速的弹性伸缩策略，解决了当前伸缩组动态调整过程存在的一些难点和问题。

目标追踪伸缩规则

目标追踪伸缩规则是弹性伸缩服务提供的一种新类型的伸缩规则，目标追踪伸缩规则扩展了弹性伸缩服务原有的伸缩规则。在本次扩展中，伸缩规则从原有的伸缩规则扩展为：简单伸缩规则和目标追踪伸缩规则。其中，简单伸缩规则对应于原伸缩规则定义（本文中提到的简单伸缩规则均指原伸缩规则定义的扩展方式）；目标追踪伸缩规则为全新类型的伸缩规则。

背景分析

弹性伸缩服务目前基于简单伸缩规则与云监控服务，为用户提供了伸缩组动态调整的能力，即，用户通过云监控服务监控特定指标值，当满足阈值条件时，则触发指定的伸缩规则。基于简单伸缩规则的动态调整策略为用户带来了极大的灵活性，同时节约了大量成本，使用户真真实现了“按需使用”的目标。但是，该种方式下的动态调整策略仍存在以下问题：

1. 定义模糊。对于大多数使用弹性伸缩动态调整策略的用户来说，关心的核心问题在于是否达到目标监控指标期望值，而基于简单伸缩规则的动态调整策略则将动态调整策略的定义抛给了用户。
2. 调整粒度固定。简单伸缩规则定义了具体的扩缩容动作，其定义不感知监控指标的实际状态，因此用户只能够根据经验来设置一个固定的伸缩规则，其调整过程粒度无法实现动态调整。对于扩缩容过程，这意味着扩缩容过程的精度和效率无法协调。

3. 调整过程缺乏控制。基于简单报警规则的动态调整策略，仅仅是将如何调整和何时调整这两个定义简单组合起来，缺乏有效的控制手段。下面简单介绍两种主要的问题：

   1. 数据抖动。对于新加入伸缩组的实例，其监控数据在短时间内是不可获得或不准确的，因此，实例的加入，将使得整体的监控数据发生较大的抖动，新加入的实例占比越大，这种抖动带来的影响也越大。在该阶段，将可能导致报警事件的触发不符合实际需要。
   2. 连续回调。由于实例数变化带来的监控指标变化通常不是同步的，当实例个数已经发生变化，但监控指标还未相应变化时，仍可能触发报警事件，此时将再次触发伸缩规则，导致响应了延迟数据触发的扩缩容。
4. 震荡问题。当用户期望将监控指标值维持在某区间时，通常是针对同一指标值设置一条扩容规则和一条缩容规则，不合理的设置将可能导致伸缩组实例个数来回震荡。

目标追踪伸缩规则与云监控进行深度结合，重新定义了伸缩组动态调整过程。具体表现在以下几点：

1. 将如何扩容和何时扩容两者定义整合到一起，将用户关心的监控指标值暴露给用户，用户只需要关注监控指标的目标值。
2. 快速、精准、动态的扩缩容。目标追踪伸缩规则增加了对监控数据的感知能力，根据历史的监控数据值和期望目标值计算出所需要的扩缩容实例数，使用尽量少的调整过程趋近监控指标目标值。
3. 实例预热。新实例加入伸缩组后，将首先进入实例预热阶段，在该阶段，不会向云监控上报其监控数据，也不作为扩缩容过程的基数实例。预热阶段能够有效防止增加过多的实例。
4. 动态稳定区间。根据伸缩组的历史监控数据计算目标值稳定的区间。

支持的监控项

在使用目标追踪伸缩规则时，对可选的监控指标有一定限制，指标需要能够正确反映伸缩组内机器整体的繁忙程度，并且指标值需要满足根据伸缩组内实例数量的变化而相应的增加或减少，满足上述条件的监控指标适合应用于目标追踪伸缩规则。例如：cpu平均使用率指标能够有效的反映实例的繁忙程度，并且与实例的数量变化具有明显的线性关系；相反，cpu平均负载则不能准确的反映实例的繁忙程度，当机器上存在大量io等待时，可能出现高负载低使用率的情况，这种情况下，通常不是机器过于繁忙，而应该考虑能否优化应用结构。

目前目标追踪伸缩规则支持的监控指标如下：

注意事项

• 目标追踪规则假设在指标值高于目标值时进行扩展操作，不支持在指标低于目标值时进行扩展操作。
• 目标追踪规则将为您创建2条云监控报警规则，分别用于扩容过程和缩容过程，我们采用了相对激进的扩容策略和相对保守的缩容策略。伸缩组扩容报警规则采样间隔为60s，连续3分钟满足阈值条件则进行扩容，缩容报警规则采样间隔为60s，连续15分钟满足阈值条件则进行缩容。
• 当计算得到的调整实例个数为小数时，对于扩容过程，采取向上取整；对于缩容过程，采取向下取整。例如，当需要增加实例个数为1.5时，实际将增加2个实例；当需要缩容的实例个数为-1.5时，实际将减少1个实例。
• 当监控数据指标不足时，将不会触发扩/缩容操作。
• 当报警规则发生报警时，将触发对应的扩缩容操作，弹性伸缩将根据监控指标的历史数据计算扩缩容过程的实例个数。对于扩容过程，计算所得的扩容数量采取向上取整，避免扩容的机器不足；对于缩容过程，计算所得的扩容数量采取向下取整，避免释放过多的实例数量。
• 监控指标值可能与目标值存在较大的差距，这种情况通常发生在组内实例个数较少的情况下，此时，组内实例数量的变化，对伸缩组聚合指标值具有较大的影响。例如，您可能会遇到作用于缩容过程的报警规则一直处于报警状态，却没有缩容活动发生的情况。这种情况主要是由于缩容过程计算得到的缩容实例数量少于一个，因此不会产生实际的伸缩活动。
• 请勿编辑或删除为目标追踪伸缩规则创建的报警规则。任何修改都将导致拒绝执行对应的扩/缩容活动，当您删除伸缩规则时，相应的报警规则会自动删除。

禁用缩容

目标追踪伸缩规则支持禁用缩容，通过指定disableScaleIn参数为true，便可禁用缩容过程，禁用缩容操作将不会创建或者删除作用于缩容过程的报警规则。通过该功能，您可以使用其他方式控制伸缩组的缩容过程，例如，您可以通过报警规则监控其他指标，触发一条简单的伸缩规则用于缩容。

实例预热

新的实例加入伸缩组之后，通常需要经历业务部署，slb健康检查，数据采集等过程，才能上报稳定的监控数据，不适合在此基础上触发新的伸缩活动。为了限制扩/缩容过程执行的频率，我们通常建议对伸缩规则设置合适的冷却时间，在冷却期内，将拒绝执行伸缩规则。对于目标追踪伸缩规则，我们引入了全新的实例预热过程，下面我们将详细介绍实例预热过程。

注意：只有目标追踪规则创建出来的实例才拥有实例预热阶段。

实例在预热阶段时具有以下行为：

1. 实例将正常加入伸缩组，但是实例不会开始向云监控上报数据，云监控在聚合伸缩组维度监控指标时忽略预热实例，不将预热实例作为伸缩组内实例。
2. 实例预热结束后，将开始向云监控上报数据，云监控此时将其作为伸缩组内实例。
3. 扩容过程中，预热实例不会做为扩容基数。例如，当前组内实例数量为c,伸缩组触发扩容活动，添加5个实例到伸缩组，预热时间设置为300s，在实例预热期间，再次触发扩容活动，仍按照数量c作为扩容基数。假设本次需要扩容的实例数量为6，那么实际上只需要再生产的实例数量为1，使得预热实例数达到6个。这可确保添加的实例不会超出您的需要。
4. 缩容过程中，对于缩容过程，将自动根据历史执行情况，设置合适的冷却时间，方式由于数据延迟引发的连续缩容事件导致实例过多释放。

我们建议您根据实际的业务需要设置合适的实例预热时间，这可帮助目标追踪伸缩策略更高效，更准确的接近您所设置的目标值。

最佳实践

使用SDK创建目标追踪伸缩规则

这里我们主要展示如何使用java SDK创建伸缩规则，并采用maven进行依赖管理。创建目标追踪伸缩规则，需要使用aliyun-java-sdk-ess 2.2.9及以上版本。

程序所需的maven依赖如下：

        <dependency>
            <groupId>com.aliyun</groupId>
            <artifactId>aliyun-java-sdk-core</artifactId>
            <version>3.0.8</version>
        </dependency>
        <dependency>
            <groupId>com.aliyun</groupId>
            <artifactId>aliyun-java-sdk-ess</artifactId>
            <version>2.3.1-SNAPSHOT</version>
        </dependency>

创建目标追踪伸缩规则

        CreateScalingRuleRequest request = new CreateScalingRuleRequest();
        request.setScalingGroupId(scalingGroupId);
        request.setScalingRuleType("TargetTrackingScalingRule");
        request.setTargetValue(targetValue);
        request.setMetricName(metricName);
        request.setDisableScaleIn(disableScaleIn);
        request.setEstimatedInstanceWarmup(estimateWarmupTime);
        CreateScalingRuleResponse response = client.getAcsResponse(request);

控制台操作介绍

请参考 Auto Scaling 支持目标追踪伸缩规则。