1️⃣ Zookeeper 모드
Zookeeper란 분산 시스템에서 서버들 간의 상호 조정과 상태 정보 공유를 관리해주는 시스템이다.
여러 서버로 구성된 앙상블로 동작하며, 데이터를 복제하여 장애에 대비하고 내부에 Leader와 Follower가 존재한다. Write 요청이 들어오면 요청을 받은 서버가 Leader에게 전달하고 Leader가 이를 업데이트한다. 업데이트 후에는 Follower들에게 브로드캐스트처럼 동기화를 수행한다. Read 요청은 각 Follower 노드에서 직접 처리하여 부하를 분산한다.
카프카에서는 Zookeeper을 사용하여 클러스터의 메타데이터와 설정을 관리하며, 내부 브로커·파티션·토픽 정보를 저장한다. kafka 클러스터에서는 브로커 중 한대가 자동으로 컨트롤러 브로커로 선출된다. 이 컨트롤러 브로커가 클러스터를 대표하여 주키퍼와 통신한다.
만약 이 브로커에 장애가 생기면, 주키퍼의 중재 하에 다른 브로커 중 하나가 새로운 컨트롤러로 선출된다.
2️⃣ KRaft 모드
Apache Kafka 3.0부터 도입된 합의 프로토콜로, 기존의 Zookeeper 의존성을 완전히 제거하기 위해 설계되었다. 카프카 4.0 버전에서는 Zookeeper가 완전히 제거되고, KRaft mode 만 지원하다. KRaft모드는 Kafka 내에서 자체적으로 메타데이터를 관리하는 구조다.
Kafka 내부에 보통 3대의 전용 컨트롤러 노드로 쿼럼을 구성한다. 이 3대 중 Raft 알고리즘으로 선출된 한 대의 액티브 컨트롤러과 주요 관리 업무를 전담하며, 나머지 노드들은 대기 상태로 메타데이터를 상시 동기화한다. 메타데이터는 카프카 내부의 전용 메타데이터 로그 토픽 __cluster_metadata 에서 관리한다.
<aside> ✨
장점
토픽 내 파티션 개수는 얼마로 해야할까? 너무 적으면 병렬 실행이라는 강점이 사라지고, 너무 많으면 운영 오버헤드가 발생한다. 따라서 필요한 만큼 최소한의 개수로 설정해야한다.
1️⃣ 파티션 수 ≥ 컨슈머 수
파티션 수는 최대 컨슈머 수 이상이 되야한다.
Kafka에서는 하나의 파티션이 하나의 컨슈머에만 할당되기 때문에, 파티션 수가 컨슈머 수보다 적을 경우 일부 컨슈머는 작업을 할당받지 못하고 IDLE 상태가 된다. 즉 컨슈머가 늘어나더라도 처리 속도가 그대로이므로 의미가 없어진다.