亚马逊云科技-Aurora Serverless云数据库

关键字: [亚马逊云科技， Aurora Serverless， Aurora Serverless 数据库， 自动扩缩容机制， 容量单元 Acu， 扩缩容影响因素， 动态伸缩架构]

导读

张靖宇老师在本次演讲中介绍了亚马逊云科技的Aurora Serverless云数据库。他首先回顾了Aurora的发展历程，解释了为什么需要Serverless数据库。接着详细阐述了Aurora Serverless的自动扩缩容机制，包括ACU容量单元、扩缩容触发条件、扩容方式和速率等。他还介绍了Serverless实例对Aurora传统架构的影响，以及与亚马逊云科技其他服务如Global Database和Data Pipeline的集成应用。最后由郑明明老师分享了Aurora Serverless在亚马逊云科技区域的实践经验。整个演讲重点阐释了Aurora Serverless如何实现资源利用率优化、成本节约，并支持弹性扩缩以满足业务需求。

演讲精华

以下是小编为您整理的本次演讲的精华。

根据视频标题“亚马逊云科技-Aurora Serverless云数据库”和字幕内容，我将以叙事风格详细阐述本视频的主要内容。

大家下午好，我是亚马逊云科技数据库产品经理张靖宇。今天我将与同事解决方案架构师郑明明老师一起，为大家介绍如何利用亚马逊Aurora Serverless数据库来构建可扩展和成本优化的应用。

我们今天将分享5个主要内容:

1. 首先，我们将回顾一下Aurora的整体情况，包括它的发展历史。
2. 然后，我们将探讨在已有Aurora的情况下，为什么还需要一个Serverless数据库。
3. 在Serverless中，最重要的概念是自动扩容。我们将详细展开自动扩容相关的机制。
4. 接下来，我们将看看Aurora Serverless这样的特性对于Aurora已有的架构会带来哪些改变。
5. 最后，郑明明老师将分享Aurora Serverless V2在亚马逊云科技北京区域保险行业的落地应用经验。

让我们首先看一下Amazon Aurora。Aurora是一个兼容MySQL和PostgreSQL的云原生数据库，它最大的特点是享有与商业数据库同等的性能和可用性，但成本却低得多。Aurora也是亚马逊云科技所有服务中增长最快的一个。

我们可以回顾一下Aurora的十年创新之路。早在2014年，我们率先提出了存算分离的概念，并发布了兼容MySQL数据库的Aurora版本。随后在2018年，我们很早就提出了将Serverless应用于关系型数据库的概念，并发布了Aurora Serverless的第一个版本。时间再往后发展，到了2022年，我们进行了Serverless的一个重大迭代，发布了第二个版本。所以我们现在看到的Aurora Serverless实际上已经经过了7到8年的打磨和迭代，也经过了市场和众多客户的检验。

我们刚刚大概看了Aurora和Serverless的特性，接下来我们将探讨为什么需要Serverless这种关系型数据库。

(图示说明)

假设我们有一个固定规格的数据库实例，无论把这条横线的配置拉高还是降低，你始终无法同时解决成本和弹性扩缩的两个问题，这也是需要Serverless的一个重要原因。

Serverless主打的是按需和自动扩缩配置，代表着它不是一个固定规格。比如说，当资源需求增加时，它可以扩容;需求减少时，它可以缩容，同时它是按秒计费，所以它的计费颗粒度和容量波动都是非常灵敏的。在这种情况下，我们就不再需要手工或根据经验配置一个固定规格实例。

接下来，我们将深入探讨Serverless自动扩缩容这一部分的内容。

在谈自动扩缩容之前，有一个前置条件是按什么颗粒度或标准来进行扩缩容?所以我们有第一个概念叫ACU，即Aurora Capacity Unit。一个ACU相当于2GB内存以及与之匹配的CPU、网络资源。它实际上是我们定义的一个容量单元。用户在使用Serverless时，只需要设置最小和最大ACU，Serverless会根据业务负载的需求，动态调整容量值。

值得注意的是，最小容量是一个事实存在的容量，也就是说，当设置完最小容量后，这个最小容量会一直保持。但最大容量是一个容量上限值，实例在波动过程中始终不会突破这个上限。

我们最近发布的新特性之一就是支持将ACU缩小至0个ACU，意味着在某个时间点，集群中的某个实例实际上没有分配计算资源。基于此，0 ACU是没有任何费用的。我们可以设置连接数为0，比如在接下来的5分钟或10分钟内，设定一个自动缩零的策略。当它缩小到0时，如果有新的连接或请求进来，Serverless会在15秒内自动恢复，类似于有一个sleep或wake up的过程。所以这是我们对最小ACU的一个新特性。

另一方面，Serverless上限最大可以支持到256个ACU，按照前面1:2的CPU和内存配比，这相当于一个512GB内存的实例，规格已经相当大，我们认为它能够满足绝大多数业务对容量的需求。对于过去创建的Serverless数据库或集群，以及未来创建的数据库实例，都可以支持这样的上限和下限，当然有版本要求。所以现在我们拥有了一个下限可以为0 ACU(没有计算资源)、上限可以达到256个ACU(非常大的容量资源)的Serverless数据库。

有了这个前提，我们可以看看Serverless在弹性扩缩时，有哪些因素会影响它的伸缩。主要有三大因素:CPU、内存和网络吞吐。对于Serverless实例来说，当这三个主要维度中任意一个维度资源不足时，都会触发扩容。缩容则是相反，必须是三个影响因素都出现了，比如当前ACU数量大于实际需求时，才会进行缩容。所以扩缩容的基础逻辑是由这三个主要要素构成的。

另外，在扩容的方式上也发生了一些变化。过去，如果要从一个固定规格实例切换到另一个固定规格，需要短暂停机进行failover或split brain操作。但对于Serverless来说，它的容量定义是在线容量，不需要停机。假设资源不足时，我们的系统会自动为它分配更多资源，所以在扩容过程中，正在运行的数据库负载或请求不会受到影响。

此外，Serverless支持以0.5个ACU的颗粒度进行扩容。0.5个ACU相当于1GB内存，比如我们有一个4个ACU的集群正在运行，如果业务轻微波动，我们可以扩展到4.5个ACU，就能满足那个轻微波动的需求。0.5 ACU的颗粒度还可以保证实例扩缩容和业务实际需求之间曲线的拟合度，让它非常贴近实际需求。

关于扩容时间，Serverless是秒级响应进行扩容，因为它整个监测逻辑都是秒级单位。至于扩容速度，大家可以想象一下，Serverless就相当于在一个桶里注水，随着水量增多，桶的实际容量肯定会扩大，这非常好理解。关于扩容速率，就像注水的填充速率一样，也会随着水量增多而加快。也就是说，可以想象水桶里面水逐渐增多，出水速度也逐渐增快，以尽快填充业务对容量的需求。所以Serverless的动态扩容速度是一个加速扩容，而不是静态恒定速度扩容。

另外，在扩缩时，除了CPU或网络，还有一个关键影响维度是缓冲池。比如在MySQL引擎里有innodb_buffer_pool_size概念，当扩容时，内存增多，缓冲池空间也会加大。但当缩容时，由于内存缩小，会导致缓冲池把一些数据页裁剪或丢弃掉，所以我们采用LFU和LRU算法，以保证缓冲池里始终缓存最热数据，来保证业务性能。

在实际应用上，我们可以通过CloudWatch和Performance Insights监控，看到比如Serverless database capacity当前ACU消耗情况、最小最大值、CPU利用率、内存使用情况，甚至某个时间点ACU消耗和相关活动。这些监控都在解释一件事情，就是我们的最小ACU是否合理满足业务需求，最大是否足够，以及从最小到最大的波动过程是否符合预期。

接下来讲一下，Serverless实例对于Aurora的传统架构会带来什么变化。首先Serverless它是一个动态伸缩实例，从功能上和预制规格实例没有区别。但当我们把传统架构移植为Serverless时，就会发生一些有趣的应用。

比如一个常见架构是一个写入实例、一个只读实例，都是固定规格如R6G。在同一个集群里，我们可以直接挂载一个Serverless类型的只读实例对外提供服务。并且写入实例的failover有时会优先向只读实例failover，所以Serverless实例不会影响failover结构。对于这种Serverless实例应用，一些OLAP查询、批处理作业或只读作业都可以应用。

但如果发现整个集群资源利用率不高，我们也可以把它全部换成Serverless实例，因为Serverless和固定规格实例之间只需一次failover就可以轻松转换。不过需要注意，当整个集群全是Serverless实例时，为保证高可用，写入实例和只读实例的配置资源在任何时候都是完全一致的，以保证failover后有足够资源减少停机时间。但中间那个只读实例不受影响，它根据自身读取流量动态变化。

另一个话题是Serverless驱动的Aurora Global Database架构。不知道大家有没有用过Global Database，它可以跨区域进行数据复制或传输。比如区域1和区域2，想象一下是新加坡到香港。在Global Database架构里，跨区域只读副本延迟可以做到1秒内，最多可扩展5个被区域，在整个集群下最多可挂90个只读实例。当灾难发生时，切换时间小于1分钟。

在被区域里，往往可能没有太多工作负载，这很常见，因为不可能每个区域工作流和负载都1:1。所以我们建议用户在被区域的只读实例采用Serverless，并将下限设为0 ACU。在这种情况下，如果被区域没有工作负载、查询或批处理作业，Serverless就会缩为0，不会计费。但一旦有实际业务请求，它会被激活重新扩展对外提供服务，这是一个非常灵活动态的配置策略。

最后是Serverless和Amazon Data Pipeline的集成架构。不知道大家了解Amazon Data Pipeline吗?它可以从Aurora数据库全自动同步数据到Amazon Redshift，无需人工干预，只需简单配置。因为前面介绍了Redshift Serverless是面向数据分析查询的AP数据库引擎，而Aurora本身是一个TP库，当我们用Data Pipeline把两者联系起来时，我们得到了一个在数据层面从TP到AP的全站Serverless化架构。不管是TP作业还是AP作业，它的资源利用率和弹性扩缩都会变得整体更优秀。

以上就是全部内容，接下来时间交给解决方案架构师郑明明老师分享Serverless在亚马逊云科技北京区域的落地和实践。

总结一下，本次分享主要介绍了亚马逊Aurora Serverless云数据库的发展历史、需求背景、自动扩缩容机制、对传统架构的影响，以及与其他亚马逊云科技服务的集成应用。Aurora Serverless通过按需自动扩缩容，可以满足业务需求的同时优化资源利用和成本，是一种高度灵活和经济的云数据库解决方案。

下面是一些演讲现场的精彩瞬间：

Amazon Aurora 经历了十年的创新历程，从提出存算分离概念到推出兼容 MySQL 的 Aurora 版本，再到引入 Serverless 关系型数据库并不断迭代优化。

The speaker explains the concept of Aurora Capacity Unit (ACU)， which defines a capacity unit with 2GB of memory and matching CPU and network resources， used for auto-scaling in Amazon Aurora Serverless.

云数据库 Serverless 版本现在支持将计算资源缩小到 0 ACU，实现按需付费，节省成本。

总结

亚马逊云科技的 Aurora Serverless 云数据库为企业提供了一种全新的数据库解决方案。这种无服务器数据库能够根据实际业务需求自动扩缩容，实现了资源利用的最优化。它采用了 ACU (Aurora Capacity Unit) 作为容量单位，可以在 0.5 ACU 的精细粒度下动态调整计算资源，确保资源供给与业务需求的高度契合。Aurora Serverless 不仅在成本方面具有优势，而且在架构上也带来了诸多创新，如与 Amazon Data Pipeline 的集成、跨区域 Global Database 的部署等，为企业构建高效、弹性的云数据库系统提供了新的可能性。通过 Aurora Serverless，企业可以摆脱手动配置资源的繁琐，专注于业务创新，真正释放云计算的潜能。

Aurora Serverless 的自动扩缩容机制是其核心优势所在。它会根据 CPU、内存和网络吞吐等三大因素的实时状况进行动态调整，确保资源始终处于最佳利用状态。在扩容过程中，不会影响正在运行的数据库请求，实现了无缝扩展。而缩容时，则会采用 LFU 和 LRU 算法，保留热数据在缓冲池中，从而维持性能水平。通过 CloudWatch 和 Performance Insights，用户可以全面监控 Aurora Serverless 的运行状况，优化资源配置策略。

Aurora Serverless 不仅可以作为独立的数据库实例使用，也可以与传统 Aurora 架构相结合，发挥更大的潜能。例如，在一个包含写入实例和只读实例的集群中，可以将只读实例替换为 Serverless 实例，满足只读查询和批处理作业的需求。如果整个集群的资源利用率不高，则可以将所有实例都转换为 Serverless 模式，实现整体资源优化。此外，Aurora Serverless 还可以与 Aurora Global Database 架构相融合，在被区域的只读实例上采用 Serverless 模式，实现跨区域的高可用和成本优化。

我们正处在Agentic AI爆发前夜。2025亚马逊云科技中国峰会提出，企业要从“成本优化”转向“创新驱动”，通过完善的数据战略和AI云服务，把握全球化机遇。亚马逊将投入1000亿美元在AI算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在AI时代突破。