주키퍼(Zookeeper)란

728x90

주키퍼란?

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

구글 번역기 >>

zooKeeper는 구성 정보 유지, 이름 지정, 분산 동기화 제공 및 그룹 서비스 제공을 위한 중앙 집중식 서비스입니다. 이러한 모든 종류의 서비스는 분산 응용 프로그램에서 어떤 형태로든 사용됩니다. 구현될 때마다 불가피한 버그와 경쟁 조건을 수정하는 데 많은 작업이 필요합니다. 이러한 종류의 서비스를 구현하는 것이 어렵기 때문에 애플리케이션은 일반적으로 처음에는 이러한 서비스에 인색하여 변화가 있을 때 부서지기 쉽고 관리하기 어렵습니다. 올바르게 수행된 경우에도 이러한 서비스를 다르게 구현하면 응용 프로그램을 배포할 때 관리가 복잡해집니다.

간단하게 요약하자면 분산시스템 코디네이션(= 조율) 서비스를 제공하는 오픈소스 프로젝트이다!

구체적으로 어떤 일을 하는가?

프로젝트로 직접 어플리케이션 작업을 조율하는 것을 쉽게 개발할 수 있도록 도와준다.
API를 이용해 동기화나 마스터 선출(?) 등의 작업을 쉽게 구현할 수 있게 도와줌.

일반적으로 N개의 주키퍼 서버의 집합인 Ensemble로 구성되고 이 Ensemble은 leader-follower 구조를 사용한다. Leader가 Follwer에게 동기화를 위한 명령을 내린다.

각 애플리케이션의 정보를 중앙 집중화하고 구성관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공한다.
주키퍼의 데이터는 메모리에 저장되고, 영구 저장소에 스냅샷을 저장한다.

분산 코디네이션 서비스란?

분산 시스템에서 시스템 간의 정보 공유, 상태 체크, 서버들 간의 동기화를 위한 락 등을 처리해주는 서비스

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

 

주키퍼는 분산 시스템의 일부분이기 때문에 동작을 멈춘다면 분산 시스템이 멈출 수도 있다. 그래서 안정성을 확보하기위해 클러스터구축한다. 클러스터는 홀수로 구축한다. 어떤 서버에 문제가 생겼을 경우 과반수 이상의 데이터를 기준으로 일관성을 맞추기 때문이다. 살아있는 노드가 과반수 이상이라면 지속적인 서비스를 제공 (ex. 주키퍼 클러스터를 3대로 구성했다면, 노드 1대만 죽은 경우에는 서비스가 가능하다 과반수인 2대가 죽어버리면 서비스가 불가)

여러대의 서버를 클러스터(= 앙상블)로 구성하고 분산 애플리케이션들이 각각 클라이언트가 되어 주키퍼 서버들과 커넥션을 맺은 후 상태 정보 등을 주고 받는다.

상태 정보들은 주키퍼의 지노드(znode)라고 불리는 곳에 Key-Value의 형태로 저장, 지노드에 저장된 것을 이용하여 분산 애플리케이션들은 서로 데이터를 주고받게 된다.

지노드는 일반적인 디렉토리와 비슷한 형태로서 자식 노드를 가지고있는 계층형 구조로 구성되어있다.

여기서 일반적으로 Server로 Zookeeper, Client로 Kafka로 구성하는 경우가 많은 듯하다.

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

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

 

노드 및 임시 노드

표준 파일 시스템과 달리 ZooKeeper 네임스페이스의 각 노드는 자식뿐만 아니라 연결된 데이터를 가질 수 있습니다. 파일이 디렉토리가 될 수 있는 파일 시스템을 갖는 것과 같다. (ZooKeeper는 조정 데이터(상태 정보, 구성, 위치 정보 등)를 저장하도록 설계되었으므로 각 노드에 저장되는 데이터는 일반적으로 바이트에서 킬로바이트 범위로 작다)

Znode는 캐시 유효성 검사 및 조정된 업데이트를 허용하기 위해 데이터 변경, 액세스 제어 목록(ACL) 변경 및 타임스탬프에 대한 버전 번호를 포함하는 상태 구조를 유지한다. znode의 데이터가 변경될 때마다 버전 번호가 증가한다. 예를 들어 클라이언트가 데이터를 검색할 때마다 데이터 버전도 받습니다. (이하, ZooKeeper 데이터 노드를 znode라고 부른다)

네임스페이스의 각 znode에 저장된 데이터는 원자적으로 읽고 쓴다. 읽기는 znode와 관련된 모든 데이터 바이트를 가져오고 쓰기는 모든 데이터를 대체한다. 각 노드에는 누가 무엇을 할 수 있는지를 제한하는 액세스 제어 목록(ACL)이 있다.

ZooKeeper에는 임시 노드라는 개념도 있습니다. 이러한 znode는 znode를 생성한 세션이 활성 상태일 때, 존재한다. 세션이 종료되면 znode가 삭제된다.

Zookeeper가 보증하는 것

Zookeeper는 매우 빠르고 매우 간단하다. 그러나 목표는 동기화와 같은 보다 복잡한 서비스의 구축의 기초가 되는 것이므로 몇몇 보증을 제공한다.

  • 순차적 일관성: 클라이언트의 업데이트는 전송된 순서대로 적용 된다.
  • 원자성: 업데이트가 성공하거나 실패한다. 부분 결과가 없다.
  • 단일 시스템 이미지: 클라이언트는 연결된 서버에 관계없이 동일한 서비스 보기를 보게 된다. 즉, 클라이언트가 동일한 세션을 사용하여 다른 서버로 장애 조치하더라도 클라이언트는 시스템의 이전 보기를 볼 수 없다.
  • 안정성: 업데이트가 적용되면 클라이언트가 업데이트를 덮어쓸 때까지 해당 시간부터 지속된다.
  • 적시성: 시스템의 클라이언트 보기는 특정 시간 범위 내에서 최신 상태로 보장된다.

간단한 API

Zookeeper의 설계 목표 중 하나는 매우 간단한 프로그래밍 인터페이스를 제공하는 것이다.
따라서 다음 작업만 지원한다.

  • create: 트리의 위치에 노드 생성
  • delete: 노드를 삭제
  • exists: 노드가 위치에 존재하는지 테스트한다.
  • get data: 노드에서 데이터를 읽는다.
  • set data: 노드에 데이터 쓰기
  • get children: 노드의 자식 목록을 검색
  • sync: 데이터가 전파되기를 기다린다.

번외) Zookeeper 이름의 유래

주키퍼의 이름을 잘 보면 Zoo Keeper 이다. 직역해보면 동물원 관리자 정도로 볼 수 있다.
위에서 주키퍼가 어떤 녀석인지 알아봤는데, 그 역할에 빗대어보자면 동물원이 분산시스템을 뜻하는게 아닐까 싶고 관리자의 의미는 조율(관리라는 표현이 더 적절한 것 같다)을 해준다는 뜻이 아닐까 싶다.

(찾아봤는데, 얼추 비슷하다 😆 참고자료: https://www.oreilly.com/library/view/zookeeper/9781449361297/ch01.html )

The Origin of the Name “ZooKeeper”

ZooKeeper was developed at Yahoo! Research. We had been working on ZooKeeper for a while and pitching it to other groups, so we needed a name. At the time, the group had been working with the Hadoop team and had started a variety of projects with the names of animals, Apache Pig being the most well known. As we were talking about different possible names, one of the group members mentioned that we should avoid another animal name because our manager thought it was starting to sound like we lived in a zoo. That is when it clicked: distributed systems are a zoo. They are chaotic and hard to manage, and ZooKeeper is meant to keep them under control.

The cat on the book cover is also appropriate, because an early article from Yahoo! Research about ZooKeeper described distributed process management as similar to herding cats. ZooKeeper sounds much better than CatHerder, though.

구글 번역>>

"주키퍼"라는 이름의 유래

ZooKeeper는 Yahoo!에서 개발되었습니다. 연구. 우리는 한동안 ZooKeeper 작업을 했고 다른 그룹에 이를 제안했기 때문에 이름이 필요했습니다. 당시 이 그룹은 하둡 팀과 함께 일하며 동물 이름으로 다양한 프로젝트를 시작했는데 아파치 피그(Apache Pig)가 가장 잘 알려져 있다. 가능한 다른 이름에 대해 이야기하고 있을 때, 그룹 구성원 중 한 명이 우리가 동물원에 사는 것처럼 들리기 시작했다고 매니저가 생각하기 때문에 다른 동물 이름을 피해야 한다고 말했습니다. 클릭했을 때입니다. 분산 시스템은 동물원 입니다 . 그것들은 혼란스럽고 관리하기 어려우며, ZooKeeper는 그것들을 통제하기 위한 것입니다.

책 표지의 고양이도 적절합니다. Yahoo!의 초기 기사 때문입니다. ZooKeeper에 대한 연구에서는 분산 프로세스 관리가 고양이를 모으는 것과 유사하다고 설명했습니다. 하지만 ZooKeeper는 CatHerder보다 훨씬 나은 것 같습니다.

Zookeeper 실제 사용 예시

ZooKeeper가 어디에 적용되는지 더 잘 이해하는 데 유용했던 몇 가지 예를 살펴보겠습니다.

  • 아파치 HBase
    • HBase는 일반적으로 Hadoop과 함께 사용되는 데이터 저장소입니다. HBase에서 ZooKeeper는 클러스터 마스터를 선택하고 사용 가능한 서버를 추적하며 클러스터 메타데이터를 유지하는 데 사용됩니다.
  • 아파치 카프카
    • Kafka는 pub-sub 메시징 시스템입니다. ZooKeeper를 사용하여 충돌을 감지하고 주제 검색을 구현하며 주제의 생산 및 소비 상태를 유지합니다.
  • 아파치 솔러
    • Solr는 엔터프라이즈 검색 플랫폼입니다. SolrCloud라고 하는 분산 형태에서 ZooKeeper를 사용하여 클러스터에 대한 메타데이터를 저장하고 이 메타데이터에 대한 업데이트를 조정합니다.
  • 야후! 가져오기 서비스
    • 크롤러 구현의 일부인 가져오기 서비스는 robots.txt 파일 의 정책과 같은 웹 서버 정책이 보존되도록 하면서 콘텐츠를 캐싱하여 효율적으로 웹 페이지를 가져옵니다 . 이 서비스는 마스터 선택, 충돌 감지 및 메타데이터 저장과 같은 작업에 ZooKeeper를 사용합니다.
  • 페이스북 메시지
    • 이메일, SMS, Facebook 채팅 및 기존 Facebook 받은 편지함과 같은 커뮤니케이션 채널을 통합하는 Facebook 애플리케이션 입니다 . 샤딩 및 장애 조치를 구현하고 서비스 검색을 위해 ZooKeeper를 컨트롤러로 사용합니다.

Zookeeper (with Kafka)

  • 서버의 상태를 감지하기 위해 사용되며 새로운 토픽이 생성되었을 때, 토픽의 생성과 소비에 대한 상태를 저장한다.
  • 주키퍼와 카프카대규모 환경에서는 다른 서버에 두는 편이 좋다. 주키퍼 앙상블은 홀수로 구성되어 과반수 이상이 장애가 발생하면 중단되고, 카프카는 그렇지 않아도 되기 때문에 다른 서버에 두는 것을 권장한다.

참고자료

728x90