AWS 介绍弹性伸缩特性

01。弹性伸缩组是什么？

随著云计算技术的不断发展和云原生理念的深入人心，各种基础部署模式层出不穷。弹性伸缩组是一个相对“传统”的云技术概念，很多同学可能还是有些陌生。今天，我用云计算我的鼻祖 AWS 以弹性伸缩组为例，谈谈云计算发展的基础产品。弹性伸缩组是 Iaas 在基础设施发展的后期，提出了一种云产品，相信大家对 k8s 会有所了解󿀌基于容器的弹性扩缩方案并不是一个新概念。我们可以理解弹性伸缩组是基于云虚拟机解决动态膨胀容量需求的产品。AWS 于 2006 年 8 月推出了 EC2 产品，由于动态扩缩是自然存在的基本需求，于是从 2008 年 4 ࿰从月开始c;各种三方弹性伸缩软件出现，包括 Scalr 和 RightScale。2009 年 5 月 18 日，AWS 推出了自己的弹性伸缩功能[1]。总结，弹性伸缩组的主要目的是解决不断变化的流量需求而产生的产品，核心概念可分为两部分：“弹性伸缩”和“组”。

02。弹性伸缩组的功能是什么？

围绕“弹性伸缩”和“组”，弹性伸缩组的主要功能可分为两个主要部分：

节点管理。

弹性伸缩组管理的核心资源是我们的计算节点，因此，弹性伸缩组本质上是一个节点组󿀌管理一组同构或异构节点，管理好节点自然是本产品的基本能力。围绕节点管理 AWS 定义了几个基本概念：

• 启动模板。

为应对灵活的扩缩需求，新增和销毁快速节点必须支持#xff1b;同时，它也被归纳在一个组中，节点必然或多或少有共性。能够快速创建节点的模板是最好的选择。AWS 大多数启动模板支持配置 EC2 参数属性󿀌为伸缩组提供了一个基本的属性模板。

• 期待，最大，最小数量。

手动管理节点容量，用户可以设置预期的节点数量，控制节点的数量。当实际节点数量不等于预期数量时，弹性伸缩组将自动创建和回收节点，匹配预期数量。使用自动弹性策略时，本质也是通过修改预期数量来控制扩张。最大和最小数量可以理解为约束值，限制预期数量的范围，防止集群水位过低或服务器成本过高。

• 健康检查。

  修正预期数量的前提是节点处于节点状态『健康』状态，对于『不健康』节点，弹性伸缩组将被替换，确保组中的节点处于健康状态，能够正常提供服务。识别节点是否处于健康状态，一般可以分为两种方法：

  ◦ 当设置负载平衡器时，#xff0c;节点的健康状况将通过负载均衡器的健康检查来判断。

  ◦ 可以通过 API 手动设置节点的健康状态，通常适用于自定义的健康检查逻辑。

• 型号管理策略。

一个高可用集群通常需要几个可用区域的服务节点，但由于库存和型号在不同的可用区域之间存在差异，很难提前设置适合所有可用区的型号，在这个时候，我们需要更智能的策略来管理模型。
AWS 管理机型࿱提供了两种方法a;

• 手动配置机型：手动指定多个型号，根据某些规则选择库存充足的型号。

  ◦ #xff1优先级模式a;按配置顺序选择第一个库存充足的型号。

  ◦ 价格优先模式：选择库存充足中价格最低的型号。

• 自动机型筛选：可以配置 cpu 动态筛选合适的型号，包括核数、内存等指标。

弹性膨胀容量。

• 定时策略。

当应用流量具有明显的周期性特征࿰时c;可采用定期策略实现周期性扩容和缩容。

• 基于指标的自动策略。

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

• 冷却时间。

集群数量变化过于频繁，不仅不会提高服务质量，而且会导致集群不稳定，为了防止这类问题�会有冷却时间限制，实现最小时间间隔的变化。

03。AWS 弹性伸缩的高级特性。

除上述基本能力࿰外c;AWS 弹性伸缩还为更先进的特性提供了更好的体验。

生命周期钩。

当组内节点状态变化时，#xff0c;用户可以添加自定义逻辑#xff0c;实现节点状态切换时的额外操作，例如，资源的初始化或清理。实现定制操作的主要方法有几种：

• 使用 cloud-init 执行自定义脚本，严格来说，这种方法不属于生命周期钩的概念范畴，只能操作启动周期，但也是实现自定义操作最简单的可用方案。

• 使用 Lambda 实现定制操作的服务c;通过监听 EventBridge 触发配置的事件 Lambda 操作。

• 使用自研程序进行监控 SNS 或者 SQS 事件，执行自定义程序流程。

自定义操作一般配备超时间，用户可以定义超时后的操作模式，因此，在自定义程序执行后，应当要调用 AWS 的 API 通知弹性伸缩组已完成生命周期钩逻辑。

暖池。

为提高节点扩容的敏捷性，AWS 提出了暖池的概念，除弹性伸缩组的节点外，尽量减少节点提供服务的预热时间，在应对突发容量时提供应变能力。暖池中的节点有三种状态：

• Stopped：节点处于关机状态，节省创建节点的时间。

• Hibernated：节点运行的内存状态将以快照的形式保存在磁盘中，可以进一步减少启动所需的时间。

• Running：节点处于运行状态，弹性伸缩组࿰几乎可以瞬间加入c;加载均衡，提供服务（当然，如果设置生命周期钩，还有时间执行自定义逻辑），当然，节点运行的所有费用也必须同时支付。

基于权重的多机型策略。、。

当节点的服务能力无法准确描述基本型号指标时，AWS 支持用户为指定型号设置权重，代表机型的相对服务能力。例如＀例c;机型 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]#xff09版;，我们可以认为节点可以随时终止和替换。这样就完全满足了使用弹性伸缩管理集群的前提条件，随着负载的变化，分钟级甚至秒级的容量增减可以通过弹性伸缩来实现。使用弹性伸缩组时，将 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 对内存指标不敏感，其负载的核心指标是网络吞吐量，因此，我们需要将弹性的核心指标定位为服务器的网络进出带宽。就像我们之前介绍的多弹性伸缩组的架构࿰一样c;我们还需要使用它 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/弹性伸缩 [3]https://docs.automq.com/automq/getting-started/deploy-direct-s3-cluster。

关于我们。
我们是来自 Apache RocketMQ 和 Linux LVS 项目核心团队，它见证并应对了大型互联网公司和云计算公司新闻队列基础设施的挑战。现在我们基于对象存储优先、存算分离、多云原生等技术理念󿀌重新设计和实现 Apache Kafka 和 Apache RocketMQ，带来高达 10 成本优势倍，弹性效率提高百倍。

🌟 GitHub 地址：https://github.com/AutoMQ/automq。
💻 官网：https://www.automq.com?utm_source=openwrite。