넷플릭스, 하둡 성공 아닌 실패 경험담 공개

영상 스트리밍 서비스로 관록의 케이블TV들까지 위협하고 있는 넷플릭스는 빅데이터 분석을 통한 개인화에 내공이 있다는 평가를 받아왔다.

넷플릭스가 제공하는 개인화 추천 서비스는 하둡으로 대표되는 빅데이터 기술에 대한 노하우에 기반한다. 넷플릭스가 가진 빅데이터 노하우는 하루아침에 거저 얻은 것이 아니다. 많은 실패와 시행착오의 결과물이다.

통상 실패 사례는 외부에 잘 공개되지 않는 법인데, 30일 열린 네이버 데뷰2014에선 넷플릭스가 겪은 하둡 실패 경험이 공유돼 참가자들로부터 관심을 끌었다.

넷플릭스 빅데이터플랫폼팀 엔지니어로 일하고 있는 박철수 아파치 피그 프로젝트관리위원회(PMC) 의장은 '네이버 데뷰2014'에서 '아파치 피그(Pig)를 위한 테즈(Tez) 연산 엔진 개발하기'라는 주제로 발표를 진행했다.

다른 발표와 달리 실패사례를 제시하고 당면한 문제를 전달한 점이 눈길을 끌었다. 빅데이터를 다루는데 있어 '끝이란 없다'는 것을 재확인시켜주는 발표였다.

피그는 아파치 하둡에서 대용량 데이터세트를 분석하기 위한 스크립트 언어다. 넷플릭스는 이를 하둡 데이터를 추출하고 적재하고 변환(ETL)하는데 써 왔다. 쿼리를 맵리듀스(MR) 작업으로 전환해 하둡에서 실행하는데 이 방식은 비효율적이라는 게 박 의장의 평가다.

넷플릭스는 내부 개발자에게 서비스형 하둡플랫폼(HPaaS)을 제공하기 위해 AWS 클라우드 인프라와 심플스토리지서비스(S3)를 사용한다.

업무 프로세스는 클라우드 애플리케이션의 이벤트 데이터와 카산드라 NoSQL DB 데이터를 매일 저장하고 이후 데이터 과학자들이 하둡 클러스터 배치 작업과 피그 쿼리, 또는 페이스북 프레스토를 동원해 분석하는 절차로 진행된다.넷플릭스 데이터 파이프라인을 통해 매일 수집되는 데이터는 40테라바이트(TB) 수준이다. 이 데이터가 ETL 과정을 거쳐, SQL 비슷한 쿼리 언어로 조회 가능한 '하이브(Hive)' 테이블로 저장되는 데이터 용량은 100TB에 달한다. 넷플릭스가 이렇게 아마존S3에 쌓은 데이터웨어하우스(DW) 용량은 현재 10페타바이트(PB)를 넘었다. 용량이 커지나 ETL 속도가 느려지는 문제가 발생했다.

박철수 의장은 하둡이 규모가변적(Scalable)인 기술이긴 하지만 데이터가 늘면서 ETL 작업은 점점 느려졌다며 넷플릭스에서 (분석에) 피그를 쓰기 위해 과거 ETL 작업 목표였던 '10시간 이내 처리'는 몇 년 전 얘기가 됐고, 이는 넷플릭스뿐아니라 링크드인, 야후 등 오픈소스 하둡 스택을 도입한 회사에 공통된 문제였다고 설명했다.

■맵리듀스 대신 테즈로 하둡 ETL 쿼리를 빠르게

넷플릭스가 과거 MR 기반으로 써 온 피그 언어는 성능에 불리한 몇가지 문제점을 안고 있었다.

하둡파일시스템(HDFS)에 중간처리값을 저장해 불필요한 과정을 거친다거나, 오래된 MR 프로그래밍 패러다임의 한계로 현대적 ETL 처리 방식을 모두 표현하지 못하거나, 클러스터 자원 사용 효율을 떨어뜨리거나, 자원 사용 효율을 높이기 위한 다중쿼리최적화 작업이 오히려 색인 과정에 네트워크 부하를 늘려버리는 등의 현상이 발생했다.

이에 넷플릭스, 링크드인, 야후 엔지니어들은 하둡 피그 기반 분석 성능을 끌어올리기 위해 힘을 합쳤다. 하둡 전문 업체인 호튼웍스까지 끌어들였다. 이들 회사에서 모인 개발자 6명이 '피그온테즈(Pig on Tez)' 팀을 꾸렸다. 피그온테즈 팀 활동 목표는 그 이름처럼 테즈(Tez)를 기반으로 피그 스크립트를 통한 하둡 데이터 처리 및 분석 속도를 개선하는 기술을 개발하는 것이다.

테즈는 하둡의 기존 MR을 대체하는 연산 엔진이다. 하둡2.0 환경에서 도입된 자원 관리 기술 겸 애플리케이션 플랫폼 '얀(Yarn)' 위에서 돌아간다. 야후에서 분사한 하둡 전문업체 호튼웍스가 개발하기 시작해 지난 7월 아파치 톱레벨 프로젝트로 승격됐다. 현재 테즈 0.5 버전이 최신판이다. 당시 넷플릭스는 피그 성능을 2배 가량 개선할 수 있을 것으로 기대했다.

박 의장은 넷플릭스처럼 피그 의존도가 높은 회사에서는 피그 외의 도구로 ETL을 짜는 결정을 내리기가 쉽지 않다며 '피그온테즈'가 기존 피그 쿼리를 그대로 실행하면서 성능을 개선한다면 기존 ETL 파이프라인으로 더 많은 데이터를 처리할 수 있어 매력적이었다고 평했다.

이어 테즈는 하둡 사용자가 데이터 처리 스케줄을 '방향성 비순환 그래프(DAG)' 형태로 짤 수 있는 저수준 DAG프레임워크라며 DAG 실행 스케줄을 순차화할지 동시적으로 할지, 작업간 연결 구조를 1대1, 브로드캐스팅, 분산(scatter), 수렴(gather) 중 어떤 형태로 할지 등을 정할 수 있다고 설명했다.

그가 언급한 DAG는 아파치 테즈 기술이 데이터처리 흐름을 나타내기 위한 일종의 객체기반 표현 체계다. 처리 로직과 그 실행에 필요한 자원 및 환경을 나타내기 위해 꼭지점(vertex)이라는 객체가 정의된다. 그리고 정의된 꼭지점간 데이터 흐름이 1대1인지 브로드캐스팅인지, 분산인지 수렴인지 등을 선(edge) 객체가 나타내 준다. MR에 비해 테즈가 피그 쿼리를 더 효율적으로 처리할 수 있는 여지를 제공한다.

■테즈 투입한 넷플릭스 ETL, 뭐가 좋아졌나

기존 넷플릭스 시스템에 데이터처리 명령이 들어가면 MR컴파일러를 통해 작업 계획이 생성되고 MR 실행 엔진이 돌아가는 과정을 거쳤다. 피그온테즈 기술을 도입함에 따라, 피그로 짠 데이터처리 명령을 MR컴파일러 대신 테즈컴파일러가 처리해 작업 계획을 생성하고 테즈 실행엔진을 돌리는 방식이 가능해졌다.

넷플릭스는 더불어 '버텍스그룹'이라는 개념을 도입해 여러 순차적 단계로 나뉘던 작업을 통합하고, 상위 작업에서 하위 작업으로 가는 과정에 MR의 '지연시작 및 예비실행(slow start/prelaunch)' 개념을 적용해 전체 스케줄링 시간을 줄이는 방식 등으로 실행시간을 단축시킬 수 있었다고 박 의장은 덧붙였다.

박 의장은 (피그온테즈의 DAG 형태로 데이터처리 작업을 실행해 본 결과) 데이터를 순서별 또는 그룹별로 묶는 작업이 (사람의) 머릿속으로 생각하는 흐름과 비슷하게 연산을 거치다 보니 논리적으로 자연스러워졌다며 실험해 본 작업에 한해선 속도도 빨라졌고, 자원 사용량 예측이 가능해진 것도 장점이었다고 평했다.

그는 피그온테즈의 성공 사례로, 얀 플랫폼의 하둡 애플리케이션 자원 관리 및 할당용 구성요소 '애플리케이션마스터(AM)'가 과거 MR 기반으로 피그 작업을 돌릴 때 9개씩 동원됐던 반면, 테즈 기반으로 피그 작업을 돌릴 때는 1개만 동원되는 등 리소스 효율이 개선되는 결과를 얻었다고 밝혔다.

■피그온테즈, 미완의 도전

하지만 넷플릭스의 피그온테즈 도입 프로젝트는 결과적으로 성공을 거두지 못한 상태다. 넷플릭스에서 1명, 링크드인에서 2명, 야후에서 2명, 호튼웍스에서 1명 이렇게 6명이 피그온테즈 팀을 꾸려 1년동안 기술을 개발하고, 지난 8월 한달간 상용화(파일럿 프로그래밍)를 추진했지만 아직 (현업에 도입하기는) 이르다는 결론을 얻었다고 박 의장은 고백했다.

그는 원인을 '병렬도(parallelism) 문제'라고 표현했다. 하둡에서 병렬도는 데이터를 처리하기 위해 작업을 분산시키는 정도를 가리킨다. 기본적으로 분산 환경인 하둡에서는 병렬도를 어떻게 최적화하느냐에 따라 성능이 달라질 수 있다. 병렬도를 조정해 성능이 개선되는 경향을 보였지만, 그걸 자동화해야 하는 게 숙제였다.

박 의장의 표현을 빌리면 넷플릭스는 현재 피그를 사용해 과거 수작업으로 지정된 MR용 병렬도 값을 무시할 수 있을만큼 더 나은 병렬도 자동화 방법을 찾지 못해 헤매고 있다.

일단 현재까지 넷플릭스는 기존 하둡 사용자들이 지정한 병렬도 값을 우선 새 시스템에도 그대로 적용케 했다. 만일 별다른 설정이 없을 경우엔 피그온테즈 팀이 만들어낸 정적 규칙을 기반으로 DAG 방식의 작업 스케줄 단계에서 병렬도를 줄이고, 이후 실행 단계에도 단계별 샘플링으로 재차 병렬도를 조정했다.

박 의장은 지금 알고리즘은 테즈의 자체 메커니즘을 활용해 쿼리 컴파일 상황을 추정하고, 이를 실행할 때 입력 데이터 사이즈에도 맞춰 병렬도를 자동화하는 방식이라며 테즈엔 그 인터페이스만 존재하고 구현체는 없기 때문에, 피그에서 그 동작 코드를 급한대로 만들어 놨는데 현업에서 쓸만한 로직은 아니라는 게 문제라고 언급했다.

그는 이어 넷플릭스 엔지니어들은 그간 500여개에 달하는 ETL 작업 스크립트의 로직을 만드는 시간보다 튜닝을 하는 데 더 많은 시간을 들여 왔다며 그런데 (MR 환경에) 튜닝이 된 스크립트를 변경하지 않고 테즈 환경에서 돌리면 오히려 느려지는 작업이 많아지는 등 성능에 부정적인 영향이 컸다고 설명했다.

■테즈에서 아쉬운 점은…

박 의장에 따르면 피그의 병렬도 자동화 문제와 별개로 SQL온하둡 기술 테즈의 기술 성숙도 측면에도 아쉬운 부분이 몇 가지 있다.

우선 테즈에서는 작업 명령을 받으면 최종 결과만 '성공' 또는 '실패'라고 알려줄 뿐, MR에서처럼 브라우저를 통해 '태스크 몇 개 또는 매퍼 몇 개 완성' 이런 식으로 진행 상황을 파악할 방법을 제공하지 않는다.

하둡의 얀 기반 애플리케이션을 위한 히스토리서버로 '애플리케이션 타임라인서버'가 제공되는데 테즈가 아직 통합되지 않았다는 점도 문제다. 밤새 테즈 기반 작업을 돌리다 실패하더라도 타임라인서버에 별다른 기록이 남지 않는다는 뜻이기 때문에, 현업에서 이를 사용하긴 어렵다는 지적이다.