Share Groups(KIP-932) — 파티션 하나를 여러 컨슈머가 나눠 먹는다
Kafka Share Groups(KIP-932) 및 프로듀서 ID 만료(KIP-854) 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — Apache Kafka KIP-932(Queues for Kafka), KIP-854(Separate configuration for producer ID expiry), morling.dev 기술 블로그 Apache Kafka KIP-932: Queues for Kafka (Early Access, 4.0)
이 모듈을 다 읽으면
- Share Group이 kafka-learn-07의 컨슈머 그룹(파티션당 컨슈머 1개 고정)과 근본적으로 다른 소비 모델임을 설명할 수 있다
- 레코드의 Available→Acquired→Acknowledged/Archived 상태 전이와 delivery count가 poison pill 문제를 어떻게 막는지 설명할 수 있다
kafka-learn-07에서 다룬 '파티션 하나는 그룹 안에서 컨슈머 하나만 담당한다'는 전통적 컨슈머 그룹 모델을 전제로, Kafka 4.0에 얼리 액세스로 도입된 Share Group이 이 제약을 어떻게 깨고 큐(queue)에 가까운 소비 모델을 제공하는지 정리한다.
파티션당 컨슈머 1개라는 오랜 제약을 깬다
전통적 컨슈머 그룹은 kafka-learn-07에서 다룬 것처럼 한 파티션을 그룹 안의 컨슈머 정확히 하나가 담당한다 — 그래서 컨슈머 병렬성의 상한은 파티션 개수로 정해진다. Share Group은 이 규칙을 깨고, 같은 파티션의 메시지를 그룹 안의 여러 컨슈머가 동시에 나눠 처리할 수 있게 한다. 그 결과 파티션 수보다 (활성) 컨슈머 수가 더 많아질 수 있고, 파티션이 몇 개 안 되거나 심지어 1개뿐이어도 높은 수준의 컨슈머 병렬성을 얻을 수 있다.
핵심 포인트
- 전통적 컨슈머 그룹: 파티션 1개=컨슈머 1개 고정, 병렬성 상한=파티션 수 (kafka-learn-07)
- Share Group: 같은 파티션을 여러 컨슈머가 동시에 나눠 처리 — 파티션 수보다 컨슈머가 많아도 되고, 파티션이 적어도 높은 병렬성 확보 가능
레코드별 확인응답과 상태 전이 — Available/Acquired/Acknowledged/Archived
전통적 컨슈머는 오프셋 하나로 '여기까지 처리 완료'를 표시하는 오프셋 커밋 방식이지만, Share Group은 레코드 하나하나를 개별적으로 확인응답(acknowledge)할 수 있다 — ACCEPT(정상 처리), RELEASE(일시적 오류라 다시 배달받고 싶음), REJECT(재시도 불가능한 오류) 세 가지로 응답한다. 각 레코드는 Available(소비 대기)→Acquired(어떤 컨슈머가 가져간 상태)→Acknowledged(처리 완료) 또는 Archived(포기) 상태를 오가며, 이 창(window)의 하한을 share-partition start offset(SPSO), 상한을 share-partition end offset(SPEO)이라 부른다.
핵심 포인트
- 레코드별 개별 확인응답: ACCEPT(정상)/RELEASE(재배달 요청)/REJECT(재시도 불가) — 오프셋 하나로 뭉뚱그리는 방식이 아님
- 레코드 상태: Available→Acquired→Acknowledged/Archived, 창의 하한·상한이 SPSO/SPEO
delivery count — poison pill이 파티션 전체를 막는 걸 방지한다
모든 레코드는 배달 횟수(delivery count)를 갖고, 어떤 컨슈머가 그 레코드를 가져갈(acquire) 때마다 이 값이 증가한다. group.share.delivery.attempt.limit(브로커 설정)에 도달하면 그 레코드는 더 이상 재배달 대상이 되지 않고 Archived 상태로 넘어간다 — 이는 처리 불가능한 메시지 하나('poison pill') 때문에 무한 재시도 루프에 빠지는 것을 막는 안전장치다. 전통적 컨슈머 그룹에서는 오프셋 순서를 지켜야 해서 처리 안 되는 레코드 하나가 그 뒤 전체를 막는 head-of-line blocking이 생길 수 있는데, Share Group의 레코드 단위 확인응답+delivery count는 이 문제를 구조적으로 완화한다.
핵심 포인트
- delivery count: 레코드가 acquire될 때마다 증가, group.share.delivery.attempt.limit(기본 5) 도달 시 Archived로 전환해 무한 재시도(poison pill) 방지
- 전통 컨슈머 그룹의 head-of-line blocking(처리 안 되는 레코드 하나가 뒤 전체를 막는 문제)을 레코드 단위 확인응답으로 구조적으로 완화