동물원을 탈출한 카프카 — Zookeeper-less Kafka
이 글은 medium의 Giorgos Myrianthous 저자님이 쓰신 Kafka No Longer Requires ZooKeeper 를 번역 및 제 첨언을 붙인 글입니다. 영어 본문의 문맥을 짚어보고 싶으시면 원글을 보시길 강력히 추천드립니다.
또한, Raft 라는 Distributed Consensus Protocol을 잘 이해하고 있다는 가정 하에 쉽게 읽고 이해할 수 있으며 그 가치를 깨달을 수 있는 글이라고 느껴집니다.
Raft에 대해 자세히 알고 싶으시면, 아래의 아티클들을 추천 드립니다.
Introduction
Apache Kafka 2.8.0이 마침내 출시됐다고 합니다. 모든 사용자는 Early Access로 자유롭게 사용해볼 수 있으며, 이는 Apache Zookeeper의 dependency를 모두 제거했습니다.
주키퍼 대신에, 카프카는 Raft 라는 Distributed Consensus Protocol을 이용하여 의견 일치 및 Rog Replication을 수행하기로 했습니다.
이를 사용해보려면 Kafka Raft Metadata Mode를 활성화시키면 됩니다.
이 새 기능들은 cluster administration과 infrastructure management를 간편하게 만들고 또한 카프카의 새로운 영역을 개척시켰습니다.
Zookeeper-less Kafka
이번 아티클에서 우리는 왜 주키퍼 의존성을 제거해야 했는지를 첫 번째로 논할 것입니다.
추가적으로, 우리는 어떻게 ZooKeeper가 kafka 2.8.0의 KRaft mode 을 통해 대체될 수 있고 이 의존성을 제거함으로써 어떤 효과가 있는지, 또한 카프카 자체의 입장에서 어떤 이득이 있는지도 알아보겠습니다.
What is KPI-500
그동안 Apache ZooKeeper는 kafka에서 metadata store로 사용되어 왔습니다.
partition과 broker들의 메타데이터를 ZooKeeper Quorum에 저장하고 이는 kafka Controller election에 대한 책임이 있습니다.
ZooKeeper는 카프카와 연동해야 하는 외부 시스템으로써 자체의 문법, 관리 툴과 best practices들을 가지고 있습니다.
그러므로, 만약 사용자가 kafka cluster를 배포하고 싶다면 당신은 ZooKeeper 또한 관리하고, 배포하고, 모니터링을 해야했습니다.
이 두가지 분산 시스템은 서로 다른 configuration을 요구하기 때문에 복잡성 수준이 증가하고 이 때문에 시스템 관리자가 더욱 실수하기 쉬워집니다.
또한 두개의 시스템이 존재하는 것은 클러스터 관리에 대한 작업을 중복으로 수행하게 만들죠 —
예를 들어, 특정 보안 기능을 적용하려고 한다면 당신은 카프카 뿐만 아니라 ZooKeeper 서비스의 configuration에도 마찬가지로 해당 보안 설정을 적용해야합니다.
외부 메타데이터 스토어는 추가적인 프로세스를 요구하게 함으로써 리소스 면에서도 비효율적입니다. 뿐만 아니라, 이 때문에 카프카 자체의 확장성을 제한시켜왔습니다.
매번 클러스터를 기동시킬 때마다, kafka controller는 반드시 cluster의 state를 ZooKeeper로부터 불러들여야 합니다.
이와 동일한 일이 새로운 controller가 선거될 때마다 발생합니다. 시간이 지남에 따라 메타데이터의 양이 커지는 것을 고려하면, 시간이 지날수록 메타 데이터를 불러올 때마다 비효율성이 커지기 때문에 그를 방지하기 위해 ZooKeeper에서 cluster 내의 partition 수에 제한을 걸었던 것입니다.
KPI는 Kafka Improvement Proposals 을 나타내며 KPI-500 은 ZooKeeper-less Kafka의 기초적인 아키텍처를 소개하고 있다.
Introducing Kafka Raft Metadata Mode
Version 2.8.0은 ZooKeeper-less Kafka를 KPI-500의 일부로서 Early Access로 소개하고 있습니다. 다만 KPI-500의 100%가 아니라 부분적으로 구현이 완료되었기에, 이를 아직 절대 production 환경에서 사용하면 안된다고 합니다.
가장 최근의 릴리즈에서, 주키퍼는 내부의 Raft Quorum으로 대체될 수 있게 되었습니다.
Kafka Raft Metadata mode를 활성화시켰을 때, kafka는 메타데이터와 configuration을 @metadata 라는 이름의 토픽으로 저장하게 됩니다.
이 내부 토픽은 내부 quorum에 의해 관리되고 cluster 간에 replicate됩니다.
그리고 클러스터 내의 노드는 broker, controller, 혹은 둘 다가 될 수 있다고 합니다.
(called combined nodes).
KRaft mode 가 활성화되었을 때, 오직 몇개의 선택된 서버만 controller가 될 수 있고 이것들로 내부의 quorum이 구성되어집니다. controller는 active 혹은 standby mode 둘 중 하나가 되고 만약 현재 active인 controller 서버가 탈락하거나 종료되면 controller 역할을 위임받게 된다고 하네요. (standby 모드일 때 — Raft의 candidate 느낌.)
그리고 이제 모든 Kafka Server는 process.roles라는 이름을 가진 parameter를 추가적인 configuration으로 가지게 됩니다.
이 파라미터는 다음과 같은 value를 가질 수 있다고 합니다.
broker: The Kafka Server will server as a brokercontroller: The Kafka Server will serve as a controller of the internal Raft quorumbroker, controller: The Kafka Server will serve as a both a controller of the quorum and a broker
유의해야할 것은 ZooKeeper mode에서는 위 parameter를 사용하지 않으며, 오직 KRaft mode를 활성화시켰을 때만 사용되는 parameter라는 점입니다.
추가적으로, 각각의 노드는 이제 node.id를 통해 식별되며,
ZooKeeper의 zookeeper.connect 와 대응되는 controller.quorum.voters configuration parameter를 반드시 설정해야한다는 것이다.
이 파라미터는 내부 쿼럼의 controller server를 식별하는데 사용되며 다음과 같은 방식으로 값을 지정한다.serverID1@host:port, serverID2@host:port, ...
그래서 만약 우리가 KRaft mode에서 7개의 broker와 3개의 controller로 클러스터를 구성한다고 하면, configuration은 다음과 같이 될 겁니다.
process.roles=controller
node.id=1
listeners=CONTROLLER://controller-1-host:9092
controller.quorum.voters=1@controller-1-host:9092,2@controller-2-host:9092,3@controller-3-host:9092이와 비슷하게, 아래의 configuration은 broker를 설정하는 법을 알려줍니다.
process.roles=broker
node.id=4
listeners=PLAINTEXT://:9092
controller.quorum.voters=1@controller-1-host:9092,2@controller-2-host:9092,3@controller-3-host:9092이젠 안녕, ZooKeeper
Apache ZooKeeper dependency를 제거하는 것은 분명히 kafka platform을 위한 발걸음입니다. 모든 커뮤니티(특히 Confluent) 에선 이를 위해 지난 몇년간 의존성 제거 작업을 진행해왔다고 합니다.
이번 최신 릴리즈는 ZooKeeper-Less Kafka를 만들기 위해 엄청난 노력을 쏟아부은 릴리즈가 아닐 수 없습니다. production에서도 사용할 수 있는 완전한 version은 올해 내로 완성 예정이라고 합니다. 그들의 수고에 감사를 표하며, 다시금 개발자들의 오픈 소스 정신이 없었으면 이루지 못했을 발전이라고 체감하게 됩니다.
Conclusion
주키퍼의 의존성을 제거하는 것은 카프카를 위한 거대한 한걸음 입니다.
사실, 이번의 KRaft mode는 Apache Kafka의 확장성을 훨씬 더 증대시켜줄 것이며 더 이상 카프카를 다뤄보기 위해 ZooKeeper까지 공부할 필요없이 러닝 커브를 완만하게 만들어 줄 혁신이 아닐 수 없습니다.
이는 또한 kafka의 configuration과 배포를 더 쉽고 효율적으로 만들어 줄 것입니다.
KPI 500에 더하여, kafka 2.8.0은 많은 기능 향상과 bug fix가 포함되어 있습니다. 이에 대해서 알고 싶으면 release note를 확인해주세요.
