Zookeeper (Apache Zookeeper)
Cluster 최신 설정정보 관리, 동기화, 리더 채택 등 클러스터 서버들이 공유하는 데이터를 관리하기 위해 사용되며 Broker에 분산 처리된 메세지 큐의 정보들을 관리한다.
클러스터를 관리하는 Zookeeper 없이는 Kafka 구동이 불가능하다. 따라서 Kafka 서버를 가동하려면, Zookeeper를 먼저 가동해야한다.
이 Zookeeper를 쉽게 비유하자면 교무실 같은 존재라고 생각할 수 있다.
- 최신 정보 관리: 시간표, 학사 일정, 교직원 정보 등 관리
-> Kafka 브로커 (서버)들의 설정 정보를 중앙에서 관리 - 동기화: 모든 교사와 학생이 같은 정보를 공유하도록 함
-> 모든 브로커가 최신 정보를 가지고 있도록 함 - 리더 선출: 각 학년의 대표, 학생회장, 학생 주임 등을 뽑는 선거 주관
-> 클러스터에서 리더 역할을 할 브로커 선택
위와 같은 일들을 Kafka 클러스터내에서 Zookeeper가 하고 있다.
이렇듯 Kafka와 Zookeeper는 교무실 없이 학교가 제대로 운영될 수 없듯, Zookeeper없이는 Kafka도 제대로 작동할 수 없다.
예를 들어, 한 Kafka 브로커가 갑자기 다운되면, Zookeeper는 이를 감지하고 다른 브로커에게 알려주어 시스템이 계속 원할하게 작동될 수 있도록 브로커들이 서로 협력할 수 있도록 중재자 역할을 하게 된다.
Zookeeper의 데이터 모델
계층적 네임스페이스 (파일 시스템과 유사)
- Znode: Zookeeper의 데이터 노드
- 영구 노드(Persistent Node): 명시적으로 삭제하지 않는 한 유지
- 임시 노드(Ephemeral Node): 세션 종료 시 자동 삭제
- 순차 노드(Sequential Node): 자동으로 순차적 번호 부여
Zookeeper와 Kafka의 상호작용
- 브로커 관리: 클러스터의 모든 브로커 목록 유지 및 브로커 상태 모니터링 및 실패 감지
- 토픽 관리: 토픽의 구성 정보(파티션 수, 복제 팩터 등) 저장 및 각 파티션의 리더와 팔로워 정보 관리
- 컨트롤러 선출: Kafka 클러스터의 컨트롤러 선출 및 컨트롤러 실패 시 새로운 컨트롤러 즉시 선출
- 구성 정보 관리: 브로커의 구성 정보 중앙 관리 및 클러스터 전체의 ACL(접근 제어 목록) 정보 저장
Zookeeper의 작동 방식
- Leader Election: Zookeeper 앙상블 내 리더 선출
- Atomic Broadcast: 리더가 모든 변경사항을 팔로워들에게 동시 브로드캐스트
- Quorum: 과반수 서버의 동의로 변경사항 적용
- Watches: 클라이언트가 특정 Znode의 변경 알림 요청 가능
TOPIC
topic들은 Kafka cluster내에 존재하며, 데이터를 구분하기 위한 가상의 저장소라 할 수 있다.
각 토픽은 하나 이상의 파티션으로 나눠져있고, 이를 통해서 메세지를 병렬로 처리할 수 있다.
특정 주제나 카테고리에 관련된 메시지들의 스트림이다.
TOPIC의 구조와 특징
PARTITION 기반 구조
- 각 TOPIC은 하나 이상의 PARTITION으로 분할된다.
- PARTITION을 통해서 메세지를 병렬로 처리할 수 있다.
- 처리 성능 및 확장성이 향상된다.
데이터 보존
- 설정된 보존 기간동안 데이터를 저장할 수 있다.
- 용량 기반 또는 시간 기반으로 데이터 보존 청책 설정 가능하다.
Producer & Consumer
- PRODUCER: 특정 TOPIC에 데이터를 발행(Publish)
- CONSUMER: TOPIC에서 데이터를 구독(Subscribe)하고 처리
실제 사용 예시
- 로그 수집: 애플리케이션 로그를 특정 Topic으로 전송하여 중앙 집중식 로그 분석
- 사용자 활동 추적: 웹사이트나 앱에서의 사용자 행동 데이터를 실시간으로 수집 및 분석
PARTITION
Kafka에서 Partition은 데이터 처리를 효율적으로 하기위한 핵심 요소로 Broker안에 한개 이상 존재한다.
Partition의 경우 큐를 나눠서 병렬 처리를 가능하게하여 메세지가 병렬로 처리될 수 있다.
postql
