Kafka Connect Sink 커넥터의 전달보장 — 기본은 at-least-once, exactly-once는 싱크에 달렸다
Kafka OAUTHBEARER 재인증(KIP-368) 및 Connect Sink 전달보장 공식 문서 종합 (웹 리서치, 2026) — KIP-368: Allow SASL Connections to Periodically Re-Authenticate + Confluent 공식 문서(design/delivery-semantics, kafka-connectors/elasticsearch) Confluent 공식 문서 Message Delivery Guarantees 및 Elasticsearch Sink Connector
이 모듈을 다 읽으면
- sink 커넥터가 기본적으로 at-least-once만 제공하는 이유를 설명할 수 있다
- sink 커넥터가 exactly-once 효과를 내려면 무엇이 필요한지, 그 방법이 source 커넥터의 EOS(KIP-618)와 왜 근본적으로 다른지 설명할 수 있다
kafka-learn-61에서 다룬 source 커넥터의 EOS(KIP-618, 트랜잭션 기반)를 전제로, 그와 정반대 방향인 sink 커넥터는 왜 프레임워크 차원의 트랜잭션만으로 exactly-once를 보장할 수 없는지, 그리고 실제로는 무엇에 의존해야 하는지를 정리한다.
sink 커넥터의 기본값은 at-least-once — 재시도가 중복을 만든다
Kafka Connect sink 커넥터는 역사적으로 at-least-once 전달만 제공해왔다 — 배치 쓰기가 실패하면 재시도하는데, 대상 시스템(external sink)이 멱등적이지 않으면 이 재시도가 중복 레코드를 만들어낼 수 있다. 예를 들어 JDBC Sink 커넥터도 Kafka 토픽에서부터의 전달을 최소 한 번(at-least-once)만 보장한다고 공식 문서에 명시돼 있다.
핵심 포인트
- sink 커넥터는 역사적으로 at-least-once만 제공 — 배치 쓰기 실패 시 재시도가 대상 시스템이 멱등적이지 않으면 중복을 만듦
- JDBC Sink 커넥터도 공식적으로 Kafka로부터의 전달을 at-least-once로만 보장한다고 명시
왜 source의 EOS(KIP-618)와 근본적으로 다른가
kafka-learn-61에서 다룬 source 커넥터의 EOS는 'Kafka에 쓰기'와 '오프셋 커밋'을 Kafka 트랜잭션 하나로 묶어 프레임워크 차원에서 보장할 수 있었다 — 둘 다 Kafka 내부의 일이기 때문이다. 반면 sink 커넥터는 'Kafka에서 읽기'와 '외부 시스템에 쓰기'를 연결하는데, 이 외부 시스템 쓰기는 Kafka 트랜잭션의 보호 범위 밖에 있다 — 그래서 일반적으로는 exactly-once를 외부 대상 시스템에 대해 달성하는 것은 애플리케이션(커넥터) 설계의 몫으로 남는다.
핵심 포인트
- source의 EOS는 'Kafka 쓰기+오프셋 커밋'이 둘 다 Kafka 내부라 트랜잭션으로 묶을 수 있었음
- sink는 '외부 시스템 쓰기'가 Kafka 트랜잭션 보호 범위 밖이라, 일반적으로 exactly-once 달성은 커넥터(애플리케이션) 설계의 몫
실무 해법 — 멱등적 쓰기로 exactly-once '효과'를 낸다
일부 커넥터는 멱등적 동작을 시도해 exactly-once에 준하는 효과를 얻는다 — 예를 들어 JDBC Sink는 기본 키를 이용한 upsert로 중복 삽입을 피할 수 있고, Elasticsearch Sink 커넥터는 Elasticsearch 문서에 결정론적인 ID(Kafka 메시지에 키가 있으면 그 키를, 없으면 topic+partition+offset 조합을) 설정해 같은 레코드가 재시도돼도 같은 문서 ID로 덮어쓰기(overwrite)만 될 뿐 중복 문서가 생기지 않게 한다. 즉 exactly-once는 Kafka 쪽 트랜잭션이 아니라, 대상 시스템이 '같은 쓰기를 여러 번 받아도 결과가 같은' 멱등적 쓰기를 지원하는지에 달려 있다.
핵심 포인트
- JDBC Sink: 기본 키 기반 upsert로 중복 삽입 회피, Elasticsearch Sink: 문서 ID를 Kafka 메시지 키(없으면 topic+partition+offset)로 결정론적 설정해 재시도도 같은 문서를 덮어쓸 뿐 중복 안 생기게 함
- sink의 exactly-once는 Kafka 트랜잭션이 아니라 대상 시스템의 멱등적 쓰기 지원 여부에 달려 있음