[Kafka] 토픽 생성시 고려사항

카프카 토픽을 생성할 일이 생겼다!

기존에 ActiveMq만 사용해봤던 나는 이것도 금방 생성할 수 있을 거라고 믿었다...

CLI 명령어를 사용해서 생성할 수도 있고, 카프카 대시보드를 활용해 생성할 수도 있다.

우리 팀은 대시보드를 활용해서 생성하고 있다.

 

고려사항

기본적으로 토픽 생성 시 고려해야 할 사항으로는 메시지의 크기, 예상 트래픽, 메시지 보유기간, 세그먼트 사이즈 등이 있다.

또한, 대부분의 카프카를 쓴다면 클러스터 구성으로 사용하고 있을 텐데 그렇기 때문에 예상 메시지 크기보다 훨씬 디스크를 많이 먹는다.

 

설정

위의 고려사항을 생각하면서 Config를 구성해보자.

cleanup.policy (defalut=delete)

compact나 delete 옵션 중에서 사용하게 되는데, retention policy를 어떻게 할지를 결정한다.

• compact : 말 그대로 로그를 압축해준다. 기본적으로 cleaner.dedupe.buffer.size를 통해 128MB가 클리너 프로세스에 할당된다.
• delete : retention.ms나 retention.bytes 사이즈 제한을 넘으면 오래된 세그먼트를 삭제한다.

default인 delete를 사용하고 있는데, 아직 로그를 압축하고 전송해야 할 만큼의 양은 아닌 것 같아서 위와 같이 사용하는 것 같다.

 

retention.ms (default = 604800000 ms) 7일

삭제 정책을 사용하는 경우 토픽의 공간을 확보하기 위해 로그를 최대한 보존할 시간을 제어한다.

 

retention.bytes (default = -1)

cleanup.policy를 delete로 사용하는 경우 공간을 확보하기 위해 오래된 segement를 버리기 전에 파티션이 커질 수 있는 최대 크기를 제어한다. 쉽게 말해, 파티션의 크기가 retention.bytes를 넘어서면 예전 로그를 삭제하고 새로운 로그를 추가한다. 기본값인 -1을 사용하게 되면, 크기 제한은 하지 않고 시간제한만 생기게 되기 때문에 retention.ms에 따라서 파티션의 크기가 결정된다.

 

segments

segemetns라는 개념은 카프카에서 데이터를 저장할 때 파티션이 세그먼트 단위로 나눠서 저장하게 된다. segemetns의 크기가 꽉 차게 되면, 새로운 segemetns가 생성되고 새로 생성된 segemetns가 active segemetns가 된다. 현재 메세지가 쓰이고 있는 사용 중인 segemetns가 active segemetns이다.

segemetns의 파일 이름은 offset(=index)이 된다. 만약 파일 이름이 2.log면 offset이 2 이상인 로그가 저장된다.

• segements.ms : 일정기간이 지난 데이터에 대해 세그먼트 파일이 가득 차지 않은 경우에도 카프카가 강제로 로그를 롤링할 수 있는 기간. (default = 604800000(7일))
• segements.bytes : 로그의 segements 파일 크기를 제어한다. segments의 정리 단위는 하나의 파일 크기 단위로 제어되기 때문에, 크기가 크다면 파일 수는 적겠지만, 보존에 대한 세부적인 제어를 하기 힘들다. (default = 1073741824 (1GB))

 

헷갈렸던 부분

retension.bytes

• 파티션당 용량이므로 Topic의 수, Partition의 수를 고려해서 설정해야 한다
• 물리 서버 3대 + Partition 3개 + Replication 3로 설정된 환경에서는 각 물리 서버당 3개의 Partition이 저장된다. retension.bytes를 1G로 설정하면 디스크는 3G를 실제로는 차지하게 된다.
• segment.bytes 설정을 retention.bytes 이하의 값으로 지정해야 정상적으로 삭제가 된다.

 

Retention.ms vs delete.retention.ms

막상 retention.ms를 지정하려고 하니, 2가지의 옵션이 보여서 어느 부분에 설정을 해야 내가 원하는 값인지 알기 힘들었다.

찾아보니 delete.retention.ms의 경우에는 clean.policy 정책이 compact인 주제에 적용되는 옵션이었다.

 

실적용 예제

약 하루 20만 개의 메세지가 발행되고 메세지의 크기는 약 1KB라고 가정할 때 1GB가 차려면 대략 5일 정도가 소요된다고 해보자.

그럼 retention.ms를 1일로 두면 segements.bytes는 약 100MB 정도로 설정하면 된다!

 

참고

카프카 브로커 공식문서