Study Notes - EC2 Auto Scaling - Scaling Policies


EC2 Auto Scaling 是自動控制 EC2 橫向擴展 (Scalable) 的機制,名稱有個 Auto 的字眼,很多同事就會問這樣問題:

不是 Auto 了,為什麼還要設定?

這是個好問題,因為大家都以為自動了,就啥都不要管了 XD

實際上自動只是一種最終目的,而整個機制必須保留彈性,讓過程中,如果有非預期的狀況,可以做各種適度的橋整與安排,而這就叫做 Scaling Policies

EC2 Auto Scaling 系列文章


Scaling Policies

Scaling Policies 中文稱為 擴展策略,依據不同的情境、架構,會有不同的選擇。ASG 有四種 Scaling Policies:

  1. Manual Scaling (手動) –> 人工 or 自己來
  2. Scheduled Scaling (排程) –> 半自動
  3. Dynamic Scaling (動態) –> 全自動
  4. Predictive Scaling (預測) –> AIOps

不難看出,從第一到第四,就是手動到完全自動。但是不表示使用上可以一步登天,或者全自動就是最好,而是要依照應用程式的特性、架構考量、維運考量、部署考量等特性,找到最 適合的策略

技術上,ASG 透過控制這三個參數來達成擴展:

  • Disired Capacity: 期望值
  • MinSize: 最小值
  • MaxSize: 最大值

這三個值的關係: Min <= Disired <= Max

底下一一整理這些 Scaling Policies 的特性以及要注意的地方。

Manual Scaling

手動增減機器,也就是透過調整 Disired Capacity 參數增減機器。通常一開始玩 ASG 建議先從這裡開始。

要注意:

  1. 手動調整 Desired Capcity 時,如果有開啟 Dynamic Scaling
  2. Disired 不可以超過 MinSize or MaxSize

Scheduled Scaling

透過排程,調整 Disired、Min、Max 的數值。

第一次上線的服務,建議先從 Scheduled Scaling 開始,而且最好是在上班時間執行,有問題時,可以馬上處理。

要注意:排程時區是 UTC

Dynamic Scaling

動態擴展,也是 ASG 最理想的策略。主要透過 控制變因臨界值 的設定,然後 執行動作 進而達到改變 Disired Capacity 的設定。

  • 控制變因像是 EC2 的 CPU Utilization
  • 臨界值:超過 80%
  • 執行動作:Scale In or Out

自 ASG 大部分的 Scale In/Out 的條件,主要搭配 CloudWatch Metric + Alarm ,然後調整 Disired Capacity,也就是增減 Instance。ASG 預設的 Dynamic Scaling Policy 有兩種:

  • Target tracking scaling: 可以依據某一個指標的數字,自動跟著 Scaling
  • Simple Policy: 根據 CloudWatch Alarm 狀況,執行一個動作
  • Step Policy: 根據 CloudWatch Alarm 狀況的範圍,細分條件,執行不一樣的動作。像是 CPU 在 70-85 增加一台、超過 85 增加兩台

調整機器數量的方式,除了用 數量 調整,也可以使用 百分比 方式。

Predictive Scaling

2018/11/20 發佈的新功能。

透過 Machine Learning,依據過去的資料訓練出預測模型,進而達到 [Predictive Scaling][r17] 的功能與效果。不過這個功能現在放在 AWS Auto Scaling 產品底下,不是在 EC2 Auto Sacling 裡。

類似的功能其實 Netflix 在 2013 年就有實作,詳細參閱: Scryer: Netflix’s Predictive Auto Scaling Engine


結論

導入 Auto Scaling 過程中,很多人會問:

不是 Auto 了,為什麼還要設定?

實際上,依據不同的場景,通常在設計機制的時候,都必須全面的思考,特別是越是通用的機制,全面性的考量需要越嚴謹,換言之,他也會越來越複雜。

了解 Scaling Polices 之後,依據你的場景,選擇適當的。


延伸閱讀

系列文章

站內延伸


Comments