Read Original
#Backend

카프카 파티션 개수 산정식 설계 여정

카프카 파티션 개수 산정식 설계 여정
01

Summary

"감"으로 정하던 카프카 파티션, 채널톡의 실측 기반 산정식으로 종결하기

장애 복구 시간까지 고려한 파티션 설계 노하우와 실측 데이터 대공개

카프카 운영의 가장 큰 고민 중 하나인 파티션 개수 산정을 수학적이고 체계적인 접근법으로 해결하는 과정을 담은 아티클입니다. 단순 유입량뿐만 아니라 컨슈머의 처리 시간과 복구 요구사항을 결합한 공식을 제시하고, Confluent Cloud 환경에서의 직접적인 벤치마킹 결과를 바탕으로 현실적인 가이드를 제공합니다.

  • 01컨슈머의 다운타임 복구를 위한 'Catch-up 배수' 개념 도입 및 공식화
  • 02CV(변동계수) 0.15 이하 구간을 활용한 지속 가능한 처리량 임계치 측정
  • 03컨슈머 앱의 레코드당 처리 시간(L)과 파티션 개수의 상관관계 정량 분석
  • 04Confluent Cloud Enterprise eCKU 한도를 고려한 파티션 예산 수립 전략
  • 05실제 계산 예시를 통한 프로듀서 중심 vs 컨슈머 중심 설계 차이 비교

RECOMMENDATION

카프카 기반 시스템을 설계하는 아키텍트와 백엔드 엔지니어에게 필독을 권하며, 특히 컨슈머 병목으로 인해 파티션 확장을 고민 중인 팀에서 이 산정 모델을 즉시 적용해 볼 것을 추천합니다.

The Problem

카프카 토픽의 파티션 개수 결정 시 명확한 기준이 없어, 처리량 부족으로 인한 성능 저하나 과도한 파티션 생성으로 인한 클러스터 관리 오버헤드가 발생할 수 있는 상황이었습니다. 특히 컨슈머 장애 시 발생하는 지연(Lag)을 특정 시간 내에 복구해야 하는 운영적 요구사항을 산정식에 반영하는 것이 핵심 과제였습니다.

The Solution

프로듀서의 피크 처리량뿐만 아니라 컨슈머의 장애 복구 시간(Catch-up time)을 고려한 파티션 산정식을 도출하였으며, 실측을 통해 파티션당 유입(6MB/s) 및 유출(0.1MB/s) 처리량 기준값을 확립했습니다. 이 과정에서 CV(변동계수) 지표를 도입하여 처리량의 안정성을 검증하고, 클러스터 리소스(eCKU) 한도 내에서 최적의 파티션 예산을 설계했습니다.

The Result

토픽 생성 시 개발자가 일관되게 사용할 수 있는 가이드라인을 구축하였으며, 특히 컨슈머의 레코드당 처리 시간(L)이 파티션 수 결정의 핵심 변수임을 확인하여 비즈니스 로직 최적화의 중요성을 정량화했습니다. 예시로 평균 2MB/s 유입 토픽에 대해 4일치 지연을 1일 내 복구하기 위한 100개 파티션이라는 구체적인 기준을 제시했습니다.

Trade-off

장애 복구 성능을 보장하기 위해 파티션 수를 넉넉하게 산정함에 따라 리소스 비용이 증가할 수 있으며, 카프카 특성상 파티션 수를 줄이는 것이 불가능하여 초기 설정의 신중함이 요구됩니다. 또한 egress 기준값을 보수적으로 잡을수록 파티션 수가 급격히 늘어나는 트레이드오프가 존재합니다.

03

Key Concepts

Concept · 01

Catch-up 배수

컨슈머가 일정 시간 동안 중단되었을 때 쌓인 지연 데이터(Lag)와 그동안 새로 유입되는 데이터를 목표 시간 내에 모두 처리하기 위해 필요한 처리 능력의 배율입니다.

  • (1 + 컨슈머 중단 시간 / 복구 목표 시간) 공식으로 산출함
  • 채널톡에서는 4일 중단 시 1일 내 복구를 기준으로 하는 5배수를 기본값으로 사용함
Concept · 02

CV (Coefficient of Variation)

표준편차를 평균으로 나눈 변동계수로, 측정된 처리량 데이터가 평균값 주변에 얼마나 안정적으로 분포하는지를 나타내는 척도입니다.

  • 순간적인 최고점이 아닌 운영 가능한 '지속 가능한 처리량'을 판단하는 기준으로 활용
  • 1분 윈도우 기준 CV 0.15 이하인 구간만을 안정적인 결과로 간주함
Concept · 03

Egress per Partition

파티션 하나당 컨슈머가 안정적으로 읽어서 처리할 수 있는 데이터량으로, 주로 컨슈머 애플리케이션의 비즈니스 로직 처리 시간에 의해 결정됩니다.

  • 카프카의 읽기 성능보다 컨슈머의 레코드당 처리 시간(L)에 더 큰 영향을 받음
  • 순차 처리 모델에서 50ms 처리 시간 기준 0.1MB/s를 실측 및 운영 기본값으로 선정함