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

不是 Auto 了，為什麼還要設定？

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

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

EC2 Auto Scaling 系列文章

• Study Notes - EC2 Auto Scaling 基礎介紹
• Study Notes - EC2 Auto Scaling - Scaling Policies
• Study Notes - EC2 Auto Scaling - Termination Policies
• Study Notes - EC2 Auto Scaling - Lifecycle and Hooks
• Study Notes - EC2 Auto Scaling 導入與應用
• Study Notes - 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 增加兩台

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

• 更多參閱：Dynamic Scaling for Amazon EC2 Auto Scaling

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 之後，依據你的場景，選擇適當的。

延伸閱讀

系列文章

• Study Notes - EC2 Auto Scaling 基礎介紹
• Study Notes - EC2 Auto Scaling - Scaling Policies
• Study Notes - EC2 Auto Scaling - Termination Policies
• Study Notes - EC2 Auto Scaling - Lifecycle and Hooks
• Study Notes - EC2 Auto Scaling 導入與應用
• Study Notes - EC2 Auto Scaling 常見問答

站內延伸

• Resource Provisioning and DevOps