技術專欄

集結國內外精選文章,掌握最新雲端技術新知與應用 

iKala Cloud / 部落格 / 基礎架構 / 設定與測試 Instance Group Autoscaler

設定與測試 Instance Group Autoscaler

上一篇文章我們介紹了 HTTP(S) load balancing 各個元件的功能、建立方式以及整體的使用情境,但我們當時只用了兩個 instance 處理服務,以流量穩定的服務來說這也許足以應付多數狀況。但如果你的服務流量會隨著時間或突發事件而會有極大變化時,你要如何決定你的 instance 數量?以最低流量來決定,那在流量上升時服務無法在短時間內消化這麼多流量、甚至無法正常提供服務,使用者等待時間變長甚至無法使用,體驗下降後導致使用者離開是服務經營者所不樂見的。若以最高流量來決定,那在流量低下時又會有大量資源閒置,對自己的財務支出似乎又過不去。幸好今天我們使用的是 Google Cloud Platform , GCP 的 managed instance group 提供了 autoscaler 的功能,能夠讓你指定 autoscaler 要以何種數據作為依據,判斷是否需要增減 managed instance group 中 instance 的數量,如此我們便能以適量的資源應對當下的流量,同時也減少了財務上過度的支出。

設定 managed instance group autoscaler

在這裡我們將接續上一篇文章建立的各個元件,我們會修改一下 backend service 對其中一個 managed instance group 的 balancing mode ,然後為該 managed instance group 加上 autoscaler ,各元件的關係圖如下。 sample-instance-group 由 example-instance-group-manager 控管其 instance 的數量,而 Autoscaler 則依據指定的數據判斷,對 example-instance-group-manager 發出增減 instance 的指示。

instance-autoscaler 出處:Scaling Based on CPU or Load Balancing Serving Capacity

最後我們會實際送入大量的 HTTP request ,促使該 managed instance group 增加 instance 數量,並在停止送入大量的 HTTP request 後,觀察 instance 數量下降。

Step 1 修改 balancing mode

gcloud compute --project "demo-project" \
  backend-services update-backend "demo-http-backend-service" \
  --instance-group "demo-instance-group-ae1a" \
  --instance-group-zone "asia-east1-a" \
  --balancing-mode "RATE" \
  --max-rate-per-instance "10" \
  --capacity-scaler "0.9" 

Step 2 加上 autoscaler這裡我們修改了 demo-http-backend-service 對 demo-instance-group-ae1a 的 balancing mode ,改成以 RATE (RPS) 作為分配的依據,設定單一一個 instance 最高能處理 10 RPS ,並讓該 backend service 能使用該 managed instance group 約 90% 的 capacity 。

gcloud compute --project "demo-project" \
  instance-groups managed set-autoscaling "demo-instance-group-ae1a" \
  --zone "asia-east1-a" \
  --max-num-replicas "5" \
  --min-num-replicas "1" \
  --target-load-balancing-utilization "0.8" \
  --cool-down-period "60"

這裡我們為 demo-instance-group-ae1a 這個 managed instance group 加上了 autoscaler 的功能,我們設定這個 managed instance group 最少有 1 個、最高能有 5 個 instance 提供服務。而 cool down period 設定為 60 秒則是指說當新的 instance 被開機以後,需要等待 60 秒後 autoscaler 才會開始收集數據、評估該 instance 目前的負載量,這是為了避免 autoscaler 將 instance 在剛開機的那段期間,得要做很多初始化工作造成的負載計入。

然後,我們來特別說明一下 –target-load-balancing-utilization “0.8” 這個設定代表的意思、 autoscaler 的計算方式以及建議的設定方式。首先,因為這個 managed instance group 是搭配著 HTTP(S) load balancing 在使用,所以我們以 HTTP(S) load balancing 這邊的設定作為 autoscaler 評估所需 instance 數量的依據。接下來我們回顧一下,在 Step 1 中,我們設定該 managed instance group 每個 instance 最高可以負載 10 RPS 並讓它使用約 90% 的 capacity ,所以一個 instance 最高可以負載到 10 RPS * 90% = 9 RPS ,之後 HTTP(S) load balancing 就會將 HTTP request 往其他仍有餘裕的 instance 送,而我們在 target utilization 設定為 80% ,則 autoscaler 會在該 managed instance group 平均每個 instance 處理超過 10 RPS * 80% = 8 RPS 時增加服務的 instance 以將 utilization 控制在 80% 附近。舉例來說,現在該 managed instance group 總共有 2 個 instance ,而流入該 managed instance group 的 HTTP request rate 為 30 RPS ,也就是平均處理著 15 RPS 的量,超出 target utilization 的 8 RPS ,為了要達到平均處理約 8 RPS 的量,我們需要 30 RPS / 8 RPS 、無條件進位後得到需要 4 個 instance 才能滿足需求,這時 autoscaler 就會增加 2 個 instance 到 managed instance group 中。這裡建議是 target utilization 要設定的比 capacity 還小,這樣才能在到達 capacity 、 HTTP request 被導向到其他 instance group 前讓 autoscaler 開始增減 instance 。

測試 managed instance group autoscaler

首先,我們先來看該 managed instance group 中目前有多少個 instance 。

gcloud compute --project "demo-project" \
  instance-groups managed describe "demo-instance-group-ae1a" \
  --zone "asia-east1-a" | grep "targetSize"

從 targetSize: 1 可以得知目前該 managed instance group 的目標為 1 個 instance 。

接著我們用以下指令,對該 HTTP load balancing 送出大量的 HTTP request 。

ab -c 10 -n 100000 -t 900 http://111.111.111.111/

在上面那個指令執行一段時間後,我們再次察看該 managed instance group 目標為需要多少 instance 。

gcloud compute --project "demo-project" \
  instance-groups managed describe "demo-instance-group-ae1a" \
  --zone "asia-east1-a" | grep "targetSize"

我們得到了 targetSize: 5 的結果,代表目前該 managed instance group 目標是產生出 5 個 instance ,等 ab 執行完一段時間後(約 10 分鐘)再執行同樣的指令,會得到 targetSize: 1 的結果,代表 autoscaler 判斷只需要 1 個 instance 。但要記得 targetSize 的數值並不代表現在 managed instance group 中的 instance 數量,而是代表目標需要的數量,因為 instance 可能正處在產生或刪除的階段。

總結

在這篇文章中,我們說明了 managed instance group autoscaler 如何搭配 HTTP(S) load balancing 一起使用、 autoscaler 是以哪些數據來判斷是否需要 scale-in/out 、如何計算一次要 scale-in/out 多少 instance 、以及最後的測試。當然, autoscaler 除了可以以 HTTP(S) load balancing 這邊的設定作為判斷 scale-in/out 的依據外,也可以使用 CPU utilization 、甚至是更進階的使用 Stackdriver Monitoring 提供的數據來 autoscaling ,各位可以依據自己服務的特性,選擇使用其中一種或多種方式來 autoscaling 。

Reference

Backend services and autoscaled managed instance groups

Restrictions and guidance

Scaling based on HTTP(S) load balancing serving capacity

Understanding Autoscaler Decisions

InstanceGroupManagers – Resource representations

 

分享本文:
FacebookLineTwitter
回到頂端