Apache Kafka 4.0.0 출시: KRaft, 큐, 향상된 리밸런스 성능

Kafka 4.0 소개

2025년 3월, Apache Kafka는 4.0.0 버전 릴리즈로 큰 이정표를 세웠습니다. 이번 릴리즈는 새로운 기능, 개선사항, 지원 종료 및 중요한 업데이트를 포함하고 있습니다. 이번 글에서는 Apache Kafka 4.0.0의 주요 변경사항과 이 변경점이 개발자, 시스템 아키텍트, 통합 담당자에게 어떻게 영향을 미치는지 살펴봅니다.

ZooKeeper의 종말: KRaft의 시대

그동안 Apache Kafka를 운영하려면 클러스터 메타데이터 관리와 리더 선출 등의 용도로 외부 ZooKeeper 클러스터가 반드시 필요했습니다. 이 추가 구성요소는 운영 및 로컬 개발환경 모두 복잡도를 더했습니다. 이제 이 시기는 공식적으로 종료되었습니다.

KIP-500은 2021년에 출시된 Kafka 2.8.0에서 이른액세스 기능으로 도입되었습니다. 이후 여러 릴리즈를 거치며 KRaft(Kafka Raft)가 성숙해지고, 실사용이 가능한 마이그레이션 기능을 갖추게 되었습니다.

Kafka 4.0.0부터는 ZooKeeper 지원이 완전히 제거되었습니다. 이제 KRaft가 기본이자 유일한 메타데이터 관리 방식이 됩니다. 이는 Kafka 클러스터의 설계와 운영 방식을 크게 바꿉니다.

ZooKeeper 기반 클러스터에서 KRaft 기반 클러스터로 이전한다면, 공식 마이그레이션 가이드를 참고하여 제한사항, 도구, 베스트 프랙티스를 숙지해야 합니다.

KIP-848: 새 컨슈머 그룹 프로토콜로 더 똑똑하고 빠른 리밸런싱

KIP-848은 Kafka의 컨슈머 리밸런스 프로토콜을 다음 세대로 발전시킵니다. 컨슈머 그룹 내 파티션 할당 방식이 근본적으로 변경됩니다.

이 개선은 애플리케이션 재배포나 컨슈머 재시작 등으로 리밸런스가 자주 발생하는 대규모 배포에서 중요합니다. 기존에는 리밸런스가 진행되는 동안 메시지 처리가 정지되어 시스템 성능에 영향을 주었습니다.

주요 변화점:

• 브로커가 파티션을 관리 및 할당하며, 기존의 컨슈머 그룹 리더가 담당하던 역할을 넘겨받음
• Kafka 클라이언트 내부 로직이 크게 단순화됨
• 컨슈머 그룹에 새로운 멤버가 합류할 때, 기존에는 모든 멤버가 파티션 할당을 반납하고 리밸런스가 완료될 때까지 대기해야 했지만, 이제는 신규 멤버가 인크리멘털(점진적)로 파티션을 할당받을 수 있음

이 새로운 프로토콜 덕분에 대규모 환경에서도 리밸런스 성능이 대폭 향상되고, 다운타임과 지연이 크게 줄어듭니다.

더 자세한 내용은 Confluent Current 2024의 관련 발표 영상도 참고하세요.

KIP-932: Apache Kafka 4.0의 큐 – 얼리 액세스 프리뷰

Kafka의 메시징 모델(토픽+파티션)은 현대 이벤트 구동 아키텍처의 핵심이 됐습니다. 하지만 일부 경우에는 RabbitMQ나 Google Cloud Pub/Sub에서 볼 수 있듯 좀 더 전통적인 큐(Queue) 방식이 필요합니다. 메시지 처리 중 일부가 일시적으로 실패해 재처리가 필요할 때, 순서가 보장되지 않는 처리가 오히려 유용합니다. 이를 위해 많은 팀에서 복잡한 커스텀 재시도 메커니즘을 만들어 왔죠.

KIP-932는 Kafka 4.0에서 큐 개념의 프리뷰를 도입해, 그동안 불가능했던 새로운 워크로드 유형을 지원합니다.

주요 추가 기능:

• 공유 그룹(shared groups) 개념 – 메시지의 협업적 소비(cooperative consumption) 지원
• 개별 메시지 확인(acknowledgment) 및 재전달(redelivery) 지원
• 일부 메시지 실패 및 재시도가 필요한 환경에서 유용한 순서 없는(unordered) 처리

Kafka가 큐잉 시스템이 필요했던 기존 시나리오도 충족시키는 큰 발전입니다.

더 심도 있는 내용이 궁금하다면 Adam Warski의 Kafka 큐 블로그 포스트를 참고하세요.

지원 종료 API 및 업데이트된 자바 버전 요구사항

메이저 릴리즈는 대대적인 정리의 기회입니다. Kafka 4.0.0에서도 여러 레거시 API가 제거되고, 플랫폼이 현대화되었습니다.

주요 변경점:

• Java 8 지원 종료
• Kafka Clients와 Streams는 Java 11+ 필요
• Kafka Broker, Connect, Tools는 Java 17+ 필요

최신 Java 런타임 환경과 정렬되어 더 나은 성능, GC 알고리즘, LTS(장기 지원)를 제공합니다. Java 11은 2018년, Java 17은 2021년부터 배포되어 이미 업계 표준으로 자리 잡았습니다.

또 한 가지 중요한 변경: 오래된 프로토콜 API 버전이 제거되었습니다. Kafka 4.0 Java 클라이언트는 최소 브로커 2.1 이상을 필요로 합니다. 또한, 메시지 포맷 v0, v1 지원도 중단되어, 매우 오래된 프로듀서나 컨슈머는 영향을 받을 수 있습니다.

요약

KRaft, 새 리밸런스 프로토콜, Kafka 큐. 이 세 가지 변화는 Kafka 4.0의 방향성을 보여줍니다. 플랫폼은 더욱 단순해지고, 성능 및 새로운 사용 사례에 집중하며 빠르게 진화 중입니다.

기업용 측면에선, Kafka 4.0 기반 Confluent Platform 8.0이 2025년 여름 출시될 것으로 예상되며, 위 기능들이 엔터프라이즈 환경에 적용될 전망입니다.

Kafka 4.0 업그레이드, Kafka 큐 도입이 고민되나요?
Confluent 프리미엄 파트너인 SoftwareMill이 마이그레이션부터 튜닝, 아키텍처 설계까지 여정을 함께할 수 있습니다.

👉 고성능 이벤트 구동 시스템, 함께 만들어보세요!

리뷰: Michał Ostruszka