ZooKeeper 옵저버와 CLI

 

·       Version : Zookeeper

 

주키퍼는 리더가 모든 서버에 쓰기 요청을 보내고 과반수 이상의 응답을 받은 처리한다. 주키퍼 서버에 연결되는 클라이언트수가 많으면, 서버를 확장하여 읽기에 대한 부하분산이 가능하다. 하지만 서버가 늘어날 경우, 쓰기 연산 발생시 전체 서버에 대해서 응답을 기다려야 하기 때문에, 그만큼 성능 저하가 발생할 있다. 이러한 문제를 해결하기위해 옵저버 개념이 도입되었다.

옵저버는 투표에 참여하지 않는 서버를 뜻한다. 리더는 쓰기 요청을 받고 서버로 쓰기에 대한 응답을 보내고 받을때, 옵저버 서버에는 보내지 않는다. 그리고 일반 서버의 투표에 의한 정상 처리인 경우, 쓰기 요청을 옵저버로 보내 옵저버의 로컬 메모리에 데이터를 기록한다. 서버가 옵저버로 동작하게 하려면 옵저버 서버의 환경설정에 아래와 같은 값을 입력한다.

peerType=observer

 

그리고 모든 서버의 환경 설정에 옵저버 서버의 정보를 추가하여 투표 요청을 하지 않도록 한다. 아래 예시는 192.168.0.2 서버가 observer 서버라는 정보를 환경 설정에 등록한 것이다.

Server.1:192.168.0.2:2181:3181:observer

 

주키퍼는 CLI(Command Lind Interface)기반의 프로그램을 제공한다. 클라이언트 쉘을 실행하려면 아래와 같은 명령을 입력 한다.

bin.zkCli.sh ?server 127.0.0.1:2181

 

아래표는 CLI 명령어와 설명이다.

command

Description

connect host:port

주키퍼 서버에 접속한다.

get path

노드에 저장된 데이터를 보여준다.

ls path

노드의 자식 노드 목록을 조회한다.

set path data

노드의 데이터를 수정한다.

delquota [-n|-b] path

노드의 사용 용량 설정 정보를 삭제 한다.

quit

쉘을 종료 한다.

printwatches on|off

와처에서 받은 이벤트 정보를 콘솔에 출력할지 여부를 설정한다.

create [-s][-e] path data acl

노드를 생성한다. -s옵션은 순차노드를 생성, -e 임시노드를 생성한다.

stat path

패스의 상태 정보를 조회한다.

close

주키퍼 접속을 종료한다.

ls2 path

ls stat명령을 동시에 수행시킨 내용을 보여준다.

history

수행한 명령어 목록을 보여준다.

listquota path

패스에 설정된 용량 설정 정보를 보여준다.

setAcl path acl

패스에 권한을 설정한다.

getAcl path

패스의 ACL 목록을 조회한다.

sync path

패스에 sync 명령을 보낸다.

redo cmdno

쉘에서 이전에 실행했던 명령을 다시 실행한다.

addauth scheme auth

현재 오픈되어 있는 쉘의 주키퍼 연결에 인증 정보를 추가한다.

delete path

패스를 삭제한다.

 

 

 

2020-05-18 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

'SW Engineering > Hadoop' 카테고리의 다른 글

Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19
ZooKeeper 옵저버와 CLI  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18
ZooKeeper 클라이언트 요청 처리  (0) 2020.05.18
ZooKeeper 멀티 서버 구성  (0) 2020.05.17
ZooKeeper 리더선출과 데이터 ACID 정책  (0) 2020.05.14

ZooKeeper 클라이언트 요청 처리

 

·       Version : Zookeeper

 

주키퍼의 모든 서버는 클라이언트로 부터 읽기, 쓰기 요청을 받을 있다. 읽기 요청은 클라이언트가 접속한 서버의 로컬 데이터를 이용한다. 쓰기 요청을 받은 서버는 리더 서버로 리다이렉트 한다.

 

 

리더는 새로운 트랜잭션아디이(zxid) 생성한 모든 팔로워에게 쓰기 요청을 보낸다. 쓰기 요청을 받은 서버는 자기의 로컬 트랜잭션 로그 파일에 처리 내역을 저장하지만 실제 메모리에는 반영하지 않고, 리더로 ACK 신호를 보낸다. 리더는 과반수 이상의 팔로워로부터 ACK 신호를 받으면 메모리에 반영하라고 하는 커밋 신호를 보낸다. 커밋 신호를 받은 팔로워는 자신의 메모리에 쓰기 요청된 정보를 반영한다. 팔로워 클라이언트로 부터 요청을 받은 서버는 클라이언트로 처리 결과를 보낸다. 아래 그림에서 순서를 쉽게 확인할 있다.

 

 

 

 

주피커는 이벤추얼한 정합성을 가지고 있는데, 동일 데이터에 대해 쓰기나 읽기가 서로 다른 클라이언트에서 서로 다른 주키퍼 서버에 접속하면 읽기 연산을 수행하는 클라이언트에는 반영되기 전의 데이터가 읽혀질 가능성이 크다. 그래서 강한 정합성을 필요로 하는 애플리케이션이나 기능에서는 sync() 메소드를 이용하여 해결할 있다. Sync() 메소드는 파라미터로 전달된 패스에 대해 모든 주키퍼 서버가 처리 중인 쓰기 연산을 로컬 메모리에 모두 반영하는것을 보장하는 메소드다.

 

주키퍼 서버에 장애가 발생하면 클라이언트 측에서는 Disconnected 이벤트가 발생하고, 클라이언트 라이브러리에서는 자동으로 다른 서버로 접속을 시도한다. 주키퍼 클라이언트는 자신이 실행한 최종 트랜잭션 아이디(zxid) 메모리에서 관리한다. 주키퍼 서버는 자신의 트랜잭션아이디보다 값을 가지고 있는 클라이언트의 접속 요청은 거절한다.

 

 

 

2020-05-17 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

'SW Engineering > Hadoop' 카테고리의 다른 글

ZooKeeper 옵저버와 CLI  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18
ZooKeeper 클라이언트 요청 처리  (0) 2020.05.18
ZooKeeper 멀티 서버 구성  (0) 2020.05.17
ZooKeeper 리더선출과 데이터 ACID 정책  (0) 2020.05.14
Zookeeper 세션(Session)  (0) 2020.05.13

ZooKeeper 멀티 서버 구성

 

·       Version : Zookeeper

 

주키퍼를 멀티서버로 구성하려면 서버에 멀티서버에 대한 정보를 추가해야 한다. 주피커 설치 디렉터리에서 conf/zoo.cfg 파일에 아래와 같이 정보를 입력 한다.

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/data/zookeeper

clientPort=2181

 

server.1=192.168.1.1:2888:3888

server.2=192.168.1.2:2888:3888

server.3=192.168.1.3:2888:3888

 

zoo.cfg 파일에서 서버 만큼 server.x=IP:Port:Port 입력한다. server 예약어이며, x 서버를 식별하는 ID 숫자를 입력한다. IP 서버의 IP 입력하고, 첫번째 포트는 리더에 접속하기 위한 포트이며, 두번째 포트는 리더를 선출하는데 사용되는 포트이다. 위에서 생성한 설정 파일을 서버에 복사하고, 서버의 데이터 디렉터리에 myid 라는 파일을 만들어서 해당 서버의 아이디를 입력한다. 아래 예제는 서버1에서 데이터 경로가 /data/zookeeper 사용하였다.

vi /data/zookeeper/myid

1 #숫자 입력 종료

 

설정이 완료되고 서버에서 주키퍼 서버를 시작하면, 멀티서버 주키퍼 클러스터로 동작한다. 멀티서버 구성에는 실행되고 있는 서버의 수가 과반수(등록된 서버 + 1)/2) 이하이면 동작하지 않는다. 예를들어 클러스터가 3대일때, 2대의 서버 장애가 발생하면 서비스가 중지 된다. 아래 스크립트는 주키퍼 서버를 시작하는 명령어이다.

bin/zkServer.sh start

 

서버에서 주키퍼를 시작하면 첫번째 서버 시작시 오류 메시지가 나타나는데, 멀티서버로 설정된 주키퍼는 설정 파일에 있는 다른 서버에 접속해 리더 선출과정을 거쳐야 정상으로 작동되기 때문에 설정 파일에 등록된다른 서버를 시작하면 경고가 발생하지 않는다. 서버 메시지에서 “LEADING” 메시지가 표시된 서버가 리더로 선출된 서버이다.

 

아래 표는 주키퍼 환경 설정에 대한 속성과 설명이다.

속성

설명

clientPort

클라이언트로 요청을 받기 위한 포트

dataDir

메모리에 있는 데이터를 스냡샷으로 저장하는 디렉터리 경로

tickTime

주키퍼에서 사용되는 기본 시간 단위. 최소 세션타임아웃은 값의 2배이다.

dataLogDir

트랜잭션 로그를 저장하는 디렉터리. 특별한 설정을 하지 않으면 dataDir 저장. 성능상 다른 디스크의 디렉터리에 분리하는것이 좋다.

globalOutstandingLimit

큐가 많이 쌓이게 되면 메모리 부족으로 정상 작동하지 못하게 된다. 사이즈보다 많은 요청을 받지 못하도록 설정하는 값이며 기본값은 1000 이다.

preAllocSize

트랜잭션 로그 저장을 위해 미리 할당 받은 파일 사이즈. 기본값은 64MB 스냅샷을 자주 만들경우 값을 줄여서 사용한다.

snapCount

트랜잭션 회수가 snapCount 이상되면 메모리 내용을 스냅샷 파일로 저장하고 새로운 트랜잭션 파일을 만든다.

traceFile

설정이 켜져 있으면 클라이언트 요청을 traceFile.year.month.day 형태의 파일명에 저장한다. 주로 디버그 용도로 활용하며 설정이 켜져 있으면 오버헤드가 발생한다.

maxClientCnxns

클라이언트로 부터 동시에 접속할 있는 연결 수를 지정. 연결수는 클라이언트 IP 개수이며, 기본값은 10이며 0 무제한이다.

clientPortBindAddress

서버의 네트워 카드 IP 여러개 일때, 클라이언트가 접속할 서버의 IP주소나 호스트명을 지정한다. 기본값은 모든 IP 주소, 네트워크 카드에 접속 가능하다.

minSessionTimeout

최소 세션 타임아웃이며 단위는 밀리세컨드 (ms)이다. 기본값은 tickTime *2 이다.

maxSessionTimeout

최대 세션 타임아웃이며 단위는 밀리세컨드(ms)이다. 기본값은 tickTime *20 이다.

electionAlg

리더를 선출하는 알고리즘. 기본값은 3이다.
0 : UDP 기반의 기본 리더 선출

1 : UDP 기반의 비인증 빠른 리더 선출(FastLeaderElection)

2 : UDP 기반의 인증 빠른 리더 선출

3 : TCP 기반의 빠른 리더 선출

initLimit

초기에 팔로워가 리더에 접속하거나 데이터를 동기화 시키기 위한 시간으로 단위는 tickTime 이며 initLimit * tickTime으로 계산된다.

leaderServes

클라이언트의 요청을 리더가 받을 것인지에 대한 설정 기본값은 yes 이다. 쓰기 연산이 많은 경우, 리더가 클라이언트 요청을 받게되면 쓰기 연산에 대한 처리와 클라이언트로 부터의 읽기,쓰기 연산을 동시에 하게 되면서 많은 오버헤드가 발생한다. 경우 no 설정하는 것이 좋다.

server.x=ip:port:port

멀티 서버를 구성할 경우 서버 목록 지정. 앞의 포트는 리더에 접속하기 위한 포트이며, 번째는 리더를 선출하는 포트이다.

syncLimit

Sync 수행하는 시간으로 Tick기준이다. 시간동안 sync 안되면 해당 팔로워는 클러스터에서 제외된다.

group.x=id[:id]

계층적 정족수를 설정한다 x 그룹 아이디로 숫자 값을 설정한다. = 이후에는 그룹에 포함될 서버 아이디를 입력하며 구분자는 : 이다.

weight.x= n

서버간 정족수 투표를 할때 서버의 가중치를 설정. X 서버 아이디이며 n 가중치 값을 설정한다. 기본값은 1이다.

 

주키퍼는 자바로 개발되었으며 JVM(Java Virtual Machine)환경에서 운영된다. 그래서 JVM 대한 설정도 고려해야한다. JVM GC(Garbage Collection) 수행할때 모든 스레드가 멈추게 되는 경우도 있다. GC 수행되는 모든 모든 스레드가 동작하지 못하게 되면 예기치 못한 타임아웃이 발생하고, 클라이언트, 서버 모두 정상적인 상황임에도 세션을 유지하지 못하는 상태가 발생한다. 주키퍼 서버를 실행할 GC옵션을 아래와 같이 설정하며 GC 수행중에도 스레드가 동작할 있게 한다.

-XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC

 

외에도 성능이 저하되지 않도록 JVM 메모리 스왑이 발생하지 않도록 해야한다.

 

[참고자료]

·       Clustered (Multi-Server) Setup : https://zookeeper.apache.org/doc/r3.3.2/zookeeperAdmin.html#sc_zkMulitServerSetup

·       How To Install and Configure an Apache ZooKeeper Cluster on Ubuntu 18.04 : https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-an-apache-zookeeper-cluster-on-ubuntu-18-04

·       16 Tuning JVM Garbage Collection for Production Deployments : https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm#autoId0

 

 

 

2020-05-16 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

ZooKeeper 리더선출과 데이터 ACID 정책

 

·       Version : Zookeeper

 

주키퍼를 사용하여 분산 시스템을 관리할 경우 주키퍼는 반드시 멀티 서버로 운영해야한다. 멀티서버로 운영할 경우 네트워크 단절, 트랜잭션 타임아웃등의 상황에 대비해야한다. 특히 일부 주키퍼 서버 장애발생시 해당 서버에 접속된 클라이언트의 세션에 대한 처리, 장애복구 서버간 데이터 동기화 등이 고려되어야 한다. 주키퍼는 이러한 문제를 자체적으로 해결하기 때문에 마스터 서버 구성시 주키퍼를 사용함으로써 상대적으로 쉽게 해결할 있다.

 

주키퍼를 멀티서버로 설치하면 모든 서버는 동일한 데이터를 가지고 있다. 클라이언트는 모든 서버에 접속해서 읽기, 쓰기 요청을 보낼수 있다. 읽기 연산은 모든 데이터가 동기화 되어 있기 때문에 자체 서버에서 제공할 있지만, 쓰기연산은 특정 서버가 마스터 역할을 수행하면서 쓰기 작업이 정상적으로 수행되었는지 확인할 필요가 있다. 이러한 역할을 하는 서버를 리더(leader)라고 한다.

주키퍼는 클러스터내에서 자동으로 리더를 선출한다. 클러스터가 재시작되거나 장애가 발생하면 자동으로 리더를 선출하며 리더를 선출하는 방법 순서는 아래와 같다.

1.       서버는 자신의 현재 트랜잭션ID(zxid) 자신을 후보자로 지명해 모든 서버로 전송

2.       서버는 트랜잭션 아이디를 받은 자신이 최대값이 아니면 다시 최대값을 갖고 있는 서버를 후보자로 지명하여 모든 서버에 전송

3.       과반수 이상의 서버로부터 후보자로 지명된 서버는 리더로 선출

4.       다른 서버는 팔로워(follower) 동작

 

분산처리 시스템에서 ACID 속성중 정합성(Consistency) 독립성(Isolation) 보장하는것은 쉽지 않다. 주키퍼는 데이터 저장시 아래와 같은 사항을 보장한다.

·       순차적 정합성(Sequential Consistency) : 주키퍼 클러스터에 저장되는 데이터는 강한 정합성(Strong Consistency) 보장하지 않고, 이벤추얼 정합성(Eventual Consistency) 보장한다. 이벤추얼 정합성은 일정 시간이 지나면 정합성이 맞춰지는 속성이다. 특정 클라이언트로부터 데이터 저장에 대한 요청이 있을때 , 분산되어 있는 주키퍼 서버에 반영되는 순서는, 클라이언트에서 전송된 요청 순서대로 처리되는것을 보장한다.

·       원자성(Atomic) : 전체가 수행되거나 전체가 실패되는 행위로, 부분적인 성공은 존재하지 않는다.

·       단일 이미지 제공 (Single System Image) : 클라이언트는 어떤 주키퍼 서버에 접속하더라도 동일한 데이터 뷰를 제공 받는다.

·       안정성 (Reliability) : 주키퍼에 저장된 데이터는 클라이언트의 명시적인 호출에 의해 수정되지 않는한 영속성을 가지고 있다.

 

 

 

2020-05-13 / Sungwook Kang / http://sungwookkang.com

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, 주키퍼, Zookeeper, 분산 코디네이션

+ Recent posts