토픽과 파티션, 레코드
토픽은 카프카에서 데이터를 구분하기 위해 사용하는 단위이다. RDB를 예로 들면 테이블이라고 볼 수 있을 것 같다.
토픽은 최소 1개 이상의 파티션을 소유하고 있으며 파티션에는 프로듀서가 보낸 데이터들이 들어가 저장되는데 이 데이터를 '레코드(record)'라고 부른다.
파티션은 카프카의 병렬처리의 핵심으로써 그룹으로 묶인 컨슈머들이 레코드를 병렬로 처리 할 수 있도록 해준다. 컨슈머의 처리량이 한정된 상황에서 많은 레코드를 병렬로 처리하는 가장 좋은 방법은 컨슈머의 개수를 늘려 스케일 아웃하는 것이다.
컨슈머 개수를 늘림과 동시에 파티션 개수도 늘려야 하며 처치량이 증가하는 효과를 볼 수 있다.
파티션 수와 컨슈머 수 공식
파티션 수 >= 컨슈머 수
파티션은 자료구조에서 접하는 큐(queue)와 비슷한 구조라고 생각하면 쉽다. First-in-first-out(FIFO) 구조와 같이 먼저 들어간 레코드는 컨슈머가 먼저 가져가게 된다.
다만 일반 큐와 다른 점은 큐는 데이터를 가져가면(pop) 레코드를 삭제하지만 카프카에서는 삭제 하지 않는다. 이러한 특징 때문에 토픽의 레코드는 다양한 목적을 가진 여러 컨슈머 그룹들이 토픽의 데이터를 여러 번 가져 갈 수 있다.
레코드
레코드는 타임스탬프, 메시지 키, 메시지 값, 오프셋으로 구성되어 있다. 프로듀서가 생성한 레코드가 브로커로 전송되면 오프셋과 타임스탬프가 지정되어 저장된다.
브로커에 한번 적재된 레코드는 수정할 수 없고 로그 리텐션 기간 또는 용량에 따라서만 삭제 된다.
레코드에 지정되는 타임스탬프에는 브로커 기준 유닉스 시간이 설정된다.컨슈머는 레코드의 타임스탬프를 토대로 레코드가 언제 브로커에 적재되었는지 알 수있다.
다만, 프로듀서가 레코드를 생성할 때 임의의 타임스탬프 값을 설정할 수 있고, 카프카 0.10.0.0 버전 이상에서만 타임 스탬프를 사용할 수 있다는 점을 유의해야 한다.
메시지 키는 메시지 값을 순서대로 처리하거나 메시지 값의 종류를 나타내기 위해 사용한다.
메시지 키를 사용하면 프로듀서가 토픽에 레코드를 전송할 때 메시지 키의 해시값을 토대로 파티션을 지정하게 된다. 즉, 동일한 메시지 키라면 동일 파티션에 들어가는 것이다.
다만, 어느 파티션에 지정될지 알 수 없고 파티션 개수가 변경되면 메시지 키와 파티션 매칭이 달라지게 되므로 주의해야 한다.
메시지 키를 사용하지 않는다면 null로 설정된다. 메시지 키가 null로 설정된 레코드는 프로듀서 기본 설정 파티셔너에 따라 로드밸런싱방식으로 분배되어 적재된다.
메시지 값에는 실질적으로 처리할 데이터가 들어 있다. 메시지 키와 메시지 값은 직렬화되어 브로커로 전송되기 때문에 컨슈머가 이용할 때는 직렬화한 형태와 동일한 형태로 역직렬화를 수행해야 한다.
만약 프로듀서가 StringSerializer로 직렬화한 메시지 값을 컨슈머가 IntegerDeserializer로 역직렬화하면 정상적인 데이터를 얻을 수 없다.
오프셋은 0 이상의 숫자로 이루어져 있으며 직접 설정할 수 없고 브로커에 저장될 때 이전에 전송된 레코드 오프셋의 +1 값으로 생성된다.
오프셋은 컨슈머가 데이터를 가져갈 때 사용되며 데이터를 어디까지 가져갔는지 명확히 알 수 있다.
'Kafka' 카테고리의 다른 글
Spring Kafka로 토픽 구독 (0) | 2022.01.26 |
---|---|
카프카 토픽명 규칙 (0) | 2022.01.26 |
Kafka에서 데이터 순서 보장하려면? (0) | 2022.01.26 |
Kafka 정리 (0) | 2022.01.26 |
자주쓰는 Kafka 명령어 (0) | 2022.01.26 |