본문으로 바로가기

Kafka 학습하기_프로듀서

category MQ 2024. 6. 4. 08:00
반응형


[인프런 - 아파치 카프카 애플리케이션 프로그래밍]

 

프로듀서 애플리케이션

ProducerRecord: 프로듀서에서 생성하는 레코드. 오프셋은 미포함.
Send: 레코드를 전송 요청 메서드.
Partitioner: 어느 파티션으로 전송할지 지정하는 파티셔너. 기본값으로 DefaultPartitioner로 설정됨.
Accumulator: 배치로 묶어 전송할 데이터를 모으는 버퍼

 

 

프로듀서의 기본 파티셔너
프로듀서API를 사용하면 2개의 파티셔너를 제공한다. UniformStickyPartitioner, RoundRobinPartitioner 
2.5.0 버전에서 파티셔너를 지정하지 않는 경우 UniformStickyPartitioner로  설정된다.

 

메시지 키가 있을 경우 동작

UniformStickyPartitioner와 RoundRobinPartitioner 둘 다 메시지 키가 있을 때는 메시지 키의 해시값과 파티션을 매칭하여 레코드를 전송한다.
동일한 메시지 키가 존재하는 레코드는 동일한 파티션 번호에 전달됨.
만약 파티션 개수가 변경될 경우 메시지 키와 파티션 번호 매칭은 깨지게 됨.

메시지 키가 없을 때 동작
RoundRobinPartitioner 방식은 ProducerRecord가 들어오는 대로 파티션을 순회하면서 전송, 어큐뮤레이터에서 묶이는 정도가 적기 때문에 전송 성능이 낮음.
UniformStickyPartitioner 방식은 어큐뮤레이터에서 레코드들이 배치로 묶일 때까지 기다렸다가 전송. 배치로 묶일 뿐 결국 파티션을 순회하면서 보내기 때문에 모든 파티션에 분배되어 전송됨.

프로듀서의 커스텀 파티셔너
메시지 키 뿐만 아니라 메시지 값까지 확인해서 특정 파티션으로 보내는 로직을 커스텀하게 구현해 쓸 수 있다

 

프로듀서 주요 옵션(필수)

bootstrap.servers 
- 프로듀서가 데이터를 전송할 대상 카프카 클러스터에 속한 브로커의 호스트 이름:포트를 1개 이상 작성
- 2개 이상 브로커 정보를 입력해 일부 브로커에 이슈가 발생하더라도 접속하는 데 이슈가 없도록 설정 가능

key.serializer
- 레코드의 메시지 키를 직렬화하는 클래스 지정

value.serializer
- 레코드의 메시지 값을 직렬화하는 클래스 지정

 

프로듀서 주요 옵션(선택)

acks
- 프로듀서가 전송한 데이터가 브로커들에 정상적으로 저장되었는지 전송 성공 여부를 확인하는 데 사용하는 옵션. 

- 기본값은 1
- 전송만 성공했는지, 리더 파티션에만 저장되었는지, 팔로 파티션까지 복제가 되었는지 등 확인

linger.ms
- 배치를 전송하기 전 까지 기다리는 최소 시간. 기본값은 0
- 일부 지연을 감수하고 최대한 많은 데이터를 한번에 보내고 싶으면 옵션 지정 가능

retries
- 브로커로부터 에러를 받고 난 뒤 재전송을 시도하는 횟수. 기본값은 2147483647
- 재전송 필요없으면 값을 줄이거나 0으로 설정

max.in.flight.requests.per.connection
- 한 번에 요청하는 최대 커넥션 개수. 설정된 값만큼 동시에 전달 요청을 수행
- sender에서 브로커로 데이터 전송 시 커넥션을 생성해서 진행하는데, 브로커로 동시에 전송할 양이 많다면 해당 설정값을 늘려 대응할 수 있음

partitioner.class
- 레코드를 파티션에 전송할 때 적용하는 파티셔너 클래스, 2.5.0부터는 UniformStickyPartitioner가 기본값

enable.idempotence
- 멱등성 프로듀서로 동작할지 여부, 데이터 중복 전송을 막기 위함

transactional.id
- 프로듀서가 레코드를 전송할 때 레코드를 트랜잭션 단위로 묶을지 여부를 설정, 기본값은 null

 

ISR(In-Sync-replicas)


리더 파티션과 팔로우 파티션이 모두 싱크 된 상태
ISR이라는 용어가 나온 이유는 팔로우 파티션이 리더 파티션으로부터 데이터를 복제 하는데 시간이 걸리기 떄문
이 복제 시간 차 때문에 리더와 팔로우 간 오프셋 차이가 발생함

 

acks
acks 옵션을 통해 카프카 클러스터에 얼마나 신뢰성 높게 저장할지 지정할 수 있다, 신뢰성과 성능은 trade-off 관계

 

acks=0


프로듀서가 리더 파티션으로 데이터를 전송했을 때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다는 뜻이다.
데이터 전송 속도는 1 또는 all보다 훨씬 빠르고 데이터 일부 유실 발생해도 속도가 중요한 경우에는 이 옵션값 사용하면 된다.

 

acks=1


프로듀서는 보낸 데이터가 리더 파티션에만 정상 적재되었는지 확인함

리더 파티션에 정상 적재되지 않았다면, 적재될때까지 재시도 가능
ISR을 2이상으로 운영할 경우 리더에 적재 완료되어도 팔로우에는 아직 동기화되지 않을 수 있는데, 팔로우에서 데이터를 복제하기전에 리더에 장애가 발생하면 동기화되지 못한 데이터는 유실될 수 있다.


acks=-1(all)


프로듀서는 보낸 데이터가 리더 파티션과 팔로워 파티션에 모두 정상 적재되었는지 확인한다. 일부 브로커에 장애가 발생해도 안전히 데이터를 전송하고 저장할 수 있음을 보장할 수 있다 대량 처리시 속도가 너무 느려 처리량이 안좋음.

 

min.insync.replicas 

acks=all일 경우 최소 적재 보장 파티션 개수.

반응형

'MQ' 카테고리의 다른 글

Kafka Pub 호출 방안  (0) 2024.08.18
Kafka 학습하기_컨슈머  (0) 2024.06.05
Kafka 학습하기_토픽, 파티션, 레코드  (0) 2024.06.02
Kafka 학습하기_브로커와 클러스터  (0) 2024.06.01
Kafka 학습하기_장단점  (0) 2024.06.01