基礎設施守護着企業內部重要 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 利用率，而無需考慮整體工作負載水平，不在活動池中的服務器不接收流量。
我們將其描述爲反饋閉環控制（feedback loop control）問題，如圖 1 所示。控制閉環首先從收集所有活動服務器的利用率信息（CPU、請求隊列等）開始。根據這些數據，Autoscale 控制器對最優活動池大小作出決定，並將決定傳遞給負載均衡器。然後，負載均衡器在活動服務器之間均勻地分配工作負載。它在下一個控制週期中重複這一過程。
決策邏輯
反饋閉環的關鍵部分是決策邏輯。我們希望做出最優決策，以適應不斷變化的工作負載，包括因突發時間導致的工作負載激增或下降等情況。一方面，我們希望最大限度地利用節能機會。另一方面，我們不希望流量過度集中，以至於可能影響網站的性能。
爲此，我們採用了經典的控制理論和 PI 控制器來獲得反應時間快、超調量小等最優控制效果。爲了應用控制理論，我們首先需要對 CPU 利用率和每秒處理請求數（RPS）等關鍵因素的關係進行建模。爲了做到這一點，我們進行實驗來了解它們之間的相互關係，然後根據實驗數據來估算模型。例如，圖 2 顯示了 Facebook 上一種 Web 服務器的 CPU 和 RPS 之間關係的實驗結果。圖中藍點爲原始數據點，紅色虛線爲估算模型（分段線性）。根據得到的模型，然後用經典的穩定性分析法設計控制器，挑選出最優控制參數。
部署與初步結果
Autoscale 已被部署到 Facebook 的生產 Web 集羣中，到目前爲止，Autoscale 已被證明是成功的。
在當前階段，我們決定要麼讓不活動的服務器處於空閒狀態以節省能源，要麼將不活動的容量重新用於批處理任務。這兩種方式都提高了我們的整體能源效率。
圖 3 顯示的是 Facebook 的一個生產 Web 集羣的結果。Y 軸是通過 Autoscale 在 24 小時週期內進入非活動模式的服務器的歸一化數值。這些數值是根據午夜時分非活動服務器的最大數量進行歸一化的。而且，正如我們所預期的那樣，在高峯期間，這個集羣中的任何服務器都不能進入非活動模式。
在將非活動服務器進入省電模式時的節能效果方面，圖 4 顯示了我們其中一個生產 Web 集羣的總功耗——相對於每日最大功耗的歸一化功耗值。紅線是在沒有 Autoscale 的情況下，我們所能做的最好的。相比之下，藍線顯示的是使用 Autoscale 後的功耗。在這個集羣中，Autoscale 在午夜時分節省了 27% 的電能（正如預期的那樣，高峯時段節省的功耗爲 0%）。在 24 小時週期內，不同的 Web 集羣平均節能率約爲 10~15%。在擁有大量 Web 集羣的系統中，Autoscale 可以節省大量的能量。
下一步
我們在優化軟件基礎設施以提高能源效率方面仍處於早期階段，我們還在繼續在軟件棧的不同層次上探索機會，以降低數據中心的功耗。我們希望通過不斷的創新，讓 Facebook 的基礎設施更加高效、更加環保且可持續。
原文鏈接：