上一篇文章我們介紹了 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 的指示。

 出處：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