카프카(Kafka) 파티션 개수, 어떻게 결정해야 할까?
by DD
2개월 전
조회수 44
카프카(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)의 안정적인 운영을 위한 핵심 전략이다.
파티션 수 결정의 중요성: 순서 보장과 운영 비용
카프카(Kafka) 파티션 수를 결정할 때, 단순히 트래픽(Traffic) 양만 고려하는 것이 아니라, 다양한 요소를 종합적으로 고려해야 한다.
순서 보장: 같은 key를 가진 레코드는 같은 파티션으로 전송되어야 순서가 보장되므로, 파티션 수 변경은 순서 보장에 영향을 미침
운영 비용: 파티션 수가 증가하면 브로커(Broker)의 메타데이터 관리, 파일 핸들, 리더 선출, 복구 비용 증가
Confluent Cloud eCKU 한도: 파티션 수가 eCKU 한도를 초과하면, 트래픽 감소에도 불구하고 더 큰 eCKU를 유지해야 함
결론적으로, 파티션 수 최적화는 성능뿐 아니라, 시스템의 안정성과 운영 비용 절감에도 중요한 영향을 미친다.
