들어가며
Apache Kafka 4.0은 2025년 3월에 출시된 메이저 릴리즈로, 이벤트 스트리밍 플랫폼의 역사에서 중요한 전환점을 맞이했습니다. 가장 주목할 만한 변화는 10년 이상 Kafka의 중추 역할을 해온 Apache ZooKeeper의 완전한 제거입니다. 이제 Kafka는 자체 개발한 KRaft 모드를 기본으로 사용하며, 더욱 간결하고 확장 가능한 아키텍처로 진화했습니다.
1. ZooKeeper에서 KRaft로: 아키텍처의 혁명
ZooKeeper 의존성 제거
Kafka 4.0의 가장 큰 변화는 KRaft(Kafka Raft) 모드가 기본이 되었다는 점입니다. 과거에는 메타데이터 관리를 위해 별도의 ZooKeeper 앙상블을 운영해야 했지만, 이제는 Kafka 자체적으로 모든 메타데이터를 관리합니다.
KRaft의 주요 이점
운영 복잡성 감소
- 별도의 ZooKeeper 클러스터 관리 불필요
- 설치 및 배포 과정 간소화
- 통합된 시스템으로 관리 포인트 축소
확장성 향상
- 100만 개 이상의 파티션 지원 가능
- ZooKeeper의 10만 파티션 제한 극복
- 더 빠른 메타데이터 처리
성능 개선
- 컨트롤러 페일오버 시간 단축
- 메타데이터 변경 작업의 응답 속도 향상
- 클러스터 복구 시간 감소
2. 차세대 컨슈머 그룹 프로토콜 (KIP-848)
Kafka 4.0은 완전히 새로운 컨슈머 그룹 프로토콜을 도입하여 리밸런싱 성능을 획기적으로 개선했습니다.
주요 개선사항
Stop-the-World 리밸런싱 제거
- 기존: 리밸런싱 중 모든 컨슈머의 메시지 처리 중단
- 개선: 점진적 리밸런싱으로 다운타임 최소화
성능 향상
- 대규모 컨슈머 그룹에서 리밸런싱 시간 대폭 단축
- 레이턴시 감소로 실시간 스트리밍 안정성 향상
- 컨슈머 추가/제거 시 영향 최소화
사용 방법
- 서버 측: 기본으로 활성화
- 클라이언트 측:
group.protocol=consumer설정으로 옵트인
# 새로운 컨슈머 프로토콜 활성화
group.protocol=consumer3. Queues for Kafka: 큐 시맨틱 지원 (KIP-932)
Kafka 4.0은 전통적인 메시지 큐 기능을 Early Access로 제공합니다. 이는 Kafka의 활용 범위를 Pub-Sub 패턴을 넘어 Point-to-Point 메시징으로 확장합니다.
Share Group 개념
Share Group이란?
- 여러 컨슈머가 하나의 토픽을 협력적으로 소비
- 각 메시지는 그룹 내 하나의 컨슈머만 처리
- 기존 시스템의 "Durable Shared Subscription"과 유사
사용 사례
- 작업 큐(Work Queue) 패턴 구현
- 로드 밸런싱이 필요한 태스크 처리
- 병렬 처리가 필요한 배치 작업
4. 기타 주요 기능 및 개선사항
보안 및 안정성 강화
트랜잭션 서버 측 방어 (KIP-890)
- 프로듀서 장애 시 "좀비 트랜잭션" 발생 가능성 감소
- 트랜잭션 무결성 강화
Eligible Leader Replicas (KIP-966)
- 데이터 손실 없는 안전한 리더 선출
- High-Watermark까지 완전한 데이터를 가진 복제본만 리더 후보로 지정
Pre-Vote 메커니즘 (KIP-996)
- 불필요한 KRaft 리더 선출 감소
- 네트워크 파티션이나 일시적 문제로 인한 중단 최소화
클라이언트 및 관리 도구 개선
애플리케이션 메트릭 수집 (KIP-1076)
- Kafka Streams 같은 임베디드 클라이언트의 메트릭 수집 가능
- 클라이언트 메트릭과 애플리케이션 메트릭 통합 모니터링
기간 기반 오프셋 리셋 (KIP-1106)
auto.offset.reset옵션에 duration 기반 전략 추가- 무한 스토리지 환경에서 유용한 시간 기반 초기화
# 24시간 전부터 소비 시작
auto.offset.reset=by-duration:PT24H그룹 관리 개선 (KIP-1043, KIP-1099)
- 새로운
kafka-groups.sh도구로 모든 그룹 타입 조회 - Consumer Group과 Share Group 정보 상세 표시
- 트러블슈팅 향상
플랫폼 업그레이드
Java 버전 요구사항 상향
- Kafka Clients & Kafka Streams: Java 11 이상
- Kafka Brokers, Connect, Tools: Java 17 이상
- 최신 Java 기능 활용 및 성능 최적화
로깅 프레임워크 업그레이드 (KIP-653)
- Log4j에서 Log4j2로 마이그레이션
log4j-transform-cli도구로 기존 설정 자동 변환- 보안 및 성능 개선
구 프로토콜 API 제거 (KIP-896)
- 최소 12개월 이상 deprecated된 API 제거
- 업그레이드 전 브로커 버전 2.1 이상 필요
- 명확한 업그레이드 경로 제시 (KIP-1124)
5. Kafka Streams & Connect 개선
Kafka Streams
Foreign Key 추출 개선 (KIP-1104)
- 키와 값 모두에서 Foreign Key 추출 가능
- 조인 작업 간소화 및 스토리지 오버헤드 감소
커스텀 프로세서 래핑 (KIP-1112)
ProcessorWrapper인터페이스 도입- 횡단 관심사(Cross-cutting concerns) 로직 적용 간편화
프로덕션 예외 핸들링 (KIP-1065)
ProductionExceptionHandler에 "RETRY" 옵션 추가- 재시도 루프 제어 및 에러 복구 전략 유연성 향상
향상된 메트릭 (KIP-1091)
- 각 StreamThread와 클라이언트 인스턴스의 상태 메트릭 추가
- 애플리케이션 상태에 대한 상세한 가시성 제공
Kafka Connect
사용자 내부 토픽 복제 (KIP-1074)
- MirrorMaker 2에서
.internal또는-internal접미사 토픽 복제 가능 - 커스텀 복제 정책 없이 비즈니스 토픽 복제
하트비트 복제 비활성화 (KIP-1089)
- MirrorSourceConnector에서 하트비트 토픽 복제 선택적 비활성화
- 여러 커넥터 사용 시 중복 복제 방지
Jakarta EE 10 업그레이드 (KIP-1032)
- Java 17 필수 요구사항
- 현대적인 Jakarta EE 프레임워크와의 호환성 향상
6. Kafka 4.0으로의 마이그레이션
업그레이드 전 체크리스트
-
버전 요구사항 확인
- 브로커: 2.1 이상 버전에서 업그레이드
- Java: Clients(Java 11), Brokers(Java 17) 준비
-
KRaft 모드 마이그레이션
- Kafka 4.0은 KRaft 모드만 지원
- ZooKeeper 모드 완전 제거
- 메타데이터 버전 최소 3.3.x 이상 필요
-
Deprecated API 확인
- 12개월 이상 deprecated된 API 제거됨
- 애플리케이션 코드에서 구 API 사용 여부 점검
-
로깅 설정 변환
- Log4j 설정을 Log4j2 형식으로 변환
log4j-transform-cli도구 활용
업그레이드 경로
권장 순서
1. 개발 환경에서 테스트
2. 브로커를 먼저 업그레이드 (Java 17)
3. 클라이언트 및 애플리케이션 업그레이드 (Java 11)
4. 새로운 컨슈머 프로토콜 점진적 활성화
5. Share Group 기능 테스트 (선택사항)
주의사항
- KRaft 모드로의 전환은 신중하게 계획
- 롤백 불가능한 지점 이후 주의 필요
- 상세한 내용은 공식 업그레이드 가이드 참고
마치며
Apache Kafka 4.0은 단순한 버전 업그레이드가 아닌, 아키텍처의 근본적인 혁신을 이룬 릴리즈입니다. ZooKeeper 의존성 제거는 10년 이상 지속된 관계의 종료를 의미하지만, 동시에 Kafka가 더욱 자립적이고 확장 가능한 플랫폼으로 진화했음을 보여줍니다.
차세대 컨슈머 프로토콜과 큐 시맨틱 지원은 Kafka의 활용 범위를 더욱 넓혀, 다양한 메시징 패턴을 하나의 통합 플랫폼에서 처리할 수 있게 합니다. 175명의 기여자가 참여한 이번 릴리즈는 오픈소스 커뮤니티의 힘을 다시 한번 증명했습니다.
Kafka 4.0으로의 마이그레이션을 계획하고 있다면, 충분한 테스트와 단계적 접근을 통해 안전하게 전환하시기 바랍니다. 새로운 기능들을 활용하여 더욱 견고하고 효율적인 이벤트 스트리밍 아키텍처를 구축하시길 바랍니다.
참고 자료
