容量規劃與評估實踐

容量規劃的本質就是在「沒有足夠硬件資源」和「花錢買了太多硬件資源」之間的一種權衡；在同時，容量規劃也是一門玄學，因爲沒人能清楚未來會發生什麼，所以通常來說是數據和直覺相結合的過程。

容量規劃背景

在沒有進行容量規劃之前，嘗試問自己如下三個問題。

問題 1 誰需要進行容量規劃？

致力於成長爲國內一線互聯網公司，並經常需要爲流量激增而大規模擴容的公司。

問題 2 什麼時間進行容量規劃

容量規劃就是資源管理，當資源有限且具有一定成本時就需要進行容量規劃。

問題 3 爲什麼要進行容量規劃？

現在互聯網，不僅是軟件之間的互動，更多的是人和軟件之間的互動。主動權不掌握在軟件運營者的手中，某個話題的出現都會導致用戶激增，進而導致網站崩潰，爲了防止網站崩潰，就要精準預測流量，爲不可預知的流量做準備。

容量規劃目標

在沒有目標之前，不要進行容量規劃，也沒有辦法進行容量規劃。

一般目標如下：

另外就是時延，對於延遲敏感高的系統，不要用平均數，要用中位數，比如：P99.99 保證 50ms 以內延遲。因爲多數服務都存在長尾問題。

容量規劃方法和過程

  1. 收集最近半年或者一個季度 QPS 增長趨勢，根據增長趨勢預估接下來的增長倍數；

  2. 根據預估流量算出所需硬件數量；

  3. 計算處理能力，並添加限流；

  4. 不斷收集指標、持續優化系統處理能力，並校正容量規劃指標。

下面我會針對這四個步驟進行詳細解釋

1、指標收集

每個（重要的）系統都應該量化它的處理能力並且可視化當前狀態（QPS、延遲、錯誤率），如果不能，那就讓它變得可量化、可視化。

服務運行指標不可或缺，不僅僅容量規劃，也是日常監控告警指標的一部分。

指標收集有諸多陷阱，就以常用的 Prometheus 爲例，當計算 QPS 時，應該用 irate 把瞬時峯值計算出來，而不應該使用 rate；即便使用 irate，可能還會存在誤差，一般 Prometheus 的採集指標是 15s，只對規定採樣週期內的最後兩個樣本進行計算，而忽略前面所有樣本。

Grafana 只是一個指標觀測工具，不能完全靠它去做容量評估，我們知道當你查詢最近半小時的 QPS 時，分鐘展示；但是你進行容量評估可能會查看連續多天的數據指標，這樣的話單位就變成了天，如果裏面有一個短暫的峯值，grafana 並不會展示，那麼峯值可能被忽略掉。

基於肉眼查看界面會存在誤判，所以不要依賴界面化操作，而是實現自動化指標查詢。Prometheus 本身就是個時序數據庫，可以通過 HTTP 調用的方式以採集週期爲單位把某段時間內最大數據指標收集出來。例如使用以下表達式查詢請求表達式在 30 秒範圍內以 15 秒爲間隔計算 PromQL 表達式的結果。

$ curl 'http://localhost:9090/api/v1/query_range?query=http_requests_total{environment=~"staging|testing|development",method!="GET"}
&start=2015-07-01T20:10:30.781Z&end=2015-07-01T20:11:00.781Z&step=15s'
{
   "status" : "success",
   "data" : {
      "resultType" : "matrix",
      "result" : [
         {
            "metric" : {
               "__name__" : "up",
               "job" : "prometheus",
               "instance" : "localhost:9090"
            },
            "values" : [
               [ 1435781430.781, "1" ],
               [ 1435781445.781, "1" ],
               [ 1435781460.781, "1" ]
            ]
         },
         {
            "metric" : {
               "__name__" : "up",
               "job" : "node",
               "instance" : "localhost:9091"
            },
            "values" : [
               [ 1435781430.781, "0" ],
               [ 1435781445.781, "0" ],
               [ 1435781460.781, "1" ]
            ]
         }
      ]
   }
}

建議每 2 個小時存儲一個最大值，然後把以天、月爲單位畫出走勢圖，根據走勢圖預測下個週期預測值。

2、計算所需資源

既然資源評估，那就需要計算自己需要的資源，CPU、內存、磁盤；其中內存和磁盤使用都會存在一個固定趨勢，根據現有指標相對更容易的計算出來。

這裏通常有兩個原則：

量化你的 QPS 和延遲的關係, 量化你的 QPS 和硬件（CPU、內存、磁盤、IO）的關係, 量化你的每個請求需要消耗的資源。

下面我以計算 CPU 爲例，說明下如何進行計算資源的評估。

首先我們需要計算出每個請求消耗的 CPU 資源，計算公式如下：

每個請求 CPU% = 總的 CPU% 消耗 / 請求總數

承載 QPS 最大值 = 100% * CPU 數量 / 每個請求消耗 CPU%

首先根據監控查看 QPS 對應的 CPU 消耗，建議使用線上數據，如果第一次上線，則使用基準壓測數據。

假設上述 qps 佔用32core

  1. 每個請求佔用的 CPU 資源 = 32 * 40%/13400 = 0.09%

  2. 32core 滿載的情況下承載 QPS 最大值 = 3200/0.09 = 35,555

  3. 當然按照業界標準一般 CPU 佔用率安全線 85%，那麼 35,555 * 0.85 = 30221 qps

  4. 如果要滿足 10w qps 需求，那麼就需要 106core = 100000/30221 * 32

當然這是一種資源評估方法，並不能完全解決服務中存在的問題，比如說 JVM 在某個不確定的時間發生了 GC、存在 SQL 慢查詢.... 這種偶爾故障導致的 CPU 消耗超過閾值，只能具體問題具體分析，比如：JVM 調優，儘可能少發生 FGC。添加監控告警指標，出現不符合正常邏輯指標升高，告警、人工處理等。

3、採購硬件

硬件資源是軟件運行過程中不可忽略的成本，只有根據上述數據評估清楚，到底需要購買多少硬件，才應該開始硬件的採購和安裝過程。

JhsqeV

這裏的原則是儘可能採購同類型的機器，減少機器之間的差異性，簡化故障維修；當機器不同零部件出現問題時可以同型號裝配，提高硬件資源利用率；最後儘量不做做定製化設置，有利於後期的自動化。

容量規劃問題討論

在我工作過程中，經常有人把性能優化和容量規劃混爲一談，認爲他們兩個可以直接劃等號，其實並沒有什麼關係，性能優化只是其中一個過程，通過性能優化可以提高服務處理能力，降低資源消耗，但是容量規劃還是需要按部就班的做。

在很多開發團隊中，產品和開發甚至運維人員都是相對比較獨立的團隊，這就導致產品人員不關心開發進度、開發不關心運維如何部署，這個沒什麼好的辦法，只能改變企業文化，加強產品開發運維的一體化，這就現在工作中倡導的 DevOps。

使用操作系統虛擬化技術，比如現在的 Kubernetes，能夠輕鬆完成資源的調度和分配，從而實現峯谷互補。

總結

容量規劃這種事不去做，一直都是個空白，只要邁開第一步，隨着時間的推移，會逐漸認識到自己服務的處理能力，容量預測也會變得更加準確，服務穩定性也會在一定程度上得到保障。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/HJyTqJdutaadz1kb7mr1XA

猜你喜歡