关键字: [ 亚马逊云科技中国峰会2024, Amazon Aurora Serverless, 无服务器数据库架构, 工作负载波动应对, 细粒度扩展能力, 高可用故障转移, 跨区域灾备成本]

本文字数: 4600, 阅读完需: 23 分钟

导读

在本次亚马逊云科技中国峰会2024 上, 演讲者介绍了无服务器数据库架构与应用实践, 重点讲解了Amazon Aurora 和ElastiCache 的无服务器架构特点及应用场景。他们解释了无服务器数据库可以即时在线扩展、细粒度扩展以及提供高可用性, 适用于新业务上线、业务负载波动、微服务/SaaS 应用和临时性工作负载等场景。此外, 美团工程师分享了在Aurora Serverless 上的最佳实践, 包括容量预热和数据预热, 以应对业务高峰时的流量波动, 从而降低成本。

演讲精华

以下是小编为您整理的本次演讲的精华，共4300 字，阅读时间大约是22 分钟。

大家下午好, 我今天演讲的题目是无服务器的数据库架构。这个讲座由我和美团的首席研发工程师黄岩硕老师一起讲, 就这位戴红帽子的很酷的黄老师。

今天议程分两个部分: 首先, 我会介绍亚马逊的整个无服务器数据库家族。接下来, 我会重点讲一下Amazon Aurora 和ElastiCache 的无服务器架构特点, 以及它们的应用场景。最后一部分由黄老师重点讲解美团使用Amazon Aurora Serverless 数据库的最佳实践。

数据库面临的挑战之一实际上是面对有波动或不可预测的流入工作负载, 因为这种情况下很难设置合适的数据库容量。如果设置过高, 按照峰值来配置, 可能造成资源浪费; 如果设置过低, 在峰值时无法应对业务需求, 这是数据库面临的挑战之一。通常来讲, 要应对这种业务负载波动,Serverless 是目前的一个好办法。

在亚马逊云科技, 从整个计算层一直到数据库层, 都有一个完整的Serverless 解决方案。在数据库这一层, 我们很多数据库服务已经具备了Serverless 特性。亚马逊实际上已经有超过16 种以上的数据库引擎, 包括关系数据库、非关系数据库, 其中支持Serverless 特性的数据库引擎已经有8 种, 包括关系数据库、缓存, 还有一些其他的Key-Value 数据库, 基本上你各种应用场景, 只要你享用到了Serverless 特性, 我们都有相应的数据库来支持你的需要。

我们重点看一下Aurora 的Serverless 架构。实际上亚马逊在2018 年就推出了针对关系数据库Aurora 的Serverless V1 第一个版本, 大概是六年前。在大概2022 年, 就两年前, 我们又推出了新的Serverless V2 第二版这个架构。 第二版的架构跟第一版有大幅的提升, 它基本上跟我们标准的Aurora 集群的架构是一致的。

我们知道标准的Aurora 数据库集群, 实际上大概来讲它就是上下分两层。上面这一层是计算层, 它会跨三个可用区, 可以部署多个计算节点, 其中包括一个主节点和多达15 个的只读副本。下面一层是个存储层, 存储层是我们会跨3 个可用区存储6 个副本, 然后这个存储层和计算层是相互独立来扩展的, 相互不影响。你存储层你可以独立来扩展它的IO 以及存储空间, 你不用停机, 不影响计算层。同样的计算层你也可以纵向扩展或者横向扩展, 你也不影响存储层。

现在我们Serverless V2 跟我们的标准版已经做了一个整合, 在一个Aurora 集群里面, 你可以完全是一个标准的实例类型, 也可以是完全是Serverless 的一个实例类型, 或者根据你的需要可以来进行混合部署, 有一部分节点可能是一个标准的预留实例类型, 那有一些节点可能是一些Serverless 的一个节点类型, 这样的话最大程度地满足一些变化的工作负载的需要, 同时可以省钱。

具体来看,Serverless 有几大关键的点, 给我们的客户带来一些好处: 首先它是一个即时的在线的扩展, 当工作负载来的时候, 它可以快速地扩展, 在不到一秒的时间内就可以快速扩展到数以十万计的事务。同时的话, 它这个扩展是不停机的, 这对业务就是没有一个侵入。第二个特点是它的一个细粒度的扩展能力。因为我们知道, 实际上不管是计算层还是数据库层, 你扩展总是有些办法的, 但是那以前的扩展可能不够及时, 这是刚才讲到的。第二个方面, 可能的力度不够细, 力度不够细的话, 你流量一进来, 它扩展太快, 也就是说你预配了很多额外的资源, 也就会造成成本的浪费, 资源的浪费。Amazon Aurora Serverless 它是一个细粒度的一个扩展, 它的一个基本的计算单元叫做ACU, 每个ACU 相当于配置了2GB 的内存资源。为什么说它是细粒度的, 它最小的一个Serverless 实例, 它可以配置0.5 个ACU 的资源, 这最小你可以达到的一个力度, 也就是说大概1GB 的一个实例在跑。同时的话, 当你流量进来的时候, 它可以快速扩展, 快速扩展也不是说随便地给你配一个很大的一个资源过去, 它可以最小0.5 个ACU 的这个力度来逐步来扩展, 也就是尽可能让你资源的变化紧贴你工作负载的变化, 这样的话既能满足工作负载变化的需要的同时, 最可能自己帮客户来省钱, 这是它第二个特性。第三个特性的话是高可用及它的扩展能力。因为实际上我们很多应用都是企业级的应用, 虽然它的业务可能波峰波谷波动比较大, 但是高可用这块其实还是必不可少的。这边我们也是支持高可用的一个架构, 它可以做一个主从的一个故障转移。我们可以做相关的设置, 虽然在一个集群里面, 每个节点实例可能都可以配置成Serverless 的一个特性, 可以自己独立来这个伸缩。但同时的话, 为了保证故障转移的效果, 我们可以设置在第0 层和第1 层的这个节点, 它们俩的这个伸缩变化是同步进行的, 因为你第0 层通常是主节点, 你主节点一旦比如说Crash 掉了, 你第1 层的这个只读节点, 因为它的配置是跟着主节点是同步来进行伸缩的, 所以一旦它接管这个Crash 的一个主节点的时候, 它就有足够的能力来承担当时主节点正在进行的一个工作, 不会因为你这个只读节点配置太小, 一旦转过去, 然后承接不了主节点本来的一个工作负载的一个量。

好, 同时的话, 再进一步我们扩展一下, 刚才那个老师也讲到了我们的Global Database,Global Database 做跨区域的灾备。跨区域灾备大家最关心的是跨区域灾备的一个成本, 因为其实成本不便宜, 相当于买个保险, 但也很贵。但是我们这边有个特性, 就是我们的跨区域的, 就从区域里面的集群的节点也是可以用Serverless 的一个架构, 从区域你可以用一种最小的配置方式在运行, 最小的配置方式就意味着你最低的一个成本, 这样的话既可以实现这个跨区域的一个Resilience 灾备的功能, 同时又保证我们这个计算节点是随时可以来接替一些意外的一个情况。

这边我们再顺便提一下, 之前我们在去年re:Invent 期间发布的一个Babelfish for Aurora Serverless, 它其实它的底层也是基于Aurora Serverless V2 来构建的, 它可以自动地进行一个分布式的查询规划以及相关的事务管理, 同时的话它可以进行纵向和横向的收缩, 因此它可以支持PB 级的数据量以及每秒数百万的一个并发写入。

Aurora 关系数据库是我们常见的一个需要Serverless 的一个数据库, 除此之外, 第二常见的我想一定是内存数据库, 我们的缓存这边我们也推出了Serverless for ElastiCache, 它这边其实有很多类似的特性, 跟刚才的Aurora Serverless 的都类似, 我这边就不一一讲了。

这是ElastiCache Serverless 的一个基本的架构, 它底层也是一些ElastiCache 集群模式的一个集群, 它通常是三个分片, 然后每个分片有一组两重三个节点, 然后它会根据的工作负载来动态进行纵向或者横向的一个扩展。而且它提供了单一的一个访问端口, 并且通过这个代理层来抽象底层相关的一个拓扑逻辑, 就可以在出现一些故障转移的时候, 或者是一些其他的连接中断的时候, 它可以来保持这个连接, 而且当你去做打补丁、做升级的时候, 也不会影响这个业务, 也不会中断。

接下来简单概括一下Serverless 数据库的适用场景: 通常用的最多的就是新业务上线的场景, 因为新业务上线实际上我们很难做容量的一个预置, 因为你也不知道这个流量到底有多大, 你的游戏, 你的App 到底会不会爆款, 你不知道。你配置高了一定浪费, 配置低了, 到时候一旦你这个爆款了, 业务一上来, 你要扩容, 以前要停机, 一停机的话, 本来这个正好是火爆的一个产品, 你一停机的话可能把它给搞下去了, 那就得不偿失。那这时候用Serverless 就可以无缝进行扩展, 承接你新业务不可预测的流量, 这是第一种。

第二种就是你的业务负载是规律性的进行波动, 比如早上上班的时间, 或者中午的时间, 或者晚上8 点钟的时间, 可能你的终端用户都同时上线了, 可能没就那几个小时时间, 是一个有个波峰的一个段, 然后大部分时间是个波谷的时间段, 那这个时候用Serverless 也可以大幅减少我们的成本。

第三个是微服务或者是SaaS 的应用, 因为我们微服务通常每个服务后面会接一个数据库, 当你要管理可能几十上百个数据库的时候, 这个容量规划就是一个很头疼的问题, 因为规划不好可能就造成了资源的浪费, 规划而且有可能规划太小的, 有可能又造成业务的一个处理的一个问题, 那用了Serverless, 你每个微服务后面加个Serverless 数据库, 那你就不用操心这个容量的一个管理了。

第四就是一种临时性的工作负载, 比如说你跑测试, 跑批, 临时做些报表, 用这个Serverless 是最合适的, 因为可能就跑的几个小时, 接下来就不用它了, 那Serverless 是最省钱的。这是几种常见的场景。

我们像Serverless 推出以来的, 在各行各业都有广泛的应用, 包括一些IoT 的平台, 一些电信的厂商, 一些CRM 的一些客户, 还有一些像Zoom, 是一个在线视频会议的一个软件, 大家都非常熟悉。这边我们的客户的例子也不单是Aurora, 还包括ElastiCache 的Serverless, 还包括DynamoDB, 那是我们11 年前就推出的一个Serverless 的一个Key-Value 的数据库。

好, 这是前面整体的一个Serverless 的特性的介绍。那接下来时间我把这个话筒就交给我们的黄老师, 然后谢谢韩总。

那个大家下午好, 很高兴今天下午能给大家分享美团在Amazon Aurora 无服务器数据库的一些实践。我是黄岩硕, 刚才也介绍了美团的一个普通的工程师。

先打个广告, 来都来了, 那我们公司呢是做团餐的, 就是给这个企业提供餐饮的解决方案, 做ToB 的业务, 所以普通的这个ToC 的用户可能对我们不了解, 但是一般我出去吃饭或者跟人社交什么的, 大家问一问, 反正都会有美团曾经用过美团的客户, 或者是目前正在用美团的客户, 但是这些企业客户或者合作商户, 这些数据其实没有什么有意思的事情。那有意思的事情是我们目前日均服务的人次是190 万以上, 盘子不大, 但是很有特点, 所以值得拿出来讲一讲。

那我们的业务特点是什么呢? 既然大家吃饭嘛, 吃饭其实很有规律的, 我们对吧, 早中晚一日三餐, 那可能中午的时候, 大家统一地集中在某一个时间段, 比如说11 点半到1 点的时候用我们的系统, 然后晚上还有一波的时间。

那我拿一个我们一个服务来举例, 我们可能有个服务, 它平时的QPS 大概也就1 千或者几千, 然后到高峰的时候突然涨到了好几万, 然后可能最高能到十几万的QPS, 但是高峰11 点半, 像我说的11 点半到1 点, 基本上这个波峰就过去了, 然后晚上的话还有一小波。所以我们的业务它是很有特点的, 它的这个波峰是有一个非常非常高的尖刺, 然后波谷持续的时间又会很长, 那波峰波谷相差的这个时间, 相差的这个数量又非常的多。

这个是我们一个刚才我举例子的那个业务, 它的负载均衡器的一个数据, 可以很明显地看出来, 这个周一二三四五, 这个中午的尖刺非常非常的尖, 晚上的话还有一小波, 后面这个周六周日就稍微温柔一些。所以这种业务的特质对我们系统的弹性的考验是非常的高的。

但是往往我们说一个系统有弹性, 那我们计算资源其实很好解决, 那我可能平日20 个EC2 把这个业务就走起来了, 到高峰的时候我开他100 个对吧? 这就扛住了。但是这是对于我们现代化应用来说的计算资源是这样的, 嗯, 数据库资源, 其实你想做它的弹性, 做它的扩缩容, 那比如说我们用这个MySQL 或者用PostgreSQL 这种关系型数据库的话, 很难做, 尤其是用这个, 普通的RDS 很难做,Aurora 可能还稍微好一些。我们当时就是为了扛住这个高峰, 有一个业务跑了96 个核, 就为了这个高峰。过去以后, 这个机器它的CPU 利用率还不到5%, 基本上全浪费了。

所以去年的时候这个参加美国的re:Invent, 那亚马逊云科技的CTO 也讲了这个勤俭架构, 它是叫简约架构, 勤简节约的架构, 所以我们能看出来这个降增开节, 降本增效, 开源节流这个填空题是一个目前的主要趋势。

当然我们如果计算资源能实现弹性的话, 数据库除了这个Aurora Serverless v2, 去年在中国区应该GA 的, 那我们同样也能做到弹性, 以后我们就可以实现我们这个降增开节的目的。

然后去年的时候中国区GA, 我们马上就做了测试, 那么这个测试其实很基础的一个测试, 我们配置了一个一个业务上的一个小的应用, 它模拟它的实际的场景, 从0.5 个ACU, 最小ACU, 一直到8 个, 这个ACU 是一个非常简单的服务, 然后我们就开始测试, 开始压测。那最开始的时候它的TPS 大概是从500 多, 这个时候数据库是0.5 个ACU, 之后逐渐涨到了1,200 多, 这个时候它的数据库就已经扩到8 个ACU 了, 那我们认为这个时候数据库它已经是趋于稳态了。稳态以后我们再重新做了这个DB 的Vacuum, 然后又重新进行测试它, 基本上它的TPS 就可以保持在1,200-1,300 左右。8 个ACU 相当于是一个2xlarge 的实例, 那我们同样也用这个2xlarge 的预置实例做了测试, 基本上它的表现和这个Serverless 是一致的。当然我们后面为了上生产, 其实做了一些其他的测试, 不过今天时间有限, 我们就先说这个, 至少在性能上是没有问题的。

这个是我们调整以后那个示例业务的架构, 业务应用一不用管他是做什么的, 那它的这个有一个Primary 主节点负责写入, 然后三个从节点, 其中这个R1 、R2 它是预置实例, 然后R3 是这个Serverless v2 的实例, 然后它还有另外一个业务应用2, 我们可以把它理解成是一个业务应用一的一个小的从库, 它有一个没有办法这个避免的一个写节点用来做数据复制的, 然后它的只读节点用的是只有一个Serverless v2 。所以就在这种混部的架构的场景下, 我们用这个Serverless v2 来应对我们高峰时间的这个波动的负载, 然后用预置实例去支撑我们日常稳定的负载, 从而降低的总共总拥有的成本。

就刚才韩总说能够再节约一点, 其实不是能节约很多, 目前我们以刚才那个结构来讲, 我们工作日的成本降低了30%, 然后周末的成本降低了50%, 这就是一大笔钱的这个预留实例资源缩减空间。

是另外一个有意思的事情, 刚才我说了, 我们以前用了96 个实例, 现在用了这个Serverless v2 以后, 预置实例开的是64 个实例, 相当于减了1/3 。然后为什么没接着往下减? 是因为我们开机器都买预留实例, 预留实例相当于一个包年的套餐, 那套餐没到的话, 你把这机器关了, 你钱就浪费了。所以我们还是接着开着这个机器, 但是目标来说, 我们的目标是把96 核一直降到48 个核, 然后后面的话有希望还能接着往下降, 所以这个成本数据库的话是能够减少一半的。

之后说一点这个经验之谈最佳实践, 得讲点干货, 那两个事情其实还能讲很多。容量预热是这样的, 就是我们自己做的测试, 你的数据库在32 个acu 之前, 它的增长是需要时间的, 就是这个斜率, 大概是每分钟能增长3 个acu 。但是像我们这种的, 你中午蹭一下就上去了, 对吧, 这火就冒上来了。你如果只靠这个Serverless 自己的扩容的话, 它是来不及的, 所以我们需要在这个流量激增前, 当然我们有规律, 有规律可以预测, 就是中午12:20 的时候, 通过调整这个最小acu 的方式, 让这个数据库提前地热起来, 就是提前地去扩容。

那第二个事情就是数据预热。数据预热这个大家不管用mysql 还是用pg, 其实原理都差不多, 你这直接查磁盘它很慢, 但是你直接查内存它就很快。但是这两个数据库, 什么数据关系型数据库都差不多, 它都会最大程度地利用你的内存, 把你的热点的数据放在内存里边。那在这种情况下, 你查询进来走内存, 它就很快。那我们假设一个情况, 我有一个80g 的数据库, 咔我扩到了160g, 我有80g 的内存, 它就空着的, 相当于里边什么都没有。那这个时候我们武高峰来了, 诶, 你这个查询进来了, 有新的东西了, 全打到磁盘上了, 出事了, 就开始出现拥堵了, 然后开始io 开始变慢了, 客户就开始抱怨了, 你刷卡吃饭的时候, 诶, 怎么半天付不了钱啊, 这客户就不乐意了。所以就需要做数据预热。

那实现这两个经验的, 或者说实现这两个问题其实特别简单, 你就用亚马逊现成的服务也行, 比如说这个Amazon Event Bridge, 它以前叫CloudWatch Event, 是定时在工作日的时候发起一个Event, 就会触发这个Amazon 的Lambda Function 。比如说你可以去调整这个Serverless 它的最小的ACU, 你可以去做一些这种数据库预热性质的查询, 写不了这个十来行代码, 反正这个事就搞定了。所以这是我们的两个经验。

然后其实这是最后一张片子了, 当然可能还有几分钟的时间, 我们再说点别的, 嗯, 其实这个我是非常推荐大家在有这种波峰波谷流量的时候去选择用这个Aurora 的Serverless 的, 然后包括你看现在我们说的挺火的, 这个AI 什么的, 你跑p 对吧, 你用一个Serverless 的这个pg, 然后你用这个pg vector 插件, 你要算一个什么东西, 你把Serverless 调高点, 或者说干脆用完以后你就给它扔掉不用了, 这个都很方便。

然后当然有一些这个其他的问题, 所以比如说什么问题, 就是Serverless 它不见得真的便宜, 就是同样开这个8acu 的机器, 你开Serverless 的机器, 那可能会比开这个预置实例要贵一些, 所以这个我觉得大家在选择的时候也可以跟这个自己公司的sa 去做沟通, 然后帮助计算一下, 看看到底应该用哪一个实例比较好, 然后咱们大概就这个样子吧, 如果有什么其他的问题的话, 咱们可以会后交流。

总的来说, 亚马逊Aurora Serverless V2 架构能够高效应对波动工作负载, 在保证性能的同时大幅节省成本, 值得广泛应用。美团的实践证明, 采用该架构后, 工作日成本降低30%, 周末成本降低50%, 机器数量也大幅减少。关键是通过容量预热和数据预热等最佳实践, 确保高峰期的性能表现。虽然Serverless 并非绝对便宜, 但对于波动工作负载、新业务上线、微服务等场景极为适合。未来, 该架构在IoT 、电信、CRM 、在线会议等多个行业都有广阔的应用前景。

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

亚马逊云科技中国峰会2024: 亚马逊云数据库服务支持高可用架构, 可实现主从故障转移, 确保企业级应用的可靠性和扩展能力。

亚马逊云科技中国峰会2024: 通过测试证明亚马逊云数据库服务性能卓越, 可满足生产需求。

亚马逊云科技中国峰会2024: 数据预热的重要性 - 避免新数据全部落盘导致I/O 拥堵, 影响客户体验

亚马逊云科技中国峰会2024: 探讨数据预热技术, 提高系统响应速度, 确保高峰时期性能稳定

亚马逊云科技中国峰会2024 上, 演讲者分享了关于计算和存储扩容的独立性和联动性的经验和见解。

总结

亚马逊云科技中国峰会2024 上, 两位演讲者分享了关于无服务器数据库架构的见解。首先, 韩老师介绍了亚马逊云科技无服务器数据库家族, 重点讲解了Amazon Aurora 和ElastiCache 的无服务器架构特点及应用场景。Aurora Serverless V2 与标准版集群架构一致, 可实现即时在线扩展、细粒度扩展以及高可用性, 适用于新业务上线、业务负载波动、微服务/SaaS 应用和临时工作负载等场景。

接着, 黄老师分享了美团在Aurora Serverless V2 的实践经验。美团业务具有高峰时段流量激增的特点, 采用Serverless V2 与预置实例混合部署, 可降低30%-50% 的数据库成本。他还分享了容量预热和数据预热的最佳实践, 以确保高峰时段的响应速度。最后, 黄老师总结了Serverless 的优缺点, 建议根据具体场景选择合适的实例类型。

总的来说, 无服务器数据库架构能够满足不同业务场景的弹性需求, 同时降低运维成本, 是未来发展趋势之一。两位演讲者的分享为无服务器数据库架构的实践提供了宝贵经验。

2024 年 5 月 29 日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。