緣起
Amazon Elastic Container Service (Amazon ECS) 已經許久沒有迎來新功能了！這次迎來的新功能是「Amazon ECS Cluster Capacity Providers」。本篇將快速分享 AWS re:Invent 2019 CON312 [NEW LAUNCH!] Automatic cluster scaling with Amazon ECS 的議程內容。
Amazon ECS 這個全託管的容器編排調度服務 (fully managed container orchestration service) 不僅僅 Amazon 自身很愛用，其他如 Duolingo, Samsung, GE, 以及 Cook Pad 都是 Amazon ECS 的愛用者之一。
內容大綱
然而在大環境、大潮流下，大家多半將關愛的眼神及注意力放在 K8S 系的 Amazon Elastic Kubernetes Service (Amazon EKS) 身上 [1]，但其實小而美的 Amazon ECS 在某些應用場景或是中小企業應用上，能帶來部署簡化與營運效率，更專注在企業應用本身以及獲利上。身為 Amazon ECS 愛用者（以及身為冷靜拆解、不愛追隨潮流者（a.k.a 懶惰鬼）），來跟大家分享一下這次 AWS 終於在 re:Invent 2019 發布針對 Amazon ECS 的新功能：「Capacity Providers」。
之所以會有 Capacity Providers 的推出，我們得先回頭看一眼之前的 Amazon ECS 有哪些擴展的功能。
原本的 Amazon ECS 將擴展的功能放在 ECS Service 層，有個 Service Auto Scaling 可以用來擴展。
但是 ECS Cluster 層，是交給 CloudFormation 建立 ECS Cluster 時所建立的 ASG (Auto Scaling Group) 做管理，設定起來相當不便、不直覺，連原本的官方文件都是透過 AWS Management Console 裡頭透過 ECS Cluster 的介面去手動調整要幾台 ECS Instances，而且還不能直接去動那個 ASG 的 LC 參數，因為此 ASG 是從 CloudFormation 長出來的，所以像是為了升級 ECS Container Agent 而要更新 AMI ID，那可是一場混戰（不信的話可以參考這篇和這篇，其中一篇還會誤導讀者，到最後還是會被 CloudFormation 的參數給回寫覆蓋，等於做白工。但現在有了 Capacity Providers 也就不需要跟大家說哪一篇最好不要看了），這一題我們留到文末來討論。
現在有了 Capacity Provider 這一層，可以簡便地將 ECS Cluster 與 ECS Service 兩層動態地連結起來，讓 Amazon ECS 這個服務更加就手，簡化維運成本。以下就以個人出席參與 re:Invent 2019 CON312 的議程內容來作簡要介紹，更多細節可以追看官方文件或其他 re:Invent 議程內容。（以下就是個把議程當遊記在寫的概念…）
CON312: Automatic cluster scaling with Amazon ECS
CON312 原本的議程標題是「[NEW LAUNCH!] Automatic cluster scaling with Amazon ECS」，是官方於 re:Invent 2019 週二 Keynote 發布 Amazon ECS Cluster Capacity Providers 之後，新冒出來的隱藏議程，手刀搶到後，趕緊前往現場與 Amazon ECS 團隊的成員面對面交流。以後若有實體參加 AWS re:Invent 活動，記得週三之後的議程先不要排太滿，才有機會與新服務背後的團隊做第一手的交流。
抵達現場之後，看到議程主題有稍做微調，成為「Simpler Application Management with Amazon ECS」。與原訂議程主題看似無關，但也帶出了 Application-First 的這個思考主軸。關於 Application-First 概念，可以延伸閱讀 CON325 - [NEW LAUNCH!] Enabling application-first thinking with Amazon ECS capacity providers 這個議程。
Overview
這場 CON312 由 Prasad Sristi 與 David Westbrook 主講。
Amazon 自家多個服務也都放在 Amazon ECS 上頭，包含這次 re:Invent Keynote 最搶佔鎂光燈焦點的 Amazon SageMaker 也運行在 Amazon ECS 之上。
這次 re:Invent 也在同一天發佈了 Amazon ECS 新支援 AWS Fargate Spot。也就是投影片中標示「New!」的那條線。
當 Applications 運行在 Amazon ECS 時，常有各種面向與細節需要考量、照顧。
但如果這些需求、場景、條件可以對應調配將我們的 Applications 運行在 EC2 Spot、EC2 On-demand、AWS Farget、AWS Fargate Spot 四種環境呢？
Capacity Providers
那就是時候來介紹 Capacity Providers 以及 Capacity Provider Strategies 出場了。
整個建立的過程是，逐步將 ECS Cluster、ASG、Capacity Provider 建立起來。以上三者都是一次性動作。
接著定義 ECS Tasks 並將之運行起來，然後會將 Instances 跑起來。
最後 ECS Tasks 會依照策略、條件於對應條件的 Instances 上頭運行。
Capacity Provider Strategies
接著介紹 Capacity Provider Strategies。基本款，使用權重做調配。David 也在 CON325 講解到 Capacity Provider Strategies 用來取代原本的 ECS Launch Types。
但可以玩出類似這樣的結果，將部份 ECS Tasks 運行在 Spot 上頭，以節省運行成本。（人生要先有理想跟目標…）
搭配 IAM policies 可以玩出更多限制條件，例如只可以運行在 Spot 上、拜託不要運行在第二個 CP 上之類。
Managed Auto Scaling
跟大部分全託管 (Managed) 服務的邏輯類似，目的是想讓大家專注在 Applications 的開發上，一些基礎設施的運營與安全就讓全託管來幫忙。（他講得越模糊，大家就越想問，所以這場 Chalk Talk 最後 Q&A 時，大家都在關心這個 auto scaling 對應的規則、反應速度/頻率等等。）
Live Demo
但是沒關係，這場 Chalk Talk 還帶來了 live demo！昨天（議程的前一天）剛 GA 的新功能，今天就來玩給大家看。
大家也可以參閱 CON325 的錄影檔，大約從 34:00 左右開始，也是相同由 David 帶來的 Live Demo 內容。
先來開一個 ASG，他一開始先設定 0 個 instance，等一下用來示範會跑起來 2 個 instances。（先開 ECS Cluster 或先開 ASG 都可以，待會建個 Capacity Provider 將兩者關聯起來即可。）
定義一個示範用的 ECS Service、ECS Task，剛一開始處在 PROVISIONING 狀態。
接下來應該是在等 ASG 接球的期間，先跳過來跟大家介紹對應 Capacity Provider 功能而新增的 CloudWatch Metrics AWS/ECS/ManagedScaling。
指標從 100 跳上去 200 了，可以來擴充 ASG 裡頭的 instances 數量了。
ASG 裡頭的 Desired 數量從 0 被 Managed Auto Scaling 修改成 2。
2 個 instances 被啟動之後，
ECS Task 也順利在這兩個 instances 上頭運行成功，狀態顯示為 RUNNING。
試著連線到這個 ECS Task，成功。很順利的一段 live demo。
討論
當天 Q&A 時，Amazon ECS Capacity Provider 功能僅能在 AWS Management Console 介面上進行操作，還未能於 ECS CLI v2、CloudFormation、CDK 等方式操作，但應該在 2020 年都會陸續跟上。大家後續可以追蹤 Github 上的這幾個 issues：
- roadmap: [ECS] Full support for Capacity Providers in CloudFormation.
- CDK: aws-ecs: support capacity provider #5471
- (20191227 更新) AWS CLI 有支援 Amazon ECS Capacity Provider 功能。若要在現有的 ECS Cluster 加入 Fargate Capacity Provider 目前只能透過 AWS CLI
aws ecs [put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)或 Amazon ECSPutClusterCapacityProvidersAPI。記得更新到最新版本 AWS CLI。（參考文件） - (20191227 更新) roadmap: [ECS] Add the ability to delete an ASG capacity provider.
- (20191227 更新) roadmap: [ECS] Support for updating parameters of an ASG capacity provider
- (20191227 更新) roadmap: [ECS] Full support for capacity providers in the ECS console
- (20200620 更新) New resource AWS::ECS::CapacityProvider was added in CloudFormation.
文章開頭提到的 Amazon ECS Cluster 維運很常遇到的一題就是更新 AMI ID，不論是自建 AMI 或是使用官方為 ECS 特調的 AMI，都會為了 ECS Container Agent 更新升級或是其它套件升級而需要更新 AMI ID。這個題目在 Capacity Provider 這一層推出之前，相當麻煩，連官方部落格都曾出現無法實際運用的教學內容（好在後來有一篇有修正），但現在有了 Capacity Provider，根本就是打中維運甜蜜點！
廢話不多說，AWS Principal Product Manager Nick Coult 直接畫圖給大家看：
Another use case for #ECS capacity providers, as drawn by me: seamlessly migrate your ECS cluster from one AMI to another by using capacity providers. To start, you have your service up and running using an ASG capacity provider. The ASG is using an old AMI. 1/n pic.twitter.com/Mm13MlfL0I
— Nick Coult (@nickcoult) December 9, 2019
關於
CapacityProviderReservation的計算（資料來源）：- We will be publishing a deep dive blog that covers how the metric is calculated, but the simple version of it is that
CapacityProviderReservation = M/N x 100, whereN = the number of instances already in your ASG, andM = the estimated number of instances required to run all existing and provisioning tasks. (A provisioning task is a task that was run using a capacity provider strategy and was assigned to a capacity provider that did not have sufficient capacity to run the task immediately. Tasks run using launch type will not reach this state). - If you have provisioning tasks assigned to that capacity provider then M>=1. If you have no provisioning tasks, then M=the number of instances running at least one non-daemon service task.
- Special cases:
- If N=0 and M>0, then CapacityProviderReservation = 200.
- If N=0 and M=0, then CapacityProviderReservation = 100.
- We will be publishing a deep dive blog that covers how the metric is calculated, but the simple version of it is that
延伸閱讀：ECS 相關議程
最後將 AWS re:Invent 2019 與 ECS 相關的議程整理成清單，大家可以用議程代號尋找對應的投影片或錄影，交叉參照。從議程代號 200、300、400 系列可以看出議程規劃的順序與邏輯脈絡。有些議程沒有錄影，可能是 Chalk Talk 或 Workshop 形式，這類議程應該可以找得到投影片 [2]。
- CON213 - Using containers & serverless to accelerate application development (youtube)
- CON217 - Roadmaps for containers, application networking & Amazon Linux at AWS (youtube) (slide)
- CON218 - How Amazon Lex uses Amazon ECS to process batches at scale (youtube) (slide)
- CON312 - [NEW LAUNCH!] Automatic cluster scaling with Amazon ECS (slide)
- CON313 - Life of your containerized application with new Amazon ECS CLI v2 (slide)
- CON324 - [NEW LAUNCH!] Cost Optimization with Containers and Spot (youtube) (slide)
- CON325 - [NEW LAUNCH!] Enabling application-first thinking with Amazon ECS capacity providers (youtube) (slide)
- CON328 - Improving observability of your containers (youtube) (slide)
- CON333 - Best practices for CI/CD using AWS Fargate and Amazon ECS (youtube)
- CON407 - CI/CD and deployment strategies for containers running on AWS
- CON423 - AWS Fargate under the hood (youtube) (slide)
備註
[1] 這在 AWS Container Roadmap (ECS, ECR, Fargate, and EKS) 上頭可以看到大家的關愛在哪些主題上。
[2] AWS Event Content re:Invent Slides 投影片下載點。