前言
原文
在這篇文章中
我們可以看到可以設置 autoscale 的條件有什麼
以及我們應要怎樣設置這些條件
Autoscaling and the App Service Plan
Autoscaling 是 App service plan 的一項功能
在 Scale out 的時候
Azure 就會為該 App service plan 多開一個 instance 來運行 plan 內的 app
Instance 的數量愈多
相應的收費也會愈高
為免超出預期的收費
請為你的 plan 設置 instance 數量上限
請注意,不同 tier 的 plan 有其相應的最高 instance 數量上限
Autoscale conditions
Azure 提供了兩種 autoscaling 的選項
- 基於計量(metric) 的條件
- 有很多計量(metric) 都可以被設為 scaling 的觸發條件,例如
- Disk queue 的長度
- 待處理的 HTTP 請求的數量
- 有很多計量(metric) 都可以被設為 scaling 的觸發條件,例如
- 基於排程(schedule) 的條件
- 你可以設定在指定的時間進行 scale out 和 scale back
- 時間可以是一天的特定時間、或特定日期、或一週的某一天
- 你可以設定在指定的時間進行 scale out 和 scale back
你可以同時使用這兩種選項來達到更靈活的控制
比如說,你可以指定在特定的幾個小時內才啟用基於計量(metric) 的 autoscaling
你也可以時啟用多個 autoscaling 的條件
一但滿足了一其中一個條件
Azure 就會作出相應的 autoscale
Metrics for autoscale rules
下列這些計量(metric)都可以被設為autoscale 的條件
- CPU Percentage
- 所有 instances 的 CPU 的使用率,如果這個數值接近上限,就可能會造成處理請求延遲
- Memory Percentage
- 所有 instances 的記憶體佔用量,如果這個數值很高,可能會使一個或多個 instances 出現故障
- Disk Queue Length
- 所有 instances 的待處理 I/O 數量,如果這個數值很高,可能會發生磁碟競爭(disk contention)
- 磁碟競爭(disk contention) 是指多個進程同時試圖訪問同一磁碟時,導致的資源競爭情況
- 所有 instances 的待處理 I/O 數量,如果這個數值很高,可能會發生磁碟競爭(disk contention)
- Http Queue Length
- 正在等待被處理的 client request 數量,如果這個數值很高,可能會發生 HTTP 408 (Timeout) 的錯誤
- Data in
- 所有 instances 有收到過多少 bytes 的總計量
- Data out
- 所有 instances 有送出過多少 bytes 的總計量
同時你也可以以其他 Azure services 的計量(metric) 作為 autoscale 的條件
例如,如果你的 app 是 Service Bus Queue 的 consumer
你可以考慮以 Service Bus Queue 的長度作為增加 instance 數量的條件
How an autoscale rule analyzes metrics
時間粒紋(time grain)
時間粒紋指的是 Azure 會在每一個指定的時間段(通常是1分鐘)內統計一次計量(metric)
而統計的計算方式可以是平均值(Average)、最小值(Minimum)、最大值(Maximum)、總和(Sum)、最後值(Last)和計數(Count)
時間彙總(time aggregation)
由於一個時間紋粒(time grain)的持續時間比較短
所以 Azure 會把連續幾個的時間紋粒總計起來再統計一次
這樣更能看出整體的變化趨勢
而幾個時間紋粒總計起來的就是時間彙總了
時間彙總最短可設置的持續時間是五分鐘
通常也就是5個時間紋粒的時間長度
同時,時間彙總的統計的計算方式也可以是平均值(Average)、最小值(Minimum)、最大值(Maximum)、總和(Sum)、最後值(Last)和計數(Count)
也就是說,你最後得到可被用作 autoscale 的計量是經過了時間紋粒和時間彙總各自的統計
而這兩次的統計的計算方式也可以是不一樣的
例如說,時間粒紋採用最大值(Maximum)而時間彙總則採用平均值(Average)也都是可以的
這使你可以更靈活的調配適合你的 app 的 autoscale 的規則
Autoscale actions
Autoscale 可以執行三種動作
分別是 scale out (增加 instance 數量)
scale in (減少 instance 數量)
和增減至指定的 instance 數量
你可以用不同的運算子(operator) 來設定觸發條件
例如有小於(less than)、大於(grater than)和等於(equal to) 等等
通常觸發 scale out 的會用大於
而觸發 scale in 的則會用小於
Cool down period
每次 autoscale 被觸發後都會有一段冷卻(cool down)時間
在冷卻時間內
即使觸發條件被滿足了
autoscale action 都不會被觸發
你可以自訂冷卻時間的長度(以分鐘為單位)
冷卻時間的長度下限為 5分鐘
由於 instance 需要時間啟動或關閉
所以相關的計量在短時間內或不會有明顯的變化
若冷卻時間設定得太短
則可能會無意義的連續觸發
Pairing autoscale rules
Scale out 和 scale in 的規則應成對的被設定
在某個計量(metric) 太大的時候 scale out
然後在該計量回復正常的時 scale in 到原本的 instance 數量
Combining autoscale rules
一個 autoscale condition 可以包含多個 autoscale rule
例如一個 scale out rule 和其相應的 scale in rule
但一個 autoscale condition 內的 autoscale rule 之間不一定要相互有關係
下面就是一個例子
- 如果 HTTP 佇列長度(HTTP queue length)超過 10,則相應 scale out 1
- 如果 CPU 使用率(utilization)超過 70%,則相應 scale out 1
- 如果 HTTP 佇列長度為零,則相應 scale in 1
- 如果 CPU 使用率低於 50%,則相應 scale in 1
要注意的是
任意一個 scale out 條件被滿足都會觸發 scale out
全部 scale in 條件被滿足的時候才會觸發 scale in
如果你想任意 scale in 條件被滿足的時候都觸發 scale in 的話
你就需要把各項 scale in 條件各自放到不同的 autoscale condition
發佈留言