Posted in: AWS云服务器代维护

AWS Study Notes – Basic Concept of Auto Scaling教程

整理 AWS 很重要的核心功能之一：Auto Scaling Group 學習筆記，這篇整理基本的概念以及重要的名詞。

基本概念

效益

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

使用的條件

需要先準備 AMI (Amazon Machine Images )，並且搭配 userdata 配置需要的環境，像是安裝 nginx, tomcat, 部署應用程式、監控工具 … 等。
EC2 Instance 裡面的 Application 的設計必須是 stateless
- 應用程式的『狀態』，像是 Session、Cookie 等，要透過其他儲存媒介儲存，像是 ElasticCache、RDS、S3、EFS …
- Instance 可以隨時被砍掉
- 需要長時間執行的程序，要透過 SQS 。
透過 AMI 建立的 Instance 開機就要可以上線
可以預載部署工具，像是 CodeDeploy、SSM Agent、Log 蒐集工具、監控工具的 Agent.

導入 ASG 注意事項

在 Auto Scaling Group 裡，每個 EC2 Instance 不再是固定的寵物 (Pets)，而是隨時會被砍掉的牲畜 (Cattle)，所以要導入 Auto Scaling 要思考以下：

架構調整：應用程式一定要是 Stateless (無狀態)，架構上需要考慮 Loose Coupling。更多參考 Architecting for the Cloud 的整理。
調整慮部署方式：部署方式要先從如何做 AMI 開始，如何自動化應用程式的配置 (Provision)、部署 (Deployment)、測試、監控 (Observation)、Log 如何搜集 … 等，這邊的重點在於這些事情都要 自動化
- 配置請參閱 Resource Provisioning and DevOps，有更多想法整理。
思考環境：因為有 AMI，環境的建置應該更快更容易，所以各個階段的環境應該都可以更自動，像是 Dev / Test / Staging / Production。
思考維運流程：這邊的維運指的是上線之後的事情，像是如何監控、異常處理流程、人員的訓練、監控機制的調整 … 等，都是要跟著改變的。
思考是否配合 ELB、EC2、Route53、CloudFormation 等服務使用，讓部署更自動化

重要的名詞與概念

Auto Scaling Group

控制自動 Scale In/Out 的主要功能，以下簡寫成 ASG。

Launch Configurations

以下簡稱 LC。

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

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

Health Check Type

分成 EC2 和 ELB 兩種。怎樣的狀況 EC2 Instance 會被 ASG 判斷成 health or unhealty？

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

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

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

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

Termination Policies

Scale In 的時候，ASG 會移除 (Terminate) 多的機器。刪除機器的規則，預設 (Default Termination Policy) 如下圖：

Source: Controlling Which Instances Auto Scaling Terminates During Scale In

選擇刪除的條件次序：

據機器在 AZ 的數量 -> 選擇機器多的 AZ，然後挑一台砍掉
有沒有使用舊的 LC -> 找舊的 LC 跑起來的機器，挑一台砍掉
那一台機器快到下個 Billing 的時間

除了 Default Termination Policy，使用者也可以使用 Custom Termination Policy，目前支援以下幾種：

OldestInstance: 刪除最舊的 Instance 。通常用在更換 AMI / LC 的時候，可以透過增加一倍的機器，等機器都好了，再恢復期望值，如此就的機器就會全部刪除了。有點像是 Blue-Green Deployment 時的狀況。
NewestInstance: 跟上一個相反，刪除最新的 Instance。通常用在測試新版本的 AMI / LC，可以想像適用 Canary Deployment 的方式。
OldestLaunchConfiguration: 刪除最舊的 LC 所建立的機器。
ClosestToNextInstanceHour: 刪除最接近下次收費的機器。
Default: 預設，就是前面的流程圖。

Termination Policy 可以有多個。

Scaling Policies – Dynamic Scaling

用來 Scale In/Out 的條件，主要搭配 CloudWatch Alarm 增減 Instance，有 Simple Policy 和 Step Policy 兩種：

Simple Policy: 根據 CloudWatch Alarm 狀況，執行一個動作
Step Policy: 根據 CloudWatch Alarm 狀況的範圍，細分條件，執行不一樣的動作。像是 CPU 在 70-85 增加一台、超過 85 增加兩台

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

更多參閱：Dynamic Scaling

Auto Scaling Cooldowns

如果 ASG 裡的機器 CPU 達到 Scale Out 的條件，這時候 ASG 依照 Scaling Policies 的設定增加一台新機器，但是這台機器跑起來要花五分鐘，這五分鐘之內 CloudWatch Alarm 發現 CPU 的狀況超過設定，還是符合 Scaling Policies 的，那麼 ASG 要繼續增加一台機器嗎？

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

Health Check Grace Period

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

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

Lifecycle Hooks

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

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

完整筆記參閱：Study Notes – AutoScaling Lifecycle and Introduce

Others

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

結論

ASG 東西真的滿多的，而且有點複雜，所以如果要導入新產品，技術上要做很多 Lab 以及評估，流程上要重新思考部署流程，特別是在 Resource Provisioning 部分。

參考資料

Auto Scaling – User Guide

Tags: AWS代付, 云主机托管, 云服务解决方案, 企业上云服务咨询, 服务器迁移, 电话告警, 运维支持