gimmesilver's blog

Agbird.egloos.com

포토로그



NoHadoop 데이터분석


 25년 동안 권좌의 자리를 지키던 관계형 DB 및 SQL 이 최근 부흥하고 있는 "NoSQL 운동" 세력으로부터 집중 포화를 받고 있다. 이 (반대)세력의 중심에는 하둡이라고 하는 구글의 MapReduce 시스템을 오픈 소스로 구현한 시스템이 존재한다. NoSQL 이 의미하는게 "SQL은 아니야" 든 "SQL 만으로는 안된다" 든 상관없이 그들이 주는 메시지는 명확하다. "당신이 만약 대용량 데이터에 압박받고 있다면, 당신이 할 수 있는 선택은 바로 하둡을 사용하는 것이다."

 근데 여기서 한 가지 문제가 되는 것은 정말로 탁월한 성능과 확장성(scalability)을 필요로 하는 사람들은 이미 하둡 (프로그래밍) 모델에서 벗어나고 있다는 점이다. (심지어) 일부는 다시 SQL 로 돌아가고 있으며, 그보다 훨씬 더 많은 사람들은 하둡과 MapReduce 가 가진 능력 및 그 한계점을 깨닫고 있다. 최근 하둡의 뒤를 잇는 새로운 구조가 많이 개발되고 있는데 이들 대부분은 하둡보다 월등한 성능을 갖고 있다. 우리는 이제 새로운 "NoHadoop" 시대를 시작하려 한다. 대용량 데이터를 처리할 때 하둡만으로는 부족하다는 것(Not Only Hadoop)을 깨닫는 기업들이 점점 늘고 있는 것이다.

 MapReduce나 하둡과 같은 단순한 배치 작업 도구는 대용량 데이터 공간의 여러 단면 중 어떤 정말로 중요한 하나를 처리하는 데에는 충분히 강력하지 못하다. 물론 하둡은 embarrassingly parallel한 단순 배치 작업에는 뛰어나다. 그러나 기업들이 직면해 있는 대부분의 어려운 대용량 데이터 처리 작업은 이보다 훨씬 더 복잡하다.
 이런 작업들은 복잡한 조인 작업이나 ACID, 실시간성, 슈퍼 컴퓨팅 알고리즘, 그래프 분석, 상호 연관성 분석 혹은 지속적으로 증가하는 수정 작업 등을 필요로 한다. 하둡은 이런 작업을 합당한 수준의 성능으로 처리할 수 없다. 그러나 다행히도 각각의 경우에 맞는 차세대 대용량 데이터 처리 구조가 현재 존재하고 있으며 이들은 필요한 만큼의 성능과 스케일을 제공한다. 몇 년 뒤에는 이들이 업계의 중심에 자리 잡을 것이다.

<하략>

* * * * *

 지난 달에 구글에서 Percolator 라고 하는 일종의 분산 트랜잭션 시스템에 대한 논문을 공개했다. 분산 DB에 데이터 변경이 일어나면 해당 데이터와 연관된 데이터 수정 및 처리 작업을 연쇄적으로 수행하는 시스템(DB의 Trigger와 유사하다)인데 웹 문서 인덱스 시스템을 MapReduce 에서 이것으로 교체했다고 한다. 이 외에도 이미 구글에서는 그래프 연산을 위한 Pregel 이라고 하는 BSP(Bulk Synchronous Parallel) 기반 시스템을 개발해 링크 분석 등에 사용하고 있다.

 으레 그렇듯 오픈 소스 진영에서도 Pregel 을 따라한 HAMA 가 아파치 인큐베이팅 중이고 Percolator 가 발표되자마자 야후에서는 Streaming MapReduce 프로젝트를 자신들의 연구 사이트에 소개했다.

 작년에 MapReduce를 이용해서 게임 로그를 분석해 컨텐츠를 만드는 시스템을 개발했었다. 전체 분석 단계가 약 100 여 단계에 달하는 복잡한 작업이었다. 이게 하루치 로그 데이터를 분석하는 데에는 2시간 정도면 충분한데 10분치 데이터를 분석하는데에도 1시간이 걸렸다. 10분치 로그 데이터의 양은 그리 크지 않은데 분석 단계가 워낙 많다보니 분산 처리의 효과는 거의 없고 오히려mapper와 reducer 간에 주고 받는 네트워크 부하가 시간을 많이 소모하기 때문이다(MapReduce는 reducer 단계가 많으면 성능이 떨어진다).
 그래서 10분 데이터를 분석할 때는 서로 독립적인 데이터(이 경우에는 게임 월드 서버별 로그)들을 분산해서 장비에 할당하고 각 서버 별로 데이터 분석 시 하둡의 로컬 모드 방식으로 돌리는데 이 때 분석할 로그 데이터는 모두 메모리에 올려 처리했다. 이렇게 하니 mapper 와 reducer 간의 I/O 부하가 거의 없어져 6~7분 정도면 분석을 마칠 수 있었다.

 최근에도 비슷한 경험을 했다. 그래프 클러스터링 작업이었는데 한 1년 반 가량 MapReduce를 사용하다보니 습관적으로 이번에도 MapReduce로 프로그래밍을 했다. 일주일치 정도되는 로그를 분석해서 연관된 노드끼리 클러스터링을 하는 로직인데 iteration을 많이 해야하다보니 30~40분 정도 걸렸다.
 전체 데이터 양이 별로 크지도 않은데(노드가 약 10만 수준의 작은 그래프였다) 너무 오래 걸리는 것 같아 로그를 읽어 클러스터링을 위한 기초 데이터를 만드는 과정에서만 MapReduce를 쓰고 이 가공된 데이터로 클러스터링 하는 부분은 MapReduce 안쓰고 메모리에 올려서 작업하도록 프로그램을 새로 만들었더니 수행하는데 한 1분 30초 정도 걸리더라(이 중에 1분 20초가 MapReduce로 데이터를 가공하는 과정에서 걸리는 시간이었다).

 암튼 당연한 말이지만 MapReduce가 만능은 아니다. MapReduce 모델은 전체 데이터를 읽어서 단순한 작업을 처리하는데에는 유리하지만 일부 데이터의 수정만 필요하거나 그래프 연산처럼 반복적인 iteration 이 필요한 작업에는 쥐약이다. 기본 개념이 전체 데이터를 통째로 읽어서 처리하고 다시 통째로 쓰는 것이니 이런 용도가 아닌 곳에서 사용하려면 쓸데없는 부하가 걸리는 것이 당연하다.
 내 경우도 굳이 MapReduce를 쓸 필요가 없는 부분에서 관성적으로 MapReduce를 들이댔기 때문에 생긴 에피소드이다. 

 어떻게 보면 하둡을 비롯해서 요즘 나오는 많은 수의 분산 처리 시스템들이 갖고 있는 장점은 MapReduce 모델 자체의 우수성이 아니라 관리에 대한 편의성이 아닌가 생각한다. 여러 개의 서버를 관리하는 것은 무척이나 소모적인 일이며 서버들은 수시로 말썽을 일으킨다.
 우리 팀에서도 150 대 정도되는 장비로 로그를 분석하는데 보통 이틀에 한 대 꼴로 OS 행이 걸리거나 디스크 파티션이 풀리거나 해서 장애가 발생한다. 그럼에도 불구하고 웬만해서는 로그 분석 시스템 자체에서 문제가 생기는 일은 거의 드물다. 그냥 행 걸리면 해당 장비 껐다 키고, 파티션 풀리면 다시 설정하고 디스크 맛 가면 교체하고... 이런 식이다.
 그래도 라이브 서비스에 심각하게 영향 주지 않는 것은 기본적으로 하둡 자체가 장애가 발생해도 데이터 처리 결과에 영향을 주지 않도록 설계되어 있고 MapReduce 프로그래밍 모델 자체도 그런 개념을 갖고 만들어 졌기 때문이다. 모든 장애를 처리하지는 못하지만 최소한 개발자에게 side effect free 한 프로그래밍을 하도록 가이드는 되어 준다.

 Percolator나 Pregel 같은 논문을 보면 개네들이 무슨 천지개벽하는 새로운 시스템은 아니고 다 기본 개념은 비슷하다. 분산해서 데이터 처리하고 장애 발생해도 데이터가 더럽혀지지(corrupted) 않게 잘 관리해주고 하는 식이다. 다만 데이터를 어떻게 처리하느냐 하는 프로그래밍 모델 부분에서 차이가 날 뿐이다.

 따라서 NoHadoop 이라기보단 Extended Hadoop 정도가 맞을 듯 싶다.

덧글

댓글 입력 영역