彈性伸縮：高可用架構利器（架構+演算法+思維）

Hello-Brand發表於2024-06-20
架構演算法

1 介紹

雲端計算資源彈性伸縮是一種根據業務需求動態調整計算資源規模的技術。它可以根據系統的效能指標（如CPU使用率、記憶體佔用率、磁碟IO、網路卡讀寫率、請求響應時間等）或者預定義的規則（如時間週期、業務事件等），自動增加或減少計算資源的數量，以滿足業務負載的變化。這種技術可以確保系統在高峰時期擁有足夠的處理能力，而在低谷時期則能釋放多餘資源，從而實現資源的最大化利用。

簡單說，就是監測資源指標，發現到達瓶頸的時候，進行資源增量，發現利用過剩的時候，進行資源縮減。

2 實現方案和原理

從雲端計算的容器化方面，有哪些辦法呢？我們先來看看容器的一些配置。

2.1 容器的Request和Limit

resources:
      limits:  # 資源上限，不能超過該資源的閾值，否則會觸發限制或者重啟
        cpu: "1"
        memory: 8G
      requests:  # 資源下限，無論是否使用上，都會佔據對應空間
        cpu: 200m
        memory: 500M

Request指標
Request表示容器在執行過程中所需的最小資源量，即容器啟動時的資源保證。當Pod被排程到節點上時，Kubernetes會確保該節點上至少有足夠的資源來滿足Pod中所有容器的Request值。如果節點可用資源無法滿足時，則Pod將不會被排程到該節點上，而會保持在Pending狀態，直到找到滿足條件的節點為止。因此，合理設定Request值可以確保Pod的穩定性和可靠性。

Limit指標
Limit則表示容器在執行過程中可以使用的最大資源量，即容器可以消耗的資源上限。如果容器的實際資源使用量超過了Limit值，Kubernetes會採取相應的措施來限制容器的資源使用，例如限制CPU使用率、殺死程序等，以確保不會因資源不足而導致系統崩潰或效能下降。透過設定Limit值，可以有效地防止單個容器或整個Pod佔用過多的資源，從而影響整個叢集的效能和穩定性。

也就是說 Requet 是下限，Limit 是上限。在實際使用中，需要根據應用程式的特性和需求來合理設定Request和Limit值，以確保既能夠滿足應用程式的效能需求，又能夠充分利用叢集資源，避免資源浪費。

但是不可避免的，我們的容量評估沒有那麼標準。這時候，雲端計算如果能夠根據策略有條件的進行自動伸縮，那會給我們解決很多麻煩。那伸縮的策略又分為兩種，垂直（VPA）和水平（HPA），下面我們詳細來分析下。

2.2 VPA的演算法實現

VPA全稱Vertical Pod Autoscaler，即垂直Pod自動擴縮容。
它根據容器資源使用率自動設定CPU和記憶體的requests/limits，從而允許在節點上進行適當的容積排程，以便為每個Pod提供適當的資源。

image

  1. Recommender 元件每隔 1 分鐘採集 CPU 和記憶體的用量資訊，
  2. 將採集到的資料放入Decaying Exponential Histogram（衰減指數直方圖）的 bucket 中，bucket 存放的是權重值，這樣隨著時間的推移就會生成一個分佈圖。衰減直方圖參考下面演算法分析。
  3. 算出指數直方圖的 P95，P90，P50 對應 bucket 的起始值就是推薦值（設為 estimation95，estimation90，estimation50），但這其實不是最終的推薦值
  4. 為了保證推薦值的安全性，還會給這些資料乘以安全邊際係數（safetyMarginFraction ）和置信乘數（confidenceMultiplier）
  5. 最終算出來的值才是真正的推薦值，這三個值分別是 VPA 推薦值的 upperBound（推薦上線）、target（推薦目標值）、lowerBound（推薦下限）

公式如下：

  • 推薦 Request最大值：
    \(upperBound = estimation95 * (1 + 1/history-length-in-days)\)
  • 推薦 Request 值：
    \(target = estimation90*(1+safetyMarginFraction)\)
  • 推薦 Request 最小值：
    \(lowerBound = estimation50 * (1 + 0.001/history-length-in-days)^{-2}\)

2.3 衰減指數直方圖簡介

DecayingExponentialHistogram
衰減的意思是直方圖中的樣本的權重值會隨著時間的增長，權重會逐步降低，也就意味著最新的樣本資料對推薦值的影響更大。指數直方圖的意思是直方圖的步長是指數增長的，假設第一個 bucket 是 firstBucketSize 大小，那麼索引為 n 的 bucket 大小就是 firstBucketSize * ratio^n，ratio 是固定的係數。第 n 個 bucket 的起始值就是：
\(firstBucketSize * (1 + ratio + ratio^2 + ... + ratio^{(n-1)}) = firstBucketSize * (ratio^n - 1) / (ratio - 1)\)

如下（CPU樣本指數直方圖）：
image

2.4 HPA的演算法實現

HPA全稱Horizontal Pod Autoscaler，即水平Pod自動擴縮容。
簡單說就是 增加例項數量，調整replicas副本數，來滿足資源擴容的過程 。
image

  1. Recommender 元件每隔 1 分鐘採集 CPU 和記憶體的用量資訊，
  2. CMP配置HPA策略和擴容任務
  3. Metric Server 採集kube資源的各種指標
  4. 如果達到策略閾值，則進行擴容
  5. 下面這個例子中，我們使用了 CPU 利用率 的度量指標，並且設定目標 CPU 利用率為 60%，大於該值啟動擴容。
apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
  namespace: default  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app  
  minReplicas: 1   # 最少副本數1
  maxReplicas: 10   # 最多副本數10
  metrics:  
  - type: Resource  
    resource:  
      name: cpu  
      target:  
        type: Utilization  
        averageUtilization: 60

我們要求的是CUP不超過60%，所以反向計算合理副本的辦法如下：

計算邏輯：當前期望副本數 = ceil（當前副本數 * （當前指標/期望指標數））
舉例：
當前指標：CPU利用率 70%
期望指標：CPU利用率60%
當前副本數：10
期望副本數：ceil(10*(70/60))=12
最終擴容數量為2

3 架構帶來的啟發

如果有看過我的MySQL系列和Redis系列，一定對其中的分庫分表、分片(Sharding)印象深刻，其實同一個道理。
就是當資源不夠的時候進行增強和拆分負載的做法，我們稱之為分治思維。
彈性伸縮的模式是讓這一個過程變得更加自動化了，後續我們繼續分享下儲存層的動態伸縮，那我們的整個系統是不是就變得更加彈性了？

4 總結

彈性伸縮技術是雲端計算領域的一項重要技術，它透過動態調整計算資源規模來滿足業務負載的變化需求。在實際應用中，我們需要根據具體的業務場景和負載型別選擇合適的監控指標和伸縮策略，並充分利用自動化指令碼和工具來提高操作的效率和準確性。同時，我們還需要建立完善的監控與告警機制來確保系統的穩定性和可靠性。隨著雲端計算技術的不斷髮展和應用場景的不斷擴充，彈性伸縮技術將在未來發揮更加重要的作用。

★ 總結部分透過AI對全文內容進行理解並總結

相關文章