Categories
程式開發

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 利用率,而无需考虑整体工作负载水平,不在活动池中的服务器不接收流量。

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

图 1:Autoscale 整体架构

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

决策逻辑

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

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

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

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

部署与初步结果

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

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

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

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

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

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

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

图 4:使用和不使用 Autoscale 的生产Web集群的功耗(经归一化处理)

下一步

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

原文链接

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