KIP

카프카의 파티션은 오랫동안 한 번에 하나의 컨슈머만 처리할 수 있다는 제약을 갖고 있었습니다. 그 결과 파티션 개수와 컨슈머 개수가 강하게 묶여 있었고, 처리량을 늘리려면 필요 이상으로 파티션을 쪼개야 하는 경우가 잦았습니다. 여러 컨슈머가 하나의 파티션을 나눠 처리하는 큐(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) 설계였습니다. 컨슈머 그룹 리밸런싱에 버그가 있으면 그 수정이 클라이언트 쪽에서 이뤄져야 하는데, 클라우드 서비스를 운영하는 입장에서는 사용자의 클라이언트를 강제로 고칠 수 없으니 이는 매우 까다로운 제약입니다. 대부분의 로직이 클라이언트에서 실행되다 보니, 문제가 생겨도 서버 쪽 로그만으로는 원인을 진단하기 어렵다는 점 또한 문제를 더 어렵게 만들었습니다. ...

안녕하세요. 이번 글에서는 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 설정과 같은 요소에 따라 일부 차이가 존재할 수 있습니다만, 이번에는 핵심 용어를 중심으로 전반적인 과정을 다루는 것을 목표로 하였습니다. ...