카프카 - (3) 토픽

 

 

카프카 토픽 생성

먼저 지난번 포스팅에서 사용한 네트워크를 통한 통신으로 토픽을 생성해본다.

로컬 기기의 kafka_2.12-2.5.0 디렉토리에서 다음 커맨드를 실행해 준다.

* 지난 포스팅에서 카프카가 설치된 서버를 /etc/hosts에 johnny로 등록해준 것을 기억하자.

bin/kafka-topics.sh --create --bootstrap-server johnny:9092 --topic kafka-test

 

토픽 생성이 성공적으로 되었다면 다음과 같은 메시지를 출력할 것이다.

Created topic kafka-test.

 

토픽 생성 규칙

카프카 토픽은 영어 대소문자와 숫자, 그리고 대쉬(-), 언더스코더(_), 마침표(.) 로 조합할 수 있다.

한가지 특별한 규칙이 있다면, 언더스코어(_)와 마침표(.)는 같은 의미를 가져 중복될 수 었다.

예를 들어 kafka.test라는 토픽을 생성했다면, kafka_test라는 토픽은 생성할 수 없다.

 

파티션과 복제 데이터

위 그림에서와 같이 카프카는 파티션이라는 단위로 데이터를 분산처리한다.

최소 파티션의 갯수는 1개이다.

또한 각 파티션의 데이터는 복제본의 갯수를 설정해 분산 저장할 수 있다.

첫 포스팅에서 언급했던 바와 같이 복제본은

하나의 브로커에 장애가 발생했을 때 빠르게 데이터를 복구할 수 있도록 할 수 있다.

파티션은 1대의 브로커당 여러개를 만들 수 있지만,

복제본의 경우는 브로커 한대당 1개씩을 만들 수 있다.

따라서 브로커가 한대밖에 없는 경우, 복제본은 여러개를 만들 수 없다.

 

위 두가지 요소는 생성시에 다음과 같이 설정해 줄 수 있다.

bin/kafka-topics.sh --create \
--bootstrap-server johnny:9092
--topic kafka-test \
--partitions 3 \
--replication-factor 3

 

이미 토픽을 생성한 경우 파티션의 갯수는 다음과 같이 수정해 줄 수도 있다.

*replication-factor 옵션의 경우 --alter와 사용이 불가능하니 주의하자.

bin/kafka-topics.sh --bootstrap-server johnny:9092 \
--topic kafka-test \
--alter \
--partition 3

 

replication-factor를 수정하기 원하는 경우

다음과 같이 --delete 옵션을 통해 토픽을 삭제한 뒤 다시 생성해주면 된다.

bin/kafka-topics.sh --delete \
--bootstrap-server johnny:9092
--topic kafka-test \

 

원하는 대로 토픽 생성이 완료 되었다면,

다음 커맨드를 통해 토픽이 제대로 등록되었는지 확인해 보자.

bin/kafka-topics.sh --list --bootstrap-server johnny:9092

 

그리고 다음 커맨드를 통해 토픽의 설정을 확인해 보자.

bin/kafka-topics.sh --describe --bootstrap-server johnny:9092

 

다음과 같이 각 파티션의 정보가 나온다면 성공한 것이다.

Topic: kafka-test PartitionCount: 3 ReplicationFactor: 1 Configs: segment.bytes=1073741824
Topic: kafka-test Partition: 0 Leader: 0 Replicas: 0 Isr: 0
Topic: kafka-test Partition: 1 Leader: 0 Replicas: 0 Isr: 0
Topic: kafka-test Partition: 2 Leader: 0 Replicas: 0 Isr: 0

 

레코드

카프카에게 전달되는 레코드는 key:value 쌍으로 전달되며, 이를 레코드라고 부른다.

레코드를 카프카에게 전달하는 방식이므로 메시지라고 부르기도 한다.

 

레코드의 처리

메시지는 각 파티션에 분산처리 된다.

메시지의 키를 사용한 해싱(hashing)을 통해 파티션에 할당되고,

각 메시지는 오프셋을 지니게 된다.

오프셋은 메시지를 받은 시점이라고 생각하면 되고, 장애 복구시에 유용하게 사용된다.

같은 키를 가진 메시지는 같은 파티션으로 전송되는 것이 보장된다.

만약 키가 null이라면 라운드로빈 방식으로 모든 파티션에 한개씩 전송하게 된다.