“넷플릭스(Netflix)” 2011년 6월 경 사용하던 Oracle 을 버리고 AWS 환경에 구성된 Cassandra (no SQL) 전환

“넷플릭스(Netflix)”[1] 는 2011년 6월 경 사용하던 Oracle 을 버리고 AWS 환경에 구성된 Cassandra Cluster 를 이용하기로 계획했습니다. 그 당시 그들이 마주한 상황은 다음과 같습니다.

  • 미국, 캐나다에서 2천 3백만 이용자가 존재
  • 시장의 글로벌화 (2011년 하반기에 새로운 시장이 추가될 예정이며 2012에도 확장을 계획)

시장의 확대를 위해 글로벌을 지향하고 있다는 점이 중요한 포인트 입니다.

사실 넷플릭스는 2011 년 초 기존 Oracle 의 한계를 극복하기 위해 Amazon Simple DB, Hadoop/HBase, Cassandra 등을 검토합니다. 하나의 DBMS 통해 모든 문제를 해결 하는게 아니라 관점을 달리하여 필요에 의해 NoSQL 개별적 특수성과 그에 따른 효율성에 근거한 선택, 그리고 그것의 정착을 위한 노력을 하게 됩니다.

6개월 동안 넷플릭스는 Apache 그룹의 Cassandra 를 적용하기 위해 테스트를 진행하였고 이 문서는 그 결과와 그에 따른 시사점을 다루고 있습니다.

테스트 결과 (Cassandra 클러스터의 선형적 Scale-up)


테스트 환경 구성은 총 66분 동안 진행되었으며 이중 EC2 가 288개의 instance 를 만드는데 약 15분이 걸렸고 리눅스를 부팅, 테스트를 위한 자동화 도구가 올라갈 Apache Tomcat JVM 실행, Cassandra 를 실행, Cassandra Cluster Ring 에 조인 후 전체 클러스터(관련해서는 제가 예전에 개발자 블로그에 적어드린 글 “Cassandra DBMS 에 대하여” 를 참고하세요)가 구성되는데 나머지 시간이 소요됨

선형성(linearity)이라는 것, 개발자들은 익숙하지만 일반적으로는 익숙한 단어가 아닐 것입니다. 쉽게 말하면 한 버스에 45명이 탄다고 했을 때 2대는 90명, 3대는 135명이 타게 됩니다. 즉 버스 대수만큼 수용할 수 있는 사람도 비례하여 늘어납니다. 이럴 때 선형성을 가진다고 하게 되는데요. Cassandra 클러스터의 경우도 노드 수에 비례하여 처리량, 저장할 수 있는 데이터의 크기가 늘어나는 것을 목표로 하고 있습니다. 이번 넷플릭스가 AWS 환경에서 테스트 한 것도 이와 같은 특징을 보이고 있습니다.

<노드 수에 따른 처리량의 변화 그래프>

위는 Netflix 가 테스트한 결과 입니다. Y 축은 초당 처리량, X 축은 노드 수 입니다. 보시다시피 일정하게 증가하고 있으며 한 노드당 약 3500 writes/s 를 처리하고 있습니다.(이때 클라이언트는 200 개의 threads 로 동시에 throughput 을 만듬)

넷플릭스가 AWS 를 사용하며 배운 5가지 교훈

5 Lessons We’ve Learned Using AWS
지난 포스트에서는 넷플릭스가 컴퓨팅 플랫폼으로 AWS 를 선택한 이유를 소개드렸습니다. 이제, 기존에 사용하던 데이타센터에서 AWS 로 옮겨간지 이제 1년 정도 시간이 지났군요. 그 동안 넷플릭스는 많은 교훈을 배웠습니다. 그 중에 여러분에게 도움이 될만한 이야기들을 조금 해보려고 합니다.
1. 도로시, 여기는 너의 시골 농장이 아니야. 회오리 바람이 너를 오즈로 날려 버렸단다.
여러분이 사내에서 제공하는 내부 데이타 센터에 어플리케이션을 배포하는일에만 익숙하시다면, 우선 새로운 환경에 적응하기 위하여 기존에 알고 계신 많은 지식과 노하우를 저 멀리 던져 버릴 각오를 하셔야합니다. 클라우드 환경과 기존 환경간의 차이적을 적극적으로 이해하고 포용할 필요가 있습니다.
아… 쓰라린 추억이 떠오릅니다. 하드웨어 장비의 안정성 같은 문제가 먼저 떠오르네요. 하드웨어가 고장나는 경우가 별로 없는, 넷플릭스 내부 데이터 센터를 사용할 때 개별 셔션별로 메모리를 관리하는 것은 아주 타당한 선택이였습니다. 서로 다른 인스턴스가 합쳐 지는 일도 거의 없기 때문에, 휘발성 메모리를 이용하여 상태 정보를 관리하는 것도 합리적으로 생각되었습니다. 이전 부터, AWS 내에서 개별 인스턴스가 고장날 확률이 높다는 이야기는 알고 있었지만, 그러한 문제가 이런 차이점을 야기할 거라고는 생각하지 못했습니다.
또 한가지 예가 있습니다. 넷플릭스 데이터 센터에서는 굉장히 빠르고 대역폭이 크고 안정적인 네트워크를 사용 할 수 있었습니다. 덕분에 리모트 시스템과 메세지를 주고 받기 위해서 삐까번쩍한 API 를 설계하고 사용할 수 있었지요. 반면에 AWS 에서는 네트우어크 레이턴시가 일정하지 않고 좀 들쭉 날쭉 한 편입니다. 따라서, 비록 넷플릭스 시스템이 보다 고도로 분산된 아키텍처로 변화했음에도 불구하고, 네트워크 상호작용에 관하여 활씬 더 효율 높은 구조로 변경 될 필요가 있었습니다.
2. ‘Co-tenancy – 리소스를 공동 소유하는 것’ 은 간단한 문제가 아닙니다.
클라우드 환경 내에서 사용자를 대상으로 한 소프트웨어를 설계할 때 가장 중요하게 고려되야 할 사항은, 사용자의 요청에 대해 최대한 빠르게 응답하는 것 입니다. 그런데, AWS 는 여러 시스템 인스턴스가 하드웨어, 네트워크, 스토리지 등의 리소스를 공유하는 형태의 모델을 기반으로 구현되었습니다. 따라서, 전체 소프트웨어 스택(가장 아래쪽에서 가장 위까지…)중 어느 한 단계에서는 발생한 문제는 전체 서비스의 처리량에 영향을 줄 수 있습니다.그러므로, 어떤 경우에는 리소스가 공동 소유되는 것을 피하기 위하여 특정한 서브 모듈을 아예 제거 하거나, AWS 의 특정 리소스는 직접 관리할 필요가 있습니다. 다시말해, 여러분은 시스템 어떤 단계에서 문제가 발생하던지 간에 이를 잘 처리할 수 있도록 시스템을 구현해야합니다. 다음 항목에서 좀 더 자세하게 이야기 해 보겠습니다.
3. 실패를 방지하는 가장 좋은 방법은 계속해서 실패하는 것 입니다.
넷플릭스 개발팀은 종종 AWS 에서 동작하고 있는 소프트웨어 아키텍처를 가리켜 ‘람보’ 아키텍처라고 부르곤 합니다. 각각의 개별 시스템은 하여간에 무슨일이 있어도 항상 ‘성공’ 해야만 하거든요. 이를 위하여 우리는 분산되어 있는 각각의 시스템을 설계 할 때, 특정 시스템에 의존하고 있는 시스템이라고 할 지라도, 해당 시스템이 동작하지 않는 상황에서도 적절한 작업을 수행할 수 있도록 설계하였습니다.
예를 들어, 추천 시스템이 다운되어 버린다 할 지라도, 우리는 사용자에게 적절한 컨텐츠를 추천해 줍니다. 물론 추천의 질이 낮아지긴 하지만요. 개별 사용자 기록을 기반으로 추천된 컨텐츠를 권하는 대신, 현재 가장 인기 있는 컨텐츠 목록을 표시하는 식으로 말이지요. 어쨌든간에 사용자들은 자신의 요청에 대한 응답을 받을 수 있습니다. 또 다른 예로, 만일 검색 시스템이 갑작스럽게 느려지는 경우에도 스트리밍 서비스는 완벽하게 자신의 역할을 수행할 수 있습니다.
넷플릭스의 엔지니어팀이 AWS 기반으로 작성한 가장 첫번째 시스템은 바로 “카오스 몽키” 였습니다. 카오스 몽키는 AWS 상에서 동작하고 있는 우리 시스템의 특정 인스턴스나 서비스를 랜덤하게 종료시키는 소프트웨어 입니다. 만일 우리가 수 많은 오류가 발생하는 상황에서도 불구하고 성공적으로 서비스를 제공할 수 있는지에 대하여 끊임없이 테스트를 하지 않는 다면, 예를 들어 갑작스러운 정전 사태가 발생하는 경우에 우리의 시스템이 정상적으로 동작할 것이라고 기대할 수는 없을 것 입니다.
4. 장난감 모델 대신, 실재 규모의 데이타를 활용하여 공부해야 합니다.
넷플릭스는 AWS 를 선택하기로 결정하기 전, 클라우드 플랫폼에 대한 연구와 이를 테스트 할 수 있는 시스템을 구축하는데 오랜 시간을 들였습니다. 정말로 실제와 유사한 사용자 트래픽을 시뮬레이션 하기 위하여 여러가지로 노력을 기울였지요. 그러한 테스트에서 나온 결과과 AWS 를 선택한 주요한 근거 중 하나였습니다. 하지만, 그럼에도 불구하고, 시간이 지난 후에 살펴보니, 우리가 정성스럽게 시뮬레이션 한 각종 트래픽 모델들은 기대한 것 만큼 큰 도움이 되지는 못했습니다.
제품이 AWS 에 올라간 후, 넷플릭스 엔지니어들은 간단한 리피터를 작성하였습니다. 모든 고객 트래픽을 AWS 시스템으로 복사하여 전달하도록 말이지요. 그리고 그제서야, 우리는 시스템 어떤 부분이 정말로 병목현상을 일으키는지 알 수 있었습니다. 그리고 화이트 보드상에서는 그럴싸하게 보였던 몇몇 설계안들이 실제 규모에서는 얼마나 바보 같은 결정이었는지도 알 수 있겠되었지요.
바로 지금 이순간에도, 넷플릭스 AWS 위에서 새로운 기술에 대한 연구를 수행하고 있습니다. 잘 설계된 시뮬레이션 데이타 대신에 풀 스케일의 실제 데이타를 기반으로 말입니다. 예를 들어 우리가 새로운 NoSQL 옵션에 대하여 궁금한 부분이 생긴다면, 실제 전체 데이터를 사용하여, 대상으로 해당 옵션을 적용하여 작업을 수행해봅니다.
5. 클라우드로 뛰어 드세요.
올해 AWS 마이그레이션 하면서, 넷플릭스의 엔지니어 팀이 이루어낸 일들에 대해 생각해보면 정말로 놀랍습니다. 하지만 AWS 를 마이그레이션 하는 과정이 늘 좋았던건 아닙니다. AWS 는 아직 몇 년 밖에 되지 않았고, 정말로 거대한 규모의 시스템을 AWS 상에서 동작 시키는 것은 아직 새로운 부분이 많이 남아있습니다. 힘들 순간이 많았습니다. 해야할 일은 엄청나게 많았고, AWS 의 동작방식과 기존 넷플릭스의 데이터 센터의 동작 방식간에 차이점도 있었습니다.
마치 장애물 경주를 하듯이 허들을 뛰어 넘기 위해서는 과감한 결단과 용기가 필요합니다. 넷플릭스의 CEO 인 Read Hastings 는 AWS 통합 과정 전체에 참가했을 뿐만아니라, 이 일을 해내자고 비전을 갖고 동기를 부여해주었습니다. 그의 헌신과 사내 기술 리더들의 노력으로 인해 우리는 포기하고 싶던 순간에도 다시 한번 힘을 내어 전진할 수 있었습니다.
AWS는 훌륭한 서비스의 집합입니다. 끊임없이 발전하고 있으먀, 바로 지금 이 순간에 넷플릭스 같은 큰 시스템이 성공적으로 동작하고 있습니다. 여러분도 할 수 있습니다. 우리는 여러분이 우리의 실수와 경험을 기반으로 보다 좋은 서비스를 할 수 있기를 기원합니다.
-john ciancutti.

(주)리화이트 대표 / CEO & Founder

Next Article빅브라더가 욕심 낼 빅데이터, 어떻게 관리하고 있습니까?