3. 카프카 프로듀서 애플리케이션 개발

프로듀서

• kafka console producer
• 카프카의 데이터 시작점 = 프로듀서
• 리더 파티션이 있는 브로커와 통신을 한다.

• 다른 언어로도 프로듀서를 만들 수 있다. 그런데 자바가 아니면 공식 라이브러리가 아니다. 자바 라이브러리에 비해서 성능, 기능면에서 떨어진다. 그래서 자바를 추천한다.

• Producer record: 프로듀서에서 생성하는 레코드. 토픽과 메시지 값만 있어도 데이터를 보내는데 이상 없다.
• send(): 레코드 전송 요청 메서드
• Partitioner: 어느 파티션으로 전송할 것인가? 기본 값은 DefaultPartitioner로 설정. 메시지 키에 따라서 달라진다.
• Accumulater: 배치로 묶어 전송할 데이터를 모으는 버퍼

프로듀서 파티셔너

UniformStickyPartitioner

• default 파티셔너
• 메시지 키가 null 일 때와 있을 때의 동작이 구분된다.
• 키가 있을 시 동작
  • 해시값과 파티션을 매칭하여 레코드 전송.
  • 동일한 키는 동일한 파티션 번호로 전달
  • 파티션 개수가 변경되면, 메시지 키와 파티션 번호 매칭은 깨진다. 0번으로 가던 것이 1번으로 갈 수도 있다는 뜻. 그래서 토픽을 만드는 단계에서 파티션 개수를 충분히 많이 생성하는 것이 좋다.
• 없을 때 동작
  • 파티션에 동일하게 분배한다.
  • RoundRobinPartitioner에서는 어큐뮤레이터에서 묶이는 정도가 적다.
  • UniformStickyPartitioner 는 레코드들이 배치로 묶일 때 까지 기다렸다가 전송해서 성능이 더 좋다. 이것도 라운드 로빈이긴 하다.

커스텀 파티셔너

• Partitioner 인터페이스를 제공하고 있다.
• Record의 여러가지 데이터를 바탕으로 특정 파티션으로 보낼 수 있다.

프로듀서 주요 옵션

필수 옵션(default 값이 없다)

• bootstarp.servers
  • 어떤 카프카 클러스터로 보낼 것인지? 2개 이상의 브로커 정보를 입력하는 것이 일반적이다. 이름: 포트를 적는 것
• key.serializer
  • 프로듀서 → record를 보낼 때 직렬화를 한다. 레코드의 메시지 키를 직렬화하는 클래스
• value.serializer
  • 마찬가지로 메시지 값을 직렬화 하는 클래스를 지정
  • 직렬화는 것이 좋다. String으로만 하지 말고 float나 int로 하면 더 효율이 좋아진다.
  • 근데 string으로 직렬화하지 않으면 kafka-console-consumer에서 확인을 못한다. 그래서 대부분 운영 상의 이점으로 string으로 한다.

선택 옵션(default 값이 있다)

• acks
  • 0, 1, -1 중에 하나로 설정 가능
  • 브로커에게 정상적으로 저장되었는지 전송 성공 여부 확인
• linger.ms
  • 배치를 전송하기 전까지 기다리는 최소 시간. 기본 값은 0이다.
• retries
  • 브로커로부터 에러를 맏고 난 뒤 재전송을 시도하는 횟수. 기본 값은 매우 큰 값. 작은 수로 바꾸는 것도 좋은 방법
• max.in.flight.requests.per.connection
  • 한번의 요청하는 최대 커넥션 개수.
• partitioner.class
  • 레코드를 파티션에 전송할 때 적용하는 파티셔너 클래스를 지정. UniformStickyPartitioner로 기본으로 지정한다.
• enable.idempotence
  • 멱등성 프로듀서 동작 여부. 기본 false
• transactional.id
  • 레코드를 트랜잭션 단위로 묶을 것인지?

ISR

• 프로듀서의 acks값은 중요하다. 프로듀서 → 브로커로 메시지를 보낼 때 얼마나 신뢰성이 높게 저장할지 지정한다.
• 리더, 팔로워 파티션의 레코드 오프셋이 동일할 때 ISR이 됐다고 한다.
• 복제 시간 차이 때문에 둘 간의 오프셋 차이가 발생한다.

acks = 0 인 경우

• 프로듀서가 리더 파티션으로 전송했을 때, 리더에 저장됐는지 확인 안한다는 것. 보내면 OK라고 본다.
• 가장 속도가 빠르다. 신뢰도는 낮다.
• GPS 데이터와 같은 것을 사용할 때

acks = 1 인 경우

• 프로듀서가 보낸 데이터가 리더 파티션에만 정상적으로 적재되었는지 확인. 적재되면 ack
• 적재되지 않았으면 다음에 승급된 파티션에 적재할 수 있다.
• 받기 까지 시간이 좀 걸린다.
• 근데 대부분 경우는 1로 설정한다.

acks = -1(all) 인 경우

• 프로듀서 → 리더에 저장되었는지, 팔로워도 저장이 되었는지 확인하고 ack
• 0이나 1에 비해서 네트워크 처리량, 속도 매우 낮다.
• 근데 이렇게 까지 안해도 acks = all로두고 min.insync.replicas 옵션 값으로 2로 해서 하나의 리더, 하나의 팔로워만 확인하는 것이 좋다.

min.insync.replicas

• 프로듀서가 리더 파티션, 팔로워 파티션에 데이터가 확인 하는 최소 ISR 그룹의 파티션 개수
• 1이면 acks=1 이랑 같기 때문에 2로 하자

acks = -1, min.insync.replicas = 2

• 이것이 신뢰성 있는 정배이다. 근데 대부분 1로 함