Zookeeper Ensemble
여러 대의 Zookeeper 서버가 하나의 클러스터를 이루는 구조

왜 여러 대가 필요할까?
가용성
1대가 죽어도 나머지로 계속 서비스 가능
내결함성
장애 복구 및 안정성 확보
데이터 일관성
다수결 기반으로 동기화 보장
구성 요소
LEADER
쓰기 요청 처리, 모든 데이터 변경의 중심
Follower
읽기 요청 처리, Leader 의 변경사항 복제
Observer
읽기만 가능
몇 대 필요할까?
- 항상 홀수 개 권장
- 과반수가 살아있어야 작동
ex) 3대 중 2대, 5대 중 3대
동작 예시
- 클라이언트 요청
- 리더가 쓰기 요청 처리
- Follower 들과 ZAB 프로토콜을 통해 합의
- 과반수 동의 시, 쓰기 요청 커밋
- 클라이언트 응답
ZAB 프로토콜
Zookeeper 에서 데이터 일관성을 보장하기 위해 사용하는 합의 프로토콜
여러 Zookeeper 서버가 동일한 데이터를 가지도록 만드는 방법이 ZAB
즉, "하나의 리더가 모든 쓰기를 처리하고, 나머지 서버들과 동기화하면서 과반수 동의가 있을 때만 커밋하는 방식"
요약
- Zookeeper Ensemble = Zookeeper 서버들의 클러스터
- LEADER - FOLLOWER 구조
- 고가용성 + 데이터 일관성 보장
- kafka 같은 분산 시스템에서 중심축 역할