Kafka 4.x 이후 리밸런싱 프로토콜 변화

— 왜 “컨슈머가 파티션을 나누지 않게” 되었나

Kafka 4.x에 들어서면서 컨슈머 리밸런싱 모델이 구조적으로 바뀌었다.

이 변화의 핵심은 **“리밸런싱 로직을 컨슈머에서 브로커로 옮겼다”**는 점이다.

이 글은 Apache Kafka 4.x 이후의 리밸런싱 프로토콜 변화를

왜 바뀌었는지 → 무엇이 달라졌는지 → 운영에서 뭐가 좋아졌는지 순서로 정리한다.

---

1. 기존 리밸런싱 모델의 근본적 한계

Kafka 3.x까지의 구조 (Classic Consumer Group)

• 컨슈머가 직접 파티션 할당
• 흐름:
  1. 그룹 코디네이터가 멤버 목록 전달
  2. 리더 컨슈머가 assignor 실행
  3. 결과를 다시 브로커에 전달

즉,

리밸런싱 로직이 “컨슈머 애플리케이션 코드 안”에 있었다

---

이 구조의 문제점

1️⃣ 리밸런싱이 컨슈머 상태에 의존

• GC pause
• 일시적 네트워크 지연
• 느린 컨슈머 1개

→ 전체 리밸런싱 지연

---

2️⃣ 할당 전략이 컨슈머별로 달라질 수 있음

• 라이브러리 버전 불일치
• assignor 설정 실수
• 롤링 업그레이드 중 혼용

→ 예측 불가능한 리밸런싱

---

3️⃣ Cooperative 리밸런싱도 한계

• CooperativeStickyAssignor로 개선은 되었지만
• 여전히:
  • “누가 뭘 반납할지”를
  • 컨슈머끼리 협상

→ 대규모 그룹에서는 복잡성 증가

---

2. Kafka 4.x의 방향성: “브로커 중심 리밸런싱”

Kafka 4.x에서는 리밸런싱을 이렇게 재정의한다.

“파티션 할당은 클러스터 메타데이터의 일부다.”

그래서 등장한 것이

👉 New Consumer Group Protocol (KIP-848 계열)

---

3. 새로운 리밸런싱 프로토콜의 핵심 변화

① 파티션 할당 주체 변경

구분	기존	Kafka 4.x
할당 계산	컨슈머	브로커
assignor 위치	client	server-side
리더 컨슈머	필요	불필요

→ 컨슈머는 “참여자”만 되고, 판단은 브로커가 한다

---

② 서버 사이드 Assignor

• 파티션 할당 전략이 브로커 플러그인으로 존재
• 예:
  • Uniform Assignor
  • Range Assignor (server-side)
• 컨슈머는:
  • “난 이 그룹의 멤버다”
  • “이 토픽을 구독한다”
  • 만 전달

---

③ 리밸런싱 = 메타데이터 변경

• 컨슈머 추가/제거
• 파티션 변경

→ 브로커가 즉시 일관된 할당 계산

컨슈머 간:

• 협상 ❌
• 재조정 프로토콜 ❌

---

4. 리밸런싱 동작 흐름 (Kafka 4.x)

1. 컨슈머가 그룹 참가
2. 브로커가 멤버십 변경 감지
3. 브로커가 파티션 할당 계산
4. 컨슈머에게 최종 결과 통지
5. 컨슈머는 그냥 실행

리밸런싱이

“분산 합의” → “중앙 계산”으로 바뀜

---

5. 이 변화가 주는 실질적 효과

✔ 리밸런싱 안정성

• 느린 컨슈머 하나가
• 전체 그룹을 잡아두지 못함

---

✔ 운영 단순화

• assignor 설정 불일치 문제 제거
• 롤링 업그레이드 안전성 증가

---

✔ 예측 가능한 리밸런싱

• 동일한 입력 → 동일한 결과
• 컨슈머 버전/언어 차이 영향 최소화

---

✔ 대규모 그룹에 유리

• 수백~수천 컨슈머 환경에서
• 리밸런싱 시간/복잡도 감소

---

6. 그럼 CooperativeSticky는 사라지나?

❌ 아니다

• Kafka 4.x는 점진적 리밸런싱 개념을 유지
• 다만:
  • “협력(cooperative)”의 주체가
  • 컨슈머 → 브로커로 이동

즉,

개념은 유지, 구현 주체만 변경

---

7. 운영 관점에서의 정리

Kafka 3.x까지

• 리밸런싱 튜닝 = assignor + group.instance.id + 타임아웃 조정

Kafka 4.x 이후

• 리밸런싱 안정성 = 프로토콜 자체가 해결

운영자는:

• “리밸런싱을 어떻게 피할까?”보다
• “처리 로직과 오프셋 관리”에 집중 가능