← 학습 카테고리

Learn

Kafka

84개 모듈 · 현재 59번째

Kafka 모듈 59/84 kafka-learn-59

KIP-848 — JoinGroup/SyncGroup을 없애고 서버가 직접 할당을 계산하는 새 리밸런싱

KIP-848 새 컨슈머 그룹 프로토콜 및 Kafka Streams num.standby.replicas 공식 문서 종합 (웹 리서치, 2026) — KIP-848: The Next Generation of the Consumer Rebalance Protocol + Confluent 공식 문서(streams/sizing, streams/developer-guide/config-streams) KIP-848: The Next Generation of the Consumer Rebalance Protocol

이 모듈을 다 읽으면

  • 구 프로토콜에서 파티션 할당 계산을 누가(클라이언트 vs 서버) 담당했는지 설명할 수 있다
  • KIP-848이 리밸런싱을 '증분적'으로 만드는 방식을 설명할 수 있다

kafka-learn-39에서 다룬 '그룹 리더(컨슈머)가 파티션 할당을 계산하고 코디네이터가 배포한다'는 구 프로토콜 구조를 전제로, Kafka 4.0에서 프로덕션 준비 완료된 KIP-848이 이 계산 주체 자체를 서버로 옮기고 다단계 프로토콜을 하나로 통합한 방식을 정리한다.

구 프로토콜의 문제 — JoinGroup/SyncGroup이라는 블로킹 장벽

kafka-learn-39에서 다룬 것처럼 구 프로토콜에서는 그룹 코디네이터가 멤버 목록을 모으고 그중 한 컨슈머(Group Leader)에게 실제 파티션 할당 계산을 위임했다 — 이 과정은 JoinGroup과 SyncGroup이라는 별도의 API 호출 단계를 거치며, 이 두 단계가 일종의 블로킹 장벽(barrier) 역할을 해 그룹의 모든 멤버가 이 단계들을 동기적으로 통과해야 리밸런싱이 완료됐다. 이 구조 때문에 그룹 규모가 커질수록 리밸런싱에 걸리는 시간과 그 사이의 처리 중단 영향이 커지는 경향이 있었다.

핵심 포인트

  • 구 프로토콜: 그룹 리더(컨슈머)가 파티션 할당을 계산, JoinGroup/SyncGroup이라는 별도 API 단계가 블로킹 장벽으로 작동
  • 그룹 규모가 커질수록 이 블로킹 장벽 구조 때문에 리밸런싱 소요 시간과 처리 중단 영향이 커지는 경향

새 프로토콜 — ConsumerGroupHeartbeat 하나로 멤버십과 할당을 함께 처리

KIP-848은 JoinGroup/SyncGroup/Heartbeat로 나뉘어 있던 다단계 조율을 ConsumerGroupHeartbeat라는 단일 API로 통합한다 — 이 API가 지속적인 하트비트 루프 안에서 멤버십 확인과 파티션 할당/회수를 동시에 처리한다. 가장 근본적인 변화는 할당 계산의 주체다 — 서버사이드 모드에서는 그룹 코디네이터(브로커)가 직접 할당을 계산하고, 클라이언트는 단지 그 결과에 따라 파티션을 반납하거나 새로 맡는 역할만 수행한다 — kafka-learn-39에서 다룬 '클라이언트 사이드 리더가 계산' 구조와 정반대다.

핵심 포인트

  • ConsumerGroupHeartbeat API 하나로 멤버십 확인+파티션 할당/회수를 지속적인 하트비트 루프 안에서 함께 처리(JoinGroup/SyncGroup 별도 단계 제거)
  • 서버사이드 모드에서는 그룹 코디네이터(브로커)가 직접 할당을 계산 — 클라이언트는 결과에 따라 반납/할당만 수행, 구 프로토콜(클라이언트 리더가 계산)과 정반대

증분적·부분적 리밸런싱 — 그룹 전체가 아니라 실제로 이동하는 파티션만

새 프로토콜에서 리밸런싱은 증분적(incremental)이고 부분적(partial)으로 일어난다 — 실제로 소유권이 바뀌는 파티션만 영향을 받고, 변경과 무관한 나머지 컨슈머들은 계속 처리를 이어갈 수 있다. 이는 kafka-learn-35에서 이미 다룬 CooperativeStickyAssignor의 점진적 재배정 철학을 프로토콜 차원(서버사이드 계산+단일 API)으로 한 단계 더 발전시킨 것으로 볼 수 있다.

핵심 포인트

  • 새 프로토콜의 리밸런싱은 증분적·부분적 — 실제로 이동하는 파티션만 영향받고 나머지 컨슈머는 처리를 계속 이어감
  • kafka-learn-35의 CooperativeStickyAssignor 점진적 재배정 철학을 프로토콜 차원(서버사이드 계산+단일 API)에서 한 단계 더 발전시킨 형태