Apache Hama는 왜 실패했을까?
일기보다 못한 것..
Apache Hama의 탄생 배경
먼저 Apache Hama를 처음 탄생시킨 일화부터 적어보자. 2007년, 나는 구글 GFS, BigTable, 그리고 MapReduce 논문에 대한 내용의 블로거로 유명해지면서, 한국의 검색 엔진 회사 네이버로부터 스카웃 제의를 받고 IT 산업계에 처음 발을 들였다.
내가 구글 논문에 관심이 있었던 이유는, 그 당시 구글이 4억 건의 웹 문서에서 검색 중이라는 내용 때문이었다. 이게 왜 그렇게 놀라웠냐? 구글의 페이지랭크 계산 방식을 한번 보자.
웹 페이지의 개수가 N 일때, 웹 링크 그래프 구조는 N by N 행렬로 표현한다. 만약 page j가 page i로 가는 링크를 갖고 있다면 행렬 M(I, j)는 1/c 값을 갖는다 (c는 page j의 outlink 개수). 이러한 행렬 M은 한 열의 값을 모두 합친 값이 1이 되므로 column stochastic matrix 라고 한다.
웹페이지의 개수가 4개일 때의 행렬 M의 예시값이 0인 것은 link가 없음을 뜻하며 0이 아닌 값을 가진 페이지는 열값페이지->행값페이지로 가는 링크가 있음을 뜻한다. 이러한 그래프 데이터에 페이지랭크 계산은 'Power Iteration method'라고 불리는 방법으로 반복적으로 행렬과 벡터를 곱해 수렴하는 값을 찾아낸다.
4억건의 웹 문서의 링크 구조는 즉 16 * 10^16 개의 double 값 (8 bytes) 으로 표현되므로 (zerofill), 1.2 exabytes가 된다.
이런 규모의 데이터에 반복적 행렬 곱셈이 수행된다.
자, 학교 폐급 PC 주섬주섬 주워다가 이런 복잡한 연산을 해내고 있다는 것에 어떻게 놀라지 않을 수 있을까!?
많은 엔지니어들은 구글의 빅 테이블을 RDBMS 같은 초대형 데이터베이스로 생각하고 있었다. 그러나, 나는 데이터베이스라기보다는 희박 행렬(sparse matrix)을 저장하고 행과 열의 고속 스캔을 위해 만들어졌다고 생각했다. 지금도 그렇게 생각하고 변형된 document DB 같은 종류를 보면 굉장히 혐오스럽게 바라보고 있다.
또한, MapReduce 같은 프로그래밍 모델로 PageRank를 계산하는 것은 불가능하다고 생각했다. 이때부터, 행렬 연산과 같은 복잡한 연산에 특화된 컴퓨팅 프레임워크가 필요하다고 생각했다. Hama는 Hadoop 기반의 Matrix computation package로 유래된 이름이다.
MapReduce에서 BSP 메시지 패싱으로
맵리듀스는 한번의 풀 스캔과 reduce 함수로 취합하는 구조로 만들어져있다. 이 때문에, 반복적인 알고리즘을 구현하면, 데이터를 매번 읽어들이는 불합리한 구조로 동작한다.
K-means 계산을 예로 들자. K개의 centroids와 나머지 points 간의 거리 계산을 한 후, 중심을 이동 시키는 반복 알고리즘이다. 매 iteration마다 데이터를 읽어들이기 때문에 느리다.
반면, 한번 데이터를 읽어들이고, 반복 계산을 하는 과정에 프로세서 간 업데이트를 동기화를 해주는 개념이 BSP (Bulk Synchronous Parallel) 모델이다. 이 모델로 MapReduce와 성능 차이는 1,000배가 나는 것을 확인하였다.
이때부터 beyond MapReduce로 방향을 잡았다.
주 목표점은 기계학습, 네트워크 분석, 수치 분석 등 과학적 계산 집약적 병렬 연산 도구를 만드는 것이었다.
이 시기에 비슷한 시도들이 있었으니, Apache Spark과 HaLoop 같은 것들이었다.
이렇게 우수한 성능을 내는 프로젝트는 왜 실패 했을까?
앤드류 응 교수는 힌튼 교수에게 ImageNet challenge에 신경망과 GPU를 사용하도록 권유했다. 그 가능성은 2012년 이미지넷 우승으로 증명된다. 응 교수는 GPU에 특히나 가능성을 보고 있었던 것 같고, 2011년부터 구글 브레인 수장으로 합류하여 GPU와 Deep Learning의 시대를 열었다.
거의 비슷한 시기에 MapReduce의 창시자이며 commodity clustering 설계에 익숙한 Jeff Dean은 뉴런-중심의 대형 병렬 처리 머쉰을 만들고 distbelief라는 논문을 냈는데, (내막은 모르지만) 응 교수와 정면 배치되는 상황이었지 않을까 한다. BSP기반의 대형 그래프 처리를 위한 Pregel도 거의 비슷한 시기에 출현했다.
약간의 시간이 흐른 뒤 앤드류 응과 Pregel 고안자는 모두 Google을 떠났고, 제프 딘 사단에서 TensorFlow가 출현했다. 개인적으로 별로 달갑게 쳐다보지는 않는다.
어쨌건, 내 생각에 Big Data와 commodity cluster computing 시대는 이때부터 저물고 있었고, GPU와 데이터과학의 시대로 넘어가는 전환점이었다고 본다.
Spark, Hama, HaLoop 모두 commodity cluster computing이기 때문에 계산-집약적 컴퓨팅 성능이 GPU 꼽은 컴퓨터들과 비교가 어려웠고, 요즘은 모두 fadeout 과정이라고 생각한다.
Apache Hama는 왜 실패했을까에 대한 답변은 간단하다.
Apache 재단 하의 Big Data 커뮤니티는 너무 대용량 처리의 엔지니어링에 집중한 경향이 있다. 워드 카운팅 처럼 입/출력이 명확한 문제, 그리고 데이터 파이프라인 구성과 설계가 전부다. 데이터 응용과 과학적 수학적 접근에 친숙하지 않다.
요즘 유행하는 iterative refinement하는 UX design, growth hacking 같은, 데이터를 중심으로 비지니스 문제를 해결하는 프로세스 중 Big Data community에서 탄생한게 뭐가 있는가? 없다. 그저 서버를 묶고 성능 좋은 엔지니어링의 향연에 불과했다.
Apache Hama는 조금 다르게 데이터 과학을 위한 과학 연산과 유연한 환경 제공을 추구했다. 그 시절에는 데이터 과학자같은 Job title도 없던 시절이라 이걸 어떻게 써먹는건지 잘 몰랐던것 같고, 너무 앞서 간 것 같다. 그리고, commodity cluster computing에 너무 묶여 있었다. 정작 중요한게 뭔지 몰랐지 싶다.
