[Kafka] 아파치 카프카 알아보기(2) - 운영 가이드

카프카는 여러대의 서버에 분산되어 실행되고, 각 토픽은 여러 개의 파티션으로 분리되어 있으며 각 브로커에 복제되어 분산되어 저장되는 등 복잡하게 운영되는 애플리케이션이다. 따라서 카프카 클러스터를 운영하다 보면 다양한 이슈가 발생하게 되고, 이슈들을 대응하기 위해 토픽의 상태 정보, 토픽의 설정 변경 작업 등이 매우 빈번하게 발생한다.

 

 

1) 토픽 설정 변경

카프카를 운영하면서 토픽의 설정을 변경해야 하는 경우가 있다. 운영 중인 카프카의 디스크 공간을 확보하는 가장 좋은 방법은 디스크 공간을 가장 많이 차지하는 토픽의 보관 주기를 줄여주는 것이다. 토픽 보관주기의 기본값은 7일이다. 토픽의 보관주기 설정을 변경하기 위해 kafka-configs.sh 명령어를 이용한다. 추가 옵션으로는 --zookeeper 옵션에 주키퍼 정보를 추가하고 --alter 옵션을 추가한 다음, --entity-type에는 토픽의 이름을 추가하고 --add-config 옵션에 보관주기 1시간을 의미하는 retention.ms=3600000을 추가하면 된다.

 

kafka-topics.sh의 --describe 옵션을 추가하여, 토픽에 변경내용 적용여부를 확인할 수 있다. 토픽 상세 중 Configs 부분에 새로 추가된 retention.ms 설정이 생겨있을 것이다. 만약 추가 옵션으로 설정한 보관주기 1시간 설정을 삭제하고 싶은 경우에는 --add-config 대신 --delete-config를 추가하고 삭제할 옵션인 retention.ms를 입력하면 된다.

 

 

2) 토픽의 파티션 수 변경

카프카를 운영하다 보면 토픽의 파티션을 변경하는 일이 생긴다. 예를 들어 최초 토픽을 생성할 때에는 메시지 요청량이 많지 않아 파티션 수를 2로 구성했는데, 이후에 처리량이 높아지면 파티션 수를 늘려야 하는 경우가 있다. 이런 경우에는 간단하게 명령어를 이용해 토픽의 파티션 수를 늘려주면 된다.

 

카프카에서는 토픽의 파티션 수는 증가만 가능하고, 감소는 불가능하다. 처음 토픽을 생성할때 파티션 수를 처리량에 대해 미리 확인한 후 신중하게 결정해 적용한다. 정확한 판단이 어렵다면, 가능한 한 작은 수의 파티션으로 우선 생성해두고 필요한 경우에 파티션 수를 늘려주는 방법으로 대응할 수 있다. 파티션만 증가했다고 메시지에 대한 전체 처리 성능이 좋아진 것은 아니다. 파티션의 수만큼 컨슈머 역시 추가해줘야 한다.

 

토픽의 파티션 수를 변경하기 위한 명령어는 kafka-topics.sh이며, 추가 옵션으로는 --zookeeper 옵션에 주키퍼 정보를 추가하고, --alter 옵션을 추가한 다음, --topic에 토픽명을 추가한 뒤에, --partitions에 늘려주고 싶은 파티션 수를 입력한다.

 

'파티션을 늘리면 메시지 순서에 영향을 끼칠 수 있다'는 주의 문구가 나타나고 Adding partitions succeeded라는 메시지가 뜨면서 파티션 수가 성공적으로 늘었다는 내용도 확인할 수 있다. 메시지 순서에 영향을 끼치지 않도록 아래와 같이 테스트를 해보자.

  1. 파티션 수가 1인 토픽 peter-test를 생성한다.

  2. 프로듀서가 key를 이용해 peter-test토픽에 메시지를 전송한다.

  3. 컨슈머가 peter-test 토픽에서 메시지를 가져와 결과를 확인한다.

  4. 토픽 peter-test의 파티션 수를 1에서 4로 변경한다.

  5. 프로듀서가 key를 이용해 peter-test 토픽에 메시지를 전송한다.

  6. 컨슈머가 peter-test 토픽에서 메시지를 가져와 결과를 확인한다.

 

파티션 수가 하나일때,

프로듀서는 10개의 메시지를 전송했고, key=1, key=2 모두 0번 파티션으로 메시지가 전송된 사실을 알 수 있다. 만약 key=1의 메시지를 필요로 하는 컨슈머가 있다면, 해당 컨슈머는 0번 파티션에서만 메시지를 가져오면 된다.

 

파티션 수를 4개로 늘렸을때,

프로듀서는 10개의 메시지를 전송했고, key=1의 메시지는 파티션 3번으로 key=2의 메시지는 파티션 0번으로 전송된 사실을 알 수 있다. 만약 key=1의 메시지를 필요로 하는 컨슈머가 파티션 수 변경 이후에도 계속해서 0번 파티션만 바라본다면, 컨슈머는 더이상 메시지를 가져갈 수 없을 것이다. 이렇게 key를 이용해 메시지를 전송하고 가져오는 형태로 운영하고 있다면, 파티션 수를 변경할때 주의해야 한다.

 

 

3) 토픽의 리플리케이션 팩터 변경

파티션과 마찬가지로 운영 중에 리플리케이션 팩터를 변경해야 하는 경우가 생길 수 있다. 리플리케이션 팩터를 변경하려면 먼저 json형식의 파일을 만들어야 한다. 먼저 peter-topic 토픽의 파티션 위치를 확인해야 하는데, 0번 파티션은 브로커 1번에 위치하고, 1번 파티션은 브로커 2번에 위치해 있다.

{"version":1,
 "partitions": [
    {"topic":"peter-topic", "partition":0, "replicas":[1,2]},
    {"topic":"peter-topic", "partition":1, "replicas":[2,3]}
]}

peter-topic의 파티션 내용을 보면, 파티션 0번은 "replicas":[1,2]이라고 되어 있다. 즉 파티션0의 복제 수는 2이며, 앞에 있는 수자가 리더를 의미하기 때문에 리더는 브로커1이고, 리플리카는 브로커2라는 의미이다.

 

동일하게 파티션 1번도 리플리케이션 팩터는 2이고, 리더는 브로커2, 리플리카는 브로커3이라는 의미다. 한가지 주의할 점을 이르자면, replicas의 첫번째 숫자를 현재 상태의 토픽 파티션 정보를 확인한 후 각 파티션의 현재 리더 정보와 일치하도록 설정해 파티션의 리더가 변경되지 않게 해야 한다. 리더가 변경되지 않기 때문에 토픽의 리플리케이션 팩터를 변경해도 프로듀서와 컨슈머에 영향을 주지 않을 수 있다.

 

또한, 만약 토픽의 리플리케이션 팩터를 2가 아닌 3으로 설정하기를 원한다면 replicas 설정에서 숫자를 하나 더 추가하면 된다. ("replicas":[1,2,3])

 

토픽의 리플리케이션 팩터를 변경하는 카프카 명령어는 kafka-reassign-partitions.sh이며 몇가지 추가 옵션을 주어야 한다. 추가 옵션으로는, --zookeeper 옵션에 주키퍼 정보를 추가하고, --reassignment-json-file 옵션에 미리 만들어둔 json 형식의 파일 경로와 파일명을 입력한 다음, --execute를 실행하면 된다.

 

만약 토픽 크기가 크다면, 데이터를 복사하는 시간이 필요하기 때문에 완료까지 시간이 소요될 수 있다.

 

 

4) 컨슈머 상태와 오프셋 확인

컨슈머의 현재 상태를 확인하기 위한 명령어는 kafka-consumer-groups.sh이며, 추가 옵션으로는 --bootstrap-server 옵션으로 브로커 리스트를 입력하고 --group 옵션으로 컨슈머 그룹 이름을 준 다음 --describe를 입력하고 실행하면 된다.

 

결과 필드에서 LAG는 현재 토픽의 저장된 메시지와 컨슈머가 가져간 메시지의 차이를 뜻한다.

 

컨슈머에서 더이상 가ㄱ져갈 메시지가 없는 상태를 LAG=0 이라고 한다. 다시 말해 LAG 숫자가 높다는 것은 해당 토픽 또는 파티션에 컨슈머가 읽어가지 못한 메시지가 많이 있다는 의미이다. 따라서 만약 LAG가 계속 증가하는 상황이라면 컨슈머 처리가 늦어지고 있는 것이기 때문에 컨슈머나 파티션 수를 늘려서 대응을 해야 하며, 특정 파티션에서만 LAG가 증가한다면 해당 파티션에 연결된 컨슈머에 문제가 없는지를 확인해야 한다.

주키퍼 스케일 아웃

주키퍼 3대로 구성한 것과 5대로 구성한 처리량을 비교해보면 약 60,000개 정도의 요청 수를 더 처리할 수 있음을 알 수 있다. 또한 주키퍼 노드의 장애 발생시 과반수 법칙에 따라 3대로 구성한 경우에는 최대 1대의 노드 장애까지는 지속적인 서비스가 가능하고, 5대로 구성한 경우에는 최대 2대의 노드 장애까지 지속적인 서비스가 가능하다. 이러한 점은 고려해 5대의 앙상블을 구성하는 편이 좋지만, 사용량이 적은 상태에서 5대를 운영하는 것보다는 최초 3대로 운영하다가 요청수가 늘어나는 경우 추가 증설하는 방법을 추천한다.

 

확장을 위해 추가한 peter-zk004, peter-zk005의 zoo.cfg 설정에는 peter-zk001~peter-zk005까지의 정보를 모두 입력한 상태고, peter-zk001~003의 경우 zoo.cfg 설정에 peter-zk001~peter-zk003까지의 정보만 입력한 상태이다. 기존에 구성된 peter-zk001~003서버에 추가된 서버 정보를 zoo.cfg에 추가하고 난 다음, 적용을 위해 주키퍼 1대씩 재시작하는 작업을 진행해야 한다. 재시작 작업에 별다른 순서가 있는 것은 아니지만 리더가 변경되면서 문제가 발생할 수도 있기 때문에, 주키퍼 앙상블의 리더는 가장 마지막에 작업하는 것을 권장한다. 리더를 가장 마지막으로 작업하기 위해서는 현재의 리더가 누구인지 알아야 한다. 리더를 찾는 방법은 주키퍼의 명령어를 이용해 확인할 수 있다. (zkServer.sh status)

 

결과 화면에서 Mode: follower라고 표시된다면, 현 앙상블 구성에서 peter-zk001은 팔로워인 상태이다. Mode: leader로 표시된 서버가 현 앙상블의 리더이다. 

 

주키퍼 재시작 작업이 완료되고 나면, 모든 주키퍼 노드에 변경된 zoo.cfg 내용이 적용된 상태가 된다. 마지막으로 주키퍼 앙상블 구성된 서버마다 zoo.cfg 파일이 동일한지 확인하면 된다. 설정 내용에 이상이 없다면, 주키퍼 앙상블이 잘 동작하고 있는지 확인해야 한다. 앙상블이 잘 동작하고 있다는 것은 리더와 팔로워들이 동기화가 잘 진행되고 있다는 의미와도 동일하다. 주키퍼에서는 현재 상태의 앙상블 모니터링을 위해 제공하는 mntr명령어와 리눅스의 nc(tcp/udp를 연결할 수 있는 명령어)를 함께 이용하면 간단하게 리더와 팔로워가 동기화를 잘하고 있는지 알 수 있다.

 

echo mntr | nc localhost 2181 | grep zk_synced_followers

앙상블 리더의 위 명령어에 대한 출력을 보면 zk_synced_followers 4로 현재 동기화되고 있는 팔로워의 수는 4로 확인되었다. 현재 앙상블은 모두 5대의 서버로 구성되어 있고, 리더 하나가 제외된 4대의 팔로워가 리더와 동기화를 해야만 현재 앙상블이 잘 유지되는 것이다. 동기화되고 있는 팔로워 수가 4로 확인되었기 때문에 리더를 제외한 나머지 4대의 서버가 모두 리더와 동기화를 하고 있는 상태이다. 만약 팔로워 수가 다르게 나타난다면, 주키퍼가 실행되지 않았는지를 확인해보고 systemctl 명령어를 이용해 재실행 해본다.

카프카 스케일 아웃

카프카 클러스터의 스케일 아웃은 주키퍼 앙상블의 스케일 아웃보다 매우 간단하다. 카프카를 스케일 아웃하는 방법은, 새롭게 추가하는 서버의 카프카 설정 파일에서 broker.id 부분만 다른 서버와 겹치지 않게 추가한 후 실행하면 카프카 클러스터에 간단하게 추가된다. 

 

카프카 클러스터 작업하기 전에 파티션 수는 5, 리플리케이션 팩터는 2인 peter5라는 토픽 하나를 미리 만들어 둔다.

 

카프카 클러스터의 스케일 아웃을 위해 호스트 이름이 peter-kafka004, peter-kafka005인 서버 2대를 추가한다. server.properties에서 peter-kafka004는 broker.id=4로 입력하고, peter-kafka005는 broker.id=5로 입력한다. 주키퍼 입력도 기존 브로커에 설정한 정보와 동일하게 설정한다. 이제 설정을 완료한 후 새로 추가하는 peter-kafka004, peter-kafka005 서버에서 카프카를 실행한다.

 

추가한 서버들이 카프카 클러스터에 잘 조인되었는지 확인하는 방법은 주키퍼에서 broker 정보를 확인하는 것이다. 주키퍼에서 정보를 확인하려면 주키퍼 서버에 접속한 후 주키퍼 CLI를 이용한다. 주키퍼 CLI(zkCli.sh)로 접속한 후 리스트를 확인할 수 있는 ls 명령어로 정보가 잘보이는지 확인한다.

 

브로커가 새로 추가되었지만 파티션 재배치는 자동으로 하지 않기 때문에, 추가된 브로커에는 토픽과 파티션이 없는 상태이고, 다른 브로커에 비해 리소스가 굉장히 많이 남아있는 상태이다. 새로 추가한 브로커에도 리소스를 분산시키기 위해서는 파티션 분산 작업을 해야 한다.

{"version":1,
 "partitions":[
    {"topic":"peter5","partition":0,"replicas":[2,1]},
    {"topic":"peter5","partition":1,"replicas":[3,2]},
    {"topic":"peter5","partition":2,"replicas":[4,3]},
    {"topic":"peter5","partition":3,"replicas":[5,4]},
    {"topic":"peter5","partition":4,"replicas":[1,5]}
]}

 파티션 분산 작업을 위한 명령어는 kafka-reassign-partitions.sh이며, 추가하는 옵션으로 --zookeeper 옵션에 주키퍼 정보를 추가하고 --reassignment-json-file 옵션에 미리 만들어둔 json 형식의 파일 경로와 파일명을 입력한 다음, --execute를 실행하면 된다.

 

신규 브로커를 추가한 후 토픽의 파티션을 분산시키는 작업을 해주어야만 새로운 브로커도 같은 클러스터로서 역할을 할 수 있게 된다. 운영중인 환경의 토픽과 파티션이라면 카프카에 저장된 파티션 크기가 매우 클 것이다. 예를 들어 하나의 파티션 사이즈가 약 1GB에서 5GB 정도 되는 경우 파티션 분산작업으로 파티션을 이동시킨다면 브로커에 영향이 없을 수도 있지만, 10GB 이상 되는 파티션을 이동시킨다면 이는 네트워크 인터페이스의 사용량을 급증시킬 뿐만 아니라 브로커에도 상당한 부담이 될 수 있다.

 

파티션 분산 작업을 안전하게 하려면,

첫번째 토픽의 사용량이 가장 적은 시간에 수행하는 방법을 추천하고, 두번째로는 토픽의 보관 주기를 줄여서 임시로 사이즈를 축소시킨 후 작업하는 방법을 추천한다.

카프카 모니터링

카프카 클러스터를 안정적으로 운영하기 위해서는 모니터링 정보를 수집하고 현 클러스터의 이상 유무를 한눈에 빠르게 확인할 수 있어야 한다. 아파치 카프카 도큐먼트에서는 가장 쉬운 방법으로 JMX를 추천하고 있다.

 

JMX(Java Management eXtensions)는 자바로 만든 애플리케이션의 모니터링 등을 위한 도구를 제공하는 자바 API로서, MBean(Managed Bean)이라는 객체로 표현된다.

 

카프카에서 JMX를 이용하려면 JMX를 사용할 수 있도록 설정해야 한다. JMX를 사용할 수 있도록 설정하는 방법은, 카프카 실행 파일에 JMX 관련 설정을 추가하는 방법고, systemd를 이용한 환경변수 추가방법 2가지가 있다. 설정이 끝나면 카프카를 재시작해주어야 한다.

 

1) JMX 모니터링 지표

JMX 모니터링 지표란 카프카 클러스터 모니터링시 확인해야할 주요 지표들이다. 

브로커 주요 항목	설명 ( MBean 이름 / 설명 / 기본값 )
Message in rate	MBean 이름: kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec 설명: 브로커 서버로 초당 들어오는 메시지 수를 확인할 수 있다. 기본값: -
Byte in rate	MBean 이름: kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec 설명: 브로커 서버로 초당 들어오는 사이즈를 확인할 수 있다. 기본값: -
Byte out rate	MBean 이름: kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec 설명: 브로커 서버로 초당 나가는 사이즈를 확인할 수 있다. 기본값: -
under replicated partitions	MBean 이름: kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions 설명: 현재 복제가 되지 않고 있는 파티션 수를 확인할 수 있다. 알람을 설정한다면 브로커의 이상 유무를 빠르게 감지할 수 있다. 기본값: 0이 아닌 경우 알람을 발생하게 된다.
Is controller active on broker	MBean 이름: kafka.server:type=KafkaController,name=ActiveControllerCount 설명: 클러스터 내 커느롤러 서버를 찾는 용도로 사용한다. 클러스터 내 컨트롤러 서버는 1대이다. 기본값: 컨트롤러는 1, 아닌 경우는 0
Partition counts	MBean 이름: kafka.server:type=ReplicaManager,name=PartitionCount 설명: 브로커에 있는 파티션 수를 나타낸다. 특정 브로커에 너무 많은 파티션 수가 몰려 있는 경우를 파악하거나 브로커에 전체 ㅍ티션 수를 파악하는데 용이하다. 기본값: -
Leader counts	MBean 이름: kafka.server:type=ReplicaManager,name=LeaderCount 설명: 브로커에 있는 리더의 수를 나타낸다. 클러스터내 특정 브로커에 리더가 집중되어 있으면 해당 브로커에만 부담이 크기 때문에 각각의 브로커에 골고루 리더를 분산 시켜주는 것이 좋다. 기본값: -
ISR shrick rate	MBean 이름: kafka.server:type=ReplicaManager,name=IsrShrinksPerSec 설명: 브로커가 다운되는 경우 일부 파티션에서 ISR 축소가 발생하게 되고 해당 비율을 나타내는 지표이다. 알람을 설정한다면 브로커의 이상 유무를 빠르게 감지할 수 있다. 기본값: 0이 아닌 경우 알람을 발생하게 된다.

카프카 매니저

카프카를 운영하며 토픽 추가/삭제/설정 변경 등의 작업을 웹 GUI로 이용하는 방법인 카프카 매니저에 대해 알아본다. 카프카 운영 툴인 카프카 매니저는 야후에서 오픈소스로 공개했다. 카프카 운영에 필요한 몇가지 기능은 오직 cli 환경에서만 적용할 수 있지만, 카프카 매니저에서는 운영과 관련된 많은 기능과 클러스터의 상태를 한눈에 알아볼 수 있어서 카프카 운영자들에게 매우 인기가 좋다.

 

카프카에서 JMX를 enable 했을 경우 Enable JMX Polling 항목을 체크하면 카프카 매니저를 이용해 현재 클러스터의 메시지 유입 상태 등의 추가 정보를 확인할 수 있다.

 

항목	설명
Brokers	해당 클러스터를 구성하고 있는 브로커들의 현재 상태 정보를 한눈에 확인할 수 있다.
Topic	해당 클러스터에 토픽을 신규로 생성할 수 있고, 이미 생성된 전체 토픽 리스트를 한 눈에 확인할 수 있다.
Preferred Replica Election	브로커 다운이 발생하거나 브로커의 점검 등으로 인해 파티션의 리더가 변경될 수 있다. 장애가 발생한 브로커가 정상화 되고 난 후 수동으로 파티션의 리더를 원복할 수 있다.
Reassign Partitions	토픽의 파티션 변경 작업을 할 때 사용하는 메뉴이다.
Consumers	해당 클러스터의 컨슈머 리스트 등을 확인할 수 있다.
Cluster Information	해당 클러스터의 주키퍼 정보와 버전 정보를 확인할 수 있다.
Cluster Summary	해당 클러스터에서 사용하고 있는 전체 토픽의 수와 브로커의 수를 확인할 수 있다.

Broker

브로커의 상세 메뉴에서는 클러스터를 구성하는 각각의 브로커별 상태 정보와 클러스터의 상태를 확인할 수 있다.

항목	설명
ID	브로커의 환경설정 파일인 server.properties에서 broker.id로 표시한 값이 나타난다.
Host	브로커의 호스트 이름을 나타낸다.
Port	브로커에서 카프카가 사용하는 TCP Port 9092 정보를 나타낸다.
JMX Port	브로커에서 사용하는 TCP Port 9999 정보를 나타낸다.
Bytes In	Bytes In은 해당 브로커로 들어오는 초당 바이트 수를 나타낸다.
Bytes Out	Bytes Out은 해당 브로커로 나가는 초당 바이트 수를 나타낸다.
Messages in /sec	Messages in /sec는 클러스터 전체 기준이며, 초당 메시지 수를 나타낸다.
Bytes in /sec	Bytes out /sec는 클러스터 전체 기준이며, 들어오는 초당 바이트 수를 나타낸다.
Bytes out /sec	Bytes in /sec는 클러스터 전체 기준이며, 나가는 초당 바이트 수를 나타낸다.
Bytes rejected /sec	Bytes rejected /sec는 클러스터 전체 기준이며, 거부되는 초당 바이트 수를 나타낸다.
Failed fetch request /sec	클러스터 전체 기준이며, 초당 fetch 요청이 실패되는 수를 나타낸다.
ailed produce request /sec	클러스터 전체 기준이며, 초당 produce 요청이 실패되는 수를 나타낸다.

Topic

해당 메뉴에서는 토픽을 생성하거나, 토픽의 전체 리스트를 확인할 수 있다. 토픽 생성 메뉴에서는 retention.ms와 같은 토픽의 추가 옵션을 입력하여 토픽을 생성할 수도 있다.

항목	설명
Operations	파티션 변경 작업 등을 할 수 있다.
Topic	토픽 이름을 나타낸다.
Partitions	토픽의 파티션 수를 나타낸다.
Brokers	해당 토픽의 파티션들이 몇개의 브로커에 분산되어 있는지를 나타낸다.
Brokers Spread %	해당 토픽의 파티션들이 몇개의 브로커에 분산되어 있는지를 퍼센트로 나타낸다. 100~80이면 변화가 없고, 80~50이면 노란색으로 표시되고, 50~0이면 붉은색으로 표시된다.
Brokers Skew	파티션이 브로커에 균등하게 분산되어 있는지를 퍼센트로 나타낸다.
Brokers Leader Skew	리더가 브로커에 균등하게 분산되어 있는지를 퍼센트로 나타낸다.
Replicas	리플리케이션 수를 나타낸다.
Under Replicated	토픽의 파티션별로 리플리케이션 상태 정보를 퍼센트로 나타낸다. 0이면 정상인 상태이고, 숫자가 높아지면 파티션의 리플리케이션이 불일치한 상태이다.

 

카프카 토픽 상세보기

항목	설명
Topic Summary	토픽의 정보, 현 상태 정보, 토픽 전체 리스트 화면에서 보여주는 항목들의 내용을 확인할 수 있다.
Operations	토픽의 삭제, 파티션 추가 등의 작업을 할 수 있다.
Metrics	해당 토픽이 카프카 초당 몇 개의 메시지가 유입되고 있는지, 인아웃의 바이트 정보 등을 확인할 수 있다.
Consumers consuming from this topic	이 토픽에서 메시지를 가져가고 있는 컨슈머를 볼 수 있고, 컨슈머 폴링을 enable해야 한다.
Partition Information	토픽 파티션의 리더와 ISR 정보 등을 확인할 수 있다.

카프카 매니저는 웹 UI 형태로 한눈에 클러스터의 상태, 토픽의 상태, 파티션의 상태 등을 확인할 수 있고, 파티션 변경 작업 등도 할 수 있어 매우 유용하게 활용되는 관리자 툴이다.

토픽의 보관주기를 변경하면 오래된 데이터가 삭제되어 디스크 공간을 확보할 수 있다. 이러한 증상은 카프카 기본 설정이 7일 보관이므로 자주 발생하게 되는데, 가능하다면, log.retention.hourse 옵션을 48시간 또는 72시간으로 변경하면 보다 효율적으로 운영할 수 있다.

출처: https://12bme.tistory.com/530?category=737765 [길은 가면, 뒤에 있다.]