cloumon 미국 pre-sales 후기

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

이번 출장의 목적은 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개월 같이 지내다 보면 가능할 것 같다 였습니다. 물론 국내에서도 준비를 좀 해야 하겠지만요. "너무 두려워 할 필요는 없을 것 같다" 입니다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 김형준


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

하둡 실행 유저(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를 다시 실행한다.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 김형준


2012년을 보내며

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

한분 한분 모두 메일이나 찾아뵙고 인사드려야 겠지만 제 블로그를 통해 감사의 마음을 전합니다.
2013년 건강하시고 복 많이 받으세요.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 김형준


oozie에 사용자 function 추가하기

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

이번 주제는 간단하게 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>

여러 개인 경우는 "," 로 구분
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 김형준


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

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

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

Posted by 김형준


최근 기술에 대한 meetup 공지

최근 기술 동향에 대한 meetup 공지입니다. 주제는 다음과 같습니다.
1. kafka: 유동민 님
2. HCatalog & Templeton: 김영우님, 김대근님
3. sqoop: 홍태희님
4. Storm: Iryoung Jeong 님
5. Pregel, GoldenORB, Giraffa: 공용준님

- 일자: 7/18(수) 18:00 ~
- 장소: 강남역 nexr 사옥 까페, http://www.nexr.co.kr/nexrcorp_en/company/location.php
- 참석 인원: 60명
- 참석 신청: http://www.facebook.com/groups/cloudtech/
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by 김형준


오픈 소스 코드 분석을 위한 팁

MySQL, Apache, Tomcat 등과 같은 오픈 소스는 매뉴얼이나 문서, 책 등도 많이 나와 있으며 오픈 소스이지만 솔루션 자체도 안정적이라서 특별한 이유가 아니면 소스를 분석할 필요는 없습니다.
하지만 하둡이나  NoSQL  등과 같은 솔루션은 문서도 부족하지만 문서로만 설명할 수 없는 복잡한 내용으로 구성되어 있는 솔루션이 많습니다. 따라서 제대로 솔루션을 사용하거나 운영하기 위해서는 반드시 소스 분석이 필요하게 되었습니다.
 
최근 루씬 기반의 분산 검색 엔진 솔루션인 ElasticSearch를 분석할 필요가 있어 몇일간 삽질했었는데 삽질하면서 제 나름대로 오픈 소스 분석에 사용하는 몇가지 팁을 정리했습니다. 제가 주로 사용하는 프로그램언어가 자바라서 대부분 자바 기준으로 되어 있습니다.

- 해당 솔루션에 대한 기본 지식을 먼저 익혀라.
하둡을 분석하려면 구글에서 발표한 논문을 읽어 봐야하고  HBase를 분석하기 위해서는 BigTable 논문을 읽어야 한다,
분석하고자 하는 솔루션에 대한 이론적인 배경 지식이 없는 상태에서 소스 코드를 바로 보면 그냥 스파게티처럼 얽혀 있는 코드를 보고 있는 느낌이 들것이다. 

- 특정 알고리즘에 대해서는 코드가 더 보기 쉬울때도 있다.
전체 코드 중 일부는 어떤 알고리즘이나 기법을 구현한 코드가 있을 수 있는데 이 경우 해당 솔루션내에 있는 코드를 먼저 이해하기 보다는 그 알고리즘만 구현된 공개된 코드를 찾아서 보는 것이 알고리즘을 문서로 이해하는 것보다 훨씬 빨리 이해할 수 있다.

- 분석하고자 하는 프로그램 언어에 대한 기본 지식은 필수이다.
두말하면 잔소리...

- 본인 PC에 빌드 및 실행 환경을 구축하라.
코드 분석을 빨리하기 위해서는 분석에 필요한 로그를 추가하여 재 컴파일한 후 실행하면서 로그를 확인하는 것이 좋다. 단순 코드만 보면 특정 연산의 흐름이 어떻게 진행되고 있는지를 파악하기 어려운 경우가 많기 때문이다.
최근의 오픈소스들은 분산 환경에서 운영되는 경우가 많은데 이 경우라 하더라도 개발자의 PC(가능하면 노트북)에 빌드와 실행환경을 모두 구성하는 것이 좋다. "좋다"라는 정도가 아니라 필수 사항이라 할 수 있다.
최근 오픈 소스는 복잡도의 증가와 연관된 다른 오픈 소스가 많아서 eclipse 등에 빌드 환경을 구성하는 것이 쉬운 작업은 아니다. 빌드 및 실행환경을 구성하는 것만으로 코드 분석의 50%는 진행되었다고 할 수 있다.
그리고 가능하면 노트북에 환경을 구성하여 회사, 집, 이동중에도 지속적으로 분석할 수 있는 환경을 갖추는 것이 좋다.
참고로 필자의 노트북은 맥북프로인제 최근 리눅스 기반 오픈 소스 솔루션이 많이 나오고 있는데 업무용 PC와 개발용 PC를 같이 사용하는데에는 이만한 노트북은 없는 것 같다. 메모리 8GB에 SSD(필자는 SATA) 정도면 왠만한 시스템은 다 실행할 수 있다.
필자의 경우 MySQL, ZooKeeper, Hadoop, Flume, ElasticSearch, HBase 등은 노트북에서 실행한다.  그리고 필자의 eclipse에는 프로젝트가 100개 이상으로 대부분은 오픈 소스 프로젝트 코드를 구성한 것이다.
일부 대기업의 경우 보안 등의 문제로 노트북의 외부 반출을 엄격하게 제한하고 있는데 이러면서 소프트웨어에 투자하겠다는 등의 소리는 하지 말았으면 한다. 소프트웨어에 대한 실력은 지정된 자리에 앉아서만은 결코 이룰수 없다.

사용자 삽입 이미지

- 자신에게 질문을 많이 하라.
오픈 소스 개발자라고 해서 하늘에서 떨어진 개발자는 아니다. 대부분 비슷한 교육을 받고 비슷한 경험을 하고 있다. 따라서 특정 기능에 대해서 나라면 어떻게 개발했을까? 라고 자신에게 질문을 던지고 머리속에 어떻게 구현할 것인지를 먼저 그려본다. 처음에는 많이 틀리겠지만 코드를 많이 보고 연습을 많이 하면 이것도 얼추 많이 맞춘다. 

- 분석하면서 문서로 정리하라.
분석을 하면서 그림 또는 문서로 정리를 해라. 굳이 UML이 아니더라도 ppt 같은 도구로 정리하면 된다. 이렇게 중간 중간에 정리하면 머리속에서만 빙빙 돌던 생각이 정리될때가 많다. "분석이 다 된 다음에 깔끔하게 정리해야지" 라는 생각이면 거의 정리는 못한다고 봐야 한다. 나중에 정리하려면 정리도 어렵고 생각도 잘 나지 않는다.
다음은 필자가 2006년에 분석한 Hadoop의 MapReduce 처리를 정리한 그림이다.

사용자 삽입 이미지

-  LOG level을 DEBUG로 설정하라.
배포되는 패키지는 대부분 Logger의 설정이 INFO 또는 WARN으로 설정된 경우가 많다. 더 많은 정보를 얻기 위해서는 logger 설정의 DEBUG로 설정한다. DEBUG로 설정할 경우 너무 많은 로그 메시지가 나올 수 있는데 패키지 수준에 따라 적절하게 LOG level을 설정한다.

- 디버거의 breakpoint 기능을 활용하라.
집중적으로 분석하고 싶은 구간은 디버거의 breakpoint 기능을 이용하여 step 단위로 실행하면서 각 변수의 변화 상태를 확인한다.

-  System.out.println 보다는  Thread.dumpStack()을 활용하라.
객체지향 구현의 단점이 상속 관계에 있으면 어떤 클래스가 실제로 호출되는지 실행환경에서 결정되는 경우가 많다.
특히 자바의 경우 reflection이나 Injection을 사용하게 되면 어떤 객체가 호출되는지 코드만 봐서는 이해하기 어려운 경우가 많다. 그리고 해당 로직이 어떤 경로를 거쳐 호출되는지 찾기 어려운 경우가 많다.
이 경우 앞에서 설명한 디버거를 이용할 경우에도 어디에 breakpoint를 걸어야 할 지 애매한 경우가 많은데 이때 Thread.dumpStack() 코드를 적절한 위치에 추가하면 전체 호출 흐름을 볼 수 있다.

- 당장 관심있는 부분부터 집중적으로 파악하라.
방대한 시스템의 경우 전체를 보다 보면 금방 지루하고 갈 곳을 읽어 버리는 수가 많다. 당장 필요하거나 관심있는 부분부터 집중해서 보는 것이 좋다. 하둡 파일 시스템의 경우 클라이언트 모듈인 FileSystem과  DFSClient부터 보면서  해당 기능과 연결되어 있는  NameNode, DataNode의 method를 파악하는 것이 좋다.

 - 그래도 어려우면 초기 버전을  다운로드 받아 분석하라.
복잡해보이는 오픈소스도 초창기 버전은 단순하게 기본 기능만 구현되어 있는 경우가 많다. 버전이 올라가면서 개발자들이 많이 참여하게 되고 코드는 점점 복잡해지고 기능도 많아지게 된다. 초창기 버전에서는 핵심 기능에만 집중하는 경우가 많기 때문에 핵심 기능을 분석하기에는 초창기 버전이 좋다.

대충 생각나는 것만 정리해 보았습니다. 더 좋은 팁 있으면 댓글 환영합니다.

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

Posted by 김형준


Bamboo: Data pipeline 개요

명색이 기술 블로그를 지향하면서 요즘은 기술적인 이야기보다 다른 이야기로 많이 채워졌네요. 최근 저의 근황이 기술에 대한 연구보다는 서비스 개발, 프로젝트 진행 등에 많은 시간을 투자하다 보니 그런것 같습니다. 최근 논문 한편 볼 시간도 없는 상황입니다.
그래서 이본 글에서는 알려진 기술이나 오픈소스에 대한 소개보다는 그루터의 서비스(www.seenal.com) 또는 내부 플랫폼에 사용하고 있는 Bamboo에 대해 간단하게 소개 정도만 해볼까 합니다.
Bamboo가 정확하게 어떤 분류 이름을 달아야 할지는 애매해서 일단 제목에서 Data pipeline이라고 했습니다. 내부적으로 Data bus 등이라는 용어가 어떨까 하는 의견도 있습니다.

과거에는 데이터 분석, 처리에 있어 데이터량이 작거나 트랜젝션이 많지 않으면 데이터(트랜젝션) 발생 즉시 데이터베이스 등에 저장하고 이를 웹 화면 또는 질의를 통한 분석을 하였습니다. 데이터가 많으면 주기적으로 안정적인 저장소에 저장하거나 분석 작업을 수행하였습니다.
최근 빅데이터라는 개념이 나오면서 데이터의 크기와 상관없이 비즈니스 요구에 맟는 데이터의 처리 속도가 중요하게 되었습니다. 즉, 데이터의 크기에 상관없이 요구사항이 즉시 처리 해야 하는 경우라면 그 요구사항에 부합되게 처리를 할 수 있는 플랫폼 또는 기술이 경쟁력이 되는 시대가 온 것입니다. 이를 지원하기 위한 오픈소스 진영에서도 Storm, S4 등과 같은 솔루션이 나오고 있으면 조금은 다르긴 하지만 데이터 수집 및 저장에 이르는 일련의 흐름을 쉽고 유연하게 처리할 수 있는 Flume, Chukwa, Scribe 등과 같은 솔루션도 있습니다. 이런 솔루션을 사용하여 끊임없이 들어오는 데이터(트렌젝션)에 대해 연속적(Stream)으로 처리할 수 있겠지만 그루터에서는 자체적으로 Bamboo라는 솔루션을 개발하여 사용하고 있습니다.

Bamboo에 대한 요구사항은 다음과 같습니다.    
- 요구사항
  . 끊임없이 전송되는 데이터에 대해 측시 처리 가능해야 한다.
  . 분산되어 발생되는 데이터의 흐름을 쉽게 제어할 수 있어야 한다.
  . 일부 서버의 장애 또는 점검, 비즈니스 로직 변경 등으로 데이터를 받을 수 없는 상황에서도 데이터는 계속 흘러가야 한다.
  . 데이터를 처리할 수 있는 로직은 쉽게 추가하거나 제거할 수 있어야 한다. 
  . 데이터 처리 로직에 부하가 발생할 경우 이를 다시 분산해서 처리할 수 있어야 한다.
  . 서버의 장애, 점검 등의 상황에서는 일부 데이터의 유실 또는 중복은 발생할 수 있다.

한줄로 요약하면
"데이터는 계속 흘러야 하고 그 흐르는 데이터는 누구든 쉽게 언제든지 가져다 쓸수 있어야 한다."
입니다.

다른 요구사항은 장점에 대한 요구사항이지만 데이터의 유실 또는 중복이 발생할 수 있다라는 요구사항은 단점에 해당하는 요구사항입니다. 하지만 분산된 환경에서 끊임없이 전송되는 외부 데이터를 유실, 중복없이 관리할 수 있는 솔루션을 개발하는 것은 많은 기술과 시간이 소요됩니다. Bamboo에서 처리하는 데이터의 속성이 소셜네트워크 데이터, 웹 페이지 데이터 등과 같이 외부 인터넷 서비스의 데이터가 주요 데이터이기 때문에 데이터 일부 유실이 되어도 다시 가져올 수 있고 중복은 백앤드에서 처리할 수 있는 구조를 가지고 있기 때문에 시스템을 복잡하게 만들지 말자는 요건으로 요구사항에 추가된 것입니다.
이런 요구사항에 맞추어 다음과 같은 구조를 가지고 있는 솔루션을 만들었습니다.

사용자 삽입 이미지

- 구성요소
  . Bamboo Client: 데이터 수집기(Crawler)에 내장되어 수집되거나 생성된 데이터를 Collector로 전송하는 기능
  . Bamboo Collector: client에서 전송된 데이터가 모이는 허브 역할을 수행하고 Collector에서는 비즈니스 로직을 처리하지 않고 즉시 백앤드(Group Connector)로 전송하는 기능. 즉 데이터 허브 역할 수행. Group Connector로의 데이터 전송은 동일한 데이터를 모든 Connector에게 전송.
  . Group Connector: Collector로 부터 데이터를 받아서 비즈니스 로직을 처리할 각 Receiver 로 데이터를 전송하는 기능. 데이터 스위치 역할 수행. 하나의 Collector에는 여러개의 Group Connector가 붙을 수 있으며 동적으로 추가, 제거가 가능.
  . Receiver: 실제 비즈니스 로직을 처리하는 모듈이 탑재되어 있으며 하나의 Group Connector에는 여러개의 Receiver가 붙을 수 있으며 데이터 전송 all 또는 round robin 방식이 있다. Receiver도 동적으로 추가, 제거할 수 있다.
 
이런 구성이 필요 했던 이유는 서버 등의 부족으로 어떤 서버에서 처리하던 일을 필요에 따라(해당 서버는 다른 역할을 수행하게 하거나 부하가 많이 발생하는 경우 등) 다른 서버로 옮기는 등의 작업이 수시로 발생하고 전체 데이터에 대해 원본 저장, 실시간 분석, 검색 인덱싱, 집계 등 여러 종류의 작업이 수행되어야 하고 이 작업의 종류도 수시로 변하기 때문입니다.
처음에는 하나의 Group Connector에 여러개의 Receiver를 붙여서 처리하다가 Group Connector에 부하가 걸리면 Collector에 새로운 Group Connector를 붙여 데이터 흐름을 하나 더 만들어서 처리하고 하는 등의 방식으로 데이터를 처리하고 있습니다.
위의 데이터 흐름은 고정된 것이 아니고 필요에 따라 Group Connector에 또 다른 Group Connector로 붙일 수 있는 유연한 구조를 가지고 있습니다.

- 사례: Bamboo를 이용한 IDC 이중화
그루터의 서버는 2개의 IDC에 분산되어 있는데 수집은 하나의 IDC에서만 하고 있습니다. IDC 이중화 또는 용도별로 데이터를 활용하기 위해서는 수집을 하지 않는 IDC에도 수집 데이터가 전송되어야 하고 이것은 배치가 아닌 수집 즉시 전달되어야 합니다. 그리고 데이터에 대한 처리도 양쪽 IDC에서 다양하게 추가되거나 제거될 수 있는 상황입니다.
이 요구사항을 만족시키기 위해 Bamboo를 이용하여 다음과 같이 구성하였습니다.

사용자 삽입 이미지


IDC간의 네트워크 비용이 비싸기 때문에 각각 개별 프로그램에서 필요에 따라 데이터를 전송할 경우 불필요하게 유사한 데이터가 전송되는 등의 문제가 있는데 Bamboo를 이용하여 IDC 이중화 데이터 흐름을 구성한 후 반대쪽 IDC에서는 해당 IDC에 설치된 Group Connector에 붙어서 작업을 수행할 수 있도록 구성하였습니다.

이런 구성은 Flume 등을 이용하여 구성하는 것도 가능합니다. 실제로 그루터에서는 Flume도 일부 사용하고 Flume을 효과적으로 관리할 수 있는 관리도구도 만들어서 제공하고 있습니다. 하지만 동적으로 쉽게 데이터의 흐름을 추가하고 바꾸고 하는 작업에서는 Bamboo를 이용하여 쉽게 처리하고 있습니다.
Bamboo는 아쉽게도 오픈소스는 아닙니다. 제가 강연에서 가능하면 기업 내부에서 만든 솔루션은 오픈 소스화 해줬으면 좋겠다고 외치고 있지만 정작 저희가 만든 솔루션은 오픈한 것도 있지만 오픈하지 않은 것도 있습니다. 아직 수익구조가 탄탄하지 않고 국내의 비즈니스 환경이 오픈 소스에 대한 비용 지불에 대한 구조가 정확하게 확립되지 않은 상황이다 보니 전략적으로 아직 공개를 하지 못하였습니다.
Bamboo는 한순간에 뚝딱 만든 솔루션이 아니라 플랫폼과 서비스를 운영하면서 지속적으로 개선하면서 현재의 모습으로 갖추게 되었습니다. 이것은 단순 구축형 프로젝트가 아닌 내부 서비스를 가지고 있기 때문에 지속적인 개선이 가능했던 것 같습니다.

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

Posted by 김형준


내 경력에는 조기축구회 4년이 있다.

NHN에 근무했다는 것이 이렇게 민망할때가 그지 없습니다. 오늘 아침에 출근 길에 다음 기사를 보고 드는 느낌이었습니다.

이해진 "편해서 네이버 왔다는 직원에 억장 무너져"
http://www.hankyung.com/news/app/newsview.php?aid=2012041550991&sid=0002&nid=000&ltype=1


기사를 보자마자 출근글 지하철 안이지만 한마디 적기로 마음먹었습니다.
모든 개발자라면 다 알고 있듯이 소프트웨어 개발은 이미 3D 직군입니다. 국내 많은 부분을 차지하고 있는 SI 프로젝트는 짧은 납기와 적은 비용으로 계속해서 변화하는 고객의 요구사항에 맞추기 위해 개발자들만 죽어 나가고 있는 형국입니다. 프로젝트 수주의 열매는 영업이 가져가고 프로젝트 성공에 대한 성과는 주 계약자인 SI 업체가 가져갑니다.
그렇다고 SI 업체에 있는 개발자는 좋은 환경일까요? 개발 업무를 수행하거나 새로운 기술을 연구, 학습하기는 커녕 보고 문서 작업, 외주 업체 관리 등의 과중한 업무로 개발 코드는 쳐다보지 못하고 있는 상황입니다.
그런 의미에서 보면 NHN의 개발 환경은 정말 "편한" 환경입니다. 서비스 오픈에 집중하여 사내 다양한 리소스(디자인, 기획, 품질 등)가 개발팀과 협업하고 있고 문서 중심의 보고 체계보다는 실무 중심의 보고 체계로 개발자가 개발에 집중할 수 있는 환경을 가지고 있기 때문입니다.
저도 삼성에 있다가 NHN으로 이직을 하였습니다. NHN이 훨씬 편했습니다. 여기서 편했다는 의미는 몸이 편했다는 것이 아니라 개발 환경이 편하고 치열하게 조직내/외부에서 경쟁했던 과거에 비해 조직 문화가 좋아서 편했다는 것입니다.
물론 일부 직원은 말그대로 편하게 지내는 분들도 있을 겁니다. 하지만 그런 일부 직원들의 모습을 보고 전체 직원, 개발자들을 한낱 조기축구회로 만들어 버리는 경영진을 보니 어이가 없습니다.
그러면 다음 질문에 대해서는 어떻게 생각하시나요? 인터넷 환경이 급격하게 변하는 시기에 경영진은 무엇을 했습니까? 모바일 붐을 일으키려는 그 시기에 모바일 센터를 없애고, 메신저 서버스가 모바일에서 킬러 서비스가 되려는 시작의 시기에 네이버 폰 서비스를 없애는 등은 누구의 잘못인가요? 일본 검색 시장 진출에 대한 성과 평가는 어떻게 생각하시나요?
아무리 위기이고 직원들이 이 위기를 공감하지 않는다고 해서 경영진이 수천명의 직원을 조기축구회원으로 만들어 버리는 언급은 위험한 발상입니다. 위기라면 설사 경영진이 잘못하지 않았더라도 경영진의 무능함을 먼저 사과하고 현재의 상황을 공유하여 직원들과 위기를 공유하는게 맞지 않을까요? 새롭고 혁신적인 서비스가 나오지 않고, 서비스의 일정이 지연되는 것이 모두 직장을 편하게 생각하고 있는 직원(개발자)의 잘못일까요?
NHN에 근무하는 중에 지금 새롭게 소프트웨어 개발자를 하려고 하는 졸업생이 너무 부족하여 어렵다 라는 말을 많이 들었습니다. 왜 부족할까요? 좋은 근무 환경(어떻게 보면 편한)의 직장이 너무 없다는 것입니다. 그만큼 공부했으면 다른 직업을 가졌으면 훨씬 더 좋은 대우를 받을수 있다는 것이죠... 그런 의미에서 NHN의 지금과 같은 상황은 소프트웨어 개발 업종으로 들어오지 말라고 이야기하는 것과 마찬가지 입니다.
업무 강도에 대한 이야기를 해보겠습니다. 현재의 NHN은 임직원 수를 보면 이미 대기업입니다. 그리고 과거의 벤처 시절의 긴장과 업무 강도는 성공했을 때 그 성과를 모두 다 가져갈 수 있다는 벤처 회사만의 특징이었을 겁니다. 지금의 구성원은 자기가 아무리 밤새워 일해도 나에게 돌아오는 거는 남들보다 조금 더 많은 성과금이라는 것을 알고 있습니다. 이것도 나의 노력이 내 윗선에 인정을 받았아야 한다는 조건이 달립니다. 이런 대기업적인 조직환경에서 벤처 시대의 긴장감을 요구하는 것 자체가 무리가 아닐까요? 현재의 NHN은 일상적인 관리 문화에서 새로운 것을 만들어내야 합니다. 그런 조직과 프로세스를 만들어 내야 하는 것이 경영진의 숙제인것이고요. 그것을 개발자 또는 임직원의 나태나 긴장감 부족으로 위안을 삼기에는 너무 커져 버리지 않았을까요?
 NHN에는 많은 우수한 개발자가 있습니다. 제가 아시는 분들도 많고요. 하지만 많은 분들이 또 나오셨습니다. 그런 분들에게는 애초에 근무 시간이나 근무 강도는 의미가 안되었습니다. 개발자의 생산성은 얼마나 자리에 않아 있고 야근을 했냐가 아니라 얼마나 자기 주도적으로 했냐라고 생각합니다. 그런 측면에서 보면 현재의 NHN 환경은 개발자에게 그냥 늦게까지 야근만 하다가 가는 그런 무의미한 시간 보내기 활동만하는 것이 평가에 더 좋은 그런 회사가 되었습니다.
이런 회사에서 개발자는 어떤 행동 패턴을 보일까요?  1. 그냥 회사에서 시간 뭉개고 자기 개발이나 한다. 2.그냥 딴데 간다.(이런 개발자는 주로 잘하는 개발자일 가능성이...)
이런것을 원하신건가요?
그리고 야근을 강요하고 계시는데 이것은 엄연한 노동법 위반입니다. 야근을 원하시면 정당한 급여에 비례한 야근 수당을 주고 야근을 시켜야하지 않을까요?
우리 개발자들 그렇게 하지 않아도 퇴근하면서도 배포된 프로그램 장애가 나지 않을까 고민하고 자면서도 문자메시지 오면 벌떡 일어나서 모니터 쳐다 보고 있습니다.
위기라면 자신의 잘못을 먼저 살펴보고 직원들을 다독거리고 공감을 이끌어 나가는 것이 리더의 자세가 아닐까 생각해서 안타까운 마음에 글을 적어 보았습니다.

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

Posted by 김형준


조금 다르게 보는 트위터 총선 분석

이번 포스팅은 깔대기 포스팅입니다.
2011/10월 서울시장 선거에서 그루터에서 트위터 데이터를 분석하여 박원순 후보와 나경원 후보의 언급 수, 주요 키워드, 많이 리트윗된 메시지 등에 대해서 서비스를 제공하였습니다.
서울 시장 선거 당시만 해도 소셜 네트워크 데이터에 대해서 이런 서비스를 제공하는데는 몇군데 없었는데 이번 총선에는 포털부터 시작해서 많은 업체들이 서비스를 내놓고 있습니다.
그루터도 처음에는 이런 서비스를 오픈하려고 기획을 했는데 남들 다하는 서비스 만들어 봐야 리소스만 낭비이고 차별화 시키기 어렵다는 내부 의견이 많아서 조금 다른 방향으로 접근해 보았습니다.
그래서 오늘의 총선돌이(님)와 오늘의 네거티브트윗,  보수/진보 각 진영에서 가장 이슈화된 트윗 형태로 만들어 봤습니다.

http://www.seenal.com/election2012

그리고 그루터의 실시간 분석 기술을 이용하여 만든 오늘의 총선돌이(님) 쓴 글이 어떻게 전파되고 누구를 통해 전파되었는지를 한눈에 볼수 있는 리트윗 지도도 볼 수 있습니다. 리트윗 지도는 시스템 리트윗 뿐만 아니라 실시간 네트워크 분석 기법을 이용 멘션된 리트윗도 트레이스하여 보여주고 있습니다.
사용자 삽입 이미지


한번씩 둘러 보세요... 이유있는 댓글 환영합니다. ㅋㅋㅋ
그리고 http://www.seenal.com 도 관심 가져주세요.


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

Posted by 김형준


« Previous : 1 : 2 : 3 : 4 : 5 : ... 12 : Next »