본 글은 Neflix Tech Blog의 Netflix Billing Migration to AWS 내용을 정리한 것이다.
넷플릭스에서 빌링 서비스와 같이 섬세한 처리가 요구되는 복잡한 시스템을 어떻게하면 IDC 환경에서 AWS로 마이그레이션 할 수 있을까에 대한 고민들과 그 접근 방식에 대해 정리한 글이다.
해당 내용을 보기 전에 그동안 넷플릭스가 지나온 클라우드로의 마이그레이션 내용을 간략히 살펴보자.
처음 넷플릭스가 AWS로 마이그레이션을 시작한 것은 2008년이다. 그로부터 정확히 7년 뒤, 2015년에 빌링과 회원 서비스를 제외한 대부분의 시스템에 대한 마이그레이션을 완료했다.
그 7년 동안 넷플릭스는 회원 수 8배, 전체 시청률 3배가 증가하였다. 또한 몇 분 안에 수천개의 가상 서버와 PB 규모의 스토리지를 추가할 수 있는 확장성으로 2016년 전세계 130개 이상의 국가에게 넷플릭스 서비스를 제공할 수 있게 되었다.
넷플릭스에서는 비즈니스 로직, DB, 빅데이터 처리/분석, 트랜스코딩 등 기타 수백가지 기능을 모두 클라우드에 의존하며 네트워크는 자체 Open Connect를 사용한다.
비용 절감이 클라우드로 전환하기로 결정한 주된 이유는 아니지만 실제 클라우드 비용은 IDC 비용의 일부에 불과하였고 경제적인 이점을 가질 수 있었다.
사실 클라우드로 이전하는 가장 쉬운 방법은 IDC 환경의 모든 시스템을 그대로 클라우드로 올리는 것임에 틀림없다. 하지만 그렇게되면 IDC의 모든 문제와 제한 사항도 함께 가져가는 것이었기에 넷플릭스에서는 거의 모든 기술을 재구축하고 회사의 운영 방식을 근본적으로 바꾸는 클라우드 네이티브 방식을 채택하였다.
아키텍처적으로 NoSQL DB를 사용하여 수백개의 마이크로 서비스로 마이그레이션하고 데이터 모델을 비정규화했다. 여러 팀들과 협력하고 프로비저닝 주기가 지속적으로 바뀌는 등 많은 변화가 있었지만 새로운 기술을 배우고 새로운 시스템을 구축함으로써 넷플릭스는 현재 보다 나은 위치에 있게 되었다.
빌링 인프라는 넷플릭스 회원의 청구 상태를 관리하는 책임을 진다.
마이그레이션 이전에 빌링 시스템에는 IDC와 클라우드 시스템이 통합되어 있었고 아래와 같이 구성되어 있었다.
위 구조를 보면 얼마나 많은 코드와 데이터가 오라클과 연관되어 있는지 알 수 있다. 따라서 첫번째 목표는 오라클 의존적인 아키텍처를 서비스 기반 아키텍처로 분해하는 것이었다.
일부 API는 다중 영역이어야 하며 가용성이 높았기 때문에 데이터 저장소를 아래와 같이 여러개로 분할하기로 결정했다. 먼저 가입자 관련 데이터는 카산드라로 마이그레이션했고 빌링 처리 작업은 ACID 거래가 필요했기에 MYSQL로 마이그레이션 했다.
Netflix가 새로운 국가에서 출시되면서 많은 어려움을 겪었지만 레거시가 아닌 새롭고 깨끗한 데이터로 클라우드 인프라를 테스트할 수 있는 기회를 얻을 수 있었다.
이를 통해 클라우드에서 모든 사용자 대면 서비스와 배치 프로세스의 경량 버전을 만들 수 있었고 새로운 빌링 인프라를 만들어 빌링 워크플로우를 완료할 수 있었다.
새로운 국가에서 클라우드로의 서비스 제공을 성공적으로 처리할 수 있게 되면서 기존 대형 레거시 국가, 특히 미국에서의 클라우드 마이그레이션 역시 수행할 수 있다는 확신을 얻을 수 있었다.
기존 멤버의 데이터를 카산드라로 마이그레이션하는 동안 해당 데이터의 사용자에 대한 서비스가 중단되는 시간이 발생했다. 이를 위해 아래와 같은 작업을 선행했다
데이터베이스의 이전은 최종 목표를 항상 생각하며 계획해야 한다. 스토리지 예측에 필요한 최소 1년 분량의 성장, 생산 및 테스트 환경 모두에 대한 라이센스 비용, 대규모 EC2 인스턴스 관리, DB 아키텍처가 데이터의 확장성, 가용성 및 안정성을 해결할 수 있는 많은 결정이 있다.
마이그레이션의 일환으로 데이터베이스를 라이센스가 필요한 오라클에서 오픈소스 MYSQL로 변경하였다.
TB 데이터 마이그레이션
구독 시스템이 카산드라를 사용하는 동안 빌링 프로세스는 트랜잭션 처리를 위해 RDBMS가 필요했다. 또한 TB 제한이 있는 AWS RDS에 맞지 않게 이미 다중 TB 데이터베이스를 가지고 있었다.
MYSQL 마스터를 위한 다중 리전, 확장 가능한 아키텍처를 정의했고 마스터의 리소스 경합을 피하기 위해 모든 ETL 처리를 복제본으로 옮겼다. 필요에 따라 모니터링 및 복구를 보장하기 위해 MYSQL 인스턴스에 대한 툴링 및 Alert 시스템을 구축했다.
무중단 데이터 마이그레이션
많은 옵션을 탐색하던 중 오라클 GoldenGate를 진행하여 다른 DB에 테이블을 복제할 수 있었으며 지속적인 변경도 병행해서 진행하였다.
이 과정은 매우 큰 데이터의 이동이었으며 몇달동안 운영과 마이그레이션을 병렬로 실행했다.
MYSQL로의 완전히 이전하기 몇 주전에 MYSQL에서 테스트 DB를 실행했고 ORACLE 데이터와의 최종 유효성 검사를 수행하고 MYSQL 코드 분기에서 발생하는 모든 문제를 수정하고 테스트했다.
클라우드로의 마이그레이션은 전체적으로 원활했지만 뒤돌아보면 더 잘 할 수 있었던 몇 가지 일들이 있다. 그 중 대표적인 것이 테스트 자동화 요구사항이다. end to end 테스트에 대한 보다 나은 방법이 없었는데 이러한 측면에서 더 노력을 기울였다면 개발 속도가 향상됐을 것이라고 생각한다.
마이그레이션 후 여러 이점이 많지만 하나는 소프트웨어가 이전보다 효율적이고 가벼워졌다는 것이다. 또한 마이그레이션 하면서 작성한 여러 검증 툴 및 모니터링 툴들은 운영 환경에서도 도움이 되었다.
클라우드로 이전하면서 넷플릭스는 혁신을 통한 서비스 향상의 다양한 기회가 생겼고 글로벌 진출에 발판을 마련할 수 있었다. 앞으로 넷플릭스는 보다 효율적이고 글로벌 대규모 가입자를 위한 플랫폼을 재설계하기 위한 다음 스텝을 준비중이다.