Zookeeper Architecture

Apache hadoop 의 Zookeeper Architecture 공식 문서를 번역한 게시글이다.

 

https://zookeeper.apache.org/doc/r3.5.1-alpha/zookeeperOver.html

ZooKeeper

 

 

Zookeeper : 분산 애플리케이션을 위한 분산 Coordination 서비스

Zookerper는 분산 application을 위한 분산 및 coordination 서비스인 오픈소스이다. Zookeeper는 분산 application이 동기화, configuration 유지보수, 그룹 및 이름 지정을 위한 더 높은 수준의 서비스를 구현하기 위해 구축할 수 있는 간단한 기본요소 집합을 보여준다. 프로그램하기 쉽게 설계되어 있으며, 파일 시스템의 친숙한 트리 구조를 본딴 데이터 모델을 사용한다. Zookeeper는 자바로 실행되고, Java와 C 둘다를 위한 binding도 가지고 있다.

Coordination 서비스는 바로잡기 어렵다고 악명높다. 특히 오류가 발생하기 쉬운데 예를 들면 race conditions 과 deadlock 이다. Zookeeper의 동기는 처음부터 coordination 서비스 구현의 책임을 분산 application에서 덜어주기 위함이다.

Design Goals

Zookeeper는 단순하다.

Zookeeper는 표준 파일 시스템과 유사한 공유 계층 네임스페이스를 통해 분산 프로세스를 조정한다. 네임스페이스는 data registers 로 구성된다 - Zookeeper 표현으로 znodes 라 불린다. 그리고 파일과 디렉터리들과 유사하다. 저장소를 위해 설계된 전형적인 파일 시스템과 달리, Zookeeper 데이터는 in-memory에서 유지되고 이는 Zookeeper가 높은 처리량과 낮은 지연시간을 달성할 수 있다.

ZooKeeper 안정성이 높다.

조정하는 분산 프로세스 처럼, Zookeeper는 앙상블이라고 하는 일련의 호스트들을 통해 복제하기 위한 것이다.

Zookeeper 서비스를 구성하는 서버들은 각자 서로에 대해 알아야한다. 영구 저장소 안의 트랜잭션로그와 스냅샷을 따라서 그들은 상태의 인메모리 이미지를 유지한다. 다수의 서버가 사용가능하는 한, Zookeeper 서비스도 사용 가능할 것이다.

클라이언트는 단일 Zookeeper 서버에 연결한다. 클라이언트는 요청 보내거나, 요청 받거나, 이벤트 받거나 heart beats를 전송하는 TCP 연결을 유지한다. 만약 서버에 연결한 TCP 연결이 끊어질 경우, 클라이언트는 다른 서버에 연결할 것이다.

ZooKeeper 는 체계적이다.

ZooKeeper는 모든 ZooKeeper 트랜잭션의 순서를 반영하는 번호로 각 업데이트를 스탬프로 표시합니다. Subsequent operations 는 동기화 기본 항목과 같은 상위 수준의 추상화에 사용할 수 있습니다.

ZooKeeper 는 빠르다.

워크로드에서 읽기가 특히 빠르다. Zookeeper 애플리케이션은 수천개의 머신위에서 실행되고, 쓰기보다 읽기가 더 성능이 좋다. 읽기/쓰기 비율은 약 10:1이다.

데이터 모델과 계층 구조 네임스페이스

Zookeeper에 의해 제공되는 네임스페이스 표준 파일 시스템과 와 같다. 이름은 (/)로 구분되는 경로 요소의 시퀀스이다. Zookeeper의 네임스페이스의 모든 노드는 경로에 의해 구분된다.

Nodes 와 ephemeral nodes

표준 파일 시스템과 달리, Zookeeper 네임스페이스에서 각 노드는 자식 뿐만이 아니라 관련된 데이터를 가지고 있다. 파일도 디렉터리가 되도록 허용하는 파일 시스템을 갖는 것과 같다. ( Zookeeper는 조정 데이터 저장 하도록 설계되어있다. : 상태 정보, configuration, 위치 정보 등. 따라서 각 노드에 저장된 데이터는 대케 바이트 ~ 킬로바이트 범위로 작다. ) 우리는 znode라는 용어를 사용해 Zookeeper 데이터 노드에 대해 이야기 하고 있음을 명확히 한다.

Znode는 캐시 유효성 검사 및 조정된 업데이트를 허용하려면, 데이터 변경, ACL 변경, 타임스팸프를 위한 버전 번호를 포함하는 상태 구조를 유지한다. znode의 데이터는 매번 변경되며, 버전 번호는 증가한다. 예를 들면, 클라이언트가 데이터를 검색할 때 마다 데이터의 버전도 수신된다.

네임스페이스안의 각 znode에 저장된 데이터는 원자적으로 읽고 쓴다. 읽기는 znode와 관련된 모든 데이터 바이트를 가져오고 모든데이터를 대체하여 쓴다. 각 노드는 누가 할 수 있는지의 제한에 대한 ACL를 가지고 있다.

또한 Zookeeper는 ephemeral nodes의 개념을 가지고 있다. znode는 znode를 생성한 세션이 활성화 되어있는 한 존재한다. 세션이 종료되어 znode가 삭제된다. Ephemeral nodes가 다시 구현을 원할 때 유용하다.

조건 업데이트 및 감시

Zookeeper는 감시의 컨셉을 지원한다. 클라이언트들은 znode를 감시할 수 있다. znode가 변경될 때 감시는 촉발되거나 제거된다. 감시가 촉발됐을 때, 클라이언트는 znode가 변경되었음을 나타내는 패킷을 받는다. 그리고 만약 클라이언트와 zookeeper의 서버 중 하나와의 연결이 끊어졌을 때, 클라이언트는 로컬 알림을 받을 것이다.

Guarantees 보증

zookeeper는 매우 빠르고 간단하다. 그러나 그것의 동기화와 같은 목표는 복잡한 서비스 구축을 위한 기초가 되는 것 이기 때문에, 그것은 일련의 보증을 제공한다. 다음과 같다. :

• 순차적 일관성 - 클라이언트의 업데이트는 전송된 순서대로 적용된다.
• 원자성 - 업데이트는 성공 또는 실패이다. 부분 결과는 없다.
• 단일 시스템 이미지 - 클라리언트는 연결된 서비스에 관계없이 동일한 뷰를 볼 수 있다.
• 신뢰성 - 업데이트가 적용되면, 클라이언트가 업데이트를 덮어쓸 때까지 계속 유지된다.
• 적시성 - 시스템의 클라이언트 뷰는 특정 시간 범위 내에서 최신으로 보장된다.

Simple API

주키퍼의 설계 목표 중 하나는 아주 간편한 프로그래밍 인터페이스다. 결과적으로, 이런 operations들만 지원한다.

delete	deletes a node
exists	tests if a node exists at a location
get data	reads the data from a node
set data	writes data to a node
get children	retrieves a list of children of a node
sync	waits for data to be propagated

Implementation 구현

주키퍼 컴포넌트는 주키퍼 서비스의 높은 수준의 컴포넌트를 보여준다. 요청 프로세서의 예외 포함해서 주키퍼 서비스를 구성하는 각 서버는 각 컴포넌트의 자체 복사본을 복제한다.

복제된 데이터베이스는 전체 데이터 트리를 포함한 인메모리 데이터베이스다. 업데이트는 회복성을 위해 디스크에 기록하고 쓰기는 인메모리데이터베이스에 적용되기전에 디스크에 직렬화된다.

모든 주키퍼 서버는 클라이언트에게 제공한다. 클라이언트는 요청을 제출하기위해 정확하게 한 서버에 연결한다. 요청 읽기는 각 서버 데이터베이스의 로컬 복사본에서 제공된다. 서비스, 쓰기 요청 의 상태 변경에 대한 요청은 agreement protocol에 의해 진행된다.

agreement protocol 의 일부로 클라이언트의 모든 쓰기 요청은 리더로 불리는 단일 서버로 전달된다. 팔로워라 불리는 나머지 주키퍼 서버들은 리더로부터 메세지 제안서를 받고 메세지 전달에 동의한다. 메세지 계층은 실패에 대한 리더를 교체하고 리더와 팔로워를 동기화한다.

주키퍼는 custom atomic messaging protocol를 사용한다. 메세지 계층이 원자성 계층이므로, 주키퍼는 로컬 복사본이 갈라지지 않는 것을 보증할 수 있다. 리더가 쓰기 요청을 받을 때, 시스템 상태가 무엇인지를 계산하고 이 새로운 상태를 포확하는 트랜잭션으로 변환한다.

Uses 사용

주키퍼에 대한 프로그래밍 인터페이스는 매우 간단하다. 동기화 프리미티브, 오너쉽, 등과 같은 높은 order operations를 구현할 수 있다.

Performance 수행

주키퍼는 성능이 뛰어나게 설계되었다. 하지만 그럴까? 야후에서 주키퍼의 개발팀 결과는 가리킨다. 쓰기는 모든 서버의 상태를 동기화 시키는 것을 포함하기 때문에 읽기 수가 쓰기 수보다 더 많은 애플리케이션에서 특히 높은 성능을 발휘한다.

ZooKeeper Throughput as the Read-Write Ratio Varies 수치는 듀얼 2Ghz Xeon과 SATA 15K RPM drives위에서 실행한 3.2 릴리즈 버전의 주키퍼의 처리량이다. 하나의 드라이브는 전용 주키퍼 로그 장치로 사용된다. 스냅샷 OS 드라이브에 기록된다. 쓰기는 1K 쓰기를 요구하고, 읽기는 1K로 읽기를 요구한다. “서버“는 주키퍼의 앙상블의 크기를 표시하고, 서버의 개수는 서비스로 구성된다. 대략 30개 다른서버들은 클라이언트를 실험하는데 사용됐다. 주키퍼 앙상블은 클라이언트에서 연결을 허용하지않은 리더들로 구성된다.

[Note]

3.1 버전과 비교하여 약 두배 3.2버전의 읽기 쓰기 성능은 향상됐다. 벤치마크는 신뢰할 수 있음을 나타낸다. Reliability in the Presence of Errors deployment가 다양한 장애에 대응하는 방법을 보여준다. 그림에 표시된 이벤트는 다음과 같다.

1. Failure and recovery of a follower
2. Failure and recovery of a different follower
3. Failure of the leader
4. Failure and recovery of two followers
5. Failure of another leader

Reliability 신뢰성

보여주기위해 우리가 실행하는 7개의 머신으로 구성된 주키퍼 서비스에 실패하여 시간 경과된 시스템 동작을 주입했다. 우리는 이전처럼 같은 saturation benchmark 실행하는데 우리는 이때 항상 우리가 예상한 쿼크로드의 적은 비율로 30% 쓰기 퍼센테이지를 유지한다.

이 그래프에서 중요한 몇몇 관측치가 있다. 첫번째로, 팔로워들이 실패해서 빠르게 회복한다면, 주키퍼는 실패에도 불구하고 높은 처리량을 유지하는 것이 가능하다. 하지만 더 중요한 것은, 리더 선정 알고리즘은 시스템이 빨리 복구될 수 있도록 처리량이 크게 떨어지는거로부터 막는다. 우리의 관측치에서, 주키퍼는 200ms 미만 소요하어 새로운 리더를 선정한다. 세번째로, 팔로워가 회복되는거로 주키퍼는 그들이 프로세싱 요구를 시작할 때 처리량을 다시 높일 수 있다.

---

Node의 종류는 한번 생성될 떼 정해지며 후에 변경되지 않는다.

• Persistent(영속) Node : 클라이언트의 세션에 묶여있지않아 클라이언트의 연결이 끊어져도 삭제되지 않는다.
• Ephemeral(임시) Node : 클라이언트가 연결을 끊는 경우, 주키퍼가 삭제한다. 어떠한 znode도 자식으로 가질 수 없다.
• Sequence(순차) Node : znode 이름 뒤에 순차 번호를 부여한 것이다.

 

https://kr.cloudera.com/products/open-source/apache-hadoop/apache-zookeeper.html

Apache ZooKeeper | Cloudera

 

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