producer.id.expiration.ms(KIP-854) — 오래 유휴 상태인 프로듀서 ID 정리하기
Kafka Share Groups(KIP-932) 및 프로듀서 ID 만료(KIP-854) 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — Apache Kafka KIP-932(Queues for Kafka), KIP-854(Separate configuration for producer ID expiry), morling.dev 기술 블로그 Apache Kafka KIP-854: Separate configuration for producer ID expiry
이 모듈을 다 읽으면
- producer.id.expiration.ms가 kafka-learn-53의 좀비 펜싱(epoch)과 별개로, '유휴 상태의 PID 자체'를 브로커 메모리에서 정리하는 메커니즘임을 설명할 수 있다
- 이 값을 delivery timeout보다 짧게 잡으면 왜 중복이 늘어날 수 있는지 설명할 수 있다
kafka-learn-53에서 다룬 '살아있는 프로듀서의 좀비 펜싱(epoch 증가)'과 별개로, 이 모듈은 '한동안 아무것도 안 보낸 프로듀서 ID 자체를 브로커가 언제 잊어버리는지'를 정리한다 — idempotent producer가 3.0+부터 기본값이 되며 PID 개수가 늘어난 것이 이 설정이 KIP-854로 분리된 배경이다.
왜 별도 설정이 필요해졌는가 — idempotent producer 기본화와 메모리 관리
원래 프로듀서 ID의 시간 기반 만료는 transactional.id.expiration.ms 하나로 같이 제어됐다. 그런데 idempotence(kafka-learn-35에서 다룬 exactly-once의 기반)가 기본값이 되면서 트랜잭션을 안 쓰는 일반 프로듀서도 PID를 발급받는 경우가 크게 늘었다. KIP-854는 이 두 개념(트랜잭션 ID 만료 vs 프로듀서 ID 만료)을 producer.id.expiration.ms로 분리해, 브로커가 유휴 PID를 더 세밀하게(트랜잭션과 무관하게) 관리할 수 있게 했다 — 새 브로커의 기본값은 1일이다.
핵심 포인트
- idempotent producer가 3.0+부터 기본값이 되며 PID 발급이 크게 늘어난 것이 별도 설정이 필요해진 배경
- KIP-854로 producer.id.expiration.ms를 transactional.id.expiration.ms에서 분리 — 새 브로커 기본값 1일
만료되지 않는 조건과, 너무 짧게 잡았을 때의 대가
진행 중인 트랜잭션에 연결된 PID는 이 시간이 지나도 만료되지 않는다 — 트랜잭션이 살아있는 한 그 PID도 살아있어야 하기 때문이다. 반대로, 토픽의 리텐션 정책 때문에 그 PID의 마지막 쓰기 레코드가 삭제되면 이 설정값보다 더 일찍 PID가 만료될 수도 있다. 그리고 이 값을 프로듀서의 delivery timeout보다 더 짧게 잡으면, 프로듀서가 재시도하는 사이에 PID가 이미 만료돼버려(UnknownProducerIdException) 새 PID로 다시 보내야 하는 상황이 늘어나고, 이는 곧 중복 발생 가능성 증가로 이어진다.
핵심 포인트
- 진행 중인 트랜잭션에 연결된 PID는 만료 안 됨 / 토픽 리텐션으로 마지막 레코드가 먼저 삭제되면 이 값보다 일찍 만료될 수도 있음
- delivery timeout보다 짧게 잡으면 재시도 도중 PID가 만료돼(UnknownProducerIdException) 새 PID로 재전송해야 하는 경우가 늘어 중복 가능성 증가