https://zookeeper.apache.org/doc/current/zookeeperOver.html

위 링크의 공식문서를 해석 및 요약해놓은 글입니다.

ZooKeeper는 구성 정보 유지, 이름 지정, 분산 동기화 제공 및 그룹 서비스 제공을 위한 중앙 집중식 서비스입니다. (자체적으로 분산 파일 시스템으로도 볼 수 있습니다.)

분산 애플리케이션에서 사용됩니다.

개요

주키퍼 소개

zookeeper 분산 애플리케이션을 위한 분산 조정 서비스

분산 애플리케이션을 위한 분산 오픈 소스 서비스

주키퍼의 구현 철학

간단한 기본 요소 집합 제공함으로써
→ 더 높은 수준의 서비스 구현하게 돕는다.
높은 수준 서비스 예시) 동기화, 구성유지관리 ,그룹 및 이름 지정

주키퍼의 특징

• 프로그래밍하기 쉽게 설계
• 파일시스템과 유사한 디렉토리 구조 데이터 모델 사용
• 자바 기반, 자바와 C에 대한 바인딩(API)

배경

코디네이션은 어렵다.특히 경쟁조건 교착상태 상황을 생각한다면.
→ 주키퍼는 분산 애플리케이션의 구현의 어려움을 줄여준다.

디자인 목표

주키퍼는 간단.

주키퍼 사용시, 분산 프로세스가 파일 시스템과 유사한 네임스페이스를 통해 서로 조정 가능 → 이 네임스페이스는 ZNODE라고하는 데이터로 구성. 파일이나 디렉토리와 유사. 주키퍼의 데이터는 메모리에 보관. 따라서, 빠르다

주키퍼의 구현은 고성능, 고가용성, 엄견한 순서의 액세스에 중점

1. 고성능 : 대규모 분산 시스템에서 사용가능함 의미
2. 고가용성: 단일 실패 지점을 방지
3. 엄격한 순서: 정교한 동기화 프리미티브 구현가능

주키퍼는 복제된다.

주키퍼 자체도 앙상블이라는 호스트 집합을 통해 복제됨

• 주키퍼를 구성하는 서버들은 모두 서로에 대해 알아야한다.
• 다음을 유지 관리
  1. 영구 저장소의 트랜잭션 로그 및 스냅샷
  2. 메모리 내 상태 이미지
• 주키퍼 그룹의 과반수의 서버가 살아있다면 주키퍼 서비스 정상작동

주키퍼는 순서 중시.

• 각 업데이트에 순서 스탬프 찍는다 ← 모든 주키퍼 트랜잭션의 순서를 반영하는 번호로
• 이 순서를 바탕으로 더 높은 수준의 추상화(동기화같은) 구현 가능

주키퍼는 빠르다

• 특히 읽기 중심 워크로드에서 빠르다. 읽기 쓰기 10:1 비율에서 제일 빠르다

데이터 모델 및 계층적 네임스페이스

주키퍼의 네임스페이스는 파일시스템의 네이스페이스와 유사

모든 노드(ZNODE, 주키퍼의 데이터 모델)를 경로로 식별

• 주키퍼의 계층적 네임스페이스

노드 및 임시 노드

ZNODE 특징

• ZNode는 파일과 디렉토리를 합친 느낌
  • 파일적) 자체적으로 데이터 저장( 작은 크기 바이트~킬로바이트단위)
  • 디렉토리적) 자식 노드를 가질 수 있음
• Znode는 데이터 변경, ACL 변경 및 타임스탬프에 대한 버전 번호를 포함하는 통계 구조를 유지 → 캐시 검증 및 조정된 업데이트를 허용
  • ex) 클라이언트 데이터 검색할 때 데이터 버전도 수신
• ZNODE 데이터 읽기 쓰기는 원자적(1 or 0), 각 노드에는 ACL(접근제어목록, 권한목록)이 있다.
  • 읽기: znode와 관련된 모든 데이터 가져오기
  • 쓰기 : 모든 데이터 대체
• 임시 znode 역시 존재해서, 세션이 활성화된동안에만 존재. 세션이 끝나면 삭제

조건부 업데이트 및 감시

watch(감시) 컨셉 지원.

1. znode에 watch 설정
2. znode 변경시 watch 트리거되고 제거
3. 트리거 되면 클라이언트는 znode가 변경되었음을 알리는 패킷 수신

( 위의 세션에 따른 임신znode와 결합되어 세션이 종료되면 클라이언트에게 트리거를 보낼 수 있다. → 세션에 따른 트리거가 가능해진다. )

(하둡의 예시, 네임노드 세션 종료시 임시 노드 삭제 후 워치 정책에 따라 워치 트리거로 클라이언트에 패킷 전송
→ 장애극복 조치 트리거
⇒ 네임노드 삭제에 따른 자동장애극복조치 구성됨)

주키퍼가 보장하는 것

• 순차적 일관성
  • 클라이언트의 업데이트는 전송 순서대로 유지
• 원자성
  • 업데이트가 성공 혹은 실패. 부분 결과 x
• 단일 시스템 이미지
  • 클라이언트는 주키퍼 그룹의 어느 서버에 연결되어 있어도 동일한 서비스
• 안정성
  • 업데이터 적용되면 업데이트 유지. 클라이언트가 덮어쓰기전까지
• 적시성
  • 클라이언트에게 최신 상태의 시스템 제공

간단한 API

디자인 목표 중 하나나느 간단한 프로그래밍 인터페이스 제공

다음 작업만 제공

• create
• delete
• exists
• get data : 노드에서 데이터를 읽기
• set data : 노드에 데이터 쓰기
• get children
• sync : 데이터가 전파될 때까지 기다린다.

구현

상위 수준 구성 요소

request processor 제외한 다른 구성요소를 복제 ex 데이터베이스

복제된 데이터베이스

• 전체 데이터 트리 포함하는 인메모리 데이터베이스
• 업데이트는 복구를 위해 디스크에 기록
• 쓰기는 메모리 내 데이터베이스에 적용 되기 전에 디스크에 직렬화
• 주키퍼의 업데이트? by chatgpt 는 ZooKeeper가 데이터를 안전하게 보존하기 위해 내부적으로 사용하는 메커니즘을 설명합니다.

  ZooKeeper의 데이터 기록 방식:

  1. 트랜잭션 로그: ZooKeeper는 모든 데이터 변경(업데이트)을 디스크에 기록하는 트랜잭션 로그를 사용합니다. 이 로그는 ZooKeeper 서버의 안정성과 데이터 일관성을 보장하는 중요한 역할을 합니다. 트랜잭션 로그에 기록된 데이터는 서버 재시작 후에도 복구될 수 있어 데이터의 영속성을 보장합니다.

  2. 스냅샷: 일정 시간이 지나거나 일정 수의 트랜잭션이 처리된 후, ZooKeeper는 현재의 전체 데이터 상태를 스냅샷으로 디스크에 저장합니다. 스냅샷은 시스템의 복구 시간을 단축시키고, 오래된 트랜잭션 로그를 정리하는 데 도움을 줍니다.

  3. 복구 메커니즘: 시스템 장애가 발생했을 때, ZooKeeper는 디스크에 저장된 가장 최근 스냅샷과 트랜잭션 로그를 사용하여 데이터를 복구합니다. 이 과정은 데이터의 일관성과 무결성을 유지하는 데 필수적입니다.

     ZooKeeper의 이러한 데이터 기록 방식은 분산 환경에서 데이터의 안전성을 확보하고, 여러 클라이언트 간의 데이터 동기화 상태를 유지하는 데 중요한 역할을 합니다. 데이터를 디스크에 기록하는 것은, 데이터가 손실되지 않고 장애 상황에서도 복구될 수 있도록 하는 핵심적인 방법입니다.

클라이언트의 요청

• 하나의 서버에 연결
• 읽기 요청 : 데이터베이스의 로컬 복제본에서 처리
• 쓰기 요청 : agreement(동의 처리) 프로토콜에 의해 처리

동의 처리 프로토콜

• 모든 쓰기 요청은 리더(leader)라 하는 단일 서버로 전달
• 팔로워라 불리는 나머지 서버는 리더러부터 메시지 제안을 받고 메시지 전달에 동의
• 메시징 레이어가 리더 팔로워의 교체 및 동기화 담당
• 메시징 레이어? 주키퍼 구성요소 중 하나 역할
  1. 리더 선출
  2. 메시지 제안 및 동의 처리
  3. 팔로워 동기화
  4. 장애 복구

원자적 메시징 프로토컬

• 로컬 복제본이 분기되지 않도록 보장
• 쓰기 요청을 받으면 리더가 이를 트랜잭션으로 변환