Study Notes - EC2 Auto Scaling 導入與應用


整理導入 EC2 Auto Scaling 到新的系統、新架構過程中,在團隊協作溝通、前中後的技術確認、以及常見問答 … 等問題。

EC2 Auto Scaling 系列文章


導入前的溝通

導入任何新技術,最開始的,也是最重要的:向上溝通、團隊學習與訓練、安排執行計畫。

ASG 是協助維運的機制,解決的是維運面對的資源配置問題。所以導入這件事情,在現代的軟體開發裡面,如果是以類似敏捷開發、或者一些業務導向的公司,技術導入往往不會落在工作項目裡面,而且很容易因為溝通造成更多誤解。


評估與考慮

導入 ASG 馬上會面臨很多新的問題,整理如下:

  • 應用程式設計與屬性:
    • 是否 Stateless (無狀態性)
    • 依賴是否清楚,例如第三方依賴 (npm, maven, nuget …)、中介軟體 (middleware) 像是 Nginx、apache、IIS、tomcat …
  • 系統架構:
    • 包含清楚的角色定義、網路拓墣、實際使用的技術、抽象角色?
    • 通訊模式:Pull or Push
  • 部署流程:
    • Infra (不含 VM) 是否每次都重建
    • 機器 (VM) 的建置機制 (Provisioning) 是否完善?
    • CI 是否有產出物 (Artifact)?
  • 部署策略:Canary?Blue/Green?A/B? …
  • 維運策略:
    • Log 蒐集與儲存
    • 監控機制:動態資源狀態蒐集、動態告警機制
    • 緊急應變流程
    • OS Patch 資安策略

了解這些的目的是:

  1. 判斷應用程式可否導入 Auto Scaling?或者還差哪些具體的條件?
  2. 導入的門檻與效益是否不成比例

如何判斷應用程式可以導入 Auto Scaling?

先講結論:

能否自動化建置 VM (EC2) 是導入 Auto Scaling 的關鍵,也就是 Resource Provisioning 提到的概念。

實際上,如果針對的是有歷史的應用程式來講,Resource Provisioning 要思考的事情不少、面向廣泛、技術複雜度高,通常需要有經驗的人比較容易完成。如果可以使用容器化,整個過程會簡單多,但如果只能使用 VM,那麼就會比較複雜。

底下是建議判斷的方法:

  1. 利用可否容器化,判斷是否適合導入。
  2. 可以容器化間接代表著應用程式需要無狀態化 Stateless

容器化是現代流行的方式,但不見得每個企業或者架構都適合。但是應用程式能否容器化,卻可以用來判斷、檢測應用程式是否適合導入 Auto Scaling。可否容器化的答案有很多種:不用改、小改、大改、砍掉重練。有幾個變因可以判斷改動大小:

  • 環境變數
    • 服務的 endpoint
    • 敏感性資料:DB Id / Pwd
  • 配置檔:
    • 應用程式 分成 系統配置參數 (Config)商業應用參數 (Settings)
      • 系統配置參數 (Config): 通常是依賴的 endpoints,以及認證、授權資訊
      • 商業應用參數 (Settings): 通常是特定的參數設定
    • 環境建置 參數同樣分成這兩種:系統配置 (Config)、環境配置參數 (Settings)
      • 系統控制參數 (Config): 通常是依賴的 endpoints,以及認證、授權資訊
      • 環境配置參數 (Settings): 通常是特定的參數設定
  • 冪等性 (idempotent):每次重複執行的結果是一樣的
  • 資料永續性:像是 Session

經過上面的考量與整理,大概會歸納出以下幾種調整的範圍:

  • 不用改:只要注入 (DI) 環境變數、配置檔即可。
  • 小改:需要調整抽離部分的 Config
  • 大改:Lagency Application,如果沒有很大的痛點,會不容易驅動改變。

了解系統架構

一個系統通常會有很多角色 (Role),像是 DB、Web、API、Frontend、Cache、LB … 等角色。了解這些關係與整體的樣貌,了解哪一些適合使用這樣的技術。


上線前:準備工作

應用程式無狀態

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

  • 架構調整:應用程式一定要是 Stateless (無狀態),架構上需要考慮 Loose Coupling。更多參考 Architecting for the Cloud 的整理。
  • 思考環境:因為有 AMI,環境的建置應該更快更容易,所以各個階段的環境應該都可以更自動,像是 Dev / Test / Staging / Production。
  • 思考維運流程:這邊的 維運 指的是上線之後的事情,像是如何監控、異常處理流程、人員的訓練、監控機制的調整 … 等,都是要跟著改變的。
  • 思考是否配合 ELB、EC2、Route53、CloudFormation 等服務使用,讓部署更自動化

Artifacts Management

應用程式的 Artifact 必須完善,ASG 在執行部署時,才更有彈性。

通常會有兩種選擇:

  • 固定版本 (FIXED):也就是 Auto Scaling 啟動的機器,載入指定的版本,例如 固定在 1.5.0 這個版本。
  • 最新版 (LATEST):每次啟動的 EC2 Instance 都直接配置 最新版本

詳細參見: Artifacts Management聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)

EC2 建置自動化

調整慮部署方式:部署方式要先從如何做 AMI 開始,如何自動化應用程式的配置 (Provision)、部署 (Deployment)、測試、監控 (Observing)、Log 如何搜集 … 等,這邊的重點在於這些事情都要 自動化

Config Managemnet

應用程式的配置管理 (Config Management, CM) 與設定 (Settings) 必須完全的應用程式抽離。

Design for Failure

使用 ASG 當發生異常時,必須要有應變的方法。故障的種類大概有以下幾種:

  1. Instance Failure: 機器硬體故障
  2. System Failure: 機器的作業系統故障
  3. Application Failure: 應用程式本身故障

Graceful Shutdown 是處理方式,簡單說,上述的狀況發生時,透過生命週期的 Callback / Hook,決定如何處理這些問題。底下是 EC2 Instance Lifecycle 和 ASG Lifecycle 的整理,只要有處理這些 Hook / Event 就可以達到自動修復的功能。

設計:Health Check

在介紹 淺談系統監控與 CloudWatch 應用 的分享中,提到 Health Check 的設計,可以針對不同 Layer 設計,例如只打到 API 層次,當機器發生異常時,可以直接知道異常的路徑與層次,甚至直接回報異常原因。


上線中:部署策略

部署的考量是:

  1. 資料
  2. 應用程式特性
  3. 系統架構

然後選擇如何:

  1. 有效部署
  2. 如何快速恢復
  3. 考量成本

部署策略的顆粒度,有幾個方向:應用程式、VM、AutoScaling

  • 以應用程式為單位
    • 搭配 CodeDeploy, Chef, Ansible, … 等工具
  • 以 VM 為單位
  • 以更換 Auto Scaling 為單位

如何部署新的應用程式?

因為 Auto Scaling 的機器都是動態的,所以部署的流程與方法都要重新考慮。

CI 流程:

  • 如果是直接透過 Jenkins 把 Build 好的 Artifacts 丟到機器,這樣的流程就要重新思以下方法:
    • 把 Build 好的 Artifacts 放到 S3,然後 EC2 Userdata 開機時自動下載安裝
    • Maintain 一份 ASG 線上機器的清單,這份清單必須是動態的。

部署方法:

  • 透過 Auto Scaling 更新 Launch Configuration (LC) 部署:
    • 更新 LC,然後透過調整 Desire Size 大小,先放一樣的數字後,等新機器 Ready 後,還原原本大小
    • 建立新的 ASG,上同樣的 ELB,完成後砍掉舊的 ASG
    • 建立新的 ASG + LC + ELB,可以使用 CloudFormation
  • 只更新應用程式,不更換 EC2
    • CodeDeploy
    • 用 [SSM: Amazon EC2 Simple Systems Manager][7] 部署 - 但是要自己 maintain EC2 list
    • 用 OpsWorks - Chef
    • 用 Ansible
  • 設計 Rollback 流程
  • 考慮 Blue-Green Deployment
    • 需要先有 EC2 的 Provisioning
    • 可以考慮用 CloudFormation or Terraform Provision 整個 Stack

如何取得機器的資訊?

在前一段提到 Maintain 一份 ASG 上機器的清單,主要是部署或者維護過程中,程式或者人可能會需要知道特定機器,甚至要進去機器看狀況,傳統沒有 ASG 的時候,是靠機器的名字作識別與溝通,ASG 就不會有這樣的概念,所以需要維護一份自己的清單。

理想的狀況之下,使用 ASG 的機器不應該,也不需要知道特定的機器。

這段我想提的其實就是 Whitepapter: Architecting for the Cloud 裡面的 Service Discovery,要開發一個服務,用來提供這些資源的資訊,讓其他服務可以查詢。這個服務自己就是批次更新 Resource 資訊,擔心資訊不夠即時,可以提供一個 refresh 的參數提供即時更新。


上線後:維運、監控

Scale-In Protected

Scale-In Protected 是 ASG 提供的機制,主要是在 Scale-In 的時候,機器不會被收走。

線上機器建議至少有兩台設定為 Scale-In Protected,因為如果 Scale-Out 的時候,機器因為無法正常啟動,避免正常的機器全部被收走,造成線上沒有可以運行的機器。

線上發現異常如何處理?

如何發現異常 是一個議題,所以前一段的監控機制與 Log 蒐集就很重要:設計容易讓維運人員了解的 Metric 。

線上發現異常時,ASG 要做的第一件事情是:

  1. 確認線上的機器是否都正常服務,如果有,請設定 Scale-In Protected 兩台以上
  2. 找到有問題的機器:透過設計 Health Check 的檢查,直接告知結果,例如靜態頁面,返回機器的資訊 (instance-id / ip) 等,有問題直接自動 detach 或者回報到 Slack.

上線後如何 Operation?

定義的有以下:

  • 異常處理流程
  • OS Patch - AMI Maintain
  • Service Capacity (Scale Up or Scale Out)
  • 系統權限的調整
  • Backup and Recovery
  • Cost and Budget
  • Hardware Failure

如何監控?如何蒐集 Log ?

同樣的,機器是動態的,所以監控的指標 (Metric) 將會是動態的,蒐集 Log 的方式也是動態的,蒐集 Log 時要注意留下像是機器 Instance-ID / IP 等資訊,以利日後可以查問題使用。

監控指標與 Log 蒐集可以使用 CloudWatch Log,詳細的說明參閱 Study Notes - CloudWatch 的整理。


結論

Auto Scaling 是 AWS 非常重要的核心技術,幾乎所有 Managed Services 背後的時候,都需要仰賴這樣的機制,才能變成自動化服務。

哪些 Managed Services?這是我猜測的,像是 ELB (CLB, ALB, NLB)、Elastic Beanstalk、API Gateway、RDS、Batch、EKS、ECS …

而如何善用這個機制,則是學習 AWS 除了 VPC 之外,我認為最重要的核心概念之一。


延伸閱讀

系列文章

站內延伸


Comments