파티션은 카프카 클러스터 내부에서 토픽의 크기가 확장되는 방법이다. 그래서 몇 개로 잡느냐가 처리량의 상한을 정하고, 결론은 언제나 같은 자리에 있다. 파티션은 많아야 하지만 너무 많으면 안 된다.
목표 처리량에서 나오는 계산
목표 처리량과 컨슈머의 예상 처리량을 알면 계산이 나온다. 토픽을 초당 1GB로 읽고 싶은데 컨슈머 하나가 초당 50MB를 처리한다면 최소 20개의 파티션이 필요하다. 20개의 컨슈머가 동시에 하나의 토픽을 읽어 초당 1GB를 채운다.
계산이 성립하는 근거는 파티션 하나를 한 컨슈머만 읽을 수 있다는 규칙이다. 파티션 수가 곧 병렬 처리의 상한이라 컨슈머를 아무리 늘려도 파티션 수를 넘으면 남는 컨슈머는 논다. 프로듀서가 단일 파티션에 쓰는 속도도 고려할 수 있지만 대체로 컨슈머보다 훨씬 빠르므로 이 계산은 건너뛰어도 된다.
보통은 토픽당 파티션 개수를 클러스터 내 브로커 수와 맞추거나 그 배수로 잡는다. 파티션이 브로커들 사이에 고르게 분산되기 때문이다. 파티션 10개짜리 토픽이 호스트 10대에서 돌고 각 파티션의 리더가 고르게 흩어져 있으면 최적의 처리량이 나온다. 부하를 분산하는 다른 방법도 있으니 필수는 아니고, 자연스러운 출발점 정도다.
상세 정보가 없으면 링크드인의 경험칙이 있다. 디스크에 저장된 파티션 하나의 용량을 6GB 미만으로 유지하는 것이 대체로 결과가 좋았다는 것이다. 그리고 작게 시작해서 점진적으로 늘리는 편이 그 반대보다 쉽다.
많이 잡을 때 치르는 비용
파티션을 넉넉히 잡는 것은 공짜가 아니다. 각 파티션이 브로커의 메모리와 자원을 쓰고, 메타데이터 업데이트와 리더 역할 변경에 걸리는 시간이 늘어난다. 클라우드에서는 VM이나 디스크에 걸린 IOPS 상한에 걸릴 수 있는데, 파티션이 많으면 병렬 처리 때문에 IOPS가 증가한다. 미러링을 할 예정이라면 미러링 설정의 처리량도 봐야 한다. 큰 파티션이 병목이 되는 경우가 많다.
나중에 늘릴 때 깨지는 것
나중에 늘리면 된다는 생각도 조심해야 한다. 키를 기준으로 파티션을 고르고 있다면 해시의 나머지가 달라져서 같은 키가 다른 파티션으로 가고, 순서 보장이 그 지점에서 끊어진다. 그래서 현재 사용량이 아니라 미래의 사용량 예측값으로 계산한다.