KRaft에 대해(2)
이번 글에서는 이전 글에 이어 KRaft의 구성 방법, 마이그레이션 전략, 릴리스 노트와 향후 계획에 대해 살펴보겠습니다. 아직 이전 글을 읽어보지 못한 분들은 이전 글을 먼저 읽어보시기를 추천드립니다.
KRaft의 구성
전통적인 주키퍼 모드를 사용하면서 많은 사용자들이 느꼈던 불편함 중 하나는 바로 주키퍼와 카프카 서버를 별도로 운영해야 한다는 점이었습니다. 이는 단순히 별도의 애플리케이션 운영 관리를 넘어서, 추가로 별도의 물리적 서버 자원의 할당까지 포함하고 있습니다. 제가 받은 많은 질문 중 하나도, 주키퍼 물리 서버의 할당과 관련된 주제로, 주키퍼와 카프카를 동일한 서버에서 실행해도 되는지에 관한 것이었습니다. 사실 주키퍼는 카프카를 관리하는 역할을 하므로, 이상적으로는 카프카와 분리된 별도의 서버에서 운영하는 것을 권장합니다. 하지만 이는 강제성을 요구하는 것도 아니고, 서버의 리소스 제약이 있는 경우 주키퍼와 카프카를 동일한 서버에서 실행할 수도 있습니다.
KRaft의 등장 이후 카프카 사용자들이 환영한 변화중 하나는 주키퍼의 의존성 제거입니다. 이는 애플리케이션의 관리 단순화뿐만 아니라, 물리적 서버의 리소스 절감도 가능하다고 생각했던 것 같습니다. 실제로 KRaft 공개 이후, 주키퍼 서버 없이 카프카를 운영할 수 있는지에 대한 문의가 많았습니다. 하지만 KRaft 모드에서도 여전히 브로커와 KRaft를 분리된 서버에 배치하는 것을 강력히 추천하고 있습니다. 따라서 주키퍼 서버의 리소스 절약을 주된 목적으로 KRaft로 전환을 고려하는 것은 추천하지 않습니다. 그럼에도 불구하고 서버 자원이 한정적인 경우라면 브로커와 KRaft를 동일한 서버에 배치하는 것을 고려할 수 있습니다.
별도로 구성한 KRaft 모드 공식 문서에 따르면, KRaft 구성의 권장 방식은 브로커와 별개로 KRaft 서버를 할당하여 운영하는 것입니다. 이 구성은 브로커와 컨트롤러를 분리하여 높은 가용성과 안정성을 확보하는데 중점을 둡니다. 이렇게 분리된 구성은 시스템의 장애 포인트를 최소화하고, 하나의 구성 요소에서 문제가 발생했을 시 전체 시스템에 미치는 영향을 줄일 수 있습니다. 이러한 접근 방식은 클러스터의 관리 효율성과 시스템의 안정성을 더욱 강화합니다. 특히 대규모 카프카 클러스터를 운영하거나, 엄격한 SLA를 충족해야 하는 비즈니스 환경에서는 반드시 브로커와 별개로 KRaft 서버를 할당하여 사용하기를 추천합니다.
브로커와 통합으로 구성한 KRaft 모드서버의 리소스가 한정적인 경우에는 KRaft와 브로커를 동시에 운영할 수 있습니다. 이 경우 브로커와 컨트롤러가 동일한 서버에서 실행되므로, 해당 서버에 장애가 발생하면 컨트롤러 역시 불필요하게 종료될 수 있습니다. 이는 시스템의 높은 가용성과 안정성을 유지하기 위한 모범 사례와 상충될 수 있으므로, 추천하는 방식은 아닙니다. 하지만, 작은 규모의 카프카 클러스터를 운영하거나, 개발 용도의 경우 적합합니다.
KRaft 서버 권장 사양
KRaft가 카프카와 같이 많은 데이터를 처리하지 않으므로 권장 사양은 생각보다 높지 않습니다.
CPU: CPU를 공유하는 경우 Dedicated CPU
MEM: 최소 4GB
DISK: 최소 SSD 64GB
JVM: 최소 1GB
KRaft 릴리스 정보와 향후 계획
KRaft는 2021년 아파치 카프카 2.8 버전과 같이 공개되었습니다. 릴리스 내용을 통해 KRaft의 주요 릴리스 내역과 향후 계획에 대해 알아보겠습니다. (참고 페이지)
2021년 카프카 2.8과 KRaft early access
2022년 카프카 3.3과 KRaft Production ready
2023년 카프카 3.5과 주키퍼 모드 deprecated, 주키퍼 마이그레이션 Preview
2023년 카프카 3.6과 주키퍼 마이그레이션 GA
2024년 카프카 3.7과 주키퍼 모드 지원 마지막 버전
2024년 카프카 4.0과 KRaft only 모드 지원
아파치 카프카 3.7 버전이 주키퍼 모드를 지원하는 마지막 버전이고, 이후 카프카 4.0 버전의 경우는 KRaft 모드로만 사용해야 합니다. 현재까지는 주키퍼 모드로 사용해도 무방하지만, 카프카 4.0 공개 후 카프카의 필수 최신 기능 등을 사용하기 위해서는 KRaft 모드로의 마이그레이션 필수일 것입니다.
주키퍼 모드 -> KRaft 모드 마이그레이션
최근 카프카를 최초 구성하시는 분들은 처음부터 KRaft 모드로 구성하여 사용하시는 분들도 일부 계신 것 같습니다. 하지만 현업에서 카프카를 활발히 사용하시는 분들은 대부분 주키퍼 모드를 사용하고 있을 거라 생각됩니다. 현재 주키퍼 모드를 사용하는 분들을 대상으로 KRaft 마이그레이션에 대해 설명할 예정이며, KRaft의 마이그레이션 상세 매뉴얼 형식보다는 전반적인 마이그레이션 방법에 대해 설명하겠습니다.
KRaft의 마이그레이션 방법은 다음과 같은 순서로 진행합니다.
현재 주키퍼 버전 모드 -> 1차 카프카 버전 업그레이드(브리지 모드) -> 2차 KRaft 모드 마이그레이션
주키퍼 모드로 카프카를 사용하면서 KRaft 모드로의 전환은 단순한 업그레이드가 아닙니다. 내부적으로 사용하는 API와 구성의 근본적인 변화로 인해 주키퍼 모드에서 KRaft 모드로 다이렉트 마이그레이션은 불가능합니다. 이러한 복잡한 이슈를 해결하기 위해 카프카는 브리지 모드를 도입하였습니다. 브리지 모드는 주키퍼 모드와 KRaft 모드를 동시에 지원하며 두 모드 사이의 다리 역할을 하게 됩니다.
주키퍼 마이그레이션 GA가 지원되는 카프카 3.6 버전이 주키퍼에서 KRaft로의 전환을 고려할 때 브리지 모드로 고려해야 할 버전으로 추천합니다. 이번 글에서는 현재 사용 중인 주키퍼 모드를 사용하고 있으며 카프카 버전이 3.0이라고 가정하고 설명하겠습니다.
1단계: 카프카 3.0 버전 + 주키퍼 모드 -> 카프카 3.6 버전 + 주키퍼 모드
현재 사용하고 있는 카프카 버전에서 주키퍼 마이그레이션 GA가 지원되는 카프카 3.6 버전으로 먼저 업그레이드를 해야 합니다. 버전 업그레이드 시 현재 카프카의 상태 파악, 사전 준비, 업그레이드 계획 수립, 테스트 및 검증, 실제 업그레이드 실행, 사후 점검 등의 상세한 작업등을 진행해야 하지만, 여기서는 업그레이드에 대한 모든 내용을 다루기에는 어려움이 있습니다. 만약 카프카 버전 업그레이드에 대한 자세한 내용이 궁금하신 분들은 <카프카, 데이터 플랫폼의 최강자>, <실전 카프카 개발부터 운영까지> 책을 참고하시기 바랍니다.
업그레이드 작업 시 업그레이드 전략은 롤링 업그레이드 방식으로 진행할 수 있으며, 클라이언트의 타임아웃이 일부 발생하기는 하지만 무중단으로 업그레이드가 가능합니다.
2단계: 카프카 3.6 버전 + 주키퍼 모드 -> 카프카 3.6 버전 + KRaft 모드
버전 업그레이드를 성공했다면, 현재 실행 중인 카프카의 버전은 3.6입니다. 이제 KRaft 모드로 마이그레이션을 하기 위한 사전 준비가 완료되었으며, 실제 마이그레이션에 대한 상세 매뉴얼은 컨플루언트 공식 문서를 참고할 수 있습니다. 해당 문서에서 설명하는 대로 따라 하면 무리 없이 KRaft로 전환을 할 수 있습니다. 마이그레이션 과정에서 특히 주의 깊게 확인해야 하는 부분은 바로 로그입니다. 작업 중간에 로그를 주기적으로 확인하면서 문제가 없는지 체크해야 합니다. 마이그레이션 작업 중 로그를 확인하다 보면 아래와 같이 Quorum, KRaft와 같은 단어들을 확인할 수 있을 것입니다.
$ cat /usr/local/kafka/logs/controller.log
[2024-03-00 00:00:00,754] INFO [QuorumController id=3003] Creating new QuorumController with clusterId xfKvdoiPRr6Kj3uaaMrFIQ. ZK migration mode is enabled. (org.apache.kafka.controller.QuorumController)
[2024-03-00 00:00:00,612] INFO [ZooKeeperClient KRaft Migration] Initializing a new session to kcluster01.foo.bar:2181,kcluster02.foo.bar:2181,kcluster03.foo.bar:2181. (kafka.zookeeper.ZooKeeperClient)
[2024-03-00 00:00:00,832] INFO [ZooKeeperClient KRaft Migration] Waiting until connected. (kafka.zookeeper.ZooKeeperClient)
Quorum: KRaft 모드에서는 새로운 협의 알고리즘과 투표 기반의 리더 선출 과정에서 사용하는 중요한 개념입니다. Quorum 관련 로그는 클러스터의 상태와 선출 과정 등을 이해하는데 도움이 됩니다.
KRaft: KRaft 모드의 동작 상태나 관련된 경고, 에러 메시지등이 기록되므로 관련 로그를 주의 깊게 확인해야 합니다.
또한, 컨트롤러의 리더 변경이 일어나게 되면, 아래와 같은 로그도 확인할 수 있습니다.
[2024-03-00 00:00:00,851] INFO [QuorumController id=3003] In the new epoch 7, the leader is (none). (org.apache.kafka.controller.QuorumController)
[2024-03-00 00:00:00,908] INFO [QuorumController id=3003] In the new epoch 7, the leader is 3001. (org.apache.kafka.controller.QuorumController)
KRaft 마이그레이션 작업 역시 롤링 업그레이드 방식으로 진행하며, 직접 몇 차례 테스트해 본 결과 클라이언트의 타임아웃이 일부 발생하기는 하지만 무중단으로 업그레이드가 가능합니다.
최종: 카프카 3.6 버전 + KRaft 모드
KRaft 모드로의 전환은 카프카의 운영을 단순화하고, 주키퍼에 대한 의존성을 제거하는 중요한 변화입니다. 이 변화로 인해 카프카는 클러스터의 메타 데이터관리를 자체적으로 수행할 수 있으며, 이에 따라 새로운 도구들이 필요합니다. kafka-metadata-quorum은 KRaft 모드에서 클러스터 ID, 현재 리더, 팔로워 LAG 등 중요한 정보를 조회하는 데 사용되며, 현재 상태와 리더, 팔로워 LAG 등을 파악하는데 필수적인 도구입니다.
$ /usr/local/kafka/bin/kafka-metadata-quorum.sh --bootstrap-server kcluster01.foo.bar:9092,kcluster02.foo.bar:9092,kcluster03.foo.bar:9092 describe --status ClusterId: AcVsv1FpSq-0yX3iTY01lw
LeaderId: 3002
LeaderEpoch: 5
HighWatermark: 1699
MaxFollowerLag: 0
MaxFollowerLagTimeMs: 493
CurrentVoters: [3001,3002,3003]
CurrentObservers: [1,2,3]
리더 변경 후
$ /usr/local/kafka/bin/kafka-metadata-quorum.sh --bootstrap-server kcluster01.foo.bar:9092,kcluster02.foo.bar:9092,kcluster03.foo.bar:9092 describe --status ClusterId: AcVsv1FpSq-0yX3iTY01lw
LeaderId: 3001
LeaderEpoch: 6
HighWatermark: 2161
MaxFollowerLag: 0
MaxFollowerLagTimeMs: 0
CurrentVoters: [3001,3002,3003]
CurrentObservers: [1,2,3]
현재 실행 중인 카프카는 카프카 3.6 버전 + KRaft 모드이므로, KRaft 모드로의 마이그레이션이 완료되었습니다. 이후 만약 필요하다면 카프카 4.0 버전(KRaft only)으로도 업그레이드도 가능합니다. 업그레이드 전 고려 사항이나 필요한 작업 등은 향후 공개될 아파치 카프카 4.0 버전의 릴리스 소식을 참고하시면 될 것 같습니다.
정리
주키퍼 지원 중단 버전이 공개되면서, 저 역시 KRaft 버전으로 마이그레이션 해야 하는 상황을 고려하여 KRaft에 대해 조금 더 자세히 살펴보고, 버전 업그레이드 및 마이그레이션 테스트등을 진행하면서 배운 내용 등을 공유하고 싶었습니다. 이번 글에서는 KRaft 모드의 모니터링과 같이 운영과 관련된 부분은 다루지 않았지만, 이후 잘 준비하여 공유할 수 있도록 하겠습니다. 긴 글 읽어주셔서 감사드리며, KRaft의 마이그레이션에 대해 고민하시는 분들에게 조금이라도 도움이 되었으면 합니다.
참고(KRaft의 발음에 대해)
발음의 통일은 효과적인 커뮤니케이션을 용이하게 하고 기술적 대화의 명확성에 기여한다고 생각합니다. 이러한 맥락에서 KRaft의 정확한 발음에 대한 혼란을 해소하고자 합니다. 많은 분들이 '크래프트' 또는 '케이래프트'라고 발음하지만, 어느 것이 정확한지에 대해서는 정확히 알 수 없었습니다.
결론부터 말씀드리자면, KRaft의 발음은 '크래프트'가 맞습니다. 이는 컨플루언트 코리아(Confluent Korea)의 임직원들로부터 직접 확인한 내용입니다.
또한 해외 사이트와 컨플루언트(Confluent)의 공식 YouTube 채널에서도 '크래프트'라는 발음이 권장되고 있는 것을 확인할 수 있었습니다.
Kafka, in its architecture, has recently shifted from ZooKeeper to a quorum-based controller that uses a new consensus protocol called Kafka Raft, shortened as Kraft (pronounced “craft”).
