容量推薦引擎：基於吞吐量和利用率的預測縮放

容量推薦引擎：基於吞吐量和利用率的預測縮放

本文介紹了一種容量推薦模型，實現方式相對相對比較簡單，且已在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生成的指標關係來計算容量實例數。每個步驟都對最終的推薦容量和服務可靠性至關重要。下面將深入瞭解一下各個步驟。

評估峯值吞吐量

由於擴縮容的頻率不同(小時、天、周)，其需要評估的吞吐量也不同。

例如按周來評估吞吐量：將目標吞吐量 RPS_Target作爲下一週評估的峯值流量。CRE使用的默認吞吐量評估方式爲時序分解模型。使用基於STL的時序分解方式將全局吞吐量時序數據分爲趨勢(trend)、季節性(seasonality)和其他(residue)三部分。這三部分之和表示了原始全局吞吐量指標。seasonality表示一個頻率模式，trend表示跨天的模式。下例以天作爲seasonality，展示了美國/拉丁美洲的上下班的峯值。residue 爲不匹配trend或seasonality的剩餘原始指標，通常表示噪音。使用時序分解結果，CRE可以爲大多數服務提供可靠的預測。

圖２吞吐量分解結果

定義目標利用率

目標利用率(Utilization_Target)是CRE中用來推導容量數值的一個信號。該信號描述了未來服務資源的最大利用率。爲了有效利用資源，應該儘量提高利用率，以便爲未預測到的情況預留一部分緩衝餘地。正常情況下，每天的流量不會超過目標利用率。目標利用率應該包括某些特殊場景，如區域下線，此時該區域的流量會轉移到其他區域，此時由於流量的上升，利用率也會隨之上升。

線性迴歸：歸一化吞吐量和利用率

對於資源密集型的服務，利用率、吞吐量、容量、服務以及硬件性能都是常見的關聯因子，且相互影響。一旦其中一個因子發生了變化，通常也會影響到其他因子。由於我們的目標是評估服務容量，因此需要確定這些信號之間的關係。CRE使用利用率和歸一化吞吐量來構建一個線性迴歸模型。通過將吞吐量除以實例核數，可以得出歸一化吞吐量--稱之爲每核吞吐量(TPC)。通過歸一化吞吐量指標，我們可以將相關因子範圍縮小到利用率和TPC。通過線性迴歸結果展示的斜率和截距可以觀察到性能變化曲線。下面是利用率和TPC的關係公式：

\[Utilization =𝛼+𝛽 ⨯ TPC \]

通過去除異常值和歸一化，對數據進行預處理。如果由於控制面問題，指標源提供了明顯異常的數據點，則需要在處理過程中移除這些數據。可以使用交叉驗證來提高模型質量。當可以通過線性迴歸模型復現數據時，將會體現爲調整後的判定係數(與結果質量相對應的測量值，數值越大，擬合度越高)。

圖3：利用率 vs 每核吞吐量

在圖4中可以看到評估的線性關係並不能代表指標關係，相反可以將數據點近似分爲兩個不同的線性關係組。出現這種現象很可能是因爲服務多樣化以及/或硬件性能的變化引起的。

圖4：利用率 vs 每核吞吐量

有了利用率和TPC線性關係方程，一旦提供了目標利用率，就可以計算出目標TPC。例如，假設將目標利用率設置爲0.7，在圖5中，目標TPC 趨勢相對比較穩定合理，我們還可以從TPC中推斷出各區域基礎設施之間的差異。特別地，相比其他區域，zoneF地目標TPC比較小，原因可能是底層基礎設施和硬件的性能比較好。此外從圖中可以看出，各區域的曲線有下降趨勢。服務的性能下降也可以成爲未來考察的一種可能因子。

圖5：服務的目標TPC趨勢

生成建議的容量

使用線性迴歸的結果𝛼(利用率)和𝛽(斜率)，以及預定義的目標利用率和評估到的峯值流量，我們可以計算出服務所需的核數，即容量。

變量定義：

TPC_Target: 目標每核吞吐量(TPC)

RPS_Target: 峯值流量評估階段提供的目標RPS

Utilization_Target: 定義的目標利用率

Cores_Total: 服務所需的總核數

Cores_Instance: 每個實例所需的核數

公式：

基於線性迴歸模型，將Utilization 和 TPC更新到目標值

\[TPC_{target} = \frac{Utilization_{Traget}-\alpha}{\beta}~~~~~~...(1) \]

變量定義：

\[TPC_{target} = \frac{RPS_{Traget}}{Cores_{Total}}~~~~~~...(2) \]

通過公式(1)和(2)，可以得出：

\[Core_{Total} = \frac{\beta \times RPS_{Traget}}{Utilization _{Traget}-\alpha} \]

在獲取到所需的總核數後，就可以得出每個實例所需的核數。最後獲取到推薦的容量實例數。

\[Instances = \frac{Cores_{Total}}{Cores_{Instance}} \]

安全護欄(Guard Rail)：保障結果

在生成推薦的容量數據後，爲了安全地滾動變更，我們引入了護欄來在自動擴縮容前對結果進行檢測。該步驟可以保證自動擴縮容的質量和服務的可靠性。例如，使用護欄來對比當前容量和推薦結果，通過預定義的百分比閾值，如果推薦值超過了當前的容量百分比，則護欄會處理該數據並調整對應的推薦結果。還有其他類似的護欄，如保障模型性能質量的護欄，在擴縮容結束之後，它會在報告中爲工程師提供一個告警消息，便於檢查後續的數據。

架構

分析流：調度分析

圖6：調度流

典型的調度容量推薦流包括以下步驟：

1. workflow manager基於配置庫中的cadence(節奏)配置創建調度流
2. workflow manager觸發調度流
3. 通過指標庫以及採集的數據作爲輸入數據，分析模型會採用所選擇的方式進行分析
4. 將分析結果存儲到結果庫中

分析流：按需分析

圖7：按需流

如果服務所有者希望臨時生成容量建議，可以使用按需容量推薦流。

按需容量推薦分析流與調度流類似，區別是：

1. 用戶請求發送到網關服務後，由網關服務將請求發送到CRE分析服務，以此來觸發推薦流程
2. 在分析並生成結果後，會通過郵件將報告發送給請求者

數據採集流

圖8：數據採集流

專用數據採集流會基於配置來採集和存儲關鍵服務的原始指標時序數據。該流會用到特定的指標服務。

典型的數據採集流包括如下步驟：

1. workflow manager基於配置庫中的cadence配置創建調度流
2. workflow manager觸發調度流
3. 數據採集模塊採集原始的m3時序數據，並將其存儲到指標庫中

結果

我們已經上線了多個關鍵業務服務。下圖是一個服務隨時間擴縮容的曲線。根據分析結果對實例數週期性地進行擴縮容。圖9展示了兩個區域的容量實例隨時間的變化曲線。不同的服務的性能、流量模式和底層硬件性能都會影響到利用率和線性迴歸模型。隨着時間的推移，會導致不同的擴縮容趨勢。

圖9：區域容量

圖10是服務利用率的擴縮容曲線，整體呈上升趨勢，每天和每週的流量模式都會導致不同的利用率。CRE會嘗試根據評估的峯值流量來提高利用率，以滿足其需求。

圖10：區域利用率

結論

本文引入了一種容量推薦引擎，通過機器學習模型來分析歷史數據，能夠對區域服務的性能趨勢和利用率模式進行分析。有了這些數據，就可以通過自動擴縮容來可靠地管理數千個微服務的容量。現在，通過吞吐量評估以及一個基於吞吐量和利用率的線性迴歸模型，可以以天爲節奏爲我們推薦後續7天的峯值流量容量。我們的下一個目標是按小時進行反應式擴展，以擴大每日高峯流量的容量，並在非高峯時段釋放容量。這將使我們能夠利用各種任務所使用的資源利用率模式，以進一步提高整體資源使用效率。