카프카 상세 개념 설명

• 적정 파티션 개수

  토픽의 파티션 개수는 카프카의 성능과 관련이 있다.

  • 적정 파티션 개수

    • 토픽 생성시 파티션 개수의 고려사항
      • 데이터 처리량
      • 메시지 키 사용 여부
      • 브로카, 컨슈머 영향도

  • 파티션은 카프카의 병렬처리의 핵심이다. 파티션의 개수가 많아지면 많아질수록 1:1 매핑되는 컨슈머 개수가 늘어나기 때문

  • 데이터 처리 속도를 올리는 방법은 2가지로 첫째, 컨슈머의 처리량을 늘리는것. 둘째, 컨슈머를 추가하여 병렬처리량을 늘리는것이다

  • 컨슈머 특성상 다른 시스템들과 연동되기 때문에 일정 수준 이상 처리량을 올리는것이 매우 어렵다.

  • 데이터 처리량을 늘리는 가장 확실한 방법은 파티션 개수를 늘리고 파티션 개수만큼 컨슈머를 추가하는것

  • 파티션 개수의 공식

    프로듀서 전송 데이터량 < 컨슈머 데이터 처리량 x 파티션 개수

    ex) 프로듀서가 전송하는 데이터가 1000/s 레코드이고, 컨슈머 처리량이 100/s 레코드라면 필요 파티션 개수는 10개이다.

  • 파티션 개수만큼 컨슈머 스레드를 운영한다면 해당 토픽의 병렬처리를 극대화할 수 있다.

  • 전체 컨슈머 데이터 처리량이 프로듀서가 보내는 데이터보다 적다면 컨슈머 렉이 생기고, 데이터 처리 지연이 발생한다.

  • 컨슈머는 다른 시스템과 연동되는 특성이 있기에 테스트 환경과 상용 환경과의 처리량 차이가 날 수 있으므로 상용환경에서의 테스트가 권장된다.

  • 파티션 개수를 늘리는것은 컨슈머와 브로커에 부담이 있기때문에 지연 발생에 따른 서비스 영향도를 같이 고려하여 파티션 개수를 고려하자

  • 기존 파티션의 개수가 달라지면 이미 매칭된 파티션과 메시지 키의 매칭이 깨지고 전혀 다른 파티션에 데이터가 할당된다.

  • 메시지 키를 사용하는 컨슈머는 특정 메시지 키의 순서를 더는 보장받지 못한다.

  • 메시지 키를 사용하고 컨슈머에서 메시지 처리 순서가 보장되어야 한다면 최대한 파티션의 변화가 발생하지 않는 방향으로 운영되어야 한다.

  • 키별로 처리 순서를 보장하기 위해서는 파티션 개수를 프로듀서가 전송하는 데이터양보다 더 넉넉하게 잡고 생성하는 것이 좋다

  • 파티션은 각 브로커의 파일 시스템을 사용하기 때문에 파티션이 늘어나는 만큼 브로커에서 접근하는 파일 개수가 많아진다.

  • 그러나 운영체제 에서는 프로세스 당 열 수 있는 파일 최대 개수를 제한하고 있다.

  • 카프카 브로커가 접근하는 파일 개수를 안정적으로 유지하기 위해선 각 브로커당 파티션 개수를 모니터링해야한다.

  • 파티션 개수가 너무 많다면 파티션 개수를 분산하기 위해 카프카 브로커 개수를 늘리는 방안도 고려해야 한다.

  
  
  

• 토픽 삭제
  • 토픽의 데이터를 삭제할 때는 세그먼트 단위로 삭제를 진행한다.
  • 세그먼트는 토픽의 데이터를 저장하는 명시적인 파일 시스템 단위이다.
  • 데이터를 저장하기 위해 사용중인 세그먼트를 액티브 세그먼트 라고 한다.
  • 삭제된 데이터는 복구할 수 없다.

• 토픽 압축
  • 여기서 압축이란 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책을 뜻한다.

• ISR
  • ISR은 리더 파티션과 팔로워 파티션이 모두 싱크(동기화)가 된 상태를 뜻한다.
  • 서로의 오프셋이 같아야 동기화가 완료되었다고 말할 수 있다.
  • 일부 데이터 유실이 발생하더라도 서비스를 중단하지 않고 지속적으로 토픽을 사용하고 싶다면 ISR이 아닌 팔로워 파티션을 리더로 선출하도록 설정할 수 있다.
  • ISR이 아닌 팔로워 파티션, 즉 동기화가 되지 않은 팔로워 파티션도 리더로 선출될 수 있다.(동기화 되지 않은 팔로워 파티션이 리더로 선출되면 이전 동기화 되지 않은 데이터들은 유실될 수 있음)

​