前言

[Azure 筆記] 前言

---

原文

Examine scale out options

---

Azure App Service 有着 auto scaling 的能力
你的 app 可以依據排程(schedule) 或資源狀況來進行 scaling

要注意的是
這裏說的 scaling 是 scale in 和 scale out (增加或減少 instances 數量)
而不是 scale up 和 scale down (增加或減少單個 instance 可使用的 resources)

Azure App Service autoscaling

Autoscaling rules

App Service 會持續的監察你的資源使用狀況
你可以透過設置 autoscaling rule 來告訴 App Service
在什麼情況下需要 scale in 或 scale out

你需要小心的設置 autoscaling rules
例如，如果有人對你的 App 進行 DDoS 攻擊
過量的 Scale out 就會產生高額的費用

更好的做法是
在處理請求(request)前進行檢測和過濾
以免這些無用的請求消耗了過多的資源

When should you consider autoscaling?

Autoscaling 可以在服務負載較高的時候避免超時(timeout)或超載(overload) 的情況出現

並不是所有的情況都適合使用 autoscaling
以下是適合使用其他方案去處理的例子

如果需要耗費大量資源去處理單一請求的話
(例如是需要動用大量運算能力及記憶體去處理大量的數據)
Scale up (增加單個 instance 的可動用資源)可能會更適合

此外，如果你的服務的用戶數有着持續的增長
原本你設計的 instance 數量已經不足以應付日益增大的需求
那麼，你不應用 autoscaling 來 scale out
因為 autoscaling 的資源監察以及 scaling 的觸發會有一定的花費
你應該用 manual scale out 的方法來滿足可預測的需求

初始的 instance 數量也是一個考慮點
如果初始的 instance 數量太少
在 scaling 完成前
你的 app 可能就已經會不勝負荷

Azure App Service automatic scaling

App Service 有提供一種名為 automatic scaling 的服務
(注意，這裏說的是 automatic 而上文提及的是 auto，兩者是不同的喔！ ((Azure 你起名字可以起得好一點嗎，害我疑或了半天 🤧

相比 autoscaline，automatic scaling 有以下的不同

• 只有 Premium tier 可用
• 不能設置 scaling 的觸發條件 (autoscaling rule)
• Azure 會根據當時的 Http 流量 (traffic) 來自動決定是不是要進行 scaling
• 最少會有一個可被使用的 instance
• 最少會有一個 prewarned instance，可避免 scale out 時的 cold start 造成的服務影響
• 同一個 App Service Plan 內不同的 App 可以有不同數量的 instance
• 可設置 instance 數量上限，可用作避免 backend resource (e.g database, 其他幫忙處理請求的系統) 的負荷過重