Kafka 파티션 증가/감소

프로젝트/kafka

Junuuu 2023. 8. 12. 00:01

728x90

Kafka의 파티션은 증가시킬 순 있지만 감소할 수 없기 때문에 주의 깊게 증가시켜야 한다는 이야기를 듣게 되었습니다.

Kafka의 파티션은 왜 감소시킬 수 없는지 알아보고자 합니다.

그리고 파티션을 증가하면 어떤일이 일어나는지 알아보고자 합니다.

클라이언트는 메시지를 어느 파티션에 게시할지 제어할 수 있습니다.

이때 로드밸런싱을 구현하여 무작위로 수행하거나, 시맨틱 파티셔닝 함수를 통해 수행될 수 있습니다.

시맨틱 파티셔닝이란 사용자가 키를 지정하는 경우 DefaultPartioner가 키에 대한 해시를 처리합니다.

반대로 사용자가 키를 지정하지 않은 경우에는 라운드로빈 스타일로 파티션을 사용하게 됩니다.

사용자가 직접 Custom Partitioner도 구현할 수 있습니다.

Partitioner 인터페이스를 구현한 뒤 producer의 설정(partitioner.class)에 넣어줄 수 있습니다.

key를 지정한 경우에는 위의 로드밸런싱을 통해 다음 그림과 같이 파티션내부에서는 순서보장이 가능합니다.

targetPartition = Math.abs(Utils.murmur2(keyBytes)) % (numPartitions −1)

결론적으로 위의 식을 보면 파티션의 개수가 있기 때문에 파티션을 추가하면 식의 결괏값이 달라질 수 있습니다.

key를 포함하여 데이터를 보내면 key의 해시값을 기준으로 파티션이 결정됩니다.

이때 파티션의 수가 변경되면 순서의 보장이 더 이상 유지되지 않을 수 있습니다.

이런 상황을 피가히 위해 기본적으로 1~2년 후의 미래 목표 처리량을 기준으로 파티션 수를 결정합니다.

순서보장이 무조건 일어나야 한다면, 파티션을 추가하는 대신 새로운 토픽을 만들어 데이터를 마이그레이션 해야 할 것 같습니다.

결론적으로는 그렇지 않습니다.

파일 핸들러가 낭비되고, 장애 복구 시간이 증가될 수 있습니다.

각 파티션은 브로커의 디렉터리와 매핑되고 모든 디렉터리의 파일에 대해 파일 핸들을 열게 됩니다.

파티션이 많아질 수록 파일 핸들러의 수가 많아져 리소스가 낭비됩니다.

kafka는 고가용성을 제공하기 위해 Broker에 대한 message replication factor를 제공합니다.

이때 복제 옵션을 주어 partition에 들어온 message를 복제할 수 있는데 Partition의 메시지를 복제하는 것을 처리하는데 시간이 걸리게 됩니다.

이때 Cluster에 존재하는 Broker에 장애가 발생하면 복제의 기준이 되는 리더가 사라지게 되고 장애복구를 위해 복제하는 게 시간이 많이 걸리게 됩니다.

동적으로 파티션을 감소시키려는 경우 어떤일이 일어나야 할까요?

여러 복합적인 이유가 있을 수 있지만 다수 브로커에 분배되어 있는 세그먼트를 다시 재배열하는 것에 상당한 리소스가 들어가기 때문에 파티션을 감소시킬 수 없습니다.

KIP-694에서 파티션 개수를 줄이는 방안에 대해 논의했으나 더 이상 진행되고 있지 않습니다.

원하는 파티션 수로 새 토픽을 만든 다음 이전 토픽에서 새 토픽으로 데이터를 마이그레이션 할 수 있습니다.

참고자료

https://kafka.apache.org/documentation/#majordesignelements