jaso extends j2ee

cloumon 미국 pre-sales 후기

(김형준) — Mon, 20 May 2013 21:37:49 +0900

한국인 개발자/매니저 등 여러 분들을 만나서 많은 도움과 좋은 말씀을 많이 들었습니다.
생각날때 포스팅으로 남겨 놓을까 합니다.

이번 출장의 목적은 cloumon 구매 가능성이 있는 고객에서 cloumon을 소개하고 제품에 대한 반응 및 구매 단계로 넘어가기 위한 pre-sales 였습니다. 별도의 마케팅 활동 없이 직접 잠재 고객을 찾아 간다는 것이 어렵기는 하지만 실제 고객들이 어떻게 하둡을 사용하고 하둡의 사용에 있어 문제점과 어려움이 무엇이 있는지를 확인해보기에는 사용하는 고객을 직접 만나는게 최선이라고 생각해서 몇군데 미리 일정을 잡아 방문하였습니다.
느낀 점을 정리하면 대략 다음과 같습니다.

1. 핵심 기술을 가지고 있어야 한다.
현재 수준의 cloumon은 핵심 기술이라기 보다는 핵심 기술을 지원하는 도구입니다. 물론 내부 기능에서는 일부 분석 가능한 기능과 잘 활용하면 쉽게 분석 업무나 ETL 등은 수행할 수 있지만 이것들이 구분없이 섞여 있어 데모를 보는 사람(고객)의 입장에서는 관리도구입니다.
그리고 미팅에서 반드시 물어보는 것이 있습니다. 다른 경쟁 제품과의 차별성이 뭐냐? cloumon의 경우 ambari, cloudera manager, hue 등과 같은 맥락의 제품이다 보니 소개를 받으시는 분들의 대부분의 이 내용을 집중 질문 하는 듯 하였습니다.

2. 기능 위주가 아닌 제품이어야 한다.
필요한 핵심 기능이 되어야 하는 것은 당연하고 동영상/문서 -> evaluation 버전를 이용한 고객 직접 설치 및 사용 -> 계약 -> 기술/유지보수 지원 subscription 형태의 풀 사이클이 되어 있어햐 한다.
국내에서는 evaluation 버전을 준비하는 것이 별로 중요하지 않고 심지어는 불법 버전 사용을 조장할 수도 있지만 여기서는 그런 부분에 대해서는 투명하게 움직이기 때문에 가능한 evaluation 버전 사용이 가능하도록 구성해야 한다.
그렇게 하기 위해서는 고객이 직접 다운로드 받아서 설치 매뉴얼만으로도 설치가 가능한 구성이 되어야 한다.

3. 직원의 채용/해고, 회사의 창업/폐업 등이 다이나믹하게 움직여야 소프트웨어 또는 서비스 업종은 성공 확률을 높일 수 있다.
현지에 계신 한국 개발자들 몇분과 만나서 이야기 해보면 인력들이 정말 다이나믹하게 움직이는 것을 알 수 있었습니다. 개발자 스스로 또는 회사의 필요에 따라 채용/해고 등이 자연스럽게 일어나고 그것에 따라 회사의 정책, 서비스 등이 기민하게 움직이고 있었습니다. 물론 그런 조직에서도 사내 정치, 라인이 존재합니다. 새로운 매니저가 오면 그 매니저 중심으로 라인이 형성되는 것은 모든 조직이 동일한 것 같습니다.

4. 비즈니스는 한국과 미국 모두 같다.
얼굴을 자주 보고 친하게 지내야 하고, 인적 네트워크를 형성해야 하는 등등의 선행되어야 물건을 팔 수 있습니다. 그리고 꾸준히 회사의 브랜드 가치를 쌓아야 합니다.

5. 서비스적인 접근이 필요
4번에 대면해서 네트워크를 형성해야만 물건을 팔 수 있다고 했는데 서비스인 경우는 조금 다른 것 같습니다. 현재 미국내에서는 많은 클라우드 서비스가 성공하고 있고 기업들은 설치형보다는 이제는 서비스쪽으로 전환되어 가고 있는 느낌이었습니다. 따라서 솔루션도 이제는 서비스 형태로 제공되어 지는 것이 훨씬 더 유리한 것 같습니다.
2번에서 제품이 되어야 하고 evaluation 기능 등이 있어야 한다고 했는데 서비스로 제공할 경우 좀 더 쉽게 접근할 수 있을 듯하였습니다.

6. 규모가 다르다.
국내 서비스의 경우 자체 트래픽 만으로 많은 기능을 하려다 보니 사용자가 많지 않으면 데이터가 많을 수가 없습니다. 그리고 연동되는 다른 서비스들 역시 사용자가 그렇게 많은 경우는 드뭅니다.
미국의 경우 자체 서비스는 규모가 작다 하더라도 연동되는 서비스가 크면 연됭되는 기능에서 발생되는 로그 등의 데이터가 어마어마 합니다. 제가 방문한 특정 회사의 경우 로그 데이터가 이미 수 TB/일 이상인 경우도 있었습니다.
그리고 어떤 회사에서는 cloumon 커버 가능한 대수가 몇대이냐? 자기들은 기본 수천대 이상이다. 라고 하였습니다. 아직 cloumon은 거기까지는 어렵다고 봐야죠. 물론 아키텍처를 개선하면 가능하고 그런 개선 방안에 대해서는 토론을 같이 했습니다만... ㅋㅋㅋ
따라서 미국 시장에서 서비스, 제품을 내놓기 위해서는 이런 상황에 대한 고려와 테스트도 많이 수행되어야 할 것 같았습니다.

7. 미국도 아직 준비 단계이다.
미국은 많이 준비된 것 같았지만 실리콘 밸리 내에 있는 서비스 회사들도 아직 많은 준비가 안되어 있는 것 같았습니다. 야후, 페이스북 등 일부 기술 선도 회사를 제외한 서비스 회사들은 국내와 바슷하게 하둡 설치하고 사용성을 확인해보는 수준 정도 였습니다. cloumon을 도입해서 잘 사용하기 위해서는 하둡을 잘 사용하고 있다는 전제조건이 있어야 하는데 아쉬운 부분이었습니다. 하지만 다른 시장에 대한 가능성은 보고 왔습니다. 국내처럼 하둡 및 에코 시스템에 대한 컨설팅 영역입니다. 이 부분은 언어적인 문제만 해결하면 가능성은 많을 것 같습니다.

8. 영어는?
저 같은 경우 막말로 영어는 거의 못합니다. 듣는 것도 잘 못듣고 말하는 것은 경상도 억양이 발음에 섞여 나올 정도입니다. ㅋㅋㅋ 이번 출장에는 영어 잘하시는 분과 같이 가서 대부분 설명은 그 분이 많이 했습니다.
미팅하면서 느낌은 기술 컨설팅 수행하는 데 경우라면 2 ~ 3개월 같이 지내다 보면 가능할 것 같다 였습니다. 물론 국내에서도 준비를 좀 해야 하겠지만요. "너무 두려워 할 필요는 없을 것 같다" 입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

하둡 클러스터 하나만 필요한가?

(김형준) — Tue, 26 Mar 2013 17:57:55 +0900

하둡 기반으로 빅데이터 플랫폼을 구축하는데 있어 플랫폼 구축 단계에서 많이 놓치는 것이 있는데 운영 단계로 넘어 갔을 때 어떻게 하둡 클러스터를 구성할 것인가에 대한 그림이다.
일반적으로 초기 단계에서는 raw 데이터 저장 후 분석 이슈가 주로 다루어 지는 내용이기 때문에 서버의 사이징 등을 데이터의 용량과 분석에 촛점을 맞춘다. 이 단계가 지나서 어느 정도 의미 있는 데이터를 찾게 되면 이 분석 작업을 정기적인 작업으로 전환하고 분석 결과를 RDB 또는 HBASE 등과 같은 실시간 데이터 제공이 가능한 저장소에 저장을 해야 한다.
이 시점에 되면 정기적인 업무는 안정적인 실행 시간을 보장 받아야 하며 혹시라도 분석 결과 데이터가 커 HBase에 저장해서 제공하는 형태라면 HBase의 성능도 고려를 해야 한다. 하나의 하둡 클러스터만 운영하는 경우에는 곤란해진다. 다양한 측면으로 데이터를 분석하는 작업은 여전히 필요하게 되고, 이 작업은 클러스터의 리소스를 대부분 가져가게 된다. 물론 fair-scheduler 등과 같은 스케줄러를 사용하여 리소스를 나누어서 사용할 수는 있지만 HBase와 같은 솔루션이 하둡 위에 올라가는 상황이라면 서비스에 필요한 성능을 보장 받을 수 없게 된다.
이때 취할 수 있는 방법은 다음과 같다.

1. 하나의 클러스터 전체 규모를 키운다.
2. 클러스터를 분리하여 서비스용, 개발/분석용으로 구분한다.

1번의 경우에도 여전히 안정적인 서비스 품질을 보장 받기 어렵기 때문에 가능하면 2번 방으로 가는 것이 좋을 것이다.

따라서 처음 도입 단계에서는 예상하기 어렵겠지만 어느 정도 분석에서 성과가 나타나기 시작하는 시점에서는 운영용 클러스터를 도입하는 것을 고려하여 예산, 인프라 계획 등을 잡는 것이 좋다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

하둡 어플라이언스 및 유지보수 대한 생각

(김형준) — Tue, 19 Mar 2013 01:02:38 +0900

빅데이터 외부 프로젝트를 수행하면서 새롭게 하둡을 도입하고자 하는 여러 기업을 만나 보았습니다. 이때 항상 물어 보는 것이 유지보수에 대한 내용입니다. 그래서 하둡이나 하둡 에코 시스템에 대한 유지보수에 대한 이야기를 좀 해볼까 합니다.
하둡 관련 프로젝트를 하면서 필자가 항상 주장하는 것은 반드시 내부 기술 역량을 갖추어야 한다는 것입니다. 내부적으로 갖추어여 할 역량은 대략 다음과 같은 것이 있습니다.

1. Hadoop 및 에코 시스템에 대한 전반적인 이해
2. 시스템 운영 능력 및 문제해결 능력
3. Hadoop 및 에코 시스템을 이용한 응용(분석 프로그램) 개발 능력

1, 3번 항목에 대해서는 실제 도입하고자 하는 회사에서도 어느 정도 인식하고 있는 부분입니다. 2번 항목의 경우 대부분의 기업은 인프라 운영 부서로 업무를 이관하려고 합니다. 하지만 하둡의 현재 솔루션 상태를 보면 인프라 운영 부서로 운영 업무를 이관하는 것이 쉬운 상황은 아닙니다. 그 이유를 몇가지 생각해보면 다음과 같습니다.

- 하둡과 에코 시스템은 복잡한 분산 아키텍처입니다. 실제 사용되는 데몬의 종류도 많고 데몬의 상태도 다양합니다. 이런 복잡한 아키텍처를 제대로 이해해야만 운영할 수 있는데 인프라 운영 조직에서 복잡한 아키텍처를 이해하면서까지 운영할 수 있는 조직은 많지 않습니다.
- 인프라 운영 부서의 대부분의 중요 미션은 장애율을 줄이는 것입니다. 거기에는 하드웨어 장애까지 포함하고 있습니다. 하지만 하둡이나 하둡 에코 시스템의 경우 기존 시스템보다 CPU, 디스크, 메모리 등을 시스템의 극한 상황까지 사용하는 경우가 많으며 다른 업무의 서버에 비해 장애가 자주 발생합니다. 하지만 서버에 장애가 발생하였다 하더라고 즉시 대응할 필요가 없는 아키텍처를 가지고 있는 것이 하둡인데 인프라 운영 조직의 특성상 이런 장애 상태를 보고만 넘어가지 않을 가능성이 많습니다. 장애 보고서와 재발 방지 대책 등등... 기존의 프로세스대로 운영을 하게 되면 운영하는 분들도 무지 스트레스를 받을 겁니다.
- 하나의 문제가 전체의 문제가 될 수도 있고 하나의 문제가 아무런 문제를 발생시키지 않을 수도 있는 복잡한 상황
- 원인 파악의 어려움
- 다양한 버전의 오픈소스

따라서 인프라 운영 조직의 경우 당연히 기존의 방식과 동일하게 벤더에서 제공하는 하둡 어플라이언스를 도입하는 것이 더 좋을 것 같다라는 의견을 많이 제시합니다. 하둡 어플라이언스를 도입한다고 해서 앞의 운영 문제가 해결될까는 의문입니다.
아직 필자도 하둡 어플라이언스를 제공하는 벤더의 유지보수 SLA을 보지는 못했습니다. 하지만 추측하건데 하드웨어 장애에 대한 즉시 대응이라던가, 장애 원인 파악 보고서 작성 등과 같이 기존의 엔터프라이즈 시스템에서 제공되던 많은 항목들이 없어지거나 수준이 낮아졌을 가능성이 높습니다.

버그나 문제가 발생할 경우 다음과 같은 해결 방법이 있습니다.

1. 오픈소스 커뮤니티의 버그 패치나 문제 해결 방법에 의존
2. 개발팀 스스로 버그 픽스 또는 문제 해결
3, 어플라이언스의 경우 제공하는 벤더에서 패치를 제공하거나 문제를 해결

벤더의 제품을 구매하는 경우 3번을 기대하고 구매하는 것인데 현재의 하둡 어플라이언스를 제공하는 업체들은 자체 하둡 코어를 수정할 수 있는 능력이나 문제를 해결할 수 있는 능력이 높은 것 같지는 않습니다. 대부분은 Cloudera 배포판을 사용하거나 아파치 버전을 조금 수정해서 사용하는 정도라고 볼 수 있습니다. 따라서 어플라이언스를 도입하고도 오픈 소스 커뮤니티에 의존하거나 심지어는 자체 해결해야 할 경우가 많아질 가능성이 높습니다. 또 하둡의 파편화는 어떻게 해결할 것인지도 고민입니다.
물론 어플라이언스를 도입했을 때 장점은 있습니다. 그런 문제 발생 시 문제의 원인, 문제의 책임을 인프라 조직이 아닌 벤더에게로 전가시킬 수 있습니다. 이 장점을 제외한다면 하둡 어플라이언스를 구매했을 때의 장점은 거의 없다고 할 수 있습니다. 물론 많은 업체들이 이런 이유때문에 벤더 솔루션을 선정하는 경우도 많습니다.

그러면 하둡을 도입하고자 하는 기업은 하둡의 운영을 어떻게 해야 할까요? 당장의 대답은 개발팀에서 운영을 같이 해야 한다는 것입니다. 필자는 기회가 있을때 마다 어플라이언스 도입 비용으로 내부 기술력을 키우는데 투자하는 것이 더 좋다고 강조하고 있습니다. 운영의 주체를 지금 당장 인프라 운영 조직으로 넘기기 보다는 내부 개발 조직에서 기술력을 내재화 시키고 이를 기반으로 OS/하드웨어는 인프라 운영 조직에서 하둡 이후 부터는 내부 개발 조직에서 운영하는 것이 좋다고 생각합니다.
현재의 하둡은 단순히 솔루션을 사용하는 관점이 아니라 다양한 에코 시스템을 연계하여 하나의 거대한 데이터 처리 플랫폼을 만들어야 하는데 이를 위해서는 내부 개발팀에서 운영도 같이 병행하여 빠른 시간에 기술력을 올려야 하기 때문입니다.

마지막으로 빅데이터를 추진하는 대부분의 기업은 대기업입니다. 국내 소프트웨어의 경쟁력을 확보한다는 큰 뜻을 위해서라도 이런 기회에 오픈 소스 중심의 생태계를 만들어 보는 것도 좋지 않을까 제안해봅니다. 오픈 소스에서는 외국 벤더도 어쩔 수 없습니다.

두서 없이 적다 보니 내용 정리가 잘 안되지만 제 의견은 나름 전달할 수 있을 것 같아 포스팅합니다. 글 중 잘못된 내용있으면 알려주시면 바로 수정하겠습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

HBase 0.94.6 하위 버전에서 버그 하나...

(김형준) — Thu, 14 Mar 2013 11:03:49 +0900

HBase 사용시 ColumnCountFilter나 PageFilter를 자주 사용하는데 0.94.6 하위 버전에서는 다음과 같은 버그가 있습니다.

https://issues.apache.org/jira/browse/HBASE-6132

즉 위의 두 필터를 FilterList와 같이 사용하게 되면 데이터가 안나오는 버그입니다.
기본 버전의 경우 FilterList.java 패치만 적용해서 컴파일 후 다시 실행하면 바로 적용됩니다.
이 버그 모르면 코드 잘못된 줄 알고 무지 삽질합니다. 참고하세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

mapreduce 시스템 디렉토리 권한 설정

(김형준) — Thu, 28 Feb 2013 00:47:05 +0900

하둡 실행 유저(superuser)가 아닌 다른 사용자로 mapreduce 프로그램을 실행 시키기 위해서는 하둡 파일 시스템에 대한 접군권한이 필요한데 접근 권한에 대한 설정이 상황별에 따라 이상하게 동작하는 경우가 있다.
시간 내어 코드를 좀 살펴 보았는데 원인은 다음에 있었다.

JobTracker가 시작(재시작) 되면 mapred-site.xml 설정에서 "mapred.system.dir"에 설정된 디렉토리가 hdfs에 없으면 생성한다.
기본 값은 /tmp/hadoop-${hadoop-user}/mapred/system 이다.
이 디렉토리의 권한은 "rwx------"으로 생성한다.
이미 디렉토리가 존재하고 "rwx------"이 아니면 "rwx------"으로 수정한다.
이 디렉토리는 jobtracker가 관리하는 디렉토리로 다른 사용자에게는 필요 없는 디렉토리 이기 때문에 이렇게 생성한다.

그리고 사용자의 작업과 관련된 파일들은 "mapreduce.jobtracker.staging.root.dir" 설정 값으로 저장하는데 기본 값은 /tmp/hadoop-${hadoop-user}/mapred/staging 이다.

여기서 주의할 점은 jobtracker의 시스템 디렉토리와 사용자별로 사용하는 스테이징 디렉토리가 모두 /tmp/hadoop-${hadoop-user}/mapred 가 상위디렉토리이기 때문에 /tmp 디렉토리가 없는 경우 JobTracker가 system 디렉토리의 상위 디렉토리까지는 "rwxr-xr-x" 로 생성한다.
이 상태에서 작업이 실행되어 특정 사용자의 작업을 위해 staging 디렉토리를 생성해야 하는데 쓰기 권한이 없기 때문에 작업을 실행하지 못하게 된다.
해결 방법은 클러스터 실행 후 다음과 같이 권한을 변경한다.
bin/hadoop fs -chmod 777 /tmp
bin/hadoop fs -chmod 777 /tmp/hadoop-hadoop
bin/hadoop fs -chmod 777 /tmp/hadoop-hadoop/mapred
bin/hadoop fs -chmod 700 /tmp/hadoop-hadoop/mapred/system

아니면
/tmp를 모두 삭제하고 jobtracker를 중지한 다음
/tmp 권한을 777로 설정하고 jobtracker를 다시 실행한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Hadoop DistCp 독특한 문제

(김형준) — Thu, 14 Feb 2013 15:35:37 +0900

계속 새해 복많이 받으세요 라는 글만 있어서 뻘쭘함이 있어 오랜만에 팁하나 올립니다. 최근 Hadoop 클러스터간 데이터 이동하려고 DistCp를 사용했는데 네트워크 bandwidth 때문에 copy map 갯수를 5개로 주고 실행했는데 복사 성능이 너무 느리게 나왔습니다.
몇 가지 확인한 결과 5개의 copy map task가 하나의 TaskTracker에 할당되어 한 서버의 네트워크 용량만큼만 복사되는 문제가 있었습니다.

JIRA를 확인해보니 다음과 같은 문제가 있다고 보고되어 있습니다.

https://issues.apache.org/jira/browse/MAPREDUCE-2734

DistCp의 map task 할당 정보에는 tasktracker 정보가 없는데 이럴 경우 기본 스케줄러는 하나의 TaskTracker heartbeat에 하나의 Task 만 할당하도록 되어 있습니다.
하지만 fair-scheduler를 사용할 경우 TaskTracker의 remain slot 만큼 할당하도록 되어 있어 첫번째 접속해서 heartbeat을 보낸 TaskTracker가 5개를 모두 다 할당 받는 문제였습니다.
해결방법은 fair-scheduler.xml에 다음과 같은 옵션 설정

<name>mapred.fairscheduler.assignmultiple</name>

<value>false</value>

</property>

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

2012년을 보내며

(김형준) — Sun, 30 Dec 2012 14:06:19 +0900

정신없이 달려온 2012년도 끝나가네요. 2012년은 큰회사에 있으면 겪어 보지 못했을 많은 일을 걲었던 한해였던것 같습니다.
2012년 한해 동안 저를 알고 저와 만났던 모든 사람들에 미안한 마음과 감사의 뜻을 전합니다. 제가 생각했던 이상을 만들기 위해 막말을 하는 경우도 있었습니다. 악의가 아니라 조금이나마 소프트웨어의 생태계를 바꾸기 위한 몸부림이라고 이해해 주시기 바랍니다.

한분 한분 모두 메일이나 찾아뵙고 인사드려야 겠지만 제 블로그를 통해 감사의 마음을 전합니다.
2013년 건강하시고 복 많이 받으세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

oozie에 사용자 function 추가하기

(김형준) — Thu, 27 Dec 2012 11:58:07 +0900

오랜만에 글입니다. 요즘은 새로운 기술을 보는 것보다 기존에 알고 있는 기술 팔아먹는 쪽에 정신없이 지내다보니 새로운 글로 쓸게 별로 없네요. ㅋㅋㅋ

이번 주제는 간단하게 oozie에 사용자 function 추가하는 방법입니다. 방법은 간단한데 oozie 쪽 문서가 워낙 취약해서 xml 파일을 다 뒤지고 소스 코드를 봐야만 나오는 내용이라서요.

다음과 같이 임의의 클래스를 만들어서 function을 정의합니다.
예제는 format에 따른 현재시간에 대한 문자열을 반환하는 코드입니다.

public class OozieCustomFunctions {
public static String currentTime(String format) {
if(format == null) {
format = "yyyyMMdd";
}
SimpleDateFormat df = new SimpleDateFormat(format);
return df.format(new Date((System.currentTimeMillis())));
}
}

oozie-site.xml 에 다음 내용 추가

<property>
<name>oozie.service.ELService.ext.functions.workflow</name>
<value>
currentTime=org.cloumon.gruter.OozieCustomFunctions#currentTime
</value>
<description></description>
</property>

여러 개인 경우는 "," 로 구분

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

곧 오픈할 oozie workflow 디자이너 및 관리 기능

(김형준) — Wed, 12 Sep 2012 22:49:20 +0900

곧 오픈할 oozie workflow 디자이너 및 관리 기능 화면입니다. 프로젝트 2개 마무리 하고 짬 나는 시간을 이용해서 열코 모드로 거의 완성 단계..
Oozie 3.3 버전에는 자체 디자이너를 가지고 있어 약간 흥행에서는 떨어지지만 기능은 훨씬 거 좋습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

빅데이터 분석이 먼저냐? 인프라가 먼저냐?

(김형준) — Tue, 21 Aug 2012 17:11:19 +0900

"빅데이터 인프라 도입보다 `분석 역량` 먼저 갖춰야" 라는 제목의 기사를 읽으면서 제 의견을 잠깐 정리해 보았습니다.

http://media.daum.net/digital/all/newsview?newsid=20120821155133827

직접 발표를 들은 것이 아니기 때문에 기사의 내용만 보면 플랫폼을 갖추기 전에 먼저 기업의 분석 역량을 갖추고 도입 시에는 반드시 ROI를 잘 분석해서 도입해야 한다는 의견입니다.
저는 항상 반대의 의견을 주장해 왔었습니다.
즉 무엇을 분석하기 전에 먼저 플랫폼을 갖추고 데이터를 수집하라. 무엇을 분석할지도 모르는데 ROI는 의미없다.
이 주장의 핵심은 오픈 소스와 x86 장비를 이용하여 저렴한 비용으로 플랫폼을 갖추어야 한다는 것입니다. 국내 많은 회사들은 10 ~ 20대 정도로 하둡 클러스터를 구성하면 현재 기업의 데이터를 이용하여 저장, 분석하는 작업은 대부분 수행이 가능합니다. 이 비용은 하드웨어 비용만 보면 1 ~ 2억 정도입니다. 여기에 오픈 소스 기반이니 소프트웨어 비용은 거의 들지 않으며 이를 관리하거나 기능을 만드는 엔지니어 비용으로 연 2 ~ 3명 정도 투입할 경우 전체 5억 미만으로 플랫폼을 갖출 수 있습니다.
기사에서도 막대한 비용을 들여 인프라를 갖추기 이전에 분석 역량을 가져야 한다고 하지만 기업 입장에서 5억이 막대한 비용일까요?
또 다른 관점에서 국내 많은 기업들은 데이터에 대한 관리 체계가 부족하여 부서간, 시스템간 데이터 공유가 어렵습니다. 그리고 데이터 공개가 잘 되어 있지 않아 분석하고 싶어도 데이터가 없는 경우가 대부분입니다.
이런 현실에서 데이터를 모아서 분석하는 관리 체계를 갖추어야만 분석 역량을 갖출 준비가 되는 것입니다. 아무리 해외 논문을 많이 보고 사례 연구를 많이 해도 막상 데이터가 없으면 아무것도 할 수 없습니다. 제가 포털에 있을때 몇분은 이 회사에 들어온 이유가 데이터가 있기 때문이라고 했습니다.
여러 기업의 빅데이터 프로젝트의 내부를 보면 가장 시간이 많이 걸리고 어려운 부분이 바로 데이터를 모으는 일입니다. 데이터를 모으는 시스템을 구축하는 것이 어려운 것이 아니라 부서간의 협의를 얻고 시스템을 연동하는 부분이 더 어렵다고 할 수 있습니다.
제가 주장하는 플랫폼이나 인프라는 물리적인 서버나 시스템이기도 하지만 한편으로는 이런 시스템을 구축하면서 기업 내부의 데이터에 대한 시각을 바꾸고 부서간의 협의 체계를 정의하고 데이터의 공유 범위를 정의하는 등의 프로세스를 만드는 것도 포함하고 있습니다.
닭이 먼저냐 달걀이 먼저라는 논란에서 빠져 나올 수 있는 방법은 지금 당장 실행할 수 있는 것을 하면서 그것이 닭인지 달걀인지 스스로 알아나가는 것이 최선이라고 생각합니다.
여러분들은 어떻게 생각하시나요?

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.