우선 이 글을 읽는 분들은 Amazon EC2 계정이 있고 AMI, Instance, EC2 Key Pair에 대해 알고 계시다고 전제하겠습니다.

Amazon EC2에서 Hadoop 클러스터 구동

현 시점에서 Amazon EC2 환경에 Hadoop 클러스터를 구동 방법은 선택의 폭이 그리 넓지 않습니다.

1. Hadoop이 이미 설치된 이미지를 사용하고 수동 설정하는 방법
2. EBS 기반 AMI에 하둡 설치 및 복사 그리고 수동 설정
3. whirr을 사용하는 방법
4. whirr의 hadoop-ec2를 사용하는 방법

이 포스팅에서는 3번인 whirr을 이용한 구축방법을 설명합니다. 그런데  이 방법은 정말 간단하지만 한 가지 제약을 가지고 있습니다. 이 방법은 기본적으로 instance store 기반의 AMI만 활용 할 수 있습니다. 따라서 Hadoop 클러스터의 HDFS는 instance store에 기반을 두게 되며 클러스터 종료 시 HDFS의 모든 데이터가 제거됩니다 (Amazon EC2의 모든 인스턴스는 영속적인 데이터 저장을 위해 EBS나 S3와 같은 별도의 저장 서비스를 사용해야 합니다.)

저의 경우 처음에 1,2번 방법을 모두 시도했었습니다. 그러나  다음과 같은 문제점이 있었습니다.

• 최신 Hadoop 배포본(0.20 이상)이 설치된 AMI의 부재
• 수십 여개의 인스턴스의 시동(launch)의 자동화
• 매번 새로 할당 받는 IP 주소와 이에 따른 Hadoop 설정과 설정 배포의 어려움

조사해보니 인스턴스를 시동을 자동화하고 시동된 인스턴스의 IP 목록을 얻어 설정 배포까지 원활히 하기 위해서는 Amazon AWS API를 이용하거나 boto (Python interface to Amazon Web Services), jcloud (multi-cloud library) 와 같은 third-party 라이브러리를 이용해 개발을 해야합니다. 그러나 이는 많은 시간을 요구합니다. EBS 기반 AMI에 Hadoop을 직접 설치하는 사용하는 방법 역시 비슷한 이유로 포기했습니다.

위에 4번 방법인 hadoop-ec2는 원래 Hadoop의 contrib 에 속했던 프로그램으로 현재는 whirr에서 진행되고 있지만 지속적으로 유지보수가 되지 않는 것으로 보여 시도하지 않았습니다. whirr의 Change Log를 봐도 4번에 대한 내용은 찾기 어려웠습니다.

현재로써는 whirr이 가장 편리한 방법이라 여겨 집니다.

whirr?

whirr는 Apache Incubator에 속한 프로젝트로 Amazon EC2와 같은 상용 클라우드 환경에서 원하는 서비스에 대한 설치, 설정, 실행을 자동으로 수행하는 라이브러리입니다. 현재 제공하는 서비스로는 Apache Hadoop, Cassandra,  Cloudera’s Distribution for Hadoop (CDH), Zookeeper가 있으며 조만간 릴리즈 될 0.4-incubating 버전에 Hbase가 추가될 예정이라고 합니다.

동작의 개요

whirr의 사용방법을 설명하기에 앞서 전체적인 동작에 대해 개략적으로 설명을 드리겠습니다.

사용자가 ‘cluster-lunch’ 커맨드를 주면 whirr은 instance store 기반의 AMI를 이용해 다수의 인스턴스를 가동하고 모든 인스턴스들에 JDK 및 Hadoop의 설치와 설정을 일괄적으로 수행합니다. 이 과정이 끝나면 EC2 내부에서 Hadoop 클러스터가 동작하고 있게 됩니다.

그리고 사용자가 로컬 머쉰에 설치한 Hadoop 프로그램 통해 EC2에서 구동되는 Hadoop 클러스터를 제어하게 됩니다. 그런데 EC2 내부의 인스턴스들은 기본적으로 private IP만을 할당 받아 외부에서 접근할 수가 없고 기본적으로 방화벽 설정이 까다롭게 되어 있기 때문에 추가적인 설정 없이 Hadoop RPC나 웹 UI를 통한 접근이 불가능 합니다. 따라서 whirr이 제공하는 proxy 프로그램을 실행하고 난 뒤에 로컬 머쉰에 설치된 Hadoop 프로그램을 이용하여 EC2 내부의 클러스터를 제어하게 됩니다.

Hadoop 클러스터 구동

계정 생성

whirr을 통해 생성하는 Hadoop 클러스터는 linux에서 hadoop이라는 username의해 시동됩니다. Hadoop은 클러스터를 구동한 계정과 같은 계정으로 접근할 때 superuser 권한을 가집니다. 따라서 로컬에 hadoop이라는 계정을 생성하여 아래 작업을 수행해야 Amazon EC2 내부에서 동작하는 Hadoop 클러스터에 대한 superuser권한을 행사할 수 있습니다. 하지만 단순히 MapReduce 프로그램만 실행 시킨다면 아무 계정에서 작업해도 문제 없습니다.

로컬 머쉰에 Hadoop과 whirr의 설치 그리고 Hadoop Version 문제

Hadoop과 whirr은 http://archive.apache.org/dist/ 에서 다운 받아 로컬 머쉰에 설치합니다.  그런데 현 시점에서는 ‘어떤 Hadoop 버전을 설치해야 하는가’가 문제가됩니다. Hadoop은 현재 한참 빠르게 개발되고 있으며 다른 버전간 내부 프로토콜이 호환되지 않습니다.

따라서 whirr이 자동으로 설치해주는 Hadoop 클러스터와 로컬 머쉰의 Hadoop은 같은 버전으로 맞춰야 합니다. 버전을 바꾸는 것은 whirr FAQ에 아래와 같이 설명되어 있는 것 처럼 직접 install, configuration 스크립트를 수정해야 합니다.

How do I specify the service version and other service properties?

Currently the only way to do this is to modify the scripts to install a particular version of the service, or to change the service properties from the defaults.

See “How to modify the instance installation and configuration scripts” above for details on how to do this.

from http://incubator.apache.org/whirr/faq.html

whirr은 Apache Hadoop 배포본외에도 Cloudera의 Hadoop 배포본을 설치할 수 있습니다. 이는 아래 ‘whirr 설정 파일’에서 whirr.hadoop-install-runurl과 whirr.hadoop-configure-runurl에 대한 내용을 참고하시면 됩니다.

whirr 설정 파일

whirr을 이용한 클러스터의 구동은 클러스터에 대한 설정 파일을 만드는 것으로 시작합니다. 이 포스팅에서는 아래 cluster.properties 파일의 내용을 설명하고 이후 내용도 이 설정을 기준으로 설명하도록 하겠습니다.

(아래 내용은 최신인 0.3-incubating 버전에 대한 내용입니다. 0.4-incubating 버전이 릴리즈 되면 설정 방법이 변경될 예정입니다. 릴리즈 되고 나면 포스팅을 업데이트 하도록 하겠습니다.)

whirr.cluster-name=mycluster
whirr.instance-templates=1 jt+nn,16 dn+tt
whirr.provider=ec2
whirr.identity=ACCESS_KEY
whirr.credential=SECRET_KEY
whirr.private-key-file=${sys:user.home}/.ssh/id_rsa
whirr.public-key-file=${sys:user.home}/.ssh/id_rsa.pub
whirr.location-id=us-east-1d
whirr.hardware-id=m1.small
whirr.service-name=hadoop
#whirr.hadoop-install-runurl=cloudera/cdh/install
#whirr.hadoop-configure-runurl=cloudera/cdh/post-configure

각 항목에 대한 설명은 다음과 같습니다.

• whirr.cluster-name : 구동할 클러스터를 식별하는 이름입니다. 클러스터를 구동하면 ${HOME}/.whirr/<cluster-name> 가  디렉토리가 생성되며 이 디렉토리에는 Hadoop 클러스터에 접근하는데 필요한 파일들이 저장됩니다.
• whirr.instance-templates: 구동할 클러스터의 구성을 설정합니다. jt는 jobtracker, nn은 name node, dn은 data node, tt는 task tracker를 의미합니다. 이 설정을 통해 유연한 설정이 가능합니다. data node와 task tracker를 더 늘리고 싶을 때는 dn+tt 앞에 쓰여진 숫자를 변경해 주시면 됩니다.
• whirr.provider: 클러스터 서비스 제공자를 설정합니다. 현재는 Amazon EC2와 Rackspace Cloud Servers 두 가지를 지원합니다.
• whirr.identity: AWS의 access key를 입력하시면 됩니다.
• whirr.credential: AWS의 secret key를 입력 합니다.
• whirr.private-key-file: 이 설정과 아래 설정은 ec2 인스턴스를 생성할 때 사용할 key로 사용됩니다. 위 예제처럼 하기 위해서는 아래와 같이 ssh키를 생성해야 한다. 또는 기존에 다른 인스턴스를 위해 만들어 놓은 EC2 Key pair의 경로를 설정해도 됩니다.

$ ssh-keygen -t rsa -P ''

• whirr.location-id: 원하는 availability zone을 설정한다. 설정하지 않으면 whirr을 실행하는 인스턴스와 같은 zone이 설정된다.
• whirr.hardware-id: 원하는 인스턴스 유형을 설정한다. Amazon EC2가 제공하는 인스턴스 유형은 Amzon EC2 Instance Types 페이지에서 확인할 수 있으며 각 유형에 써 있는 API name을 이 설정에 적용하면 됩니다.
• whirr.service-name: 구축할 서비스를 설정합니다. 이 글은 Hadoop을 위한 것이므로 hadoop으로 남겨 둡니다.
• whirr.hadoop-install-runurl, whirr.hadoop-configure-runurl: Hadoop의 경우 apache 버전과 CDH 버전이 있습니다. 위 예제에서 주석(#)을 제거해 주면 CDH버전을 구동하게 됩니다.

설정에 대한 추가적인 설명은 Whirr Configuration Guide 문서를 참고하시면 됩니다.

Hadoop 클러스터 시동

클러스터의 시동은 다음과 같은 커맨드로 수행합니다. 클러스터를 시동하면 내부적으로 Amazon의 EC2 API를 통해 인스턴스를 생성해 필수 패키지(JDK)등을 설치하고 Hadoop 배포 버전을 다운로드 받아 설정을 하는 과정이 수행됩니다. 따라서 클러스터가 구동되는데 짧게는 수 분에서 길게는 10분 정도 소요됩니다. 클러스터 구동이 완료되면 다시 쉘 프롬프트가 뜨게 됩니다.

$ whirr/bin/whirr launch-cluster --config cluster.properties
Bootstrapping cluster
Configuring template
Starting 16 node(s) with roles [tt, dn]
Configuring template
Starting 1 node(s) with roles [jt, nn]
Nodes started: [[id=us-east-1/i-a45eb7cb, providerId=i-a45eb7cb, ...]]
.....
Nodes started: [[id=us-east-1/i-7a51b815, providerId=i-7a51b815, ...]]
Authorizing firewall
Running configuration script
Configuration script run completed
Running configuration script
Configuration script run completed
Completed configuration of mycluster
Web UI available at http://ec2-72-44-43-29.compute-1.amazonaws.com
Wrote Hadoop site file /home/-----/.whirr/mycluster/hadoop-site.xml
Wrote Hadoop proxy script /home/-----/.whirr/mycluster/hadoop-proxy.sh
Wrote instances file /home/-----/.whirr/mycluster/instances
Started cluster of 17 instances
Cluster{instances=[Instance{roles=[tt, dn], ...}]}
$

프록시 열기

whirr을 통해 구동한 Hadoop 클러스터에 접근하기 위해서는 로컬에 설치했던 Hadoop을 설정을 해야 합니다. 설정은 간단히 whirr이 클러스터 시동 후 생성해 주는 파일을 사용하면 됩니다. ‘whirr launch-cluster’ 가 완료되고 나면 ${HOME}/.whirr/<cluster-name>/hadoop-site.xml 파일이 생성됩니다. 이 파일을 로컬에 설치한 Hadoop의 ${HADOOP_HOME}/conf에 간단하게 복사하거나 다음과 같이 환경변수를 설정하여 Hadoop의 설정 디렉토리를 override 하면 됩니다.

export HADOOP_CONF_DIR=~/.whirr/<cluster-name>

하지만 EC2 내부의 클러스터들은 private IP만을 가지기 때문에 바로 Hadoop 클러스터에 접근할 수는 없습니다. ${HOME}/.whirr/<cluster-name>/hadoop-proxy.sh를 실행 해야 비로소 EC2에 구동된 Hadoop 클러스터에 접근할 수 있습니다.

$ chmod +x ~/.whirr/mycluster/hadoop-proxy
$ ~/.whirr/mycluster/hadoop-proxy

Running proxy to Hadoop cluster at ec2-72-44-43-29.compute-1.
amazonaws.com. Use Ctrl-c to quit.

$ bin/hadoop dfs -ls
...

hadoop-proxy.sh를 실행하면 EC2에서 동작하는 Hadoop 클러스터 웹 UI도 접근할 수 있습니다. 그러나 이를 위해서는 간단한 웹 브라우져 설정이 요구됩니다.

• 크롬은 Preferences -> Under the Hood 탭 -> Network -> Change Proxy Settings에서 설정하면 됩니다. Socks 설정의 주소는 localhost, 포트는 6666으로 해주시면 됩니다.
• 파폭은 기본적으로 SOCKS를 사용하더라도 로컬 머신에 설정된 DNS를 사용하게 되어 있는데 먼저 이 설정을 변경해 주셔야 합니다. 이를 위해서는 주소창에 about:config를 입력해 세부 설정으로 들어가 network.proxy.socks_remote_dns 설정을 true로 변경해주셔야 합니다. 그리고 Preferences -> Advanced -> Network 탭 -> Connection 섹션의 Settings에서 SOCKS Host를 주소는 localhost, 포트는 6666으로 설정해주시면 됩니다.

위와 같이 수정하고 hadoop-proxy.sh를 실행 했을 때 출력되는 URL에 접속하시면 됩니다.

클러스터 종료

Hadoop을 이용한 모든 작업이 끝나면 종료는 다음 커맨드를 통해 수행합니다. 위에서 언급한 바와 같이 whirr은 아직까지 instance store 기반 클러스터 구축 밖에 지원하지 못하므로 HDFS의 모든 데이터가 제거되는 사실을 염두하셔야 합니다.

$ whirr/bin/whirr destroy-cluster --config=cluster.properties

결론

whirr을 통한 Hadoop 클러스터 구동 방법을 설명했습니다. whirr은 아직 사소한 버그와 설정의 한계가 있지만 직접 클러스터 를 구축해야 하는 사용자의 노력을 상당히 줄여줍니다. 필요에 따라 MapReduce 프로그램을 대규모 클러스터에 동작시켜야 하는 사용자들에게는 특히 유용하다고 생각합니다.

참고문서

• Getting Started with Whirr
• Map-Reduce With Ruby Using Hadoop

MapReduce Counter

Hadoop MapReduce Counter provides a way to measure the progress or the number of operations that occur within MapReduce programs. Basically, MapReduce framework provides a number of built-in counters to measure basic I/O operations, such as FILE_BYTES_READ/WRITTEN and Map/Combine/Reduce input/output records. These counters are very useful especially when you evaluate some MapReduce programs. Besides, the MapReduce Counter allows users to employ your own counters. Since MapReduce Counters are automatically aggregated over Map and Reduce phases, it is one of the easiest way to investigate internal behaviors of MapReduce programs. In this post, I’m going to introduce how to use your own MapReduce Counter. The example sources described in this post are based on Hadoop 0.21 API.

Incrementing your counter

For your own MapReduce counter, you first define a enum type as follow:

public static enum MATCH_COUNTER {
  INCOMING_GRAPHS,
  PRUNING_BY_NCV,
  PRUNING_BY_COUNT,
  PRUNING_BY_ISO,
  ISOMORPHIC
};

And then, when you want to increment your own counter, you should call the increment method as follows:

context.getCounter(MATCH_COUNTER.INCOMING_GRAPHS).increment(1);

You can access context instance within setup, cleanup, map, and reduce method in Mapper or Reducer class. You can get a desired counter via calling context.getCounter method with some enum value.

Finding your counter

You can get some Counters from a finished job as follows:

Configuration conf = new Configuration();
Cluster cluster = new Cluster(conf);
Job job = Job.getInstance(cluster,conf);
result = job.waitForCompletion(true);
...
Counters counters = job.getCounters();

The instance of Counters class contains all of the counters obtained from a job. So, when you want to get your own counter, you should call findCounter method with a enum type as follows:

Counter c1 = counters.findCounter(MATCH_COUNTER.INCOMING_GRAPHS);
System.out.println(c1.getDisplayName()+":"+c1.getValue());

The below example shows how to get built-in counter groups that Hadoop provides basically.

for (CounterGroup group : counters) {
  System.out.println("* Counter Group: " + group.getDisplayName() + " (" + group.getName() + ")");
  System.out.println("  number of counters in this group: " + group.size());
  for (Counter counter : group) {
    System.out.println("  - " + counter.getDisplayName() + ": " + counter.getName() + ": "+counter.getValue());
  }
}

• Running on shared-nothing clusters of commodity hardware
• In-memory database
• SQL support
• ACID
• Linear Scalability
• Released as an Open Source software

Actually, there have already been some OLTP databases running on shared-nothing clusters. However, they cannot take advantage from the scalability of shared-nothing architecture due to their implementation’s natures, such as complex distributed locking and commit protocols [1]. In addition, according to [3], traditional RDBMSs have four overhead components, which are logging, locking, latching, and buffer management. However, M. Stonebraker claims that VoltDB eliminated these legacy overheads.

Among many features, especially I have interest in its linear scalability with ACID and performance. It is meaningful in that today’s web applications have another alternative to NoSQL data stores. Although VoltDB is under heavy development, the above features and the next benchmark result show its promising.

• Key-Value Benchmark (VoltDB versus Cassandra)

Cassandra is a remarkable key-value store and an open source project developed by apache committers. Now, it is well known as the most performant one in existing NoSQL stores. According to this benchmark result, however, in all cases VoltDB dominates Cassandra although the fairness of experiments is controversial.

• VoltDB Roadmap

It’s future plan is also expected. I wonder how much attention VoltDB will be getting from communities and industrials.

See Also:

1. Data Management in the Cloud: Limitations and Opportunities
2. Comparing VoltDB vs Postgresql
3. OLTP through the looking glass, and what we found there, ACM SIGMOD 2008
4. http://voltdb.com/product
5. H-Store: A Next Generation OLTP DBMS

얼마전 Yahoo!의 HDFS 팀에서 Multiple nodes를 사용하여 HDFS namenode의 Horizontal Scalability를 향상 시키는 방법을 제안 했었습니다 (HDFS-1052). 그런데 그 뒤로는 Dhruba Borthakur라는 Hadoop 커미터가 Vertical Scalability 개선 방법을 제안했습니다(The Curse of Singletons! The Vertical Scalability of Hadoop NameNode, HDFS-1093, HADOOP-6713). Borthakur에 대해 LinkedIn 에서 찾아보니 현재 Facebook에서 근무하는 Hadoop 엔지니어라고 나오는군요.

위 두 제안을 보면 Vertical Scalability과 Horizontal Scalability라는 용어가 나옵니다. Vertical Scalability는 시스템의 사양을 향상 시켰을 때 얻는 확장성을 의미합니다. 주로 CPU, Memory, Hard disk 등의 향상을 의미합니다. Hadoop과 같은 분산 시스템에서는 시스템 코어의 수가 늘어나는 것도 Vertical Scalability의 범주로 포함됩니다. 반면 Horizontal Scalability는 시스템의 개수를 늘렸을 때 얻는 확장성을 의미합니다. 예를 들면 노드의 수가 10대에서 20개로 늘어났을 때 얻는 확장성을 의미합니다. scale-up과 scale-out도 각각 같은 의미로 통용됩니다.

본 포스트에서는 위 두 가지 제안 중에서 Dhruba Borthaku가 제안한 vertical scalability 향상을 위한 제안을 소개합니다. 우선 Dhruba Borthakur라는 해커가 지적한 Hadoop Namenode (현재 Hadoop 0.21)의 병목현상은 다음과 같습니다.

• Network: Facebook에서 자신이 사용하는 클러스터는 약 2000개의 노드로 구성되어 있으며 MapReduce 프로그램 동작 시 각 서버들은 9개의 mapper와 6개의 reducer가 동작하도록 설정되어 있다고 합니다. 이 구성의 클러스터에서 MapReduce를 동작하면 클라이언트들은 동시에 약 30k 의 request를 NameNode 에게 요청한다고 합니다. 그러나 singleton으로 구현된 Hadoop RPCServer의 Listener 스레드가 모든 메시지를 처리하므로 상당히 많은 지연이 발생하고 CPU core의 수가 증가해도 효과가 없었다고 합니다.
• CPU: FSNamesystem lock 메카니즘으로 인해 namenode는 실제로는 8개의 core를 가진 시스템이지만 보통 2개의 코어밖에 활용되지 않는다고 합니다. Borthakur에 의하면 FSNamesystem에서 사용하는 locking 메커니즘이 너무 단순 하고 HADOOP-1269 를 통해 문제를 개선 시켰음에도 여전히 개선의 여지가 있다고 합니다.
• Memory: Hadoop의 NameNode는 논문 내용에 충실하게 모든 메타 데이터를 메모리에 유지합니다. 그런데 Borthakur가 사용하는 클러스터의 HDFS에는 6천만개의 파일과 8천만개의 블럭들이 유지하고 있는데 이 파일들의 메타데이터를 유지하기 위해 무려 58GB의 힙공간이 필요했다고 합니다.

Borthakur가 이 문제를 해결하기 위해 제안했던 방법은 다음과 같습니다.

• RPC Server: singleton으로 구현되었던 Listener 스레드에 Reader 스레프 풀을 붙였다고 합니다. 그래서 Listener 스레드는 connection 요청에 대한 accept 만 해주고 Reader 스레드 중 하나가 RPC를 직접 처리하도록 개선했다고 합니다. 결과적으로 다량의 RPC 요청에 대해 더 많은 CPU core들을 활용할 수 있게 되었다고 합니다(HADOOP-6713).
• FSNamesystem lock: Borthakur는 파일에 대한 어떤 operation이 있을 때 lock이 걸리는지 통계를 내고 그 결과로 파일과 디렉토리의 상태를 얻을 때와 읽기 위해 파일을 열 때 걸리는 lock이 전체 lock의 90%를 차지 한다는 것을 밝힙니다. 그리고 저 두 파일 operation들은 오직 read-only operation 이기 때문에 read-write lock 으로 바꾸어 성능을 향상 시켰다고 합니다(HADOOP-1093). 이 부분은 MapReduce 논문(The Google File System) 4.1절 Namespace Management and Locking 에도 설명이 잘 되어 있습니다. 이미 MapReduce에서는 namespace의 자료구조에서 상위 디렉토리에 해당하는 데이터에는 read lock을 걸고 작업 디렉토리 또는 작업 파일에는 read 또는 write lock을 걸어 가능한 동시에 다수의 operation들이 공유 데이터에 접근하게 하면서도 consistency를 유지하는 방법을 설명하고 있습니다. 아마도 file 에 대한 append가 Hadoop 0.20 버전에 추가 된 것 처럼 논문에 설명이 있음에도 구현이 되지 않은 부분이었나 봅니다. 자세한건 소스를 분석해 봐야 알 수 있을 것 같습니다.

그러나 메모리에 대한 문제는 아직 해결하지 못했다고 합니다. 그래도 Borthakur에 의하면 위 두 가지 문제점을 해결한 것만으로 무려 8배나 scalability를 향상 시켰다고 합니다.

얼마전 부터 HDFS scalability 향상에 대한 시도들이 눈에 띄고 재미있어 보여 ‘여유 있을 때 블로그에 한번 정리해 봐야 겠다’라고 한달전에 맘 먹었는데 겨우 하나를 마쳤네요. 요즘 시간이 잘 안나서 이 포스트를 시작해서 완성하는데 약 3주나 걸렸습니다. 그 사이 Usenix의 매거진인 ;login:에 Hadoop Namenode의 scalability에 대한 article인 HDFS Scalability: The Limits to Growth가 실렸습니다. 또 야후 개발자 네트워크 블로그에서 article을 소개하는 글 (Scalability of the Hadoop Distributed File System)이 실렸네요. 시간날 때 마다 마저 정리해 보겠습니다.

Hadoop은 이미 알려질대로 잘 알려진 분산 컴퓨팅 프레임워크입니다. 많은 사람들이 Hadoop 하면 MapReduce 프로그래밍을 주로 떠올리지만 자체적으로 제공하는 Hadoop RPC와 분산 파일 시스템인 HDFS를 가지고도 재미있는 것을 시도해 볼 수 있을 것 같습니다. 본 포스팅에서는 그 중에서 Hadoop RPC를 이용한 간단한 서버 클라이언트 프로그램의 구현방법을 소개합니다.

Hadoop RPC Concept

Hadoop RPC는 일반적으로 하나의 프로토콜 인터페이스(interface)와 하나의 Server 그리고 하나 이상의 Client(들)로 동작합니다. Hadoop RPC 서버의 인스턴스와 클라이언트 프록시의 인스턴스는 org.apache.hadoop.ipc.RPC 라는 클래스를 통해 얻을 수 있는데 내부적으로는 java reflection을 통해 구현되어 있습니다. 그리고 RPC method의 파라메터와 리턴 값은 오직 자바 primitive type들(예: int, long, String 등등)과 Writable 인터페이스를 구현한 구상클래스만 될 수 있습니다. 또한 Hadoop RPC는 자체적으로 서버와 클라이언트에 대한 기본적인 기능을 제공합니다. 따라서 복잡하게 스레드나 소켓 통신을 직접 구현할 필요가 없으며 개발자는 오로지 RPC 프로토콜 인터페이스와 RPC 메소드들에 대한 내용만 채워 넣으면 됩니다.

Implementation of RPC Protocol

RPC Protocol은 인터페이스로 정의되어야 하며 이 인터페이스는 org.apache.hadoop.ipc.VersionedProtocol을 상속하여야 합니다. VersionedProtocol은 자체적으로 getProtocolVersion() 메소드를 가지고 있는데 이 메소드는 프로토콜의 버전이 다양할 경우 서버-클라이언트가 다른 버전의 프로토콜로 통신하는 것을 방지하는 역할을 합니다.

RPC 프로토콜은 다음 예제와 같이 간단히 만들 수 있습니다. 아래 예제는 String 값을 반환하는 heartBeat()라는 하나의 RPC 메소드를 가진 RPC 프로토콜 인터페이스입니다.

import org.apache.hadoop.ipc.VersionedProtocol;

public interface RPCProtocol extends VersionedProtocol {
  public long versionID=0;
  public String heartBeat() throws IOException;
}

Implementation of RPC Server

위에서 설명한 RPC 프로토콜의 서버 역할을 할 구상 클래스를 구현합니다. 서버 클래스는 간단히 위에서 정의한 RPCProtocol 인터페이스를 implements 하면 됩니다 (아래 예제 참조).

import java.io.IOException;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.ipc.RPC;
import org.apache.hadoop.ipc.RPC.Server;

public class TestServer implements RPCProtocol {

  @Override
  public String heartBeat() throws IOException {
    return "Hello";
  }

  @Override
  public long getProtocolVersion(String arg0, long arg1) throws IOException {
    return 0;
  }

  /**
   * @param args
   * @throws IOException
   * @throws InterruptedException
   */
  public static void main(String[] args) throws IOException, InterruptedException {
    TestServer s = new TestServer();
    Configuration conf = new Configuration();
    Server server = RPC.getServer(s, "localhost", 10000, conf);
    server.start();
    server.join();
  }
}

RPCProtocol 인터페이스에서 정의했던 String heartBeat() 메소드 역시 구현되어 있습니다. 반환 값으로 “Hello”가 호출한 RPC 클라이언트에게 전달 될 것입니다.

서버의 시동은 main 메소드에 구현되어 있습니다. 우선 프로토콜의 구상클래스(TestServer)의 인스턴스를 생성하고 RPC.getServer()에 인자로 전달합니다. 또한 getServer 메소드는 추가적으로 서버가 binding할 IP와 port 번호를 인자로 받으며 Server 클래스의 인스턴스를 반환합니다(내부적으로는 TestServer 클래스의 인스턴스에 대한 Listener 스레드를 생성하여 파라메터로 전달된 IP 및 port 번호와 바인딩 시킵니다. 그리고 RPC 콜이 있을 때마다 TestServer의 메소드를 콜하게 됩니다. 처리 결과는 Responder 스레드를 통해 반환하게 됩니다).

RPC.getServer 메소드의 원형은 다음과 같습니다.

Implementation of RPC Client

클라이언트는 RPC.waitForProxy 메소드를 통해서 간단히 얻을 수 있습니다. 그리고 클라이언트는 반환값으로 받은 proxy 인스턴스를 이용해서 손쉽게 RPC method를 콜하고 서버로부터 응답을 받아 올 수 있습니다.

import java.io.IOException;
import java.net.InetSocketAddress;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.ipc.RPC;

public class TestClient {

  /**
   * @param args
   * @throws IOException
   * @throws InterruptedException
   */
  public static void main(String[] args) throws IOException, InterruptedException {
    Configuration conf = new Configuration();
    InetSocketAddress addr = new InetSocketAddress("localhost", 10000);
    RPCProtocol rpc = (RPCProtocol) RPC.waitForProxy(RPCProtocol.class,
        RPCProtocol.versionID, addr, conf);

    String msg = null;
    while(true) {
      Thread.sleep(1000);
      msg = rpc.heartBeat();
      System.out.println(msg);
    }
  }
}

위 예제는 프록시 인스턴스 변수인 rpc를 통해 손쉽게 rpc.heartBeat() 메소드를 실행하고 서버로 부터 결과를 얻는 내용을 설명합니다.

Test

서버를 먼저 실행하고 클라이언트를 실행하면 됩니다. 사실 순서를 바꿔 실행해도 크게 문제 되지 않습니다. Hadoop RPC의 클라이언트는 먼저 실행되었을 경우 RPC 서버에 접속이 될 때까지 1초 단위로 반복하여 접속 시도를 하게 됩니다.

정상적으로 수행되는 경우 다음과 같은 메시지를 확인할 수 있습니다.

Hello
Hello
Hello
Hello
Hello
...

References

• http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/ipc/RPC.html
• http://www.supermind.org/blog/520

그런데 제목이 ‘시도기’로 그치는 것에는 이유가 있다. 설명을 위해 우선 FTS 대해 조금 설명하면 FTS는 단순하게 SQL의 LIKE와 같이 서브 스트링을 포함하는 ROW를 찾아주는 문제가 아니다. 문서에서 조사와 같은 불용어를 제외하고 단어의 형태소 추출하며 단어간의 edit distance 까지 고려하여 철자가 유사한 단어에 대해서도 검색 결과로 내놓는다. 따라서 불용어와 형태소분석을 위해서는 사전이 필수적인 것이다. Postgresql 메뉴얼을 보니 ispell, myspell, hunspell등의 포맷을 지원한다고 써 있었다.

사전을 찾아보니 데비안 메인테이너 cwryu님이 주도하시는 hunspell-ko 프로젝트가 있었다. 안도… 그러나기쁨도 잠시 postgresql 이 사전을 제대로 읽어 들이지 못한다. IRC에서 cwryu님께 받은 조언으로 문제를 해결했지만 postgresql이 사전이 ASCII로 설정된 옵션(FLAG default) 외에는 받아들이지 않는다. 한글처리를 위해서는 default로는 불가했다.

현재 이 문제에 대해서는 postgresql bug 메일링에 리포트 해 놓은 상태이다. 결론은 postgresql로 제대로 된 full text search는 아직 꿈나라 인듯 싶다. tgtrgm 으로 짧은 문장에 대해서는 가능하기도 하지만 띄어쓰지 않은 5자 정도 이상의 문자들에 대해서는 false negative가 발생한다. false positive 는 성능 상 오버헤드가 있더라고 필터를 한번 더 주면 되지만 이것은 곤란했다.

시간이 좀 걸리더라도 짬을내어 이 문제에 대해 계속 리포트할 심산이다. 중간 중간 진행상황에 대해 포스팅 하도록 하겠다.

HBase provides two ways to allow a Hbase client to connect HBase master. One is to use a instance of HBaseAdmin class. HBaseAdmin provides some methods for creating, modifying, and deleting tables and column families. Another way is to use an instance of HTable class. This class almost provides some methods to manipulate data like inserting, modifying, and deleting rows and cells.

Thus, in order to make a hbase table, we need to connect a HBase master by initializing a instance of HBaseAdmin like line 4. HBaseAdmin requires an instance of HBaseConfiguration. If necessary, you may set some configurations like line 2.

In order to describe HBase schema, we make an instances of HColumnDescriptor for each column family. In addition to column family names, HColumnDescriptor enables you to set various parameters, such as maxVersions, compression type, timeToLive, and bloomFilter. Then, we can create a HBase table by invoking createTable like line 10.

HBaseConfiguration conf = new HBaseConfiguration();
conf.set("hbase.master","localhost:60000");

HBaseAdmin hbase = new HBaseAdmin(conf);
HTableDescriptor desc = new HTableDescriptor("TEST");
HColumnDescriptor meta = new HColumnDescriptor("personal".getBytes());
HColumnDescriptor prefix = new HColumnDescriptor("account".getBytes());
desc.addFamily(meta);
desc.addFamily(prefix);
hbase.createTable(desc);

Finally, you can check your hbase table as the following commands.

c0d3h4ck@code:~/Development/hbase$ bin/hbase shell
HBase Shell; enter 'help<RETURN>' for list of supported commands.
Version: 0.20.1, r822817, Wed Oct  7 11:55:42 PDT 2009
hbase(main):001:0> list
TEST

1 row(s) in 0.0940 seconds

The hadoop platforms are installed in cloud computing service providers and many companies as you can see in http://wiki.apache.org/hadoop/PoweredBy. However, most of them may use only MapReduce programs. As you know although MapReduce is very scalability, but it provides only the simple programming model. Many programmers want to use more various programming model without changing the platform (i.e., Hadoop). This BSP lib will be the beginning for their desires. However, like MapReduce, BSP may also be not swiss army knife. When we find appropriate applications, BSP lib on Hadoop will be valued for its scalability and ability.

Sooner, I’ll post articles about the progress of BSP library and Angrapa (the graph package on Hama).

• Use the Hadoop Distributed File System (HDFS) for storing large
  datasets, and run distributed computations over those datasets using
  MapReduce
• Become familiar with Hadoop’s data and I/O building blocks for compression, data integrity, serialization, and persistence
• Discover common pitfalls and advanced features for writing real-world MapReduce programs
• Design, build, and administer a dedicated Hadoop cluster, or run Hadoop in the cloud
• Use Pig, a high-level query language for large-scale data processing
• Take advantage of HBase, Hadoop’s database for structured and semi-structured data
• Learn ZooKeeper, a toolkit of coordination primitives for building distributed systems

그동안 소스도 분석해 보고 Hadoop 기반 어플리케이션도 짜보고 했지만 좀 더 체계적으로 알고 싶은 마음에 질러볼까합니다.
그런데 바빠서 볼 수 있을지 ~(~_~)~

The way is very simple as follows:

1. configure conf/slaves and *.xml files on master machine
2. configure conf/master and *.xml files on slave machine
3. run ${HADOOP}/bin/hadoop datanode

If you have to add more than one data node to Hadoop, run the following command (instead of the third command above) on master machine.

${HADOOP}/bin/start-all.sh

Additionally, the way to add a region server to Hbase master without restarting all is similar to that of Hadoop.

1. configure conf/regionservers and *.xml files on master machine
2. configure conf/*.xml files on slave machine
3. run ${HBASE}/bin/hbase regionserver start

https://launchpad.net/~openoffice-pkgs/+archive

Enjoy OpenOffice 3.0!

Because the mirroring service consumes so much network bandwidth, we firstly had to be permitted by the office of information technorogy & service. Last week, we finally got the permission from the office.

Above all, we provide the mirror service for Ubuntu, Gentoo Linux, Eclipse, and Apache. Later, if we are asked to mirror other opensource archives, we will do that.

The URL of our mirror site plans to be http://mirror.korea.ac.kr. However, this address is not yet available. I will register this domain to office of infomation technolorogy & service.

• 백업할 파티션이 대부분 차 있어 로컬 파티션에 백업할 수 없을 때
• 퍼미션을 유지하며 리모트 머쉰으로 복사 할 때

tar 에서 f 를 빼고 다음과 같이 하면 stdout 으로 묶은 내용을 출력합니다. 이걸 netcat 로 리모트 머쉰에 쏘는 거지요. 그럼 netcat 를 listen mode 로 켜둔 리모트 머쉰에서는 이 데이터를 받아서 tar 에게 파이프(pipe)로 건내주어 파일로 저장되게 합니다. 그럼 명령어로 한번 볼까요?

우선 백업을 저장할 머쉰 아래 명령을 먼저 수행합니다.

nc -l -p ${PORT} | tar xvf

-l 은 listen mode 로 netcat 를 작동 한는 옵션이며 이렇게 해야 소켓을 열고 접속 요청을 대기 합니다. 다시 말해 서버 처럼 작동합니다. ${PORT} 에는 대기할 port 번호를 입력합니다.

그리고 백업할 데이터가 있는 머쉰, 즉 로컬머쉰에서 다음과 같이 합니다.

tar cvf ${DIR} | nc -q 0 ${HOSTNAME} ${PORT}

nc 에서 -q 명령은 EOF 를 만난후 몇초후에 nc 를 종료할 것인지를 나타냅니다. 위 명령에서는 -q 0 이므로 EOF 를
만나면 바로 종료됩니다. -q 명령을 안쓰면 tar 명령이 끝나도 프롬프트가 나오지 않고 대기하게 되므로 언제 종료되었는지
알기가 힘듭니다. ${HOSTNAME} 은 저 위에 백업을 저장할 머쉰의 주소 입니다.

tar 의 다양한 옵션들을 추가 하면 더욱 쓸만해 집니다. 저 같은 경우 홈 디렉토리를 그대로 백업하기 위해 다음과 같이 합니다.

백업 데이터를 저장하는 머쉰에서

nc -l -p ${PORT} tar xjvpf

백업할 데이터가 있는 머쉰에서

tar cjvpf /home | nc -q 0 ${HOSTNAME} ${PORT}

참고로 말씀드리면 j 는 bzip2 로 압축하는 옵션이며 p 는 퍼미션, 즉 uid와 gid 를 그대로 유지합니다. 아마 tar 옵션을 많이 아신다면 다양한 응용이 가능할 것 같습니다.

오늘도 이 글을 쓰면서 느끼는 거지만 파이프와 함께하는 유닉스 유틸리티들은 말 그대로 예술인 것 같습니다.

컴퓨터를 잘 다룬다고 주변으로 인식 받는 사람들은 대부분주변인들에게 컴퓨터를 고쳐달라는 부탁을 받아 봅니다. 처음이나 어린나이에는 우쭐해서 잘 고쳐주다가도 사실 점차 반복되는 부탁과 나이가 들어감에 따라 대부분 귀찮아 하지요.

오죽하면 이런 티를 팔겠습니까?

귀찮아도 지인의 부탁에 고쳐줘야 하는 경우가 있습니다. 고치다 보면 해결책으로 종종 윈도우즈 재설치 처방을 내리게 됩니다. 그런데 문제는 이런 요구를 하는 사람들은 대부분 드라이버 시디를 가지고 있지 않거나 하드웨어 스펙을 잘 모릅니다(주로 랜카드와 비디오카드, 사운드).

그래서 저는 컴퓨터를 고치러 가는 경우 리눅스 라이브시디를 하나 가지고 갑니다(개인적으로 젠투 라이브를 선호 합니다). 하드웨어 스펙을 잘 모르는 경우 라이브시디로 부팅하여 터미널에서 lspci 한방이면 연결된 하드웨어 칩셋의 정보를 모델명까지 잘 보여줍니다.

저의 경우 아래와 같이 나오는 군요.

c0d3h4ck@c0d3h4ck:~$ lspci
00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G71 [GeForce 7900 GS] (rev a1)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)
03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
05:02.0 Multimedia audio controller: Creative Labs SB Audigy LS
05:02.1 Input device controller: Creative Labs SB Audigy LS Game Port
05:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
05:04.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 14)

여러분도 애용해 보세요~

그리고 우분투 7.10 Gutsy AMD64 버전을 간편하게 다음 미러(참 좋은 선례를 보여주는 회사다)에서 받아 Ok 몇번 클릭으로 설치… 역시 설치는 윈도우 보다 훨씬 쉽다.

이것저것 설치하고 글꼴도 설정들도 조율하고, VGA 카드 드라이버도 설치하고..
이제 인터넷 뱅킹을 위해 VirtualBox 설치! 앗 그런데 인터넷 뱅킹에서 죽는다..
이것 저것 검색해보니 키보드 보안 모듈 때문이란다. 그런데 이상하다 젠투에서는 문제가 없었다.

그래서 버전을 확인해 보았더니 우분투 공식 저장소에서 제공하는 VirtualBox OSE 의 버전은 1.50 으로 젠투의 VirtualBox OSE 버전인 1.52보다 조금 낮았다. 혹시 이후 버전에서 개선되었기 때문인가 하여 1.52를 받아 볼까 검색해 보니 VirtualBox 공식 사이트에서 VirtualBox 의 우분투 패키지를 아예 제공해준다(어익후 감사). 더군다나 각 우분투 및 데비안 버전마다 저장소 까지 제공해 준다. 덕분에 간단히 설치를 끝냈고 현재 인터넷 뱅킹은 문제 없이 잘되는 중이다. 아무래도 해당 문제는 1.52 이상에서 발생되지 않도록 개선된듯.

문제 있는 분들(특히 뭐 선배님) 1.52 버전로 얼렁 바꾸세요!

더군다나 썬더버드는 다른 모질라 프로그램들과 마찬가지로 프로파일 기능을 제공한다. 다시 말해, 각기 다른 프로파일을 만들어 각 프로파일 마다 각기 다른 설정과 다른 메일 박스를 가지게 되는것 이다. 이는 여러 모로 편리하다. 특히 나 같이 업무상 여러 메일 계정을 관리하는 경우 아주 유용했다.

기타 메일 프로그램들과 마찬가지로 썬더버드도 여러 계정을 동시에 등록하여 관리 가능하다. 그러나 두 계정에 들어 있는 메일들이 절대 섞이면 안되거나 발신자 메일 주소가 중요하여 A 업무를 담당하는 메일 주소를 B 업무 관련된 메일로 발송하면 안되는 경우라면 아예 계정들을 각기 다른 프로파일을 통해 분리시켜 놓는게 안전하다. 예를 들면, 비서가 사장님 메일 계정과 자신의 계정을 하나 클라이언트로 관리하다가 사장님의 전달 사항을 자신의 발신자 주소로 보냈다고 상상해봐라! 얼마나 끔찍한 일이겠는지! ^^;

thunderbird -P

썬더버드를 실행할때 위와 같이 입력하면 아래와 같이 프로파일 관리 창이 뜬다.

위 관리창에서 당신이 사용할 프로파일을 만든다. 그리고 매번 선더버드를 켤때 ‘thunderbird -P’ 를 실행하여 프로파일을 선택하는 방법이 있는 반면…

thunderbird -P c0d3h4ck

위와 같이 프로파일 이름을 써주면 바로 이름에 해당하는 프로파일로 썬더버드가 시작된다.
능력이 된다면 바로가기에 위와 같이 프로파일에 맞는 명령을 넣어 바로 시작할 수 있다.

내가 아는 한 대부분의 마우스 우 클릭 제한은 자바스크립트 코드로 수행되어진다. 그런데 대부분의 브라우저에서 자바스크립트의 수행을 켜고 끌수 있다. 따라서 자바스크립트를 사용을 해제하면 마우스 우클릭 후 나오는 메뉴를 볼 수 가 있다. 그러나 문제는 대부분의 사이트들이 링크에서 자바스크립트를 남발한다는 것이다.  그래서 자바 스크립트 사용을 통째로 해제하면 링크가 열리지 않을 수 있다!

파폭에서는 아래 설명하는 방법으로 부분적인 자바스크립트를 해제 함으로써 나머지 자바스크립트는 작동하면서도 컨텍스트 메뉴에 대한 제한만 풀 수 있다.

도구(Tool) -> 설정(Preference) 을 선택하고 다시 내용(Content)를 선택한다. 그리고 자바스크립트 사용아기(Enable Java Script) 오른쪽에 있는 고급(Advanced) 버튼을 누르면 아래와 같은 설정 창이 나온다.

위에서 나머지는 그대로 둔채 위에서 세번째인 컨텍스트 메뉴를 사용하지 않거나 바꾸기(Disable or replace context menus) 의 체크박스를 해제하고 확인을 누르면? 마음껏 오른쪽 클릭을 즐길 수 있다!

Amarok 메인 화면

노래를 연주하면 왼쪽 Context 창에선 연주된 횟수, 연관된 가수들, 현재 가수의 노래중 내가 좋아하는 노래, 그리고 현재 가수의 다른 엘범등이 소개된다. 가사와 위키피디아 가 제공하는 가수 정보도 볼 수 있다.

Cover manager

lastfm 설정 화면

OSD 설정화면

리눅스엔 이 말고도 멋진 Media Player 들이 많습니다..
차차 소개 하겠습니다.