Apache Kafka 클라이언트에 권장되는 구성

Apache Kafka 클라이언트 애플리케이션에서 Azure Event Hubs를 사용하는 데 권장되는 구성은 다음과 같습니다.

Java 클라이언트 구성 속성

생산자 및 소비자 구성

속성 권장 값 허용 범위 참고
metadata.max.age.ms 180000(대략) < 240000 메타데이터 변경 내용을 더 빨리 선택하려면 더 낮출 수 있습니다.
connections.max.idle.ms 180000 < 240000 Azure에서 240,000밀리초 미만인 인바운드 TCP 유휴 상태를 닫습니다. 이로 인해 연결이 끊긴 상태에서 보낼 수 있습니다(전송 시간 제한으로 인해 만료된 일괄 처리로 표시됨).

생산자 구성만 해당

생산자 구성은 여기서 확인할 수 있습니다.

속성 권장 값 허용 범위 참고
max.request.size 1000000 < 1046528 1,046,528바이트보다 큰 요청을 보내는 경우, 서비스에서 연결을 닫습니다. 이 값은 변경해야 하며 처리량이 많은 생성 시나리오에서 문제가 발생할 수 있습니다.
retries > 0 delivery.timeout.ms 값을 늘려야 할 수 있습니다(문서 참조).
request.timeout.ms 30000 ~ 60000 > 20000 Event Hubs는 내부적으로 최소 20,000ms로 기본 설정됩니다. 시간 제한 값이 낮은 요청은 수락되지만 클라이언트 동작은 보장되지 않습니다.

request.timeout.ms가 권장 값인 60000 이상이고 session.timeout.ms가 권장 값인 30000 이상인지 확인합니다. 두 설정이 너무 낮으면 소비자 시간 초과로 인해 리밸런싱이 발생할 수 있습니다. 이로 인해 더 많은 시간 초과와 리밸런싱이 발생하게 됩니다.

metadata.max.idle.ms 180000 > 5000 생산자에서 유휴 토픽에 대한 메타데이터를 캐시하는 기간을 제어합니다. 토픽이 마지막으로 생성된 이후, 경과된 시간이 메타데이터 유휴 기간을 초과하는 경우, 토픽의 메타데이터가 잊혀지고 메타데이터의 다음 액세스에서 메타데이터 가져오기 요청이 강제로 수행됩니다.
linger.ms > 0 처리량이 높은 시나리오의 경우, 일괄 처리를 활용하려면 남은 값이 허용 가능한 가장 높은 값과 같아야 합니다.
delivery.timeout.ms (request.timeout.ms + linger.ms) * retries 식에 따라 설정합니다.
compression.type none 압축은 현재 지원되지 않습니다.

소비자 구성만 해당

소비자 구성은 여기서 확인할 수 있습니다.

속성 권장 값 허용 범위 참고
heartbeat.interval.ms 3000 3000은 기본값이며 변경하면 안 됩니다.
session.timeout.ms 30000 6000 ~ 300000 30000부터 시작하고, 누락된 하트비트로 인해 재조정이 자주 표시되는 경우 늘려줍니다.

request.timeout.ms가 권장 값 60000 이상이고 session.timeout.ms가 권장 값 30000 이상인지 확인합니다. 두 설정이 너무 낮으면 소비자 시간 초과로 인해 리밸런싱이 발생할 수 있습니다. 이로 인해 더 많은 시간 초과와 리밸런싱이 발생하게 됩니다.

max.poll.interval.ms 300000(기본값) >session.timeout.ms 리밸런스 시간 제한에 사용되므로 너무 낮게 설정하면 안 됩니다. session.timeout.ms보다 커야 합니다.

librdkafka 구성 속성

기본 librdkafka 구성 파일(링크)에는 아래 속성에 대한 확장 설명이 포함되어 있습니다.

생산자 및 소비자 구성

속성 권장 값 허용 범위 참고
socket.keepalive.enable true 유휴 연결로 예상되는 경우 필요합니다. Azure에서 240,000밀리초 미만인 인바운드 TCP 유휴 상태를 닫습니다.
metadata.max.age.ms ~ 180000 < 240000 메타데이터 변경 내용을 더 빨리 선택하려면 더 낮출 수 있습니다.

생산자 구성만 해당

속성 권장 값 허용 범위 참고
retries 2 기본값은 2147483647입니다.
request.timeout.ms 30000 ~ 60000 > 20000 Event Hubs는 내부적으로 최소 20,000ms로 기본 설정됩니다. librdkafka 기본값은 5000이며 문제가 될 수 있습니다. 시간 제한 값이 낮은 요청은 수락되지만 클라이언트 동작은 보장되지 않습니다.
partitioner consistent_random librdkafka 설명서 참조 consistent_random은 기본값이며 가장 좋습니다. 빈 키와 Null 키는 대부분의 경우 이상적으로 처리됩니다.
compression.codec none 압축은 현재 지원되지 않습니다.

소비자 구성만 해당

속성 권장 값 허용 범위 참고
heartbeat.interval.ms 3000 3000은 기본값이며 변경하면 안 됩니다.
session.timeout.ms 30000 6000 ~ 300000 30000부터 시작하고, 누락된 하트비트로 인해 재조정이 자주 표시되는 경우 늘려줍니다.
max.poll.interval.ms 300000(기본값) >session.timeout.ms 리밸런스 시간 제한에 사용되므로 너무 낮게 설정하면 안 됩니다. session.timeout.ms보다 커야 합니다.

추가 정보

일반적인 구성 관련 오류 시나리오는 다음 표를 참조하세요.

증상 문제 솔루션
재조정으로 인한 오프셋 커밋 오류 소비자가 poll() 호출 간에 너무 오래 대기하고, 서비스에서 그룹으로부터 소비자를 제거하고 있습니다. 여러 옵션이 있습니다.
  • 폴링 처리 시간 제한 증가(max.poll.interval.ms)
  • 처리 속도를 높이기 위해 메시지 일괄 처리 크기 감소
  • consumer.poll() 차단을 방지하기 위해 처리 병렬화 개선
세 가지 조합을 적용하는 것이 가장 좋을 수 있습니다.
높은 생성 처리량의 네트워크 예외 Java 클라이언트 + 기본 max.request.size를 사용하나요? 요청이 너무 클 수 있습니다. 위의 Java 구성을 참조하세요.

다음 단계

모든 Azure 서비스의 할당량 및 제한은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.