[Kafka] 토픽과 파티션, 레코드

💜 Kafka 컴포넌트 (2) - 토픽과 파티션, 레코드

책 '아파치 카프카 애플리케이션 프로그래밍 with 자바 - 최원영 지음'을 공부하며 정리하였습니다.

 

 

1. 토픽과 파티션

 토픽 : 카프카에서 데이터를 구분하기 위해 사용하는 단위
 파티션  : 토픽은 1개 이상의 파티션을 소유함

• 파티션에는 프로듀서가 보낸 데이터들이 저장되는데 이 데이터를 레코드(record)라고 부른다. 즉 프로듀서가 전송한 레코드는 파티션에 저장된다.
• 파티션은 카프카 병렬처리의 핵심으로 그룹으로 묶인 컨슈머들이 레코드를 병렬로 처리할 수 있도록 매칭됨
• 컨슈머의 처리량이 한정된 상황이라면, 가장 좋은 방법은 컨슈머의 개수를 늘려 스케일 아웃하는 것이다. 컨슈머 개수를 늘림과 동시에 파티션 개수도 늘리면 증가하기 때문이다.
• 파티션은 큐(queue)와 비슷한 구조로 FIFO 구조와 같이 먼저 들어간 레코드는 컨슈머가 먼저 가게된다. 다만 데이터를 가져간다고 레코드는 삭제되지 않는다. 이러한 특징으로 여러 컨슈머 그룹들이 토픽의 데이터를 여러번 가져갈 수 있다.

 

의미 있는 토픽 이름 작명법

토픽 이름은 데이터의 얼굴로, 토픽 이름을 모호하게 작성하면 유지보수 시 큰 어려움을 겪을 수 있다.

최소한 토픽 이름을 통해 개발환경과 애플리케이션, 데이터 타입 등을 유추할 수 있어야 한다.

토픽 작명의 템플릿과 예시

• <환경>.<팀-명>.<애플리케이션-명>.<메시지-타입>
  • ex. prd.marketing-team.sms-platform.json
• <프로젝트-명>.<서비스-명>.<환경>.<이벤트-명>
  • ex. `commerce.payment.prd.notification1
• <환경>.<서비스-명>.<JIRA-번호>..<메시지-타입>
  • ex. dev.email-sender.jira-12324.email-vo-custom
• <카프카-클러스터-명>.<환경>.<서비스-명>.<메시지-타입>
  • ex. aws-kafka.live.marketing-platform.json

2. 레코드

레코드는 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성되어 있다.
브로커에 적재된 레코드는 수정 불가. 로그 보유 기간 또는 용량에 따라서만 삭제된다.

(1) 오프셋과 타임스탬프

프로듀서가 생성한 레코드가 브로커로 전송되면, 오프셋과 타임스탬프가 지정되어 저장된다.

• 타임스탬프는 프로듀서에서 레코드가 생성된 시점(CreatTime)의 유닉스 타임이 설정된다. 프로듀서가 레코드를 생성할 때 임의의 타임스탬프 값을 설정할 수 있고, 토픽 설정에 따라 브로커에 적재된 시간(LogAppendTime)으로 설정될 수 있다.

 

(2) 메시지 키와 값

메시지 키는 메시지 값을 순서대로 처리하거나 메시지 값의 종류를 나타내기 위해 사용한다.

• 메시지 키를 사용하면 프로듀서가 토픽에 레코드를 전송할 때 메시지 키의 해시값을 토대로 파티션을 지정한다. (동일한 메시지 키는 동일한 파티션에 적재됨)
  • 다만 어느 파티션에 지정될 지 알 수 없고, 파티션 개수가 변경되면 메시지 키와 파티션 매칭이 달라지므로 주의해야 한다.
  • 메시지 키를 선언하지 않으면 null로 설정되고, null로 설정된 레코드는 프로듀서 기본 설정 파티셔너에 따라서 파티션에 분배된다.

메시지 값에는 실질적 데이터가 들어있다.
- 메시지 키와 메시지 값은 직렬화되어 브로커로 전송되므로 컨슈머가 이용할때는 반드시 동일한 형태의 역직렬화를 해야한다.

 

(3) 오프셋과 헤더

레코드의 오프셋은 컨슈머가 데이터를 가져갈 때 사용되며, 0 이상의 숫자로 이루어져 있다. 레코드의 오프셋은 직접 지정이 불가하며 브로커에 저장될 때 이전에 전송된 레코드의 오프셋 + 1 값으로 생성된다.

헤더는 레코드의 추가적인 정보를 담은 메타데이터 저장소 용도로 사용한다.
헤더는 키/값 형태로 데이터를 추가하여 레코드의 속성(스키마 버전 등)을 저장하여 컨슈머에서 참조할 수 있다.