파티션이 많을 때의 단점

토픽이 여러 파티션으로 분산되어 저장됨으로써 프로듀서/컨슈머가 각 파티션들에 붙어 병렬적으로 처리할 수 있다.

그래서 파티션의 수가 많아질수록 한번에 병렬처리할 수 있는 데이터가 많아지기 때문에 처리량이 높아지지만, 그렇다고 파티션을 무작정 늘리는 것이 답은 아니다.

파일 핸들 요청 증가

UNIX 계열에서 파일 디스크립터(File Descriptor)라고도 불리는 파일 핸들이란, OS가 어떤 파일을 열기 위해 파일에 할당한 레퍼런스 번호이다.

프로세스가 어떤 파일을 열게 되면 비어있는 파일 디스크립터 값을 할당한 뒤, 시스템 콜을 통해 파일에 접근할 시 해당 값을 이용하게 된다.

각 파티션들은 브로커의 파일시스템에 존재하는 디스크 상의 특정 경로와 매핑이 되고, 이 경로 안에는 실제 데이터를 저장하는 파일과 인덱싱을 위한 파일이 저장되는데, 카프카는 이러한 모든 파일들에 대해서 파일 디스크립터를 유지한다.

즉, 브로커들은 파티션마다 존재하는 데이터와 인덱스 파일 모두에 대한 파일 핸들을 여는 것이다.

따라서 파티션이 많아질수록 파일의 수와 파일 핸들에 대한 요청도 많아지고, 이렇게 될 경우 자원이 낭비될 뿐만 아니라 운영체제에서 설정한 파일 핸들 수를 초과하면서 문제가 발생할 수 있다.

내부적으로, 프로듀서들은 파티션마다 일정한 메시지들을 버퍼에 저장한다.

일정한 크기의 데이터가 쌓여서 버퍼가 차게 되면, 버퍼를 비우면서 브로커에게 메시지들을 전달한다.

만약에 파티션의 수가 증가하게 된다면, 프로듀서에서 버퍼에 모으는 데이터 양이 그에 비례해서 많아지고(파티션마다 관리), 이러한 총량이 프로듀서에서 할당된 메모리 사용량을 초과하며 문제가 발생할 수 있다.

컨슈머도 파티션들에 붙어 메시지를 가져오는데, 마찬가지로 파티션이 많을수록 컨슈머가 가져오는 메시지들도 많아지면서 메모리 사용량도 많아진다.

end-to-end latency란 프로듀서가 메시지를 publish 하고 컨슈머가 메시지를 가져갈 때 까지 걸리는 시간을 말한다.

카프카는, 브로커의 리더 파티션에 메시지가 들어온 뒤 팔로워 파티션들에 복제되어 ISR 상태에 도달한 이후에 컨슈머들에게 메시지를 노출시키므로, 메시지를 커밋하는 시간이 이러한 end-to-end latency에 큰 영향을 미친다.

예를 들어 1000개의 파티션을 다른 브로커로 복제하는데 약 20ms 정도의 시간이 걸린다면, 레이턴시는 최소 20ms 가 되는 것이다.

카프카는 기본적으로 두 브로커 간에 데이터를 복제하는데 하나의 쓰레드만을 사용하고, 파티션이 많아질수록 데이터를 복제하는 시간이 길어지므로 레이턴시가 증가한다.

일반적으로 이런 레이턴시를 고려할 때는 브로커당 파티션의 개수를 1000 * number_of_brokers * replication_factor로 제한한다.

카프카는 장애가 발생해도 문제 없이 실행되는 내장애성을 위해 데이터를 다른 브로커들에 복제해놓는다.

토픽이 여러 파티션으로 나뉘어 브로커들에 분산됨으로써, 브로커에는 많은 리더 파티션들과 다른 브로커를 따라가는 팔로워 파티션들이 존재한다.

만약 브로커가 고장이 날 경우, 해당 브로커의 리더 파티션에는 더이상 접근할 수 없게 되면서 ISR 상태인 다른 브로커의 팔로워 파티션이 리더로 승격되고 클라이언트 요청을 처리한다.

파티션이 많으면 많아질수록 브로커에 존재하는 파티션들이 많아지게 되고, 브로커 장애 시 새롭게 리더를 선출하고 팔로워를 만드는데 소요되는 시간이 증가한다.

클러스터 내에서 컨트롤러로 지정된 브로커가 이러한 장애에 대응을 하는데, 컨트롤러는 클러스터 내에 하나만 존재하며 마찬가지로 컨트롤러가 죽을 경우 다른 브로커가 컨트롤러 역할을 수행한다.

만약 컨트롤러에 장애가 발생할 경우에는 장애를 복구하는데 걸리는 시간이 더 증가한다.

컨트롤러 역할을 다른 브로커가 승계한 이후에 리더 선출을 다시 해야 하며, 심지어 컨트롤러 역할의 승계를 위해서는 새로운 컨트롤러가 주키퍼를 통해 모든 파티션들에 접근해야 하므로, 클러스터 내에 파티션이 많을수록 소요 시간이 증가한다.