kafka 주키퍼가 필수가 아니다?

개요

kafka를 docker로 구성해서 사용하다 보면 zookeeper도 같이 구성해서 사용하곤 했습니다.

하지만 zookeeper는 필수가 아니라는 이야기를 듣고 궁금하여 공부해보려 합니다.

 

Zookeeper란 무엇인가?

쿠버네티스, 카프카 등의 분산 시스템에서는 분산된 시스템끼리 정보를 공유하기 위해 코디네이션 시스템이 필요하고 대표적인 오픈 소스로 Apache Zookeeper가 존재합니다.

공식문서에서는 고성능 코디네이션 시스템으로 소개하며, 이름, 설정 관리, 동기화, 그룹 관리, 리더 선출 등을 수행해 준다고 설명합니다.

 

Kafka에서 Zookeeper가 필요없어졌다

Apache Kafka 2.8.0에 출시되면서 Apache Zookeeper의 의존성이 모두 제거되었습니다.

Zookeeper 대신 Raft 하는 분산 합의 프로토콜을 이용하도록 변경되었습니다.

Zookeeper는 kafka의 Kraft mode를 통해 대체될 수 있습니다.

 

다만 2.8부터 production 준비 상태는 아니며 3.3.1 릴리즈에서 production 사용이 가능해지며 4.0부터는 zookeeper는 제거될 예정입니다.

 

 

Kafka에서 Zookeeper가 사라진 이유

주키퍼는 카프카에서 metadata store로 사용되어 왔습니다.

파티션의 위치, 토픽의 설정 정보 같은 데이터는 주키퍼 클러스터에 따로 저장되었습니다.

만약 사용자가 kafka cluster를 배포하고 싶다면 주키퍼 또한 관리하고 운영해야 했습니다.

두 가지 분산 시스템은 서로 다른 설정을 요구하며 복잡성 또한 자연스럽게 증가합니다.

이제는 카프카 내부에 메타데이터를 저장하고 관리합니다.

 

예를 들어 다음과 같은 불편함이 있다고 합니다.

• 주키퍼의 설정 및 운영배포
• 가용성 및 디스크
• 성능 => 컨트롤 플레인에서 작업 시간이 O(N) -> O(1)로 개선됨

 

Controller architecture

kafka cluster는 파티션 리더와 클러스터 메타데이터를 관리할 컨트롤러 노드를 선택합니다.

파티션과 메타데이터가 많을수록 선형적으로 작업 시간이 늘어납니다.

예를들어 장애로 인해 새로운 컨트롤러를 선택해야 할 때 전체 클러스터 상태를 로드해야 합니다.

KIP-500 이후에는 미리 여러 컨트롤러가 대기하고 있으며 긴 로딩 프로세스를 거치지 않도록 보장합니다.

게다가 ZooKeeper에서 토픽 상태를 로드할 이유가 사라지기 때문에 토픽 생성 및 삭제 속도를 높여줍니다. 

 

 

 

 

 

 

 

 

참고자료

https://psm1782.medium.com/%EB%8F%99%EB%AC%BC%EC%9B%90%EC%9D%84-%ED%83%88%EC%B6%9C%ED%95%9C-%EC%B9%B4%ED%94%84%EC%B9%B4-zookeeper-less-kafka-a71cba58d5d9

https://www.confluent.io/ko-kr/blog/removing-zookeeper-dependency-in-kafka/

https://velog.io/@joyfulbean/Apache-Kafka-Zookeeper-%EC%A0%9C%EA%B1%B0-%EC%9D%B4%EC%9C%A0

https://towardsdatascience.com/kafka-no-longer-requires-zookeeper-ebfbf3862104

https://www.confluent.io/blog/42-ways-zookeeper-removal-improves-kafka/

https://stackoverflow.com/questions/65682557/kafka-docker-image-that-works-without-zookeeper