2 Zookeeper 상세 기능

2.1 Data Model

2.1.1 Namespace Structure

ZooKeeper가 제공하는 네임스페이스는 표준 파일 시스템의 형식과 비슷하다. 이름은 슬래시(/)로 구분된 경로로 표현한다. ZooKeeper 네임스페이스의 모든 znode(데이터)는 경로로 식별된다.

ZooKeeper's Hierarchical Namespace

image source : https://rohitbankar.medium.com/zookeeper-what-is-it-df7e9bcba9f1

표준 파일 시스템과 Zookeeper Namespace 가 다른 점은 ZooKeeper 네임스페이스의 각 노드(znode)는 하위 노드뿐만 아니라 해당 노드와 연결된 데이터를 가질 수 있다. 파일 자신이 디렉터리가 될 수 있는 파일 시스템을 갖는 다고 이해하면 쉽다.

• 이런 특징 때문에, 하나의 znode에 저장하는 데이터의 크기는 수 bytes ~ 수 KB 이하로 유지하는 것을 권장한다.
  • 이 때문에 주로 설정정보, 적은 수의 metadata 정보등의 빠른 동기화 용도 위주로 사용된다.

---

Q. 다음 사례 중 Zookeeper 를 잘못 사용하는 경우는?

1. 분산 시스템에서 runtime에 변경 가능한 설정 정보
2. 분산시스템을 구성하는 노드의 IP, port 번호
3. 분산시스템에 연결된 클라이언트의 상태 정보 e.g. latest commit id
4. 분산 데이터베이스에 저장된 user 테이블의 PK리스트 e.g. user_id in user table

1. 분산 시스템에서 runtime에 변경 가능한 설정 정보
   → 적절함

   • ZooKeeper는 공통 설정 값(config)이나 플래그 같은 정보를 노드 간에 공유하기에 적합
   • 클러스터 전체에 걸쳐 실시간으로 변경 가능한 설정 정보 관리에 자주 사용됨
   • 예: feature toggle, 리소스 제한 값

2. 분산시스템을 구성하는 노드의 IP, port 번호
   → 적절함

   • ZooKeeper는 서비스 디스커버리 역할을 할 수 있음
   • 노드들의 메타데이터 (IP, 포트, 상태 등) 를 등록하고 관리하는 데 활용 가능
   • 예: Kafka broker 리스트 관리

3. 분산시스템에 연결된 클라이언트의 상태 정보 (e.g. latest commit id)
   → 적절함

   • ephemeral node를 사용해 연결된 클라이언트 상태(세션 등)를 관리 가능
   • 예: leader election, 세션 유지, heartbeat 정보 기록

4. 분산 데이터베이스에 저장된 user 테이블의 PK 리스트 (예: user_id in user table)
   → 부적절 — 정답

   • ZooKeeper는 메타데이터나 소량의 상태 정보 관리용이며,
     대량의 실제 애플리케이션 데이터 (예: 유저 ID 수십만 건)를 저장하는 용도가 아님
   • ZooKeeper는 모든 노드가 전체 데이터를 복제하므로, 대용량 데이터를 저장하면 심각한 성능 저하 발생
   • 데이터 스토리지 용도가 아님

2.1.2 Versioning

Znode는 캐시 유효성 검사 및 동기화된(coordinated) 업데이트를 위해 버전 번호(version number)를 가지고 있다.

이 버전 번호는 다음과 같은 변경이 발생할 때마다 증가한다:

• 데이터 변경
• ACL(Access Control List, 접근 권한, 액세스 제어 목록) 변경

클라이언트가 Znode의 데이터를 조회할 때는 해당 버전 번호도 함께 전달된다.
이를 통해 클라이언트는 데이터가 중간에 변경되었는지 확인하거나,
조건부 갱신(예: "내가 본 이후로 바뀌지 않았다면 업데이트")을 안전하게 수행할 수 있다.

2.1.3 Atomic Operation

ZooKeeper의 네임스페이스를 구성하는 각 znode는 atomic한(read/write) 데이터 접근을 지원한다.

Read 연산은 해당 znode에 연결된 전체 데이터를 한 번에 가져오고,

Write 연산은 기존 데이터를 통째로 덮어쓴다.
(부분 수정은 불가능하며, 항상 전체 단위로 처리됨)

또한, 각 znode에는 접근 권한을 제한하는 ACL(Access Control List)이 설정되어 있으며,
이를 통해 누가 어떤 작업(읽기, 쓰기, 삭제 등)을 수행할 수 있는지 제어할 수 있다.

2.1.4 Ephemeral nodes

ZooKeeper는 일시적인 노드의 개념을 가지고 있다. 이 Ephemeral znode는 znode를 생성한 세션이 활성화되어 있는 동안만 존재한다. 세션이 종료되면 znode가 삭제된다.

2.2 Conditional Update & watch

클라이언트가 특정 znode에 watch를 설정하면, 해당 znode 또는 자식 노드에 변경(update)이 발생할 때 watch 이벤트가 발생(trigger)한다.
이때, 기본 동작에서는 watch가 한 번만 동작하고 자동으로 해제된다.

클라이언트는 ZooKeeper API를 통해 watch에 대한 콜백 함수(callback function)를 등록할 수 있으며,
이를 통해 변경 감지 시 원하는 작업을 수행할 수 있다.

단, ZooKeeper 3.6.0 버전부터는
watch가 트리거된 이후에도 계속 유지(persistent)될 수 있도록 설정할 수 있는 기능이 추가되었다.

2.3 Zookeeper 가 보장하는 내용

• Sequential Consistency : Updates from a client will be applied in the order that they were sent.
  • 먼저 보낸 업데이트가 나중에 적용되는 일은 없음
• Atomicity : Updates either succeed or fail. No partial results.
  • 중간 상태나 부분 적용은 없음
• Single System Image : A client will see the same view of the service regardless of the server that it connects to. i.e., a client will never see an older view of the system even if the client fails over to a different server with the same session.
  • 리더든 팔로워든 동일한 최신 데이터 보장
• Reliability : Once an update has been applied, it will persist from that time forward until a client overwrites the update.
  • 명시적으로 덮어쓰기 전까지 유지
• Timeliness : The clients view of the system is guaranteed to be up-to-date within a certain time bound.
  • 너무 오래된 데이터는 보지 않음

2.4 Simple API

Zookeeper 는 다음 API를 제공한다.

• create : creates a node at a location in the tree
• 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