[1. Zookeeper 란?]
분산 어플리케이션 제어 및 관리를 위한 코디네이션 어플리케이션
- 분산 어플리케이션의 상태를 관리한다.
- 분산 어플리케이션 간 상태를 공유하게 할 수 있다.
- 클러스터로 구성(보통 홀수 개의 주키퍼) 하여 고가용성을 제공한다.
- 클러스터 구성 시 Leader - Follower 역할을 갖게 된다.
[2. 주요 사용용도]
- 설정 관리
- 클러스터 관리
- Leader 선출
- 동기화 서비스
[3. znode]
주키퍼는 내부적으로 데이터를 znode 라는 노드에 계층적 트리 형태로 관리한다.
- 일반적인 리눅스 파일 시스템 형태라고 생각하면 된다.
- 절대경로만 지원한다.
- 원자적인 데이터 접근을 보장한다.
- Key - Value 형태이다.
- 최대 1MB 의 데이터(=Value) 를 저장 할 수 있다.
znode 는 3가지 타입이 존재한다.
- Persistent znode (영속 노드)
=> 이 znode 를 만든 클라이언트가 주키퍼와 연결이 끊겨도, 주키퍼 서버에 남아있는다. - Ephemeral znode (임시 노드)
=> 이 znode 를 만든 클라이언트가 주키퍼와 연결이 끊기면, 주키퍼 서버에서 사라진다.
=> 이러한 특성으로 인해, 임시 노드는 자식 노드를 가질 수 없다.
=> 이 임시 노드의 key 에 대해서 하위 경로를 가질 수 없다. - Sequential znode (연속형 노드)
=>
[4. Quorum]
앙상블 : 실제 주키퍼 서버 개수, 클러스터에 참여한 서버 개수
쿼럼
- 데이터를 안전하게 저장했음을 보장하는 서버 개수
- 주키퍼 내 어떤 노드의 상태가 바뀌었을 때, 모든 서버 내 데이터를 일치 시키는 것이아니라
일단 일부 서버만 데이터를 일치시키고, 나머지 서버는 차후에 업데이트 한다(?) - 쿼럼을 잘못 정하면, 주키퍼 데이터 영속성을 보장하지 못한다.
- 쿼럼은 n/2 + 1 로 결정한다. (n 은 앙상블 개수)
=> n=3 이면 2
=> n=5 이면 3
[98. 주키퍼 세션]
NOT_CONNECTED -> CONNECTING -> CONNECTED -> CLOSED
한 서버와 연결을 유지하다가, 일정 시간이 지나면 다른 서버와 연결을 유지하고, ... 반복
- 한 서버와 연결을 계속 유지하지는 않는다.
ref)
[99. 주키퍼 상태 감시]
폴링 방식으로 주키퍼 내 특정 노드에 대한 감시를 하는 것은 권장하지 않는다.
특정 노드에 대한 watch 를 등록하면, 해당 노드 이벤트 발생 시, 신호를 받아 처리 할 수 있다.
단, one-shot 방식이므로 알림을 받은 후 에는 watch 를 다시 등록해야 한다.
알림을 받고 watch 를 다시 설정하는 도중, 노드 상태가 바뀔 경우,
새로운 watch 를 설정 할 때 주키퍼 API 를 통해 znode 상태를 확인한다.