Facebook 如何让软件基础设施更加节能？

基础设施守护着企业内部重要 IT 设备的运行，同时也产生大量能耗。Facebook 作为世界上访问量第三大的网站，每月有高达 24.1 亿活跃用户（截止 2019 年），显然，Facebook 的能耗是极其巨大的。为了践行绿色、环境可持续发展的理念，Facebook 在这方面投入了很大的功夫。本文讲述了 Facebook 是如何让其软件基础设施更加节能。

本文最初发表于 Facebook Engineering 官方博客，由 InfoQ 中文站翻译并分享。

随着企业规模的扩大，提高能源效率和减少环境影响成了我们数据中心团队的首要任务。通过开放计算项目（Open Compute Project），我们谈了很多关于 Facebook 在节能硬件和数据中心设计方面取得的进展，但我们也开始研究如何提高我们软件的能源效率。我们探索了多种方法，包括功率建模和性能分析、峰值功率管理和能量比例计算等。我们开发了一项特别的技术，这是一种名为 Autoscale 的节能负载均衡系统，已在生产集群中得到推广，并显示出显著的节能效果。

节能负载均衡

每天，Facebook 的网络集群都要处理数十亿个页面请求，这会提高服务器的利用率，尤其是在高峰时段。

Facebook 的默认负载均衡策略是基于一个经过修改的循环算法（round-robin algorithm）。这意味着每个服务器接收的页面请求数量大致相同，利用的 CPU 数量也大致相同。因此，在工作负载较低的时候，特别是午夜时分，CPU 的整体利用率并不像我们期望的那样高。例如，Facebook 一个特定类型的 Web 服务器在空闲时消耗大约 60 瓦的功率（0 RPS，即每秒处理请求数）。当服务器的 CPU 利用率（PRS 值很小）较低时，功率将跃升至 130 瓦。但当服务器以中等水平的 CPU 利用率运行时，功耗仅略微增加到 150 瓦。因此，从能效的角度来看，我们应该尽量避免以较低的 RPS 运行服务器，而是尽量运行在中等水平的 RPS 下。

为了解决这一问题，并更有效地利用能量，我们改变了将负载分配到集群中不同 Web 服务器的做法。Autoscale 的基本思想是，负载均衡器将工作负载集中到某台服务器上，直到它至少有一个中等水平的工作负载，而不再是纯粹的循环方式。如果整体工作负载较低（比如午夜时分），负载均衡器将只使用服务器的一部分。其他服务器可以仍处于空闲状态，也可以用于批处理工作负载。

虽然这个想法听起来很简单，但对于一个大规模的系统来说，要有效地、稳定地实现这一想法，却是一个具有挑战性的任务。

整体架构

在每个前端集群中，Facebook 使用自定义负载均衡器将工作负载分配到 Web 服务器池。在实现 Autoscale 后，负载均衡器现在使用的是活动的，或者说是“虚拟的”服务器池，它本质上是物理服务器池的一个子集。Autoscale 的设计是为了动态调整活动池的大小，使每台活动服务器都能获得至少中等水平的 CPU 利用率，而无需考虑整体工作负载水平，不在活动池中的服务器不接收流量。

图 1：Autoscale 整体架构

我们将其描述为反馈闭环控制（feedback loop control）问题，如图 1 所示。控制闭环首先从收集所有活动服务器的利用率信息（CPU、请求队列等）开始。根据这些数据，Autoscale 控制器对最优活动池大小作出决定，并将决定传递给负载均衡器。然后，负载均衡器在活动服务器之间均匀地分配工作负载。它在下一个控制周期中重复这一过程。

决策逻辑

反馈闭环的关键部分是决策逻辑。我们希望做出最优决策，以适应不断变化的工作负载，包括因突发时间导致的工作负载激增或下降等情况。一方面，我们希望最大限度地利用节能机会。另一方面，我们不希望流量过度集中，以至于可能影响网站的性能。

为此，我们采用了经典的控制理论和 PI 控制器来获得反应时间快、超调量小等最优控制效果。为了应用控制理论，我们首先需要对 CPU 利用率和每秒处理请求数（RPS）等关键因素的关系进行建模。为了做到这一点，我们进行实验来了解它们之间的相互关系，然后根据实验数据来估算模型。例如，图 2 显示了 Facebook 上一种 Web 服务器的 CPU 和 RPS 之间关系的实验结果。图中蓝点为原始数据点，红色虚线为估算模型（分段线性）。根据得到的模型，然后用经典的稳定性分析法设计控制器，挑选出最优控制参数。

图 2：一种 Web 服务器的 CPU 与 RPS 关系的实验结果，红色虚线为估算的分段线性模型。

部署与初步结果

Autoscale 已被部署到 Facebook 的生产 Web 集群中，到目前为止，Autoscale 已被证明是成功的。

在当前阶段，我们决定要么让不活动的服务器处于空闲状态以节省能源，要么将不活动的容量重新用于批处理任务。这两种方式都提高了我们的整体能源效率。

图 3 显示的是 Facebook 的一个生产 Web 集群的结果。Y 轴是通过 Autoscale 在 24 小时周期内进入非活动模式的服务器的归一化数值。这些数值是根据午夜时分非活动服务器的最大数量进行归一化的。而且，正如我们所预期的那样，在高峰期间，这个集群中的任何服务器都不能进入非活动模式。

图 3：在 24 小时周期内，被 Autoscale 设置为非活动模式的 Web 集群中服务器的归一化数量

在将非活动服务器进入省电模式时的节能效果方面，图 4 显示了我们其中一个生产 Web 集群的总功耗——相对于每日最大功耗的归一化功耗值。红线是在没有 Autoscale 的情况下，我们所能做的最好的。相比之下，蓝线显示的是使用 Autoscale 后的功耗。在这个集群中，Autoscale 在午夜时分节省了 27% 的电能（正如预期的那样，高峰时段节省的功耗为 0%）。在 24 小时周期内，不同的 Web 集群平均节能率约为 10~15%。在拥有大量 Web 集群的系统中，Autoscale 可以节省大量的能量。

图 4：使用和不使用 Autoscale 的生产 Web 集群的功耗（经归一化处理）

下一步

我们在优化软件基础设施以提高能源效率方面仍处于早期阶段，我们还在继续在软件栈的不同层次上探索机会，以降低数据中心的功耗。我们希望通过不断的创新，让 Facebook 的基础设施更加高效、更加环保且可持续。

原文链接：

https://engineering.fb.com/production-engineering/making-facebook-s-software-infrastructure-more-energy-efficient-with-autoscale