从Aurora最新产品看Serverless发展

就在不久前，AWS发布了其重量的数据库产品-Aurora Serverless形态的最新预览版本：Aurora Serverless V2。其对云数据库产品发展带来很大的引领意义。本文将从Aurora Serverless V2的能力谈起，并谈谈数据库产品Serverless的发展趋势。

1. 浅谈Aurora Serverless V2

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

1).Aurora Serverless 简介

Amazon Aurora Serverless是Amazon Aurora支持按需自动缩放的版本。它可根据应用程序的需要自动启停并扩展计算容量。Aurora Serverless从设计上旨在提供多租户无服务器云环境中所需的安全性和隔离性。这一架构开销更小，并可快速做出响应；并且做够强大，以满足处理需求的急剧增长。对于终端用户来说，Aurora Serverless为数据库使用提供一种更为简洁、经济的使用方式。系统架构图如下：

Aurora有三个架构组件:路由层、查询层和存储层。

❖ 路由层

路由层接受来自客户端的数据库连接，并将它们多路复用到查询层进程的连接上。它是水平可扩展和多租户的。路由层本身是协议感知的，支持MySQL和PostgreSQL连线协议。Aurora的路由层除了简单地将请求路由到正确的进程之外，还有两个主要目的。它通过从数据库进程本身卸载连接开销来帮助提高可伸缩性。此外，还允许Aurora在迁移或重新启动数据库进程时保持客户端连接打开。路由层通过跟踪底层数据库连接的使用情况，通知自动扩展；这一点对于Serverless非常重要。

❖ 查询层

查询层的作用是连接到路由层，执行客户机提交的查询的计算组件，并访问存储层以读写底层行和索引。查询层“版本”是底层开源PostgresQL和MySQL数据库软件的分支。这实际上与你自己托管开源数据库代码的体验是相同的。在一个Aurora集群中，可以有许多只读数据库进程，但只有一个写入器。由于数据库进程不是多租户的，而是运行在用户定义的虚拟机实例上。通过减少供应粒度并提高供应速度对于Serverless非常重要。

❖ 存储层

存储层管理区域内和跨区域的复制。为了提供高可用性，每个Aurora区域都保留6个数据集副本:三个可用分区(AZ)中的每个分区都有2个副本。这让它能够容忍一系列特定的故障，同时最小化应用程序的影响：

• 在不同AZ中丢失两个分区副本不会对用户产生影响
• 在同一个az中丢失两个分区副本将影响延迟，并可能需要主进程故障转移到另一个az来缓解，但数据库仍可用于写操作
• 丢失三个分区副本将使数据库无法进行写操作，但不会导致数据丢失
• 丢失四个或更多分区副本将使数据库完全不可用，并可能丢失数据

Aurora存储层还管理备份、恢复和其他灾难恢复场景，简化了查询层。与PostgreSQL和MySQL默认使用的B-tree引擎不同，Aurora使用的是日志结构的存储引擎。

2). Aurora Serverless V2变化

Aurora Serverless支持实例弹性伸缩。在之前的v1版本中，其扩展单位ACU是需要按倍数增长，以此来支持工作负载。但在v2版本中，支持已更小以粒度0.5个ACU为单位，实现伸缩。这一变化无疑为计算容量带来很大的灵活性（用户不需要为不需要的资源买单），此外其伸缩延迟也将大大减少（最高可达15倍）。Aurora Serverless v2的另一大变化与配置计算的方式有关。Aurora Serverless v2 实例会根据应用程序负载在几毫秒内自动扩展。这将使得资源计算的时长更加精准。

Aurora Serverless 一个亮点能力是增加“只读”能力。在v2版本中可最多增加15个只读节点，每个节点可扩充至256个ACU。

Aurora Serverless V2还提供了在单个集群中创建混合配置的能力。这意味着，单个集群可以是混合预配置和Serverless的实例。不仅如此， 还可以修改现有的预配置Aurora群集以支持新的Serverless实例。如果您有一个现有集群，并且想要添加高度可扩展的按需读取容量，则无需创建新集群或迁移数据就可以做到这一点。上图中的模式就是这样。

❖ 弹性扩展示例

作为Aurora Serverless的基础能力，弹性伸缩对用户很有意义。在v2版本中，提供了更为平滑、精细的伸缩能力。如下图是一个示例：

上图显示业务压力（蓝色）和ACU（橙色）的变化曲线。随着业务的增长和缩减，ACU资源随之变化。ACU 由内存 (RAM) 和处理器 (CPU) 组成。CPU 利用率的增加可立即响应工作负载需求。当需求从峰值开始下降时，随着内存的释放速度（相比于 CPU）越来越慢，从最大 ACU 向下扩展的速度也更慢。这是一种经过深思熟虑的架构选择。Aurora Serverless v2随着需求的减少而逐渐释放内存，以避免影响工作负载。

3).定价问题

Amazon声称客户通过使用Aurora Serverless v2，可以节省高达90%的成本（相对于峰值负载）。但从现有定价来看，v2 ACU的价格是原始v1 ACU的价格的两倍（每ACU小时0.12美元与每ACU小时0.06美元）。V2的优势在于更细粒度的调度、更快的收缩时间。对于多租户、动态变化的负载更有优势；对于稳定负载来说收益需评估。

2. 数据库产品Serverless趋势

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

Serverless作为一种新的基础设施使用方式，近些年愈发流行。作为基础软件之一的数据库，受限于架构数据库对Serverless模式支持相对滞后。随着以Amazon、腾讯等厂商的推进，Serverless形态的数据库产品逐步走入人们的视野。下面让我们从产品角度分析下Serverless型产品的发展趋势。

1).需求输入

• 轻量化 通常意义来讲，数据库是比较重的，提供更为轻量化的方案对客户很有吸引力。所谓轻量化是指，客户可在较短时间内获取，并以一种简洁的方式使用数据库。真正如同云所倡导的，提供类似水、电类的基础服务，不在需要复杂的配置管理、容量规划等。用之即来，用后即去。
• 高弹性 提供更加灵活的弹性能力，包括对计算、存储资源的弹性需求。客户以更精细化的粒度使用数据库，并可以在很大范围内调配资源。
• 响应快 提供更为快捷的响应方式，传统数据库漫长的扩容流程将被摒弃。取而代之的是召之即来的资源能力。这会带来客户对数据库使用的新模式，其将不在拘泥于资源规划，完全可根据负载快速获得。从使用体验及成本上都会更具优势。
• 成本低

传统的基建式的构建方式，导致的是大量的资源闲置。客户不得不为空置的资源买单，导致极大的浪费。无服务器模式将大大改善这种情况，也许在单位时间成本上后者更高，但从整体使用成本上是降低的。

2).适用场景

• 不常用应用 使用时间很短，通过预置资源方式处理，费效比很低。通过Serverless模式，只在使用时为计算资源付费；平时数据可只做静态存储，费用很低。
• 新应用程序 新开发应用程序，不确定其负载特点，只做验证性使用。通过Serverless模式，可以让数据库自动扩展到应用程序的容量需求，无需提前规划容量。
• 可变工作负载 负载差异较大的应用，可通过Serverless模式保留对峰值的支撑。通过“固定+弹性”的组合，提供兼具一定费效比的可变负载下的支持能力。
• 不可预测负载 通过Serverless模式自动扩展容量以满足应用程序的峰值负载需求，然后在活动涌现结束时再收缩，以此应对不可预测工作负载。
• 开发测试库 此类对数据库需求，具有明显在使用上的时间特点。通过Serverless模式，可做好必要的计划调度。
• 租户类应用 在面对纷繁复杂、海量的应用，在Serverless模式下，无需为每个租户定义资源。此方式下天然具备自动调整容量，自动适应。

3).未来发展

Serverless模式，还处于相对早期，随着这一理念被更多客户认可，相信其未来发展前景广阔。在发展方向上，可能朝下面几个方向演进：

• 更加平滑 改善用户使用体验，从接入层、计算层、存储层做到更加顺滑的弹性体验。
• 更加低廉 当前单位时间使用成本仍显过高，未来技术突破可进一步减低成本。
• 更加简洁 客户从更高维度使用数据库，不用考虑其底层物理架构。只需考虑最为基本的“计算+存储”诉求。
• 更易集成 与现有数据库架构，可更方便的集成，提供迁入、迁出、组合的灵活方案。
• 更易使用 与应用更好地结合，甚至在应用端直接支持，对数据库端完全无感。