hadoop 도입시 고려사항 [펌]

2012년 올해는 IT업계에서는 No-SQL이 큰 이슈 중에 하나로 떠오르고 있는 것 같습니다. 몽고 DB나 카산드라 하둡과 같은 오픈소스들을 말하는 것이겠죠? IT업계에서는 이를 이용해서 로그 데이터나 비정형 데이터를 분석해서 고객의 패턴을 분석해서 영업을 잘해야 한다고 강조하고 외국에서는 이미 그렇게 하고 있다고 영업을 하고 다닙니다.

오늘은 제가 작업하고 있는 하둡에 대한 몇가지 이야기를 해보려고 합니다.  이 이야기는 하둡을 이용해서 돈을 버는 사람들의 눈에서 보는게 아니라 하둡을 운영하는 고객의 입장에서 적어보는 것입니다. 여기의 내용은 개인적인 내용이기 때문에 과도한 비판은 삼가해주시길 부탁드립니다.

요 몇 개월간 하둡을 이용하는 프로젝트를 하고 있습니다.  처음 하둡에 접근할 때의 기대보다 운영 해야하는 지금의 입장은 많이 불안하고 걱정이 앞서는 입장입니다.   하둡 프로젝트를 진행하면서 어찌보면 배보다 배꼽이 크다는 생각도 가끔은 들기도 합니다. 그래서 오늘은 작정하고 하둡을 비판해 보겠습니다.

첫번째 비판 : 절대 꽁짜가 아니다.
하둡은 오픈소스입니다. 많은 고객분들은 ‘오픈소스는 공짜다’ 생각을 많이 가지고 계십니다. 하지만 아는 사람들은 오픈소스는 절대 공짜가 아니다라는 사실을 충분히 알고 있습니다. 예를 들어 오라클이나 벤더에서 파는 DB를 구입하면 충분한 기술지원을 받을 수 있습니다. 즉 장애를 해결함에 있어서 크게 걱정이 없다는 소리입니다. 물론 별도의 라이센스 비용을 지불 할 수도 있는 경우도 있습니다. 오픈소스는 장애가 나면 어디에 기술지원을 요청해야 할까요? 그리고 기술지원을 받는다 해도 벤더처럼 24시간, 365일 기술지원을 즉시 받을 수 있을까요? 받을 수 있다고 하더라도 장애에 대한 기술지원비용은 벤더의 비용보다 훨씬 많은 비용을 지불 할 것은 분명해보입니다. 수요의 법칙에 의해서 아직 까지는 기술 인력이 많이 있지 않을 가능성이 많습니다. 하둡은 더욱 관련된 엔지니어의 숫자는 크지 않겠죠?

두번째 비판 : 어디 자바도 잘알고 쿼리도 잘알고, 하드웨어도 정통한 사람 없어요?
장애 비용이외에도 관리비용도 있습니다. 비교는 어렵겠지만 하둡과 오라클을 비교해보겠습니다. 오라클의 경우에 유지보수하는 사람은 DBA 정도이면 충분하고 오라클이 올라간 서버는 많아야 한대에서 두대 입니다. 하드웨어 관리하는 사람도 한사람정도라고 가정을 해봅시다. 그런데 하둡을 쓰게 되면 하둡을 기본적으로 아는 엔지니어와 하이브를 쓴다면 쿼리를 잘아는 엔지니어(오라클의 DBA 정도의 역할 + 자바의 기본지식을 가진사람) 그리고 하드웨어를 관리하는 사람이 필요합니다. 하드웨어의 숫자는 기본적으로 오라클의 한 두대와 비교해서 수십대에서 수백대로 늘어나게 됩니다.  이를 모니터링 툴을 도입해서 조금은 효율화를 할 수도 있겠지만 일단 관리 포인트가 엄청 늘어나는것은 분명해 보입니다. 거기다가 플럼이나 주키퍼, OOZIE 같은 오픈소스를 같이 쓰게되면 관리해야할 사람은 계속 늘어나겠죠?

세번째 비판 : 하둡은 분산이니까 싸구려 장비를 써도 되!
하둡을 쓰게 되면서 가장 큰 오해는 하둡이 탑재될 장비에 대한 오해입니다. 용산에서 조립한 것 같은 PC에 하둡을 돌리면 비용은 많이 절감될 것입니다. 하지만 자료를 찾아보면 그렇게 저렴한 장비를 운영해서 하둡을 돌릴 경우 매일 장비의 장애상황에 부딛혀서 복구하는데 시간이 더 많이 든다고 합니다. 적어도 엔트리 서버급의 장비를 사용해야 그나마 안정적으로 운영할 수 있다고 합니다. 엔트리급 서버의 장비의 경우에는 적어도 500만원 에서 2000만원까지 합니다. 이런 장비를 수십대 수 백대 구매하게 되면 비용이 정말 만만치가 않겠죠? 비용도 마찬가지 이지만 장애포인트는 엄청 늘어나겠죠? 차라리 이럴바에 1억에서 3억 정도의 큰 서버와 넉넉한 스토리지에 데이터를 저장하고 쓰는게 인프라 관리 측면에서는 비용을 아끼는 지름길 이겠죠?

네번째 비판 : 하둡은 오라클이 아니에요!
고객들이 기존 오라클같은 관계형DB와 비교할 때 하둡에 대해서 아주 크게 오해하는 부분은 실시간 쿼리의 문제입니다.  관계형 DB에서 select * from emp where emp_id=12345 라고 질의하게 되면 순식간에 결과가 나오게 됩니다 .물론 emp_id에 인덱스가 걸려 있다는 가정하에 말이죠. 만약 하둡과 하이브를 이용해서 위의 질의를 날린다고 하면 기본적으로 수분에서 수십분이 걸리게 됩니다. 왜 이럴까요? 하둡은 기본적으로 64MB ~ 128MB 단위의 블록으로 데이터를 저장하게 됩니다. 그리고 하이브를 이용해서 질의할 경우 하둡의 맵/리듀스 프로그램을 통해서 관련 작업들을 수행하게 됩니다. 만약 emp_id=12345 데이터가 특정 블록에 저장된 것을 찾아와서 이를 읽는다고 해도 64MB를 다 읽어야 결과가 나옵니다. 재수가 좋으면 더 빨리 나올수도 있겠죠?  그래서 기본적으로 하둡은 실시간으로 데이터를 조회하는 것이 불가능합니다. 따라서 이런 곳에서는 하둡을 쓰면 안되겠죠? 만약 실시간을 하고 싶다면 루씬 같은 검색엔진을 써서 별도의 작업해주면 되지만 루씬과 같은 검색엔진도 기본적으로 인덱스 만드는데 데이터량이 하둡만큼 싸이게 됩니다. 또한 복제본을 몇개를 가지고 결정을 해야하지만 만약 하둡과 루씬에서 복제본을 3개씩 가지고 간다고 가정하면 원본 데이터의 6배의 하드디스크 저장공간이 기본적으로 필요하게 됩니다. 내부 하드디스크 저장단가가 타 스트로지 보다 가장 큽니다. 이렇게 되면 진짜 배보다 배꼽이 더 커지는 말도 안되는 아키텍쳐이겠죠? 설마 이렇게 하는 곳은 없을 것입니다.

여기까지 생각 나는데로 하둡 프로젝트를 하면서 느낀 하둡의 안 좋은 점을  몇자 적어봤습니다.  하둡이 안정화 되고 많은 사람들이 사용하게 되고 그래서 엔지니어가 늘어나게 되면 이런 고민들을 할 필요가 없겠죠?
그러나 아직은 초기인 관계로 특히 국내와 같이 IT서비스 회사와 ITO계약을 통해서 IT를 관리하는 회사의 경우에는 하둡의 도입을 조금 많이 더 고민을 해야할 것 같습니다.  오픈소스를 이용해서 라이센스 비용 몇 천 또는 몇 억을 줄이고자 하드웨어 비용, ITO대가 비용, 장애의 위험을 무릅쓰고 도입을 할지 아니면 다른 솔루션을 찾아볼지는 고객 입장에서 충분히 고민할 필요가 있다고 생각됩니다.

컴퓨터시스템응용기술사 이지훈(mhb8436@gmail.com

출처 : https://thinkingcookie.wordpress.com/2012/06/07/%ED%95%98%EB%91%A1hadoop-%EB%8F%84%EC%9E%85-%EC%8B%9C-%EA%B3%A0%EB%A0%A4%EC%82%AC%ED%95%AD/