Amazon Aurora Serverless v2 在保险 SaaS 应用中的探索和实践

前言

Amazon Aurora Serverless v2 基于无服务器工作负载的自动扩展功能，无需进行复杂的容量规划和过度配置。在数据库层面，Amazon Aurora Serverless v2 可在不到一秒钟的时间内扩展到能够处理数十万个事务的能力。在扩展过程中，系统会以极为精细的增量容量调整，从而确保恰好提供应用程序所需的数据库资源量。

本文通过 Peak3 公司采用 Amazon Aurora Serverless v2 的实践历程，深入探索了 Amazon Aurora Serverless v2 的扩展性、性能、数据库切换等多个维度的表现。

Peak3 简介

在保险行业数字化转型的大趋势下，众安国际科技成立于 2018 年，作为一家金融科技公司，依托国内众安保险的创新经验，打造出了一套支持保险全流程的 SaaS 服务，帮助保险公司进行产品创新和数字化转型。

在 2024 年 6 月 18 日，众安国际科技（ZA Tech）宣布完成 3500 万美元 A 轮融资，并正式更名为 Peak3。

作为全球领先的保险核心系统 SaaS 服务提供商，Peak3 目前已落子全球 12 个国家地区，国际化客户的“朋友圈”不断扩容。在东京、新加坡、德国、丹麦、法国、爱尔兰等 20 个国家地区设有办事处，以科技驱动协助合作伙伴减少营运成本提高生产效率，推动普惠金融提升用户体验。Peak3 基于 Graphene 和 Fusion 两大核心产品解决方案，已与友邦保险、忠意保险、保诚和苏黎世等知名保险公司实现了保险数字化的合作。同时，还与 Carro、Grab、Klook 和 PayPay 等国际领先的数字化平台合作，不断建立和扩展其嵌入式保险业务。

保险行业 SaaS 应用的特点

保险行业对 IT 系统有更严格的要求，主要包括可靠性、高性能和高可用性。可靠性要求具备稳定的基础资源设施和容灾机制。高性能要求 IT 系统快速响应用户的查询和交易请求，以提供良好的用户体验。高可用性需要采用高可用架构，确保出现故障时能够自动快速切换，最小化停机时间。Peak3 的 Graphene 产品是一个云原生的保险 SaaS 平台，采用了多种云原生服务来保障可靠性、高性能和高可用性。目前，Peak3 在东南亚、欧洲、日本等地区都基于亚马逊云科技构建了保险 SaaS 平台，为该地区客户提供了服务。

SaaS 租户对数据库的需求

对于保险业务，核心承保、理赔、定损等业务环节，都会高度依赖保险数据的信息，而保险数据是一组结构化数据，适合使用关系型数据库存储。

Peak3 的 SaaS 平台是面向保险机构的多租户模式，客户通过与保险行业生态中的数字流量平台战略合作，显著提升其在精准数字营销和目标群体流量的竞争力。作为一个 SaaS 服务提供方，Peak3 提供灵活的多租户解决方案和先进的技术架构来帮助保险公司实现数字化转型，所以对数据库层面的可用性、性能、弹性伸缩、数据安全和备份等需求更为突出。同时，对于保险业务数据库，需要能够满足潜在高峰流量的保险业务读写请求。Peak3 希望能够尽可能减少对于基础设施的运维复杂度，也能够在云平台上获得充分的支持来满足保险客户的各类要求。

综合了上述几个需求，Peak3 选择了 Amazon RDS 作为我们的多租户保险业务数据库。那对于每个租户，应该如何选择合适的数据库规格，既能够满足客户潜在高峰流量的保险业务读写，也能够在日常业务稳定运行期间减少资源浪费，降低整体平台的成本呢？

如何规划 SaaS 租户的数据库

在 Peak3 的 SaaS 服务中，我们数据安全隔离措施采用了每个租户一个独立的数据库实例，来支持租户数据的独立性和安全性，并通过 Amazon RDS 的 Multi-AZ deployment 方式来保障生产环境下租户数据库的高可用；同时，我们也针对有异地备份需求的租户，基于 Amazon RDS 的跨区域只读副本的方式建立了跨区域的备份机制，来应对异地数据备份和灾备的需求。

下图简单描述了 SaaS 服务的租户数据库架构：

在数据库的选型和规格配置上，Peak3 会在压测环境根据不同租户的险种配置进行出单理赔等各种业务性能压测，并依据压测结果和监控数据选定合适的规格。

以一个常用的租户为例，经过评估选择了 Amazon RDS 的 4c16G 规格为基准配置。在实际运行过程中，可以通过 Amazon Cloudwatch 服务来监控租户的数据库状态，发现在大部分时间内，租户的数据库均处于一个非常低的负载水平，下图展示了收集了 30 天的 CPU 负载情况（数据库配置 m6g.xlarge）：

可以看到，整体数据库 CPU 负载在大部分时间都在 10% 左右，在某些时间段，由于会进行定时的批处理任务或活动流量推广，负载会有一些突增上升阶段，且峰值会超过 60% 左右，根据此现象我们发现原先的数据库的配置存在一定程度的资源浪费，并且在高峰期间，可能存在潜在的扩容需求。但对于保险租户来说，由于无法预测其保险产品是否会在某些时段由于促销或其他因素而产生大量业务请求从而对数据库产生大量读写需求，也就没有办法直接缩容或随时扩容我们的租户数据库且对业务无感。

那有没有一种数据库，既能够满足在短时间内弹性扩展来应对业务流量高峰，也能够在平时低谷期避免资源浪费呢？Peak3 把目光转向到了 Amazon Aurora Serverless v2，通过调研，发现 Amazon Aurora Serverless v2 的弹性扩缩容的特性，理论上能够帮助租户在业务低谷期避免资源浪费，同时在保险租户业务高峰期能够及时扩容满足数据库的读写需求，那下一步就需要进行实际的测试和评估。

测试评估 Amazon Aurora Serverless v2

在初步调研之后，Amazon Aurora Serverless v2 在 Peak3 使用的 Region 均有提供且完全兼容 MySQL，并且有足够的可靠性来支持业务需求。Amazon Aurora Serverless v2 的计量单位是 ACU，每个 ACU 是约 2 GiB 的内存、相应的 CPU 和网络的组合。用户可以配置最小 0ACU 到最大 256ACU 的容量范围，每当写入器或读取器扩缩时，容量会增加或减少。使用 ServerlessDatabaseCapacity 和 ACUUtilization 指标能够监控数据库使用情况。

为了验证 Amazon Aurora Serverless v2，Peak3 进行了两方面的测试，扩展速度和性能表现。

一、Amazon Aurora Serverless v2 扩缩速度压测分析

使用 sysbench 压测工具，配置 16 线程 8 张表，每张表 1000 万条记录持续 600s 进行测试。针对随机 oltp_read_write 动作进行性能测试。以下是 Aurora serverless v2 配置 ACU 容量（0.5-8）压测扩缩详细情况及资源使用率监控分析：

ACU 容量灵活的秒级弹性扩容能力

从秒级别的监控图中可以看出，当压测线程开启后，ACU 从 0.5 探测到负载上升后 2 秒内快速扩容到 6 ACU，随着 tps 和 qps 的升高，ACU 也在 6-8 之间波动扩缩，确保能够应对突发的流量高峰请求，ACU 容量扩容期间不会影响任何在执行的事务连接，在整个压测期间未发现任何的连接异常情况。

优雅的自动收缩阶梯形态

待 600s 压测完成后，ACU 呈阶梯状缓慢缩容，大概每 3 分钟左右下降一个台阶缩容一次，每次收缩 1-2 个 ACU，直到降到 0.5 ACU。避免了不必要的资源和成本浪费，同时降低资源成本的费用支出。

二、Amazon Aurora Severless v2 和 RDS Instance MySQL 压测性能对比

压测环境基础配置情况

Amazon Aurora Serverless v2 分别使用容量 ACU（0.5-8）和 ACU（1-16）配置进行压测。
Amazon RDS instance MySQL 分别使用 4c 16G 和 8c 32G 的 single az 配置进行压测，EBS 使用 gp3 100G。
sysbench 压测工具配置不同的线程，8 tables，1000w rows，600s 时间分别到 Amazon Aurora Serverless v2 和 Amazon RDS instance MySQL 上执行随机的读写操作，并输出执行的性能结果。
根据不同 DB 类型和 CPU，参照内存大小接近的方式比对压测结果及性能。
MySQL 版本选择为 MySQL 8，对应 Aurora Serverless v2。

不同配置压测数据对比

下图展示了不同压测条件下的数据库表现对比，包含了 16G 和 32G 内存的两组不同的配置。对于保险数据库，由于业务特点，我们更关注保单生成的响应时间，以及同时能够完成承保操作的并发量，因此在数据库性能指标上，写的性能和延迟更为重要。
以下是详细测试数据：

Amazon Aurora Serverless v2 的测试结果和成本

从上述的两个测试过程和结果来看，可以得到以下几点：

Amazon Aurora Serverless v2 的弹性扩容速度很快，1-2 秒内就能探测到负载上升随之扩大到需求的 ACU 容量。没有发现在扩容和缩容时间范围内导致数据库连接失败或事务失败的错误信息，因此扩缩动作不会影响业务使用。
在 16G 内存配置下分别使用 8、16、32 线程进行压测，Amazon Aurora Serverless v2 整体的 QPS、TPS、Response time 指标性能上会优于 Amazon RDS。同时，Serverless 模式下，ACU 使用率基本很高，能够充分发挥出性能。
Amazon Aurora Serverless v2 的 buffer pool size 会随着内存的扩缩而调整变化，这可能会影响某些读取操作的性能。然而，这个问题可以通过适当的预热策略来缓解。本次压测结果显示，在 OLTP 读取操作方面，Serverless 模式可能与传统的 m 系列 RDS 实例有所不同。不过，值得注意的是，Serverless 模式在 OLTP 写入操作上表现出色，性能明显优于 Amazon RDS 实例。
单个租户使用 Amazon RDS instance 的成本和 Amazon Aurora Serverless v2 的成本分析，整体每个租户预估可以节省 15% 的成本（以 m6g.xlarge 一年期 No Upfront RI 的价格为基础进行对比）。

最小化停机迁移 Amazon Aurora Serverless v2 方案

在确定了使用 Amazon Aurora Serverless v2 之后，我们需要考虑怎么确保在 SaaS 生产环境中进行对客户业务影响最小的切换方式。为了实现生产业务最小化停机迁移 Amazon Aurora Serverless，我们设计使用 Amazon Route53 CNAME 解析域名切换的方式来快速变更目的数据库 endpoint。下面是迁移架构图及步骤概述：

在控制台的 Amazon RDS MySQL 创建一个 Amazon Aurora MySQL instance 只读副本，能够数据实时同步到 Amazon Aurora MySQL 上。
修改 Amazon Aurora MySQL instance 类型为 serverless 类型。
在- Amazon Route53 上新增一条 dns 域名和 cname 解析记录，并设置为 Amazon RDS endpoint，TTL 设置最短 60s。
修改服务连接的 Amazon RDS 地址为 Amazon Route53 上新增的域名地址，重启服务生效。
在业务低峰期，修改 Amazon RDS instance 参数组 read_only 参数为 true，等待 replica Lag 为 0，再 promote Amazon Aurora serverless 为独立集群，接着修改 Amazon Route53 的 DNS cname 解析记录为 Amazon Aurora Serverless endpoint。
在 DNS cname TTL 60s 解析生效后，重启原 RDS 实例，所有服务自动连接到新的 Amazon Aurora Serverless 集群上。新集群切换和业务恢复完成。

总结

通过对 Amazon Aurora Serverless v2 的测试和验证，我们发现对于业务流量无法预测的保险客户，非常适合使用这个服务，既能够在秒级别提升容量来应对业务高峰，也能够在日常流量低谷期节约资源，降低成本，同时在性能方面也能够满足保险客户的大部分场景。

作为保险核心系统下一代 SaaS 服务解决方案提供商，Peak3 采用 Amazon Aurora Serverless v2 作为保险业务数据库。这种云原生数据库服务具备弹性伸缩的能力，可以根据业务需求自动调整计算资源。在互联网保险业务的高峰期间，如批量出单或营销活动时，系统可以无缝扩展资源，确保用户体验不受影响。同时，在业务稳定期，资源也可以自动缩减，避免了资源浪费，帮助公司实现了运营降本增效的目标。Amazon Aurora Serverless v2 的这一优势，使得保险公司能够轻松应对互联网业务的高峰需求，为客户提供稳定高效的服务体验。

亚马逊AWS官方博客