[Kafka] Zookeeper와 KRaft(Kafka Raft)

Apache Kafka.

 

이번 글에서는 Zookeeper와 이를 대체하기 위해 등장한 KRaft에 대해 소개 할 예정이다.

 

본 글의 목차는 다음과 같다.

1. Apache ZooKeeper 개요
      1.1 Zookeeper 앙상블
      1.2 Zookeeper Read & Write
2. Zookeeper와 Kafka
3. Zookeeper의 문제점
4. KRaft(Kafka Raft) 모드
5. 마무리

 

Apache ZooKeeper 개요

---

Apache ZooKeeper.

 

Zookeeper는 분산 애플리케이션을 위한 분산 코디네이션 서비스로, 개별 시스템을 관리 및 조율하며 고가용성을 보장한다.

분산 환경에서 클러스터 메타데이터를 관리하고 노드 간의 협업을 돕는 핵심 역할을 수행한다.

 

Zookeeper 앙상블

 

Zookeeper Ensemble.

 

Zookeeper는 여러 서버로 구성된 앙상블 형태로 동작한다. 각 앙상블은 데이터를 복제하여 장애에 대비하며, Leader와 Follower로 나뉜다.

 

또한, 앙상블 내의 과반수 이상의 서버가 정상이면 서비스를 유지하는 특징을 가지고 있다.

예를 들어, 5대의 서버가 있고 2대가 장애가 발생하더라도 동작한다. 따라서, 일반적으로 3대 이상의 홀수개의 노드로 운영된다.

 

Zookeeper Data Read & Write

Zookeeper Data Read & Write.

 

Read는 요청을 받은 서버에서 데이터를 읽어온다.

 

Write는 요청 받은 서버에서 다시 Leader에게 전달하고, Leader에서 이를 업데이트한다.

업데이트 후에는 Follower들에게 브로드캐스트 형식으로 전달하여 동기화를 수행한다.

 

따라서, Write보다 Read 연산이 많은 경우에 더 빠르게 동작한다.

 

Zookeeper와 Kafka

---

ZooKeeper Mode.

 

Kafka는 Zookeeper를 사용하여 클러스터의 메타데이터와 설정을 관리한다.

Zookeeper는 Kafka 클러스터 내 Broker, Partition, Topic 등의 정보를 저장하며, 주요 역할을 다음과 같다.

1. Broker 관리: 클러스터 내의 Broker 리스트를 관리하고, Broker의 상태를 확인
2. 리더 선출: Partition의 리더 Broker를 선출하며, Partition 복제본 간의 역할 분담을 조정
3. 변경사항 알림: 새로운 Topic 생성, 삭제, Broker 추가/제거와 같은 변경사항을 Kafka 컨트롤러 노드에 알림
4. 메타데이터 저장: 클러스터의 메타데이터를 저장하고 관리

Zookeeper는 Kafka 컨트롤러 노드와 통신을 통해 역할을 수행한다. 컨트롤러 노드는 클러스터의 중심 역할을 하며 다음과 같은 작업을 수행한다.

1. 메타데이터 업데이트를 Zookeeper로부터 받아 Broker에 전파
2. Topic, Partition, 복제본 설정 업데이트
3. 클러스터의 상태 변화 모니터링

또한, Kafka 0.9 이전에는 Consumer offset이 Zookeeper에 저장되었지만, Kafka 0.10부터는 Consumer offset을 Kafka 자체의 내부 Topic인 __consumer_offsets에 저장하는 방식으로 변경되었다.

 

Zookeeper의 문제점

---

하지만, Zookeeper와 Kafka의 기존 구조는 다음과 같은 한계점을 드러냈다.

• Zookeeper에 의존성으로 인해 보안과 성능에서 한계를 드러냄
• 별도의 관리 계층(Zookeeper)을 추가하므로 복잡성이 증가
• 모든 Write는 Zookeeper 리더 노드에 집중되므로 수평 확장이 불가
• 클러스터 크기가 커질수록 Zookeeper의 성능이 병목될 가능성이 높음
• 컨트롤러의 문제
  • 컨트롤러는 시작 시 Zookeeper에서 모든 메타 데이터를 동기적으로 로드하고 이를 모든 브로커에 푸시해야하기 때문에 클러스터 크기가 클수록 시간이 오래걸림
  • 컨트롤러가 시작 중일 때는 Topic 생성 등 컨트롤러가 필요한 작업이 불가
  • Broker와 Partition이 많아질수록 컨트롤러의 로드 및 동기화 시간이 늘어나며, 확장성에 큰 제약

 

KRaft(Kafka Raft) 모드

---

KRaft Mode.

 

Kafka는 위 문제들을 해결하기 위해 KRaft(Kafka Raft) 모드를 도입했다. 이의 주요 목적은 Kafka의 구조를 단순화 하고 확장성을 향상시키기 위함이다.

 

KRaft는 Zookeeper를 제거하고 Kafka 내에서 자체적으로 메타데이터를 관리하는 새로운 구조이다.

 

기존 Zookeeper 모드에서는 단일 컨트롤러가 존재했지만, KRaft 모드에서는 3개의 컨트롤러를 운영한다. 이 중 하나가 액티브 컨트롤러가 되어 리더 역할과 Write 작업을 담당한다.

 

또한, Zookeeper 모드에서는 Zookeeper가 메타데이터를 관리했지만, KRaft 모드에서는 Kafka 내부의 전용 Topic(__cluster_metadata)을 사용해 메타데이터를 관리한다.

 

액티브 컨트롤러가 장애나 종료로 인해 사용 불가능해지면, KRaft의 합의 알고리즘(Raft)을 통해 새로운 리더를 선출한다.

 

이러한 KRaft는 다음과 같은 특징을 가진다.

• Zookeeper를 제거하여 관리 복잡성을 줄이고 Kafka 내에서 모든 작업을 수행
• 여러 컨트롤러를 통해 고가용성과 성능 개선
• 리더 선출 과정이 효율적이며, 시스템 복구가 빠르게 이루어짐

 

마무리

---

이번글에서는 Zookeeper에 개요와 KRaft가 왜 등장했는지와 무엇인지 알아보았다.

 

다음에는 Kafka 설치와 간단한 실습에 대해 포스팅할 예정이다.