눈누난나

배경

• 하둡의 서브 프로젝트중의 하나로 탄생했다.
• 대용량 분산 처리 애플리케이션인 하둡은 중앙에서 분산 애플리케이션을 관리하는 코디네이션 애플리케이션이 필요했기 때문에 서브 프로젝트로 주키퍼 개발을 진행했었다.
• 2011년 1월 하둡 서브 프로젝트 → 아파치의 탑 레벨 프로젝트로 승격한다. (wow)
• storm, hbase, NiFi 등 많은 애플리케이션에서 사용중이다.

소개

• 구성 정보를 유지 관리하고 이름을 지정하여 분산 동기화를 제공하고 그룹 서비스를 제공하는 중앙 집중식 서비스
  • 분산 코디네이터
• 분산 시스템을 구성할 때 고려해야 할 사항
  • 네트워크의 신뢰성
  • 지연
  • 대역폭
  • 안정성
  • 토폴로지
  • 전송 비용
  • 네트워크 유형
• 분산 서버들 간의 정보 공유, 동기화 분산 서버들의 상태 확인 또한 필요하다.
• 역할
  • 그룹 멤버십
  • 잠금 제어
  • 구독/배포
  • 리더 선정
  • 동기화

카프카를 위한 주키퍼

데이터 모델

• 데이터를 디렉토리 구조로 저장하고, 데이터가 변경되면 클라이언트에게 어떤 노드가 변경되었는지 콜백을 통해서 알려준다.
• 클러스터 구성원 간의 데이터 공유가 가능하다(중앙화된 분산 코디네이터 클러스터).
• 데이터 스토리지(영속/임시 데이터), 클러스터 멤버십 관리를 통한 데이터 변경 통지(watch), 마스터 및 분산 락 등에 활용되는 시퀀스 노드 등을 제공한다.

노드

• persistent(영속) node
  • 한번 저장되고 나면 세션이 종료되어도 삭제되지 않고 유지되는 노드
  • 명시적으로 삭제하지 않는 한 해당 데이터는 삭제 및 변경되지 않는다.
• ephemeral(임시) node
  • 특정 노드를 생성한 세션이 유효한 동안 데이터가 유효한 노드
  • 주키퍼 서버에 접속한 클라이언트가 특정 노드를 emphermeral node로 생성했다면 세션이 끊어질 때 해당 노드는 자동으로 삭제된다.
  • 클라이언트가 동작하는지의 여부를 쉽게 판단 가능하다.
• sequence(순서) node
  • 노드 생성 시 sequence number가 자동으로 붙는 노드
  • 이 기능을 활용하여 분산 락 등을 구현할 수 있다

Watcher

• 주키퍼 클라이언트가 특정 znode에 watch를 걸어놓을 경우 해당 znode가 변경되었을 때 클라이언트로 콜백 호출을 날려 해당 클라이언트가 변경됨을 알 수 있다.

znode

• 주키퍼가 제공해주는 파일시스템에 저장되는 파일 하나를 znode라고 한다.
• unix의 파일시스템처럼 node간에 hierarchy namespace를 가진다.
• /(슬래시)를 사용
• 기존 파일 시스템과 다르게 주키퍼는 file과 directory의 개념이 없어 znode하나만 쓰인다.

보통 zookeeper는 분산 작업을 제어하기 위한 트리 형태의 데이터 저장소로 kafka broker를 관리하는 용도로 많이 사용한다.

하지만 이런 기능 외에도 semaphore를 관리하는 서버의 용도로도 사용할 수 있다.

예제는 다음과 같다.

val zookeeperClient: CuratorFramework = CuratorFrameworkFactory.newClient(s"${conf.host}:${conf.port}", new ExponentialBackoffRetry(1000, 3))
client.start()

val maxSemaphoreNum = 5 // 5개 까지 허용
val semaphore: InterProcessSemaphoreV2 = new InterProcessSemaphoreV2(zookeeperClient, "/my/semaphore/directory", ${maxSemaphoreNum})

val lease: Lease = semaphore.acquire()

... // semaphore 획득 후 수행할 task

semaphore.returnLease(lease)
zookeeperClient.close()