카프카
파티션

파티션

파티션 키와 파티션 복제

파티션의 데이터는 오프셋으로 순서가 보장된다. 프로듀스 시 파티션 키 명시하지 않으면 round-robin 방식으로 파티션 분배한다. 즉 순서가 지켜지지 않으니 키를 명시해야 한다. 키가 있는 경우 키의 hash 값에 해당하는 파티션에 할당하기 때문에 키 값을 잘 정해야 한다.

브로커의 토픽의 파티션은 다른 브로커에도 복제가 된다. 그러므로 파티션과 레플리카 사이에 리더와 팔로워가 존재하게 된다. 브로커가 3개가 있다고 가정할 때 리더 파티션 하나와 팔로워 파티션 2개가 생성된다. 1번 파티션의 리더가 브로커1에 있을 경우 2번 파티션의 리더는 브로커 2나 브로커 3에 존재하게 된다. 이렇게 파티션이 나누어져 있어 여러 프로듀서와 브로커 간의 병렬 전송, 처리가 가능하게 된다. 파티션

파티션 수 증가 시 문제점

무조건 많은 파티션을 만들게 되면 비가용성을 초래하게 된다. 하나의 브로커에 1000개의 파티션이 있다고 할 경우 브로커가 다운되었을 경우 새 리더를 선출하는데 걸리는 시간이 늘어나게 된다. 또한 브로커에 프로듀스 시 나머지 브로커에도 전부 복제가 되어야 하기 때문에 end to end latency가 증가하게 된다.

파티션은 디렉터리와 매핑된다. 파티션에 저장되는 데이터마다 2개의 파일(index와 실제data)가 생성되어 세그먼트에 추가된다? 카프카에서는 모든 디렉터리의 파일들에 대해 파일 핸들러를 오픈하게 되고 많은 메모리 소모를 하게 된다.

파티션 개수 줄이지 못하는 이유

파티션 수를 정하고 다시 늘리거나 줄이기가 힘드르모 결정할 때, 1~2년 후의 처리량을 고려해서 결정하는게 좋다. 이러한 이유에는 카프카를 이루는 설계요인이 복합적으로 적용된다. 다수 브로커에 분배되어있는 세그먼트를 다시 재배열하는것에 상당한 리소스가 사용되기 때문이라고 한다.

레퍼런스

카프카 옵션브로커