Amazon Aurora深度探索--第一篇--整体架构

栏目: 数据库 · 发布时间: 7年前

内容简介：Amazon Aurora深度探索--第一篇--整体架构

2017 年， Amazon 在 SIGMOD 上发表了论文《 Amazon Aurora: Design Considerations for High Throughput Cloud Native Relational Databases 》。

这篇论文，描述了 Amazon 的云数据库 Aurora 的架构。基于 MySQL 的 Aurora 对于 单点写多点读的主从架构 做了进一步的发展，使得事务和存储引擎分离，为数据库架构的发展提供了具有实战意义的已实践用例。其主要特点如下：

q 实践了“日志即数据库” [1] 的理念。

q 事务引擎和存储引擎分离。

n 数据缓冲区提前预热。

n REDO 日志从事务引擎中剥离，归并到存储引擎中。

n 储存层可以有 6 个副本，多个副本之间通过 Gossip 协议可以保障互相数据的“自愈”能力。

n 主备服务的备机可达 15 份，提供强大的读服务能力。

q 持续可靠的云数据库的服务能力。

n 数据存储跨多个区：提供了多级别容灾能力。

n 万能数据库的概念呼之欲出。

之所以有这样的设计，是因为 Amazon 认为： 网络 IO 已经成为数据库最大的瓶颈 [2] 。

认识 Aurora 的整体架构，需要先理解 AWS 的物理设施，而论文中对 Aurora 基于的物理设施着墨不多，所以我们先来掌握物理设施与整体架构的关系。

Aurora 的计算节点和存储节点分离，分别位于不同的 VPC （ Virtual Private Cloud ）中。这是 Aurora 架构最亮眼之处。

如图 1-1 ，用户的应用，通过 Customer VPC 接入，然后可以读写位于不同 AZ( Availability Zone ) 的数据库。而不同的 AZ 分布于全球的不同的 Region 中（如图 1-2 [3] ，截止到 2017 年初， AWS 全球有 16 个区域即 Region ，有 42 个可用区即 AZ ，每个 Region 至少有 2 个 AZ 。而每个 AZ 由两到多个数据中心组成，数据中心不跨 AZ ，每个 AZ 内部的数据延迟低于 0.25ms [4] 。 AWS 文档称， AZ 之间的延迟低于 2ms 通常小于 1ms ）。

数据库的部署，是一主多从的集群架构，图 1-1 的是写数据的节点，只能有一个（这点说明 Aurora 还是传统的数据库架构，不是真正的对等分布式架构，这点也是一些批评者认为 Aurora 缺乏真正创新之处）。而是只读的从节点，由零到多个备节点组成，最多可以有 15 个。主从节点可以位于不同的 AZ （最多位于 3 个 VPC ，需要 3 个 AZ ）但需要位于同一个 Region 内，节点通过 RDS (Relational Database Service) 来交互。

RDS 是由位于每个节点上的称为 HM(Host Manager) 的 agent 来提供主从集群的状态监控、以应对主节点 fail over 的问题以便进行 HA 调度、以及某个从节点 fail over 需要被替换等问题。这样的监控服务，称为 control plane 。

图 1-1 Aurora 整体架构

Amazon Aurora深度探索--第一篇--整体架构

图 1-2 Aurora 的 Region

分布图

数据库的计算服务和存储分离，数据缓冲区和持久化的“数据”（对于 Aurora 实则是日志和由日志转化来的以 page 为单位的数据，而不是直接由数据缓冲区刷出的 page 存储的数据）位于 Storage VPC 中，这样和计算节点在物理层面隔离。一个主从实例，其物理存储需要位于同一个 Region 中，这样的存储称为 EC2 VMs 集群，其是由一个个使用了 SSD 的 Storage Node 组成。

Aurora 提倡“ the log is the database ”，这是其设计的核心。围绕这个观点，传统数据库的组件架构，发生了一些变化。

对于 Aurora ，每一个存储节点，如图 1-3 ，由两部分构成。

1 第一部分： Caching

第一部分是“ Caching ”，这是一个重要的关键点，可惜论文没有描述其细节。

如同传统数据库架构的数据缓冲区，向事务层提供数据。传统数据库架构的数据缓冲区，向上起着消耗存储 IO 的 I 加载数据到内存供计算层读写数据的作用、向下起着消耗 IO 的 O 写出脏数据到存储层以实现数据持久存储的作用。对于一个写密集的 OLTP 系统，大量随机写花费了很多时间，系统的性能因此经常表现为存储层的 IO 瓶颈。尽管 checkpoint 技术缓解了每个写操作刷出脏数据的冲动，尽管 SSD 的使用缓解了存储层的瓶颈，但是，毕竟存储层的 I 与 O 的时间消耗还是巨大的，尤其是对于随机写密集的 OLTP 系统。

的设计，消除了脏数据刷出的过程，数据缓冲区的作用，只是加载数据供上层使用，而脏数据不必从数据缓冲区刷出到物理存储上，这对于随机写密集的 OLTP 系统而言，是一个福音，性能的瓶颈点被去掉了一个（如图 1-3 ，在“ Caching ”和“ Logging+Storage ”之间，竖线的箭头，应该是指向“ Caching ”的，以表示数据只是加载到 Caching 中，不存在脏数据的刷出操作）。

但是，观察图 1-3 ，“ Caching ”是位于了存储层内还是计算层内？论文没有明示。

从图 1-3 观察，似乎 “ Caching ” 是存储层和计算层所共用的一个组件，那么就可能存在这样的一个两层设计：位于存储层和计算层各有一部分“ Caching ”，这两部分“ Caching ”组合成为一个逻辑上的“ Caching ”，而逻辑意义上的“ Caching ”似乎在 AWS 认为，其更像是属于计算层的。如下文引自论文原文：

Although each instance still includes most of the components of a traditional kernel (query processor, transactions, locking, buffer cache , access methods and undo management) several functions (redo logging, durable storage, crash recovery,and backup/restore) are off-loaded to the storage service.

位于存储层内的“ Caching ”，更像是一个分布式的共享文件系统，为了提高性能也许是一个分布式内存型的共享文件系统，为主从架构的数据库提供高速读服务，此点妙处，论文没有点出，这里权做推测。存储层如果能为所有的主备节点提供一致的缓冲数据，则有更为积极的意义，可以对比参考的如 Oracle 的 RAC 。

而位于计算层内的“ Caching ”，是单个数据库实例读数据的场所，独立使用。

Aurora 提供了一个“自动恢复”缓冲预热的功能，其官方宣称如下：

“ 自动恢复 ” 缓存预热

当数据库在关闭后启动或在发生故障后重启时， Aurora 将对缓冲池缓存进行 “ 预热 ” 。即， Aurora 会用内存页面缓存中存储的已知常用查询页面预加载缓冲池。这样，缓冲池便无需从正常的数据库使用 “ 预热 ” ，从而提高性能。

Aurora 页面缓存将通过数据库中的单独过程进行管理，这将允许页面缓存独立于数据库进行 “ 自动恢复 ” 。 在出现极少发生的数据库故障时，页面缓存将保留在内存中 ，这将确保在数据库重新启动时，使用最新状态预热缓冲池。

源自： http://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/Aurora.Overview.html

“ 在出现极少发生的数据库故障时，页面缓存将保留在内存中 ”，这句话很重要，一是其表明数据不用很耗时地重新加载了，二是数据库实例崩溃前的数据内存状态被保留着，三是数据库崩溃重启不必再执行“故障恢复”的过程即使用 REDO 日志重新回放以保障数据的一致性了（事务的 ACID 中的 C 特性）。

那么，页面缓冲是一直保留在哪个节点的内存中？是存储节点还是计算节点？如果是位于计算节点，那么备机节点发生数据库故障时，这样的机制不会对备机节点起到保护作用。如果是位于存储节点，则存储作为一个服务，服务了一主多备的多个节点，则能更好的发挥“自动恢复”缓冲预热的功效（存储节点的 caching 一直存在，向上层计算节点的提供数据批量加载服务，但也许不是这样，而是提供一个接口，能够向计算层的 caching 提供高速读数据的服务，论文没有更多的重要细节披露，权做推测）。由此看来， “ Caching ” 层的两层设计，当是有价值的，与预写日志功能从事务层剥离是关联的设计。

这就又回到前面引用的论文中的那段英文，其表明： Aurora 的设计，把 REDO 日志、持久化存储、系统故障恢复、物理备份与物理恢复这些功能模块，归属到了存储层。由此就引出了 Aurora 的另外一个重要话题 --- 存储层的设计（如下的第二部分和下一节内容）。

对于计算层的 “ Caching ” ，其实现将被大为简化。脏数据不再被写出，脏页面不再需要复杂的淘汰策略进行管理，消除了后台的写任务线程，同时也消除了 checkpoint 线程的工作，数据缓冲区的管理大为简化，即降低了系统的复杂度又减少了时间的消耗、还避免了因执行后台写等任务带来的性能抖动，解耦带来的功效确实宜人。 Aurora 额外需要做的一项新工作是： only pages with a long chain of modifications need to be rematerialized 。

Amazon Aurora深度探索--第一篇--整体架构

图 1-3 存储结构图

另外，如果 “ Caching ”确实存在两层，而如 2.1 节所述，存储层也在处理日志、并依据日志生成页数据，则存储节点也存在处理数据的能力，就类似于的 ExaData 。这样导致的一个可能是，两层的“ Caching ”还是可能存在差别的。存储层的“ Caching ”能够帮助做谓词下推的工作，然后把较少的数据传回计算层的“ Caching ”，由此实现类似 Oracle 的 ExaData 的智能扫描（ Smart Scan ）的功能。是否如此，或者 Aorora 的体系结构和功能模块在未来继续演变的时候，是否 会在存储层内的“ Caching ”做足文章 ，可以拭目以待。不过，目前制约 存储层内的“ Caching ” 起更大作用的因素，主要在于分布式事务的机制的选取和 InnoDB 自身的事务实现机制。详细讨论参见 3.2 节。

2 第二部分： Logging+Storage

第二部分是“ Logging+Storage ”，日志和持久化存储。日志传统数据库对于预写日志（ WAL ）的利用方式与 MySQL 不同，这点是 Aurora 实现计算与存储分离的核心（下一节详述存储层实现细节）。

如图 1-4 所示，对于日志数据，从 Primary RW DB 写出到一个存储节点，每个 AZ 至少有 2 份数据，写出的日志数据会自动复制到 3 个 AZ 中的 6 个存储节点，当其中的多数节点回应写日志成功，则向上层返回写成功的 ACK 。这表明写日志信息采用了多数派协议（ quorum ）。

MySQL 的事务模型符合 SS2PL 协议 [5] ，当日志成功写出，就可以在内存中标识事务提交成功 [6] ，而写日志信息是一个批量的、有序的 IO 操作，再加上 Aurora 去除了大量的缓冲区脏数据的随机写操作，因此 Aurora 的整体性能得到大幅提升。

借用官方论文的一组对比数据，可以感性认识存储和计算分离的所带来的巨大好处，如图 1-5 所示， MySQL 的每个事务的 IO 花费是 Aurora 的 7.79 倍，而事务处理量 Aurora 是 MySQL 的 35 倍，相差明显。

Amazon Aurora深度探索--第一篇--整体架构

图 1-4 主从复制日志存储图

图 1-5 Aurora 与 MySQL 主从复制架构性能数据对比图

对于主备系统之间，如图 1- 3 所示，主备之间有日志等数据的传递。也就是说备机的数据是源自主机的。如图 1-3 所示的主备之间的紫色箭头，表示主机向备机传输的是更新了的元数据，绿色箭头表示日志作为数据流被发送给了备机（这个复制，应该是异步的，相关内容请参考 2.1 节）。所以备机的数据更新，应该是应用了主机传输来的事务日志所致。这是论文中表述的内容，原文如下：

In this model, the primary only writes log records to the storage service and streams those log records as well as metadata updates to the replica instances.

但是，日志的应用功能是被放到了存储层实现的，如原文描述：

Instead, the log applicator is pushed to the storage tier where it can be used to generate database pages in background or on demand.

而官方的网站 [7] 用图 1-6 描述了备机的数据，是从存储节点读入的，备机数据获取和更新的这个细节，算是个谜。“ Caching ”如果确实分为两层，在存储层提供从日志中恢复成为数据页的形式而被缓冲，则主备系统之间应该没有必要再传输日志数据，对于备机而言，直接从统一的存储层的“ Caching ”中获取数据即可。