[Zookeeper] Zookeeper 소개

주키퍼 도입 배경

• 과거에는 한 대의 컴퓨터에서 동작하는 단일 프로그램이 대다수였으나, 현재 빅데이터와 클라우드 환경에선 대규모의 시스템들이 동작하고 있음
• 이 대규모 시스템은 수많은 서버와 인프라로 구성 되어 애플리케이션 기능을 함
• 복잡한 시스템 구조로 인하여 각 애플리케이션이 공유하고 있는 클러스터 자원에 무분별한 쓰기 동작으로 인한 경쟁 상태가 발생할 수도 있고, 단일 장애점이 쉽게 발생되기도 함
• 결국 이 개별적인 시스템들을 각각 조율해야 하는 코디네이션 시스템의 수요가 발생
• 이러한 분산 코디네이션 시스템의 수요가 발생하더라도, 정작 대강 만들거나 필요한 로직에 집중하지 못하게 되는 경우가 많아짐

주키퍼는 무엇인가?

• 분산 코디네이션 서비스를 제공하는 오픈소스
• 개발자가 코디네이션 로직보다는 비즈니스 핵심 로직에 집중하게끔 지원함
• Leader Follower로 구성되는 Master-Slave 아키텍처 기반
• 크게 아래 3가지로 구성됨
  1. 여러 주키퍼 서버로 이루어진 앙상블(Ensemble)
  2. 앙상블 데이터의 불일치를 방지하고자 하는 쿼럼(Quorum)
  3. 분산 데이터 시스템인 znode로 이루어진 주키퍼 데이터 모델

주키퍼의 사용 용도

• 설정 관리 : 클러스터의 설정 정보를 최신으로 유지하기 위한 조율 시스템으로 활용
• 클러스터 관리 : 클러스터의 서버가 추가되거나 제외될 때 그 정보를 클러스터 내 서버들이 공유
• 리더 채택 : 다중 애플리케이션 중에서, 어떤 노드를 리더로 선출할지 정하는 로직을 만드는데 사용
• 락, 동기화 서비스 : 클러스터에 쓰기 연산이 빈번할 경우, 경쟁 상태가 발생할 수 있음. 이 때 데이터 불일치로 이어질 수 있는데, 이 때 클러스터 전체를 대상으로 동기화해(락을 검) 경쟁상태 발생을 사전 방지함

주키퍼 아키텍처

• 클라이언트들은 주키퍼 서버들로 이루어진 앙상블(클러스터)에 접근하여 주키퍼 내 znode의 데이터를 읽거나 업데이트 함
• 앙상블 내 주키퍼 서버들은 조율된 상태이며 항상 동일한 데이터를 가지고 있음 > 어느 서버에서 데이터를 조회하여도 동일함
• 쓰기 동작이 발생할 경우 프로세스
  1. 만약 주키퍼 서버에 쓰기 동작을 할 경우, 그 업데이트 된 서버는 leader의 역할을 맡은 주키퍼 서버에 그 데이터를 알리고 업데이트 함
  2. 이 업데이트를 감지한 leader 서버는 그 정보를 다른 곳에 브로드캐스트 형식으로 전파함

주키퍼의 znode는 무엇인가?

• 주키퍼의 핵심으로 이 znode를 통해 주키퍼가 제공할 수 있는 글로벌 락, 동기화, 리더 채택, 설정 관리 등의 기능 구현이 가능해짐
• 아래는 znode의 데이터 모델로 리눅스 파일 시스템과 유사함
  • 각각의 znode는 stat 구조를 유지하고 있음. 이 stat은 znode의 메타데이터를 제공함
  • 메타데이터를 이루는 것은 버전 넘버, ACL(Action control list), 타임스탬프(timestamp), 데이터 길이가 있음
• znode는 크게 3가지 타입으로 분류됨
  • 영속 znode : 특정 znode를 만든 특정 클라이언트의 접속이 끊어져도 계속 주키퍼 데이터 모델에 남아 있음. 클러스터 관리 로직을 구현할 때 중요함
  • 임시 znode : 특정 znode를 만든 특정 클라이언트의 접속이 끊어지면 주키퍼 데이터 모델에서 사라짐. 리더 선출을 구현할 때 중요함
  • 연속형 znode : 영속적일수도 있고 임시적일 수도 있음. lock을 구현하거나 글로벌 큐를 구현할 때 중요함

이렇게 좋은 주키퍼, 단점은?

• 소규모 서버로 구성된 플랫폼의 경우, 하나의 노드(물리적 서버 공간)에 여러 소프트웨어를 설치해야 하는 경우가 많다. 이 경우 클릭하우스와 카프카를 같이 설치를 하게 된다면 포트 충돌이 일어날 수 있다. 즉, 하나의 노드에 2개의 서로 다른 주키퍼를 설치 및 관리해야 한다.
• 주키퍼와 실제 데이터를 담고 있는 저장소 간 데이터 불일치가 일어날 수 있다. 클릭하우스의 경우 해당 데이터가 없다고 뜨지만 주키퍼에서는 이런 신호를 받지 못해 여전히 replica(주키퍼 메타데이터에서는 znode)를 가지고 있어 관리포인트가 될 수 있다.
• 카프카와 주키퍼가 의존도가 큰 만큼 주키퍼를 운영해야 하는데, 주키퍼 또한 안정적인 서비스 제공을 위해서는 적어도 3대(정확히는 3대 이상의 홀수)는 필요하다. 2대가 아니라 3대다. 이는 과반수의 법칙 때문이다. 해당 법칙은 따로 게시글로 소개하겠다.

참고

• 아파치 주키퍼 소개 및 아키텍처
  https://engkimbs.tistory.com/660

• 아파치 주키퍼와 카프카의 의존도에 대한 내용
  💔 Kafka 와 Zookeeper 의 헤어질 결심. 그 결말은?? (tistory.com)