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 時間，效果顯而易見。