zookeeper는 분산 코디네이션 서비스를 제공하는 오픈소스 프로젝트이다.
직접 어플리케이션 작업을 조율하지 않고 조율하는 것을 쉽게 개발할 수 있도록 도와주는 도구이다.
API를 이용해 동기화나 마스터 선출 등의 작업을 구현할 수 있어서 간편하다.
각 애플리케이션의 정보를 중앙 집중화하고 구성관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공한다.
주키퍼의 데이터는 메모리에 저장되고, 영구 저장소로 스냅샷을 저장합니다.
분산 코디네이션 서비스
분산 시스템에서 시스템 간의 정보를 공유하고 상태 체크, 서버들 간의 동기화를 위한 락 등의 처리를 해주는 서비스를 분산 코디네이션 서비스라고 합니다.
주키퍼는 분산 시스템의 일부분이기 때문에 동작이 멈춘다면 분산 시스템이 멈출수도 있습니다.
그래서 안정성을 확보하기 위해 클러스터로 구축합니다.
이 클러스터는 반드시 홀수로 구축해야합니다. 왜냐하면 홀수여야 과반수 상황이 생기기 때문에 만약의 경우에 과반수 이상의 데이터를 기준으로 일관성을 맞출 수 있습니다.
서버 여러 대를 앙상블(클러스터)로 구성하고, 분산 어플리케이션들이 각각 클라이언트가 되어 주키퍼 서버들과 커넥션을 맺은 후 상태 정보 등을 주고 받는다.
주키퍼 특징
1. 단순하다
사용자는 몇가지 추상화된 기능을 통해서 분산처리를 위한 주키퍼 파일시스템을 활용할 수 있다.
2. 기능이 풍부하다
대규모 데이터 구조와 프로토콜의 코디네이션에 사용되는 구성요소를 제공한다.
3. 고가용성을 제공한다
다수의 머신에서 실행되며 고가용성을 보장하도록 설계되었다.
4. 느슨하게 연결된 상호작용을 할 수 있도록 해준다.
주키퍼가 동작할 때 참여자들은 서로에 대해 몰라도 상관 없다.
5. 오픈소스 라이브러리다
일반적인 코디네이션 패턴에 대한 구현체와 구현 방법을 오픈소스로 제공한다. 공통 프로토콜을 직접 개발(보통 제대로 하기 어렵다)하는 부담에서 벗어날 수 있다.
구성 과정
1. Request Processor
Write 요청 처리
2. Zab(Zookeeper Atomic Broadcast Protocol)
Request Processor에서 처리한 요청을 트랜잭션을 생성하여 모든 서버에게 전파한다. Leader-Propose -> Follower-Accept -> leader-Commit 단계로 구성된다.
3. In-memory DB
Znode의 정보가 저장되며, 로컬 파일시스템에 Replication을 구성할 수 있다.
주키퍼 데이터 모델 znode
상태 정보들은 주키퍼의 지노드(znode)라고 불리는 곳에 Key-Value 형태로 저장하며, 지노드에 저장된 것을 이용하여 분산 어플리케이션들은 서로 데이터를 주고받게 된다.
지노드(znode)는 우리가 알고 있는 일반적인 디렉토리와 비슷한 형태로서 자식노드를 가지고 있는 계층형 구조로 구성되어 있다.
노드의 종류는 다음입니다.
- persistent
영구 저장소- Ephemeral
Client가 종료되면 사라진다.- Sequence
일반 Node로 생성 시 뒤에 숫자가 붙음.
Watcher
ZooKeeper는 znode에 변화를 감지할 수 있는 Watcher를 클라이언트가 설정할 수 있도록 한다. Watcher는 자신이 감시하고 있는 znode에 수정이 발생하였을 때, 클라이언트로 callback 호출을 전송하는 알림 기능을 제공한다.
Watcher를 통해 znode에 변경사항이 기록되는데 그 과정은 다음과 같습니다.
1. 주키퍼를 사용하는 클라이언트 A가 ZooKeeper에게 Watcher 등록을 요청한다.
2. 주키퍼를 사용하는 클라이언트 B가 ZooKeeper에게 ZNode를 수정한다고 말한다.
3. 클라이언트 A에게 변경 이벤트를 전달한다.
Quorum
Leader가 새로운 트랜잭션을 수행하기 위해서는 자신을 포함하여 과반수 이상의 서버의 합의를 얻어야 한다. 과반수의 합의를 위해 필요한 서버들을 Quorum이라고 한다. Ensemble을 구성하는 서버의 수가 5개라면, Quorum은 3개의 서버로 구성이 된다.
트랜잭션 처리
- Leader에게 Request 전달
새로운 트랜잭션 요청이 Follower에게 도착하였을 경우, Follower는 Leader에게 요청을 전달한다.- Propose
Propose는 Leader가 Quorum을 구성하는 서버들에게 트랙잭션을 수행해도 되는지 여부를 요청하는 과정을 의미한다.- Ack
Quorum을 구성하는 서버들은 Leader로 부터 Propose 요청을 받으면, 트랙잭션을 수행해도 된다는 Ack 응답을 Leader에게 전송한다.- Commit
모든 Quorum으로 부터 Ack를 받으면, Leader는 트랙잭션을 처리하라는 Commit 명령을 broadcast 형태로 모든 Follower에 전파한다. ZooKeeper에서는 Commit 명령을 전달할 때, ZAB(ZooKeeper Atomic Broadcast) 알고리즘을 사용한다. Atomic Broadcast는 broacast 방식 중 하나로, 멀티 프로세스 시스템에서 모든 프로세스에게 동일한 순서로 메시지가 전달된다는 것을 의미한다.
대표적 예시
이러한 주키퍼는 쓰는 대표적인 툴이 카프카입니다.
카프카에서 주키퍼는 서버의 상태를 감지하기 위해 사용되며 새로운 토픽이 생성되었을 때, 토픽의 생성과 소비에 대한 상태를 저장한다.
주키퍼와 카프카는 대규모 환경에서는 다른 서버에 두는 편이 좋다. 주키퍼 앙상블은 홀수로 구성되어 과반수 이상이 장애가 발생하면 중단되고, 카프카는 그렇지 않아도 되기 때문에 다른 서버에 두는 것을 권장한다.
