Kafka의 파티션

 

Kafka에는 브로커(서버)가 있고 

메시지가 전달되는 기준인 토픽이 다수 개 존재하며

한 토픽 내부에도 여러 파티션으로 나뉘어져 각각의 파티션에 메시지들이 저장되고 전달된다.

 

위 사진의 0이 들어있는 큐를 보면 토픽1 내부의 파티션 중 하나와 매칭이 되어 있는 것을 볼 수 있다.

이와 같이 파티션은 하나의 큐와 같은 형태로 동작하고 각 큐(파티션)은 내부의 메시지에 오프셋을 달아

메시지의 순서를 관리하고 전달한다.

 

그렇기 때문에

토픽 내 파티션이 많을수록 더욱 많은 메시지의 병렬처리가 가능해지기 때문에

파티션의 수는 Kafka의 병렬처리 단위라고도 말할 수 있다.

 

허나 Throughput(처리량)이 증가함에 따라 발생하는 Trade-off도 당연 존재한다.

 

 

1) 파일 핸들러의 증가

각 파티션 별로 담당하는 Open file handler는 2개씩 존재한다.(인덱스용, 실 데이터 저장 용)

따라서 파티션 수 * 2 만큼 OS의 file handler 자원을 잡아먹게 된다.

 

2) End-to-End 전송속도의 지연

Kafka는 각 메시지의 Replication이 전부 완료된 후에 메시지를 수신 가능하게끔 Consumer에게 보여준다.

이 복제는 모든 Partition 각각을 대상으로 하기 때문에 파티션이 늘어날수록

이 Replication이 모두 이뤄지는 시점도 늦춰지므로 당연히 전송 속도가 느려질 수 밖에 없다.

 

이를 제외하고도 Producer나 Consumer의 메모리를 좀 더 잡아먹는다는지

혹은 Kafka의 가용성을 낮춘다는지의 부작용이 존재한다.

 

그렇다면 어떻게 적절한 파티션의 수를 선정할 수 있을까?

그건 이제 나도 알아봐야 한다.