ohjongsung's Dev Story

Ohjongsung's Dev Story

카프카 파티션 수 설계

2020년 01월 11일

카프카에 파티션 수가 늘어날 수록 처리량을 올라가지만, 그에 따른 반작용이 있다. 바로 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 * b * r
      • b : 브로커 수
      • r : replication factor 수