3. Kafka - 키가 없는 경우의 파티셔닝 전략

카프카를 파티셔닝해서 쓰는 경우, 어떻게 파티셔닝이 이뤄질까?

 

카프카는 키가 없는 경우의 파티셔닝 전략으로 2가지 파티션 분배 전략을 가지고 있다.

 

1) 라운드 로빈 (Round Robin) - Kafka 2.4 버전 이전 기본 파티셔닝 전략

2) 스티키 파티셔닝 (Sticky Partitioning) - Kafka 2.4버전 이상 기본 파티셔닝 전략

 

라운드 로빈은 순차적으로 메시지를 파티셔닝 하는 것이며,

요즘 사용하고 있는 카프카는 거의 대부분 "스티키 파티셔닝"일 것이다.

 

먼저 Kafka Producer에서 만들어진 메시지는 브로커의 특정 토픽 파티션에 들어가기 전,

파티셔너 (Partitioner)에 의해 "Batch"라는 단위로 모여 있다가, Batch 단위로 파티션에 send 된다.

 

즉 Producer에서 생산된 메세지가 1, 2, 3, 4, 5, 6, 7 순서로 들어왔고, 파티션이 2개라면,

		Topic
Producer	Batch 0	Partition 0
	1, 3, 5, 7	1, 3, 5, 7
1,2,3,4,5,6,7 순서	Batch 1	Partition 1
	2, 4, 6	2, 4, 6

 

이렇게 순차적으로 배치에 메시지가 넣어지고, Partition으로 배치 단위로 보내진다.

그러면 어떤 단위로 보내질까? 

 

바로 배치 단위로 보내지기 때문에 일정량이 채워지지 않으면 파티션으로 메시지가 보내지지 않는다.

그러면 batch.size 옵션을 줄여서 일정량인 배치 크기를 줄일 수 있고,

linger.ms 옵션을 통해서 다음 배치를 기다리는 시간을 조절할 수도 있다.

 

하지만, 이렇게 줄여서 거의 실시간에 가깝게 전송된다면? 부하가 생기거나

전송횟수가 많아지는 만큼 배치의 효율이 떨어지게 된다.

 

그러면 2.4 버전 이후의 스티키 파티셔닝은 어떨까?

		Topic
Producer	Batch 0	Partition 0
	1, 2, 3, 4	1, 2, 3, 4
1,2,3,4,5,6,7 순서	Batch 1	Partition 1
	5, 6, 7	5, 6, 7

 

하나의 배치크기가 4라고 가정한다면, Batch0 메시지를 먼저 빠르게 채워져 송신된다. 

즉, 하나의 배치 크기를 먼저 빠르게 채워 송신시키는 방식이다. 

 

아래의 코드로 컨슈머를 실행시켜둔 뒤, 스티키 파티셔닝이 어떻게 진행되는지 확인해보자.

docker exec -it kafka kafka-console-consumer --bootstrap-server localhost:9092 --topic multipart-topic --property print.partition=true

 

아래의 코드로 프로듀서를 열어 마구마구 눌러보자.

docker exec -it kafka kafka-console-producer --bootstrap-server localhost:9092 --topic multipart-topic

 

테스트 시에 a를 마구 보내고 b를 마구 보낸 후 d를 일정 시간 뒤에 보내보았다.

 

여기서 확인해볼 수 있는 점은?

일정 시간 내에 마구 보내면 약 7개 정도가 배치 사이즈로 정해져있다는 것을 확인할 수 있었다.

또한, 스티키 파티셔닝 전략을 통해 하나의 파티션에 보내질 배치를 먼저 채워넣는 방식이란 것을 알 수 있으며,

계속 7개씩 배치사이즈로 파티션에 들어가다가, 조금 뒤에 d를 쳤을 때에는 0번 파티션에 들어가지 않고,

1번 파티션에 보내진 것으로 보아, 일정 시간이 지난 0번 파티션은 이미 전송된 후였던 것이다.

 

그렇게 본다면, 확실히 스티키 파티셔닝이 기존의 라운드 로빈 보다는 효율적이라고 볼 수 있을 것 같다.