亚马逊云科技：云原生数据库极致弹性体验-Amazon Aurora Serverless v2

一、前言

Aurora Serverless是Amazon Aurora的按需自动扩展配置。Aurora Serverless v2在几分之一秒内将数据库工作负载扩展到数十万个事务。它以细粒度的增量调整容量，为应用程序的需求提供适量的数据库资源。您无需管理数据库容量，只需为应用程序消耗的资源付费。早在2018年Amazon Aurora即提供了Serverless选项。

Amazon Aurora最新提供的Aurora Serverless V2版本相比于上一代V1版本更上一层楼，重点提升部分：资源容量采用原地扩展，使资源容量扩展速度由V1分钟级提升到秒级，v2版本能够在容量调整时做到更细粒度，以0.5 ACU作为扩展单元（V1翻倍扩展），并能够依据多个维度进行容量调整，通过持续的监控和尽可能大的利用缓冲池。Aurora Serverless v2相比V1增加了完整的Amazon Aurora功能，包括多可用区支持、只读副本和全球数据库等，支持跨AZ和跨区域的高可用部署和读取扩展。

Amazon Aurora Serverless v2非常适合各种应用程序。例如，面对业务快速增长场景与海量多租户场景时，当拥有数十万个应用程序的企业，或拥有具有成百上千个数据库的多租户环境的软件即服务(SaaS)供应商，可以使用Amazon Aurora Serverless v2来管理整个SaaS应用中众多数据库的容量，同时还适用于业务吞吐量波动明显的场景，如游戏业务、电商业务、测试环境等，以及无法预估吞吐量的新业务系统。对于大部分时间都处于低谷的业务系统，Amazon Aurora Serverless v2可以有效地为客户节省成本。

作为新一代云原生无服务数据库，Aurora Serverless V2提供了无与伦比弹性伸缩性，动如脱兔；同时也提供了面向企业级应用的坚不可摧的高可用性，静若磐石。

本篇重点会围绕着Aurora Serverless V2的弹性伸缩和高可用特性，展开测试和分析，进一步向您展示Aurora Serverless V2的特点。

二、测试

2.1 扩展性测试

2.1.1 测试目标

● Aurora Serverless V2随负载变化的弹性伸缩能力

● Aurora Serverless V2与V1弹性伸缩能力比较

Aurora Serverless 资源扩展以ACU为单位，关于ACU定义：

● Aurora Capacity Unit(ACU)用于测量Aurora Serverless所分配资源容量

● 1个ACU有2 GiB的内存，同时具有相应的CPU和网络等资源，CPU、网络和内存的配比与预置Aurora实例相同

● Aurora Serverless V2启动容量可以最低设置成0.5 ACU（1 GiB内存），最高ACU支持设置为128

2.1.2 测试结果和分析

模拟负载波峰波谷，采用sysbench读写负载，基于不同线程压测10/100/50/600/10，每轮压测120秒，观测在初始20秒Aurora Serverless V2/V1资源扩展情况：

轮次	线程数	测试结果观测 (V2/V1 Min ACU:4/Max ACU:32)
1	10	V2 随着负载启动 在第12秒开始扩展 ACU (由初始值min ACU:4 扩展至ACU:10) V1 随着负载启动 在第120秒开始扩展ACU V2:V1 ACU随负载变化 V2相比V1按需扩展速度提升10倍 V2 随着负载启动 按需扩展ACU 数据库引擎缓存池(innodb_buffer_pool_size)也随之变化 V2 随着ACU扩展 性能不断攀升 在第53秒趋于平稳 第一轮测试结束 V2 ACU扩展至10/Innodb_buffer_pool_size 扩展至10.21GB/ Max Connections  恒定保持3000 （max connections由max ACU值决定 整个测试max ACU=32没有变化）
2	100	V2 随着负载增加 在第7秒开始扩展 ACU V1 从整个测试开始 在第120秒刚开始扩展ACU V2 ACU 扩展 采用细粒度扩展 以0.5为增加单元 V1 ACU 扩展 采用翻倍扩展 4 扩展至8 第二轮测试结束 V2 ACU扩展至 17
3	50	此轮压测前 V2/V1 ACU 已经扩展至 17/8 已基本满足50线程压测 整轮测试 V2/V1 ACU相对比较平稳 第三轮测试结束 V2 ACU扩展至 22.5
4	600	在600线程高并发负载压测下 V1运行三次 尝试在30秒内启动运行 均未成功 sysbench 放弃 退出此轮测试 在600线程高并发负载压测下 V2运行三次 二次成功运行 V2 随着负载增加 在第8秒开始扩展 ACU 第四轮测试结束 V2 ACU扩展至 30
5	10	第五轮测试开始时 V2/V1 ACU已扩展至 30/16 已满足10线程压测需求 整轮测试 ACU和性能相对平稳 负载降低 V2 ACU 会逐步下降 相对于上升扩展 下降回缩速度会更加平稳 从压测结束 ACU降低到min  ACU:4 大致经历18分钟

测试过程中 CloudWatch Dashboard监控指标：

 

观测结果：V2 CPUUtilization与ServerlessDabaseCapacity曲线拟合度非常高，ACU值随着CPU指标变化而变化，特别是负载上升期间CPU上升ACU可达到瞬间上升；CPU下降时ACU值相对平稳下降

V1 ServerlessDabaseCapacity扩展相对于CPUUtilization扩展有一定的延迟和滞后

V2/V1总体性能比较：

 

 

 

 

 

由于Aurora Serverless V2系统扩展更敏捷负载上升V2始终获得比V1更高的资源配置（ACU）因而Aurora Serverless V2相比V1在不同压测场景 性能提升1.5-3倍(TPS & QPS)同时V2采用MySQL 8.0 V1采用MySQL 5.7版本不同，性能表现也会有所差异。

扩展速度测试：

将V2 Min ACU设置成8ACU和4ACU查看ACU扩展速度是否有提升，测试负载sysbench读写、线程数采用恒定值100运行15分钟。

运行次数	Min acu	Max acu	线程数	ACU第n秒开始扩展
1	8	32	100	4 （第一次扩展至9）
2	4	32	100	14 （第一次扩展至10）

测试观察：

ACU扩展速度与Min ACU或者当前数据库的ACU值相关ACU值越大，扩展速度越快

2.1.3扩展性测试总结

● Aurora Serverless V2采用即时原地扩展 随负载变化可实现敏捷扩展  实现秒级ACU扩展

● 实现细颗粒度资源扩展 以0.5ACU 为扩展单元

● Aurora Serverless V2 ACU 资源扩展同时，其它相应资源， 例如数据库引擎缓存池innodb_buffer_pool也实现动态扩展

● ACU 扩展速度 与min ACU 或者当前数据库的ACU值相关 ACU值越大 扩展速度越快

● Aurora Serverless V2 资源扩展速度敏捷 回缩相对平稳 以保障系统负载平稳支撑

● Aurora Serverless V2 vs V1

● 总体性能提升5-3倍

● 资源扩展速度提升10-15倍

● 扩展单元更细粒度

● 在高并发场景 可平稳运行

2.2读副本测试

Aurora Serverless V2增加了读副本功能 可以通过增加读副本 最多可创建15个读副本 实现跨AZ容灾以及读负载扩展； Aurora Serverless V2 的高failover优先级读副本（Tier 0/1）ACU会随着主节点ACU伸缩 从而保障在主从负载故障切换后 快速承载主节点负载；Aurora Serverless V2 低failover优先级读副本（Tier 2-15）ACU不会随着主节点ACU伸缩 会依据自身实例负载实现资源ACU伸缩

2.2.1 测试目标

● Aurora Serverless V2 tier 0/1 读副本是否会随着主节点ACU扩展而扩展

● Aurora Serverless V2 tier 2-15 读副本负载是否会独立主节点而扩展

● Aurora Serverless V2 主从节点切换时间

2.2.2 测试结果和分析

创建一主两从Aurora Serverless V2集群 读副本failover级别分别为Tier 0和Tier 15 （Min ACU:4;Max ACU:32）:

轮次	测试内容	测试结果观测
1	只在主节点添加sysbench读写压力	主节点ACU 随着sysbench压测变化 在不断发生变化， Tier 0的读副本的ACU也在随着主节点的ACU的变化不断变化， Tier 15的读副本的ACU不会随着主节点的ACU的变化而变化，在无负载的情况下，ACU持续平稳保持在4. Tier 0的读副本CPU 并不会随着主节点的CPU变化而变化
2	在主节点添加恒定的sysbench读写压力（线程为100）, 在Tier 15的读副本上 添加（线程为10）的恒定的sysbench只读压力	主节点ACU 随着sysbench压测变化 在不断发生变化， Tier 0的读副本的ACU也在随着主节点的ACU的变化不断变化，两者ACU值基本一致; Tier 15的读副本的ACU会独立变化，不会随着主节点的ACU的变化而变化
3	在主节点手工做Failover 观测在多少时间主从切换至Tier 0 读副本	手动做failover 会切换到Tier 0读副本 切换时间大致6秒 (切换过程中 查询脚本有6秒获取不到信息)

2.2.3读副本测试总结

● Aurora Serverless V2 通过读副本 可实现跨AZ 高可用性 主从切换时间在秒级

● Aurora Serverless V2 通过读副本 实现读负载的水平扩展

● Tier 0/1 读副本的ACU也在随着主节点的ACU的变化不断变化 两者ACU值基本一致 可保障主从切换后 资源充足供应

● Tier 2-15读副本读副本的ACU会独立变化，不会随着主节点的ACU的变化而变化

2.3 全球数据库测试

Aurora Serverless V2增加了全局数据库功能 可以通过增加全局数据库 实现跨区域容灾以及就近本地读访问； 全球数据库采用物理复制方式以及通过亚马逊云科技跨区域主干网高效传输数据 使得跨区域数据复制延迟低 小于1秒；容灾发生时 可以在分钟级将从集群提升为主集群；一个主集群 可建最多达五个从集群 主从集群总共可以创建多达90个读副本

2.3.1 测试目标

● Aurora Serverless V2 全球数据库： 主集群上运行读写负载 在从集群上运行只读负载 观测主从集群ACU 变化

● Aurora Serverless V2 全球数据库： 在主集群上运行高并发只写负载 在从集群上观测主从集群复制延迟

● Aurora Serverless V2 全球数据库：执行Managed Planned Failover操作观测Failover所需要时间

2.3.2 测试结果和分析

● 主集群（4 ACU-32 ACU）在美东1

● 从集群 （4 ACU – 32 ACU）在美西2

轮次	测试内容	测试结果观测
1	在主集群添加恒定的sysbench读写压力（线程为100）, 在从集群添加（线程为10）的恒定的sysbench只读压力	从集群的ACU会随着自身负载变化而独立变化，不会随着主集群的ACU的变化而变化
2	在主节点添加恒定的sysbench只写压力（线程为100）, 在从集群上观测复制延迟	随着主集群写负载上升 从集群的负载相对独立 不会随着主集群的负载上升 在主集群写压力比较大的情况下 主从集群复制延迟 保持在低位 在200毫秒左右
3	执行Managed Planned failover(从us-west-2切换回us-east-1) 观测主从切换所需时间	手动做failover从us-west-2切回到us-east-1并使从集群的cluster endpoint可用 总体切换时间大致3分钟

2.3.3全球数据库测试总结

● Aurora Serverless V2 通过全球数据库 可实现跨Region 高可用性 主从切换时间在分钟级

● Aurora Serverless V2 通过全球数据库实现跨区域容灾和就近数据访问

● 从集群的ACU会随着自身负载变化而独立变化，不会随着主集群的ACU的变化而变化

● 主从集群复制延迟比较低 通常保持在200毫秒左右

三、迁移数据库到Aurora Serverless V2

3.1 选择Aurora Serverless V2的理由

选择Aurora Serverless V2 有众多益处， 以下从四个方面概括阐述选择Aurora Serverless V2的理由：

1.高度可扩展

创新的云原生无服务数据库，实现数据库的弹性伸缩，进一步简化客户创建、维护和扩展数据库，实现高度扩展性及自动伸缩容量。

Amazon Aurora Serverless v2采用即时原地扩展技术，在扩展性方面比上一代更上一层楼，可以立即扩展以支持最苛刻的应用程序，瞬间扩展不到一秒时间，即可将数据库工作负载由支持几百个事务扩展至支持数十万个事务。

2.提供面向企业级应用高可用性

Aurora Serverless V2提供所有的 Aurora 功能，包括回溯、克隆、全球数据库、多可用区部署以及只读副本等，满足业务关键型应用程序的需求，可以通过创建只读副本实现跨多可用区高可用性，实现秒级跨可用区故障切换；可以通过创建全球数据库实现跨区域高可用性，实现分钟级跨区域故障切换，可提供面向企业级应用高可用性。

3.易管理

Aurora Serverless V2可按需自动扩展，根据应用程序的需求自动扩展或缩减容量，简化客户创建、维护和扩展数据库， 不再需要进行复杂的数据库容量预置和管理， 数据库会根据应用程序的需求自动扩展资源。

4.经济高效

Aurora Serverless V2可以以细粒度的0.5 ACU增量资源扩展，确保恰好提供应用所需的数据库资源量，并且仅为使用的容量付费，同时Aurora Serverless V2可按秒计费， 实现更细粒度计费模式。

3.2 如何迁移数据库到Aurora Serverless V2

版本要求：

Aurora Serverless V2 MySQL: Aurora MySQL 3.0.2及以上 （兼容MySQL 8.0）

Aurora Serverless V2 PostgreSQL: Aurora PostgreSQL 13.6及以上

迁移：

迁移场景1: 将预置模式Aurora集群迁移到Aurora Serverless V2

 

Aurora Serverless V2 支持集群里采用灵活的混合配置架构， 即主节点可以是预置模式实例， 读节点是Aurora Serverless V2实例； 同时也支持主节点是Aurora Serverless V2实例， 读节点是Aurora预置模式实例

迁移方法：创建Aurora Serverless V2混合配置架构 通过主从切换将预置模式主节点实例转换成Aurora Serverless V2实例：

 

● 将Aurora 预置模式主节点升级到Aurora Serverless V2所需版本

● 在集群级别设置Min ACU和Max ACU

● 增加实例类型为Serverless读副本 (Failover级别：Tier 0/1)

● 执行主从切换: Provisioned Writer变成Provisioned Reader; Serverless Reader变成 Serverless Writer

迁移场景2: 将Aurora Serverless V1迁移到Aurora Serverless V2

迁移方法：通过创建快照迁移

 

● 基于Aurora Serverless V1创建快照

● 基于快照恢复预置Aurora集群

● 将Aurora 预置模式主节点升级到Aurora Serverless V2所需版本

● 在集群级别设置Min ACU和Max ACU

● 增加实例类型为Serverless读副本 (Failover级别：Tier 0/1)

● 执行主从切换: Provisioned Writer变成Provisioned Reader; Serverless Reader变成 Serverless Writer

四、总结

本篇重点展示了Aurora Serverless V2作为新一代云原生数据库特点：高度可扩展性-动如脱兔，以及面向企业级应用高可用性-静若磐石；当云原生数据库Aurora深度融合无服务，必将数据库创新做到极致！