01 背景
弹性是云原生、Serverless 的基础。AutoMQ 从软件设计之初即考虑将弹性作为产品的核心特质。对于 Apache Kafka 而言，由于其存储架构诞生于 IDC 时代，针对物理硬件设计，存储层强依赖本地存储，已不能很好地适应现在云的时代了。当然，这并不意味着我们要放弃 Kafka。Kafka 凭借极其优异的生态已经塑造了其在流处理领域不可撼动的地位，Kafka API 俨然已经成为流处理协议的事实标准。正是因为看到了这一点，AutoMQ 积极拥抱 Kafka 生态，在完全兼容其计算层的基础上，对底层存储做了云原生的改造，充分兑现云的规模化成本、技术红利。
AutoMQ 利用对象存储、云盘构建了一个拥有极速弹性能力的内核底座，使得我们在云上实现自动弹性（下文均称 Autoscaling）成为可能。本文将介绍 AutoMQ 是如何在云上实现 Autoscaling 的，并且分享我们在实践过程中的经验与教训。
02 什么是 AutoMQ 追求的 Autoscaling
对于流处理系统来说，Autoscaling 的关键在于其可以动态调整其容量来满足不同的写入工作负载。当写入流量变多时，集群可以快速扩容拓展集群性能用于承载突增的流量；当写入流量变少甚至为零时，集群可以缩小规模，减少资源开销，甚至做到 scale to zero 的目标，没有任何资源的使用。
我们认为，具备最佳 Autoscaling 能力的产品一定是具备如下特质的：
ꔷ 构建于公有云上或者具备一定规模的私有云上：云的本质是资源的整合和复用带来的技术、成本红利。在这一点上具备最大使用规模的公有云一定是最有优势的。自动弹性的价值在于当你不再使用某一项资源时，你可以尽快释放它，从而避免额外的成本开销；而当你重新需要资源时，通过资源池的预留资源你可以以最快的速度获取到所需的资源。在这一点上来说，公有云的大规模则最具优势。虽然私有云也可以做到类似的效果，但是同样预留 10\%的限制资源，在私有云环境可能是 100 台机器，在 aws 上可能是 10000 台机器，大家弹性的上限是不同的。
Tips: 当前以及未来一定仍然会有一些场景需要在非云环境上进行部署。但是按照近年来的趋势，例如 Kubernetes 的兴起，我们可以预见的是，私有环境的技术底座未来和公有云是趋同的。在私有环境也可以提供类似云盘（openebs）、对象存储（minio）这样的能力。
ꔷ 可以充分发挥云服务的能力：AutoMQ 的核心理念是充分利用云上成熟、具备规模优势和技术红利的云服务来构筑自身领先的产品力。对于弹性方面，我们对多云经过了充分的调研，观察到计算实例的弹性伸缩组（或称节点组）已经成为一项标准功能。因此，AutoMQ 在实现自动弹性时充分利用了云端弹性伸缩组服务，以帮助实现快速部署生产级弹性能力。
Tips: 由于弹性伸缩组包括其配套的弹性能力在各个云上都是趋同的，下文即直接以 AWS 的云服务为例来阐述。
从技术指标上来说，AutoMQ 追求的 Autoscaling 一定是：
ꔷ 弹得快：这里弹得快，我们主要是指的扩容。对于生产级系统来说，我们往往遵循“快弹慢缩”的最佳实践来保证整个弹性伸缩对业务是无感的。 从 AutoMQ 集群开始接收突增的写入流量开始到集群完成扩容，并且最终写入吞吐流量提升到目标吞吐值的耗时越短，则我们认为弹得越快。
ꔷ 弹得准：弹得准主要包含两层含义。一层含义是容量的调整需要尽快稳定在目标容量，而不要因为一些弹性策略的设置导致一些容量抖动。另外一层含义是弹的目标容量要尽量接近实际的需求，不要多弹或者少弹。多弹过多的容量会造成资源浪费，少弹容量则会影响消息端到端的延迟。
ꔷ 弹得省：自动弹性主要依赖监控信息来确定何时进行扩容或者缩容。存储、管理和应用 metric 都会产生一些额外的成本。
03 Autoscaling 技术架构
由于充分利用了云的能力，AutoMQ 完成自动弹性的架构变得十分的简单。主要涉及如下组件：
ꔷ Auto Scaling Group （缩写为 ASG）: AWS 提供的弹性伸缩组可以将一组 EC2 计算实例作为一个逻辑分组。以计算实例组为单位进行容量管理，并且提供了配套的机器监控、弹性、生命周期钩子等能力。该服务在各个云上均是免费使用的能力。
ꔷ Cloud Watch: AWS 云监控，可以配置监控与报警，用于触发 ASG 的容量调整。AWS 对 EC2 提供了免费的机器监控（粒度为 5 分钟）。在一些弹性速度要求低的场景，可以充分利用云厂商提供的这种免费能力来降低成本。
ꔷ AutoMQ Control Panel: AutoMQ 的控制面，负责与云的 API 进行交互，创建 ASG 弹性策略以及将 Cloud Watch 中的报警模块关联 ASG 的弹性策略。这样可以保证满足报警阈值时，可以触发 ASG 容量的调整。对于 ASG 来说，只要将弹性策略和对应的 metric 阈值关联好，满足阈值后的容量调整是自动进行的。
04 云上 Autoscaling 的挑战
4.1 理解云提供的不同弹性策略的特征以及组合效果
云厂商基本都提供了几种标准化的弹性策略，通过利用这些现成的弹性策略 AutoMQ 可以快速构建起自身的 Autoscaling 能力。然而，在我们的实践过程中我们发现事情并没有那么简单。如果对云提供的这些弹性策略没有一个充分的理解的话，会导致一些弹性策略的错误使用，并且无法达到预期的效果。
下面分享下 AutoMQ 对 AWS ASG 提供的几种弹性策略（其他云也是近似的）应用的心得。
4.1.1 简单策略
简单策略[1]是基于 metric 来报警触发的。报警触发时可以选择的行为包括扩、缩 x 台计算实例。其优点是简单，缺点是不能精细化控制针对不同的情况，动态设置不同的步长，不太灵活。此外，值得注意的是，简单扩缩在扩缩活动开始后，该策略必须等待扩缩活动或运行状况检查替换完成并且冷却时间到期，然后才会响应其他警报。冷却时间有助于防止在先前活动产生明显影响前启动其他扩展活动。
弹性策略的步长（step）: 当弹性策略被满足，触发容量调整需要扩或者缩 x 台实例时，x 的大小即为步长。
冷却时间（cooldown）: 在上一个扩缩容行为完成后需要等待的时间即为冷却时间。主要是为了预留时间让应用在机器扩缩容后进入稳态，才继续容量调整，使得扩缩容对应用来说感知更少，变化更加平滑。
4.1.2 步进策略
步进策略[1]可以理解成简单策略的优化版本。可以允许不同档位的监控阈值来配置不同的步长。例如，如果 CPU 使用率 75%-85%之间，增加 2 个实例；如果在 85%-95%之间，增加 3 个实例；如果超过 95%，增加 4 个实例。相比简单策略，可以有更加精细化的容量控制，从而避免容量弹多或者弹少。
4.1.3 目标跟踪策略
一般而言，我们是希望负载能够将容量充分利用以避免资源浪费。目标跟踪策略[2]的实现方式就是设置一个目标值，例如 CPU 使用率，然后由 AWS 自己去调节增加、减少机器，扩缩的步长可以自己的定义。那么到底怎样才算维持在目标值附近呢？AWS 默认采用的是容量优先的策略。例如，假设您将 CPU 使用率的目标值设置为 50%，然后 Auto Scaling 组超过了该目标。我们可以确定，添加 1.5 个实例会将 CPU 使用率降低到接近 50%。由于不可能添加 1.5 个实例，我们将该值向上取整，添加两个实例。这可能会将 CPU 使用率降至 50% 以下，但可确保应用程序具有充足的支持资源。同样，如果我们确定删除 1.5 个实例可使 CPU 使用率提高到 50% 以上，我们将只删除一个实例。
AutoMQ 最早实践目标跟踪策略时，实际是希望其可以动态调整步长，更快、更准的帮助我们弹到目标容量。但是实际应用中发现，其效果根本没有那么智能。自己通过组合简单策略反而可以实现比目标跟踪策略有更好的灵活性。例如，目标跟踪策略不允许你自定义扩缩容的步长调整。
4.1.4 预测试扩展
适用于周期性负载（至少需要 24 小时数据），AWS 自己会用机器学习去尽量拟合负载。可以配合其他扩展策略一起执行。AutoMQ 一开始就没有尝试该弹性策略。一方面，AutoMQ 作为通用的流处理系统，不仅仅会应用在周期性负载的场景，二来我们也没法预测用户到底会采用怎样的工作负载。
4.1.5 计划扩展
本质就是定时扩展，可以设置定时任务设置容量，适合大促这类对目标容量有明确感知的场景。
4.1.6 多个弹性策略冲突时如何工作
不同云厂商之间弹性策略冲突时的处理方式不同，正确使用弹性策略需要充分理解弹性策略冲突时的表现。例如阿里云上弹性策略冲突时候会叠加两个弹性策略执行最终的结果。例如一个弹性策略需要扩容4台，另外一个需要缩容2台则最终结果为扩容2台。而 AWS 提供的弹性策略则主要是优先保证容量从而保证可用性。当多个弹性策略冲突时候，云会优先选择执行后具有更大容量的弹性策略。
4.2 寻找触发弹性执行的金指标
弹性策略只是一个执行的逻辑计划。何时触发弹性策略的执行是实践中的重要挑战。弹性策略执行的触发条件是基于监控数据来触发的。寻找一个触发弹性的金指标是自动弹性弹得准的关键。然而实际生产应用中，部署机型、工作负载等都会影响到金指标的选择。
理想情况下，我们希望应用内核可以提供一个金指标。任何外部环境的瓶颈例如 CPU Load 过高、网络流量瓶颈等最终都可以反应到这个唯一金指标。可惜的是， Kafka 本身在内核侧并没有提供这样的一个指标。当前 AutoMQ 提供的自动弹性默认是根据网络流量来确定触发的时机的。根据我们的判断，弹性金指标必然不是一个单一指标，而是一个组合多个因子和权重的综合指标。包含的关键因子可以包括 broker 机器的网络上下行流量、CPU 使用率、内存使用率、磁盘 IOPS 和带宽等。在不同负载和硬件环境下，这些因子的权重也会有所不同。未来理想的情况是 AutoMQ 提供一个默认的多因子指标来指导弹性的触发，用户同时可以自定义参与组合指标的因子及其权重。
4.3 AutoMQ 最终应用的弹性策略
4.3.1 定时弹性
AutoMQ 实际采用的弹性策略本质是一个基于简单策略自己实现的目标跟踪策略再配合一个可选的定时弹性策略。默认的目标跟踪策略的扩缩行为为了保证平滑地执行弹性和避免资源过于浪费，没有设置采用很大的步长。但是，实际很多业务场景例如电商大促或者外卖行业在特定时段都会有突增的流量，这个仅仅依靠默认的弹性策略来扩是来不及扩容的。因此提供可选的定时弹性策略对于弹性的生产应用是十分重要的。定时弹性，本质是人提前做了容量规划，属于一种启发式弹性，当流量峰值过去以后，集群又会自动缩容到指定容量。定时弹性策略利用云底座提供的能力基于 cron 表达式配置定时执行的时间并且配置目标容量信息即可。例如下图的定时弹性策略比较符合餐饮行业，每天上午 11 点时执行扩容，扩容到指定容量 20；当下午 2 点时再重新缩容会一个较小的目标容量。
4.3.2 自定义目标跟踪策略
AutoMQ 基于简单策略实现了自定义的目标跟踪策略。该策略当前默认使用的是基于网络流量来触发弹性的执行的，在通用场景下可以满足绝大部分要求。相比云默认提供的目标跟踪策略具备更好的灵活性，可以做快扩慢缩，在实际生产应用中具有更加稳健的弹性效果。自定义目标跟踪策略主要由一个负责扩的简单弹性策略和一个负责缩的简单弹性策略构成。自定目标跟踪策略中，针对扩、缩的步长我们采用了按比例的调整，这样可以保证在不同集群规模下都有相同的扩缩容效率。在 AWS 上 ASG 上展现的弹性策略内容如下。
由于大部分云都有提供这种默认机器指标的采集，AutoMQ 默认的弹性策略不需要自己采集和管理这些 metric 指标。我们可以最大化利用这些云的能力来降低我们自身实现的复杂度。首先定义下弹性策略中参与表达式计算的变量：
ꔷ network-in byts（nin）: 每个 metric 上报间隔内累计的网络流入字节数；
ꔷ network-in bytes per second（nins）: aws 计算每秒字节数可以用表达式 nins=nin/DIFF_TIME（nin）来得到每秒网络流入字节数；
ꔷ network-out（nout）: 每个 metric 上报间隔内累计的网络流出字节数；
ꔷ network-out bytes per seconds（nouts）:aws 计算每秒字节数可以用表达式 nouts=nin/DIFF_TIME（nout）来得到每秒网络流出字节数；
ꔷ active instance count in asg（acount）: asg 中活跃的实例数，因为 aws 默认采集的是 group 合计的指标，计算单台 broker 的流量时需要除一下 asg 内 broker 机器的个数；
ꔷ upper: 扩容网络流量阈值，默认值为机型网络带宽上限的 80%，用户也可以自定义该值；
ꔷ lower: 缩容网络流量阈值，默认值为机型网络带宽下限的 50%，用户也可以自定义该值；
负责扩容的简单弹性策略公式如下，该公式含义表示：入或者出的 broker 平均网络流量较大值超过设定的平均网络带宽时，则按照我们设定的步长（默认为扩容当前容量的 10%，且至少为 1 台）来进行扩容。这里值得注意的是，云厂商提供的计算实例，假设网络带宽是 100MB/s，意味着其入和出分别为 100MB/s。
max(nins/acount,nouts/acount) > upper
负责缩容的简单弹性策略公式为如下，该公式含义表示：同时满足以下三个条件时才进行缩容：
ꔷ 当前存活的 broker 数至少为 1，不允许缩至 0 台
ꔷ 入或出的 broker 平均网络流量较大值低于设定的阈值下限时才允许缩容
ꔷ 第三部分计算的实际就是假设当前 broker 数量减少 1 台，然后按照扩容的公式去计算值，需要确保其小于我们设定的阈值 upper。
这种方式主要是为了避免小规模集群时候缩容一台以后马上扩容的行为出现。在小规模集群上，这种频繁的扩缩容对集群的影响就会比较大。
acount>1 ( max(nins/acount,nouts/acount) < lower ) && ( max(nins/acount-1,nouts/acount-1) < upper )
05 自动弹性效果展示
下图展示了 AutoMQ 在一个流量有变化的负载下，集群规模和集群网络流量的变化关系，可以看到 Broker 数量很好的拟合了流量曲线的变化，达到了自动弹性的效果。对于经常有变化的负载，开启自动弹性可以大大节约成本，达到 pay-as-you-go 的效果。关于具体的实验测试，可以参考我们的成本报告[4]。
06 展望 AutoMQ Autoscaling 的未来
当前提供的自动弹性能力仍然有很多值得优化的地方，他们包括：
ꔷ 更加有效的弹性策略触发金指标：提供用于弹性策略的默认组合指标及其配套的产品化能力。默认的组合指标可以使得默认弹性策略可以去适配更多的场景。提供产品化能力则可以让用户根据自己的场景灵活调整指标的构成和权重，从而带来更加精准的弹性效果。
ꔷ 多云自动弹性的适配：当前我们仍然有一些云平台尚未支持自动弹性。不同云厂商提供的云监控、报警以及机器监控自动采集能力上会存在差异。让自动弹性能力适配更多的云有利于我们构建多云一致的自动弹性能力。
ꔷ 自定义监控采集和发布：在我们实践过程中发现不同云厂商提供的云监控提供的能力和 SLA 都有所不同。在一些比较严苛的场景，云厂商默认提供的监控采集与发布可能是不够的。例如 AWS 默认机器监控的最小粒度为 1 分钟。如果需要更加极速的弹性，提供一种 AutoMQ 自行采集和上报监控数据的模式也是有必要的。一方面可以使用更加灵活可控的监控数据，另外一方面也可以在监控指标的采集、存储上持续优化降低这块基础设施的成本。
ꔷ K8S 上自动弹性：关于 k8s，我们初期其实已经使用 AutoScaler [5]做过了一些探索。k8s 作为当前云原生领域的重要力量，具有大量的用户基础。AutoMQ 也会及时跟进，让大家在 k8s 上一样可以使用到 AutoMQ 自动弹性的能力。
