共计 5550 个字符，预计需要花费 14 分钟才能阅读完成。
简介：阿里云数据库实现了其特有的 Autosaling 能力，该能力由数据库内核、管控及 DAS（数据库自治服务）团队独特构建，内核及管控团队提供了数据库 Autoscaling 的根底能力，DAS 则负责性能数据的监测、Scaling 决策算法的实现及 Scaling 后果的出现。本文将从 Autosaling 的工作流程和落地等方面，具体论述 Autosaling 相干常识。
1. 前言
Gartner 预测到 2023 年，寰球 3 / 4 的数据库都会跑在云上，云原生数据库最大的劣势之一便是人造领有云计算的弹性能力，数据库能够像水、电、煤一样随取随用，而 Autosaling 能力便是弹性的极致体现。数据库的 Autoscaling 能力是指数据库处于业务高峰期时，主动扩容减少实例资源；在业务负载回落时，主动开释资源以降低成本。
业界的云厂商 AWS 与 Azure 在其局部云数据库上实现了 Autoscaling 能力，阿里云数据库同样实现了其特有的 Autosaling 能力，该能力由数据库内核、管控及 DAS（数据库自治服务）团队独特构建，内核及管控团队提供了数据库 Autoscaling 的根底能力，DAS 则负责性能数据的监测、Scaling 决策算法的实现及 Scaling 后果的出现。DAS（Database Autonomy Service）是一种基于机器学习和专家教训实现数据库自感知、自修复、自优化、自运维及自平安的云服务，帮忙用户打消数据库治理的复杂性及人工操作引发的服务故障，无效保障数据库服务的稳固、平安及高效。其解决方案架构如图 1. 所示，Autoscaling/Serverless 能力在其中属于“自运维”的局部。
图 1. DAS 的解决方案架构
2. Autosaling 的工作流程
数据库 Autoscaling 整体的工作流程可定义为如图 2. 所示的三个阶段，即“When：何时触发 Scaling”、“How：采取哪种形式 Scaling”及“What：Scaling 到哪个规格”。
- 何时触发 Scaling 即确定数据库实例的扩容与回缩的机会，通常的做法是通过观测数据库实例的性能指标，在实例的负载高峰期执行扩容操作、在负载回落时执行回缩操作，这是常见的 Reative 被动式触发形式，除此之外咱们还实现了基于预测的 Proactive 主动式触发形式。对于触发机会在 2.1 章节会进行具体的介绍。
- Scaling 的形式通常有 ScaleOut（程度扩缩容）与 ScaleUp（垂直扩缩容）两种模式。以分布式数据库 PolarDB 为例，ScaleOut 的实现模式是减少只读节点的数量，例如由 2 个只读节点减少至 4 个只读节点，该形式次要实用于实例负载以读流量占主导的情景；ScaleUp 的实现模式是降级实例的 CPU 与内存规格，如由 2 核 4GB 降级至 8 核 16GB，该形式次要实用于实例负载以写流量占主导的情景。对于 Scaling 形式在 2.2 章节会进行具体的介绍。
- 在扩容形式确定后须要抉择适合的规格，来使实例的负载降至正当的水位。例如对于 ScaleOut 形式，须要确定减少多少个实例节点；对于 ScaleUp 形式，须要确定降级实例的 CPU 核数与内存，以确定降级至哪种实例规格。对于扩容规格的抉择在 2.3 章节会进行具体的介绍。
图 2. Autoscaling 的工作流程图示
2.1 Autoscaling 的触发机会
2.1.1 Reactive 被动式触发（基于察看）
基于察看的 Reactive 被动式触发是以后 Autoscaling 次要的实现模式，由用户为不同的实例设置不同的扩、缩容触发条件。对于计算性能扩容，用户能够通过设置触发 CPU 阈值、观测窗口长度、规格下限、只读节点数量下限及静默期等选项来配置合乎业务负载的触发条件；对于存储空间扩容，用户能够通过设置空间的扩容触发阈值及扩容下限来满足实例业务的增长，并防止磁盘资源的节约。被动式触发的配置选项在 3.2 章节会进行具体的展现。
Reactive 被动式触发的长处是实现绝对容易、用户接受度高，但如图 3. 所示，被动式触发也存在其毛病，通常 Scaling 操作在达到用户配置的观测条件后才会真正执行，而 Scaling 操作的执行也须要肯定的工夫，在这段时间内用户的实例可能曾经处于高负载较长时间，这会在肯定水平上影响用户业务的稳定性。
图 3. 被动式触发的扩容资源比照图示
2.1.2 Proactive 主动式触发（基于预测）
解决 Reactive 被动式触发的办法便是 Proactive 主动式触发，如图 4. 所示，通过对实例负载的预测，在预测实例负载行将处于顶峰前的一段时间，便提前对实例执行扩容操作，使实例可能安稳度过整个业务高峰期。周期性 workload 是基于预测的形式中最典型的利用场景（线上具备周期性特色的实例约占 40%），DAS 应用了达摩院智能数据库实验室同学实现的周期性检测算法，该算法联合了频域和时域信息，准确率达到了 80% 以上。例如对具备“天级别”周期性特色的线上实例，Autoscaling 服务会在实例每天的业务高峰期开始之前进行扩容，以使实例更好地应答周期性的业务峰值。
图 4. 主动式触发的扩容资源比照图示
咱们同样在 RDS-MySQL 的存储空间扩容里实现了基于预测的形式，基于实例过来一段时间的磁盘使用量指标，应用机器学习算法预测出实例在接下来的一段时间内存储空间会达到的最大值，并会依据该预测值进行扩容容量的抉择，能够防止实例空间快速增长带来的影响。
图 5. 基于磁盘使用量趋势的预测
2.2 Autoscaling 的形式决策
DAS 的 Autoscaling 形式有 ScaleOut 与 ScaleUp 两种，在给出 Scaling 计划的同时也会联合 Workload 全局决策分析模块给出更多的诊断倡议（如 SQL 主动限流、SQL 索引倡议等等）。如图 6. 所示是 Scaling 形式的决策示意图，该示意图以 PolarDB 数据库作为示例。PolarDB 数据库采纳的是计算存储拆散的一写多读的分布式集群架构，一个集群蕴含一个主节点和多个只读节点，主节点解决读写申请，只读节点仅解决读申请。图 6. 所示的“性能数据监测模块”会一直的监测集群的各项性能指标，并判断以后时刻的实例负载是否满足 2.1 章节所述的 Autoscaling 触发条件，当满足触发条件时，会进入到图 6. 中的 Workload 剖析模块，该模块会对实例以后的 Workload 进行剖析，通过实例的会话数量、QPS、CPU 使用率、锁等指标来判断实例处于高负载的起因，若判断实例是因为死锁、大量慢 SQL 或大事务等起因导致的高负载，则在举荐 Autoscaling 倡议的同时也会推出 SQL 限流或 SQL 优化倡议，使实例迅速故障自愈以升高危险。
在 Autoscaling 形式的决策生成模块，会判断采取何种 Scaling 形式更无效。以 PolarDB 数据库为例，该模块会通过实例的性能指标以及实例的主库爱护、事务拆分、零碎语句、聚合函数或自定义集群等特色来判断集群以后的负载散布，若判断实例以后以读流量占主导，则会执行 ScaleOut 操作减少集群的只读节点数量；若判断实例以后以写流量占主导，则会执行 ScaleUp 操作来降级集群的规格。ScaleOut 与 ScaleUp 决策的抉择是一个很简单的问题，除了思考实例以后的负载散布外，还须要思考到用户设置的扩容规格下限及只读节点数量下限，为此咱们也引入了一个成果追踪与决策反馈模块，在每次决策判断时，会剖析该实例历史上的扩容形式及扩容成果，以此来对以后的 Scaling 形式抉择算法进行肯定的调整。
图 6. PolarDB 的 Scaling 形式决策示意图
2.3 Autoscaling 的规格抉择
2.3.1 ScaleUp 决策算法
ScaleUp 决策算法是指当确定对数据库实例执行 ScaleUp 操作时，依据实例的 workload 负载及实例元数据等信息，为以后实例抉择适合的规格参数，以使实例以后的 workload 达到给定的束缚。最开始 DAS Autoscaling 的 ScaleUp 决策算法基于规定实现，以 PolarDB 数据库为例，PolarDB 集群以后有 8 种实例规格，采纳基于规定的决策算法在后期足够用；但同时咱们也摸索了基于机器学习 / 深度学习的分类模型，因为随着数据库技术最终迭代至 Serverless 状态，数据库的可用规格数量会十分宏大，分类算法在这种场景下会有很大的用武之地。如图 7. 及图 8. 所示，咱们以后实现了基于性能数据的数据库规格离线训练模型及实时举荐模型，通过对自定义 CPU 使用率的范畴标注，参考 DAS 之前落地的 AutoTune 主动调参算法，在标注数据集进行模型分类，并通过实现的 proxy 流量转发工具进行验证，以后的分类算法曾经获得了超过 80% 的准确率。
图 7. 基于性能数据的数据库规格 ScaleUp 模型离线训练示意图
图 8. 基于性能数据的数据库规格 ScaleUp 实时举荐办法示意图
2.3.2 ScaleOut 决策算法
ScaleOut 决策算法与 ScaleUp 决策算法的思路相似，实质问题是确定减少多少个只读节点，能使实例以后的 workload 负载降至正当的水位。在 ScaleOut 决策算法里，咱们同样实现了基于规定的与基于分类的算法，分类算法的思维与 2.3.1 章节里形容的根本相似，基于规定的算法思维则如图 9. 所示，首先咱们须要确定与读流量最相干的指标，这里选取的是 com_select、qps 及 rows_read 指标，s_i 示意第 i 个节点读相干指标的表征值，c_i 示意第 i 个节点的指标束缚表征值（通常应用 CPU 使用率、RT 等间接反馈业务性能的指标），f 指指标函数，算法的指标便是确定减少多少个只读节点 X，能使整个集群的负载降至 f 函数确定的范畴。该计算方法明确且无效，算法上线后，以变配后集群的 CPU 负载是否降至正当水位作为评估条件，算法的准确率达到了 85% 以上，在确定采取 ScaleOut 变配形式后，ScaleOut 决策算法新增的只读节点根本都能处于“恰好饱和”的工作负载，可能无效的晋升数据库实例的吞吐。
图 9. 基于性能数据的数据库节点数量 ScaleOut 举荐算法示意图
3. 落地
3.1 实现架构
Autoscaling 能力集成在 DAS 服务里，整个服务波及异样检测、全局决策、Autoscaling 服务、底层管控执行多个模块，如图 10. 所示是 DAS Autoscaling 的服务能力架构。异样检测模块是 DAS 所有诊断优化服务（Autoscaling、SQL 限流、SQL 优化、空间优化等）的入口，该模块会 7 *24 小时对监控指标、SQL、锁、日志及运维事件等进行实时检测，并会基于 AI 的算法对其中的趋势如 Spike、Seasonaliy、Trend 及 Meanshift 等进行预测及剖析；DAS 的全局决策模块会依据实例以后的 workload 负载给出最佳的诊断倡议；当由全局决策模块确定执行 Autoscaling 操作时，则会进入到第 2 章节介绍的 Autoscaling 工作流程，最终通过数据库底层的管控服务来实现实例的扩、缩容。
图 10. DAS 及 AutoScaling 的服务能力架构
3.2 产品计划
本章节将介绍 Autoscaling 性能在 DAS 里的开启形式。如图 11. 所示是 DAS 的阿里云官网产品首页，在该界面能够看到 DAS 提供的所有性能，如“实例监控”、“申请剖析”、“智能压测”等等，点击“实例监控”选项能够查看用户接入的所有数据库实例。咱们点击具体的实例 id 链接并抉择“自治核心”选项，能够看到如图 12. 及图 13. 所示的 PolarDB 主动扩、缩容设置及 RDS-MySQL 主动扩容设置，对于 PolarDB 实例，用户能够设置扩容规格下限、只读节点数量下限、观测窗口及静默期等选项，对于 RDS-MySQL 实例，用户能够设置触发阈值、规格下限及存储容量下限等选项。
图 11. DAS 产品首页
图 12. PolarDB 主动扩、缩容设置图示
图 13. RDS-MySQL 主动扩、缩容设置图示
3.3 成果案例
本章节将介绍两个具体的线上案例。如图 14. 所示为线上 PolarDB 实例的计算规格 Autoscaling 触发示意图，在 05:00-07:00 的时间段，实例的负载缓缓回升，最终 CPU 使用率超过了 80%，在 07:00 时触发了主动扩容操作，后盾的 Autoscaling 服务判断实例以后读流量占主导，于是执行了 ScaleOut 操作，为集群减少了两个只读节点，通过图示能够看到，减少节点后集群的负载显著降落，CPU 使用率降至了 50% 左右；在之后的 2 个小时里，实例的业务流量持续减少，导致实例负载持续在迟缓回升，于是在 09:00 的时候再次达到了扩容的触发条件，此时后盾服务判断实例以后写流量占主导，于是执行了 ScaleUp 操作，将集群的规格由 4 核 8GB 降级到 8 核 16GB，由图示能够看到规格降级后实例的负载趋于稳定，并维持了近 17 个小时，之后实例的负载降落并触发了主动回缩操作，后盾 Autoscaling 服务将实例的规格由 8 核 16GB 降至 4 核 8GB，并缩小了两个只读节点。Autoscaing 服务在后盾会主动运行，无需人工干预，在负载高峰期扩容、在负载低谷时回缩，晋升业务稳定性的同时升高了用户的老本。
图 14. 线上 PolarDB 程度扩容、垂直扩容成果示意图
如图 15. 所示为线上 RDS-MySQL 实例的存储空间主动扩容示意图，左侧图示意实例在近 3 个小时内触发了 3 次磁盘空间扩容操作、累计扩容近 300GB，右侧是磁盘空间的增长示意图，能够发现在实例存储空间迅速增长时，空间主动扩容操作可能无缝执行，真正做到了随用随取，在防止实例空间打满的同时节俭了用户的老本。
图 15. 线上 RDS-MySQL 空间扩容成果示意图
原文链接
本文为阿里云原创内容，未经容许不得转载。
