효율적인 Kafka 일괄 처리 전략을 위한 모범 사례

Apache Kafka는 높은 처리량을 가진 분산 이벤트 스트리밍 플랫폼으로, 종종 최신 데이터 아키텍처의 근간을 이룹니다. Kafka 자체는 본질적으로 빠르지만, 특히 대량 시나리오에서 최대 효율성을 달성하려면 클라이언트 구성을 신중하게 조정해야 합니다. 성능 최적화의 핵심 영역은 일괄 처리(batching), 즉 여러 레코드를 단일 네트워크 요청으로 그룹화하는 관행입니다. 프로듀서 및 컨슈머 일괄 처리를 올바르게 구성하면 네트워크 오버헤드가 크게 줄고, I/O 작업이 감소하며, 처리량이 극대화됩니다. 이 가이드에서는 Kafka 프로듀서와 컨슈머 모두에 대한 효율적인 일괄 처리 전략 구현을 위한 모범 사례를 살펴봅니다.

Kafka 일괄 처리 및 오버헤드 이해하기

Kafka에서는 TCP/IP를 통해 데이터 전송이 이루어집니다. 레코드를 하나씩 보내면 각 요청에 대한 TCP 승인, 네트워크 지연 및 직렬화 및 요청 프레이밍을 위한 CPU 사용량 증가와 관련된 상당한 오버헤드가 발생합니다. 일괄 처리는 레코드를 로컬에서 누적한 다음 더 크고 연속적인 단위로 전송하여 이 오버헤드를 완화합니다. 이는 네트워크 활용도를 획기적으로 개선하고 동일한 양의 데이터를 처리하는 데 필요한 네트워크 왕복 횟수를 줄입니다.

프로듀서 일괄 처리: 전송 효율성 극대화

프로듀서 일괄 처리는 성능 튜닝에서 가장 큰 영향을 미치는 영역이라고 할 수 있습니다. 목표는 배치 크기가 네트워크 비용을 상쇄할 만큼 충분히 크면서도 허용할 수 없는 엔드투엔드 지연 시간을 유발할 만큼 너무 크지 않은 지점을 찾는 것입니다.

주요 프로듀서 구성 매개변수

여러 중요 설정이 프로듀서가 배치를 생성하고 전송하는 방식을 결정합니다:

batch.size: 이는 보류 중인 레코드에 대한 프로듀서의 인메모리 버퍼의 최대 크기를 바이트 단위로 정의합니다. 이 임계값에 도달하면 배치가 전송됩니다.
- 모범 사례: 기본값(16KB)을 두 배로 늘린 후 점진적으로 테스트를 시작하고, 레코드 크기 및 지연 시간 허용 범위에 따라 64KB에서 1MB 사이의 크기를 목표로 합니다.
linger.ms: 이 설정은 새로운 레코드가 도착한 후 버퍼를 채우기 위해 프로듀서가 대기하는 시간(밀리초)을 지정하며, 불완전한 배치를 전송하기 전에 대기합니다.
- 상충 관계: linger.ms가 높으면 배치 크기가 증가하여 처리량은 향상되지만 개별 메시지의 지연 시간도 증가합니다.
- 모범 사례: 최대 처리량을 위해서는 이 값을 더 높게 설정할 수 있습니다(예: 5-20ms). 낮은 지연 시간이 필요한 애플리케이션의 경우, 이 값을 0에 가깝게 매우 낮게 유지하고 더 작은 배치를 수용합니다.
buffer.memory: 이 구성은 단일 프로듀서 인스턴스에 대해 전송되지 않은 레코드를 모든 토픽과 파티션에 대해 버퍼링하는 데 할당된 총 메모리를 설정합니다. 버퍼가 가득 차면 후속 send() 호출은 차단됩니다.
- 모범 사례: 이 값이 피크 버스트를 편안하게 수용할 수 있을 만큼 충분히 큰지 확인해야 하며, 종종 여러 배치가 인플라이트 상태에 있도록 예상되는 batch.size보다 몇 배 더 커야 합니다.

프로듀서 일괄 처리 예시 구성 (Java)

Properties props = new Properties();
props.put("bootstrap.servers", "kafka-broker:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

// 성능 튜닝 매개변수
props.put("linger.ms", 10); // 레코드를 더 기다리기 위해 최대 10ms 대기
props.put("batch.size", 65536); // 64KB 배치 크기 목표
props.put("buffer.memory", 33554432); // 32MB 총 버퍼 공간

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

컨슈머 일괄 처리: 효율적인 가져오기 및 처리

프로듀서 일괄 처리가 효율적인 전송에 중점을 두는 반면, 컨슈머 일괄 처리는 수신 및 처리 워크로드를 최적화합니다. 컨슈머는 파티션에서 데이터를 일괄적으로 가져오며, 이를 최적화하면 브로커로의 네트워크 호출 빈도가 줄어들고 애플리케이션 스레드에 필요한 컨텍스트 전환 횟수가 제한됩니다.

주요 컨슈머 구성 매개변수

fetch.min.bytes: 이는 단일 페치 요청에서 브로커가 반환해야 하는 최소 데이터 양(바이트)입니다. 브로커는 최소한 이 정도의 데이터가 준비되거나 fetch.max.wait.ms 타임아웃에 도달할 때까지 응답을 지연합니다.
- 이점: 이는 컨슈머가 더 큰 데이터 덩어리를 요청하도록 강제하며, 프로듀서 일괄 처리와 유사합니다.
- 모범 사례: 네트워크 활용도가 주된 관심사이고 처리 지연 시간이 부차적인 경우, 이 값을 기본값보다 훨씬 높게(예: 1MB 이상) 설정합니다.
fetch.max.bytes: 이는 컨슈머가 단일 페치 요청에서 수락할 최대 데이터 양(바이트)을 설정합니다. 이는 컨슈머의 내부 버퍼가 과부하되는 것을 방지하기 위한 상한 역할을 합니다.
max.poll.records: 이는 애플리케이션 처리량에 매우 중요합니다. 단일 consumer.poll() 호출에서 반환되는 최대 레코드 수를 제어합니다.
- 맥락: 컨슈머 애플리케이션에서 레코드를 루프 내에서 처리할 때, 이 설정은 폴링 루프의 단일 반복 동안 처리되는 작업 범위를 제한합니다.
- 모범 사례: 파티션이 많고 볼륨이 높은 경우, 이 값을 늘리면(예: 500에서 1000 이상으로) 컨슈머 스레드가 다시 poll()을 호출하기 전에 폴 주기당 더 많은 데이터를 처리할 수 있어 폴링 오버헤드가 줄어듭니다.

컨슈머 폴링 루프 예시

레코드를 처리할 때 재조정(rebalance)에 신속하게 대응할 수 있는 능력과 폴당 달성된 작업량 사이의 균형을 유지하기 위해 max.poll.records를 존중해야 합니다.

while (running) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));

    // max.poll.records가 1000으로 설정된 경우, 이 루프는 최대 1000회 실행됩니다
    for (ConsumerRecord<String, String> record : records) {
        process(record);
    }
    // 처리 후 오프셋 커밋
    consumer.commitSync();
}

max.poll.records에 대한 경고: 이 값을 너무 높게 설정하면 컨슈머 재조정 중에 문제가 발생할 수 있습니다. 재조정이 발생하면 컨슈머는 그룹을 성공적으로 떠나기 전에 현재 poll()에서 얻은 모든 레코드를 처리해야 합니다. 배치가 지나치게 크면 세션 시간 초과가 길어지고 불필요한 그룹 불안정성을 초래할 수 있습니다.

고급 일괄 처리 고려 사항

일괄 처리 최적화는 특정 작업 부하 특성(레코드 크기, 처리량 목표 및 허용 가능한 지연 시간)에 따라 반복적인 프로세스입니다.

1. 레코드 크기 변동

메시지 크기가 매우 다양한 경우 고정된 batch.size는 크기 제한을 기다리느라 너무 많은 소규모 배치가 조기에 전송되거나, 버퍼링된 매우 큰 메시지로 인해 네트워크 용량을 초과하는 매우 큰 배치가 생성될 수 있습니다.

팁: 메시지가 일관되게 큰 경우, 단일 대용량 메시지가 전송 버퍼의 상당 부분을 점유하는 것을 방지하기 위해 linger.ms를 약간 줄여야 할 수 있습니다.

2. 압축

일괄 처리와 압축은 시너지 효과를 냅니다. 대규모 배치를 전송 전에 압축하는 것이 작고 개별적인 메시지를 압축하는 것보다 훨씬 더 나은 압축률을 제공합니다. 항상 효율적인 일괄 처리 설정과 함께 압축(예: snappy 또는 lz4)을 활성화하십시오.

3. 속성 기반(Idempotence) 및 재시도

엄격하게 일괄 처리와 관련되지는 않지만, enable.idempotence=true를 보장하는 것이 중요합니다. 큰 배치를 보낼 때, 일시적인 네트워크 오류가 레코드 하위 집합에 영향을 미칠 가능성이 증가합니다. 속성 기반 처리는 일시적인 실패로 인해 프로듀서가 배치를 다시 시도하더라도 Kafka가 메시지를 중복 없이 처리하여 성공적인 전달 시 중복을 방지합니다.

일괄 처리 최적화 목표 요약

구성	목표	처리량에 미치는 영향	지연 시간에 미치는 영향
프로듀서 `batch.size`	요청당 최대 데이터	큰 증가	중간 증가
프로듀서 `linger.ms`	충만함을 위해 잠시 대기	큰 증가	중간 증가
컨슈머 `fetch.min.bytes`	더 큰 청크 요청	중간 증가	중간 증가
컨슈머 `max.poll.records`	폴링 오버헤드 감소	중간 증가	최소한의 변화

프로듀서 설정(batch.size 대 linger.ms)을 신중하게 균형 조정하고 컨슈머 페칭 매개변수(fetch.min.bytes 및 max.poll.records)를 조정함으로써 네트워크 오버헤드를 크게 최소화하고 Kafka 클러스터를 최대 지속 가능한 처리량 용량에 가깝게 끌어올릴 수 있습니다.