[우선  프로듀서의 idempotence에 대해 알아보자]

 

** 멱등성(idempotence)
  . 멱등성이란 연산을 여러번 적용하더라도 결과가 달라지지 않는 것.
  . REST API를 예로 들자면 get, put, delete는 멱등성을 가지고 있지만, post는 상태를 변경하기 때문에 멱등성이 없다.


** 카프카에서 멱등성 프로듀서란?
프로듀서가 동일한 데이터를 여러번 보내더라도 브로커 단위에서 1번만 적재하는 것.
  . 프로듀서는 retry 로직에 의해서 동일 ProducerRecord가 브로커에 여러 번 적재될 가능성이 있음

  . 프로듀서는 ProducerRecord를 전송할 때 데이터에 숫자(Sequence)와
    PID(프로듀서 번호)를 보냄으로서 브로커가 중복 처리

 

 

[멱등성 프로듀서]

 

멱등성 프로듀서로 동작하지 않는 기본 프로듀서는 send() 이후에 데이터에 대한 적재 응답을 제대로 못받았을 경우에는 데이터를 다시 보내게 됩니다. 이것은 retry 로직의 자연스러운 데이터 처리 방법인데, 카프카는 기본 옵션으로 사용했을 때 "at least once" 즉 적어도 한 번 이상 데이터를 보내는 로직으로 되어 있기 때문입니다. 이 방식은 데이터를 유실 없이 안정적으로 처리하지만, 중복해서 데이터를 처리할 가능성이 있습니다.


동일한 레코드가 여러 번 들어가는 것을 원치 않을때는 멱등성 프로듀서를 사용하면 됩니다.
브로커는 PID와 Sequence 번호를 토대로 데이터가 중복되어 전송되지 않았는지 확인합니다.

 

 

[멱등성 프로듀서의 설정과 장/단점]

 

** 설정 방법
  . ENABLE_IDEMPOTENCE_CONFIG = true


** 장점
  . 프로듀서와 브로커 사이의 데이터 전송에 있어 레코드가 딱 한번만 적재됨을 보장
  . 딱 한번만 적재(Exactly-once)되므로 데이터 유실이나 중복이 발생하면 안되는 곳에서는 반드시 이 옵션을 켜야 함


** 단점
  . 브로커는 PID(프로듀스 아이디)와 레코드 시퀀스넘버를 가지고 있으면서 계속 모니터링하므로 브로커에 부하가 발생하므로(= 데이터의 처리속도가 느려질 수 있음, 데이터의 처리량이 낮아질 수 있음) 브로커의 CPU나 메모리 사용량을 고려해야 함
  . 프로듀서의 장애애 의해서 프로듀서가 재시작 되는 경우에는 PID가 달라지므로 이에 대한 대응책이 필요함

 

 

[트랜잭션이란?]

 

** 데이터베이스의 상태를 변환시키는 하나의 논리적인 기능을 수행하는 작업의 단위 또는 일련의 연산
  . 커밋, 롤백을 통해 논리적인 수행 단위를 완료 또는 복구 가능

 

** 카프카에 트랜잭션이란?
  . 여러 파티션에 데이터를 atomic(원자성)하게 보내는 것
  . 여러 작업 단위를 여러 토픽에 보낼 경우 논리적으로 수행한 단위가 완료되었음을 begin과 commit으로 지정할 수 있다.

 

카프카에서는 스트림 데이터 처리에 있어 트랜잭션 개념을 추가하였습니다.
즉 카프카에서 트랜잭션이란 스트림 트랜잭션에 가깝습니다.

 

트랜잭션 프로듀서는 beginTransaction()을 호출해서 원자 단위로 묶을 레코드들이 이제 전송된다는 것을 선언합니다. 그리고 트랜잭션 컨슈머는 트랜잭션이 시작된 데이터에 대해서 즉시 가져가지는 않습니다. 왜냐하면 커밋이 되어서 원자 단위로 트랜잭션이 끝나지 않았기 때문입니다.

트랜잭션 프로듀서는 하나의 트랜잭션으로 묶일 레코드를 모두 보내고 난 이후에 commitTransaction()을 호출해서 트랜잭션이 끝났음을 알립니다. 이후 트랜잭션 컨슈머는 커밋이 완료된 데이터를 가져가서 처리하게 됩니다.

스트림데이터에서 트랜잭션이란 여러 레코드를 하나의 단위로 묶어서 처리하는 것이라고 볼 수 있습니다.

 

[트랜잭션 프로듀서, 컨슈머 설정 방법]

 

** 트랜잭션 프로듀서
  . 설정
     - TRANSACTION_ID_CONFIG = UUID.randomUUID().toString() -> 유일한 값으로 설정해야 함
  . 트랜잭션 프로듀서를 설정하면 자동으로 멱등성 프로듀서가 설정된다.


** 트랜잭션 컨슈머
  . 설정
     - ISOLATION_LEVEL_CONFIG = "read_committed"
  . 프로듀서가 커밋하기 이전 레코드는 가져가지 않는다
  . 만약 기본 설정값(read_uncommitted)일 경우에는 커밋되지 않은 레코드도 모두 가져가서 처리한다.

 

 

[언제 트랜잭션 프로듀서와 트랜잭션 컨슈머를 사용해아 할까?]

 

** 여러 이벤트가 반드시 동시에 처리되어야 하는 경우

'~2022 > Apache Kafka' 카테고리의 다른 글

[Kafka] server.properties  (0) 2022.04.06
[Kafka] 기본 개념  (0) 2022.03.16
[Apache Kafka] 9. 컨슈머와 컨슈머 그룹  (0) 2021.11.11
[Apache Kafka] 8. 복제  (0) 2021.11.11
[Apache Kafka] 7. 프로듀서  (0) 2021.11.11

+ Recent posts