Categories
程式開發

滴滴內部線上系統的容量評估方法


1. 背景

以滴滴內部某業務為例,從BI監控、流量晚的流量高峰、夜間的流量低谷。但把周期拉長,可以看到業務單量及服務流量的增加趨勢。

滴滴內部線上系統的容量評估方法 1

滴滴內部線上系統的容量評估方法 2

對應該服務的資源使用,比如CPU Idle,長期看則有一定的下降趨勢。

滴滴內部線上系統的容量評估方法 3

基於此,我們能否從中找到規律,回答幾個重要的問題:

  • 隨著業務單量增長,該服務的流量也會增加,峰值會是多少?
  • 隨著該服務的流量增加,該服務消耗更多的資源,容量上限是多少?
  • 以及終極問題:隨著業務單量增長,該服務是否需要擴容,擴容多少?

2. 容量預估的思路

懵懂中有這樣的猜想,服務的流量應該取決於業務單量。所以換個角度考慮,把上面三幅圖的橫坐標改為業務單量,縱坐標改為服務流量。如果關係成立,預測流量增長自然不難。

滴滴內部線上系統的容量評估方法 4

不出意外,資源使用率(如CPU Idle)應該取決於服務流量。如果關係成立,評估容量上限也會迎刃而解。

滴滴內部線上系統的容量評估方法 5

想法是否成立,我們快速驗證一下,採集了5個線上服務,生成服務流量與業務單量的關係圖,結果顯示,有3個服務存在較強的關係:

滴滴內部線上系統的容量評估方法 6

接下來是資源使用率與服務流量,採集了多個資源使用率指標,比如內存、CPU Idle、磁盤IO等,結果顯示,應用類服務的CPU Idle與流量存在較強的關係

滴滴內部線上系統的容量評估方法 7

3. 容量預估的方案

評估容量上限

流量高峰時,如果某個服務的主要資源指標下降到一定程度,我們會覺得其容量到了上限。前面分析驗證過,應用類的服務大多數是CPU類型,CPU使用率或者CPU Idle是主要的資源指標。有一定的理由相信,如果CPU Idle下降到基線標準,我們可以說該服務的容量達到了上限。

但基線標準如何定義?在達到特定的容量時,該服務的錯誤率有明顯提升、或者時延SLA不達標、或者突然Crash,這就是一個經過驗證、令人信服的基線值。

在沒有驗證的基線之前,我們可以依賴歷史經驗,比如這裡取CPU Idle 40%作為基線值。

滴滴內部線上系統的容量評估方法 8

從圖中可以看出,服務的CPU Idle與流量有較強的相關性,給出性能基線後,很容易評估其容量上限。

預測服務流量

很多時候業務上對增長有較明確的預期,比如半年之內單量增加50%,即使一些促銷的運營類活動,也應該對業務增長有粗略的估算,這樣底層的IT系統可以更好應對。

這些業務增長的預期,會直接轉化為內部各服務的流量,前面已經分析和驗證過二者的關係,因此服務的流量也是可以預測的。

下面的左圖非常典型,流量與單量強相關。右圖則不然,呈現出兩個不同的階段。其實這種情況不難理解,某些服務的流量不只受單量影響,還受制於司機數量,即使單量增加,但司機不夠,很多訂單分不出去,相關服務的流量必然不會一直增長。所以需要綜合考慮服務流量與業務單量、司機在線數等多個因素的關係。

滴滴內部線上系統的容量評估方法 9

算法說明

持續採集線上數據,經過預處理、格式轉換,可以用來做預測。多次訓練和驗證對比,並使用節假日時的高峰流量二次驗證,為不同的服務選擇不同的算法。

滴滴內部線上系統的容量評估方法 10

最後,由於關係圖上的點有一定的離散度,引入bootstrap 95%置信區間算法,給出的預測結果是一個範圍,而非具體的一個數值。

4. 預測結果的準確度

不難理解,大家會有很多疑問:

  • 預測準不准,怎麼證明?
  • 按CPU Idle 40%進行計算,會不會出現CPU Idle 60%或者50%時服務突然Crash?

滴滴內部線上系統的容量評估方法 11

當某個服務的流量繼續增加,CPU Idle持續降低,我們與哨兵壓測合作,讓該服務單台機器的流量增加,並採集資源類數據,如下圖所示。肉眼看起來,基本符合預測的關係,並進行了量化計算,預測的準確度大概是89%。

滴滴內部線上系統的容量評估方法 12

至於是否會Crash,起碼從哨兵壓測CPU Idle降到40%的情況下,這兩個模塊未發生突然Crash。這當然避免不了流量繼續增加是否會Crash,但我們在選擇性能基線的時候可以更保守一些。容量的預估只需要採集相關的業務指標、流量數據、資源數據,幾乎不需要服務側做任何改動,僅此接入的成本較低。

5. 案例分析

容量的預估只需要採集相關的業務指標、流量數據、資源數據,幾乎不需要服務側做任何改動,僅此接入的成本較低。

案例一

以某服務為例,集群共有10台機器,當前的峰值流量1000QPS(非線上實際數值,僅為示例用途,下同),兩個主要的關係圖如下:

滴滴內部線上系統的容量評估方法 13

經過計算,該服務的結果如下:

  • 若不擴容,該服務的容量上限預測結果為:【1500-1700】
  • 單量增加30%、司機增加10%時,該服務的流量峰值是:【2000-2200】
  • 按悲觀估算,容量取下限1500,峰值流量取上限2200,則該服務需要擴容4~5台

案例二

以另一個服務為例,集群共5個容器,當前的峰值流量是250QPS。

滴滴內部線上系統的容量評估方法 14

經過計算,該服務的結果如下:

  • 若不擴容,該服務的容量上限預測結果為:【1100-1200】
  • 單量增加30%、司機增加10%時,該服務的流量峰值是:【450-500】
  • 按悲觀估算,容量取下限1100,峰值流量取上限500,則該服務需要縮容2台

案例三

從業務角度,可以看到各核心服務的容量上限、流量增長趨勢,以及建議的擴容結果:

滴滴內部線上系統的容量評估方法 15

6. 局限性說明

線上業務面臨各種各樣的穩定性挑戰,這種常規場景下的容量預估方法,當然也有其局限性:

性能基線如何選擇

使用CPU Idle作為基線指標,源於本文對少量數據集的驗證結果,大部分應用類服務是CPU資源型。

使用CPU Idle 40%作為基線值,則是源於經驗。在40%之前服務是否存在性能拐點,是否會發生crash,則需要結合全鏈路壓測、哨兵壓測等其他機制驗證。

對下游時延增加等性能抖動的容錯

一旦下游服務或基礎組件發生性能抖動,比如時延增加、錯誤率增加,對很多服務會產生致命的影響,甚至引發雪崩。

服務可以容錯多大的性能抖動,可以結合防火等手段進一步驗證。因此本文的容量預估結果,更多是對服務容量的一個參考。

作者介紹

張曉慶

滴滴 | 高級算法專家

本文轉載自公眾號滴滴技術(ID:didi_tech)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI1NDA3NzY4NA==&mid=2247485991&idx=2&sn=b05f02468e54fd0661cbf86299f77084&chksm=e9cbf5bcdebc7caa9b69dbbbeb6de6ba163a3553c7c5a4b23b96e5e6dd02b38c3a6f7f95abee&scene=27#wechat_redirect