容量推薦引擎：基於吞吐量和利用率的預測縮放
本文介紹了一種容量推薦模型，實現方式相對相對比較簡單，且已在Uber內部使用，可以依照文中的方式開發一版容量推薦系統。
譯自：Capacity Recommendation Engine: Throughput and Utilization Based Predictive Scaling
簡介
容量是服務可靠性的關鍵部分。為了支援不同的業務單元，Uber的服務需要足夠的資源來處理每天的峰值流量。這些服務部署在不同的雲平臺和資料中心上。手動管理容量通常會導致過度分配資源，導致資源利用率低下。Uber構建了一個自動擴縮容服務，用於管理和調節上千個微服務的資源。目前的自動擴縮容服務單純基於資源利用率指標實現的。最近我們構建了一個新的系統，稱為容量推薦引擎(Capacity Recommendation Engine (CRE))，新的演算法結合了吞吐量和利用率，並使用機器學習模型來實現擴縮容。該模型提供了黃金指標和服務容量之間的對應關係。通過反應性預測，CRE可以基於線性迴歸模型和峰值流量估算出區域服務的容量。除了容量，分析報告還可以告訴我們不同區域服務的特性和效能迴歸。本文將會深入介紹CRE模型以及系統架構，並提供該模型的一些分析結果。
使用的指標
在容量管理方面，利用率(utilization)是最常用的擴縮容指標。在CRE中，除了利用率，還使用吞吐量(throughput)作為另一個容量評估的重要指標。吞吐量代表了業務產品需求。在服務層面，可以轉換為每個例項的RPS(每秒請求數)。每當推出新產品以及變更依賴的扇出模式時，都會直接導致服務吞吐量的變化，從而影響容量需求。我們的目標是獲取滿足利用率需求的服務容量或例項數。我們將例項的CPU core乘以例項數，得到服務所需的總CPU core數。通過將資源分配引入預測模型，就可以將指標與服務容量關聯起來。CRE使用吞吐量和資源分配時序資料來構造線性迴歸模型。
圖1：CRE使用的黃金指標
CRE演算法
Uber使用了多家雲廠商，每家廠商都有不同的網路棧、硬體型別和流量模型。我們將每個區域作為獨立的擴縮容目標，通過單獨進行線性迴歸分析來考慮不同環境下的差異。從結果中可以看出各自的效能差異，並進一步影響縮放組中的容量。
CRE的推薦流程包括如下步驟：
- 評估峰值吞吐量
- 定義目標利用率
- 建立線性迴歸模型
- 生成推薦結果
- 限制服務使用的資源
CRE使用峰值吞吐量和目標利用率，以及步驟3生成的指標關係來計算容量例項數。每個步驟都對最終的推薦容量和服務可靠性至關重要。下面將深入瞭解一下各個步驟。
評估峰值吞吐量
由於擴縮容的頻率不同(小時、天、周)，其需要評估的吞吐量也不同。
例如按周來評估吞吐量：將目標吞吐量 RPSTarget作為下一週評估的峰值流量。CRE使用的預設吞吐量評估方式為時序分解模型。使用基於STL的時序分解方式將全域性吞吐量時序資料分為趨勢(trend)、季節性(seasonality)和其他(residue)三部分。這三部分之和表示了原始全域性吞吐量指標。seasonality表示一個頻率模式，trend表示跨天的模式。下例以天作為seasonality，展示了美國/拉丁美洲的上下班的峰值。residue 為不匹配trend或seasonality的剩餘原始指標，通常表示噪音。使用時序分解結果，CRE可以為大多數服務提供可靠的預測。
圖２吞吐量分解結果
定義目標利用率
目標利用率(UtilizationTarget)是CRE中用來推導容量數值的一個訊號。該訊號描述了未來服務資源的最大利用率。為了有效利用資源，應該儘量提高利用率，以便為未預測到的情況預留一部分緩衝餘地。正常情況下，每天的流量不會超過目標利用率。目標利用率應該包括某些特殊場景，如區域下線，此時該區域的流量會轉移到其他區域，此時由於流量的上升，利用率也會隨之上升。
線性迴歸：歸一化吞吐量和利用率
對於資源密集型的服務，利用率、吞吐量、容量、服務以及硬體效能都是常見的關聯因子，且相互影響。一旦其中一個因子發生了變化，通常也會影響到其他因子。由於我們的目標是評估服務容量，因此需要確定這些訊號之間的關係。CRE使用利用率和歸一化吞吐量來構建一個線性迴歸模型。通過將吞吐量除以例項核數，可以得出歸一化吞吐量--稱之為每核吞吐量(TPC)。通過歸一化吞吐量指標，我們可以將相關因子範圍縮小到利用率和TPC。通過線性迴歸結果展示的斜率和截距可以觀察到效能變化曲線。下面是利用率和TPC的關係公式：
通過去除異常值和歸一化，對資料進行預處理。如果由於控制面問題，指標源提供了明顯異常的資料點，則需要在處理過程中移除這些資料。可以使用交叉驗證來提高模型質量。當可以通過線性迴歸模型復現資料時，將會體現為調整後的判定係數(與結果質量相對應的測量值，數值越大，擬合度越高)。
圖3：利用率 vs 每核吞吐量
在圖4中可以看到評估的線性關係並不能代表指標關係，相反可以將資料點近似分為兩個不同的線性關係組。出現這種現象很可能是因為服務多樣化以及/或硬體效能的變化引起的。
圖4：利用率 vs 每核吞吐量
有了利用率和TPC線性關係方程，一旦提供了目標利用率，就可以計算出目標TPC。例如，假設將目標利用率設定為0.7，在圖5中，目標TPC 趨勢相對比較穩定合理，我們還可以從TPC中推斷出各區域基礎設施之間的差異。特別地，相比其他區域，zoneF地目標TPC比較小，原因可能是底層基礎設施和硬體的效能比較好。此外從圖中可以看出，各區域的曲線有下降趨勢。服務的效能下降也可以成為未來考察的一種可能因子。
圖5：服務的目標TPC趨勢
生成建議的容量
使用線性迴歸的結果?(利用率)和?(斜率)，以及預定義的目標利用率和評估到的峰值流量，我們可以計算出服務所需的核數，即容量。
變數定義：
TPCTarget: 目標每核吞吐量(TPC)
RPSTarget: 峰值流量評估階段提供的目標RPS
UtilizationTarget: 定義的目標利用率
CoresTotal: 服務所需的總核數
CoresInstance: 每個例項所需的核數
公式：
基於線性迴歸模型，將Utilization 和 TPC更新到目標值
變數定義：
通過公式(1)和(2)，可以得出：
在獲取到所需的總核數後，就可以得出每個例項所需的核數。最後獲取到推薦的容量例項數。
安全護欄(Guard Rail)：保障結果
在生成推薦的容量資料後，為了安全地滾動變更，我們引入了護欄來在自動擴縮容前對結果進行檢測。該步驟可以保證自動擴縮容的質量和服務的可靠性。例如，使用護欄來對比當前容量和推薦結果，通過預定義的百分比閾值，如果推薦值超過了當前的容量百分比，則護欄會處理該資料並調整對應的推薦結果。還有其他類似的護欄，如保障模型效能質量的護欄，在擴縮容結束之後，它會在報告中為工程師提供一個告警訊息，便於檢查後續的資料。
架構
分析流：排程分析
圖6：排程流
典型的排程容量推薦流包括以下步驟：
- workflow manager基於配置庫中的cadence(節奏)配置建立排程流
- workflow manager觸發排程流
- 通過指標庫以及採集的資料作為輸入資料，分析模型會採用所選擇的方式進行分析
- 將分析結果儲存到結果庫中
分析流：按需分析
圖7：按需流
如果服務所有者希望臨時生成容量建議，可以使用按需容量推薦流。
按需容量推薦分析流與排程流類似，區別是：
- 使用者請求傳送到閘道器服務後，由閘道器服務將請求傳送到CRE分析服務，以此來觸發推薦流程
- 在分析並生成結果後，會通過郵件將報告傳送給請求者
資料採集流
圖8：資料採集流
專用資料採集流會基於配置來採集和儲存關鍵服務的原始指標時序資料。該流會用到特定的指標服務。
典型的資料採集流包括如下步驟：
- workflow manager基於配置庫中的cadence配置建立排程流
- workflow manager觸發排程流
- 資料採集模組採集原始的m3時序資料，並將其儲存到指標庫中
結果
我們已經上線了多個關鍵業務服務。下圖是一個服務隨時間擴縮容的曲線。根據分析結果對例項數週期性地進行擴縮容。圖9展示了兩個區域的容量例項隨時間的變化曲線。不同的服務的效能、流量模式和底層硬體效能都會影響到利用率和線性迴歸模型。隨著時間的推移，會導致不同的擴縮容趨勢。
圖9：區域容量
圖10是服務利用率的擴縮容曲線，整體呈上升趨勢，每天和每週的流量模式都會導致不同的利用率。CRE會嘗試根據評估的峰值流量來提高利用率，以滿足其需求。
圖10：區域利用率
結論
本文引入了一種容量推薦引擎，通過機器學習模型來分析歷史資料，能夠對區域服務的效能趨勢和利用率模式進行分析。有了這些資料，就可以通過自動擴縮容來可靠地管理數千個微服務的容量。現在，通過吞吐量評估以及一個基於吞吐量和利用率的線性迴歸模型，可以以天為節奏為我們推薦後續7天的峰值流量容量。我們的下一個目標是按小時進行反應式擴充套件，以擴大每日高峰流量的容量，並在非高峰時段釋放容量。這將使我們能夠利用各種任務所使用的資源利用率模式，以進一步提高整體資源使用效率。