Kafka server.property (config 설정) 관련 옵션들 - 2

이 페이지에서는 Kafka broker 들을 구성할 때, 튜닝을 고려 할 수 있는 server.property 옵션들에 대하여 다룬다.

 

이 페이지는 perplexity 를 통해 필자가 어떤 prompt 를 작성하여 공부하는지를 공유한다. ([] 로 표기)

또한, 검색이외에 추가로 덧붙일 내용은 ※ 로 추가한다.

 

AI 를 통해 관련된 자료를 검색하다보면 이전 게시글과 중복된 사항도 있으나 이는 복습 및 상기 차원에서 그대로 기재 되도록 한다.

또한, 출처 또한 동시에 표기한다.

 

[Kafka 에서 auto.leader.rebalance.enable 에 대해서 알려줘]

 

Kafka의 auto.leader.rebalance.enable 옵션은 카프카 클러스터 내에서 파티션 리더(Leader)의 분포가 특정 브로커에 치우치는 불균형(leader skew)을 자동으로 해소하는 기능입니다. 이 옵션의 주요 목적과 동작 방식은 다음과 같습니다.

주요 역할 및 필요성

• 리더 분포 불균형(Leader Skew) 해소
  카프카의 각 파티션은 여러 브로커에 복제(replica)되지만, 실제로 데이터를 읽고 쓰는 역할(리더)은 한 브로커에만 집중됩니다.
  클러스터 운영 중 브로커 추가/삭제, 장애 복구 등으로 인해 특정 브로커에 리더가 몰리면, 해당 브로커에 과부하가 발생할 수 있습니다125.
• 자동 리더 재분배
  auto.leader.rebalance.enable=true로 설정하면, 백그라운드 스레드가 주기적으로 리더 분포 상태를 체크하고, 불균형이 감지되면 파티션 리더를 선호 리더(preferred leader)로 자동 재조정합니다12568910.

동작 방식

• 주기적 체크
  리더 분포 상태는 leader.imbalance.check.interval.seconds 설정(기본 300초, 환경에 따라 다름)마다 확인됩니다2568.
• 불균형 기준
  특정 브로커에 리더가 전체 파티션의 leader.imbalance.per.broker.percentage(기본 10%) 이상 몰리면 리밸런싱이 트리거됩니다258.
• 선호 리더(Preferred Leader) 복귀
  파티션의 첫 번째 replica가 "선호 리더"이며, 리밸런싱 시 이 preferred leader로 리더를 재선출합니다136.

설정 예시

auto.leader.rebalance.enable=true 
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10

기타 참고사항

• 운영 편의성
  자동 리밸런싱을 통해 관리자의 수고를 줄일 수 있지만, 대규모 브로커 추가 등 특정 상황에서는 수동 리밸런싱(kafka-leader-election.sh 등)도 고려해야 합니다12.
• 비활성화 가능
  필요 시 이 옵션을 false로 두고, 리더 재분배를 수동으로 관리할 수도 있습니다4.

요약:
auto.leader.rebalance.enable은 카프카 클러스터의 리더 역할이 특정 브로커에 몰리는 현상을 자동으로 감지·해결하여, 클러스터의 부하를 균등하게 분산하고 성능 저하 및 장애 위험을 줄이는 중요한 설정입니다12568910.

1. https://velog.io/@tedigom/Kafka-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-Rebalance-%ED%95%98%EA%B8%B0
2. https://yeon-kr.tistory.com/183
3. https://joochang.tistory.com/139
4. https://docs.redhat.com/ko/documentation/red_hat_streams_for_apache_kafka/2.0/html/using_amq_streams_on_rhel/assembly-managing-kafka-str
5. https://assu10.github.io/dev/2024/06/15/kafka-install/
6. https://mandykr.tistory.com/95
7. https://westlife0615.tistory.com/653
8. https://velog.io/@kidae92/Apache-Kafka-%EC%A3%BC%EC%9A%94-%EC%9A%94%EC%86%8C4Replication
9. https://maru-itdeveloper.tistory.com/82
10. https://docs.aws.amazon.com/ko_kr/msk/latest/developerguide/msk-default-configuration.html

 

[delete.topic.enable 에 대해서 알려줘]

 

delete.topic.enable은 Kafka에서 토픽(topic) 삭제 기능의 활성화 여부를 제어하는 브로커 설정 옵션입니다.

주요 내용

• 기능
  이 옵션이 true로 설정되어 있어야만, kafka-topics.sh --delete 명령을 통해 토픽을 실제로 삭제할 수 있습니다256810.
• 기본값
  최신 Kafka 버전에서는 기본값이 true이지만, 일부 환경이나 과거 버전에서는 기본값이 false일 수 있습니다5.
• 설정 위치
  브로커 설정 파일(server.properties)에 아래와 같이 추가합니다

delete.topic.enable=true

• 동작 방식
  • true : 토픽 삭제 명령 실행 시, 해당 토픽의 데이터와 메타데이터가 실제로 삭제됩니다.
  • false : 삭제 명령을 내려도 토픽은 "marked for deletion(삭제 예약)" 상태로만 남고 실제로 삭제되지 않습니다. 이 상태에서는 토픽에 접근할 수 없지만, 디스크 공간은 회수되지 않고, 동일 이름의 토픽 재생성 등에도 문제가 발생할 수 있습니다24678.
• 주의 사항
  • 설정 변경 후에는 Kafka 브로커를 재시작해야 적용됩니다789.
  • 토픽을 바라보는 커넥터나 컨슈머가 있을 경우, 삭제가 지연되거나 제대로 삭제되지 않을 수 있습니다1.
  • 완전히 삭제되지 않은 경우, Zookeeper 쉘을 이용해 /brokers/topics/토픽이름 경로를 직접 삭제해야 할 수도 있습니다2489.

요약

• delete.topic.enable=true여야 토픽 삭제가 정상적으로 동작합니다.
• 이 옵션이 false면 삭제 명령은 "예약"만 하고 실제 삭제는 이루어지지 않습니다.
• 설정 변경 후 브로커 재시작이 필요하며, 토픽 삭제가 안 될 때는 Zookeeper에서 직접 정리해야 할 수도 있습니다.

Kafka에서 토픽 삭제를 원한다면, 반드시 delete.topic.enable=true를 확인하고 사용하세요.

1. https://seojeong-99.tistory.com/142
2. https://jusunglee.tistory.com/entry/%ED%86%A0%ED%94%BD-%EC%82%AD%EC%A0%9C-Topic-delete
3. https://pinggoopark.tistory.com/entry/kafka-%EC%B9%B4%ED%94%84%EC%B9%B4%EC%97%90%EC%84%9C-%ED%86%A0%ED%94%BD-%EC%82%AD%EC%A0%9C%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95
4. https://deep-dive-dev.tistory.com/61
5. https://docs.redhat.com/ko/documentation/red_hat_streams_for_apache_kafka/2.5/html/using_amq_streams_on_rhel/con-topic-deletion-str
6. https://knight76.tistory.com/entry/kafka-%ED%86%A0%ED%94%BD-%EC%82%AD%EC%A0%9C-%EA%B4%80%EB%A0%A8-%EC%98%88%EC%A0%9C
7. https://starblood.tistory.com/entry/kafka-topic-%EC%82%AD%EC%A0%9C%EC%8B%9C-%EC%9C%A0%EC%9D%98%EC%82%AC%ED%95%AD
8. https://yebali.tistory.com/69
9. https://hyojaedev.tistory.com/38
10. https://presentlee.tistory.com/12

 

[num.partitions 에 대해서 알려주고 이에 따른 주의점과 파티션 개수 결정 기준에 도움이 되는 사항들을 알려줘]

 

Kafka의 num.partitions란?

**num.partitions**는 Kafka에서 토픽을 생성할 때 기본적으로 생성되는 파티션의 개수를 의미합니다.
파티션은 Kafka의 토픽 데이터를 물리적으로 분산 저장하는 단위로, 병렬 처리, 확장성, 메시지 순서 보장 등에 중요한 역할을 합니다.

• 토픽 생성 시 별도 지정이 없으면 브로커 설정의 num.partitions 값이 적용됩니다12.
• 각 파티션은 클러스터 내 여러 브로커에 분산되어 저장·관리됩니다.

주의점 및 파티션 개수 결정 시 고려사항

1. 파티션 개수와 병렬성

• 병렬 소비의 한계: 한 컨슈머 그룹 내에서 동시에 병렬로 메시지를 처리할 수 있는 컨슈머 수는 파티션 개수와 동일합니다. 예를 들어, 10개의 파티션이 있으면 최대 10개의 컨슈머가 병렬로 처리할 수 있습니다34.
• 프로듀서·컨슈머 처리량: 파티션이 많을수록 프로듀서와 컨슈머가 더 높은 처리량을 달성할 수 있습니다.

2. 파티션 개수 결정 공식

• 기본 공식
  • 필요한 파티션 수 = max(총 목표 처리량 ÷ 단일 파티션 처리량(프로듀서), 총 목표 처리량 ÷ 단일 파티션 처리량(컨슈머))
  • 예시: 컨슈머 1개가 초당 50MB를 처리할 수 있고, 전체 처리량이 1000MB/sec라면 최소 20개 파티션 필요567.

3. 적절한 파티션 개수 산정 가이드

• 병렬성: 컨슈머 그룹 내 동시 처리 수요에 맞게 파티션 수를 산정.
• 브로커 수와 배수: 파티션 개수를 브로커 수의 배수로 설정하면 리더 분산이 고르게 이루어져 부하가 균등해집니다8.
• 향후 확장성: 미래 데이터 증가와 컨슈머 확장 가능성을 고려해 다소 넉넉하게 설정하는 것이 좋습니다.
• 메시지 순서 보장: 파티션 내에서는 메시지 순서가 보장되지만, 파티션을 늘리면 키 기반 메시지의 순서가 깨질 수 있으므로 주의해야 합니다64.

4. 주의해야 할 점

• 과도한 파티션 수의 부작용
  • 각 파티션은 별도의 파일 핸들, 메모리, 네트워크 리소스를 사용하므로, 너무 많은 파티션은 클러스터의 성능 저하, 메타데이터 관리 부담, 장애 발생 시 복구 시간 증가 등의 문제를 유발할 수 있습니다9410.
  • 일반적으로 브로커당 100개 내외, 클러스터 전체 10,000~200,000개 이내로 관리하는 것이 권장됩니다96410.
• 파티션 수 변경의 제약
  • 파티션 수는 늘릴 수 있지만, 줄일 수는 없습니다.
  • 파티션을 늘리면 키 기반 메시지의 분산 방식이 바뀌어 기존 순서 보장이 깨질 수 있습니다64.

5. 실무적 권장사항

• 작게 시작해서 점진적 확장: 처음에는 3~12개 정도로 시작하고, 필요에 따라 늘리는 것이 일반적입니다119.
• 파티션 키 설계: 데이터가 특정 파티션에 몰리지 않도록 키 설계를 신중하게 해야 합니다.
• 모니터링 필수: 파티션별 크기, 소비 지연, 처리량 등을 지속적으로 모니터링하고 조정합니다.

파티션 개수 결정 체크리스트

고려 항목설명 및 권장사항

컨슈머 병렬성	필요한 동시 컨슈머 수 이상으로 설정
브로커 수	브로커 수의 배수로 맞추면 리더 분산에 유리
처리량/성능	단일 파티션 처리량을 측정해 공식 적용
순서 보장	키 기반 메시지라면 파티션 수 변경에 신중
리소스 한계	브로커당 100~200개, 클러스터 10,000~200,000개 권장
미래 확장성	데이터 증가, 컨슈머 확장 고려해 여유 있게 설정

 

 

요약
Kafka의 num.partitions는 토픽의 병렬성, 처리량, 확장성에 직접적인 영향을 미치는 핵심 설정입니다.
너무 적으면 성능이 제한되고, 너무 많으면 클러스터 리소스와 관리에 부담이 커지니
처리량, 컨슈머 수, 브로커 수, 메시지 순서 보장, 향후 확장성 등을 종합적으로 고려해 신중히 결정해야 합니다912564810713.

 

※ 위에 게시된 데로 한번 늘린 토픽수는 줄일 수 없으니 신중하게 결정해야 한다.

 

1. https://codemia.io/knowledge-hub/path/kafka_create_topic_with_default_number_of_partitions
2. https://log-laboratory.tistory.com/226
3. https://www.reddit.com/r/apachekafka/comments/xd5s95/number_of_partitions/
4. https://github.com/AutoMQ/automq/wiki/Kafka-Partition:-All-You-Need-to-Know-&-Best-Practices
5. https://stackoverflow.com/questions/50271677/how-to-choose-the-no-of-partitions-for-a-kafka-topic
6. https://docs.confluent.io/kafka/operations-tools/partition-determination.html
7. https://www.confluent.io/blog/how-choose-number-topics-partitions-kafka-cluster/
8. https://www.reddit.com/r/apachekafka/comments/r701jg/how_to_decide_number_of_partitions/
9. https://www.datastreamhouse.com/blog/how-many-partitions-do-i-need-in-apache-kafka
10. https://dattell.com/data-architecture-blog/kafka-optimization-how-many-partitions-are-needed/
11. https://www.reddit.com/r/apachekafka/comments/1goigd1/kafka_topics_partition_best_practices/
12. https://newrelic.com/kr/blog/best-practices/effective-strategies-kafka-topic-partitioning
13. https://learn.conduktor.io/kafka/kafka-topics-choosing-the-replication-factor-and-partitions-count/
14. https://stackoverflow.com/questions/59114675/the-behavior-about-num-partitions-in-properties-file
15. https://presentlee.tistory.com/12
16. https://kafka.apache.org/documentation/
17. https://www.redpanda.com/guides/kafka-tutorial-kafka-partition-strategy
18. https://strimzi.io/blog/2021/06/08/broker-tuning/
19. https://stackoverflow.com/questions/58806232/what-is-the-ideal-number-of-partitions-in-kafka-topic
20. https://stackoverflow.com/questions/50121042/kafka-is-our-number-of-partitions-insane

 

[default.replication.factor 에 대해서 알려줘]

 

**default.replication.factor**는 Kafka 브로커의 설정 옵션 중 하나로, 자동 생성되는 토픽의 파티션 복제본(Replication) 개수의 기본값을 지정합니다.
즉, 토픽을 명시적으로 만들 때 replication-factor를 지정하지 않거나, auto.create.topics.enable=true 상태에서 토픽이 자동 생성될 때 적용되는 복제본 개수입니다67910.

주요 설명

• Replication Factor란?
  각 파티션 데이터를 여러 브로커에 복제해 저장하는 개수입니다.
  예를 들어 replication factor가 3이라면, 각 파티션 데이터가 3개의 브로커에 저장됩니다145.
• default.replication.factor의 기본값
  보통 1(복제 없음)이나 2~3(복제본 2~3개)로 설정됩니다.
  운영 환경에서는 장애 대비와 데이터 내구성을 위해 2 이상, 일반적으로 3을 권장합니다457.
• 설정 위치
  server.properties 파일에 아래와 같이 설정합니다.

default.replication.factor=3

• 동작 예시
  • 명령어로 토픽 생성 시 replication-factor를 지정하지 않으면 이 값이 적용됩니다.
  • auto.create.topics.enable=true 상태에서 존재하지 않는 토픽에 메시지를 보내면, 이 값이 자동 적용되어 토픽이 생성됩니다610.

주의점

• 브로커 수 제한
  replication factor는 반드시 클러스터 내 브로커 수 이하로만 설정해야 합니다.
  예: 브로커가 2대뿐인데 replication factor를 3으로 하면 토픽 생성이 실패합니다46.
• 디스크 사용량 증가
  복제본 수가 늘어나면 데이터가 여러 번 저장되므로 디스크 사용량이 배로 증가합니다.
  또한, 브로커 간 복제 트래픽과 리소스 사용도 늘어납니다145.
• 복제본 관리
  복제본이 많을수록 장애 시 데이터 손실 위험이 줄어들지만, 리소스 부담도 커집니다.
  데이터 중요도에 따라 적절한 값을 선택하는 것이 중요합니다145.

복제본 개수 결정 기준 및 팁

• 데이터 중요도
  • 중요 데이터: 3 이상 권장(장애 시 데이터 손실 최소화)
  • 비중요 데이터: 1~2도 가능
• 클러스터 브로커 수
  • replication factor는 브로커 수 이하로만 설정 가능
• 운영 환경 표준
  • 일반적으로 3을 가장 많이 사용(1개는 leader, 2개는 follower)
• 내부 토픽 별도 설정
  • offsets.topic.replication.factor 등 내부 토픽 복제본도 별도 설정 필요
• 리소스 고려
  • 복제본이 많을수록 디스크/네트워크/CPU 사용량이 증가함에 유의

요약 표

설정 값설명권장값/주의점

default.replication.factor	자동 생성 토픽의 기본 복제본 개수	3(운영), 1(테스트)
브로커 수	replication factor ≤ 브로커 수	브로커 수 미만 불가
디스크/리소스 사용량	복제본 수만큼 배로 증가	리소스 한계 고려
데이터 중요도	중요할수록 높은 replication factor 권장	3 이상 권장

 

정리:
default.replication.factor는 Kafka에서 토픽 복제본의 기본값을 정하는 옵션으로,
**데이터 내구성과 장애 대비를 위해 2~3 이상을 권장**하지만,
**브로커 수와 리소스 한계를 반드시 고려**해 설정해야 합니다14567.

1. https://damdam-kim.tistory.com/17
2. https://log-laboratory.tistory.com/226
3. https://presentlee.tistory.com/12
4. https://xonmin.tistory.com/80
5. http://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-topic-replication/
6. https://hbase.tistory.com/218
7. https://firststep-de.tistory.com/43
8. https://www.ibm.com/docs/ko/oala/1.3.7?topic=collection-configuring-apache-kafka-brokers
9. https://velog.io/@ehdrms2034/%EC%B9%B4%ED%94%84%EC%B9%B4-2%EC%9E%A5-%EC%BB%A4%EB%A7%A8%EB%93%9C%EB%9D%BC%EC%9D%B8-%ED%88%B4
10. https://rockintuna.tistory.com/265

 

[log.retension.ms, log.retension.bytes, log.segment.bytes, log.roll.ms  에 대해서 알려줘]

 

 

Kafka 로그 및 세그먼트 관련 주요 설정 설명

1. log.retention.ms

• 의미: 메시지(로그)를 최소한으로 보관할 시간을 밀리초(ms) 단위로 지정합니다.
• 기본값: 7일(604800000ms)
• 동작: 해당 시간이 지나면 로그 세그먼트가 삭제 대상이 됩니다.
• 활용 예시:
•  

  text

  log.retention.ms=86400000 # 1일 보관
• 주의: -1로 설정하면 시간 제한 없이 무한 보관합니다. 시간 단위로는 log.retention.minutes, log.retention.hours도 사용 가능123.

2. log.retention.bytes

• 의미: 파티션별로 보관할 로그의 최대 크기(바이트 단위)를 지정합니다.
• 기본값: -1(무제한)
• 동작: 파티션의 로그 크기가 이 값을 초과하면 오래된 세그먼트부터 삭제됩니다.
• 활용 예시:
•  

  text

  log.retention.bytes=1073741824 # 1GB 보관
• 주의: 파티션별로 적용되므로, 전체 토픽 보관 용량은 파티션 개수 × log.retention.bytes로 계산해야 합니다45.

3. log.segment.bytes

• 의미: 하나의 로그 세그먼트(파일) 최대 크기를 지정합니다.
• 기본값: 1GB(1073741824 bytes)
• 동작: 세그먼트 파일이 이 크기에 도달하면 닫히고, 새로운 세그먼트가 생성됩니다.
• 활용 예시:
•  

  text

  log.segment.bytes=536870912 # 512MB
• 주의: 세그먼트가 많아지면 파일 핸들, 메타데이터 관리 부담이 커질 수 있습니다. 너무 작게 설정하면 오픈 파일 수가 급증할 수 있습니다678.

4. log.roll.ms

• 의미: 활성 세그먼트가 지정된 시간(ms) 이상 유지되면, 강제로 세그먼트를 닫고 새 세그먼트를 생성합니다.
• 기본값: 7일(604800000ms)
• 동작: 메시지 유입이 적어도, 이 시간이 지나면 세그먼트가 롤링(교체)됩니다.
• 활용 예시:
•  

  text

  log.roll.ms=3600000 # 1시간마다 세그먼트 롤링
• 주의: log.segment.bytes와 함께 세그먼트 롤링 조건을 결정합니다. 둘 중 하나라도 조건을 만족하면 롤링이 발생합니다679.

요약 표

설정명기본값의미/용도주의사항 및 팁

log.retention.ms	604800000(7일)	메시지 보관 최소 시간	-1: 무제한, 시간 단위별 옵션 존재
log.retention.bytes	-1(무제한)	파티션별 보관 최대 크기	파티션 수에 따라 전체 용량 산정
log.segment.bytes	1073741824(1GB)	세그먼트 파일 최대 크기	파일 핸들, OS 한계 고려
log.roll.ms	604800000(7일)	세그먼트 최대 유지 시간(롤링 주기)	log.segment.bytes와 병행 적용

 

실무 적용 팁

• retention 설정: 데이터 보존 정책, 디스크 용량, 처리량에 따라 적절히 조합해 사용.
• segment 설정: 파일 핸들 제한, 장애 복구 속도, 운영 환경에 맞게 조정.
• 모니터링 필수: 세그먼트 수, 디스크 사용량, 메시지 보관 기간 등 지속적 체크 필요.

이 네 가지 옵션을 적절히 조합하면 Kafka의 데이터 보관 정책과 성능을 효과적으로 관리할 수 있습니다.

1. https://deep-dive-dev.tistory.com/63
2. https://devfoxstar.github.io/mq/kafka-retention-ms/
3. https://docs.redhat.com/ko/documentation/red_hat_streams_for_apache_kafka/2.5/html/kafka_configuration_tuning/managing_logs_with_data_retention_policies
4. https://stackoverflow.com/questions/53039752/kafka-how-to-calculate-the-value-of-log-retention-byte
5. https://gunju-ko.github.io/kafka/2019/03/16/%EC%B9%B4%ED%94%84%EC%B9%B4%EA%B0%80%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A5%BC%EC%A0%80%EC%9E%A5%ED%95%98%EB%8A%94%EB%B0%A9%EB%B2%95.html
6. https://westlife0615.tistory.com/514
7. https://www.redpanda.com/guides/kafka-performance-kafka-logs
8. https://stackoverflow.com/questions/65507232/kafka-log-segment-bytes-vs-log-retention-hours
9. https://kafka.apache.org/30/generated/topic_config.html
10. https://westlife0615.tistory.com/930
11. https://blog.metafor.kr/253
12. https://hojak99.tistory.com/681
13. https://learn.conduktor.io/kafka/kafka-topic-configuration-log-retention/
14. https://docs.redhat.com/ko/documentation/red_hat_streams_for_apache_kafka/2.6/html/kafka_configuration_tuning/managing_kafka_logs_with_delete_and_compact_policies
15. https://forum.confluent.io/t/what-happens-if-i-increase-log-segment-bytes/5845
16. https://developnote-blog.tistory.com/197
17. https://www.baeldung.com/ops/kafka-log-segment-bytes-vs-log-retention-hours
18. https://docs.redhat.com/ko/documentation/red_hat_streams_for_apache_kafka/2.7/html/kafka_configuration_tuning/managing_kafka_logs_with_delete_and_compact_policies
19. https://soono-991.tistory.com/106
20. https://docs.confluent.io/platform/current/installation/configuration/topic-configs.html

 

[log segment 에 대해서 알려줘]

 

Kafka에서 **log segment(로그 세그먼트)**란, 파티션 데이터를 실제로 저장하는 파일 단위를 의미합니다.
Kafka의 저장 구조는 "토픽 → 파티션 → 세그먼트" 계층으로 이루어지며, 각 파티션의 데이터는 여러 개의 세그먼트 파일로 쪼개어 브로커의 로컬 디스크에 저장됩니다2457.

핵심 특징 및 구조

• 세그먼트란?
  • 각 파티션에 저장되는 메시지들은 순차적으로 세그먼트 파일에 기록됩니다.
  • 세그먼트 파일에는 메시지의 키, 값, 오프셋, 메시지 크기 등 부가 정보까지 함께 저장됩니다2567.
  • 세그먼트 파일의 이름은 해당 세그먼트에서 시작하는 첫 번째 메시지의 오프셋으로 정해집니다7.
• 세그먼트 파일 종류
  • .log: 실제 메시지 데이터 저장
  • .index: 오프셋과 물리적 위치 매핑 정보
  • .timeindex: 오프셋과 타임스탬프 매핑 정보7
  • 기타: 리더 에포크 정보 등 관리 파일

세그먼트 관리 방식

• 롤링(Rolling)
  • 세그먼트 파일은 설정된 최대 크기(log.segment.bytes, 기본 1GB) 또는 **최대 시간(log.roll.ms 등)**에 도달하면 닫히고, 새로운 세그먼트 파일이 생성됩니다1357.
  • 이 방식을 통해 파일 크기가 너무 커지거나, 관리가 어려워지는 것을 방지합니다.
• 삭제(Delete) 및 보존(Retention)
  • 세그먼트는 보관 기간(log.retention.ms/hours/minutes) 또는 **최대 크기(log.retention.bytes)**를 초과하면 오래된 세그먼트부터 삭제됩니다135.
  • 이로써 디스크 공간을 효율적으로 관리할 수 있습니다.
• 컴팩션(Compaction)
  • 보존 정책이 compact로 설정된 토픽의 경우, 동일 키에 대해 가장 최신 메시지만 남기고 이전 메시지는 세그먼트 내에서 제거합니다123.
  • 대표적으로 __consumer_offsets 토픽이 이 방식을 사용합니다.

세그먼트의 역할과 중요성

• 효율적 대용량 데이터 관리: 세그먼트 단위로 데이터가 나뉘어 저장되기 때문에, 삭제·압축·복구 등 관리 작업이 효율적으로 이루어집니다4.
• 순차적 읽기/쓰기 최적화: Kafka는 세그먼트에 데이터를 순차적으로 추가(append-only)하므로, 디스크 I/O 성능이 뛰어납니다46.
• 오프셋 기반 접근: 컨슈머는 세그먼트 파일에서 오프셋을 기반으로 원하는 메시지를 빠르게 조회할 수 있습니다78.

요약

• **log segment**는 Kafka 파티션 내 데이터를 저장하는 기본 파일 단위입니다.
• 세그먼트는 크기 또는 시간 기준으로 분할·관리되며, 삭제/컴팩션 정책에 따라 오래된 데이터가 정리됩니다.
• 세그먼트 구조 덕분에 Kafka는 대용량 메시지의 저장, 읽기, 삭제, 압축 등 다양한 작업을 효율적으로 수행할 수 있습니다.

1. https://velog.io/@zndndn112/Kafka-%EC%B9%B4%ED%94%84%EC%B9%B4-%EB%A1%9C%EA%B7%B8%EC%99%80-%EC%84%B8%EA%B7%B8%EB%A8%BC%ED%8A%B8
2. https://colevelup.tistory.com/18
3. https://any-ting.tistory.com/166
4. https://curiousjinan.tistory.com/entry/understanding-kafka-all-structure
5. https://hoing.io/archives/57594
6. https://etloveguitar.tistory.com/116
7. https://teki.tistory.com/78
8. https://velog.io/@dmsqo1403/Kafka-Segment
9. https://zeroco.tistory.com/105
10. https://yeongchan1228.tistory.com/52

 

[min.insync.replicas 에 대해서 알려줘]

 

Kafka min.insync.replicas란?

**min.insync.replicas**는 Kafka에서 파티션의 리더와 팔로워 중 동기화(In-Sync) 상태를 유지해야 하는 최소 레플리카(replica) 개수를 지정하는 설정입니다.
이 값보다 적은 수의 레플리카만 동기화되어 있으면, 프로듀서의 쓰기 요청이 거부되고, 메시지가 저장되지 않습니다.

주요 개념 및 동작 방식

• ISR(In-Sync Replicas):
  리더와 팔로워 중, 최신 데이터를 모두 반영하고 있는 브로커 집합입니다.
• min.insync.replicas:
  ISR에 포함되어 있어야 하는 최소 레플리카 수(리더 포함)를 의미합니다.
• acks=all과의 연계:
  프로듀서가 acks=all로 메시지를 보낼 때, ISR의 개수가 min.insync.replicas 이상이어야만 메시지가 정상적으로 저장되고 ack가 반환됩니다123.

예시 시나리오

• replication.factor=3, min.insync.replicas=2
  • 세 개의 브로커(리더+팔로워2)가 모두 동기화 상태라면 정상 동작.
  • 브로커 하나가 장애로 ISR이 2개만 남아도, 메시지 쓰기는 계속 가능.
  • ISR이 1개(리더만 남음)로 줄어들면, 쓰기 요청이 거부되고 에러(NotEnoughReplicasException)가 발생123.

설정 목적 및 효과

• 데이터 내구성 보장
  최소한의 레플리카가 항상 최신 데이터를 보유하도록 강제해, 브로커 장애 시에도 데이터 손실을 방지합니다.
• 운영 권장값
  • 일반적으로 replication.factor=3, min.insync.replicas=2 조합을 많이 사용합니다.
  • 이 조합은 브로커 하나가 장애 나도 서비스가 중단되지 않으면서, 데이터 무손실을 보장할 수 있습니다13.

주의사항

• min.insync.replicas > ISR
  • ISR이 min.insync.replicas보다 적으면 쓰기 불가, 프로듀서에 에러 반환.
• replication.factor와의 관계
  • min.insync.replicas는 replication.factor 이하로 설정해야 하며, 너무 높게 설정하면 브로커 장애 시 전체 쓰기가 중단될 수 있습니다.
• acks=all과 함께 사용
  • 데이터 무손실 보장이 필요하다면 반드시 acks=all과 함께 사용해야 효과가 있습니다.

요약 표

설정 예시동작 및 효과

replication.factor=3 min.insync.replicas=2	브로커 1대 장애 시에도 쓰기 가능, 데이터 무손실 보장
replication.factor=3 min.insync.replicas=3	브로커 1대만 장애 나도 쓰기 불가(가용성 저하)
replication.factor=2 min.insync.replicas=2	브로커 1대 장애 시 쓰기 불가, 데이터 무손실 보장

 

정리
min.insync.replicas는 Kafka의 데이터 내구성과 무손실 보장을 위한 핵심 옵션입니다.
적절한 값으로 설정하면 장애 상황에서도 데이터 손실 없이 안정적으로 메시지를 처리할 수 있습니다123.

1. https://devlog-wjdrbs96.tistory.com/436
2. https://blog.2minutestreaming.com/p/kafka-acks-min-insync-replicas-explained
3. https://saay-hi.tistory.com/22
4. https://songhayoung.github.io/2020/07/13/kafka/acks-replicas/
5. https://learn.conduktor.io/kafka/kafka-topic-configuration-min-insync-replicas/
6. https://stackoverflow.com/questions/74921436/kafka-min-insync-replicas-replication-factor
7. https://bistros.tistory.com/152
8. https://xonmin.tistory.com/80
9. https://sungjk.github.io/2023/05/13/kafka-not-enough-replicas.html
10. https://kafka.apache.org/documentation/

 

[message.max.bytes 에 대해서 알려줘]

 

message.max.bytes는 **Kafka 브로커에서 허용하는 단일 메시지(혹은 레코드 배치)의 최대 크기(바이트 단위)**를 지정하는 설정입니다.
이 값보다 큰 메시지는 브로커에서 거부되어 저장되지 않습니다.

주요 특징

• 기본값: 약 1MB(1048588 bytes)178
• 설정 위치: 브로커(server.properties) 전체에 적용되며, 토픽별로 max.message.bytes로 별도 지정도 가능합니다14.
• 작동 방식: 프로듀서가 보낸 메시지(혹은 레코드 배치)가 이 값을 초과하면 브로커가 메시지를 거부하고 에러를 반환합니다125.
• 압축 사용 시: 압축이 적용된 경우, 압축 후 크기가 기준이 됩니다24.

연관 설정 및 주의점

컴포넌트관련 설정설명 및 주의사항

Producer	max.request.size	프로듀서가 한 번에 보낼 수 있는 최대 요청 크기(기본 1MB). 이 값도 함께 늘려야 함125.
Broker	message.max.bytes	브로커가 허용하는 최대 메시지 크기. 프로듀서의 max.request.size보다 크거나 같아야 함123.
Topic	max.message.bytes	특정 토픽에만 별도로 최대 메시지 크기를 지정할 수 있음14.
Consumer	fetch.max.bytes, max.partition.fetch.bytes	컨슈머가 한 번에 가져올 수 있는 최대 데이터 크기. 이 값도 충분히 커야 함169.

 

• 설정 불일치 시 문제:
  • Producer의 max.request.size < Broker의 message.max.bytes < Consumer의 fetch.max.bytes
  • 이 순서로 설정되어야 대용량 메시지 송수신이 원활합니다1236.

실무 적용 및 주의사항

• 대용량 메시지 사용 시:
  • 이미지, 대형 JSON 등 1MB를 초과하는 메시지를 쓸 경우, 위 모든 관련 설정을 동일하게 충분히 늘려줘야 합니다125.
• 네트워크 및 리소스 영향:
  • 메시지 크기가 커질수록 네트워크 지연, 브로커 및 컨슈머의 메모리 사용량, 장애 시 복구 시간 등이 증가할 수 있으니 주의가 필요합니다17.
• 오류 예시:
  • RecordTooLargeException 등 메시지 크기 초과 관련 에러가 발생할 수 있습니다5.

요약

• **message.max.bytes**는 Kafka 브로커가 허용하는 단일 메시지(혹은 레코드 배치)의 최대 크기입니다.
• 기본값은 약 1MB이며, 대용량 메시지 송수신 시 프로듀서, 브로커, 컨슈머의 관련 설정을 모두 일관성 있게 조정해야 합니다.
• 값이 맞지 않으면 메시지 전송 실패, 에러 발생 등 문제가 생길 수 있습니다12345789.

※ 이 값은 압축된 메시지의 크기를 기준으로 한다. 즉, 압축전 메시지가 이 값보다 크더라도 압축된 크기가 이 설정값보다 적다면, 메시지 전송이 여전히 가능하다.

 

1. https://always-kimkim.tistory.com/entry/kafka-operations-settings-concerned-when-the-message-has-more-than-1-mb
2. https://jiyun-dev.tistory.com/23
3. https://heodolf.tistory.com/11
4. https://dejavuhyo.github.io/posts/kafka-send-large-message/
5. https://programmer-eun.tistory.com/101
6. https://docs.redhat.com/ko/documentation/red_hat_streams_for_apache_kafka/2.7/html-single/kafka_configuration_tuning/index
7. https://data-engineer-tech.tistory.com/11
8. https://motti.tistory.com/entry/%EC%B9%B4%ED%94%84%EC%B9%B4Kafka-%ED%99%9C%EC%9A%A9%EC%A0%95%EB%A6%AC
9. https://any-ting.tistory.com/161