좀비 펜싱 — transactional.id와 producer epoch로 유령 프로듀서 차단하기
Kafka 트랜잭션 좀비 펜싱 및 Kafka Connect DLQ 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka KIP-447/KIP-298 + Confluent 공식 블로그(Transactions in Apache Kafka, Kafka Connect Deep Dive Error Handling and Dead Letter Queues) Apache Kafka KIP-447 및 Confluent 블로그 Transactions in Apache Kafka
이 모듈을 다 읽으면
- '좀비 프로듀서'가 어떤 상황에서 발생하는지 설명할 수 있다
- transactional.id와 epoch가 어떻게 결합해 좀비를 차단하는지 설명할 수 있다
kafka-learn-35에서 다룬 프로듀서 트랜잭션/멱등성을 전제로, 같은 transactional.id를 가진 프로듀서 인스턴스가 재시작 등으로 여러 개 동시에 살아있게 될 때 옛 인스턴스(좀비)의 쓰기를 어떻게 안전하게 차단하는지를 정리한다.
문제 상황 — 죽은 줄 알았던 프로듀서가 다시 쓰기를 시도한다
네트워크 지연이나 GC 일시정지로 프로듀서가 일시적으로 응답을 못 하면, 애플리케이션 관리 계층(예: 컨테이너 오케스트레이터)이 그 인스턴스를 죽었다고 판단해 새 인스턴스를 띄울 수 있다 — 그런데 옛 인스턴스가 실제로는 완전히 죽지 않고 살아있다가 뒤늦게 다시 쓰기를 시도하면, 새 인스턴스와 옛 인스턴스 둘 다 같은 transactional.id로 동시에 쓰기를 하려는 위험한 상황이 생긴다. 이렇게 '죽은 줄 알았지만 살아있는' 옛 인스턴스를 좀비(zombie)라고 부른다.
핵심 포인트
- 네트워크 지연/GC 일시정지 등으로 옛 프로듀서 인스턴스가 죽지 않은 채 새 인스턴스가 추가로 뜰 수 있음 — 이 옛 인스턴스가 좀비
- 좀비와 새 인스턴스가 같은 transactional.id로 동시에 쓰기를 시도하면 데이터 일관성이 깨질 위험
펜싱 메커니즘 — initTransactions가 epoch를 올려 옛 인스턴스를 무효화
프로듀서가 시작할 때 initTransactions()를 호출하면, 브로커(트랜잭션 코디네이터)는 그 transactional.id에 연결된 미완료 트랜잭션을 정리하고, 그 transactional.id에 연결된 epoch 값을 증가시켜 새 인스턴스에 발급한다. 이후 모든 트랜잭션 요청에는 이 epoch가 함께 실려가는데, 코디네이터는 요청에 실린 epoch가 자신이 알고 있는 최신 epoch와 일치하는지 검사한다 — 옛 인스턴스(좀비)는 여전히 예전 epoch를 갖고 있으므로 이 검사에서 실패해 ProducerFencedException을 받고 거부된다.
핵심 포인트
- initTransactions() 호출 시 브로커가 해당 transactional.id의 epoch를 증가시켜 새 인스턴스에 발급, 미완료 트랜잭션도 정리
- 이후 모든 트랜잭션 요청은 epoch를 함께 보내고, 코디네이터가 최신 epoch와 불일치하면 거부(ProducerFencedException) — 옛 epoch를 가진 좀비가 이 방식으로 차단됨
한 번에 하나의 인스턴스만 '진행 허가'를 받는다
이 메커니즘의 핵심 보장은, 특정 transactional.id에 대해 어느 시점에나 '진행이 허가된' 프로듀서 인스턴스가 정확히 하나뿐이라는 것이다 — 즉 새 인스턴스가 정상적으로 initTransactions()를 마치면 그 순간부터 이전 인스턴스는 자동으로 펜싱 대상이 된다. 이는 EOS(정확히 한 번 처리)를 프로세스 장애·재시작이 반복되는 상황에서도 유지하기 위한 핵심 보장 중 하나로, 옛 인스턴스가 부활해 중복이나 순서 뒤바뀐 쓰기를 남기는 것을 원천적으로 막는다.
핵심 포인트
- 특정 transactional.id에 대해 어느 시점에나 '진행 허가'를 가진 인스턴스는 정확히 하나 — 새 인스턴스 등록 즉시 이전 인스턴스는 자동 펜싱 대상
- 프로세스 장애·재시작이 반복되는 상황에서도 EOS(정확히 한 번 처리)를 유지하기 위한 핵심 보장