[zookeeper] 쥬키퍼 overview (공식문서 정리)

ZOOKEEPER 는 왜 인스턴스가 여러개 올라갈까??

를 알아보기 위해 공부하기!!

 

Zookeeper: 분산된 어플리케이션들의 분산 코디네이터 서비스

zookeeper는 분산된 어플리케이션들에 사용되는 분산되어 있고, 오픈소스인 코디네이터로, 분산된 어플리케이션들이 동기화된 고레벨의 서비스, 구성 유지, 그룹, 네이밍을 할 수 있도록 한다. 프로그래밍하기 쉽게 되어 있으며 친숙한 트리구조의 파일시스템의 데이터 모델을 사용한다. zookeeper의 목적은 분산 어플리케이션들의 코디네이터 서비스 도입 책임을 완화시키는 것에 있다.

 

예를 들어 여러개 노드에서 프로세스를 하는 분산된 어플리케이션들은 부분적으로 실패할 가능성을 고려해야 하는데, 이러한 실패를 효율적으로 처리하기 위해서 필요하다.

 

Design Goals

• 간단함

zookeeper는 분산된 프로세스들이 쉐어되고 있는 계층적 네임스페이스를 통해서 서로(분산된 프로세스들)를 조정하도록 한다.

namespace는 znode라고 불리는 data register를 가지는데 이것은 파일과 디렉티와 비슷하다. 차이점이라면 파일시스템은 스토리지를 다루는데 반해 zookeeper는 인메모리(in-memory) 이며, 이 특성으로 인해 높은 처리량과 저지연성을 갖는다.

그렇기 때문에 single point of failure을 방지할 수 있다.

• 복제됨

zookeeper가 조정하는 분산 프로세스들처럼 zookeper도 ensamble이라는 호스트들에 복제된다

ensamble은 여러개 노드로 이루어진 클러스터를 이야기한다. 이는 replicated mode로 수행되어야 한다.

여러개의 서버들은 zookeeper services들을 잘 알고 있고, persistent store에 있는 트랜잭션(transaction) 로그와 스냅샷 상태 그리고 인메모리 이미지를 관리한다. 과반수의 서버가 가능하다면 zookeeper는 가용(available)하다.

 

• 순서가 있음

zookeper의 transaction의 순서가 반영되어 모든 업데이트를 쌓아간다. 

• 빠름

write보다 read에서 10배 정도 더 빠름

 

 

Data model and the hierarchical namespace

name은 slash(/)로 구분되고 네임스페이스는 path로 구분됨 (절대 경로만 가능)

네임스페이스 안에 노드가 있음

 

Nodes and ephemeral nodes

zookeeper 네임스페이스 안의 node들은 연관된 데이터를 가질 수 있다(ex children). 그래서 상태 정보, 구성정보, 위치 정보 등의 코디네이션 데이터를 가지고 있다.(또한 그러기 위해 디자인 되었다)

각 znode에 저장된 data는 atomical(더 이상 나누어 질 수 없는?? , ;;;나의 해석)으로 읽어진고 써진다. 연관된 데이터들을 모두 읽어와서 대체한다. 각각의 node는 ACL(access contol list)를 가지고 있고 누가 무엇을 할 수 있는제 제한한다.

 

 

Condirional updates and watches

zookeeper는 cache validation과 코디네이트된 업데이트를 위해서, 데이터가 변경되거나 ACL 변경 그리고 타임스탬프 등의 version을  가지는 stat 구조를 관리한다. watch과 트리거 될 때 클라이언트는 znode가 변했다는 packet을 전송받는다. 클라이언트와의 연결이나 zookeeper서비스 중 하나가 고장나면 client는 local 알림을 받는다.

znode는 자신을 생성시킨 세션이 살아있을 때만 존재하고, 세션이 끝나면 삭제된다.

 

 

Implementation

zookeeper는 다음과 같이 구성되어 있다.

각각의 서버들에서 zookeeper 서비스는 자신을 복제하는데, request processor는 예외다.

인메모리 DB안의 복제된 DB는 전체 데이터 트리를 가지고 있다. 변경사항은 복구를 위해 디스크에 로깅되며 인메모리DB에 반영되기전 디스크에 기록된다.

 

모든 zookeeper 서버는 client에 서비스를하고, 클라이언트틑 무조건 단 하나의 서버에만 요청을한다. Read 요청은 로컬의 각 서버DB의 replica에서 서비스 된다.요청은 서비스의 상태를 변경하고, 요청을 저장하고 argreement protocol 에 의하여 처리된다.

 

agreement protocol은 모든 write요청을 특정 서버(leader)에게로 넘기고, 나머지 서버들(followers)이 리더 서버로부터 message proposal을 받게되며, message delivery에 따라 의견을 낸다.

이 메시지 layer가 장애시 leader를 관리하기도 하며, leader와 follower의  sync를 맞춘다.

 

zookeeper는 custom atomic messaging protocol을 사용하며, message layer가 atomic하기 때문에 zookeeper는 local의 replica까리 달라지지 않도록 보장한다. 리더 서버가 write 요청을 받았을 때, zookeeper는 어떤 시스템 상태가 언제 write를 적용하고 이것을 transaction 에 반영하는지 계산한다. 

 

그럼 노드가 일반적으로 홀수인 이유는??

1. ensamble에서는 agreement protocol에 의하여 과반수의 의견을 따르게 됨

2. 짝수 n으로 노드를 구성하는경우  (n/2)+1개의 쿼럼이 필요하지만, 홀수 o로 노드를 구성하는 경우 (n/2) + 1/2개의 쿼럼이 필요 => 비례적으로 짝수에서 노드가 더 많이 필요

 

 

 

공식문서: 

https://zookeeper.apache.org/doc/r3.8.0/zookeeperOver.html