作者：AnalyticDB MySQL研发团队—胡振宇(孤月)
1. 前言
在全球经济增长放缓的大背景之下，企业在加强数字化建设的过程中，降本增效成为一个绕不开的话题。云原生数仓AnalyticDB MySQL湖仓版（以下简称ADB MySQL） 在发布之初提供了定时弹性功能，帮助业务有规律的客户定时升降配计算资源以节省成本。时隔一年，ADB MySQL针对用户痛点，再推出Multi-Cluster弹性资源模式，它具备贴合用户负载、自动配置、性能线性提升等优点，进一步帮用户节省成本，提高计算效率。
2. Multi-Cluster弹性模型优势
ADB MySQL 在没有Multi-Cluster弹性模型之前
- 易用性： 用户只能根据业务规律，在固定时间段弹升，弹性计划生效间隔长（最短间隔10分钟）
- 性能： 小查询的性能容易受到大查询的干扰， 查询并发数不随资源组大小变化，查询可能排队
- 成本： 用户需要指定固定时间段的弹升规格，难以贴合业务负载，短时间段的业务波谷无法缩容
Multi-Cluster弹性模型是作用在ADB MySQL 在线资源组内部的，一个在线资源组由一个或者多个Cluster组成，相比普通在线资源组在以下方向进行了提升
- 易用性： 自动根据当前实例的负载进行Cluster个数的扩缩， 用户只需设置好Cluster个数的上限、下限及每个Cluster大小即可
- 性能：查询在Cluster之间隔离，查询性能线性提升， 查询并发数随着Cluster个数的增长而线性增长
- 成本： 贴合用户负载，动态选择最优Cluster个数，充分贴合业务的每一次业务波谷
3. Multi-Cluster技术架构
在设计Multi-Cluster技术架构的时候，我们的核心目标有三个： 弹得准、弹得快、弹得好。 下图是ADB MySQL Multi-Cluster的整体架构图，从上至下可分为三层:
- 接入层：负责将用户的查询投递到特定的资源组，再根据Cluster的负载情况分配到具体的Cluster上去执行
- 执行层：资源组内部划分为相同大小的多个Cluster，每个query只在其中一个Cluster上执行
- 决策层：通过实时读取ADB MySQL资源的负载情况， 进行Multi-Cluster资源组的扩缩容决策
3.1 弹得快：实时数据链路
为了保障扩容的时效性，快速应对用户查询的到来，ADB MySQL建立了Region级别的指标采集系统。ADB MySQL实例也进行了改造，能实时地更新内部的业务指标（如 Query 排队数、CPU使用等），并被指标采集进程采集到中心的存储端。目前整个数据链路的延迟在10s左右。
3.2 弹得准：稳定的扩缩容策略
ADB MySQL实例是由接入层节点、计算节点、存储节点共同构成的复杂系统，在对计算资源进行扩缩容决策的时候面临如下挑战：
- 多组件交互的系统，如何识别外部组件瓶颈
- 实例指标繁多，基于什么指标来进行扩缩容决策
- 如何防止指标短时间的抖动，导致扩缩容策略不准
- 如何判断扩缩容决策是否合理
为此，我们将整个Cluster个数计算分为三个阶段：决策、执行、反馈
3.2.1 决策
瓶颈识别
我们在决策系统中，将指标分为两类
正向指标： 反馈要扩容目标的负载情况，决定扩容目标的扩缩容
负向指标： 反馈除扩容目标外的其余组件的负载情况，用于判断外部瓶颈
当负向指标达到设定的阈值时，我们认为计算节点扩容对于ADB MySQL实例整体而言已经无法起到加速查询，提升并发数的作用。对于这种情况，决策系统将会报警直至瓶颈解除
Cluster个数预估
对ADB MySQL实例的负载分析后，我们发现对于扩缩容的决策并不能由单个指标决定，随着用户负载类型不同，决定扩缩容的指标也不一样。主要用到的指标有： 用户CPU使用率， 用户内存使用率， 用户查询排队数等。
因此在扩缩容的预估的过程中，我们会先根据每个指标计算得出一个候选Cluster数，最后再选择所有指标中最大的Cluster数作为最终候选项
- 对于和Cluster挂钩的指标（如CPU利用率）我们采用如下计算公式：
clusterCount1 = ceil(\frac{所有Cluster的CPU利用率之和}{Cluster的目标CPU利用阈值})
- 对于和资源组挂钩、但不和Cluster挂钩的指标（如查询排队数和并发数）我们采用如下公式计算
clusterCount2= ceil((\frac{平均排队数 + 平均并发数}{Cluster并发数阈值}) * 当前Cluster数)
最终我们取所有算出来的目标Cluster数的较大值
目标Cluster数= \max(clusterCount1, clusterCount2，... clusterCountN)
稳定窗口
为避免因为实例负载抖动等因素造成的metric抖动，我们采用了稳定窗口的算法来避免抖动
在稳定窗口期间，每次预估的Cluster个数都会记录下来，并使用当前的Cluster个数和稳定窗口中推荐的个数进行对比
- 若 窗口Min <= 当前Cluster个数 <= 窗口Max, 则当前Cluster个数数保持不变
- 若 当前Cluster个数 < 窗口Min, 则说明应当将当前Cluster个数应当扩容至窗口 Min
- 若 当前Cluster个数 > 窗口Max，说明当前Cluster个数应当缩到稳定窗口Max
3.2.2 执行
资源组组内部的Cluster，在ADB MySQL内部对应的K8s的自定义资源（Custom Resource），由自研的Operator进行管理，这些自定义资源实现了K8s的Scale subResource。 当决策系统作出决策后，会通过K8s的 Scale API，将目标Cluster个数下发给自定义Operator 进行扩缩容
3.2.3 反馈：有效性评估
在执行完扩（缩）容后，决策系统会记录扩容之前的metric指标的值，并在扩（缩）容完成后持续观察用户负载的指标
- 扩容评估: 决策系统持续观察扩容后用户查询的qps是否按照Cluster的比例增长了，或者用户查询的rt是否按照Cluster的比例降低了，如果没有明显增长，则认为扩容无效， 决策将Cluster个数恢复成扩容前的个数，停止扩容决策运行，并预警
- 缩容评估： 决策系统持续观察缩容后用户查询的qps 和 rt 是否均有明显变化，如果变化超过了一定的阈值，则将Cluster恢复成缩容前的个数，决策系统将Cluster个数恢复成缩容前的个数，停止缩容决策，并预警
3.3 弹得好：负载均衡路由策略
在Cluster个数提升之后，用户无需指定查询路由到的Cluster，ADB MySQL 自动根据负载均衡算法将查询路由到负载最小的Cluster中。
下图是一个根据Cluster负载均衡路由的示意图
- 当Q5到来时，由于Cluster0的负载是2，Cluster1的负载是1，Cluster2的负载是1。Q5会优先分配给Cluster1执行
- 当Q6到来时，由于Cluster0的负载是2，Cluster1的负载是2，Q6会分配给Cluster2执行
4. Multi-Cluster的收益估算
为了让用户对Multi-Cluster模型和定时弹性模型在收益上有更清楚地认识，我们这里举个案例。
- 0-7点：某客户在晚上0-7点的时候，处于业务低峰期，用户采用定时弹性，将计算资源缩小至48ACU
- 7-24点：客户业务处于间歇性高峰期, 用户采用定时弹性将计算资源保持在192ACU，以应对随时可能到来的波峰
应用Multi-Cluster模型之后
- 0-7点： 用户将Cluster大小缩小为48ACU, 保持和定时弹性的资源使用量一直
- 7-24点： 用户将Cluster大小变为96ACU, 并设置最小Cluster个数为1，最大Cluster为2
可以看到相对定时弹性，Multi-Cluster模型可以在业务两个高峰之间的波谷，为用户减少Cluster个数，节省成本，当用户的业务波峰到来后，Cluster个数随之弹升，满足业务负载
5. 总结及未来规划
我们推出了ADB MySQL Multi-Cluster形态，完成了自动化、智能化扩缩容的第一步。ADB MySQL Multi-Cluster形态有如下特点：
成本: 可以贴合负载扩缩容，相比单Cluster资源组固定资源，可以节省更多的成本
查询性能: 线性增加，查询的隔离性相比单Cluster资源组要更优越
自动弹性: 避免了用户手动调整资源组大小
未来，我们还将在以下几个方面继续打磨和增强:
主动弹性：基于预测的主动弹性，查询延迟最小化
负载解耦：基于WorkLoadManager， 大query自动投递到离线资源组减少对在线资源组的资源抢占
弹性效率：资源Pod热池加速弹性效率
效果展示：性能优化及成本节省可视化
ADB MySQL Multi-Cluster形态 目前正在邀测中，欢迎感兴趣的客户加入湖仓版体验交流钉钉群（群号：33600023146）申请邀测名额。产品文档请参见。
