CHAPTER8. ‘정확히 한 번’ 의미 구조

8.1 멱등적 프로듀서

• 목적:
  • 동일 메시지가 브로커에 중복 저장되는 것을 방지.
  • 프로듀서의 재시도로 인한 중복만 방지하며, 동일 메시지를 반복 호출한 경우는 탐지하지 못함.
• 작동 원리:
  1. 프로듀서 ID (PID)와 시퀀스 번호를 사용해 각 메시지를 고유하게 식별.
  2. 브로커는 마지막 5개 메시지의 시퀀스 번호를 추적하여 중복 메시지 필터링.
  3. 프로듀서 설정:
     • enable.idempotence=true.
     • max.in.flight.requests.per.connection <= 5.
• 제약사항:
  • 브로커 장애나 리더 교체로 인해 일부 메시지가 유실될 수 있음.

 

8.2 트랜잭션

• 목적:
  • 다중 파티션 쓰기 및 오프셋 커밋을 원자적으로 처리하여 데이터 일관성 보장.
  • 정확히 한 번 의미 구조(Exactly Once Semantics, EoS) 구현.
• 활용 사례:
  • 금융 애플리케이션, 데이터 정확성을 요구하는 스트림 처리.

8.2.1 트랜잭션의 작동 원리

1. 트랜잭션 시작:
   • initTransactions() 호출로 트랜잭션 초기화.
   • beginTransaction()으로 트랜잭션 범위 설정.
2. 오프셋과 메시지 처리:
   • 출력 메시지: 출력 토픽에 기록.
   • 오프셋 정보: __consumer_offsets 토픽에 저장.
   • sendOffsetsToTransaction()으로 처리된 오프셋을 트랜잭션에 포함.
3. 트랜잭션 완료:
   • 커밋: commitTransaction()으로 메시지와 오프셋 동시 커밋.
   • 중단: abortTransaction() 호출 시 모든 메시지 롤백.

8.2.2 트랜잭션의 주요 기능

1. 좀비 팬싱 (Zombie Fencing):
   • transactional.id와 Epoch를 사용하여 중복 트랜잭션 프로듀서 차단.
2. 격리 수준 설정:
   • read_committed: 커밋된 데이터만 읽기.
   • read_uncommitted: 모든 데이터 읽기.
3. 내부 메커니즘:
   • 2단계 커밋: 트랜잭션의 안정성 확보.
   • 내부 토픽 사용:
     • __transaction_state: 트랜잭션 상태 저장.
     • 트랜잭션 로그로 중단된 작업 복구.

8.2.3 해결 가능한 문제

• 중복 방지:
  • 애플리케이션 크래시로 인한 재처리 방지.
  • 좀비 컨슈머로 인한 데이터 중복 방지.

8.2.4 해결 불가능한 문제

• 스트림 처리의 부수 효과(side effects).
• 데이터베이스와의 트랜잭션:
  • 아웃박스 패턴 권장.
  • 중계 서비스가 카프카에서 읽고 데이터베이스를 업데이트.
• 클러스터 간 데이터 복제:
  • 미러메이커로 데이터 복제를 수행하나, 트랜잭션 원자성은 보장하지 않음.

8.2.5 트랜잭션 사용법

• 스트림즈 사용:
  • processing.guarantee=exactly_once 설정으로 트랜잭션 활성화.
• API 직접 사용:
  • 프로듀서 설정에 transactional.id 추가.
  • 트랜잭션 관련 메서드(initTransactions, commitTransaction 등) 호출.

 

8.3 트랜잭션 성능

• 프로듀서 오버헤드:
  • 트랜잭션 초기화와 커밋 요청의 동기 처리로 인해 성능 저하.
  • 메시지를 한 번에 많이 포함시키는 것이 유리.
• 컨슈머 오버헤드:
  • 커밋 마커를 읽는 작업에서 추가 오버헤드 발생.

 

8.4 요약

• 멱등적 프로듀서:
  • 프로듀서의 재시도로 발생하는 메시지 중복 방지.
• 트랜잭션:
  • 스트림 처리 및 다중 파티션 쓰기에서 정확히 한 번 보장을 구현.
• 제약사항:
  • 데이터베이스와의 트랜잭션이나 클러스터 간 복제는 별도 설계 필요.
• 활용 방법:
  • 카프카 스트림즈의 설정 또는 트랜잭션 API 사용.