Zookeeper & KRaft

주키퍼(ZooKeeper)는 카프카 클러스터의 상태 정보를 관리하고 동기화하는 분산 코디네이션 서비스로, 카프카는 자체적으로 클러스터의 상태를 관리하는 기능이 없어 이 역할을 외부 시스템인 주키퍼에 의존했다.

주키퍼(ZooKeeper)의 역할

분산된 여러 서버(노드)들이 하나의 시스템처럼 동작하도록 돕는 "조정자" 또는 "중앙 관리소" 역할 수행한다.

리더 선출 (Leader Election): 클러스터 내 여러 브로커 중 단 하나를 컨트롤러(Controller) 브로커로 선출
- 컨트롤러는 클러스터의 전반적인 상태 변경을 책임지는 리더 역할 수행
상태 관리 (Status Management): 클러스터의 모든 상태 정보(메타데이터)를 저장하고 관리
- 클러스터에 어떤 브로커가 참여 중인지, 어떤 토픽이 생성되었는지, 각 토픽의 파티션은 몇 개인지, 각 파티션의 리더는 어떤 브로커인지 등
장애 감지 (Failure Detection): 특정 브로커에 장애가 발생하여 이 연결이 끊어지면, 주키퍼는 이를 감지하고 컨트롤러에게 알려 클러스터가 복구 작업 시작

카프카는 여러 브로커가 함께 동작하는 분산 시스템이므로, 클러스터의 일관성을 유지하고 장애에 대응하기 위한 중앙 관리 기능이 반드시 필요하다.

예를 들어, 특정 토픽의 파티션 리더를 담당하던 브로커에 장애가 발생했다고 가정해 봅시다.

이처럼 카프카는 클러스터의 두뇌 역할을 주키퍼에 맡겨 안정성을 확보했습니다.

주키퍼는 매우 안정적이지만, 카프카를 운영하는 데 있어 몇 가지 불편한 점이 존재했다.

운영 부담: 카프카와는 별개인 주키퍼 클러스터를 따로 구축하고 관리 필요
- 인프라 구성, 모니터링, 패치 등 운영 부담을 가중
성능 및 확장성 한계: 클러스터 규모가 매우 커지면(파티션 수십만 개 이상), 모든 메타데이터 변경이 주키퍼를 통해 이루어지면서 병목이 발생 가능
느린 장애 복구: 컨트롤러 브로커에 장애 발생 시, 새로운 컨트롤러가 주키퍼로부터 모든 메타데이터를 읽어오는 데 많은 시간이 소요

위의 문제들을 해결하기 위해 KRaft가 등장했다.

주키퍼를 제거함으로써 다음과 같은 이점이 있다.

현재 카프카는 KRaft 모드를 정식으로 지원하며, 신규 클러스터는 KRaft 모드로 구성하는 것이 표준으로 권장되고 있다.

KRaft 모드에서는 카프카 노드가 명확한 역할을 부여받으며, 메타데이터는 내부 토픽을 통해 관리된다.

노드의 역할 분리 (Node Roles): KRaft 클러스터의 각 노드는 controller, broker, combined 중 하나의 역할을 가짐
- 컨트롤러(Controller) 노드: Raft 쿼럼에 참여하여 메타데이터를 처리하고 저장하는 역할만 수행(데이터 I/O는 처리하지 않음)
- 브로커(Broker) 노드: 기존처럼 데이터 I/O(쓰기/읽기)를 담당하지만, 메타데이터 관리는 컨트롤러에게 위임
- 혼합(Combined) 노드: 컨트롤러와 브로커 역할을 동시에 수행(테스트 환경이나 소규모 클러스터에 적합)

컨트롤러 노드는 과반수 이상의 동의를 얻어야만 메타데이터 변경을 승인하는 Raft 합의 알고리즘을 사용하기 때문에 3대 이상의 홀수 개 노드로 구성하는 것이 일반적이다.

주키퍼와 KRaft의 차이는 관리 요소의 단순화 뿐만 아니라, 정량적으로도 뚜렷한 차이를 보인다.

항목

주키퍼(ZooKeeper) 기반

크래프트(KRaft) 기반

장애 복구 시간

수십 초 ~ 수 분(메타데이터 로딩)

수 밀리초 ~ 수 초(즉각적인 리더 전환)

최대 파티션 수

수십만 개(주키퍼 병목)

수백만 개 이상(내부 토픽으로 관리)

운영 리소스

Kafka JVMs + ZooKeeper JVMs

Kafka JVMs Only

아키텍처 복잡도

높음(2개의 분산 시스템)

낮음(단일 시스템)

이처럼 KRaft는 단순한 의존성 제거를 넘어, 카프카의 성능과 확장성, 운영 편의성을 향상시켰다고 할 수 있다.

Last updated 18 days ago

Was this helpful?