카프카(Kafka) 파티션 개수, 어떻게 결정해야 할까?

카프카(Kafka) 파티션 개수는 처리량, 컨슈머 병렬성, 순서 보장에 영향을 미치며, 토픽 생성 시 적정 개수 판단을 위한 기준 제시

프로듀서 처리량, 컨슈머 lag, egress/ingress 처리량을 고려한 파티션 산정식 도출 및 각 요소의 측정 방법 설명

Confluent Cloud Enterprise 환경에서 ingress/egress 처리량 실측 결과를 바탕으로 운영 기준값 설정

컨슈머 처리 시간이 egress_per_partition에 미치는 영향과, 순차 처리 모델에서의 50ms 레코드 처리 시 0.1MB/s egress_per_partition 적용

파티션 수 결정 시 프로듀서 처리량보다 컨슈머 처리 시간과 lag catch-up 목표가 더 큰 영향을 미칠 수 있음을 강조

파티션 산정식 도출 과정: 요구량과 처리량의 균형

본문에서는 카프카(Kafka) 파티션 수를 결정하기 위해 프로듀서(Producer) 요구량과 컨슈머(Consumer) 요구량을 정의하고, 이를 파티션의 처리 능력으로 나누는 방식을 사용한다.

Producer Requirement: 피크(Peak) 시점의 프로듀서 처리량(producer_peak_throughput)을 기준으로 설정

Consumer Requirement: 평소 평균 유입량과 장애 발생 시 lag을 따라잡아야 하는 처리량을 고려하여 계산

최종 파티션 수 계산: `ceil(max(producer_peak_throughput / ingress_per_partition, consumer_requirement / egress_per_partition))` 공식을 통해 산출

이러한 접근 방식은 리틀의 법칙(Little's Law)과 유사하게, 시스템의 요구량과 처리 능력을 비교하여 적절한 파티션 수를 결정하는 데 중점을 둔다.

Ingress/Egress 처리량 측정: Confluent Cloud 환경 분석

채널에서는 Confluent Cloud Enterprise 환경에서 ingress_per_partition과 egress_per_partition을 직접 측정하여 운영 기준을 설정했다. 측정의 목표는 최대 처리량이 아닌, 지속 가능한 보수적인 기준값을 찾는 것이다.

Ingress 측정: 파티션 수(P)를 늘려가며 총 처리량과 produce request latency 관계를 분석하여, 안정적인 ingress_per_partition을 도출

Egress 측정: 컨슈머(Consumer)의 레코드 처리 시간(L)을 조절하며, L별로 파티션당 안정적인 egress를 측정

CV(Coefficient of Variation) 활용: 처리량의 안정성을 판단하기 위해 CV를 활용하여, 1분 윈도우 기준 CV가 0.15 이하인 구간을 안정적인 결과로 간주

컨슈머 처리 시간과 Egress_per_partition의 관계

본문에서는 컨슈머(Consumer)의 레코드 처리 시간이 egress_per_partition에 미치는 영향에 주목한다. 컨슈머의 처리 시간이 길어질수록 egress_per_partition이 낮아져, 동일한 consumer_requirement를 처리하기 위해 더 많은 파티션이 필요하다.

순차 처리 모델: 레코드 처리 시간이 50ms인 경우, egress_per_partition은 약 0.1MB/s 수준으로 감소

병렬 처리 활용: 컨슈머 내부에서 병렬 처리를 활용하면 egress_per_partition을 높일 수 있지만, 실제 병렬 효율을 별도로 측정해야 함

레코드 처리 시간 관리: 개발자는 egress_per_partition 기준을 만족하도록 컨슈머 처리 시간을 일정 수준 이하로 유지해야 한다.

결과적으로, 컨슈머 성능 최적화가 카프카(Kafka) 파티션 수 결정에 매우 중요한 요소임을 강조한다.

기본값 설정: Catch-up 배수와 Egress_per_partition의 조화

기본값 설정 시, egress_per_partition뿐 아니라 컨슈머(Consumer)가 멈춘 시간을 얼마나 빨리 따라잡을지, 즉 catch-up 배수를 함께 고려해야 한다. Confluent Cloud Enterprise eCKU의 파티션 한도를 고려하여, 기본값을 설정한다.

Catch-up 배수: 컨슈머 다운 타임(consumer_down_time)과 catch-up 시간(catchup_time)의 비율

기본값 설정: egress_per_partition = 0.1MB/s, catch-up 배수 5로 설정

파티션 수 계산: `partitions = topic_ingress * (1 + 4) / 0.1 = topic_ingress * 50` 공식을 통해, 평균 ingress가 2MB/s인 토픽은 약 100개의 파티션이 필요함을 설명

이러한 접근 방식은 Kafka 클러스터(Kafka Cluster)의 안정적인 운영을 위한 핵심 전략이다.