Partition 수 결정
토픽의 파티션 수는 성능, 확장성, 운영에 큰 영향을 미치는 중요한 설계 결정입니다.
파티션 수의 영향
파티션 수에 따른 특성
┌─────────────────────────────────────────────────────────────────┐
│ Partition Count Trade-offs │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 파티션 수 ↑ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 장점: │ │
│ │ • 처리량 증가 (병렬 Consumer) │ │
│ │ • 더 많은 Consumer 병렬화 가능 │ │
│ │ • 더 세밀한 데이터 분산 │ │
│ ├─────────────────────────────────────────────────────────┤ │
│ │ 단점: │ │
│ │ • Broker 메모리 사용량 증가 │ │
│ │ • Controller 부하 증가 │ │
│ │ • Rebalance 시간 증가 │ │
│ │ • 파일 핸들 수 증가 │ │
│ │ • End-to-end 지연 증가 가능 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
파티션 수와 Consumer 관계
파티션 수: 6
Consumer 수: 4
┌──────────────────────────────────────────────────────────────┐
│ Consumer 1: [P0, P1] │
│ Consumer 2: [P2, P3] │
│ Consumer 3: [P4] │
│ Consumer 4: [P5] │
└──────────────────────────────────────────────────────────────┘
Consumer 수 > 파티션 수인 경우:
┌──────────────────────────────────────────────────────────────┐
│ Consumer 1: [P0] │
│ Consumer 2: [P1] │
│ Consumer 3: [P2] │
│ Consumer 4: [P3] │
│ Consumer 5: [P4] │
│ Consumer 6: [P5] │
│ Consumer 7: (유휴 - 할당된 파티션 없음) │
│ Consumer 8: (유휴 - 할당된 파티션 없음) │
└──────────────────────────────────────────────────────────────┘
핵심: 파티션 수 = 최대 병렬 Consumer 수
파티션 수 결정 공식
처리량 기반 계산
필요 파티션 수 = max(
목표_처리량 / 파티션당_Producer_처리량,
목표_처리량 / 파티션당_Consumer_처리량
)
예시:
- 목표 처리량: 1GB/s
- Producer 파티션당 처리량: 100MB/s
- Consumer 파티션당 처리량: 50MB/s
파티션 수 = max(1000/100, 1000/50) = max(10, 20) = 20개
벤치마크 기반 접근
# Producer 벤치마크
kafka-producer-perf-test.sh \
--topic test-topic \
--num-records 1000000 \
--record-size 1024 \
--throughput -1 \
--producer-props bootstrap.servers=localhost:9092
# 결과: 80 MB/s per partition
# Consumer 벤치마크
kafka-consumer-perf-test.sh \
--bootstrap-server localhost:9092 \
--topic test-topic \
--messages 1000000
# 결과: 50 MB/s per partition (처리 포함)실무 권장 공식
파티션 수 = max(
예상_최대_Consumer_수,
목표_처리량_MB_s / 파티션당_처리량_MB_s,
보관_기간_일 * 일일_데이터_GB / 파티션당_최대_크기_GB
)
예시:
- 예상 최대 Consumer: 10
- 목표 처리량: 500MB/s, 파티션당 50MB/s → 10
- 보관 7일, 일일 100GB, 파티션당 50GB → 14
결과: max(10, 10, 14) = 14개 → 여유 고려해서 16개 권장
시나리오별 권장값
소규모 (개발/테스트)
# 토픽 생성
kafka-topics.sh --create \
--topic small-topic \
--partitions 3 \
--replication-factor 1 \
--bootstrap-server localhost:9092
권장: 3-6 파티션
이유: 적은 리소스, 빠른 Rebalance중규모 (일반 프로덕션)
# 토픽 생성
kafka-topics.sh --create \
--topic medium-topic \
--partitions 12 \
--replication-factor 3 \
--bootstrap-server localhost:9092
권장: 12-24 파티션
이유:
- 일반적인 Consumer Group 크기 (6-12)의 배수
- 충분한 병렬화
- 관리 가능한 파티션 수대규모 (고처리량)
# 토픽 생성
kafka-topics.sh --create \
--topic large-topic \
--partitions 64 \
--replication-factor 3 \
--bootstrap-server localhost:9092
권장: 64-128 파티션
이유:
- 높은 처리량 요구
- 많은 Consumer 병렬화
- 향후 확장 대비초대규모 (특수 사례)
# 토픽 생성
kafka-topics.sh --create \
--topic xlarge-topic \
--partitions 256 \
--replication-factor 3 \
--bootstrap-server localhost:9092
권장: 100+ 파티션 (신중하게)
주의:
- Controller 부하 고려
- Broker 리소스 충분히 확보
- 모니터링 강화파티션 수 변경
파티션 증가
# 파티션 수 증가 (감소는 불가)
kafka-topics.sh --alter \
--topic my-topic \
--partitions 24 \
--bootstrap-server localhost:9092주의사항
┌─────────────────────────────────────────────────────────────────┐
│ Partition Increase Side Effects │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 키 기반 라우팅 변경 │
│ - 동일 키가 다른 파티션으로 갈 수 있음 │
│ - 순서 보장 일시적 손상 │
│ │
│ 2. Consumer Rebalance 발생 │
│ - 일시적 처리 중단 │
│ - Lag 증가 가능 │
│ │
│ 3. Compacted Topic │
│ - 기존 데이터 접근 패턴 변경 │
│ - Compaction 재실행 필요 │
│ │
└─────────────────────────────────────────────────────────────────┘
파티션 변경 전략
1. 초기 설계 시 여유 있게 설정
- 예상 최대치의 2배 고려
2. 변경이 필요한 경우
- 피크 시간 회피
- Consumer 준비 상태 확인
- 모니터링 강화
3. 키 기반 라우팅 의존 시
- 새 토픽 생성 + 데이터 마이그레이션 고려
리소스 고려사항
Broker 리소스
파티션당 리소스:
- 메모리: ~1MB (버퍼, 인덱스)
- 파일 핸들: 3개 (로그, 인덱스, 타임인덱스)
- 복제 스레드: 공유
예시 계산:
- 토픽 100개 × 파티션 12개 × RF 3 = 3,600 파티션/Broker
- 메모리: ~3.6GB
- 파일 핸들: ~10,800개
Controller 부하
Controller 작업량:
- 파티션 메타데이터 관리
- Leader 선출
- ISR 관리
권장:
- 클러스터당 총 파티션 < 200,000
- Broker당 파티션 < 4,000
- KRaft 모드에서 더 많이 지원 가능
Rebalance 영향
Rebalance 시간 ∝ 파티션 수
파티션 100개: ~5초
파티션 1000개: ~30초
파티션 10000개: ~5분
최적화:
- Cooperative Rebalancing 사용
- Static Membership 활용
용도별 권장 설정
이벤트 스트리밍
# 높은 처리량, 낮은 지연
partitions=24
replication.factor=3
min.insync.replicas=2
# 키: 이벤트 소스 ID
# 파티션 수 = Consumer 인스턴스 수의 2-3배로그 수집
# 매우 높은 처리량, 순서 덜 중요
partitions=48
replication.factor=2
# 키: null (라운드 로빈)
# 파티션 수 = 예상 처리량 / 파티션당 처리량명령/쿼리 (CQRS)
# 순서 보장 중요
partitions=12
replication.factor=3
min.insync.replicas=2
# 키: Aggregate ID
# 파티션 수 = Aggregate 카디널리티 고려CDC (Change Data Capture)
# 테이블당 파티션
partitions=6
replication.factor=3
# 키: Primary Key
# 파티션 수 = 소스 테이블 특성에 따라Best Practices
1. 초기 설계 원칙
✓ 예상 최대 Consumer 수보다 크게
✓ 2의 배수 또는 Broker 수의 배수
✓ 향후 2-3년 성장 고려
✓ 파티션 감소 불가 염두
2. 모니터링 기반 조정
모니터링 지표:
- Consumer Lag 추이
- 파티션당 처리량
- Rebalance 빈도
- Broker 리소스 사용률
조정 시기:
- Consumer Lag 지속 증가
- Consumer 추가해도 개선 없음
- 특정 파티션 핫스팟
3. 토픽 분류별 기준
critical_topics:
description: "주문, 결제 등 핵심 비즈니스"
partitions: 24
replication_factor: 3
standard_topics:
description: "일반 이벤트, 알림"
partitions: 12
replication_factor: 3
logging_topics:
description: "로그, 메트릭"
partitions: 48
replication_factor: 2
temp_topics:
description: "임시 데이터"
partitions: 6
replication_factor: 14. 문서화
# topic-registry.yaml
topics:
- name: orders
partitions: 24
replication_factor: 3
key_strategy: order_id
expected_throughput: 10000_msg_per_sec
retention_days: 7
consumers:
- order-processor (6 instances)
- analytics (3 instances)
rationale: |
24 partitions allow up to 24 parallel consumers.
Current max is 9, leaving room for 2.5x growth.파티션 수 결정 체크리스트
□ 목표 처리량 정의됨
□ 예상 Consumer 수 산정됨
□ 데이터 보관 요구사항 확인
□ 키 전략 결정됨
□ 순서 보장 요구사항 확인
□ 향후 성장 고려됨
□ Broker 리소스 검토됨
□ 다른 토픽과의 일관성 확인
댓글 (0)