Kafka 파티션 전략: 개수 산정과 증가 시 고려사항¶
Kafka에서 파티션은 병렬 처리의 기본 단위입니다. 파티션 수를 늘리는 것은 처리량(Throughput) 향상에 도움이 되지만, 무분별한 증가는 예기치 못한 부작용을 초래할 수 있습니다.
1. 파티션 수 산정 기준¶
1.1 처리량 기반 산정¶
공식적인 산정 공식은 없으나, 대략 다음과 같은 수식을 참고합니다.
- 목표 처리량: $T$ (MB/s)
- Producer 1개의 처리량: $P$ (MB/s)
- Consumer 1개의 처리량: $C$ (MB/s)
- 필요 파티션 수: $max(T/P, T/C)$
1.2 Consumer Group과의 관계¶
- 파티션 수 > Consumer 수: 일부 Consumer가 여러 파티션을 담당. (병렬 처리 여력 있음)
- 파티션 수 = Consumer 수: 1:1 매칭. (최적의 효율)
- 파티션 수 < Consumer 수: 남는 Consumer는 메시지를 받지 못하고 대기 상태가 됨. (자원 낭비)
💡 질문에 대한 답변: 현재 Consumer가 10개인데 파티션을 60개로 늘리는 것은, 향후 Consumer를 최대 60개까지 늘려 병렬 처리 성능을 6배까지 확장하겠다는 의도로 해석됩니다. 현재 10개의 Consumer가 각각 6개의 파티션을 처리하게 되므로 CPU/메모리 부하를 체크해야 합니다.
2. 파티션 증가 시의 장단점 및 부작용¶
2.1 장점¶
- 병렬 처리 확장: Consumer를 추가로 투입하여 처리 지연(Lag)을 빠르게 해소할 수 있습니다.
- 처리량(Throughput) 향상: 이론적으로 파티션 수에 비례하여 전체 처리량이 증가합니다.
2.2 단점 및 부작용 (주의사항)¶
- 메시지 순서 보장 위반 (Key 사용 시): 파티션 수가 변경되면 기존에 사용하던 해시 로직(
DefaultPartitioner)의 결과값이 달라집니다. 따라서 동일한 Key를 가진 메시지가 이전과 다른 파티션으로 전송되어 순서가 꼬일 수 있습니다. - 가용성 저하 (장애 복구 시간 증가): 브로커 장애 시, 해당 브로커가 담당하던 수많은 파티션들의 리더(Leader)를 새로 선출해야 합니다. 파티션이 너무 많으면 이 과정이 길어져 일시적인 서비스 중단 시간이 늘어날 수 있습니다.
- 클라이언트 리소스 증가: Producer와 Consumer 모두 파티션마다 별도의 버퍼와 메타데이터를 관리해야 하므로 메모리 사용량이 늘어납니다.
- 파일 핸들 오버헤드: 각 파티션은 브로커에서 별도의 파일로 관리되므로 운영체제의 파일 핸들(File Descriptor) 소모가 커집니다.
3. 공식 가이드 및 권장 사항 (Confluent 기준)¶
3.1 적정 개수 권장¶
- 브로커당 파티션 수: 최신 버전(3.0+) 기준, 클러스터 전체 성능을 위해 브로커당 1,000개 미만의 파티션을 권장합니다. (과거에는 Zookeeper 한계로 더 적게 권장했으나 KRaft 모드에서는 더 늘어남)
- 배수 증가 전략: 파티션을 늘릴 때는 기존 개수의 배수(예: 20 -> 40 -> 60)로 늘리는 것이 파티션 할당의 균형 측면에서 유리할 수 있습니다.
3.2 파티션 수 감소 불가¶
- Kafka는 한 번 늘린 파티션 수를 줄이는 기능을 지원하지 않습니다. 줄이려면 토픽을 새로 만들고 데이터를 마이그레이션해야 합니다. 따라서 60개로 늘리기 전에 신중한 결정이 필요합니다.
4. 실전 가이드: 20개에서 60개로 늘려도 될까?¶
- 순서 보장이 중요한가?: 중요하다면 파티션 증가 시 데이터 순서가 뒤섞일 수 있음을 인지하고 대응책을 마련해야 합니다.
- 리소스 여유가 있는가?: Consumer 10개가 60개의 파티션을 관리하기에 메모리/연산 자원이 충분한지 확인하세요.
- 단계적 증가 추천: 60개가 최종 목표라면 우선 40개 정도로 늘려 부하를 테스트해본 뒤 최종 60개로 가는 방안도 좋습니다.