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时间，效果显而易见。