2PC 참여(KIP-939) — Kafka를 외부 트랜잭션의 참가자로 만든다
Kafka Fetch Session(KIP-227) 및 2PC 참여(KIP-939) 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka KIP-227(Introduce Incremental FetchRequests to Increase Partition Scalability), KIP-939(Support Participation in 2PC) Apache Kafka KIP-939: Support Participation in 2PC
이 모듈을 다 읽으면
- KIP-939가 kafka-learn-35/77의 트랜잭션(Kafka 내부에서 완결)과 근본적으로 다른 문제를 푼다는 것을 설명할 수 있다
- prepare/commit 두 단계 RPC가 외부 코디네이터와 어떻게 맞물리는지 설명할 수 있다
kafka-learn-35(트랜잭션)와 kafka-learn-77(sendOffsetsToTransaction)에서 다룬 Kafka 내부의 원자적 쓰기(Kafka 트랜잭션은 Kafka 안에서 완결됨)를 전제로, KIP-939가 그 경계를 Kafka 바깥의 외부 시스템까지 확장하는 방법을 정리한다.
지금까지 다룬 트랜잭션과의 근본적 차이 — 'Kafka 안'이 아니라 'Kafka와 외부 시스템 사이'
kafka-learn-35와 77에서 다룬 트랜잭션·sendOffsetsToTransaction은 전부 Kafka 내부에서 완결되는 원자성이었다 — 여러 파티션에 걸친 쓰기, 또는 오프셋 커밋과 출력 쓰기를 Kafka 트랜잭션 하나로 묶는 것이었다. KIP-939는 완전히 다른 문제를 다룬다 — Kafka에 쓰는 것과 외부 데이터베이스 같은 시스템에 쓰는 것을 함께 원자적으로 묶는(dual write) 문제다. 이를 위해 트랜잭셔널 프로듀서가 외부에서 조율되는 2PC(2단계 커밋) 트랜잭션에 참여하고 있다고 선언할 수 있게 됐다.
핵심 포인트
- kafka-learn-35·77의 트랜잭션: Kafka 내부(파티션 간 쓰기, 오프셋 커밋)에서 완결되는 원자성
- KIP-939: Kafka 쓰기와 외부 시스템(DB 등) 쓰기를 함께 원자적으로 묶는 dual write 문제 — 트랜잭셔널 프로듀서가 외부 조율 2PC 트랜잭션 참여를 선언 가능
prepare/commit — 2PC 프로토콜에 맞춘 새 RPC
2PC 프로토콜은 'prepare'(준비 완료를 알림)와 'commit'(실제 확정) 두 단계로 정의된다 — 그래서 KIP-939는 Kafka에 'prepare' RPC를 자연스럽게 추가하는 방향으로 설계됐다. 이 구조에서 외부 시스템(예: Flink의 잡 매니저)이 사실상 2PC의 외부 트랜잭션 코디네이터 역할을 하고, Kafka는 그 트랜잭션의 참가자 중 하나가 된다 — Kafka가 스스로 트랜잭션을 주도하는 게 아니라, 외부 코디네이터의 지시에 따라 준비·확정을 수행하는 쪽으로 역할이 바뀌는 것이다. 이 기능이 활성화되려면 브로커 전체가 이를 지원하는 버전으로 업그레이드된 뒤 transaction.version이 3으로 올라가야 하며, 그 전에는 Enable2pc=true로 InitProducerId를 요청하면 UNSUPPORTED_VERSION 에러로 거부된다.
핵심 포인트
- 2PC는 prepare(준비)/commit(확정) 두 단계 — Kafka에 'prepare' RPC를 추가하는 방향, 외부 시스템(예: Flink 잡 매니저)이 코디네이터, Kafka는 참가자
- 브로커 전체가 지원 버전으로 업그레이드되고 transaction.version이 3이 돼야 활성화 — 그 전엔 Enable2pc=true 요청이 UNSUPPORTED_VERSION으로 거부됨