[Apache Kafka] 카프카 프로듀서 상세 개념

데이터 유실을 막기 위해서 프로듀서에서 제공하는 다양한 옵션을 함께 사용해야 한다. 여기서는 프로듀서의 고급 활용법과 옵션별 동작 방식에 대해 알아본다.

acks 옵션

• 카프카 프로듀서읭 acks 옵션은 0, 1, all(또는 -1) 값을 가질 수 있음
• 이 옵션을 통해 프로듀서가 전송한 카프카 클러스터에 얼마나 신뢰성 높게 저장할지 지정 가능
• 또한, acks 옵션에 따라 성능이 달라질 수 있으므로 acks 옵션에 따른 카프카의 동작 방식을 상세히 알고 설정해야 함
• 복제 개수(replication.factor)가 1인 경우 acks 옵션에 따른 성능 변화가 크지 않으므로 여기선느 복제 개수가 2 이상인 경우에 대해 알아보자

acks=0

• 프로듀서가 리더 파티션으로 데이터를 전송했을 때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다는 뜻
  • 프로듀서가 데이터를 보낸 이후에 이 데이터가 몇 번째 오프셋에 저장되었는지 확인 불가
• acks가 0일 때는 데이터 전송이 실패했음을 감지하지 않기에 retries 옵션값은 무의미함
  • retries 옵션: 데이터의 전송이 실패했을 때 재시도 할 수 있도록 설정하는 옵션
• 데이터가 유실되더라도 응답이 없으니 프로듀서는 지속적으로 다음 데이터를 보냄
  • => 데이터 전송 속도는 acks 1 또는 all로 설정했을 때보다 훨씬 빠름
  • 데이터의 일부 유실이 허용되며 전송 속도가 중요한 경우 이 옵션을 사용하면 좋음

acks=1

• 프로듀서는 보낸 데이터가 '리더 파티션에만' 정상적으로 적재되었는지 확인
  • 리더 파티션에 정상적으로 적재되지 않은 경우, 리더 파티션에 적재될 때까지 재시도 가능
• 여전히, 팔로워 파티션에는 데이터가 동기화 되지 않을 수 있음
  • 팔로워 파티션이 데이터를 복제하기 직전, 리더 파티션이 있는 브로커에 장애가 발생하면 동기화되지 못한 일부 데이터가 유실 가능
• acks를 0으로 설정하는 것에 비해 신뢰성은 높지만 속도는 느림

acks=all 또는 acks=-1

• 프로듀서는 보낸 데이터가 'ISR 그룹에 포함된 파티션들'에 정상 적재되었는지 확인
  • 리더와 팔로워 모두 확인하기에 속도가 가장 느림
  • but, 일부 브로커에 장애가 발생하더라도 프로듀서는 안전하게 데이터를 전송하고 저장할 수 있음이 보장
• min.insync.replicas 옵션값에 따라 안정성이 달라짐
  • min.insync.replicas: 리더 파티션과 팔로워 파티션에 데이터가 적재되었는지 확인하기 위한 최소 ISR 그룹의 파티션 개수
    • ex) 이 값이 1이라면, ISR 중 최소 1개 이상의 파티션에 데이터가 적재되었음을 확인
      • 이 경우, acks를 1로 설정했을 때와 동일하게 동작함 (ISR 중 가장 처음 적재가 완료되는 파티션은 리더 파티션이니까)
      • min.insync.replicas을 2로 설정했을 때부터 acks를 all로 설정하는 것의 의미가 있음
• min.insync.replicas를 설정할 때는 복제 개수(replication.factor)도 함께 고려해야 함
  • 운영하는 카프카 브로커 개수가 min.insync.replicas의 옵션값보다 작은 경우, 프로듀서는 더는 데이터를 전송할 수 없기 때문
  • ex) 복제 개수를 3으로 설정하고 min.insync.replicas를 3으로 설정한 경우 브로커 3대 중 1대에 이슈 발생 시 프로듀서는 더이상 데이터를 해당 토픽에 전송 불가..
    • 최소한으로 복제되어야 하는 파티션 개수가 3인데, 팔로워 파티션이 위치할 브로커의 개수가 부족하기 때문
    • 이 경우 NotEnoughReplicasException 또는 NotEnoughReplicasAfterAppendException이 발생
• min.insync.replicas 옵션 설정 시 절대로 브로커 개수와 동일한 숫자로 설정하면 안됨
  • 카프카 클러스터의 버전 업그레이드와 같은 상황 발생 시 브로커는 롤링 다운 타임이 생기는데, 브로커가 1대라도 중단되면 프로듀서가 데이터를 추가할 수 없게 됨.. (최소한 min.insync.replicas에 설정된 값만큼 브로커가 실행 중이어야 복제본이 생기는 것을 만족할 수 있기 때문)
  • => 토픽별 min.insnyc.replicas 옵션값은 브로커 개수 미만으로 설정해서 운영해야 함
• 상용환경에서 가장 안정적으로 데이터를 보내기 위한 권장 설정은 다음과 같음
  • replication.factor=3
  • min.insync.replicas=2
  • acks=all

---

멱등성(idempotence) 프로듀서

• 멱등성(idempotence): 여러 번 연산을 수행하더라도 동일한 결과가 나타나는 것을 의미
• 멱등성 프로듀서: 동일한 데이터를 여러 번 전송하더라도 카프카 클러스터에 '단 한번만' 저장됨을 의미

적어도 한 번 전달(at least once delivery)

• 기본 프로듀서의 동작 방식은 '적어도 한 번 전달(at least once delivery)'을 지원
  • 적어도 한 번 전달: 프로듀서가 클러스터에 데이터를 전송하여 저장할 때 적어도 한 번 이상 데이터를 적재할 수 있고, 데이터가 유실되지 않음
    • 다만, 2번 이상 적재할 가능성이 있음 = 데이터 중복 발생
• 데이터 중복 적재를 막기 위해 enable.idempotence 옵션을 사용하여 '정확히 한 번 전달(exactly once delivery)'를 지원
  • enable.idempotence=true 설정 시 멱등성 프로듀서로 동작
• 멱등성 프로듀서는 기본 프로듀서와 달리 데이터를 브로커로 전달할 때 프로듀서 PID(Producer Unique ID)와 시퀀스 넘버를 함께 전달
  • 브로커는 이를 확인하여 동일한 메시지의 적재 요청이 오더라도 단 한 번만 데이터를 적재함으로써 프로듀서의 데이터는 정확히 한 번 브로커에 적재되도록 동작
• 단, 멱등성 프로듀서는 동일한 세션에서만 정확히 한 번 전달을 보장
  • 동일 세션 = PID의 생명 주기
  • 프로듀서가 이슈 등으로 인해 종료되고 재시작하면 PID가 달라지므로 세션이 달라짐
  • => 멱등성 프로듀서는 장애가 발생하지 않을 경우에만 정확히 한 번 적재하는 것을 보장

enable.idempotence=true 설정 시 함께 강제 설정되는 옵션들

• retries 옵션 -> Integer.MAX_VALUE로 설정
• acks 옵션 -> all로 설정
• 프로듀서가 적어도 한 번 이상 브로커에 데이터를 보냄으로써 브로커에 단 한 번만 데이터가 적재되는 것을 보장하기 위함
  • 멱등성 프로듀서는 정말로 한 번만 전송하는 것이 X -> 상황에 따라 여러 번 전송하되 브로커가 여러 번 전송된 데이터를 확인하고 중복된 데이터는 적재하지 않는 것

OutOfOrderSequenceException

• 멱등성 프로듀서의 시퀀스 넘버는 0부터 시작하여 숫자를 1씩 더한 값이 전달됨
• 브로커에서 멱등성 프로듀서가 전송한 데이터의 PID와 시퀀스 넘버를 확인하는 과정에서 시퀀스 넘버가 일정하지 않은 경우(예상과 다를 경우) -> OutOfOrderSequenceException 발생
• 순서가 중요한 데이터를 전송하는 프로듀서는 OutOfOrderSequenceException이 발생했을 경우 대응하는 방안을 고려해야 함

---

트랜잭션(transaction) 프로듀서

• 트랜잭션 프로듀서: 다수의 파티션에 데이터를 저장할 경우, 모든 데이터에 대해 동일한 원자성(atomic)을 만족시키기 위해 사용
• 원자성: 다수의 데이터를 동일 트랜잭션으로 묶어서 전체 데이터를 처리하거나 전체 데이터를 처리하지 않는 것
• 트랜잭션 프로듀서 사용 방법
  1. enable.idempotence=true 설정
  2. transactional.id를 임의의 String 값으로 정의
  3. 컨슈머의 isolation.level을 read_committed로 설정
• 위처럼 설정하면 프로듀서와 컨슈머는 트랜잭션으로 처리 완료된 데이터만 쓰고 읽게 됨

• 트랜잭션은 파티션의 레코드로 구분
• 트랜잭션 프로듀서는 사용자가 보낸 데이터를 레코드로 파티션에 저장하고, 트랜잭션의 시작과 끝을 표현하기 위해 트랜잭션 레코드를 한 개 더 보냄
• 트랜잭션 컨슈머는 파티션에 저장된 트랜잭션 레코드를 보고 트랜잭션이 커밋되었음을 확인 후 데이터를 가져감
• 트랜잭션 레코드: 실질적인 데이터는 없으며 트랜잭션이 끝난 상태를 표시하는 정보만 가지는 레코드
  • 단, 레코드의 특성은 그대로 가지고 있기에 파티션에 저장되어 오프셋을 한 개 차지

• 트랜잭션 컨슈머는 커밋이 완료된 데이터가 파티션에 있을 경우에만 데이터를 가져감
  • 만약 데이터만 존재하고 트랜잭션 레코드가 존재하지 않을 경우 트랜잭션이 완료되지 않았다고 판단하고 데이터 가져가지 않음