Aurora Serverless

󰃭 2024-11-15

Resource Management in Aurora Serverless

摘要

Amazon Aurora Serverless 是 Amazon Aurora 的一种按需自动扩展配置，完全兼容 MySQL 和 PostgreSQL。它根据客户数据库应用程序的需求自动提供容量扩展/缩减(即垂直扩展)。通过这种方式，它使客户无需显式管理其数据库容量；客户只需使用一个简单易懂的多资源容量抽象概念——Aurora 容量单位(ACU)来指定最小和最大边界。对于工作负载随时间变化的客户，由于其灵活和细粒度的扩展以及基于使用的计费模式，与预置的 Aurora 或其他替代方案相比，它可以节省成本。本文描述了 Aurora Serverless 资源管理的关键思想。为了帮助实现其目标，Aurora Serverless 采用并微调了与资源过度订阅相关的成熟思想；基于近期测量的反应式控制；分布式和分层决策；以及数据库引擎、操作系统和虚拟机管理程序在效率方面的创新。也许最具挑战性的目标是在以高度利用率运行主机的同时提供一致的资源弹性体验。Aurora Serverless 实现了几个新颖的想法，以在这些相互对立的需求之间取得平衡。其将工作负载映射到主机的技术确保在常见情况下，主机内有足够的备用容量来支持工作负载的快速扩展。在罕见的情况下，如果不是这样，它被设计为实时迁移工作负载以确保无缝扩展。其负载分配策略的特点是跨主机"不平衡"负载，以实现灵活的实时迁移。最后，它采用基于令牌桶的速率调节机制，以防止不断增长的工作负载在基于实时迁移的补救措施之前使其主机饱和。

1 引言和动机

Amazon Aurora [1] 是一种现代关系数据库服务，为完全开源的 MySQL 和 PostgreSQL 兼容版本提供大规模的性能和高可用性保证 [37]。2014 年推出的原始预置 Aurora 产品允许客户选择按需实例（虚拟机），按小时付费使用数据库，无需长期承诺或预付费用，或选择预留实例以获得额外优惠 [2]。最近，Amazon 开始提供 Aurora Serverless [3]，这是 Amazon Aurora 的一种按需自动扩展配置。Aurora 提供的自动扩展能力是向上/向下扩展（即单个数据库实例分配资源的"垂直"扩展），而不是某些其他系统提供的横向扩展（“水平"扩展）。Aurora Serverless 旨在快速扩展数据库工作负载，从每秒数百次事务到数十万次事务。第一个 Aurora Serverless 产品（ASv1）于 2018 年 8 月推出，而最新产品（ASv2）于 2022 年 4 月发布。

为什么选择 Aurora Serverless？Aurora Serverless 的主要卖点是它在很大程度上减轻了客户管理其数据库资源容量如何响应动态工作负载的需求。客户无需预先选择特定的实例大小或配置，只需以称为 Aurora 容量单位（ACU）[4] 的单位指定数据库容量。每个 ACU 是 2 GB 内存、相应的 CPU、网络和块设备 I/O 吞吐量的组合。Aurora Serverless 根据应用程序需求，在客户指定的（最小，最大）ACU 范围内持续自动扩展客户数据库集群中的每个写入器或读取器。与预置的 Aurora 或其他替代方案相比，Aurora Serverless 因以下原因带来的成本节省和便利性而吸引各种客户：

它减少了规划数据库实例大小和随工作负载变化调整数据库实例大小的工作。
它帮助客户避免过度配置数据库实例。在数据库实例扩展时，它以细粒度增量添加资源。客户只需为使用的数据库资源付费。
它根据需要扩展计算和内存容量，不会中断客户端事务或整体工作负载。
它使客户无需管理虚拟机类型，这是由于弃用、容量限制、新 AWS 区域不支持旧类型等原因而必需的。它还消除了对某种实例类型的承诺需求，这通常是获得折扣价格所必需的。

总的来说，发现 Aurora Serverless 有吸引力的客户包括：(i) 具有高时间可变性的工作负载（可预测的模式如一天中的时间效应 [11, 12] 或不可预测的）；以及 (ii) 需求尚未确定的新应用程序。

为了说明 Aurora Serverless 的功能，在图 1 中，我们比较了使用预置和 Aurora Serverless v2（ASv2）的动态工作负载。我们的工作负载基于 sysbench 基准测试 [9] 的只读配置，serverless 场景的最大和最小容量为 128 和 0.5 ACU，预置场景为 128 ACU。图 1(a) 显示了我们工作负载的高度动态性，每秒查询数（QPS）的吞吐量在接近 0 到超过 200,000 的范围内变化，有多次向上和向下扩展。在图 1(b) 中，我们展示了 ASv2 如何根据工作负载的动态性改变其 ACU 分配（严格来说是一个称为"预留 ACU"的量，我们将在后面的论文中描述）。最后，在图 1(c) 中，我们比较了两种配置的查询延迟（具体是在 10 秒窗口内测量的 P95 延迟）。

我们发现以下观察值得注意。在预置模式下,我们的工作负载始终产生128个ACU的成本 - 即使在非高峰时段。ASv2紧密跟踪工作负载,能够分配足够资源来处理峰值,逐步与工作负载同步增长,然后在工作负载下降时也相应跟踪。最后,ASv2能够在很大程度上匹配预置模式提供的延迟(最大偏差出现在ACU分配降至最小值的时期),同时只需要预置场景中总ACU小时数的54.9%。通常,当我们实例的ACU分配被缩减到最大值的约50%以下时,ASv2与预置模式的延迟差距最大 - 这些是与其他共置实例的资源争用对我们实例性能影响相对较大的运行状态。

贡献: 本文的目标是描述Aurora Serverless当前的资源管理策略,这些策略使其能够为客户提供上述资源弹性。我们还希望强调从ASv1到ASv2的进展过程中学到的重要经验。这个过程涉及将现有最佳实践与新想法仔细结合。我们描述了我们的策略如何受到我们对客户需求和行为不断发展的理解的影响。最后,我们迄今为止的经验表明了一些有前景的未来方向,本文也对此进行了讨论。我们的论文涉及Aurora Serverless资源管理的以下几个方面:

容量边界:Aurora Serverless允许其客户以ACU为单位指定其需求的最小和最大边界。Aurora Serverless保证客户的资源分配在这些边界内根据其动态变化的需求而变化,并且客户在这些边界内体验可预测的扩展体验和基于使用的定价。
资源过度订阅和过度配置:Aurora Serverless出于不同原因对其主机上的资源进行过度订阅和过度配置。主机上的vCPU数量可能超过它们映射到的物理CPU的容量,以获得统计复用的好处。同样,内存容量也根据主机上实例的客户指定最大ACU进行过度订阅。这涉及其自身成本/利用率与客户体验(共置实例间的资源争用和扩展限制)之间的复杂权衡。同时,实例的ACU分配通常略高于其当前使用量 - 这个"扩展带"能够在调整分配时快速检测和满足扩展需求。
通过实时迁移进行动态实例打包:Aurora Serverless使用实例的实时迁移来确保主机有足够的备用容量来容纳其实例的扩展事件 - 如果一个主机开始变得高度利用(“热”),实例会被移走以创造更多空间。确定启动此类迁移的标准、迁移哪个实例以及迁移到哪里都是非常复杂的决策,Aurora Serverless在这一领域做出了新的贡献。值得注意的是,其负载分配策略的特点是跨主机的有限形式的"不平衡” - 这与传统的面向负载平衡的技术不同 - 以留出足够的轻负载主机来容纳迁移。其实例打包策略确保在常见情况下,实例扩展可以完全在主机内本地实现(“原地扩展”),而无需进行实时迁移。
扩展速率调节:快速扩展和高利用率运行主机之间存在根本矛盾。Aurora Serverless采用基于令牌桶的实例增长调节来补充其打包和迁移策略。这种调节有助于防止快速增长的实例导致其主机利用率饱和,从而导致自身和其他共置实例性能下降的情况;有界增长率(与其他系统特性如实时迁移时间一起仔细调整)允许Aurora Serverless及时将合适的实例从受影响的主机迁移出去,以高概率避免不希望出现的高利用率水平。一个重要的新贡献是基于对实例增长场景和迁移时间的广泛表征,将目标主机利用率水平与令牌桶参数一起配置。
分布式反应式控制:Aurora Serverless资源管理跨越两个时空尺度:跨集群(“舰队”)和主机内。舰队范围的控制采购/释放主机并确定实例到主机的映射(包括通过迁移),而主机内控制使用操作系统机制确保充分满足实例的资源需求。它使用反应式控制风格,以简单和易于实现。它还保持两个控制级别基本独立(即松耦合)。这些选择使其控制具有可扩展性。尽管其主机内扩展是反应式的,但反应在最后一位RAM被使用之前就开始了 - 这是通过在即时需求之外维持一小段容量来检测和适应短期增长实现的。
提高效率的系统机制:Aurora Serverless在整个软件栈中实现了许多创新的系统机制,以支持其运营目标:Nitro虚拟机管理程序(安全性和隔离性可与预置Aurora相媲美);增强的Linux内核(实例内存使用的节俭性);以及Aurora数据库引擎(相关指标帮助Aurora Serverless进行主机级资源分配和舰队范围的打包决策)。特别是,它在引擎中引入了一个指标来估计缓冲区缓存中工作集的大小。这个指标允许估计可以释放多少内存回服务而不影响客户体验。

文章的其余部分安排如下。在第2节中,我们提供背景,包括从ASv1到ASv2的历程。在第3节中,我们概述ASv2资源管理,第4和5节分别详细介绍其主机间和主机内级别。我们在第6节中呈现一些实证观察。最后,我们在第7节讨论相关工作,在第8节描述关键经验教训,并在第9节总结。

2 背景

2.1 挑战和一个关键设计原则

为了以高效率为客户提供上述资源弹性，Aurora Serverless需要解决一些挑战。这些包括政策问题，如：(i) 如何定义"热度"（即基于哪些资源使用特征来做决策）？何时认为一个实例"过热"（即需要采取补救措施）？何时认为一个主机过热？何时认为热度已得到缓解？(ii) 将新实例放在哪个主机上？如何使用实时迁移动态映射现有实例到主机？以及 (iii) 如何在利用率和扩展速率之间取得适当平衡？机制问题包括：(i) 什么是正确的虚拟化解决方案？以及 (ii) 在虚拟机内外需要什么来无缝扩展数据库引擎？

鉴于Aurora Serverless的开创性质，一开始我们不得不在没有大规模现场数据的情况下做出这些选择。我们想避免为一小部分特殊用户群优化的风险，这可能会阻碍其他类型的用户采用该产品。因此，Aurora Serverless演进过程中的一般设计原则是从对工作负载的最少假设开始，只有在我们的数据集中看到足够证据后才纳入特殊性。这种方法的一些例子可以在我们允许客户指定的容量边界中看到；从ASv1到ASv2的过渡；我们最初选择保守的利用率目标和扩展速率；以及我们选择反应式而非预测性机制。在某些情况下（例如容量边界），初始选择经受住了时间的考验；在其他一些情况下（例如从ASv1到ASv2，提高我们的利用率水平），我们能够吸取运营经验来改进我们的解决方案；还有一些情况（例如利用工作负载的可预测性），我们正在进行将这些经验教训纳入我们方法的工作。

2.2 Aurora Serverless容量边界

Aurora Serverless为其客户提供与Aurora预置产品相同的功能，同时确保资源弹性。Aurora Serverless的资源容量/度量单位是Aurora容量单位（ACU）。每个ACU是2 GB内存、相应的CPU（目前为0.25 vCPU）、网络和块设备IO吞吐量的组合。对于使用单主复制的集群，客户可以创建最多15个只读Aurora副本（“读取器实例”）。客户定义一个容量范围：每个写入器或读取器可以在其间扩展的最小和最大容量值（分别为实例i的$c_i^{min}$和$c_i^{max}$）。容量范围对DB集群中的每个写入器或读取器都相同。$c_i^{max}$允许的最大值为128，而$c_i^{min}$允许的最小值为0.5。Aurora Serverless容量的费用以ACU小时为单位，以1秒的粒度计算[2]。

在制定我们的容量边界时，除了易用性外，我们还必须考虑以下因素：(i) 我们能为客户提供多接近完全按使用付费的体验？(ii) 我们能多高效快速地恢复一个经过一段时间不活动后返回的客户？以及 (iii) 我们的基础设施可以在多高的利用率水平下运行？这些关切之间存在固有的矛盾。例如，如果我们让最小ACU为0，并在一段时间不活动后实际移除客户的资源，我们可能在(ii)方面表现不佳。要在(ii)方面表现良好，我们需要能够很好地预测不活动期，以便在下一个活动期之前提前恢复暂停的数据库。将最小容量设置为一个小数字（低至0.5 ACU）让轻负载的DB集群消耗最少的计算资源。同时，它们保持随时可以立即接受连接并在繁忙时扩展。Aurora Serverless建议将最小值设置为允许每个DB写入器或读取器在缓冲池中保持应用程序工作集的值。这样，缓冲池的内容在空闲期间不会被丢弃。

2.3 从ASv1到ASv2

从Aurora Serverless v1到v2的演进过程体现了我们从简单开始，然后基于运营经验增加特殊性的方法。ASv1于2018年8月推出。最重要的区别是，与使用实时迁移作为其资源管理构建块不同，它使用了一个简单得多的会话转移功能。为了扩展数据库，数据库会被重新启动。为此，ASv1在数据库引擎中实现了支持，允许中断服务并将会话从一个后端转移到另一个后端。ASv1实现了一个多租户代理前端，可以通过VPC端点从客户的VPC安全访问，这使得服务能够识别目标数据库目的地，而无需依赖数据库、用户名或凭证的唯一命名。

我们的团队认为，这些功能的组合将允许数据库后端根据工作负载进行扩展，并在空闲时完全释放。然而，ASv1设计的一些限制很快就变得明显。扩展方法需要找到不会中断客户性能的安静点来进行会话转移；但是，我们发现对于许多客户工作负载来说，这并不总是可能的。并非所有类型的会话状态（例如临时表）都可以转移到不同的后端。将会话转移代码移植到新版本数据库引擎的负担很高，因为服务无法完全控制添加到两种数据库产品中的功能。ASv1对其会话转移协议的依赖决定了ASv1的其他架构决策，这些决策只有在数据库实例快速交换为另一容量实例的情况下才能证明是合理的。然而，必须交换不同大小的实例导致了其他客户体验问题：扩展只能以大增量进行（上下扩展2倍）。这也导致我们的扩展策略触发扩展或缩减太晚，无法成为一个成本效益高的解决方案。回想一下图1(b)中说明的ASv1的这些限制。由于这种源于粗粒度容量增量的扩展"跷跷板问题"，无法提供更精确的工作负载跟踪。尽管存在这些缺点，ASv1的广泛采用为我们的团队提供了许多有用的运营和业务洞察。这些使得服务能够重新考虑方法，考虑到大量客户吸引力和对成本效益高且可扩展的无服务器数据库解决方案的需求。

基于我们使用ASv1的经验，Aurora Serverless V2从一开始就被定义为可以原地扩展的数据库产品。这本身就解决了粗粒度2倍扩展带来的问题，使ASv2比ASv1更具成本效益。此外，在大多数情况下，原地扩展比跨实例扩展更快，这允许更快地响应增加的工作负载。这种扩展可以在SQL语句运行和事务打开时进行，无需等待安静点。ASv2可以更快地上下扩展。扩展可以将容量变化小至0.5 ACU，而不是将ACU数量翻倍或减半。扩展通常完全不会暂停处理。扩展不涉及客户必须意识到的事件，这与ASv1不同。扩展可以在SQL语句运行和事务打开时进行，无需等待安静点。

ASv2扩展将使用两种机制：内存和CPU热插拔以及实例跨主机的实时迁移。此外，ASv2将消除对前端代理层的需求，这在ASv1中加剧了延迟和嘈杂邻居问题。最后，ASv2将提供接近100%的Aurora预置功能对等性，并将由相同的系统管理，这将简化未来维护功能对等性并防止客户体验的分裂。这是通过引入一种新的VM类型实现的，该类型提供了内存大小的可扩展性，这是我们的服务在多年生产经验中学会处理的抽象。上述方法在积累了运营、市场和客户洞察后变得可行。在没有ASv1数据和客户吸引力的情况下，人们认为无法证明创建ASv2所需的新构建块的合理性。

在本文的其余部分，我们将专注于v2，并简单地称之为Aurora Serverless，而不明确指出v2。

3 概述

我们将重点关注"舰队"内的资源管理，这是Aurora Serverless在可用区（AZ）[5]内管理的一组主机（配有Aurora存储服务的存储）。

3.1 策略

Aurora Serverless资源管理的整体决策分为两种时间/空间粒度：(i)舰队范围（详见第4节）和(ii)主机内（详见第5节）。图2提供了这种决策的高级概述。

3.1.1 主机内

主机内的资源由"实例管理器们"集体管理，每个实例一个。实例管理器负责资源使用收集/推断、实例的"就地扩展"和"边界管理"。就地扩展动态计算实例的资源需求，形式为实例的"保留ACU"；让我们将时间t时实例i的这个值表示为$r_{i,t}$。实例i能够在其当前使用量$u_{i,t}$和其保留ACU $r_{i,t}$之间的小范围内（如果有的话）立即扩展。图3中展示了实例i的这种即时扩展范围。进一步超出保留ACU的扩展需要"边界调整"，即增加实例的保留ACU。边界管理确保实例的保留ACU不会相对于其需求过度配置，并且不会以可能导致与其共置实例产生不良资源竞争的速度增长。实例管理器轮询特定于引擎的代理以获取资源使用信息，并使用这些信息来确定如何扩展数据库。它还与客户操作系统交互，根据其对最近使用情况的观察来执行资源限制。在图3中，实例的使用量为$u_{i,t1}$，并将被允许立即增长到$r_{i,t1}$（就地扩展）。如果实例的需求进一步增长，其保留ACU也将增加，但以受控的速率进行。保持保留ACU略高于使用量允许我们快速检测实例使用量的增长趋势。

3.1.2 舰队范围

一个称为舰队管理器的服务根据期望的利用率水平和预测需求，在粗粒度时间尺度（目前为周/月）上调节舰队规模。舰队管理器采用实例的实时迁移，以确保主机不会在其容量无法容纳放置在其上的实例需求的情况下运行：如果主机上的一组实例A开始表现出集体资源使用的增长趋势，可能导致该主机上不良的资源竞争水平，舰队管理器必须能够及时将适当的一组实例B（不一定与A相同或甚至相交）从该主机迁移走。这个问题有两个方面：

如何确保在进行基于实时迁移的补救措施时，主机上有足够的备用容量继续满足任何增长的实例需求？同样，实例迁移到的主机必须能够在容纳其已有实例的基础上满足新实例的需求。
如何确保实例的资源需求增长不会超过基于实时迁移的补救措施的速度？

Aurora Serverless的舰队管理器通过控制实例到主机的映射来解决问题1，这反过来决定了主机上备用容量的分布。通过舰队范围的热度管理和主机级机制的组合来解决问题2。对于正在进行实时迁移以缓解资源压力（“热度”）的主机，舰队管理器可能会对其实例施加短期的最大ACU限制。在热度缓解期间，将舰队管理器为时间t时实例i规定的最大ACU限制表示为$h_{i,t}$，我们可能有$h_{i,t} < c_i^{max}$。这些限制在热度缓解后立即解除，因此在常见情况下，我们有$h_{i,t} = c_i^{max}$。在图3中，我们为实例i说明了这些场景。在时间$t_1$时，当主机不被认为是热的，$h_{i,t1} = c_i^{max}$。在时间$t_2$时，舰队管理器认为主机变热，导致它暂时将$h_{i,t2}$冻结在$r_{i,t2}$。

3.2 机制

Aurora Serverless继续使用Aurora的分离存储架构[37]，因此继承了后者的可靠性和持久性特征。Aurora数据存储在集群卷中，这是一个使用固态硬盘（SSD）的单一虚拟卷。每个Aurora数据库集群的存储包括所有客户数据的六个副本，分布在三个可用区（AZ）中。无论数据库集群是否包含除写入器之外的任何读取器，这种内置的数据复制都适用。当数据写入主数据库实例时，Aurora会同步地将数据跨AZ复制到与集群卷关联的六个存储节点。Aurora集群卷会随着数据量的增加自动增长。Aurora集群卷的最大大小为128或64 TB，具体取决于数据库引擎版本。对于其计算层，Aurora Serverless是由最多256个ACU组成的主机。

Aurora Serverless利用了我们在5.1节中描述的系统软件创新。简而言之，它使用基于Nitro系统[6]的新实例类型，该类型提供Nitro的低IO延迟（基于硬件IO虚拟化，通过SRIOV暴露给实例），以及灵活的CPU和内存配置。它依赖于对Linux操作系统的增强，允许动态调整实例的RAM容量。Aurora Serverless依赖于我们数据库引擎内的机制来提供工作集估计，并采取措施，如在缓冲缓存和用户查询之间交换内存，或在短暂的高资源压力情况下选择性地减少负载。最后，Aurora Serverless利用实时迁移设施，允许将运行中的实例以最小中断的方式透明地从一个主机移动到另一个主机。

4 舰队范围的资源管理

舰队范围的资源管理负责在分钟到小时及更长时间尺度上的决策。它依赖于三个关键控制旋钮：(i)实时迁移；(ii)调节每个实例的舰队管理器规定的ACU限制($h_{i,t}$)，这会影响实例内的边界管理；以及(iii)舰队规模调整。一个关键问题是如何/何时我们认为一个主机需要采取补救措施来缓解其资源压力；我们将这样的主机称为变得"热"。我们采用的方法基于在以下一个或多个容量维度上定义关键利用率水平：(i)CPU带宽；(ii)已分配RAM；(iii)总网络吞吐量；或(iv)本地块设备I/O吞吐量（用于索引过程、排序结果等）。除了简单之外，这种方法还有一个优势，即随着我们的机制效率提高，我们能够提高这些关键利用率阈值。

4.1 基于实时迁移的动态实例重新打包

舰队管理器定期轮询各个实例管理器，以获取（高度精细的，秒级）资源使用指标，用于其决策。每秒钟，它执行以下三步程序来确定是否需要进行任何实时迁移以重新打包实例。

步骤1：哪些主机需要迁出？ 对于每个主机，舰队管理器运行主机热度聚合任务，以评估是否需要将该主机的某些实例移至其他地方。这个评估基于观察过去几分钟内主机实例的保留ACU总和是否超过阈值$\theta_{acu}^{mig}$。超过此阈值的主机被认为变热。然后舰队管理器检查热主机是否有足够的网络带宽来支持迁出。对于可以支持迁出的热主机，舰队管理器继续进行步骤2来确定要迁出哪些实例。此外，对于所有热主机，如果它们的使用量超过阈值$\theta_{acu}^{hi} > \theta_{acu}^{mig}$，所有实例的舰队管理器规定的最大ACU（回顾图3第3节中实例i在时间t的$h_{i,t}$）将保持在其当前保留的ACU值；这样做的效果是将实例的资源分配冻结在当前值，即禁止超出当前分配的进一步增长。一旦通过迁移和/或某些实例工作负载强度下降而消散热度，这些主机上实例的舰队管理器规定的最大ACU将重置为各自的客户最大ACU。

步骤2：从热主机迁出哪个实例？ 确定正确的迁移实例是一个非平凡的决定，因为有多个标准会影响决策的质量。例如，考虑：(i)对于相同的内存大小，CPU或网络使用率较高的实例可能是更好的迁出候选；(ii)迁移时间受当前内存映像大小和迁移期间的脏页率影响，使某些实例比其他实例迁移更快；(iii)可能需要在一段时间内对实例被迁移的次数有一个"公平"的概念。理论上，这个问题是一种在线装箱问题，加上迁移的复杂性，因此是NP难的[17]。Aurora Serverless的关键设计挑战是提出一种既有效又极快且可扩展的启发式方法（这种决策需要在几百毫秒内为包含数百台主机的池进行，每台主机可能包含数十到数百个实例），并且能够在迁移过程中保持数据库性能稳定。舰队管理器采用了一个3阶段的启发式方法，我们通过经验发现这种方法在这些要求之间提供了良好的权衡。

阶段2a：应用某些迁移资格过滤器以减少要考虑迁出的实例数量（例如，最近迁移的实例被排除）。
阶段2b：创建过滤后实例的偏好排名。每个偏好分数是二进制的，这些分数通过加权和组合。例如，一个分数捕捉实例是否最近被迁移。另一个偏好最近有响应的实例（因此不太可能不可用）。
阶段2c：使用两个排序器为每个实例创建数值分数：(i)第一个排序器返回与实例保留ACU成比例的分数，目的是选择迁移后能缓解更多热度的实例（从而有助于保持迁移次数较低）；(ii)第二个排序器返回网络Rx/Tx吞吐量、EBS吞吐量和EBS IOPS容量的未使用部分（大致）的线性组合。对于这两个排序器，更理想的实例会被分配更高的分数。这两个分数通过加权和合并为一个单一分数。

选择具有最高偏好分数的实例，如果出现平局则使用数值分数来打破。

步骤3：迁移到哪里？ 舰队管理器遵循类似于步骤2的3阶段过程。

阶段3a：应用过滤器以确保主机处于活动状态，新实例不会超过热度阈值，有带宽支持迁移，且主机上的实例数量小于阈值。
阶段3b：基于以下因素创建主机的偏好排名：出于容错原因，倾向于将同一集群的实例放在不同的主机上；倾向于最近没有失败或未参与失败迁移的主机。
阶段3c：计算两个数值分数，然后通过乘积组合它们（得分较高的主机被认为是更理想的目的地）。第一个相当于装箱问题的"最佳匹配"启发式，计算分数为新实例加入后主机热度与$\theta_{acu}^{mig}$的比率。大致思想是确保负载在主机之间不均匀分布，使一些主机有足够的余量作为实时迁移目的地。第二个计算分数为1减去最利用资源对应的ACU与$\theta_{acu}^{mig}$的比率；这个分数的效果是减少资源（即CPU vs. 内存 vs. 网络）之间的负载不平衡。在6.3节的评估中，我们通过与替代方案的比较为我们的启发式方法提供了经验证据。

一个说明性例子： 在图4中，我们通过展示舰队内111台主机的相关状态来说明舰队管理器的实时迁移决策。这里，主机s根据上述步骤1中描述的标准被认为变热。在这个特定情况下，这是由于实例i的扩展导致主机的总ACU超过了$\theta_{acu}^{mig}$阈值。随后，舰队管理器选择实例i本身进行迁出，并选择主机d作为其目的地。值得强调几个观察结果。首先，注意舰队在主机的总ACU负载方面相当平衡，但一些主机（例如主机d）相对空闲，以便在需要时进行大规模迁移。其次，注意为实例i选择的目的地并不是剩余容量最大的主机（例如，比较主机d和主机d’）。这两点都是我们策略的结果，即保持舰队略微不平衡，以便比更平衡的系统能进行更快/更少的实时迁移。

4.2 新实例放置

这里的困难在于缺乏对新实例资源需求的了解（在一般情况下）。系统可用的唯一提示是客户的最小/最大ACU限制。Aurora Serverless使用客户最小ACU作为新实例的资源需求。原因与Aurora Serverless支持的扩展速度比缩减速度快得多有关：如果客户最小ACU是低估的，Aurora Serverless的就地扩展可以快速适应，而如果客户最大ACU被证明是高估的，则会在相对较长的缩减期内导致容量浪费。在此之后，确定哪个主机最能容纳这个新实例的剩余问题与上面步骤3解决的问题完全相同。

客户不会因更高的最大ACU而支付更多费用，这意味着我们鼓励客户在最大容量方面选择安心，并承诺只在需要时使用它。在这些条件下，基于实例需要立即以最大ACU服务工作负载的最坏情况来放置新实例是不合理的。

4.3 舰队规模调整

鉴于Aurora Serverless当前的增长阶段，舰队规模调整的重点是确保舰队始终有足够的主机，并提前足够时间请求额外的主机。通常，随着我们对客户工作负载了解的加深以及资源管理技术效率的提高，我们能够提高期望的利用率水平。舰队管理器采用舰队级需求预测和在舰队利用率超过预定阈值时触发额外采购的组合方法。采用更复杂的预测并将舰队规模调整更紧密地与其他资源管理集成是未来工作的一个领域。

舰队规模调整的一个关键考虑因素是资源管理系统必须进行的计算和高频数据收集，因为这些开销随舰队规模增长而增加。我们将舰队规模保持在一个允许使用一个热度管理服务器进行本地计算舰队健康状况的数量以下。

5 主机内资源管理

主机内的资源管理由实例管理器执行，每个主机上的每个实例都有一个。实例管理器是一个封装了Aurora Serverless在实例内功能的库。Serverless功能是Aurora实例管理器的一个插件，而与资源管理无关的其他功能与常规Aurora相同，从而实现功能对等。图5总结了实例管理器及其与各种实体的交互。在下文中，我们首先描述Aurora Serverless实例管理器的各种支持机制，然后是其资源管理策略。

5.1 机制

5.1.1 数据收集

实例管理器依赖于特定于引擎的代理来实现引擎特有的功能，包括：(i)引擎如何基于提供的缓冲池数量进行扩展；(ii)收集引擎的使用情况和对其所需缓冲池大小的估计。引擎使用自己的内部算法来估计这些数量，并将它们写入共享内存段，代理从中读取这些数据。

对于除缓冲池外的所有资源的使用统计，实例管理器依赖于客户操作系统。它使用多个"指标获取器"，每秒运行一次，从操作系统收集资源使用信息。这些指标被收集到内存中的扩展数据报告中。选择查看每秒数据是基于确保对资源使用峰值在细粒度时间尺度上的响应性。特别是，虽然CPU周期不足通常会导致体验的逐渐降级，但内存不足最终会导致崩溃。因此，如果我们能够，我们需要在知道需要更多内存时尽快批准内存增加。

5.1.2 虚拟化解决方案

数据库引擎，如Aurora支持的MySQL和PostgreSQL引擎，是复杂的，用不提供内存安全的语言编写，处理任意代码和数据，甚至以扩展的形式运行客户提供的原生代码。这种复杂性使数据库引擎容易受到经典安全威胁的影响，如缓冲区和堆栈溢出，主要由内存安全漏洞引起。在像AWS这样的多租户环境中，数据库引擎不适合作为安全边界，需要被包裹在更强大的隔离原语中。自推出以来，Aurora一直在由硬件虚拟化保护的自己的虚拟机(VM)中运行每个数据库实例。这为数据库和客户之间提供了强大的保护，防止远程代码执行、侧信道和其他安全漏洞。Aurora Serverless需要保持这种安全姿态，但也需要一个允许动态调整每个数据库引擎可用内存、CPU和其他资源数量的解决方案。它最初评估了Firecracker VMM [10]，它提供安全、轻量级和灵活的虚拟化。Firecracker在几个方面非常适合：它通过使用硬件虚拟化进行隔离来满足系统的安全需求，允许动态调整内存和CPU，每个VM的开销低至5MB。不幸的是，发现用户空间IO虚拟化（如Firecracker中使用的）的延迟和CPU开销，结合Aurora的分离存储设计[37]，导致缓存局部性差的工作负载性能损失不可接受（这些工作负载对Aurora存储层的增加延迟特别敏感）。我们的团队开发了一种基于Nitro系统[6]的新实例类型，它提供了Nitro的低IO延迟（基于硬件IO虚拟化，通过SRIOV暴露给实例），以及灵活的CPU和内存配置。

5.1.3 资源超额预订支持

主机具有超额订阅（即超额预订）CPU和内存的能力。具体来说，CPU超额订阅意味着主机内所有实例的vCPU总和可以超过主机上的物理CPU总数；内存超额订阅意味着对应于实例客户最大ACU的总内存量可以超过主机的物理内存。

5.1.4 高效内存扩展支持

任何Aurora Serverless实例，无论其实际资源需求如何，都属于同一种称为db.serverless的实例类型，能够增长到128 ACU的大小。在这个意义上，Aurora Serverless实例是过度配置的。由于这种过度配置，Aurora Serverless客户内核中出现了一个特殊的内存使用效率问题。默认情况下，Linux内核将任何未使用的内存视为"浪费"，并设计为尽可能多地使用内存。这在Aurora Serverless上下文中是不理想的，因为内核会倾向于不断增加其使用的内存，可能一直增加到客户最大ACU。Aurora Serverless在其客户内核中实现了一些功能，使其在内存使用上变得节俭。

内存离线：内核实现了内存离线 - 能够动态释放部分内存给主机。内存离线还有助于减少一些元数据内存开销 - Linux为每4KB页面维护一个64B的页面结构，对于db.serverless实例来说，这相当于2GB。
冷页面识别：一个名为DARC [8]的内核进程持续监控页面并识别冷页面。它将基于文件的冷页面标记为空闲，并将冷匿名页面换出。
空闲页面报告：Aurora Serverless引入了一个显式的空闲页面报告机制。客户内部运行一个守护进程寻找空闲页面。如果找到2MB的空闲块，它会报告给虚拟机监控程序，后者可以回收它。
压缩：Nitro仅在2MB粒度下操作，以保持由于回收空闲页面而导致的页面错误开销较低。因此，Aurora Serverless客户操作系统在可能的情况下采用压缩活动，将4KB空闲页面合并成2MB块，以增加它们被虚拟机监控程序回收的可能性。

5.1.5 边界执行

这涉及确保实例根据第5.2节中的扩展策略确定的"边界"分配资源。实例管理器采用两种类型的机制来控制其实例的CPU和内存分配（类似的想法适用于其他资源）：

cgroup：更细粒度的机制使用cgroups [7]。广泛来说，引擎和实例管理器进程被归为一组，并为该组指定对应于本地最大ACU的资源分配。对于CPU，这种机制特别适用于控制子ACU粒度的分配。使用CPU份额和实例管理器JVM的保证大小，为实例管理器提供与数据平面进程的资源隔离。
CPU和内存上/下线：作为上述的补充，可以向客户内核添加或从中移除vCPU或内存（以2MB为粒度）以控制实例的资源分配。引入额外的vCPU可以帮助缓解"嘈杂邻居"问题，特别适用于确保多个小ACU实例合并在一起时的良好性能。内存离线提供了一种限制cgroups无法限制的进程内存使用的方法（因为后者只能限制用户空间进程）。

5.2 策略

实例管理器有两个关键的重要策略问题：(i)边界管理和(ii)就地扩展。

5.2.1 边界管理

实例管理器决策的这个方面关注根据实例最近的使用模式动态调整其保留ACU（即资源分配边界）。Aurora Serverless边界管理策略主要考虑了两个方面。

敏捷高效地检测增长趋势：应选择保留ACU，使其在近期内可能略高于资源消耗。回想图reffig:acus中这个差距（即扩展带）对于快速检测不断增长的资源需求是至关重要的；这种检测允许实例管理器相应地重新评估并增加实例的分配。同时，扩展带不应导致资源的浪费性过度配置。

我们发现效果良好的方法如下。实例管理器每秒监控数据平面内存占用，并维护实例估计动态内存使用的历史记录。它使用过去一分钟的最大内存使用量并将其转换为ACU，以确定实例的保留ACU。它不仅仅关注内存。我们还查看其他参数，如CPU使用率、网络吞吐量和块设备IO。当任何这些参数超过给定ACU数量的当前允许最大值时，即使其他参数没有超过配额，服务也认为这个VM使用了更多ACU。如果当前ACU使用量低于客户配置的最大值，这将导致为实例分配更多资源。

受控增长：保留ACU的增长速度应该受到限制，以避免快速增长的实例压倒舰队管理器基于实时迁移的补救措施。为此，实例管理器限制扩展速率，以给舰队范围的资源管理足够的时间通过实时迁移来缓解主机上的高热度。具体来说，实例管理器为实例的保留ACU实现了基于令牌桶的调节器（回顾第3节的$r_{i,t}$）；因此，只要实例的使用量低于其保留ACU，它就能享受几乎即时的扩展。

源自网络[15]的经典令牌桶由两个参数表征：(i)可持续（或承诺）速率（R字节/秒）和(ii)桶大小（B字节）。从概念上讲，令牌以固定速率R进入桶中。策略基于确保只有当等于其大小的令牌可用时，资源分配请求才会得到满足；桶的内容会相应调整以反映这种令牌的消耗。

实例管理器为ACU抽象调整了经典令牌桶，并进行了以下增强：令牌桶参数被定义为当前本地最大ACU c的增函数，即R = R(c) ACUs/s和B = B(c) ACUs。Aurora Serverless基于自身观察以及客户需求做出这个选择，因为他们的工作负载在更高强度下往往需要更高的增长率。实例管理器令牌桶参数由经验观察到的迁移持续时间和工作负载资源增长分布决定。从高层次来看，以高概率，单个精心选择的迁移能够消散的热量应该能够舒适地容纳迁移期间令牌桶允许的增长。

最后，Aurora Serverless还限制了缩减速率。限制缩减速率是有限扩展速率的必然结果 - 由于扩展只以故意控制的速率发生，实例管理器选择不激进地缩减，以防高工作负载强度在短暂平静后返回。关键思想是在开始缩减之前允许足够长的低活动时间经过。

5.2.2 就地扩展

就地扩展的核心元素关注确定引擎的理想扩展目标（即资源分配水平）。实例管理器对缩减采取比扩展更谨慎的方法。以下是用于确定引擎理想扩展目标的两步过程。这个决策每秒运行一次，并考虑最多几分钟的每秒历史使用数据。决策的大部分关注资源特定的"决策器"，每个决策器用于估计实例对特定资源类型的需求。

步骤1：决策器：每个决策器将其对特定资源需求的预测转换为引擎缓冲池需求的通用货币，允许跨各种决策器进行比较。我们下面描述直接基于引擎缓冲池的决策器，然后是一个代表性的非缓冲池决策器：

估计引擎的缓冲池需求。为此，它将引擎在过去一分钟内的最大缓冲池使用量作为其预计缓冲池需求。具体决定方式因引擎而异，因此由特定于引擎的代理从其与引擎共享的内存段中获取。
响应实例最近CPU使用的重大变化。首先确定以下两个数量：(i)过去30秒的P50 CPU使用率；和(ii)过去60秒的P70 CPU使用率。对于这些百分位数中的每一个，它根据ACU的形状确定相应的内存大小（分别称为mem30s和mem60s）。如果mem30s超过当前引擎固定内存，决策器的目标引擎固定内存大小设置为mem30s。然而，如果mem30s和mem60s都低于当前引擎固定内存，决策器的目标引擎固定内存大小设置为mem60s。注意潜在的缩减比扩展考虑得更谨慎。

还使用了四个额外的基于资源的决策器，用于网络（接收和传输）和存储（带宽和IOPS），在概念上类似于上述CPU的决策器。

步骤2：组合各种决策器：通过取各种决策器产生的引擎缓冲池需求的最大值，将它们转换为单一预测。这确保了如果任何决策器规定容量增加，就会发生扩展，而只有当所有决策器都这样做时，才会发生缩减。最小扩展粒度为0.5 ACU。

6 经验观察和评估

在本节中，我们结合Aurora Serverless舰队的观察和模拟来理解其资源管理的有效性。

6.1 数据集和感兴趣的指标

我们报告来自2个不同PostgreSQL舰队的指标：(i) 舰队1：AWS区域us-east-1，在2024年1月14日至2024年2月1日的17天期间；(ii) 舰队2：AWS区域us-west-2，在2024年1月1日至2024年2月1日的31天期间。我们还使用这些舰队的实例级保留ACU测量数据进行模拟。

通常，评估Aurora Serverless资源管理有效性时，有两类指标值得关注。第一类指标与舰队的运营效率有关，例如主机利用率。第二类指标与客户体验有关，例如提供的资源弹性。虽然由于专有性质，我们无法分享与舰队规模、主机利用率水平以及运营参数（如利用率阈值或令牌桶）设置相关的绝对数字，但我们将呈现以下指标以帮助理解客户体验：

多少百分比的扩展事件是就地满足的，而不是通过实时迁移？较小的百分比表明我们的重新打包和放置策略的有效性。
多少百分比的扩展事件导致主机被认为变热？回想一下，对于被认为变热的主机，在进行补救性实时迁移时，其实例最大ACU暂时限制在当前保留的ACU。这些补救措施对客户工作负载有什么影响？

6.2 客户体验观察

在舰队1中，我们的观察期内共有33,792个实例。这些实例总共展现了16,440,024次扩展事件。其中，只有2,923次扩展事件需要一次或多次实时迁移（即主机上的 $\theta_{acu}^{mig}$ 阈值被突破），而绝大多数（99.98%）完全通过我们的就地扩展机制得到满足。在无法就地满足的扩展事件中，大多数（52%）只需要1次实时迁移；这类扩展事件的平均迁移次数为1.68。最后，主机突破其 $\theta_{acu}^{hi}$ 阈值的次数为198，即对于6.77%无法就地满足的扩展事件，实例保留的ACU暂时保持在其当前分配水平。

在舰队2中，我们的观察期内共有12,467个实例。这些实例总共发生了8,151,229次扩展事件。其中，只有1,214次扩展事件需要一次或多次实时迁移，而其余的完全通过我们的就地扩展机制得到满足。在无法就地满足的扩展事件中，大多数（55%）只需要1次实时迁移；这类扩展事件的平均迁移次数为1.56。最后，主机突破其 $\theta_{acu}^{hi}$ 阈值的次数仅为48，即对于3.95%无法就地满足的扩展事件，实例保留的ACU暂时保持在其当前分配水平。

这些观察表明，Aurora Serverless的重新打包和放置策略在确保绝大多数扩展请求完全在当前主机内本地满足方面是有效的，为客户提供了无缝的资源弹性体验。此外，即使需要重新打包，通常一次迁移就足以进行补救，这限制了对客户资源弹性和性能的任何不利限制。

6.3 与替代重新打包策略的比较

为了说明我们如何选择整体方法的特定方面而不是其他自然替代方案，我们在模拟中与一个基线进行比较，该基线修改了第4.1节中我们技术的步骤3（“迁移到哪里？"）如下：它采用纯粹的最佳匹配方法，而不是我们结合最佳匹配和CPU/内存平衡的方法。通常，我们发现基线倾向于将实例集中在比我们的技术更小的主机集上，导致这些主机的利用率高于我们技术下的占用主机。我们的技术比基线维持更多空或轻载主机，这使得平均需要更少的迁移来缓解热度。对于舰队1，我们发现基线的总实时迁移次数比我们的技术高82%，而繁忙主机的平均利用率约高10%。作为客户体验影响的指标，实例ACU分配在热度被补救时"冻结"的总时间增加了约55%。同样，对于舰队2，我们发现基线的总实时迁移次数约高57%，主机的平均利用率约高12%。实例ACU分配被冻结的总时间增加了57%。

6.4 仔细观察迁移辅助的扩展

最后，我们仔细观察一个实例，其扩展由于进行另一个实例的实时迁移而创造的容量而得到就地满足。图6显示了感兴趣的关键事件。我们关注一个时间段（归一化到(0, 100)时间单位范围），在此期间，容纳我们扩展实例（“扩展实例”）的主机（标记为"源主机”）由于扩展实例资源需求的快速增长而变热。我们描述了源主机的总保留ACU（归一化到(0, 100)范围）在这段时间内的演变。我们还显示了扩展实例贡献的热度，它在35个时间单位左右开始扩展。在41个时间单位左右，舰队管理器发现$\theta_{acu}^{mig}$阈值被突破，随后它确定了一个"迁移实例"进行迁出。选择的目的地是"目标主机"，其负载比源主机低得多。我们还显示了目标主机热度的时间线。迁移在41个时间单位开始，在50个时间单位结束。我们看到迁移有效地允许扩展实例满足其需求。迁移结束后，源主机的总热度保持在$\theta_{acu}^{mig}$以下，主要是因为扩展实例没有进一步扩展（它在达到峰值后不久开始稳定缩减，在约66个时间单位时回到几乎为0的使用率）。如果它需要进一步扩展，舰队管理器会启动额外的迁移以允许这种增长。

7 相关工作

集群和数据中心规模系统的资源管理有大量文献，可以追溯到20世纪90年代。Aurora Serverless采用了这些工作中的几个想法，并根据其需求进行了微调。工作负载资源需求的多种互补形式被利用。将CPU密集型、内存密集型和网络密集型工作负载放在一起可以提高打包密度[20,24,34,39]。单个工作负载的峰值需求可能很少发生，允许为其配置不足的资源[27,36]。一组工作负载的总需求可能表现出比单个峰值之和低得多的峰值需求（因为单个峰值发生在不同时间），允许资源被超额预订[13,16,32,36]。虽然Aurora Serverless的方法受到这些想法的深刻影响（特别是与超额预订相关的想法），但其一个显著特征是它基于最近观察到的工作负载特征而不是长期分析和表征来做出决策。这种方法部分是由其简单性和高度灵活的纠正性实时迁移设施的可用性所驱动的。

许多工作已经证明了结合预测和反应技术进行管理的优点[25,29,30,35]。这一领域的早期工作使用了排队理论和控制的经典思想[14,19,33]。最近，使用（深度）ML/RL研究这类问题的技术引起了很大兴趣[21,22,25]。虽然Aurora Serverless的反应机制已经证明是有效的，但将预测管理纳入舰队规模调整和迁移调度可能会带来进一步的改进，我们目前正在研究这一点。例如，许多Aurora Serverless工作负载表现出周期性，如一天中的时间效应[11,12]，这些适合预测管理。我们的初步调查表明，反应机制的一个特殊弱点与释放未使用的资源有关 - 回想Aurora Serverless的保守缩减。预测资源需求的下降趋势可能允许Aurora Serverless更有效地释放空闲主机以节省成本。

虽然实时迁移作为资源管理的一个控制旋钮在许多论文中被研究过[18,28,38,40]，但由于相关的复杂性，它在商业规模系统中的使用相对不常见。Aurora Serverless在将实时迁移建立为对性能敏感和具有挑战性的工作负载类别的有效控制旋钮方面做出了重要贡献。

作为负载分配问题，我们的方法与大多数集群系统形成对比 - 大多数系统试图保持系统负载平衡[23]，而Aurora Serverless属于较少见的故意保持集群"不平衡"的系统类别[26,31]。具体来说，它确保舰队始终有一些主机有足够的备用容量，可以作为从较繁忙主机迁移实例的目的地。

8 经验教训和关键要点

我们强调在开发和改进Aurora Serverless资源管理过程中学到的一些显著经验教训。

正如一开始所述，一个核心设计原则是从简单开始，避免过早优化的陷阱。这在资源管理领域尤为重要，因为存在大量丰富的技术。我们提供了几个这种方法的例子，只有在观察到客户工作负载特征和需求的基础上才增加更多复杂性。
设计可预测的资源弹性体验一直是第二个核心原则，我们相应地共同设计了我们的SLA和资源管理。具体来说，任何效率的改进都必须与提供一致性能体验的目标保持一致。在这种情况下，一个特别有趣的设计选择是限制允许实例资源分配增长的速率，即使这意味着有时我们不让实例增长得像其主机上可用的余量理论上允许的那么快。
Aurora Serverless资源管理的决策主要是反应性的。这意味着不使用对资源需求（或任何其他工作负载特征）的明确预测。资源管理组件使用最近的数据（粒度为一分钟到几分钟）作为即将到来行为的代表（即假设工作负载特征在分钟尺度上具有时间局部性），这可以被视为一种隐式预测形式。显然，利用工作负载的可预测性（例如，一天中的时间效应[11,12]）可以帮助Aurora Serverless改善其成本（例如，通过提前进行迁移并在工作负载强度低时释放主机），这确实是一个重要的正在进行的研究领域。相对于基于预测的替代方案，反应控制的主要优点是其简单性。此外，随着迁移技术变得更加灵活，反应式和预测式管理之间的差距可能会缩小。
我们发现让舰队范围与主机级别的资源管理方面大部分独立运作是有效的。它们之间唯一的交互发生在实例特定的$h_{i,t}$上，舰队管理器在热主机上将其从客户最大ACU的默认值降低。这反过来影响边界管理使用的保留ACU限制。这显著简化了我们的资源管理算法，并使它们比替代方案更具可扩展性。
最后，Aurora Serverless的演变提供了一个强有力的例证，说明能够以更适合数据库工作负载的方式发展虚拟机监控程序和操作系统内核。这似乎是一个未被充分利用的研究领域，在共同设计和优化这些层面可能存在很多机会。

9 结束语

我们描述了Aurora Serverless最新版本中的资源管理如何采用经典技术，同时也贡献了一些新颖的想法。它将可预测的资源弹性作为其核心目标。这一点最好地体现在即使在理论上主机的备用容量允许更快增长的情况下，它也使用令牌桶调节来控制实例扩展。它主要依赖于基于最近分钟级测量（即假设工作负载特征具有短期时间局部性）的反应式控制，这种控制基于舰队范围和主机级管理之间的松散耦合。其核心控制旋钮是实时迁移设施。它贡献了新颖的启发式方法来识别要迁移的实例及其目的地，这些方法仔细平衡了多个优化目标。其负载分配的特点是一种跨主机的负载不平衡形式，以促进灵活的实时迁移。

微调这些技术是一个持续进行的过程，还有几个进一步探索的方向，最值得注意的是可以从以下方面获得改进：

(i) 为实时迁移引入预测技术； (ii) 共同设计预测和反应机制，使它们能很好地互补； (iii) 更紧密地整合舰队范围和主机级管理； (iv) 利用源于互补资源需求的统计复用机会（例如，优先将CPU密集型和内存密集型实例打包在一起）； (v) 使用复杂的基于ML/RL的技术进行工作负载预测和决策。