zookeeper 알아보기

http://zookeeper.apache.org/

소개

Zookeeper is a distributed Coordination Service for distributed applications

잘 정리된 포스팅이 있어서 일부 발췌함.

http://kimseunghyun76.tistory.com/397

• 분산 처리 환경에서 사용 가능한 데이터 저장소
• 분산 서버간의 정보 공유, 서버 투입/제거 시 이벤트 처리, 서버 모니터링, 시스템 관리, 분산 락 처리, 장애 상황 판단 등 다양한 분야에서 활용
• ZooKeeper는 데이터를 디렉토리 구조로 저장하고, 데이터가 변경되면 클라이언트에게 어떤 노드가 변경됐는지 콜백을 통해 알려줌.
• 영속성(Persistent)를 유지하기 위해서 트랜잭션 로그와 스냅샷 파일이 디스크에 저장되고, 시스템을 재시작해도 데이터가 유지됨.
• ZooKeeperer Server에 접속한 클라이언트가 특정 노드를 Ephermeral Node 로 생성했다면, 그 클라이언트와 서버간의 세션이 끊어지면(ping를 제대로 처리 못하면) 해당 노드는 자동 삭제.
• ZooKeeper 서버는 Leader 와 Follower로 구성되어 있다. 서버들끼지 자동으로 Leader 를 선정하며 모든 데이터 저장을 주도 한다.
• 클라이언트에서 Server(Follower)로 데이터 저장을 시도 할때, Server(Follower)-> Server(Leader) -> 나머지 Server(Follower) 로 데이터를 전달 하는 구조. 모든 서버에 동일한 데이터가 저장된 후 클라이언트에게 성공/실패 여부를 알려주는 동기 방식으로 작동함.
• 동적으로 ZooKeeper 서버를 추가/삭제하는 것이 안됨. Zookeeper cluster 안에서 다른 서버들 리스트는 사전에 설정 파일로 고정되어야 함.

slideshare 로도 잘 정리된게 있음.

http://www.slideshare.net/madvirus/zookeeper-34888385

zookeeper를 활용한 Redis Cluster 관리

http://d2.naver.com/helloworld/294797

위 내용 중 일부 발췌

• ZooKeeper 서버는 일반적으로 3대 이상을 사용하며 서버 수는 주로 홀수로 구성한다. 서버 간의 데이터 불일치가 발생하면 데이터 보정이 필요한데 이때 과반수의 룰을 적용하기 때문에 서버를 홀수로 구성하는 것이 데이터 정합성 측면에서 유리하다.

• 사용/운영 시 몇 가지 주의 사항이 있다. 개발에 급급한 나머지 ZooKeeper를 캐시 용도로 사용해 서비스를 오픈했다가 장애가 발생한 사례도 종종 있다고 한다. 데이터의 변경이 자주 발생하는 서비스에서 ZooKeeper를 데이터 저장소로 사용하는 것은 추천하지 않는다. ZooKeeper에서 추천하는 Read : Write 비율은 10 : 1 이상이다.

• 그리고 ZooKeeper 서버가 제대로 실행되지 않을 때가 있는데, 대부분 서버간의 데이터 불일치로 인한 데이터 동기화 실패가 그 원인이다. 주로 베타 테스트 후 운영 직전에 ZooKeeper 서버를 증설해서 사용하는데, 이럴 때 기존에 테스트했던 서버와 신규로 투입한 서버의 데이터 차이로 인해 이런 현상이 종종 발생한다. 이때는 데이터를 초기화한 후 서버를 실행하면 된다.

손쉽게 사용하는 ZooKeeper 스토리지, Zoopiter!

http://d2.naver.com/helloworld/583580

위 내용 중 일부 발췌

• ZooKeeper는 데이터를 디스크에 영구 저장하긴 하지만, 빠른 처리를 위해 모든 트리 노드를 메모리에 올려놓고 처리한다. 즉 대규모의 데이터를 처리하기엔 무리가 있다. 따라서 Memcached나 Redis와 같은 캐시 서버와는 다른 용도로 쓰인다.

• ZooKeeper 앙상블 분산 작업을 제어하기 위해 사용되는 만큼 ZooKeeper 서버가 중단되면 ZooKeeper에 의존하는 모든 서버가 영향을 받는다. 따라서 ZooKeeper는 최대한 정상 동작을 보장하여야 한다. 이를 위해 여러 대의 ZooKeeper 서버를 클러스터링하여 고가용성을 지원하도록 설정할 수 있다. 이 ZooKeeper 클러스터를 앙상블(Ensemble)이라 부른다.

• Multi-Tenancy ZooKeeper는 상당히 좋은 성능 특성을 보인다. ZooKeeper 서버(2 Core/4G RAM) 3대를 앙상블로 묶어 테스트를 진행해 본 결과, 쓰기와 읽기를 각각 10%, 90%로 배분할 경우 초당 약 23,000번의 트랜잭션을 수행할 수 있다. 그러나 실제 ZooKeeper 사용 사례에서는 이 성능을 온전히 사용하지 않는다는 것을 알 수 있었다. HDFS와 같은 분산 처리 시스템에서 ZooKeeper를 사용할 때는 다른 용도로 이미 사용하는 서버에 ZooKeeper 프로세스를 추가 실행하는 것으로 처리하기도 한다.

• ZooKeeper 단독으로 서버를 구성할 때는 자원 낭비가 심하다. 사실 '분산 처리 제어'에 동원되는 CPU나 I/O 자원은 그다지 크지 않다. 일반적으로 수십 개 이하의 노드만 조작하면 되고, 조작 자체도 자주 일어나지 않는다. 하지만 앙상블 구성을 위해 3대 이상의 ZooKeeper 서버를 동원해야 한다는 것은 가동률 측면에서 다소 과도하다.

• ZooKeeper는 노드별 ACL(Access Control List)을 지원하므로, ZooKeeper 클라이언트로 노드를 만들 때 다른 클라이언트 중 일부만 읽기 또는 쓰기를 할 수 있도록 설정할 수 있다. 하지만 상위 노드에 설정한 ACL이 자동으로 하위 노드로 전파되지는 않는다. 따라서 노드마다 ACL을 직접 설정해야 한다. 만약 노드 A에 ACL을 설정해 놓고 실수로 노드 A의 하위 노드 A1에 ACL을 설정하지 않았다면, 노드 A1은 누구든 접근해 쓰고 읽을 수 있다. 사소한 실수로 데이터 접근 위험에 바로 노출되는 것이다. 이런 상황에서 ZooKeeper를 공유 서버 형태로 제공하기에는 큰 위험이 따른다.

ZooKeeper 클라이언트 작성 방법

• 디폴트 ZooKeeper 클라이언트 라이브러리를 사용한 자바 샘플
• Neflix에서 제공하는 Curator를 사용한 자바 샘플
• 디폴트 ZooKeeper 클라이언트 라이브러리를 사용한 C 샘플
• 확장 ZooKeeper 클라이언트 라이브러리를 사용한 C# 샘플
• ZooKeeper CLI 도구인 zkCli.sh를 사용하여 ZooKeeper 앙상블에 직접 접근하는 방법 API의 편의성과 안정성 측면에서 Curator가 디폴트 ZooKeeper 클라이언트에 비해 더 낫다. 예를 들어, ZooKeeper 디폴트 라이브러리는 특정 명령 처리 도중에 현재 연결된 서버가 중단되면 해당 명령을 내리는 구문에서 예외를 반환한다. 하지만 Curator는 다른 서버로 재접속해 해당 명령을 다시 수행하므로 별도의 예외 처리가 필요 없다. 별다른 사유가 없다면 Curator를 사용하는 것을 권장한다. http://curator.incubator.apache.org/