[카프카] 토픽과 파티션

토픽

• 토픽은 물리적인 구조가 아니라 추상적인 개념이다
• 토픽에는 하나 이상의 파티션이 있다
• 파티션은 각 디스크에 물리적 공간이 존재한다
• 카프카 클러스터에서 토픽을 구성하는 데이터를 로그에 기록. 로그를 카프타 브로커의 파일 시스템에 기록한다.
• 토픽의 구성은 가장 상위 수준에서 컨슈머가 데이터에 접근하는 방식에 영향을 미친다

 

 

토픽 설계 2단계 프로세스

1. 우리가 가진 이벤트를 본다. 그들은 하나의 토픽에 속해있는가? 아니면 둘 이상에 속해있는가?
2. 각 토픽을 고려한다. 사용해야 하는 파티션의 수는 얼마인가?

가장 중요한 점은 파티션이 토픽별 설계에 대한 질문이지 클러스터 전체의 제한이나 요구가 아니라는 것이다

 

 

파티션 수를 정할 때 고려해야 할 항목

• 데이터 정확성 data correctness
  • ex) 순서 보장이 필요한 경우 keyed message 사용
• 컨슈머 당 메시지의 양 volume of message
  • 200p에 나온 예시 이해가 잘 안됨
• 가지고 있거나 처리해야 할 데이터의 양 quantity of data
• 파티션 수를 줄이는 기능은 아직 지원하지 않는다

토픽 생성 옵션

• delete.topics.enable
  • Default false
  • True로 변경 시 토픽 삭제 가능해짐
• 토픽 길이 제한. 249자
  • 토픽이름-파티션번호 형태로 구성
  • 리눅스 파일명 제한 255자 - 파티션번호 5자 - 하이픈 1자 = 249
• auto.create.topics.enable
  • default true
  • True일 경우, 메시지를 보낸 토픽이 등록되지 않은 토픽일 경우 자동으로 토픽 생성해줌
  • 운영 환경에서 원치 않는 토픽 생성을 방지하려면 false 설정

복제 팩터

• 총 레플리카 수가 브로커의 수보다 적거나 같도록 계획해야 한다

 

파티션

• 컨슈머 관점에서 각 파티션은 변경할 수 없는 메시지 로그다
• 컨슈머는 메시지를 직접 삭제할 수 없다
• 토픽에서 메시지를 리플레이 할 수 있다

 

파티션을 구성하는 세그먼트

 

활성 세그먼트 : 현재 새 메시지가 기록되고 있는 파일

 

세그먼트마다 파일 3개씩 있음

.log : 메시지가 파티션 디렉토리에 기록되는 위치

.index

.timeindex

카프카 환경 테스트 하기

• EmbededKafkaCluster
• TestContainers

 

토픽 컴팩션 (=로그 컴팩션)

• 목표는 메시지를 만료시키는 것이 아니라 키의 최신 값이 존재하는지 확린하고 이전 상태를 새 상태로 교체하는 것
• cleanup.policy=compact
  • 기본값은 delete (재정의 전에 삭제)
  • 토픽 만들 때 설정
• 카프카 내부 토픽인 __consumer_offset 도 토픽컴팩션을 사용함
  • 컨슈머는 오프셋 이력이 아니라 최신 오프셋이 필요하므로