Broker-Visible vs Client-Local Parallelism

Author: Jack Vanlightly | Source: jack-vanlightly.com | Published: 2026-06-04

한 줄 요약

병렬성은 어딘가에서 회계되어야 하며, 그 단위가 broker-visible(파티션·컨슈머)이면 고병렬 워크로드에서 자원이 폭발하므로 client-local(가상 스레드·async task)로 옮기는 것이 핵심 — 모든 메시징 시스템에 공통.

Kafka Share Group은 병렬화가 주 목적이 아니라 로그 위에 큐 시맨틱(개별 레코드 accept/reject)을 노출하는 것. 다만 메시지가 독립적이고 느슨한 순서를 수용하면 파티션 수에서 병렬성을 분리하는 도구로 쓸 수 있음
핵심 통찰: 병렬성의 단위가 broker-visible/managed면 한계가 있음. broker가 관리해야 하는 것(프로토콜 상호작용·상태·TCP 연결)으로 보이면 고병렬에서 비싸짐
aggregate parallelism = rate × avg processing time(초). 60,000 msg/s × 1s = 60,000 병렬 단위 필요
단위가 serial consumer면 60,000 컨슈머(엄청난 연결·프로토콜 상태). 단위가 client-local(I/O 대기 중 한 클라이언트가 1,000개 동시 처리)이면 60 컨슈머로 충분
트레이드오프: client-side는 클라이언트 복잡도 증가(라이브러리 도움 가능, 단 ParallelConsumer는 유지보수 중단). Share group + client-side 병렬성을 결합하는 새 라이브러리 필요성 제기

60,000 msg/s × 10s 처리 = 600,000 컨슈머, 100만+ TCP 연결 필요
가상/OS 스레드 관리가 TCP 연결 + 메타데이터/단위 관리보다 훨씬 저렴
Consumer group은 1 partition당 1 committed offset, share group은 개별 레코드 상태(available/delivered/acknowledged) 추적