setting kafka consumer
fetch.min.bytes
fetch.min.bytes는 소비자가 서버에서 데이터를 가져올 때 한 번에 수신하려는 최소 데이터 크기(바이트 단위)를 정의하는 설정입니다.
즉, 이 값보다 적은 데이터를 서버로부터 받지 않겠다는 의미입니다. Kafka는 소비자가 요청한 최소 데이터 크기만큼의 데이터를 준비할 때까지 기다렸다가 데이터를 전송합니다.
이 값을 크게 설정하면, 소비자는 한 번에 많은 데이터를 받아 네트워크 요청 횟수를 줄일 수 있습니다. 하지만, 기다리는 동안 데이터가 적게 도착하면 지연이 발생할 수 있습니다.
사용 사례:
고성능 또는 대량 데이터 처리가 필요한 경우 이 값을 크게 설정하여 네트워크 효율을 높일 수 있습니다. 반대로 지연을 최소화하려면 이 값을 작게 설정하여 즉시 가능한 데이터를 가져올 수 있습니다.
기본값: 1 byte
1 byte. 소비자는 기본적으로 한 번의 요청에서 1 바이트 이상의 데이터를 가져오며, 그 이하로는 기다리지 않습니다.
fetch.max.wait.ms
fetch.max.wait.ms는 소비자가 서버에서 데이터를 요청한 후, 응답을 기다릴 수 있는 최대 시간(밀리초)을 설정합니다.
소비자가 데이터를 요청했을 때, 서버는 fetch.min.bytes로 설정한 최소 데이터 크기를 맞추기 위해 필요한 시간이 있으면 기다립니다. 만약 이 시간이 fetch.max.wait.ms보다 길어지면, 최소 크기에 상관없이 서버는 현재 가능한 데이터를 즉시 전송합니다.
이 설정은 최소 데이터를 수신하기 위해 기다리는 시간을 제한하며, 데이터가 부족한 상황에서도 응답이 늦어지지 않도록 보장합니다.
사용 사례:
지연을 줄이기 위해서 이 값을 줄여 서버가 데이터를 빠르게 반환하도록 하거나, 효율적인 네트워크 사용을 위해서 이 값을 늘려 더 많은 데이터를 한꺼번에 수신할 수 있도록 합니다.
기본값: 500 ms
500 ms. 서버는 기본적으로 소비자가 요청한 데이터를 최대 500ms 동안 기다렸다가 fetch.min.bytes 기준을 충족하지 못해도 현재 가능한 데이터를 응답합니다.
fetch.min.bytes와 fetch.max.wait.ms의 관계:
fetch.min.bytes는 소비자가 수신하고자 하는 최소 데이터 크기를 정의하고, fetch.max.wait.ms는 그 데이터를 준비하는 데 서버가 기다릴 수 있는 최대 시간을 설정합니다.
서버는 소비자가 요청한 최소 크기의 데이터를 준비하기 위해 기다리지만, 이 시간이 fetch.max.wait.ms를 넘지 않도록 보장합니다. 예시: 소비자가 100KB의 데이터를 fetch.min.bytes로 요청했지만, 서버가 500ms 동안 그만큼의 데이터를 수집하지 못하면, 현재 가능한 데이터 크기와 상관없이 500ms 뒤에 데이터를 전송하게 됩니다.
이 두 설정은 지연(latency)과 처리량(throughput) 간의 균형을 조절하는 데 사용됩니다.
max.in.flight.requests.per.connection
Kafka 프로듀서의 max.in.flight.requests.per.connection 속성은 프로듀서가 브로커에 한 번에 보낼 수 있는, 아직 응답(ACK)을 받지 못한 요청(즉, 메시지 또는 메시지 배치)의 최대 개수를 제어합니다.
기본값: 5
목적: 이 속성은 프로듀서가 브로커로 보낸 후 아직 ACK를 받지 않은 “인플라이트(in-flight)” 메시지의 개수를 조절합니다. 프로듀서는 메시지를 배치로 브로커에 보내며, 브로커가 해당 배치를 성공적으로 받으면 ACK(확인 응답)를 보냅니다.
동작:
이 값을 너무 낮게 설정하면(예: 1), 프로듀서는 한 번에 하나의 배치만 전송할 수 있고, ACK를 받기 전까지는 다른 배치를 전송할 수 없습니다. 이는 성능 저하로 이어질 수 있습니다. 반대로 이 값을 너무 높게 설정하면(예: 5 이상), 프로듀서는 더 많은 메시지를 동시에 보낼 수 있어 처리량을 향상시킬 수 있지만, 재시도(retry)가 발생할 때 메시지의 순서가 뒤바뀔 가능성이 커집니다(특히 retries가 설정된 경우). 메시지 순서 뒤바뀜 가능성:
여러 개의 요청이 응답을 기다리는 동안, 초기 요청 중 하나가 실패하여 재시도되는 경우, 이미 ACK를 받은 후속 메시지가 있을 수 있습니다. 이때 재시도가 발생하면 초기 메시지가 나중에 전달되어 순서가 뒤바뀔 수 있습니다. 사용 예시:
엄격한 메시지 순서 보장이 필요한 애플리케이션(특히 retries가 설정된 경우)에서는 이 값을 1로 설정하여 메시지가 순차적으로 전송 및 응답되도록 해야 하며, 이는 순서 뒤바뀜을 방지합니다. 반면, 약간의 메시지 순서 변경이 큰 문제가 되지 않고 성능이 중요한 애플리케이션에서는 기본값(5)을 사용하거나 더 큰 값을 설정하여 성능을 향상시킬 수 있습니다.
max.block.ms
기본값: 60000 (밀리초, 즉 60초) 상세 설명: 목적: max.block.ms는 Kafka 프로듀서가 내부 버퍼가 가득 차거나 메타데이터를 수집하는 데 시간이 오래 걸릴 때, 프로듀서가 메시지를 전송하기 전에 최대 대기할 수 있는 시간을 설정합니다.
동작:
프로듀서는 내부적으로 데이터를 임시로 저장할 수 있는 버퍼(buffer.memory)를 사용합니다. 이 버퍼가 꽉 차면 추가로 전송하려는 메시지는 버퍼가 비워질 때까지 대기해야 합니다. max.block.ms는 이 대기 시간의 한도를 설정하는 값입니다. 즉, 프로듀서가 버퍼에 공간이 없어 더 이상 메시지를 저장하지 못하는 상황에서, 지정된 시간(max.block.ms) 내에 버퍼가 비워지지 않으면, 프로듀서는 TimeoutException을 발생시킵니다. 사용 예시:
이 속성은 고성능 애플리케이션에서 중요한데, 프로듀서가 지정된 시간 내에 버퍼에 공간을 확보하지 못하면, 애플리케이션의 흐름을 방해하지 않고 타임아웃을 발생시키도록 할 수 있습니다. 너무 짧게 설정하면 자주 타임아웃이 발생할 수 있으며, 너무 길게 설정하면 시스템이 응답 없이 대기하는 시간이 늘어날 수 있습니다.
buffer.memory
buffer.memory는 Kafka 프로듀서가 전송할 메시지를 일시적으로 저장하는 내부 메모리 버퍼의 크기를 설정하는 속성입니다.
기본값: 32MB (33554432 바이트)
동작:
프로듀서는 메시지를 즉시 전송하지 않고, 메시지들을 버퍼에 쌓아 적절한 크기 또는 시간이 되었을 때 한꺼번에 전송합니다. 이렇게 하면 네트워크 전송 효율을 높일 수 있습니다.
buffer.memory는 이 버퍼의 최대 크기를 지정합니다. 만약 프로듀서가 버퍼에 더 이상 메시지를 저장할 수 없을 정도로 꽉 차면, 메시지를 전송하기 전까지 프로듀서는 블록(block)됩니다.
이때 블록되는 시간이 max.block.ms로 제어되며, 해당 시간이 지나면 타임아웃이 발생합니다.
사용 예시:
메모리와 네트워크 대역폭이 넉넉한 환경에서는 buffer.memory 값을 크게 설정하여 한 번에 더 많은 메시지를 전송할 수 있습니다. 하지만 이 값을 너무 크게 설정하면 메모리 사용량이 증가할 수 있으며, 시스템에 따라 메모리 부족 문제가 발생할 수 있습니다. 반면, 이 값을 너무 작게 설정하면 버퍼가 빨리 차서 프로듀서가 자주 대기 상태에 빠질 수 있습니다.
max.poll.interval.ms
기본값: 300000 (밀리초, 즉 5분)
상세 설명: 목적: max.poll.interval.ms는 Kafka 컨슈머가 메시지를 가져오고 처리하는 데 걸리는 최대 시간을 설정하는 속성입니다. 즉, 컨슈머가 메시지를 성공적으로 가져오기 전까지 다음 poll() 호출 간 최대 허용 시간입니다.
동작:
컨슈머는 poll() 메서드를 호출하여 Kafka로부터 메시지를 가져옵니다. 이 속성은 poll() 호출 간격이 너무 길어지지 않도록 제한하는 역할을 합니다. 만약 컨슈머가 max.poll.interval.ms 내에 poll()을 호출하지 않으면, Kafka는 해당 컨슈머가 느리거나 비정상적으로 동작한다고 판단하고, 컨슈머 그룹에서 제거합니다. 이는 Consumer Group Rebalancing을 촉발할 수 있습니다.
사용 예시:
메시지 처리 시간이 오래 걸리는 애플리케이션의 경우, 이 값을 충분히 크게 설정하여 처리 도중 타임아웃이 발생하지 않도록 해야 합니다. 예를 들어, 대량의 데이터를 처리하거나 복잡한 비즈니스 로직을 수행하는 경우, 기본값(5분)보다 더 길게 설정할 수 있습니다. 하지만 이 값을 너무 길게 설정하면, 컨슈머가 중단되거나 응답이 없을 때 빠르게 감지하기 어렵습니다.
max.poll.records
기본값: 500
목적: max.poll.records는 한 번의 poll() 호출로 가져올 수 있는 최대 레코드(메시지)의 수를 설정하는 속성입니다.
동작:
컨슈머는 poll() 메서드를 사용하여 Kafka로부터 메시지 배치를 가져옵니다. 이때 한 번에 가져올 메시지의 수를 제한하여, 메시지 처리 성능과 메모리 사용을 최적화할 수 있습니다.
이 값을 낮게 설정하면, 한 번에 적은 수의 메시지를 가져오므로 메시지 처리가 더 자주 이루어집니다. 반면, 이 값을 크게 설정하면, 한 번에 많은 메시지를 가져와 처리 빈도는 줄어들지만, 처리 시간이 더 길어질 수 있습니다.
사용 예시:
만약 메시지 처리가 가볍고 빠르게 이루어질 수 있는 경우, max.poll.records 값을 크게 설정하여 한 번에 많은 메시지를 처리할 수 있습니다. 반면, 각 메시지 처리가 복잡하고 시간이 오래 걸리는 경우, 값을 작게 설정하여 한 번에 적은 수의 메시지를 가져와 처리 시간을 분배할 수 있습니다.
요약 max.poll.interval.ms: 컨슈머가 메시지를 가져오기 위해 poll()을 호출하는 간격의 최대 시간을 설정합니다. 기본값은 5분. max.poll.records: 한 번의 poll() 호출로 가져올 수 있는 메시지의 최대 개수를 설정합니다. 기본값은 500개. 이 두 속성은 컨슈머의 메시지 처리 성능과 효율성에 큰 영향을 미치므로, 애플리케이션의 요구 사항에 맞게 적절히 설정해야 합니다.
Kafka 컨슈머의 client.rack 속성은 메시지를 가져오는 브로커의 위치를 기반으로 데이터를 효율적으로 처리하는 데 중요한 역할을 합니다.
client.rack
기본값: 없음 (명시적으로 설정되지 않으면 기본적으로 비어 있습니다)
목적: client.rack은 Kafka 클러스터의 rack-awareness 기능을 활용하기 위해 사용되는 속성입니다. 이 속성은 컨슈머가 속해 있는 데이터 센터나 랙(rack)의 위치를 정의하며, 이를 통해 Kafka는 컨슈머와 가까운 브로커로부터 데이터를 우선적으로 가져올 수 있도록 최적화합니다.
동작:
Kafka 클러스터는 종종 여러 데이터 센터나 여러 랙에 분산되어 있습니다. client.rack을 설정하면, Kafka는 해당 컨슈머가 속한 랙 또는 데이터 센터에 더 가까운 복제본(replica)으로부터 데이터를 가져오도록 하여, 네트워크 대역폭을 줄이고 지연 시간을 최소화할 수 있습니다.
예를 들어, 만약 컨슈머가 특정 데이터 센터에 위치해 있고, 해당 데이터 센터에 있는 브로커에서 데이터를 읽는 것이 더 빠르다면, client.rack을 설정하면 Kafka가 그 브로커의 리더 또는 팔로워로부터 데이터를 읽도록 조정합니다.
이점:
성능 향상: 컨슈머가 가까운 위치의 브로커로부터 데이터를 읽음으로써, 데이터 전송 지연(latency)과 네트워크 비용을 줄일 수 있습니다.
안정성: 데이터 센터 간 장애가 발생하더라도, client.rack을 설정해 놓으면 다른 데이터 센터에 있는 브로커로부터 데이터를 가져오는 대신, 같은 데이터 센터 내에서 안정적으로 데이터를 가져올 수 있습니다.
사용 예시:
여러 데이터 센터에 분산된 Kafka 클러스터에서 사용되며, 각 컨슈머가 특정 데이터 센터 또는 랙에 배치된 경우, 그 위치를 client.rack으로 설정하여 최적의 데이터 처리 성능을 얻을 수 있습니다. 예를 들어, 만약 컨슈머가 동부 데이터 센터에 위치해 있고, Kafka 브로커 복제본도 해당 데이터 센터에 존재한다면, client.rack을 “us-east”로 설정하여 컨슈머가 가까운 복제본으로부터 데이터를 읽을 수 있게 할 수 있습니다.
요약
client.rack: 컨슈머가 위치한 데이터 센터 또는 랙의 위치를 정의하는 속성으로, Kafka가 더 가까운 브로커 복제본으로부터 데이터를 가져오도록 최적화합니다. 기본값은 없으며, 명시적으로 설정해야 합니다.
이 설정을 통해 네트워크 비용을 줄이고, 데이터 전송의 지연 시간을 줄여 성능을 최적화할 수 있습니다. 특히, 대규모 클러스터나 멀티 데이터 센터 환경에서 매우 유용합니다.
댓글남기기