이 게시물은 Kafka 토픽 파티션 개수를 Broker/컨슈머 지연(lag) 관점에서 산정하는 과정을 정리한 내용입니다.

최종 산정식

요구량을 producer와 consumer로 분리해 최대값을 올림 처리

• required_partitions = ceil(max(producer_peak_throughput / ingress_per_partition, consumer_requirement / egress_per_partition))
• consumer_requirement = max(producer_avg_throughput * (1 + consumer_down_time / catchup_time), producer_peak_throughput)
• 고정 기준값: egress_per_partition = 0.1MB/s, 기본 catch-up 배수 5(=1 + consumer_down_time / catchup_time)

기준값 도출 로직

ingress_per_partition과 egress_per_partition을 실측해 보수적으로 선택

• ingress_per_partition은 latency가 급격히 튀기 직전 knee point 직전 총 처리량을 파티션 수로 나누고 안전계수(0.75) 적용
• Confluent Cloud Enterprise eCKU 환경에서 ingress_per_partition은 6MB/s로 결정
• egress_per_partition은 컨슈머 처리시간 병목을 반영해 레코드 처리시간 L별로 측정하며, 기본값으로 0.1MB/s 사용
• 파티션 한도 관점에서 catch-up 배수와 eCKU 파티션 예산을 함께 검토해 기본값 조합을 확정

주의점

파티션은 늘린다고 항상 좋은 것이 아니며 순서 보장에도 영향

• 파티션이 많으면 메타데이터/복구 비용 증가, key 기반 순서 토픽은 파티션 증설이 어려움