Netflix의 선택

실력이라는 것은 평가하는 기준에 따라 달라집니다. 요리를 잘하는 두 사람을 예로 들어 설명해 보겠습니다. A라는 사람은 최상의 요리를 만듭니다. 그러나 한 번에 소수의 사람만 먹을 수 있을 정도의 양만 만들 수 있습니다. B라는 사람은 최상의 맛은 아니더라도 맛있는 한 끼로 손색없는 요리를 만듭니다. 그리고 한 번에 만들 수 있는 양도 수백 명이 먹을 수 있을 정도로 많습니다. A와 B의 경우 요리 실력이 더 뛰어난 사람은 누구일까요? 맛이 기준이라면 A이겠지만 많은 손님을 대접해야 하는 상황이라면 B일 것입니다. 따라서 특별한 한두 명의 손님을 대접해야 하는 경우는 A를 요리사로 선택하겠지만 수백 명의 하객을 대접해야 한다면 B를 선택할 것입니다. 이처럼 상황은 선택에 영향을 미칩니다.

Netflix를 이용하지는 않더라도 Netflix를 모르는 분들은 없을 겁니다. 2019년 기준으로 Netflix는 190여 개 나라에서 1억 5천 백만 명의 이용자를 거느리는 거대 기업입니다. Netflix가 처음부터 스트리밍 영화 서비스를 한 것은 아닙니다. 1997년 8월에 Netflix를 창업했을 당시의 비즈니스 모델은 DVD 대여업이었습니다. 물론 DVD 대여를 온라인으로 하는 것이 기존 방식과 달랐던 것입니다. 그러나 Netflix는 2007년에 영화와 드라마를 스트리밍으로 볼 수 있는 서비스를 선보입니다. 이제 Netflix는 거대 스케일을 다루는 능력이 사업의 성패를 좌우할 수 있음을 깨닫습니다.

Netflix는 2007년에 "Watch Now" 서비스를 시작하면서 데이터에 관심을 갖습니다. 고객이 남기는 흔적들을 모두 데이터로 모으기 시작합니다. 고객이 본 영화가 무엇인지 얼마나 오랫동안 봤는지 등등 고객의 행동을 모두 데이터로 기록하였습니다. 그러한 데이터를 모두 오라클이라는 데이터베이스에 저장하였습니다. 오라클은 이 책을 집필 중인 2020년 현재에도 여전히 DB-Engines Ranking 사이트에서 부동의 1위를 지키고 있습니다. 오랜 시간 성능이 증명되었고 그만큼 많은 사용자의 신뢰를 받고 있습니다. Netflix가 데이터 저장소로 오라클을 선택한 것도 그러한 신뢰가 있었기 때문입니다. 그런데 Netflix의 규모가 급속도로 성장하면서 오라클은 Netflix의 요구를 충족시키는 데 한계를 드러냅니다.

2010년에 Netflix는 AWS(Amazon Web Services) 클라우드 기반으로 서비스를 전환합니다. 당시 Netflix의 트래픽은 급속도로 증가하였고 오라클은 그러한 규모를 감당할 수 없을 정도가 됩니다. 문제는 트래픽만이 아니었습니다. 오라클이 설치된 서버의 위치가 잠재 위험으로 지적되었습니다. 즉, 같은 위치의 서버에 장애가 발생하면 Netflix의 서비스가 중단되는 위험을 안고 있었습니다. 이것을 single point of failure 라고 합니다. 쉽게 설명하면 삼각대의 다리 중 하나가 부러지면 삼각대가 쓰러지는 상황입니다. 이 외에도 Netflix는 오라클이 가진 특성이 Netflix 서비스와는 맞지 않는다는 것을 알게 됩니다. 그래서 대안을 찾습니다.

Netflix가 Apache Cassandra를 선택한 이유는 크게 다음의 두 가지 조건을 충족했기 때문입니다.

· Scalability
· No Single Point Of Failure

Scalability는 데이터의 양이 증가하면 데이터베이스의 성능도 향상되는 것을 말합니다. 이것은 서버의 증설이 전통적인 관계형 데이터베이스보다 매우 쉽게 이루어지기 때문에 가능한 것입니다. No Single Point Of Failure는 서버의 일부가 중단되더라도 Netflix 서비스는 계속된다는 것입니다. 서비스가 글로벌화 되면서 Scalability와 No Single Point Of Failure는 데이터베이스를 선택하는 중요한 기준이 되었습니다. 즉, 실력을 평가하는 기준이 달라진 것입니다.