Study Notes - EC2 Auto Scaling 常見問題


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

EC2 Auto Scaling 系列文章


FAQ

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

有以下好處:

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

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

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

  • EC2 Auto Scaling 的應用場景:面對自然成長的流量、維運效率與自動化、成本優化、高可用性
  • 如何解決瞬間巨量:要有 適度的資源 + 架構的設計

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

而瞬間巨量、搶購 (panic buying) 技術上面對的是 限流機制 的問題,生活中最常見的就是台灣每年春節時,高速公路的高乘載管制,這就是限流的最基本概念。所以回到問題,ASG 是否可以解決瞬間巨量的問題?

答案是:不一定。因為瞬間巨量是要透過架構機制解決,而不是透過資源解決。資源只能緩解,但是沒有現流機制配合,很容易就會產生連鎖反應,最後產生的就是系統異常的現象。一個系統從入口的 Gateway (LB)、經過應用 (App)、快取 (Cache),最後到 Database,整串的 Stack 是很複雜的,而 Auto Scaling 大部分解決的會是 App 層的資源問題,剩下整體的機制,就要從架構層面考量。

Q: EC2 Auto Scaling 有什麼缺點?

任何技術都有其擅長的、適合的情境,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,為什麼還要手動配置機器?

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

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

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

詳細參閱:

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 時間
    • 成本:部署過程會有額外成本產生
    • 優點:可以處理無法向下相容的版本,新舊版本可以快速切換,流量百分比可以自行控制

延伸閱讀

系列文章

站內延伸


Comments