주키퍼

주키퍼

분산 시스템

분산 시스템에서는 클러스터를 중심으로 하위 노드들이 집결되어 있다.
카프카, 쿠버네티스 환경이 그러하다.
보통 클러스터에 여러 노드들이 있는 경우 노드들을 관리하기 위해서 다음의 작업이 필요하다.

• 노드들의 헬스체크
  - 노드가 다운됬을 경우 데이터를 보내거나, 받거나, 처리하는 과정에서 제외되어야 한다.
• Lock processing
  - 분산 시스템에서 공유된 자원을 접근하기 위해서는 락이 필요하다.
  - 마치 프로세스간의 공유 메모리에 접근시 락이 필요한 것처럼.

이러한 문제를 해결하는 것이 분산시스템 = 코디네이션 서비스 시스템이다.
이런 코디네이션 시스템에 장애가 발생하면 전체 장애로 이어지기 때문에
이중화가 가능해야 하고 고가용성이 필요하다.

카프카 2.0대까지만 해도 주키퍼가 꼭 필요하지만 3.0대부터는 꼭 필요하지는 않다.
하지만 아직까지는 완벽하게 대체하지 못하기 때문에 무조건 주키퍼가 있어야 한다고 보면 된다.

주키퍼란 ?

아파치 산하 프로젝트인 하둡, 나이파이, 에이치베이스 스톰 등 많은 어플리케이션이 분산 애플리케이션으로 개발되고 있는데,
분산 어플리케이션 관리를 위해서 안정적인 코디네이션 어플리케이션이 추가로 필요하게 된다.

이 코디네이션 서비스가 주키퍼이다.

주키퍼의 역할

뷴산되어 있는 각 애플리케이션의 정보를 중앙에 집중하고
구성관리, 그룹 관리 네이밍, 동기화 등의 서비스를 제공.

• 설정 관리 = 구성 관리
  - 클러스터의 설정 정보를 최신으로 유지한다.
• 클러스터 관리 = 그룹 관리
  - 클러스터의 노드들이 추가되거나 제외될때 그 정보를 다른 노드들이 알 수 있게 한다.
• 리더 채택
  - 어떤 노드가 리더인가 채택. 그리고 리더가 다운됐을때 새로운 리더를 채택
• 동기화 = 락
  - 데이터 정합을 위해서 락을 건다.

카프카와 주키퍼

주키퍼는 카프카 클러스터를 운영하기 위해서 반드시 필요한 애플리케이션이다.
카프카는 여러대의 브로커(서버)가 분산 환경에서 클러스터에 속해 일하는 구조이다.
즉 여러대의 서버가 동시에 동작을 하게 되고 이들 서버들의 코디네이션을 위해서 주키퍼가 필요하다.

주키퍼 앙상블

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

이렇게 하는 이유는 주키퍼가 코디네이션 시스템이고 주키퍼에 장애가 발생하면 전체 장애로 이어진다.
따라서 안정성을 위해서 다수의 서버를 이용하는 서버-클러스터링을 사용한다.

1개의 리더와 n개의 팔로워가 있다.
이를 주키퍼 앙상블이라고 한다.

카프카의 경우
주키퍼가 실행되고 카프카 브로커 서버가 실행된다.
즉 하나의 주키퍼 서버는 그림에서 Server에 해당하고, 각 브로커는 client가 되는것이다.

카프카 서버는 앙상블을 통해서 Znode의 데이터를 읽고 쓴다.

앙상블의 갯수가 n개라면, n/2개 이상의 노드들이 살아있는 경우 정상 동작하지만, n/2 초과의 갯수가 다운된다면 장애가 발생한다.

znode (zookeeper data model)

znode는 디렉토리 기반 구조로된 key-value 자료구조이다.

상태정보들은 주키퍼의 지노드라는 곳에 key-value 형태로 저장된다.
즉 각 주키퍼 서버들은 znode라는 자료구조들을 통해서 데이터를 공유하고,
하나의 서버가 znode를 업데이트할시 다른 서버들도 공유받는다.

주키퍼에서 사용되는 znode는 데이터를 저장하기 위한 공간 이름을 말하는 것으로,
일반 컴퓨터의 파일이나 폴더 개념이라고 이해하면 된다.

일반적으로 znode에 저장되는 데이터의 크기는 byte에서 kilobyte 정도로 매우 작다.

기본적으로는 자식노드를 갖고 있는 계층형 구조이다.

리눅스 파일 시스템과 동일하게 계층형 트리구조이다.

주키퍼의 znode는 데이터 변경 등에 대한 유효성 검증을 위해 버전 번호를 관리하게 된다.
znode의 데이터가 변경될 때마다 znode의 버전 번호가 증가한다.

znode들은 다 in-memory여서 처리량이 매우 크고 속도도 빠르다.