整理導入 EC2 Auto Scaling 過程中，常見的問答。

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 常見問答

FAQ

Q: 為什麼要導入 EC2 Auto Scaling？

有以下好處：

• 減少日常流量自然增長時，在系統維運上，減輕人力負擔、減少機器的費用成本。
• 提供彈性的部署機制，例如更快速地增減機器，以符合藍綠部署、A/B Test、甚至是 Rollback 的需求。
• 提供環境建置的一致性

Q: EC2 Auto Scaling 能否面對瞬間巨量？

這問題分成兩個層面回答：

• EC2 Auto Scaling 的應用場景：面對自然成長的流量、維運效率與自動化、成本優化、高可用性
• 解決瞬間巨量的條件有 1) 擴容架構 2) 架構的設計: 限流 + 排隊機制

EC2 Auto Scaling 的設計是要面為維運時資源的彈性配置、減少人工介入，這在前面有很多介紹。

答案：不能。

因為瞬間巨量是要透過架構機制解決，加上擴容架構。而搶購整體的交易總數通常由 Database 的總量決定，也就是 DB 單位時間能夠處理的交易量，常用的詞是 TPS (每秒交易次數)。TPS 是整個系統的短板，整個系統可以承載交易量，由此確立。剩下的就是 AP 曾如何處理沒搶到的流量請求，所以需要排隊機制、限流、擴容等配套措施，也是預防 DB 被流量沖垮。一個交易請求次序為：入口的 CDN 、Ingress (LB)、經過應用 (AP)、快取 (Cache)，最後到 Database 完成交易。而 Auto Scaling 大部分解決的會是 AP 層的擴容問題，注意，無法瞬間 (<10s) 增加容量。

生活中最常見的就是台灣每年春節時，高速公路的高乘載管制，這就是限流的最基本概念。2020/Q1 因為武漢肺炎因素，口罩的分配機制，也是一種搶購概念。

所以回到問題，ASG 是否可以解決瞬間巨量的問題？

• 關於系統容量量測，更多參閱：如何量測系統的容量？（壓測） 介紹
• 電商的搶購用詞：buying frenzy、buying spree、panic buying
• 限流機制參閱：API Gateway - Rate Limit and Throttling
• 2020/03/21: 在 Facebook Backend 台灣，針對館長搶購，鄉民討論解，我寫下的建議

Q: EC2 Auto Scaling 有什麼缺點？

任何技術都有其擅長的、適合的情境，EC2 Auto Scaling 缺點：

1. 機制稍微複雜 (但我覺得合理)
2. 進入門檻高
3. 沒有使用既定機器的方法

如同第一篇 EC2 Auto Scaling Group 基礎介紹 的整理，很多人大概還沒看就吐血了，那麼多名詞、那麼多東西要理解，更別提還要做 Lab。但因為他是通用性的設計，換言之必須考慮所有可能的場景與彈性，所以複雜是可以理解，且合理的。

如果你要設計一個 Auto Scaling 機制，你會想怎麼讓使用者使用？

另外的缺點是，他無法針對既有的機器直接管理，換言之，機器必須是用完即刪、可以自動化建置的機器才能使用 AutoScaling 這樣的機制。

許願：其實可以設計成指定 Pool，讓 ASG 去配置，而不用砍掉，這樣會降低使用門檻很多。

Q: Scale-In 機器會被砍掉，這是依照怎樣的規則？

依照 Termination Policies，相關的條件有 AZ 數量分布、機器建置的先後，這些條件會構成選擇的策略。

詳細參閱：EC2 Auto Scaling - Termination Policies。

Q: Auto Scaling 既然叫做 Auto，為什麼還要手動配置機器？

依照使用的情境，會有不同的需求。例如：

1. 測試階段，需要確認 Scale-In / Scale-Out 是否正確建置機器、正常 Graceful Shutdown
2. 開發過程，就需要了解如何設計 Graceful Shutdown、了解如何搭配 Lifecycle Hook，如何 Debug
3. 線上維運，如果發生異常，必須能暫時暫停自動擴展，變成手動控制，以維持服務的正常。

所以實際上 Auto Scaling 機制本身必須有所有可能的組合，也就是從手動、半自動、全自動等選擇，這稱為 Scaling Policies (擴展策略)，依據不同的場景，選擇適當的策略。

詳細參閱：

• EC2 Auto Scaling - Scaling Policies
• EC2 Auto Scaling - Lifecycle and Hooks

Q: 部署過程，如何透過 ASG 做到 Zero Downtime？

考量以下兩個情境：

1. 前後版本 向下相容 (Backward Compatible)
2. 前後版本 不相容

作法大概有以下：

1. 直接調整 ASG 的 Desired
   • 流程：
     1. 為新版本建立 新的 Golden Image 與 Launch Config
     2. 為 ASG 更換 Launch Config - 新舊版本不一樣的
     3. 確認 Termination Policies：先砍最舊的
     4. 調整 Desired 數量，例如從 2 to 4：新舊版本同時存在
     5. 調整 Desired 數量，例如從 4 to 2：舊版本收掉，剩下新版本
   • Rollback：調整 LC ，重新伸縮機器數 2 -> 4 -> 2 即可。
   • 優點：很簡單
   • 缺點：比較慢
2. Blue/Green: 建立新的 ASG
   • 流程：
     1. 建立新的 ASG，長出與舊 ASG 一樣的機器數
     2. 透過自動化，交換兩個新舊 ASG 的 ELB 設定
   • 風險：有問題，可以隨時 Rollback
   • 成本：部署過程會有額外成本產生
   • 優點：可以處理無法向下相容的版本，新舊版本可以快速切換
3. A/B: 建立新的 ELB 與額外成本產生立兩組，流量透過 Route53 直接調整分佈比例
   • 流程：
     1. 建立新的 ELB + ASG
     2. 設定 Route53 的 Traffic Policy
     3. 導流量
   • 風險：有問題，可以隨時 Rollback，依照 DNS TTL 時間
   • 成本：部署過程會有額外成本產生
   • 優點：可以處理無法向下相容的版本，新舊版本可以快速切換，流量百分比可以自行控制

延伸閱讀

系列文章

• 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 常見問答

站內延伸

• 如何量測系統的容量？（壓測）
• Artifacts Management
• 聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)
• Resource Provisioning and DevOps
• Study Notes - CloudWatch
• 淺談系統監控與 CloudWatch 的應用 - AWS User Group Taiwan
• EC2 Instance Lifecycle and Troubleshooting

更新紀錄

• 2020/03/22: 重新描述 ASG 能否面對搶購