AWS 弹性伸缩特性介绍

01 什么是弹性伸缩组
随着云计算技术的不停发展与云原生理念的深入民气，更加多种多样的底子部署模式层出不穷。弹性伸缩组作为一个相对较为“传统”的云技术概念，大概还是有不少同学有些陌生。本日我就以云计算鼻祖 AWS 的弹性伸缩组为例，谈一谈这个伴随着云计算发展的底子产品。弹性伸缩组是 Iaas 底子办法发展晚期被提出的一类云产品，信任各人对于 k8s 都会有所了解，基于容器的弹性扩缩容方案不是一个希奇的概念。弹性伸缩组我们可以明确为是基于云假造机的办理动态扩缩容需求的产品。AWS 于 2006 年 8 月推出了 EC2 产品，由于动态扩缩容是天然存在的底子需求，于是从 2008 年 4 月开始，各类三方弹性伸缩软件出现，包罗 Scalr 和 RightScale。2009 年 5 月 18 日，AWS 推出了本身的弹性伸缩功能[1]。总结一下，弹性伸缩组重要的目的是为了办理多变的流量需求而诞生的产品，核心概念可以分解为两个部门：“弹性伸缩”与“组”。
02 弹性伸缩组都有什么功能
围绕“弹性伸缩”与“组”，我们可以将弹性伸缩组的重要功能拆分为两个重要部门：
节点管理
弹性伸缩组管理的核心资源还是我们的计算节点，所以本质上弹性伸缩组一个节点组，管理了一组同构或异构的节点，把节点管理好天然是这个产品的底子能力。围绕节点管理 AWS 定义了几个底子概念：

• 启动模板
  

为了应对机动的扩缩容需求，必须必要支持快捷的节点新增与销毁；同时被归纳到一个组内，节点一定存在着或多或少的共性。这时一个能快捷创建节点的模板是一个最好的选择。AWS 的启动模板支持设置大部门的 EC2 参数属性，为伸缩组提供了一个底子性的属性模板。

• 期望，最大，最小数量
  

当手动举行节点容量管理时，用户可以设置一个期望的节点数量，来控制节点的数量。当实际的节点数量不即是期望数量时，弹性伸缩组会主动举行节点的创建与接纳，来匹配期望数量。当利用主动弹性计谋时，本质也是通过修改期望数量来达到控制扩缩的效果。而最大、最小数量则可以明确为一个约束值，来限定期望数量的范围，防止出现集群水位过低或服务器成本过高的题目。

• 康健检查
  对于期望数量的修正的条件是节点处于『康健』状态，对于『不康健』的节点，弹性伸缩组会对其举行置换，以包管组内的节点均处于康健状态，能够正常提供服务。识别节点是否处于康健状态，大要上可以分为两类方法：
  ◦ 当设置负载均衡器时，会通过负载均衡器的康健检查来判断节点的康健状态
  ◦ 可以通过 API 手动设置节点的康健状态，往往适配于自定义康健检查逻辑
  
• 机型管理计谋
  

一个高可用的集群往往必要若干个可用区的服务节点，但由于在差异可用区往往存在着库存与机型的差异，我们很难预先设置一种机型适配所有的可用区，这时我们必要更加智能的计谋来管理机型。
AWS 提供了两种方式来管理机型：

• 手动设置机型：手动指定若干个机型，按照某种规则选择库存充足的机型
    ◦ 优先级模式：按照设置的顺序选择第一个库存充足的机型
    ◦ 价格优先模式：选择库存充足中价格最低的机型
  
• 主动机型筛选：可以设置 cpu 核数、内存和其他指标来动态筛选合适的机型
  

弹性扩缩容能力

• 定时计谋
  

当一个应用流量具有显着的周期性特性，可以采用定时计谋实现周期性的扩容与缩容

• 基于指标的主动计谋
  

基于云提供的监控指标，随着指标的上升主动扩容，或随着指标的下降主动缩容

• 冷却时间
  

过于频仍的举行集群数量的变动不但不会提高服务的质量，而且会导致集群的不稳固，为了防止此类题目，会有一个冷却时间举行限定，实现最小的变动时间间隔
03 AWS 弹性伸缩的高级特性
除了上述的一些底子能力，AWS 弹性伸缩还提供了更加高级的特性提供更好的体验。
生命周期钩子
在组内节点举行状态变动时，用户可以参加自定义逻辑，来实现对于节点状态切换时举行的额外利用，例如资源的初始化或清理。自定义利用的实现方式重要有几种：

• 利用 cloud-init 来实行自定义脚本，此种方式严酷来说不属于生命周期钩子的概念范畴，且只能针对启动周期举行利用，但也是一种最为简单实现自定义利用的可用方案。
  
• 利用 Lambda 服务实现自定义利用，通过监听 EventBridge 事件来触发设置的 Lambda 利用。
  
• 利用自研程序监听 SNS 或者 SQS 事件，实行自定义的程序流程
  

自定义利用一般都设置有超时时间，用户可以定义超时后的利用方式，因此在自定义程序实行竣事后，应当要调用 AWS 的 API 通知弹性伸缩组已完成生命周期钩子逻辑。
暖池
为了提高节点扩容的敏捷性，AWS 提出了暖池的概念，独立于弹性伸缩组的节点之外，最大限度的减少节点提供服务的预热时间，提供应对突发容量时的应变能力。暖池内的节点有三种状态：

• Stopped：节点处于关机状态，如许可以节省创建节点的时间。
  
• Hibernated：节点运行的内存状态将以快照形式保存到磁盘中，可以进一步减少开机所需的时间。
  
• Running：节点处于运行状态，几乎可以瞬间参加的弹性伸缩组中，参加负载均衡，提供服务（当然假如设置了生命周期钩子，另有实行自定义逻辑的时间），当然同时也必须支付全部的节点运行费用。
  

基于权重的多机型计谋、
当底子的机型指标不能准确形貌节点的服务能力时，AWS 支持用户为指定的机型设置权重，代表机型的相对服务能力。举个例子，机型 a 与 b 均为 2 核 4G 的设置，但由于其他的综合指标，颠末压测效果，a 机型的服务能力是 b 机型的两倍，此时我们就可以设置 a 机型的权重为 2，b 为 1。弹性伸缩组的期望、最大最小容量就可以不代表节点数量，而代表抽象的服务能力，当我们指定期望值为 8 时，利用 a 机型必要 4 个节点，而利用 b 机型则必要 8 个节点。如许就会更加准确的形貌总服务能力，或者包管多可用区间的能力平衡。
04 AutoMQ 是怎样利用 AWS 弹性伸缩的
存算分离的 Kafka 节点
由于 AutoMQ 的存算分离架构，几乎所有的状态信息均存储于对象存储中（有部门写缓冲数据在 EBS 卷中，现在已经推出无 EBS 的 Direct S3 版本[3]），我们可以认为节点都是可以随时被终止和替换的。如许就完全具备了利用弹性伸缩管理集群的条件条件，随着负载的变革，可以借助弹性伸缩实现分钟级甚至秒级的容量增减。我们在利用弹性伸缩组时，将 kafka 的 controller 与 broker 节点举行了区分，采用了差异的伸缩组，在此我们提出了一个概念，把同时具备 controller 和 broker 功能的节点称为 server 节点。随着集群规模的增大，我们会根据特性差异将纯 broker 节点按照特性切分为差异的弹性伸缩组。

利用机型计谋办理多可用区库存题目
以现在 AutoMQ 利用的两类机型为例，r6in.large 与 r6i.large 均为 2 核 16G 内存的机型，但在实际综合测试中，两者的服务能力存在着本质的区别，可以几乎认为 r6in.large 的服务能力为 r6i.large 的两倍，而两者在差异地域与可用区的分布并不均匀，当我们选择利用多可用区高可用结构的情况下，很难做到差异可用区的服务能力是平衡的。因此利用机型权重即可有用的办理此类题目，将 r6in.large 的权重设置为 r6i.large 的两倍，在多可用区均衡计谋下，利用 r6in.large 的可用区可以利用一半的节点数量达到同等的服务能力。
利用康健检查及生命周期钩子保持集群的康健
对于常规的 web 应用，利用负载均衡的主动康健检查是一个最为高效的手段。但对于 Kafka 此类应用来说，往往会有更加复杂的节点康健评估机制。因此，我们必要借助自定义的方案来包管集群节点的康健。我们会根据内部的巡检及一些额外的机制，对于节点举行康健评估，假如发现节点处于非康健状态，我们会利用 AWS 的康健状态设置接口，手动的更改节点的康健状态。此时，弹性伸缩组会主动实行节点的替换利用，得益于 AutoMQ 的无状态架构，可以平滑的举行节点的替换。通过节点关闭的生命周期钩子，我们可以确保界限情况下数据的完备性与可靠性。
利用主动弹性计谋实现秒级扩容体验
由于 Kafka 重要运用于大数据量，高吞吐的场景，其运行特性差异于常规的计算密集型应用，对于 cpu 与内存指标并不敏感，决定其负载的核心指标为网络吞吐量，所以我们必要将弹性的核心指标定位至服务器的网络收支带宽。正如我们前面介绍的多弹性伸缩组的架构，我们还必要利用 AWS 的一个关键特性：通过本伸缩组的弹性指标对另外一个组举行伸缩。例如一个规模较小的集群，往往只包罗 server 节点，分配了一个伸缩组，当流量规模达到一定比例时，平均的流量已经凌驾了安全阈值，此时我们必要增加节点数量，由于 server 节点的数量往往是固定的，不可通过简单的增加 server 节点提高整体集群的节点数量。所以我们会在初始化集群的时间，创建两个弹性伸缩组，同时将另一个伸缩组容量设置为 0。如许我们可以通过 server 伸缩组的指标，增加另一个伸缩组的节点数量，整体集群节点的平均流量就会符合预期地下降至合理水位。
05 结语
本日我们简单介绍了 AWS 弹性伸缩组的根本概念与 AutoMQ 是怎样利用弹性伸缩组实现产品特性的，接下来我们会针对 AutoMQ 是怎样利用云底子办法这一话题展开介绍，请各人敬请等待。
参考资料
[1]https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html [2]https://zh.wikipedia.org/wiki/%E5%BC%B9%E6%80%A7%E4%BC%B8%E7%BC%A9 [3]https://docs.automq.com/automq/getting-started/deploy-direct-s3-cluster
关于我们
我们是来自 Apache RocketMQ 和 Linux LVS 项目的核心团队，曾经见证并应对过消息队列底子办法在大型互联网公司和云计算公司的挑战。如今我们基于对象存储优先、存算分离、多云原生等技术理念，重新计划并实现了 Apache Kafka 和 Apache RocketMQ，带来高达 10 倍的成本优势和百倍的弹性效率提拔。