Sticky Partitioner(KIP-480) — 키 없는 메시지를 라운드로빈 대신 뭉쳐 보낸다
Kafka listeners/advertised.listeners 및 Sticky Partitioner(KIP-480) 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — Confluent 공식 블로그(Kafka Listeners Explained), Apache Kafka KIP-480: Sticky Partitioner Apache Kafka KIP-480: Sticky Partitioner
이 모듈을 다 읽으면
- 기존 라운드로빈 파티셔닝이 왜 배치를 작게 만드는 비효율을 낳았는지 설명할 수 있다
- Sticky Partitioner가 배치가 찰 때까지(또는 linger.ms 도달 시) 한 파티션에 '들러붙는' 원리를 설명할 수 있다
kafka-learn-38에서 다룬 프로듀서 배치·linger.ms 튜닝을 전제로, 키 없는(null key) 메시지를 어느 파티션에 보낼지 정하는 기본 파티셔너가 KIP-480으로 어떻게 바뀌었는지를 정리한다.
기존 방식의 문제 — 라운드로빈이 배치를 잘게 쪼갠다
파티션도 키도 지정하지 않은 경우, 기존 기본 파티셔너는 연속된 레코드를 파티션 0, 1, 2...순으로 라운드로빈 방식으로 골고루 분산시켰다. 파티션 간에 데이터를 고르게 뿌린다는 점에서는 좋지만, 그 대가로 각 파티션으로 가는 배치가 더 작고 더 많아진다는 문제가 있었다 — kafka-learn-38에서 다룬 것처럼 프로듀서는 같은 파티션으로 갈 레코드를 배치로 묶어 보내는데, 매 레코드마다 파티션이 바뀌면 배치를 채울 기회 자체가 줄어든다.
핵심 포인트
- 기존 라운드로빈: 연속 레코드를 파티션 0→1→2 순으로 골고루 분산 — 균등하지만 배치가 작고 많아지는 비효율
- 매 레코드마다 파티션이 바뀌면 kafka-learn-38의 배치(같은 파티션으로 갈 레코드를 묶어 전송) 자체를 채울 기회가 줄어듦
Sticky Partitioner — 배치가 찰 때까지 한 파티션에 들러붙는다
Sticky Partitioner(KIP-480)는 null 키 레코드를 매번 다른 파티션으로 흩뿌리는 대신, 토픽별로 하나의 파티션에 '들러붙어서'(stick) 그 배치가 다 차거나(또는 linger.ms 시간이 다 돼) 전송될 때까지 계속 그 파티션으로 보낸다. 배치가 전송되고 나면(레코드 누적기가 그 토픽·파티션에 새 배치를 할당하는 시점에) 다음에 붙을 파티션이 새로 정해진다. 이렇게 하면 라운드로빈보다 더 크고 더 적은 배치를 만들 수 있어 시스템의 지연을 줄이는 효과가 있다.
핵심 포인트
- null 키 레코드를 토픽별로 한 파티션에 '들러붙여' 배치가 다 차거나 linger.ms에 도달할 때까지 그 파티션으로 계속 전송
- 배치가 전송되면 다음 붙을 파티션이 새로 정해짐 — 라운드로빈보다 크고 적은 배치로 지연 감소
UniformStickyPartitioner — 키가 있어도 sticky하게
기본 Sticky Partitioner는 키가 없는 레코드에만 적용된다. 키가 있는 레코드에도 동일한 sticky 방식을 적용하고 싶다면 별도로 만들어진 UniformStickyPartitioner를 쓸 수 있는데, 여기서 중요한 함정이 있다 — 이 파티셔너는 파티셔닝 전략에 레코드 키를 아예 쓰지 않는다는 것이다. 즉 같은 키를 가진 레코드들이 항상 같은 파티션으로 간다는 보장이 사라진다 — kafka-learn-06/07에서 다룬 '같은 키는 같은 파티션에 가야 순서가 보장된다'는 일반적 기대와 충돌할 수 있어, 순서 보장이 필요한 경우엔 쓰면 안 된다.
핵심 포인트
- UniformStickyPartitioner: 키가 있는 레코드에도 sticky 방식 적용 — 단, 파티셔닝에 키를 아예 안 씀
- 같은 키가 항상 같은 파티션에 간다는 보장이 사라짐 — 키 기반 순서 보장이 필요한 워크로드에는 부적합