인사이트리포트

들어가며

Kafka 클러스터를 운영 중 흔히 겪는 상황부터 살펴보자. 메시지 유입량이 늘면서 Consumer Lag이 쌓이기 시작했다. 처리 용량이 부족하다고 판단한 운영자는 Consumer 인스턴스를 한 대 추가한다. 새 Consumer가 기존 Consumer들과 Partition을 나눠 맡으면 처리량이 늘고 Lag도 줄어들 것이라는 판단이다.

그런데 Classic Consumer Group에서는 정반대의 상황이 먼저 벌어진다. 새 Consumer가 그룹에 들어오는 순간 Rebalance가 시작되고, 정상적으로 메시지를 처리하던 기존 Consumer들까지 작업을 멈춘다. 처리량을 늘리려고 Consumer를 추가했지만, 잠시나마 그룹 전체가 멈추면서 Lag이 오히려 더 커지는 셈이다.

이것은 장애나 설정 오류가 아니다. 기존 Rebalance Protocol이 동작하는 방식에서 비롯된 구조적인 한계다. Classic Protocol에서는 멤버 구성이 바뀌면 모든 Consumer가 기존 Partition 할당을 반납한다. 이후 JoinGroup과 SyncGroup을 거쳐 새 할당이 확정될 때까지 기다린다. Consumer 한 대의 변화가 전체 그룹의 Stop-the-world로 이어지는 이유가 여기에 있다.

같은 문제는 Scale-out뿐 아니라 Consumer 장애나 Rolling Deployment 때도 반복된다. 그룹 규모가 크거나 Consumer 초기화에 시간이 오래 걸리면 중단 시간은 길어지고, 쌓인 Lag을 회복하는 데도 더 많은 시간이 든다. 기존 Rebalance의 문제는 단순히 재할당이 느리다는 데 있지 않다. 변경과 관계없는 Consumer까지 함께 멈춘다는 점이 더 큰 문제다.

Kafka 4.0에서 정식 지원되는 KIP-848 기반 Consumer Rebalance Protocol은 이 구조를 바꿨다. Partition 할당 계산을 Broker의 Group Coordinator가 맡고, 변경이 필요한 Consumer만 개별적으로 조정한다. 목표는 Rebalance 시간을 몇 초 줄이는 데 그치지 않는다. 멤버가 바뀌더라도 그룹 전체가 멈추지 않게 만드는 것이 이번 변화의 중심이다.

1. Consumer Group과 Rebalance

하나의 Topic은 여러 Partition으로 나뉜다. 같은 Consumer Group 안에서는 하나의 Partition을 한 Consumer가 맡는다. 아래 그림은 6개 Partition을 Consumer 3개가 나눠 처리하는 가장 기본적인 구성이다.

그림 1. Consumer Group의 기본 파티션 할당 구조

Consumer가 추가되거나 빠지면 Partition을 다시 나눠야 하므로 Rebalance가 시작된다. Scale-out, 장애, Rolling Deployment처럼 운영 중 자주 일어나는 변화가 모두 Rebalance를 유발한다.

2. 기존 Rebalance Protocol은 어떻게 발전했나

Eager Rebalance: 모두 멈춘 뒤 다시 나눈다

Classic Protocol의 Eager 방식은 멤버 변화를 감지하면 모든 Consumer로부터 Partition을 회수한다. Group Leader가 새 할당을 계산한 뒤 모든 Consumer가 SyncGroup을 마쳐야 메시지 처리가 다시 시작된다.

그림 2. Eager Rebalance에서는 모든 멤버가 JoinGroup과 SyncGroup 장벽을 통과할 때까지 처리가 중단된다

구조는 단순하지만 치러야 할 비용이 크다. 옮겨야 할 Partition이 한두 개뿐이어도 그룹 전체의 Fetch와 Commit이 멈춘다. Consumer가 많거나 시작 과정이 무거운 애플리케이션에서는 이 중단 구간이 더 길어진다.

Cooperative Rebalance: 필요한 Partition만 단계적으로 옮긴다

CooperativeStickyAssignor는 불필요한 Partition 회수를 줄이기 위해 도입됐다. 기존 할당과 새 할당이 충돌하면 먼저 옮겨야 할 Partition만 회수하고, 다음 Rebalance에서 새 Consumer에 넘긴다.

그림 3. Cooperative 방식은 이동할 Partition만 회수하나, 회수와 재할당을 위해 두 번 이상의 조정 라운드가 필요할 수 있다

Eager 방식과 비교하면 영향 범위가 확실히 줄었다. 이동 대상이 아닌 Partition은 Fetch를 계속할 수 있다. 다만 Rebalance가 여러 차례에 걸쳐 진행되고 그룹 전체가 여전히 동기화 절차에 참여한다. 이 과정에서 Commit이 대기하거나 실패할 수 있다. 모든 Partition을 한꺼번에 반납하는 문제는 완화됐지만, 그룹 단위 동기화 장벽은 그대로 남아 있는 것이다.

3. Consumer Rebalance Protocol: Broker가 목표 상태를 관리한다

새 프로토콜에서는 Consumer가 Partition을 모두 반납한 뒤 새 할당을 기다리지 않는다. 대신 구독 정보와 현재 할당 상태를 Heartbeat에 담아 보낸다. Group Coordinator는 이를 바탕으로 그룹의 Target Assignment를 계산하고, 각 Consumer에 필요한 변경 사항만 알려준다.

그림 4. 새 프로토콜은 Consumer별 Heartbeat와 Epoch를 이용해 실제 변경 대상만 점진적으로 조정한다. 전역 JoinGroup·SyncGroup 장벽은 없다

Consumer C가 새로 들어와 P3과 P6을 넘겨받는 상황을 예로 들어보자.

1. Consumer C가 구독 정보를 담은 Heartbeat를 보낸다.
2. Coordinator는 새 Target Assignment와 Assignment Epoch를 계산한다.
3. P3과 P6을 갖고 있던 Consumer만 해당 Partition을 반납하고 결과를 보고한다.
4. 반납이 확인되면 Coordinator가 P3과 P6을 Consumer C에 할당한다.
5. 이동 대상이 아닌 Partition은 그동안에도 Fetch와 Commit을 계속한다.

Consumer는 상태를 알리고, Coordinator가 할당한다

Consumer의 역할은 자신이 구독한 Topic과 현재 할당 상태를 알리는 것이다. 실제 할당 계산은 Consumer Group Leader가 아니라 Broker의 Group Coordinator가 담당한다. 이 변화로 리더 선출과 전체 Subscription 수집을 위해 오가던 JoinGroup·SyncGroup 절차가 사라졌다.

필요한 Consumer만 조금씩 바꾼다

Coordinator는 모든 Consumer를 한 번에 최종 상태로 바꾸지 않는다. Heartbeat 응답을 통해 Partition 반납과 할당을 순서대로 전달하고, 각 Consumer가 목표 상태에 도달하도록 조정한다. 한 Consumer의 응답이 늦더라도 그룹 전체가 기다릴 필요가 없다. 변경 사항이 없는 Consumer는 기존 Partition을 처리하면서 Offset Commit도 이어갈 수 있다.

운영 설정은 Broker에서 관리한다

Heartbeat 주기와 Session Timeout도 Broker 설정인 group.consumer.heartbeat. interval.ms, group.consumer.session.timeout.ms로 옮겨갔다. 클라이언트마다 다른 값을 관리하는 대신 Broker에서 그룹 정책을 일관되게 적용할 수 있다.

4. “리밸런스가 빨라졌다”보다 중요한 변화

새 프로토콜을 Rebalance Duration 하나로만 평가하면 변화의 의미를 놓치기 쉽다. 운영 관점에서는 다음 세 가지가 더 중요하다.

• 영향 범위 축소: 한 멤버의 변화가 전체 Consumer 중단으로 번지지 않는다.
• Commit 연속성: 변경과 무관한 Consumer는 Rebalance 중에도 Offset Commit을 이어갈 수 있다.
• 제어 지점 중앙화: Coordinator가 할당과 타이밍을 관리하므로 대규모 그룹의 동작을 예측하고 통제하기 쉬워진다.

검증할 때도 “Rebalance가 몇 초 만에 끝났는가?”만 봐서는 부족하다. 몇 개의 Partition이 실제로 멈췄고, 그 상태가 얼마나 이어졌는지를 함께 확인해야 한다.

5. 적용 방법과 전환 시 주의사항

Kafka 4.0 이상 클라이언트에서는 아래 설정으로 새 프로토콜을 사용할 수 있다.

group.protocol=consumer
group.remote.assignor=uniform

group.remote.assignor를 지정하지 않으면 Broker에 설정된 기본 assignor를 사용한다. partition.assignment.strategy, heartbeat.interval.ms, session.timeout.ms처럼 Classic Protocol에서 사용하던 일부 Consumer 설정은 새 프로토콜에서 지원하지 않으므로 기존 설정을 그대로 옮기면 안 된다.

조건이 맞으면 Classic Protocol에서 서비스 중단 없이 전환할 수도 있다. 다만 기본 제공 assignor를 사용하고 있는지, 사용자 정의 Subscription Metadata에 의존하고 있지는 않은지 먼저 확인해야 한다. 실제 운영 환경에서는 아래 순서로 접근하는 편이 안전하다.

• Broker와 Client의 지원 버전을 확인한다.
• 사용 중인 Assignor 및 사용자 정의 Metadata 의존성을 점검한다.
• 비운영 환경에서 Scale-out, Restart, Crash를 재현한다.
• Lag뿐 아니라 Commit과 Partition별 처리 공백을 함께 측정한다.
• 소규모 Consumer Group부터 단계적으로 전환한다.

6. 새 프로토콜이 해결하지 않는 것

Consumer Protocol을 적용한다고 모든 지연 문제가 사라지는 것은 아니다. 메시지 처리 시간이 길어 max.poll.interval.ms를 초과하거나, 특정 Partition에 부하가 몰리거나, 외부 시스템 응답이 늦는 문제는 별도로 해결해야 한다. Rack-aware 배치나 사용자 정의 Assignor가 필요하다면 지원 범위와 Broker 설정도 미리 확인할 필요가 있다.

마치며

Classic Eager는 모든 Consumer를 멈춘 뒤 Partition을 다시 나눈다. Cooperative 방식은 필요한 Partition만 옮기도록 개선했지만, 그룹 단위 동기화 절차까지 없애지는 못했다. Kafka 4.x Consumer Rebalance Protocol은 목표 할당을 Broker가 관리하고 Consumer별로 상태를 맞추는 방식으로 이 장벽을 걷어냈다.

운영자가 체감하는 가장 큰 차이는 Rebalance 시간 자체보다 처리의 연속성이다. 배포나 장애로 그룹 구성이 바뀌더라도 영향을 받지 않는 Partition은 Fetch와 Commit을 계속할 수 있다. Consumer Group의 규모가 커질수록 이 차이는 더 분명해진다.