옛날엔 round-robin 방식을 사용했기에 producer로 작성한 메시지들이 여러 partition에 걸쳐 spread되었다.
요즘엔 sticky partitioner 방식을 사용한다고 한다.
partition 개수는 3개야. kafka producer를 통해 3개의 메시지를 입력했어. comsumer로 메시지들을 읽어보니 쓴 순서대로 나오더라고. 파티션 폴더들을 직접 뒤져보니, 2번 파티션 안에만 메시지들이 기록돼있어. 근데 강사님의 폴더를 보면 세 메시지가 각각 다른 파티션에 저장돼 있어. 나의 경우는 왜 한 파티션 안에만 저장된 거야?
가능한 원인은 거의 “파티션을 고르는 기준(=파티셔너 동작)” 차이야. Kafka는 메시지를 보낼 때마다 3개 파티션에 자동으로 골고루 넣는 게 기본 보장사항이 아니고, 아래 규칙으로 “어느 파티션에 쓸지”를 결정해.
1) key를 줬다면: 같은 key → 항상 같은 파티션
프로듀서가 key를 함께 보냈으면(예: userId, concertId 같은 값), Kafka는 기본 파티셔너가 key 해시로 파티션을 고정해.
- key가 항상 동일했다 → 항상 2번 파티션으로만 감
- key가 메시지마다 달랐다 → 파티션이 분산될 수 있음
✅ 확인 포인트
- 콘솔 프로듀서면
--property parse.key=true --property key.separator=:같은 옵션 썼는지 - 코드면
ProducerRecord(topic, key, value)형태로 key 넣고 있는지 - Spring Kafka면
KafkaTemplate.send(topic, key, value)쓰는지
2) key가 없는데도 한 파티션만 간다면: “sticky partitioner” 동작일 가능성이 큼
요즘 Kafka 클라이언트(특히 2.4+ 이후 기본 파티셔너)는 키가 없을 때 round-robin이 아니라 “sticky” 방식이 기본이야.
Sticky partitioner 요약
- key 없는 레코드는 한 파티션을 “잠깐 고정”해서 계속 그 파티션에 몰아서 보냄
- 이유: 배치 효율(압축/네트워크) 때문에 처리량이 좋아짐
- “3개 메시지” 정도의 소량이면 우연이 아니라 설계상 한 파티션에만 들어갈 수 있음
즉, 네가 3개를 짧은 시간에 연달아 보냈다면:
- 프로듀서가 선택한 “현재 sticky 파티션 = 2번”
- 그래서 3개가 전부 2번에 기록
이게 아주 흔한 케이스야.
반면 강사님은
- 메시지를 더 많이 보냈거나 / flush 타이밍이 달랐거나
- 설정이 round-robin이었거나(혹은 예전 클라이언트)
- key를 메시지마다 다르게 줬거나
이 중 하나라서 파티션이 갈라져 보였을 확률이 높아.
3) “쓴 순서대로 소비되더라”는 건 정상
Kafka는 파티션 내부 순서만 보장해.
너는 3개가 같은 파티션(2번) 으로 갔으니 소비 시에도 쓴 순서대로 나오는 게 당연해.
강사님처럼 각 메시지가 다른 파티션이면,
- 컨슈머 그룹에서 여러 파티션을 같이 읽을 때는 전체 순서가 섞일 수 있어(파티션 간 순서 보장 없음)
4) 딱 이것만 보면 원인 구분 가능
가장 빠른 체크:
- consumer 출력에 partition 번호 찍기
- 콘솔 컨슈머면
--property print.partition=true --property print.key=true --property print.offset=true류 옵션(환경마다 다름)으로 확인 - 코드면
record.partition()출력
- producer가 key를 보내는지 확인
- key가 항상 같으면: 100% 그 파티션 고정
- key 없는데도 한 파티션이면 sticky로 이해하면 됨
- 메시지 100개 정도 더 보내보면 “어느 순간” 다른 파티션으로 옮겨가는 패턴이 보일 거야(배치/linger/flush에 따라).
원하면, 네가 메시지 넣은 방식(콘솔 명령어 / Python 코드 / Spring 코드) 그대로 붙여줘. 그걸 기준으로 “key를 주고 있는지”, “sticky 동작인지”, “왜 2번으로 고정됐는지”를 정확히 짚어서 재현 가능한 형태로 설명해줄게.
