카프카 기본 개념과 구조

프로듀서의 기본 동작과 예제 맛보기

프로듀서 디자인

• ProducerRecord라고 표시된 부분은 카프카로 전송하기 위한 실제 데이터이다
• 레코드는 토픽, 파티션, 키, 벨류로 구성된다
• 레코드의 토픽과 벨류는 필수값이다
• 특정 파티션을 지정하기 위한 레코드의 파티션과 특정 파티션에 레코드들을 정렬하기 위한 레코드의 키는 필수값이 아닌 옵션이다
• 각 레코드들은 프로듀서의 send() 메소드를 통해 시리얼라이저, 파티셔너를 거치게 된다
• 프로듀서 레코드의 옵션인 파티션을 지정했다면, 파티셔너는 아무 동작도 하지 않고 지정된 파티션으로 레코드를 전달한다
• 파티션을 지정하지 않은 경우에는 키를 가지고 파티션을 선택해 레코드를 전달하는데, 기본적으로 라운드 로빈 방식으로 동작한다
• 프로듀서 내부에서는 send() 메소드 동작 이후 레코드들을 파티션별로 잠시 모아둔다
• 레코드들을 모아두는 이유는 프로듀서가 카프카로 전송하기 전, 배치 전송을 하기 위함이다
• 전송이 실패하면 재시도 동작이 이뤄진다
• 지정된 횟수만큼의 재시도가 실패하면 최종적으로 실패를 전달하며, 전송이 성공하면 메타데이터를 리턴한다

---

프로듀서의 주요 옵션

프로듀서 옵션	설명
bootstrap.servers	카프카 클러스터는 마스터라는 개념이 없으므로, 클라이언트가 카프카 클러스터에 처음 연결하기 위한 호스트와 포트 정보
client.dns.lookup	하나의 호스트에 여러 IP를 매핑해 사용하는 일부 환경에서 클라이언트가 하나의 IP와 연결하지 못할 경우에 다른 IP로 시도하는 설정 *use_all_dns_ips (default) : DNS에 할당된 호스트의 모든 IP를 쿼리하고 저장한다. 첫 번째 IP로 접근이 실패하면, 종료하지 않고 다음 IP로 접근을 시도한다. *resoleve_canonical_bootstrap_servers_only : 커버로스(Kerberos) 환경에서 FQDN을 얻기 위한 용도로 사용된다
acks	프로듀서가 카프카 토픽의 리더 측에 메세지를 전송한 후 요청을 완료하기를 결정하는 옵션으로 0, 1, all(-1)로 표현한다 *0: 빠른전송을 의미, 일부 메세지 손실가능 *1: 리더가 메세지를 받았는지 확인하지만, 모든 팔로워를 확인하지는 않는다. 대부분 기본 값으로 1을 사용한다. *all(-1): 팔로워가 메세지를 받았는지 여부를 확인한다. 다소 느리지만 메세지는 손실되지 않는다.
buffer.memory	프로듀서가 카프카 서버로 데이터를 보내기 위해 잠시 대기(배치 전송이나 딜레이 등) 할 수 있는 전체 메모리 바이트
compression.type	프로듀서가 메세지 전송 시 선택할 수 있는 압축 타입. (none, gzip, snappy, lz4, zstd)
enable.idempotence	설정을 true로 하는 경우 중복 없는 전송이 가능하며, 이와 동시에 max.in.flight.requests.per.connection은 5이하, retries는 0이상 acks는 all로 설정해야한다.
max.in.flight.requests.per.connection	하나의 커넥션에서 프로듀서가 최대한 ACK 없이 전송할 수 있는 요청수, 메세지의 순서가 중요하다면 1로 설정할 것을 권장하지만 성능은 다소 떨어진다
retires	일시적인 오류로 인해 전송에 실패한 데이터를 다시 보내는 횟수
batch.size	프로듀서는 동일한 파티션으로 보내는 여러 데이터를 함께 배치로 보내려고 시도한다. 적절한 배치 크기 설정은 성능에 도움을 준다
linger.ms	배치 형태의 메세지를 보내기 전에 추가적인 메세지를 위해 기다리는 시간을 조정하고, 배치 크기에 도달하지 못한 상태에서 linger.ms 제한 시간에 도달했을 때 메세지를 전송한다
transactional.id	'정확히 한 번 전송' 을 위해 사용하는 옵션이며, 동일한 TransactionId에 한해 정확히 한 번을 보장한다. 옵션을 사용하기 전 enable.idempotence를 true로 설정해야 한다

---

프로듀서 예제