Kafka 4.0 Consumer Rebalance: 이제 조율은 브로커가 한다

Kafka consumer group을 운영하다 보면 rebalance는 늘 신경 쓰이는 이벤트입니다.

Consumer가 추가되거나 빠지고, topic partition이 늘어나고, session timeout이 발생하면 group은 partition ownership을 다시 나눕니다. 이 과정에서 일부 consumer는 partition을 revoke하고, 새 assignment를 받고, 다시 poll을 이어갑니다.

문제는 이 과정이 단순한 내부 구현 세부가 아니라 운영 체감에 직접 드러난다는 점입니다.

rebalance가 길어지면 처리 지연이 커진다.
consumer가 자주 흔들리면 lag이 계단처럼 튄다.
큰 group에서는 전체 동기화 비용이 더 크게 보인다.

Apache Kafka 4.0에서는 KIP-848, The Next Generation of the Consumer Rebalance Protocol이 GA가 되었습니다. Kafka 문서에서는 이를 new consumer rebalance protocol로 설명합니다. 이 글에서는 본문 흐름상 새 rebalance protocol이라고 부르겠습니다.

이 글의 핵심은 짧습니다.

새 프로토콜은 rebalance 조율의 중심을 consumer client에서 broker group coordinator로 옮긴다.

이 변화는 단순히 설정 이름이 바뀐 정도가 아닙니다. Consumer group을 더 큰 규모에서 다루고, rebalance 시간을 줄이고, client 구현을 단순하게 만들기 위한 구조적 변화입니다.

기존 protocol에서는 누가 조율했나

기존 consumer group protocol은 이 글에서 기존 protocol이라고 부르겠습니다. classic이라는 표현은 Kafka 설정값이나 공식 문서 용어를 직접 가리킬 때만 사용하겠습니다.

기존 protocol의 흐름을 단순화하면 이렇습니다.

1. consumer들이 group coordinator에 JoinGroup 요청
2. coordinator가 group leader consumer를 선택
3. leader consumer가 전체 member와 topic metadata를 보고 assignment 계산
4. member들이 SyncGroup으로 assignment 수신
5. 각 consumer가 partition revoke/assign 후 처리 재개

여기서 중요한 점은 partition assignment를 broker가 직접 계산하지 않는다는 것입니다. Broker의 group coordinator는 group membership을 조율하지만, assignment strategy는 consumer client 쪽에 있고, group leader로 선출된 consumer가 assignment를 계산합니다.

이 구조는 오래 잘 동작했습니다. 하지만 group이 커지고, consumer가 많아지고, subscription과 metadata가 복잡해질수록 몇 가지 부담이 드러납니다.

• Rebalance가 global synchronization barrier처럼 동작하기 쉽습니다.
• Leader consumer가 assignment 계산 책임을 가집니다.
• Client마다 assignor와 protocol metadata를 맞춰야 합니다.
• Rebalance 중 영향을 받지 않아도 되는 member까지 기다리는 비용이 생깁니다.
• Assignment policy가 client 배포와 강하게 묶입니다.

물론 cooperative rebalance 같은 개선도 있었습니다. CooperativeStickyAssignor는 모든 partition을 한 번에 revoke하는 eager rebalance보다 훨씬 나은 운영 경험을 줍니다. 하지만 기존 protocol의 큰 틀, 즉 client-side assignment와 group-level synchronization이라는 구조는 남아 있습니다.

Kafka 4.0의 새 rebalance protocol은 이 지점을 더 깊게 바꿉니다.

새 rebalance protocol은 무엇을 바꾸나

새 rebalance protocol에서는 group coordinator가 더 많은 책임을 갖습니다.

가장 큰 변화는 assignment가 server side로 이동한다는 점입니다.

기존 protocol:
  client leader가 assignment 계산

새 rebalance protocol:
  broker group coordinator가 assignment 계산 및 조율

Consumer는 더 이상 partition.assignment.strategy로 client-side assignor를 나열하지 않습니다. 새 rebalance protocol에서는 broker 설정인 group.consumer.assignors가 server-side assignor 목록을 가집니다. 기본 builtin assignor는 uniform, range입니다.

Consumer 쪽에서는 필요할 때 group.remote.assignor로 사용할 server-side assignor 이름을 지정할 수 있습니다. 지정하지 않으면 broker의 group.consumer.assignors 목록에서 첫 번째 assignor가 기본값으로 선택됩니다.

설정 관점에서는 이렇게 보입니다.

# consumer client
group.protocol=consumer

# optional: choose a server-side assignor by name
group.remote.assignor=uniform

Broker 쪽에서는 다음 설정들이 중요해집니다.

# broker
group.consumer.assignors=uniform,range
group.consumer.heartbeat.interval.ms=5000
group.consumer.session.timeout.ms=45000

공식 consumer config 문서는 group.protocol이 classic 또는 consumer를 지원하며, consumer를 지정해야 새 rebalance protocol을 사용한다고 설명합니다. 기본값은 아직 classic입니다.

즉 Kafka 4.0 broker가 있다고 해서 모든 consumer group이 자동으로 새 rebalance protocol을 쓰는 것은 아닙니다.

server: Kafka 4.0부터 새 protocol 사용 가능
client: group.protocol=consumer로 명시해야 사용

heartbeat와 timeout도 broker 쪽으로 이동한다

기존 protocol에서는 consumer client가 heartbeat.interval.ms, session.timeout.ms 같은 값을 갖습니다.

새 rebalance protocol에서는 이 설정들이 client에서 더 이상 사용되지 않습니다.

Kafka 문서는 group.protocol=consumer일 때 다음 client 설정과 API가 더 이상 usable하지 않다고 설명합니다.

heartbeat.interval.ms
session.timeout.ms
partition.assignment.strategy
enforceRebalance()
enforceRebalance(String)

Heartbeat interval과 session timeout은 broker 설정으로 이동합니다.

group.consumer.heartbeat.interval.ms
group.consumer.session.timeout.ms

이 변화는 작지 않습니다.

기존 protocol에서는 consumer application마다 heartbeat와 session timeout을 다르게 들고 있을 수 있었습니다. 새 rebalance protocol에서는 group coordinator가 member에게 heartbeat interval을 주고, failure detection policy를 broker 쪽에서 더 일관되게 관리합니다.

운영 관점에서는 “consumer application 설정”이던 일부 값이 “cluster policy”에 가까워진 셈입니다.

global barrier를 줄이는 incremental design

Kafka 문서는 새 protocol이 fully incremental design이며, global synchronization barrier에 의존하지 않아 rebalance time을 줄인다고 설명합니다.

이 문장이 중요합니다.

기존 rebalance에서는 group 전체가 한 번에 join/sync 흐름을 통과하는 느낌이 강합니다. 어떤 member가 들어오거나 나가면 group 전체가 새 assignment를 기다리는 구간이 생길 수 있습니다.

새 rebalance protocol에서는 coordinator가 target assignment를 관리하고, member들이 자신의 assignment 변화만 점진적으로 반영하는 방향으로 움직입니다.

개념적으로는 다음 차이입니다.

기존 protocol:
  모두 멈추고 다시 모여 새 assignment를 받는 느낌

새 rebalance protocol:
  coordinator가 target assignment를 관리하고
  member가 필요한 partition 변화만 점진적으로 따라가는 느낌

물론 실제 구현은 더 복잡합니다. 하지만 운영자가 이해해야 할 핵심은 이것입니다.

rebalance가 group 전체를 덜 흔드는 방향으로 바뀐다.

이것이 Kafka 4.0 새 rebalance protocol의 가장 큰 의미입니다.

왜 이 변화가 중요한가

첫째, 큰 consumer group에서 의미가 큽니다.

Consumer 수가 많고 partition 수가 많을수록 rebalance coordination 비용은 더 잘 보입니다. Rebalance가 몇 초만 길어져도 처리 지연, lag, downstream 지연이 같이 흔들릴 수 있습니다.

새 rebalance protocol은 group coordinator가 assignment를 관리하고 incremental하게 변화를 전파하므로, large group에서 더 나은 확장성을 기대할 수 있습니다.

둘째, client 구현이 단순해집니다.

기존 protocol에서는 client가 assignor, subscription metadata, leader assignment 계산, cooperative/eager behavior를 이해해야 했습니다. 새 rebalance protocol은 이 중 일부 책임을 broker로 옮깁니다.

이 방향은 특히 다양한 언어의 Kafka client 생태계에서 중요합니다. Assignment와 rebalance 핵심 로직이 broker 쪽으로 이동하면, client별 구현 차이를 줄일 여지가 생깁니다.

셋째, 운영 정책이 중앙화됩니다.

Assignor 목록, heartbeat interval, session timeout이 broker 쪽 설정으로 이동합니다. 이는 consumer group 동작을 cluster 운영 정책으로 다룰 수 있게 한다는 의미입니다.

넷째, rebalance를 더 관측 가능한 대상으로 만들 수 있습니다.

Kafka 문서는 새 protocol 사용 시 improved threading model에 대한 visibility를 제공하는 consumer metric이 추가됐다고 설명합니다. Rebalance가 client 내부에서만 복잡하게 일어나는 것이 아니라, group coordinator 중심의 protocol로 정리되면 운영자가 볼 수 있는 신호도 더 명확해집니다.

그렇다고 모든 문제가 사라지는 것은 아니다

새 rebalance protocol은 중요한 개선이지만 만능은 아닙니다.

Kafka 문서의 limitations에는 두 가지가 명시되어 있습니다.

Client-side assignors are not supported.
Rack-aware assignment strategies are not fully supported.

즉 기존에 custom client-side assignor를 강하게 사용하던 환경이라면 바로 전환하기 어렵습니다. 새 protocol에서는 server-side assignor 모델을 받아들여야 합니다.

또한 rack-aware assignment를 강하게 의존하는 환경에서는 지원 상태를 확인해야 합니다.

Regex subscription도 주의할 점이 있습니다. 새 rebalance protocol에서 subscribe(SubscriptionPattern) 계열 API는 regular expression을 server side에서 평가하고, RE2J format을 사용합니다. 기존 Java regex 가정과 차이가 있을 수 있으므로 pattern subscription을 쓰는 consumer는 확인이 필요합니다.

업그레이드는 어떻게 생각해야 하나

Kafka 문서는 offline upgrade와 online upgrade를 모두 설명합니다.

Offline 방식은 단순합니다.

consumer group을 모두 중지
group.protocol=consumer로 consumer 재시작
group이 비어 있는 상태에서 기존 protocol <-> 새 protocol 변환

단점은 consumer group을 내려야 한다는 것입니다.

Online upgrade도 가능합니다. Consumer application을 group.protocol=consumer 설정으로 rolling out하면 첫 새 protocol consumer가 group에 join할 때 group이 기존 protocol에서 새 protocol로 변환됩니다. 다만 문서는 이 방식이 custom metadata를 embed하지 않는 assignor를 사용하는 기존 group에서만 가능하다고 설명합니다.

따라서 운영에서는 이렇게 접근하는 편이 좋습니다.

1. broker가 Kafka 4.0 이상인지 확인
2. group.consumer.* broker 설정 검토
3. 기존 consumer의 assignor 확인
4. custom client-side assignor 사용 여부 확인
5. regex subscription 사용 여부 확인
6. 작은 consumer group에서 group.protocol=consumer 테스트
7. lag, rebalance metric, assignment 변화 관찰
8. 중요 group으로 확장

설정 하나로 끝나는 migration이라기보다, rebalance ownership model을 바꾸는 migration으로 보는 것이 안전합니다.

기존 protocol과 새 protocol을 비교하면

요약하면 차이는 다음과 같습니다.

항목	기존 protocol	새 protocol (group.protocol=consumer)
사용 설정	group.protocol=classic 또는 기본값	group.protocol=consumer
assignment 계산	group leader consumer	broker group coordinator
assignor 설정	partition.assignment.strategy	broker group.consumer.assignors, client group.remote.assignor
heartbeat interval	client heartbeat.interval.ms	broker group.consumer.heartbeat.interval.ms
session timeout	client session.timeout.ms	broker group.consumer.session.timeout.ms
rebalance 성격	global barrier 성격이 강함	fully incremental design
client-side assignor	지원	미지원
기존 사용성	안정적이고 익숙함	Kafka 4.0부터 GA, 명시적 enable 필요

중요한 것은 기존 protocol이 사라진 것이 아니라는 점입니다. Kafka 문서는 기존 방식도 여전히 consumer group을 구성할 수 있다고 설명합니다.

따라서 새 rebalance protocol은 “즉시 모두 바꿔야 하는 설정”이라기보다, 큰 consumer group과 rebalance 민감도가 높은 workload에서 검토할 새로운 선택지입니다.

운영자가 봐야 할 신호

새 rebalance protocol을 적용할 때는 단순히 lag만 보면 부족합니다.

확인해야 할 신호는 다음과 같습니다.

• rebalance 발생 빈도
• rebalance duration
• assignment change 빈도
• partition revoke/assign 수
• consumer lag 변화
• poll latency
• processing latency
• coordinator request latency
• heartbeat 관련 metric
• consumer thread 관련 metric
• broker group coordinator 부하

특히 중요한 것은 “rebalance가 줄었는가”보다 “rebalance가 처리 흐름을 덜 흔드는가”입니다.

Lag이 일시적으로 튀는지, 특정 member만 partition 이동을 겪는지, unaffected member가 계속 처리하는지, rolling deploy 때 처리 흐름이 얼마나 매끄러운지를 봐야 합니다.

Konduo처럼 Kafka, JVM, host, container, alert 신호를 함께 보는 도구는 이런 전환을 관찰할 때 도움이 됩니다. Consumer rebalance는 client 설정 하나의 문제가 아니라 broker coordinator, consumer processing, partition assignment, host resource 상태가 같이 만드는 운영 현상이기 때문입니다.

의미는 “rebalance를 broker가 운영 책임으로 끌어온 것”

Kafka 4.0의 새 rebalance protocol을 한 문장으로 정리하면 이렇게 볼 수 있습니다.

consumer group rebalance를 client leader 중심의 협상에서
broker coordinator 중심의 incremental control plane으로 옮긴 변화

이 변화는 Kafka가 consumer group을 더 큰 규모에서 안정적으로 운영하기 위한 방향입니다.

기존 protocol은 여전히 쓸 수 있습니다. 작은 group, 익숙한 assignor, 기존 운영 방식에서는 급하게 바꿀 필요가 없을 수 있습니다.

하지만 consumer group이 커지고, rolling deploy 때마다 lag이 흔들리고, rebalance 시간이 운영 이슈가 되는 환경이라면 Kafka 4.0의 새 rebalance protocol은 충분히 검토할 가치가 있습니다.

핵심은 이것입니다.

rebalance는 소비자의 내부 이벤트가 아니라 운영 control plane이다.
Kafka 4.0은 그 control plane을 broker 쪽으로 더 강하게 끌어왔다.

함께 읽기 좋은 글

이 글의 관점과 이어지는 주제를 더 보려면 아래 글도 함께 읽어볼 수 있습니다.

• Consumer Group인데 Consumer가 아니다: Kafka 안에서 노드들이 서로를 찾는 법 - Kafka group coordination을 소비가 아닌 조율 관점에서 설명합니다.
• Consumer Lag은 건강 점수가 아니다: Kafka Consuming Pressure라는 관점 - rebalance 이후 lag을 더 넓은 처리 압력 관점으로 해석합니다.
• Kafka Client Metrics는 관측의 빈틈을 메울 수 있을까 - consumer client 쪽 관측 신호가 왜 중요한지 다룹니다.