数据库自治服务DAS的Auto Scaling是以数据库实例的实时性能数据作为输入，由DAS完成流量异常发现、合理数据库规格建议和合理磁盘容量建议，使数据库服务具备自动扩展存储和计算资源的能力。
背景信息
为业务应用选择一个合适的数据库计算规格（CPU和内存），是每个数据库运维人员都会经常面临的一个问题。若规格选得过大，会产生资源浪费；若规格选的过小，计算性能不足会影响业务。
通常情况下，运维人员会采用业务平稳运行状态下，CPU处于合理水位（例如50%以下）的一个规格（如4核CPU配8 GB内存）并配一个相对富余的磁盘规格（如200 GB）。
然而在数据库应用的运维人员日常工作中，线上应用流量突增导致数据库资源打满的情况时有发生，而引发这类问题的场景可能多种多样：
新业务上线，对业务流量预估不足，导致资源打满。如新上线的应用接入了大量的引流，或基础流量比较大的平台上线了一个新功能。
不可预知的流量。如突发的舆论热点带来的临时流量，或某个网红引发的限时抢购、即兴话题等。
一些平时运行频次不高，但又偶发集中式访问。如每日一次的上班打卡场景，或每周执行几次的财务核算业务。这类业务场景平时业务压力不高，虽已知会存在访问高峰，但为节省资源而通常不会分配较高的规格。
当上述业务场景突发计算资源不足状况时，通常会让运维人员措手不及，严重影响业务，如何应对“数据库资源打满”是运维人员常常被挑战的问题之一。
在数据库场景下，资源打满可分为计算资源和存储资源两大类，其主要表现：
计算资源打满：主要表现为CPU或内存资源利用率达到100%，即当前规格下的计算能力不足。
存储资源打满：主要表现为磁盘空间使用率达到100%，数据库写入的数据量达到当前规格下磁盘空间的最大容量，导致业务无法写入新数据。
针对上述两类问题，数据库自治服务DAS进行了服务创新，使数据库服务具备自动扩展存储和计算资源的技术能力，可从容应对。
本文将对DAS Auto Scaling服务的架构进行详细的介绍，包括技术挑战、解决方案和关键技术。
技术挑战
计算资源规格调整是数据库优化的一种常用手段，尽管计算资源规格只涉及到CPU和内存，但在生产环境中进行规格变配产生的影响不容忽视，涉及数据迁移、HA切换、Proxy切换等操作，对业务也会产生影响。
在业务有突发流量时，通常计算资源会比较紧张，甚至出现CPU利用率达到100%的情况。面对这种情况，通常采用扩容数据库规格的方式来解决问题，而专业运维人员（DBA）在准备扩容方案时会至少思考如下三个问题：
扩容是否能解决资源不足的问题？
在数据库场景下，CPU打满只是计算资源不足的一个表征，导致这个现象的根因很多，解法也各不相同：
例如业务流量激增，当前规格的资源确实不能够满足计算需求，在合适的时机点，弹性扩容是一个好的选择。
例如出现了大量的慢SQL，慢SQL堵塞任务队列，且占用了大量的计算资源等，此时资深的数据库管理员首先想到的是紧急SQL限流，而不是扩容。
在感知到实例资源不足时，DAS同样需要从错综复杂的问题中抽丝剥茧定位根因，基于根因做出明智的决策，是限流，是扩容，还是其他。
何时应该进行扩容？
如何选择合适的扩容时机和扩容方式：
对于应急扩容时机，选择的好坏与紧急情况的判断准确与否密切相关。“紧急”告警发出过于频繁，会导致实例频繁的高规格扩容，产生不必要的费用支出；“紧急”告警发出稍晚，业务受到突发情况影响的时间就会相对较长，对业务会产生影响，甚至引发业务故障。在实时监控的场景下，当我们面临一个突发的异常点时，很难预判下一时刻是否还会异常。因此，是否需要应急告警变得比较难以决断。
对于扩容方式，通常有两种方式，分别是通过增加只读节点的水平扩容，以及通过改变实例自身规格的垂直扩容。
水平扩容适用于读流量较多，而写流量较少的场景，但传统数据库需要搬迁数据来搭建只读节点，而搬迁过程中主节点新产生的数据还存在增量同步更新的问题，会导致创建新节点比较慢。
垂直扩容则是在现有规格基础上进行升级，其一般流程为先对备库做升级，然后主备切换，再对新备库做规格升级，通过这样的流程来降低对业务的影响，但是备库升级后切换主库时依然存在数据同步和数据延迟的问题。
因此，在什么条件下选择哪种扩容方式也需要依据当前实例的具体流量来进行确定。
如何扩容，规格该如何选择？
在数据库场景下，实例变更一次规格涉及多项管控运维操作。以物理机部署的数据库变更规格为例，一次规格变更操作通常会涉及数据文件搬迁、cgroup隔离重新分配、流量代理节点切换、主备节点切换等操作步骤；而基于Docker部署的数据库规格变更则更为复杂，会额外增加Docker镜像生成、Ecs机器选择、规格库存等微服务相关的流程。因此，选择合适的规格可有效地避免规格变更的次数，为业务节省宝贵的时间。
当CPU利用率已经是100%的时候，升配一个规格将会面临两种结果：第一种结果是升配之后，计算资源负载下降并且业务流量平稳；第二种结果是升配之后，CPU依然是100%，并且流量因为规格提升后计算能力增强而提升。第一种结果，是比较理想的情况，也是预期扩容后应该出现的效果，但是第二种结果也是非常常见的情形，由于升配之后的规格依然不能承载当前的业务流量容量，而导致资源依然不足，并且仍在影响业务。
如何利用数据库运行时的信息选择一个合适的高配规格将直接影响升配的有效性。
解决方案
针对上文提到的三项技术挑战，下面从DAS Auto Scaling服务的产品能力、解决方案、核心技术这三个方面进行解读，其中涉及RDS MySQL、PolarDB MySQL版、Redis等多种数据库服务，提供了存储自动扩容、计算规格自动扩容和网络带宽自动扩容等功能，最后以一个案例进一步具体说明。
能力介绍：
针对即将达到用户已购买规格上限的实例，DAS存储自动扩容服务可以进行磁盘空间预扩容，避免出现因数据库磁盘占满而影响用户业务的事件发生。在该服务中，用户可自主配置扩容的阈值比例，也可以采用DAS服务预先提供的90%规格上界的阈值配置，当触发磁盘空间自动扩容事件后，DAS会对该实例的磁盘进行扩容。
针对需要变更实例规格的数据库实例，DAS规格自动变配服务可进行计算资源的调整，用更符合用户业务负载的计算资源来处理应用请求，在该服务中，用户可自主配置业务负载流量的突发程度和持续时间，并可以指定规格变配的最大配置以及变配之后是否回缩到原始规格。
针对需要扩容实例带宽规格的数据库实例，DAS网络带宽自动变配服务可对实例带宽进行调整，扩缩到合适的网络带宽规格来解决实例带宽吞吐量的问题。
在用户交互层面，DAS Auto Scaling主要采用消息通知的方式展示具体的进度以及任务状态，其中主要包括异常触发事件、规格建议和任务状态三部分。异常触发事件用于通知用户触发变配任务，规格建议将针对存储扩容和规格变配的原始规格和目标值进行说明，而管控任务状态则将反馈Auto Scaling任务的具体进展和执行状态。
方案介绍
为了实现上面介绍的具体能力，DAS Auto Scaling实现了一套完整的数据闭环，如下图所示：
在该数据闭环中，包含性能采集模块、决策中心、算法模型、规格建议模块、管控执行模块和任务跟踪模块，各模块的具体功能如下：
性能采集模块负责对实例进行实时性能数据采集，涉及数据库的多项性能指标信息、规格配置信息、实例运行会话信息等。
决策中心模块则会根据当前性能数据、实例会话列表数据等信息进行全局判断，以解决挑战一的问题。例如可通过SQL限流来解决当前计算资源不足的问题则会采取限流处理；若确实为突增的业务流量，则会继续进行Auto Scaling服务流程。
算法模型是整个DAS Auto Scaling服务的核心模块，负责对数据库实例的业务负载异常检测和容量规格模型推荐进行计算，进而解决挑战二和挑战三的具体问题。
规格建议校验模块将产出具体建议，并针对数据库实例的部署类型和实际运行环境进行适配，并与当前区域的可售卖规格进行二次校验，确保的建议能够顺利在管控侧进行执行。
管控模块负责按照产出的规格建议进行分发执行。
状态跟踪模块则用于衡量和跟踪规格变更前后数据库实例上的性能变化情况。
下文将分别针对DAS Auto Scaling支持的存储扩容、计算规格变配和带宽规格变配三个业务场景进行展开介绍。
存储扩容的方案如下图所示，主要有两类触发方式，分别是用户自定义触发和算法预测触发。其中，算法将根据数据库实例过去一段时间内的磁盘使用值结合时序序列预测算法，预测出未来一段时间内的磁盘使用量，若短时间内磁盘使用量将超过用户实例的磁盘规格，则进行自动扩容。每次磁盘扩容将最少扩大5 GB，最多扩大原实例规格的15%，以确保数据库实例的磁盘空间充足。
目前在磁盘Auto Scaling的时机方面，主要采用的是阈值和预测相结合的方式。当用户的磁盘数据缓慢增长达到既定阈值（如90%）时，将触发扩容操作；如果用户的磁盘数据快速增长，算法预测到其短时间内将会可用空间不足时，也会给出磁盘扩容建议及相应的扩容原因说明。
计算规格变配的方案如图3所示，其具体流程为：首先，异常检测模块将针对业务突发流量从多个维度（qps、tps、active session、iops等指标）进行突发异常识别，经决策中心判别是否需要Auto Scaling变配规格，然后由规格建议模块产生高规格建议，再由管控组件进行规格变配执行。
待应用的异常流量结束之后，异常检测模块将识别出流量已回归正常，然后再由管控组件根据元数据中存储的原规格信息进行规格回缩。在整个变配流程结束之后，将有效果跟踪模块产出变配期间的性能变化趋势和效果评估。
目前规格的Auto Scaling触发时机方面，主要是采取对实例的多种性能指标（包括cpu利用率、磁盘iops、实例Logic read等）进行异常检测之后，结合用户设定的观测窗口期长度来实现有效的规格Auto Scaling触发。触发Auto Scaling之后，规格推荐算法模块将基于训练好的模型并结合当前性能数据、规格、历史性能数据进行计算，产出更适合当前流量的实例规格。此外，回缩原始规格的触发时机也是需要结合用户的静默期配置窗口长度和实例的性能数据进行判断，当符合回缩原始规格条件后，将进行原始规格的回缩。
带宽规格变配的方案如图4所示，其具体流程为：首先，异常检测模块针对实例出/入口流量使用率进行突增流量异常识别，经决策中心判别是否需要进行带宽自动扩容，然后由带宽规格建议模块产生高规格建议，再由管控组件执行带宽规格升配。
待异常流量结束后，异常检测模块将识别出流量已回归正常，带宽规格建议模块产生带宽回缩建议，然后再由管控组件执行带宽规格回缩。在整个变配流程结束之后，将有变配效果跟踪模块产出变配期间的性能变化趋势和效果评估。
目前带宽自动弹性伸缩在触发时机方面，主要是采取对实例的出/入口流量使用率进行异常检测之后，结合用户设定的观测窗口期长度来实现带宽弹性伸缩的触发。触发带宽弹性伸缩后，带宽规格推荐算法模块将基于训练好的模型结合当前实例的性能数据、带宽规格以及历史性能数据进行计算，产出更适合当前流量的实例带宽规格。带宽规格回缩的触发时机也是结合了实例的性能数据进行判断，当符合带宽规格回缩条件后，将基于带宽规格建议模块产生的带宽回缩建议进行带宽规格的回缩。
核心技术
DAS Auto Scaling服务依赖的是阿里云数据库数据链路团队、管控团队和内核团队的综合技术，其中主要依赖了如下几项关键技术：
全网数据库实例的秒级数据监控技术，目前监控采集链路实现了全网所有数据库实例的秒级采集、监控、展现、诊断，可每秒实时处理超过1000万项监控指标，为数据库服务智能化打下了坚实的数据基础。
全网统一的实例管控任务流技术，目前该管控任务流承担了阿里云全网实例的运维操作执行，为Auto Scaling技术的具体执行落地提供了可靠的保障。
基于预测和机器学习的时序异常检测算法，目前的时序异常检测算法可提供周期性检测、转折点判定和连续异常区间识别等功能，目前对线上70w+的数据库实例进行1天后数据预测，误差小于5%的实例占比稳定在99%以上， 并且预测14天之后的误差小于5%的实例占比在94%以上。
基于DeepLearning的数据库RT预测模型，该算法可基于数据库实例的CPU使用情况、逻辑读、物理读和iops等多项数据指标预测出实例运行时的rt值，用于指导数据库对BufferPool内存的缩减，为阿里巴巴数据库节省超27T内存，占比总内存约17%。
基于云计算架构的下一代关系型数据库PolarDB MySQL版。PolarDB MySQL版是阿里云数据库团队为云计算时代定制的数据库，其中它的具备计算节点与存储节点分离特性对Auto Scaling提供了强有力的技术保障，能够避免拷贝数据存储带来的额外开销，大幅提升Auto Scaling的体验。
在上述多项技术的加持下，DAS Auto Scaling目前针对多个引擎提供不同的弹性能力，在解决业务资源受限问题的同时，能够保证弹性服务期间的数据一致性和完整性，能够在不影响业务稳定性的情况下实现弹性能力，为业务保驾护航，具体弹性能力支持情况如下：
弹性服务类型
支持的数据库引擎
计算规格弹性
RDS MySQL高可用系列云盘版、高可用系列本地盘版（通用型）、三节点企业系列（通用型）
PolarDB MySQL版的集群版
Redis社区版云盘实例、企业版内存型云盘实例
存储规格弹性
RDS MySQL高可用系列云盘、集群系列
RDS PostgreSQL高可用系列云盘版
MyBase MySQL高可用云盘版、高可用本地盘
带宽规格弹性
Redis本地盘实例
具体案例
以RDS MySQL实例上的弹性过程为例。在该实例上，用户配置了15分钟的观测窗口以及CPU利用率阈值为80%的触发条件。
从上图可以看出，该实例在07:10突然出现异常流量，导致CPU利用率和活跃会话飙升，CPU利用率上升至80%以上，资源相对紧张。经过对实例上的读写流量进行分析发现，当前流量中以读流量为主，DAS Auto Scaling算法判断通过增加2个只读节点缓解CPU资源，且实例的CPU利用率下降到60%，解决了CPU资源紧张的问题。然而随着用户业务的变化，在09:00时CPU再一次打高出现资源紧张的情况，此时的流量分析发现以写流量为主，DAS Auto Scaling算法判断通过提升计算资源规格缓解CPU资源，且实例的CPU利用率下降到50%，解决了第二次CPU紧张的问题。
从这个实例的业务使用情况可以看出，DAS Auto Scaling通过2次主动介入，缓解了实例的CPU紧张问题，有效保障数据库实例的业务稳定运行。