kafka - Topic Partition 개수 설계

카프카에 파티션 수가 늘어날 수록 처리량을 올라가지만, 그에 따른 반작용이 있다. 바로 Latency 증가하고 recovery time 이 늘어난다. 그래서 무작정 파티션 수를 늘리는 것보다, 적절한 목표 처리량을 설정하고 그에 맞춰 파티션 개수를 산정해야한다. 이어 기능상에 대해서도 고려를 해야한다.

카프카 파티션 수 설계 가이드

• 파티션 수를 증가하면 처리량이 높아짐 (분산효과)
  • 프로듀서, 브로커 : write 처리량이 증가, hardware 자원 사용 증가
  • 컨슈머 : 파티션 수만큼 병렬 쓰레드 구동해서 처리량 증가
  • 목표 처리량 (t) 이 있다면, 파티션 개수를 정할 수 있음
    • 단일 파티션 쓰기 속도 계산 (p)
    • 단일 파티션 읽기 속도 계산 (c)
    • 파티션 개수 = max (t/p, t/c)
  • 고려사항
    • batch size, compression type, acks, replication factor 등에 따라 처리 성능이 달라짐
    • Key 별로 파티션 할당해야 하는 경우, 향후 증가량을 고려해서 개수 할당
    • 스트리밍을 고려한다면 데이터 순서를 보장할 수 없음
• 각 파티션은 브로커의 특정 directory(log) 에 저장됨
  • log segment 당 2개의 파일 생성 (index, data)
  • 카프카는 모든 log segment 의 index 와 data file handler 를 오픈
  • 파티션이 많아지면, OS 의 file handler 관련 설정 변경이 필요 (걍 미리 올려놓자)
• 파티션 수를 증가하면 서비스 리커버리 시간이 증가함
  • 카프카는 가용성과 유실 방지를 위해, 복제복(replicat) 를 생성
  • leader broker 는 복제본 중 1개를 가지고 있고, 다운되면 순간적으로 leader 의 파티션은 서비스 불가능해짐
    • 대부분 브로커는 정상적으로 다운되어, 사전에 파티션의 리더를 변경 (controller broker 의 역할)
    • 하나의 파티션 리더 변경은 순식간에 실행되어, 컨슈머 관점에서는 잠깐 접속이 안되는 상황 발생
  • 만약 브로커에 1000 개의 파티션이 있고, 비정상 종료(kill -9) 되었다면?
    • 파티션의 서비스 중지 시간은 파티션 개수에 비례
    • 하나의 파티션 리더 선출하는 시간이 5ms
    • 1000 파티션이면 5 sec 소요 ( 5초동안 서비스 불가)
    • 만약 controller broker 가 다운되었다면? 새로운 controller 가 실행될때까지 모든 파티션의 리더 선출 불가능
• 파티션 수를 증가시키면 ent to ent latency 증가
  • 프로듀서에서 컨슈머로 메시지 전송은 커밋된 후에 가능
    • 복제된 메시지가 모두 ISR 상태에 있는 것을 의미
    • 카프카는 브로커간의 데이터 복제에 single thread 만 사용
    • 1000 개의 파티션을 다른 브로커로 복제하는데 20ms 소요 (latency 에 영향)
    • 클러스터가 크다면 (브로커 노드가 많다면), 1000개의 파티션이 여러 브로커에 분산복제되어 복사속도는 줄어듬
  • latency 가 중요하다면
    • 브로커 당 파티션 개수를 제한
    • 파티션 수 = 100 * (broker count) * (rf count)
    • broker count : 브로커 수
    • rf count : replication factor 수

 

참고자료:

https://ohjongsung.io/2020/01/11/%EC%B9%B4%ED%94%84%EC%B9%B4-%ED%8C%8C%ED%8B%B0%EC%85%98-%EC%88%98-%EC%84%A4%EA%B3%84