Study Notes - EC2 Auto Scaling 導入與應用

整理導入 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 常見問答

導入前的溝通

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

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 資安策略

了解這些的目的是：

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

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

先講結論：

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

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

底下是建議判斷的方法：

利用可否容器化，判斷是否適合導入。

可以容器化間接代表著應用程式需要無狀態化 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、聊聊軟體交付的濫觴談產出物管理

EC2 建置自動化

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

配置請參閱 Resource Provisioning，有更多想法整理。

Config Managemnet

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

Design for Failure

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

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

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

EC2 Auto Scaling - Lifecycle and Hooks
EC2 Instance Lifecycle and Troubleshooting

設計：Health Check

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

上線中：部署策略

部署的考量是：

資料
應用程式特性
系統架構

然後選擇如何：

有效部署
如何快速恢復
考量成本

部署策略的顆粒度，有幾個方向：應用程式、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 要做的第一件事情是：

確認線上的機器是否都正常服務，如果有，請設定 Scale-In Protected 兩台以上
找到有問題的機器：透過設計 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 之外，我認為最重要的核心概念之一。