CATCHPLAY長期採用AWS服務,帶動SRE團隊成長 智慧應用 影音
DFORUM
EVmember

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


關鍵字
議題精選-數位轉型專網