CATCHPLAY長期採用AWS服務，帶動SRE團隊成長

創立於2006年的CATCHPLAY，是台灣一家經營影視發行及製作的公司，目前提供CATCHPLAY+線上影音，線上串流、影音媒體等服務。多年以來，CATCHPLAY歷經了不同階段的雲端佈建過程。

在CATCHPLAY負責率領SRE團隊Angus Lai指出，對於OTT業者來說，究竟雲端能提供什麼好處？他整理了幾個重點。第一是彈性的海量儲存空間；第二是高速的基礎網路。因為OTT平台上有大量媒體素材，所以不論是空間或網路，對業者來說都算是必要資源。第三是多樣的計算類型，意指能提供各種計算類型的機器，在搭配使用不同的服務上，可以擁有不同選擇。例如轉檔時可使用高CPU或GPU選項，一般服務則適用General類型。

再來第四是動態的服務資源。以OTT來說，流量的起伏與觀眾的生活作息息相關，因此在晚間會出現顛峰流量，不過到了半夜，通常只會有晚上峰值的1/4~1/3，故業者可善用資源的動態調配來節省可觀成本。第五是足夠好用的CDN，對OTT來說CDN至關重要，因為這部分會直接影響到成本結構。最後一點則是信賴度，當OTT服務Host在居於業界領頭羊的AWS雲平台時，更容易搏得夥伴的信賴。

Angus Lai表示，回顧CATCHPLAY最早採用AWS服務的時期，是從VM開始，當時是由RD人員手動部署與維護，使用的元件是Amazon EC2及RDS，缺點包括服務的機器上有各式手動殘留的痕跡，形同為後續維護的人製造「考古題」，若在必要時解題不成，就不見得能成功還原服務。

後來CATCHPLAY開始前進CI/CD，採用Ansible。當時服務已成長到大量使用AWS元件，此時已會使用到EC2、RDS、ELB、AWS ElasticCache for Redis、SES等，好處是部署出來的機器本身是乾淨的，也不必擔心重新部署失敗，在良好的實作下，基本上每次重複部署都能產生一樣的結果。至於為何不用AWS CodeDeploy？係因當時在部署機制上，不想與平台綁得太深。後期有不同程式語言實作的版本，需要做Layer 7 Routing，而當時AWS正好推出ALB，故選用ALB來執Layer 7 Routing任務。

在導入CI/CD後，雖達到部署自動化，但AWS上的服務仍靠手動設定，所以經常需要手動開VM，儘管AWS基礎架構的進入門檻變低了，但不代表可以忽略在雲平上複雜的網路與系統知識，所以必須多花時間閱讀雲平台提供的訓練資源，但很多時候仍會因不熟悉而使用錯誤資源、造成浪費。

到了下一階段，CATCHPLAY決定從手動部署朝向自動部署AWS元件，以揮別時間成本過高、手動配置導致結果不一致等缺憾。過去曾嘗試使用Config管理工具，但礙於很難用且缺乏狀態管理功能，於是導入IaC工Terraform，純粹是因為在雲端資源的管理上，Terraform比較簡單易用、也更貼近RD使用習慣所致。

選用ECS，建立容器協調機制

接下來往容器化前進，原因有二，一是有新版本服務實作，決定用容器來封裝；另一是為了縮短部署時間，在CI/CD完成後部署頻率變高，SRE每週都有服務要部署到Production環境。此時也面臨Orchestration的抉選擇，考量SRE單位較迷你，因而相中Amazon ECS簡單、小而美等特色，並加以採用。

大致上來說ECS具有三大好處，包括容易理解、容易部署、容易除錯。但CATCHPLAY不是透過原生部署方式來使用ECS，而是用ecs-cli，它是AWS提供的工具，簡單易整合，算是Compose相容的設定方式，對習慣Docker的人容易入手。目前此工具已有新版本，名為AWS Copilot CLI。

不過ECS仍有所欠缺，少了Service Discover、Configmap，再來就如何處理兩個獨立Scaling事件的機制(即服務的Scaling、Hosts的Scaling是分開的)，但前二者相對重要。對此Angus Lai採取一些解法，首先使用Route53加Internal ALB來做Service Routing，但衍生Multiple Target Group Register問題，自行以Lambda來加以解決。但後來ECS新增支援Service Discover，也支持Multiple Target Group Register。

針對ConfigMap部分，主要是CATCHPLAY有大量設定檔需求，用以切換不同環境，但ECS預設以環境變數來提供設定，維護上有些瑣碎，故最後決定使用S3來儲存。針對處理兩獨立Scaling事件，則引入第三方服務來代管Auto Scaling Group，讓Host能依Service需求來建立，SRE僅需專注在Service Level Scaling即可，也使Scaling Metrics更容易。

而目前ECS已開始提供類似功能，即是Capacity Provider。論及IaC與ECS完成後的好處，在於能夠快速產生全新環境；短時間內進行大量擴展，相較以前架構只縮減至只剩6分之1時間，效果顯而易見。