[왓챠] 왓챠는 왜 쿠버네티스를 선택하였을까?

오늘은 OTT 시장과 관련된 기업에 대한 포스팅을 진행하려 합니다.

 

그 이유는 다음과 같습니다.

• OTT 시장의 춘추전국시대(넷플릭스, 웨이브, 티빙, U+모바일tv, 왓챠, 쿠팡 플레이, ... 등등0)
• 국내 OTT 시장을 장악하고 있는 넷플릭스의 한국에만 5500억 대규모 투자
• 디즈니플러스 한국 OTT 시장 진출(구독자 1억명 돌파한 대규모 플랫폼)

 

• http://apnews.kr/View.aspx?No=2126893 

[OTT뉴스] 글로벌 OTT 시장 규모 2030년까지 '329조 성장' 예측

• https://www.mk.co.kr/news/economy/view/2021/10/966037/

글로벌 OTT 1위 넷플릭스-기대작 줄줄이 출격…게임·팟캐 신사업 기대

• https://m.etnews.com/20211025000131

디즈니플러스, 11월 한반도 상륙…OTT 시장 지각변동 일으킬까

 

이처럼 OTT 시장은 말 그대로 춘추전국시대를 겪고 있으며, 국내 OTT 시장의 각춘전에서 누가 승리하게 될지 국내 고객들의 이목을 끌고 있습니다. 

 

그 중에서 오늘 저는 왓챠라는 기업에서 OTT 시장에서 살아남기 위해, 서비스 품질을 높이기 위해 어떤 클라우드 기술들을 다루고 있는지에 알아보고 공부해보려 합니다.

https://www.jobplanet.co.kr/contents/news-1492

넷플릭스・디즈니 공세 속 왓챠의 전략은?

 

 

왓챠 팀 블로그

https://medium.com/watcha/watcha-k8s-%EC%A0%84%ED%99%98-part-1-3ac7193d04d7

WATCHA K8S 전환 -PART 1

해당 글은 왓챠 팀 기술 블로그를 참고하여 작성하였습니다.

(서버 및 인프라 시니어 개발자들이 모여 21년 한 해의 목표를 그리며 시작하게 되었다고 합니다.)

 

해당 포스팅의 말을 빌려 왜 왓챠는 쿠버네티스로 인프라를 바꾸었는지에 대해 말씀드리겠습니다.

현재 폭발적으로 사용자가 증가하고 있다.
게다가 추가적으로 진행될 서비스들이 준비되어 있어 MSA가 더욱 가속화 될 것이다.
그것에 맞추어 서비스 인프라를 Kubernetes 기반으로 이전하자.

왜 쿠버네티스 일까요?

이전 왓챠 서버/인프라 구조

• AWS EC2 직접 운영
• Elastic Beanstalk를 이용한 EC2, ECS 기반 운영

쿠버네티스를 도입함으로써 얻을 수 있는 이점

• 서비스 개발자들이 인프라 담당자의 지원 없이도 손쉽게 원하는 자원을 이용하여 서버를 운영할 수 있음
• 서비스 서버에 배포 및 설정을 한곳에 모으기 용이함(코드 또는 yaml로 관리)
• 빠른 배포
• 자원을 효율적으로 이요할 수 있음

단점

• 운영 관리의 어려움
• 사용하기 어려움
• 진입장벽이 높음

그럼에도 불구하고, 쿠버네티스를 도입하는 이유는 단점보다 장점이 더욱 크기 때문에 많은 IT 기업에서 쿠버네티스로 이전하고 있고, 왓챠 또한 쿠버네티스로 이전하는 것으로 결정하게 되었다고 합니다.

 

EKS? GKE?

왓챠에서는 AWS && GCP 모두 운영하고 있었다고 하는데요. 따라서 EKS와 GKE 모두 검토 대상이었습니다.

 

결론적으로, EKS를 고려하게 되었습니다. 그 이유는 다음과 같습니다.

• 왓챠는 대부분의 주요 리소스들이 AWS에 종속된 상황이었기에 GKE를 사용하게 되면 사이드이펙트가 우려되어 고려 대상에서 제외
• Google Anthos를 이용하여 AWS에서 쿠버네티스를 운영하는 방안도 가능하지만, 적용 사례를 찾아볼 수 없고 사이드이펙트가 발생할 수 있음

 

EKS NodeGroup? EKS Fargate?

EKS에서 노드들을 운영하는 방법

• NodeGroup
  EC2를 사내 인프라 관리자들이 업데이트 및 관리
• Fargate
  EC2를 AWS에서 직접 업데이트 및 관리

 

왓챠 EKS 인프라 구조

사용 기술 스택

• Fluent-Bit
• DataDog
• App Mesh
• Gloo Edge

 

왓챠 GitOps 구조

사용 기술 스택

• HELM
• CircleCI
• Github Action
• ArgoCD

 

왓챠 쿠버네티스 Pod 내 Container 구조도

각 서비스 별로 차이는 있지만, 왓챠에서 일반적으로 Pod 내에 구동되는 Container 들은 위 그림과 같습니다.

 

보통 Sidecar Container로 Fluent-Bit, DataDog Agent, Envoy(App Mesh) 3개의 컨테이너가 뜨게 됩니다.

Envoy(App Mesh) 역할

• inbound, outbound 트래픽 제어
• APP 서버에서 일시적으로 에러 발생시, Retry && Timeout 기능 제공
• 장애 상황에 대비하여 Circuit Breaker && Rate Limit 기능 제공

DataDog Agent 역할

• App에서 발생하는 다양한 metric을 App 코드의 큰 변경없이도 손쉽게 수집 가능
• Opentracing && Opentelemetry 를 기반으로 데이터를 수집하여 손쉽게 APM을 사용할 수 있도록 해줌
• metric을 통합하여 서비스 간의 관계를 UI로 확인 가능
• 장애 대응 및 분석에 용이

Fluent-Bit 역할

• App에서 발생하는 RAW한 로그를 수집하여 왓챠 로그 플랫폼으로 전송
• 수집된 로그는 BigQuery에 저장되어 데이터 분석에 활용함

 

---

https://medium.com/watcha/watcha-k8s-%EC%A0%84%ED%99%98-part-2-caea323da57d

WATCHA K8S 전환 -PART 2

쿠버네티스로 전환 시 왜 API Gateway에 신경을 써야하는 걸까요?

API Gateway의 유무에 따른 차이점

API Gateway를 사용해야하는 이유

• MSA 구조로의 변화 -> 큰 서비스들이 여러 개의 작은 서비스로 분리
• 분리된 서비스들이 클라이언트를 통해 직접 호출한다면? -> 각 서비스별로 Endpoint와 인증 및 권한 관리를 해야하는 어려움이 있음(비효율적)
• 보안의 취약점(클라이언트와 통신하며 외부로 시스템을 노출시키기 때문임)
• 인증 및 권한 관리, 라우팅 및 로드밸런싱, 보안, Rate Limit, Circuit Breaker 등 다양한 기능 활용

단점

• SPOF(Single Point Of Failure) -> 적절한 Fallback 또는 장애 대응 프로세스가 필요함.

 

API Gateway 선택 과정

후보 API Gateway

• Kong
• Tyk
• Gloo Edge
• KrakenD
• apigee
• ZUUL

왓챠는 이러한 API Gateway 중에서 Gloo Edge를 선택하였습니다. 그 이유는 다음과 같습니다.

• CRD 지원
• Envoy 기반
• Golang 기반
• 귀여운 아이콘... 총총(아이콘을 확인해봤는데 정말 귀엽더라고요 ㅎㅎ)

 

왓챠의 Gloo Edge를 이용한 인프라 구조

• Proxy
• Monitoring
• Logging
• 라우팅 및 옵션

 

Future Blueprint

왓챠에서 Gloo Edge를 API Gateway로 선택한 이유는 앞으로 가고자하는 방향에 부합했기 때문에 선택했다고 합니다.

왓챠의 앞으로의 계획

• Envoy 앞단에 다양한 필터를 배포하여 실제 요청이 각 MSA 서비스에 전달되기 전에, 전처리 작업을 진행할 것임

ex.

예를 들면 실제 서비스에 전달 되기전에 어뷰징 체크 및 웹 방화벽 같은 역할을 하는 Envoy Filter를 개발하여서 서비스 안정성을 높힐수 있고, 외부에 노출 되는 인증 토큰과 내부에서 사용하는 인증 토큰을 분리하여 보안에 좀더 신경 쓰고, 내부 MSA 기반 서비스들을 내부 인증 토큰 통합하여서 인증에 큰 신경쓰지 않아도 MSA 서비스를 손쉽게 늘려 나갈수 있도록 할수 있습니다.

참고로 Envoy 에서는 기본으로 지원하는 여러 Filter 를 활용 할수 있고, 뿐만아니라 WASM 기반으로 Filter 개발을 지원하기 때문에 사용하는 언어에 제한없이 개발할 수 있는 장점이 있어서 개발자 익숙한 언어로 빠르게 Filter 들을 개발할 수 있습니다.

 

---

추후, 관련 기술 스택들에 대한 포스팅과 더불어 글을 더욱 풍부하게 만들어오겠습니다.

부족한 글 끝까지 읽어주셔서 감사합니다.