摘要

原文链接：https://dl.acm.org/doi/pdf/10.1145/3342195.3387524

在许多公共和私有云系统中，用户需要指定资源量（CPU内核和RAM）的限制以为其工作负荷提供资源。 超出其限制的作业可能会受到限制或终止，从而导致最终用户请求的延迟或丢弃，因此人工操作人员针对这种问题出于谨慎考虑，会申请高于任务自身需要的配置。 从规模上讲，这将导致大量的资源浪费。

为了解决这个问题，Google使用Autopilot自动配置资源，同时调整作业中的并发任务数（水平缩放）和单个任务的CPU /内存限制（垂直缩放）。 Autopilot与人工操作员遵循相同的原则：Autopilot的主要目标是减少松弛（slack）（申请资源和实际资源使用之间的差异），同时最大程度地降低因内存不足（OOM）错误或 由于CPU节流，其性能下降。 Autopilot将机器学习算法应用到有关作业先前执行情况的历史数据上，再加上一组经过微调的启发式方法来实现这一目标。 在实践中，Autopilot工作只有23％的松弛（slack），而手动管理工作只有46％的松弛（slack）。 此外，Autopilot将受OOM严重影响的工作数量减少了10倍。

尽管有其优点，要确保Autopilot被广泛采用仍需付出巨大的努力，包括使尚未加入的客户容易看到潜在的建议，自动迁移某些类别的任务以及增加对自定义推荐器的支持。 在撰写本文时，Autopilot任务占Google资源使用的48％以上。

ACM参考格式：

Krzysztof Rzadca，Pawel Findeisen，Jacek Swiderski，Przemyslaw Zych，Przemyslaw Broniek，Jarek Kusmierek，Pawel Nowak，Beata Strack，Piotr Witusowski，Steven Hand和John Wilkes。 2020年。

Autopilot：Google的工作负载自动缩放。 在第十五欧洲2020年4月27日至30日，计算机系统会议（EuroSys'20），希腊伊拉克利翁。 ACM，美国纽约，纽约，共16页。 https://doi. org/10.1145/3342195.3387524

1 介绍

许多类型的公共云和私有云系统要求其用户声明在执行期间其工作负载将需要多少个实例以及每个实例所需的资源：在公共云平台中，用户需要选择他们需要租用虚拟机（VM）的类型和数量； 在Kubernetes集群中，用户可以设置Pod副本的数量和单个Pod的资源限制; 在Google中，我们要求用户指定所需的容器数量以及每个容器的资源限制。 这些限制使云基础架构能够提供足够的性能隔离，从而使云计算成为可能。

但是限制（主要是）对用户造成了麻烦。 很难估计一个作业需要多少资源才能最佳运行：CPU功率，内存和同时运行的副本数的正确组合。 负载测试可以帮助找到初始估计值，但是随着资源需求随时间变化，这些建议将过时，因为许多最终用户服务工作具有每日或每周的负载模式，并且随着服务变得越来越流行，流量在更长的时间内发生变化 。 最后，处理给定负载所需的资源会随着基础软件或硬件堆栈的新功能，优化和更新而变化。如果CPU容量不足，超出请求的资源可能会导致性能下降，或者导致任务被杀死 内存不足（OOM）。 都不是好事。

从调研结果看，理性的用户将故意高估其工作所需的资源，从而导致对物理资源的不良利用。 一项分析[26]对在一个Google集群[27]上执行的为期一个月的作业跟踪显示，平均内存利用率为50％； 对阿里巴巴YARN集群的另一项分析[23]显示任务的峰值内存利用率从未超过80％。

针对配置资源的困难，一种常见的模式是采用水平自动缩放器，该缩放器通过监控终端用户流量或平均CPU利用率的变化添加或删除副本来缩放任务。 所有主要的云提供商（AWS，Azure和GCP）都提供水平自动扩展功能； 它在某些云中间件（如Kubernetes）中也可用。 较不常见的模式是使用垂直自动缩放来调整每个副本可用的资源量。 两种技术也可以组合。

Autopilot是Google在其内部云上使用的主要自动缩放器。 它提供水平和垂直自动缩放。 本文重点介绍Autopilot的内存垂直扩展，因为这种情况鲜为人知。 论文：

• 描述下Autopilot，以及它用于垂直自动缩放的两个主要算法：第一个算法依赖于历史用量的指数平滑滑动窗口； 另一个是基于从强化学习中借用的思想的元学习，该算法运行滑动窗口算法的许多变体，并为每个任务选择历史数据表现最佳的算法。（译注：强化学习：依赖海量的训练，并且需要精准的奖励。成本较高且比较复杂。元学习：具备自学能力，能够充分利用过去的经验来指导未来的任务。被认为是实现通用人工智能的关键。）

• 通过Google的工作负载采样评估Autopilot算法的有效性；

• 讨论为使我们的集群广泛采用Autopilot而采取的步骤。

2 通过Borg管理云资源

Autopilot的目标和制约因素来自Google的Borg基础架构，并且针对Google的工作负载进行了调整。 我们在此处提供了两者的简要概述：有关Borg的更多详细信息，请参见[34]，有关工作负载的更多详细信息，请参见[26、27、31、35]。

2.1 机器、作业和任务

Google计算基础架构由分布在多个地理位置的许多集群组成。一个中值集群大约有10,000台物理机，并同时运行许多不同类型的工作负载。一台物理计算机可能会同时计算大量占用内存和CPU的批处理，提供存储和内存数据库的切片提供查询能力，还可以处理对延迟敏感的终端用户请求。

（We call a particular instance of a workload a job.）我们称工作负载的特定实例为工作。一项作业由一个或多个任务组成。任务在单个物理计算机上执行；一台机器可以同时执行多个任务。作业是与具有某些功能的服务（例如文件系统或身份验证服务）相对应的逻辑实体；任务执行实际工作，例如为最终用户或文件访问请求提供服务。一项作业持续数月的情况并不罕见，尽管在这段时间内我们可能会多次执行该任务运行的二进制文件。在作业发布时，新任务逐渐取代了运行旧二进制文件的任务。

我们运行的工作负载可以分为两类：服务和批处理。服务工作通常旨在严格保证查询响应时间的性能（例如，在95％的位置上，请求延迟服务级别目标或SLO≤50 ms）。如此严格的等待时间要求排除了OS内核决定之外的任何带内资源分配决策，因此服务作业具有为其明确请求预留的资源。相反，批处理作业旨在“快速”完成并退出，但通常没有严格的完成期限。服务性工作是我们基础架构能力的主要驱动力，而批处理工作通常会填充剩余或暂时未使用的能力，如[4]所示。

内存不足（OOM）事件终止单个任务。某些工作可以合理地容忍OOM事件。有些根本不是；还有一些介于两者之间。总体而言，由更多任务组成且状态较少的作业在单个任务终止时遇到的服务故障越小，因此对OOM容灾能力更高。有些作业需要低的，可重复的延迟来处理请求。有些没有。Autopilot会根据作业的声明大小、优先级和类别选做默认值，但允许我们的用户覆盖它们。Borg驱逐任务，为了安全性和OS更新，为更高优先级的任务腾出空间，并让我们更有效地将工作打包到计算机上。我们有意识的通过计算集群架构和应用的弹性来分散负荷。系统期望通过弹性解决任务驱逐和硬件故障问题。Borg发布了预期内最大驱逐率，观察到的驱逐率之间的差异也使我们可以自由地使用任务的资源设置进行实验-在了解任务需要时可以偶尔进行OOM。 （使用VM实时迁移之类的工具来隐藏外部Cloud VM的这些内部优化。）一个典型的服务工作有很多任务，并且负载均衡器将流量驱动到可用负载，因此丢失任务只会导致其负载平摊给其他任务。 这是正常现象，而不是灾难性的故障，它使我们能够更加积极地利用基础架构，并能够妥善处理偶发的硬件故障。 使用MapReduce [6]中使用的技术，在批处理作业中也内置了类似的弹性。

2.2 Borg调度架构

每个集群都由我们专用的集群调度程序Borg的专用实例管理。 下面，我们简要介绍Borg架构和功能, 因为会直接影响Autopilot设计； 请参阅[34]以获取完整说明。

Borg有一个多复本的Borgmaster，负责制定计划决策，还有一个称为Borglet的代理程序，它在集群中的每台计算机上运行。 一台机器可以同时执行Borglet控制的数十个任务； 依次将其状态和资源使用情况报告给Borgmaster。 将新作业提交给Borgmaster时，它会选择一台或多台机器，这些机器上有足够的空闲资源来执行新提交的作业–或通过驱逐优先级较低的作业来腾出空间来创建这种情况。 在Borgmaster决定将任务的任务放置在何处后，它将启动和运行任务的过程委派给所选计算机上的Borglet。

2.3 通过任务限制进行资源管理

为了获得可接受和可预测的性能，必须将一台计算机上运行的任务相互隔离。 与Kubernetes一样，Borg在单独的Linux容器中运行每个任务，并且本地代理设置容器资源限制以使用cgroup实现性能隔离。 与操作系统级别的传统公平共享不同，这可确保任务的性能在同一二进制文件，不同机器（只要硬件相同）和不同邻居（任务在同一机器上共同调度）的不同执行之间保持一致 ）[38]。

在我们的架构中，CPU和RAM是需要管理的关键资源。 我们使用术语限制来指代通常可以消耗的每种资源的最大允许量。 由于Borg通常将作业的任务视为可互换的副本，因此所有任务通常具有相同的限制。

作业以标准化的毫核心表示其CPU限制[31]，并且此限制由标准Linux内核cgroups机制强制执行。 如果争用很少（以总体CPU利用率衡量），则允许任务使用CPU超出其限制。 但是，一旦发生争用，就会强制执行限制，并且可能会限制某些任务以在其限制内运行。

作业以字节为单位表示其内存限制。 与标准Linux cgroup一样，作业的RAM限制的实施可能是硬性的也可能是软性的，并且作业的所有者在提交作业时声明了实施类型。 一旦使用硬RAM限制的任务超过其限制，该任务就会因内存不足（OOM）错误而被杀死，并将故障报告给Borgmaster。允许使用软RAM限制的任务可以内存超过其限制，但如果计算机上的总体RAM利用率过高，则Borglet将开始杀死超出其限制的任务（带有OOM错误），直到该计算机不再受到威胁（参见标准）为止。 cgroup实施，只是防止超限容器保留更多的内存）。

Borg允许作业在作业运行时修改其资源需求。在水平缩放中，作业可以动态添加或删除任务。在垂直扩展中，作业可以更改其任务的RAM和CPU限制。增加作业的RAM和CPU限制是一项潜在的高成本操作，因为某些任务可能不再适合他们的计算机。在这种情况下，这些计算机上的Borglet将终止一些优先级较低的任务；反过来，这些任务将重新安排到其他计算机上，并可能触发其他优先级更低的任务的终止。 （几年前，我们大大降低了优先级的有效数量，以减少这种等级的数量）。

尽管通常会过度设置作业限制，但存在一些背压：我们向服务用户收取他们保留的资源（而不是他们使用的资源）的费用，并且请求的资源会递减用户的配额-这是对用户的严格限制他们可以在集群中的所有作业中获得的资源总量。 这类似于对公共云中的VM使用定价和配额。 收费和配额都有帮助，但实际上效果有限：配置不足的弊端通常远远超过通过请求较少资源获得的收益。 我们发现这是一个反复出现的主题：在实践中，理论上可达到的效率通常很难实现，因为手动执行所需的努力或风险过高。 我们需要一种自动进行权衡的方法。 这就是Autopilot所做的。

3 Autopilot自动限制

Autopilot使用垂直缩放来微调CPU和RAM限制，以减少冗余（即资源限制与实际使用之间的差异），同时确保任务不会耗尽资源。 它还使用水平缩放（更改作业中的任务数）来适应更大的工作负载更改。

3.1 架构

Autopilot的功能体系结构是三合一的闭环控制系统，一个用于每个作业级别的水平缩放，另两个分别用于每个任务资源（CPU和内存）的垂直缩放。该算法（在后续章节中详细介绍）充当控制器。Autopilot单独考虑作业-没有跨作业学习能力。

Autopilot的实现（图1）采用架构上的一组标准作业的形式：每个集群都有自己的Autopilot。每个Autopilot的资源推荐器（根据其历史使用情况来确定任务的大小）都作为单独的任务运行，并具有三个任务副本以提高可靠性。多复本的Autopilot服务会选择负责选择用于作业的主推荐器，并通过执行器作业将推荐信息（过滤后的）传递给Borgmaster。如果请求更改任务数量，则Borgmaster会相应地生成或终止任务。如果请求更改资源限制，则Borgmaster首先会做出任何需要适应这些限制的调度决定，然后联系适当的Borglet代理以应用更改。一个独立的监控系统跟踪每个任务使用多少资源。Autopilot只是从中订阅更新。

今天，我们的用户通过一个简单的标志设置就明确选择了使用Autopilot的工作。 我们正在将其设置为默认值，并且允许显式不使用。 用户还可以通过多个方面配置Autopilot行为，例如：（1）强制所有副本具有相同的限制，这对于只有一个活动主服务器的容错程序很有用；（2）增加限制，以便来自另一个群集中的副本作业的负载将能够立即故障转移到该群集。

将Autopilot的作业提交给Borgmaster时，它将暂时排队，直到Autopilot有机会为其提出初步资源推荐为止。 之后，它将继续进行正常的调度过程。

3.2垂直（每任务）自动缩放

Autopilot服务根据要自动缩放的资源是内存还是CPU，来选择要用于作业的推荐器。 作业对资源不足事件的容忍度（延迟容忍度与否，OOM敏感度与OOM容忍度） 以及可选的用户输入（其中可能包括明确的推荐者选择）或其他参数来控制Autopilot的行为，例如可以设置的上限和下限。

3.2.1预处理：汇总输入信号

推荐器使用预处理的资源使用信号。 大部分预处理是由我们的监控系统完成的，以减少历史数据的存储需求。 聚集信号的格式类似于[35]中提供的数据。

低级任务监控记录原始信号是针对一项工作的每个任务的时间测量序列。 我们将监视系统在任务time的时间recorded记录为𝑟𝑖[𝜏]。 此时间序列通常每1秒包含一个样本。

（例如，TABLE1。用于描述推荐者的符号

𝑟𝑖[𝜏] 每个任务的原始CPU / MEM时间序列（1s分辨率）

𝑠𝑖[𝑡] 按任务汇总的CPU / MEM时间序列（直方图，5分钟分辨率）

𝑠[𝑡] 每个作业的汇总CPU / MEM时间序列（直方图，5分钟分辨率）

ℎ[𝑡] 每个作业负载调整后的直方图

𝑏[𝑘] 直方图的第k个bin的值（边界值）

𝑤[𝜏] the weight to decay the sample aged 𝜏

𝑆[𝑡] 时的移动窗口推荐𝑡

𝑚 模型（参数化的arg min算法）

𝑑𝑚 使用model模型的衰减率

𝑀𝑚 使用model的安全浮动空间

𝐿 推荐器测试的极限值

𝐿𝑚[𝑡] 使用模型𝑚推荐的极限值

𝐿[𝑡] ML推荐器的最终推荐

𝑜（𝐿）限度的超支成本𝐿

𝑢（𝐿）限制的底线成本𝐿

𝑤𝑜 超支成本的权重

𝑤𝑢 不足成本的权重

𝐿Δ𝐿 改变限制的惩罚权重

𝑚Δ𝑚 权改变模型的惩罚重

𝑑 衰减率，用于计算模型成本

𝑐𝑚[𝑡] 模型m的（已减少）历史成本

CPU或RAM使用率，或收到的查询数）

为了减少设置作业限制时存储和处理的数据量，我们的监视系统将𝑟𝑖[𝜏]预处理为汇总信号𝑠[𝑡]，该信号通常在5分钟的窗口内汇总值。 汇总信号𝑠[𝑡]的一个样本是一个直方图，总结了这5分钟内所有工作任务的资源使用情况。

更详细的内容。对于每个窗口，聚合的每个任务信号𝑠𝑖[𝑡]是一个矢量，其中的直方图保持在原始信号𝑟𝑖[𝜏]上，其中𝜏∈𝑡。对于CPU信号，此向量𝑠𝑖[𝑡] [𝑘]的元素对落入大约400个使用桶中的每个原始信号样本signal [𝜏]的数量进行计数：𝑠𝑖[𝑡] [𝑘] = |{𝑟𝑖[𝜏] : 𝜏 ∈ 𝑡 ∧𝑏 [𝑘 − 1] ≤ 𝑟𝑖[𝜏] < 𝑏 [𝑘]}|，其中𝑏[𝑘]是第k个bin的边界值（这些值由监视系统固定）。对于存储信号，我们在直方图中仅记录5分钟窗口内任务的峰值（最大）请求（即，每个任务直方图𝑠𝑖[𝑡] [𝑘]仅具有一个非零值）。内存信号使用峰值而不是整个分布，因为我们通常希望提供（接近）峰值内存使用率：与CPU相比，任务对内存不足配置（因为它将以OOM结尾）更加敏感。它只会受到CPU限制）。

然后，我们通过简单地将𝑠[𝑡] [𝑘] = Σ𝑖 𝑠𝑖[𝑡] [𝑘]，将每个任务的直方图𝑠𝑖[𝑡]聚合为单个的每个作业的直方图𝑠[𝑡]。 我们没有明确考虑个别任务-例如，通过检查极端价值。 由于大多数Borg作业中的单个任务都是可互换的副本，因此除少数特殊情况外，我们对所有其他任务使用相同的限制。

3.2.2 移动窗口推荐器

移动窗口推荐器通过使用聚合信号𝑠 的统计信息来计算限制。

我们希望限制随着使用量的增加而迅速增加，但要在负载减少后缓慢减小，以避免对工作量暂时下降的过快响应。 为了平滑对负载尖峰的响应，我们通过指数衰减权重𝑤[𝜏]对信号进行加权：

[图片上传失败...(image-485e74-1610255534492)]

其中𝜏是样本年龄，而𝑡1/ 2是半衰期：权重减少一半之后的时间。 Autopilot适合长期运行的工作：我们将CPU信号的半衰期设为12小时，将内存的半衰期设为48小时。使用以下有关的统计信息之一来计算时间𝑡的推荐𝑆[𝑡]：

峰值(𝑆max) 返回最近采样的最大值，𝑆max [𝑡] = max𝜏 ∈ {𝑡−(𝑁 −1),...,𝑡 } {𝑏 [𝑗] : 𝑠[𝜏] [𝑗] > 0}, 最近N个样本中非空存储桶的最大值，其中N是固定的系统参数。

加权平均 (𝑆𝑎𝑣𝑔)，计算平均信号值的时间加权平均值：

[图片上传失败...(image-d80952-1610255534492)]

𝑠[𝜏]是直方图的平均使用率，[图片上传失败...(image-bd1659-1610255534492)]

%j 调整使用量(𝑆𝑝𝑗),首先计算负载调整后的衰减直方图ℎ[ℎ]，其第𝑘个元素ℎ[𝑡] [𝑘]将第𝑘个桶中的衰减样本数乘以负载𝑏[𝑘]：

[图片上传失败...(image-53749d-1610255534492)]

然后返回该直方图的某个百分位数𝑃𝑗（ℎ[𝑡]）。 ℎ与标准直方图𝑠的区别在于，在𝑠中，每个样品都具有相同的单位重量，而在ℎ中，存储桶𝑘中的样品重量等于负载𝑏[𝑘]。

请注意，负载调整后的使用率的给定百分位数随时间的变化可能与相同的使用率百分位数显着不同。在许多情况下，我们要确保在设置限制以容纳提供的负载时可以提供给定负载的给定百分位数，而不是简单地计算瞬时观测到的负载可以处理的次数-即，我们希望根据负载而不是样本数量来加权计算。图2中说明了这种差异：如果将极限设置为1（时间的90％），则最后时刻的9/19单位负载将超过极限（虚线下方）。在这种情况下，负载调整后的直方图ℎ的计算如下。由负载调整后的直方图count计数的单个观测值可以解释为在一定负载（信号的当前电平）下处理的信号区域的单位。 ℎ等于ℎ[1] = 1·9（9个时间单位中的1的负载）和ℎ[10] = 10·10（1个时间单位中10的负载）。因此，ℎ的90％ile（即要求以极限值或低于极限值处理90％的信号区域所需的极限）为10 –在这种情况下，意味着可以在极限范围内处理整个信号.

[图片上传失败...(image-656a9-1610255534492)]

图2.负载信号的90％ile可能与负载时间曲线积分的90％ile显着不同。在此示例中，

使用基于时间的样本，负载的90％ile为1个单位，但如果还考虑了负载的大小，则为10个单位

Autopilot根据信号使用以下统计信息和作业类行。 对于CPU限制，我们使用：

• 批处理作业：𝑆𝑎𝑣𝑔，这是因为，如果一项作业可以承受CPU限制，则对基础结构的最有效限制是该作业的平均负载，这使该作业得以继续进行而不会累积延迟。

• 服务作业：根据负载对延迟的敏感度，调整负载后的使用量是𝑆𝑝95（95％ile）或𝑆𝑝90（90％ile）。

对于内存，Autopilot根据作业的OOM公差使用不同的统计信息。 对于大多数大型作业，默认设置为“低”，对于小型作业，默认设置为“最小”（最严格），但可由用户覆盖：

• 𝑆𝑝98 适用于OOM容错低的作业。

• 𝑆max 适用于OOM容错小的作业。

• 对于具有中等OOM容错的作业，我们选择值来（部分）覆盖短负载峰值。 我们通过使用最大值𝑆𝑝60（加权的60％ile）和最大值0.5％（最大值）的一半来做到这一点。

最后，这些原始建议在应用之前先进行后处理。 首先，建议增加10％到15％的安全裕度（对于较大的限制较小）。 然后，我们采用过去一小时内看到的最大推荐值，以减少波动。

3.2.3基于机器学习的推荐器

原则上，Autopilot解决了机器学习问题：针对一项工作，根据其过去的使用情况，找到一个限制，可以优化表示该工作和基础架构目标的功能。上一节中描述的方法（基于对移动窗口的简单统计来设置限制）指定了解决此问题的算法。相比之下，Autopilot的ML推荐器从成本函数（所需解决方案的规格）开始，然后针对每个工作选择合适的模型参数来优化此成本函数。这种自动化使Autopilot可以为每个作业优化先前方法为所有作业固定的参数，例如衰减率𝑡1/ 2，安全裕度或缩减稳定期。

在内部，ML推荐器由许多模型组成。推荐者针对每项工作定期选择效果最佳的模型（根据下面根据历史使用情况计算得出的成本函数）；然后由所选模型负责设置限制。每个模型都是简单的arg min类型算法，可最大程度地降低成本–模型因分配给arg min（译注：arg min 就是使后面这个式子达到最小值时的变量的取值）各个元素的权重而异。机器学习方法反复出现的问题之一是其结果的可解释性[8]：在Autopilot中，推荐器设置的限制必须向工作负责人解释。拥有许多简单的模型有助于解释ML推荐器的操作：单个模型大致对应于推断的工作特征（例如，稳定时间长的模型对应于利用率变化迅速的工作）。然后，考虑到所选模型所施加的权重，其决策很容易解释

更正式地说，对于信号𝑠，在时间𝑡，ML推荐器从一组模型{𝑚}中选择一个单个模型𝑚[𝑡]，用于推荐极限值。模型是参数化的arg min算法，可计算给定历史信号值的极限。模型𝑚由衰减率𝑑𝑚和安全裕度𝑀𝑚设置参数。

在每个时刻𝑡，模型都会测试所有可能的极限值𝐿（可能的极限值对应于直方图块的后续边界𝐿∈{𝑏[0]，...，𝑏[𝑘]}）。 对于每个极限值，模型都会根据最近的使用直方图𝑠[𝑡]计算当前的超支和超支成本，然后用历史值对其进行指数平滑。 超支成本𝑜（𝐿）[𝑡]计算最近直方图中超出限制𝐿的存储桶中的样本数：

[图片上传失败...(image-84fa43-1610255534492)]

同样，cost 𝑢(𝐿) [𝑡] 计算低于限制𝐿的存储桶中的样本数，

[图片上传失败...(image-540fc2-1610255534491)]

然后，模型选择一个极限𝐿 ′ 𝑚 [𝑡]，以使极限的可能变化最小化超限，超限和罚分Δ(𝐿, 𝐿′ 𝑚 [𝑡 − 1])的加权和：

[图片上传失败...(image-74df9e-1610255534491)]

如果𝑥≠𝑦，则Δ（𝑥，𝑦）= 1，否则为0。 （使用Kronecker delta，Δ（𝑥，𝑦）= 1-𝛿𝑥，𝑦。）此函数包含在大型系统中做出资源分配决策的三个关键成本。 溢出表示损失机会的成本–在服务工作中，发生溢出时，查询会延迟，这意味着某些最终用户可能不太愿意继续使用该系统。 营业不足表示基础设施的成本：工作储备的资源越多，所需的电力，机器和人员就越多。 惩罚项Δ有助于避免过于频繁地更改限制，因为这可能导致任务不再适合其当前计算机，从而导致其（或其他任务）被逐出.

最后，将限制增加安全系数𝑀𝑚，即

[图片上传失败...(image-6401b5-1610255534491)]

为了在运行时选择模型（从而优化特定作业的衰减率𝑑𝑚和安全裕度）），ML推荐器为每个模型维护其（指数平滑）成本𝑐𝑚，它是超限，不足和限制更改的惩罚：

img

由于历史成本包括在𝑐𝑚 [𝑡 − 1],中，因此给定模型的欠额𝑢𝑚和超额𝑜𝑚成本仅考虑最新成本，即直方图样本数超出最后一个样本的限制，因此𝑜𝑚 (𝐿𝑚 [𝑡], 𝑡) = sigma:𝑏 [𝑗]>𝐿 𝑠[𝑡] [𝑗], and 𝑢𝑚 (𝐿𝑚 [𝑡], 𝑡) = sigma 𝑗:𝑏 [𝑗]<𝐿 𝑠[𝑡] [𝑗].

img

最后，推荐人选择的模型可以最大程度地降低此成本，但要更改限额和模型会受到其他惩罚：

img

总体而言，该方法类似于multi-armed bandit problem（参考：https://blog.csdn.net/coffee_cream/article/details/58034628） 多臂老虎机问题，其中匪徒的“手臂”与限制值相对应。但是，多臂匪的关键特性是，一旦选择了一个分支，我们就无法观察到所有其他分支的结果。相反，一旦知道下一个时间段的信号，Autopilot便可以计算所有可能极限值的成本函数-除非极少数情况下，激活极限太小且任务以OOM终止（我们展示OOM在4.3节中很少见）。这种完全的可观察性使我们的问题变得相当容易。

集成具有五个超参数：上面定义的成本函数中的权重（𝑑，𝑤𝑜，𝑤𝑢，𝑤Δ𝐿和𝑤Δ𝑚）。这些权重大致对应于美元机会与美元基础设施成本。我们在离线实验中调整这些超参数，在这些实验中，我们根据从代表性工作中获取的已保存迹线的样本来模拟Autopilot的行为。这种调整的目的是产生一种配置，该配置在大部分样本中占据着替代算法（例如，移动窗口推荐器）的主导地位，并且具有类似（或略低）数量的超限和极限调整，以及明显更高的利用率。这种调整是迭代的和半自动的：我们对权重的可能值执行参数扫描（详尽搜索）；然后手动分析异常值（表现异常差的作业）。如果我们认为这种行为是不可接受的，则在下一次参数扫描的迭代中汇总结果时，我们会手动增加相应作业的权重。

这些离线实验使用原始的（未调整的）使用轨迹，即它们不尝试根据新设置的限制来调整信号（例如，在OOM之后，应终止任务然后重新启动）。但是，根据特定的作业，OOM或CPU节流的影响可能有所不同–对于某些作业，OOM可能会增加未来的负载（因为终止的任务的负载由其他任务接管），而对于其他任务，这可能会导致服务质量下降（当服务质量下降时，最终用户会掉下来）。实际上，这不是问题，因为使用情况调整事件很少发生，而且我们会持续监控生产中的Autopilot，在这种情况下，很容易发现过频繁的OOM等问题。

3.3水平自动缩放

对于许多作业，仅垂直自动缩放是不够的：单个任务不能超过其正在运行的计算机。 为了解决这个问题，Autopilot水平缩放可根据作业的负载动态更改作业中的任务数量（副本）。 水平和垂直扩展机制相互补充：垂直自动扩展确定单个任务的最佳资源分配，而水平自动扩展随着服务的受欢迎程度和负载的变化添加或删除副本。

水平自动缩放使用以下来源之一在时刻𝑡 推导出原始建议𝑛𝑟[𝑡]：

CPU使用率：作业所有者指定（1）CPU使用率信号的平均窗口（默认为5分钟）； （2）视界长度𝑇（默认视界为72小时）； （3）统计𝑆：max或𝑃95，即95％ile； （4）目标平均利用率。 Autopilot根据最新T利用率样本的值time在时间time处计算副本数number [𝑡] = 𝑆𝜏∈[𝑡−𝑇，𝑡] {𝑖𝑟𝑖[𝜏]}。 然后，原始建议的副本数为𝑛𝑟[𝑡] =𝑟𝑆[𝑡] /𝑟∗。

目标大小：作业所有者指定用于计算任务数量的函数，即𝑛𝑟[𝑡] =𝑓[𝑡]。 该功能使用来自作业监视系统的数据。 例如，使用排队系统管理请求的作业可以按请求处理时间的95％缩放； 文件系统服务器可能会根据其管理的文件空间量进行扩展。

水平自动缩放比垂直自动缩放需要更多的自定义，垂直自动缩放不需要为绝大多数作业进行配置。即使在标准的CPU利用率算法中，作业所有者也必须至少设置目标平均利用率𝑟∗（这与配置公共云中的水平自动缩放的方式类似）。在我们的基础架构中，水平自动缩放主要用于大型作业。他们的所有者通常喜欢调整自动缩放器以优化特定于作业的性能指标，例如95％的延迟（直接通过指定目标大小；或通过实验性地改变目标平均利用率并观察对指标的影响来间接地）。

然后对原始建议𝑛𝑟[𝑡]进行后处理，以生成稳定的建议𝑛𝑠[𝑡]，该建议旨在减少任务数量的突然变化。 Autopilot为工作负责人提供以下平滑策略选择（对平均工作具有合理的默认值）：

递减的缩减会从𝑇𝑑最近的建议中返回最大建议：𝑛𝑠[𝑡] =max𝑡-𝑇𝑑，𝑡{𝑛𝑟[𝑡]}。因此，缩小是推迟到用户指定的时间，而放大是立即进行的。我们的大多数工作都使用𝑇𝑑：大约40％的员工使用2天； 35％的人使用3天。

缓慢衰减可避免同时终止太多任务。如果当前任务number [𝑛]的数量超过稳定的建议𝑛𝑠[𝑡]，则某些任务将每5分钟终止一次。选择一次终止的任务数以在给定时间内将任务数减少一半（98％的作业使用默认的一小时）。

延迟较小的更改在某种程度上与缓慢衰减相反：当建议与当前任务数之间的差异较小时，它忽略更改。

限制增长使工作所有者可以对正在初始化的任务（即尚未响应运行状况检查）的部分指定限制，从而限制任务的添加速度。

4 推荐系统质量

本部分使用来自我们生产工作负载的样本，探讨了Autopilot在Google上的有效性。 我们在这里集中讨论RAM的垂直扩展，因为OOM具有直接可测量的影响。 关于CPU扩展影响的概述，请参见[31]。

4.1方法论

我们的结果基于监视系统的观察结果，该监视系统使用我们的基础结构监视所有作业。大规模的运营为我们提供了对Autopilot实际收益的良好统计估计，但是任何纯粹的观察性研究的不利之处在于，它无法控制工作获得的收益（Autopilot或手动设置的限值），因此我们需要尽可能弥补这一点。

观察性研究的另一种选择是A / B实验，在该实验中，我们会将Autopilot应用于随机抽样的一组工作样本中。尽管我们对小组工作进行了A / B研究，但迁移高优先级，大型生产工作需要得到工作所有者的明确同意，因此在统计学上意义重大。

另一个选择是使用记录的跟踪进行模拟研究，但是它们有其自身的偏差，并且我们没有可靠的方法来预测实际作业将如何响应诸如CPU限制之类的模拟事件（例如，最终用户观察延迟增加可能会断开连接，降低CPU使用率，或者重新发出查询，从而增加CPU使用率）或OOM事件（例如，如果问题是暂时性的过载，则任务可能会重新启动并成功执行，或者如果是由问题引起的，则再次出错内存泄漏）。

为了减轻可观察性研究的问题，我们使用从几个不同工作人群中抽样的结果。

第一个群体是在我们的作业集合中随机选择的20000个工作的（有偏见）样本。我们从以下四个类别中分别采样了5000个作业：具有使用硬RAM限制的手动设置的限制的作业；具有使用软RAM限制的手动设置的限制的作业；使用Autopilot移动窗口推荐器的作业；以及使用Autopilot ML推荐器的作业。只要我们控制了一些潜在问题，这些群体就可以为我们提供所有服务集对Autopilot效果的衡量指标：

• 大多数具有手动设置的RAM限制的作业都使用硬限制，而Autopilot将其所有作业切换到软RAM限制。 此开关本身可能会减少OOM的数量。 我们通过对相同数量的具有硬RAM和软RAM限制的作业进行采样来缓解此问题。

• 作业可能被迫使用手动限制，因为Autopilot无法正确设置其限制。 我们通过使用第二个群体来解决此问题，该群体包括在特定日历月开始使用Autopilot的500个工作样本。 我们报告了更改前后两个日历月的性能，以减轻二进制文件或负载特性可能已更改的风险。 因为我们只能抽样成功迁移的工作，所以即使这个群体也可能有偏见，但是我们的成功率很高，因此我们认为这不是一个重大问题。

4.1.1 指标

我们报告的绩效指标基于整个日历日（在5分钟的汇总窗口内（我们的监控系统的默认设置），在日历天内（与我们对资源分配的收费方式保持一致）所取的样本），并且通常使用95％百分位数来实现 利用率和OOM率之间的适当平衡。 指标如下：

在一个日历日内，一项工作的足迹是任务平均限制的总和（每个任务均以当日的运行时间加权）。占用空间直接与作业的基础结构成本相对应：任务一旦请求资源，其他高优先级任务便无法回收它们。占地面积以字节表示；但是，我们通过将原始值（以字节为单位）除以一台（大型）计算机所拥有的内存量来对其进行归一化。因此，如果一个作业占用10台计算机，则意味着为其分配的RAM数量等于10台计算机的内存（这并不意味着它在专门用于此作业的10台计算机上分配）。

在一个日历日内，某项工作的相对空闲时间是（限制减去使用量）除以限制-即请求资源中未使用的部分。在这里，使用量是一个日历日报告的所有任务所有5分钟平均使用量值的95％，而限制是该24小时内的平均限制。

日历日内工作的绝对空闲时间（以字节为单位）直接衡量浪费：这是一项工作的所有任务的极限秒数减去使用秒数的总和，除以24×3600（一天）。这种聚集将更多的重点放在更大，成本更高的工作上。此处，limit-seconds是使用5分钟的平均值在任务的运行时间内所请求的内存限制的整数。我们在对占用空间进行归一化的同时对绝对松弛进行归一化，因此，如果算法的总绝对松弛为50，则我们浪费的RAM数量等于50台计算机的数量。实现绝对值的较小值是一个雄心勃勃的目标：它要求所有任务的限制几乎始终与使用相同。

相对OOM率是一天中某项工作经历的内存不足（OOM）事件数，除以该天该工作具有的平均运行任务数。它直接关系到我们的用户需要多少工作量才能容忍Autopilot对工作造成的额外不可靠性。由于OOM很少，因此我们还跟踪根本没有OOM的工作日数。

针对工作日报告指标（即，每个工作将在一个日历月中报告30或31个这样的值），并在所有报告日中为所有工作计算统计数据（例如，相对相对松弛中位数）。 当自动尝试尝试增加作业的限制时（例如，任务变得大于可用的配额，用户指定的边界甚至一台机器的大小），自动驾驶仪可能会达到扩展限制。 我们并未筛选出此类OOM，因为目前尚不清楚该工作的未来行为，并且此类事件的影响应独立于所使用的算法。

4.1.2作业采样和过滤

我们显示了单个日历月（或4个月，以分析迁移的工作）在基础架构上执行的工作样本的性能。 尽管我们的基础架构可以运行许多类型的作业，但其规模是由高优先级的服务性作业驱动的，因为可以保证此类作业获得其声明为极限的资源。 因此，更严格的限制直接转化为更大的容量和未来基础架构扩展速度的降低。 因此，我们的分析重点是这些工作。

除非另有说明，否则我们仅考虑长期运行的工作（至少在整个日历月内提供服务的工作），因为这些工作对我们的基础架构影响最大[26]。 我们还将使用特殊，不寻常的SLO和使用自定义推荐程序的作业筛选出一些作业类别，以使讨论重点放在默认算法的质量上。

4.2 减少预估与真实用量差值

与非Autopilot作业相比，Autopilot作业的松弛度要低得多。图3a显示了每个工作日的空闲时间的累积分布函数（CDF）。非Autopilot作业的平均相对松弛度为60％（硬性限制）至46％（软性限制）；而Autopilot作业的平均相对松弛度为31％（移动窗口）至23％（ML）。

非Autopilot的工作浪费了大量的能力。图3b显示了样本中作业绝对松弛的累积分布函数。我们的10,000个非Autopilot工作样本的总绝对松弛总和（按月平均）等于12,000多台机器；而Autopilot作业样本的绝对松弛量少于500台计算机。差异相当于数千万美元的机器成本。

但是，这些比较可能会有偏差，因为在构建这些样本时，我们控制了每个类别的作业数量，而不是资源的总量：如果所有Autopilot作业的使用率较低，而所有非Autopilot作业的使用率较高，则可能不管每个组的限制质量如何，最终都可以节省类似的绝对松弛量（但是，相对松弛度比较仍然有效）。为了解决这个问题，我们在图3c中显示了作业足迹的CDF。该图确认了与非Autopilot作业相比，Autopilot作业的占地面积确实较小。但是，正如我们在分析迁移到Autopilot的作业时所看到的那样，这种较小的占用空间至少部分是Autopilot减少作业限制的结果。此外，默认情况下，小型作业使用Autopilot（第5节）。

最后，我们分析了最近开始使用Autopilot的工作减少的情况（图4）。在迁移之前，几乎所有作业都使用了硬盘限制。迁移之后，几乎所有人都使用ML推荐器。我们的图表显示了超过4个月的工作寿命的结果。所有作业在同一日历月开始使用Autopilot，表示为第0个月（m0）。我们显示了前两个月中这些作业的效果，当作业使用手动限制时分别表示为m-1和m-2。以及迁移后两个月内的性能，当作业使用Autopilot设置的限制时表示为m + 1和m + 2。

图4a显示了每个工作日相对松弛的CDF。迁移前一个月的平均相对松弛度为75％，中位数为84％。迁移后的一个月，平均相对松弛度下降到20％，中位数下降到17％。迁移后的两个月内，松弛值的分布保持一致，这表明收益是持久的。

绝对的空闲时间（图4b）表明可以节省大量资金：在迁移之前，这些作业浪费了相当于1870台计算机的RAM容量；迁移后，这些作业仅浪费了162台计算机：通过迁移这些作业，我们节省了1708台计算机的容量。

迁移后的工作足迹的CDF（图4c）表明，工作足迹随着时间的推移而增加，表明流量的有机增长。迁移前两个月的工作总规模小于迁移前一个月；同样，迁移后一个月的总足迹要小于迁移后两个月的足迹。 m0的迁移逆转了这一趋势：尽管足迹逐月有机增长，但m + 1的足迹明显小于m-1的足迹。迁移后，足迹的增长速度也降低了，因为m + 2的CDF比m-2的CDF接近m-1。

500个已迁移工作的足迹分布（图4c）与我们整个机队采样的2万个工作的足迹分布（图3c）不同：迁移的工作所占足迹比整个船队要大。这是因为许多小型作业会Autopilot到m0之前，而m0是我们选择作为该样本参考月份的月份（有关详细信息，请参见第5节）。

4.3可靠性

上一节演示了Autopilot可以大大减少浪费的容量。 但是，将这些限制设置为0的琐碎算法将通过这些指标获得更好的结果–以频繁的OOM为代价！ 在本节中，我们展示了Autopilot作业比非Autopilot作业具有更高的可靠性。

图三

图四

图五

图六

图5显示了按工作日划分的相对OOM的累积分布函数（CDF）。 OOM很罕见：超过99.5％的Autopilot工作日没有OOM。 虽然ML推荐器产生的无OOM的工作日数比移动窗口推荐器要多一些，但它也导致相对的OOM数略多（每任务日0.013比0.002）。 两种算法显然都占主导地位的手动限制设置。 由于存在硬RAM限制，因此约98.7％的工作日不使用OOM。 相对OOM率为0.069 /任务日。 软RAM限制作业的相对OOM比率较好，为0.019，但无OOM的工作日略少（97.5％）。

OOM的数量自然取决于相对的松弛度-较高的松弛度意味着更多的可用内存，因此一项任务应该很少出现OOM。图6中的线斜率表示OOM速率与松弛的相关程度，而截距则反映了OOM的总数。具有软限制的非Autopilot作业的回归线低于具有硬限制的非Autopilot作业的回归线；在使用移动窗口算法的Autopilot作业和使用软限制的非Autopilot作业之间也有类似的严格控制。但是，ML算法的回归与使用手动指定的软限制的作业线和使用移动窗口自Autopilot方案的作业线相交，建议对于松弛率低的作业使用更多的OOM，而对于松弛度较高的作业则使用更少的OOM。

表2.按算法，受OOM严重影响的工作日数。每行对应一个不同的阈值，用于将工作日归为受OOM严重影响的类别：例如，在第一行中，如果工作任务的5或1/7（以较高者为准）会严重影响工作日以OOM终止。 “硬”和“软”都有手动限制设置。

表2

由于ML推荐器比滑动窗口推荐器产生的平均相对OOM比率更高，因此ML推荐器可能会过于积极地降低作业限制。但是，ML推荐器旨在偶尔对不会受到太大影响的工作进行OOM。正如我们在第2节中所解释的，我们的工作旨在吸收偶发的故障-只要有足够多的尚在执行的任务能够吸收已终止任务一旦处理的流量即可。这按预期工作，并且好处是可以节省更多资源。但是，可能还是有理由担心推荐者过于激进。

为了探讨这种担忧，我们将一个工作日归类为当OOM在一天中经历的OOM数量大于其阈值数量（例如4）或分数（例如1/7）中较大者时受到OOM的严重影响。表2显示了在某些阈值设置（从更宽松（最高）到更保守（最低））中，受OOM严重影响的工作日数。尽管绝对数略有变化，但是方法的相对顺序保持不变。

在非Autopilot作业中，我们惊奇地发现具有硬RAM限制的作业虽然具有相对较高的OOM（如上所述），但受OOM的影响较小。我们假设用户可能会手动为具有不稳定的内存使用模式的作业手动指定软限制，这特别难以设置。正如预期的那样，在Autopilot作业中，尽管使用移动窗口算法的作业的相对OOM较少，但是与使用ML算法的作业相比，它们更可能受到OOM的严重影响。

我们还更详细地研究了OOM如何集中于各个工作。如果大多数OOM仅发生在少数几个工作中，则可能表明自动缩放算法存在系统性问题-我们宁愿许多工作很少遇到OOM。我们分析了当月至少有一个OOM的作业。对于每项这样的工作，我们用至少一个OOM来计算天数（我们计算OOM天数，而不是简单地计算OOM或相对OOM，而是着眼于可重复性，而不是我们上面测量的幅度）。对于Autopilot ML，此类作业中有46％仅一次进行OOM； 4天或更短时间内完成80％的工作OOM。相比之下，在Autopilot移动窗口推荐器中，只有28％的工作完全是OOM一次； 21天或更短时间内完成80％的工作OOM。

在我们的第二个样本群体中（迁移到Autopilot的工作），OOM的数量太少，无法对相对OOM和严重OOM进行有意义的估计。在迁移前的一个月中，总共有348个工作日，其中至少有一个OOM；迁移后，这个数字减少到只有48。这些工作的迁移成功。

图七

4.4限制变更次数

手动控制的工作很少会改变其限制：在我们的10,000个手动限制的工作样本中，我们观察到一个月内有334次变化，或者每个工作日大约0.001次变化。 图7显示了Autopilot更改10,000个工作样本限制的频率：每个用户的频率比用户高出几百倍。 但是，它仍然相当稳定：在大约70％的工作日中，没有任何变化。 而99％ile的工作日一天内只有6（移动窗口）到7（ML）的限制变化。 考虑到即使被逐出，找到任务的新位置通常只需要几十秒钟，那么为节省大量资金似乎是一个合理的价格。

有人可能会争辩说，上一节中报告的OOM（和严重的OOM）的减少仅仅是由于比操作员更频繁地更改限制而引起的。 在图7中，AutopilotML和移动窗口具有相似数量的极限变化。 但是，如表2所示，Autopilot ML更有效地利用了这一中断预算。

4.5及时行为

在前面的部分中，我们专注于长期运行的工作：我们的工作至少连续工作一个月。在本部分中，我们将根据工作年龄来分析Autopilot的性能。图8a显示了每个不同年龄段的1000个工作的相对松弛的CDF。

运行少于一天的作业的松弛度要比运行时间更长的作业高得多：这是Autopilot针对长期运行的作业进行调整的直接结果–历史记录越多，松弛度越低。但是即使在14天之后，松弛度仍高于上一部分中分析的稳态。

对相对OOM速率的分析（图8b）表明，Autopilot对于短期工作非常谨慎。对于持续时间少于24小时的作业，几乎没有OOM：但是，如果我们过滤掉短期作业（总任务持续时间少于1.5小时的作业），则OOM会比稳定状态更多。一旦我们考虑了7天或更早之前开始的工作，相对OOM比率就可以与稳态行为相提并论。

图八

5 赢得用户的信任：增加采用率的关键

我们的基础架构为成千上万具有不同角色，经验和期望的内部用户提供服务。 较小或较新的服务通常由最初创建它们的软件工程师在生产中运行，而较大的，已建立的服务则具有专门的开发人员/操作团队。 为了增加Autopilot的采用率，我们不仅必须确保算法的质量可以接受，还必须确定并满足工程师对基础架构的需求。 本节讨论这些定性方面。 我们的经验巩固了[5]中描述的许多课程

5.1评估过程

我们与Autopilot一起开发了评估潜在推荐者的流程。推荐人首先在脱机模拟中使用代表作业样本的资源使用情况进行评估。尽管这样的评估还远远没有完成（我们将在4.1节中详细说明问题），但足以确定是否值得在推荐者身上投入更多的精力。如果是这样，我们将继续使用空运行，其中推荐程序与其他推荐程序一起作为生产Autopilot服务的一部分运行–已记录其建议，但未执行。在两个阶段中，我们分析通常的统计汇总，例如均值和高百分位数，但也要特别注意离群值-推荐者在其中表现特别差的工作。这些异常值有助于捕获实现中的错误以及算法的意想不到的后果。

之后，我们执行A / B测试，其中新推荐程序为选定集群中的一小部分用户提高生产限制。即使在此阶段完全失败的算法也不大可能造成灾难性的灾难：如果一个群集中的一项作业失败，该服务的负载均衡器会将其流量切换到其他群集，这些群集应具有足够的能力来应对浪涌。

最后，当新推荐人在A / B测试中获得好评时，我们逐渐将其推荐为整个车队的新标准。为了降低可能发生故障的风险，分批进行分批部署，它们之间有多个小时的间隔，如果发现异常，则可以回滚。

5.2作业所有者可以轻松访问Autopilot限制

我们用于资源监视的标准仪表板（图9）显示了作业CPU和内存使用情况的分布以及Autopilot计算的限制-即使对于未Autopilot的作业（对于这些作业，Autopilot在模拟模式下运行）。 仪表板可帮助用户了解Autopilot的操作，并建立对Autopilot在Autopilot上启用的功能的信任：用户可以看到Autopilot将如何响应每日和每周的周期，新版本的二进制文件或突然变化的负载

5.3自动迁移

一旦我们对大型离线模拟研究和较小规模的A / B实验对Autopilot的操作有了足够的信任，就可以将其作为所有现有小型作业的默认设置（总计最多限制10台机器），并且 所有新工作。 提前通知了用户，他们可以选择退出。 这种自动迁移几乎没有用户反冲，从而大大提高了采用率。

图九

(a)Autopilot作业的痕迹。 8:00之后，一些任务开始显示出更高的内存使用量； Autopilot迅速提高了工作限制。

(b)使用手动指定的限制以及在模拟模式下运行的Autopilot来跟踪作业。 新推出的产品存在内存泄漏，导致内存使用量稳定增加。 在工作开始到OOM时，工作的监视系统在17:30左右开始寻呼呼叫。

直到19:30，值班开发人员才设法提高工作的内存限制（18:20到19:00之间的限制振荡是来自监视系统的时间序列数据未对齐的产物）

。 如果该作业是自动执行的，则可能不会进行OOM设置，因为自动增加的限制将使dev / ops有更多时间发现内存泄漏并回滚到二进制的先前版本。

5.4用自定义推荐器覆盖推荐器

Autopilot的算法依靠历史CPU /内存使用情况来设置将来的限制或任务计数。但是，对于某些作业，其他信号可以更好地预测极限：例如，我们的文件系统服务器的负载几乎线性地取决于服务器控制的文件的总大小。此外，一些长期运行的服务在Autopilot之前已经开发了自己的水平自动缩放器，其中一些包含经过细化的，经过微调的逻辑，这些逻辑已经经过了多年的完善（尽管它们通常仅具有Autopilot的一部分功能，而它们并没有始终跟上Borg的变化）。 Autopilot的自定义推荐程序使用户可以保留此类算法的关键部分（计算任务数量或单个任务资源限制），同时将支持功能（如致动）委派给Autopilot生态系统。

定制推荐器很受欢迎：在提供三个月后，定制推荐器管理着我们全部机队资源的13％。

6 减少工程量

Google遵循减少劳动量的dev / ops原则：繁琐，重复的工作应该由机器而不是工程师来完成，因此我们在自动化上进行了投资。Autopilot就是一个例子。

随着工作量的增加，需要增加工作的限制。受欢迎的服务，即使不包括最初的快速增长阶段，也可能应该每两周或每月调整一次。而且每次推出新的二进制版本都可能需要调整限制。假设这些是手动完成的。我们假设手动调整大小平均需要30分钟的工作：更改配置文件，将更改提交到版本控制系统，查看建议的更改，初始化发布并监视其结果。对于我们的1万个具有手动限制的工作的样本，甚至334个手动限制的调整也代表了大约一个人月的工作量，并且这大大少于预期的更新次数。

Autopilot的水平缩放-向正在运行的作业中添加任务-自动处理自然的负载增长。Autopilot的垂直缩放可以处理每个任务的负载变化，也可以处理推出新二进制文件带来的影响。两者都代表着显着的人工减少。

我们询问了几位大型工作的老板，这些老板迁移到了Autopilot，以估计他们所经历的辛苦工作减少了。一项大型服务（由多个作业组成）报告，在迁移到Autopilot之前，他们每月执行大约8次手动调整大小。

另一项服务估计，Autopilot每月可以为他们节省2个小时的人工调整之前的人工工作。另一个服务的负载在群集之间和时间上变化很大，每月需要大约12次手动调整大小。另一个好处是减少了必须由待命的dev / ops工程师处理的中断（页面）。随着可靠性的提高，任务失败的频率降低，报告系统发出的警报也更少。对于集群中负载差异很大的作业，这种减少尤为明显：设置不同的手动限制的工作是经常出现的问题根源，甚至使监视变得复杂。一项服务报告说，迁移后，Autopilot增加了某些群集中的内存限制，这导致OOM的数量从每天大约2000个减少到可以忽略的数量。迁移后的将近一年中，另一个服务没有报告OOM。通话页面的数量从每周3个减少到少于1个（其余页面用于无关的问题）。

Autopilot的资源限制越来越严格，可能会暴露出一些漏洞，而这些漏洞却由于较大的限制而未被发现。众所周知，罕见的内存泄漏或越界访问是很难找到的。尽管Autopilot仪在大多数情况下都能很好地工作，但它可能仍需要针对一些工作进行自定义配置。因此，当作业迁移到Autopilot然后频繁开始进行OOM时，可能很难区分Autopilot配置错误和真正的错误。一个小组将这种问题归咎于Autopilot的内存限制设置算法，并在几周后才发现根本原因：很少触发的越界内存写操作。

最后，批处理作业会大量使用Autopilot（CPU启用了88％的此类作业）。我们推测这是因为Autopilot使用户甚至不必为此类工作指定限制

7 相关工作

尽管Autopilot执行，UX和某些自定义特定于Borg，但Autopilot解决的问题几乎在云资源管理中普遍存在。

预期的副本数及其资源需求将由许多云资源管理系统中的用户提供，因为调度程序使用它们将任务打包到机器上[14]。 Borg [34]，Omega [29]和Kubernetes [3]都要求用户在提交作业（Borg，Omega）或吊舱（Kubernetes）时设置此类限制。 YARN [32]要求应用程序（作业）声明容器（任务）的数量以及每个容器的CPU和RAM资源需求。在有些不同的情况下，用于HPC系统的调度程序（例如Slurm [37]）需要每个批处理作业来指定计算机的数量。

其他研究证实，当手动设置作业限制时，我们在基础架构中观察到的私有云利用率较低。 [30]分析了阿里巴巴的一万台机器的YARN集群的5天使用情况，并报告说80％的时间中RAM利用率低于55％。 [23]分析了一个短时间（12小时）的阿里巴巴跟踪，表明对于几乎所有实例（任务），峰值内存利用率为80％或更少。 [26]分析了30天的Google集群跟踪[27]，结果表明，尽管平均请求内存几乎等于总可用内存，但实际使用量（超过一小时窗口的平均值）低于50％。

设置更精确的限制的一种替代方法是超额订阅资源，即有意分配给机器任务，以使它们的要求总和高于本地可用的物理资源量。 [30]显示了一个系统过度订阅YARN群集中的资源。尽管超额预订可用于可以承受偶尔的速度下降的批处理工作负载，但它可能导致服务工作负载的尾部等待时间显着增加-这需要仔细的概率处理[2，21]。

水平和垂直自动缩放需要作业具有弹性。通常，众所周知，许多类别的应用程序都很难扩展。例如，JVM在其默认配置下不愿意释放堆内存。幸运的是，对于Autopilot而言，Google的绝大多数工作都是在考虑扩展的基础上进行的。

自动缩放是一个发达的研究领域。最近的调查包括[11，16，22]。大多数研究涉及水平自动缩放。 [17]通过实验分析了一些针对工作流的水平自动缩放算法的性能。 [10]建立了AWS和Azure中水平自动缩放器的概率性能模型。 [24]测量了AWS，Azure和GCE中水平自动缩放器的性能。虽然Autopilot还具有反应式水平自动缩放器，但本文主要集中于垂直缩放（在[16]中也称为调整大小或VM适应）。 Kubernetes垂直吊舱自动缩放器（VPA，[15]）使用移动窗口上的统计信息来设置容器的限制（例如，对于RAM，24小时内的第99个百分点）。 Kubernetes的方法直接受到我们移动窗口推荐器的启发（第3.2.2节）。 [25]提出了一种估计器，该估计器使用窗口中样本的中值和标准差之和。

我们描述了两个推荐器：一个基于从移动窗口计算出的统计信息，其中包含窗口参数（例如，长度）由工作所有者设置（第3.2.2节）；另一个根据成本函数自动选择移动窗口参数（第3.2.3节）。这些简单的统计数据的替代方法是使用更高级的时间序列预测方法，例如自回归移动平均（ARMA）（如[28]中也使用工作绩效模型），神经网络（如[18]中）， [9，20]中的递归神经网络或[13]中的自定义预测表明基于马尔可夫链的预测比基于自回归或自相关的方法表现更好。我们使用此类方法进行的初步实验表明，在绝大多数博格案例中，不需要ARMA的其他复杂性：作业倾向于使用较长的窗口（例如，移动窗口推荐器中内存的默认半衰期为48小时，第3.2.2节）；并且日间趋势足够小，以至于一个简单的移动窗口能够迅速做出反应。对于可以由用户配置的推荐器，我们相信参数具有简单的语义并且可以可预测地调整推荐器更为重要。

Autopilot不建立工作绩效模型：它不会尝试优化批处理工作的完成时间或服务于工作的最终用户响应延迟。我们发现，控制限制使工作所有者可以推理工作绩效（和性能问题），并在工作与基础架构之间进行区分。关注点的分离部分取决于群集和节点级调度程序。例如，Autopilot不需要考虑所谓的嘈杂邻居的性能问题，因为Borg通过特殊机制对其进行处理[38]。为了涵盖其余的一些特殊情况，Autopilot提供了水平缩放挂钩，以允许团队使用自定义指标甚至自定义推荐程序。相比之下，许多研究旨在直接优化工作的绩效指标，而不仅仅是分配的资源量。例如，在Quasar [7]中，用户指定性能限制，而不是限制，而调度程序负责满足这些限制。在公共云中，在其中将作业严格分配给VM，Paris [36]建议在具有代表性任务及其性能指标的情况下配置VM。 D2C [12]是一种水平自动缩放器，它通过学习每一层的性能参数（使用排队论建模）来缩放多层应用程序每一层中的副本数量。学习过程是在线的–不必预先对应用程序进行基准测试。

如果作业类别更窄，则可以进行更具体的优化。 Ernest [33]专注于批处理，机器学习工作，而CherryPick [1]也考虑分析工作。尽管本文着重于服务工作，但Google的88％批处理工作也使用了Autopilot（以CPU消耗量衡量）。 [19]使用强化学习（RL）来驱动服务工作的水平扩展（具有效用函数，考虑了副本的数量，吞吐量和任何违反SLO的响应时间）。 Autopilot的ML推荐器借鉴了RL的一些想法，例如根据模型的历史表现选择模型和极限值。

8 结论

弹性伸缩对于云来说效率、可靠性、运维工作量至关重要。手动设置的限制不仅浪费资源（平均配置限制太高），而且随着负载增加或新版本的服务推出时，会导致频繁违反限制。

自动扩缩对于云来说效率、可靠性、运维工作量至关重要。手动设置的限制不仅浪费资源（平均配置限制太高），而且随着负载增加或新版本的服务推出时，会导致频繁违反限制。Autopilot是Google使用的垂直和水平自动缩放工具。通过自动提高限制设置的精度，它减少了资源浪费并提高了可靠性：内存不足错误不那么常见，不那么严重，并且减少任务间项目影响。使用简单的时间加权滑动窗口算法可以实现其中一些增益，但是切换到受强化学习启发的更复杂的算法可以实现更大的增益。

现在，Autopiloted工作占我们整个集群使用量的48％以上。 实现如此高的采用率需要采取重大的发展和建立信任的措施，即使在可靠性和效率上都有明显的提高。 但是，我们证明了这种额外的工作已获得回报，因为用户不再需要手动调整其工作大小，而提高的可靠性导致更少的通话警报。 我们向其他大型计算集群的用户强烈推荐这种方法。