2015년 12월 29일 화요일

Mesos 0.26.0 - 기본 설치 세팅 On CentOS7.X

최근 들어 Mesos 버전업이 매우 빠른 듯 하다.
약 4개월 전 TO-BE Cluster 에 최신 버전 업그레이드를 한 바 있었는데.. 금일 TO-BE 클러스터에 0.26.0 으로 다시 클러스터 버전을 업그레이드 해보았다. 고세 TO-BE 클러스터의 갯수가 3배 이상 늘어 났기도 하고...
(*주의* : 2015년 12월 30일 현재 Spark 1.5.1과 본 Mesos 버전에는 일부 so모듈상에 호환성 문제가 발견되고 있음.)

DevOps 환경인지라...TO-BE 라고는 하지만, 부분 적으로 AS-IS 운영 모드로도 사용 중인 지라, 당분간 Adhoc 배치 위주로 버전 업 된 Mesos 환경에서 여러가지 AS-IS 모듈들을 돌려 보아야 하겠다. 아래는 디테일한 튜닝 작업 전 기본 세팅 버전의 설치 스크립트 이다.

무슨 일기 쓰는 느낌이네...
  1. Download 및 설치 준비
    1. wget http://apache.mirror.cdnetworks.com/mesos/0.26.0/mesos-0.26.0.tar.gz
    2. tar xvzf mesos*.tar.gz
    3. cd mesos-0.26.0
    4. sudo wget http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo -O /etc/yum.repos.d/epel-apache-maven.repo
    5. epel-release 설치
    6. sudo yum install -y epel-release
  2. Mesos dependency 모듈 설치
    1. dependency 프로그램을 위한 추가 설정
    2. $ sudo cat > /etc/yum.repos.d/wandisco-svn.repo <<EOF
      [WANdiscoSVN]
      name=WANdisco SVN Repo 1.9
      enabled=1
      baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/
      gpgcheck=1
      gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco
      EOF
    3. sudo yum update systemd
    4. sudo yum groupinstall -y "Development Tools"
    5. sudo yum install -y apache-maven python-devel java-1.8.0-openjdk-devel zlib-devel libcurl-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 apr-devel subversion-devel apr-util-devel
  3. Mesos 설치
    1. cd mesos폴더
    2. ./bootstrap
    3. mkdir build
    4. cd build
    5. ../configure
    6. make -j (core갯수) V=0
    7. make check
    8. sudo make install
  4. Master Node Running Script
    1. work_dir 설정
      1. mkdir /data02/mesos
    2. build/bin 아래에 run script 만듦.
      1. /data01/mesos/mesos-0.26.0/build/bin/mesos-master.sh --ip=서버IP --work_dir=/data02/mesos &
      2. 구동.
  5. Slave Node Running Script
    1. build/bin 아래에 run script 만듦.
      1. /data01/mesos/mesos-0.26.0/build/bin/mesos-slave.sh --master=서버IP --work_dir=/data02/mesos &
      2. 구동
  6. Web 관리 콘솔 구동
    1. http://masterNo_IP:5050

2015년 11월 26일 목요일

Kafka 0.8.22 설치기

2년 하고도 6개월 전 설치한 카프카를 지금도 잘 쓰고 있다가, 매우 매우 오랜만에 Kafka 를 버전 업 설치 해 보았다. ( 그냥 다시 설치 했다는 표현이 더 맞을 것이다. )

Kafka 는 정말 에러 없이 안정적인 기능을 제공해 준 에코 시스템 중 하나이다. 거의 문제를 일으키지 않았으며, 가끔 콜렉션 레이어나 hadoop 레이어가 잠시 문제가 있거나, 재부팅을 하는 동안, 훌륭하게 버퍼 역할을 해 주었다.

아쉬운 점은 내심 2년 반 만의 업그레이드 이니, 무언가 새로운 기능들이 있었으면 했는데, 기능 개선이 거의 없었고, 심지어 버전도 얼마 오르지 않았다는 점이다.

링크드인의 한국인 개발자에 의하여 '수로' 라는 별도 파생 프로젝트가 생긴것으로 아는데, 우선 '수로'는 다음 기회에 살펴보기로 하고, TO-BE 머신의 한켠에 Kafka 최신 버전을 가볍게 세팅해 보았다. (참고, 아래 설정은 최초 Initial 세팅이다. 세세한 Production 모드 세팅은 차근 차근 할 거라는 예기...)

설치방법

  1. 다운로드 및 설치
    1. wget http://apache.mirror.cdnetworks.com/kafka/0.8.2.2/kafka_2.10-0.8.2.2.tgz
    2. tar xvzf kafka_2.10-0.8.2.2.tgz
  2. 설정
    1. config/zookeeper.properties 내 dataDir 경로 수정
      1. 해당 경로에 디렉토리 생성 후 수행.
    2. config/consumer.properties 내 zookeeper connect 주소 변경
    3. config/producer.properties 내 metadata broker list 주소 변경
    4. 브로커의 server.properties 를 2개로 copy 하여 새로 만들고 내부 변수 변경
      1. broker.id 변경
      2. port 변경
      3. log.dir 변경
      4. zookeeper 주소 변경
    5. 각 파일들을 N개 노드에 복사 싱크
  3. 구동
    1. 1번노드에서 Zookeeper 구동
      1. bin/zookeeper-server-start.sh config/zookeeper.properties &
    2. 브로커노드에서 
      1. bin/kafka-server-start.sh config/server-1.properties &
      2. bin/kafka-server-start.sh config/server-2.properties &
  4. 토픽생성
    1. 1번노드에서
      1. bin/kafka-topics.sh --create --zookeeper 서버주소:2181 --replication-factor 2 --partitions 1 --topic ssg-replicated-topic
    2. 1번노드에서
      1. bin/kafka-console-producer.sh --broker-list 서버주소1:9093,서버주소2:9094 --topic ssg-replicated-topic
    3. 3번노드에서
      1. bin/kafka-console-consumer.sh --zookeeper 서버주소:2181 --from-beginning --topic ssg-replicated-topic
  5. 메시지 전달 테스트
    1. Producer

    2. Consumer

2015년 11월 19일 목요일

Grafana (RealTime Visualization) - version upgrade (2.1.3 -> 2.5.0)

Grafana 리얼타임 시각화 도구가 최근 2.1.3에서 2.5.0 으로 급격하게 버전이 바뀌었다. 패널을 드래그&드롭 하거나 크기를 자유롭게 마우스로 변경 한다던지, ElasticSearch 등에 대한 Full Featured Query Editing 을 지원한다던지 하는 기능도 추가 되었다.

  1. 다운로드 및 설치
    1. 다운로드 & yum install
    2. sudo yum install https://grafanarel.s3.amazonaws.com/builds/grafana-2.5.0-1.x86_64.rpm
  2. 설정 변경 ( 2.1.3과 좀 바뀐부분이 많다 )
    1. vi /etc/sysconfig/grafana-server  
      1. data 디렉토리 변경
        1. DATA_DIR=/data02/grafana/data
      2. log 디렉토리 변경
        1. LOG_DIR=/data02/grafana/log
    2. 그리고 vi /etc/grafana/grafana.ini 에서도 수정
      1. ;data = /data02/grafana/data
      2. ;logs = /data02/grafana/log
      3. ;http_port = 3033
    3. vi /usr/share/grafana/conf/defaults.ini (기본 port 는 요기서도 변경 해주어야 적용이 되었다.)
      1. 기본 Port 변경
        1. http_port = 3033
      2. 기타 Password 등 변경
  3. 구동
    1. sudo service grafana-server start
    2. 구동시 자동 구동되도록 설정
      1. sudo /sbin/chkconfig --add grafana-server
  4. 관리 Web Console

2015년 11월 18일 수요일

Grafana (RealTime Visualization) 2.1.3 - 설치기

influxDB 및 graphite 와 궁합이 좋은 실시간 시각화 툴.(최근 버전은 ElasticSearch 도 지원한다.)
이 툴을 이용하면, 실시간 Dash Board 를 Wizard 모드로 쉽게 만들어 낼 수 있다. 최근에 2.5.0 버전이 나왔는데....
요건 오래전에 정리해놓고 올리지 못한 2.1.3 버전 설치 문서...

  1. 다운로드 및 설치
    1. 다운로드 & yum install
    2. sudo yum install https://grafanarel.s3.amazonaws.com/builds/grafana-2.1.3-1.x86_64.rpm
  2. 설정 변경
    1. vi /usr/share/grafana/conf/defaults.ini 
      1. data 디렉토리 변경
        1. data = /data02/grafana/data
      2. log 디렉토리 변경
        1. logs = /data02/grafana/log
      3. 기본 Port 변경(필요시에만...)
        1. http_port = 3033
      4. http_addr 수정
      5. domain 수정
      6. admin_passwd 변경
  3. 구동
    1. sudo service grafana-server start
    2. 구동시 자동 구동되도록 설정
      1. sudo /sbin/chkconfig --add grafana-server
  4. 관리 Web Console

InfluxDB (Distributed time series database for RealTime Aggregation) - version upgrade (0.9.3 -> 0.9.4.2)

InfluxDB를 Production Level 에서 사용해 보면, 초반에 느껴지는 강렬한 장점들 외에도, 보이지 않는 부분에 단점도 많이 발견 되는 것이 사실이다. 무엇보다, 아직 정식 1.0 버전이 아닌지라 아직 미완의 기능들이 존재하여, 더욱 그럴것이다.

그럼에도 불구하고 버전업이 빠르고, 여러가지 플러그인 프로젝트들도 활발하여, 어찌 되었든 매우 매력적인  NoSQL이다라는 느낌에는 변함이 없다.

0.9.3 을 사용한지 얼마 되지 않았지만, 0.9.4.2 로 현재 stable 버전이 올라가 있어(현재 0.9.5가 RC3 까지 나와 있긴 하지만..), 버전 업 적용을 해 보았다.

아쉽게도, 홈페이지 설치 메뉴얼은 아직 0.9.3 버전에서 갱신이 일부만 되어 있어 그데로 설치 했다가는 설치가 잘 되지 않는 현상이 존재한다.( 2015년 11월 17일 현재 CentOS 7.X 에서만..)

아래는 CentOS 7.X 에 /etc/init.d/ 가 아닌 systemctl 환경에서 에러가 나는 부분을 수동 구동 방식으로 해결한 설치 스크립트 세팅 방법이다. (개인적인 해결 방법이므로 비공식 구동 방법임.)


  1. 기본설치
    1. 기본적인 설치는 0.9.3과 동일하다.
      1. http://hoondongkim.blogspot.kr/2015/08/influxdb-distributed-time-series.html
  2. 클러스터 세팅
    1. 클러스터 세팅 방식이 2015년 11월 17일자 공식 홈페이지 상의 설치 문서로는 CentOS7.X 에서 구동이 되지 않는다. (0.9.3 스타일로 설명이 되어 있는데, 0.9.4.2 에서의 버그 이거나, 혹은 CentOS7.X 버전에서만의 버그 일 수 있음.)
    2. 그래서 아래처럼 해주었다.
      1. sudo vi /etc/opt/influxdb/influxdb.conf
        1. hostname = "localhost" 를 각 노드 hostname 으로 수정
        2. port 를 1번노드는 :8088 , 2번노드는 :9099 , 3번노드는 :10101 로 수정.
      2. 전체 노드에서 아래처럼 변경
        1. sudo vi /opt/influxdb/init.sh 에서 아래 수정
          1. USER=수행USER_ID (예, root)
          2. GROUP=수행GROUP_ID (예, root)
          3. PIDFILE 수정 후 Permission을 위 ID 로 Read/Wrtie 가능하게 수정.
          4. STDERR 도 경로 및 퍼미션 수정
        2. sudo vi /etc/opt/influxdb/influxdb.conf 에서 hinted-handoff 부분 dir 프로퍼티 수정
          1. 경로를 위 1에서 만든 USER_ID 가 억세스 가능한 디렉토리로 수정.
        3. root 가 아닌 경우 권한에 따라 go 랭귀지 소스를 tmp 디렉토리에서 빌드 수행시 에러 날 수 있음. go 소스 수행 권한이 있는 USER_Group 이어야 함.
      3. 1번 노드에서 아래처럼 구동
        1. 메뉴얼데로 하면 안됨.
        2. sudo /opt/influxdb/init.sh start
      4. 2번노드에서 아래처럼 INFLUXD_OPTS 값 변경 및 구동
        1. sudo vi  /opt/influxdb/init.sh 에서 INFLUXD_OPTS="-join hostname1:8088"
        2. sudo /opt/influxdb/init.sh start
      5. 3번노드에서 아래처럼 INFLUXD_OPTS 값 변경 및 구동
        1. sudo vi  /opt/influxdb/init.sh 에서 INFLUXD_OPTS="-join hostname1:8088,hostname2:9099"
        2. sudo /opt/influxdb/init.sh start
  3. 설치완료 확인
    1. 3Node 인 경우의 클러스터 구성 확인. 이후 동일한 방법으로 Node 추가 하고 클러스터 확인 하면 끝.
    2. WebConsole 확인. 아직 변화는 없넹....
 

2015년 10월 20일 화요일

Spark Yarn Cluster vs Spark Mesos Cluster : [두번째] 안정성 및 DevOps 측면 비교

지난번 Spark Yarn Cluster vs Spark Mesos Cluster (vs 기타 다양한 모드) : [첫번째] 수행성능 및 활용성 비교 이어 이번에는 안정성 및 DevOps 측면에서 비교를 해보았다.

첫번째 포스트를 보고 많은 분들이 개인적인 문의를 주셨다. 그리고, 많은 반박글도 보내주셨다. 주로 Yarn모드를 쓰시는 분들의 반박 내용이 많았는데... 그 분들과 대화를 나누어 보면, 사용하고 있는 옵션이나 세팅은 큰 차이가 없었다. 하지만, 데이타의 저장 방식이나 성격, 수행하고 있는 Batch 의 성격과 주기 그리고, HW 구성이 저마다 달라 충분히 다른 결과가 나올 수 있음을 서로 공감할 수 있었다.

나 역시 Yarn 모드 수행 초반에는 Yarn모드의 성능에 대하여 Over Estimate 한 적도 있었다. 그래서 한동안 TO-BE 아키텍처가 상당 부분 Yarn 모드였던 적이 있었다. 뒤에서도 설명하겠지만, TO-BE 아키텍처 부터 DevOps 구성을 도입 한지라, TO-BE 라고는 하지만, 상단 기간 Production 배치를 리얼 모드 테스트가 가능하였다. 그로부터(DevOps 환경으로부터) 설정을 다양하게 바꾸어 가며 충분한 태스트 해 볼 수 있었고, Job의 성격도 달리 해가며, 다양한 리얼데이타 태스트를 해본 결과 아키텍처를 좀더 우리 환경에 맞는 걸로 변경 적용 할 수 있는 경험치를 얻게 되었다.

지난번 글이 다소 Mesos 에 치우친 글이 었을 수 있을 것이다. 하지만, 모든 면에서 Mesos가 유리한것은 아니다. Yarn 모드가 유리한 부분도 분명 존재하며, 오늘 두번째 고찰에서는 그런쪽도 함께 언급 하도록 하겠다.

두 가지 모드 모두 장단점을 가지고 있는데, 취사 선택은 자신의 몫일 것이다. 자신이 보유한 HW  구성의 특성이나, 비지니스 로직의 성격, 데이타 소스의 성격에 따라, 그리고 무엇보다 중요한 Priority 에 따라 어떤 구성을 할지 선정해야 하며... 그것이 바로 AA(어플리케이션 아키텍처의)의 역할이기도 할것이다.

시작하기에 앞서

서두에 언급한 것 처럼, 여기에 언급 된 내용은 다분히 일부 기능, 혹은 일부 요소에만 국한되어, 성급한 일반화로 보여 질 수 있을 것이다. 본 내용은 논문이나 구글링을 하며 학습한 내용을 적은것이 아니라, 개인적인 경험에서 느낌점을 나열한 것일 뿐이기 때문이다. 돈을 받고 컨설팅 리포팅을 하는 입장이 아니므로, 나에게 혹은 우리 조직에 있어 중요한 요소를 실험 및 경험으로 채득하고, 그 부분에 특화하여 언급하였을 뿐이다.
MECE(Mutually Exclusive and Collectively Exhaustive) 하게 모든 고려 요소를 훓터 주고 있는 건 아니므로, 이 글을 참고하여 아키텍처를 수립하려고 하시는 분들은 꼭 자신의 데이타와 자신의 요건을 가지고 실험을 직접 해보면서 아키텍처 검증 과정을 거치시라 첨언하는 바이다.

[1] 안정성 측면

안정성은 약간 양날의 검인 부분이 존재한다. 지난번 포스트에서도 언급한 바 있지만, Yarn 모드에서는 excutor 갯수, core 갯수(물론 driver-memory 와 excutor-memory 설정도 각각 해줘야 하고...)를 수동 지정해야 하고, Mesos 모드에서는 그 할당을 Mesos 가 추상화 해 주어서, 정교한 세팅을 하지 않아도 되는... 그래서 Mesos 에 활용성 측면에서 더 많은 점수를 주었던 바 있었다. ..( Yarn 도 이런 설정이 불가능 한것은 아니다.. Yarn Dynamic Resource Allocation 으로 검색 해 보시길.. 메커니즘은 약간 다른것 같다. 특히, excutor가 remove 될때 RDD 가 같이 사라지는 문제가 있어, 이 문제를 해결하기 위해 RDD  를 전달 하는 external shuffle 메커니즘이 Mesos  의 그것과 좀 다르다. 아키텍처 특성상.. Mesos 는 해당 Tier 자체가 공유 Memory 를 고려한 프레임워크 인지라 이런 공유 RDD 처리가 좀더 메크러운 것 같다.)
활용성이라고 표현을 하긴 했지만, Production 용 배치로 Job을 돌려 보면, 약 3배 정도 Yarn 모드가 더 빈번한 Java Heap Memory 에러를 접하게 된다.(좀 빡세게 리소스를 Fully 활용하는 경우에 한하여..)

여기까지만 보면 Mesos 모드가 3배 더 안정적이다 라고 결론을 내릴 수도 있다.

하지만, 내가 내리는 결론은 약 52 : 48 정도로 안정성 측면에서는 Yarn 모드에 점수를 더 주고 싶다. 그 이유는 다양한 Job 이 경합을 벌이는 상황에서, Yarn 은 각 Job 의 성격 별로 Queue 나 User 별 그룹을 주고, 그룹 별 Resource 제한이나, 정교한 Priority 설정이 가능하다는 성격 때문이다. (DW 에서도 이런기능이 약한 DW가 있고, 강한 DW가 있다. 물론 필드에서는 기능이 있긴 하지만, 활용하지 않고 사용하는 경우도 태반이긴 하지만...)


위 처럼 복수개의 Queue 를 만들고, 수행하는 Job 별로 Priority 나 동시에 수행가능한 App의 갯수, max Resource 등을 제한하면, Production 환경에서 꼭 수행되어야 하는 Job 과 월배치 처럼 에러가 나면, 다시 돌려도 되는 Job , 그리고, adhoc 배치 처럼 에러가 나도 무방한 Job ,  혹은 Backup 용 부수적인 Job 들을 분리하여, 안정성이 높아야 할 Job 들은 에러가 덜 나고, 혹여나 에러가 나더라도, 안정성이 중요치 않은 Job 들이 에러가 나도록 세팅이 가능하다.

위의 파일을 세팅하기 위해서는 사실 위 파일만 가지고는 안된다. 우선 yarn-site.xml 에 요런식의 별도 설정 추가가 필요하다.



 위처럼 파일경로를 세팅하지 않으면, Yarn 은 Default 로 Capacity Scheduler 를 사용한다. 병렬 수행을 하면서, 그 Queue 별 그룹핑을 하기 위해 앞에서 언급한 Scheduler 세팅은 Fair Scheduler 를 사용한 예이다. (default 로는 존재하지 않아 새로 생성해 주고 내용을 체워줘야 한다.)

하지만 불행히도, Hadoop Config 상의 위 2개 파일만 세팅하면, 일반적인 MR  Job과 Hive 나 Cascading 처럼 외부 Layer 가 수행한 MR성 Job 그리고 Spark Job 간의 관리만 가능하다. 복수 Spark Job 들 내부에서도 정교하게 그루핑을 하고, Fair 모드를 사용하기 위해서는 별도의 추가 세팅이 필요하다.

해당 내용(세번째 세팅)은 아래 메뉴얼에 잘 나와 있다. (1.5.1 세팅의 예임...)
http://spark.apache.org/docs/latest/job-scheduling.html#fair-scheduler-pools

위 까지 모두 세팅을 마무리하고 나면, Spark Job 도 병렬 수행도 되고, 리소스 할당에 제한을 줄수도 있으며, Priority 를 주어 Resource 경합 시 어떤 Job 에 리소스를 몰아 줄지 보다 더 정교한 세팅이 가능하다. 아래처럼 Job 이 동시에 도는 세팅만 하고 싶어도 위 3가지 설정 중 3번째 세팅은 필수로 필요하다. (물론 그것을 구현하기 위한 다른 방법도 존재하긴 하지만..)

위와 같은 세팅은 Mesos 에는 매우 약한 부분이다. 그래서, Heap Memory 에러가 훨신 덜 나는 Mesos 라 할지라도, Yarn 에 더 많은 점수를 주었다. (Mesos 의 경우 동시 수행 세팅은 약 10배 설정이 편하고(거의 할게 없다.), Priority 및 리소스 제약 세팅은 약 30배 세팅이 복잡하다.(편법을 동원하지 않고는 거의 잘 안된다.))

[2] DevOps 측면

위처럼 Yarn 은 정교한 수동 세팅을 할 수 있는 반면, 정교한 수동 세팅은 달리 말하면, 관리 포인트가 많거나 높다 라는 의미로 해석 될 수 있다.

실제, 정교하게 튜닝해서 꽤 안정적이 된 내부 시스템들이, 새롭게 신규 개발된 job 들이 배포되거나, 혹은 한두개 Heavy 배치가 추가 되었거나, 혹은 사이트가 이벤트를 해서 갑자기 트래픽이 폭주했거나.... 혹은 앞의 상황이 하나도 없어도...데이타는 자꾸 적재되면서 크기가 커지니까... 결국에는 최적화가 깨지고 에러를 유발하는 상황을 자주 접하게 된다.

그래서 신경쓸게 너무 많고... 코딩하는게 어려운게 아니라 config 맞추는게 더 어렵다.  그것때문에 내가봤을 때는 반 애자일 적이었다. (이 부분에서는 다분히 주관적인 해석이 많이 들어갔을 수 있다...)

어찌 되었던, 자사의 시스템이 Enterprise 시스템의 한 부분으로서, 애자일 보다는 안정성 및 예측 가능성이 훨씬 더 중요하고, 안정성을 유지하기 위한 수많은 번거로움은 감수 가능한 내부 아키텍처 철학을 가지고 있다면,  Yarn 이 더 적합해 보인다.

마치 Spring 을 도입하는 많은 기업들이 그런 측면에서 안정성에 더 Priority 를 높게 주고 있는 것과 같은 맥락일 것이다. (Spring 프로젝트에서 제일 쉬운건 코딩이요..제일 어려운건 Config 였던 경험이 많이 있다.. 그럼에도 불구하고, Spring 프로젝트를 하게 되면, 개발자에 따른 코딩 스타일의 기복이 없고, 모든 코드가 획일화 된 코드와 성능과 예측 가능성을 가지게 된다.)

그 경우(안정성에 더 가중치를 둔 경우) 전통적인 엔터프라이즈 시스템의 구성처럼 Production Zone 과 QA 및 Staging Zone 그리고, Dev Zone 을 물리적으로 구분시키고, 개발 및 배포도 그에 맞추어 branch 와 workflow 관리를 하는게 일반적이다. (아래 처럼..)


git 이나 maven 이나 jenkins 같은 것들이 이를 위한 훌륭한 도구 일 수 있으며, 우리도 초반 1년 반 정도는 BigData  시스템을 그 철학으로 운영했던 경험이 있다. (초반에는 예측가능성과 안정성에 더 초첨을 뒀었기 때문이다...)

DevOps 측면에서 보자면, Yarn 보다는 Mesos 가 좀더 적합한것 같다. 우리의 현 AS-IS 시스템과 TO-BE 시스템이 이쪽에 더 비중을 두고 있는 이유이기도 한데....바로, 정교한 시스템 세팅 그리고 탄탄한 시스템 보다는, 유연하게 아키텍처가 바뀔 수 있고, 아키텍처의 버전업이 수시로 있으면서도, 운영중 Rolling Upgrade가 가능하며, 수시로 실험적인 세팅이 도입되었다가 롤백 되었다가 반복적일 수 있는 아키텍처를 지향하기 때문이다.

DevOps 측면에 더 무게를 둔 시스템은 애자일(agile), 지속적 통합(Continuos integration), 적응형(adaptive style) 개발방법론, 롤링업그레이드 등에 더 Priority 를 준 시스템일 것이다.  그러한 환경에서는 Production Zone 과 Dev Zone 이 방화벽을 사이에 두고 물리적으로 확고한 경계가 있으면 안된다. Dev Zone 이 2개일수도 있고, 3개 일수도 있으며, 지난주에는 Dev Zone 이 10개 Node 였었는데, 이번주는 Dev Zone 이 50개 Node 일수도 있다. 그리고 다음주에는 Dev Zone 이 갑자기 그대로, Production 배치가 도는 Production Zone 으로 탈 바꿈 되어 있을 수도 있으며, 때로는 Dev 프로그램들과 Production 프로그램이 공존해서 돌 수도 있는 것이다. 모든 Production 이 동일 버전으로 수행되진 않아도 되며, 안정성을 필요로하는 Job 들은 가장 안정버전의 버전으로 구동이 되고, adhoc 배치처럼 안정성이 덜 중요한 Job 들은 Production 배치임에도 불구하고, 최신 버전의 환경 구성에 수행되면서, 그 자체가 Dev이면서, 그 자체가 Staging Test 이며, 그 자체가 리얼 운영 QA 단계를 포함한 운영 배포이기도 한 상태가 될 수 있다. 각 단계를 배포 과정을 거치면서 water fall 형태로 하나하나 수행해야 할 필요가 없으며, 한번의 배포가 Dev,QA,Staging,Production 배포를 모두 끝내 줄수도 있다.(마치 아래 처럼..) 그리고 무엇보다... 나선형 개발 방법론 처럼, 하다가 아키텍처나 호환성이 좋지 않으면, 특정 시점의 구성으로 돌아가 언제든 아키텍처나 버전을 달리하며 테스트가 가능하다. 특정 시스템이나 특정 버전으로 돌아가는데 10분이 넘게걸리면 이미 애자일이나 DevOps 를 거론하기에는 자격 미달이다.


이 측면(DevOps 측면)에서 보면, 프로세스 가상화 개념의 Mesos 모드가 90:10 정도로 훨씬 더 유리하다. Hadoop 은 stable 하게 한곳에 있을 수 있고, 분리된 Layer 로서의 Mesos Layer 는 Hadoop Node 를 모두 쓸수도 부분만 쓸수도 있으며, 안쓰는 NoSQL 노드도 다이나믹하게 끌어 들일 수도 있다. Mesos 위에 Docker 를 올려서 다시한번 추상화된 다른 Layer 를 올릴수도 있다. 그리고 무엇보다 Public Cloud 까지 동원할 수 있다. 순수하게 계산 노드 이므로... 이 모든게 가능한 이유는 Mesos 모드는 정교한 컨피그가 없어도 되기 때문이다.

이 경우는 Yarn 이 하나의 시스템안에 Queue 로 Zone 을 나누는것과 달리 mesos 의 경우는 구동 zone 자체를 복수개를 운영하는 시나리오를 취할 수 있다. 복수 Zone 은 각각 Dev, QA, Staging, Production 일 수 있으며, Node 의 갯수가 다이나믹할 수 있고, 리소스를 극명하게 분리할 수도 있으며, 경우에 따라 하나의 머신에 복수 Zone을 띄울 수도 있다.

이 경우 이러한 구성을 자동화 함에 있어, 좀 무겁게는 Open Stack 이 사용될 수도 있고, 좀 가볍게는 Vagrant 가 사용될 수도 있으며, 갑자기 노드가 부족하면, Mesos 노드만 Azure 나 AWS 등 Public Cloud 로 원하는 만큼 무한정 늘려 사용할 수도 있다. 월배치나 분기 배치가 너무나 헤비하다..그러면, 종량제로 다이나믹하게 하루 정도만 수백대를 더 붙여서 돌리고 파기 할 수도 있다. 물론 개발환경을 개발자에게 다이나믹하게 할당해 줄수도.... 수십 테라를 실험한다고 해도....자유롭게 독립적인 테스트 환경을 구비 해줄 수도 있다.

그러면서도 내부 HDFS 는 Fix 된 체로 내부 IDC에 존재하고, dev 존이 Public Cloud 라 할지라도 VPN등 보안 프로토콜을 경유 하여, 내부 데이타를 가지고 리얼 데이타 테스트가 가능한 것이다.

Spark 1.4.1 을 쓰다가 Spark 1.5.1 로 롤링 업그레이드를 하는 시나리오를 가정해보자.

  1. 초반.
    1. 1.4.1과 1.5.1의 노드 비율이 초반에는 9:1 일수 있다. 
    2. 10% 의 TO-BE 노드에서는 안정성이 필요하지 않는... adhoc 배치들만 돌리면서 일정 기간 테스트 수행을 할 수 있다.
  2. 중반.
    1. adhoc 배치들이 어느정도 잘 도는 시점이 되면, 비율을 6:4 정도로 To-be 에 초반보다 좀 더 할당해주고 as-is 에서 돌던 Heavy 월 배치 중 완료 시간이 민감하지 않은 일부 배치들을 몽땅 to-be 에서 구동 되도록 바꾸고 1~2주 진행상황을 살펴 볼 수 있다. 빌드하지 않아도 쉡 옵션 레벨에서 변경 가능한것이 많은 도움이 된다. 
    2. 이 경우는 Dev 가 real-data 로 QA 및  Staging 역할 까지 하는 경우이며, 아직 까지는 Test 베드 이지만, Production 역할 도 하는 시점이다...
  3. 중 후반.
    1. 중반정도까지 수행해도 안정적인 경우 일배치 중 장애시 민감도가 덜한 부분 부터 점진적으로 TO-BE 로 이관하는 단계이다.
    2. 그러면서 점진적으로 AS-IS 의 노드를 줄이면서, TO-BE 노드로 다이나믹하게 이관되는 시점이다.
  4. 후반
    1. 충분한 시간 TO-BE 로 Production 배치들에 대한 안정성 검증이 어느정도 마무리 되었기 때문에, 최적화 튜닝 및 시스템 리소스 상황을 모니터링을 하면서, 전체 노드 이관이 완료 적용되는 시점이다.
    2. 이 단계를 포함 여기까지의 모든 과정이 Rolling Upgrade  단계였다.
    3. 물론 요 시점 부터는 튜닝 옵션들을 바꾸어 가며, 조금더 최적화를 진행해야 하는 단계이기도 하다.

위를 진행함에 있어, Mesos 의 장점은 바로 프로세스 가상화라는 점이다. Spark 가 각 노드에 안깔려 있어도 무방하다. Spark gz 압축 파일이 HDFS 같은 공유 리파지토리에 버전별로 저장되어 있으면, Job 을 수행할때, 어떤 버전을 써서 돌릴지 Job 별로 다이나믹하게 분배가 가능하다. 즉, 위의 Zone 에서는 그런 시나리오가 없었지만, 동일한 Zone 에서 복수의 버전을 돌리는 것도 가능하다는 의미이다. 버전을 바꾸어가면 테스트하는게 1분도 안걸리고, 동시에 N개의 버전을 동시 테스트 하는 것도 가능하다.

예를 들어 보겠다. Spark-submit 스크립트에서 master 의 주소를 바꾸어 가며 수행하는 경우, 버전이 서로 다른 서로 다른 Zone 을 다르게 구동할 수 있으며, 버전이 같은데 서로 다른 Zone 으로 구동도 가능하다. 그리고 동일 Zone 에서 버전을 달리 주는 것도 가능한데..바로 아래처럼 spark.executor.uri 옵션에 수행할 spark 버전을 다르게 주어 가능한 것이다. Spark 가 버전별로 복수 노드에 다 설치될 필요가 없고, 위처럼 옵션만 달리하여, Mesos 만 깔린 여러 Node 에 복수개의 Zone 이나 복수개의 버전을 다이나믹하게 조합하여 테스트 할 수가 있다.



부가적으로... Spark-Streaming 의 경우 Yarn 환경에서는 분리된 Yarn 클러스터를 두거나, 정교한 Fair 스케줄러 세팅을 해야 하는 반면, Mesos 환경에서는 Zone 을 분리하는 방식이 Mesos 의 Fair 스케쥴러에 Fine Graind 세팅을 해서 구동하는 것보다 훨씬 더 안정적이며, 훨씬 더 성능이 좋게 나왔다.

[3] 결론.

잡설이 좀 길어 졌는데, 어찌되었든, 결론은 Yarn 모드가 장점이 있고, Mesos 모드가 장점이 있는 것 같다. 각각의 장점 중 어느 부분을 취할지는 AA의 몫일 것이며, 현 상황 이 시스템을 도입하려는 조직의 Dev 스타일의 철학적인 부분에 달려 있으리라 본다.

내가 주장하는 결론은 애자일을 위해선 Mesos를... Enterprise 수준의 안정성을 위해서는 Yarn 이 조금 더 낳은 것 같다 이다.

2015년 10월 6일 화요일

Spark Yarn Cluster vs Spark Mesos Cluster (vs 기타 다양한 모드) : [첫번째] 수행성능 및 활용성 비교

Spark Yarn Cluster 모드와 Spark Mesos Cluster 모드의 성능 비교를 하기에 앞서.....
Spark 를 여러 모드로 사용해본 기억을 더듬어 보았다..대략 이정도...

  1. Spark + Shark + parquet 
  2. Spark + Shark
  3. Spark + Tachyon + parquet
  4. Spark + Shark + Tachyon
  5. Spark + Tachyon + parquet
  6. Spark + Tachyon
  7. Spark Stand Alone Cluster
  8. Spark Yarn Cluster
    1. Yarn Client Mode
    2. Yarn Cluster Mode
  9. Spark Mesos Cluster

[1~2번 조합에 대하여..]

초창기에 실험했던 조합이다. 2~3년전인가... spark 가 0.6~0.7 요정도였던 시기였던 듯..
그때는 Scala 가 익숙치 않았었고, Spark가 지원하는 세세한 라이브러리들의 기능들이 빈약해서, SQL on Hadoop 용도로의 활용 에만 꼳혀 있었던 터라...Shark 를 써보려고 무던히 애를 썻었다.

-> [결론] Shark 쪽에 Error 가 너무 많아서.. Production 화 하지는 못했고, Adhoc 용도로만 사용했었다. Parquet 파일포맷과의 호환성도 최악이었다. 요즘은 조금 상황이 다르지만, 당시에는 버전업이 자주 되었고, 버전업 때마다 하위 호환성은 최악이었으며, 타 Legacy 와의 Compatibility 이슈가 매우 빈번하였다.

[3~6번 조합에 대하여..]

-> Tachyon 은 메모리 기반의 분산 NFS 형태로, Parquet 포맷 원천 HDFS 상 파일을 De-Normalize 하여 Plain 포맷으로 올려놓고(마치 DW와 Mart 의 조합처럼...), 빠르게 읽고 쓰고 하는 용도로 사용했었고, 꽤 성능이 우수하였다. HDFS 상의 Parquet 보다, Tachyon 상의 PLAIN TSV 포맷 텍스트 파일의 성능이 더 좋았으며, NFS 처럼 마운트가 가능하여, Legacy 와의 호환성도 매우 좋았다.

-> [결론] 이 시점 부터 월배치 수행 정도로 조금씩 Production에서도 활용하기 시작.. 여전히 약간 불안...일배치를 돌릴 정도로 안정적이진 못했음. ( 버전이 아직 1.0되기 전 시점인지라..)

[7~9번 조합에 대하여..]

-> 1.0 버전 이상이 되면서, 안정성과 SQL 자체 지원. 그리고, 다양한 특화 라이브러리 자체 지원등 여러가지 활용성이 좋아졌고, 드디어 Production 에 사용하기 시작했다.
-> 작년 중순부터였던 듯..

-> [결론] 전반적으로 Spark Stand Alone Cluster 모드가 테스트 시점에는 가장 쉽고, 성능도 단일 프로세스를 Serial 하게 쓸때는 나름 빠르게 나온다. Adhoc 분석 시스템일때는 이 모드로 쭉 써도 무방할듯. 그러나, 프로덕션 환경에서 동시에 병렬 수행되는 Spark  Job 이 5~6개 이상일 정도로 활용성이 증가 된 환경에서는, Stand Alone 모드로 사용이 불가능에 가깝다. 즉, 이 시점부터 Spark Yarn Mode 로 사용할지, Mesos Mode 로 사용할지 고민에 빠지게 된다....

  1. 실험환경
    1. HW 및 데이타
      1. 실험에 사용된 Data 는 수TB 이상의 데이타 이며, TSV 포맷이다. 두 시스템에서 사용된 HW는 100% 동일한 HW이다. 
    2. 버전
      1. Hadoop 2.7.1
      2. Spark 1.4.1
      3. Mesos 0.22.1
    3. Business Logic 구현 언어
      1. Scala
  2. Spark Yarn Mode vs Spark Mesos Mode 성능 비교 
    1. CPU & Memory 자원을 거의 쓰지 않고, Disk IO 와 Network IO 를 극단적으로 많이 쓰는 Business Logic 수행.

      1. mesos cluster (FAIR  모드)

        1. 605초 걸렸다. (2차 시도에서도 606초)
        2. 물론 mesos 모드에서는 Fair 모드 여부와 Fine Grain 여부 등등 성능과 좌우되는 다양한 옵션이 존재하긴 하지만...다소 느리지만 안정적인 General 옵션으로 수행하였음.
      2. yarn client 모드
        1. 219초 무려 3배 가까이 빠르다. (2차 시도에서도 216초)
      3. yarn cluster 모드
        1. 225초. Client 모드보다 살짝 느리지만...비슷한 수준. (2차 시도에서도 221초)
    2. CPU 와 Memory 를 많이 쓰는 Group By & Sort & Aggregation 로직이 포함 된 Business Logic 수행.
      1. mesos cluster 모드
        1. 29초 걸렸다. (2차 시도는 30초)
      2. yarn client 모드
        1. 1차시도 57초. 2차 시도 59초. 결과는 Mesos 의 그것과 동일.
        2. 오홋....드디어 Mesos 가 저력을 발휘... Mesos 가 2배 정도 빠름. 다시말하여, Yarn Client 모드는 Mesos 보다 2배 정도 느렸다.
      3. yarn cluster 모드
        1. 61초.
        2. 여전히 yarn client 보다 3~4초 느리고. mesos 보다 2배 느리다..
  3. 결론
    1. Disk 와 Network 만 극단적으로 사용하고 CPU 나 Memory를 거의 쓰지 않는 극단적인 로직에선 Yarn이 성능이 좋았다. 그 이유는 Yarn 은 HDFS 에서 바로 연산을 하기 때문일 것이다. 
    2. 반면, Mesos Layer 가 추가 된 아키텍처에서는 동일 머신에 Mesos Cluster 가 있음에도 불구하고, Mesos 의 Memory Cache Layer 로 다시한번 Data 셔플이 일어나면서 Over Head 가 한단계 더 있어서 일거라 예상이 된다.
    3. 실제, tmp 디렉토리에 Mesos 쪽에서 남기는 셔플된 데이타들이 꽤 된다. 
    4. 그러나, IO 만 극단적으로 사용하는 Business Logic 은 극히 드물다. 사실 우리의 경우 그런류의 배치는 50개 중에 1개가 있을까 말까이다... 대부분은 컬럼 한두개 이상으로 Partition 되도록 Directory 정책을 Collection 시점에 적용하고 있어, Full Data 로딩이 거의 없고, Full Data 로딩을 하는 경우에도 Filter 로직으로 셔플은 일어나지 않고, N대의 분산 머신에서 RDD 자체에 로딩을 하지 않도록(mesos tmp 에 file block 들이 쌓이지 않도록), 데이타 로딩 시점에 제한 로직을 가하고 있다. (다 로딩하고 SparkSQL 에서 where 로 데이타를 줄이거나 하진 않는다는 의미이다..)
    5. 대부분의 경우 CPU와 Memory를 많이 먹는 Group By Aggregation 로직이 많은데, 이 경우는 역시 Mesos 가 2배 정도 빠른 성능을 보여주었다. ( Yarn 이 설치된 동일 HW에 Mesos 가 구동되었고, Yarn으로 할때는 Mesos 데몬을 내려주고 했어도 그렇다.)
    6. 성능과는 다른 이야기 이지만, Mesos 의 장점은 좀더 있다.. 바로 요런거...
      1. Yarn 모드로 spark submit 할때는 core 사용갯수. executor 메모리, driver 메모리, executor 갯수를 실험적으로 매우 적절히 사용해야 한다. 
        1. 물론 하드웨어가 핑핑 남아돌면, 다 충분히 크게 주면 되지 않냐는 반문이 있을 수 있다. 하지만, 메모리 등을 너무 크게 주면 GC 에서 예기치 못한 장애가 유발 될 수 있다. 
        2. Spark 메뉴얼은 아래처럼 권고하고 있다.
        3. Use more executors with smaller heap sizes. This will reduce the GC pressure within each JVM heap.  
        4. 그러나 heap size 를 줄이는 경우 반대로 heap memory 부족 에러도 훨씬 자주 접한다.
        5. 즉, 어느 한쪽으로 치우쳐도 안되고 job 에 따라 적절히 줘야 하는데...Job 이 수백개인 경우...그리고, 데이타 크기나 새로 인입되는 job 이 한달에 10개 이상이라고 한다면... 그러면, 적절히 최적화 해놓은 해당 값들이 다 틀어진다..TT
        6. Mesos 는 그런거를 추상화 해준다.
        7. Job 이 적을때랑 많을때 지가 알아서 cpu 코어 갯수나 memory 나 executor 의 갯수를 다이나믹하게 할당하고, job 이 좀 몰리면, 적절하게 분할 배분 수행시킨다.
        8. 관리적인 측면에서 이건 매우 큰 이점이며, 약간 이상의 성능은 충분히 커버하고도 남을 정도로 중요한 요소이기도 하다. 특히 안정성 측면에서..
        9. ( Yarn 도 이런 설정이 불가능 한것은 아니다.. Yarn Dynamic Resource Allocation 으로 검색 해 보시길.. 메커니즘은 약간 다른것 같다. 특히, excutor가 remove 될때 RDD 가 같이 사라지는 문제가 있어, 이 문제를 해결하기 위해 RDD  를 전달 하는 external shuffle 메커니즘이 Mesos  의 그것과 좀 다르다. 아키텍처 특성상.. Mesos 는 해당 Tier 자체가 공유 Memory 를 고려한 프레임워크 인지라 이런 공유 RDD 처리가 좀더 메크러운 것 같다.)
      2. 추가적으로 Hadoop Eco System 에는 Hadoop 보다 훨씬 많은 노드가 NoSQL 이나 다른 Service Layer 에 존재 할 수 있다.. 좀 헝그리하게 시스템을 운영하는 경우라면..(우리처럼 TT) Mesos 를 모든 장비에 깔아주면.. 모든 시스템을 쥐어 짜듯 죄다 활용할 수 있어서... 모니터링 콘솔들을 보고 있자면, 놀고 있어도 일하는 거 같고... 왠지 알아주는 사람 없지만, 회사에 수(or 수십)억원을 Save 시켜주고 있다는 느낌을 혼자(TT) 받을 수 있다.
      3. 모니터링 또한 Mesos 의 모니터링 콘솔이 훨씬 직관적이고 잘 되어 있다. 현재 얼마나 cpu 를 쓰고 있고, 메모리를 쓰고 있고, 몇개의 executor 가 job 별로 할당되어 있고.... 어떤 job 이 대기 타고 있는지 1초만에 확인 가능한 단일 view 를 제공한다. yarn 은 여러번의 클릭을 하고 머릿속에서 종합해야 할 일들이다. 물론 스케줄러가 좀더 큰 그림의 진행 상황을 별도로 보여주는 레이어로 존재할지라도..현 시점의 Job 상황을 HW 리소스 와 함께 맵핑하여 본다는 건 실무에서 꽤 필요한 부분이다.
      4. Spark Streaming 이나 SparkR 에서도 할이야기들이 좀 더 있지만...요건 별도 Post 하는 걸로...





2015년 8월 31일 월요일

InfluxDB (Distributed time series database for RealTime Aggregation) - 설치기

InfluxDB는 오랫동안 예의 주시해오던 RealTime Layer의 TimeSeries (Aggregation도 되는) NoSQL DB 이다.( Go 랭귀지로 만들어져 있고, 요런류의 NoSQL 로는 신생에 속해서, 왠지 그냥 빠를것 같다는 선입견도 있었는데 진짜로 빠르고 직관적이라 사용하기도 쉽다.)
그러나, 오랫동안 Cluster 세팅이 베타 버전이었고, 0.9.1 과 0.9.2 는 three node 구성만 지원하는 제약이 있어, Production 에서 사용하기에 많이 부족한 면이 없지 않았다. 하지만 최근(본 글을 쓰는 시점으로 부터 4일전. 2015년 8월 27일) 0.9.3 버전이 오픈되면서 이 제약이 풀렸다. 7월초에 0.9.1이 정식 릴리즈 되었었고, 7월말에 0.9.2 이 정식 릴리즈 된바 있었는데, 한달이 지난 8월 27일 드디어 클러스터 세팅이 공식 지원되는 첫 버전이 릴리즈 된 것이다. ( 요놈도 마이너 버전이긴 하지만, 마이너 정식버전 릴리즈가 엄청나게 빠르다. )

아래는 클러스터 지원에 대한 공식 홈페이지에서의 언급 내용이다. 물론 아직 약간의 개선되어야 할 피처가 남아 있는게 사실이다. Computing Node 즉 분산쿼리에 있어서는 아직 Beta State 라고 언급하고 있고, 단지, Storage 입장에서 Data Node 가 3대 이상으로 확장되고, Size 분산되는 입장에서만 Release 가 정식버전이라 언급하고 있다.(3대 노드 이상일때 분산 쿼리가 지원이 안되는 것은 아니다, 좀더 해결해야 할 부분들이 더 남아 있다는 표현이 맞을 듯 하다.) 즉, 분산 쿼리 측면에서는 아직 Hybrid 한 느낌이다. (여하튼 아직까지는 3대 정도의 Node 갯수에서도 Spark Streaming 이 전처리를 한, 작은 Window Size 의 데이타에 대하여는 충분히 빠른 결과를 보여주고 있다.)




  1. 디렉토리 구성 및 설치 파일 다운로드. 그리고 간략 설치.
    1. cd /data01
    2. mkdir influxdb
    3. cd influxdb
    4. wget https://s3.amazonaws.com/influxdb/influxdb-0.9.3-1.x86_64.rpm
    5. sudo yum localinstall -y influxdb-0.9.3-1.x86_64.rpm
    6. sudo /etc/init.d/influxdb start <--- single node 구성이 아닐때는 요걸 먼저 수행하면 큰일 남... 이것땜에 삽질 많이 함. 모든 컨피그 끝나고 첫 수행을 해야 함. Cluster Mode 세팅 시에는 Cluster 관련 세팅 종료 후 구성해야 함.
      1. 일단 요기까지 하면, single node 구성 세팅 완료. 
  2. CLI 구동 ( Cluster Node 일때는 모든 세팅 끝나고 수행 )
    1. 우선 환경변수에 추가.( at .bashrc 에 /opt/influxdb 추가 )
    2. influx 하면 CLI 가 구동 됨.
    3. 아래는 상세 옵션 들.... import 도 되고, 원격서버접속도 되고, format  옵션으로 json 이나 csv 로 output 을 뽑을 수도 있고, compressed import 옵션도 보인다.
  3. Cluster 세팅 
    1. 각 노드에서 설정 변경
      1. sudo vi /etc/opt/influxdb/influxdb.conf
        1. hostname = "localhost" 를 각 노드 hostname 으로 수정
        2. port 를 1번노드는 :8088 , 2번노드는 :9099 , 3번노드는 :10101 로 수정. 
      2. 1번 노드에서 재구동
        1. sudo /etc/init.d/influxdb stop
        2. sudo /etc/init.d/influxdb start
      3. 2번 노드에서 아래처럼 구동
        1. sudo vi /etc/init.d/influxdb 에서 INFLUXD_OPTS="-join hostname1:8088"
        2. sudo /etc/init.d/influxdb stop
        3. sudo /etc/init.d/influxdb start
      4. 3번 노드에서 아래처럼 구동
        1. sudo vi /etc/init.d/influxdb 에서 INFLUXD_OPTS="-join hostname1:8088,hostname2:9099"
        2. sudo /etc/init.d/influxdb stop
        3. sudo /etc/init.d/influxdb start
      5. 확인
        1. influx 하여 CLI  콘솔을 띄우고, show servers  해서 node 들이 복수개 보여야 함.
        2. 그러나 위데로(메뉴얼데로) 했는데, 안되기도 함.TT
        3. 아래처럼 config 파일을 열어서 수동으로 세팅...
        4. sudo vi /var/opt/influxdb/meta/peers.json
        5. ["<hostname 1>:<port 1>","<hostname 2>:<port 2>","<hostname 3>:<port 3>"]
        6. 정상 수행 완료 되면, show servers 명령에 아래처럼 3개 Node 가 보여져야 함.

Druid (Interactive Analytics at Scale) - Cluster Setting

RealTime Analytics Layer 에서 사용가능한 NoSQL 중 설치는 다소 복잡하지만, 튜닝을 적절히 해주면 꽤 좋은 성능을 얻을 수 있는 Druid.

아래는 Druid Production Cluster 를 위한 간략한 버전의 Cluster Setting 설치기 이다. 간략해 보이지만, 실제 웹사이트 메뉴얼에 부족한 부분 위주로 정리한거라 실제는 이것보다 훨씬 방대한 설치 세팅 작업이 필요하다. 한가지 아쉬운점은 웹상 메뉴얼데로 설치하면 난관을 30번쯤 만난 다는 점.. 아래는 난관을 해결한 Key 위주로만 적은 내용이라, 실제 설치시에는 메뉴얼과 함께 보면서 설치해야 한다.

우선 메뉴얼을 속독 하면서 보았던, 인상깊은 문구....
When talking about query speed it is important to clarify what "fast" means: with Druid it is entirely within the realm of possibility (we have done it) to achieve queries that run in single-digit seconds across a 6TB data set.


본 Cluster 노드 세팅 스크립트를 메모하면서 수행한 시점에 동원된 Node 는 총 7대 이며, 일전에 세팅한 Single Node 로 세팅된 환경을 VM Template 화 하여 7대로 증분 시키고, 필요없는 데몬을 끄거나, 재 설정 하는 식으로 세팅하였다.

[그림1] VM6대 노드 구성


구성한 노드의 구성은 아래와 같다.

vm-broker01 : broker (32core,244GB,SSD), 32G Heap
vm-druid01 : historical (32core,244GB,SSD), 32G Heap
vm-druid02 : middleManager (32Core,244GB,SSD), 32G Heap
vm-druid03 : realtime -> (32Core,244GB,SSD), 32G Heap
vm-druid04 : zookeeper01, coordinator (8Core)
vm-druid05 : zookeeper02, mysql , overlord (8Core) - for indexing Service

[그림2] web datasource 콘솔


[그림3] web task 콘솔


[그림4] middlemanager 모니터링


  1. mysql 세팅 변경 ( at vm-druid05 )
    1. default 패스워드 변경
      1. http://blog.naver.com/gihyunkwak/220329365505
    2. 원격 접속 허용되도록 변경
      1. http://nsinc.tistory.com/70
    3. Template 화 Copy 된 Node 이므로 vm-druid06 Node 를 제외한 전체 노드에서 Mysql데몬 중지. 그리고 druid05에만 구동.
      • sudo service mysqld stop
      • sudo service mysqld start
  2. zookeeper 세팅 변경 ( at vm-druid06 )
    1. zoo.cfg 변경
      • dataDir=/data02/zookeeper/data
    2. zookeeper 세팅 복제 및 복제 서버 세팅
      • 상세 세팅 방법은 Zookeeper 페이지 메뉴얼에 잘 나와 있으므로 skip
    3. zookeeper 구동
      • bin/zkServer.sh start &   ( & 안해도 되긴 하지만... )
    4. zookeeper AutoStart 설정
  3. dervy 설치: 아래 dervy 모드는 최초 설치 테스트 시점에만 사용. dervy로 설치 성공 이후에는, 실 Production 용에서는 AWS 와 Hadoop Yarn 모드로 변경 세팅 해야 함. (설치 메뉴얼 그데로 구성하였으므로 이 부분은 설치 메뉴얼 정리 skip)
    1. wget http://apache.mirror.cdnetworks.com//db/derby/db-derby-10.11.1.1/db-derby-10.11.1.1-bin.tar.gz
    2. 기타 세팅
      1. http://db.apache.org/derby/papers/DerbyTut/ns_intro.html
      2. 서버 모드 실행
        1. http://db.apache.org/derby/papers/DerbyTut/ns_intro.html
        2. java -jar derbyrun.jar server start
        3. lib 폴더로 가서 위 2를 수행하면 path 안잡아줘도 수행 가능.
  4. common 세팅 ( all node )
    1. config 수정 : 메뉴얼 내용과 유사하지만.. 수치 값에는 데이타 크기와 Job 성격에 따른 실험적 튜닝이 필요함.
    2. SCP 로 전체 노드에 복사
      • scp common.runtime.properties moneymall@vm-druid01.cloudapp.net:/data01/druid/druid-0.7.0/config/_common/
  5. overload 실행
    1. config 수정 : 메뉴얼 내용과 유사하지만.. 수치 값에는 데이타 크기와 Job 성격에 따른 실험적 튜닝이 필요함.
    2. SCP 로 전체 노드에 복사
    3. run 스크립트 작성 : 메뉴얼 내용과 동일
  6. middle manager node 실행
    1. config 수정 : 메뉴얼 내용과 유사하지만.. 수치 값에는 데이타 크기와 Job 성격에 따른 실험적 튜닝이 필요함.
    2. scp 로 전체 노드에 복사
    3. run 스크립트 작성 
  7. coordinator 실행
  8. historical 실행
  9. broker 실행
    1. config 수정
      1. 아래 부분 수치를 메뉴얼 데로 하면 안됨. 1의 자리 숫자 8을 7로 바꿈.
      2. druid.processing.buffer.sizeBytes=2147483647
  10. 기타 장애 해결
    1. 중요 batch 수행 장애 해결 tip1
      1. batch 수행을 05번 노드 (overload 노드)에서 수행하였는데, ddl 이 담겨져 있는 json 에서(overload 노드에 존재하는..) 가리키는 물리 path 는 실은 05번 노드가 아닌, middlemanager 가 접근하는 path 로 적어져 있어야 함. middlemanager 가 복수개 이므로, 어떤 manager 에 할당될지 모르는 환경에서는 hdfs 등 공유 스토리지가 아닌 경우 path 설정에 유의할 필요가 있음.
    2. 중요 batch 수행 장애 해결 tip2
      1. config 디렉토리는 모두 실제 존재하고 적절한 퍼미션이 있어야 함.
      2. 특히, jvm 옵션중에 존재하는 tmp 디렉토리 또한 실제 물리적으로 존재하고 퍼미션이 적절해야 에러 없이 수행 됨.
    3. 인덱스가 다이나믹 하게 되도록 수정. 
      1. http://druid.io/docs/0.7.1.1/Indexing-Service-Config.html





2015년 8월 5일 수요일

Mesos 0.22.1 HA 구성 Test

Mesos Client 중 한대가 죽으면, 걍 죽은데로, 나머지 노드에서 Job 이 잘 돌아간다. 물론 죽는 시점에 죽는 노드에서 돌던 Job 자체는 Fail 이 될 수 있다. 그럼 master 가 죽으면 어떻게 될까?

최신 버전으로 실험을 해보았다. 실험에 사용한 버전은  Mesos 0.22.1 이다.

갑자기 Mesos Master 노드에서 Kill 로 Master 를 죽여 보았다. (실험시점 Master 를 구동할때 별도로 Zookeeper 세팅을 해준게 전혀 없는 상태이다.)

그랬던니, 첫번째 Client 에서 아래와 같은 로그를 볼수 있다. "Waiting for a new master to be elected" 그리고는, 갑자기 첫번째 Client 가 Master 가 되면서, 전체적으로 클러스터 자체는 동작하고 있는 상태가 되었다.


잘만들었네.. ^^ 물론 바뀐 Master 노드 주소를 찾아가게 하는 문제는 남아 있지만...그런거는 뭐 전통적인 방법으로 풀면 되니까..skip...

BigData 파트에서의 전통적인 방법이라 함은.... 예를 들어 요런거...(zookeeper 를 이용해서..)

Spark Submit 스크립트가 Mesos Master 주소를 Set 할때 요런식으로..

--master=zk://호스트1주소:port1,호스트2주소:port2,호스트3주소: port3,.../path


2015년 8월 4일 화요일

Spark Cluster Settings On Yarn : Spark 1.4.1 + Hadoop 2.7.1

spark + yarn 의 Cluster 세팅은 spark + mesos 의 Cluster 세팅에 비하여 매우 쉽다. spark stand alone Cluster 의 경우 client node 에 spark 를 모두 설치해 주어야 하지만, spark + yarn Cluster 의 경우에는, spark + mesos Cluster 의 경우와 마찬가지로, master 에만 설치해주면 동작한다. (물론 Yarn 위에서 구동되므로, Yarn 관련 설정은 모든 Node 에 동일하게 설정되어 있어야 한다. 그리고, Yarn 이나 Mesos Master 가 Spark  Master 와 반드시 같은 Node 필요는 없다.)

기존 spark stand alone 클러스터 세팅에서 아래 정도만 신경 쓰면 설치가 완료 된다.
  1. 환경변수 세팅
    1. 기존 Hadoop 환경변수는 세팅되어 있다고 가정
    2. HADOOP_CONF_DIR 라인을 Copy 하여 YARN_CONF_DIR추가(모든 Node 에서)
  2. Spark.local.dir 관련 폴더 생성
    1. 모든 노드에 Disk 파티션이 큰 영역에 별도의 spark local dir 폴더 생성.
    2. 이것을 정의 하지 않으면, /tmp 가 차올라서 disk full 이 되기 십상이다.
    3. mkdir /data02/spark_tmp/
    4. spark.local.dir 관련 set 은 SparkConf().setAppName("AppName").set("","") 메소드를 이용.(프로그램 내부에서 정의 함. 물론 실행 시점이나, 글로벌 conf 파일에서 정의 할수도 있긴 하지만...)
  3. Mode 선정
    1. spark + yarn 모드는 두가지 모드가 있으며 아래와 같은 특징이 있다.
      1. yarn cluster mode
        1. job이 중앙에서 구동되는 방식이다. 좀더 Yarn 의 리소스에 의존하여 구동되는 느낌이다.
        2. scala 소스 내에 println 을 넣으면, spark-submit 을 한 콘솔에 출력되지 않고, hadoop의 yarn Job 관리 UI 에서 stdout Log 를 통해 확인할 수 있다.
        3. 위 그림은 println 한 결과 출력 창이다. (MapReduce UI)
      2. yarn client mode
        1. 특정 client 에서 spark-submit 을 날리면, 해당 머신에서 main 클래스가 구동되는 듯 하다. 물론 실제 잘게 쪼개진 sub task 들은 yarn 위에서 구동된다.
        2. 때문에, yarn cluster mode 와 달리, println 을 하면, 수행시킨 Console 에서 결과가 stdout 으로 바로 보여진다. 
        3. 잘게 쪼깨진 sub task 만 yarn 에의해 관리되는것 같다.
        4. 동작방식이 mesos cluster 위에서 spark job 을 구동했을때와 매우 흡사해 보인다.
        5. 위 그림은 println 한 결과 출력 창이다. (수행 Console )
구동을 하면 아래처럼 Yarn 의  Job 관리 UI 에서 수행 상태를 확인 할 수 있다. 이러한 Job UI  자체는 Mesos나 Spark Stand Alone Cluster 의 그것에 비하여 좀 기능이 떨어진다. Application Type 이 MapReduce 인 경우 MAPREDUCE 라고 보이는 반면 Spark Job 은 SPARK 라고 보여 진다.






2015년 7월 29일 수요일

Hadoop 1.X -> Hadoop 2.X Data Copy with DISTCP

Hadoop 1.X 에서 Hadoop 2.X 로 Data 를 Copy 할때는 여전히 distcp 를 이용하면 MapReduce Job 을 이용 N대의 머신의 IO 를 모두 활용 빠르게 Copy 가 가능하다.

하지만, 동일 버전의 서로다른 2대의 클러스터에서 사용할때와는 좀 다르게 사용해야 한다.

우선 동일 버전의 Cluster 에서는 아래처럼 사용했었다.

hadoop distcp hdfs://source-masternodeURL:9000/path hdfs://destination-masternodeURL:9000/path

그러나, 버전이 다른, 특히 1.X 와  2.X 처럼 크게 버전이 다른 경우에는 아래와 같은 에러가 발생한다.


 그래서, 위 명령어를 2.X 에서 수행하면서, 아래처럼 1.X 의 프로토콜을 변경해 주어야 호환성 있게 작동을 한다.

hadoop distcp hftp://source-masternodeURL:50070/path hdfs://destination-masternodeURL:9000/path

그러나, 위처럼 작업을 하면, 또 아래와 같은 에러가 발생하다가 MapReduce Job 이 죽어 버린다. 결과를 확인해 보면, Directory 만 잔뜩 에러 없이 만들어지고, 파일을 Copy 하는 과정에서는 아래처럼 CheckSUM 에러가 잔뜩 나다가 죽어 버리는 상황이 반복된다.

위 에러를 해결하는 방법은 아래와 같다.

에러메시지를 자세히 보면, using -skipCrc 요런 문구가 보인다. 그런데 옵션 메뉴얼상을 보면 -skipCrc 라는 옵션은 존재하지 않는다...아마도 에러메시지의 bug 인듯... 해당 옵션은 -skipcrccheck 이다. 그리고 해당 옵션만 넣고 수행하면, 또 -update 옵션과 함께 사용하라는 문구가 나온다. 결국 최종 컴멘드는 아래와 같다.

hadoop distcp -update -skipcrccheck hftp://source-masternodeURL:50070/path hdfs://destination-masternodeURL:9000/path

위 명령어 수행시 아래처럼 MapReduce Job 이 수행되면서 두 서로 다른 버전의 hadoop cluster 가 병렬 분산 Copy 가 이루어 진다.


2015년 7월 27일 월요일

Hadoop 2.7.1 - Cluster Setup 설치 적용기.

최근들어 hadoop 2.X의 버전업이 매우 긴박하게 이루어지고 있는 느낌이다. 작년 말 2.6.0 이 정식 릴리즈 된 이후, 잠시 Spark 때문에 Hadoop 버전업을 따라가고 있지 못한 사이, 불과 3달 전(2015년 4월말) Hadoop 2.7.0 이 4~5개월여 만에 또 다시 정식 릴리지가 된 바 있었기 때문이다. (그리고, 다시 언급하겠지만, 몇주전 Hadoop 2.7.1 이 정식 릴리지 되었다.)

그러나, Hadoop 2.6.0 을 Skip 하고 Hadoop 2.7.0 을 staging 에서 production 화 테스트 시작했던 두어달 전, 나는 작업 하던 중간 아래와 같은 문구를 발견하고, 한참 세팅하던 과정을 접고 다시 Hadoop 2.6.0 으로 Down Grade 하였던 아픈 기억이 있다.


바로 위에서 파란색으로 Highlight 한, 2.7.0 은 몇가지 critical issue 때문에 production 에서는 아직 이용하지 않는게 좋다는 문구 때문이었다.

위 이미지 내에 언급된것 처럼 2.7.0 에는 몇가지 매력적인 업그레이드가 있었다. 그중 하나는 Azure Storage 를 쓸 수 있게 된점이고(회사에서 그룹사 계약으로 Azure Storage 를 Amazon 보다 유리한 조건으로 사용이 가능하다.), 또 다른 점들은 (좀더 실험을 해 보아야 하겠지만) variable length 나 file truncate 를 사용할 수 있게 된 점 등이었다.

여하튼 그런 일부 매력적인 기능을 포기하고, 다시 2.6.0 으로 Down Grade 하였다가, 막 테스트를 끝내고 Production 환경 Rolling Upgrade Script 에 반영 Freezing 하려던 찰나...난 몇주전 또 한번 좌절하고 말았다.

바로, 2.7.0의 Critical Issue 가 해결된 2.7.1 의 안정버전이 발표 되었기 때문이었다.(정확히는 2015년 7월 6일 정식 릴리즈 발표가 있었다.) 버전 바꾸는 삽질을 많이했지만, 기저에 해당하는 Hadoop 의 버전업은 매우 조심하고 신중하게 처리해야 하고, 자주 하기도 힘든 작업인 까닭에, 어찌 되었든 다시 2주 정도를 할애하여, 신규 구성중인 New 시스템의 호환성 테스트를 마치고, Production Rolling Upgrade 버전을 다시 2.7.1 로 수정 하였다. 2.7.0 대비 131개의 Bug 패치가 더해졌다고 하니, 이 버전으로 한동안 안정적인 운영을 했으면 하는 바램이다. (대부분 2.6.0 과 호환성이 맞춰진 Legacy 들은 2.7.1 과 특별한 호환성 이슈가 발견되지 않았다.)

아래는 기본적인 테스트를 마친 Hadoop 2.7.1 설치 스크립트의 기본 버전이다. (일부 특수한 Legacy 및 자체환경 특화 Custom 세팅 부분은 제외한 기본 세팅 버전....)
  1. 초기세팅 ( at .bashrc )
    1. 환경변수 $JAVA_HOME 세팅 되어 있는지 확인
    2. 환경변수 $HADOOP_HOME , $HADOOP_CONF_DIR 세팅
    3. 환경변수 $HADOOP_PREFIX 세팅
    4. 환경변수 $LD_LIBRARY_PATH 세팅
    5. source .bashrc
  2. 다운로드
    1. wget http://apache.mirror.cdnetworks.com/hadoop/common/hadoop-2.7.1/hadoop-2.7.1.tar.gz
  3. 설치
    1. tar xvzf hadoop-2.7.1.tar.gz
    2. cd hadoop-2.7.1
    3. mkdir /data02/log/hadoop
  4. 세팅
    1. etc/hadoop/hadoop-env.sh 세팅
      1. export HADOOP_NAMENODE_OPTS 에 -XX:+UseParallelGC 추가
      2. export HADOOP_LOG_DIR=/data02/log/hadoop
      3. export HADOOP_HEAPSIZE=4000
      4. export HADOOP_NAMENODE_INIT_HEAPSIZE="4000"
    2. etc/hadoop/core-site.xml 세팅
    3. etc/hadoop/hdfs-site.xml 세팅
      1. for NameNode
      2. for DataNode
    4. etc/hadoop/yarn-site.xml 세팅
      1. 우선 대부분 default 로...
      2. 위 Address 및 기본 옵션 추가
    5. etc/hadoop/mapred-site.xml 세팅
    6. etc/hadoop/slaves 세팅
      1. 모든 slave 노드의 hostname 혹은 ip를 등록
    7. Rack Awareness
      1. 현재 Staging 배포 버전에선 skip. Production 할때 하는 걸로...
  5. 전체 노드로 설정파일 overwrite 복사
    1. 위에서 수정한 설정 파일들에 대하여 전체 노드에 복사.(with scp)
    2. hdfs-site.xml 의 경우 NameNode 설정과 DataNode 설정값이 다소 다름.
  6. 전체 노드에 기본 디렉토리 생성
    1. 위 xml 파일에서 설정하였던 디렉토리들 mkdir
  7. 전체 노드에 기본 유저 생성
    1. Stage 모드에서는 moneymall로 통일
  8. password less 설정
    1. master node 루트 에서
      1. ssh-keygen -t rsa 하고 엔터 세번...
      2. scp ~/.ssh/id_rsa.pub moneymall@각노드Domain:~/.ssh/authorized_keys
    2. clinet node 에서
      1. mkdir ~/.ssh
      2. chmod 700 ~/.ssh
      3. chmod 600 ~/.ssh/authorized_keys
  9. 각 노드 구동
    1. master node 의 hadoop home 으로 이동
    2. bin/hdfs namenode -format moneymall(<-cluster 이름)
    3. sbin/hadoop-daemon.sh --config $HADOOP_CONF_DIR --script hdfs start namenode
    4. sbin/start-all.sh
    5. 리소스메니저가 안뜨면...
      ./yarn-daemon.sh start nodemanager
      ./yarn-daemon.sh start resourcemanager
      
      
  10. DataNode jps 확인
  11. NameNode jps 확인
  12. Web UI 띄움. (Classic 버전) <-- Classic UI 가 2.6.0 에서는 공존하였는데, 2.7.1 에서는 Default 로는 링크가 존재하지 않는다.
  13. [내부 정보 유출 방지를 위하여 이미지는 Dev-Zone 이미지 임.]
  14. Web UI 띄움. (New 버전) <-- New  UI가 2.6.0 에서는 하단 링크로 존재하였었는데, 현재 버전에서는 Default 로 존재한다.
  15. [내부 정보 유출 방지를 위하여 이미지는 Dev-Zone 이미지 임.]

2015년 5월 29일 금요일

Spark(1.2.1 -> 1.3.1) 을 위한 Mesos(0.18 -> 0.22.rc) - Upgrade

Spark 1.3.1 is designed for use with Mesos 0.21.0 and does not require any special patches of Mesos.
위 문구처럼 Spark 1.3.1 은 mesos0.21.0 에 최적화 되어 개발되어 있다.

그러나, 현 시점 mesos 0.21.0 은 bootstrap  수행시 m4 디렉토리를 인식하지 못한다는 메시지의 에러가 발생한다.

autoreconf: configure.ac: adding subdirectory 3rdparty/stout to autoreconf
autoreconf: Entering directory `3rdparty/stout'
aclocal: couldn't open directory `m4': No such file or directory
autoreconf: aclocal failed with exit status: 1

그리고, bootstrap 관련 스크립트의 에러 발생 부분 위치를 찾아 어거지로 해당 디렉토리를 인식하도록 fix  하고 수행을 한다 손 치더라도, 뒤이어 configure 를 돌릴때, gcc 버전을 아래처럼 더 올려서 수행하라는 메시지를 만나게 된다.

checking dependency style of gcc... (cached) gcc3
checking if compiling with clang... no
configure: GCC version: 4.4.7
configure: error: GCC 4.8 or higher is required for compiling Mesos

관련한 에러 메시지는 0.22.0 최신 버전을 수행하여도 동일하게 발생한다. 좀 이상한 것은 정상 설치 되던 0.18.0을 과거 설치하기 위해 다운받은 버전으로 다시 설치해도 예전에는 에러가 발생않던게 이번에는 에러가 난다는 점.

여기서 0.22.0을 설치하기 위해 yum 으로 dependency 모듈을 다운 받고 일부 dependency 걸린 모듈을 upgrade 하였는데, 그 dependency 로 인한 에러일것 같다는 유추가 가능하다. (더구나, 에러가 bootstrap 쪽인지라)

최근 버그 리포트와 빌드 노트를 확인해 보았더니, 최근에 패치가 된 bootstrap  파일 자체와 configure.ac 파일에서 gcc 관련 버그로 인한 패치가 있었는데, 본 에러와 관련된 패치 인것으로 여겨 진다. 여하튼 그 에러 때문에, 0.21.0 stable 버전을 포기하고, 최근 패치가 반영된 0.22.1-rc 버전을 다운받아 설치 하였다. 아울러 위 GCC 버전오류 때문에 GCC 도 업그레이드 해주었다.
  1. Mesos 0.22.1-rc 다운로드 및 기본 설치
    1. git clone https://github.com/apache/mesos.git
    2. cd mesos
    3. root 계정으로 vi /etc/yum.repos.d/wandisco-svn.repo
    4. [WandiscoSVN] name=Wandisco SVN Repo baseurl=http://opensource.wandisco.com/centos/6/svn-1.8/RPMS/$basearch/ enabled=1 gpgcheck=0
    5. yum groupinstall -y "Development Tools"
    6. yum install -y python-devel zlib-devel libcrul-devel openssl-devel cyrus-sasl-devel cyrus-sasl-md5 apr-devel subversion-devel apr-util-devel
    7. maven 설치 ( 설치 안된 경우 만...)
    8. wget http://mirror.nexcess.net/apache/maven/maven-3/3.0.5/binaries/apache-maven-3.0.5-bin.tar.gz
      tar -xvzf apache-maven-3.0.5-bin.tar.gz
      sudo ln -s /data01/maven/apache-maven-3.0.5/bin/mvn /usr/bin/mvn
  2. GCC 버전 업
    1. wget http://people.centos.org/tru/devtools-2/devtools-2.repo -O /etc/yum.repos.d/devtools-2.repo
    2. yum remove gcc
    3. yum --enablerepo=testing-devtools-2-centos-6 install -y devtoolset-2-gcc devtoolset-2-binutils devtoolset-2-gcc-gfortran gcc gcc-c++
    4. scl enable devtoolset-2 bash
    5. gcc -v  버전이 바뀌었는지 확인.
    6. g++ -v 버전이 바뀌었는지 확인. ( 보통 요거는 안바뀌어 있음. )
    7. yum whatprovides "*/g++"    => 지울목록과 설치할 목록 확인
      yum remove gcc-c++-4.4.7-11.el6.x86_64
      yum install devtoolset-2-gcc-c++-4.8.2-15.el6.x86_64
      yum whatprovides "*/g++"    =>  설치 여부 확인
      cd /usr/bin/
      ln -s /opt/rh/devtoolset-2/root/usr/bin/g++ g++
    8. g++ -v 버전이 바뀌었는지 확인. ( 이제 요거도 바뀜. )
  3. Host 정보 수정
    1. 처음 설치된 깨끗한 장비인 경우 만 해당.
    2. 요작업을 해주지 않으면 make check 과정에서 에러 중단 됨.
    3. vi /etc/hosts vi /etc/sysconfig/network hostname 호스트명
  4. Mesos 빌드
    1. cd /data01/mesos/mesos-0.22.1-rc/
    2. ./bootstrap
    3. mkdir build cd build ../configure
    4. make -j 16 ( <- core 갯수를 써주면, core 갯수만큼 병렬 수행한다... )
    5. make check ( <- 이 과정에 약간 에러가 보이는데, 소스를 까보면 Test Script 상의 문제이다. 아직 Nightly Build 버전인지라 make Check 용 스크립트가 최신 버전으로 마이그레이션이 덜 된 것으로 보인다.) 
    6. make install
여기 까지 하면 우선 Spark 1.3.1을 위한 Mesos 업그레이드는 마무리 된다.

2015년 4월 27일 월요일

SparkSQL cacheTable 메소드 사용 성능 비교 - default vs cacheTable vs cacheTable (with columnar Compression)


SparkSQL 을 사용하다 보면, 복잡한 Nested Query 를 사용하는 것보다, 최대한 쿼리들을 단순하게 쪼개고, 중간 결과물을 registerAsTable 로 Table 화 하여, 여러 Step 으로 나누어 하는 경우 훨씬 빠른 결과물을 얻을 수 있는 경우를 종종 접한다. 메모리 부족 에러 등도 이런경우 훨씬 덜하다.

그런데, 가끔 로그를 보다 보면, 앞부분에서 이미 수행했던 쿼리가 뒷부분에서 결과를 가지고 재 쿼리를 할때 앞에서 수행했던 쿼리를 다시 또 수행하는 현상을 목격한게 된다.

이런 경우를 막는 것이 cacheTable 메소드 인데... (sqlContext 안에 정의 되어 있음.) 메뉴얼에는 schemaRDD 의 경우 cache 메소드 보다 cacheTable 메소드를 강력히 추천한다고 되어 있다. (이유는 Columnar 압축 저장 방식 때문...)

RDD.cache() 처럼 이것도, 뒷부분에서 재사용이 많지 않을때는 약간의 overhead 만 더 주어 좀더 느려진다. 아래 실험 또한 재사용이 거의 없는 셈플을 가지고 수행했더니, 오히려 살짝 느려 졌다. 

특이한 점은 아래처럼 inMemoryColumnarStorage.compressed 옵션을 켰더니 또 더 빨라 졌다는 점..... 
물론 compressing 은 case 별로 빨라질때도, 느려질때도 있음을 잘 알고 있다. 아마도 아래 Job 에서는 Columnar compressing 으로 인하여, shuffle 되는 양이 줄었기 때문인 듯...

아래 실험에서는 2번과 3번이 큰 효율을 보이고 있지는 않지만, 재사용이 많은, 그리고 재사용하는 테이블이 복잡한 헤비 쿼리(혹은 헤비 데이타)인 경우, 이론적으로는 훨씬 급격한 성능 향상을 꽤 할 수 있으리라 기대해본다.

관련 메뉴얼 : https://spark.apache.org/docs/1.1.0/sql-programming-guide.html#caching-data-in-memory


1. Default 수행
-> 647초 소요.


2. cacheTable 메소드 사용.
-> 679초 소요.


3. cacheTable 및 Colmanar Compress 옵션 사용
-> .set("spark.sql.inMemoryColumnarStorage.compressed", "true")
-> 557초 소요


2015년 4월 4일 토요일

Druid (Interactive Analytics at Scale) - 설치기

Druid 설치는.... 공식 Web Site 의 Getting Started 를 참조 했지만, 무지 skip이 많다.

http://druid.io/

홈페이지 대문에 링크되어 있는 Getting Started는 그대로 따라하면 대략 5~6개의 에러를 만난다. 대표적으로, wikipedia 셈플은 MySQL 디펜던시가 없다고 해놓구선, 실행해보면 mysql 관련 시도를 한다...

물론 config 쪽에서 MySQL 접근을 하지 않도록 하는 방법도 있겠지만, Sample  만 돌리고 말것도 아니므로...대략적인 Full Setting 을 해 보았다. 기타 기본적인 세팅과 데몬 구동이 필수 필요함에도, Getting Started  는 모든걸 skip 하고 있었다.

어찌되었든, Getting Started 가 좀 비약이 심하지만, 나머지 Document 정리는 잘 되어 있는 느낌이다. github 내 소스들도 최근에도 활발히 소스 갱신이 있었음을 확인 하였다.

[Druid Dowload & install & Setting]

  1. wget http://static.druid.io/artifacts/releases/druid-0.7.0-bin.tar.gz
  2. tar xvzf druid*.tar.gz
  3. Download Zookeeper & Setting
    1. wget http://mirror.apache-kr.org/zookeeper/zookeeper-3.3.6/zookeeper-3.3.6.tar.gz
    2. tar xvzf zookeeper-3.3.6.tar.gz
    3. cp conf/zoo_sample.cfg conf/zoo.cfg
    4. ./bin/zkServer.sh start
  4. Install MySQL & initial Setting
    1. sudo yum install -y mysql-server
    2. sudo service mysql start
    3. mysql -u root
    4. GRANT ALL ON druid.* TO 'druid'@'localhost' IDENTIFIED BY 'diurd'; 
      CREATE DATABASE druid DEFAULT CHARACTER SET utf8;
  5. Coordinator Node settings
    1. 주석제거
      1. druid.host=localhost
        druid.port=8081
    2. strart
      1. java -Xmx256m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -classpath config/_common:config/coordinator:lib/* io.druid.cli.Main server coordinator
  6. Historical Node settings
    1. 주석제거
      1. druid.host=localhost druid.port=8083
    2. start
      1. java -Xmx256m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -classpath config/_common:config/historical:lib/* io.druid.cli.Main server historical
  7. Broker Node Settings
    1. 주석제거
      1. druid.host=localhost druid.port=8082
    2. start
      1. java -Xmx256m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -classpath config/_common:config/broker:lib/* io.druid.cli.Main server broker
  8. Realtime Node Settings
    1. 주석제거
      1. druid.host=localhost druid.port=8084
    2. start
      1. java -Xmx512m -Duser.timezone=UTC -Dfile.encoding=UTF-8 -Ddruid.realtime.specFile=examples/wikipedia/wikipedia_realtime.spec -classpath config/_common:config/realtime:lib/* io.druid.cli.Main server realtime
      2. realtime 으로 데이타를 가져오는 것까지 준비가 되어 있다. example 로 우선 구동 태스트를 해 보았으며, 결과를 빠르게 확인해보기 위해서는 위 .spec 파일을 열어 수집 갱신 주기를 바꾸어 주면 가능하다.
위 처럼 Coordinator ip:port 를 브라우저에서 치면, web ui 를 볼 수 있다.
아래처럼 저장해둔 example query 를 콘솔에서 restful url 로 수행해 보자 결과가 json 으로 떨어진다. 즉, WebService 를 위한 별도의 WAS 나 Gateway Ajax 용 호스팅 Web Page 를 만들지 않아도 된다.
일단, 오늘은 싱글노드 설치 & 쿼리 결과 보는 것 까지...!!!!