Kafka 리밸런스 프로토콜 비교: Classic과 KIP-848 Consumer

🧐 들어가기 전

컨슈머를 하나 더 띄웠을 뿐인데 그룹 전체의 소비가 몇 초씩 멈추는 경험은 흔하다. 그렇다고 이게 카프카의 버그는 아니고, classic 프로토콜이 합의를 만들어 내는 방식에서 구조적으로 따라 나오는 결과다. 그래서 "리밸런스가 느리다"를 튜닝 문제로만 보면 어디를 건드려야 하는지가 끝내 보이지 않는다.

같은 리밸런스라는 이름 아래에서도 멈추는 방식은 다르다. classic 의 eager rebalancing 은 보유 파티션을 전부 놓고 그룹 전체가 JoinGroup 배리어에 모인다. incremental cooperative rebalancing 은 이동할 파티션만 놓지만, JoinGroup 과 SyncGroup 으로 왕복하는 classic 의 골격은 그대로 사용한다. KIP-848 의 consumer 프로토콜은 그 골격 자체를 없애고 멤버별 heartbeat 로 목표 할당에 수렴한다.

차이를 가르는 축은 두 가지다. assignor 가 어디에서 실행되는가, 그리고 누가 누구를 기다려야 하는가다. leader 컨슈머의 JVM 과 그룹 단위 배리어가 결합하면 가장 느린 멤버가 전체를 붙잡는다. 계산을 브로커로 옮기고 멤버별 reconciliation 으로 바꾸면 영향을 받지 않는 파티션은 계속 소비할 수 있다. 이 두 축을 기준으로 classic 의 eager/cooperative 와 KIP-848 consumer 프로토콜을 순서대로 따라간다.

1. 리밸런스의 구성요소

리밸런스의 단계에 들어가기 전에 구성요소와 그룹의 상태 전이부터 정리해보고자 한다.

1-1. 세 가지 구성요소

역할	하는 일
GroupCoordinator	특정 브로커가 그룹 하나를 담당한다. 멤버 명단, 그룹 상태, 오프셋을 들고 있다
멤버(컨슈머)	주기적으로 heartbeat 를 보내 살아있음을 알리고, 할당받은 파티션을 소비한다
assignor	실제 파티션 분배를 계산하는 알고리즘. 이게 어디서 실행되는지가 두 프로토콜의 결정적 차이다

assignor가 실행되는 위치가 이 글 전체의 축이다. assignor 가 컨슈머의 JVM 에서 도는가 브로커에서 도는가에 따라, 리밸런스가 그룹 단위 왕복이 되기도 하고 멤버별 수렴 루프가 되기도 한다.

1-2. classic 그룹의 상태 전이

classic 프로토콜에서 리밸런스는 Stable 을 벗어나 한 바퀴 돌아오는 여정이다.

stateDiagram-v2
    [*] --> Empty
    Empty --> PreparingRebalance: 첫 JoinGroup 도착
    Stable --> PreparingRebalance: 멤버 변화 감지
    PreparingRebalance --> CompletingRebalance: 전원 JoinGroup 도착 = join phase 종료
    CompletingRebalance --> Stable: leader 의 SyncGroup 할당 수신 = sync phase 종료
    PreparingRebalance --> Empty: 전원 이탈

[!IMPORTANT]
classic eager 에서 코디네이터가 PreparingRebalance 로 전환했다고 즉시 모든 소비가 멈추는 것은 아니다. 기존 멤버는 리밸런스를 인지하고 poll 경로에서 파티션을 revoke 하기 전까지 소비할 수 있다. 각 멤버가 전체 파티션을 revoke 한 시점부터 새 할당을 받을 때까지가 그 멤버의 실제 소비 정지 구간이다.

2. classic 프로토콜

2-1. 리밸런스 라운드의 단계별 전개

한 라운드는 크게 아래와 같은 네 단계로 이루어진다.

단계	단계명	대표 요청과 상태
1단계	rebalance trigger	PreparingRebalance 전환, 응답 에러 코드 REBALANCE_IN_PROGRESS
2단계	join phase	JoinGroup 요청, JoinGroup 의 rebalance timeout 대기
3단계	client-side assignment	leader 컨슈머가 ConsumerPartitionAssignor 실행
4단계	sync phase	SyncGroup 요청과 응답, CompletingRebalance → Stable

[!NOTE]
Kafka 의 클라이언트측 할당 제안 문서는 그룹 멤버십 프로토콜을 "join phase 와 sync phase 두 단계"로 설명한다.

flowchart LR
    S1[1단계 rebalance trigger<br/>PreparingRebalance 전환] --> S2[2단계 join phase<br/>JoinGroup 배리어]
    S2 --> S3[3단계 client-side assignment<br/>leader 지명과 할당 계산]
    S3 --> S4[4단계 sync phase<br/>SyncGroup 응답]
    S4 --> ST[Stable<br/>현재 generation 의 할당 확정]

정지 시간이 길어지는 지점을 미리 말해 두면 그림을 읽기가 쉽다. join phase 는 알려진 멤버들이 다시 합류할 때까지 기다리므로, 가장 늦게 JoinGroup 을 보내는 멤버 한 명이 이 구간의 길이를 결정할 수 있다.

2-1-1. 1단계: rebalance trigger

코디네이터와 컨슈머는 멤버십이나 구독 메타데이터의 변화를 감지하면 재합류를 시작한다. Kafka 4.3 ConsumerRebalanceListener Javadoc을 기준으로 대표적인 rebalance trigger 는 다음과 같다.

• 신규 멤버의 JoinGroup 도착
• 멤버 이탈, 즉 LeaveGroup 수신
• 구독 토픽 변경
• session timeout 만료, 즉 heartbeat 가 끊긴 멤버
• 구독 중인 토픽의 파티션 수 변경
• 정규식 구독에 새로 매칭되는 토픽의 생성 또는 구독 토픽의 삭제

이 단계에서 오가는 메시지만 떼어 보면 아래와 같다.

sequenceDiagram
    participant A as Consumer A
    participant B as Consumer B
    participant GC as GroupCoordinator
    participant N as Consumer C - 신규

    Note over GC: Stable
    N->>GC: JoinGroup 신규 합류
    Note over GC: PreparingRebalance 로 전환

    A->>GC: Heartbeat 주기적 호출
    GC-->>A: REBALANCE_IN_PROGRESS
    B->>GC: Heartbeat 주기적 호출
    GC-->>B: REBALANCE_IN_PROGRESS
    Note over A,B: 각자의 다음 heartbeat 때 비로소 인지

주목할 곳은 코디네이터에서 A 와 B 로 나가는 화살표가 전부 응답 화살표라는 점이다. 코디네이터가 멤버에게 능동적으로 푸시하는 선은 그림 어디에도 없다. 각 멤버가 보내는 주기적 heartbeat 의 응답에 REBALANCE_IN_PROGRESS 에러 코드를 실어서 간접적으로 알린다. 카프카의 요청과 응답 모델이 클라이언트 주도(pull)이기 때문에 이렇게 설계된 것이다.

classic 의 heartbeat.interval.ms 기본값은 3초이므로, 정상적인 네트워크 조건에서는 trigger 발생 후 기존 멤버가 다음 heartbeat 응답을 받을 때까지 0~한 설정 주기 정도의 인지 지연이 생길 수 있다. 다만 이 시간 전체를 소비 정지로 계산하면 안 된다. KIP-62에 따라 heartbeat 는 백그라운드에서 계속되고, 실제 재합류와 revoke 콜백은 애플리케이션 스레드가 poll 로 돌아왔을 때 진행된다. 멤버는 revoke 전까지 기존 할당을 소비할 수 있다.

2-1-2. 2단계: join phase

통보받은 멤버들은 자기 구독 정보, 즉 원하는 토픽과 지원하는 assignor 목록을 담아 JoinGroup 을 다시 보낸다. eager assignor 라면 이 직전에 보유 파티션 전부를 revoke 하므로, 여기서부터 그룹 전체가 소비 정지 상태다.

[!TIP]
assignor 의 종류: partition.assignment.strategy 에 넣을 수 있는 기본 구현은 네 가지이고, "누구에게 무엇을 주는가"(분배 규칙)와 "언제 파티션을 놓는가"(rebalance protocol) 두 축으로 갈린다.

assignor	분배 규칙	프로토콜	성격
RangeAssignor	토픽별로 파티션을 정렬해 연속 구간을 나눠 준다	eager	기본 목록의 첫 항목이라 기본 선택된다. 토픽 여러 개를 같이 구독하면 앞 번호 컨슈머에 쏠릴 수 있다
RoundRobinAssignor	전체 파티션을 한 줄로 세워 멤버에게 번갈아 준다	eager	균등하지만 리밸런스마다 배치가 통째로 흔들린다
StickyAssignor	최대한 균등하게 나누되 직전 할당을 최대한 유지한다	eager	이동은 줄지만 revoke 는 여전히 전면적이다
CooperativeStickyAssignor	sticky 와 같은 계산	cooperative	이동 대상 파티션만 revoke 한다. KIP-429 의 구현체

두 축이 왜 따로인지가 핵심이다. sticky 는 "몇 개가 움직이는가"를 줄이고, cooperative 는 "움직이지 않는 파티션까지 멈추는가"를 없앤다. StickyAssignor 는 제자리에 남을 파티션까지 일단 전부 놓았다가 다시 받지만, 재할당 후 상태 복구 비용이 큰 워크로드에서는 여전히 값을 한다.

eager 와 cooperative 를 가르는 실체는 ConsumerPartitionAssignor 의 supportedProtocols() 값이다. 다만 코디네이터가 이 값을 직접 비교하는 것은 아니고, JoinGroup 에 실린 assignor 이름 목록에서 모든 멤버가 지원하는 이름을 고른다. 선택된 assignor 의 supportedProtocols()에 따라 각 클라이언트가 revoke 방식을 결정한다. 공식 Javadoc이 cooperative 활성화에 모든 컨슈머가 해당 assignor 를 사용해야 한다고 명시하는 이유다.

Kafka 4.3 consumer 설정 문서의 기본 목록은 [RangeAssignor, CooperativeStickyAssignor] 이며 앞의 RangeAssignor 가 선택된다. cooperative 로 전환하려면 모든 멤버의 목록에서 RangeAssignor 를 제거해야 한다. [[3|consumer 프로토콜]]로 넘어가면 이 client-side 클래스 선택은 group.consumer.assignors와 group.remote.assignor의 server-side 선택으로 대체된다.

느린 멤버가 하나 섞여 있을 때 이 phase 가 어떻게 늘어지는지를 그림으로 보면 이렇다.

sequenceDiagram
    participant A as Consumer A
    participant B as Consumer B - 느린 멤버
    participant GC as GroupCoordinator

    Note over A,B: eager 라면 여기서 전 파티션 revoke → 소비 정지
    A->>GC: JoinGroup 구독정보 + assignor 목록
    Note over GC: A 도착. 아직 전원이 아니라 라운드를 닫지 않음
    Note over B: 무거운 poll 처리 중이라 아직 못 보냄
    Note over A: 파티션을 이미 놓은 채로 대기
    B->>GC: JoinGroup 뒤늦게 도착
    Note over GC: 전원 도착 → 배리어 해제

핵심은 코디네이터가 알고 있는 멤버 전원이 모일 때까지 라운드를 닫지 않는다는 점이다. 이게 배리어(barrier)의 실체다. KIP-848 은 이 구조를 group-wide synchronization barrier라고 부른다.
즉, 가장 늦게 오는 한 명이 전체 출발 시각을 결정한다.

동적 멤버만 있는 일반적인 그룹에서 배리어는 다음 두 경로로 열린다.

flowchart TD
    P[PreparingRebalance] --> W{알고 있는 멤버 전원이<br/>JoinGroup 을 보냈나}
    W -- 예 --> C[배리어 해제<br/>CompletingRebalance 로]
    W -- 아니오 --> T{rebalance timeout 경과}
    T -- 아니오 --> W
    T -- 예 --> K[미도착 동적 멤버를 명단에서 빼고 진행]
    K --> C

KIP-62에 따라 Java client 는 max.poll.interval.ms 값을 JoinGroup 의 rebalance timeout 으로 보낸다. 멤버마다 값이 다르면 코디네이터는 그룹에서 가장 큰 rebalance timeout 을 사용한다. 위 그림의 루프가 오래 돌수록 eager 멤버가 할당을 비운 시간도 길어진다.

• 느린 멤버 하나가 전원을 붙잡는 경우: 어떤 멤버가 무거운 레코드 처리를 끝내지 못해 poll 로 돌아오지 않으면 JoinGroup 도 늦어진다. 이미 revoke 를 마친 eager 멤버들은 그 멤버의 합류나 timeout 을 기다린다.
• 응답하지 않는 동적 멤버를 제거하는 경우: 프로세스가 죽어 heartbeat 가 끊기면 session timeout 으로 제거된다. 이미 리밸런스가 진행 중인데 동적 멤버가 재합류하지 않으면 rebalance timeout 으로도 제거될 수 있다. KIP-62의 정의대로 둘 중 먼저 충족되는 경로가 그룹을 진행시킨다.

[!WARNING]
정적 멤버십(group.instance.id)에서는 규칙이 다르다. KIP-345에 따라 미도착 정적 멤버는 rebalance timeout 만으로 명단에서 제거되지 않고 session timeout 까지 식별자를 유지한다. Kafka 4.3 consumer 설정 문서도 정적 멤버가 max.poll.interval.ms 를 넘기면 파티션을 즉시 재할당하지 않고 heartbeat 를 중단한 뒤 session timeout 에 재할당한다고 설명한다. 짧은 재시작을 흡수하는 대신 실제 이탈 시 재할당이 늦어질 수 있는 트레이드오프다.

2-1-3. 3단계: client-side assignment

전원이 모이면 코디네이터는 generation id 를 하나 올리고, 멤버 중 하나를 leader 로 지명한다. 이 단계의 그림에서 응답이 차별된다는 것이다.

sequenceDiagram
    participant A as Consumer A - leader 로 지명됨
    participant B as Consumer B
    participant N as Consumer C - 신규
    participant GC as GroupCoordinator

    Note over GC: generation++ 후 멤버 하나를 leader 로 지명
    GC-->>A: JoinGroup 응답 - 전원의 구독정보 전달
    GC-->>B: JoinGroup 응답 - 빈 값
    GC-->>N: JoinGroup 응답 - 빈 값
    Note over A: partition.assignment.strategy 에 지정한<br/>assignor 클래스를 A 의 JVM 에서 실행
    Note over GC: 브로커는 이 계산에 관여하지 않음

여기가 classic 의 가장 특이한 지점이다. 할당 계산은 브로커가 아니라 leader 컨슈머의 JVM 에서 일어난다. 이 설계를 가리키는 이름이 곧 client-side assignment 이고, 이걸 도입한 설계 문서의 제목 자체가 "Kafka Client-side Assignment Proposal" 이다. partition.assignment.strategy 에 지정한 ConsumerPartitionAssignor 구현이 로드되고 실행되는 자리가 바로 여기다. 이 설정이 "클라이언트측 설정"인 이유가 이것이다.

@Configuration
class ClassicConsumerConfig {

    @Bean
    fun consumerFactory(): ConsumerFactory<String, String> = DefaultKafkaConsumerFactory(
        mapOf(
            ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG to "kafka:9092",
            ConsumerConfig.GROUP_ID_CONFIG to "settlement-worker",
            // 이 클래스는 브로커가 아니라, leader 로 뽑힌 컨슈머의 JVM 에서 실행된다
            ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG to
                listOf(CooperativeStickyAssignor::class.java.name),
            // ...
        ),
    )
}

핵심은 PARTITION_ASSIGNMENT_STRATEGY_CONFIG 의 값이 클래스 이름이라는 점이다. 브로커는 이 문자열이 무슨 알고리즘인지 알지 못한다. 멤버들이 신고한 목록에서 모든 멤버가 공통으로 지원하는 assignor 이름을 골라주는 역할까지만 한다.

2-1-4. 4단계: sync phase

계산이 끝나면 전원이 SyncGroup 을 보내는데, 이 phase 의 그림에서도 요청이 대칭이 아니다.

sequenceDiagram
    participant A as Consumer A - leader
    participant B as Consumer B
    participant N as Consumer C - 신규
    participant GC as GroupCoordinator

    A->>GC: SyncGroup 전체 할당표 포함
    B->>GC: SyncGroup 빈 요청
    N->>GC: SyncGroup 빈 요청
    Note over GC: 할당표를 저장하고 멤버별로 잘라 응답
    GC-->>A: 내 몫만
    GC-->>B: 내 몫만
    GC-->>N: 내 몫만
    Note over A,N: 할당 콜백 실행 후 소비 재개
    Note over GC: leader 의 할당 수신 후 Stable

leader 의 요청에만 전체 할당표가 실려 있고 나머지는 사실상 "결과 주세요"라는 빈 요청이다. 코디네이터는 그 할당표를 저장한 뒤, 각 멤버의 SyncGroup 응답에 그 멤버 몫만 잘라서 돌려준다. generation id 는 join phase 가 성공적으로 끝날 때 이미 증가하며, leader 의 SyncGroup 에 담긴 할당을 코디네이터가 받으면 그룹은 Stable 로 전환할 수 있다. 각 멤버는 자기 SyncGroup 응답을 받은 뒤 할당 콜백을 거쳐 소비를 재개한다. Spring Kafka 에서는 revoke 와 assign 시점을 리스너로 받아 볼 수 있다.

class RebalanceLogger : ConsumerAwareRebalanceListener {

    override fun onPartitionsRevokedBeforeCommit(
        consumer: Consumer<*, *>,
        partitions: Collection<TopicPartition>,
    ) {
        // eager 면 보유 파티션 전체가, cooperative 면 이동분만 담겨 온다
        log.info("revoked: {}", partitions)
    }

    override fun onPartitionsAssigned(
        consumer: Consumer<*, *>,
        partitions: Collection<TopicPartition>,
    ) {
        log.info("assigned: {}", partitions)
    }
}

@Bean
fun kafkaListenerContainerFactory(
    consumerFactory: ConsumerFactory<String, String>,
) = ConcurrentKafkaListenerContainerFactory<String, String>().apply {
    this.consumerFactory = consumerFactory
    containerProperties.setConsumerRebalanceListener(RebalanceLogger())
}

정상적인 소유권 이전에서 onPartitionsRevokedBeforeCommit 에 찍히는 목록은 eager 면 전체 할당, cooperative 면 이동 대상 부분집합이다. 예외적으로 멤버가 펜싱되거나 소유권을 이미 잃은 경우에는 revoke 가 아니라 lost 콜백 경로를 타므로, 이 로그 하나만으로 모든 리밸런스 상황을 설명할 수는 없다.

generation id 는 단순한 카운터가 아니라 펜싱(fencing) 장치다. 그룹 관리로 구독한 멤버의 OffsetCommit 요청에는 generation id 와 member id 가 실리고, 구세대 멤버가 뒤늦게 보낸 커밋은 ILLEGAL_GENERATION 같은 오류로 거부된다. 네트워크 지연으로 뒤처진 좀비 멤버가 이미 남의 것이 된 파티션의 오프셋을 덮어쓰는 사고를 막아 주는 셈이다.

2-2. classic protocol 전체 플로우

sequenceDiagram
    participant A as Consumer A
    participant B as Consumer B
    participant GC as GroupCoordinator
    participant N as Consumer C - 신규

    Note over GC: Stable
    N->>GC: JoinGroup 신규 합류
    Note over GC: rebalance trigger → PreparingRebalance

    A->>GC: Heartbeat
    GC-->>A: REBALANCE_IN_PROGRESS
    B->>GC: Heartbeat
    GC-->>B: REBALANCE_IN_PROGRESS

    Note over A,B: eager 라면 여기서 전 파티션 revoke → 소비 정지
    A->>GC: JoinGroup 구독정보 + assignor 목록
    B->>GC: JoinGroup 구독정보 + assignor 목록
    Note over GC: join phase - 전원 도착까지 대기 = 배리어

    Note over GC: generation++, A 를 leader 로 지명
    GC-->>A: JoinGroup 응답 - 전원의 구독정보
    GC-->>B: JoinGroup 응답 - 빈 값
    GC-->>N: JoinGroup 응답 - 빈 값

    Note over A: client-side assignment - leader 의 JVM 에서 실행
    A->>GC: SyncGroup 전체 할당표
    B->>GC: SyncGroup 빈 요청
    N->>GC: SyncGroup 빈 요청

    GC-->>A: 내 몫만
    GC-->>B: 내 몫만
    GC-->>N: 내 몫만
    Note over GC: sync phase 종료 - Stable, 현재 generation 의 할당 확정

2-3. incremental cooperative rebalancing: 라운드를 두 번 도는 이유

eager 와 cooperative 는 같은 기계 위에서 도는 서로 다른 전략이다. 공식 이름으로는 각각 eager rebalancing 과 incremental cooperative rebalancing(KIP-429)이라고 부른다. 차이는 "언제 파티션을 놓느냐"에 있고, 그래서 [[2-1-2|join phase]] 의 모습이 달라진다.

2-3-1. 1라운드: 이동 대상 식별과 revoke

cooperative 는 JoinGroup 을 보내기 전에 전체 파티션을 미리 revoke 하지 않는다. 1라운드의 leader 는 의도한 최종 할당을 계산하되, 이전 소유자가 아직 들고 있는 이동 파티션을 새 소유자의 결과에서 제외한다. 기존 소유자는 SyncGroup 응답에서 빠진 파티션만 revoke 하고 즉시 다음 리밸런스를 요청한다.

sequenceDiagram
    participant A as Consumer A - p3 보유
    participant B as Consumer B
    participant GC as GroupCoordinator

    Note over A: 파티션을 놓지 않은 채 참여
    A->>GC: JoinGroup
    B->>GC: JoinGroup
    Note over A: leader 의 JVM 에서 할당 계산
    A->>GC: SyncGroup 할당표 - p3 이동은 보류
    GC-->>A: 내 몫에 p3 이 빠져 있음
    Note over A: SyncGroup 응답 처리 중 p3 만 revoke
    GC-->>B: 내 몫 - 아직 p3 은 비어 있음
    Note over A,B: 1라운드 끝에는 p3 만 소유권 공백

1라운드가 끝난 시점에 A 는 p3 을 놓았지만 B 는 아직 받지 못했다. KIP-429은 이전 소유자의 revoke 를 확인하기 전에 새 소유자에게 같은 파티션을 주지 않는다. p3 이 더는 어떤 멤버의 owned partitions 에도 나타나지 않는 다음 라운드에서야 B 에게 할당할 수 있다.

2-3-2. 2라운드: 새 소유자에게 할당

이동 파티션만 revoke 한 기존 소유자는 즉시 JoinGroup 을 다시 보내 2라운드를 시작한다. 이 라운드에서 코디네이터와 leader 가 p3 에 기존 소유자가 없음을 확인하면 새 주인에게 할당한다.

sequenceDiagram
    participant A as Consumer A
    participant B as Consumer B
    participant GC as GroupCoordinator

    Note over A: p3 만 revoke, p1 p2 는 계속 소비
    A->>GC: JoinGroup 재합류 트리거
    B->>GC: JoinGroup
    A->>GC: SyncGroup 할당표
    GC-->>A: p1 p2
    GC-->>B: p3 추가
    Note over B: p3 소비 시작
    Note over GC: Stable

두 라운드를 하나의 판단 흐름으로 압축하면 아래와 같다.

flowchart TD
    S[rebalance trigger] --> R1[1라운드 join phase/sync phase]
    R1 --> D{이동 대상 파티션 있나}
    D -- 없음 --> ST[Stable]
    D -- 있음 --> RV[해당 멤버가 이동분만 revoke<br/>나머지 파티션은 계속 소비]
    RV --> R2[2라운드 join phase/sync phase]
    R2 --> AS[새 주인에게 할당]
    AS --> ST

라운드 수는 늘지만 각 라운드에서 멈추는 건 이동분뿐이라, 체감 정지가 크게 줄어든다. 왕복 횟수와 정지 범위를 맞바꾼 설계다. 그렇다고 배리어 자체가 사라진 건 아니어서, [[2-1-2|앞에서 본]] "가장 느린 멤버가 전체를 붙잡는" 성질은 cooperative 에서도 그대로 남는다. 오히려 라운드가 두 번이니 그 배리어를 두 번 통과한다.

3. consumer 프로토콜(KIP-848)

classic 프로토콜의 플로우와 비교해보면 KIP-848이 어떤 과정을 없앤 건지 확인할 수 있다.. [[2-2|이어 붙인 그림]]의 세로줄 전체, 그러니까 join phase 와 sync phase 로 이루어진 그룹 단위 왕복이 통째로 사라진다.

Apache Kafka 4.3 Consumer Rebalance Protocol 문서는 이 프로토콜을 Kafka 4.0 부터 GA 로 설명한다. 브로커에서는 활성화되어 있지만 컨슈머의 기본값은 여전히 classic 이므로, 실제 사용에는 group.protocol=consumer 설정이 필요하다.

3-1. 사라진 세 가지

• leader 컨슈머와 기존 client-side assignment 없음 → Kafka 4.3 의 일반 컨슈머에서는 특정 JVM 이 그룹 전체의 할당을 책임지지 않는다
• sync phase(SyncGroup) 없음 → 별도의 배포 왕복이 없다
• join phase 의 배리어 없음 → 전원이 모일 때까지 기다리는 지점 자체가 없다

새 Consumer 그룹에서는 JoinGroup/SyncGroup/Heartbeat 가 하던 멤버십/할당/생존 확인을 ConsumerGroupHeartbeat 가 맡는다. 코디네이터가 server-side assignment 로 target assignment 를 계산하고, 멤버별 heartbeat 응답에 현재 사용할 수 있는 할당을 증분으로 실어 보낸다. KIP-848 은 각 멤버가 그 목표로 이동하는 과정을 reconciliation(수렴)이라고 부른다. 리밸런스가 "한 번의 그룹 이벤트"에서 "멤버별 상태 수렴"으로 바뀐 것이다.

3-2. reconciliation 루프의 단계별 전개

3-2-1. 0단계: server-side assignment 와 target assignment

멤버 합류/이탈, 구독 변경, 토픽 메타데이터 변경으로 group epoch 가 올라가면 코디네이터가 새 할당을 계산한다. 멤버는 heartbeat 로 구독과 현재 보유 파티션을 보고하고, 코디네이터는 저장된 그룹 상태를 근거로 "이렇게 되어야 한다"는 목표를 만든다. 이 목표 상태의 공식 이름이 target assignment 다.

flowchart LR
    HB[멤버들의 ConsumerGroupHeartbeat<br/>현재 보유 파티션 보고] --> GC[GroupCoordinator]
    GC --> AS[server-side assignor<br/>uniform 또는 range]
    AS --> T[target assignment<br/>도달해야 할 목표 상태]
    T --> D[각 멤버의 heartbeat 응답에<br/>증분 지시를 실어 보냄]

classic 과 비교하면 차이가 한눈에 보인다. 매 리밸런스마다 계산 입력을 다시 모으려고 전원이 같은 JoinGroup 라운드에 도착할 때까지 기다리는 지점이 없다. 코디네이터는 지속적으로 보관한 그룹 상태로 target assignment 를 계산하고, 각 멤버를 독립적으로 수렴시킨다.

3-2-2. 1단계: 할당 차이에 따른 revoke

target assignment 에 따르면 p3 은 B 의 몫인데 지금은 A 가 들고 있다. 그러면 코디네이터는 A 에게만 p3 이 빠진 할당을 보낸다. 별도의 revoke RPC가 있는 것은 아니며, A 가 현재 로컬 할당과 heartbeat 응답의 할당 차이를 계산해 p3 을 revoke 한다.

sequenceDiagram
    participant A as Consumer A - p1 p2 p3 보유
    participant B as Consumer B - p4 보유
    participant GC as GroupCoordinator

    A->>GC: Heartbeat 보유 p1 p2 p3 보고
    GC-->>A: 할당 응답 p1 p2 - p3 제외
    Note over A: p3 만 정리, p1 p2 는 계속 소비
    B->>GC: Heartbeat 보유 p4 보고
    GC-->>B: 지시 없음
    Note over B: p4 를 한 번도 멈추지 않고 소비 중

여기서 B 에게 내려간 응답이 "지시 없음"이라는 점이 중요하다. B 는 자기 기존 파티션을 계속 소비한다. classic eager 라면 B 도 전체 할당을 revoke 하고 배리어 앞에 섰겠지만, Consumer 프로토콜에서는 할당이 바뀌지 않는 멤버를 전역 라운드에 세우지 않는다.

3-2-3. 2단계: revoke 완료 보고와 새 할당

A 가 p3 정리를 마치면 즉시 보내는 다음 heartbeat 에 그 사실을 보고한다. 코디네이터는 그 보고를 받고 나서야 B 에게 p3 을 사용할 수 있는 할당으로 내려준다.

sequenceDiagram
    participant A as Consumer A
    participant B as Consumer B
    participant GC as GroupCoordinator

    A->>GC: Heartbeat p3 revoke 완료 보고
    Note over GC: p3 의 소유권 공백 확인
    B->>GC: Heartbeat
    GC-->>B: 할당 응답 p3 p4
    Note over B: p4 에 이어 p3 소비 시작, reconciliation 완료

주목할 점은 B 가 A 를 기다린 게 아니라, 코디네이터가 B 에게 아직 알려주지 않았을 뿐이라는 것이다. B 는 그동안 자기 파티션을 정상적으로 소비하고 있었다. 파티션 하나의 관점에서 상태 이동을 그리면 정지 범위가 어디까지인지가 분명해진다.

stateDiagram-v2
    [*] --> A소유: 초기 상태
    A소유 --> 공백: A 가 p3 만 revoke
    공백 --> B소유: 코디네이터가 B 에게 assign
    B소유 --> [*]: reconciliation 완료
    note right of 공백
        멈춰 있는 건 p3 하나뿐이다.
        p1 p2 p4 는 내내 소비 중이다.
    end note

classic eager 에서는 모두가 전체 할당을 놓았지만, 여기서는 정상적인 소유권 이전 기준으로 이동하는 파티션 하나만 잠깐 비어 있게 된다. 정지의 단위가 그룹에서 파티션으로 내려온 셈이다. 펜싱이나 세션 만료처럼 소유권을 잃는 예외 경로에서는 멤버가 전체 파티션을 abandon 하고 onPartitionsLost를 호출할 수 있다.

3-2-4. 이어 붙인 한 번의 reconciliation

세 단계를 한 장으로 붙이면 아래와 같다.

sequenceDiagram
    participant A as Consumer A
    participant B as Consumer B
    participant GC as GroupCoordinator

    Note over GC: server-side assignor 가 target assignment 계산
    A->>GC: Heartbeat 현재 보유 파티션 보고
    GC-->>A: 할당 응답 p1 p2 - p3 제외
    Note over A: p3 만 정리, p1 p2 는 계속 소비

    B->>GC: Heartbeat
    GC-->>B: 대기 - A 가 아직 안 놓음

    A->>GC: Heartbeat p3 revoke 완료
    B->>GC: Heartbeat
    GC-->>B: 할당 응답 p3 p4
    Note over B: p3 소비 시작, reconciliation 완료

[[2-2|classic 의 전체 그림]]과 나란히 놓고 보면 차이가 형태로 드러난다. classic eager 는 모든 멤버가 같은 라운드에서 전체 할당을 놓고, classic cooperative 도 revoke 범위는 줄지만 전역 배리어는 통과한다. Consumer 프로토콜에서는 멤버마다 heartbeat 로 각자 수렴하므로 세로로 정렬된 그룹 배리어 선이 없다.

[!NOTE]
KIP-848 의 group epoch 는 구독이나 멤버십이 바뀌어 새 target assignment 가 필요한 시점을 나타내고, member epoch 는 각 멤버가 그 목표에 어디까지 수렴했는지를 나타낸다. 요청 펜싱과 OffsetCommit 검증에는 member epoch 가 사용된다. [[2-1-4|앞에서 본]] 전역 generation 기반 검증을 멤버별 진행 상태로 세분화한 구조다.

3-3. server-side assignor

할당 계산이 브로커로 옮겨왔으니 설정 키도 바뀐다.

@Bean
fun consumerFactory(): ConsumerFactory<String, String> = DefaultKafkaConsumerFactory(
    mapOf(
        ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG to "kafka:9092",
        ConsumerConfig.GROUP_ID_CONFIG to "settlement-worker",
        "group.protocol" to "consumer",
        // 이 assignor 는 브로커에서 실행된다. uniform 또는 range
        "group.remote.assignor" to "uniform",
    ),
)

remote 라는 이름이 관점을 그대로 드러낸다 -- 컨슈머 입장에서 원격(브로커)에 있는 assignor 를 지정하는 것이기 때문이다. [[2-1-3]]의 설정이 클래스 이름이었던 것과 달리, 여기서는 브로커가 알아듣는 문자열 식별자를 넘긴다는 점도 대비된다.

4. classic 과 consumer 를 나란히 놓으면

앞의 흐름을 같은 기준으로 맞춰 놓으면 KIP-848 이 무엇을 개선했는지가 분명해진다. cooperative 는 classic 의 정지 범위를 줄였고, Consumer 프로토콜은 정지를 만들어 내던 그룹 단위 동기화 구조를 바꿨다.

비교축	classic eager	classic cooperative	consumer(KIP-848)
할당 계산 위치	leader 컨슈머	leader 컨슈머	GroupCoordinator
핵심 요청	JoinGroup → SyncGroup	JoinGroup → SyncGroup	ConsumerGroupHeartbeat
동기화 단위	그룹 전체 배리어	그룹 전체 배리어 유지, 이동이 있으면 연속 라운드	멤버별 reconciliation
정상 재할당의 revoke 범위	보유 파티션 전체	이동 대상 파티션만	이동 대상 파티션만
진행 상태	generation 단위	generation 단위	group epoch/member epoch 단위
영향을 받는 범위	그룹 전체	이동 파티션은 줄지만 느린 멤버의 배리어 영향은 남음	이동 파티션과 관련 멤버, 나머지는 계속 소비

표에서 중요한 행은 revoke 범위가 아니라 동기화 단위다. cooperative 와 Consumer 모두 이동분만 내려놓지만, cooperative 는 전원이 같은 라운드를 통과해야 한다. Consumer 프로토콜은 멤버마다 현재 할당을 보고하고 각자 목표 할당으로 수렴하므로, 느린 멤버 하나가 그룹 전체의 출발 시점을 결정하는 구조가 없다.

4-1. cooperative 는 consumer 프로토콜의 이전 이름이 아니다

둘은 같은 문제를 서로 다른 층에서 푼다. KIP-429의 incremental cooperative rebalancing 은 classic 프로토콜 안에서 파티션을 언제 놓을지를 바꾼다. 1라운드의 SyncGroup 결과에서 기존 소유자가 이동 파티션만 revoke 하고, 다음 라운드에서 새 소유자에게 넘긴다. JoinGroup, leader 의 client-side assignment, SyncGroup, generation 은 그대로 남는다.

KIP-848은 그 라운드를 누가 조율할지를 바꾼다. 코디네이터가 target assignment 를 만들고, 멤버별 heartbeat 응답의 할당 차이로 revoke 와 assign 을 유도한다. cooperative 가 왕복 횟수와 정지 범위를 맞바꿨다면, Consumer 프로토콜은 왕복을 성립시키던 전역 배리어를 제거한 것이다. KIP-848 원안도 cooperative 프로토콜조차 그룹 단위 배리어에 의존한다는 점을 기존 구조의 한계로 명시한다.

4-2. 설정의 소유권도 브로커로 이동한다

실행 위치가 달라지면 같은 이름의 설정을 그대로 옮길 수 없다. Kafka 4.3 공식 문서는 Consumer 프로토콜에서 heartbeat.interval.ms, session.timeout.ms, partition.assignment.strategy를 사용할 수 없다고 정리한다.

classic 에서의 책임	Consumer 프로토콜에서의 책임
클라이언트의 heartbeat.interval.ms	브로커의 group.consumer.heartbeat.interval.ms
클라이언트의 session.timeout.ms	브로커의 group.consumer.session.timeout.ms
클라이언트의 partition.assignment.strategy	브로커의 group.consumer.assignors
leader JVM 이 assignor 클래스 실행	코디네이터가 server-side assignor 실행
각 클라이언트가 assignor 우선순위 신고	클라이언트는 필요할 때 group.remote.assignor로 서버 assignor 이름만 선택

기본 server-side assignor 는 uniform 과 range 다. 공식 마이그레이션 표는 RangeAssignor를 range 로, RoundRobinAssignor/StickyAssignor/CooperativeStickyAssignor를 uniform 으로 대응시킨다. uniform 과 range 모두 기존 할당을 최대한 유지하는 sticky 성질을 가지므로, Consumer 프로토콜 위에 CooperativeStickyAssignor를 한 겹 더 얹는 구조는 성립하지 않는다. partition.assignment.strategy 자체가 이 프로토콜에서는 실행되지 않는다.

4-3. 전환 전에 확인할 경계

Consumer 프로토콜은 Kafka 4.0 부터 GA 지만, 설정 하나만 바꾼다고 모든 그룹이 같은 조건으로 전환되는 것은 아니다.

• 브로커와 클라이언트 버전: 브로커뿐 아니라 컨슈머도 Consumer 프로토콜을 지원해야 한다. Java client 는 Kafka 4.0 부터 정식 지원한다.
• 온라인 전환 조건: rolling 방식의 무중단 전환은 브로커의 group.consumer.migration.policy가 upgrade 를 허용하고, classic 그룹의 assignor 가 커스텀 메타데이터를 할당 정보에 심지 않는 경우에 지원된다. 조건을 만족하지 않으면 그룹을 비운 뒤 프로토콜을 바꾸는 offline 전환이 필요하다.
• 커스텀 할당 로직: Kafka 4.3 기준 client-side assignor 는 Consumer 프로토콜에서 지원되지 않는다. 브로커에 ConsumerGroupPartitionAssignor 구현을 배포하는 server-side 확장은 가능하지만, 클라이언트마다 코드를 싣는 기존 방식과 운영 경계가 다르다.
• 설정 소유권: heartbeat 와 session timeout 이 브로커 설정으로 이동한다. 특정 애플리케이션만의 값을 조정하던 운영 방식이라면 전환 전에 클러스터/그룹 설정 정책을 함께 정리해야 한다.

따라서 전환 판단은 "CooperativeStickyAssignor 보다 빠른가"로 끝나지 않는다. 커스텀 메타데이터와 assignor 의 존재 여부, timeout 설정의 소유 주체, rolling migration 가능성까지 확인해야 한다. 이 조건을 통과하면 Consumer 프로토콜은 cooperative 의 정지 범위 축소를 유지하면서 classic 의 전역 배리어까지 제거한다.

마무리

• classic 의 리밸런스는 그룹 단위 왕복이다. rebalance trigger(heartbeat 응답으로 간접 통보) → join phase(전원 JoinGroup 배리어) → client-side assignment(leader 의 JVM) → sync phase(SyncGroup) 순으로 한 바퀴를 돈다. 이 중 프로토콜이 phase 로 이름 붙인 것은 가운데 둘뿐이다.
• eager 리밸런스를 길게 만드는 핵심 대기 지점은 join phase 의 배리어다. 가장 늦게 재합류하는 멤버가 라운드 완료 시점을 결정할 수 있기 때문이다. 다만 trigger 인지 전에는 기존 할당을 계속 소비할 수 있으므로 코디네이터의 PreparingRebalance 체류 시간 전체가 곧 소비 정지 시간은 아니다.
• incremental cooperative rebalancing 은 이 기계를 그대로 쓰되 "1라운드 끝에 이동분만 revoke 하고, 다음 라운드에 새 소유자에게 넘긴다"로 정지 범위를 줄인 전략이다. 왕복 횟수를 늘려 정지 범위를 산 셈이다.
• KIP-848 의 Consumer 프로토콜은 그룹 전체가 함께 도는 왕복을 없애고, target assignment 계산 → 할당 차이에 따른 revoke → 완료 보고 → 새 할당으로 이어지는 reconciliation으로 대체했다. 정상 재할당에서 멈추는 단위가 그룹 전체에서 이동 파티션으로 내려온다.
• group.protocol=consumer에서는 partition.assignment.strategy를 사용할 수 없으므로 CooperativeStickyAssignor를 겹쳐 적용할 수 없다. 정상 재할당의 incremental 동작은 Consumer 프로토콜이 담당하고, 기본 server-side uniform/range assignor 는 기존 할당을 최대한 유지하는 sticky 성질을 제공한다.

출처

• Kafka Client-side Assignment Proposal — join phase 와 sync phase, leader 의 할당 계산
• KIP-62: Allow consumer to send heartbeats from a background thread — max.poll.interval.ms, rebalance timeout, heartbeat thread
• KIP-345: Introduce static membership protocol — 정적 멤버의 session timeout 동작
• KIP-429: Kafka Consumer Incremental Rebalance Protocol — incremental cooperative rebalancing
• KIP-848: The Next Generation of the Consumer Rebalance Protocol — server-side assignment, target assignment, reconciliation, epoch
• Apache Kafka 4.3 Consumer Configs — classic 기본값, assignor 목록, timeout 설정
• Apache Kafka 4.3 ConsumerRebalanceListener — 리밸런스 trigger 와 revoke 범위
• Apache Kafka 4.3 CooperativeStickyAssignor — cooperative 활성화 조건
• Apache Kafka 4.3 Consumer Rebalance Protocol — GA 버전, 설정 변화, assignor 대응, 전환 조건과 제한사항
• Apache Kafka 4.3 Broker Configs — Consumer 프로토콜 migration policy