토픽

• 토픽은 물리적인 구조가 아니라 추상적인 개념
• 토픽은 일반적으로 하나의 브로커에만 존재하는 것은 아니다
• 토픽 이름 뒤에는 실제로 데이터를 보유하는 하나 이상의 파티션이 있다

토픽 설계 프로세스

1. 이벤트 확인
   • 같은 토픽에 속해있는가 다른 토픽에 속해있는가
2. 각 토픽을 고려한다
   • 파티션의 수는 얼마인가

데이터 정확성

• 순서를 지정해야하는 이벤트가 동일 파티션, 동일한 토픽에 있는지 확인하는 작업이 포함된다
• 타임스탬프를 기반으로 배치할 수 있지만 교차 토픽 이벤트를 조정하는 것이 더 문제가 되고 오류가 발생하기 쉽다

메시지 규모

• 하루에 5만건의 검색이 발생하지만 100명의 학생을 수용할 수 있는 공간만 있다고 가정해보자
  - 전체 메시지의 1% 미만을 사용하거나 관심을 갖는 토픽을 구독하려는 팀이 있는가?

데이터 양

• 제한된 시간내에 처리하기 위해 메시지 수에 따라 여러 컨슈머가 실행돼야 하는가
  - 그룹의 컨슈머 수가 토픽의 파티션에 의해 어떻게 제한되는지 알고 있어야한다.
  

토픽 생성 옵션

• 토픽을 삭제해야 하는가?
  - 타당한 확인 없이는 발생하지 않도록 해야 한다
  • delete.topic.enable 옵션의 활성화를 요구한다
• 브로커 수준에서 관리하기에 좋은 다른 옵션은 auto.create.topics.enable을 false로 설정하는 것
  - 존재하지 않았고 잘못 입력된 토픽이름으로 메시지를 보내면 자동으로 토픽을 생성하는 것을 차단하고, 의도적으로 생성하도록 강제할 수 있다
  

복제 팩터

• 실질적으로 운영되기 위해서는 총 레플리카 수가 브로커 수보다 적거나 같도록 계획해야 한다.

파티션

파티션 위치

• log.dirs 위치를 찾아보자
• 확장자가 .log인 파일은 데이터 페이로드가 저장되는 위치이다.
• .index, .timeindex는 논리적 메시지 오프셋과 인덱스 파일내의 물리적 위치 간의 매핑을 저장한다
• 파티션은 많은 파일로 구성된다
  - 단일 파일이 아니라 여러 세그먼트로 분할됨을 의미한다
• 활성 세그먼트는 현재 새 메시지가 기록되고 있는 파일이다
• 카프카는 활성 세그먼트가 아닌 이전 세그먼트를 다양한 방식으로 관리한다

로그 보기

• 텍스트 편집기로는 확인할 수 없다
• kafka-dump-log.sh를 통해 확인할 수 있다

EnbeddedKafkaCluster를 사용한 테스트

• 준비된 클러스터 없이도 카프카 클러스터를 가동할 수 있다
• 모의 객체와 중간지점 역할을 하는 통합 유틸리티 클래스를 제공한다

dependency

	implementation("net.mguenther.kafka:kafka-junit:2.1.1")

토픽 컴팩션

• 키의 최신값이 존재하는지 확인하고 이전 상태를 새 상태로 교체하는 것
• cleanup.policy=compact
• 코드가 더 많은 데이터를 추가하는 대신 기존 필드를 업데이트
  - 멤버심 개념 생각
  - 사용자가 처음 기본 멤버십으로 시작하고 이후에 골드 멤버십으로 변경했을 때 가장 최근의 멤버십만 필요하다
• 컴팩션을 사용하려는 다른 이유는 소비하는 오프셋 이력이 필요한 것이 아니라 최신 오프셋만 필요하다