💔 Kafka 와 Zookeeper 의 헤어질 결심. 그 결말은??

💬 Kafka 와 Zookeeper 의 관계?
떼려야 뗄 수 없는 관계다.
Kafka 는 Zookeeper 를 통해 필요한 Metadata 를 안전하게 저장하고 Cluster 운영을 위한 리더 및 파티션 오너를 선출하고 있다. 
이러한 관계로 Kafka 를 운영하기 위해서는 반드시 Zookeeper 가 구축되어야 하고 운영단계에서는 Kafka 가 사용하는 Zookeeper 를 다른 솔루션과 함께 사용하지 말라고 권장하고 있다.

💬 Kafka 는 왜 Zookeeper 와 헤어지려고 하는가?
다음과 같은 몇가지 이유가 있다.

1️⃣ Kafka 를 쓰려면 Zookeeper 도 같이 알아야 한다.
- 처음 Kafka 를 배우는 입장에서는 동시에 2가지의 솔루션을 배워야 한다는 것에 진입장벽을 느낄 수 있다.
- 서로 다른 두개의 분산 시스템을 같이 운영하고 관리 및 배포를 할 수 있도록 학습이 되고 준비가 되어야 하는데 이는 처음 진입하는 사람 입장에서는 부담스러울 수 있고 학습 비용 및 구축에 시간이 들 수 있다.

2️⃣ 보안 설정시 Zookeeper 도 같이 설정해줘야 한다.
- 1번 내용과 비슷한 맥락이지만 완벽하게 Kafka Cluster 에 대한 보안 설정을 적용하려면 Zookeeper 까지 같이 해줘야 한다.
- 만약 이러한 부분을 놓쳐서 Kafka 만 진행했을 경우 보안에 이슈가 발생할 가능성이 있다.

3️⃣ Zookeeper 를 운영하는 서버 리소스가 아깝다.
- 안전하게 운영하길 원한다면 Zookeeper 를 최소 5대 이상 구축할것을 권장하고 있다. 만약 이렇게 구축한 Zookeeper 노드를 모두 Kafka 로 바꿀 수 있다면 Kafka Cluster 에서 운영할 수 있는 토픽이나 파티션수가 증가하게 된다.
- 간단하게 테스트 목적으로 Single 노드를 구축 하고싶어도 Zookeeper 가 기본적으로 구축 되어야 하므로 이에 대한 리소스 낭비나 비효율적인 구조가 발생한다.

4️⃣ Kafka 와 Zookeeper 간의 데이터 불일치가 발생한다.
- 이게 아마 가장 큰 이유이지 않을까 싶은데, 몇가지 Metadata 는 Zookeeper 에 기록하지만 Kafka 에서도 메모리에 기록하는데 이때 Kafka 와 Zookeeper 간에 데이터 불일치가 발생하면 운영에 크리티컬한 이슈가 발생한다.
- 이러한 이슈를 피하기 위해 Zookeeper 의 znode 를 매번 탐색하도록 하는것도 비효율적이고 상태 변경이나 전파가 오래걸리거나 중간에 유실될 수 있다.

💬 Kafka 는 Zookeeper 와 어떻게 헤어지려고 하는가?
https://careerly.co.kr/comments/64092?utm_campaign=self-share 에서도 언급했던 Raft 라는 알고리즘으로 새롭게 분산 시스템 운영에 필요한 리더 선출이나 이벤트 전파등을 만들려고 시도하고 있다.
즉, 기존에 Zookeeper 를 통해 사용하던 ZAB 알고리즘을 Raft 알고리즘으로 바꾸는거라 생각하면 된다.
최소 3대 이상의 쿼럼 노드가 있고 이중에 컨트롤러와 Metadata 복제 및 컨트롤러 상태를 체크하는 팔로워 노드를 둔다. 
쿼럼 노드들은 Raft 알고리즘으로 구현한 이벤트 전파 및 Metadata 복제, 리더 선출등을 하게 된다. 
Zookeeper 와 마찬가지로 쿼럼 노드가 많으면 많을수록 장애에 대한 복구 가능성이 커진다.
변경되는 항목중에 알고리즘 외에 흥미로웠던 부분은 기존에는 Metadata 에 대한 변경이 발생하면 컨트롤러 노드가 나머지 노드들에게 변경사항을 Push 하는 구조였는데 이게 Poll 형태로 바뀐다는 점이다.

💬 결말은?
2019년 7월에 이 제안이 나왔고 그로부터 2년뒤인 2021년 4월에 2.8 버전으로 얼리 엑세스 빌드가 릴리즈 되었다.
현재 3.2 버전까지 출시가 되었지만 아직까지 운영(Production)단계에서 Zookeeper 를 사용하는것을 권장하고 있다.
개인적으로 Zookeeper 제외에 대한 안정화된 릴리즈가 나오기를 바라고 있지만 실제로는 더 오래걸릴것 같다는 생각이 든다.
그 이유로 분산 시스템의 핵심이나 다름없는 리더 선출이나 이벤트 전파 및 Metadata 관리 알고리즘을 바꾼다는게 생각보다 쉬운일이 아니다. 더군다나 Zookeeper 에서 사용하는 ZAB 알고리즘이 아닌 Raft 알고리즘으로 바꾸는 것이니 그 간극은 더 클 수 밖에 없다.
또한 오픈소스 특성상 많은 사람들이 써보고 경험한 다양한 이슈를 올려줘야 이를 패치하고 안정화가 진행될 수 있는데 Zookeeper 제외 모드를 운영환경에서 쓰는 사용자가 많지 않은것도 한몫 하지 않을까 싶다. 사실 이런건 Kafka 가 어느정도 안정된 상태였을때 개선하지 말고 초반(1.0 버전 전이었을때)에 했어야 하지 않았나 싶다.
이 로맨스(?)의 결론이 어떻게 날지 귀추가 주목된다.

 

# Reference

- https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=123898922#content/view/123898922