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)、機器起來時如何部署/安裝應用程式。
  • 可以預載維運管理工具,像是:

更多相關說明參見:


核心概念與名詞

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 statusrunning 以外的狀況
  • system statusimpaired

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

如果 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

相關文件:

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 以及評估,以下是建議要考量以及準備的:

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


延伸閱讀

站內延伸

參考資料

更新紀錄

  • 2017/02/04: 初版
  • 2018/12/12: 重構
    • 標題改名:Basic Concept of Auto Scaling -> EC2 Auto Scaling
    • 重構整體結構與內容 (40%)

Comments