TVING 사례로 본 AWS 인프라를 이용한 글로벌 비즈니스 확장 기반 마련하기

비즈니스 배경

TVING은 ‘NO.1 K-콘텐츠 플랫폼’이라는 목표 아래 다양한 콘텐츠를 수급 또는 직접 제작하는 콘텐츠 기업이자 D2C 서비스를 제공하는 종합 엔터테이먼트 플랫폼입니다. 실시간 TV, 방송 VOD, 영화는 물론 분데스리가, 국내 프로야구, AFC, UFC 등 다양한 스포츠 콘텐츠 그리고, TVING 오리지널 콘텐츠까지 제공합니다.

2010년 5월 CJ헬로비전에서 출시된 TVING은 2020년 독립회사로 출범하였습니다. 국내 최초 MAU(Monthly Active Users) 500만을 돌파하였고 현재는 월평균 530만, 일평균 120만 활성 사용자들이 TVING을 이용하고 있습니다.

순간적인 트래픽 대응, 사용자에게 더 나은 서비스 경험 제공, 나아가 글로벌 비즈니스 확장 기반 마련을 위해 TVING은 기존의 온프레미스 기반의 인프라에서 클라우드로 전환을 결정했습니다.

글로벌 비즈니스 확장의 장애물

글로벌 비즈니스 확장을 위한 TVING의 여정이 순탄치만은 않았습니다. 2010년부터 쌓인 기술부채, 낮은 민첩성, 비효율적인 개발 등의 장애물이 있었고 무엇보다 기존의 온프레미스 기반 인프라에서 한계가 분명했습니다.

온프레미스의 환경에서는 장비 증설을 위해서 견적, 구매, 발주 등의 프로세스가 필요했기 때문에 환경 변화에 빠르고 유연하게 대처하기 어려웠습니다. 또한, 국내 IDC 환경으로는 생산 효율적인 개발 환경을 위해 최신 기술을 적용하기 어려웠을 뿐만 아니라, 글로벌 인프라 환경을 준비하는 과정에서 느린 응답속도 등 문제점들이 나타나기 시작했습니다.

IDC의 제한된 확장성과 환경 변화에 대해 적응하기 어려운 점에 대한 해결 방안으로서 클라우드 전환 필요성이 대두되었습니다.

글로벌 비즈니스 확장 기반 마련을 위한 AWS 솔루션

AWS Control Tower

초기 2, 3 개 워크로드를 관리하는 것은 어렵지 않았지만, 점점 추가되는 워크로드에 대해 계정/권한/네트워크를 관리하는 것은 많은 노력이 필요했습니다. 이러한 노력을 최소화하고 다른 업무에 시간을 활용하기 위해서 AWS Control Tower를 도입하였습니다.

AWS Control Tower 적용을 위해 워크로드를 재정의 했습니다. OU(Organizational Units)에는 Amazon Route53, 사용자 계정 등 공통적으로 사용 관리하는 리소스, 네트워크는 AWS Transit Gateway와 Amazon VPC 관련 리소스, 보안 OU에는 로그 아카이브 및 감사를 위한 리소스, 티어/서비스별 워크로드, 마지막으로 서비스 테스트나 POC 등 언제든 생성하거나 삭제할 수 있는 샌드박스 워크로드를 구성했습니다. 이렇게 구성한 OU 표준화를 진행하였고 워크로드별 정책 배포 틀을 마련했습니다.

[그림 1. 워크로드 정의]

AWS Control Tower를 도입함으로써 멀티 어카운트 관리가 용이해졌습니다. SCP 정책의 중앙 관리가 가능해졌고,  AWS IAM Identity Center를 통해 계정 생성이나 관리 등을 위한 Landing Zone도 구성할 수 있게 되었습니다. SSO를 통해 서드파티 솔루션 계정에 연동이 가능해진 점도 IAM Identity Center 도입에 따른 추가적인 이점이었습니다. 현재 SSO를 통해 AWS VPN, Amazon Managed Grafana(AMG)뿐만 아니라 Datadog 계정까지 관리하고 있습니다.

AWS Transit Gateway와 AWS Direct Connect(DX)

워크로드의 증가는 계정뿐만 아니라 네트워크 복잡성도 초래하였습니다. VPC Peering을 사용할 때, 새로운 워크로드별 VPC가 추가되면서 East-West 통신이 필요해집니다. 이 경우 각 계정은 VPC Peering을 통해 풀 메쉬(Full Mesh) 구조의 네트워크 설정을 해야 합니다. 이로 인해 관리가 복잡해지는 문제가 있습니다. 따라서,  AWS Transit Gateway를 도입하여 East-West 통신 관리를 단순화하였습니다.

[그림 2. 트래픽 네트워크 단순화]

초기에는 IDC와의 비동기 통신이 대부분이었기 때문에 Active-Standby 구성을 사용하였지만 서비스가 확장되며 비동기 통신이나 AWS-IDC 간 트래픽이 점점 증가하면서 Site-to-Site VPN의 설정을 BGP-ECMP로 변경하여 Active-Active로 운영하였습니다. 이에 따라 추가 설정하는 인터페이스 마다 대역폭을 늘릴 수 있게 되었고 안정성도 높아지게 되었습니다.

이후 비즈니스가 확장됨에 따라 API 간 통신 및 Amazon Managed Streaming for Apache Kafka(MSK)의 MSK Connect를 통한 Change Data Capture(CDC) 데이터 동기화 통신이 증가하였고 VPN보다 안정적인 통신이 필요하여 AWS Direct Connect(DX)로 전환하게 되었습니다.

AWS Fargate

내부 서비스들은 Amazon ECS와  AWS Fargate 기반으로 구성했습니다. 서버리스 아키텍처로 구성하여 관리를 최소화하고 러닝 커브를 낮춰 개발 효율성을 향상시켰습니다. 특정 메트릭 기준으로 API 서버들을 오토 스케일링하였고, 피크 시간대 오토 스케일링을 통해 확장성, 유연성과 탄력성을 갖출 수 있었습니다. 또한 중요한 설정 정보들은 AWS Systems Manager Parameter Store와 AWS Secrets Manager로 관리하여 안정성과 멱등성도 갖출 수 있었습니다.

AWS Fargate에 대한 모니터링은 다음과 같이 진행했습니다. AWS Disto for OpenTelemetry(ADOT)를 통해 메트릭을 수집해서 Amazon Managed Service for Prometheus(AMP)에 저장하였고, Fluentbit를 통해 로그를 Datadog과 내부 Elasticsearch에 저장하였습니다. AMP 및 Elasticsearch는 AMG 대시보드를 통해 확인하였고, Datadog 사이드카를 통해 애플리케이션 모니터링[1]을 진행하였습니다

Fargate는 container 이미지가 캐싱이 되지 않기 때문에 기존 JAVA기반으로 개발된 이미지를 jdeps와, jlink를 통해서 경량화하였습니다. 결과적으로 서비스에 투입되는 속도가 65% 개선되었습니다.[2] Amazon ECS에서 openfile 및 프로세스에 대한 ulimit 설정이 가능한데, 해당 부분 값을 적절히 수정하였습니다. 2023년 8월부터는 Fargate를 사용하여 network 관련 커널 파라미터 수정이 가능하게 되었기 때문에 기존 OS에서 적용했던 내용들을 그대로 활용할 수 있었습니다.

[1] ‘TVING 사례로 본 AWS ECS를 이용한 대용량 트래픽 처리하기’에서 별도 상술합니다.
[2] 자세한 내용은 이 링크를 참고하시기 바랍니다.

[그림 3. jdeps, jlink를 통한 JAVA 이미지 경량화]

이렇게 구성된 서비스는 확장성 개선 뿐만 아니라 배포 시간을 줄이는 효과도 있었습니다. 기존에는 롤링 업데이트로 최대 1시간이 소요되었습니다. GitHub Action 또는 젠킨스를 활용해서 블루/그린 배포로 진행하였고, 기존 1시간이었던 배포 속도는 빌드/배포 시간을 포함하여 5분 안에 완료할 수 있게 되었습니다. 또한 기존에는 서비스 롤백 시에도 재배포를 실행했기 때문에 똑같이 1시간이 소요되었지만 현재는 블루/그린 배포 혹은 이미지 태깅을 수정해서 롤백하기 때문에 1~2분 내에 완료할 수 있게 되었습니다.

AWS Korea Professional Services (ProServe)

AWS Korea ProServe는 위에서 설명한 AWS Control Tower, AWS Transit Gateway, AWS Direct Connect, AWS Fargate 등 AWS 솔루션을 TVING에 적용하기 위한 아키텍처 분석과 설계부터 실 적용까지 모든 과정에 함께하였습니다.

TVING에서는 modernization 로드맵을 자체적으로 수립한 상태였습니다. AWS Korea ProServe는 직접적인 AWS 솔루션 뿐만 아니라 (AWS 솔루션과 연계된) TVING 자체 로드맵을 문제 없이 진행하는 것에도 큰 도움을 주었습니다.

기존 레거시 백엔드 시스템의 경우 ‘코어 모듈 기반 모놀리식 아키텍처’로 구성되어 있었는데, 이러한 아키텍처에서는 각각 제공되는 모듈을 가지고 필요한 인터페이스만 재정의하여 어플리케이션을 만들 수 있었습니다. 레거시 개발 당시에 비해 현재 비즈니스 환경에서는 확장성, 변경 용이성, 배포 효율성에서 문제가 있었습니다.

이를 개선하기 위해 TVING의 modernization 로드맵에서는 백오피스와 콘텐츠 시스템의 개선과 이를 사용하는 API에 대한 신규 구축을 목표로 하였고 먼저 BFF(Backend for Frontend) 아키텍처를 적용한 API를 7월에 선 오픈하였습니다.

TVING 레거시에서는 각 콘텐츠 띠별로 서로 다른 API를 호출하여 화면을 구성합니다. 만약 백오피스에서 30 개의 띠를 편성하게 되면 TVING 프론트는 홈에서 30 개의 API를 호출하여 화면을 구성하던 것입니다. BFF 아키텍처에서는 프론트에서 각각의 API를 호출하지 않고, 중간에 BFF 서버를 두어서 화면에 필요한 API를 모두 조합하여 하나의 API로 제공하도록 개선하였습니다.

BFF 적용 후 약 30% 속도가 향상되었고 앱에서 홈 전체 기준으로 데이터 크기도 95% 정도 감소되어 줄어든 메모리 사용률만큼 더 안정적인 서비스를 제공할 수 있게 되었습니다. AWS Korea ProServe는 BFF 성능 테스트 등 기술적인 부분은 물론 일하는 방식 공유를 통해 TVING이 modernization 로드맵 전 과정에서 AWS를 효과적으로 활용할 수 있도록 도와주었습니다.

효과 및 Next Step

TVING은 AWS 솔루션을 도입하여 글로벌 비즈니스 확장 기반을 마련할 수 있었습니다.

가까운 사례로서 지난 2023년 8월 ‘UFC 정찬성 할로웨이 경기’ 때 지난 2022년 ‘환승연애’ 서비스 때만큼 사용자가 유입되었지만, 지연 없이 서비스할 수 있었습니다. TVING이 AWS 솔루션을 도입하여 얻은 효과를 요약하면 아래와 같습니다.

• Operational Resilience

AWS Fargate 기반으로 서버리스 아키텍처로 구성하여 특정 메트릭 기준으로 오토 스케일링 하였습니다. 이와 더불어 주기적으로 트래픽 이 급증하는 오후 10시 이후 스케줄에 따른 스케일 아웃 및 스케일 인 처리를 통해 인프라 자원을 유연하고 효율적으로 운용할 수 있게 되었습니다.

AWS Transit Gateway를 통해서 통신 관리를 단순화할 수 있었고 AWS Direct Connect(DX) 전환을 통해 서비스 안정성을 확보할 수 있었습니다.

Application 캐싱 외에도 Amazon CloudFront의 캐싱 처리도 가능하게 되어 기능 또는 화면 구성에 따라 목적에 맞는 다양한 캐싱 전략도 사용할 수 있게 되었습니다.

• Staff Productivity

AWS Control Tower를 도입함으로써 추가되는 워크로드에 대해 계정/권한/네트워크 관리 노력을 최소화하고 다른 업무 시간을 확보할 수 있었습니다.

또한, 블루/그린 형태의 배포 프로세스를 적용하여 배포 및 롤백에 필요한 시간을 크게 감소시킬 수 있었습니다. 이것은 물론 resilience 측면의 개선으로도 볼 수 있습니다.

• Business Agility

AWS Korea ProServe와 함께 TVING의 글로벌 비즈니스 확장을 위한 modernization 로드맵의 첫걸음을 성공적으로 뗄 수 있었습니다.

TVING은 아직까지 온전한 AWS 클라우드 전환을 하지는 못했습니다. 향후 클라우드 100% 전환을 목표로 나아가, Disaster Recovery 구축과 FinOps 전략까지 준비 중에 있습니다.

작성자 소개