devops

Kafka Producer의 파티셔닝 동작 원리 및 전송 방식 본문

DevOps/Kafka

Kafka Producer의 파티셔닝 동작 원리 및 전송 방식

vata500 2022. 11. 20. 21:54
반응형

Producer

카프카의 토픽은 병렬처리가 가능하기 위해서 파티션으로 나뉘어, 최소 하나 이상의 파티션으로 구성된다. 그리고 프로듀서가 카프카로 전송한 메시지는 토픽 내 각 파티션의 로그 세그먼트에 저장된다.

그래서, 프로듀서는 토픽으로 보낼 때 토픽의 어느 파티션으로 메시지를 보내야할 지 결정해야하고 이 때 사용하는 것이 '파티셔너(Partitioner)'다.

그래서 파티션의 증가에 따라 관리자의 의도와 다르게 메시지 전송이 이뤄질 수 있기 때문에 되도록 파티션 수를 변경하지 않는 것이 좋다.

파티셔닝 방법 2가지

https://www.confluent.io/blog/apache-kafka-producer-improvements-sticky-partitioner/

레코드들은 배치 처리를 위해서 프로듀서의 버퍼 메모리 영역에서 잠시 대기한 후에 카프카로 전송된다. 이 때 크게 두가지전략을 고려할 수 있다. 

1) 라운드 로빈 전략

키 값을 지정하지 않은 default 전략이 라운드 로빈 전략이다. 프로듀서는 목적지 토픽의 파티션에 레코드들을 랜덤 전송하는 방식이다. 키 값이 null인 레코드를 순차적으로 하나씩 할당되는데, 문제는 버퍼 메모리 영역에서 불필요하게 대기하는 배치가 발생할 수 있게된다. 

위 그림 처럼 레코드가 모두 채워지지 않고 6개의 파티션에 골고루 쌓이면서 전송이 되지 못하는 상황이 발생한다.

이를 해결하기 위해서 스티키 파티셔닝이 도입되었다.

2) 스티키 파티셔닝 전략

스티키 파티셔닝은 라운드 로빈 전략에 의해 발생하는 지연시간과 비효율적인 전송을 개선할 수 있다. 배치 전송을 위한 레코드 수를 채우지 못하는 문제를 해결할 수 있다.

파티셔너는 배치를 위한 레코드 수에 도달할 때까지 다른 파티션으로 보내지 않고 동일한 파티션으로 레코드를 담는다.

위 사진처럼 6개의 레코드가 2개의 파티션에 모두 채울 수 있게 되어 빠른 전송이 가능해진다. 

전송 방법 3가지

https://medium.com/@andy.bryant/processing-guarantees-in-kafka-12dd2e30be0e

데이터 프로세싱 과정에서 메시지 중복을 다루는 것은 중요하다. 별도 중복 처리 과정이 없으며 데이터 정합성을 체크하 필요가 없기 때문에 시간과 비용을 아낄 수 있다.

이를 위해서 몇가지 방식을 참고해야한다.

1) at-least-once

적어도 한번 전송이라는 뜻에서 브로커가 메시지를 받았다는 ACK를 응답하지 못했을 때를 가정해서 한번 더 전송하는 중복이 발생할 수 있다. 최소한 한번의 메시지 전송은 보장하기 때문에 이 방식이 디폴트로 사용된다.

2) at-most-once

at-least-once와 반대로, 브로커의 ACK 응답이 없어도 다시 전송하지 않는다. 그래서 중복 가능성은 없지만 메시지이 제대로 전송되지 않았을 가능성이 존재한다.

3) exactly-once

메시지의 헤더에 PID와 메시지 번호가 입력되어 전달되는 방식이다. 프로듀서는 고유한 PID를 할당받고, 메시지에 따라 0에서 순차적으로 늘어나는 메시지 번호가 사용된다.

프로듀서가 ACK응답을 받지 못하여 메시지를 재전송하게 되더라도 브로커는 이미 동일한 PID와 메시지번호가 있는 것을 확인하면 중복저장을 피할 수 있게 된다.

그러나 헤더에 PID와 메시지 번호가 할당되기 때문에 기존에 비해서 약 20%의 성능감소가 발생하게 된다.

반응형
Comments