트랜잭션 프로토콜
트랜잭션 프로토콜 (Transaction Protocol)
이 페이지는 Apache Kafka 4.0부터 강화된 서버 측 트랜잭션 프로토콜(KIP-890)을 설명해요. 프로듀서 에포크를 매 트랜잭션마다 올려 의도한 메시지만 트랜잭션에 포함되고 중복이 다음 트랜잭션에 쓰이지 않게 하는 개선이에요.
출처: 문서
본문
개요 (Overview)
Apache Kafka 4.0부터 서버 측 트랜잭션 방어(Transactions Server Side Defense, KIP-890)가 강화된 트랜잭션 프로토콜을 제공합니다. 활성화되고 4.0 프로듀서 클라이언트를 사용하면 매 트랜잭션마다 프로듀서 에포크가 증가되어, 모든 트랜잭션이 의도한 메시지를 포함하고 중복이 다음 트랜잭션의 일부로 쓰이지 않게 보장합니다.
이 프로토콜은 Apache Kafka 4.0부터 서버에서 자동으로 활성화됩니다. 프로토콜의 활성화·비활성화는 transaction.version 피처 플래그로 제어됩니다. 이 플래그는 새 클러스터 생성 시 storage 도구로 설정하거나, 기존 클러스터에는 features 도구를 통해 동적으로 설정할 수 있습니다. 4.0 이상의 프로듀서 클라이언트는 서버에서 활성화되어 있는 한 새 트랜잭션 프로토콜을 사용합니다.
업그레이드와 다운그레이드 (Upgrade & Downgrade)
서버에서 새 프로토콜을 활성화하려면 transaction.version=2로 설정하세요. 프로듀서 클라이언트를 재시작할 필요는 없으며, 다음에 브로커에 연결하거나 재연결할 때 동적으로 업그레이드됩니다. (또는 클라이언트를 재시작해 이 연결을 강제할 수 있습니다.) 프로듀서는 트랜잭션 중간에 업그레이드하지 않고, 서버 측 업그레이드를 인지한 후 다음 트랜잭션 시작에서 업그레이드합니다.
다운그레이드도 안전하며 비슷하게 작동합니다. 프로듀서가 다운그레이드된 프로토콜을 인지한 후 첫 트랜잭션에서 클라이언트가 이전 프로토콜을 사용합니다.
성능 (Performance)
새 트랜잭션 프로토콜은 파티션 추가에 서버 측에서 단일 호출만 보내는 방식으로 성능을 개선합니다. 이전에는 클라이언트에서 추가하는 호출과 서버가 검증하는 호출이 각각 하나씩 있었습니다.
이 변경의 한 결과는 KAFKA-5477이 도입한 하드코딩된 재시도 백오프를 더 이상 사용할 수 없다는 것입니다. endTransaction api의 비동기 특성 때문에 클라이언트는 마커가 기록되기 전에 다음 트랜잭션에 파티션 추가를 시작할 수 있습니다. 이 경우 이전 트랜잭션이 완료될 때까지 서버가 CONCURRENT_TRANSACTIONS를 반환합니다. 이러한 재시도에 대해 기본 클라이언트 백오프 대신 20ms의 더 짧은 재시도 백오프가 있었습니다.
이제 서버 측 요청으로 서버는 CONCURRENT_TRANSACTIONS 오류를 볼 때 이 오류를 클라이언트에 반환하기 전에 파티션 추가를 몇 번 재시도합니다. 이로 인해 이 요청들에 대해 보고되는 produce 지연시간이 높아질 수 있습니다. 트랜잭션의 종단 간 지연시간(클라이언트가 트랜잭션을 시작한 때부터 커밋할 때까지 측정)은 이 변경으로 전체적으로 증가하지 않습니다. 시간이 클라이언트 측 백오프에서 produce 지연시간의 일부로 계산되는 것으로 이동할 뿐입니다.
서버 측 백오프와 총 재시도 시간은 다음 새 구성으로 설정할 수 있습니다.
add.partitions.to.txn.retry.backoff.msadd.partitions.to.txn.retry.backoff.max.ms
더 알아보기 (Learn more)
transaction.version=2로 강화된 트랜잭션 프로토콜을 켤 수 있어요.- 프로듀서 에포크 증가는 중복 트랜잭션 쓰기를 막는 핵심이에요.
- 트랜잭션 성능 튜닝은 새 재시도 백오프 구성으로 조절해요.