[BASIC #7] Config 구분 및 이해: 카프카 설정의 계층 구조 파악하기

1. 개요

카프카를 운영하다 보면 수많은 설정(Config) 값들을 마주치게 된다. 이 설정들을 제대로 이해하고 구분하는 것은 시스템의 성능과 안정성을 원하는 대로 제어하기 위한 첫걸음이다. 어떤 설정은 카프카 클러스터 전체에 영향을 미치는 반면, 어떤 설정은 특정 애플리케이션에만 국한되어 적용되기 때문이다. 이번 글에서는 카프카의 방대한 설정을 어떻게 구분하고 이해해야 하는지 그 기준을 알아보겠다.

---

2. Kafka Config의 두 가지 큰 축

2.1. (Broker/Topic) VS (Producer/Consumer)

카프카의 설정은 크게 서버(Broker/Topic) 레벨과 클라이언트(Producer/Consumer) 레벨로 나눌 수 있다. 이 둘의 관계를 은행에 비유하면 훨씬 쉽게 이해할 수 있다.

[1] 서버 설정 (Broker/Topic): "은행의 운영 규칙" 🏦

• 이는 카프카 클러스터 전체에 적용되는 글로벌 정책과 같다. 데이터 보관 기간(log.retention.ms), 파티션 복제본 수(default.replication.factor) 등이 여기에 해당한다. 모든 클라이언트에게 영향을 주며, 시스템의 안정성과 자원 사용량에 직접적인 연관이 있다. 주로 카프카 관리자나 인프라 담당자가 책임지는 영역이다.

[2] 클라이언트 설정 (Producer/Consumer): "개별 고객의 ATM 사용법" 🧑‍💻

• 이는 카프카에 접속하는 개별 애플리케이션에만 적용되는 로컬 정책이다. 프로듀서가 한 번에 보낼 메시지 묶음 크기(batch.size)나 컨슈머가 한 번에 가져올 메시지 수(max.poll.records) 등이 있다. 이 설정은 오직 해당 클라이언트의 성능과 동작에만 영향을 주며, 애플리케이션 개발자가 자신의 서비스 요구사항에 맞게 최적화해야 할 영역이다.

2.2. Config 적용 범위 상세

Config 구분	설명
Broker와 Topic 레벨 Config	• 카프카 서버에서 설정되는 Config이다. • server.properties 파일에 저장되는 Static Config(변경 시 브로커 재시작 필요)와, 재시작 없이 변경 가능한 Dynamic Config가 있다.
Producer와 Consumer 레벨 Config	• 카프카 클라이언트(애플리케이션 코드)에서 설정되는 Config이다. • 서버가 아닌 클라이언트 레벨에서 설정되므로 kafka-configs 명령어로 수정할 수 없으며, 클라이언트를 생성하는 시점에 코드 내에서 직접 설정한다.

---

3. Spring Framework에서의 Kafka Config 설정

실무에서 카프카를 사용할 때 많은 개발자들이 Spring Framework를 활용한다. Spring을 사용하면 설정 방식이 조금 달라지는데, 이를 이해하면 "어떤 설정을 어디에 해야 하는가?"에 대한 혼란이 줄어든다.

3.1. Broker/Topic 레벨 설정: 인프라 영역

브로커와 토픽 레벨의 설정은 여전히 카프카 서버 자체에서 관리한다. 이는 스프링 애플리케이션과 무관하게 클러스터를 운영하는 인프라 담당자의 영역이다.

• server.properties 파일 수정
• kafka-configs.sh 명령어를 통한 동적 설정 변경
• 토픽 생성 시 -config 옵션으로 토픽 레벨 설정 지정

예를 들어 토픽의 데이터 보관 기간을 7일로 설정하는 것은 인프라 담당자가 클러스터에 설정하는 일이며, 개별 스프링 애플리케이션이 관여할 부분이 아니다.

3.2. Producer/Consumer 레벨 설정: 애플리케이션 영역

프로듀서와 컨슈머 설정은 스프링 애플리케이션 내에서 처리한다. 여기서 두 가지 방식이 존재한다.

3.2.1. Java Properties 방식 (순수 Java 클라이언트)

Properties props = new Properties();
props.setProperty(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.setProperty(ProducerConfig.BATCH_SIZE_CONFIG, "16384");  // 클라이언트 레벨 설정

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

3.2.2. Spring Boot 방식: application.yml과 @Configuration

Spring Boot에서는 application.yml(또는 application.properties)에 설정을 정의하고, 스프링이 자동으로 KafkaTemplate이나 KafkaListenerContainerFactory를 생성해주는 방식을 사용한다.

application.yml 예시:

spring:
  kafka:
    bootstrap-servers: localhost:9092
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
      batch-size: 16384  # 프로듀서 배치 크기
      acks: all          # 프로듀서 ACKS 설정
    consumer:
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      group-id: my-group
      max-poll-records: 500  # 한 번에 가져올 최대 레코드 수

KafkaConfig 클래스 예시 (세밀한 제어가 필요할 때):

@Configuration
public class KafkaProducerConfig {

    @Value("${spring.kafka.bootstrap-servers}")
    private String bootstrapServers;

    @Bean
    public ProducerFactory<String, String> producerFactory() {
        Map<String, Object> configProps = new HashMap<>();
        configProps.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        configProps.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        configProps.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        configProps.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
        configProps.put(ProducerConfig.LINGER_MS_CONFIG, 100);
        configProps.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, "snappy");
        return new DefaultKafkaProducerFactory<>(configProps);
    }

    @Bean
    public KafkaTemplate<String, String> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }
}

3.3. Spring에서의 설정 계층 정리

설정 유형	설정 위치	담당자	예시
Broker 레벨	server.properties / kafka-configs.sh	인프라 담당자	log.retention.ms, num.partitions
Topic 레벨	kafka-topics.sh --config	인프라 담당자	retention.ms, max.message.bytes
Producer 레벨	application.yml의 spring.kafka.producer 또는 @Configuration	애플리케이션 개발자	batch.size, linger.ms, acks
Consumer 레벨	application.yml의 spring.kafka.consumer 또는 @Configuration	애플리케이션 개발자	max.poll.records, enable.auto.commit

정리하자면, Spring 기반 애플리케이션을 개발할 때 개발자가 신경 써야 할 Kafka 설정은 대부분 Producer와 Consumer 레벨의 클라이언트 설정이다. 브로커와 토픽 레벨의 설정은 이미 인프라 팀에 의해 적절히 구성되어 있다고 가정하고, 개발자는 자신의 애플리케이션 요구사항(메시지 손실 허용 수준, 처리량, 지연 시간 등)에 맞춰 클라이언트 설정을 application.yml이나 @Configuration 클래스에 정의하면 된다.

---

4. Kafka-configs: 서버 설정의 동적 관리

과거에는 서버 설정을 변경하려면 반드시 브로커를 재시작해야 했다. 하지만 이제 Dynamic Config에 해당하는 설정들은 kafka-configs.sh 스크립트를 통해 서비스 중단 없이 동적으로 확인하고 변경할 수 있다. (이 부분은 인프라 담당자의 영역이다.)

4.1. kafka-configs 명령어 사용법

구분	사용법
Config 값 확인	kafka-configs --bootstrap-server [host:port] --entity-type [brokers/topics] --entity-name [id/name] --all --describe
Config 값 설정	kafka-configs --bootstrap-server [host:port] --entity-type [brokers/topics] --entity-name [id/name] --alter --add-config prop=value
Config 값 Unset	kafka-configs --bootstrap-server [host:port] --entity-type [brokers/topics] --entity-name [id/name] --alter --delete-config prop

 

5. 요약: Config 이해가 주는 이점

Config의 적용 범위를 명확히 이해하면 다음과 같은 이점을 얻을 수 있다.

• 명확한 책임 소재: 문제 발생 시 원인이 서버 정책에 있는지, 개별 클라이언트의 로직에 있는지 빠르게 파악하고 담당자가 대응할 수 있다.
• 효율적인 성능 튜닝: 특정 애플리케이션의 처리량을 높이고 싶다면 해당 클라이언트의 설정을 최적화하고, 클러스터 전체의 안정성을 높이려면 서버 설정을 조정하는 등 목적에 맞는 접근이 가능하다.
• 안정적인 시스템 운영: 서버 설정이 시스템 전체에 미치는 영향을 이해함으로써, 무분별한 변경으로 인한 클러스터 전체의 장애를 예방할 수 있다.

결론적으로, 카프카 Config의 계층 구조를 이해하는 것은 단순히 기능을 아는 것을 넘어, 시스템을 안정적이고 효율적으로 운영하기 위한 필수적인 역량이라 할 수 있다. 특히 Spring 개발자라면 "어떤 설정은 인프라에 맡기고, 어떤 설정은 내 애플리케이션 코드에서 관리해야 하는가"를 명확히 구분하는 능력이 중요하다.

---

6. 실습

6.1. 실습 [1]: kafka-configs 명령어로 파라미터 조회 및 수정

[1] broker 0번의 config 설정 확인

kafka-configs --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --all --describe

[2] topic의 config 설정 확인

kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name multipart-topic --all --describe

[3] topic의 config 설정 변경 (max.message.bytes 추가)

kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name multipart-topic --alter \\
--add-config max.message.bytes=2088000

[4] 변경한 topic의 config를 다시 기본값으로 원복

kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name multipart-topic --alter \\
--delete-config max.message.bytes

6.2. 실습 [2]: kafka-dump-log 명령어로 로그 파일 내부 살펴보기

kafka-dump-log 명령어 실행

kafka-dump-log --deep-iteration --files /home/min/data/kafka-logs/multipart-topic-0/00000000000000000000.log --print-data-log