[Apache Kafka] 7. 멱등성 프로듀서, 트랜잭션 프로듀서와 컨슈머

본 포스팅은 인프런 데브원영님의 [아파치 카프카 애플리케이션 프로그래밍]의 강의를 수강 후 정리하는 글입니다.

[아파치 카프카 애플리케이션 프로그래밍] 개념부터 컨슈머, 프로듀서, 커넥트, 스트림즈까지!

 

 

1. 멱등성 프로듀서

1-1.  전달 신뢰성

멱등성: 여러 번 연산을 수행하더라도 동일한 결과

멱등성 프로듀서: 동일한 데이터를 여러 번 전송하더라도 카프카 클러스터에 단 한 번만 저장됨

 

 

 

1-2. 멱등성 프로듀서

프로듀서가 보내는 데이터의 중복 적재를 막기 위해 0.11.0 이후 버전부터 enable.idempotence 옵션 지원

3.0.0 이하 버전: enable.idempotence : false가 기본값

3.0.0 이상 버전: enable.idempotence: true(acks=all)가 기본값

 

enable.idempotence를 true로 설정하면 브로커에 단 한 번만 데이터가 적재되는 것을 보장하기 위해 프로듀서의 일부 옵션들이 강제로 설정

• retries: INTEGER.MAX_VALUE
• acks: all

정확히 한 번 전송하는 것이 아니라, 상황에 따라 여러 번 전송할 수도 있지만, 여러 번 전송된 데이터를 확인하고 중복된 데이터는 적재하지 않음

1-3. 멱등성 프로듀서의 동작

1. 멱등성 프로듀서는 기본 프로듀서와 달리 데이터를 브로커로 전달할 때, 프로듀서 PID(Producer Unique ID)와 시퀀스 넘버를 함께 전달
2. 브로커는 프로듀서의 PID와 시퀀스 넘버를 확인하여 동일한 메시지의 적재 요청이 오더라도 단 한 번만 데이터를 적재

1-4. 멱등성 프로듀서 사용시 오류 확인

브로커에서 멱등성 프로듀서가 전송한 데이터의 PID와 시퀀스 넘버를 확인할 때, 시퀀스 넘버가 일정하지 않은 경우 OutOfOrderSequenceException이 발생할 수 있음. 브로커가 예상한 시퀀스 넘버와 다른 번호의 데이터의 적재 요청이 왔을 때 발생함. 발생했을 경우에는 시퀀스 넘버의 역전현상이 발생할 수 있기 때문에, 순서가 중요한 경우 대응 방안을 고려해야함

2. 트랜잭션 프로듀서, 컨슈머

2-1. 트랜잭션 프로듀서의 동작

카프카의 트랜잭션: 다수의 파티션에 데이터를 저장할 경우, 모든 데이터에 대해 동일한 원자성을 만족시키기 위해 사용

다수의 데이터를 동일 트랜잭션으로 묶음으로써 전체 데이터를 처리하거나 전체 데이터를 처리하지 않도록 하는 것

ALL or NOTHING

 

트랜잭션 프로듀서는 사용자가 보낸 데이터를 레코드로 파티션에 저장할 뿐만 아니라 트랜잭션의 시작과 끝을 표현하기 위해 트랜잭션 레코드를 한 개 더 보냄

2-2. 트랜잭션 컨슈머의 동작

파티션에 저장된 트랜잭션 레코드를 보고 트랜잭션이 완료(commit)됨을 확인 한 후 데이터를 가져감

2-3. 트랜잭션 프로듀서 설정

트랜잭션 프로듀서로 동작하기 위해 transactional.id를 설정해야 함.

init, begin, send, commit 순서대로 수행되어야 함

2-4. 트랜잭션 컨슈머 설정

커밋이 완료된 레코드만 읽기 위해 isolation.level 옵션을 read_committed로 설정

기본 값은 read_uncommitted로서 트랜잭션 프로듀서가 레코드를 보낸 후 커밋여부와 상관없이 모두 읽음

하지만 read_committed로 설정하면 커밋이 완료된 레코드만 읽음