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
6. sudo yum localinstall -y influxdb-0.9.3-1.x86_64.rpm
7. 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. 
4. 아래는 상세 옵션 들.... import 도 되고, 원격서버접속도 되고, format  옵션으로 json 이나 csv 로 output 을 뽑을 수도 있고, compressed import 옵션도 보인다.
5. 
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 가 보여져야 함.
7. 

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 설정
• http://www.programering.com/a/MjNxQjNwATc.html 참조
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

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

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 라고 보여 진다.