Kafka

카프카의 파티션은 오랫동안 한 번에 하나의 컨슈머만 처리할 수 있다는 제약을 갖고 있었습니다. 그 결과 파티션 개수와 컨슈머 개수가 강하게 묶여 있었고, 처리량을 늘리려면 필요 이상으로 파티션을 쪼개야 하는 경우가 잦았습니다. 여러 컨슈머가 하나의 파티션을 나눠 처리하는 큐(queue) 스타일이 더 어울리는 워크로드도 분명 있는데, 기존 구조로는 그것을 흉내 내기가 어려웠습니다. KIP-932: Queues for Kafka는 공유 그룹(Share Group)이라는 새로운 그룹 유형을 도입해서 이 제약을 풀어냅니다. Share Group 공유 그룹은 기존 컨슈머 그룹의 대안으로 등장한 그룹 유형(share)입니다. 가장 큰 차이는 여러 컨슈머가 하나의 파티션을 동시에 공유할 수 있다는 점입니다. 그룹 안의 컨슈머 수가 토픽의 전체 파티션 개수를 넘어설 수도 있고, ack는 레코드 단위로 이루어지며, 메시지가 전달된 횟수도 함께 기록됩니다. ...

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

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

안녕하세요. 이번 글에서는 leader epoch이 처음으로 제안된 (KIP-101) Alter Replication Protocol to use Leader Epoch rather than High Watermark for Truncation에 대한 번역과 개인적인 후기를 작성해보았습니다. Log Replication Protocol leader epoch에 대해 다루기 전에, 먼저 카프카에서 파티션 로그가 리더 브로커에서 팔로워 브로커로 복제되는 과정에 대해서 살펴보도록 하겠습니다. 로그 복제 과정은 producer의 ack 설정이나 min.isr 설정과 같은 요소에 따라 일부 차이가 존재할 수 있습니다만, 이번에는 핵심 용어를 중심으로 전반적인 과정을 다루는 것을 목표로 하였습니다. ...