03. Broker, Zookeeper

Kafka Broker

Partition에 대한 Read 및 Write를 관리하는 소프트웨어

• Kafka Server라고 부르기도 함.

• Topic 내의 Partition 들을 분산, 유지 및관리

• 각각의 Broker들은 ID로 식별됨 (단, ID는 숫자)

• Topic의 일부 Partition들을 포함 → Topic 데이터의 일부분(Partition)을 갖을 뿐 데이터 전체를 갖고 있지 않음

• Client는 특정 Broker에 연결하면 전체 클러스터에 연결됨

• Kafka Cluster : 여러 개의 Broker들로 구성됨

• 최소 3대 이상의 Broker를 하나의 Cluster로 구성해야 함 → 4대 이상을 권장함

Bootstrap Servers

모든 Kafka Broker는 Bootstrap(부트스트랩) 서버라고 부름

• 하나의 broker에만 연결하면 Cluster 전체에 연결됨 → 하지만, 특정 Broker 장애를 대비하여, 전체 Broker List(IP, port)를 파라미터로 입력 권장

• 각각의 Broker는 모든 Broker, Topic, Partition에 대해 알고 있음(Metadata)

Zookeeper

Zookeeper는 Broker를 관리(Broker 들의 목록/설정을 관리)하는 소프트웨어

• Zookeeper는 변경사항에 대해 kafka에 알림 → Topic 생성/제거, Broker 추가/제거 등

• Zookeeper 없이는 Kafka가 작동할 수 없음 →KIP-500을 통해 Zookeeper 제거가 진행중 →2022년에 Zookeeper를 제거한 정식 버전 출시 예정

• Zookeeper는 홀수의 서버로 작동하게 설계 (최소 3, 권장 5)

• Zookeeper에는 Leader(writes)가 있고 나머지 서버는 Follower(reads)

아파치 주키퍼를 걷어낸 KIP-500의 얼리 억세스가 2.8 릴리즈에 포함

→ Kafka Raft Metadata 모드, 줄여서 KRaft (크라프트)배포 및 운영이 훨씬 더 간단하고, Kafka 전체를 싱글 프로세스로 실행 가능

→ 클러스터당 더 많은 파티션 수용 가능

→ 아직 ACL 및 기타 보안기능 및 트랜잭션은 지원 안함

→ 파티션 재할당 및 JBOD는 KRaft모드에서 미지원(년말에 출시될 카프카 릴리즈에서 가능해질 에정) Event-Driven Consensus 로 동작하는 Quorum Controller

→ KRaft 프로토콜을 이용하여 메타데이터를 쿼럼 전체에 정확하게 복제

→ ZooKeeper의 ZAB 프로토콜 및 Raft 와 유사하지만, 이벤트 기반 아키텍처를 사용

Zookeeper 아키텍처

• Leader/Follower 기반 Master/Slave 아키텍처

• Zookeeper는 분산형 Configuration 정보 유지, 분산 동기화 서비스를 제공하고 대용량 분산 시스템을 위한 네이밍 레지스트리를 제공하는 소프트웨어

• 분산 작업을 제어하기 위한 Tree 형태의 데이터 저장소 → Zookeeper를 사용하여 멀티 Kafka Broker들 간의 정보(변경 사항 포함) 공유, 동기화 등을 수행

Zookeeper Failover

• Quorum 알고리즘 기반

• Quorum(쿼럼): 합의체가 의사를 진행시키거나 의결을 하는데 필요한 최소한도의 인원수

• 분산 코디네이션 환경에서의 장애 대응을 위해 사용