03. 토픽(Topic)과 파티션(Partition)

1. 적정 파티션 개수

  토픽의 파티션 개수는 카프카의 성능과 관련이 있습니다. 그렇기 때문에 토픽을 운영함에 있어 적절한 파티션 개수를 설정하고 운영하는 것이 중요합니다. 토픽 생성 시 파티션 개수 고려사항으로 데이터 처리량, 메시지 키 사용 여부 및 브로커, 컨슈머 영향도가 있습니다.

 

1) 데이터 처리량

  데이터 처리 속도를 올리는 방법은 컨슈머의 처리량을 늘리는 것(서버의 사양을 올리는 스케일 업 또는 GC 튜닝 등)과 컨슈머를 추가해서 병렬처리량을 늘리는 것입니다. 파티션 개수는 프로듀서가 보내는 데이터양과 컨슈머의 데이터 처리량을 계산해서 정하면 됩니다.

  프로듀서 전송 데이터량 < 컨슈머 데이터 처리량 X 파티션 개수

  파티션 개수만큼 컨슈머 스레드를 운영한다면 해당 토픽의 병렬처리를 극대화할 수 있습니다. 만약 전체 컨슈머 데이터 처리량이 프로듀서가 보내는 데이터양보다 적다면 컨슈머 랙이 생기고, 데이터 처리 지연이 발생하게 됩니다.

 

2) 메시지 키 사용 여부

  메시지 키를 사용함과 동시에 데이터 처리 순서를 지켜야 하는 경우에 대해 고려해야 합니다. 메시지 키를 사용하면 프로듀서가 토픽으로 데이터를 보낼 때 메시지 키를 해시 변환하여 메시지 키를 파티션에 매칭시킵니다. 다만, 파티션 개수가 달라지면 이미 매칭된 파티션과 메시지 키의 매칭이 깨지고 전혀 다른 파티션에 데이터가 할당됩니다. 그러므로 파티션 개수가 달라지는 순간 메시지 키를 사용하는 컨슈머는 특정 메시지 키의 순서를 더는 보장받지 못합니다. 메시지 키를 사용하지만 데이터 처리 순서를 지키지 않아도 된다면 파티션 개수를 처음부터 넉넉하게 잡을 필요는 없습니다. 데이터의 양에 따라 파티션을 늘리면 되기 때문입니다.

 

3) 브로커, 컨슈머 영향도

  파티션은 각 브로커의 파일 시스템을 사용하기 때문에 파티션이 늘어나는 만큼 브로커에서 접근하는 파일 개수가 많아집니다. 그런데 OS에서 프로세스당 열 수 있는 파일 최대 개수를 제한하기 때문에 각 브로커당 파티션 개수를 모니터링해야 합니다. 만약 브로커가 관리하는 파티션 개수가 너무 많다면 파티션 개수를 분산하기 위해서 카프카 브로커 개수를 늘리는 방안도 고려해야 합니다.

 

2. 토픽 정리 정책(cleanup.policy)

  토픽의 데이터는 시간 또는 용량에 따라 삭제 규칙을 적용할 수 있습니다.

 

1) 토픽 삭제 정책(delete policy)

  토픽을 운영하면 일반적으로 대부분의 토픽의 cleanup.policy를 delete로 설정합니다. 이 옵션은 명시적으로 토픽의 데이터를 세그먼트 단위(파일 시스템 단위)로 삭제합니다. 삭제 정책이 실행되는 시점은 시간 또는 용량이 기준이 됩니다.

# 토픽의 데이터를 유지하는 기간을 밀리초(millisecond)로 설정
retention.ms
# 토픽의 최대 데이터 크기 제어
retention.bytes

 

2) 토픽 압축 정책(compact policy)

  여기서 압축이란 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책을 뜻합니다. 압축 정책은 액티브 세그먼트(데이터를 저장하기 위해 사용 중인 세그먼트)를 제외한 나머지 세그먼트들에 한해서만 데이터를 처리합니다. 토픽의 압축은 min.cleanable.dirty.ratio 값에 따라 수행됩니다.

min.cleanable.dirty.ratio = 더티 레코드 개수 / (클린 레코드 개수 + 더티 레코드 개수)

  더티(dirty) 레코드는 헤드(head) 영역의 압축이 되기 전 레코드이며, 클린(clean) 레코드는 테일(tail) 영역의 브로커의 압축 정책에 의해 압축이 완료된 레코드를 뜻합니다.

 

3. ISR(In-Sync-Replicas)

  ISR은 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻합니다. 리더 파티션에 데이터가 적재된 이후 팔로워 파티션이 복제하는 시간차 때문에 오프셋 차이가 발생합니다. 이런 차이를 모니터링하기 위해 리더 파티션은 replica.lag.time.max.ms값만큼의 주기를 가지고 팔로워 파티션이 데이터를 복제하는지 확인합니다. 만약 팔로워 파티션이 replica.lag.time.max.ms값 보다 더 긴 시간 동안 데이터를 가져가지 않는다면 해당 팔로워 파티션에 문제가 생긴 것으로 판단하고 ISR 그룹에서 제외합니다. ISR로 묶인 리더 파티션과 팔로워 파티션은 파티션에 존재하는 데이터가 모두 동일하기 때문에 팔로워 파티션은 리더 파티션으로 새로 선출될 자격을 가집니다.

  일부 데이터 유실이 발생하더라도 서비스를 중단하지 않고 지속적으로 토픽을 사용하고 싶다면 ISR이 아닌 팔로워 파티션을 리더로 선출하도록 설정할 수 있습니다.

unclean.leader.election.enable
# false : ISR이 아닌 팔로워 파티션을 리더 파티션으로 선출하지 않음
# true  : ISR이 아닌 팔로워 파티션도 리더 파티션으로 선출

# topic 생성 시 설정 방법
$ bin/kafka-topics.sh --bootstrap-server localhost:9092 \
--create --topic my-topic \
--config unclean.leader.election.enable=false