Maru's Study Memo

[프로듀서 내부 동작]

** ProducerRecord로 메시지 키, 값 초기화.
** Partitioner는 메시지 키 유무에 따라 어느 토픽으로 보낼 것인지 지정
** Partitioner가 파티션을 지정한 후 Accumulator는 최대한 배치로 데이터를 모으고 나서 Sender는 데이터를 클러스터로 발송

프로듀서는 데이터를 저장해야하는 토픽의 리더 파티션이 위치한 프로커와 직접 통신합니다

카프카 클라이언트들은 리더 파티션이 위치한 브로커와 직접 통신하기 전에 이미 연결되어 있는 브로커와 통신해서, 리더 파티션이 위치한 브로커의 정보를 가져오는 작업을 합니다.

[메시지 키가 없는 레코드를 발송하는 프로듀서]

** 프로듀서 = 특정 토픽 + 특정 파티션에 데이터를 전송하는 주체
** 프로듀서가 브로커로 데이터 전송을 요청하면 브로커는 파일시스템에 데이터를 저장
** 레코드가 어느 파티션에 저장되었는지 프로듀서는 브로커로부터 응답 받음

레코드를 정의할 때, 실제로 사용하는 데이터를 메시지 값에 저장하고 데이터를 보내면 토픽의 파티션들 중 하나에 데이터가 저장되는데, 메시지 키가 없는 레코드를 보내면 파티션들에 Round-Robin으로 데이터가 돌아가면서 저장됩니다.

** 메시지 키가 없는 레코드
  . 기본적으로 라운드 로빈 형태로 파티션에 데이터를 전송
** 메시지 키가 있는 레코드
  . 해쉬 형태로 변환하여 특정 파티션에 지정되어 저장됨

[기본 파티셔너]

** 기본 파티셔너는 2개를 제공함
  . UniformStickyPartitioner, RoundRobinPartitioner
  . 2.4.0부터는 파티셔너를 지정하지 않을 경우 UniformStickyPartitioner가 기본 설정됨

** UniformStickyPartitioner
  . 배치로 묶어 전송되어야 하는 데이터를 Accumulator에 최대한 묶어서 발송함(메시지 키가 없는 경우)
  . 이전의 RoundRobinPartitioner는 Accumulator의 배치와 무관하게 ProduceRecoder가 들어오는대로 모두 순회하면서 전송했기 때문에 성능이 느렸음(네트워크 사용량이 높음)
  . 메시지 키가 있는 경우에는? -> 메시지 키를 해시 값으로 변환하여 파티션을 지정

[언제 메시지 키를 넣어야 할까?]

** 기본 파티셔너를 사용하는 경우에 "동일 메시지 키는 동일 파티션으로 들어간다"
  . 처리해야 하는 데이터가 컨슈머에 분산되면 안되는 경우 (ex. 상태가 있는 처리를 할 때; Stateful)
  . 처리해야 하는 데이터가 ordering을 만족해야 하는 경우 (ex. 은행 데이터, 결제 데이터)

[메시지 키를 넣으면 안되는 경우]

** 충분히 분산될 만한 메시지 키가 아닌 경우
  . Ex) 레코드의 메시지 값(json)의 스키마 버전 -> 스키마 버전은 빈번히 바뀌는 값이 아니고 분산되지 않기 때문에 일부 컨슈머에는 데이터처리를 하지 않고 계속해서 쉴 수도 있습니다.

다양한 종류가 아닌 데이터에 메시지 키를 사용하면 데이터가 일부 파티션에만 몰릴 수 있습니다. 데이터가 일부 파티션에 몰리게 되면 일부 컨슈머만 데이터가 처리되기 때문에, 컨슈머 측이 데이터를 최대의 성능으로 처리할 수 없습니다.
 
** 파티션 개수가 빈번히 변할 경우
  . 파티션의 개수가 변하면서 메시지 키와 파티션의 할당이 변경됩니다.
  . 이로 인해서 메시지 키를 넣어서 예상하는 동작과 다르게 동작할 수도 있습니다.

[커스텀 파티셔너]

** 메시지 키 뿐만 아니라 메시지 값, 토픽 이름 등을 이용하여 파티션 지정 가능
** 카프카 클라이언트 라이브러리에서 제공하는 Partitioner 인터페이스 사용

기본 파티셔너 2개 외에 다른 파티셔너를 활용하고 싶다면, 카프카 클라이언트 라이브러리의 partitioner 인터페이스를 사용해서 커스텀 파티셔너를 개발, 프로듀서 옵션을 추가하면 됩니다. 커스텀 파티셔너를 사용하면 메시지 키 뿐만 아니라 메시지 값, 토픽 이름, 클러스터 이름을 토대로 파티셔너를 지정할 수 있습니다.

커스텀 파티셔너를 이용하면 여타 메시징 브로커에서 사용하는 것 처럼 우선순위 큐를 만들 수도 있습니다.

위 그림처럼 일반 고객은 파티션 2개에 할당하고, VIP 고객은 파티션 4개에 할당하는 방식을 예로 들 수 있습니다.

1개의 파티션은 최대 1개의 컨슈머에 할당되는 특징을 사용하여 일반 고객 대비 VIP 고객의 데이타 처리를 2배 빠르게 할 수 있다는 장점이 있습니다.