Study Notes - EC2 Auto Scaling 基礎介紹

整理 AWS 很重要的核心功能之一：EC2 Auto Scaling 筆記，這篇整理核心功能以及概念。

AWS 另一個類似發表於 2018/01/16 的服務叫做 AWS Auto Scaling 則是超集 (Superset) 整合服務，可以管理 EC2 Auto Scaling Groups、EC2 Spot Fleet Requests、ECS、DynamoDB、Auroa … 等服務。本文介紹的只是其中一個子集。

基本概念

效益

根據流量提供可用的容量，省去人工監控、排程
更好的容錯 (fault tolerance) 機制
更好的高可用度 (High Available) 機制
節省成本:
- 依據 Scaling Policy 自動增減機器，達到成本最佳化
- 可以搭配 Spot Instance 使用，更省！
搭配 container 更省成本！不過也相對更複雜

使用的條件

使用 EC2 Auto Scaling 要有一些前提條件，建議要依據系統架構、應用程式特性規劃，技術面簡單整理如下：

規劃 Resource Provisioning 策略，主要是 VM Level 建置方法與工具
- Immutable：透過 AMI 建立的 Instance 開機就要可以上線。換言之，機器隨時可以被砍掉，是 cattle, Not pets.
規劃 Artifacts Management 策略，主要是管理流程與方法
- 準備 AMI (Amazon Machine Images)
  - 此 AMI 為 Golden Image
  - 依據 部署策略 搭配 userdata 配置需要的環境，像是安裝中介軟體 (Middleware)，像是 nginx、tomcat，還有待部署應用程式、監控工具 … 等。
規劃 Config Management 的管理或者服務
架構設計考量
- EC2 Instance 裡面的 Application 的設計必須是 stateless
- 應用程式的 狀態，像是 Session、Cookie 等，要透過其他儲存媒介儲存，像是 ElasticCache、RDS、S3、EFS …
- 考量 Scale-In / Scale-Out 生命週期的管理，包含 Instance 可以隨時被砍掉（需要 Graceful Shutdown)、機器起來時如何部署/安裝應用程式。
可以預載維運管理工具，像是：
- 部署工具：CodeDeploy
- 維運工具：SSM Agent
- Log 蒐集：CloudWatch Agent、Kinesis Agent …
- Docker Agent: Sidecar Pattern for Logger, Config, Service Mesh

更多相關說明參見：

Study Notes - EC2 Auto Scaling 的導入與應用

Resource Provisioning and DevOps

核心概念與名詞

EC2 Auto Scaling Group

全名為 EC2 Auto Scaling Group (以下簡寫成 ASG)，依據擴展策略 (Scaling Policies) 控制 EC2 增加 (Scale Out) 或者是減少 (Scale In)。

Launch Configurations

以下簡稱 LC。

ASG 用來執行擴展 (Scale In/Out) 時，用來指定建立 EC2 Instance 的相關資訊，像是 Instance Type、AMI Id、KeyPair、Security Group、User Data、Spot Instance … 等資訊。

他有點像是在建立 EC2 的時候需要的相關資訊，但是不包含 Subnet、EBS 等。

Launch Template

2018/01/19 發佈的新功能：Launch Templates (以下簡稱 LT)，與 LC 有點類似，不過可以客製化 EC2 更多細節資訊，包含 EC2 AMI 相關資訊、Network Interface、Stroage 配置、Tags、Advanced Detail …

這些設定可以變成類似於 Config 的概念，同時也包含了版本控制，下次要建立 EC2 Instance 的時候，可以直接使用此 Template。

使用 LT 要注意其限制：

每個 Region 5000 LT
每個 LT 有 10,000 個版本
要確認每次指定的參數都是對的，例如選擇 Placement Group 的同時，必須自行選擇支援的 Instance Type
LT Version 不支援 Tag 功能
LT Version Number 不能自己指定

詳細參閱：Launching an Instance from a Launch Template

Health Check Type

怎樣的狀況 EC2 Instance 會被 ASG 判斷成 health or unhealty？ASG 支援三種類型：EC2、ELB、Custom。

如果選擇 EC2，只要是以下兩種之一，就會被判斷成 unhealthy：

instance status 是 running 以外的狀況
system status 是 impaired

這兩個是 EC2 的 Status Check，用來判斷 EC2 是否正常啟動的依據之一

EC2 的 Instance Status 和 System Status 參閱筆記 EC2 Instance Lifecycle and Troubleshooting 的整理與說明。

如果 Health Type 是 ELB，那麼就會根據 CLB 或者 ALB Target Group 的狀態決定。當 ELB 狀態是 OutOfService 的時候，ASG 呈現 unhealthy 狀態。如果 Connection Draining 有開啟，那麼 ASG 會 in-flight 請求，或者等到 timeout。

Health Type 可以自行定義，使用上目前只能透過 AWS CLI 設定，直接指定某一台機器的狀態為 Unhealthy，而這個狀態就由使用者自行設計，只是最後是透過 CLI 設定，如下：

1
2
3

aws autoscaling set-instance-health \
        --instance-id i-123abc45d \
        --health-status Unhealthy

相關文件：

EC2: Health Checks for Auto Scaling Instances

CLB: Using Elastic Load Balancing Health Checks with Auto Scaling

ALB: Health Checks for Your Target Groups

Scaling Cooldowns

Scaling Cooldowns 的目的是 Scale Policies 被觸發的時候，不管是 Scale Out or In (這些活動稱為 Scaling Activities)，ASG 會有一段時間暫時忽略符合 Scaling Policies 的狀況，避免 Scaling Activities 被重複觸發。

最常見的情境：

ASG 裡的機器跑起來，到狀態為 health 要 5 分鐘 (300 秒)
如果 ASG 裡的機器 CPU 達到 Scale Out 的條件，這時候 ASG 依照 Scaling Policies 的設定增加一台新機器
- 但是這台機器跑起來要花五分鐘
- 這五分鐘之內 CloudWatch Alarm 發現 CPU 的狀況超過設定，還是符合 Scaling Policies 的，那麼 ASG 要繼續增加一台機器嗎？
檢查 Cooldowns 的時間判斷是否要重複觸發，或者忽略此觸發動作。

相關要注意的課題：

Default Cooldowns
Scaling-Specific Cooldowns
Cooldowns and Multiple Instances
Cooldowns and Lifecycle Hooks
Cooldowns and Spot Instances

Health Check Grace Period

ASG 等待 EC2 Instance 一段時間之後，才開始做 Health Check，這段等待時間叫 Grace Period，單位是秒。

因為 EC2 Instance 從 AMI 建立要一點時間，通常會落在 3-5 分鐘，如果有使用 userdata 跑額外的東西，像是安裝應用程式、最新版本的程式、監控程式等，則會更久。

要注意的是：

Health Check Type 如果是 ELB，那麼 ELB 又有另一段 Check 的時間
Grace Period 跟 Scaling Cooldowns 是不一樣的

Lifecycle Hooks

ASG 支援 Lifecycle Hooks，可以在特定的狀態執行客製的動作。

也可以透過 SNS 方式觸發 Lambda 執行特定動作，目前支援 launch, terminate, fail to launch, fail to terminate 四個動作。

完整筆記參閱：Study Notes - EC2 Auto Scaling Lifecycle and Hooks

Others

Suspended Processes: 主要是用來 Debug Config，像是啟動機器的時候先不要加入 ELB、或者 Scale In 時，先不要 Terminate Instance … 等。
Instance Protection: Scale Out 時，增加的機器自動變成 Protection 狀態，不會被刪除。
Enabled Metrics: 啟動 ASG 的 CloudWatch Metrics

系列文章

EC2 Auto Scaling 的知識量很多，分別整理成一系列文章如下：

結論

AWS 的服務這幾年爆炸性的成長，新的服務雨後春筍的生出來，有時候打開 AWS Console 我都覺得服務多到像是在看報紙。

從架構以及應用面來看，所謂的 #新服務我猜可能就是利用 AWS 核心服務 (EC2 / ELB / VPC / EBS / S3 / IAM / CloudWatch …) 組裝出來的產品。也因此，AWS 核心服務的功能也是越來越強大，功能越來越複雜。所以學習 AWS 的時候，掌握其核心服務的功能、設計考量、設計原理、應用場景、常見問題 … 等，是非常重要的，也可以從中學習到 AWS 的產品思維與架構概念。

EC2 Auto Scaling 是 AWS 非常核心的關鍵服務，它的功能隨著時間越來越多，也越來越複雜，應用場景也越來越全面。從這些功能的設計，不難發現是為了維運、成本、可靠性、安全而設計，如同 Well-Architected 所描述，特別是維運是優先。

雖然，這年代的新創事業以 Serverless 當道、Container / K8s 正在潮，大家都很會兜 Solution，組東組西，但往往真正上線維運後，挑戰才真的開始，問題才慢慢浮現。

不管傳統也好，新創也罷，VM or Container，只要 EC2 還有在出新的 Family 的一天，Auto Scaling 也會一直是很重要的服務。

不管是學習，或者是要導入新產品，技術上要做很多 Lab 以及評估，以下是建議要考量以及準備的：

Artifacts Management
Resource Provisioning
Config Management
部署策略
維運策略
監控策略

策略 是種選擇，但是在選擇之前，要知道有哪些。

Study Notes - EC2 Auto Scaling 基礎介紹

基本概念

效益

使用的條件

核心概念與名詞

EC2 Auto Scaling Group

Launch Configurations

Launch Template

Health Check Type

Scaling Cooldowns

Health Check Grace Period

Lifecycle Hooks

Others

系列文章

結論

延伸閱讀

站內延伸

參考資料

官方更新

更新紀錄

Comments

About

著作

演講

Facebook

AWS Certifications