클로져를 이용해서 웹 어플리케이션 간단한 것을 만들어 보고 싶은 욕망이 있을 것입니다. 만들어 보고 싶은 욕망은 의외로 간단하게 해결이 됩니다. 바로 컴포져(Compojure) 를 이용하면 쉽게 만들 수가 있습니다.

예전 포스트 를 보고 클로져 개발환경이 세팅되어 있다고 가정합니다.

compojure 로 만들어진 예제를 다운 받습니다.

    $ cd ~/work (없으면 만들어 줍니다)
    $ git clone git://github.com/weavejester/compojure-example.git


 
    $ cd compojure-example
    $ lein deps
    $ lein ring server


이렇게 하고 좀 오랜 시간을 기다리면 Port 3000 번에 Jetty 를 이용한 어플리케이션 서버가 떠 있는 것을 확인 하실수 있습니다. ( http://localhost:3000 에 브라우져로 접속하면 바로 확인 가능)

쉽게 만들었으면 배포하고 서비스하고 싶은 것이 개발자의 마음 아니겠습니까?

요즘 화두가 되고 있는 nginx 를 설치하고 그 웹서버와 위에서 만든 (실은 다운 받은) 예제를 연결시켜 보겠습니다. 

먼저 nginx 를 설치해줍니다.

    $ sudo apt-get install nginx


또 한번 외쳐줄 필요가 있습니다. 우분투 만세!!!

이제 nginx 의 설정파일은 손 봐줍니다. 정확히는 site 설정 정보가 되겠습니다.

 
   $ sudo emacs /etc/nginx/sites-available/default


   
   
server {

        #       root /usr/share/nginx/www;
        root /home/crazia/work/compojure-example/resources/public;
        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to index.html
                try_files $uri $uri/ /index.html;
        # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
                proxy_pass      http://127.0.0.1:3000;
    }

    location ~*    ^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov|avi|wmv|mp3)$
    {
        break;
    }

   
    ....


   $ sudo /etc/init.d/nginx restart


위에 진하게 표시한 부분을 바꾸어 주시거나 추가해 주시면 됩니다. 간단하게 설명드리자면 기본적으로 정적인 파일들은 nginx 을 통해서 서비스가 되고 동적으로 만들어지는 파일들은 proxy_pass 를 이용해서 Jetty 가 떠 있는 3000 번 포트로 포워딩 하라는 뜻 입니다.

이제 접속을 유지하지 않더라도 항상 Jetty 가 떠 있게 만드는 방법을 알아볼 차례입니다. 이거 저거 설정해주기 귀찮더군요.

     $ lein ring server

이 부분을 screen 을 이용해서 계속 떠 있게 유지해줄 생각입니다. 일단 기존에 떠 있던 프로세스를 죽여줍니다. (간단하게 Ctrl-c 눌러줍니다)

그리고 스크린을 설치해줍니다.

     $ sudo apt-get install screen


다시한번 외쳐줄까요? 우분투 만세!!

     $ screen -S clj


이러면 가상 터미널이 한개 만들어 집니다. clj 라는 이름으로 말이죠

     $ cd ~/work/compojure-example
     $ lein ring server


Ctrl-a d (컨트롤 a 를 동시에 누른 다음에 d 누름) 이러면 화면에서 떨어져 나갑니다. 이상태에서 접속을 끊는다 하더라도 clj 라고 만들어진 가상 터미널 (스크린) 은  유지 됩니다.

다시 clj 로 돌아가고 싶으면

     $ screen -list
     $ screen -r clj


 -list 옵션은 어떤 스크린이 있는지 리스트를 확인하라는 명령입니다.

 이상입니다.
   

폴 그레이엄은 리습에 관한 책 두권을 썼습니다. 한권은 Common Lisp 을 바닥부터 쉽게 배울 수 있는 책입니다. 그리고 또 한권이 "OnLisp" 입니다.

마스터 하기만 하면 초 상급 리습 프로그래머가 될 수 있는 지름길로도 알려졌지만 그 난이도가 장난이 아닙니다. 요즘 마스터를 시도하고 있는데 역시나 무지 어렵습니다.

너무나 어려워서인지 잘 팔리지도 않아서 폴 그레이엄 사이트에 가면 무료로 배포하고 있습니다. ㅎㅎ

여기 에서 받아가세요.

그나저나 Chapter 7 의 제목이 'Macros' 더군요. 왠지 머릿속에서 '두둥' 하는 효과음이 들리는 것 같은 느낌이였습니다. (매크로는 진정한 리습을 쓰는 이유라고 까지 불리웁니다)


"리습은 그것을 마침내 손에 넣게 되었을 때 경험하게 되는 심오한 깨달음을 위해서라도 배울 가치가 있다. 리습을 이용할 일이 그렇게 많지 않다고 할지라도 그 경험은 그 자체만으로도 당신을 훨씬 훌륭한 프로그래머로 만들어 줄 것이다." - 에릭 레이먼드 (Eric Raymond)


제가 아는 선배가 송재경 (바람의 나라, 리지니 만드신 분) 씨와 인터뷰를 할 일이 있었는 데 그 분이 하신 말씀 중에

"프로그램은 어떠한 언어로 짜는 것이 중요한 것이 아니다. 가장 중요한 것은 전산적인 마인드를 소유하는 것이다"

라는 이야기를 들었다고 합니다. 상당히 많은 시간이 지났지만 이 이야기가 가지고 있는 의미는 아직까지도 도움이 됩니다. 저 또한 후학들을 만나면 이와 같은 이야기를 많이 합니다.

왜 리습을 공부해야 하는가? 전산적인 마인드를 소유하는데 도움이 되는 연습을 가장 열심히 할 수 있는 언어였다고 자신할 수가 있습니다.

저는 예전에도 리습을 공부하였고, 지금도 공부중이고 앞으로도 공부할 것입니다. 조금만 떨어지면 멀어져 버리는 전산적인 마인드를 붙잡기 위해서 입니다. (요즘은 리습 방언인 클로져에 빠져 있습니다)


제가 사용하고 있는 만화책 Viewer 는 JJComics 입니다. 일단 무료 이고요. 여러 코믹스 뷰어를 설치해 봤지만 이 어플만한 녀석이 없더군요.

그런데 TIF 파일을 못 읽는 안타까움이 있습니다. 하지만 Linux 사용자라면 편하게 이미지 파일 형식을 변환할 수 있는 툴이 들어 있습니다. convert 라는 툴인데요. Command Line 에서 편하게 파일을 변경할 수가 있습니다.

TIF -> GIF 로 바꿔서 다시 압축을 해주면 JJComics 에서 볼 수가 있습니다.

$ find . -type f -name '*.TIF' | while read filename; do echo "converting ${filename}"; convert "${filename}" "`echo "${filename}" | sed -e 's/\.TIF$/\.GIF/'`"; done


조금 설명을 부연하자면

1. 현재 디렉토리 ( . ) 에서 확장자가 TIF 인 파일을 찾습니다.

2. 그 각각을 filename 으로 인자로 받아들입니다.
   - while read filename 으로 가능합니다.

3.  간단한 변환 메시지를 출력하고
  -  converting ${filename} 을 통해서 그게 가능합니다

4. 실제로 convert 명령을 이용해서 변환을 가해 줍니다.
  - convert 001.TIF 001.GIF 와 같은 방식으로 변환이 가능합니다.
  - convert "${filename} 은 원래 파일 이름 (001.TIF)
  - "`echo "${filename}" | sed -e 's/\.TIF$/\.GIF/'`" 은 바껴질 파일 (001.GIF) 를 의미합니다.



lein 을 이용한 프로젝트 생성시 요즘 clojure 버젼이 1.4.0 이 기본인 것처럼 만들어 집니다. 아무 생각 없이 slime 을 연결해서 코딩을 시작하면 무엇인지 이상한 기분이 들기 시작합니다. 바로

doc

함수 입니다. doc 함수가 동작을 안합니다. "1.2.1" 버젼에서는 제대로 동작했는데 갑자기 동작안하기 시작합니다. 정확히는 "1.3.x" 와 "1.4.0" 에서 동작을 안합니다.

REPL 상에서

user> (use 'clojure.repl)


만 해주면 그 다음부터 사용이 됩니다.
보통 이런것들 볼 때마다 과장이 좀 심하구나 라는 생각을 했는데, IT 관련 사업을 해 본바, 그리 과장이 아닌 것들도 눈에 띕니다. 유머라고도 볼 수 있고 또는 교훈이라고 생각할 수 있겠습니다.

1. \"오늘까지\"라는 말은 \"내일 아침까지\"라는 말이다.

2. 프로그램은 내가 원하는대로 움직이지 않는다. 타이핑대로 움직인다.

3. 요구 사양은 프로그램을 완성한 후에 추가된다.
   기본 사양은 완성품을 고객이 보고 나서 결정된다.
   상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4. 소프트웨어 설계에는 두 개의 방법이 있다.

    하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다.
    다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5. 코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다.
    디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6. 프로그래머를 죽이기 위해서는 칼이 필요없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7. 다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다.
    주의사항 - 먼저 자신을 의심해라.

8. 개발에 마지막은 없다. 출시만이 있을 뿐이다.

9. 클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다.
    이것을「납기 불변의 법칙」이라고 한다.

10. 우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11. 주머니가 짠 고객일수록 잔소리가 많다.

12. 개발 스케줄은 산수를 무시하며 짜여진다. 영업과는 1+1=2를 이해하지 못하는 사람의 모임이다.

13. 한 명이 쓰러지면 모두가 쓰러진다.

14. 버그가 너무 심하다? 걱정마라. 어느 순간 그것은 기본 사양이 될 것이다.

15. 좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다.
     나쁜 설계는 백명의 범재보다 한 명의 천재를 요구한다.

16. 고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다.
     시스템 엔지니어에게 고객은 돈이다.
     프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17. 돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가?
      웃어라. 그 기회는 영원히 주어지지 않는다.

18. 품질은 사양 변경의 수와 규모에 의해, 얼마나 열화될지 결정된다.

19. 영업과는 공상이 실현된다고 생각하는 몽상가이다.
      시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다.
      프로그래머와는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20. 유능한 프로그래머가 프로그램 설계개념도를 받아들고 최초로 하는 일은, 프로그램의
     목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는
     도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21. 프로그램이란, 운과 감에 의해서 작성되는 기적이다.
      운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다.
      따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번
      일어날 것으로 믿는 무모한 행위이다.

22. 시스템 엔지니어는 지구력, 프로그래머는 순발력.

23. 정시에 퇴근하면, 일이 늘어난다.

24. 완벽한 프로그램은 완벽한 시간과 돈을 필요로 한다.
      미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25. 눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이,
      쉴 수 있다.

26. 불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와
     납기일에 의해 결정된다.

27. 정장 대신 캐쥬얼을 입고 출근하는 \"캐쥬얼 데이\"를 세간에서는 휴일이나 공휴일이라고 부르는
      것 같다.

28. 프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29. 내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30. 고객은 거짓말을 한다.
      영업은 꿈을 말한다.
      시스템 엔지니어는 공상을 이야기한다.
      프로그래머는 과묵해진다. (혼잣말은 많아진다)

31.「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰히 다시 생각해보라.

32. 프로그래머는 1분 생각하고 1일을 코딩에 소비한다.
      1시간 생각하고 1시간 코딩하는 대신에 말이다.

33. 납품 이후의 디버그는 버그를 부른다.

34. 세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 엔드리스 루프라고 한다.

35. 안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지
      않는다. 그것은 시스템 엔지니어의 일이다.

36. 아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37. 아마추어는 버그발견의 천재이다.

38. 아, 그건 마이크로소프트에서만 가능한 주문입니다.

39. 프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40. 건강하기 때문에, 건강을 해친다.

41. 그건, 당신이 말한 요구조건입니다만.

42. 아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43. 고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다.
      시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다.
      프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44. 만약 다른 직업을 갖게 된다면, 정시퇴근을「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45. 시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46. 최소한 자기가 쓴 시방서는 읽어주세요.

47. 고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을
      깨닫고 빨리 최종요구조건을 확정하는 것이다.

     SE가 고객에게  사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48. 납기일이란, 작업현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49. 가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50. 개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다.
     개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다.
     개발비의 30%는 프로그램의 버그를 잡는데 사용된다.
     개발비의 10%만이 프로그램의 개발에 사용된다.


하둡에서 파생된 로그를 수집하고 , 분석할 수 있는 오픈소스 솔루션입니다. 물론 로그를 분석하는 것은 하둡의 맵-리듀스를 이용합니다.

하둡 자체가 로그를 분석하기 위한 목적으로 태어났기 때문에, 로그를 수집하는 솔루션은 어찌보면 당연하게 하둡에서 파생될 수 밖에 없었을 거라 생각합니다.

설치법 자체는 간단합니다. 척와 소스를 내려 받습니다.

http://ftp.daum.net/apache/hadoop/chukwa/chukwa-0.4.0/ 여기에 가면 있습니다.

  
   $ cd ~/work
   $ tar xvzf chukwa-0.4.0.tar.gz
   $ cd chukwa-0.4.0
   $ ant

  
하면 컴파일 되면서 설치 완료 입니다.
척와를 제대로 동작시키기 위해서는 하둡이 설치되어 있어야 합니다.

하둡 설치는 예전 문서를 참조하시면 됩니다.

   ~/work/hadoop-1.0.2


에 하둡이 설치되어 있다고 가정합니다. 버젼은 1.0.2 버젼입니다. 그리고 물론 하둡은 떠 있는 상태여야만 합니다.

chukwa-env.sh 파일을 열어서 간단하게 편집해줍니다.

   $ cd ~/work/chukwa-0.4.0/
   $ emacs conf/chukwa-env.sh

chukwa-env.sh 내용


   export JAVA_HOME=/usr/lib/jvm/default-java
  
   export HADOOP_HOME="/home/crazia/work/hadoop-1.0.2"
   export HADOOP_CONF_DIR="/home/crazia/work/hadoop-1.0.2/conf"

   export chukwaRecordsRepository="/chukwa/"

   export CHUKWA_PID_DIR=/home/crazia/tmp/chukwa/pidDir

   export CHUKWA_LOG_DIR=/home/crazia/tmp/chukwa/log

 
위와 같은 부분을 찾아서 자신의 환경에 맞춰서 변경해줍니다.

  
$ emacs conf/collectors


collectors 내용
  
http://localhost:8080


이부분은 콜렉터 (로그 저장하는 데몬)가 떠 있는 위치를 지정하는 것입니다.

  
$ emacs conf/initial_adaptors

initial_adaptors 내용

  
   # add org.apache.hadoop.chukwa.datacollection.adaptor.ExecAdaptor Iostat 60 /usr/bin/iostat -x -k 55 2 0
   # add org.apache.hadoop.chukwa.datacollection.adaptor.ExecAdaptor Df 60 /bin/df -l 0
   # add org.apache.hadoop.chukwa.datacollection.adaptor.ExecAdaptor Sar 60 /usr/bin/sar -q -r -n ALL 55 0
   add org.apache.hadoop.chukwa.datacollection.adaptor.ExecAdaptor Top 60 /usr/bin/top -b -n 1 -c 0

앞의 세개는 루트 권한을 필요로 하기 때문에 # 처리 해 줍니다.

   $ cd ~/work/hadoop-1.0.2
   $ cp hadoop-core-1.0.2.jar hadoop-1.0.2-core.jar

   구동되는데 이 파일 (hadoop-1.0.2-core.jar) 이 필요합니다.

  
   $ cd ~/work/chukwa-0.4.0/lib
   $ cp ~/work/hadoop-1.0.2/lib/commons-configuration-1.6.jar .

컬렉터를 띄우는데 이 파일 (commons-configuration-1.6.jar) 이 필요하더군요.

이제 컬렉터를 띄워줍니다.

   $ cd ~/work/chuckwa-0.4.0
   $ bin/start-collectors.sh

로 띄우고

 
  $ bin/chukwa agent


로 agent 를 띄워줍니다.
  
http://localhost:50070 에서 실제로 파일이 저장되는지 확인해 봅니다. 대략 5분마다 한번씩  저장됩니다.


boost 1.46 버젼, 쓰리프트 0.8.0 버젼을 기반으로 하여 스크라이브를 설치하는 방법입니다. 스크라이브는 현재 4년간 소스에 변동이 없습니다. 따라서 최신 라이브러리 기반으로 컴파일 할려고 하면 알려준 방법대로 되지 않습니다. 

1. 부스트 설치 

$ sudo apt-get install libboost-all-dev libevent-dev automake libtool flex bison pkg-config g++ libssl-dev 


언제나 우분투 (Debian) 계열 (민트도 우분투 계열이라고 볼 수 있으니..) 이라고 가정하고 이야기 할 것입니다. 

2. 쓰리프트 (Thrift) 설치 

$HOME/work 밑에 설치한다고 가정하고 

       $ cd ~/work 
       $ git clone git://git.apache.org/thrift.git
       $ cd thrift
       $ ./bootstraph.sh
       $ ./configure
       $ make
       $ sudo make install
       $ cd lib/py
       $ sudo python setup.py install


 fb303 부분을 컴파일 해줘서 설치합니다. 
       
 

       $ cd ../../contrib/fb303
       $ ./bootstraph.sh
       $ ./configure
       $ make
       $ sudo make install 


만약 이 방법으로 컴파일 안될 시에는 

$ ./configure CPPFLAGS="-DHAVE_INTTYPES_H -DHAVE_NETINET_IN_H  -DBOOST_FILESYSTEM_VERSION=2 -DHAVE_NETDB_H=1 -fpermissive"


해주고 make 와 make install 을 해주면 됩니다. 


3. 스크라이브 설치 

       $ cd ~/work
       $ git clone http://github.com/facebook/scribe.git
       $ cd scribe
       $ CPPFLAGS="-DBOOST_FILESYSTEM_VERSION=2" ./bootstrap.sh
       $ ./configure CPPFLAGS="-DHAVE_INTTYPES_H -DHAVE_NETINET_IN_H  -DBOOST_FILESYSTEM_VERSION=2 -DHAVE_NETDB_H=1 -fpermissive"
       $ make 

       

아마 에러가 발생할 것입니다. 

       undefined reference to boost::system::generic_category()'

위와 같은 에러인데 라이브러리 링크 순서를 바꾸어 주면 거짓말 처럼 해결이 되더군요. 

     

 $ cd src
 $ g++  -Wall -O3  -o scribed store.o store_queue.o conf.o file.o conn_pool.o  scribe_server.o network_dynamic_config.o dynamic_bucket_updater.o  env_default.o -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lfb303 -lthrift -lthriftnb -levent -lpthread  libscribe.a libdynamicbucketupdater.a  -L/usr/lib
       -lboost_system-mt -lboost_filesystem-mt 


원래 붉은 색으로 표시 된 부분이 문장 앞 부분에 존재하는데 이를 뒷 부분으로 돌리면 됩니다. 

 
NodeJS 는 예전부터 C/C++ 이 차지하던 위치를 (최근에 Python 이 차지한 것 같은 이야기가  있습니다) 차지한 것 같은 언어 입니다. (C/C++ 에 비하여) 어렵지도 않고 아주 쉽고 편하게 서버 어플리케이션을 만들 수 있는 쉬운 언어 입니다. 그 쉬운 NodeJS 를 살펴볼 일이 있어서 잠깐  살펴보게 됐습니다.

 설치법

여러가지 해줘야 하는 것이 있지만, 우리는 Ubuntu 를 쓰지 않겠습니까? 초 간단하게 설치가 가능합니다. (당연히 Mint 도 동일합니다)
   
    sudo apt-get install python-software-properties
    sudo apt-add-repository ppa:chris-lea/node.js
    sudo apt-get update
    sudo apt-get install nodejs npm   


 구동 테스트

간단하게 파일을 한개 편집해줍니다.

   
$ emacs example.js

그리고 다음과 같은 내용을 써 줍니다.
	
    var http = require('http');

    http.createServer(function (request, response) {
    response.writeHead(200, {'Content-Type': 'text/plain'});
    response.end('Hello World\n');
    }).listen(8124);

    console.log('Server running at http://127.0.0.1:8124/');

이제 다 됐습니다. 바로 확인해 보기로 합니다.

 
   $ node example.js

브라우져에서 http://localhost:8124 를 입력해서 제대로 동작하는지 테스트 합니다.

사실 이 정도 쉽게 해주는 방법은 많이 나왔지만, 이 언어가 각광 받는 이유는 여러가지가 있겠습니다. 일단 가볍고, 문법 자체가 JavaScript 기 때문에 배우기도 쉽고 (이거 될까? 하는게 다 되는게 자바 스크립트 입니다 ㅎㅎ) 그리고 만들어진 결과물 자체의 효율도 좋습니다.



클라우드 서비스의 성능을 측정하기 위한 벤치마크 툴입니다. 여러개의 대안이 있을 때 어떤 것이 우리쪽에 더 적합한가 측정하기에 아주 훌륭한 도구 입니다.

  YCSB 메인 페이지


설치 방법

   
    $ wget https://github.com/downloads/brianfrankcooper/YCSB/ycsb-0.1.4.tar.gz
    $ tar xfvz ycsb-0.1.4.tar.gz
    $ cd ycsb-0.1.4


컴파일 된 바이너리를 다운 받는 방법 (자바로 추정)

    $ git clone git://github.com/brianfrankcooper/YCSB.git
    $ cd YCSB
    $ mvn clean package


실제로 다운 받아서 컴파일 하는 방법. 그러나 컴파일이 안됩니다. asm 3.1.jar 의 압축이 풀리지 않는다는 이유로 에러가 발생합니다. (여기서 중단.. 안되는 일을 되게 할려는 노력도 중요하지만 굳이 쉽게 되는 일이 있는데 할 필요는 없는 듯..)

설치가 됐으면 실제로 테스트 해보는 시간입니다. 자세한 설명은

 https://github.com/brianfrankcooper/YCSB/wiki/Running-a-Workload

위 주소에서 잘 나와 있습니다. 그러니 생략하고 제가 좋아하는 실전형 따라하기 모드로 가겠습니다. MongoDB 에서 테스트를 한다고 가정합니다.

    - MongoDB 는 Local 에 설치되어 있다고 가정합니다. Port 는 40001 에 띄워져 있습니다.
   

YCSB 는 2가지 형태의 모드가 있습니다. (정확히는 3가지지만 shell 은 당장 안 쓸거라서 설명에서는 제외하겠습니다) 즉 load 와 run 입니다.


    load

데이터를 벤치마크 대상 데이터 저장소에 삽입하는 일입니다.


    run

이미 들어간 데이터를 가지고 벤치마크 테스트를 행하는 일입니다.


그러나 load 는 간단한 건에 대해서는 잘 동작하지만 건수가 억단위로 가면 시간이 기하급수적으로 늘어납니다. 그래서 데이터를 입력하는 것은 수동으로 1-100000000 의 숫자 아이디를 가진 'x' * 1000 바이트 짜리 데이터를 입력하는 모듈을 짜서 데이터를 입력해 두었습니다. (load 가지고 테스트를 하고 싶으면 대략 10만에서 100만 정도 까지 데이터를 입력하는 형태로 운영하시면 좋습니다)

ycsb-0.1.4 디렉토리에 있다고 가정하면 결론부터 이야기 하기로 하겠습니다.

 
   $ ./bin/ycsb run mongodb -P workloads/workloada -P mongo.ini -s > result.log


지금은 이대로 따라서 하면 에러가 발생할 것입니다. (그러나 어떤 원리인지 모르지만 파라미터가 틀려도 기본적으로 동작합니다.)


ycsb 는 실행 명령입니다.

run 은 transaction mode 로 실행하라는 소리입니다.

mongodb 는 내가 테스트 하고 싶은 DB Layer 가 MongoDB 라는 소리입니다.

-P workloads/workloada 는 Property 로 workloads 디렉토리 밑에 있는 workloada 를 선택해 주라는 이야깁니다. Property 는 지정 파일을 열어보시면 ycsb 를 실행할때 필요한 설정들이 들어 있는 것을 확인하실 수 있습니다. -P 는 파일을 지정할 수 있고, -p 는 개별 설정들을 지정할 수 있습니다.

-P mongo.ini 는 내가 지정해 줄 수 있는 설정들을 포함하고 있습니다. -P 인것을 보니 파일을 지정하는 것이겠지요? workloada 와 mongo.ini 에 같은 항목에 대한 언급이 있다면 마지막에 명시된 설정값을 따릅니다. 즉 위 예제에 따르면 mongo.ini 에 있는 것을 따르게 되어 있습니다.

-s 는 10초마다 진행사항을 보여주라는 의미입니다.


그리고 mongo.ini 의 내용입니다.


    mongodb.url=mongodb://localhost:40001
    mongodb.database=mydb
    mongodb.writeConcern=normal
    table=robots
    operationcount=10000


내용중에 관심 있게 볼 것은
   

url 은 mongodb 가 떠 있는 주소와 포트입니다.
database 는 테스트할 대상이 있는 db 의 이름입니다.
table 은 테스트할 대상이 있는 collection 의 이름입니다.
operationcount 는 내가 run 을 실행할때 몇번의 수행작업을 할 것인지 정해주는  것입니다. (load 시에는 recordcount 입니다)

어려운듯 보입니다만 (실은 어려웠습니다.. ) 막상 실행을 해보니 어렵지는 않더군요.

+ Recent posts