Consumer Group

카프카 4.0에서 GA된 KIP-848: The Next Generation of the Consumer Rebalance Protocol을 정리해봅니다. 컨슈머 그룹 멤버가 바뀌어도 downtime을 거의 없애는 것, 그리고 리밸런싱의 주요 책임을 클라이언트에서 브로커로 옮기는 것이 이 KIP의 핵심 목표입니다. 배경 도입된 지 8년이 지난 기존 컨슈머 그룹 리밸런싱 프로토콜은 몇 가지 구조적인 한계에 부딪힌 상태였습니다. 가장 큰 문제는 클라이언트에 지나치게 많은 역할을 부여한(thick client) 설계였습니다. 컨슈머 그룹 리밸런싱에 버그가 있으면 그 수정이 클라이언트 쪽에서 이뤄져야 하는데, 클라우드 서비스를 운영하는 입장에서는 사용자의 클라이언트를 강제로 고칠 수 없으니 이는 매우 까다로운 제약입니다. 대부분의 로직이 클라이언트에서 실행되다 보니, 문제가 생겨도 서버 쪽 로그만으로는 원인을 진단하기 어렵다는 점 또한 문제를 더 어렵게 만들었습니다. ...

카프카 클라이언트 라이브러리 코드를 살펴보던 와중에, 컨슈머 그룹 리밸런싱이 발생한 시점에 컨슈머가 구독할 파티션을 결정하는 ConsumerPartitionAssignor 인터페이스와 몇 가지 구현체 (RangePartitionAssignor, CooperativeStickyAssignor)가 있는 것을 확인할 수 있습니다. 연결된 컨슈머 정보를 기반으로 파티션을 분배하는 작업은 서버(예: 브로커)가 처리해야 할 작업처럼 보였는데, 이러한 로직이 클라이언트 라이브러리 코드에 포함되어 있다는 점이 다소 생소하게 느껴졌습니다. 이에 대해 조금 더 살펴보던 중, 카프카에서 이러한 구조를 채택하게 된 배경을 설명하는 문서를 찾아 공유해 드립니다. client-side 파티션 분배 정책의 필요성 파티션 분배 작업은 반드시 서버가 처리해야 하는 것은 아닙니다. 예를 들어, 파티션 분배의 책임이 브로커에 있을 경우, 새로운 파티션 분배 정책을 적용하기 위해서는 브로커를 재시작해야 하는 부담이 있습니다. 파티션 분배 정책은 매우 다양할 수 있어서 이에 대한 획일화된 검증 규칙을 적용하기 어렵습니다. 예를 들어, 하나의 파티션을 여러 컨슈머에게 동시에 배정해야 할 수도 있습니다. 커스텀한 파티션 분배 정책이 필요한 대표적인 사례는 다음과 같습니다. ...