big data (빅데이터) ZooKeeper란 무엇인가?

 

 

ZooKeeper란 무엇인가?

조대협 (http://bcho.tistory.com)

 

소개

 

분산 시스템을 설계 하다보면, 가장 문제점 중의 하나가 분산된 시스템간의 정보를 어떻게 공유할것이고, 클러스터에 있는 서버들의 상태를 체크할 필요가 있으며 또한, 분산된 서버들간에 동기화를 위한 락(lock)을 처리하는 것들이 문제로 부딪힌다.

 

이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템 (coordination service)라고 하는데, Apache Zookeeper가 대표적이다. 이 코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보등을 유지하기 때문에, 코디네이션 서비스의 장애는 전체 시스템의 장애를 유발하기 때문에, 이중화등을 통하여 고가용성을 제공해야 한다. ZooKeeper는 이러한 특성을 잘 제공하고 있는데, 그런 이유로 이미 유명한 분산 솔루션에 많이 사용되고 있다. NoSQL의 한종류인 Apache HBase, 대용량 분산 큐 시스템인 Kafka등이 그 대표적인 사례이다.

분산 시스템을 코디네이션 하는 용도로 디자인이 되었기 때문에, 데이타 억세스가 빨라야 하며, 자체적으로 장애에 대한 대응성을 가져야 한다. 그래서 Zookeeper는 자체적으로 클러스터링을 제공하며, 장애에도 데이타 유실 없이 fail over/fail back이 가능하다.

 

Apache Zookeeper의 기능은 사실상 별로 없다. 디렉토리 구조기반으로 znode라는 데이타 저장 객체를 제공하고, (key-value식). 이 객체에 데이타를 넣고 빼는 기능만을 제공한다. 일단 디렉토리 형식을 사용하기 때문에 데이타를 계층화된 구조로 저장하기 용이하다.

 

데이타 모델

 

데이타 모델은 간단하다. 디렉토리 구조의 각 노드에 데이타를 저장할 수 있다.

 

 

 

 

노드는 아래와 같이 기능에 따라 몇가지 종류로 나뉘어 지는데 

 

• Persistent Node : 노드에 데이타를 저장하면 일부러 삭제하지 않는 이상 삭제되지 않고 영구히 저장된다.

• Ephemeral Node : 노드를 생성한 클라이언트의 세션이 연결되어 있을 경우만 유효하다. 즉 클라이언트 연결이 끊어지는 순간 삭제 된다. 이를 통해서 클라이언트가 연결이 되어 있는지 아닌지를 판단하는데 사용할 수 있다. (클러스터를 구성할때 클러스터내에 서버가 들어오면, 이 Ephemeral Node로 등록하면 된다.)

• Sequence Node : 노드를 생성할때 자동으로 sequence 번호가 붙는 노드이다. 주로 분산락을 구현하는데 이용된다.

 

Watcher

 

Watch 기능은 ZooKeeper 클라이언트가 특정 znode에 watch를 걸어놓으면, 해당 znode가 변경이 되었을때, 클라이언트로 callback 호출을 날려서 클라이언트에 해당 znode가 변경이 되었음을 알려준다. 그리고 해당 watcher는 삭제 된다. 

 

ZooKeeper 활용 시나리오

 

Zookeeper는 단순히, 디렉토리 형태의 데이타 저장소이지만, 노드의 종류별 특성과, Watcher 기능들을 활용하면 다양한 시나리오에 사용할 수 있다. 

 

1. 큐 : Watcher와 Sequence node를 이용하면, 큐를 구현할 수 있는데, Queue 라는 Node를 만든 후에, 이 노드의 Child node를 sequence node로 구성하면, 새롭게 생성되는 메세지들은 이 sequence node로 순차적으로 생성된다. 이 큐를 읽는 클라이언트가 이 큐 node를 watch 하도록 설정하면, 이 클라이언트는 새로운 메세지가 들어올 때 마다 call back을 받아서, 마치 메세지 Queue의 pub/sub 과 같은 형태의 효과를 낼 수 있다. 대용량 메세지나 애플리케이션 성격상의 메세지는 일반적인 큐 솔루션인 Rabbit MQ등을 활용하고, ZooKeeper는 클러스터간 통신용 큐로 활용하는 것을 고려해볼 수 있다.

2. 서버 설정 정보 : 가장 일반적인 용도로는 클러스터 내의 각 서버들의 설정 정보(Configuration)를 저장하는 저장소로 쓸 수 있다. 정보가 안정적으로 저장이 될 뿐 아니라. Watch 기능을 이용하면, 설정 정보가 저장될 경우, 각 서버로 알려서 바로 반영을 할 수 있다.

3. 클러스터 정보 : 현재 클러스터에서 기동중인 서버 목록을 유지할 수 있다. Ephemeral Node는 Zookeeper 클라이언트가 살아 있을 경우에만 유효하기 때문에, 클러스터내의 각 서버가 Ephemeral Node를 등록하도록 하면, 해당 서버가 죽으면 Ephemeral Node 가 삭제 되기 때문에 클러스터 내의 살아 있는 Node 리스트만 유지할 수 있다. 조금 더 발전하면, 클러스터가 master/slave 구조일때, master 서버가 죽었을 때, 다른 master 서버를 선출하는 election logic 도 구현이 가능하다. (https://zookeeper.apache.org/doc/r3.4.6/recipes.html#sc_recipes_Queues 참고)

4. 글로벌 락 : Zookeeper를 이용하여 많이 사용되는 시나리오 중의 하나인데, 여러개의 서버로 구성된 분산 서버가 공유 자원을 접근하려고 했을때, 동시에 하나의 작업만이 발생해야 한다고 할때, 그 작업에 Lock을 걸고 작업을 할 수 있는 기능을 구현할때 사용한다. 자바 멀티 쓰레드 프로그램에서 synchronized를 생각하면 쉽게 이해가 가능할 것이다.

자세한 구현 방식과 시나리오에 대해서는 https://zookeeper.apache.org/doc/r3.4.6/recipes.html 를 참고하기 바란다.

 

설치

https://zookeeper.apache.org 에서 gz 파일을 다운 받아서, 압축만 풀면 간단하게 설치는 끝난다. 여기서는 안정 버전인 3.4.6 버전을 사용하였다. 그리고 c:\dev\tools\zookeeper 디렉토리에 압축을 풀었다.

 

간단한 테스트 하기

$ZooKeeper_home/conf/zoo.conf를 다음과 같이 작성하자

clientPort=2181

tickTime=2000

dataDir=c:\temp\

 

그리고

c:\dev\tools\zookeeper>.\bin\zkServer.cmd로 서버를 구동한다. 이때 하나의 서버만 구동하기 때문에, 이를 standalone 모드라고 한다. (원래 Production에서는 데이타 복제를 통한 페일오버를 지원하기 위해서 여러개의 서버를 띄운다.)

다음으로 zookeepr에 접속해보자

C:\dev\tools\zookeeper>bin\zkCli -server 127.0.0.1:2181

 

다음과 같이 쉘이 실행됨을 확인할 수 있다.

 

 

 

 

다음으로, 새로운 znode를 하나 만들어보자. 다음과 같이 create 명령을 이용하여 zk_test 노드를 “hello”라는 값으로 생성한다. 다음에, get 명령을 이용하여 데이타를 조회한다.

 

다음으로, my_server1 라는 노드를 추가로 만들자 그리고, ls / 명령어를 실행하면 다음과 같이 아까 만든 zk_test 노드와, my_server1 노드가 생성됨을 확인할 수 있다.

 

 

참고 자료

https://zookeeper.apache.org/doc/r3.4.6/zookeeperStarted.html

http://helloworld.naver.com/helloworld/textyle/294797 이 글은 레디스 클러스터를 주키퍼를 이용하여 구현한 실 사례로, 읽어볼 여지가 있다.

조대협 (http://bcho.tistory.com)

 

소개

 

분산 시스템을 설계 하다보면, 가장 문제점 중의 하나가 분산된 시스템간의 정보를 어떻게 공유할것이고, 클러스터에 있는 서버들의 상태를 체크할 필요가 있으며 또한, 분산된 서버들간에 동기화를 위한 락(lock)을 처리하는 것들이 문제로 부딪힌다.

 

이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템 (coordination service)라고 하는데, Apache Zookeeper가 대표적이다. 이 코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보등을 유지하기 때문에, 코디네이션 서비스의 장애는 전체 시스템의 장애를 유발하기 때문에, 이중화등을 통하여 고가용성을 제공해야 한다. ZooKeeper는 이러한 특성을 잘 제공하고 있는데, 그런 이유로 이미 유명한 분산 솔루션에 많이 사용되고 있다. NoSQL의 한종류인 Apache HBase, 대용량 분산 큐 시스템인 Kafka등이 그 대표적인 사례이다.

분산 시스템을 코디네이션 하는 용도로 디자인이 되었기 때문에, 데이타 억세스가 빨라야 하며, 자체적으로 장애에 대한 대응성을 가져야 한다. 그래서 Zookeeper는 자체적으로 클러스터링을 제공하며, 장애에도 데이타 유실 없이 fail over/fail back이 가능하다.

 

Apache Zookeeper의 기능은 사실상 별로 없다. 디렉토리 구조기반으로 znode라는 데이타 저장 객체를 제공하고, (key-value식). 이 객체에 데이타를 넣고 빼는 기능만을 제공한다. 일단 디렉토리 형식을 사용하기 때문에 데이타를 계층화된 구조로 저장하기 용이하다.

 

데이타 모델

 

데이타 모델은 간단하다. 디렉토리 구조의 각 노드에 데이타를 저장할 수 있다.

 

 

 

 

노드는 아래와 같이 기능에 따라 몇가지 종류로 나뉘어 지는데 

 

• Persistent Node : 노드에 데이타를 저장하면 일부러 삭제하지 않는 이상 삭제되지 않고 영구히 저장된다.

• Ephemeral Node : 노드를 생성한 클라이언트의 세션이 연결되어 있을 경우만 유효하다. 즉 클라이언트 연결이 끊어지는 순간 삭제 된다. 이를 통해서 클라이언트가 연결이 되어 있는지 아닌지를 판단하는데 사용할 수 있다. (클러스터를 구성할때 클러스터내에 서버가 들어오면, 이 Ephemeral Node로 등록하면 된다.)

• Sequence Node : 노드를 생성할때 자동으로 sequence 번호가 붙는 노드이다. 주로 분산락을 구현하는데 이용된다.

 

Watcher

 

Watch 기능은 ZooKeeper 클라이언트가 특정 znode에 watch를 걸어놓으면, 해당 znode가 변경이 되었을때, 클라이언트로 callback 호출을 날려서 클라이언트에 해당 znode가 변경이 되었음을 알려준다. 그리고 해당 watcher는 삭제 된다. 

 

ZooKeeper 활용 시나리오

 

Zookeeper는 단순히, 디렉토리 형태의 데이타 저장소이지만, 노드의 종류별 특성과, Watcher 기능들을 활용하면 다양한 시나리오에 사용할 수 있다. 

 

1. 큐 : Watcher와 Sequence node를 이용하면, 큐를 구현할 수 있는데, Queue 라는 Node를 만든 후에, 이 노드의 Child node를 sequence node로 구성하면, 새롭게 생성되는 메세지들은 이 sequence node로 순차적으로 생성된다. 이 큐를 읽는 클라이언트가 이 큐 node를 watch 하도록 설정하면, 이 클라이언트는 새로운 메세지가 들어올 때 마다 call back을 받아서, 마치 메세지 Queue의 pub/sub 과 같은 형태의 효과를 낼 수 있다. 대용량 메세지나 애플리케이션 성격상의 메세지는 일반적인 큐 솔루션인 Rabbit MQ등을 활용하고, ZooKeeper는 클러스터간 통신용 큐로 활용하는 것을 고려해볼 수 있다.

2. 서버 설정 정보 : 가장 일반적인 용도로는 클러스터 내의 각 서버들의 설정 정보(Configuration)를 저장하는 저장소로 쓸 수 있다. 정보가 안정적으로 저장이 될 뿐 아니라. Watch 기능을 이용하면, 설정 정보가 저장될 경우, 각 서버로 알려서 바로 반영을 할 수 있다.

3. 클러스터 정보 : 현재 클러스터에서 기동중인 서버 목록을 유지할 수 있다. Ephemeral Node는 Zookeeper 클라이언트가 살아 있을 경우에만 유효하기 때문에, 클러스터내의 각 서버가 Ephemeral Node를 등록하도록 하면, 해당 서버가 죽으면 Ephemeral Node 가 삭제 되기 때문에 클러스터 내의 살아 있는 Node 리스트만 유지할 수 있다. 조금 더 발전하면, 클러스터가 master/slave 구조일때, master 서버가 죽었을 때, 다른 master 서버를 선출하는 election logic 도 구현이 가능하다. (https://zookeeper.apache.org/doc/r3.4.6/recipes.html#sc_recipes_Queues 참고)

4. 글로벌 락 : Zookeeper를 이용하여 많이 사용되는 시나리오 중의 하나인데, 여러개의 서버로 구성된 분산 서버가 공유 자원을 접근하려고 했을때, 동시에 하나의 작업만이 발생해야 한다고 할때, 그 작업에 Lock을 걸고 작업을 할 수 있는 기능을 구현할때 사용한다. 자바 멀티 쓰레드 프로그램에서 synchronized를 생각하면 쉽게 이해가 가능할 것이다.

자세한 구현 방식과 시나리오에 대해서는 https://zookeeper.apache.org/doc/r3.4.6/recipes.html 를 참고하기 바란다.

 

설치

https://zookeeper.apache.org 에서 gz 파일을 다운 받아서, 압축만 풀면 간단하게 설치는 끝난다. 여기서는 안정 버전인 3.4.6 버전을 사용하였다. 그리고 c:\dev\tools\zookeeper 디렉토리에 압축을 풀었다.

 

간단한 테스트 하기

$ZooKeeper_home/conf/zoo.conf를 다음과 같이 작성하자

clientPort=2181

tickTime=2000

dataDir=c:\temp\

 

그리고

c:\dev\tools\zookeeper>.\bin\zkServer.cmd로 서버를 구동한다. 이때 하나의 서버만 구동하기 때문에, 이를 standalone 모드라고 한다. (원래 Production에서는 데이타 복제를 통한 페일오버를 지원하기 위해서 여러개의 서버를 띄운다.)

다음으로 zookeepr에 접속해보자

C:\dev\tools\zookeeper>bin\zkCli -server 127.0.0.1:2181

 

다음과 같이 쉘이 실행됨을 확인할 수 있다.

 

 

 

 

다음으로, 새로운 znode를 하나 만들어보자. 다음과 같이 create 명령을 이용하여 zk_test 노드를 “hello”라는 값으로 생성한다. 다음에, get 명령을 이용하여 데이타를 조회한다.

 

다음으로, my_server1 라는 노드를 추가로 만들자 그리고, ls / 명령어를 실행하면 다음과 같이 아까 만든 zk_test 노드와, my_server1 노드가 생성됨을 확인할 수 있다.

 

 

참고 자료

https://zookeeper.apache.org/doc/r3.4.6/zookeeperStarted.html

http://helloworld.naver.com/helloworld/textyle/294797 이 글은 레디스 클러스터를 주키퍼를 이용하여 구현한 실 사례로, 읽어볼 여지가 있다.

 

[출처] http://bcho.tistory.com/1016