Confluent Platform 8.3: Kafka 4.3 기반 Flink SQL 통합·KRaft 전환 단순화·Kafka Streams 관측성 개선

엔터프라이즈 Kafka 플랫폼의 세 가지 과제

Apache Kafka를 직접 운영하는 팀과 Confluent Platform 같은 엔터프라이즈 배포판을 사용하는 팀은 서로 다른 문제에 직면한다. 오픈소스 Kafka 운영팀의 고민이 브로커 설정·ZooKeeper/KRaft 마이그레이션·파티션 재배치라면, 엔터프라이즈 배포판 운영팀은 여기에 Flink SQL 관리·멀티 클러스터 가시성·거버넌스 통합이 더해진다.

2026년 7월, Confluent는 Platform 8.3.0을 발표했다. Apache Kafka 4.3.0 기반의 이 릴리스는 세 가지 방향을 동시에 진전시켰다.

1. Flink SQL 운영 도구의 통합 — 별도 UI 없이 CMF에서 직접
2. KRaft 마이그레이션 절차 단순화
3. Kafka Streams 애플리케이션 메트릭을 Unified Stream Manager로 통합

Confluent Platform 8.3의 구조

Confluent Platform은 Apache Kafka에 추가 운영 레이어를 얹은 배포판이다. 8.3.0의 주요 컴포넌트 관계를 이해하려면 몇 가지 용어를 먼저 짚어야 한다.

Apache Kafka 4.3과 KRaft

Confluent Platform 8.3은 Apache Kafka 4.3.0 기반이다. Kafka 4.x 계열은 ZooKeeper를 완전히 제거하고 KRaft(Kafka Raft Metadata)만 사용하는 첫 번째 주요 릴리스 계열이다.

KRaft에서 Kafka 클러스터의 메타데이터 관리는 별도의 KRaft Controller 노드가 담당한다. 브로커가 직접 메타데이터를 ZooKeeper에 쓰는 구조에서, Controller가 Raft 합의 프로토콜로 메타데이터를 복제하는 구조로 바뀌었다.

Confluent Platform 8.3에서 KRaft 관련 신규 기능:

KRaft 마이그레이션 프리체크 유틸리티 ZooKeeper에서 KRaft로 마이그레이션하기 전에 클러스터 상태를 점검하는 도구다. 마이그레이션 가능 여부를 미리 확인하고, 알려진 블로커(비호환 설정·브로커 버전 불일치 등)를 사전 진단한다. 기존에는 마이그레이션을 시작해야 문제를 알 수 있었다면, 이 도구로 실행 전에 실패 원인을 파악할 수 있다.

2.5DC(Multi-Datacenter) 배포의 KRaft 지원 Active-Active 또는 Active-Passive로 구성된 다중 데이터센터 배포에서 KRaft 전환을 지원한다. 단일 클러스터 마이그레이션이 안정화된 이후 가장 큰 운영 난제 중 하나였던 부분이다.

동적 쿼럼 클러스터의 KRaft Controller 스케일업 기존 Controller나 공동 배치(co-located) 브로커를 롤링 재시작 없이 KRaft Controller 레플리카를 추가할 수 있다. 가용성을 유지한 채 Controller 쿼럼 크기를 조정하는 작업이 가능해졌다.

CMF 2.4: Flink SQL 관리의 단일 창

Confluent Platform 8.3의 가장 가시적인 변화는 Flink SQL 관리 UI의 통합이다.

이전까지는 Confluent Control Center(CC)와 Confluent Manager for Apache Flink(CMF)가 별도 컴포넌트로 공존했다. Flink 환경을 관리하려면 CC에서 Flink 관련 UI를 별도 설치하고 접근해야 했다. 설정 복잡도가 높고, Flink 운영자 입장에서 화면 전환이 잦았다.

CMF 2.4부터 이 구조가 달라진다.

• CC의 Flink UI 설치 불필요: 기존 Confluent Control Center에서 Flink UI 설치 방식은 CMF 2.4부터 더 이상 권장하지 않는다(deprecated).
• CMF UI가 단독으로: CMF의 자체 UI가 Flink 환경·리소스·운영을 위한 전용 단일 창이 된다.
• 16개 읽기 전용 디버깅 도구 + 20개 쓰기 도구: CMF 2.4.0은 Flink 리소스 관리를 위한 구체적인 도구 세트를 명시했다. 읽기 도구로 Job·TaskManager·SavePoint·Checkpoint 상태를 조회하고, 쓰기 도구로 Job 재시작·SavePoint 트리거·스케일 조정을 수행한다.

Confluent for Kubernetes(CFK) 측에서도 지원이 강화됐다. Flink SQL 객체를 Kubernetes Custom Resource로 관리할 수 있는 6개의 신규 CRD(Custom Resource Definition) 가 프리뷰로 추가됐다. GitOps 방식으로 Flink SQL 파이프라인을 관리하는 것이 가능해진다.

Unified Stream Manager: Kafka Streams 메트릭 통합

Confluent의 Unified Stream Manager(USM) 는 Kafka 클러스터 전반의 관측성을 통합하는 제어면이다. 이전까지는 Kafka 토픽·컨슈머 그룹 수준의 메트릭이 주였다면, 8.3부터 Kafka Streams 애플리케이션 메트릭이 추가됐다.

USM에서 새롭게 확인할 수 있는 Kafka Streams 메트릭:

이전에는 Kafka Streams 애플리케이션 메트릭을 확인하려면 JMX 에이전트를 직접 설정하거나, Prometheus exporter를 붙여야 했다. USM 통합으로 별도 설정 없이 Confluent Cloud Console에서 직접 볼 수 있다. 단, KRaft 모드로 실행 중인 Confluent Platform 8.3.0 이상 클러스터에서만 지원된다.

Confluent Health+의 EOL과 USM 이전

8.3 릴리스에서 운영팀이 확인해야 할 중요한 변화가 하나 있다. Confluent Health+가 EOL(End-of-Life) 프로세스에 진입했다.

Confluent Health+는 이전까지 클러스터 헬스 모니터링과 지원 메트릭 수집에 사용되던 컴포넌트다. 이제 그 역할이 Unified Stream Manager로 이전된다.

EOL 일정은 공식 문서에서 확인해야 하지만, 현재 Health+에 의존하는 알림·대시보드·지원 패키지가 있다면 USM으로 마이그레이션 계획을 세워야 한다.

운영자 체크리스트

Confluent Platform 8.3으로 업그레이드하거나, 해당 기능을 도입할 때 확인할 항목:

KRaft 마이그레이션 관련

• 현재 클러스터가 ZooKeeper 기반이라면: 8.3에서 추가된 프리체크 유틸리티로 마이그레이션 블로커를 먼저 파악한다
• 다중 데이터센터(2.5DC) 배포라면: 8.3부터 공식 KRaft 지원이 됐지만, 롤아웃 순서와 Raft 쿼럼 구성을 사전에 검토한다
• Controller 레플리카를 늘릴 계획이라면: 동적 쿼럼 스케일업 기능으로 롤링 없이 진행 가능한지 확인한다

Flink SQL 관리 관련

• 현재 CC의 Flink UI를 사용 중이라면: CMF 2.4로 전환 후 CC의 Flink UI는 더 이상 지원되지 않는다. UI 접근 경로 변경을 팀 내 공유한다
• CFK 기반 GitOps 파이프라인이 있다면: 6개의 신규 Flink SQL CRD가 프리뷰 상태임을 감안해 프로덕션 도입 전 안정성을 검증한다

모니터링·거버넌스 관련

• Kafka Streams 앱 메트릭을 JMX/Prometheus로 직접 수집 중이라면: USM 통합이 중복되는지 확인하고, 필요 시 중복 수집 제거를 검토한다
• Confluent Health+를 알림·지원 워크플로우에 사용 중이라면: EOL 일정에 맞춰 USM 이전 계획을 수립한다

기반 Kafka 4.3의 운영 변화

Confluent Platform 8.3이 채택한 Apache Kafka 4.3.0에는 몇 가지 운영상 중요한 변화가 있었다.

브로커 코도닝(Broker Cordoning): 파티션 리더십을 특정 브로커에서 단계적으로 이전하는 기능이다. 브로커를 다운하기 전에 코드닝 상태로 전환하면, 새로운 파티션이 해당 브로커에 할당되지 않는다. 순차적 브로커 재시작이나 유지보수 시 트래픽 급격한 이동을 완화할 수 있다.

Share Groups: Kafka 큐 의미론의 확장이다. 기존 컨슈머 그룹은 파티션-컨슈머가 1:1 관계로 묶이지만, Share Groups는 여러 컨슈머가 같은 파티션을 공유하며 레코드를 나눠서 처리할 수 있다. 이 동작은 전통적인 메시지 큐(RabbitMQ 등)와 유사하며, Kafka를 작업 큐(work queue)로 사용하는 패턴에서 파티션 수 증가 없이 처리량을 늘릴 수 있다.

요약

엔터프라이즈 Kafka 운영의 복잡성은 브로커만이 아니다. Flink SQL 파이프라인·KRaft 전환·Kafka Streams 앱이 모두 같은 클러스터 위에서 돌아가는 환경에서, Confluent Platform 8.3은 각 레이어의 관측성과 운영 도구를 하나의 제어면으로 모으는 방향을 계속 진전시켰다.

References

• Announcing Confluent Platform 8.3
• Release Notes for Confluent Platform 8.3
• Confluent Manager for Apache Flink (CMF) Changelog
• Unified Stream Manager for Confluent Platform
• Monitor Kafka Streams Applications in Confluent Platform
• Apache Kafka 4.3.0 Release Notes