본문 바로가기
📨 Apache Kafka

[아파치 카프카 애플리케이션 프로그래밍 with 자바] 4-2장 카프카 프로듀서

by GroovyArea 2023. 5. 7.

카프카 프로듀서

  • 카프카 프로듀서는 토픽에 데이터를 저장하는 첫 단계!

acks 옵션

  • 프로듀서의 옵션으로 acks 옵션
  • 프로듀서가 전송한 데이터를 클러스터에 얼마나 신뢰성 있게 저장할 지 지정 가능
  • 옵션에 따라 성능이 달라질 수 있다.

acks = 0

  • 프로듀서가 리더 파티션으로 데이터를 전송했을 때 리더 파티션으로 데이터가 저장되었는지 확인 하지 않는다
  • 리더 파티션은 데이터가 저장된 이후, 몇 번째 오프셋에 저장되었는지 return
  • 이 경우에는 데이터가 저장된 여부에 따른 응답을 받지 않음.

  • 프로듀서는 데이터 전송 실패시, 재시도할 수 있게, retries 옵션 설정 가능
  • 하지만 acks = 0 일 경우, 데이터 전송을 무조건 성공으로 간주, 해당 옵션은 무의미하다.
  • 프로듀서와 브로커 사이의 네트워크 오류나 브로커의 이슈 등을 인하여 데이터가 유실 되더라도, 프로듀서는 리더 파티션으로부터 응답 값을 받지 않음
    • 지속적으로 다음 데이터를 보낸다.
    • 1, -1 일 경우보다 데이터 전송 속도가 훨씬 빠름.
  • 데이터가 일부 유실 되어도 ok? => acks = 0

acks = 1

  • 프로듀서는 보낸 데이터가 리더 파티션에 정상적으로 적재되었는지 확인
  • 정상적으로 적재되지 않았을 경우, 적재될 때까지 재시도
  • 적재되었더라도, 데이터 유실 발생 가능성
    • 복제 개수를 2개 이상으로 운영 시, 팔로워 파티션이 리더 파티션으로부터 복제하기 직전, 리더 파티션에 있는 브로커에 장애 발생 가능
    • 동기화되지 못한 일부 데이터가 유실될 가능성이 있다.

  • 이 경우에는, 리더 파티션에 데이터가 적재될 때까지 기다린 뒤 응답을 받음
  • acks = 0 일 경우보다 전송 속도가 느림.

acks = all || acks = -1

  • 프로듀서는 보낸 데이터가 리더 파티션과 팔로워 파티션에 모두 정상 적재되었는지 확인
  • 모두 확인하므로, 다른 옵션 값들보다 데이터 전송 속도가 느림.
  • 모두 적재되었는지 확인하므로, 일부 브로커에 장애가 발생해도, 안전하게 데이터를 전송하고 저장하는 것을 보장 가능함.

  • acks = all
  • 토픽 단위로 설정 가능한 min.insync.replicas 옵션 값에 따라 데이터의 안정성이 달라짐
  • 이 옵션은 프로듀서가 리더, 팔로워 파티션에 데이터가 정상 적재되었는지 확인하기 위한 최소 ISR 그룹의 파티션 개수
  • 예로, 1 이라면, ISR 중 최소 1개 이상의 파티션에 데이터가 적재되었음을 확인 하는 것.


  • 상용 환경에서 일반적으로 브로커를 3대 이상으로 묶어 클러스터를 운영
  • 이 점을 고려하여 데이터를 안정적으로 보내고 싶으면, 토픽의 최대 개수 = 3, min.insync,replicas = 2 설정
  • acks = all 로 설정해보자~

멱등성 (idempotence) 프로듀서

  • 멱등성 프로듀서 = 동일 데이터를 여러 번 전송해도, 카프카 클러스터에 단 한번 저장
  • 기본 프로듀서의 동작 방식은 At Least Once 를 지원
  • 이 방식은, 프로듀서가 클러스터에 데이터를 전송하여 저장할 때, 적어도 한번 이상 데이터를 적재할 수 있고, 데이터가 유실되지 않음을 일컫는다.
  • 두번 이상 적재 가능성 => 데이터의 중복 발생

  • enable.idempotence 옵션 값 true 설정으로 사용 가능
  • 기본 프로듀서와 다르게, 브로커로 데이터 전달 시, 프로듀서 PID(Producer unique ID) 와 시퀀스 넘버 (sequence number) 로 함께 전달
  • 브로커는 PID, Sequence Number 를 확인 후, 동일 메시지의 적재 요청이 와도, 단 한번만 데이터를 적재함.
    • 프로듀서의 데이터는 정확히 한번 브로커에 적재되도록 동작 (exactly once)


  • 앞서 말했다싶이, 동일한 세션에서만 정확히 한번 전달을 보장
  • 세션 = PID 의 생명주기
  • 멱등성 프로듀서로 동작하는 프로듀서 앱에 문제가 발생하여 종료되고, 재시작하면 PID 가 달라짐!
  • 동일 데이터를 보내더라도, PID 가 다르므로, 브로커 입장에서 다른 프로듀서 앱이 다른 데이터를 보냈다고 판단, 장애가 발생하지 않는 상황에서만 exactly once 를 보장한다는 점을 고려하자.

  • enable.idempotence 를 true 로 설정하면 정확히 한번 적재되는 로직이 성립되기 위해 프로듀서의 일부 옵션들이 강제로 설정
  • 프로듀서의 데이터 전송 횟수를 정하는 retries 는 기본적으로 Integer.MAX_VALUE 가 됨, acks = all 로 설정
  • 이유는, 프로듀서가 적어도 한 번 이상 브로커에 데이터를 보내므로, 단 한 번만 데이터가 적재되는 것을 보장하기 위함이다.

트랜잭션 (transaction) 프로듀서

  • 카프카 트랜잭션 프로듀서는 다수의 파티션에 데이터를 저장할 경우, 모든 데이터에 대해 동일한 원자성 (atomic) 을 만족하기 위해 사용
  • 이 의미는, 다수의 데이터를 동일 트랜잭션으로 묶음, 전체 데이터를 처리하거나, 처리하지 않도록 하는 것임
  • 컨슈머는 기본적으로 프로듀서가 보내는 데이터를 파티션에 쌓이는 대로 모두 가져가서 처리함.
  • 트랜잭션으로 묶인 데이터를 가져갈 때는 다르게 동작하도록 설정 가능

  • 트랜잭션 프로듀서를 사용하려면 enable.idempotence = true 설정
  • transactional.id 를 임의 string 값으로 정의
  • 컨슈머의 isolation.level 을 read_committed 로 설정하면, 프로듀서와 컨슈머는 트랜잭션 처리 된 데이터만 쓰고 읽는다.

  • 트랜잭션은 파티션의 레코드로 구분 됨.
  • 트랜잭션 프로듀서는 사용자가 보낸 데이터를 레코드로 파티션에 저장
  • 트랜잭션의 시작과 끝을 표현하는 레코드를 한 개 더 보냄.
  • 트랜잭션 컨슈머는 파티션에 저장된 트랜잭션 레코드를 보고, 완료 됨을 확인 후 데이터를 가져간다.
  • 만약 데이터가 존재하고 트랜잭션 레코드가 없으면, 완료되지 않았음으로 판단, 데이터를 가져가지 않음!

반응형