Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

RHEL에서 AMQ Streams 사용

Red Hat AMQ Streams 2.0

Red Hat Enterprise Linux에서 AMQ Streams 2.0 배포 구성 및 관리

초록

대규모 메시징 네트워크를 빌드하도록 AMQ Streams와 함께 배포된 operator 및 Kafka 구성 요소를 구성합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체
링크 복사

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. AMQ Streams 개요
링크 복사

Red Hat AMQ Streams는 Apache Zoo Cryostat 및 Apache Kafka 프로젝트를 기반으로 하는 대규모 확장 가능하고 분산된 고성능 데이터 스트리밍 플랫폼입니다.

주요 구성 요소는 다음과 같습니다.

Kafka 브로커

클라이언트 생성에서 클라이언트 사용으로 레코드 전달을 담당하는 메시징 브로커입니다.

Apache Zoo Cryostat는 Kafka의 핵심 종속성으로, 고도의 안정적인 분산 조정을 위한 클러스터 조정 서비스를 제공합니다.

Kafka Streams API
스트림 프로세서 애플리케이션 작성을 위한 API입니다.
생산자 및 소비자 API
Kafka 브로커 간에 메시지를 생성하고 사용하기 위한 Java 기반 API입니다.
Kafka Bridge
AMQ Streams Kafka Bridge는 HTTP 기반 클라이언트가 Kafka 클러스터와 상호 작용할 수 있는 RESTful 인터페이스를 제공합니다.
Kafka Connect
Connector 플러그인을 사용하여 Kafka 브로커와 기타 시스템 간에 데이터를 스트리밍하는 툴킷입니다.
Kafka MirrorMaker
데이터 센터 내 또는 여러 개의 Kafka 클러스터 간에 데이터를 복제합니다.
Kafka Exporter
모니터링을 위해 Kafka 메트릭 데이터 추출에 사용되는 내보내기입니다.

Kafka 브로커의 클러스터는 이러한 모든 구성 요소를 연결하는 허브입니다. 브로커는 구성 데이터를 저장하고 클러스터 조정을 위해 Apache Zoo Cryostat를 사용합니다. Apache Kafka를 실행하기 전에 Apache Zoo Cryostat 클러스터를 준비해야 합니다.

그림 1.1. AMQ Streams 아키텍처

AMQ Streams 아키텍처
View larger image
AMQ Streams 아키텍처

1.1. Kafka 기능
링크 복사

Kafka의 기본 데이터 스트림 처리 기능 및 구성 요소 아키텍처는 다음을 제공할 수 있습니다.

  • 매우 높은 처리량과 짧은 대기 시간으로 데이터를 공유하는 마이크로서비스 및 기타 애플리케이션
  • 메시지 순서 확인
  • 데이터 스토리지에서 메시지 되감/ 재생을 통해 애플리케이션 상태 재구성
  • 키-값 로그를 사용할 때 이전 레코드를 제거하기 위한 메시지 압축
  • 클러스터 구성의 수평 확장성
  • 내결함성을 제어하기 위한 데이터 복제
  • 즉시 액세스할 수 있도록 대량의 데이터 보존

1.2. Kafka 사용 사례
링크 복사

Kafka의 기능은 다음에 적합합니다.

  • 이벤트 중심 아키텍처
  • 이벤트 로그로 애플리케이션 상태에 대한 변경 사항을 캡처하는 이벤트 소싱
  • 메시지 브로커링
  • 웹사이트 활동 추적
  • 메트릭을 통한 운영 모니터링
  • 로그 수집 및 집계
  • 분산 시스템의 커밋 로그
  • 애플리케이션이 데이터에 실시간으로 응답할 수 있도록 스트림 처리

1.3. 지원되는 구성
링크 복사

지원되는 구성에서 실행하려면 AMQ Streams가 지원되는 운영 체제의 JVM 버전에서 실행되어야 합니다.

자세한 내용은 Red Hat Streams for Apache Kafka 지원 구성을 참조하십시오.

1.4. 문서 규칙
링크 복사

교체 가능

이 문서에서 교체 가능한 텍스트는 monospace에서 italics , 대문자 및 하이픈으로 스타일을 지정할 수 있습니다.

예를 들어 다음 코드에서 BOOTSTRAP-ADDRESS 및 CryostatIC -NAME을 고유한 주소 및 주제 이름으로 교체하려고 합니다. 

bin/kafka-console-consumer.sh --bootstrap-server BOOTSTRAP-ADDRESS --topic TOPIC-NAME --from-beginning
Copy to Clipboard Toggle word wrap

2장. 시작하기
링크 복사

2.1. AMQ Streams 배포
링크 복사

AMQ Streams는 단일 ZIP 파일로 배포됩니다. 이 ZIP 파일에는 AMQ Streams 구성 요소가 포함되어 있습니다.

2.2. AMQ Streams 아카이브 다운로드
링크 복사

AMQ Streams의 아카이브 배포는 Red Hat 웹 사이트에서 다운로드할 수 있습니다. 아래 단계에 따라 배포 사본을 다운로드할 수 있습니다.

프로세스

2.3. AMQ Streams 설치
링크 복사

Red Hat Enterprise Linux에 최신 버전의 AMQ Streams를 설치하려면 다음 절차를 따르십시오.

기존 클러스터를 AMQ Streams 2.0으로 업그레이드하는 방법은 AMQ Streams 및 Kafka 업그레이드 를 참조하십시오.

사전 요구 사항

프로세스

  1. 새 kafka 사용자 및 그룹을 추가합니다. 

    sudo groupadd kafka
sudo useradd -g kafka kafka
sudo passwd kafka
    Copy to Clipboard Toggle word wrap

  2. 디렉토리 /opt/kafka 를 만듭니다. 

    sudo mkdir /opt/kafka
    Copy to Clipboard Toggle word wrap

  3. 임시 디렉터리를 생성하고 AMQ Streams ZIP 파일의 내용을 추출합니다. 

    mkdir /tmp/kafka
unzip amq-streams_y.y-x.x.x.zip -d /tmp/kafka
    Copy to Clipboard Toggle word wrap

  4. 추출된 콘텐츠를 /opt/kafka 디렉토리로 이동하고 임시 디렉터리를 삭제합니다. 

    sudo mv /tmp/kafka/kafka_y.y-x.x.x/* /opt/kafka/
rm -r /tmp/kafka
    Copy to Clipboard Toggle word wrap

  5. /opt/kafka 디렉터리의 소유권을 kafka 사용자로 변경합니다. 

    sudo chown -R kafka:kafka /opt/kafka
    Copy to Clipboard Toggle word wrap

  6. Zoo Cryostat 데이터를 저장하기 위한 /var/lib/zookeeper 디렉토리를 만들고 소유권을 kafka 사용자로 설정합니다. 

    sudo mkdir /var/lib/zookeeper
sudo chown -R kafka:kafka /var/lib/zookeeper
    Copy to Clipboard Toggle word wrap

  7. Kafka 데이터를 저장하기 위한 /var/lib/kafka 디렉터리를 생성하고 소유권을 kafka 사용자로 설정합니다. 

    sudo mkdir /var/lib/kafka
sudo chown -R kafka:kafka /var/lib/kafka
    Copy to Clipboard Toggle word wrap

2.4. 데이터 스토리지 고려 사항
링크 복사

효율적인 데이터 스토리지 인프라는 AMQ Streams의 최적의 성능에 필수적입니다.

AMQ Streams는 블록 스토리지가 필요하며 Amazon Elastic Block Store(EBS)와 같은 클라우드 기반 블록 스토리지 솔루션에서 원활하게 작동합니다. 파일 스토리지를 사용하는 것은 권장되지 않습니다.

가능한 경우 로컬 스토리지를 선택합니다. 로컬 스토리지를 사용할 수 없는 경우 파이버 채널 또는 iSCSI와 같은 프로토콜에서 액세스하는 SAN(Storage Area Network)을 사용할 수 있습니다.

2.4.1. Apache Kafka 및 Zoo Cryostat 스토리지 지원
링크 복사

Apache Kafka 및 Zoo Cryostat에 대해 별도의 디스크를 사용합니다.

Kafka는 여러 디스크 또는 볼륨의 데이터 스토리지 구성인 JBOD(디스크 Bunch) 스토리지를 지원합니다. JBOD는 Kafka 브로커에 대해 향상된 데이터 스토리지를 제공합니다. 또한 성능을 향상시킬 수 있습니다.

SSD(Solid-State Drive)는 필수는 아니지만 여러 주제로 데이터를 보내고 비동기적으로 수신하는 대규모 클러스터에서 Kafka의 성능을 향상시킬 수 있습니다. SSD는 Zoo Cryostat에서 특히 효과적이며 빠르고 짧은 대기 시간 데이터 액세스가 필요합니다.

참고

Kafka 및 Zoo Cryostat 둘 다 데이터 복제가 내장되어 있기 때문에 복제된 스토리지를 프로비저닝할 필요가 없습니다.

2.4.2. 파일 시스템
링크 복사

XFS 파일 시스템을 사용하도록 스토리지 시스템을 구성하는 것이 좋습니다. AMQ Streams는 ext4 파일 시스템과도 호환되지만 최상의 결과를 얻으려면 추가 구성이 필요할 수 있습니다.

추가 리소스

2.5. 단일 노드 AMQ Streams 클러스터 실행
링크 복사

다음 절차에서는 동일한 호스트에서 실행되는 단일 Apache Zoo Cryostat 노드와 단일 Apache Kafka 노드로 구성된 기본 AMQ Streams 클러스터를 실행하는 방법을 보여줍니다. 기본 구성 파일은 Zoo Cryostat 및 Kafka에 사용됩니다.

주의

단일 노드 AMQ Streams 클러스터는 안정성과 고가용성을 제공하지 않으며 개발 목적으로만 적합합니다.

사전 요구 사항

  • AMQ Streams가 호스트에 설치되어 있습니다.

클러스터 실행

  1. Zoo Cryostat 구성 파일 /opt/kafka/config/zookeeper.properties 를 편집합니다. dataDir 옵션을 /var/lib/zookeeper/:로 설정합니다. 

    dataDir=/var/lib/zookeeper/
    Copy to Clipboard Toggle word wrap

  2. Kafka 구성 파일 /opt/kafka/config/server.properties 를 편집합니다. log.dirs 옵션을 /var/lib/kafka/:로 설정합니다. 

    log.dirs=/var/lib/kafka/
    Copy to Clipboard Toggle word wrap

  3. kafka 사용자로 전환합니다. 

    su - kafka
    Copy to Clipboard Toggle word wrap

  4. 확대/축소를 시작합니다. 

    /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

  5. Zoo Cryostat가 실행 중인지 확인합니다. 

    jcmd | grep zookeeper
    Copy to Clipboard Toggle word wrap

    반환: 

    number org.apache.zookeeper.server.quorum.QuorumPeerMain /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

  6. Kafka 시작: 

    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

  7. Kafka가 실행 중인지 확인합니다. 

    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap

    반환: 

    number kafka.Kafka /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

추가 리소스

2.6. 클러스터 사용
링크 복사

다음 절차에서는 Kafka 콘솔 생산자 및 소비자 클라이언트를 시작하고 이를 사용하여 여러 메시지를 보내고 수신하는 방법을 설명합니다.

새 주제는 1단계에서 자동으로 생성됩니다. 주제 자동 생성은 auto.create.topics.enable 구성 속성을 사용하여 제어됩니다(기본적으로 true 로 설정). 또는 클러스터를 사용하기 전에 주제를 구성하고 생성할 수 있습니다. 자세한 내용은 항목을 참조하십시오.

사전 요구 사항

프로세스

  1. Kafka 콘솔 생산자를 시작하고 새 항목에 메시지를 보내도록 구성합니다. 

    /opt/kafka/bin/kafka-console-producer.sh --broker-list <bootstrap-address> --topic <topic-name>
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    /opt/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-topic
    Copy to Clipboard Toggle word wrap

  2. 콘솔에 여러 메시지를 입력합니다. Enter 를 눌러 각 개별 메시지를 새 주제로 보냅니다. 

    >message 1
>message 2
>message 3
>message 4
    Copy to Clipboard Toggle word wrap

    Kafka에서 새 주제를 자동으로 생성하면 주제가 존재하지 않는다는 경고가 표시될 수 있습니다. 

    WARN Error while fetching metadata with correlation id 39 :
{4-3-16-topic1=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
    Copy to Clipboard Toggle word wrap

    추가 메시지를 보낸 후에는 경고가 다시 나타나지 않아야 합니다.

  3. 새 터미널 창에서 Kafka 콘솔 소비자를 시작하고 새 주제의 시작 부분에서 메시지를 읽도록 구성합니다. 

    /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server <bootstrap-address> --topic <topic-name> --from-beginning
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my-topic --from-beginning
    Copy to Clipboard Toggle word wrap

    들어오는 메시지가 소비자 콘솔에 표시됩니다.

  4. 생산자 콘솔로 전환하고 추가 메시지를 보냅니다. 소비자 콘솔에 표시되는지 확인합니다.
  5. Kafka 콘솔 생산자를 중지한 다음 Ctrl+C 를 눌러 소비자를 중지합니다.

2.7. AMQ Streams 서비스 중지
링크 복사

스크립트를 실행하여 Kafka 및 Zoo Cryostat 서비스를 중지할 수 있습니다. Kafka 및 Zoo Cryostat 서비스에 대한 모든 연결이 종료됩니다.

사전 요구 사항

  • AMQ Streams가 호스트에 설치되어 있습니다.
  • Zookeeper 및 Kafka가 실행 중입니다.

프로세스

  1. Kafka 브로커를 중지합니다. 

    su - kafka
/opt/kafka/bin/kafka-server-stop.sh
    Copy to Clipboard Toggle word wrap

  2. Kafka 브로커가 중지되었는지 확인합니다. 

    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap

  3. Zoo Cryostat를 중지합니다. 

    su - kafka
/opt/kafka/bin/zookeeper-server-stop.sh
    Copy to Clipboard Toggle word wrap

2.8. AMQ Streams 구성
링크 복사

사전 요구 사항

  • AMQ Streams가 호스트에 다운로드 및 설치됨

프로세스

  1. 텍스트 편집기에서 Zoo Cryostat 및 Kafka 브로커 구성 파일을 엽니다. 구성 파일은 다음에 있습니다.

    ZooKeeper
    /opt/kafka/config/zookeeper.properties
    Kafka
    /opt/kafka/config/server.properties

  2. 구성 옵션을 편집합니다. 구성 파일은 Java 속성 형식입니다. 모든 구성 옵션은 다음 형식의 별도의 행에 있어야 합니다. 

    <option> = <value>
    Copy to Clipboard Toggle word wrap

    # 또는 ! 로 시작하는 행은 주석으로 처리되며 AMQ Streams 구성 요소에서 무시합니다. 

    # This is a comment
    Copy to Clipboard Toggle word wrap

    값은 줄 바꿈 / line 반환 바로 앞에 \ 를 사용하여 여러 줄로 분할할 수 있습니다. 

    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
    username="bob" \
    password="bobs-password";
    Copy to Clipboard Toggle word wrap
  3. 변경 사항을 저장
  4. Zoo Cryostat 또는 Kafka 브로커를 다시 시작합니다.
  5. 클러스터의 모든 노드에서 이 절차를 반복합니다.

2.9. 환경 변수에서 구성 값 로드
링크 복사

환경 변수 구성 공급자 플러그인을 사용하여 환경 변수에서 구성 데이터를 로드합니다. 예를 들어 환경 변수 구성 공급자를 사용하여 환경 변수에서 인증서 또는 JAAS 구성을 로드할 수 있습니다.

공급자를 사용하여 생산자 및 소비자를 포함하여 모든 Kafka 구성 요소에 대한 구성 데이터를 로드할 수 있습니다. 예를 들어 공급자를 사용하여 Kafka Connect 커넥터 구성에 대한 인증 정보를 제공합니다.

사전 요구 사항

  • AMQ Streams가 호스트에 다운로드 및 설치됨
  • AMQ Streams 아카이브의 환경 변수 구성 공급자 JAR 파일

프로세스

  1. Kafka libs 디렉터리에 환경 변수 구성 공급자 JAR 파일을 추가합니다.

  2. Kafka 구성 요소의 구성 속성 파일에서 환경 변수 구성 공급자를 초기화합니다. 예를 들어 Kafka 공급자를 초기화하려면 server.properties 파일에 구성을 추가합니다.

    환경 변수 구성 공급자를 활성화하는 구성

    config.providers=env
config.providers.env.class=io.strimzi.kafka.EnvVarConfigProvider
    Copy to Clipboard Toggle word wrap

  3. 환경 변수에서 데이터를 로드하려면 속성 파일에 구성을 추가합니다.

    환경 변수에서 데이터를 로드하는 구성

    option=${env:MY_ENV_VAR_NAME}
    Copy to Clipboard Toggle word wrap

    MY_ENV_VAR_NAME 과 같은 대문자 또는 대문자 환경 변수 이름 지정 규칙을 사용합니다.

  4. 변경 사항을 저장합니다.
  5. Kafka 구성 요소를 다시 시작합니다.

3장. Zoo Cryostat 구성
링크 복사

Kafka는 구성 데이터를 저장하고 클러스터 조정을 위해 Zoo Cryostat를 사용합니다. 복제된 Zoo Cryostat 인스턴스의 클러스터를 실행하는 것이 좋습니다.

3.1. 기본 설정
링크 복사

가장 중요한 Zoo Cryostat 구성 옵션은 다음과 같습니다.

tickTime
Zookeeper의 기본 시간 단위(밀리초)입니다. 하트비트 및 세션 시간 초과에 사용됩니다. 예를 들어 최소 세션 시간 제한은 두 틱입니다.
dataDir
Zoo Cryostat가 메모리 내 데이터베이스의 트랜잭션 로그와 스냅샷을 저장하는 디렉터리입니다. 설치 중에 생성된 /var/lib/zookeeper/ 디렉터리로 설정해야 합니다.
clientPort
클라이언트가 연결할 수 있는 포트 번호입니다. 기본값은 2181 입니다.

config/zookeeper.properties 라는 Zoo Cryostat 구성 파일은 AMQ Streams 설치 디렉터리에 있습니다. Zoo Cryostat의 대기 시간을 최소화하기 위해 dataDir 디렉토리를 별도의 디스크 장치에 배치하는 것이 좋습니다.

Zookeeper 구성 파일은 /opt/kafka/config/zookeeper.properties 에 있어야 합니다. 구성 파일의 기본 예는 다음과 같습니다. kafka 사용자가 구성 파일을 읽을 수 있어야 합니다. 

tickTime=2000
dataDir=/var/lib/zookeeper/
clientPort=2181
Copy to Clipboard Toggle word wrap

3.2. Zookeeper 클러스터 구성
링크 복사

대부분의 프로덕션 환경에서는 복제된 Zoo Cryostat 인스턴스의 클러스터를 배포하는 것이 좋습니다. 안정적이고 가용성이 높은 Zoo Cryostat 클러스터는 신뢰할 수 있는 Zoo Cryostat 서비스를 실행하는 데 중요합니다. Zookeeper 클러스터는 ensembles 라고도 합니다.

Zookeeper 클러스터는 일반적으로 홀수의 노드로 구성됩니다. Zookeeper에서는 클러스터의 대다수 노드가 실행 중이어야 합니다. 예를 들면 다음과 같습니다.

  • 3개의 노드가 있는 클러스터에서는 두 개 이상의 노드를 가동 중이어야 합니다. 즉, 하나의 노드가 다운될 수 있습니다.
  • 5개의 노드로 구성된 클러스터에서 노드를 3개 이상 사용할 수 있어야 합니다. 즉, 두 개의 노드를 중단할 수 있습니다.
  • 7개의 노드로 구성된 클러스터에서 노드를 4개 이상 사용할 수 있어야 합니다. 즉, 세 개의 노드를 중단할 수 있습니다.

Zoo Cryostat 클러스터에 더 많은 노드를 보유하면 전체 클러스터의 복원력과 안정성이 향상됩니다.

Zookeeper는 노드 수가 짝수인 클러스터에서 실행할 수 있습니다. 그러나 추가 노드는 클러스터의 복원력을 늘리지 않습니다. 4개의 노드가 있는 클러스터에서는 3개 이상의 노드를 사용할 수 있어야 하며, 하나의 노드만 다운될 수 있습니다. 따라서 3개의 노드만 있는 클러스터와 정확히 동일한 복원력이 있습니다.

이상적으로, 다른 Zoo Cryostat 노드는 다른 데이터 센터 또는 네트워크 세그먼트에 위치해야 합니다. Zoo Cryostat 노드의 수를 늘리면 클러스터 동기화에 소요되는 워크로드가 증가합니다. 대부분의 Kafka 사용 사례의 경우 3, 5 또는 7개의 노드가 있는 Zoo Cryostat 클러스터만으로도 충분합니다.

주의

3개의 노드가 있는 Zoo Cryostat 클러스터는 사용할 수 없는 1개의 노드만 허용할 수 있습니다. 즉, 다른 노드에서 유지보수를 수행하는 동안 클러스터 노드가 충돌하면 Zoo Cryostat 클러스터를 사용할 수 없습니다.

복제된 Zoo Cryostat 구성은 독립 실행형 구성에서 지원하는 모든 구성 옵션을 지원합니다. 클러스터링 구성에 추가 옵션이 추가되었습니다.

initLimit
의사 결정자가 클러스터 리더에 연결하고 동기화할 수 있도록 허용하는 시간입니다. 시간은 여러 틱으로 지정됩니다(자세한 내용은 timeTick 옵션 참조).
syncLimit
리더의 배후가 될 수 있는 시간입니다. 시간은 여러 틱으로 지정됩니다(자세한 내용은 timeTick 옵션 참조).
reconfigEnabled
동적 재구성 을 활성화하거나 비활성화합니다. Zoo Cryostat 클러스터에 서버를 추가하거나 제거하려면 활성화해야 합니다.
standaloneEnabled
하나의 서버로만 실행되는 독립 실행형 모드를 활성화하거나 비활성화합니다.

위의 옵션 외에도 모든 구성 파일에는 Zoo Cryostat 클러스터의 멤버여야 하는 서버 목록이 포함되어야 합니다. 서버 레코드는 server.id=hostname:port1:port2 형식으로 지정해야 합니다.

id
Zoo Cryostat 클러스터 노드의 ID입니다.
hostname
노드가 연결을 수신 대기하는 호스트 이름 또는 IP 주소입니다.
port1
클러스터 내부 통신에 사용되는 포트 번호입니다.
port2
리더 선택에 사용되는 포트 번호입니다.

다음은 3개의 노드가 있는 Zoo Cryostat 클러스터의 설정 파일의 예입니다. 

timeTick=2000
dataDir=/var/lib/zookeeper/
initLimit=5
syncLimit=2
reconfigEnabled=true
standaloneEnabled=false

server.1=172.17.0.1:2888:3888:participant;172.17.0.1:2181
server.2=172.17.0.2:2888:3888:participant;172.17.0.2:2181
server.3=172.17.0.3:2888:3888:participant;172.17.0.3:2181
Copy to Clipboard Toggle word wrap
참고

Zoo Cryostat 3.5.7에서 4개의 문자 단어 명령을 허용 목록에 추가해야 사용할 수 있습니다. 자세한 내용은 Zoo Cryostat 설명서를 참조하십시오.

MyID 파일

Zoo Cryostat 클러스터의 각 노드에는 고유한 ID 가 할당되어야 합니다. 각 노드의 ID 는 myid 파일에 구성하고 /var/lib/zookeeper/ 와 같은 dataDir 폴더에 저장해야 합니다. myid 파일에는 작성된 ID 가 텍스트인 단일 행만 포함되어야 합니다. ID 는 1에서 255 사이의 임의의 정수일 수 있습니다. 각 클러스터 노드에 이 파일을 수동으로 생성해야 합니다. 이 파일을 사용하여 각 Zoo Cryostat 인스턴스는 구성 파일의 해당 server. 행의 구성을 사용하여 리스너를 구성합니다. 또한 다른 모든 server. 행을 사용하여 다른 클러스터 멤버를 식별합니다.

위의 예제에는 세 개의 노드가 있으므로 각각 1,2 및 3 의 값이 각각 다른 myid 가 있습니다.

3.3. 다중 노드 Zoo Cryostat 클러스터 실행
링크 복사

다음 절차에서는 Zoo Cryostat를 다중 노드 클러스터로 구성하고 실행하는 방법을 보여줍니다.

참고

Zoo Cryostat 3.5.7에서 4개의 문자 단어 명령을 허용 목록에 추가해야 사용할 수 있습니다. 자세한 내용은 Zoo Cryostat 설명서를 참조하십시오.

사전 요구 사항

  • AMQ Streams는 Zoo Cryostat 클러스터 노드로 사용할 모든 호스트에 설치됩니다.

클러스터 실행

  1. /var/lib/zookeeper/ 에 myid 파일을 만듭니다. 첫 번째 Zoo Cryostat 노드에 ID 1 을, 두 번째 Zoo Cryostat 노드의 경우 2 를 입력합니다. 

    su - kafka
echo "<NodeID>" > /var/lib/zookeeper/myid
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    su - kafka
echo "1" > /var/lib/zookeeper/myid
    Copy to Clipboard Toggle word wrap

  2. 다음과 같이 Zoo Cryostat /opt/kafka/config/zookeeper.properties 구성 파일을 편집합니다.

    • dataDir 옵션을 /var/lib/zookeeper/ 로 설정합니다.
    • initLimit 및 syncLimit 옵션을 구성합니다.
    • reconfigEnabled 및 standaloneEnabled 옵션을 구성합니다.

    • 모든 Zoo Cryostat 노드 목록을 추가합니다. 목록에는 현재 노드도 포함되어야 합니다.

      5명의 멤버가 있는 Zoo Cryostat 클러스터의 노드 구성 예

      timeTick=2000
dataDir=/var/lib/zookeeper/
initLimit=5
syncLimit=2
reconfigEnabled=true
standaloneEnabled=false

server.1=172.17.0.1:2888:3888:participant;172.17.0.1:2181
server.2=172.17.0.2:2888:3888:participant;172.17.0.2:2181
server.3=172.17.0.3:2888:3888:participant;172.17.0.3:2181
server.4=172.17.0.4:2888:3888:participant;172.17.0.4:2181
server.5=172.17.0.5:2888:3888:participant;172.17.0.5:2181
      Copy to Clipboard Toggle word wrap

  3. 기본 설정 파일로 Zoo Cryostat를 시작합니다. 

    su - kafka
/opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

  4. Zoo Cryostat가 실행 중인지 확인합니다. 

    jcmd | grep zookeeper
    Copy to Clipboard Toggle word wrap
  5. 클러스터의 모든 노드에서 이 절차를 반복합니다.

  6. 클러스터의 모든 노드가 가동되어 실행되면 ncat 유틸리티를 사용하여 각 노드에 stat 명령을 전송하여 모든 노드가 클러스터의 멤버인지 확인합니다.

    ncat stat를 사용하여 노드 상태 확인

    echo stat | ncat localhost 2181
    Copy to Clipboard Toggle word wrap

    출력에 노드가 리더 또는 후속 항목이라는 정보가 표시됩니다.

    ncat 명령의 출력 예

    ZooKeeper version: 3.4.13-2d71af4dbe22557fda74f9a9b4309b15a7487f03, built on 06/29/2018 00:39 GMT
Clients:
 /0:0:0:0:0:0:0:1:59726[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 0/0/0
Received: 2
Sent: 1
Connections: 1
Outstanding: 0
Zxid: 0x200000000
Mode: follower
Node count: 4
    Copy to Clipboard Toggle word wrap

추가 리소스

3.4. 인증
링크 복사

기본적으로 Zoo Cryostat는 어떠한 형태의 인증을 사용하지 않으며 익명 연결을 허용합니다. 그러나 SASL(Simple Authentication and Security Layer)을 사용하여 인증을 설정하는 데 사용할 수 있는 JAAS(Java Authentication and Authorization Service)를 지원합니다. Zookeeper는 로컬에 저장된 인증 정보가 있는 vmwareGEST-MD5 SASL 메커니즘을 사용한 인증을 지원합니다.

3.4.1. SASL을 사용한 인증
링크 복사

JAAS는 별도의 구성 파일을 사용하여 구성됩니다. JAAS 구성 파일을 Zoo Cryostat 구성(/opt/kafka/config/)과 동일한 디렉토리에 배치하는 것이 좋습니다. 권장 파일 이름은 Zookeeper -jaas.conf 입니다. 여러 노드가 있는 Zoo Cryostat 클러스터를 사용하는 경우 모든 클러스터 노드에 JAAS 구성 파일을 생성해야 합니다.

JAAS는 컨텍스트를 사용하여 구성됩니다. 서버 및 클라이언트와 같은 별도의 부분은 항상 별도의 컨텍스트 로 구성됩니다. 컨텍스트는 구성 옵션이며 다음과 같은 형식을 갖습니다. 

ContextName {
       param1
       param2;
};
Copy to Clipboard Toggle word wrap

SASL 인증은 서버 간 통신(파이플리드 인스턴스 간 통신)과 클라이언트-서버 간 통신( Kafka와 Zoo Cryostat 간 통신)에 대해 별도로 구성됩니다. 서버 간 인증은 여러 노드가 있는 Zoo Cryostat 클러스터에만 관련이 있습니다.

서버 간 인증

서버 간 인증의 경우 JAAS 구성 파일에는 다음 두 부분이 포함되어 있습니다.

  • 서버 구성
  • 클라이언트 구성

goodGEST-MD5 SASL 메커니즘을 사용하는 경우 QuorumServer 컨텍스트는 인증 서버를 구성하는 데 사용됩니다. 암호화되지 않은 형식으로 암호와 연결할 수 있는 모든 사용자 이름을 포함해야 합니다. 두 번째 컨텍스트 인 Quorum learner 는 Zoo Cryostat에 구축된 클라이언트에 대해 구성해야 합니다. 또한 암호화되지 않은 형식의 암호가 포함되어 있습니다. goodGEST-MD5 메커니즘에 대한 JAAS 구성 파일의 예는 다음과 같습니다. 

QuorumServer {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       user_zookeeper="123456";
};

QuorumLearner {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       username="zookeeper"
       password="123456";
};
Copy to Clipboard Toggle word wrap

JAAS 구성 파일 외에도 다음 옵션을 지정하여 일반 Zoo Cryostat 구성 파일에서 서버 간 인증을 활성화해야 합니다. 

quorum.auth.enableSasl=true
quorum.auth.learnerRequireSasl=true
quorum.auth.serverRequireSasl=true
quorum.auth.learner.loginContext=QuorumLearner
quorum.auth.server.loginContext=QuorumServer
quorum.cnxn.threads.size=20
Copy to Clipboard Toggle word wrap

KAFKA_OPTS 환경 변수를 사용하여 JAAS 구성 파일을 Java 속성으로 Zoo Cryostat 서버에 전달합니다. 

su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
Copy to Clipboard Toggle word wrap

서버 간 인증에 대한 자세한 내용은 Zoo Cryostat wiki를 참조하십시오.

클라이언트 간 인증

클라이언트 간 인증은 서버 간 인증과 동일한 JAAS 파일에서 구성됩니다. 그러나 서버 간 인증과 달리 서버 구성만 포함됩니다. 구성의 클라이언트 부분은 클라이언트에서 수행해야 합니다. 인증을 사용하여 Zoo Cryostat에 연결하도록 Kafka 브로커를 구성하는 방법에 대한 자세한 내용은 Kafka 설치 섹션을 참조하십시오.

JAAS 구성 파일에 서버 컨텍스트를 추가하여 클라이언트-서버 간 인증을 구성합니다. goodGEST-MD5 메커니즘의 경우 모든 사용자 이름과 암호를 구성합니다. 

Server {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    user_super="123456"
    user_kafka="123456"
    user_someoneelse="123456";
};
Copy to Clipboard Toggle word wrap

JAAS 컨텍스트를 구성한 후 다음 행을 추가하여 Zoo Cryostat 구성 파일에서 클라이언트-서버 간 인증을 활성화합니다. 

requireClientAuthScheme=sasl
authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.2=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.3=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
Copy to Clipboard Toggle word wrap

Zoo Cryostat 클러스터의 일부인 모든 서버에 대해 authProvider. <ID > 속성을 추가해야 합니다.

KAFKA_OPTS 환경 변수를 사용하여 JAAS 구성 파일을 Java 속성으로 Zoo Cryostat 서버에 전달합니다. 

su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
Copy to Clipboard Toggle word wrap

Kafka 브로커에서 Zoo Cryostat 인증 구성에 대한 자세한 내용은 4.6절. “Zookeeper 인증” 을 참조하십시오.

3.4.2. vmwareGEST-MD5를 사용하여 서버 간 인증 활성화
링크 복사

다음 절차에서는 Zoo Cryostat 클러스터 노드 간의 SASL hieradataGEST-MD5 메커니즘을 사용하여 인증을 활성화하는 방법을 설명합니다.

사전 요구 사항

  • AMQ Streams가 호스트에 설치되어 있습니다.
  • Zookeeper 클러스터는 여러 노드로 구성됩니다.

SASL>-<GEST-MD5 인증 활성화

  1. 모든 Zoo Cryostat 노드에서 /opt/kafka/config/zookeeper-jaas.conf JAAS 구성 파일을 생성하거나 편집하고 다음 컨텍스트를 추가합니다. 

    QuorumServer {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       user_<Username>="<Password>";
};

QuorumLearner {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       username="<Username>"
       password="<Password>";
};
    Copy to Clipboard Toggle word wrap

    사용자 이름과 암호는 JAAS 컨텍스트 모두에서 동일해야 합니다. 예를 들면 다음과 같습니다. 

    QuorumServer {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       user_zookeeper="123456";
};

QuorumLearner {
       org.apache.zookeeper.server.auth.DigestLoginModule required
       username="zookeeper"
       password="123456";
};
    Copy to Clipboard Toggle word wrap

  2. 모든 Zoo Cryostat 노드에서 /opt/kafka/config/zookeeper.properties Zoo Cryostat 구성 파일을 편집하고 다음 옵션을 설정합니다. 

    quorum.auth.enableSasl=true
quorum.auth.learnerRequireSasl=true
quorum.auth.serverRequireSasl=true
quorum.auth.learner.loginContext=QuorumLearner
quorum.auth.server.loginContext=QuorumServer
quorum.cnxn.threads.size=20
    Copy to Clipboard Toggle word wrap

  3. 모든 Zoo Cryostat 노드를 하나씩 다시 시작합니다. JAAS 구성을 Zoo Cryostat에 전달하려면 KAFKA_OPTS 환경 변수를 사용합니다. 

    su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

추가 리소스

3.4.3. vmwareGEST-MD5를 사용하여 Client-to-server 인증 활성화
링크 복사

다음 절차에서는 Zoo Cryostat 클라이언트와 Zoo Cryostat 사이의 SASL hieradataGEST-MD5 메커니즘을 사용하여 인증을 활성화하는 방법을 설명합니다.

사전 요구 사항

SASL>-<GEST-MD5 인증 활성화

  1. 모든 Zoo Cryostat 노드에서 /opt/kafka/config/zookeeper-jaas.conf JAAS 구성 파일을 생성하거나 편집하고 다음 컨텍스트를 추가합니다. 

    Server {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    user_super="<SuperUserPassword>"
    user<Username1>_="<Password1>" user<USername2>_="<Password2>";
};
    Copy to Clipboard Toggle word wrap

    슈퍼 에는 자동으로 관리자 권한이 있습니다. 파일에는 여러 사용자를 포함할 수 있지만 Kafka 브로커에 하나의 추가 사용자만 필요합니다. Kafka 사용자의 권장 이름은 kafka 입니다.

    다음 예제에서는 클라이언트 간 인증에 대한 서버 컨텍스트를 보여줍니다. 

    Server {
    org.apache.zookeeper.server.auth.DigestLoginModule required
    user_super="123456"
    user_kafka="123456";
};
    Copy to Clipboard Toggle word wrap

  2. 모든 Zoo Cryostat 노드에서 /opt/kafka/config/zookeeper.properties Zoo Cryostat 구성 파일을 편집하고 다음 옵션을 설정합니다. 

    requireClientAuthScheme=sasl
authProvider.<IdOfBroker1>=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.<IdOfBroker2>=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.<IdOfBroker3>=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    Copy to Clipboard Toggle word wrap

    authProvider. &lt;ID > 속성은 Zoo Cryostat 클러스터의 일부인 모든 노드에 대해 추가해야 합니다. 3-노드 Zoo Cryostat 클러스터 구성의 예는 다음과 같아야 합니다. 

    requireClientAuthScheme=sasl
authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.2=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
authProvider.3=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
    Copy to Clipboard Toggle word wrap

  3. 모든 Zoo Cryostat 노드를 하나씩 다시 시작합니다. JAAS 구성을 Zoo Cryostat에 전달하려면 KAFKA_OPTS 환경 변수를 사용합니다. 

    su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/zookeeper-jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

추가 리소스

3.5. 권한 부여
링크 복사

Zookeeper는 ACL(액세스 제어 목록)을 지원하여 내부에 저장된 데이터를 보호합니다. Kafka 브로커는 생성하는 모든 Zoo Cryostat 레코드에 대한 ACL 권한을 자동으로 구성할 수 있으므로 다른 Zoo Cryostat 사용자는 수정할 수 없습니다.

Kafka 브로커에서 Zoo Cryostat ACL 활성화에 대한 자세한 내용은 4.8절. “Zookeeper 권한 부여” 을 참조하십시오.

3.6. TLS
링크 복사

Zookeeper는 암호화 또는 인증을 위해 TLS를 지원합니다.

3.7. 추가 구성 옵션
링크 복사

사용 사례에 따라 다음과 같은 Zoo Cryostat 구성 옵션을 설정할 수 있습니다.

maxClientCnxns
Zoo Cryostat 클러스터의 단일 멤버에 대한 최대 동시 클라이언트 연결 수입니다.
autopurge.snapRetainCount
유지될 Zoo Cryostat의 메모리 내 데이터베이스의 스냅샷 수입니다. 기본값은 3 입니다.
autopurge.purgeInterval
스냅샷 제거의 시간 간격(시간)입니다. 기본값은 0 이며 이 옵션은 비활성화되어 있습니다.

사용 가능한 모든 구성 옵션은 Zoo Cryostat 설명서에서 확인할 수 있습니다.

3.8. 로깅
링크 복사

Zookeeper는 log4j 를 로깅 인프라로 사용하고 있습니다. 로깅 구성은 기본적으로 /opt/kafka/config/ 디렉터리 또는 classpath에 배치해야 하는 log4j.properties 구성 파일에서 읽습니다. 구성 파일의 위치와 이름은 KAFKA_LOG4J_OPTS 환경 변수를 사용하여 Zoo Cryostat에 전달할 수 있는 Java 속성 log4j.configuration 을 사용하여 변경할 수 있습니다. 

su - kafka
export KAFKA_LOG4J_OPTS="-Dlog4j.configuration=file:/my/path/to/log4j.properties"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
Copy to Clipboard Toggle word wrap

Log4j 구성에 대한 자세한 내용은 Log4j 문서를 참조하십시오.

4장. Kafka 구성
링크 복사

Kafka는 속성 파일을 사용하여 정적 구성을 저장합니다. 구성 파일에 권장되는 위치는 /opt/kafka/config/server.properties 입니다. kafka 사용자가 구성 파일을 읽을 수 있어야 합니다.

AMQ Streams는 제품의 다양한 기본 및 고급 기능을 강조하는 구성 파일 예제를 제공합니다. 이 파일은 AMQ Streams 설치 디렉터리의 config/server.properties 에서 확인할 수 있습니다.

이 장에서는 가장 중요한 구성 옵션에 대해 설명합니다. 지원되는 Kafka 브로커 구성 옵션의 전체 목록은 부록 A. 브로커 구성 매개변수 을 참조하십시오.

4.1. ZooKeeper
링크 복사

Kafka 브로커는 구성의 일부를 저장하고 클러스터를 조정하고 (예: 어떤 노드가 어떤 파티션의 리더인지 결정하는 데) Zoo Cryostat가 필요합니다. Zoo Cryostat 클러스터의 연결 세부 정보는 구성 파일에 저장됩니다. zookeeper.connect 필드에는 콤마로 구분된 호스트 이름 목록과 zookeeper 클러스터 멤버의 포트가 포함되어 있습니다.

예를 들면 다음과 같습니다. 

zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181
Copy to Clipboard Toggle word wrap

Kafka는 이러한 주소를 사용하여 Zoo Cryostat 클러스터에 연결합니다. 이 구성을 사용하면 모든 Kafka znodes 가 Zoo Cryostat 데이터베이스의 루트에서 직접 생성됩니다. 따라서 이러한 Zoo Cryostat 클러스터는 단일 Kafka 클러스터에만 사용할 수 있습니다. 단일 Zoo Cryostat 클러스터를 사용하도록 여러 Kafka 클러스터를 구성하려면 Kafka 구성 파일의 Zoo Cryostat 연결 문자열 끝에 기본(접두사) 경로를 지정합니다. 

zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181/my-cluster-1
Copy to Clipboard Toggle word wrap

4.2. 리스너
링크 복사

리스너는 Kafka 브로커에 연결하는 데 사용됩니다. 각 Kafka 브로커는 여러 리스너를 사용하도록 구성할 수 있습니다. 각 리스너에는 다른 포트 또는 네트워크 인터페이스에서 수신 대기할 수 있도록 다른 구성이 필요합니다.

리스너를 구성하려면 구성 파일(/opt/kafka/config/server.properties)에서 listeners 속성을 편집합니다. listeners 속성에 쉼표로 구분된 목록으로 리스너를 추가합니다. 다음과 같이 각 속성을 구성합니다. 

<listenerName>://<hostname>:<port>
Copy to Clipboard Toggle word wrap

< hostname >이 비어 있으면 Kafka에서 java.net.InetAddress.getCanonicalHostName() 클래스를 호스트 이름으로 사용합니다.

여러 리스너 구성 예

listeners=internal-1://:9092,internal-2://:9093,replication://:9094
Copy to Clipboard Toggle word wrap

Kafka 클라이언트가 Kafka 클러스터에 연결하려고 하면 먼저 클러스터 노드 중 하나인 부트스트랩 서버에 연결합니다. 부트스트랩 서버는 클러스터에 있는 모든 브로커 목록을 클라이언트에 제공하고 클라이언트는 각각 개별적으로 연결합니다. 브로커 목록은 구성된 리스너 를 기반으로 합니다.

공개된 리스너

선택적으로 advertise .listeners 속성을 사용하여 클라이언트에 listeners 속성에 지정된 것과 다른 리스너 주소 집합을 제공할 수 있습니다. 프록시와 같은 추가 네트워크 인프라가 클라이언트와 브로커 간이거나 IP 주소 대신 외부 DNS 이름을 사용하는 경우 유용합니다.

advertise .listeners 속성은 listeners 속성과 동일한 방식으로 포맷됩니다.

광고된 리스너에 대한 구성 예

listeners=internal-1://:9092,internal-2://:9093
advertised.listeners=internal-1://my-broker-1.my-domain.com:1234,internal-2://my-broker-1.my-domain.com:1235
Copy to Clipboard Toggle word wrap

참고

공개된 리스너의 이름은 listeners 속성에 나열된 리스너와 일치해야 합니다.

broker 리스너

broker 리스너 는 Kafka 브로커 간 통신에 사용됩니다. 다음의 경우broker 간 통신이 필요합니다.

  • 서로 다른 브로커 간 워크로드 조정
  • 다른 브로커에 저장된 파티션 간 메시지 복제
  • 파티션 리더십 변경과 같은 컨트롤러의 관리 작업 처리

broker 리스너는 선택한 포트에 할당할 수 있습니다. 여러 리스너가 구성된 경우 inter.broker.listener .name 속성에서broker 리스너의 이름을 정의할 수 있습니다.

여기에서는broker 리스너의 이름이 REPLICATION 으로 지정됩니다. 

listeners=REPLICATION://0.0.0.0:9091
inter.broker.listener.name=REPLICATION
Copy to Clipboard Toggle word wrap

컨트롤 플레인 리스너

기본적으로 컨트롤러와 다른 브로커 간의 통신은 브루커 리스너를 사용합니다. 컨트롤러는 파티션 리더십 변경과 같은 관리 작업을 조정합니다.

컨트롤러 연결에 대한 전용 컨트롤 플레인 리스너 를 활성화할 수 있습니다. 선택한 포트에 컨트롤 플레인 리스너를 할당할 수 있습니다.

컨트롤 플레인 리스너를 활성화하려면 리스너 이름으로 control.plane.listener.name 속성을 구성합니다. 

listeners=CONTROLLER://0.0.0.0:9090,REPLICATION://0.0.0.0:9091
...
control.plane.listener.name=CONTROLLER
Copy to Clipboard Toggle word wrap

컨트롤러 통신은 브로커 간 데이터 복제에 의해 지연되지 않으므로 컨트롤 플레인 리스너를 활성화하면 클러스터 성능이 향상될 수 있습니다. 데이터 복제는 inter-broker 리스너를 통해 계속됩니다.

control.plane.listener 가 구성되지 않은 경우 컨트롤러 연결은 inter-broker 리스너 를 사용합니다.

자세한 내용은 부록 A. 브로커 구성 매개변수의 내용을 참조하십시오.

4.3. 커밋 로그
링크 복사

Apache Kafka는 커밋 로그에서 생산자에서 수신하는 모든 레코드를 저장합니다. 커밋 로그에는 Kafka가 제공해야 하는 레코드 형식의 실제 데이터가 포함됩니다. 이는 브로커가 수행하는 작업을 기록하는 애플리케이션 로그 파일이 아닙니다.

로그 디렉터리

log.dirs 속성 파일을 사용하여 로그 디렉터리를 구성하여 하나 이상의 로그 디렉터리에 커밋 로그를 저장할 수 있습니다. 설치 중에 생성된 /var/lib/kafka 디렉터리로 설정해야 합니다. 

log.dirs=/var/lib/kafka
Copy to Clipboard Toggle word wrap

성능상의 이유로 log.dirs를 여러 디렉터리로 구성하고 각각 물리적 장치를 다른 물리적 장치에 배치하여 디스크 I/O 성능을 향상시킬 수 있습니다. 예를 들면 다음과 같습니다. 

log.dirs=/var/lib/kafka1,/var/lib/kafka2,/var/lib/kafka3
Copy to Clipboard Toggle word wrap

4.4. 브로커 ID
링크 복사

broker ID는 클러스터의 각 브로커의 고유 식별자입니다. 브로커 ID로 0보다 크거나 같은 정수를 할당할 수 있습니다. 브로커 ID는 재시작 또는 충돌 후 브로커를 식별하는 데 사용되며, 따라서 ID가 안정적이며 시간이 지남에 따라 변경되지 않는 것이 중요합니다. 브로커 ID는 브로커 속성 파일에 구성되어 있습니다. 

broker.id=1
Copy to Clipboard Toggle word wrap

4.5. 다중 노드 Kafka 클러스터 실행
링크 복사

다음 절차에서는 Kafka를 다중 노드 클러스터로 구성하고 실행하는 방법을 설명합니다.

사전 요구 사항

클러스터 실행

AMQ Streams 클러스터의 각 Kafka 브로커에 대해 다음을 수행합니다.

  1. 다음과 같이 /opt/kafka/config/server.properties Kafka 구성 파일을 편집합니다.

    • 첫 번째 브로커의 경우 broker.id 필드를 0 으로, 두 번째 브로커의 경우 1 을 0으로 설정합니다.
    • Zookeeper .connect 옵션에서 Zoo Cryostat에 연결하기 위한 세부 정보를 구성합니다.
    • Kafka 리스너를 구성합니다.

    • 커밋 로그를 logs.dir 디렉터리에 저장해야 하는 디렉터리를 설정합니다.

      여기에서 Kafka 브로커의 구성 예가 표시됩니다. 

      broker.id=0
zookeeper.connect=zoo1.my-domain.com:2181,zoo2.my-domain.com:2181,zoo3.my-domain.com:2181
listeners=REPLICATION://:9091,PLAINTEXT://:9092
inter.broker.listener.name=REPLICATION
log.dirs=/var/lib/kafka
      Copy to Clipboard Toggle word wrap

      각 Kafka 브로커가 동일한 하드웨어에서 실행되는 일반적인 설치에서는 broker.id 구성 속성만 각 브로커 구성마다 다릅니다.

  2. 기본 구성 파일을 사용하여 Kafka 브로커를 시작합니다. 

    su - kafka
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

  3. Kafka 브로커가 실행 중인지 확인합니다. 

    jcmd | grep Kafka
    Copy to Clipboard Toggle word wrap

브로커 확인

클러스터의 모든 노드가 가동되어 실행되면 ncat 유틸리티를 사용하여 dump 명령을 Zoo Cryostat 노드 중 하나로 전송하여 모든 노드가 Kafka 클러스터의 멤버인지 확인합니다. 이 명령은 Zoo Cryostat에 등록된 모든 Kafka 브로커를 출력합니다.

  1. ncat stat을 사용하여 노드 상태를 확인합니다. 

    echo dump | ncat zoo1.my-domain.com 2181
    Copy to Clipboard Toggle word wrap

    출력에 방금 구성하고 시작한 모든 Kafka 브로커가 포함되어야 합니다.

    3개의 노드가 있는 Kafka 클러스터의 ncat 명령의 출력 예: 

    SessionTracker dump:
org.apache.zookeeper.server.quorum.LearnerSessionTracker@28848ab9
ephemeral nodes dump:
Sessions with Ephemerals (3):
0x20000015dd00000:
        /brokers/ids/1
0x10000015dc70000:
        /controller
        /brokers/ids/0
0x10000015dc70001:
        /brokers/ids/2
    Copy to Clipboard Toggle word wrap

추가 리소스

4.6. Zookeeper 인증
링크 복사

기본적으로 Zoo Cryostat와 Kafka 간 연결은 인증되지 않습니다. 그러나 Kafka 및 Zoo Cryostat는 SAS(Simple Authentication and Security Layer)를 사용하여 인증을 설정하는 데 사용할 수 있는 JAAS(Java Authentication and Authorization Service)를 지원합니다. Zookeeper는 로컬에 저장된 인증 정보가 있는 vmwareGEST-MD5 SASL 메커니즘을 사용한 인증을 지원합니다.

4.6.1. JAAS 구성
링크 복사

Zoo Cryostat 연결에 대한 SASL 인증은 JAAS 구성 파일에서 구성해야 합니다. 기본적으로 Kafka는 Zoo Cryostat에 연결하기 위해 Client 라는 JAAS 컨텍스트를 사용합니다. 클라이언트 컨텍스트는 /opt/kafka/config/jass.conf 파일에서 구성해야 합니다. 컨텍스트는 다음 예와 같이 PLAIN SASL 인증을 활성화해야 합니다. 

Client {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="kafka"
    password="123456";
};
Copy to Clipboard Toggle word wrap

4.6.2. Zoo Cryostat 인증 활성화
링크 복사

다음 절차에서는 Zoo Cryostat에 연결할 때 SASL hieradataGEST-MD5 메커니즘을 사용하여 인증을 활성화하는 방법을 설명합니다.

사전 요구 사항

  • Zoo Cryostat에서 클라이언트-서버 간 인증이 활성화됨

SASL>-<GEST-MD5 인증 활성화

  1. 모든 Kafka 브로커 노드에서 /opt/kafka/config/jaas.conf JAAS 구성 파일을 생성하거나 편집하고 다음 컨텍스트를 추가합니다. 

    Client {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="<Username>"
    password="<Password>";
};
    Copy to Clipboard Toggle word wrap

    사용자 이름과 암호는 Zoo Cryostat에 구성된 것과 동일해야 합니다.

    다음 예제에서는 클라이언트 컨텍스트를 보여줍니다. 

    Client {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="kafka"
    password="123456";
};
    Copy to Clipboard Toggle word wrap

  2. 모든 Kafka 브로커 노드를 하나씩 다시 시작합니다. JAAS 구성을 Kafka 브로커에 전달하려면 KAFKA_OPTS 환경 변수를 사용합니다. 

    su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

추가 리소스

  • Zoo Cryostat에서 클라이언트-서버 인증 구성에 대한 자세한 내용은 3.4절. “인증” 을 참조하십시오.

4.7. 권한 부여
링크 복사

Kafka 브로커의 권한 부여는 승인자 플러그인을 사용하여 구현됩니다.

이 섹션에서는 Kafka와 함께 제공된 AclAuthorizer 플러그인을 사용하는 방법을 설명합니다.

또는 고유한 권한 부여 플러그인을 사용할 수 있습니다. 예를 들어 OAuth 2.0 토큰 기반 인증을 사용하는 경우 OAuth 2.0 인증을 사용할 수 있습니다.

4.7.1. 간단한 ACL 승인자
링크 복사

AclAuthorizer 를 포함한 승인자 플러그인은 authorizer.class.name 속성을 통해 활성화됩니다. 

authorizer.class.name=kafka.security.auth.AclAuthorizer
Copy to Clipboard Toggle word wrap

선택한 승인자에게 정규화된 이름이 필요합니다. AclAuthorizer 의 경우 정규화된 이름은 kafka.security.auth.AclAuthorizer 입니다.

4.7.1.1. ACL 규칙
링크 복사

AclAuthorizer 는 ACL 규칙을 사용하여 Kafka 브로커에 대한 액세스를 관리합니다.

ACL 규칙은 형식으로 정의됩니다.

호스트 H에서 Kafka 리소스 R 에서 주체 P 가 허용 / 거부된 작업 O

예를 들어, 사용자를 위해 규칙을 설정할 수 있습니다.

존은 host 127.0.0.1의 주제 주석 을 볼 수 있습니다.

host는 존스가 연결 중인 시스템의 IP 주소입니다.

대부분의 경우 사용자는 생산자 또는 소비자 애플리케이션입니다.

Consumer01 은 호스트 127.0.0.1에서 소비자 그룹 계정에 쓸 수 있습니다.

ACL 규칙이 없는 경우

지정된 리소스에 ACL 규칙이 없으면 모든 작업이 거부됩니다. Kafka 구성 파일 /opt/kafka/config/server.properties 에서 allow.everyone.if.no.acl.found 속성을 true 로 설정하여 이 동작을 변경할 수 있습니다.

4.7.1.2. 보안 주체
링크 복사

보안 주체 는 사용자의 ID를 나타냅니다. ID 형식은 클라이언트가 Kafka에 연결하는 데 사용하는 인증 메커니즘에 따라 달라집니다.

  • 인증 없이 연결할 때 사용자:ANONYMOUS.

  • user:<username >은 PLAIN 또는 SCRAM과 같은 간단한 인증 메커니즘을 사용하여 연결된 경우입니다.

    예: User:admin 또는 User:user1.

  • TLS 클라이언트 인증을 사용하여 연결된 경우 user :<DistinguishedName >입니다.

    예를 들면 User:CN=user1,O=MyCompany,L=Prague,C=CZ 입니다.

  • User:<Kerberos username& gt; when connected using Kerberos.

DistinguishedName 은 클라이언트 인증서와 고유 이름입니다.

Kerberos 사용자 이름은 Kerberos 주체의 기본 부분이며 Kerberos를 사용하여 연결할 때 기본적으로 사용됩니다. sasl.kerberos.principal.to.local.rules 속성을 사용하여 Kerberos 주체에서 Kafka 주체를 빌드하는 방법을 구성할 수 있습니다.

4.7.1.3. 사용자 인증
링크 복사

승인을 사용하려면 클라이언트가 인증을 활성화하고 사용해야 합니다. 그렇지 않으면 모든 연결에 주체 User:ANONYMOUS 가 있습니다.

인증 방법에 대한 자세한 내용은 암호화 및 인증을 참조하십시오.

4.7.1.4. 슈퍼유저
링크 복사

슈퍼유저는 ACL 규칙에 관계없이 모든 작업을 수행할 수 있습니다.

슈퍼 사용자는 super.users 속성을 사용하여 Kafka 구성 파일에 정의되어 있습니다.

예를 들면 다음과 같습니다. 

super.users=User:admin,User:operator
Copy to Clipboard Toggle word wrap
4.7.1.5. 복제본 브로커 인증
링크 복사

권한 부여가 활성화되면 모든 리스너 및 모든 연결에 적용됩니다. 여기에는 브로커 간 데이터 복제에 사용되는 inter-broker 연결이 포함됩니다. 따라서 권한 부여를 활성화하는 경우 브랜드 간 연결에 인증을 사용하고 브로커에서 사용하는 사용자에게 충분한 권한을 부여해야 합니다. 예를 들어 브로커 간 인증이 kafka-broker 사용자를 사용하는 경우 슈퍼 사용자 구성에 사용자 이름 super.users=User:kafka-broker 가 포함되어야 합니다.

4.7.1.6. 지원되는 리소스
링크 복사

이러한 유형의 리소스에 Kafka ACL을 적용할 수 있습니다.

  • 주제
  • 소비자 그룹
  • 클러스터
  • TransactionId
  • DelegationToken
4.7.1.7. 지원되는 작업
링크 복사

AclAuthorizer 는 리소스에 대한 작업을 인증합니다.

다음 표에 X 가 있는 필드는 각 리소스에 대해 지원되는 작업을 나타냅니다.

Expand
표 4.1. 리소스에 대해 지원되는 작업
 주제소비자 그룹Cluster

읽기

X

X

 

쓰기

X

  

개발

  

X

delete

X

  

변경

X

  

describe

X

X

X

ClusterAction

  

X

All

X

X

X

4.7.1.8. ACL 관리 옵션
링크 복사

ACL 규칙은 Kafka 배포 패키지의 일부로 제공되는 bin/kafka-acls.sh 유틸리티를 사용하여 관리됩니다.

kafka-acls.sh 매개변수 옵션을 사용하여 ACL 규칙을 추가, 나열 및 제거하고 기타 기능을 수행합니다.

매개 변수에는 --add 와 같은 이중-하이프 규칙(예: --add )이 필요합니다.

Expand
옵션유형설명기본

add

동작

ACL 규칙을 추가합니다.

 

제거

동작

ACL 규칙을 제거합니다.

 

list

동작

ACL 규칙을 나열합니다.

 

승인자

동작

승인자의 정규화된 클래스 이름입니다.

kafka.security.auth.AclAuthorizer

authorizer-properties

설정

초기화를 위해 승인자에게 전달된 키/값 쌍입니다.

AclAuthorizer 의 경우 예제 값은 zookeeper.connect=zoo1.my-domain.com:2181 입니다.

 

bootstrap-server

리소스

Kafka 클러스터에 연결할 호스트/포트 쌍입니다.

이 옵션 또는 승인자 옵션을 둘 다 사용하는 것이 아닙니다.

command-config

리소스

bootstrap-server 매개변수와 함께 사용되는 Admin Client에 전달할 구성 속성 파일입니다.

 

cluster

리소스

클러스터를 ACL 리소스로 지정합니다.

 

topic

리소스

주제 이름을 ACL 리소스로 지정합니다.

와일드카드로 사용되는 별표(*)는 모든 주제로 변환됩니다.

단일 명령은 여러 --topic 옵션을 지정할 수 있습니다.

 

group

리소스

소비자 그룹 이름을 ACL 리소스로 지정합니다.

단일 명령은 여러 --group 옵션을 지정할 수 있습니다.

 

transactional-id

리소스

트랜잭션 ID를 ACL 리소스로 지정합니다.

트랜잭션 전달은 생산자가 여러 파티션으로 전송하거나 해당 파티션을 성공적으로 전달하지 않아야 함을 의미합니다.

와일드카드로 사용되는 별표(*)는 모든 ID 로 변환됩니다.

 

delegation-token

리소스

위임 토큰을 ACL 리소스로 지정합니다.

와일드카드로 사용되는 별표(*)는 모든 토큰으로 변환됩니다.

 

resource-pattern-type

설정

add 매개변수 또는 list 또는 remove 매개변수에 대한 리소스 패턴의 유형을 지정합니다.

리소스 이름에 대한 리소스 패턴 유형으로 리터럴 또는 접두사 를 사용합니다.

리소스 패턴 필터 값 또는 특정 패턴 유형 필터로 일부 또는 일치 를 사용합니다.

리터럴

allow-principal

주체

주체가 허용 ACL 규칙에 추가되었습니다.

단일 명령은 --allow-principal 옵션을 여러 개 지정할 수 있습니다.

 

deny-principal

주체

거부 ACL 규칙에 보안 주체가 추가되었습니다.

단일 명령은 --deny-principal 옵션을 여러 개 지정할 수 있습니다.

 

주체

주체

principal에 대한 ACL 목록을 반환하기 위해 list 매개변수와 함께 사용되는 주체 이름입니다.

단일 명령은 --principal 여러 옵션을 지정할 수 있습니다.

 

allow-host

호스트

--allow-principal 에 나열된 보안 주체에 액세스할 수 있는 IP 주소입니다.

호스트 이름 또는 CIDR 범위는 지원되지 않습니다.

--allow-principal 이 지정된 경우 기본값은 "모든 호스트"를 의미합니다.

deny-host

호스트

--deny-principal 에 나열된 주체에 대한 액세스를 거부하는 IP 주소입니다.

호스트 이름 또는 CIDR 범위는 지원되지 않습니다.

--deny-principal 이 지정된 경우 기본값은 * 즉 "모든 호스트"입니다.

작업

작업

작업을 허용하거나 거부합니다.

단일 명령은 단일 명령에서 multipleMultiple --operation 옵션을 지정할 수 있습니다.

All

생산자

바로 가기

메시지 프로듀서(WRITE 및 DESCRIBE, 클러스터의 CREATE)에 필요한 모든 작업을 허용하거나 거부하는 바로 가기입니다.

 

소비자

바로 가기

메시지 소비자(READ 및 DESCRIBE on topic, READ on consumer group)에 필요한 모든 작업을 허용하거나 거부하는 바로 가기입니다.

 

idempotent

바로 가기

--producer 매개변수와 함께 사용할 때 idempotence를 활성화하는 바로 가기로, 메시지는 정확히 한 번 파티션으로 전달됩니다.

Idepmotence는 생산자가 특정 트랜잭션 ID를 기반으로 메시지를 보낼 수 있는 권한이 부여된 경우 자동으로 활성화됩니다.

 

force

바로 가기

모든 쿼리를 수락하고 묻지 않는 바로 가기입니다.

 

4.7.2. 권한 부여 활성화
링크 복사

다음 절차에서는 Kafka 브로커에서 승인을 위해 AclAuthorizer 플러그인을 활성화하는 방법을 설명합니다.

사전 요구 사항

프로세스

  1. AclAuthorizer 를 사용하도록 /opt/kafka/config/server.properties Kafka 구성 파일을 편집합니다. 

    authorizer.class.name=kafka.security.auth.AclAuthorizer
    Copy to Clipboard Toggle word wrap
  2. Kafka 브로커를 시작합니다.

추가 리소스

4.7.3. ACL 규칙 추가
링크 복사

AclAuthorizer 는 사용자가 수행할 수 있고 수행할 수 없는 규칙 집합을 정의하는 ACL(액세스 제어 목록)을 사용합니다.

다음 절차에서는 Kafka 브로커에서 AclAuthorizer 플러그인을 사용할 때 ACL 규칙을 추가하는 방법을 설명합니다.

규칙은 kafka-acls.sh 유틸리티를 사용하여 추가되고 Zoo Cryostat에 저장됩니다.

사전 요구 사항

프로세스

  1. --add 옵션을 사용하여 kafka-acls.sh 를 실행합니다.

    예:

    • MyConsumerGroup 소비자 그룹을 사용하여 user1 및 user2 액세스가 myTopic 에서 읽을 수 있도록 허용합니다. 

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Read --topic myTopic --allow-principal User:user1 --allow-principal User:user2

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Describe --topic myTopic --allow-principal User:user1 --allow-principal User:user2

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Read --operation Describe --group MyConsumerGroup --allow-principal User:user1 --allow-principal User:user2
      Copy to Clipboard Toggle word wrap

    • user1 액세스를 거부하여 IP 주소 127.0.0.1 에서 myTopic 을 읽습니다. 

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Describe --operation Read --topic myTopic --group MyConsumerGroup --deny-principal User:user1 --deny-host 127.0.0.1
      Copy to Clipboard Toggle word wrap

    • MyConsumerGroup 을 사용하여 myTopic 의 소비자로 user1 을 추가합니다. 

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --consumer --topic myTopic --group MyConsumerGroup --allow-principal User:user1
      Copy to Clipboard Toggle word wrap

추가 리소스

4.7.4. ACL 규칙 나열
링크 복사

다음 절차에서는 Kafka 브로커에서 AclAuthorizer 플러그인을 사용할 때 기존 ACL 규칙을 나열하는 방법을 설명합니다.

규칙은 kafka-acls.sh 유틸리티를 사용하여 나열됩니다.

사전 요구 사항

프로세스

  • --list 옵션을 사용하여 kafka-acls.sh 를 실행합니다.

    예를 들면 다음과 같습니다. 

    $ bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --list --topic myTopic

Current ACLs for resource `Topic:myTopic`:

User:user1 has Allow permission for operations: Read from hosts: *
User:user2 has Allow permission for operations: Read from hosts: *
User:user2 has Deny permission for operations: Read from hosts: 127.0.0.1
User:user1 has Allow permission for operations: Describe from hosts: *
User:user2 has Allow permission for operations: Describe from hosts: *
User:user2 has Deny permission for operations: Describe from hosts: 127.0.0.1
    Copy to Clipboard Toggle word wrap

추가 리소스

4.7.5. ACL 규칙 제거
링크 복사

다음 절차에서는 Kafka 브로커에서 AclAuthorizer 플러그인을 사용할 때 ACL 규칙을 제거하는 방법을 설명합니다.

규칙은 kafka-acls.sh 유틸리티를 사용하여 제거됩니다.

사전 요구 사항

프로세스

  • --remove 옵션을 사용하여 kafka-acls.sh 를 실행합니다.

    예:

  • MyConsumerGroup 소비자 그룹을 사용하여 myTopic 에서 Allow user1 및 user2 액세스를 읽을 수 있도록 ACL을 제거합니다. 

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Read --topic myTopic --allow-principal User:user1 --allow-principal User:user2

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Describe --topic myTopic --allow-principal User:user1 --allow-principal User:user2

bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Read --operation Describe --group MyConsumerGroup --allow-principal User:user1 --allow-principal User:user2
    Copy to Clipboard Toggle word wrap

  • MyConsumerGroup 을 사용하여 myTopic 의 소비자로 user1 을 추가하는 ACL을 제거합니다. 

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --consumer --topic myTopic --group MyConsumerGroup --allow-principal User:user1
    Copy to Clipboard Toggle word wrap

  • IP 주소 호스트 127.0.0.1 에서 myTopic 읽기를 위해 user1 액세스를 거부하는 ACL을 제거합니다. 

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Describe --operation Read --topic myTopic --group MyConsumerGroup --deny-principal User:user1 --deny-host 127.0.0.1
    Copy to Clipboard Toggle word wrap

추가 리소스

4.8. Zookeeper 권한 부여
링크 복사

Kafka와 Zoo Cryostat 간에 인증이 활성화되면 Zoo Cryostat Access Control List(ACL) 규칙을 사용하여 Zoo Cryostat에 저장된 Kafka의 메타데이터에 대한 액세스를 자동으로 제어할 수 있습니다.

4.8.1. ACL 구성
링크 복사

Zoo Cryostat ACL 규칙 적용은 config/server .properties Kafka 구성 파일의 Zookeeper.set.acl 속성에 의해 제어됩니다.

속성은 기본적으로 비활성화되어 있으며 true 로 설정하여 활성화됩니다. 

zookeeper.set.acl=true
Copy to Clipboard Toggle word wrap

ACL 규칙이 활성화되면 znode 가 Zoo Cryostat에서 생성되는 경우 이를 생성한 Kafka 사용자만 수정하거나 삭제할 수 있습니다. 다른 모든 사용자는 읽기 전용 액세스 권한을 갖습니다.

Kafka는 새로 생성된 Zoo Cryostat znodes 에만 ACL 규칙을 설정합니다. ACL이 클러스터를 처음 시작한 후에만 활성화된 경우 zookeeper-security-migration.sh 툴에서 모든 기존 znodes 에 ACL을 설정할 수 있습니다.

Zoo Cryostat의 데이터 기밀성

Zoo Cryostat에 저장된 데이터는 다음과 같습니다.

  • 주제 이름 및 구성
  • SASL SCRAM 인증을 사용할 때 Salted 및 hashed 사용자 자격 증명입니다.

그러나 Zoo Cryostat는 Kafka를 사용하여 전송 및 수신한 레코드를 저장하지 않습니다. Zoo Cryostat에 저장된 데이터는 기밀로 간주됩니다.

데이터가 기밀로 간주되는 경우(예: 주제 이름에 고객 ID가 포함되어 있기 때문에) 보호에 사용할 수 있는 유일한 옵션은 네트워크 수준에서 Zoo Cryostat를 분리하고 Kafka 브로커에만 액세스를 허용하는 것입니다.

4.8.2. 새 Kafka 클러스터에 대해 Zoo Cryostat ACL 활성화
링크 복사

다음 절차에서는 새 Kafka 클러스터의 Kafka 구성에서 Zoo Cryostat ACL을 활성화하는 방법을 설명합니다. Kafka 클러스터를 처음 시작하기 전에 이 절차를 사용하십시오. 이미 실행 중인 클러스터에서 Zoo Cryostat ACL을 활성화하려면 4.8.3절. “기존 Kafka 클러스터에서 Zoo Cryostat ACL 활성화” 을 참조하십시오.

사전 요구 사항

프로세스

  1. /opt/kafka/config/server.properties Kafka 구성 파일을 편집하여 모든 클러스터 노드에서 zookeeper.set.acl 필드를 true 로 설정합니다. 

    zookeeper.set.acl=true
    Copy to Clipboard Toggle word wrap
  2. Kafka 브로커를 시작합니다.

4.8.3. 기존 Kafka 클러스터에서 Zoo Cryostat ACL 활성화
링크 복사

다음 절차에서는 실행 중인 Kafka 클러스터의 Kafka 구성에서 Zoo Cryostat ACL을 활성화하는 방법을 설명합니다. Zookeeper -security-migration.sh 도구를 사용하여 기존 znodes 에 Zoo Cryostat ACL을 설정합니다. Zookeeper -security-migration.sh 는 AMQ Streams의 일부로 사용할 수 있으며 bin 디렉토리에서 찾을 수 있습니다.

사전 요구 사항

Zoo Cryostat ACL 활성화

  1. /opt/kafka/config/server.properties Kafka 구성 파일을 편집하여 모든 클러스터 노드에서 zookeeper.set.acl 필드를 true 로 설정합니다. 

    zookeeper.set.acl=true
    Copy to Clipboard Toggle word wrap
  2. 모든 Kafka 브로커를 하나씩 다시 시작합니다.

  3. Zookeeper -security-migration.sh 도구를 사용하여 기존의 모든 Zoo Cryostat znodes 에서 ACL을 설정합니다. 

    su - kafka
cd /opt/kafka
KAFKA_OPTS="-Djava.security.auth.login.config=./config/jaas.conf"; ./bin/zookeeper-security-migration.sh --zookeeper.acl=secure --zookeeper.connect=<ZooKeeperURL>
exit
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    su - kafka
cd /opt/kafka
KAFKA_OPTS="-Djava.security.auth.login.config=./config/jaas.conf"; ./bin/zookeeper-security-migration.sh --zookeeper.acl=secure --zookeeper.connect=zoo1.my-domain.com:2181
exit
    Copy to Clipboard Toggle word wrap

4.9. 암호화 및 인증
링크 복사

AMQ Streams는 리스너 구성의 일부로 구성된 암호화 및 인증을 지원합니다.

4.9.1. 리스너 구성
링크 복사

Kafka 브로커의 암호화 및 인증은 리스너별로 구성됩니다. Kafka 리스너 구성에 대한 자세한 내용은 4.2절. “리스너” 을 참조하십시오.

Kafka 브로커의 각 리스너는 자체 보안 프로토콜로 구성됩니다. 구성 속성 listener.security.protocol.map 은 보안 프로토콜을 사용하는 리스너를 정의합니다. 각 리스너 이름을 보안 프로토콜에 매핑합니다. 지원되는 보안 프로토콜은 다음과 같습니다.

일반 텍스트
암호화 또는 인증이 없는 리스너입니다.
SSL
TLS 암호화를 사용하는 리스너 및 필요한 경우 TLS 클라이언트 인증서를 사용한 인증입니다.
SASL_PLAINTEXT
암호화가 없지만 SASL 기반 인증을 사용하는 리스너입니다.
SASL_SSL
TLS 기반 암호화 및 SASL 기반 인증을 사용하는 리스너입니다.

다음 리스너 구성이 제공됩니다. 

listeners=INT1://:9092,INT2://:9093,REPLICATION://:9094
Copy to Clipboard Toggle word wrap

listener.security.protocol.map 은 다음과 같을 수 있습니다. 

listener.security.protocol.map=INT1:SASL_PLAINTEXT,INT2:SASL_SSL,REPLICATION:SSL
Copy to Clipboard Toggle word wrap

이렇게 하면 SASL 인증과 함께 암호화되지 않은 연결을 사용하고, 리스너 INT2 가 SASL 인증과 함께 암호화된 연결을 사용하고 REPLICATION 인터페이스를 사용하여 TLS 암호화(TLS 클라이언트 인증과 함께)를 사용하도록 리스너 INT1 을 구성합니다. 동일한 보안 프로토콜을 여러 번 사용할 수 있습니다. 다음 예도 유효한 구성입니다. 

listener.security.protocol.map=INT1:SSL,INT2:SSL,REPLICATION:SSL
Copy to Clipboard Toggle word wrap

이러한 구성은 모든 인터페이스에 TLS 암호화 및 TLS 인증을 사용합니다. 다음 장에서는 TLS 및 SASL 구성 방법을 자세히 설명합니다.

4.9.2. TLS 암호화
링크 복사

Kafka는 Kafka 클라이언트와의 통신을 암호화하기 위해 TLS를 지원합니다.

TLS 암호화 및 서버 인증을 사용하려면 개인 키와 공개 키가 포함된 키 저장소를 제공해야 합니다. 일반적으로 JKS(Java Keystore) 형식으로 파일을 사용하여 수행합니다. 이 파일의 경로는 ssl.keystore.location 속성에 설정됩니다. 키 저장소를 보호하는 암호를 설정하는 데 ssl.keystore.password 속성을 사용해야 합니다. 예를 들면 다음과 같습니다. 

ssl.keystore.location=/path/to/keystore/server-1.jks
ssl.keystore.password=123456
Copy to Clipboard Toggle word wrap

경우에 따라 개인 키를 보호하는 데 추가 암호가 사용됩니다. 이러한 암호는 ssl.key.password 속성을 사용하여 설정할 수 있습니다.

Kafka는 인증 기관에서 서명한 키와 자체 서명 키를 사용할 수 있습니다. 인증 기관에서 서명한 키를 사용하는 것이 항상 선호되는 방법이어야 합니다. 클라이언트가 연결 중인 Kafka 브로커의 ID를 확인할 수 있도록 하려면 인증서에서 항상 공개된 호스트 이름을 CN(일반 이름) 또는 SAN(주체 대체 이름)으로 포함해야 합니다.

다양한 리스너에 다양한 SSL 구성을 사용할 수 있습니다. ssl으로 시작하는 모든 옵션 앞에 listener. name.<NameOfTheListener> 접두사를 지정할 수 있습니다. 여기서 리스너 이름은 항상 소문자여야 합니다. 이렇게 하면 해당 특정 리스너에 대한 기본 SSL 구성이 재정의됩니다. 다음 예제에서는 다양한 리스너에 다양한 SSL 구성을 사용하는 방법을 보여줍니다. 

listeners=INT1://:9092,INT2://:9093,REPLICATION://:9094
listener.security.protocol.map=INT1:SSL,INT2:SSL,REPLICATION:SSL

# Default configuration - will be used for listeners INT1 and INT2
ssl.keystore.location=/path/to/keystore/server-1.jks
ssl.keystore.password=123456

# Different configuration for listener REPLICATION
listener.name.replication.ssl.keystore.location=/path/to/keystore/server-1.jks
listener.name.replication.ssl.keystore.password=123456
Copy to Clipboard Toggle word wrap

추가 TLS 구성 옵션

위에서 설명한 기본 TLS 구성 옵션 외에도 Kafka는 TLS 구성을 미세 조정하기 위한 다양한 옵션을 지원합니다. 예를 들어 TLS / SSL 프로토콜 또는 암호화 제품군을 활성화하거나 비활성화하려면 다음을 수행합니다.

ssl.cipher.suites
활성화된 암호화 제품군 목록입니다. 각 암호화 제품군은 TLS 연결에 사용되는 인증, 암호화, MAC 및 키 교환 알고리즘의 조합입니다. 기본적으로 사용 가능한 모든 암호화 제품군이 활성화됩니다.
ssl.enabled.protocols
활성화된 TLS/SSL 프로토콜 목록입니다. 기본값은 TLSv1.2,TLSv1.1,TLSv1 입니다.

지원되는 Kafka 브로커 구성 옵션의 전체 목록은 부록 A. 브로커 구성 매개변수 을 참조하십시오.

4.9.3. TLS 암호화 활성화
링크 복사

다음 절차에서는 Kafka 브로커에서 암호화를 활성화하는 방법을 설명합니다.

사전 요구 사항

  • AMQ Streams는 Kafka 브로커로 사용할 모든 호스트에 설치됩니다.

프로세스

  1. 클러스터의 모든 Kafka 브로커에 대한 TLS 인증서를 생성합니다. 인증서에는 일반 이름 또는 주체 대체 이름에 광고 및 부트스트랩 주소가 있어야 합니다.

  2. 다음을 위해 모든 클러스터 노드에서 /opt/kafka/config/server.properties Kafka 구성 파일을 편집합니다.

    • listener.security.protocol.map 필드를 변경하여 TLS 암호화를 사용하려는 리스너의 SSL 프로토콜을 지정합니다.
    • 브로커 인증서와 함께 JKS 키 저장소의 경로로 ssl.keystore.location 옵션을 설정합니다.

    • ssl.keystore.password 옵션을 키 저장소를 보호하는 데 사용한 암호로 설정합니다.

      예를 들면 다음과 같습니다. 

      listeners=UNENCRYPTED://:9092,ENCRYPTED://:9093,REPLICATION://:9094
listener.security.protocol.map=UNENCRYPTED:PLAINTEXT,ENCRYPTED:SSL,REPLICATION:PLAINTEXT
ssl.keystore.location=/path/to/keystore/server-1.jks
ssl.keystore.password=123456
      Copy to Clipboard Toggle word wrap
  3. Kafka 브로커 시작

추가 리소스

4.9.4. 인증
링크 복사

인증의 경우 다음을 사용할 수 있습니다.

  • 암호화된 연결에 대한 X.509 인증서를 기반으로 하는 TLS 클라이언트 인증
  • 지원되는 Kafka SASL(Simple Authentication and Security Layer) 메커니즘
  • OAuth 2.0 토큰 기반 인증
4.9.4.1. TLS 클라이언트 인증
링크 복사

TLS 클라이언트 인증은 이미 TLS 암호화를 사용하는 연결에서만 사용할 수 있습니다. TLS 클라이언트 인증을 사용하려면 공개 키가 있는 신뢰 저장소를 브로커에 제공할 수 있습니다. 이러한 키는 브로커에 연결하는 클라이언트를 인증하는 데 사용할 수 있습니다. 신뢰 저장소는 JKS(Java Keystore) 형식으로 제공해야 하며 인증 기관의 공개 키가 포함되어야 합니다. 신뢰 저장소에 포함된 인증 기관 중 하나에 의해 서명된 공개 및 개인 키가 있는 모든 클라이언트가 인증됩니다. 신뢰 저장소의 위치는 ssl.truststore.location 필드를 사용하여 설정됩니다. 신뢰 저장소가 암호로 보호되는 경우 암호는 ssl.truststore.password 속성에 설정해야 합니다. 예를 들면 다음과 같습니다. 

ssl.truststore.location=/path/to/keystore/server-1.jks
ssl.truststore.password=123456
Copy to Clipboard Toggle word wrap

truststore가 구성되면 ssl.client.auth 속성을 사용하여 TLS 클라이언트 인증을 활성화해야 합니다. 이 속성은 다음 세 가지 값 중 하나로 설정할 수 있습니다.

none
TLS 클라이언트 인증이 꺼집니다. (기본값)
요청됨
TLS 클라이언트 인증은 선택 사항입니다. 클라이언트는 TLS 클라이언트 인증서를 사용하여 인증하라는 메시지가 표시되지만 선택할 수는 없습니다.
필수 항목
클라이언트는 TLS 클라이언트 인증서를 사용하여 인증하는 데 필요합니다.

클라이언트가 TLS 클라이언트 인증을 사용하여 인증하면 인증된 주체 이름이 인증된 클라이언트 인증서와 고유합니다. 예를 들어 고유 이름이 CN=someuser 인 인증서가 있는 사용자는 다음 주체 CN=someuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown 로 인증됩니다. TLS 클라이언트 인증을 사용하지 않고 SASL이 비활성화되면 주 이름은 ANONYMOUS 입니다.

4.9.4.2. SASL 인증
링크 복사

SASL 인증은 JAAS(Java Authentication and Authorization Service)를 사용하여 구성됩니다. JAAS는 Kafka와 Zoo Cryostat 간의 연결 인증에도 사용됩니다. JAAS는 자체 구성 파일을 사용합니다. 이 파일의 권장 위치는 /opt/kafka/config/jaas.conf 입니다. 이 파일은 kafka 사용자가 읽을 수 있어야 합니다. Kafka를 실행하는 경우 Java 시스템 속성 java.security.auth.login.config 를 사용하여 이 파일의 위치가 지정됩니다. 브로커 노드를 시작할 때 이 속성을 Kafka로 전달해야 합니다. 

KAFKA_OPTS="-Djava.security.auth.login.config=/path/to/my/jaas.config"; bin/kafka-server-start.sh
Copy to Clipboard Toggle word wrap

SASL 인증은 일반 암호화되지 않은 연결과 TLS 연결을 통해 모두 지원됩니다. 각 리스너에 대해 SASL을 개별적으로 활성화할 수 있습니다. 이를 활성화하려면 listener.security.protocol.map 의 보안 프로토콜이 SASL_PLAINTEXT 또는 SASL_SSL 이어야 합니다.

Kafka의 SASL 인증은 몇 가지 다른 메커니즘을 지원합니다.

PLAIN
사용자 이름과 암호를 기반으로 인증을 구현합니다. 사용자 이름과 암호는 Kafka 구성에 로컬로 저장됩니다.
SCRAM-SHA-256 및 SCRAM-SHA-512
SCRAM(Salted Challenge Response Authentication Mechanism)을 사용하여 인증을 구현합니다. SCRAM 자격 증명은 중앙 Zoo Cryostat에 저장됩니다. SCRAM은 Zoo Cryostat 클러스터 노드가 프라이빗 네트워크에서 격리된 상태로 실행되는 상황에서 사용할 수 있습니다.
GSSAPI
Kerberos 서버에 대한 인증을 구현합니다.
주의

PLAIN 메커니즘은 암호화되지 않은 형식으로 네트워크를 통해 사용자 이름과 암호를 전송합니다. 따라서 TLS 암호화와 함께만 사용해야 합니다.

SASL 메커니즘은 JAAS 구성 파일을 통해 구성됩니다. Kafka는 KafkaServer 라는 JAAS 컨텍스트를 사용합니다. JAAS에서 구성한 후 Kafka 구성에서 SASL 메커니즘을 활성화해야 합니다. 이 작업은 sasl.enabled.mechanisms 속성을 사용하여 수행됩니다. 이 속성에는 활성화된 메커니즘의 쉼표로 구분된 목록이 포함되어 있습니다. 

sasl.enabled.mechanisms=PLAIN,SCRAM-SHA-256,SCRAM-SHA-512
Copy to Clipboard Toggle word wrap

broker 간 통신에 사용되는 리스너가 SASL을 사용하는 경우 속성 sasl.mechanism.inter.broker.protocol 을 사용하여 사용해야 하는 SASL 메커니즘을 지정해야 합니다. 예를 들면 다음과 같습니다. 

sasl.mechanism.inter.broker.protocol=PLAIN
Copy to Clipboard Toggle word wrap

broker 간 통신에 사용할 사용자 이름과 암호는 사용자 이름 및 암호 를 사용하여 KafkaServer JAAS 컨텍스트에 지정해야 합니다.

SASL PLAIN

PLAIN 메커니즘을 사용하려면 연결할 수 있는 사용자 이름과 암호가 JAAS 컨텍스트에서 직접 지정됩니다. 다음 예제에서는 SASL PLAIN 인증에 대해 구성된 컨텍스트를 보여줍니다. 이 예제에서는 세 개의 다른 사용자를 구성합니다.

  • admin
  • user1
  • user2 
KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    user_admin="123456"
    user_user1="123456"
    user_user2="123456";
};
Copy to Clipboard Toggle word wrap

사용자 데이터베이스가 있는 JAAS 구성 파일은 모든 Kafka 브로커에서 동기화되어 있어야 합니다.

broker 간 인증에 SASL PLAIN도 사용하는 경우 사용자 이름과 암호 속성을 JAAS 컨텍스트에 포함해야 합니다. 

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="123456"
    user_admin="123456"
    user_user1="123456"
    user_user2="123456";
};
Copy to Clipboard Toggle word wrap

SASL SCRAM

Kafka의 SCRAM 인증은 SCRAM-SHA-256 및 SCRAM-SHA-512 의 두 가지 메커니즘으로 구성됩니다. 이러한 메커니즘은 SHA-256과 SHA-512 강화의 해시 알고리즘에서만 다릅니다. SCRAM 인증을 활성화하려면 JAAS 구성 파일에 다음 구성을 포함해야 합니다. 

KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required;
};
Copy to Clipboard Toggle word wrap

Kafka 구성 파일에서 SASL 인증을 활성화할 때 두 SCRAM 메커니즘을 모두 나열할 수 있습니다. 그러나 그 중 하나만 브루커 간 통신을 위해 선택할 수 있습니다. 예를 들면 다음과 같습니다. 

sasl.enabled.mechanisms=SCRAM-SHA-256,SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
Copy to Clipboard Toggle word wrap

SCRAM 메커니즘에 대한 사용자 자격 증명은 Zoo Cryostat에 저장됩니다. kafka-configs.sh 도구를 사용하여 관리할 수 있습니다. 예를 들어 다음 명령을 실행하여 암호 123456이 있는 user1 사용자를 추가합니다. 

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --add-config 'SCRAM-SHA-256=[password=123456],SCRAM-SHA-512=[password=123456]' --entity-type users --entity-name user1
Copy to Clipboard Toggle word wrap

사용자 인증 정보를 삭제하려면 다음을 사용합니다. 

bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name user1
Copy to Clipboard Toggle word wrap

SASL GSSAPI

Kerberos를 사용한 인증에 사용되는 SASL 메커니즘을 GSSAPI 라고 합니다. Kerberos SASL 인증을 구성하려면 JAAS 구성 파일에 다음 구성을 추가해야 합니다. 

KafkaServer {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/etc/security/keytabs/kafka_server.keytab"
    principal="kafka/kafka1.hostname.com@EXAMPLE.COM";
};
Copy to Clipboard Toggle word wrap

Kerberos 주체의 도메인 이름은 항상 대문자여야 합니다.

JAAS 구성 외에도 Kafka 구성의 sasl.kerberos.service.name 속성에 Kerberos 서비스 이름을 지정해야 합니다. 

sasl.enabled.mechanisms=GSSAPI
sasl.mechanism.inter.broker.protocol=GSSAPI
sasl.kerberos.service.name=kafka
Copy to Clipboard Toggle word wrap

여러 SASL 메커니즘

Kafka는 여러 SASL 메커니즘을 동시에 사용할 수 있습니다. 서로 다른 JAAS 구성은 모두 동일한 컨텍스트에 추가할 수 있습니다. 

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    user_admin="123456"
    user_user1="123456"
    user_user2="123456";

    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/etc/security/keytabs/kafka_server.keytab"
    principal="kafka/kafka1.hostname.com@EXAMPLE.COM";

    org.apache.kafka.common.security.scram.ScramLoginModule required;
};
Copy to Clipboard Toggle word wrap

여러 메커니즘이 활성화되면 클라이언트는 사용하려는 메커니즘을 선택할 수 있습니다.

4.9.5. TLS 클라이언트 인증 활성화
링크 복사

다음 절차에서는 Kafka 브로커에서 TLS 클라이언트 인증을 활성화하는 방법을 설명합니다.

사전 요구 사항

프로세스

  1. 사용자 인증서에 서명하는 데 사용되는 인증 기관의 공개 키가 포함된 JKS 신뢰 저장소를 준비합니다.

  2. 다음을 위해 모든 클러스터 노드에서 /opt/kafka/config/server.properties Kafka 구성 파일을 편집합니다.

    • 사용자 인증서의 인증 기관이 있는 JKS 신뢰 저장소 경로로 ssl.truststore.location 옵션을 설정합니다.
    • ssl.truststore.password 옵션을 신뢰 저장소를 보호하는 데 사용한 암호로 설정합니다.

    • ssl.client.auth 옵션을 required 로 설정합니다.

      예를 들면 다음과 같습니다. 

      ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=123456
ssl.client.auth=required
      Copy to Clipboard Toggle word wrap
  3. Kafka 브로커 시작

추가 리소스

4.9.6. SASL PLAIN 인증 활성화
링크 복사

다음 절차에서는 Kafka 브로커에서 SASL PLAIN 인증을 활성화하는 방법을 설명합니다.

사전 요구 사항

  • AMQ Streams는 Kafka 브로커로 사용할 모든 호스트에 설치됩니다.

프로세스

  1. /opt/kafka/config/jaas.conf JAAS 구성 파일을 편집하거나 만듭니다. 이 파일에는 모든 사용자와 암호가 포함되어야 합니다. 이 파일이 모든 Kafka 브로커에서 동일한지 확인합니다.

    예를 들면 다음과 같습니다. 

    KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    user_admin="123456"
    user_user1="123456"
    user_user2="123456";
};
    Copy to Clipboard Toggle word wrap

  2. 다음을 위해 모든 클러스터 노드에서 /opt/kafka/config/server.properties Kafka 구성 파일을 편집합니다.

    • SASL PLAIN 인증을 사용하려는 리스너의 SASL_PLAINTEXT 또는 SASL_SSL 프로토콜을 지정하도록 listener.security.protocol.map 필드를 변경합니다.

    • sasl.enabled.mechanisms 옵션을 PLAIN 으로 설정합니다.

      예를 들면 다음과 같습니다. 

      listeners=INSECURE://:9092,AUTHENTICATED://:9093,REPLICATION://:9094
listener.security.protocol.map=INSECURE:PLAINTEXT,AUTHENTICATED:SASL_PLAINTEXT,REPLICATION:PLAINTEXT
sasl.enabled.mechanisms=PLAIN
      Copy to Clipboard Toggle word wrap

  3. (re) KAFKA_OPTS 환경 변수를 사용하여 Kafka 브로커를 시작하여 JAAS 구성을 Kafka 브로커에 전달합니다. 

    su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

추가 리소스

4.9.7. SASL SCRAM 인증 활성화
링크 복사

다음 절차에서는 Kafka 브로커에서 SASL SCRAM 인증을 활성화하는 방법을 설명합니다.

사전 요구 사항

  • AMQ Streams는 Kafka 브로커로 사용할 모든 호스트에 설치됩니다.

프로세스

  1. /opt/kafka/config/jaas.conf JAAS 구성 파일을 편집하거나 만듭니다. KafkaServer 컨텍스트에 대해 ScramLoginModule 을 활성화합니다. 이 파일이 모든 Kafka 브로커에서 동일한지 확인합니다.

    예를 들면 다음과 같습니다. 

    KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required;
};
    Copy to Clipboard Toggle word wrap

  2. 다음을 위해 모든 클러스터 노드에서 /opt/kafka/config/server.properties Kafka 구성 파일을 편집합니다.

    • SASL SCRAM 인증을 사용하려는 리스너의 SASL_PLAINTEXT 또는 SASL_SSL 프로토콜을 지정하도록 listener.security.protocol.map 필드를 변경합니다.

    • sasl.enabled.mechanisms 옵션을 SCRAM-SHA-256 또는 SCRAM-SHA-512 로 설정합니다.

      예를 들면 다음과 같습니다. 

      listeners=INSECURE://:9092,AUTHENTICATED://:9093,REPLICATION://:9094
listener.security.protocol.map=INSECURE:PLAINTEXT,AUTHENTICATED:SASL_PLAINTEXT,REPLICATION:PLAINTEXT
sasl.enabled.mechanisms=SCRAM-SHA-512
      Copy to Clipboard Toggle word wrap

  3. (re) KAFKA_OPTS 환경 변수를 사용하여 Kafka 브로커를 시작하여 JAAS 구성을 Kafka 브로커에 전달합니다. 

    su - kafka
export KAFKA_OPTS="-Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

추가 리소스

4.9.8. SASL SCRAM 사용자 추가
링크 복사

이 절차에서는 SASL SCRAM을 사용하여 인증을 위해 새 사용자를 추가하는 방법을 설명합니다.

사전 요구 사항

프로세스

  • kafka-configs.sh 도구를 사용하여 새 SASL SCRAM 사용자를 추가합니다. 

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --alter --add-config 'SCRAM-SHA-512=[password=<Password>]' --entity-type users --entity-name <Username>
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --add-config 'SCRAM-SHA-512=[password=123456]' --entity-type users --entity-name user1
    Copy to Clipboard Toggle word wrap

추가 리소스

4.9.9. SASL SCRAM 사용자 삭제
링크 복사

다음 절차에서는 SASL SCRAM 인증을 사용할 때 사용자를 제거하는 방법을 설명합니다.

사전 요구 사항

프로세스

  • kafka-configs.sh 도구를 사용하여 SASL SCRAM 사용자를 삭제합니다. 

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name <Username>
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --delete-config 'SCRAM-SHA-512' --entity-type users --entity-name user1
    Copy to Clipboard Toggle word wrap

추가 리소스

4.10. OAuth 2.0 토큰 기반 인증 사용
링크 복사

AMQ Streams는 OAUTHBEARER 및 PLAIN 메커니즘을 사용한 OAuth 2.0 인증 사용을 지원합니다.

OAuth 2.0은 중앙 권한 부여 서버를 사용하여 리소스에 대한 제한된 액세스 권한을 부여하는 토큰을 발행하여 애플리케이션 간에 표준화된 토큰 기반 인증과 권한을 부여할 수 있습니다.

Kafka 브로커 및 클라이언트는 모두 OAuth 2.0을 사용하도록 구성해야 합니다. OAuth 2.0 인증을 구성한 다음 OAuth 2.0 인증을 구성할 수 있습니다.

참고

OAuth 2.0 인증은 사용된 권한 부여 서버에 관계없이 ACL 기반 Kafka 권한 과 함께 사용할 수 있습니다.

애플리케이션 클라이언트는 OAuth 2.0 인증을 사용하여 계정 자격 증명을 노출하지 않고도 애플리케이션 서버( 리소스 서버라고 함)의 리소스에 액세스할 수 있습니다.

애플리케이션 클라이언트는 인증 수단으로 액세스 토큰을 전달합니다. 이 방법으로 부여할 액세스 수준을 결정하는 데 사용할 애플리케이션 서버가 사용할 수 있습니다. 권한 부여 서버는 액세스 권한 부여 및 액세스 관련 문의를 처리합니다.

AMQ Streams의 컨텍스트에서 다음을 수행합니다.

  • Kafka 브로커는 OAuth 2.0 리소스 서버 역할을 합니다.
  • Kafka 클라이언트가 OAuth 2.0 애플리케이션 클라이언트 역할을 합니다.

Kafka 클라이언트는 Kafka 브로커에 인증합니다. 브로커 및 클라이언트는 필요에 따라 OAuth 2.0 권한 부여 서버와 통신하여 액세스 토큰을 얻거나 검증합니다.

AMQ Streams 배포를 위해 OAuth 2.0 통합은 다음을 제공합니다.

  • Kafka 브로커에 대한 서버 측 OAuth 2.0 지원
  • Kafka MirrorMaker, Kafka Connect 및 Kafka Bridge에 대한 클라이언트 측 OAuth 2.0 지원

RHEL의 AMQ Streams에는 두 개의 OAuth 2.0 라이브러리가 포함되어 있습니다.

kafka-oauth-client
io.strimzi.kafka.client.client.JaasClientOauthLoginCallbackHandler 라는 사용자 정의 로그인 콜백 처리기 클래스를 제공합니다. OAUTHBEARER 인증 메커니즘을 처리하려면 Apache Kafka에서 제공하는 OAuthBearerLoginModule 과 함께 로그인 콜백 핸들러를 사용합니다.
kafka-oauth-common
kafka-oauth-client 라이브러리에 필요한 일부 기능을 제공하는 도우미 라이브러리입니다.

제공된 클라이언트 라이브러리는 keycloak-core,jackson-databind, slf4j-api 와 같은 일부 추가 타사 라이브러리에 대한 종속성도 있습니다.

모든 종속성 라이브러리가 포함되도록 Maven 프로젝트를 사용하여 클라이언트를 패키징하는 것이 좋습니다. 종속성 라이브러리는 향후 버전에서 변경될 수 있습니다.

OAuth 콜백 핸들러 는 Kafka 클라이언트 Java 라이브러리에 대해 제공되므로 Java 클라이언트에 대한 자체 콜백 핸들러를 작성할 필요가 없습니다. 애플리케이션 클라이언트는 콜백 처리기를 사용하여 액세스 토큰을 제공할 수 있습니다. Go와 같은 다른 언어로 작성된 클라이언트는 사용자 지정 코드를 사용하여 권한 부여 서버에 연결하고 액세스 토큰을 받아야 합니다.

추가 리소스

4.10.1. OAuth 2.0 인증 메커니즘
링크 복사

AMQ Streams는 OAuth 2.0 인증을 위한 OAUTHBEARER 및 PLAIN 메커니즘을 지원합니다. 두 메커니즘을 통해 Kafka 클라이언트가 Kafka 브로커를 사용하여 인증된 세션을 설정할 수 있습니다. 클라이언트, 권한 부여 서버 및 Kafka 브로커 간의 인증 흐름은 각 메커니즘마다 다릅니다.

가능한 경우 OAUTHBEARER를 사용하도록 클라이언트를 구성하는 것이 좋습니다. OAUTHBEARER는 클라이언트 인증 정보가 Kafka 브로커와 공유 되지 않기 때문에 PLAIN보다 높은 수준의 보안을 제공합니다. OAUTHBEARER를 지원하지 않는 Kafka 클라이언트에서만 PLAIN을 사용하는 것이 좋습니다.

필요한 경우 동일한 OAuth 인증 리스너 구성에서 OAUTHBEARER 및 PLAIN을 함께 활성화할 수 있습니다.

OAUTHBEARER 개요

Kafka는 명시적으로 구성해야 하지만 OAUTHBEARER 인증 메커니즘을 지원합니다. 많은 Kafka 클라이언트 툴은 프로토콜 수준에서 OAUTHBEARER에 대한 기본 지원을 제공하는 라이브러리를 사용합니다.

클라이언트는 OAUTHBEARER를 사용하여 인증 정보 교환을 위해 Kafka 브로커로 세션을 시작합니다. 여기서 인증 정보는 콜백 처리기에서 제공하는 전달자 토큰의 형태를 취합니다. 콜백을 사용하면 다음 세 가지 방법 중 하나로 토큰 프로비저닝을 구성할 수 있습니다.

  • 클라이언트 ID 및 시크릿( OAuth 2.0 클라이언트 인증 정보 메커니즘을 사용하여)
  • 구성 시 수동으로 얻은 장기 액세스 토큰
  • 구성 시 수동으로 가져온 장기 새로 고침 토큰

OAUTHBEARER 를 사용하려면 Kafka 브로커의 OAuth 인증 리스너 구성에서 sasl.enabled.mechanisms 를 OAUTHBEARER로 설정해야 합니다. 자세한 구성은 4.10.2절. “OAuth 2.0 Kafka 브로커 구성” 에서 참조하십시오. 

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
Copy to Clipboard Toggle word wrap
참고

OAUTHBEARER 인증은 프로토콜 수준에서 OAUTHBEARER 메커니즘을 지원하는 Kafka 클라이언트에서만 사용할 수 있습니다.

PLAIN 개요

PLAIN은 kafkacat과 같은 개발자 툴을 포함하여 모든 Kafka 클라이언트 툴에서 지원하는 간단한 인증 메커니즘입니다. OAuth 2.0 인증에 사용할 PLAIN을 활성화하기 위해 RHEL의 AMQ Streams에는 서버 측 콜백이 포함되어 있습니다. PLAIN의 AMQ Streams 구현을 PLAIN을 통한 OAuth 2.0 이라고 합니다.

PLAIN을 통한 OAuth 2.0을 사용하면 클라이언트 인증 정보가 Zoo Cryostat에 저장되지 않습니다. 대신 OAUTHBEARER 인증이 사용되는 경우와 유사하게 호환 권한 서버 뒤에서 중앙 집중식으로 처리됩니다.

PLAIN 콜백을 통해 OAuth 2.0과 함께 사용하면 Kafka 클라이언트가 다음 방법 중 하나를 사용하여 Kafka 브로커로 인증합니다.

  • 클라이언트 ID 및 시크릿( OAuth 2.0 클라이언트 인증 정보 메커니즘을 사용하여)
  • 구성 시 수동으로 얻은 장기 액세스 토큰

PLAIN 인증을 사용하려면 클라이언트를 활성화하고 사용자 이름과 암호를 제공해야 합니다. 암호 앞에 $accessToken: 뒤에 액세스 토큰 값이 추가되면 Kafka 브로커는 암호를 액세스 토큰으로 해석합니다. 그러지 않으면 Kafka 브로커가 사용자 이름을 클라이언트 ID로 해석하고 암호를 클라이언트 시크릿으로 해석합니다.

암호 가 액세스 토큰으로 설정된 경우 사용자 이름은 Kafka 브로커가 액세스 토큰에서 얻는 것과 동일한 주체 이름으로 설정해야 합니다. 이 프로세스는 userNameClaim,fallbackUserNameClaim,fallbackUsernamePrefix 또는 userInfoEndpointUri 를 사용하여 사용자 이름 추출을 구성하는 방법에 따라 다릅니다. 또한 권한 부여 서버에 따라 달라집니다. 특히 클라이언트 ID를 계정 이름에 매핑하는 방법은 다음과 같습니다.

Kafka 브로커의 OAuth 인증 리스너 구성에서 PLAIN을 활성화할 수 있습니다. 이렇게 하려면 sasl.enabled.mechanisms 값에 PLAIN 을 추가합니다. 

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER,PLAIN
Copy to Clipboard Toggle word wrap

자세한 구성은 4.10.2절. “OAuth 2.0 Kafka 브로커 구성” 에서 참조하십시오.

4.10.1.1. 속성 또는 변수를 사용하여 OAuth 2.0 구성
링크 복사

JAAS(Java Authentication and Authorization Service) 속성 또는 환경 변수를 사용하여 OAuth 2.0 설정을 구성할 수 있습니다.

  • JAAS 속성은 server.properties 구성 파일에 구성되어 listener.name의 키-값 쌍으로 전달됩니다.LISTENER-NAME.oauthbearer.sasl.jaas.config 속성.

  • 환경 변수를 사용하는 경우에도 listener.name.LISTENER-NAME.oauthbearer.sasl.jaas.config 속성을 server.properties 파일에 제공해야 하지만 다른 JAAS 속성을 생략할 수 있습니다.

    대문자 또는 대문자 환경 변수 이름 지정 규칙을 사용할 수 있습니다.

AMQ Streams OAuth 2.0 라이브러리는 다음으로 시작하는 속성을 사용합니다.

4.10.2. OAuth 2.0 Kafka 브로커 구성
링크 복사

OAuth 2.0 인증에 대한 Kafka 브로커 구성은 다음과 같습니다.

  • 권한 부여 서버에서 OAuth 2.0 클라이언트 생성
  • Kafka 클러스터에서 OAuth 2.0 인증 구성
참고

권한 부여 서버와 관련하여 Kafka 브로커 및 Kafka 클라이언트는 모두 OAuth 2.0 클라이언트로 간주됩니다.

4.10.2.1. 권한 부여 서버의 OAuth 2.0 클라이언트 구성
링크 복사

세션 시작 중에 수신된 토큰을 확인하도록 Kafka 브로커를 구성하려면 다음 클라이언트 인증 정보가 활성화된 권한 부여 서버로 구성된 OAuth 2.0 클라이언트 정의를 생성하는 것이 좋습니다.

  • kafka-broker 의 클라이언트 ID(예:)
  • 인증 메커니즘으로 클라이언트 ID 및 시크릿
참고

권한 부여 서버의 비공개 인트로스펙션 엔드포인트를 사용하는 경우에만 클라이언트 ID와 시크릿을 사용해야 합니다. 인증 정보는 빠른 로컬 JWT 토큰 검증과 마찬가지로 공용 권한 부여 서버 끝점을 사용할 때 필요하지 않습니다.

4.10.2.2. Kafka 클러스터의 OAuth 2.0 인증 구성
링크 복사

Kafka 클러스터에서 OAuth 2.0 인증을 사용하려면 Kafka server.properties 파일에서 Kafka 클러스터에 대한 OAuth 인증 리스너 구성을 활성화합니다. 최소 구성이 필요합니다. TLS가 브루커 간 통신에 사용되는 TLS 리스너를 구성할 수도 있습니다.

다음 방법 중 하나를 사용하여 권한 부여 서버에서 토큰 검증을 위해 브로커를 구성할 수 있습니다.

  • 빠른 로컬 토큰 검증: 서명된 JWT 형식의 액세스 토큰과 함께 JWKS 끝점
  • 인트로스펙션 끝점

OAUTHBEARER 또는 PLAIN 인증을 구성하거나 둘 다 구성할 수 있습니다.

다음 예제에서는 글로벌 리스너 구성을 적용하는 최소 구성을 보여줍니다. 즉, 애플리케이션 클라이언트와 동일한 리스너 간 통신이 진행됩니다.

이 예제에서는 또한 listener.name을 지정하는 특정 리스너에 대한 OAuth 2.0 구성을 보여줍니다. sasl.enabled.mechanisms 대신LISTENER-NAME . sasl.enabled.mechanisms. LISTENER-NAME 은 리스너의 대소문자를 구분하지 않는 이름입니다. 여기서는 리스너 CLIENT 의 이름을 지정하므로 속성 이름은 listener.name.client.sasl.enabled.mechanisms 입니다.

이 예에서는 OAUTHBEARER 인증을 사용합니다.

예: JWKS 엔드포인트를 사용한 OAuth 2.0 인증에 대한 최소 리스너 구성

sasl.enabled.mechanisms=OAUTHBEARER
1 

listeners=CLIENT://0.0.0.0:9092
2 

listener.security.protocol.map=CLIENT:SASL_PLAINTEXT
3 

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
4 

sasl.mechanism.inter.broker.protocol=OAUTHBEARER
5 

inter.broker.listener.name=CLIENT
6 

listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
7 

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
8 

  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \
9 

  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \
10 

  oauth.username.claim="preferred_username"  \
11 

  oauth.client.id="kafka-broker" \
12 

  oauth.client.secret="kafka-secret" \
13 

  oauth.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/token" ;
14 

listener.name.client.oauthbearer.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
15 

listener.name.client.oauthbearer.connections.max.reauth.ms=3600000
16
Copy to Clipboard Toggle word wrap

1
SASL을 통해 인증 정보를 교환하기 위한 OAUTHBEARER 메커니즘을 활성화합니다.
2
클라이언트 애플리케이션이 연결할 리스너를 구성합니다. 시스템 호스트 이름은 공개된 호스트 이름으로 사용되며, 다시 연결하기 위해 클라이언트가 확인해야 합니다. 이 예제에서는 리스너의 이름이 CLIENT 로 지정됩니다.
3
리스너의 채널 프로토콜을 지정합니다. SASL_SSL 은 TLS용입니다. SASL_PLAINTEXT 는 암호화되지 않은 연결(TLS 없음)에 사용되지만 TCP 연결 계층에서 도청 및 인터셉션의 위험이 있습니다.
4
CLIENT 리스너의 OAUTHBEARER 메커니즘을 지정합니다. 클라이언트 이름(CLIENT)은 일반적으로 listeners 속성에 대문자로 지정되며, listener.name.client 속성의 경우 소문자(listener.name.client) 및 listener.name.client.* 속성의 일부인 경우 소문자로 지정됩니다.
5
broker 간 통신을 위한 OAUTHBEARER 메커니즘을 지정합니다.
6
broker 간 통신을 위한 리스너를 지정합니다. 구성이 유효하려면 사양이 필요합니다.
7
클라이언트 리스너에 OAuth 2.0 인증을 구성합니다.
8
클라이언트 및 브랜드 간 통신에 대한 인증 설정을 구성합니다. oauth.client.id,oauth.client.secret 및 auth.token.endpoint.uri 속성은broker 간 구성과 관련이 있습니다.
9
유효한 발행자 URI입니다. 이 발행자가 발행한 액세스 토큰만 허용됩니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME.
10
JWKS 엔드포인트 URL입니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs.
11
토큰에 실제 사용자 이름이 포함된 토큰 클레임(또는 키)입니다. 사용자 이름은 사용자를 식별하는 데 사용되는 주체 입니다. 값은 인증 흐름 및 사용된 권한 부여 서버에 따라 달라집니다.
12
모든 브로커에 대해 동일한 Kafka 브로커의 클라이언트 ID입니다. 이 클라이언트는 권한 부여 서버에 kafka-broker로 등록된 클라이언트 입니다.
13
모든 브로커에 대해 동일한 Kafka 브로커의 시크릿입니다.
14
권한 부여 서버의 OAuth 2.0 토큰 끝점 URL입니다. 프로덕션의 경우 항상 HTTP를 사용합니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token.
15
broker 간 통신을 위해 OAuth 2.0 인증에만 필요합니다.
16
(선택 사항) 토큰이 만료될 때 세션 만료를 강제 적용하고 Kafka 재인증 메커니즘 도 활성화합니다. 지정된 값이 액세스 토큰이 만료될 때까지 남은 시간보다 작으면 클라이언트는 실제 토큰 만료 전에 다시 인증해야 합니다. 기본적으로 액세스 토큰이 만료되고 클라이언트가 재인증을 시도하지 않으면 세션이 만료되지 않습니다.

다음 예제에서는 TLS 리스너에 대한 최소 구성을 보여줍니다. 여기서 TLS는 브루커 간 통신에 사용됩니다.

예: OAuth 2.0 인증을 위한 TLS 리스너 구성

listeners=REPLICATION://kafka:9091,CLIENT://kafka:9092
1 

listener.security.protocol.map=REPLICATION:SSL,CLIENT:SASL_PLAINTEXT
2 

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
inter.broker.listener.name=REPLICATION
listener.name.replication.ssl.keystore.password=KEYSTORE-PASSWORD
3 

listener.name.replication.ssl.truststore.password=TRUSTSTORE-PASSWORD
listener.name.replication.ssl.keystore.type=JKS
listener.name.replication.ssl.truststore.type=JKS
listener.name.replication.ssl.endpoint.identification.algorithm=HTTPS
4 

listener.name.replication.ssl.secure.random.implementation=SHA1PRNG
5 

listener.name.replication.ssl.keystore.location=PATH-TO-KEYSTORE
6 

listener.name.replication.ssl.truststore.location=PATH-TO-TRUSTSTORE
7 

listener.name.replication.ssl.client.auth=required
8 

listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \
  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \
  oauth.username.claim="preferred_username" ;
9
Copy to Clipboard Toggle word wrap

1
broker 간 통신 및 클라이언트 애플리케이션에는 별도의 구성이 필요합니다.
2
TLS를 사용하도록 REPLICATION 리스너와 CLIENT 리스너가 암호화되지 않은 채널을 통해 SASL을 사용하도록 구성합니다. 클라이언트는 프로덕션 환경에서 암호화된 채널(SASL_SSL)을 사용할 수 있습니다.
3
ssl. 속성은 TLS 구성을 정의합니다.
4
임의 번호 생성기 구현. 설정하지 않으면 Java 플랫폼 SDK 기본값이 사용됩니다.
5
호스트 이름 확인 빈 문자열로 설정하면 호스트 이름 확인이 해제됩니다. 설정되지 않은 경우 기본값은 HTTPS로, 서버 인증서에 대한 호스트 이름 확인을 적용합니다.
6
리스너의 키 저장소 경로입니다.
7
리스너의 신뢰 저장소 경로입니다.
8
TLS 연결을 설정할 때 REPLICATION 리스너의 클라이언트가 클라이언트 인증서로 인증되도록 지정합니다(브러 간 연결에 사용됨).
9
OAuth 2.0의 CLIENT 리스너를 구성합니다. 권한 부여 서버와의 연결은 보안 HTTPS 연결을 사용해야 합니다.

다음 예제에서는 SASL을 통해 인증 정보를 교환하기 위한 PLAIN 인증 메커니즘을 사용한 OAuth 2.0 인증에 대한 최소 구성을 보여줍니다. 빠른 로컬 토큰 검증이 사용됩니다.

예: PLAIN 인증을 위한 최소 리스너 구성

listeners=CLIENT://0.0.0.0:9092
1 

listener.security.protocol.map=CLIENT:SASL_PLAINTEXT
2 

listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER,PLAIN
3 

sasl.mechanism.inter.broker.protocol=OAUTHBEARER
4 

inter.broker.listener.name=CLIENT
5 

listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
6 

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
7 

  oauth.valid.issuer.uri="http://AUTH_SERVER/auth/realms/REALM" \
8 

  oauth.jwks.endpoint.uri="https://AUTH_SERVER/auth/realms/REALM/protocol/openid-connect/certs" \
9 

  oauth.username.claim="preferred_username"  \
10 

  oauth.client.id="kafka-broker" \
11 

  oauth.client.secret="kafka-secret" \
12 

  oauth.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/token" ;
13 

listener.name.client.oauthbearer.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
14 

listener.name.client.plain.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.plain.JaasServerOauthOverPlainValidatorCallbackHandler
15 

listener.name.client.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \
16 

  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \
17 

  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \
18 

  oauth.username.claim="preferred_username"  \
19 

  oauth.token.endpoint.uri="http://AUTH_SERVER/auth/realms/REALM/protocol/openid-connect/token" ;
20 

connections.max.reauth.ms=3600000
21
Copy to Clipboard Toggle word wrap

1
클라이언트 애플리케이션이 연결할 리스너(이 예에서는 CLIENT )를 구성합니다. 시스템 호스트 이름은 공개된 호스트 이름으로 사용되며, 다시 연결하기 위해 클라이언트가 확인해야 합니다. 이 리스너는 유일하게 구성된 리스너이므로 상호 통신에도 사용됩니다.
2
암호화되지 않은 채널을 통해 SASL을 사용하도록 예제 CLIENT 리스너를 구성합니다. 프로덕션 환경에서 클라이언트는 TCP 연결 계층에서 도청 및 인터셉션을 방지하기 위해 암호화된 채널(SASL_SSL)을 사용해야 합니다.
3
SASL 및 OAUTHBEARER 를 통해 인증 정보를 교환하는 데 PLAIN 인증 메커니즘을 활성화합니다. OAUTHBEARER는 또한 상호 통신에 필요하기 때문에 지정됩니다. Kafka 클라이언트는 연결할 메커니즘을 선택할 수 있습니다.

PLAIN 인증은 모든 플랫폼의 모든 클라이언트에서 지원됩니다. Kafka 클라이언트는 PLAIN 메커니즘을 활성화하고 사용자 이름과 암호를 설정해야 합니다. PLAIN은 OAuth 액세스 토큰 또는 OAuth clientId 및 secret (클라이언트 인증 정보)을 사용하여 인증하는 데 사용할 수 있습니다. 이 동작은 oauth.token.endpoint.uri 가 지정되었는지 여부에 따라 추가로 제어됩니다.

oauth.token.endpoint.uri 가 지정되고 클라이언트가 $accessToken: 문자열로 시작하도록 password 를 설정하는 경우 서버는 암호를 액세스 토큰으로 해석하고 사용자 이름을 계정 사용자 이름으로 해석합니다. 그렇지 않으면 사용자 이름이 clientId 로 해석되고, 브로커가 클라이언트 이름에서 액세스 토큰을 가져오는 데 사용하는 클라이언트 시크릿.

oauth.token.endpoint.uri 를 지정하지 않으면 암호 가 항상 액세스 토큰으로 해석되고 사용자 이름은 항상 토큰에서 추출된 주체 ID와 일치해야 합니다. 클라이언트가 항상 액세스 토큰을 직접 가져와야 하며 clientId 및 secret 을 사용할 수 없기 때문에 'no-client-credentials' 모드라고 합니다.

4
broker 간 통신을 위한 OAUTHBEARER 인증 메커니즘을 지정합니다.
5
broker 간 통신을 위한 리스너(이 예에서는 CLIENT )를 지정합니다. 구성이 유효한 데 필요합니다.
6
OAUTHBEARER 메커니즘에 대한 서버 콜백 핸들러를 구성합니다.
7
OAUTHBEARER 메커니즘을 사용하여 클라이언트 및 브랜드 간 통신에 대한 인증 설정을 구성합니다. oauth.client.id,oauth.client.secret 및 oauth.token.endpoint.uri 속성은broker 간 구성과 관련이 있습니다.
8
유효한 발행자 URI입니다. 이 발행자의 액세스 토큰만 허용됩니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME
9
JWKS 엔드포인트 URL입니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs
10
토큰에 실제 사용자 이름이 포함된 토큰 클레임(또는 키)입니다. 사용자 이름은 사용자를 식별하는 주체 입니다. 값은 인증 흐름 및 사용되는 권한 부여 서버에 따라 다릅니다.
11
모든 브로커에 대해 동일한 Kafka 브로커의 클라이언트 ID입니다. 이 클라이언트는 권한 부여 서버에 kafka-broker로 등록된 클라이언트 입니다.
12
Kafka 브로커의 시크릿(모든 브로커에 대해 동일)
13
권한 부여 서버의 OAuth 2.0 토큰 끝점 URL입니다. 프로덕션의 경우 항상 HTTPS를 사용합니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token
14
브랜드 간 통신을 위해 OAuth 2.0 인증을 활성화합니다.
15
PLAIN 인증에 대한 서버 콜백 처리기를 구성합니다.
16
PLAIN 인증을 사용하여 클라이언트 통신에 대한 인증 설정을 구성합니다.

OAuth.token.endpoint.uri 는 OAuth 2.0 클라이언트 인증 정보 메커니즘을 사용하여 PLAIN을 통해 OAuth 2.0 을 활성화하는 선택적 속성입니다.

17
유효한 발행자 URI입니다. 이 발행자의 액세스 토큰만 허용됩니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME
18
JWKS 엔드포인트 URL입니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs
19
토큰에 실제 사용자 이름이 포함된 토큰 클레임(또는 키)입니다. 사용자 이름은 사용자를 식별하는 주체 입니다. 값은 인증 흐름 및 사용된 권한 부여 서버에 따라 다릅니다.
20
권한 부여 서버의 OAuth 2.0 토큰 끝점 URL입니다. 프로덕션의 경우 항상 HTTP를 사용합니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token

포인트 3에 설명된 대로 clientId 및 secret 을 사용자 이름 및 암호로 전달하여 클라이언트를 인증할 수 있는 PLAIN 메커니즘에 대한 추가 구성입니다. 지정하지 않으면 클라이언트는 액세스 토큰을 password 매개변수로 전달하여 PLAIN을 통해 인증할 수 있습니다.

21
(선택 사항) 토큰이 만료될 때 세션 만료를 강제 적용하고 Kafka 재인증 메커니즘 도 활성화합니다. 지정된 값이 액세스 토큰이 만료될 때까지 남은 시간보다 작으면 클라이언트는 실제 토큰 만료 전에 다시 인증해야 합니다. 기본적으로 액세스 토큰이 만료되고 클라이언트가 재인증을 시도하지 않으면 세션이 만료되지 않습니다.
4.10.2.3. 빠른 로컬 JWT 토큰 검증 구성
링크 복사

빠른 로컬 JWT 토큰 검증은 JWT 토큰 서명을 로컬로 확인합니다.

로컬 검사에서는 토큰이 있는지 확인합니다.

  • 액세스 토큰에 대한 Bearer 의 (typ) 클레임 값을 포함하여 유형 준수
  • 유효함 (종료되지 않음)
  • 유효한IssuerURI와 일치하는 발행자가 있음

권한 부여 서버에서 발행하지 않은 토큰이 거부되도록 리스너를 구성할 때 유효한 발행자 URI 를 지정합니다.

빠른 로컬 JWT 토큰 검증 중에 권한 부여 서버에 연결할 필요가 없습니다. OAuth 2.0 권한 부여 서버에서 노출하는 JWKs 엔드포인트 URI 를 지정하여 빠른 로컬 JWT 토큰 검증을 활성화합니다. 엔드포인트에는 Kafka 클라이언트가 인증 정보로 전송되는 서명된 JWT 토큰의 유효성을 검사하는 데 사용되는 공개 키가 포함되어 있습니다.

참고

권한 부여 서버와의 모든 통신은 HTTPS를 사용하여 수행해야 합니다.

TLS 리스너의 경우 인증서 신뢰 저장소를 구성하고 truststore 파일을 가리킬 수 있습니다.

빠른 로컬 JWT 토큰 검증을 위한 속성의 예

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS" \
1 

  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/jwks" \
2 

  oauth.jwks.refresh.seconds="300" \
3 

  oauth.jwks.refresh.min.pause.seconds="1" \
4 

  oauth.jwks.expiry.seconds="360" \
5 

  oauth.username.claim="preferred_username" \
6 

  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
7 

  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
8 

  oauth.ssl.truststore.type="PKCS12" ;
9
Copy to Clipboard Toggle word wrap

1
유효한 발행자 URI입니다. 이 발행자가 발행한 액세스 토큰만 허용됩니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME.
2
JWKS 엔드포인트 URL입니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs.
3
엔드포인트 새로 고침 간격(기본값 300).
4
JWKS 공개 키를 새로 고치는 시도 사이의 최소 일시 중지 시간(초)입니다. 알 수 없는 서명 키가 발생하면 JWKS 키 새로 고침이 마지막 새로 고침 시도 이후 지정된 일시 중지를 사용하여 정기적인 스케줄 외부에 예약됩니다. 키를 새로 고치는 것은 exponential backoff 규칙을 따르고, oauth.jwks.refresh.seconds 에 도달할 때까지 일시 중지를 늘리면 실패한 새로 고침을 다시 시도합니다. 기본값은 1입니다.
5
JWKs 인증서가 만료되기 전에 유효한 것으로 간주됩니다. 기본값은 360 초입니다. 더 긴 시간을 지정하면 취소된 인증서에 대한 액세스를 허용할 위험을 고려하십시오.
6
토큰에 실제 사용자 이름이 포함된 토큰 클레임(또는 키)입니다. 사용자 이름은 사용자를 식별하는 데 사용되는 주체 입니다. 값은 인증 흐름 및 사용된 권한 부여 서버에 따라 달라집니다.
7
TLS 구성에 사용되는 신뢰 저장소의 위치입니다.
8
신뢰 저장소에 액세스하기 위한 암호입니다.
9
PKCS #12 형식의 truststore 유형입니다.
4.10.2.4. OAuth 2.0 인트로스펙션 엔드 포인트 구성
링크 복사

OAuth 2.0 인트로스펙션 엔드포인트를 사용하는 토큰 검증은 수신된 액세스 토큰을 불투명으로 처리합니다. Kafka 브로커는 검증에 필요한 토큰 정보로 응답하는 인트로스펙션 엔드포인트에 액세스 토큰 토큰을 보냅니다. 중요한 것은 특정 액세스 토큰이 유효한 경우 최신 정보와 토큰이 만료되는 시기에 대한 정보를 반환합니다.

OAuth 2.0 인트로스펙션 기반 검증을 구성하려면 빠른 로컬 JWT 토큰 검증에 지정된 JWKs 엔드포인트 URI 대신 인트로스펙션 엔드포인트 URI를 지정합니다. 인증 서버에 따라 인트로스펙션 엔드포인트가 일반적으로 보호되므로 일반적으로 클라이언트 ID 및 클라이언트 시크릿 을 지정해야 합니다.

인트로스펙션 끝점의 속성 예

listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.introspection.endpoint.uri="https://AUTH-SERVER-ADDRESS/introspection" \
1 

  oauth.client.id="kafka-broker" \
2 

  oauth.client.secret="kafka-broker-secret" \
3 

  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
4 

  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
5 

  oauth.ssl.truststore.type="PKCS12" \
6 

  oauth.username.claim="preferred_username" ;
7
Copy to Clipboard Toggle word wrap

1
OAuth 2.0 인트로스펙션 엔드포인트 URI입니다. 예: https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token/introspect.
2
Kafka 브로커의 클라이언트 ID입니다.
3
Kafka 브로커의 시크릿입니다.
4
TLS 구성에 사용되는 신뢰 저장소의 위치입니다.
5
신뢰 저장소에 액세스하기 위한 암호입니다.
6
PKCS #12 형식의 truststore 유형입니다.
7
토큰에 실제 사용자 이름이 포함된 토큰 클레임(또는 키)입니다. 사용자 이름은 사용자를 식별하는 데 사용되는 주체 입니다. oauth.username.claim 의 값은 사용된 권한 부여 서버에 따라 다릅니다.

4.10.3. Kafka 브로커에 대한 세션 재인증
링크 복사

Kafka 클라이언트와 Kafka 브로커 간의 OAuth 2.0 세션에 Kafka 세션 재인증 을 사용하도록 OAuth 리스너를 구성할 수 있습니다. 이 메커니즘은 정의된 기간 후에 클라이언트와 브로커 간에 인증된 세션 만료를 적용합니다. 세션이 만료되면 클라이언트는 기존 연결을 삭제하는 대신 다시 사용하여 새 세션을 즉시 시작합니다.

세션 재인증은 기본적으로 비활성화되어 있습니다. server.properties 파일에서 이를 활성화할 수 있습니다. OAUTHBEARER 또는 PLAIN이 SASL 메커니즘으로 활성화된 TLS 리스너에 대해 connections.max.reauth.ms 속성을 설정합니다.

리스너당 세션 재인증을 지정할 수 있습니다. 예를 들면 다음과 같습니다. 

listener.name.client.oauthbearer.connections.max.reauth.ms=3600000
Copy to Clipboard Toggle word wrap

세션 재인증은 클라이언트에서 사용하는 Kafka 클라이언트 라이브러리에서 지원해야 합니다.

세션 재인증은 빠른 로컬 JWT 또는 인트로스펙션 엔드포인트 토큰 검증과 함께 사용할 수 있습니다.

클라이언트 재인증

브로커의 인증된 세션이 만료되면 연결을 삭제하지 않고 새 유효한 액세스 토큰을 브로커에 전송하여 클라이언트가 기존 세션으로 다시 인증해야 합니다.

토큰 유효성 검사가 성공하면 기존 연결을 사용하여 새 클라이언트 세션이 시작됩니다. 클라이언트가 다시 인증되지 않으면 메시지를 보내거나 수신하려고 하면 브로커가 연결을 종료합니다. Kafka 클라이언트 라이브러리 2.2 이상을 사용하는 Java 클라이언트는 브로커에서 재인증 메커니즘이 활성화된 경우 자동으로 다시 인증됩니다.

세션 재인증은 사용되는 경우 토큰 새로 고침에도 적용됩니다. 세션이 만료되면 클라이언트는 새로 고침 토큰을 사용하여 액세스 토큰을 새로 고칩니다. 그런 다음 클라이언트는 새 액세스 토큰을 사용하여 기존 연결을 다시 인증합니다.

OAUTHBEARER 및 PLAIN의 세션 만료

세션 재인증이 구성되면 OAUTHBEARER 및 PLAIN 인증에 대해 세션 만료가 다르게 작동합니다.

OAUTHBEARER 및 PLAIN의 경우 클라이언트 ID 및 시크릿 방법을 사용합니다.

  • 브로커의 인증된 세션은 구성된 connections.max.reauth.ms 에서 만료됩니다.
  • 구성된 시간 전에 액세스 토큰이 만료되면 세션이 이전에 만료됩니다.

장기 액세스 토큰 방법을 사용하는 PLAIN의 경우:

  • 브로커의 인증된 세션은 구성된 connections.max.reauth.ms 에서 만료됩니다.
  • 구성된 시간 전에 액세스 토큰이 만료되면 재인증이 실패합니다. 세션 재인증이 시도되었지만 PLAIN에는 토큰을 새로 고치는 메커니즘이 없습니다.

connections.max.reauth.ms 가 구성되지 않은 경우 OAUTHBEARER 및 PLAIN 클라이언트는 다시 인증할 필요 없이 브로커에 무기한 연결을 유지할 수 있습니다. 인증된 세션은 액세스 토큰 만료로 끝나지 않습니다. 그러나 예를 들어 keycloak 권한 부여를 사용하거나 사용자 정의 승인기를 설치하여 권한을 구성할 때 이를 고려할 수 있습니다.

추가 리소스

4.10.4. OAuth 2.0 Kafka 클라이언트 구성
링크 복사

Kafka 클라이언트는 다음 중 하나로 구성됩니다.

  • 유효한 액세스 토큰을 얻기 위해 권한 부여 서버로 인증하는 데 필요한 인증 정보(클라이언트 ID 및 시크릿)
  • 권한 부여 서버에서 제공하는 툴을 사용하여 얻은 유효한 장기 액세스 토큰 또는 새로 고침 토큰

Kafka 브로커로 전송된 유일한 정보는 액세스 토큰입니다. 권한 부여 서버로 인증하는 데 사용되는 인증 정보는 브로커로 전송되지 않습니다. 클라이언트에서 액세스 토큰을 가져올 때 권한 부여 서버와의 추가 통신이 필요하지 않습니다.

가장 간단한 메커니즘은 클라이언트 ID 및 시크릿을 사용한 인증입니다. 장기 액세스 토큰 또는 수명이 긴 새로 고침 토큰을 사용하면 권한 부여 서버 도구에 대한 추가 종속성이 있기 때문에 복잡성이 향상됩니다.

참고

장기 액세스 토큰을 사용하는 경우 토큰의 최대 수명을 늘리려면 권한 부여 서버에서 클라이언트를 구성해야 할 수 있습니다.

Kafka 클라이언트가 액세스 토큰으로 직접 구성되지 않은 경우 클라이언트는 권한 부여 서버에 연결하여 Kafka 세션 시작 중에 액세스 토큰에 대한 인증 정보를 교환합니다. Kafka 클라이언트 교환:

  • 클라이언트 ID 및 시크릿
  • 클라이언트 ID, 새로 고침 토큰, 시크릿(선택 사항)

4.10.5. OAuth 2.0 클라이언트 인증 흐름
링크 복사

이 섹션에서는 Kafka 세션 시작 중에 Kafka 클라이언트, Kafka 브로커 및 권한 부여 서버 간의 통신 흐름을 설명하고 시각화합니다. 흐름은 클라이언트 및 서버 구성에 따라 달라집니다.

Kafka 클라이언트가 Kafka 브로커에 인증 정보로 액세스 토큰을 전송하는 경우 토큰의 유효성을 검사해야 합니다.

사용된 권한 부여 서버와 사용 가능한 구성 옵션에 따라 다음을 사용하는 것이 좋습니다.

  • 권한 부여 서버에 연결하지 않고 JWT 서명 확인 및 로컬 토큰 인트로스펙션을 기반으로 하는 빠른 로컬 토큰 검증
  • 권한 부여 서버에서 제공하는 OAuth 2.0 인트로스펙션 엔드 포인트

빠른 로컬 토큰 검증을 사용하려면 권한 부여 서버에서 토큰의 서명을 확인하는 데 사용되는 공개 인증서를 JWKS 엔드포인트에 제공해야 합니다.

또 다른 옵션은 권한 부여 서버에서 OAuth 2.0 인트로스펙션 엔드포인트를 사용하는 것입니다. 새 Kafka 브로커 연결이 설정될 때마다 브로커는 클라이언트에서 수신된 액세스 토큰을 권한 부여 서버로 전달하고, 토큰이 유효한지 여부를 확인하는 응답을 확인합니다.

Kafka 클라이언트 인증 정보는 다음을 위해 구성할 수도 있습니다.

  • 이전에 생성된 장기 액세스 토큰을 사용하여 로컬 액세스 직접
  • 새 액세스 토큰을 발행하려면 권한 부여 서버와 연락처
참고

권한 부여 서버는 불투명 액세스 토큰만 사용할 수 있으므로 로컬 토큰 유효성 검사는 사용할 수 없습니다.

4.10.5.1. 클라이언트 인증 흐름의 예
링크 복사

여기에서 Kafka 세션 인증 중에 Kafka 클라이언트 및 브로커의 다양한 구성에 대한 통신 흐름을 확인할 수 있습니다.

브로커에서 인증 서버에 검증을 위임하는 클라이언트 ID와 시크릿을 사용하는 클라이언트

Client using client ID and secret with broker delegating validation to authorization server

  1. Kafka 클라이언트는 인증 서버에서 클라이언트 ID 및 시크릿을 사용하고 필요한 경우 새로 고침 토큰을 사용하여 액세스 토큰에 액세스하도록 요청합니다.
  2. 권한 부여 서버는 새 액세스 토큰을 생성합니다.
  3. Kafka 클라이언트는 SASL OAUTHBEARER 메커니즘을 사용하여 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
  4. Kafka 브로커는 자체 클라이언트 ID와 시크릿을 사용하여 권한 부여 서버에서 토큰 인트로스펙션 엔드포인트를 호출하여 액세스 토큰을 검증합니다.
  5. 토큰이 유효한 경우 Kafka 클라이언트 세션이 설정됩니다.

브로커가 빠른 로컬 토큰 검증을 수행하는 클라이언트 ID 및 시크릿을 사용하는 클라이언트

Client using client ID and secret with broker performing fast local token validation

  1. Kafka 클라이언트는 클라이언트 ID 및 시크릿을 사용하여 토큰 끝점의 권한 부여 서버와 필요한 경우 새로 고침 토큰을 사용하여 인증합니다.
  2. 권한 부여 서버는 새 액세스 토큰을 생성합니다.
  3. Kafka 클라이언트는 SASL OAUTHBEARER 메커니즘을 사용하여 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
  4. Kafka 브로커는 JWT 토큰 서명 확인 및 로컬 토큰 인트로스펙션을 사용하여 액세스 토큰을 로컬로 검증합니다.

브로커로 권한 부여 서버에 검증을 위임하는 장기 액세스 토큰을 사용하는 클라이언트

Client using long-lived access token with broker delegating validation to authorization server

  1. Kafka 클라이언트는 SASL OAUTHBEARER 메커니즘을 사용하여 장기 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
  2. Kafka 브로커는 자체 클라이언트 ID와 시크릿을 사용하여 권한 부여 서버에서 토큰 인트로스펙션 엔드포인트를 호출하여 액세스 토큰을 검증합니다.
  3. 토큰이 유효한 경우 Kafka 클라이언트 세션이 설정됩니다.

브로커가 빠른 로컬 유효성 검사를 수행하는 장기 액세스 토큰을 사용하는 클라이언트

Client using long-lived access token with broker performing fast local validation

  1. Kafka 클라이언트는 SASL OAUTHBEARER 메커니즘을 사용하여 장기 액세스 토큰을 전달하는 Kafka 브로커로 인증합니다.
  2. Kafka 브로커는 JWT 토큰 서명 확인 및 로컬 토큰 인트로스펙션을 사용하여 액세스 토큰을 로컬로 검증합니다.
주의

빠른 로컬 JWT 토큰 서명 검증은 토큰이 취소된 경우 권한 부여 서버와 확인되지 않으므로 수명이 짧은 토큰에만 적합합니다. 토큰 만료는 토큰에 기록되지만 취소는 언제든지 발생할 수 있으므로 권한 부여 서버에 연결하지 않아도 됩니다. 발행된 토큰은 만료될 때까지 유효한 것으로 간주됩니다.

4.10.6. OAuth 2.0 인증 구성
링크 복사

OAuth 2.0은 Kafka 클라이언트와 AMQ Streams 구성 요소 간의 상호 작용에 사용됩니다.

AMQ Streams에 OAuth 2.0을 사용하려면 다음을 수행해야 합니다.

  1. AMQ Streams 클러스터 및 Kafka 클라이언트에 대한 OAuth 2.0 권한 부여 서버 구성
  2. OAuth 2.0을 사용하도록 구성된 Kafka 브로커 리스너를 사용하여 Kafka 클러스터를 배포하거나 업데이트합니다.
  3. OAuth 2.0을 사용하도록 Java 기반 Kafka 클라이언트를 업데이트
4.10.6.1. Red Hat Single Sign-On을 OAuth 2.0 인증 서버로 구성
링크 복사

다음 절차에서는 Red Hat Single Sign-On을 인증 서버로 배포하고 AMQ Streams와의 통합을 위해 구성하는 방법을 설명합니다.

권한 부여 서버는 인증 및 권한 부여와 사용자, 클라이언트 및 권한 관리를 위한 중앙 지점을 제공합니다. Red Hat Single Sign-On에는 영역이 별도의 사용자, 클라이언트, 권한 및 기타 구성을 나타내는 영역 개념이 있습니다. 기본 마스터 영역을 사용하거나 새 마스터 영역을 생성할 수 있습니다. 각 영역은 자체 OAuth 2.0 엔드포인트를 노출합니다. 즉, 애플리케이션 클라이언트와 애플리케이션 서버가 모두 동일한 영역을 사용해야 합니다.

AMQ Streams와 함께 OAuth 2.0을 사용하려면 인증 영역을 생성하고 관리할 수 있도록 권한 부여 서버를 배포해야 합니다.

참고

Red Hat Single Sign-On이 이미 배포된 경우 배포 단계를 건너뛰고 현재 배포를 사용할 수 있습니다.

사전 준비 사항

Red Hat Single Sign-On 사용에 대해 잘 알고 있어야 합니다.

설치 및 관리 지침은 다음을 참조하십시오.

사전 요구 사항

  • AMQ Streams 및 Kafka가 실행 중입니다.

Red Hat Single Sign-On 배포의 경우:

프로세스

  1. Red Hat Single Sign-On 설치.

    ZIP 파일에서 설치하거나 RPM을 사용하여 설치할 수 있습니다.

  2. Red Hat Single Sign-On 관리 콘솔에 로그인하여 AMQ Streams에 대한 OAuth 2.0 정책을 생성합니다.

    Red Hat Single Sign-On을 배포할 때 로그인 세부 정보가 제공됩니다.

  3. 영역을 생성하고 활성화합니다.

    기존 마스터 영역을 사용할 수 있습니다.

  4. 필요한 경우 영역의 세션 및 토큰 타임아웃을 조정합니다.
  5. kafka-broker 라는 클라이언트를 생성합니다.

  6. 설정 탭에서 다음을 설정합니다.

    • 액세스 유형 ( Confidential)
    • 이 클라이언트에 대한 웹 로그인을 비활성화하려면 표준 흐름을 OFF 로 활성화
    • 이 클라이언트가 고유한 이름으로 인증할 수 있도록 활성화됨
  7. 계속하기 전에 저장을 클릭합니다.
  8. Credentials 탭에서 AMQ Streams Kafka 클러스터 구성에서 사용할 시크릿을 기록합니다.

  9. Kafka 브로커에 연결할 모든 애플리케이션 클라이언트에 대해 클라이언트 생성 단계를 반복합니다.

    각 새 클라이언트에 대한 정의를 생성합니다.

    구성에서 이름을 클라이언트 ID로 사용합니다.

다음에 수행할 작업

권한 부여 서버를 배포하고 구성한 후 OAuth 2.0을 사용하도록 Kafka 브로커를 구성합니다.

4.10.6.2. Kafka 브로커에 대한 OAuth 2.0 지원 구성
링크 복사

다음 절차에서는 브로커 리스너가 권한 부여 서버를 사용하여 OAuth 2.0 인증을 사용하도록 Kafka 브로커를 구성하는 방법을 설명합니다.

TLS 리스너 구성을 통해 암호화된 인터페이스를 통해 OAuth 2.0을 사용하는 것이 좋습니다. 일반 리스너는 권장되지 않습니다.

선택한 권한 부여 서버를 지원하는 속성과 구현 중인 권한 부여 유형을 사용하여 Kafka 브로커를 구성합니다.

시작하기 전

Kafka 브로커 리스너의 구성 및 인증에 대한 자세한 내용은 다음을 참조하십시오.

리스너 구성에 사용되는 속성에 대한 설명은 다음을 참조하십시오.

사전 요구 사항

  • AMQ Streams 및 Kafka가 실행 중입니다.
  • OAuth 2.0 인증 서버가 배포됨

프로세스

  1. server.properties 파일에서 Kafka 브로커 리스너 구성을 구성합니다.

    예를 들어 OAUTHBEARER 메커니즘을 사용합니다. 

    sasl.enabled.mechanisms=OAUTHBEARER
listeners=CLIENT://0.0.0.0:9092
listener.security.protocol.map=CLIENT:SASL_PLAINTEXT
listener.name.client.sasl.enabled.mechanisms=OAUTHBEARER
sasl.mechanism.inter.broker.protocol=OAUTHBEARER
inter.broker.listener.name=CLIENT
listener.name.client.oauthbearer.sasl.server.callback.handler.class=io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
listener.name.client.oauthbearer.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
    Copy to Clipboard Toggle word wrap

  2. broker 연결 설정을 listener.name.client.oauthbearer.sasl.jaas.config 의 일부로 구성합니다.

    이 예제에서는 연결 구성 옵션을 보여줍니다.

    예 1: JWKS 엔드포인트 구성을 사용한 로컬 토큰 검증

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.valid.issuer.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME" \
  oauth.jwks.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/certs" \
  oauth.jwks.refresh.seconds="300" \
  oauth.jwks.refresh.min.pause.seconds="1" \
  oauth.jwks.expiry.seconds="360" \
  oauth.username.claim="preferred_username" \
  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
  oauth.ssl.truststore.type="PKCS12" ;
listener.name.client.oauthbearer.connections.max.reauth.ms=3600000
    Copy to Clipboard Toggle word wrap

    예 2: OAuth 2.0 인트로스펙션 끝점을 통해 인증 서버에 토큰 검증 위임

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  oauth.introspection.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/introspection" \
  # ...
    Copy to Clipboard Toggle word wrap

  3. 필요한 경우 권한 부여 서버에 대한 액세스를 구성합니다.

    서비스 메시 와 같은 기술을 사용하여 컨테이너 외부의 보안 채널을 구성하지 않는 한 일반적으로 프로덕션 환경에 이 단계가 필요합니다.

    1. 보안 권한 부여 서버에 연결하기 위한 사용자 정의 신뢰 저장소를 제공합니다. 권한 부여 서버에 액세스하려면 항상 SSL이 필요합니다.

      속성을 설정하여 신뢰 저장소를 구성합니다.

      예를 들면 다음과 같습니다. 

      listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  # ...
  oauth.client.id="kafka-broker" \
  oauth.client.secret="kafka-broker-secret" \
  oauth.ssl.truststore.location="PATH-TO-TRUSTSTORE-P12-FILE" \
  oauth.ssl.truststore.password="TRUSTSTORE-PASSWORD" \
  oauth.ssl.truststore.type="PKCS12" ;
      Copy to Clipboard Toggle word wrap

    2. 인증서 호스트 이름이 액세스 URL 호스트 이름과 일치하지 않으면 인증서 호스트 이름 검증을 끌 수 있습니다. 

      oauth.ssl.endpoint.identification.algorithm=""
      Copy to Clipboard Toggle word wrap

      검사를 통해 권한 부여 서버에 대한 클라이언트 연결이 정품인지 확인합니다. 비프로덕션 환경에서 검증을 해제할 수 있습니다.

  4. 선택한 인증 흐름에 따라 추가 속성을 구성합니다. 

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  # ...
  oauth.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token" \
    1 
    
  oauth.custom.claim.check="@.custom == 'custom-value'" \
    2 
    
  oauth.scope="SCOPE" \
    3 
    
  oauth.check.audience="true" \
    4 
    
  oauth.audience="AUDIENCE" \
    5 
    
  oauth.valid.issuer.uri="https://https://AUTH-SERVER-ADDRESS/auth/REALM-NAME" \
    6 
    
  oauth.client.id="kafka-broker" \
    7 
    
  oauth.client.secret="kafka-broker-secret" \
    8 
    
  oauth.refresh.token="REFRESH-TOKEN-FOR-KAFKA-BROKERS" \
    9 
    
  oauth.access.token="ACCESS-TOKEN-FOR-KAFKA-BROKERS" ;
    10
    Copy to Clipboard Toggle word wrap
    1
    권한 부여 서버의 OAuth 2.0 토큰 끝점 URL입니다. 프로덕션의 경우 항상 HTTP를 사용합니다. KeycloakRBACAuthorizer 를 사용하거나 OAuth 2.0이 활성화된 리스너가 뇌 간 통신에 사용되는 경우 필요합니다.
    2
    (선택 사항) 사용자 정의 클레임 검사. 검증 중에 JWT 액세스 토큰에 추가 사용자 지정 규칙을 적용하는 JsonPath 필터 쿼리입니다. 액세스 토큰에 필요한 데이터가 포함되어 있지 않으면 거부됩니다. 인트로스펙션 엔드포인트 방법을 사용하는 경우 사용자 정의 검사가 인트로스펙션 엔드포인트 응답 JSON에 적용됩니다.
    3
    (선택 사항) 토큰 끝점에 전달되는 scope 매개변수입니다. 범위는 broker 간 인증을 위한 액세스 토큰을 가져올 때 사용됩니다. clientId 및 secret 을 사용하는 PLAIN 클라이언트 인증의 OAuth 2.0용 클라이언트 이름에도 사용됩니다. 이는 권한 부여 서버에 따라 토큰과 토큰의 콘텐츠에만 영향을 미칩니다. 리스너의 토큰 검증 규칙에는 영향을 미치지 않습니다.
    4
    (선택 사항) Audience 확인 권한 부여 서버가 aud (audience) 클레임을 제공하고 대상 검사를 적용하려는 경우 ouath.check.audience 를 true 로 설정합니다. 대상 검사에서는 의도된 토큰 수신자를 식별합니다. 결과적으로 Kafka 브로커는 aud 클레임에 clientId 가 없는 토큰을 거부합니다. 기본값은 false 입니다.
    5
    (선택 사항) 토큰 끝점에 전달되는 대상 매개변수입니다. 대상 은broker 간 인증을 위한 액세스 토큰을 가져올 때 사용됩니다. clientId 및 secret 을 사용하는 PLAIN 클라이언트 인증의 OAuth 2.0용 클라이언트 이름에도 사용됩니다. 이는 권한 부여 서버에 따라 토큰과 토큰의 콘텐츠에만 영향을 미칩니다. 리스너의 토큰 검증 규칙에는 영향을 미치지 않습니다.
    6
    유효한 발행자 URI입니다. 이 발행자가 발행한 액세스 토큰만 허용됩니다. (필수 사항)
    7
    모든 브로커에 대해 동일한 Kafka 브로커의 구성된 클라이언트 ID입니다. 이 클라이언트는 권한 부여 서버에 kafka-broker로 등록된 클라이언트 입니다. 인트로스펙션 엔드포인트가 토큰 검증에 사용되거나 KeycloakRBACAuthorizer 가 사용되는 경우 필요합니다.
    8
    모든 브로커에 대해 동일한 Kafka 브로커에 대해 구성된 시크릿입니다. 브로커가 권한 부여 서버에 인증해야 하는 경우 클라이언트 시크릿에 액세스 토큰 또는 새로 고침 토큰을 지정해야 합니다.
    9
    (선택 사항) Kafka 브로커의 장기 새로 고침 토큰입니다.
    10
    (선택 사항) Kafka 브로커를 위한 장기 액세스 토큰입니다.

  5. OAuth 2.0 인증을 적용하는 방법과 사용 중인 인증 서버 유형에 따라 추가 구성 설정을 추가합니다. 

    listener.name.client.oauthbearer.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  # ...
  oauth.check.issuer=false \
    1 
    
  oauth.fallback.username.claim="CLIENT-ID" \
    2 
    
  oauth.fallback.username.prefix="CLIENT-ACCOUNT" \
    3 
    
  oauth.valid.token.type="bearer" \
    4 
    
  oauth.userinfo.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/userinfo" ;
    5
    Copy to Clipboard Toggle word wrap
    1
    권한 부여 서버에서 iss 클레임을 제공하지 않으면 발급자 검사를 수행할 수 없습니다. 이 경우 oauth.check.issuer 를 false 로 설정하고 oauth.valid.issuer.uri 를 지정하지 마십시오. 기본값은 true 입니다.
    2
    권한 부여 서버는 일반 사용자와 클라이언트를 모두 식별하는 단일 속성을 제공하지 않을 수 있습니다. 클라이언트가 자체 이름으로 인증하면 서버에서 클라이언트 ID 를 제공할 수 있습니다. 사용자가 사용자 이름과 암호를 사용하여 인증하는 경우 새로 고침 토큰 또는 액세스 토큰을 가져오기 위해 서버에서 클라이언트 ID 외에 username 속성을 제공할 수 있습니다. 기본 사용자 ID 속성을 사용할 수 없는 경우 사용할 사용자 이름 클레임(attribute)을 지정하려면 이 대체 옵션을 사용합니다.
    3
    oauth.fallback.username.claim 이 적용되는 경우 사용자 이름 클레임 값과 대체 사용자 이름 클레임의 이름 충돌을 방지할 수도 있습니다. producer 라는 클라이언트가 존재하지만 producer 라는 일반 사용자도 존재하는 상황을 고려하십시오. 이 속성을 사용하여 클라이언트의 사용자 ID에 접두사를 추가할 수 있습니다.
    4
    ( oauth.introspection.endpoint.uri) 사용 중인 권한 부여 서버에 따라 인트로스펙션 엔드 포인트가 토큰 유형 속성을 반환하거나 반환하지 않거나 다른 값을 포함할 수 있습니다. 인트로스펙션 끝점의 응답에 포함되어야 하는 유효한 토큰 유형 값을 지정할 수 있습니다.
    5
    ( oauth.introspection.endpoint.uri) 사용 시에만 적용할 수 있습니다. 인증 서버는 인트로스펙션 엔드포인트 응답에서 식별 가능한 정보를 제공하지 않기 위해 인증 서버를 구성하거나 구현할 수 있습니다. 사용자 ID를 얻으려면 userinfo 끝점의 URI를 폴백으로 구성할 수 있습니다. oauth.fallback.username.claim,oauth.fallback.username.claim, oauth.fallback.username.prefix 설정은 userinfo 엔드포인트 응답에 적용됩니다.

다음에 수행할 작업

4.10.6.3. OAuth 2.0을 사용하도록 Kafka Java 클라이언트 구성
링크 복사

다음 절차에서는 Kafka 브로커와의 상호 작용에 OAuth 2.0을 사용하도록 Kafka 생산자 및 소비자 API를 구성하는 방법을 설명합니다.

pom.xml 파일에 클라이언트 콜백 플러그인을 추가하고 시스템 속성을 구성합니다.

사전 요구 사항

  • AMQ Streams 및 Kafka가 실행 중입니다.
  • OAuth 2.0 권한 부여 서버가 Kafka 브로커에 대한 OAuth 액세스용으로 배포 및 구성됨
  • Kafka 브로커는 OAuth 2.0으로 구성되어 있습니다.

프로세스

  1. OAuth 2.0 지원이 포함된 클라이언트 라이브러리를 Kafka 클라이언트의 pom.xml 파일에 추가합니다. 

    <dependency>
 <groupId>io.strimzi</groupId>
 <artifactId>kafka-oauth-client</artifactId>
 <version>0.9.0.redhat-00001</version>
</dependency>
    Copy to Clipboard Toggle word wrap

  2. 콜백에 대한 시스템 속성을 구성합니다.

    예를 들면 다음과 같습니다. 

    System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token”);
    1 
    
System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "CLIENT-NAME");
    2 
    
System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "CLIENT_SECRET");
    3 
    
System.setProperty(ClientConfig.OAUTH_SCOPE, "SCOPE-VALUE")
    4
    Copy to Clipboard Toggle word wrap
    1
    권한 부여 서버 토큰 끝점의 URI입니다.
    2
    권한 부여 서버에서 클라이언트를 생성할 때 사용되는 이름인 클라이언트 ID입니다.
    3
    권한 부여 서버에서 클라이언트를 생성할 때 생성된 클라이언트 시크릿입니다.
    4
    (선택 사항) 토큰 끝점에서 토큰을 요청하는 범위 입니다. 권한 부여 서버에는 클라이언트가 범위를 지정해야 할 수 있습니다.

  3. Kafka 클라이언트 구성에서 TLS 암호화 연결에서 OAUTHBEARER 또는 PLAIN 메커니즘을 활성화합니다.

    예를 들면 다음과 같습니다.

    Kafka 클라이언트의 OAUTHBEARER 활성화

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;");
props.put("security.protocol", "SASL_SSL");
props.put("sasl.mechanism", "OAUTHBEARER");
props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");
    Copy to Clipboard Toggle word wrap

    Kafka 클라이언트에 PLAIN 활성화

    props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"$CLIENT_ID_OR_ACCOUNT_NAME\" password=\"$SECRET_OR_ACCESS_TOKEN\" ;");
props.put("security.protocol", "SASL_SSL");
    1 
    
props.put("sasl.mechanism", "PLAIN");
    Copy to Clipboard Toggle word wrap

    1
    여기에서는 TLS 연결을 통해 사용하기 위해 SASL_SSL 을 사용합니다. 로컬 개발을 위해 암호화되지 않은 연결보다 SASL_PLAINTEXT 를 사용하십시오.
  4. Kafka 클라이언트가 Kafka 브로커에 액세스할 수 있는지 확인합니다.

4.11. OAuth 2.0 토큰 기반 권한 부여 사용
링크 복사

토큰 기반 인증에 Red Hat Single Sign-On과 함께 OAuth 2.0을 사용하는 경우 Red Hat Single Sign-On을 사용하여 Kafka 브로커에 대한 클라이언트 액세스를 제한하도록 권한 부여 규칙을 구성할 수도 있습니다. 인증은 사용자의 ID를 설정합니다. 권한 부여는 해당 사용자의 액세스 수준을 결정합니다.

AMQ Streams는 Red Hat Single Sign-On 인증 서비스를 통해 OAuth 2.0 토큰 기반 권한 사용을 지원하므로 보안 정책과 권한을 중앙에서 관리할 수 있습니다.

Red Hat Single Sign-On에 정의된 보안 정책 및 권한은 Kafka 브로커의 리소스에 대한 액세스 권한을 부여하는 데 사용됩니다. 사용자와 클라이언트는 Kafka 브로커에서 특정 작업을 수행하기 위해 액세스를 허용하는 정책과 일치합니다.

Kafka는 기본적으로 모든 사용자에게 브로커에 대한 전체 액세스를 허용하며 AclAuthorizer 플러그인도 제공하여 ACL(Access Control Lists)을 기반으로 권한 부여를 구성합니다.

Zookeeper는 사용자 이름을 기반으로 리소스에 대한 액세스 권한을 부여하거나 거부하는 ACL 규칙을 저장합니다. 그러나 Red Hat Single Sign-On을 사용한 OAuth 2.0 토큰 기반 권한 부여는 Kafka 브로커에 대한 액세스 제어를 구현하는 방법에 대한 유연성을 훨씬 높여 줍니다. 또한 OAuth 2.0 권한 부여 및 ACL을 사용하도록 Kafka 브로커를 구성할 수 있습니다.

추가 리소스

4.11.1. OAuth 2.0 인증 메커니즘
링크 복사

AMQ Streams의 OAuth 2.0 인증에서는 Red Hat Single Sign-On 서버 권한 부여 REST 끝점을 사용하여 특정 사용자에게 정의된 보안 정책을 적용하고 해당 사용자의 다양한 리소스에 부여된 권한 목록을 제공하여 Red Hat Single Sign-On으로 토큰 기반 인증을 확장합니다. 정책은 역할과 그룹을 사용하여 사용자와 권한을 일치시킵니다. OAuth 2.0 권한 부여는 Red Hat Single Sign-On 인증 서비스에서 사용자에 대한 수신된 권한 목록을 기반으로 권한을 로컬로 적용합니다.

4.11.1.1. Kafka 브로커 사용자 정의 승인
링크 복사

Red Hat Single Sign-On 승인자 (KeycloakRBACAuthorizer)는 AMQ Streams와 함께 제공됩니다. Red Hat Single Sign-On에서 제공하는 권한 부여 서비스에 Red Hat Single Sign-On REST 엔드포인트를 사용하려면 Kafka 브로커에서 사용자 지정 승인자를 구성합니다.

인증자는 필요에 따라 권한 부여 서버에서 부여된 권한 목록을 가져와서 Kafka 브로커에 로컬로 권한 부여를 적용하여 각 클라이언트 요청에 대해 신속하게 권한 부여 결정을 내립니다.

4.11.2. OAuth 2.0 권한 부여 지원 구성
링크 복사

다음 절차에서는 Red Hat Single Sign-On 인증 서비스를 사용하여 OAuth 2.0 인증을 사용하도록 Kafka 브로커를 구성하는 방법을 설명합니다.

사전 준비 사항

필요한 액세스 또는 특정 사용자에 대해 제한하려는 경우를 고려하십시오. Red Hat Single Sign-On 그룹,역할,클라이언트 및 사용자를 결합하여 Red Hat Single Sign-On에서 액세스를 구성할 수 있습니다.

일반적으로 그룹은 조직 부서 또는 지리적 위치를 기반으로 사용자와 일치시키는 데 사용됩니다. 및 역할은 해당 기능을 기반으로 사용자와 일치시키는 데 사용됩니다.

Red Hat Single Sign-On을 사용하면 사용자와 그룹을 LDAP에 저장할 수 있지만 클라이언트와 역할은 이러한 방식으로 저장할 수 없습니다. 사용자 데이터에 대한 스토리지 및 액세스는 권한 부여 정책 구성 방법의 요소가 될 수 있습니다.

참고

Super 사용자는 Kafka 브로커에서 구현된 권한 부여에 관계없이 항상 Kafka 브로커에 대한 무제한 액세스 권한을 갖습니다.

사전 요구 사항

  • AMQ Streams는 토큰 기반 인증을 위해 Red Hat Single Sign-On과 함께 OAuth 2.0을 사용하도록 구성해야 합니다. 권한 부여를 설정할 때 동일한 Red Hat Single Sign-On 서버 끝점을 사용합니다.
  • Red Hat Single Sign-On 설명서에 설명된 대로 Red Hat Single Sign-On 인증 서비스에 대한 정책 및 권한을 관리하는 방법을 이해해야 합니다.

프로세스

  1. Red Hat Single Sign-On 관리 콘솔에 액세스하거나 Red Hat Single Sign-On 관리 CLI를 사용하여 OAuth 2.0 인증을 설정할 때 생성한 Kafka 브로커 클라이언트에 대한 인증 서비스를 활성화합니다.
  2. 인증 서비스를 사용하여 클라이언트에 대한 리소스, 권한 부여 범위, 정책 및 권한을 정의합니다.
  3. 역할 및 그룹을 할당하여 사용자 및 클라이언트에 권한을 바인딩합니다.

  4. Red Hat Single Sign-On 권한을 사용하도록 Kafka 브로커를 구성합니다.

    Kafka server.properties 구성 파일에 다음을 추가하여 Kafka에 인증자를 설치합니다. 

    authorizer.class.name=io.strimzi.kafka.oauth.server.authorizer.KeycloakRBACAuthorizer
principal.builder.class=io.strimzi.kafka.oauth.server.authorizer.JwtKafkaPrincipalBuilder
    Copy to Clipboard Toggle word wrap

  5. Kafka 브로커에 대한 구성을 추가하여 권한 부여 서버 및 권한 부여 서비스에 액세스합니다.

    여기서는 server.properties 에 추가 속성을 추가하지만 대문자 또는 대문자 이름 지정 규칙을 사용하여 환경 변수로 정의할 수도 있습니다. 

    strimzi.authorization.token.endpoint.uri="https://AUTH-SERVER-ADDRESS/auth/realms/REALM-NAME/protocol/openid-connect/token"
    1 
    
strimzi.authorization.client.id="kafka"
    2
    Copy to Clipboard Toggle word wrap
    1
    Red Hat Single Sign-On의 OAuth 2.0 토큰 끝점 URL입니다. 프로덕션의 경우 항상 HTTP를 사용합니다.
    2
    권한 부여 서비스가 활성화된 Red Hat Single Sign-On의 OAuth 2.0 클라이언트 정의의 클라이언트 ID입니다. 일반적으로 kafka 는 ID로 사용됩니다.

  6. (선택 사항) 특정 Kafka 클러스터에 대한 구성을 추가합니다.

    예를 들면 다음과 같습니다. 

    strimzi.authorization.kafka.cluster.name="kafka-cluster"
    1
    Copy to Clipboard Toggle word wrap
    1
    특정 Kafka 클러스터의 이름입니다. 이름은 권한을 대상으로 지정하는 데 사용되며 동일한 Red Hat Single Sign-On 영역에서 여러 클러스터를 관리할 수 있습니다. 기본값은 kafka-cluster 입니다.

  7. (선택 사항) 간단한 인증으로 위임합니다.

    예를 들면 다음과 같습니다. 

    strimzi.authorization.delegate.to.kafka.acl="false"
    1
    Copy to Clipboard Toggle word wrap
    1
    Red Hat Single Sign-On 인증 서비스 정책에서 액세스가 거부되는 경우 Kafka AclAuthorizer 에 권한을 위임합니다. 기본값은 false입니다.

  8. (선택 사항) 권한 부여 서버에 TLS 연결에 대한 구성을 추가합니다.

    예를 들면 다음과 같습니다. 

    strimzi.authorization.ssl.truststore.location=<path-to-truststore>
    1 
    
strimzi.authorization.ssl.truststore.password=<my-truststore-password>
    2 
    
strimzi.authorization.ssl.truststore.type=JKS
    3 
    
strimzi.authorization.ssl.secure.random.implementation=SHA1PRNG
    4 
    
strimzi.authorization.ssl.endpoint.identification.algorithm=HTTPS
    5
    Copy to Clipboard Toggle word wrap
    1
    인증서가 포함된 신뢰 저장소의 경로입니다.
    2
    truststore의 암호입니다.
    3
    truststore 유형입니다. 설정되지 않은 경우 기본 Java 키 저장소 유형이 사용됩니다.
    4
    임의 번호 생성기 구현. 설정하지 않으면 Java 플랫폼 SDK 기본값이 사용됩니다.
    5
    호스트 이름 확인 빈 문자열로 설정하면 호스트 이름 확인이 해제됩니다. 설정되지 않은 경우 기본값은 HTTPS 로, 서버 인증서에 대한 호스트 이름 확인을 적용합니다.

  9. (선택 사항) 권한 부여 서버에서 권한 부여 새로 고침을 구성합니다. 부여 새로 고침 작업은 활성 토큰을 열거하고 각각에 대한 최신 권한을 요청하여 작동합니다.

    예를 들면 다음과 같습니다. 

    strimzi.authorization.grants.refresh.period.seconds="120"
    1 
    
strimzi.authorization.grants.refresh.pool.size="10"
    2
    Copy to Clipboard Toggle word wrap
    1
    권한 부여 서버의 권한 부여 목록이 새로 고침되는 빈도(기본적으로 분당 시간)를 지정합니다. 디버깅 목적으로 새로 고침을 비활성화하려면 "0" 으로 설정합니다.
    2
    grants 새로 고침 작업에 사용되는 스레드 풀의 크기(병합 정도)를 지정합니다. 기본값은 "5" 입니다.
  10. Kafka 브로커에 특정 역할이 있는 클라이언트 또는 사용자로 액세스하여 구성된 권한에 액세스하고 필요한 액세스 권한이 있는지 또는 권한이 없는지 확인합니다.

4.12. OPA 정책 기반 권한 부여 사용
링크 복사

OPA(Open Policy Agent)는 오픈 소스 정책 엔진입니다. OPA를 AMQ Streams와 통합하여 Kafka 브로커에서 클라이언트 작업을 허용하는 정책 기반 권한 부여 메커니즘 역할을 할 수 있습니다.

클라이언트에서 요청이 생성되면 OPA는 Kafka 액세스에 대해 정의된 정책에 대한 요청을 평가한 다음 요청을 허용하거나 거부합니다.

참고

Red Hat은 OPA 서버를 지원하지 않습니다.

추가 리소스

4.12.1. OPA 정책 정의
링크 복사

OPA를 AMQ Streams와 통합하기 전에 세분화된 액세스 제어를 제공하기 위해 정책을 정의하는 방법을 고려하십시오.

Kafka 클러스터, 소비자 그룹 및 주제에 대한 액세스 제어를 정의할 수 있습니다. 예를 들어 생산자 클라이언트에서 특정 브로커 주제로 쓰기 액세스를 허용하는 권한 부여 정책을 정의할 수 있습니다.

이 경우 정책은 다음을 지정할 수 있습니다.

  • 생산자 클라이언트와 연결된 사용자 주체 및 호스트 주소
  • 클라이언트에 허용되는 작업
  • 정책이 적용되는 리소스유형 (주체 ) 및 리소스 이름

허용 및 거부 결정은 정책에 기록되며, 제공되는 요청 및 클라이언트 식별 데이터에 따라 응답이 제공됩니다.

이 예제에서는 생산자 클라이언트가 해당 항목에 쓸 수 있도록 정책을 충족해야 합니다.

4.12.2. OPA에 연결
링크 복사

Kafka가 OPA 정책 엔진에 액세스하여 액세스 제어 정책을 쿼리할 수 있도록 Kafka server.properties 파일에서 사용자 지정 OPA 승인자 플러그인(kafka-authorizer-opa-VERSION.jar)을 구성합니다.

클라이언트에서 요청을 수행하면 지정된 URL 주소와 정의된 정책의 이름이어야 하는 REST 끝점을 사용하여 플러그인에서 OPA 정책 엔진을 쿼리합니다.

플러그인은 클라이언트 요청(사용자 주체, 작업 및 리소스)의 세부 정보를 JSON 형식으로 제공하여 정책에 대해 확인합니다. 세부 정보에는 클라이언트의 고유 ID가 포함됩니다. 예를 들어 TLS 인증이 사용되는 경우 클라이언트 인증서와 고유 이름을 사용합니다.

OPA는 데이터를 사용하여 요청을 허용하거나 거부하기 위해 플러그인에 true 또는 false - 응답을 제공합니다.

4.12.3. OPA 권한 부여 지원 구성
링크 복사

다음 절차에서는 OPA 인증을 사용하도록 Kafka 브로커를 구성하는 방법을 설명합니다.

사전 준비 사항

필요한 액세스 또는 특정 사용자에 대해 제한하려는 경우를 고려하십시오. 사용자와 Kafka 리소스 를 결합하여 OPA 정책을 정의할 수 있습니다.

LDAP 데이터 소스에서 사용자 정보를 로드하도록 OPA를 설정할 수 있습니다.

참고

Super 사용자는 Kafka 브로커에서 구현된 권한 부여에 관계없이 항상 Kafka 브로커에 대한 무제한 액세스 권한을 갖습니다.

사전 요구 사항

프로세스

  1. Kafka 브로커에서 작업을 수행하기 위해 클라이언트 요청을 승인하는 데 필요한 OPA 정책을 작성합니다.

    OPA 정책 정의를 참조하십시오.

    이제 OPA를 사용하도록 Kafka 브로커를 구성합니다.

  2. Kafka에 대한 OPA 승인자 플러그인을 설치합니다.

    OPA에 연결을 참조하십시오.

    플러그인 파일이 Kafka 클래스 경로에 포함되어 있는지 확인합니다.

  3. Kafka server.properties 구성 파일에 다음을 추가하여 OPA 플러그인을 활성화합니다. 

    authorizer.class.name: com.bisnode.kafka.authorization.OpaAuthorizer
    Copy to Clipboard Toggle word wrap

  4. Kafka 브로커의 server.properties 에 구성을 추가하여 OPA 정책 엔진 및 정책에 액세스합니다.

    예를 들면 다음과 같습니다. 

    opa.authorizer.url=https://OPA-ADDRESS/allow
    1 
    
opa.authorizer.allow.on.error=false
    2 
    
opa.authorizer.cache.initial.capacity=50000
    3 
    
opa.authorizer.cache.maximum.size=50000
    4 
    
opa.authorizer.cache.expire.after.seconds=600000
    5 
    
super.users=User:alice;User:bob
    6
    Copy to Clipboard Toggle word wrap
    1
    (필수) 승인자 플러그인이 쿼리할 정책의 OAuth 2.0 토큰 끝점 URL입니다. 이 예에서는 정책을 allow 이라고 합니다.
    2
    승인자 플러그인이 OPA 정책 엔진과 연결하지 못하는 경우 클라이언트가 기본적으로 액세스가 허용되거나 거부되는지 여부를 지정하는 플래그입니다.
    3
    로컬 캐시의 초기 용량(바이트)입니다. 플러그인이 모든 요청에 대해 OPA 정책 엔진을 쿼리할 필요가 없도록 캐시가 사용됩니다.
    4
    로컬 캐시의 최대 용량(바이트)입니다.
    5
    OPA 정책 엔진에서 다시 로드하여 로컬 캐시를 새로 고치는 시간(밀리초)입니다.
    6
    Open Policy Agent 정책을 쿼리하지 않고 항상 허용되도록 슈퍼 사용자로 취급되는 사용자 주체 목록입니다.

    인증 및 권한 부여 옵션에 대한 정보는 Open Policy Agent 웹 사이트를 참조하십시오.

  5. 및 올바른 권한이 없는 클라이언트를 사용하여 Kafka 브로커에 액세스하여 구성된 권한을 확인합니다.

4.13. 로깅
링크 복사

Kafka 브로커는 Log4j를 로깅 인프라로 사용합니다. 기본적으로 로깅 구성은 log4j.properties 구성 파일에서 읽습니다. 이 구성 파일은 /opt/kafka/config/ 디렉터리 또는 classpath에 배치되어야 합니다. 구성 파일의 위치와 이름은 KAFKA_LOG4J_OPTS 환경 변수를 사용하여 Kafka로 전달할 수 있는 Java 속성 log4j.configuration 을 사용하여 변경할 수 있습니다. 

su - kafka
export KAFKA_LOG4J_OPTS="-Dlog4j.configuration=file:/my/path/to/log4j.config"; /opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties
Copy to Clipboard Toggle word wrap

Log4j 구성에 대한 자세한 내용은 Log4j 설명서 를 참조하십시오.

4.13.1. Kafka 브로커 로거의 로깅 수준 동적으로 변경
링크 복사

Kafka 브로커 로깅은 각 브로커의 여러 브로커 로거 에서 제공합니다. 브로커를 다시 시작할 필요 없이 브로커 로거의 로깅 수준을 동적으로 변경할 수 있습니다. 예를 들어 INFO 에서 DEBUG 로 변경하여 로그에 반환되는 세부 정보 수준을 늘리면 Kafka 클러스터의 성능 문제를 조사하는 데 유용합니다.

브로커 로거는 기본 로깅 수준으로 동적으로 재설정할 수도 있습니다.

사전 요구 사항

프로세스

  1. kafka 사용자로 전환합니다. 

    su - kafka
    Copy to Clipboard Toggle word wrap

  2. kafka-configs.sh 툴을 사용하여 브로커의 모든 브로커 로거를 나열합니다. 

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server BOOTSTRAP-ADDRESS --describe --entity-type broker-loggers --entity-name BROKER-ID
    Copy to Clipboard Toggle word wrap

    예를 들어 브로커 0 의 경우 다음과 같습니다. 

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server localhost:9092 --describe --entity-type broker-loggers --entity-name 0
    Copy to Clipboard Toggle word wrap

    그러면 TRACE,DEBUG,INFO,WARN,ERROR 또는 FATAL 의 로깅 수준이 반환됩니다. 예를 들면 다음과 같습니다. 

    #...
kafka.controller.ControllerChannelManager=INFO sensitive=false synonyms={}
kafka.log.TimeIndex=INFO sensitive=false synonyms={}
    Copy to Clipboard Toggle word wrap

  3. 하나 이상의 브로커 로거의 로깅 수준을 변경합니다. --alter 및 --add-config 옵션을 사용하고 각 로거와 수준을 큰따옴표로 쉼표로 구분된 목록으로 지정합니다. 

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server BOOTSTRAP-ADDRESS --alter --add-config "LOGGER-ONE=NEW-LEVEL,LOGGER-TWO=NEW-LEVEL" --entity-type broker-loggers --entity-name BROKER-ID
    Copy to Clipboard Toggle word wrap

    예를 들어 브로커 0 의 경우 다음과 같습니다. 

    /opt/kafka/bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --add-config "kafka.controller.ControllerChannelManager=WARN,kafka.log.TimeIndex=WARN" --entity-type broker-loggers --entity-name 0
    Copy to Clipboard Toggle word wrap

    성공하면 다음을 반환합니다. 

    Completed updating config for broker: 0.
    Copy to Clipboard Toggle word wrap
브로커 로거 재설정

kafka-configs.sh 툴을 사용하여 하나 이상의 브로커 로거를 기본 로깅 수준으로 재설정할 수 있습니다. alter 및 -- delete-config 옵션을 사용하고 각 브로커 로거를 큰따옴표로 쉼표로 구분된 목록으로 지정합니다. 

/opt/kafka/bin/kafka-configs.sh --bootstrap-server localhost:9092 --alter --delete-config "LOGGER-ONE,LOGGER-TWO" --entity-type broker-loggers --entity-name BROKER-ID
Copy to Clipboard Toggle word wrap

추가 리소스

5장. 주제
링크 복사

Kafka의 메시지는 항상 주제로 전송되거나 수신됩니다. 이 장에서는 Kafka 주제를 구성하고 관리하는 방법을 설명합니다.

5.1. 파티션 및 복제본
링크 복사

Kafka의 메시지는 항상 주제로 전송되거나 수신됩니다. 주제는 항상 하나 이상의 파티션으로 나뉩니다. 파티션은 shard 역할을 합니다. 즉, 생산자가 보낸 모든 메시지는 항상 단일 파티션에만 작성됩니다. 메시지를 다른 파티션으로 분할하여 수평으로 쉽게 확장할 수 있습니다.

각 파티션에는 하나 이상의 복제본이 있을 수 있으며 이는 클러스터의 다른 브로커에 저장됩니다. 주제를 만들 때 복제 요인 을 사용하여 복제본 수를 구성할 수 있습니다. 복제 요소는 클러스터 내에서 보유할 복사본 수를 정의합니다. 지정된 파티션의 복제본 중 하나가 리더로 선택됩니다. 리더 복제본은 생산자가 새 메시지를 전송하고 사용자가 메시지를 사용하는 데 사용됩니다. 다른 복제본은 후속 복제본이 됩니다. 의사들은 리더를 재현합니다.

리더가 실패하면 그 중 한 사람이 자동으로 새로운 리더가 될 것입니다. 각 서버는 일부 파티션의 리더 역할을 하며 다른 서버의 팔로우가 클러스터 내에서 부하를 분산할 수 있도록 합니다.

참고

복제 요인은 리더 및 팔로워를 포함한 복제본 수를 결정합니다. 예를 들어 복제 요소를 3 으로 설정하면 리더 1개와 후속 복제본 두 개가 있습니다.

5.2. 메시지 보존
링크 복사

메시지 보존 정책은 메시지가 Kafka 브로커에 저장되는 기간을 정의합니다. 시간, 파티션 크기 또는 둘 다에 따라 정의할 수 있습니다.

예를 들어 메시지를 유지해야 함을 정의할 수 있습니다.

  • 7일 동안
  • 페미션에 1GB의 메시지가 있을 때까지 제한에 도달하면 가장 오래된 메시지가 제거됩니다.
  • 7일 동안 또는 1GB 제한에 도달할 때까지. 어떤 제한이 먼저 제공되는지 먼저 사용할 수 있습니다.
주의

Kafka 브로커는 메시지를 로그 세그먼트에 저장합니다. 보존 정책 이후의 메시지는 새 로그 세그먼트가 생성될 때만 삭제됩니다. 이전 로그 세그먼트가 구성된 로그 세그먼트 크기를 초과하면 새 로그 세그먼트가 생성됩니다. 또한 사용자는 주기적으로 생성되도록 새 세그먼트를 요청할 수 있습니다.

또한 Kafka 브로커는 압축 정책을 지원합니다.

컴팩트한 정책이 있는 주제의 경우 브로커는 항상 각 키에 대한 마지막 메시지만 유지합니다. 동일한 키가 있는 이전 메시지는 파티션에서 제거됩니다. 압축은 주기적으로 실행되는 작업이므로 동일한 키가 있는 새 메시지가 파티션으로 전송되면 즉시 수행되지 않습니다. 대신 이전 메시지가 제거될 때까지 다소 시간이 걸릴 수 있습니다.

메시지 보존 구성 옵션에 대한 자세한 내용은 5.5절. “주제 구성” 을 참조하십시오.

5.3. 주제 자동 생성
링크 복사

생산자 또는 소비자가 존재하지 않는 주제에서 메시지를 보내거나 메시지를 수신하려고 하면 Kafka는 기본적으로 해당 주제를 자동으로 생성합니다. 이 동작은 기본적으로 true 로 설정된 auto.create.topics.enable 구성 속성을 통해 제어됩니다.

이를 비활성화하려면 Kafka 브로커 구성 파일에서 auto.create.topics.enable 을 false 로 설정합니다. 

auto.create.topics.enable=false
Copy to Clipboard Toggle word wrap

5.4. 삭제 주제
링크 복사

Kafka는 주제 삭제를 비활성화할 수 있는 가능성을 제공합니다. 이는 기본적으로 true 로 설정된 delete.topic.enable 속성을 통해 구성됩니다(즉, 주제를 삭제할 수 있음). 이 속성을 false 로 설정하면 주제를 삭제할 수 없으며 모든 주제가 성공으로 반환되지만 항목은 삭제되지 않습니다. 

delete.topic.enable=false
Copy to Clipboard Toggle word wrap

5.5. 주제 구성
링크 복사

자동 생성 주제에서는 브로커 속성 파일에 지정할 수 있는 기본 주제 구성을 사용합니다. 그러나 항목을 수동으로 생성할 때 해당 구성을 생성할 때 지정할 수 있습니다. 주제 구성을 생성한 후 변경할 수도 있습니다. 수동으로 생성된 주제의 주요 주제 구성 옵션은 다음과 같습니다.

cleanup.policy
삭제하거나 콤팩트 하도록 보존 정책을 구성합니다. 삭제 정책은 이전 레코드를 삭제합니다. 컴팩트 정책을 사용하면 로그 압축이 가능합니다. 기본값은 delete 입니다. 로그 압축에 대한 자세한 내용은 Kafka 웹 사이트를 참조하십시오.
compression.type
저장된 메시지에 사용되는 압축을 지정합니다. 유효한 값은 gzip,snappy,lz4,압축 해제(no compression) 및 producer (프로덕션에서 사용하는 압축 코드 취득)입니다. 기본값은 producer 입니다.
max.message.bytes
Kafka 브로커가 허용하는 메시지 배치의 최대 크기(바이트)입니다. 기본값은 1000012 입니다.
min.insync.replicas
쓰기가 성공으로 간주되려면 동기화에 있어야 하는 최소 복제본 수입니다. 기본값은 1 입니다.
retention.ms
로그 세그먼트를 유지할 최대 시간(밀리초)입니다. 이 값보다 오래된 로그 세그먼트는 삭제됩니다. 기본값은 604800000 (7일)입니다.
retention.bytes
파티션이 보유할 최대 바이트 수입니다. 파티션 크기가 이 제한을 초과하면 가장 오래된 로그 세그먼트가 삭제됩니다. 값 -1 은 제한이 없음을 나타냅니다. 기본값은 -1 입니다.
segment.bytes
단일 커밋 로그 세그먼트 파일의 최대 파일 크기(바이트)입니다. 세그먼트가 크기에 도달하면 새 세그먼트가 시작됩니다. 기본값은 1073741824 바이트(1GB)입니다.

지원되는 모든 주제 구성 옵션 목록은 부록 B. 주제 구성 매개변수 을 참조하십시오.

자동 생성 주제의 기본값은 유사한 옵션을 사용하여 Kafka 브로커 구성에 지정할 수 있습니다.

log.cleanup.policy
위의 cleanup.policy 를 참조하십시오.
compression.type
위의 compression.type 을 참조하십시오.
message.max.bytes
위의 max.message.bytes 를 참조하십시오.
min.insync.replicas
위의 min.insync.replicas 를 참조하십시오.
log.retention.ms
위의 retention.ms 를 참조하십시오.
log.retention.bytes
위의 retention.bytes 를 참조하십시오.
log.segment.bytes
위의 segment.bytes 를 참조하십시오.
default.replication.factor
자동으로 생성된 주제의 기본 복제 요소. 기본값은 1 입니다.
num.partitions
자동으로 생성된 주제의 기본 파티션 수입니다. 기본값은 1 입니다.

지원되는 모든 Kafka 브로커 구성 옵션 목록은 부록 A. 브로커 구성 매개변수 을 참조하십시오.

5.6. 내부 주제
링크 복사

내부 주제는 Kafka 브로커 및 클라이언트에서 내부적으로 생성 및 사용합니다. Kafka에는 여러 내부 주제가 있습니다. 소비자 오프셋(__consumer_offsets) 또는 트랜잭션 상태(__Cryostat_state )를 저장하는 데 사용됩니다. 이러한 주제는 접두사 offsets.topic. 및 transaction.state.log. 로 시작하는 전용 Kafka 브로커 구성 옵션을 사용하여 구성할 수 있습니다. 가장 중요한 구성 옵션은 다음과 같습니다.

offsets.topic.replication.factor
__consumer_offsets 주제의 복제본 수입니다. 기본값은 3입니다.
offsets.topic.num.partitions
__consumer_offsets 주제의 파티션 수입니다. 기본값은 50 입니다.
transaction.state.log.replication.factor
__ Cryostat_state 주제의 복제본 수입니다. 기본값은 3입니다.
transaction.state.log.num.partitions
__ Cryostat_state 주제의 파티션 수입니다. 기본값은 50 입니다.
transaction.state.log.min.isr
__ Cryostat_state 항목에 대한 쓰기를 승인해야 하는 최소 복제본 수가 성공으로 간주됩니다. 이 최소값을 충족할 수 없는 경우 예외와 함께 생산자가 실패합니다. 기본값은 2입니다.

5.7. 주제 생성
링크 복사

kafka-topics.sh 도구를 사용하여 주제를 관리할 수 있습니다. Kafka-topics.sh 는 AMQ Streams 배포의 일부이며 bin 디렉터리에서 찾을 수 있습니다.

사전 요구 사항

  • AMQ Streams 클러스터가 설치 및 실행 중

주제 생성

  1. kafka-topics.sh 유틸리티를 사용하여 주제를 생성하고 다음을 지정합니다.

    • --bootstrap-server 옵션에 있는 Kafka 브로커의 호스트 및 포트입니다.
    • --create 옵션에 생성할 새 주제입니다.
    • --topic 옵션의 주제 이름입니다.
    • --partitions 옵션의 파티션 수입니다.

    • --replication-factor 옵션의 복제 요인입니다.

      --config 옵션을 사용하여 일부 기본 주제 구성 옵션을 덮어쓸 수도 있습니다. 이 옵션을 여러 번 사용하여 다른 옵션을 덮어쓸 수 있습니다. 

      bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --create --topic <TopicName> --partitions <NumberOfPartitions> --replication-factor <ReplicationFactor> --config <Option1>=<Value1> --config <Option2>=<Value2>
      Copy to Clipboard Toggle word wrap

      mytopic이라는 주제를 생성하는 명령의 예

      bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic mytopic --partitions 50 --replication-factor 3 --config cleanup.policy=compact --config min.insync.replicas=2
      Copy to Clipboard Toggle word wrap

  2. kafka-topics.sh 를 사용하여 주제가 존재하는지 확인합니다. 

    bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --describe --topic <TopicName>
    Copy to Clipboard Toggle word wrap

    mytopic이라는 주제를 설명하는 명령의 예

    bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic mytopic
    Copy to Clipboard Toggle word wrap

추가 리소스

5.8. 주제 나열 및 설명
링크 복사

kafka-topics.sh 툴을 사용하여 주제를 나열하고 설명할 수 있습니다. Kafka-topics.sh 는 AMQ Streams 배포의 일부이며 bin 디렉터리에서 찾을 수 있습니다.

사전 요구 사항

  • AMQ Streams 클러스터가 설치 및 실행 중
  • 내topic이 존재하는 경우

주제 설명

  1. kafka-topics.sh 유틸리티를 사용하여 주제를 설명하고 다음을 지정합니다.

    • --bootstrap-server 옵션에 있는 Kafka 브로커의 호스트 및 포트입니다.
    • --describe 옵션을 사용하여 주제를 설명하도록 지정합니다.
    • 주제 이름은 --topic 옵션에 지정해야 합니다.

    • --topic 옵션을 생략하면 사용 가능한 모든 주제를 설명합니다. 

      bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --describe --topic <TopicName>
      Copy to Clipboard Toggle word wrap

      mytopic이라는 주제를 설명하는 명령의 예

      bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic mytopic
      Copy to Clipboard Toggle word wrap

      describe 명령은 이 항목에 속하는 모든 파티션 및 복제본을 나열합니다. 또한 모든 주제 구성 옵션을 나열합니다.

추가 리소스

5.9. 주제 구성 수정
링크 복사

kafka-configs.sh 도구를 사용하여 주제 구성을 수정할 수 있습니다. Kafka-configs.sh 는 AMQ Streams 배포의 일부이며 bin 디렉터리에서 찾을 수 있습니다.

사전 요구 사항

  • AMQ Streams 클러스터가 설치 및 실행 중
  • 내topic이 존재하는 경우

주제 구성 수정

  1. kafka-configs.sh 툴을 사용하여 현재 구성을 가져옵니다.

    • --bootstrap-server 옵션에 Kafka 브로커의 호스트 및 포트를 지정합니다.
    • --entity-type 을 topic 및 --entity-name 을 주제 이름으로 설정합니다.

    • 현재 구성을 가져오려면 --describe 옵션을 사용합니다. 

      bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name <TopicName> --describe
      Copy to Clipboard Toggle word wrap

      mytopic이라는 주제의 구성을 가져오는 명령의 예

      bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name mytopic --describe
      Copy to Clipboard Toggle word wrap

  2. kafka-configs.sh 툴을 사용하여 구성을 변경합니다.

    • --bootstrap-server 옵션에 Kafka 브로커의 호스트 및 포트를 지정합니다.
    • --entity-type 을 topic 및 --entity-name 을 주제 이름으로 설정합니다.
    • 현재 구성을 수정하려면 --alter 옵션을 사용합니다.

    • --add-config 옵션을 추가하거나 변경할 옵션을 지정합니다. 

      bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name <TopicName> --alter --add-config <Option>=<Value>
      Copy to Clipboard Toggle word wrap

      mytopic이라는 주제의 구성을 변경하는 명령의 예

      bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name mytopic --alter --add-config min.insync.replicas=1
      Copy to Clipboard Toggle word wrap

  3. kafka-configs.sh 도구를 사용하여 기존 구성 옵션을 삭제합니다.

    • --bootstrap-server 옵션에 Kafka 브로커의 호스트 및 포트를 지정합니다.
    • --entity-type 을 topic 및 --entity-name 을 주제 이름으로 설정합니다.
    • 기존 구성 옵션을 제거하려면 --delete-config 옵션을 사용합니다.

    • --remove-config 명령에서 제거할 옵션을 지정합니다. 

      bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name <TopicName> --alter --delete-config <Option>
      Copy to Clipboard Toggle word wrap

      mytopic이라는 주제의 구성을 변경하는 명령의 예

      bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name mytopic --alter --delete-config min.insync.replicas
      Copy to Clipboard Toggle word wrap

추가 리소스

5.10. 주제 삭제
링크 복사

kafka-topics.sh 도구를 사용하여 주제를 관리할 수 있습니다. Kafka-topics.sh 는 AMQ Streams 배포의 일부이며 bin 디렉터리에서 찾을 수 있습니다.

사전 요구 사항

  • AMQ Streams 클러스터가 설치 및 실행 중
  • 내topic이 존재하는 경우

주제 삭제

  1. kafka-topics.sh 유틸리티를 사용하여 주제를 삭제합니다.

    • --bootstrap-server 옵션에 있는 Kafka 브로커의 호스트 및 포트입니다.
    • --delete 옵션을 사용하여 기존 주제를 삭제해야 함을 지정합니다.

    • 주제 이름은 --topic 옵션에 지정해야 합니다. 

      bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --delete --topic <TopicName>
      Copy to Clipboard Toggle word wrap

      mytopic이라는 주제를 생성하는 명령의 예

      bin/kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic mytopic
      Copy to Clipboard Toggle word wrap

  2. kafka-topics.sh 를 사용하여 주제가 삭제되었는지 확인합니다. 

    bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --list
    Copy to Clipboard Toggle word wrap

    모든 주제를 나열하는 명령의 예

    bin/kafka-topics.sh --bootstrap-server localhost:9092 --list
    Copy to Clipboard Toggle word wrap

추가 리소스

6장. Kafka 관리
링크 복사

추가 구성 속성을 사용하여 AMQ Streams 배포를 유지 관리합니다. AMQ Streams의 성능에 응답하기 위해 설정을 추가하고 조정할 수 있습니다. 예를 들어 처리량 및 데이터 안정성을 개선하기 위해 추가 구성을 도입할 수 있습니다.

6.1. Kafka 구성 튜닝
링크 복사

구성 속성을 사용하여 Kafka 브로커, 생산자 및 소비자의 성능을 최적화합니다.

최소 구성 속성 세트가 필요하지만 속성을 추가하거나 조정하여 생산자 및 소비자가 Kafka 브로커와 상호 작용하는 방식을 변경할 수 있습니다. 예를 들어 클라이언트가 데이터에 실시간으로 응답할 수 있도록 메시지의 대기 시간과 처리량을 조정할 수 있습니다.

메트릭을 분석하여 초기 구성을 만들 위치를 측정한 다음 필요한 구성이 있을 때까지 증분 변경 및 메트릭을 추가로 비교할 수 있습니다.

Apache Kafka 구성 속성에 대한 자세한 내용은 Apache Kafka 설명서 를 참조하십시오.

6.1.1. Kafka 브로커 구성 튜닝
링크 복사

구성 속성을 사용하여 Kafka 브로커의 성능을 최적화합니다. AMQ Streams에서 직접 관리하는 속성을 제외하고 표준 Kafka 브로커 구성 옵션을 사용할 수 있습니다.

6.1.1.1. 기본 브로커 구성
링크 복사

기본 구성에는 브로커를 식별하고 보안 액세스를 제공하는 다음 속성이 포함됩니다.

  • broker.id 는 Kafka 브로커의 ID입니다.
  • log.dirs 는 로그 데이터의 디렉터리입니다.
  • Zookeeper.connect 는 Kafka를 Zoo Cryostat와 연결할 수 있는 구성입니다.
  • 리스너 는 Kafka 클러스터를 클라이언트에 노출
  • 권한 부여 메커니즘은 사용자가 실행하는 작업을 허용하거나 거부합니다.
  • 인증 메커니즘은 Kafka에 액세스해야 하는 사용자의 ID를 증명합니다.

기본 구성 옵션에 대한 자세한 내용은 Kafka 구성에서 확인할 수 있습니다.

일반적인 브로커 구성에는 주제, 스레드 및 로그와 관련된 속성 설정도 포함됩니다.

기본 브로커 구성 속성

# ...
num.partitions=1
default.replication.factor=3
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
num.network.threads=3
num.io.threads=8
num.recovery.threads.per.data.dir=1
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
group.initial.rebalance.delay.ms=0
zookeeper.connection.timeout.ms=6000
# ...
Copy to Clipboard Toggle word wrap

6.1.1.2. 고가용성을 위한 주제 복제
링크 복사

기본 주제 속성은 주제가 자동으로 생성되는 경우를 포함하여 이러한 속성을 명시적으로 설정하지 않고 생성된 항목에 적용되는 파티션 수와 복제 요소를 설정합니다. 

# ...
num.partitions=1
auto.create.topics.enable=false
default.replication.factor=3
min.insync.replicas=2
replica.fetch.max.bytes=1048576
# ...
Copy to Clipboard Toggle word wrap

auto.create.topics.enable 속성은 아직 존재하지 않는 항목이 생산자와 소비자에 의해 필요할 때 자동으로 생성되도록 기본적으로 활성화됩니다. 자동 주제 생성을 사용하는 경우 num.partitions 를 사용하여 주제의 기본 파티션 수를 설정할 수 있습니다. 그러나 일반적으로 이 속성은 명시적 주제 생성을 통해 주제를 통해 더 많은 제어가 제공되도록 비활성화되어 있습니다.

고가용성 환경의 경우 복제 요소를 주제의 경우 3 이상으로 늘리고 복제 요인보다 1 미만으로 필요한 최소 in-sync 복제본 수를 설정하는 것이 좋습니다.

데이터 지속성 의 경우 주제 구성에 min.insync.replicas 를 설정하고 생산자 구성에서 acks=all 을 사용하여 메시지 전달을 설정해야 합니다.

리더 파티션을 복제하는 각 후속자가 가져온 메시지의 최대 크기(바이트)를 설정하려면 replica.fetch.max.bytes 를 사용합니다. 평균 메시지 크기 및 처리량에 따라 이 값을 변경합니다. 읽기/쓰기 버퍼링에 필요한 총 메모리 할당을 고려할 때 사용 가능한 메모리는 모든 구현자를 곱할 때 최대 복제 메시지 크기를 수용할 수 있어야 합니다. 모든 메시지를 복제할 수 있도록 크기도 message.max.bytes 보다 커야 합니다.

항목을 삭제할 수 있도록 delete.topic.enable 속성은 기본적으로 활성화됩니다. 프로덕션 환경에서는 실수로 주제 삭제를 방지하기 위해 이 속성을 비활성화하여 데이터가 손실됩니다. 그러나 일시적으로 활성화한 후 주제를 삭제한 다음 다시 비활성화할 수 있습니다. 

# ...
auto.create.topics.enable=false
delete.topic.enable=true
# ...
Copy to Clipboard Toggle word wrap
6.1.1.3. 트랜잭션 및 커밋에 대한 내부 주제 설정
링크 복사

트랜잭션을 사용하여 생산자의 파티션에 대한 atomic 쓰기를 활성화하는 경우 트랜잭션 상태는 내부 __ Cryostat_state 항목에 저장됩니다. 기본적으로 브로커는 이 항목의 복제 요소 3과 최소 2개의 동기화 복제본으로 구성됩니다. 즉, Kafka 클러스터에 최소 3개의 브로커가 필요합니다. 

# ...
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
# ...
Copy to Clipboard Toggle word wrap

마찬가지로 소비자 상태를 저장하는 내부 __consumer_offsets 주제에는 파티션 수 및 복제 요인에 대한 기본 설정이 있습니다. 

# ...
offsets.topic.num.partitions=50
offsets.topic.replication.factor=3
# ...
Copy to Clipboard Toggle word wrap

프로덕션 환경에서 이러한 설정을 줄이지 마십시오. 프로덕션 환경에서 설정을 늘릴 수 있습니다. 예외적으로 단일broker 테스트 환경에서 설정을 줄일 수 있습니다.

6.1.1.4. I/O 스레드를 늘림으로써 요청 처리 처리량 개선
링크 복사

네트워크 스레드는 클라이언트 애플리케이션에서 요청을 생성하고 가져오는 등 Kafka 클러스터에 대한 요청을 처리합니다. 요청 생성은 요청 큐에 배치됩니다. 응답은 응답 큐에 배치됩니다.

네트워크 스레드 수는 복제 요소 및 Kafka 클러스터와 상호 작용하는 클라이언트 생산자 및 소비자의 활동 수준을 반영해야 합니다. 요청이 많은 경우 스레드 수를 늘릴 수 있습니다. 시간 스레드의 양을 사용하여 스레드를 추가할 시기를 결정합니다.

혼잡을 줄이고 요청 트래픽을 규제하기 위해 네트워크 스레드가 차단되기 전에 요청 큐에서 허용되는 요청 수를 제한할 수 있습니다.

I/O 스레드는 요청 대기열에서 요청을 가져와 처리합니다. 스레드를 추가하면 처리량이 향상될 수 있지만 CPU 코어 및 디스크 대역폭의 수는 실용적인 상한을 부과합니다. 최소한 I/O 스레드 수는 스토리지 볼륨 수와 같아야 합니다. 

# ...
num.network.threads=3
1 

queued.max.requests=500
2 

num.io.threads=8
3 

num.recovery.threads.per.data.dir=1
4 

# ...
Copy to Clipboard Toggle word wrap
1
Kafka 클러스터의 네트워크 스레드 수입니다.
2
요청 큐에 허용되는 요청 수입니다.
3
Kafka 브로커의 I/O 스레드 수입니다.
4
시작 시 로그 로드 및 종료 시 플러시에 사용되는 스레드 수입니다.

모든 브로커의 스레드 풀에 대한 구성 업데이트는 클러스터 수준에서 동적으로 발생할 수 있습니다. 이러한 업데이트는 현재 크기의 절반과 현재 크기의 두 배 사이로 제한됩니다.

참고

Kafka 브로커 메트릭은 필요한 스레드 수를 처리하는 데 도움이 될 수 있습니다. 예를 들어, 네트워크 스레드가 유휴 상태인 평균 시간(kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent)은 사용된 리소스의 백분율을 나타냅니다. 유휴 시간이 0%인 경우 모든 리소스가 사용 중이므로 더 많은 스레드를 추가하는 것이 유용할 수 있습니다.

디스크 수로 인해 스레드가 느리거나 제한되는 경우 처리량을 개선하기 위해 네트워크 요청의 버퍼 크기를 늘릴 수 있습니다. 

# ...
replica.socket.receive.buffer.bytes=65536
# ...
Copy to Clipboard Toggle word wrap

또한 수신할 수 있는 최대 바이트 수를 늘립니다. 

# ...
socket.request.max.bytes=104857600
# ...
Copy to Clipboard Toggle word wrap
6.1.1.5. 대기 시간이 긴 연결에 대한 대역폭 증가
링크 복사

Kafka는 데이터 센터 연결과 같이 Kafka에서 클라이언트로의 대기 시간이 긴 연결을 통해 합리적인 처리량을 달성하기 위해 데이터를 배치합니다. 그러나 대기 시간이 길면 메시지를 보내고 받기 위한 버퍼 크기를 늘릴 수 있습니다. 

# ...
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
# ...
Copy to Clipboard Toggle word wrap

대역폭 지연 제품 계산을 사용하여 버퍼의 최적 크기를 추정할 수 있습니다. 이 계산은 라운드트립 지연 (초 단위)과 링크의 최대 대역폭을 곱하여 최대 처리량을 유지하기 위해 버퍼의 크기를 추정할 수 있습니다.

6.1.1.6. 데이터 보존 정책을 사용하여 로그 관리
링크 복사

Kafka는 로그를 사용하여 메시지 데이터를 저장합니다. 로그는 다양한 인덱스와 연결된 일련의 세그먼트입니다. 새 메시지는 활성 세그먼트에 기록되며 이후에 수정되지 않습니다. 소비자의 가져오기 요청을 제공할 때 세그먼트를 읽습니다. 활성 세그먼트는 주기적으로 롤백 되어 읽기 전용이 되고 이를 대체하기 위해 새 활성 세그먼트가 생성됩니다. 한 번에 하나의 세그먼트만 활성화됩니다. 이전 세그먼트는 삭제할 수 있을 때까지 유지됩니다.

브로커 수준의 구성은 로그 세그먼트의 최대 크기(바이트)와 활성 세그먼트가 롤아웃되기 전의 시간(밀리초)을 설정합니다. 

# ...
log.segment.bytes=1073741824
log.roll.ms=604800000
# ...
Copy to Clipboard Toggle word wrap

segment.bytes 및 segment.ms 를 사용하여 주제 수준에서 이러한 설정을 재정의할 수 있습니다. 이러한 값을 낮추거나 늘릴 필요가 있는지 여부는 세그먼트 삭제 정책에 따라 다릅니다. 크기가 클수록 활성 세그먼트에 더 많은 메시지가 포함되어 있으며 덜 자주 롤백됩니다. 또한 세그먼트는 덜 자주 삭제할 수 있습니다.

로그를 관리할 수 있도록 시간 기반 또는 크기 기반 로그 보존 및 정리 정책을 설정할 수 있습니다. 요구 사항에 따라 로그 보존 구성을 사용하여 이전 세그먼트를 삭제할 수 있습니다. 로그 보존 정책이 사용되는 경우 보존 제한에 도달하면 비활성 로그 세그먼트가 제거됩니다. 이전 세그먼트를 삭제하면 로그에 필요한 스토리지 공간이 바인딩되어 디스크 용량을 초과하지 않습니다.

시간 기반 로그 보존의 경우 시간, 분 및 밀리초를 기준으로 보존 기간을 설정합니다. 보존 기간은 메시지가 세그먼트에 추가된 시간을 기반으로 합니다.

밀리초 단위 구성의 우선 순위는 분보다 우선하며, 이는 몇 시간보다 우선 순위가 높습니다. 분 및 밀리초 구성은 기본적으로 null이지만 세 가지 옵션은 유지하려는 데이터에 대한 상당한 수준의 제어를 제공합니다. 동적으로 업데이트할 수 있는 세 가지 속성 중 하나만이므로 기본 설정을 밀리초 구성에 제공해야 합니다. 

# ...
log.retention.ms=1680000
# ...
Copy to Clipboard Toggle word wrap

log.retention.ms 가 -1로 설정된 경우 로그 보존에 시간 제한이 적용되지 않으므로 모든 로그가 유지됩니다. 디스크 사용량은 항상 모니터링해야 하지만 -1 설정은 일반적으로 전체 디스크에 문제가 발생하여 수정하기 어려울 수 있으므로 권장되지 않습니다.

크기 기반 로그 보존의 경우 최대 로그 크기(로그의 모든 세그먼트)를 바이트 단위로 설정합니다. 

# ...
log.retention.bytes=1073741824
# ...
Copy to Clipboard Toggle word wrap

즉, 로그에는 steady 상태가 되면 일반적으로 약 log.retention.bytes/log.segment.bytes 세그먼트가 있습니다. 최대 로그 크기에 도달하면 이전 세그먼트가 제거됩니다.

최대 로그 크기를 사용할 때 발생할 수 있는 문제는 시간 메시지가 세그먼트에 추가되었음을 고려하지 않는다는 것입니다. 정리 정책에 시간 기반 및 크기 기반 로그 보존을 사용하여 필요한 균형을 얻을 수 있습니다. 먼저 도달한 임계값 중 정리를 트리거하는 것은 무엇입니까.

세그먼트 파일이 시스템에서 삭제되기 전에 시간 지연을 추가하려면 브로커 수준 또는 file.delete.delay.ms 의 모든 항목에 log.segment.delete.delay.ms 를 사용하여 해당 주제의 특정 항목에 대해 지연을 추가할 수 있습니다. 

# ...
log.segment.delete.delay.ms=60000
# ...
Copy to Clipboard Toggle word wrap
6.1.1.7. 정리 정책을 사용하여 로그 데이터 제거
링크 복사

이전 로그 데이터를 제거하는 방법은 로그 정리 구성에 따라 결정됩니다.

기본적으로 브로커에 대해 로그 정리가 활성화됩니다. 

# ...
log.cleaner.enable=true
# ...
Copy to Clipboard Toggle word wrap

주제 또는 브로커 수준에서 정리 정책을 설정할 수 있습니다. 브로커 수준 구성은 정책이 설정되지 않은 항목의 기본값입니다.

로그, 컴팩트 로그를 삭제하거나 둘 다 수행하는 정책을 설정할 수 있습니다. 

# ...
log.cleanup.policy=compact,delete
# ...
Copy to Clipboard Toggle word wrap

삭제 정책은 데이터 보존 정책을 사용하여 로그를 관리하는 데 해당합니다. 데이터가 영구적으로 유지될 필요가 없을 때 적합합니다. 컴팩트한 정책은 각 메시지 키에 대한 최신 메시지를 유지할 수 있도록 보장합니다. 로그 압축은 메시지 값을 변경할 수 있고 최신 업데이트를 유지해야 하는 경우에 적합합니다.

정리 정책이 로그를 삭제하도록 설정된 경우 로그 보존 제한을 기반으로 이전 세그먼트가 삭제됩니다. 그렇지 않으면 로그 정리기가 활성화되지 않고 로그 보존 제한이 없는 경우 로그가 계속 증가합니다.

정리 정책이 로그 압축용으로 설정된 경우 로그 헤드 는 새 메시지에 대한 쓰기 순서에 따라 표준 Kafka 로그로 작동합니다. 로그 정리기가 작동하는 컴팩트한 로그의 tail 에서는 로그에서 동일한 키가 있는 다른 레코드가 나중에 발생하면 레코드가 삭제됩니다. null 값이 있는 메시지도 삭제됩니다. 키를 사용하지 않는 경우 관련 메시지를 식별하는 데 키가 필요하므로 압축 기능을 사용할 수 없습니다. Kafka는 각 키의 최신 메시지가 유지되도록 보장하지만 전체 압축된 로그에는 중복이 포함되지 않도록 보장할 수는 없습니다.

그림 6.1. 압축하기 전에 오프셋 위치가 있는 키 값 쓰기를 표시하는 로그

키 값 쓰기를 표시하는 압축 기능
View larger image
키 값 쓰기를 표시하는 압축 기능

Kafka 압축은 메시지를 식별하기 위해 키를 사용하여 특정 메시지 키에 대해 최신 메시지(가장 높은 오프셋을 사용하여)를 유지하여 결국 동일한 키가 있는 이전 메시지를 삭제합니다. 즉, latest 상태의 메시지는 항상 사용할 수 있으며 로그 정리기가 실행될 때 특정 메시지의 최신 레코드가 결국 제거됩니다. 메시지를 다시 이전 상태로 복원할 수 있습니다.

레코드는 주변 레코드가 삭제되는 경우에도 원래 오프셋을 유지합니다. 결과적으로 tail은 연속적이지 않은 오프셋을 가질 수 있습니다. tail에서 더 이상 사용할 수 없는 오프셋을 사용하면 다음 상위 오프셋이 있는 레코드가 검색됩니다.

그림 6.2. 압축 후 로그

로그 정리 후 압축 이미지
View larger image
로그 정리 후 압축 이미지

컴팩트한 정책만 선택하면 로그가 임의로 커질 수 있습니다. 이 경우 로그를 압축 및 삭제하도록 정책을 설정할 수 있습니다. 컴팩트하고 삭제하도록 선택하면 먼저 로그 데이터가 압축되어 로그 헤드에 키가 있는 레코드를 제거합니다. 그런 다음 로그 보존 임계값 이전에 속하는 데이터가 삭제됩니다.

그림 6.3. 로그 보존 지점 및 압축 지점

보존 지점을 사용한 압축 이미지
View larger image
보존 지점을 사용한 압축 이미지

로그에서 정리를 확인하는 빈도를 밀리초 단위로 설정합니다. 

# ...
log.retention.check.interval.ms=300000
# ...
Copy to Clipboard Toggle word wrap

로그 보존 설정과 관련된 로그 보존 확인 간격을 조정합니다. 보존 크기가 작으면 더 자주 점검해야 할 수 있습니다.

정리 빈도는 디스크 공간을 관리하기에 충분한 경우가 많지만 주제의 성능에 영향을 미치는 경우가 많지는 않습니다.

정리할 로그가 없는 경우 대기 상태에 더 많은 시간을 배치하도록 시간(밀리초)을 설정할 수도 있습니다. 

# ...
log.cleaner.backoff.ms=15000
# ...
Copy to Clipboard Toggle word wrap

이전 로그 데이터를 삭제하도록 선택하는 경우 마침표를 밀리초 단위로 설정하여 삭제된 데이터를 제거하기 전에 유지할 수 있습니다. 

# ...
log.cleaner.delete.retention.ms=86400000
# ...
Copy to Clipboard Toggle word wrap

삭제된 데이터 보존 기간은 데이터가 삭제되기 전에 데이터가 손실되었음을 알리는 시간을 제공합니다.

특정 키와 관련된 모든 메시지를 삭제하려면 생산자가 tombstone 메시지를 보낼 수 있습니다. tombstone 에는 null 값이 있으며 사용자에게 값을 삭제하는 마커 역할을 합니다. 압축 후 tombstone만 유지되며, 이는 소비자가 메시지가 삭제되었음을 알 수 있도록 충분한 기간 동안 유지되어야 합니다. 이전 메시지가 삭제되면 값이 없으면 tombstone 키도 파티션에서 삭제됩니다.

6.1.1.8. 디스크 사용률 관리
링크 복사

로그 정리와 관련된 다른 많은 구성 설정이 있지만 특히 메모리 할당은 중요합니다.

중복 제거 속성은 모든 로그 정리 스레드에서 정리에 대한 총 메모리를 지정합니다. 버퍼 로드 요소를 통해 사용된 메모리의 백분율에 대한 상한을 설정할 수 있습니다. 

# ...
log.cleaner.dedupe.buffer.size=134217728
log.cleaner.io.buffer.load.factor=0.9
# ...
Copy to Clipboard Toggle word wrap

각 로그 항목은 정확히 24바이트를 사용하므로 버퍼가 단일 실행에서 처리할 수 있는 로그 항목 수를 확인하고 그에 따라 설정을 조정할 수 있습니다.

가능한 경우 로그 정리 시간을 줄이려는 경우 로그 정리 스레드 수를 늘리는 것이 좋습니다. 

# ...
log.cleaner.threads=8
# ...
Copy to Clipboard Toggle word wrap

100% 디스크 대역폭 사용량에 문제가 발생하면 로그 정리 I/O를 제한하여 작업을 수행하는 디스크 기능에 따라 읽기/쓰기 작업의 합계가 지정된 이중 값보다 작도록 할 수 있습니다. 

# ...
log.cleaner.io.max.bytes.per.second=1.7976931348623157E308
# ...
Copy to Clipboard Toggle word wrap
6.1.1.9. 큰 메시지 크기 처리
링크 복사

메시지의 기본 배치 크기는 1MB이며 대부분의 사용 사례에서 최대 처리량에 적합합니다. Kafka는 적절한 디스크 용량을 가정하면 처리량이 감소된 대규모 배치를 수용할 수 있습니다.

큰 메시지 크기는 다음 네 가지 방법으로 처리됩니다.

  1. 생산자 측 메시지 압축 은 압축 메시지를 로그에 씁니다.
  2. 참조 기반 메시징은 메시지의 값에 다른 시스템에 저장된 데이터에 대한 참조만 보냅니다.
  3. 인라인 메시징은 메시지를 동일한 키를 사용하는 청크로 분할한 다음 Kafka Streams와 같은 스트림 프로세서를 사용하여 출력에 결합됩니다.
  4. 더 큰 메시지 크기를 처리하도록 구축된 브로커 및 생산자/소유 클라이언트 애플리케이션 구성입니다.

참조 기반 메시징 및 메시지 압축 옵션이 권장되며 대부분의 상황을 다룹니다. 이러한 옵션을 사용하면 성능 문제가 발생하지 않도록 주의해야 합니다.

생산자 측 압축

생산자 구성의 경우 생산자가 생성한 데이터의 배치에 적용되는 Gzip과 같은 compression.type 을 지정합니다. 브로커는 브로커 구성 compression.type=producer 를 사용하여 생산자가 사용한 압축을 유지합니다. 생산자 및 주제 압축이 일치하지 않을 때마다 브로커는 로그에 추가하기 전에 일괄 처리를 다시 압축해야 브로커 성능에 영향을 미칩니다.

압축은 또한 소비자에 생산자 및 압축 해제 오버헤드에 추가 처리 오버헤드를 추가하지만 배치에 더 많은 데이터를 포함하므로 메시지 데이터가 잘 압축될 때 처리량에 도움이 되는 경우가 많습니다.

생산자 측 압축을 배치 크기의 미세 조정과 결합하여 처리량을 극대화할 수 있습니다. 메트릭을 사용하면 필요한 평균 배치 크기를 측정하는 데 도움이 됩니다.

참조 기반 메시징

참조 기반 메시징은 메시지의 규모를 모르는 경우 데이터 복제에 유용합니다. 외부 데이터 저장소는 이 구성이 작동하려면 빠르고 사용 가능한 고가용성이어야 합니다. 데이터는 데이터 저장소에 기록되고 데이터에 대한 참조가 반환됩니다. 생산자는 Kafka에 대한 참조가 포함된 메시지를 보냅니다. 소비자는 메시지에서 참조를 가져와서 이를 사용하여 데이터 저장소에서 데이터를 가져옵니다.

그림 6.4. 참조 기반 메시징 흐름

참조 기반 메시징 흐름의 이미지
View larger image
참조 기반 메시징 흐름의 이미지

메시지 전달에는 더 많은 여행이 필요하므로 엔드 투 엔드 대기 시간이 증가합니다. 이 접근 방식의 또 다른 중요한 단점은 Kafka 메시지가 정리될 때 외부 시스템의 데이터를 자동으로 정리하지 않는다는 것입니다. 하이브리드 접근 방식은 대규모 메시지를 데이터 저장소로만 전송하고 표준 크기의 메시지를 직접 처리하는 것입니다.

인라인 메시징

인라인 메시징은 복잡하지만 참조 기반 메시징과 같은 외부 시스템에 따라 의 오버헤드가 없습니다.

생성 클라이언트 애플리케이션은 메시지가 너무 크면 데이터를 직렬화한 다음 청크해야 합니다. 그런 다음 생산자는 Kafka Cryostat ArraySerializer 를 사용하거나 각 청크를 보내기 전에 다시 직렬화하는 것과 유사합니다. 소비자는 전체 메시지가 있을 때까지 메시지 및 버퍼 청크를 추적합니다. 클라이언트 애플리케이션을 사용하는 애플리케이션은 역직렬화 전에 어셈블되는 청크를 수신합니다. 전체 메시지는 청크된 각 메시지 세트에 대한 첫 번째 또는 마지막 청크 오프셋에 따라 소비되는 애플리케이션의 나머지 부분에 전달됩니다. 리밸런스 중 중복을 방지하기 위해 전체 메시지를 오프셋 메타데이터에 대해 성공적으로 전달할 수 있습니다.

그림 6.5. 인라인 메시징 흐름

인라인 메시징 흐름의 이미지
View larger image
인라인 메시징 흐름의 이미지

인라인 메시징은 특히 일련의 대규모 메시지를 병렬로 처리할 때 필요한 버퍼링 때문에 소비자 측에서 성능 오버헤드가 발생합니다. 버퍼에 있는 다른 대규모 메시지의 청크가 불완전하면 메시지의 모든 청크가 사용되었을 때 커밋할 수 없도록 대규모 메시지의 청크가 인터리브될 수 있습니다. 이러한 이유로 메시지 청크를 유지하거나 커밋 논리를 구현하여 버퍼링이 일반적으로 지원됩니다.

더 큰 메시지를 처리하는 구성

더 큰 메시지를 방지할 수 없고 메시지 흐름의 어느 시점에서든 블록을 피하기 위해 메시지 제한을 늘릴 수 있습니다. 이렇게 하려면 주제 수준에서 message.max.bytes 를 구성하여 개별 주제의 최대 레코드 배치 크기를 설정합니다. 브로커 수준에서 message.max.bytes 를 설정하면 모든 주제에 대해 더 큰 메시지가 허용됩니다.

브로커는 message.max.bytes 로 설정된 제한보다 큰 메시지를 거부합니다. 생산자(max.request.size) 및 소비자(message.max.bytes)의 버퍼 크기는 더 큰 메시지를 수용할 수 있어야 합니다.

6.1.1.10. 메시지 데이터의 로그 플러시 제어
링크 복사

로그 플러시 속성은 캐시된 메시지 데이터의 주기적인 쓰기를 디스크에 제어합니다. 스케줄러는 로그 캐시의 검사 빈도를 밀리초 단위로 지정합니다. 

# ...
log.flush.scheduler.interval.ms=2000
# ...
Copy to Clipboard Toggle word wrap

메시지가 메모리에 보관되는 최대 시간과 디스크에 쓰기 전에 로그의 최대 메시지 수에 따라 플러시 빈도를 제어할 수 있습니다. 

# ...
log.flush.interval.ms=50000
log.flush.interval.messages=100000
# ...
Copy to Clipboard Toggle word wrap

플러시 간 대기에는 플러시를 수행하기 전에 검사를 수행하는 시간과 지정된 간격이 포함됩니다. 플러시 빈도를 늘리면 처리량에 영향을 미칠 수 있습니다.

일반적으로 명시적 플러시 임계값을 설정하지 않고 운영 체제가 기본 설정을 사용하여 백그라운드 플러시를 수행하도록 하는 것이 좋습니다. 파티션 복제는 실패한 브로커가 동기화된 복제본에서 복구할 수 있으므로 단일 디스크에 쓰기보다 데이터 지속성을 향상시킵니다.

애플리케이션 플러시 관리를 사용하는 경우 더 빠른 디스크를 사용하는 경우 플러시 임계값을 낮추는 것이 적합할 수 있습니다.

6.1.1.11. 가용성에 대한 파티션 재조정
링크 복사

내결함성을 위해 브로커 간에 파티션을 복제할 수 있습니다. 지정된 파티션의 경우 하나의 브로커가 리더로 선택되고 모든 생성 요청을 처리합니다(로그에 쓰기). 다른 브로커의 파티션 팀은 리더가 실패할 경우 데이터 안정성을 위해 파티션 리더의 파티션 데이터를 복제합니다.

erser는 일반적으로 클라이언트를 제공하지 않지만 broker.rack 을 사용하면 Kafka 클러스터가 여러 데이터 센터에 걸쳐 있을 때 소비자가 가장 가까운 복제본에서 메시지를 사용할 수 있습니다. 차선은 파티션 리더의 메시지를 복제하고 리더가 실패할 경우 복구를 허용하기 위해서만 작동합니다. 복구에는 동기화 내 후속 조치가 필요합니다. 조각화는 리더에게 페치 요청을 보내 동기화 상태를 유지하며, 이 리더에게 메시지를 순서대로 반환합니다. 팔로워는 리더에서 가장 최근에 커밋된 메시지와 함께 배치된 경우 동기화된 것으로 간주됩니다. 리더는 후속자가 요청한 마지막 오프셋을 확인하여 이를 확인합니다. 예기치 않은 리더 선택이 허용되지 않는 한 현재 리더가 실패해야 하는 리더로서 일반적으로 동기화되지 않은 후속 조치를 취할 수 없습니다.

후속 작업이 동기화되지 않은 것으로 간주되기 전에 지연 시간을 조정할 수 있습니다. 

# ...
replica.lag.time.max.ms=30000
# ...
Copy to Clipboard Toggle word wrap

지연 시간이 동기화된 모든 복제본에 메시지를 복제하는 시간과 생산자가 승인을 기다려야 하는 기간을 지정합니다. 후속 프로그램이 가져오기 요청을 작성하고 지정된 지연 시간 내에 최신 메시지를 catch하지 못하면 동기화 내 복제본에서 제거됩니다. 실패한 복제본을 더 빨리 감지할 수 있는 지연 시간을 줄일 수 있지만 이렇게 하면 불필요하게 동기화되지 않는 자국 수를 늘릴 수 있습니다. 올바른 지연 시간 값은 네트워크 대기 시간과 브로커 디스크 대역폭에 따라 다릅니다.

리더 파티션을 더 이상 사용할 수 없는 경우 동기화 중인 복제본 중 하나가 새 리더로 선택됩니다. 파티션의 복제본 목록의 첫 번째 브로커를 선호하는 리더라고 합니다. 기본적으로 Kafka는 리더 배포 주기에 따라 자동 파티션 리더 재조정에 대해 활성화됩니다. 즉 Kafka에서 기본 리더가 현재 리더인지 확인합니다. 리밸런스를 사용하면 브로커와 브로커 간에 리더가 균등하게 분배되지 않습니다.

AMQ Streams에 대한 Cruise Control을 사용하여 클러스터 전체에서 부하를 균등하게 조정하는 브로커에 대한 복제본 할당을 파악할 수 있습니다. 그 계산은 리더와 팔로워가 경험하는 다양한 부하를 고려합니다. 나머지 브로커는 주요 추가 파티션의 추가 작업을 받기 때문에 실패한 리더는 Kafka 클러스터의 균형에 영향을 미칩니다.

Cruise Control이 실제로 균형을 맞추려면 기본 리더가 파티션을 이끌 필요가 있습니다. Kafka는 기본 리더가 사용되도록 자동으로 확인할 수 있으며 필요한 경우 현재 리더를 변경할 수 있습니다. 이렇게 하면 클러스터가 Cruise Control에서 찾은 균형 있는 상태로 유지됩니다.

리밸런스 검사의 빈도(초)와 리밸런스가 트리거되기 전에 브로커에 허용되는 최대 불균형 비율을 제어할 수 있습니다. 

#...
auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10
#...
Copy to Clipboard Toggle word wrap

브로커의 백분율 리더 불균형은 브로커가 현재 리더인 현재 파티션 수와 기본 리더인 파티션 수 간의 비율입니다. 백분율을 0으로 설정하여 선호되는 리더가 항상 동기화 중이라고 가정하도록 할 수 있습니다.

리밸런스에 대한 재조정에 더 많은 제어가 필요한 경우 자동 리밸런스를 비활성화할 수 있습니다. 그런 다음 kafka-leader-election.sh 명령줄 도구를 사용하여 리밸런스를 트리거할 시기를 선택할 수 있습니다.

참고

AMQ Streams와 함께 제공되는 Grafana 대시보드는 활성 리더가 없는 비복제 파티션 및 파티션에 대한 지표를 보여줍니다.

6.1.1.12. 불명확한 리더 선택
링크 복사

동기화되지 않은 복제본의 리더는 데이터 손실을 보장하므로 정리된 것으로 간주됩니다. 이 작업은 기본적으로 수행됩니다. 그러나 리더십을 위해 동기화되지 않은 복제본이 없으면 어떻게 됩니까? ISR(In-sync) 복제본에는 리더 디스크가 사라진 경우에만 리더가 포함되어 있을 수 있습니다. 최소 동기화 내 복제본 수를 설정하지 않고 하드 드라이브가 실패할 때 파티션 리더와 동기화되는 팔로워가 없는 경우 데이터가 이미 손실됩니다. 그뿐만 아니라 동기화 되지 않은 자국이 없기 때문에 새로운 리더를 선택할 수 없습니다.

Kafka에서 리더 실패를 처리하는 방법을 구성할 수 있습니다. 

# ...
unclean.leader.election.enable=false
# ...
Copy to Clipboard Toggle word wrap

불명확한 리더 선택은 기본적으로 비활성화되어 있습니다. 즉, 동기화되지 않은 복제본이 리더가 될 수 없습니다. 명확한 리더 선택을 통해 이전 리더가 손실되었을 때 다른 브로커가 ISR에 없는 경우 Kafka는 메시지를 쓰거나 읽을 수 있기 전에 해당 리더가 다시 온라인 상태가 될 때까지 기다립니다. 비정형 리더 선택이란 동기화되지 않은 복제본이 리더가 될 수 있지만 메시지를 손실할 위험이 있습니다. 고객의 요구 사항이 가용성 또는 지속성을 선호하는지 여부에 따라 선택할 수 있습니다.

주제 수준에서 특정 주제의 기본 구성을 재정의할 수 있습니다. 데이터 손실 위험을 감수할 수 없는 경우 기본 구성을 그대로 둡니다.

6.1.1.13. 불필요한 소비자 그룹 재조정 방지
링크 복사

새 소비자 그룹에 가입하는 소비자의 경우 지연을 추가하여 브로커에 불필요한 재조정을 피할 수 있습니다. 

# ...
group.initial.rebalance.delay.ms=3000
# ...
Copy to Clipboard Toggle word wrap

지연은 코디네이터가 멤버가 참여할 때까지 대기하는 시간입니다. 지연이 길어질수록 모든 멤버가 제 시간에 참여하고 재조정을 피할 가능성이 높습니다. 그러나 지연은 기간이 종료될 때까지 그룹이 소비되지 않도록합니다.

6.1.2. Kafka 생산자 구성 튜닝
링크 복사

특정 사용 사례에 맞는 선택적 속성이 포함된 기본 생산자 구성을 사용합니다.

처리량을 극대화하도록 구성을 조정하면 대기 시간이 증가하거나 그 반대의 경우도 발생할 수 있습니다. 필요한 균형을 유지하기 위해 생산자 구성을 실험하고 튜닝해야 합니다.

6.1.2.1. 기본 생산자 구성
링크 복사

모든 생산자에 연결 및 serializer 속성이 필요합니다. 일반적으로 추적을 위해 클라이언트 ID를 추가하고 생산자에 압축을 사용하여 요청의 배치 크기를 줄이는 것이 좋습니다.

기본 생산자 구성에서 다음을 수행합니다.

  • 파티션의 메시지 순서가 보장되지 않습니다.
  • 브로커에 도달하는 메시지에 대한 승인은 지속성을 보장하지 않습니다.

기본 생산자 구성 속성

# ...
bootstrap.servers=localhost:9092
1 

key.serializer=org.apache.kafka.common.serialization.StringSerializer
2 

value.serializer=org.apache.kafka.common.serialization.StringSerializer
3 

client.id=my-client
4 

compression.type=gzip
5 

# ...
Copy to Clipboard Toggle word wrap

1
(필수) Kafka 브로커의 host:port 부트스트랩 서버 주소를 사용하여 Kafka 클러스터에 연결하도록 생산자를 Tells합니다. 생산자는 주소를 사용하여 클러스터의 모든 브로커를 검색하고 연결합니다. 서버가 다운된 경우 쉼표로 구분된 목록을 사용하여 두 개 또는 세 개의 주소를 지정하지만 클러스터의 모든 브로커 목록을 제공할 필요는 없습니다.
2
(필수) 각 메시지의 키를 브로커로 보내기 전에 바이트로 변환하는 Serializer.
3
(필수) 각 메시지의 값을 브로커로 보내기 전에 바이트로 변환하는 Serializer.
4
(선택 사항) 요청 소스를 식별하기 위해 로그 및 메트릭에 사용되는 클라이언트의 논리 이름입니다.
5
(선택 사항) 전송된 메시지를 압축하고 압축 형식으로 저장한 다음 소비자에 도달할 때 압축을 풉니다. 압축은 처리량을 개선하고 스토리지의 부하를 줄이는 데 유용하지만 압축 또는 압축 해제 비용이 금지될 수 있는 짧은 대기 시간 애플리케이션에는 적합하지 않을 수 있습니다.
6.1.2.2. 데이터 지속성
링크 복사

메시지 전송 승인을 사용하여 메시지가 손실될 가능성을 최소화하기 위해 더 큰 데이터 지속성을 적용할 수 있습니다. 

# ...
acks=all
1 

# ...
Copy to Clipboard Toggle word wrap
1
acks=all 을 지정하면 메시지 요청이 성공적으로 수신되었음을 확인하기 전에 파티션 리더가 특정 수의 팔로우에 메시지를 복제해야 합니다. 추가 검사로 인해 acks=all 은 메시지를 전송하고 승인을 수신하는 생산자 간의 대기 시간을 늘립니다.

승인이 생산자로 전송되기 전에 로그에 메시지를 추가해야 하는 브로커 수는 주제의 min.insync.replicas 구성에 따라 결정됩니다. 일반적인 시작 지점은 다른 브로커에 두 개의 동기화 내 복제본이 있는 3의 주제 복제 인수를 갖는 것입니다. 이 구성에서 단일 브로커를 사용할 수 없는 경우 생산자는 영향을 받지 않을 수 있습니다. 두 번째 브로커를 사용할 수 없게 되면 생산자는 승인을 받지 못하며 더 많은 메시지를 생성할 수 없습니다.

acks=all을 지원하는 주제 구성

# ...
min.insync.replicas=2
1 

# ...
Copy to Clipboard Toggle word wrap

1
2 개의 동기화된 복제본을 사용합니다. 기본값은 1입니다.
참고

시스템이 실패하면 버퍼에 의도하지 않은 데이터가 손실될 위험이 있습니다.

6.1.2.3. 주문 배송
링크 복사

멱등 생산자는 메시지가 정확히 한 번 전송되므로 중복을 방지합니다. ID 및 순서 번호는 실패 시에도 전달 순서를 보장하기 위해 메시지에 할당됩니다. 데이터 일관성을 위해 acks=all 을 사용하는 경우, 주문된 전송에 멱등을 활성화하는 것이 적절합니다.

idempotency로 주문된 제공

# ...
enable.idempotence=true
1 

max.in.flight.requests.per.connection=5
2 

acks=all
3 

retries=2147483647
4 

# ...
Copy to Clipboard Toggle word wrap

1
idempotent 생산자를 활성화하려면 true 로 설정합니다.
2
idempotent delivery를 사용하면 메시지 순서 보장을 계속 제공하는 동안 진행 중인 요청 수가 1보다 클 수 있습니다. 기본값은 5 in-flight 요청입니다.
3
acks 를 all 로 설정합니다.
4
실패한 메시지 요청을 다시 전송하려는 시도 횟수를 설정합니다.

성능 비용 때문에 acks=all 및 idempotency를 사용하지 않는 경우 순서를 유지하기 위해 in-flight(알림되지 않음) 요청 수를 1로 설정합니다. 그렇지 않으면 Message-B 가 이미 브로커에 기록된 후에만 Message-A 가 성공하지 못하는 상황이 발생할 수 있습니다.

idempotency 없이 주문된 제공

# ...
enable.idempotence=false
1 

max.in.flight.requests.per.connection=1
2 

retries=2147483647
# ...
Copy to Clipboard Toggle word wrap

1
idempotent 생산자를 비활성화하려면 false 로 설정합니다.
2
진행 중인 요청 수를 정확히 1 로 설정합니다.
6.1.2.4. 신뢰성 보장
링크 복사

멱등은 단일 파티션에 정확히 한 번 쓰는 데 유용합니다. 멱등과 함께 사용되는 트랜잭션은 여러 파티션에 정확히 한 번의 쓰기를 허용합니다.

트랜잭션을 사용하면 동일한 트랜잭션 ID를 사용하는 메시지가 한 번 생성되고 모두 해당 로그에 성공적으로 기록되거나 그 중 하나가 표시되지 않습니다. 

# ...
enable.idempotence=true
max.in.flight.requests.per.connection=5
acks=all
retries=2147483647
transactional.id=UNIQUE-ID
1 

transaction.timeout.ms=900000
2 

# ...
Copy to Clipboard Toggle word wrap
1
고유한 트랜잭션 ID를 지정합니다.
2
시간 초과 오류가 반환되기 전에 허용되는 최대 트랜잭션 시간을 밀리초 단위로 설정합니다. 기본값은 900000 또는 15분입니다.

transactional.id 를 선택하는 것은 트랜잭션 보장이 유지되는 순서대로 중요합니다. 각 트랜잭션 ID는 고유한 주제 파티션 집합에 사용해야 합니다. 예를 들어, 이는 주제 파티션 이름의 외부 매핑을 트랜잭션 ID에 연결하거나 충돌을 방지하는 함수를 사용하여 주제 파티션 이름에서 트랜잭션 ID를 계산하여 수행할 수 있습니다.

6.1.2.5. 처리량 및 대기 시간 최적화
링크 복사

일반적으로 시스템의 요구 사항은 지정된 대기 시간 내의 메시지 비율에 대한 특정 처리량 대상을 충족하기 위한 것입니다. 예를 들어 초당 500,000개의 메시지를 대상으로 하는 메시지 중 95%가 2초 이내에 승인됩니다.

생산자의 메시징 의미 체계(메시지 순서 및 지속성)는 애플리케이션의 요구 사항에 따라 정의됩니다. 예를 들어 애플리케이션에서 제공하는 중요한 속성이나 보장을 손상시키지 않고 acks=0 또는 acks=1 을 사용할 수 있는 옵션이 없을 수 있습니다.

브로커 재시작은 높은 백분위 통계에 큰 영향을 미칩니다. 예를 들어 오랜 기간 동안 99번째 백분위 대기 시간이 브로커 재시작에 대한 동작으로 지배됩니다. 이는 벤치마크를 설계하거나 벤치마킹에서 성능 번호를 프로덕션에서 볼 수 있는 성능 수와 비교할 때 고려해야 합니다.

Kafka는 목표에 따라 처리량 및 대기 시간을 위해 생산자 성능 튜닝을 위한 다양한 구성 매개변수와 기술을 제공합니다.

메시지 일괄 처리(linger.ms 및 batch.size)
메시지 일괄 처리는 동일한 브로커로 향하는 더 많은 메시지가 전송되어 단일 생성 요청에 일괄 처리할 수 있기를 바랍니다. 일괄 처리는 처리량이 증가하기 위해 대기 시간이 길기 때문에 지연 시간이 길어집니다.Batching is a compromise between higher latency in return for higher throughput. 시간 기반 일괄 처리는 linger.ms 를 사용하여 구성되며 크기 기반 일괄 처리는 batch.size 를 사용하여 구성됩니다.
압축(compression.type)
메시지 압축은 생산자에 대기 시간을 추가하지만(메시지 압축에 사용된 CPU 시간) 요청(및 잠재적으로 디스크 쓰기)을 줄여 처리량을 높일 수 있습니다. 압축 여부, 사용할 최상의 압축은 전송되는 메시지에 따라 달라집니다. KafkaProducer.send() 를 호출하는 스레드에서 압축이 수행되므로 이 방법의 대기 시간이 애플리케이션에 중요한 경우 더 많은 스레드 사용을 고려해야 합니다.
pipelining (max.in.flight.requests.per.connection)
pipelining은 이전 요청에 대한 응답이 수신되기 전에 더 많은 요청을 보내는 것을 의미합니다. 일반적으로 파이프라이닝은 더 나은 처리량을 의미하며, 이로 인해 더 심각한 일괄 처리와 같은 다른 효과의 경우 처리량에 대한 영향을 대응하기 시작합니다.

대기 시간 단축

애플리케이션이 KafkaProducer.send() 를 호출할 때 메시지는 다음과 같습니다.

  • 인터셉터에서 처리
  • 직렬화됨
  • 파티션에 할당됨
  • 압축
  • 파티션별 큐의 메시지 배치에 추가됨

이 시점에서 send() 메서드가 반환됩니다. 따라서 send() 가 차단되는 시간은 다음에 따라 결정됩니다.

  • 인터셉터, serializers 및 partitioner에 소요된 시간
  • 사용된 압축 알고리즘
  • 버퍼가 압축에 사용할 때까지 대기하는 시간

배치는 다음 중 하나가 발생할 때까지 큐에 유지됩니다.

  • 배치가 가득 차 있습니다 ( batch.size에 따라 )
  • linger.ms 에 의해 도입된 지연이 통과되었습니다.
  • 발신자는 다른 파티션의 메시지 일괄 처리를 동일한 브로커로 보내려고 하며 이 배치도 추가할 수 있습니다.
  • 프로듀서가 플러시되거나 닫히고 있습니다.

대기 시간에 대한 send() 차단의 영향을 완화하기 위한 일괄 처리 및 버퍼링 구성을 확인합니다. 

# ...
linger.ms=100
1 

batch.size=16384
2 

buffer.memory=33554432
3 

# ...
Copy to Clipboard Toggle word wrap
1
linger 속성은 지연 시간(밀리초)을 추가하여 더 큰 메시지 배치가 누적되어 요청에 전송되도록 합니다. 기본값은 0입니다.
2
바이트 단위로 최대 batch.size 를 사용하면 최대값에 도달할 때 요청이 전송되거나 메시지가 linger.ms 보다 오래 대기되었습니다(더 빨리 발생함). 지연을 추가하면 일괄 처리를 통해 일괄 처리로 일괄 처리까지 메시지를 누적할 수 있습니다.
3
버퍼 크기는 배치 크기만큼 커야 하며 버퍼링, 압축 및 진행 중 요청을 수용할 수 있어야 합니다.

처리량 증가

메시지가 전달되고 전송 요청을 완료할 때까지 대기할 최대 시간을 조정하여 메시지 요청의 처리량을 개선합니다.

또한 기본값을 대체하기 위해 사용자 지정 partitioner를 작성하여 지정된 파티션으로 메시지를 보낼 수도 있습니다. 

# ...
delivery.timeout.ms=120000
1 

partitioner.class=my-custom-partitioner
2 


# ...
Copy to Clipboard Toggle word wrap
1
전체 전송 요청을 대기하는 최대 시간(밀리초)입니다. 값을 MAX_LONG 로 설정하여 무제한 재시도 횟수를 Kafka에 위임할 수 있습니다. 기본값은 120000 또는 2분입니다.
2
사용자 지정 파티션의 클래스 이름을 지정합니다.

6.1.3. Kafka 소비자 구성 튜닝
링크 복사

특정 사용 사례에 맞는 선택적 속성이 포함된 기본 소비자 구성을 사용합니다.

소비자를 튜닝할 때 주요 우려 사항은 수집된 데이터 양으로 효율적으로 처리되도록 하는 것입니다. 생산자 튜닝과 마찬가지로 소비자가 예상대로 작동할 때까지 점진적으로 변경할 준비가 되어 있어야 합니다.

6.1.3.1. 기본 소비자 구성
링크 복사

모든 소비자에 연결 및 역직렬러 속성이 필요합니다. 일반적으로 추적을 위해 클라이언트 ID를 추가하는 것이 좋습니다.

후속 구성과 관계없이 소비자 구성에서 다음을 수행합니다.

  • 소비자는 지정된 오프셋에서 메시지를 가져오고 메시지를 건너뛰거나 다시 읽도록 오프셋이 변경되지 않는 한 순서대로 메시지를 사용합니다.
  • 오프셋이 클러스터의 다른 브로커로 전송될 수 있기 때문에 Kafka에 오프셋을 커밋하는 경우에도 브로커가 응답을 처리했는지 여부를 알 수 없습니다.

기본 소비자 구성 속성

# ...
bootstrap.servers=localhost:9092
1 

key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
2 

value.deserializer=org.apache.kafka.common.serialization.StringDeserializer
3 

client.id=my-client
4 

group.id=my-group-id
5 

# ...
Copy to Clipboard Toggle word wrap

1
(필수) Kafka 브로커의 host:port 부트스트랩 서버 주소를 사용하여 Kafka 클러스터에 연결하도록 소비자를 Tells합니다. 소비자는 주소를 사용하여 클러스터의 모든 브로커를 검색하고 연결합니다. 서버가 다운된 경우 쉼표로 구분된 목록을 사용하여 두 개 또는 세 개의 주소를 지정하지만 클러스터의 모든 브로커 목록을 제공할 필요는 없습니다. 로드 밸런서 서비스를 사용하여 Kafka 클러스터를 노출하는 경우 로드 밸런서에서 가용성을 처리하므로 서비스의 주소만 있으면 됩니다.
2
(필수) Kafka 브로커에서 가져온 바이트를 메시지 키로 변환하는 Deserializer입니다.
3
(필수) Kafka 브로커에서 가져온 바이트를 메시지 값으로 변환하는 Deserializer입니다.
4
(선택 사항) 요청 소스를 식별하기 위해 로그 및 메트릭에 사용되는 클라이언트의 논리 이름입니다. id는 또한 처리 시간 할당량을 기반으로 소비자를 차단하는 데 사용할 수 있습니다.
5
(조건) 소비자가 소비자 그룹에 가입하려면 그룹 ID가 필요합니다.
6.1.3.2. 소비자 그룹을 사용하여 데이터 사용량 확장
링크 복사

소비자 그룹은 지정된 주제에서 하나 이상의 생산자가 생성한 일반적으로 대규모 데이터 스트림을 공유합니다. 소비자는 group.id 속성을 사용하여 그룹화되므로 메시지를 멤버에 분산할 수 있습니다. 그룹의 소비자 중 한 명이 리더를 선택하고 그룹의 사용자에게 파티션을 할당하는 방법을 결정합니다. 각 파티션은 단일 소비자에만 할당할 수 있습니다.

파티션만큼 많은 소비자가 없는 경우 동일한 group.id 를 사용하여 더 많은 소비자 인스턴스를 추가하여 데이터 소비를 확장할 수 있습니다. 파티션이 있는 것보다 더 많은 소비자를 그룹에 추가하면 처리량은 도움이 되지 않지만 대기 상태의 소비자가 작동을 중지해야 함을 의미합니다. 더 적은 소비자로 처리량 목표를 달성할 수 있는 경우 리소스를 절약할 수 있습니다.

동일한 소비자 그룹 내의 소비자는 오프셋 커밋과 하트비트를 동일한 브로커에 보냅니다. 따라서 그룹의 소비자 수가 많을수록 브로커에 요청이 로드됩니다. 

# ...
group.id=my-group-id
1 

# ...
Copy to Clipboard Toggle word wrap
1
그룹 ID를 사용하여 소비자 그룹에 소비자를 추가합니다.
6.1.3.3. 메시지 순서 확인
링크 복사

Kafka 브로커는 브로커에 주제, 파티션 및 오프셋 위치 목록에서 메시지를 전송하도록 요청하는 소비자의 가져오기 요청을 받습니다.

소비자는 브로커에 커밋된 것과 동일한 순서로 단일 파티션의 메시지를 관찰합니다. 즉 Kafka는 단일 파티션의 메시지에 대한 순서 만 보장합니다. 반대로, 소비자가 여러 파티션의 메시지를 사용하는 경우 소비자가 관찰한 여러 파티션의 메시지 순서가 전송된 순서를 반영하지 않습니다.

한 주제에서 메시지 순서를 엄격하게 지정하려면 소비자당 하나의 파티션을 사용합니다.

6.1.3.4. 처리량 및 대기 시간 최적화
링크 복사

클라이언트 애플리케이션이 KafkaConsumer.poll() 을 호출할 때 반환된 메시지 수를 제어합니다.

fetch.max.wait.ms 및 fetch.min.bytes 속성을 사용하여 Kafka 브로커에서 소비자가 가져온 최소 데이터 양을 늘립니다. 시간 기반 일괄 처리는 fetch.max.wait.ms 를 사용하여 구성되며 크기 기반 일괄 처리는 fetch.min.bytes 를 사용하여 구성됩니다.

소비자 또는 브로커의 CPU 사용률이 높으면 소비자의 요청이 너무 많기 때문일 수 있습니다. 더 적은 요청 및 메시지가 더 큰 배치로 전달되도록 fetch.max.wait.ms 및 fetch.min.bytes 속성을 더 높게 조정할 수 있습니다. 높은 조정을 통해 처리량은 약간의 대기 시간으로 개선됩니다. 또한 생성되는 데이터 양이 낮은 경우 더 높게 조정할 수도 있습니다.

예를 들어 fetch.max.wait.ms 를 500ms로 설정하고 fetch.min.bytes 를 16384바이트로 설정하면 Kafka에서 소비자로부터 가져오기 요청을 수신하면 두 임계값 중 첫 번째에 도달할 때 응답합니다.

반대로 fetch.max.wait.ms 및 fetch.min.bytes 속성을 더 낮게 조정하여 엔드 투 엔드 대기 시간을 개선할 수 있습니다. 

# ...
fetch.max.wait.ms=500
1 

fetch.min.bytes=16384
2 

# ...
Copy to Clipboard Toggle word wrap
1
브로커가 가져오기 요청을 완료하기 전에 대기하는 최대 시간(밀리초)입니다. 기본값은 500 밀리초입니다.
2
최소 배치 크기(바이트)가 사용되는 경우 최소에 도달하면 요청이 전송되거나, 메시지가 fetch.max.wait.ms 보다 오래 대기되었습니다(더 빨리 발생함). 지연을 추가하면 일괄 처리를 통해 일괄 처리로 일괄 처리까지 메시지를 누적할 수 있습니다.

가져오기 요청 크기를 늘려 대기 시간 단축

fetch.max.bytes 및 max.partition.fetch.bytes 속성을 사용하여 Kafka 브로커에서 소비자가 가져온 최대 데이터 양을 늘립니다.

fetch.max.bytes 속성은 브로커에서 한 번에 가져온 데이터 양에 최대 제한을 바이트 단위로 설정합니다.

max.partition.fetch.bytes 는 각 파티션에 대해 반환되는 데이터의 양에 대한 최대 제한을 바이트 단위로 설정합니다. 이 제한은 항상 브로커에 설정된 바이트 수 또는 max.message.bytes 의 주제 구성보다 커야 합니다.

클라이언트가 사용할 수 있는 최대 메모리 양은 대략적으로 다음과 같이 계산됩니다. 

NUMBER-OF-BROKERS * fetch.max.bytes and NUMBER-OF-PARTITIONS * max.partition.fetch.bytes
Copy to Clipboard Toggle word wrap

메모리 사용량이 이를 수용할 수 있는 경우 이 두 속성의 값을 늘릴 수 있습니다. 각 요청에서 더 많은 데이터를 허용하면 가져오기 요청이 줄어들기 때문에 대기 시간이 향상됩니다. 

# ...
fetch.max.bytes=52428800
1 

max.partition.fetch.bytes=1048576
2 

# ...
Copy to Clipboard Toggle word wrap
1
가져오기 요청에 대해 반환되는 최대 데이터 양(바이트)입니다.
2
각 파티션에 대해 반환되는 최대 데이터 양(바이트)입니다.
6.1.3.5. 오프셋을 커밋할 때 데이터 손실 또는 중복 방지
링크 복사

Kafka 자동 커밋 메커니즘을 사용하면 소비자가 메시지의 오프셋을 자동으로 커밋할 수 있습니다. 활성화하면 소비자는 5000ms 간격으로 브로커 폴링에서 수신된 오프셋을 커밋합니다.

자동 커밋 메커니즘은 편리하지만 데이터 손실 및 복제 위험이 발생합니다. 소비자가 여러 메시지를 가져와서 변환했지만 자동 커밋을 수행할 때 시스템이 소비자 버퍼에서 처리된 메시지와 함께 충돌하면 해당 데이터가 손실됩니다. 메시지를 처리한 후 시스템이 충돌하지만 자동 커밋을 수행하기 전에 시스템의 재조정 후 다른 소비자 인스턴스에서 데이터가 복제됩니다.

자동 커밋은 브로커의 다음 폴링 전에 모든 메시지가 처리되거나 소비자가 닫히기 전에 모든 메시지가 처리되는 경우에만 데이터 손실을 방지할 수 있습니다.

데이터 손실 또는 복제 가능성을 최소화하기 위해 enable.auto.commit 를 false 로 설정하고 클라이언트 애플리케이션을 개발하여 오프셋을 더 많이 제어할 수 있습니다. 또는 auto.commit.interval.ms 를 사용하여 커밋 간 간격을 줄일 수 있습니다. 

# ...
enable.auto.commit=false
1 

# ...
Copy to Clipboard Toggle word wrap
1
커밋 오프셋을 더 많이 제어하려면 자동 커밋이 false로 설정됩니다.

enable.auto.commit 를 false 로 설정하면 모든 처리가 수행되고 메시지가 사용된 후 오프셋을 커밋할 수 있습니다. 예를 들어 Kafka commitSync 및 commitAsync 커밋 API를 호출하도록 애플리케이션을 설정할 수 있습니다.

commitSync API는 폴링에서 반환된 메시지 배치의 오프셋을 커밋합니다. 일괄 처리의 모든 메시지 처리를 완료하면 API를 호출합니다. commitSync API를 사용하는 경우 배치의 마지막 오프셋이 커밋될 때까지 애플리케이션은 새 메시지를 폴링하지 않습니다. 처리량에 부정적인 영향을 미치는 경우 더 자주 커밋하거나 commitAsync API를 사용할 수 있습니다. commitAsync API는 브로커가 커밋 요청에 응답할 때까지 기다리지 않지만 재조정 시 더 많은 중복을 생성할 위험이 있습니다. 일반적인 접근 방식은 애플리케이션에서 커밋 API를 모두 결합한 후 소비자를 종료하거나 재조정하기 전에 사용된 commitSync API를 결합하여 최종 커밋이 성공했는지 확인하는 것입니다.

6.1.3.5.1. 트랜잭션 메시지 제어
링크 복사

트랜잭션 ID를 사용하고 생산자 측에서 멱등(enable.idempotence=true)을 활성화하여 정확하게 제공되도록 하는 것이 좋습니다. 소비자 측에서 isolation.level 속성을 사용하여 소비자가 트랜잭션 메시지를 읽는 방법을 제어할 수 있습니다.

isolation.level 속성에는 다음 두 가지 유효한 값이 있습니다.

  • read_committed
  • read_uncommitted (기본값)

read_committed 를 사용하여 커밋된 트랜잭션 메시지만 소비자가 읽도록 합니다. 그러나 이로 인해 소비자가 브로커에서 트랜잭션 결과를 기록하는 트랜잭션 마커를 작성할 때까지 메시지를 반환할 수 없기 때문에 엔드 투 엔드 대기 시간이 증가합니다(커밋 또는 중단됨). 

# ...
enable.auto.commit=false
isolation.level=read_committed
1 

# ...
Copy to Clipboard Toggle word wrap
1
사용자가 커밋한 메시지만 읽도록 read_committed 로 설정합니다.
6.1.3.6. 데이터 손실을 방지하기 위해 실패에서 복구
링크 복사

session.timeout.ms 및 heartbeat.interval.ms 속성을 사용하여 소비자 그룹 내의 소비자 실패를 확인하고 복구하는 데 걸리는 시간을 구성합니다.

session.timeout.ms 속성은 소비자 그룹 내의 소비자가 비활성으로 간주되기 전에 브로커와 연결할 수 없는 최대 시간(밀리초)을 지정하고 그룹의 활성 소비자 간에 재조정 이 트리거됩니다. 그룹이 재조정되면 그룹이 그룹 멤버에 다시 할당됩니다.

heartbeat.interval.ms 속성은 소비자가 활성 상태이고 연결되어 있음을 나타내는 소비자 그룹 코디네이터와 하트비트 검사 사이의 간격(밀리초)을 지정합니다. 하트비트 간격은 세션 시간 제한 간격보다 일반적으로 3 일까지 작아야 합니다.

session.timeout.ms 속성을 더 낮게 설정하면 실패한 소비자가 이전에 감지되고 재조정이 더 빨라질 수 있습니다. 그러나 브로커가 제 시간에 하트비트를 수신하지 못하고 불필요한 재조정을 트리거하도록 시간 초과를 설정하지 않도록 주의하십시오.

하트비트 간격을 줄이면 우발적인 재조정 가능성이 줄어들지만 더 자주 하트비트는 브로커 리소스에 대한 오버헤드를 늘립니다.

6.1.3.7. 오프셋 정책 관리
링크 복사

auto.offset.reset 속성을 사용하여 오프셋이 커밋되지 않은 경우 소비자가 작동하는 방식을 제어하거나 커밋된 오프셋이 더 이상 유효하지 않거나 삭제되지 않습니다.

소비자 애플리케이션을 처음 배포하고 기존 주제에서 메시지를 읽습니다. group.id 가 처음 사용되므로 __consumer_offsets 항목에 이 애플리케이션에 대한 오프셋 정보가 포함되어 있지 않습니다. 새 애플리케이션은 로그 시작부터 모든 기존 메시지 처리를 시작하거나 새 메시지만 처리할 수 있습니다. 기본 재설정 값은 파티션 끝에 시작되는 latest 이므로 일부 메시지가 누락됨을 의미합니다. 데이터 손실을 피하되 처리 양을 늘리려면 auto.offset.reset 을 가장 빨리 설정하여 파티션 시작 부분에 시작합니다.

또한 브로커에 대해 구성된 오프셋 보존 기간(offsets.retention.minutes)이 종료될 때 메시지가 손실되지 않도록 가장 초기 옵션을 사용하는 것이 좋습니다. 소비자 그룹 또는 독립 실행형 소비자가 비활성 상태이고 보존 기간 동안 오프셋이 없는 경우 이전에 커밋된 오프셋은 __consumer_offsets 에서 삭제됩니다. 

# ...
heartbeat.interval.ms=3000
1 

session.timeout.ms=10000
2 

auto.offset.reset=earliest
3 

# ...
Copy to Clipboard Toggle word wrap
1
예상되는 리밸런스에 따라 하트비트 간격을 더 낮게 조정합니다.
2
시간 제한이 만료되기 전에 Kafka 브로커에서 하트비트를 수신하지 않으면 소비자가 소비자 그룹에서 제거되고 재조정이 시작됩니다. 브로커 구성에 group.min.session.timeout.ms 및 group.max.session.timeout.ms 가 있는 경우 세션 시간 초과 값은 해당 범위 내에 있어야 합니다.
3
파티션 시작으로 돌아가려면 가장 빨리 설정하고 오프셋이 커밋되지 않은 경우 데이터 손실을 방지합니다.

단일 가져오기 요청에서 반환된 데이터 양이 크면 소비자가 처리하기 전에 시간 초과가 발생할 수 있습니다. 이 경우 max.partition.fetch.bytes 를 낮추거나 session.timeout.ms 를 늘릴 수 있습니다.

6.1.3.8. 리밸런스의 영향을 최소화
링크 복사

그룹의 활성 소비자 간의 파티션 재조정은 다음 작업에 걸리는 시간입니다.

  • 사용자가 오프셋을 커밋
  • 구성할 새 소비자 그룹입니다.
  • 그룹 구성원에 파티션을 할당하는 그룹 리더
  • 그룹의 소비자가 할당을 수신하고 가져오기 시작합니다.

명확하게, 이 프로세스는 특히 소비자 그룹 클러스터를 롤링 재시작하는 동안 반복적으로 발생하는 경우 서비스의 다운타임을 늘립니다.

이 경우 정적 멤버십 개념을 사용하여 리밸런스 수를 줄일 수 있습니다. 재조정은 소비자 그룹 멤버 간에 주제 파티션을 균등하게 할당합니다. 정적 멤버십에서는 세션 시간 초과 후 다시 시작하는 동안 소비자 인스턴스를 인식할 수 있도록 지속성을 사용합니다.

소비자 그룹 코디네이터는 group.instance.id 속성을 사용하여 지정된 고유 ID를 사용하여 새 소비자 인스턴스를 식별할 수 있습니다. 다시 시작하는 동안 소비자에는 새 멤버 ID가 할당되지만 정적 멤버에서는 동일한 인스턴스 ID를 계속 사용하고 주제 파티션의 동일한 할당이 수행됩니다.

소비자 애플리케이션에서 적어도 모든 max.poll.interval.ms 밀리초를 폴링하도록 호출하지 않으면 소비자가 실패한 것으로 간주되어 재조정이 발생합니다. 애플리케이션에서 폴링에서 반환된 모든 레코드를 시간 단위로 처리할 수 없는 경우 max.poll.interval.ms 속성을 사용하여 리밸런스(rebalance)를 방지하여 소비자의 새 메시지에 대한 폴링 간격(밀리초)을 지정할 수 있습니다. 또는 max.poll.records 속성을 사용하여 소비자 버퍼에서 반환된 레코드 수에 대한 최대 제한을 설정하여 애플리케이션이 max.poll.interval.ms 제한 내에서 더 적은 레코드를 처리할 수 있습니다. 

# ...
group.instance.id=UNIQUE-ID
1 

max.poll.interval.ms=300000
2 

max.poll.records=500
3 

# ...
Copy to Clipboard Toggle word wrap
1
고유한 인스턴스 ID를 사용하면 새 소비자 인스턴스가 주제 파티션의 동일한 할당을 받을 수 있습니다.
2
소비자가 메시지를 계속 처리하고 있는지 확인하려면 간격을 설정합니다.
3
소비자에서 반환된 처리된 레코드 수를 설정합니다.

6.2. Kafka 정적 할당량 플러그인을 사용하여 브로커에 제한 설정
링크 복사

중요

Kafka 정적 할당량 플러그인은 기술 프리뷰 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. Red Hat은 프로덕션 환경에서 기술 프리뷰 기능을 구현하는 것을 권장하지 않습니다. 이 기술 프리뷰 기능을 통해 향후 제품 혁신에 조기에 액세스할 수 있으므로 개발 프로세스 중에 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

Kafka 정적 할당량 플러그인을 사용하여 Kafka 클러스터의 브로커에 처리량 및 스토리지 제한을 설정합니다. Kafka 구성 파일에 속성을 추가하여 플러그인을 활성화하고 제한을 설정합니다. 브로커와 상호 작용하는 클라이언트에 제한을 두도록 바이트 비율 임계값 및 스토리지 할당량을 설정할 수 있습니다.

생산자 및 소비자 대역폭에 대한 바이트 비율 임계값을 설정할 수 있습니다. 총 제한은 브로커에 액세스하는 모든 클라이언트에 분산됩니다. 예를 들어 생산자를 위해 바이트 비율 임계값을 40MBps로 설정할 수 있습니다. 두 생산자가 실행 중인 경우 각각 처리량이 20MB로 제한됩니다.

스토리지 할당량은 소프트 제한과 하드 제한 간에 Kafka 디스크 스토리지 제한을 제한합니다. 제한은 사용 가능한 모든 디스크 공간에 적용됩니다. 생산자는 소프트 제한과 하드 제한 사이에 점진적으로 느려집니다. 제한을 통해 디스크가 너무 빨리 채워지고 용량을 초과할 수 있습니다. 전체 디스크로 인해 수정하기 어려운 문제가 발생할 수 있습니다. 하드 제한은 최대 스토리지 제한입니다.

참고

JBOD 스토리지의 경우 제한이 모든 디스크에 적용됩니다. 브로커가 두 개의 1TB 디스크를 사용하고 할당량이 1.1TB인 경우 하나의 디스크가 채워지고 다른 디스크는 거의 비어 있습니다.

사전 요구 사항

프로세스

  1. /opt/kafka/config/server.properties Kafka 구성 파일을 편집합니다.

    플러그인 속성은 이 예제 구성에 표시됩니다.

    Kafka 고정 할당량 플러그인 구성의 예

    # ...
client.quota.callback.class=io.strimzi.kafka.quotas.StaticQuotaCallback
    1 
    
client.quota.callback.static.produce=1000000
    2 
    
client.quota.callback.static.fetch=1000000
    3 
    
client.quota.callback.static.storage.soft=400000000000
    4 
    
client.quota.callback.static.storage.hard=500000000000
    5 
    
client.quota.callback.static.storage.check-interval=5
    6 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    Kafka 정적 할당량 플러그인을 로드합니다.
    2
    생산자 바이트 비율 임계값을 설정합니다. 이 예에서는 1Mbps입니다.
    3
    consumer byte-rate threshold를 설정합니다. 이 예에서는 1Mbps입니다.
    4
    스토리지에 대한 더 낮은 소프트 제한을 설정합니다. 이 예에서는 400GB입니다.
    5
    스토리지에 대해 더 높은 하드 제한을 설정합니다. 이 예에서는 500GB입니다.
    6
    스토리지의 점검 간격(초)을 설정합니다. 이 예에서는 5초입니다. 검사를 비활성화하려면 이 값을 0으로 설정할 수 있습니다.

  2. 기본 구성 파일을 사용하여 Kafka 브로커를 시작합니다. 

    su - kafka
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

  3. Kafka 브로커가 실행 중인지 확인합니다. 

    jcmd | grep Kafka
    Copy to Clipboard Toggle word wrap

6.3. 클러스터 스케일링
링크 복사

6.3.1. Kafka 클러스터 스케일링
링크 복사

6.3.1.1. 클러스터에 브로커 추가
링크 복사

주제의 처리량을 늘리는 기본 방법은 해당 항목의 파티션 수를 늘리는 것입니다. 파티션이 해당 주제의 로드를 클러스터의 브로커 간에 공유할 수 있기 때문에 작동합니다. 브로커를 일부 리소스(일반적으로 I/O)로 제한하면 더 많은 파티션을 사용하면 처리량이 증가되지 않습니다. 대신 클러스터에 브로커를 추가해야 합니다.

클러스터에 브로커를 추가하면 AMQ Streams에서 자동으로 파티션을 할당하지 않습니다. 기존 브로커에서 새 브로커로 이동할 파티션을 결정해야 합니다.

모든 브로커 간에 파티션을 재배포하면 각 브로커는 리소스 사용률이 작아야 합니다.

6.3.1.2. 클러스터에서 브로커 제거
링크 복사

클러스터에서 브로커를 제거하기 전에 파티션이 할당되지 않았는지 확인해야 합니다. 브로커의 각 파티션에 대해 어떤 남아 있는 브로커가 해제되는지 결정해야합니다. 브로커에 파티션이 할당되지 않으면 이를 중지할 수 있습니다.

6.3.2. 파티션 재할당
링크 복사

kafka-reassign-partitions.sh 유틸리티는 파티션을 다른 브로커에 다시 할당하는 데 사용됩니다.

여기에는 세 가지 모드가 있습니다.

--generate
주제 및 브로커 세트를 가져와서 재할당 JSON 파일을 생성하여 해당 브로커에 해당 주제의 파티션이 할당됩니다. JSON 파일을 다시 할당 하는 쉬운 방법이지만 전체 주제에서 작동하므로 사용이 항상 적합한 것은 아닙니다.
--execute
JSON 파일을 다시 할당 하여 클러스터의 파티션 및 브로커에 적용합니다. 파티션을 얻는 브로커는 파티션 리더의 팔로우가 될 것입니다. 지정된 파티션의 경우 새 브로커가 ISR에 가입하고 가입하면 이전 브로커가 팔로워가 되는 것을 중지하고 복제본을 삭제합니다.
--verify
--execute 단계와 동일한 재할당 JSON 파일을 사용하여 --verify 는 파일의 모든 파티션이 의도한 브로커로 이동되었는지 확인합니다. 재할당이 완료되면 적용되는 모든 제한도 제거됩니다. 제거되지 않으면 제한은 재할당이 완료된 후에도 클러스터에 계속 영향을 미칩니다.

지정된 시간에 클러스터에서 하나의 재할당을 실행할 수 있으며 실행 중인 재할당을 취소할 수 없습니다. 재할당을 취소해야 하는 경우 재할당이 완료될 때까지 기다린 다음 다른 재할당을 수행하여 첫 번째 효과를 되돌려야 합니다. kafka-reassign-partitions.sh 는 이 재버전에 대한 재할당 JSON을 출력 출력의 일부로 출력합니다. 매우 큰 재할당은 진행 중인 재할당을 중지해야 하는 경우 다수의 작은 재할당으로 분류되어야 합니다.

6.3.2.1. JSON 파일 다시 할당
링크 복사

JSON 파일의 재할당 에는 특정 구조가 있습니다. 

{
  "version": 1,
  "partitions": [
    <PartitionObjects>
  ]
}
Copy to Clipboard Toggle word wrap

여기서 & lt; CryostatObjects >는 다음과 같이 쉼표로 구분된 오브젝트 목록입니다. 

{
  "topic": <TopicName>,
  "partition": <Partition>,
  "replicas": [ <AssignedBrokerIds> ],
  "log_dirs": [<LogDirs>]
}
Copy to Clipboard Toggle word wrap

"log_dirs" 속성은 선택 사항이며 파티션을 특정 로그 디렉터리로 이동하는 데 사용됩니다.

다음은 주제 주제( a, 파티션 4 를 브로커 2 ,4 및 7 에 할당) 및 주제 주제-b 파티션 2 를 브로커 1,5 및 7 에 할당하는 예제 JSON 파일입니다. 

{
  "version": 1,
  "partitions": [
    {
      "topic": "topic-a",
      "partition": 4,
      "replicas": [2,4,7]
    },
    {
      "topic": "topic-b",
      "partition": 2,
      "replicas": [1,5,7]
    }
  ]
}
Copy to Clipboard Toggle word wrap

JSON에 포함되지 않은 파티션은 변경되지 않습니다.

6.3.2.2. JSON 파일 다시 할당 생성
링크 복사

지정된 주제 집합에 대한 모든 파티션을 지정된 브로커 집합에 할당하는 가장 쉬운 방법은 kafka-reassign-partitions.sh --generate, 명령을 사용하여 JSON 파일을 다시 할당하는 것입니다. 

bin/kafka-reassign-partitions.sh --zookeeper <ZooKeeper> --topics-to-move-json-file <TopicsFile> --broker-list <BrokerList> --generate
Copy to Clipboard Toggle word wrap

& lt;TopicsFile >은 이동할 주제를 나열하는 JSON 파일입니다. 다음과 같은 구조가 있습니다. 

{
  "version": 1,
  "topics": [
    <TopicObjects>
  ]
}
Copy to Clipboard Toggle word wrap

여기서 <TopicObjects >는 다음과 같이 쉼표로 구분된 오브젝트 목록입니다. 

{
  "topic": <TopicName>
}
Copy to Clipboard Toggle word wrap

예를 들어, topic-a 및 topic-b 의 모든 파티션을 브로커 4 및 7로 이동하려면 

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-be-moved.json --broker-list 4,7 --generate
Copy to Clipboard Toggle word wrap

topic-to-be-moved.json 의 내용은 다음과 같습니다. 

{
  "version": 1,
  "topics": [
    { "topic": "topic-a"},
    { "topic": "topic-b"}
  ]
}
Copy to Clipboard Toggle word wrap
6.3.2.3. 수동으로 JSON 파일 재할당 생성
링크 복사

특정 파티션을 이동하려는 경우 재할당 JSON 파일을 수동으로 생성할 수 있습니다.

6.3.3. Reassignment throttles
링크 복사

파티션 재할당은 브로커 간에 많은 데이터를 이동해야 할 수 있으므로 속도가 느린 프로세스일 수 있습니다. 이로 인해 클라이언트에 부정적인 영향을 미치지 않도록 하려면 재할당을 중단할 수 있습니다. 스로틀을 사용하면 재할당 시간이 더 오래 걸릴 수 있습니다. 스로틀이 너무 낮으면 새로 할당된 브로커는 게시되는 레코드를 유지할 수 없으며 재할당이 완료되지 않습니다. 스로틀이 너무 높으면 고객에게 영향을 미칩니다. 예를 들어 프로듀서의 경우 이는 승인을 기다리는 일반 대기 시간보다 높을 수 있습니다. 소비자의 경우 폴링 간에 대기 시간이 길기 때문에 처리량이 저하될 수 있습니다.

6.3.4. Kafka 클러스터 확장
링크 복사

다음 절차에서는 Kafka 클러스터의 브로커 수를 늘리는 방법을 설명합니다.

사전 요구 사항

  • 기존 Kafka 클러스터입니다.
  • AMQ 브로커가 설치된 새 머신입니다.
  • 확대된 클러스터의 브로커에 파티션을 다시 할당하는 방법에 대한 JSON 파일을 다시 할당합니다.

프로세스

  1. 다른 브로커에서 아직 사용하지 않는 숫자여야 하는 broker.id 를 제외하고 클러스터의 다른 브로커와 동일한 설정을 사용하여 새 브로커에 대한 구성 파일을 생성합니다.

  2. 이전 단계에서 생성한 구성 파일을 인수로 kafka-server-start.sh 스크립트에 전달하는 새 Kafka 브로커를 시작합니다. 

    su - kafka
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

  3. Kafka 브로커가 실행 중인지 확인합니다. 

    jcmd | grep Kafka
    Copy to Clipboard Toggle word wrap
  4. 각 새 브로커에 대해 위의 단계를 반복합니다.

  5. kafka-reassign-partitions.sh 명령줄 도구를 사용하여 파티션 재할당을 실행합니다. 

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --execute
    Copy to Clipboard Toggle word wrap

    복제를 제한하려면 브로어링된 속도가 초당 바이트 단위로 --throttle 옵션을 전달할 수도 있습니다. 예를 들면 다음과 같습니다. 

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 5000000 --execute
    Copy to Clipboard Toggle word wrap

    이 명령은 두 개의 재할당 JSON 오브젝트를 출력합니다. 첫 번째는 이동 중인 파티션에 대한 현재 할당을 기록합니다. 나중에 다시 할당해야 하는 경우 이 값을 파일에 저장해야 합니다. 두 번째 JSON 오브젝트는 재할당 JSON 파일에 전달된 대상 재할당입니다.

  6. 재할당하는 동안 throttle을 변경해야하는 경우 다른 제한 속도로 동일한 명령줄을 사용할 수 있습니다. 예를 들면 다음과 같습니다. 

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 10000000 --execute
    Copy to Clipboard Toggle word wrap

  7. kafka-reassign-partitions.sh 명령줄 도구를 사용하여 재할당이 완료되었는지 주기적으로 확인합니다. 이 명령은 이전 단계와 동일하지만 --execute 옵션 대신 --verify 옵션을 사용합니다. 

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --verify
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --verify
    Copy to Clipboard Toggle word wrap
  8. --verify 명령이 이동 중인 각 파티션을 완료된 것으로 보고하면 재할당이 완료되었습니다. 이 마지막 --verify 는 또한 reassignment throttles를 제거하는 효과가 있습니다. 원래 브로커로 할당을 되돌리기 위해 JSON을 저장한 경우 revert 파일을 삭제할 수 있습니다.

6.3.5. Kafka 클러스터 축소
링크 복사

추가 리소스

다음 절차에서는 Kafka 클러스터의 브로커 수를 줄이는 방법을 설명합니다.

사전 요구 사항

  • 기존 Kafka 클러스터입니다.
  • 브로커가 제거되면 파티션의 브로커를 다시 할당하는 방법에 대한 JSON 파일을 클러스터의 브로커에 다시 할당합니다.

프로세스

  1. kafka-reassign-partitions.sh 명령줄 도구를 사용하여 파티션 재할당을 실행합니다. 

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --execute
    Copy to Clipboard Toggle word wrap

    복제를 제한하려면 브로어링된 속도가 초당 바이트 단위로 --throttle 옵션을 전달할 수도 있습니다. 예를 들면 다음과 같습니다. 

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 5000000 --execute
    Copy to Clipboard Toggle word wrap

    이 명령은 두 개의 재할당 JSON 오브젝트를 출력합니다. 첫 번째는 이동 중인 파티션에 대한 현재 할당을 기록합니다. 나중에 다시 할당해야 하는 경우 이 값을 파일에 저장해야 합니다. 두 번째 JSON 오브젝트는 재할당 JSON 파일에 전달된 대상 재할당입니다.

  2. 재할당하는 동안 throttle을 변경해야하는 경우 다른 제한 속도로 동일한 명령줄을 사용할 수 있습니다. 예를 들면 다음과 같습니다. 

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --throttle 10000000 --execute
    Copy to Clipboard Toggle word wrap

  3. kafka-reassign-partitions.sh 명령줄 도구를 사용하여 재할당이 완료되었는지 주기적으로 확인합니다. 이 명령은 이전 단계와 동일하지만 --execute 옵션 대신 --verify 옵션을 사용합니다. 

    kafka-reassign-partitions.sh --zookeeper <ZooKeeperHostAndPort> --reassignment-json-file <ReassignmentJsonFile> --verify
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    kafka-reassign-partitions.sh --zookeeper zookeeper1:2181 --reassignment-json-file reassignment.json --verify
    Copy to Clipboard Toggle word wrap
  4. --verify 명령이 이동 중인 각 파티션을 완료된 것으로 보고하면 재할당이 완료되었습니다. 이 마지막 --verify 는 또한 reassignment throttles를 제거하는 효과가 있습니다. 원래 브로커로 할당을 되돌리기 위해 JSON을 저장한 경우 revert 파일을 삭제할 수 있습니다.

  5. 모든 파티션 재할당이 완료되면 제거되는 브로커는 클러스터의 파티션에 대한 책임이 없어야 합니다. 브로커의 log.dirs 구성 매개변수에 지정된 각 디렉터리를 확인하여 이를 확인할 수 있습니다. 브로커의 로그 디렉터리에 확장 정규식 \.[a-z0-9]-delete$ 와 일치하지 않는 디렉터리가 포함되어 있는 경우 브로커에는 여전히 라이브 파티션이 있으며 중지되지 않아야 합니다.

    다음 명령을 실행하여 확인할 수 있습니다. 

    ls -l <LogDir> | grep -E '^d' | grep -vE '[a-zA-Z0-9.-]+\.[a-z0-9]+-delete$'
    Copy to Clipboard Toggle word wrap

    위의 명령이 출력을 출력하는 경우 브로커에는 여전히 라이브 파티션이 있습니다. 이 경우 재할당이 완료되지 않았거나 재할당 JSON 파일이 올바르지 않았습니다.

  6. 브로커에 라이브 파티션이 없음을 확인한 후에는 중지할 수 있습니다. 

    su - kafka
/opt/kafka/bin/kafka-server-stop.sh
    Copy to Clipboard Toggle word wrap

  7. Kafka 브로커가 중지되었는지 확인합니다. 

    jcmd | grep kafka
    Copy to Clipboard Toggle word wrap

6.3.6. Zoo Cryostat 클러스터 확장
링크 복사

다음 절차에서는 Zoo Cryostat 클러스터에 서버(노드)를 추가하는 방법을 설명합니다. Zoo Cryostat의 동적 재구성 기능은 확장 프로세스 중에 안정적인 Zoo Cryostat 클러스터를 유지합니다.

사전 요구 사항

  • 동적 재구성은 Zoo Cryostat 구성 파일(reconfigEnabled=true)에서 활성화됩니다.
  • Zookeeper 인증이 활성화되고 인증 메커니즘을 사용하여 새 서버에 액세스할 수 있습니다.

프로세스

한 번에 하나씩 각 Zoo Cryostat 서버에 대해 다음 단계를 수행합니다.

  1. 3.3절. “다중 노드 Zoo Cryostat 클러스터 실행” 에 설명된 대로 Zoo Cryostat 클러스터에 서버를 추가한 다음 Zoo Cryostat를 시작합니다.
  2. 새 서버의 IP 주소 및 구성된 액세스 포트를 확인합니다.

  3. 서버에 대한 Zookeeper-shell 세션을 시작합니다. 클러스터에 액세스할 수 있는 머신에서 다음 명령을 실행합니다(액세스 권한이 있는 경우 Zoo Cryostat 노드 또는 로컬 시스템 중 하나일 수 있습니다). 

    su - kafka
/opt/kafka/bin/zookeeper-shell.sh <ip-address>:<zk-port>
    Copy to Clipboard Toggle word wrap

  4. 쉘 세션에서 Zoo Cryostat 노드가 실행 중인 상태에서 다음 행을 입력하여 새 서버를 쿼럼에 투표 멤버로 추가합니다. 

    reconfig -add server.<positive-id> = <address1>:<port1>:<port2>[:role];[<client-port-address>:]<client-port>
    Copy to Clipboard Toggle word wrap

    예를 들면 다음과 같습니다. 

    reconfig -add server.4=172.17.0.4:2888:3888:participant;172.17.0.4:2181
    Copy to Clipboard Toggle word wrap

    여기서 & lt;positive-id& gt;는 새로운 서버 ID 4 입니다.

    두 포트의 경우 < port1 > 2888 은 Zoo Cryostat 서버 간 통신용이며 < port2 > 3888 은 리더 선택을 위한 것입니다.

    새 구성은 Zoo Cryostat 클러스터의 다른 서버로 전파됩니다. 새 서버는 이제 쿼럼의 전체 멤버입니다.

  5. 추가하려는 다른 서버에 대해 1-4단계를 반복합니다.

추가 리소스

6.3.7. Zoo Cryostat 클러스터 축소
링크 복사

다음 절차에서는 Zoo Cryostat 클러스터에서 서버(노드)를 제거하는 방법을 설명합니다. Zoo Cryostat의 동적 재구성 기능은 축소 프로세스 중에 안정적인 Zoo Cryostat 클러스터를 유지합니다.

사전 요구 사항

  • 동적 재구성은 Zoo Cryostat 구성 파일(reconfigEnabled=true)에서 활성화됩니다.
  • Zookeeper 인증이 활성화되고 인증 메커니즘을 사용하여 새 서버에 액세스할 수 있습니다.

프로세스

한 번에 하나씩 각 Zoo Cryostat 서버에 대해 다음 단계를 수행합니다.

  1. 축소 후 유지됩니다 (예: 서버 1).

    참고

    Zoo Cryostat 클러스터에 대해 구성된 인증 메커니즘을 사용하여 서버에 액세스합니다.

  2. 서버 5와 같이 서버를 제거합니다. 

    reconfig -remove 5
    Copy to Clipboard Toggle word wrap
  3. 삭제한 서버를 비활성화합니다.
  4. 클러스터 크기를 줄이기 위해 1~3단계를 반복합니다.

추가 리소스

7장. Cryostat를 사용하여 클러스터 모니터링
링크 복사

Zookeeper, Kafka 브로커, Kafka Connect 및 Kafka 클라이언트는 모두 JMX( Java Management Extensions )를 사용하여 관리 정보를 노출합니다. 대부분의 관리 정보는 Kafka 클러스터의 상태 및 성능을 모니터링하는 데 유용한 메트릭의 형태로 제공됩니다. 다른 Java 애플리케이션과 마찬가지로 Kafka는 관리되는 빈 또는 Cryostat를 통해 이 관리 정보를 제공합니다.

Cryostat는 JVM(Java Virtual Machine) 수준에서 작동합니다. 관리 정보를 얻으려면 외부 도구가 Zoo Cryostat, Kafka 브로커 등을 실행하는 JVM에 연결할 수 있습니다. 기본적으로 동일한 시스템의 툴만 JVM과 동일한 사용자로 실행할 수 있습니다.

참고

Zoo Cryostat의 관리 정보는 여기에 문서화되어 있지 않습니다. JConsole에서 Zoo Cryostat 메트릭을 볼 수 있습니다. 자세한 내용은 JConsole을 사용한 모니터링 을 참조하십시오.

7.1. Cryostat 구성 옵션
링크 복사

JVM 시스템 속성을 사용하여 Cryostat를 구성합니다. AMQ Streams(bin/kafka-server-start.sh 및 bin/connect-distributed.sh 등)와 함께 제공되는 스크립트는 KAFKA_JMX_OPTS 환경 변수를 사용하여 이러한 시스템 속성을 설정합니다. Kafka 생산자, 소비자 및 스트림 애플리케이션이 일반적으로 JVM을 다른 방식으로 시작하는 경우에도 Cryostat 구성을 위한 시스템 속성은 동일합니다.

7.2. Cryostat 에이전트 비활성화
링크 복사

AMQ Streams 구성 요소에 대해 Cryostat 에이전트를 비활성화하여 로컬 Cryostat 툴이 JVM(예: 규정 준수 이유로)에 연결하지 못하도록 할 수 있습니다. 다음 절차에서는 Kafka 브로커에 대해 Cryostat 에이전트를 비활성화하는 방법을 설명합니다.

프로세스

  1. KAFKA_JMX_OPTS 환경 변수를 사용하여 com.sun.management.jmxremote 를 false 로 설정합니다. 

    export KAFKA_JMX_OPTS=-Dcom.sun.management.jmxremote=false
bin/kafka-server-start.sh
    Copy to Clipboard Toggle word wrap
  2. JVM을 시작합니다.

7.3. 다른 머신에서 JVM에 연결
링크 복사

Cryostat 에이전트가 수신 대기하는 포트를 구성하여 다른 머신의 JVM에 연결할 수 있습니다. 이는 Cryostat 툴이 인증 없이 어디에서나 연결할 수 있기 때문에 안전하지 않습니다.

프로세스

  1. KAFKA_JMX_OPTS 환경 변수를 사용하여 -Dcom.sun.management.jmxremote.port= <port >를 설정합니다. & lt;port > 의 경우 Kafka 브로커에서 Cryostat 연결을 수신 대기할 포트 이름을 입력합니다. 

    export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote=true
  -Dcom.sun.management.jmxremote.port=<port>
  -Dcom.sun.management.jmxremote.authenticate=false
  -Dcom.sun.management.jmxremote.ssl=false"
bin/kafka-server-start.sh
    Copy to Clipboard Toggle word wrap
  2. JVM을 시작합니다.
중요

원격 Cryostat 연결이 안전한지 확인하도록 인증 및 SSL을 구성하는 것이 좋습니다. 이 작업을 수행하는 데 필요한 시스템 속성에 대한 자세한 내용은 Cryostat 설명서를 참조하십시오.

7.4. JConsole을 사용한 모니터링
링크 복사

JConsole 툴은 JDK(Java Development Kit)와 함께 배포됩니다. JConsole을 사용하여 로컬 또는 원격 JVM에 연결하고 Java 애플리케이션에서 관리 정보를 검색하고 표시할 수 있습니다. JConsole을 사용하여 로컬 JVM에 연결하는 경우 AMQ Streams의 다른 구성 요소에 해당하는 JVM 프로세스의 이름입니다.

Expand
표 7.1. AMQ Streams 구성 요소를 위한 JVM 프로세스
AMQ Streams 구성 요소JVM 프로세스

ZooKeeper

org.apache.zookeeper.server.quorum.QuorumPeerMain

Kafka 브로커

kafka.Kafka

Kafka Connect 독립 실행형

org.apache.kafka.connect.cli.ConnectStandalone

Kafka Connect 배포

org.apache.kafka.connect.cli.ConnectDistributed

Kafka 생산자, 소비자 또는 Streams 애플리케이션

애플리케이션의 main 메서드가 포함된 클래스의 이름입니다.

JConsole을 사용하여 원격 JVM에 연결하는 경우 적절한 호스트 이름과 Cryostat 포트를 사용합니다.

다른 많은 툴 및 모니터링 제품을 사용하여 Cryostat를 사용하여 메트릭을 가져오고 해당 메트릭을 기반으로 모니터링 및 경고를 제공할 수 있습니다. 해당 툴에 대한 제품 설명서를 참조하십시오.

7.5. 중요한 Kafka 브로커 메트릭
링크 복사

Kafka는 Kafka 클러스터에서 브로커의 성능을 모니터링하기 위해 많은 Cryostat를 제공합니다. 이는 전체 클러스터가 아닌 개별 브로커에 적용됩니다.

다음 표에는 서버, 네트워크, 로깅 및 컨트롤러 메트릭으로 구성된 브로커 수준 Cryostat가 있습니다.

7.5.1. Kafka 서버 메트릭
링크 복사

다음 표는 Kafka 서버에 대한 정보를 보고하는 메트릭을 보여줍니다.

Expand
표 7.2. Kafka 서버의 메트릭
지표Cryostat설명예상 값

초당 메시지

kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec

브로커가 개별 메시지를 사용하는 비율입니다.

클러스터의 다른 브로커와 거의 동일합니다.

초당 바이트 수

kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec

생산자로부터 전송되는 데이터는 브로커가 사용하는 비율입니다.

클러스터의 다른 브로커와 거의 동일합니다.

초당의 복제 바이트 수

kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesInPerSec

다른 브로커에서 전송되는 데이터는 후속 브로커가 사용합니다.

해당 없음

초당 바이트 아웃

kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec

소비자가 데이터를 가져와서 브로커에서 읽습니다.

해당 없음

초당 복제 바이트 수

kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesOutPerSec

데이터가 브로커에서 다른 브로커로 전송되는 속도입니다. 이 메트릭은 브로커가 파티션 그룹의 리더인지 모니터링하는 데 유용합니다.

해당 없음

복제되지 않은 파티션

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

후속 복제본에서 완전히 복제되지 않은 파티션 수입니다.

Zero

최소 ISR 파티션 수

kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount

최소 IISR(In-Sync Replica) 수 아래의 파티션 수입니다. ISR 수는 리더와 최신 상태인 복제본 세트를 나타냅니다.

Zero

파티션 수

kafka.server:type=ReplicaManager,name=PartitionCount

브로커의 파티션 수입니다.

대략 다른 브로커와 비교했을 때도 마찬가지입니다.

리더 수

kafka.server:type=ReplicaManager,name=LeaderCount

이 브로커가 리더인 복제본 수입니다.

클러스터의 다른 브로커와 거의 동일합니다.

ISR 감소/초당 감소

kafka.server:type=ReplicaManager,name=IsrShrinksPerSec

브로커의 ISR 수가 감소하는 비율

Zero

ISR은 초당 확장

kafka.server:type=ReplicaManager,name=IsrExpandsPerSec

브로커의 ISR 수가 증가하는 비율입니다.

Zero

최대 지연

kafka.server:type=ReplicaFetcherManager,name=MaxLag,clientId=Replica

리더 복제본과 후속 복제본에서 메시지를 수신하는 시간 사이의 최대 지연입니다.

생성 요청의 최대 배치 크기에 비례합니다.

프로듀서의 요구 사항

kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=Produce

생산자 순례자의 전송 요청 수입니다.

해당 없음

가져오기 대상 요청

kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=Fetch

가져오기 프로세스의 가져오기 요청 수입니다.

해당 없음

요청 처리기 평균 유휴 백분율

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent

요청 처리기(IO) 스레드가 사용되지 않는 시간의 백분율을 나타냅니다.

더 낮은 값은 브로커의 워크로드가 높음을 나타냅니다.

요청 (제한에서의 요청 제외)

kafka.server:type=Request

제한에서 제외되는 요청 수입니다.

해당 없음

Zookeeper 요청 대기 시간(밀리초)

kafka.server:type=ZooKeeperClientMetrics,name=ZooKeeperRequestLatencyMs

브로커의 Zoo Cryostat 요청 대기 시간(밀리초)입니다.

해당 없음

Zookeeper 세션 상태

kafka.server:type=SessionExpireListener,name=SessionState

Zoo Cryostat에 대한 브로커 연결 상태

연결됨

7.5.2. Kafka 네트워크 메트릭
링크 복사

다음 표에서는 요청에 대한 정보를 보고하는 메트릭을 보여줍니다.

Expand
지표Cryostat설명예상 값

초당 요청 수

Kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower}

초당 요청 유형에 대한 총 요청 수입니다. Produce,FetchConsumer 및 FetchFollower 요청 유형에는 각각 고유한 Cryostat가 있습니다.

해당 없음

요청 바이트(바이트 단위)

kafka.network:type=RequestMetrics,name=RequestBytes,request=([-.\w]+)

요청 크기(바이트)는 요청 속성으로 식별되는 요청 유형(바이트)입니다. 사용 가능한 모든 요청 유형에 대한 별도의 Cryostat는 RequestBytes 노드에 나열됩니다.

해당 없음

임시 메모리 크기(바이트)

kafka.network:type=RequestMetrics,name=TemporaryMemoryBytes,request={Produce|Fetch}

메시지 형식을 변환하고 메시지 압축 해제에 사용되는 임시 메모리 양입니다.

해당 없음

메시지 변환 시간

kafka.network:type=RequestMetrics,name=MessageConversionsTimeMs,request={Produce|Fetch}

시간(밀리초)은 메시지 형식을 변환하는 데 소비됩니다.

해당 없음

총 요청 시간(밀리초)

Kafka.network:type=RequestMetrics,name=TotalTimeMs,request={Produce|FetchConsumer|FetchFollower}

총 시간(밀리초)입니다.

해당 없음

요청 큐 시간(밀리초)

Kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request={Produce|FetchConsumer|FetchFollower}

요청이 현재 요청 속성에 지정된 요청 유형에 대해 큐에서 소비하는 시간(밀리초)입니다.

해당 없음

현지 시간(현지 처리 시간)(밀리초)

Kafka.network:type=RequestMetrics,name=LocalTimeMs,request={Produce|FetchConsumer|FetchFollower}

리더가 요청을 처리하는 데 걸리는 시간(밀리초)입니다.

해당 없음

원격 시간(리더 원격 처리 시간)(밀리초)

Kafka.network:type=RequestMetrics,name=RemoteTimeMs,request={Produce|FetchConsumer|FetchFollower}

요청이 팔로워할 때까지 대기하는 시간(밀리초)입니다. 사용 가능한 모든 요청 유형에 대한 별도의 Cryostat는 RemoteTimeMs 노드에 나열됩니다.

해당 없음

응답 대기열 시간(밀리초)

Kafka.network:type=RequestMetrics,name=ResponseQueueTimeMs,request={Produce|FetchConsumer|FetchFollower}

요청이 응답 큐에서 대기하는 시간(밀리초)입니다.

해당 없음

응답 전송 시간(밀리초)

Kafka.network:type=RequestMetrics,name=ResponseSendTimeMs,request={Produce|FetchConsumer|FetchFollower}

응답을 보내는 데 걸리는 시간(밀리초)입니다.

해당 없음

네트워크 프로세서 평균 유휴 백분율

kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

네트워크 프로세서가 유휴 상태인 평균 백분율입니다.

0에서 1 사이입니다.

7.5.3. Kafka 로그 메트릭
링크 복사

다음 표에서는 로깅에 대한 정보를 보고하는 다양한 메트릭을 보여줍니다.

Expand
지표Cryostat설명예상 값

로그 플러시 비율 및 시간(밀리초)

kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs

로그 데이터가 디스크에 기록되는 속도(밀리초)입니다.

해당 없음

오프라인 로그 디렉터리 수

kafka.log:type=LogManager,name=OfflineLogDirectoryCount

오프라인 로그 디렉터리 수(예: 하드웨어 실패 후)입니다.

Zero

7.5.4. Kafka 컨트롤러 메트릭
링크 복사

다음 표는 클러스터 컨트롤러에 대한 정보를 보고하는 메트릭을 보여줍니다.

Expand
지표Cryostat설명예상 값

활성 컨트롤러 수

kafka.controller:type=KafkaController,name=ActiveControllerCount

컨트롤러로 지정된 브로커 수입니다.

하나는 브로커가 클러스터의 컨트롤러임을 나타냅니다.

리더 선택 비율 및 시간(밀리초)

kafka.controller:type=ControllerStats,name=LeaderElectionRateAndTimeMs

새 리더 복제본이 선택된 비율입니다.

Zero

7.5.5. Cryostat 메트릭
링크 복사

속도 또는 시간 단위를 나타내는 메트릭은 Cryostat 메트릭으로 제공됩니다. Cryostat 메트릭을 사용하는 class 이름 앞에 com.yammer.metrics 가 붙습니다.

Cryostat 속도 메트릭에는 모니터링 요청에 대한 다음과 같은 속성이 있습니다.

  • 수량
  • eventType(Bytes)
  • FifteenMinuteRate
  • RateUnit (Seconds)
  • MeanRate
  • OneMinuteRate
  • FiveMinuteRate

Cryostat 시간 메트릭에는 모니터링 요청에 대한 다음 속성이 있습니다.

  • Max
  • 분
  • mean
  • StdDev
  • 75/95/98/99/99.9 thcentile

7.6. 생산자 Cryostats
링크 복사

다음 Cryostat는 Kafka Streams 애플리케이션 및 소스 커넥터와 Kafka Connect를 포함한 Kafka 생산자 애플리케이션에 존재합니다.

7.6.1. Cryostat와 일치하는 kafka.producer:type=producer-metrics,client-id=*
링크 복사

이는 생산자 수준의 지표입니다.

Expand
속성설명

batch-size-avg

요청당 파티션당 전송되는 평균 바이트 수입니다.

batch-size-max

요청당 파티션당 전송되는 최대 바이트 수입니다.

batch-split-rate

초당 평균 배치 분할 수입니다.

batch-split-total

총 배치 분할 수입니다.

buffer-available-bytes

사용되지 않는 총 버퍼 메모리 양(할당되지 않았거나 사용 가능한 목록)입니다.

buffer-total-bytes

클라이언트에서 사용할 수 있는 최대 버퍼 메모리 양(현재 사용 여부 또는 사용 여부)입니다.

bufferpool-wait-time

appender가 공간 할당을 기다리는 시간의 분수입니다.

compression-rate-avg

압축되지 않은 크기의 압축된 배치 크기의 평균 비율로 정의된 레코드 배치의 평균 압축률입니다.

connection-close-rate

창에서 초당 연결이 닫힙니다.

connection-count

현재 활성 연결 수입니다.

connection-creation-rate

창에서 초당 설정된 새 연결입니다.

failed-authentication-rate

인증에 실패한 연결입니다.

incoming-byte-rate

모든 소켓에서 바이트/초를 읽습니다.

io-ratio

I/O 스레드가 I/O를 수행하는 데 소요된 시간의 분수입니다.

io-time-ns-avg

선택 항목당 I/O 평균 시간( 나노초)입니다.

io-wait-ratio

I/O 스레드가 기다리는 데 걸린 시간 중 일부입니다.

io-wait-time-ns-avg

I/O 스레드가 나노초 단위로 읽거나 쓸 준비가 된 소켓을 기다리는 데 소비한 평균 시간입니다.

metadata-age

현재 사용 중인 생산자 메타데이터의 경과 시간(초)입니다.

network-io-rate

초당 모든 연결에 대한 평균 네트워크 작업 수(읽기 또는 쓰기)입니다.

outgoing-byte-rate

모든 서버로 초당 전송되는 평균 발신 바이트 수입니다.

produce-throttle-time-avg

요청이 브로커에 의해 제한되는 평균 시간(ms)입니다.

produce-throttle-time-max

요청이 브로커에 의해 제한되는 최대 시간(ms)입니다.

record-error-rate

초당 평균 레코드 수가 전송되어 오류가 발생했습니다.

record-error-total

이로 인해 오류가 발생한 총 레코드 수가 전송됩니다.

record-queue-time-avg

전송 버퍼에 사용된 ms 레코드 배치의 평균 시간입니다.

record-queue-time-max

send 버퍼에 사용된 ms 레코드 일괄 처리의 최대 시간입니다.

record-retry-rate

재시도된 레코드 수의 초당 평균이 보냅니다.

record-retry-total

재시도된 총 레코드 수입니다.

record-send-rate

초당 전송되는 평균 레코드 수입니다.

record-send-total

전송된 총 레코드 수입니다.

record-size-avg

평균 레코드 크기입니다.

record-size-max

최대 레코드 크기입니다.

records-per-request-avg

요청당 평균 레코드 수입니다.

request-latency-avg

ms의 평균 요청 대기 시간입니다.

request-latency-max

ms의 최대 요청 대기 시간입니다.

request-rate

초당 전송되는 평균 요청 수입니다.

request-size-avg

창에 있는 모든 요청의 평균 크기입니다.

request-size-max

창에 전송된 모든 요청의 최대 크기입니다.

requests-in-flight

현재 진행 중인 요청 수는 응답을 대기합니다.

response-rate

초당 보낸 응답 수입니다.

선택 등급

I/O 계층에서 초당 새 I/O를 수행하는 횟수입니다.

successful-authentication-rate

SASL 또는 SSL을 사용하여 성공적으로 인증된 연결.

waiting-threads

사용자 스레드 수가 레코드를 큐에 추가하도록 버퍼 메모리 대기를 차단했습니다.

7.6.2. Cryostat와 일치하는 kafka.producer:type=producer-metrics,client-id=*,node-id=*
링크 복사

이는 각 브로커에 대한 연결에 대한 생산자 수준의 메트릭입니다.

Expand
속성설명

incoming-byte-rate

노드의 초당 수신된 평균 응답 수입니다.

outgoing-byte-rate

노드의 초당 전송된 평균 발신 바이트 수입니다.

request-latency-avg

노드의 평균 요청 대기 시간 ms입니다.

request-latency-max

노드의 최대 요청 대기 시간(ms)입니다.

request-rate

노드의 초당 전송되는 평균 요청 수입니다.

request-size-avg

노드의 창에 있는 모든 요청의 평균 크기입니다.

request-size-max

노드의 창에서 전송된 모든 요청의 최대 크기입니다.

response-rate

노드에 대해 초당 전송된 응답 수입니다.

이는 생산자가 메시지를 보내는 주제에 대한 주제 수준의 지표입니다.

Expand
속성설명

byte-rate

주제의 초당 전송되는 평균 바이트 수입니다.

byte-total

항목에 대해 전송된 총 바이트 수입니다.

compression-rate

압축되지 않은 크기의 압축된 일괄 처리의 평균 비율로 정의된 주제의 레코드 배치의 평균 압축률입니다.

record-error-rate

초당 평균 레코드 수가 전송되어 항목에 오류가 발생했습니다.

record-error-total

주제 오류가 발생한 총 레코드 수입니다.

record-retry-rate

재시도된 레코드당 평균 횟수는 주제로 보냅니다.

record-retry-total

주제의 총 재시도 레코드 수입니다.

record-send-rate

주제의 초당 전송되는 평균 레코드 수입니다.

record-send-total

항목에 대해 전송된 총 레코드 수입니다.

7.7. 소비자 Cryostat
링크 복사

다음 Cryostat는 Kafka Streams 애플리케이션 및 싱크 커넥터를 사용한 Kafka Connect를 포함한 Kafka 소비자 애플리케이션에 존재합니다.

7.7.1. Cryostat와 일치하는 kafka.consumer:type=consumer-metrics,client-id=*
링크 복사

이는 소비자 수준의 지표입니다.

Expand
속성설명

connection-close-rate

창에서 초당 연결이 닫힙니다.

connection-count

현재 활성 연결 수입니다.

connection-creation-rate

창에서 초당 설정된 새 연결입니다.

failed-authentication-rate

인증에 실패한 연결입니다.

incoming-byte-rate

모든 소켓에서 바이트/초를 읽습니다.

io-ratio

I/O 스레드가 I/O를 수행하는 데 소요된 시간의 분수입니다.

io-time-ns-avg

선택 항목당 I/O 평균 시간( 나노초)입니다.

io-wait-ratio

I/O 스레드가 기다리는 데 걸린 시간 중 일부입니다.

io-wait-time-ns-avg

I/O 스레드가 나노초 단위로 읽거나 쓸 준비가 된 소켓을 기다리는 데 소비한 평균 시간입니다.

network-io-rate

초당 모든 연결에 대한 평균 네트워크 작업 수(읽기 또는 쓰기)입니다.

outgoing-byte-rate

모든 서버로 초당 전송되는 평균 발신 바이트 수입니다.

request-rate

초당 전송되는 평균 요청 수입니다.

request-size-avg

창에 있는 모든 요청의 평균 크기입니다.

request-size-max

창에 전송된 모든 요청의 최대 크기입니다.

response-rate

초당 보낸 응답 수입니다.

선택 등급

I/O 계층에서 초당 새 I/O를 수행하는 횟수입니다.

successful-authentication-rate

SASL 또는 SSL을 사용하여 성공적으로 인증된 연결.

7.7.2. Cryostat와 일치하는 kafka.consumer:type=consumer-metrics,client-id=*,node-id=*
링크 복사

이는 각 브로커에 대한 연결에 대한 소비자 수준의 메트릭입니다.

Expand
속성설명

incoming-byte-rate

노드의 초당 수신된 평균 응답 수입니다.

outgoing-byte-rate

노드의 초당 전송된 평균 발신 바이트 수입니다.

request-latency-avg

노드의 평균 요청 대기 시간 ms입니다.

request-latency-max

노드의 최대 요청 대기 시간(ms)입니다.

request-rate

노드의 초당 전송되는 평균 요청 수입니다.

request-size-avg

노드의 창에 있는 모든 요청의 평균 크기입니다.

request-size-max

노드의 창에서 전송된 모든 요청의 최대 크기입니다.

response-rate

노드에 대해 초당 전송된 응답 수입니다.

소비자 그룹에 대한 소비자 수준의 메트릭입니다.

Expand
속성설명

assigned-partitions

이 사용자에게 현재 할당된 파티션 수입니다.

commit-latency-avg

커밋 요청에 걸리는 평균 시간입니다.

commit-latency-max

커밋 요청에 걸린 최대 시간입니다.

commit-rate

초당 커밋 호출 수입니다.

heartbeat-rate

초당 평균 하트비트 수입니다.

heartbeat-response-time-max

하트비트 요청에 대한 응답을 수신하는 데 걸린 최대 시간입니다.

join-rate

초당 조인된 그룹 수입니다.

join-time-avg

그룹에 다시 참여한 평균 시간입니다.

join-time-max

그룹 다시 참여에 걸린 최대 시간입니다.

last-heartbeat-seconds-ago

마지막 컨트롤러 하트비트 이후의 시간(초)입니다.

sync-rate

초당 그룹 동기화 수입니다.

sync-time-avg

그룹 동기화에 걸리는 평균 시간입니다.

sync-time-max

그룹 동기화에 걸리는 최대 시간입니다.

이는 소비자의 가져오기에 대한 소비자 수준의 메트릭입니다.

Expand
속성설명

bytes-consumed-rate

초당 소비되는 평균 바이트 수입니다.

bytes-consumed-total

사용된 총 바이트 수입니다.

fetch-latency-avg

가져오기 요청에 걸리는 평균 시간입니다.

fetch-latency-max

가져오기 요청에 걸린 최대 시간입니다.

fetch-rate

초당 가져오기 요청 수입니다.

fetch-size-avg

요청당 가져온 평균 바이트 수입니다.

fetch-size-max

요청당 가져온 최대 바이트 수입니다.

fetch-throttle-time-avg

mms의 평균 throttle 시간입니다.

fetch-throttle-time-max

ms의 최대 제한 시간입니다.

fetch-total

총 가져오기 요청 수입니다.

records-consumed-rate

초당 소비되는 평균 레코드 수입니다.

records-consumed-total

사용된 총 레코드 수입니다.

records-lag-max

이 창에서 파티션의 레코드 수에 대한 최대 지연입니다.

records-lead-min

이 창에 있는 모든 파티션에 대한 최소 레코드 수입니다.

records-per-request-avg

각 요청의 평균 레코드 수입니다.

이는 소비자의 가져오기에 대한 주제 수준의 메트릭입니다.

Expand
속성설명

bytes-consumed-rate

항목에 대해 초당 소비되는 평균 바이트 수입니다.

bytes-consumed-total

항목에 사용된 총 바이트 수입니다.

fetch-size-avg

주제의 요청당 가져온 평균 바이트 수입니다.

fetch-size-max

주제의 요청당 가져온 최대 바이트 수입니다.

records-consumed-rate

주제의 초당 소비되는 평균 레코드 수입니다.

records-consumed-total

항목에 사용된 총 레코드 수입니다.

records-per-request-avg

주제의 각 요청의 평균 레코드 수입니다.

이는 소비자의 가져오기에 대한 파티션 수준의 메트릭입니다.

Expand
속성설명

preferred-read-replica

파티션의 현재 읽기 복제본 또는 리더에서 읽는 경우 -1입니다.

records-lag

파티션의 최신 지연입니다.

records-lag-avg

파티션의 평균 지연입니다.

records-lag-max

파티션의 최대 지연입니다.

records-lead

파티션의 최신 지도입니다.

records-lead-avg

파티션의 평균 리드입니다.

records-lead-min

파티션의 최소 리드입니다.

7.8. Kafka Connect Cryostats
링크 복사

참고

Kafka Connect에는 소스 커넥터를 위한 생산자 와 싱크 커넥터를 위한 소비자에 대한 배포가 포함되어 있으며 여기에 설명된 내용도 포함됩니다.

7.8.1. kafka.connect:type=connect-metrics,client-id=*와 일치하는 Cryostat
링크 복사

연결 수준의 메트릭입니다.

Expand
속성설명

connection-close-rate

창에서 초당 연결이 닫힙니다.

connection-count

현재 활성 연결 수입니다.

connection-creation-rate

창에서 초당 설정된 새 연결입니다.

failed-authentication-rate

인증에 실패한 연결입니다.

incoming-byte-rate

모든 소켓에서 바이트/초를 읽습니다.

io-ratio

I/O 스레드가 I/O를 수행하는 데 소요된 시간의 분수입니다.

io-time-ns-avg

선택 항목당 I/O 평균 시간( 나노초)입니다.

io-wait-ratio

I/O 스레드가 기다리는 데 걸린 시간 중 일부입니다.

io-wait-time-ns-avg

I/O 스레드가 나노초 단위로 읽거나 쓸 준비가 된 소켓을 기다리는 데 소비한 평균 시간입니다.

network-io-rate

초당 모든 연결에 대한 평균 네트워크 작업 수(읽기 또는 쓰기)입니다.

outgoing-byte-rate

모든 서버로 초당 전송되는 평균 발신 바이트 수입니다.

request-rate

초당 전송되는 평균 요청 수입니다.

request-size-avg

창에 있는 모든 요청의 평균 크기입니다.

request-size-max

창에 전송된 모든 요청의 최대 크기입니다.

response-rate

초당 보낸 응답 수입니다.

선택 등급

I/O 계층에서 초당 새 I/O를 수행하는 횟수입니다.

successful-authentication-rate

SASL 또는 SSL을 사용하여 성공적으로 인증된 연결.

7.8.2. kafka.connect:type=connect-metrics,client-id=*,node-id=*와 일치하는 Cryostat
링크 복사

이는 각 브로커에 대한 연결에 대한 연결 수준의 메트릭입니다.

Expand
속성설명

incoming-byte-rate

노드의 초당 수신된 평균 응답 수입니다.

outgoing-byte-rate

노드의 초당 전송된 평균 발신 바이트 수입니다.

request-latency-avg

노드의 평균 요청 대기 시간 ms입니다.

request-latency-max

노드의 최대 요청 대기 시간(ms)입니다.

request-rate

노드의 초당 전송되는 평균 요청 수입니다.

request-size-avg

노드의 창에 있는 모든 요청의 평균 크기입니다.

request-size-max

노드의 창에서 전송된 모든 요청의 최대 크기입니다.

response-rate

노드에 대해 초당 전송된 응답 수입니다.

7.8.3. Cryostat와 일치하는 kafka.connect:type=connect-worker-metrics
링크 복사

연결 수준의 메트릭입니다.

Expand
속성설명

Connector-count

이 작업자에서 실행되는 커넥터 수입니다.

connector-startup-attempts-total

이 작업자가 시도한 총 커넥터 시작 수입니다.

connector-startup-failure-percentage

이 작업자 커넥터의 평균 백분율은 실패한 것으로 시작됩니다.

connector-startup-failure-total

실패한 총 커넥터 수가 시작됩니다.

connector-startup-success-percentage

이 작업자의 커넥터의 평균 비율이 성공하기 시작합니다.

connector-startup-success-total

성공한 총 커넥터 수가 시작됩니다.

task-count

이 작업자에서 실행되는 작업 수입니다.

task-startup-attempts-total

이 작업자가 시도한 총 작업 시작 수입니다.

task-startup-failure-percentage

이 작업자의 작업의 평균 백분율이 실패한 것으로 시작됩니다.

task-startup-failure-total

실패한 총 작업 수입니다.

task-startup-success-percentage

이 작업자의 작업의 평균 백분율이 성공한 것으로 시작됩니다.

task-startup-success-total

성공한 총 작업 수입니다.

7.8.4. Cryostat와 일치하는 kafka.connect:type=connect-worker-rebalance-metrics
링크 복사

Expand
속성설명

completed-rebalances-total

이 작업자가 완료한 총 리밸런스 수입니다.

connect-protocol

이 클러스터에서 사용하는 연결 프로토콜입니다.

epoch

이 작업자의 epoch 또는 generation 번호입니다.

leader-name

그룹 리더의 이름입니다.

rebalance-avg-time-ms

이 작업자가 재조정하는 데 소비되는 평균 시간(밀리초)입니다.

rebalance-max-time-ms

이 작업자가 재조정하는 데 소비되는 최대 시간(밀리초)입니다.

재조정

이 작업자가 현재 재조정 중인지 여부입니다.

time-since-last-rebalance-ms

이 작업자가 최신 리밸런스를 완료한 이후의 시간(밀리초)입니다.

7.8.5. Cryostat와 일치하는 kafka.connect:type=connector-metrics,connector=*
링크 복사

Expand
속성설명

Connector-class

커넥터 클래스의 이름입니다.

connector-type

커넥터의 유형입니다. '소스' 또는 'sink' 중 하나입니다.

Connector-version

커넥터에서 보고한 커넥터 클래스의 버전입니다.

status

커넥터의 상태입니다. 'unassigned', 'running', 'paused', 'failed' 또는 'destroyed' 중 하나입니다.

Expand
속성설명

batch-size-avg

커넥터에서 처리하는 배치의 평균 크기입니다.

batch-size-max

커넥터에서 처리하는 배치의 최대 크기입니다.

offset-commit-avg-time-ms

이 작업에서 오프셋을 커밋하는 데 걸리는 평균 시간(밀리초)입니다.

offset-commit-failure-percentage

이 작업의 오프셋 커밋의 평균 백분율이 실패한 것입니다.

offset-commit-max-time-ms

이 작업에서 오프셋을 커밋하는 데 걸리는 최대 시간(밀리초)입니다.

offset-commit-success-percentage

이 작업의 오프셋 커밋의 평균 백분율이 성공한 것입니다.

pause-ratio

이 작업이 일시 중지 상태에서 보낸 시간의 분수입니다.

running-ratio

이 작업이 실행 중 상태로 보낸 시간의 분수입니다.

status

커넥터 작업의 상태입니다. 'unassigned', 'running', 'paused', 'failed' 또는 'destroyed' 중 하나입니다.

7.8.7. Cryostat와 일치하는 kafka.connect:type=sink-task-metrics,connector=*,task=*
링크 복사

Expand
속성설명

offset-commit-completion-rate

성공적으로 완료된 평균 1초당 커밋 완료 횟수입니다.

offset-commit-completion-total

성공적으로 완료된 총 오프셋 커밋 완료 수입니다.

offset-commit-seq-no

오프셋 커밋의 현재 시퀀스 번호입니다.

offset-commit-skip-rate

너무 늦고 건너뛴 /무시된 평균 오프셋 커밋 완료 수입니다.

offset-commit-skip-total

너무 늦고 건너뛴/무시됨된 총 오프셋 커밋 완료 수입니다.

partition-count

이 작업자에서 이름이 지정된 싱크 커넥터에 속하는 이 작업에 할당된 주제 파티션 수입니다.

put-batch-avg-time-ms

이 작업에서 싱크 레코드 배치를 배치하는 데 걸리는 평균 시간입니다.

put-batch-max-time-ms

이 작업에서 싱크 레코드 배치를 배치하는 데 걸리는 최대 시간입니다.

sink-record-active-count

Kafka에서 읽었지만 아직 완전히 커밋되지 않은/종료/승인/취약된 레코드 수입니다.

sink-record-active-count-avg

Kafka에서 읽었지만 아직 완전히 커밋되지 않은/flushed/acknowled 작업에서 읽은 평균 레코드 수입니다.

sink-record-active-count-max

Kafka에서 읽은 최대 레코드 수이지만 싱크 작업에서 완전히 커밋/종료/취약되지 않은 레코드 수입니다.

sink-record-lag-max

싱크 작업에서 모든 주제 파티션에 대한 소비자의 위치 뒤에 있는 레코드 수에 대한 최대 지연입니다.

sink-record-read-rate

이 작업자의 이름이 지정된 싱크 커넥터에 속하는 이 작업의 Kafka에서 읽은 평균 초당 레코드 수입니다. 변환이 적용되기 전입니다.

sink-record-read-total

작업이 마지막으로 재시작되었기 때문에 이 작업자의 명명된 싱크 커넥터에 속하는 이 작업에서 Kafka에서 읽은 총 레코드 수입니다.

sink-record-send-rate

변환 및 이 작업자의 이름이 지정된 싱크 커넥터에 속하는 이 작업에 전송된 평균 초당 출력 수입니다. 변환 후 변환이 적용되고 변환에 의해 필터링된 모든 레코드를 제외합니다.

sink-record-send-total

작업이 마지막으로 다시 시작되었기 때문에 이 작업자의 이름이 지정된 싱크 커넥터에 속하는 이 작업에 대한 변환 및 전송/프로덕션의 총 레코드 출력 수입니다.

7.8.8. Cryostat와 일치하는 kafka.connect:type=source-task-metrics,connector=*,task=*
링크 복사

Expand
속성설명

poll-batch-avg-time-ms

이 작업에서 소스 레코드 배치를 폴링하는 데 걸리는 평균 시간(밀리초)입니다.

poll-batch-max-time-ms

이 작업에서 소스 레코드 배치를 폴링하는 데 걸리는 최대 시간(밀리초)입니다.

source-record-active-count

이 작업에서 생성되었지만 Kafka에 완전히 기록되지 않은 레코드 수입니다.

source-record-active-count-avg

이 작업에서 생성되었지만 Kafka에 완전히 기록되지 않은 평균 레코드 수입니다.

source-record-active-count-max

이 작업에서 생성되었지만 Kafka에 완전히 기록되지 않은 최대 레코드 수입니다.

source-record-poll-rate

이 작업자의 이름이 지정된 소스 커넥터에 속하는 이 작업에 의해 생성/폴링된 평균 레코드 수입니다.

source-record-poll-total

이 작업자에서 이름이 지정된 소스 커넥터에 속하는 이 작업에 의해 생성/폴링된 총 레코드 수입니다.

source-record-write-rate

변환에서 출력하고 이 작업자의 이름이 지정된 소스 커넥터에 속하는 이 작업의 Kafka에 작성된 평균 초당 레코드 수입니다. 변환 후 변환이 적용되고 변환에 의해 필터링된 모든 레코드를 제외합니다.

source-record-write-total

작업이 마지막으로 다시 시작된 이후 이 작업자의 이름이 지정된 소스 커넥터에 속하는 이 작업의 변환 및 Kafka에 작성된 레코드 출력 수입니다.

7.8.9. Cryostat와 일치하는 kafka.connect:type=task-error-metrics,connector=*,task=*
링크 복사

Expand
속성설명

deadletterqueue-produce-failures

dead letter queue에 대한 실패한 쓰기 수입니다.

deadletterqueue-produce-requests

dead letter 큐에 대한 시도된 쓰기 횟수입니다.

last-error-timestamp

이 작업에 마지막으로 오류가 발생했을 때의 epoch 타임 스탬프입니다.

total-errors-logged

기록된 오류 수입니다.

total-record-errors

이 작업의 레코드 처리 오류 수입니다.

total-record-failures

이 작업의 레코드 처리 실패 수입니다.

total-records-skipped

오류로 인해 건너뛰는 레코드 수입니다.

total-retries

재시도된 작업 수입니다.

7.9. Kafka Streams MBeans
링크 복사

참고

Streams 애플리케이션에는 여기에 설명된 것 외에도 생산자 및 소비자가 포함됩니다.

7.9.1. kafka.streams:type=stream-metrics,client-id=*와 일치하는 Cryostat
링크 복사

이러한 메트릭은 metrics.recording.level 구성 매개변수가 info 또는 debug 인 경우 수집됩니다.

Expand
속성설명

commit-latency-avg

이 스레드의 모든 실행 작업에서 커밋을 위한 평균 실행 시간입니다.

commit-latency-max

이 스레드의 실행 중인 모든 작업에 대해 커밋하는 최대 실행 시간입니다.

commit-rate

초당 평균 커밋 수입니다.

commit-total

모든 작업에서 총 커밋 호출 수입니다.

poll-latency-avg

이 스레드의 모든 실행 작업에서 폴링을 위한 평균 실행 시간입니다.

poll-latency-max

이 스레드의 실행 중인 모든 작업에 폴링하는 최대 실행 시간입니다.

poll-rate

초당 평균 폴링 수입니다.

poll-total

모든 작업에서 총 폴링 호출 수입니다.

process-latency-avg

이 스레드의 모든 실행 작업에 걸쳐 처리의 평균 실행 시간입니다.

process-latency-max

이 스레드의 모든 실행 작업을 처리하기 위한 ms의 최대 실행 시간입니다.

process-rate

초당 평균 프로세스 호출 수입니다.

process-total

모든 작업에서 총 프로세스 호출 수입니다.

punctuate-latency-avg

이 스레드의 실행 중인 모든 작업에서 구두를 위해 ms의 평균 실행 시간입니다.

punctuate-latency-max

이 스레드의 모든 실행 작업 간에 구두는 최대 실행 시간입니다.

punctuate-rate

초당 평균 구두점 수입니다.

punctuate-total

모든 작업에 대한 총 문장 호출 수입니다.

skipped-records-rate

초당 평균 건너뛰기 레코드 수입니다.

skipped-records-total

건너뛰는 총 레코드 수입니다.

task-closed-rate

초당 종료되는 평균 작업 수입니다.

task-closed-total

폐쇄된 총 작업 수입니다.

task-created-rate

초당 새로 생성된 평균 작업 수입니다.

task-created-total

생성된 총 작업 수입니다.

작업 지표.

이러한 메트릭은 metrics.recording.level 구성 매개변수가 디버그 인 경우 수집됩니다.

Expand
속성설명

commit-latency-avg

이 작업의 ns의 평균 커밋 시간입니다.

commit-latency-max

이 작업의 ns 최대 커밋 시간입니다.

commit-rate

초당 평균 커밋 호출 수입니다.

commit-total

총 커밋 호출 수입니다.

프로세서 노드 지표.

이러한 메트릭은 metrics.recording.level 구성 매개변수가 디버그 인 경우 수집됩니다.

Expand
속성설명

create-latency-avg

ns의 평균 실행 시간입니다.

create-latency-max

ns의 최대 실행 시간입니다.

create-rate

초당 평균 생성 작업 수입니다.

create-total

라는 총 생성 작업 수입니다.

destroy-latency-avg

ns의 평균 실행 시간입니다.

destroy-latency-max

ns의 최대 실행 시간입니다.

destroy-rate

초당 평균 제거 작업 수입니다.

destroy-total

라는 총 제거 작업 수입니다.

Forward-rate

소스 노드에서만 초당 다운스트림이 전달되는 평균 레코드 속도입니다.

Forward-total

소스 노드에서만 다운스트림을 전달하는 총 레코드 수입니다.

process-latency-avg

ns의 평균 프로세스 실행 시간입니다.

process-latency-max

ns의 최대 프로세스 실행 시간입니다.

process-rate

초당 평균 프로세스 작업 수입니다.

process-total

호출되는 총 프로세스 작업 수입니다.

punctuate-latency-avg

ns의 평균 실행 시간입니다.

punctuate-latency-max

ns의 최대 실행 시간입니다.

punctuate-rate

초당 평균 구두 작업 수입니다.

punctuate-total

라는 총 문장 작업 수입니다.

상태 저장소 지표.

이러한 메트릭은 metrics.recording.level 구성 매개변수가 디버그 인 경우 수집됩니다.

Expand
속성설명

all-latency-avg

ns의 평균 모든 작업 실행 시간입니다.

all-latency-max

ns의 모든 작업 실행 시간 최대입니다.

all-rate

이 저장소의 평균 작동률입니다.

all-total

이 저장소에 대한 모든 작업 호출의 총 수입니다.

delete-latency-avg

ns의 평균 실행 시간입니다.

delete-latency-max

ns의 최대 삭제 실행 시간입니다.

delete-rate

이 저장소의 평균 삭제 비율입니다.

delete-total

이 저장소에 대한 총 삭제 호출 수입니다.

flush-latency-avg

ns의 평균 플러시 실행 시간입니다.

flush-latency-max

ns의 최대 플러시 실행 시간입니다.

flush-rate

이 저장소의 평균 플러시 비율입니다.

flush-total

이 저장소에 대한 총 플러시 호출 수입니다.

get-latency-avg

ns의 평균 실행 시간입니다.

get-latency-max

ns의 최대 get execution 시간입니다.

get-rate

이 저장소에 대한 평균 가격입니다.

get-total

이 저장소에 대한 총 get 호출 수입니다.

put-all-latency-avg

ns의 평균 put-all 실행 시간입니다.

put-all-latency-max

ns의 최대 put-all 실행 시간입니다.

put-all-rate

이 점포의 평균 액수입니다.

put-all-total

이 저장소에 대한 총 put-all 호출 수입니다.

put-if-absent-latency-avg

ns의 평균 put-if-absent 실행 시간입니다.

put-if-absent-latency-max

ns의 최대 put-if-absent 실행 시간입니다.

put-if-absent-rate

이 저장소에 대한 평균 put-if-absent 비율입니다.

put-if-absent-total

이 저장소에 대한 총 put-if-absent 호출 수입니다.

put-latency-avg

평균 실행 시간을 ns에 넣습니다.

put-latency-max

ns의 최대 실행 시간입니다.

put-rate

이 저장소에 대한 평균 비율입니다.

put-total

이 저장소에 대한 총 호출 수입니다.

range-latency-avg

ns의 평균 범위 실행 시간입니다.

range-latency-max

ns의 최대 범위 실행 시간입니다.

range-rate

이 저장소의 평균 범위 비율입니다.

range-total

이 저장소에 대한 총 범위 호출 수입니다.

restore-latency-avg

ns의 평균 복원 실행 시간입니다.

restore-latency-max

ns의 최대 복원 실행 시간입니다.

restore-rate

이 저장소의 평균 복원 비율입니다.

restore-total

이 저장소에 대한 총 복원 호출 수입니다.

레코드 캐시 지표.

이러한 메트릭은 metrics.recording.level 구성 매개변수가 디버그 인 경우 수집됩니다.

Expand
속성설명

hitRatio-avg

총 캐시 읽기 요청에 대한 캐시 읽기의 비율로 정의된 평균 캐시 적중률입니다.

hitRatio-max

최대 캐시 적중 비율입니다.

hitRatio-min

Mininum 캐시 적중 비율입니다.

8장. Kafka Connect
링크 복사

Kafka Connect는 Apache Kafka와 외부 시스템 간에 데이터를 스트리밍하는 툴입니다. 확장성 및 안정성을 유지하면서 대량의 데이터를 이동하기 위한 프레임워크를 제공합니다. Kafka Connect는 일반적으로 Kafka 클러스터 외부에 있는 데이터베이스, 스토리지 및 메시징 시스템과 Kafka를 통합하는 데 사용됩니다.

Kafka Connect는 다양한 유형의 외부 시스템에 대한 연결을 구현하는 커넥터 플러그인을 사용합니다. 커넥터 플러그인에는 싱크와 source의 두 가지 유형이 있습니다. 싱크 커넥터는 Kafka에서 외부 시스템으로 데이터를 스트리밍합니다. 소스 커넥터는 외부 시스템에서 Kafka로 데이터를 스트리밍합니다.

Kafka Connect는 독립 실행형 또는 분산 모드로 실행할 수 있습니다.

독립 실행형 모드
독립 실행형 모드에서 Kafka Connect는 속성 파일에서 읽은 사용자 정의 구성이 있는 단일 노드에서 실행됩니다.
분산 모드
분산 모드에서 Kafka Connect는 하나 이상의 작업자 노드에서 실행되며 워크로드가 그 사이에 배포됩니다. HTTP REST 인터페이스를 사용하여 커넥터와 해당 구성을 관리합니다.

8.1. 독립 실행형 모드에서 Kafka 연결
링크 복사

독립 실행형 모드에서 Kafka Connect는 단일 노드에서 단일 프로세스로 실행됩니다. 속성 파일을 사용하여 독립 실행형 모드의 구성을 관리합니다.

8.1.1. 독립 실행형 모드에서 Kafka 연결 구성
링크 복사

독립 실행형 모드에서 Kafka Connect를 구성하려면 config/connect-standalone.properties 구성 파일을 편집합니다. 다음 옵션이 가장 중요합니다.

bootstrap.servers
Kafka에 대한 부트스트랩 연결로 사용되는 Kafka 브로커 주소 목록입니다. 예를 들어 kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092.
key.converter
메시지 키를 Kafka 형식으로 변환하거나 Kafka 형식으로 변환하는 데 사용되는 클래스입니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.
value.converter
Kafka 형식으로 메시지 페이로드를 변환하는 데 사용되는 클래스입니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.
offset.storage.file.filename
오프셋 데이터가 저장되는 파일을 지정합니다.

구성 파일의 예는 config/connect-standalone.properties 의 설치 디렉터리에 제공됩니다. 지원되는 모든 Kafka Connect 구성 옵션의 전체 목록은 [kafka-connect-configuration-parameters-str]을 참조하십시오.

Connector 플러그인은 부트스트랩 주소를 사용하여 Kafka 브로커에 대한 오픈 클라이언트 연결을 제공합니다. 이러한 연결을 구성하려면 생산자 또는 소비자 접두사가 붙은 표준 Kafka 생산자 및 소비자 구성 옵션을 사용합니다.

Kafka 생산자 및 소비자 구성에 대한 자세한 내용은 다음을 참조하십시오.

8.1.2. 독립 실행형 모드에서 Kafka Connect에서 커넥터 구성
링크 복사

속성 파일을 사용하여 독립 실행형 모드에서 Kafka Connect에 대한 커넥터 플러그인을 구성할 수 있습니다. 대부분의 구성 옵션은 각 커넥터에 따라 다릅니다. 다음 옵션은 모든 커넥터에 적용됩니다.

name
현재 Kafka Connect 인스턴스 내에서 고유해야 하는 커넥터의 이름입니다.
connector.class
커넥터 플러그인의 클래스입니다. 예를 들어 org.apache.kafka.connect.file.FileStreamSinkConnector.
tasks.max
지정된 커넥터가 사용할 수 있는 최대 작업 수입니다. 작업을 사용하면 커넥터가 병렬로 작업을 수행할 수 있습니다. 커넥터는 지정된 것보다 적은 작업을 생성할 수 있습니다.
key.converter
메시지 키를 Kafka 형식으로 변환하거나 Kafka 형식으로 변환하는 데 사용되는 클래스입니다. 이렇게 하면 Kafka Connect 구성에 의해 설정된 기본값이 재정의됩니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.
value.converter
Kafka 형식으로 메시지 페이로드를 변환하는 데 사용되는 클래스입니다. 이렇게 하면 Kafka Connect 구성에 의해 설정된 기본값이 재정의됩니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.

또한 싱크 커넥터에 대해 다음 옵션 중 하나 이상을 설정해야 합니다.

주제
입력으로 사용되는 쉼표로 구분된 주제 목록입니다.
topics.regex
입력으로 사용되는 주제의 Java 정규식입니다.

기타 모든 옵션은 사용 가능한 커넥터에 대한 설명서를 참조하십시오.

AMQ Streams에는 커넥터 구성 파일 예제가 포함되어 있습니다. AMQ Streams 설치 디렉터리의 config/connect-file-sink.properties 및 config/connect-file-source.properties 를 참조하십시오.

8.1.3. 독립 실행형 모드에서 Kafka 연결 실행
링크 복사

다음 절차에서는 독립 실행형 모드에서 Kafka Connect를 구성하고 실행하는 방법을 설명합니다.

사전 요구 사항

  • 설치되어 실행 중인 AMQ Streams} 클러스터입니다.

프로세스

  1. /opt/kafka/config/connect-standalone.properties Kafka Connect 구성 파일을 편집하고 Kafka 브로커를 가리키도록 bootstrap.server 를 설정합니다. 예를 들면 다음과 같습니다. 

    bootstrap.servers=kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092
    Copy to Clipboard Toggle word wrap

  2. 구성 파일로 Kafka Connect를 시작하고 하나 이상의 커넥터 구성을 지정합니다. 

    su - kafka
/opt/kafka/bin/connect-standalone.sh /opt/kafka/config/connect-standalone.properties connector1.properties
[connector2.properties ...]
    Copy to Clipboard Toggle word wrap

  3. Kafka Connect가 실행 중인지 확인합니다. 

       jcmd | grep ConnectStandalone
    Copy to Clipboard Toggle word wrap

추가 리소스

8.2. 분산 모드에서 Kafka 연결
링크 복사

분산 모드에서 Kafka Connect는 하나 이상의 작업자 노드에서 실행되며 워크로드가 그 사이에 배포됩니다. HTTP REST 인터페이스를 사용하여 커넥터 플러그인 및 해당 구성을 관리합니다.

8.2.1. 분산 모드에서 Kafka 연결 구성
링크 복사

Kafka Connect를 분산 모드로 구성하려면 config/connect-distributed.properties 구성 파일을 편집합니다. 다음 옵션이 가장 중요합니다.

bootstrap.servers
Kafka에 대한 부트스트랩 연결로 사용되는 Kafka 브로커 주소 목록입니다. 예를 들어 kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092.
key.converter
메시지 키를 Kafka 형식으로 변환하거나 Kafka 형식으로 변환하는 데 사용되는 클래스입니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.
value.converter
Kafka 형식으로 메시지 페이로드를 변환하는 데 사용되는 클래스입니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.
group.id
분산 Kafka Connect 클러스터의 이름입니다. 이는 고유해야 하며 다른 소비자 그룹 ID와 충돌해서는 안 됩니다. 기본값은 connect-cluster 입니다.
config.storage.topic
커넥터 구성을 저장하는 데 사용되는 Kafka 주제입니다. 기본값은 connect-configs 입니다.
offset.storage.topic
오프셋을 저장하는 데 사용되는 Kafka 주제입니다. 기본값은 connect-offset 입니다.
status.storage.topic
작업자 노드 상태에 사용되는 Kafka 주제입니다. 기본값은 connect-status 입니다.

AMQ Streams에는 분산 모드에서 Kafka Connect에 대한 구성 파일이 포함되어 있습니다. AMQ Streams 설치 디렉터리의 config/connect-distributed.properties 를 참조하십시오.

지원되는 모든 Kafka Connect 구성 옵션의 전체 목록은 부록 F. Kafka Connect 구성 매개변수 을 참조하십시오.

Connector 플러그인은 부트스트랩 주소를 사용하여 Kafka 브로커에 대한 오픈 클라이언트 연결을 제공합니다. 이러한 연결을 구성하려면 생산자 또는 소비자 접두사가 붙은 표준 Kafka 생산자 및 소비자 구성 옵션을 사용합니다.

Kafka 생산자 및 소비자 구성에 대한 자세한 내용은 다음을 참조하십시오.

8.2.2. 분산 Kafka Connect에서 커넥터 구성
링크 복사

HTTP REST 인터페이스

분산 Kafka Connect용 커넥터는 HTTP REST 인터페이스를 사용하여 구성됩니다. REST 인터페이스는 기본적으로 포트 8083에서 수신 대기합니다. 다음 끝점을 지원합니다.

GET /connectors
기존 커넥터 목록을 반환합니다.
POST /connectors
커넥터를 생성합니다. 요청 본문은 커넥터 구성이 포함된 JSON 오브젝트여야 합니다.
GET /connectors/ <name>
특정 커넥터에 대한 정보를 가져옵니다.
GET /connectors/ &lt;name&gt; /config
특정 커넥터의 구성을 가져옵니다.
PUT /connectors/ &lt;name&gt; /config
특정 커넥터의 구성을 업데이트합니다.
GET /connectors/ &lt;name&gt; /status
특정 커넥터의 상태를 가져옵니다.
PUT /connectors/ &lt;name&gt; /pause
커넥터 및 모든 작업을 일시 중지합니다. 커넥터는 모든 메시지 처리를 중지합니다.
PUT /connectors/<name>/resume
일시 중지된 커넥터를 다시 시작합니다.
POST /connectors/ &lt;name&gt; /restart
실패한 경우 커넥터를 다시 시작합니다.
DELETE /connectors/ <name>
커넥터를 삭제합니다.
GET /connector-plugins
지원되는 모든 커넥터 플러그인 목록을 가져옵니다.

커넥터 구성

대부분의 구성 옵션은 커넥터별 커넥터이며 커넥터의 문서에 포함되어 있습니다. 다음 필드는 모든 커넥터에 공통입니다.

name
커넥터의 이름입니다. 지정된 Kafka Connect 인스턴스 내에서 고유해야 합니다.
connector.class
커넥터 플러그인의 클래스입니다. 예: org.apache.kafka.connect.file.FileStreamSinkConnector.
tasks.max
이 커넥터에서 사용하는 최대 작업 수입니다. 작업은 커넥터가 작업을 병렬화하는 데 사용됩니다. 연결자는 지정된 것보다 적은 작업을 생성할 수 있습니다.
key.converter
Kafka 형식에서 메시지 키를 변환하는 데 사용되는 클래스입니다. 이렇게 하면 Kafka Connect 구성에 의해 설정된 기본값이 재정의됩니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.
value.converter
Kafka 형식으로 메시지 페이로드를 변환하는 데 사용되는 클래스입니다. 이렇게 하면 Kafka Connect 구성에 의해 설정된 기본값이 재정의됩니다. 예를 들어 org.apache.kafka.connect.json.JsonConverter.

또한 싱크 커넥터에 대해 다음 옵션 중 하나를 설정해야 합니다.

주제
입력으로 사용되는 쉼표로 구분된 주제 목록입니다.
topics.regex
입력으로 사용되는 주제의 Java 정규식입니다.

기타 모든 옵션은 특정 커넥터에 대한 설명서를 참조하십시오.

AMQ Streams에는 커넥터 구성 파일 예제가 포함되어 있습니다. 해당 파일은 AMQ Streams 설치 디렉터리의 config/connect-file-sink.properties 및 config/connect-file-source.properties 에서 찾을 수 있습니다.

8.2.3. 분산 Kafka 연결 실행
링크 복사

다음 절차에서는 분산 모드에서 Kafka Connect를 구성하고 실행하는 방법을 설명합니다.

사전 요구 사항

  • 설치되어 실행 중인 AMQ Streams 클러스터입니다.

클러스터 실행

  1. 모든 Kafka Connect 작업자 노드에서 /opt/kafka/config/connect-distributed.properties Kafka Connect 구성 파일을 편집합니다.

    • Kafka 브로커를 가리키도록 bootstrap.server 옵션을 설정합니다.
    • group.id 옵션을 설정합니다.
    • config.storage.topic 옵션을 설정합니다.
    • offset.storage.topic 옵션을 설정합니다.

    • status.storage.topic 옵션을 설정합니다.

      예를 들면 다음과 같습니다. 

      bootstrap.servers=kafka0.my-domain.com:9092,kafka1.my-domain.com:9092,kafka2.my-domain.com:9092
group.id=my-group-id
config.storage.topic=my-group-id-configs
offset.storage.topic=my-group-id-offsets
status.storage.topic=my-group-id-status
      Copy to Clipboard Toggle word wrap

  2. 모든 Kafka Connect 노드에서 /opt/kafka/config/connect-distributed.properties 구성 파일을 사용하여 Kafka Connect 작업자를 시작합니다. 

    su - kafka
/opt/kafka/bin/connect-distributed.sh /opt/kafka/config/connect-distributed.properties
    Copy to Clipboard Toggle word wrap

  3. Kafka Connect가 실행 중인지 확인합니다. 

    jcmd | grep ConnectDistributed
    Copy to Clipboard Toggle word wrap

추가 리소스

8.2.4. 커넥터 생성
링크 복사

다음 절차에서는 Kafka Connect REST API를 사용하여 분산 모드에서 Kafka Connect와 함께 사용할 커넥터 플러그인을 생성하는 방법을 설명합니다.

사전 요구 사항

  • 분산 모드에서 실행되는 Kafka Connect 설치입니다.

프로세스

  1. 커넥터 구성을 사용하여 JSON 페이로드를 준비합니다. 예를 들면 다음과 같습니다. 

    {
  "name": "my-connector",
  "config": {
  "connector.class": "org.apache.kafka.connect.file.FileStreamSinkConnector",
    "tasks.max": "1",
    "topics": "my-topic-1,my-topic-2",
    "file": "/tmp/output-file.txt"
  }
}
    Copy to Clipboard Toggle word wrap

  2. < KafkaConnectAddress > :8083/connectors 에 POST 요청을 보내 커넥터를 만듭니다. 다음 예제에서는 curl 을 사용합니다. 

    curl -X POST -H "Content-Type: application/json" --data @sink-connector.json http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap

  3. < KafkaConnectAddress > :8083/connectors 에게 GET 요청을 전송하여 커넥터가 배포되었는지 확인합니다. 다음 예제에서는 curl 을 사용합니다. 

    curl http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap

8.2.5. 커넥터 삭제
링크 복사

다음 절차에서는 Kafka Connect REST API를 사용하여 분산 모드에서 Kafka Connect에서 커넥터 플러그인을 삭제하는 방법을 설명합니다.

사전 요구 사항

  • 분산 모드에서 실행되는 Kafka Connect 설치입니다.

커넥터 삭제

  1. GET 요청을 < KafkaConnectAddress > :8083/connectors/ <ConnectorName > 에 전송하여 커넥터가 존재하는지 확인합니다. 다음 예제에서는 curl 을 사용합니다. 

    curl http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap

  2. 커넥터를 삭제하려면 < KafkaConnectAddress > :8083/connectors 로 DELETE 요청을 보냅니다. 다음 예제에서는 curl 을 사용합니다. 

    curl -X DELETE http://connect0.my-domain.com:8083/connectors/my-connector
    Copy to Clipboard Toggle word wrap

  3. < KafkaConnectAddress > :8083/connectors 에게 GET 요청을 전송하여 커넥터가 삭제되었는지 확인합니다. 다음 예제에서는 curl 을 사용합니다. 

    curl http://connect0.my-domain.com:8083/connectors
    Copy to Clipboard Toggle word wrap

8.3. 커넥터 플러그인
링크 복사

다음 커넥터 플러그인은 AMQ Streams에 포함되어 있습니다.

FileStreamSink 는 Kafka 주제에서 데이터를 읽고 파일에 데이터를 씁니다.

FileStreamSource 파일에서 데이터를 읽고 Kafka 주제로 데이터를 보냅니다.

필요한 경우 더 많은 커넥터 플러그인을 추가할 수 있습니다. Kafka Connect는 시작 시 추가 커넥터 플러그인을 검색하고 실행합니다. kafka Connect가 플러그인을 검색하는 경로를 정의하려면 plugin.path 구성 옵션을 설정합니다. 

plugin.path=/opt/kafka/connector-plugins,/opt/connectors
Copy to Clipboard Toggle word wrap

plugin.path 구성 옵션에는 쉼표로 구분된 경로 목록이 포함될 수 있습니다.

Kafka Connect를 분산 모드에서 실행하는 경우 모든 작업자 노드에서 플러그인을 사용할 수 있어야 합니다.

8.4. 커넥터 플러그인 추가
링크 복사

다음 절차에서는 추가 커넥터 플러그인을 추가하는 방법을 보여줍니다.

사전 요구 사항

  • 설치되어 실행 중인 AMQ Streams 클러스터입니다.

프로세스

  1. /opt/kafka/connector-plugins 디렉터리를 만듭니다. 

    su - kafka
mkdir /opt/kafka/connector-plugins
    Copy to Clipboard Toggle word wrap

  2. /opt/kafka/config/connect-standalone.properties 또는 /opt/kafka/config/connect-distributed.properties Kafka Connect 구성 파일을 편집하고 plugin.path 옵션을 /opt/kafka/connector-plugins 로 설정합니다. 예를 들면 다음과 같습니다. 

    plugin.path=/opt/kafka/connector-plugins
    Copy to Clipboard Toggle word wrap
  3. 커넥터 플러그인을 /opt/kafka/connector-plugins 에 복사합니다.
  4. Kafka Connect 작업자를 시작하거나 다시 시작합니다.

추가 리소스

9장. MirrorMaker 2.0에서 AMQ Streams 사용
링크 복사

MirrorMaker 2.0은 데이터 센터 내부 또는 여러 개의 활성 Kafka 클러스터 간에 데이터를 복제하는 데 사용됩니다.

클러스터 전체에서 데이터 복제는 다음과 같은 시나리오를 지원합니다.

  • 시스템 장애 발생 시 데이터 복구
  • 분석을 위한 데이터 집계
  • 특정 클러스터에 대한 데이터 액세스 제한
  • 대기 시간을 개선하기 위해 특정 위치에서 데이터 제공
참고

MirrorMaker 2.0에는 이전 버전의 MirrorMaker에서 지원되지 않는 기능이 있습니다. 그러나 레거시 모드에서 사용되도록 MirrorMaker 2.0을 구성할 수 있습니다.

추가 리소스

9.1. MirrorMaker 2.0 데이터 복제
링크 복사

MirrorMaker 2.0은 소스 Kafka 클러스터의 메시지를 사용하여 대상 Kafka 클러스터에 씁니다.

MirrorMaker 2.0은 다음을 사용합니다.

  • 소스 클러스터의 데이터를 사용하는 소스 클러스터 구성
  • 데이터를 대상 클러스터로 출력하기 위한 대상 클러스터 구성

MirrorMaker 2.0은 Kafka Connect 프레임워크를 기반으로 하며 클러스터 간 데이터 전송을 관리하는 커넥터 를 기반으로 합니다. MirrorMaker 2.0 MirrorSourceConnector 는 소스 클러스터에서 대상 클러스터로 주제를 복제합니다.

한 클러스터에서 다른 클러스터로 데이터를 미러링 하는 프로세스는 비동기적입니다. 권장되는 패턴은 메시지가 소스 Kafka 클러스터와 함께 로컬로 생성된 다음 대상 Kafka 클러스터에 원격으로 사용하는 것입니다.

MirrorMaker 2.0은 두 개 이상의 소스 클러스터에서 사용할 수 있습니다.

그림 9.1. 두 클러스터에서 복제

MirrorMaker 2.0 복제
View larger image
MirrorMaker 2.0 복제

기본적으로 소스 클러스터의 새로운 주제는 10분마다 생성됩니다. 소스 커넥터 구성에 refresh.topics.interval.seconds 를 추가하여 빈도를 변경할 수 있습니다. 그러나 작업 빈도를 늘리면 전체 성능에 영향을 미칠 수 있습니다.

9.2. 클러스터 구성
링크 복사

MirrorMaker 2.0을 활성/패시브 또는 활성 / 활성 클러스터 구성에서 사용할 수 있습니다.

  • 활성/활성 구성에서 두 클러스터 모두 활성 상태이며 동일한 데이터를 동시에 제공하므로 다른 지리적 위치에서 로컬로 동일한 데이터를 사용할 수 있도록 하려는 경우 유용합니다.
  • 활성/수동 구성에서 활성 클러스터의 데이터는 시스템 장애 시 데이터 복구와 같이 대기 상태로 유지되는 패시브 클러스터에 복제됩니다.

생산자와 소비자는 활성 클러스터에만 연결할 것으로 예상됩니다.

각 대상 대상에 MirrorMaker 2.0 클러스터가 필요합니다.

9.2.1. 양방향 복제(활성/활성)
링크 복사

MirrorMaker 2.0 아키텍처는 활성/활성 클러스터 구성에서 양방향 복제를 지원합니다.

각 클러스터는 소스 및 원격 주제의 개념을 사용하여 다른 클러스터의 데이터를 복제합니다. 각 클러스터에 동일한 항목이 저장되므로 원격 주제는 MirrorMaker 2.0으로 이름이 자동으로 변경되어 소스 클러스터를 나타냅니다. 원래 클러스터의 이름 앞에 주제 이름 앞에 추가됩니다.

그림 9.2. 주제 이름 변경

MirrorMaker 2.0 양방향 아키텍처
View larger image
MirrorMaker 2.0 양방향 아키텍처

원래 클러스터에 플래그를 지정하면 주제가 해당 클러스터로 다시 복제되지 않습니다.

원격 주제를 통한 복제 개념은 데이터 집계가 필요한 아키텍처를 구성할 때 유용합니다. 소비자는 별도의 집계 클러스터 없이도 동일한 클러스터 내의 소스 및 원격 주제를 구독할 수 있습니다.

9.2.2. Unidirectional replication (active/passive)
링크 복사

MirrorMaker 2.0 아키텍처는 활성/수동 클러스터 구성에서 비방향 복제를 지원합니다.

활성/수동 클러스터 구성을 사용하여 백업을 수행하거나 데이터를 다른 클러스터로 마이그레이션할 수 있습니다. 이 경우 원격 주제의 자동 이름 변경을 원하지 않을 수 있습니다.

소스 커넥터 구성에 IdentityReplicationPolicy 를 추가하여 자동 이름 변경을 덮어쓸 수 있습니다. 이 구성을 적용하면 주제는 원래 이름을 유지합니다.

9.2.3. 주제 구성 동기화
링크 복사

주제 구성은 소스 클러스터와 대상 클러스터 간에 자동으로 동기화됩니다. 구성 속성을 동기화하면 재조정 필요성이 줄어듭니다.

9.2.4. 데이터 무결성
링크 복사

MirrorMaker 2.0은 소스 주제를 모니터링하고 구성 변경 사항을 원격 주제로 전파하여 누락된 파티션을 확인 및 생성합니다. MirrorMaker 2.0만 원격 항목에 쓸 수 있습니다.

9.2.5. 오프셋 추적
링크 복사

MirrorMaker 2.0은 내부 주제 를 사용하여 소비자 그룹의 오프셋을 추적합니다.

  • 오프셋 동기화 주제는 레코드 메타데이터에서 복제된 주제 파티션의 소스 및 대상 오프셋을 매핑합니다.
  • Checkpoint 주제는 각 소비자 그룹의 복제된 주제 파티션에 대해 소스 및 대상 클러스터에 마지막으로 커밋된 오프셋을 매핑합니다.

체크포인트 항목에 대한 오프셋은 구성을 통해 미리 정해진 간격으로 추적됩니다. 두 항목 모두 장애 조치의 올바른 오프셋 위치에서 복제를 완전히 복원할 수 있습니다.

MirrorMaker 2.0은 MirrorCheckpointConnector 를 사용하여 오프셋 추적을 위한 체크포인트 를 내보냅니다.

9.2.6. 소비자 그룹 오프셋 동기화
링크 복사

__consumer_offsets 주제는 각 소비자 그룹에 대해 커밋된 오프셋에 대한 정보를 저장합니다. 오프셋 동기화는 소스 클러스터의 소비자 그룹에 대한 소비자 오프셋을 대상 클러스터의 소비자 오프셋 주제로 주기적으로 전송합니다.

오프셋 동기화는 특히 활성/수동 구성에서 유용합니다. 활성 클러스터가 다운되면 소비자 애플리케이션은 패시브(standby) 클러스터로 전환하고 마지막으로 전송된 오프셋 위치에서 선택할 수 있습니다.

주제 오프셋 동기화를 사용하려면 체크포인트 커넥터 구성에 sync.group.offsets.enabled 를 추가하고 속성을 true 로 설정하여 동기화를 활성화합니다. 동기화는 기본적으로 비활성화되어 있습니다.

소스 커넥터에서 IdentityReplicationPolicy 를 사용하는 경우 Checkpoint 커넥터 구성에서도 구성해야 합니다. 이렇게 하면 미러링된 소비자 오프셋이 올바른 항목에 적용됩니다.

소비자 오프셋은 대상 클러스터에서 활성 상태가 아닌 소비자 그룹에 대해서만 동기화됩니다.

활성화하면 소스 클러스터의 오프셋 동기화가 주기적으로 수행됩니다. checkpoint 커넥터 구성에 sync.group.offsets.interval.seconds 및 emit.checkpoints.interval.seconds 를 추가하여 빈도를 변경할 수 있습니다. 속성은 소비자 그룹 오프셋이 동기화되는 빈도(초)와 오프셋 추적을 위해 내보낸 체크포인트의 빈도를 지정합니다. 두 속성의 기본값은 60초입니다. 기본적으로 10분마다 수행되는 refresh.groups.interval.seconds 속성을 사용하여 새 소비자 그룹의 점검 빈도를 변경할 수도 있습니다.

동기화는 시간 기반이므로 소비자가 수동 클러스터로 전환하면 메시지가 중복될 수 있습니다.

9.2.7. 연결 검사
링크 복사

하트비트 내부 주제는 클러스터 간 연결을 확인합니다.

하트비트 주제는 소스 클러스터에서 복제됩니다.

대상 클러스터는 주제를 사용하여 확인합니다.

  • 클러스터 간 연결을 관리하는 커넥터가 실행 중입니다.
  • 소스 클러스터를 사용할 수 있음

MirrorMaker 2.0은 MirrorHeartbeatConnector 를 사용하여 이러한 검사를 수행하는 하트비트 를 내보냅니다.

9.3. ACL 규칙 동기화
링크 복사

AclAuthorizer 를 사용하는 경우 브로커에 대한 액세스를 관리하는 ACL 규칙은 원격 주제에도 적용됩니다. 소스 주제를 읽을 수 있는 사용자는 이와 동등한 원격 항목을 읽을 수 있습니다.

참고

OAuth 2.0 인증에서는 이러한 방식으로 원격 항목에 대한 액세스를 지원하지 않습니다.

9.4. MirrorMaker 2.0을 사용하여 Kafka 클러스터 간에 데이터 동기화
링크 복사

MirrorMaker 2.0을 사용하여 구성을 통해 Kafka 클러스터 간에 데이터를 동기화합니다.

이전 버전의 MirrorMaker는 레거시 모드에서 MirrorMaker 2.0을 실행하여 계속 지원됩니다.

구성은 다음을 지정해야 합니다.

  • 각 Kafka 클러스터
  • TLS 인증을 포함하여 각 클러스터에 대한 연결 정보

  • 복제 흐름 및 방향

    • 클러스터 간 클러스터
    • 주제 주제
  • 복제 규칙
  • 커밋된 오프셋 추적 간격

다음 절차에서는 속성 파일에서 구성을 만든 다음 MirrorMaker 스크립트 파일을 사용하여 연결을 설정할 때 속성을 전달하여 MirrorMaker 2.0을 구현하는 방법을 설명합니다.

참고

MirrorMaker 2.0은 Kafka Connect를 사용하여 클러스터 간 데이터를 전송합니다. Kafka는 데이터 복제를 위한 MirrorMaker 싱크 및 소스 커넥터를 제공합니다. MirrorMaker 스크립트 대신 커넥터를 사용하려면 Kafka Connect 클러스터에서 커넥터를 구성해야 합니다. 자세한 내용은 Apache Kafka 설명서를 참조하십시오.

사전 준비 사항

샘플 구성 속성 파일은 ./config/connect-mirror-maker.properties 로 제공됩니다.

사전 요구 사항

  • 복제하려는 각 Kafka 클러스터 노드의 호스트에 AMQ Streams가 설치되어 있어야 합니다.

프로세스

  1. 텍스트 편집기에서 샘플 속성 파일을 열거나 새 파일을 생성하고 각 Kafka 클러스터의 연결 정보 및 복제 흐름을 포함하도록 파일을 편집합니다.

    다음 예제에서는 두 클러스터, cluster-1 및 cluster-2 를 양방향으로 연결하는 구성을 보여줍니다. 클러스터 이름은 클러스터 속성을 통해 구성할 수 있습니다. 

    clusters=cluster-1,cluster-2
    1 
    

cluster-1.bootstrap.servers=CLUSTER-NAME-kafka-bootstrap-PROJECT-NAME:443
    2 
    
cluster-1.security.protocol=SSL
    3 
    
cluster-1.ssl.truststore.password=TRUSTSTORE-NAME
cluster-1.ssl.truststore.location=PATH-TO-TRUSTSTORE/truststore.cluster-1.jks
cluster-1.ssl.keystore.password=KEYSTORE-NAME
cluster-1.ssl.keystore.location=PATH-TO-KEYSTORE/user.cluster-1.p12_

cluster-2.bootstrap.servers=CLUSTER-NAME-kafka-bootstrap-<my-project>:443
    4 
    
cluster-2.security.protocol=SSL
    5 
    
cluster-2.ssl.truststore.password=TRUSTSTORE-NAME
cluster-2.ssl.truststore.location=PATH-TO-TRUSTSTORE/truststore.cluster-2.jks_
cluster-2.ssl.keystore.password=KEYSTORE-NAME
cluster-2.ssl.keystore.location=PATH-TO-KEYSTORE/user.cluster-2.p12_

cluster-1->cluster-2.enabled=true
    6 
    
cluster-1->cluster-2.topics=.*
    7 
    
cluster-2->cluster-1.enabled=true
    8 
    
cluster-2->cluster-1B->C.topics=.*
    9 
    

replication.policy.separator=-
    10 
    
sync.topic.acls.enabled=false
    11 
    
refresh.topics.interval.seconds=60
    12 
    
refresh.groups.interval.seconds=60
    13
    Copy to Clipboard Toggle word wrap
    1
    각 Kafka 클러스터는 별칭으로 식별됩니다.
    2
    부트스트랩 주소 와 포트 443 을 사용하는 cluster-1 에 대한 연결 정보입니다. 두 클러스터 모두 포트 443 을 사용하여 OpenShift 경로를 사용하여 Kafka에 연결합니다.
    3
    ssl. 속성은 cluster-1 에 대한 TLS 구성을 정의합니다.
    4
    cluster-2 에 대한 연결 정보입니다.
    5
    ssl. 속성은 cluster-2 에 대한 TLS 구성을 정의합니다.
    6
    cluster-1 클러스터에서 cluster -2 클러스터로 복제 흐름이 활성화됩니다.
    7
    cluster-1 클러스터에서 cluster -2 클러스터로 모든 주제를 복제합니다.
    8
    cluster-2 클러스터에서 cluster -1 클러스터로 복제 흐름이 활성화됩니다.
    9
    cluster-2 클러스터에서 cluster -1 클러스터로 특정 주제를 복제합니다.
    10
    원격 주제의 이름 변경에 사용되는 구분자를 정의합니다.
    11
    활성화하면 ACL이 동기화된 항목에 적용됩니다. 기본값은 false입니다.
    12
    새 주제를 동기화할지 확인하는 기간입니다.
    13
    새 소비자 그룹이 동기화되는지 확인하는 기간입니다.

  2. OPTION: 필요한 경우 원격 주제의 자동 이름을 재정의하는 정책을 추가합니다. 소스 클러스터 이름이 있는 이름을 보류하는 대신 주제는 원래 이름을 유지합니다.

    이 선택적 설정은 활성/수동 백업 및 데이터 마이그레이션에 사용됩니다. 

    replication.policy.class=io.strimzi.kafka.connect.mirror.IdentityReplicationPolicy
    Copy to Clipboard Toggle word wrap

  3. OPTION: 소비자 그룹 오프셋을 동기화하려면 구성을 추가하여 동기화를 활성화하고 관리합니다. 

    refresh.groups.interval.seconds=60
sync.group.offsets.enabled=true
    1 
    
sync.group.offsets.interval.seconds=60
    2 
    
emit.checkpoints.interval.seconds=60
    3
    Copy to Clipboard Toggle word wrap
    1
    활성/수동 구성의 복구에 유용한 소비자 그룹 오프셋을 동기화하는 선택적 설정입니다. 동기화는 기본적으로 활성화되어 있지 않습니다.
    2
    소비자 그룹 오프셋의 동기화가 활성화된 경우 동기화 빈도를 조정할 수 있습니다.
    3
    오프셋 추적의 검사 빈도를 조정합니다. 오프셋 동기화의 빈도를 변경하는 경우 이러한 검사의 빈도를 조정해야 할 수도 있습니다.

  4. 대상 클러스터에서 Zoo Cryostat 및 Kafka를 시작합니다. 

    su - kafka
/opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap 
    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

  5. 속성 파일에 정의된 클러스터 연결 구성 및 복제 정책으로 MirrorMaker를 시작합니다. 

    /opt/kafka/bin/connect-mirror-maker.sh /config/connect-mirror-maker.properties
    Copy to Clipboard Toggle word wrap

    MirrorMaker는 클러스터 간 연결을 설정합니다.

  6. 각 대상 클러스터에서 주제가 복제되고 있는지 확인합니다. 

    /bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --list
    Copy to Clipboard Toggle word wrap

9.5. 레거시 모드에서 MirrorMaker 2.0 사용
링크 복사

다음 절차에서는 레거시 모드에서 사용하도록 MirrorMaker 2.0을 구성하는 방법을 설명합니다. 레거시 모드는 이전 버전의 MirrorMaker를 지원합니다.

MirrorMaker 스크립트 /opt/kafka/bin/kafka-mirror-maker.sh 는 레거시 모드에서 MirrorMaker 2.0을 실행할 수 있습니다.

중요

Kafka MirrorMaker 1 (문서에서 MirrorMaker 라고도 함)은 Apache Kafka 3.0.0에서 더 이상 사용되지 않으며 Apache Kafka 4.0.0에서 제거됩니다. 그 결과 Kafka MirrorMaker 1도 AMQ Streams에서 더 이상 사용되지 않습니다. Kafka MirrorMaker 1은 Apache Kafka 4.0.0을 채택할 때 AMQ Streams에서 제거됩니다. 대신 MirrorMaker 2.0을 IdentityReplicationPolicy 와 함께 사용합니다.

사전 요구 사항

현재 레거시 버전의 MirrorMaker에서 사용하는 속성 파일이 필요합니다.

  • /opt/kafka/config/consumer.properties
  • /opt/kafka/config/producer.properties

프로세스

  1. MirrorMaker consumer.properties 및 producer.properties 파일을 편집하여 MirrorMaker 2.0 기능을 끕니다.

    예를 들면 다음과 같습니다. 

    replication.policy.class=org.apache.kafka.mirror.LegacyReplicationPolicy
    1 
    

refresh.topics.enabled=false
    2 
    
refresh.groups.enabled=false
emit.checkpoints.enabled=false
emit.heartbeats.enabled=false
sync.topic.configs.enabled=false
sync.topic.acls.enabled=false
    Copy to Clipboard Toggle word wrap
    1
    이전 버전의 mirrorMaker를 에뮬레이션합니다.
    2
    내부 체크포인트 및 하트비트 주제를 포함하여 MirrorMaker 2.0 기능이 비활성화됨

  2. 이전 버전의 MirrorMaker와 함께 사용한 속성 파일을 사용하여 변경 사항을 저장하고 MirrorMaker를 다시 시작하십시오. 

    su - kafka /opt/kafka/bin/kafka-mirror-maker.sh \
--consumer.config /opt/kafka/config/consumer.properties \
--producer.config /opt/kafka/config/producer.properties \
--num.streams=2
    Copy to Clipboard Toggle word wrap

    소비자 속성은 소스 클러스터에 대한 구성을 제공하고 생산자 속성은 대상 클러스터 구성을 제공합니다.

    MirrorMaker는 클러스터 간 연결을 설정합니다.

  3. 대상 클러스터에서 Zoo Cryostat 및 Kafka를 시작합니다. 

    su - kafka
/opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap 
    su - kafka
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

  4. 대상 클러스터의 경우 주제가 복제되고 있는지 확인합니다. 

    /bin/kafka-topics.sh --bootstrap-server <BrokerAddress> --list
    Copy to Clipboard Toggle word wrap

10장. Kafka 클라이언트
링크 복사

kafka-clients JAR 파일에는 Kafka AdminClient API와 함께 Kafka Producer 및 Consumer API가 포함되어 있습니다.

  • Producer API를 사용하면 애플리케이션이 Kafka 브로커에 데이터를 보낼 수 있습니다.
  • Consumer API를 사용하면 애플리케이션이 Kafka 브로커의 데이터를 사용할 수 있습니다.
  • AdminClient API는 주제, 브로커 및 기타 구성 요소를 포함하여 Kafka 클러스터를 관리하는 기능을 제공합니다.

10.1. Kafka 클라이언트를 Maven 프로젝트에 종속성으로 추가
링크 복사

다음 절차에서는 AMQ Streams Java 클라이언트를 Maven 프로젝트에 종속성으로 추가하는 방법을 보여줍니다.

사전 요구 사항

  • 기존 pom.xml 이 있는 Maven 프로젝트입니다.

프로세스

  1. pom.xml 파일의 < repositories > 섹션에 Red Hat Maven 리포지토리를 추가합니다. 

    <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <!-- ... -->

    <repositories>
        <repository>
            <id>redhat-maven</id>
            <url>https://maven.repository.redhat.com/ga/</url>
        </repository>
    </repositories>

    <!-- ... -->

</project>
    Copy to Clipboard Toggle word wrap

  2. pom.xml 파일의 <dependencies > 섹션에 클라이언트를 추가합니다. 

    <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <!-- ... -->

    <dependencies>
        <dependency>
            <groupId>org.apache.kafka</groupId>
            <artifactId>kafka-clients</artifactId>
            <version>2.8.0.redhat-00005</version>
        </dependency>
    </dependencies>

    <!-- ... -->
</project>
    Copy to Clipboard Toggle word wrap
  3. Maven 프로젝트를 빌드합니다.

11장. Kafka Streams API 개요
링크 복사

Kafka Streams API를 사용하면 애플리케이션이 하나 이상의 입력 스트림에서 데이터를 수신하고 매핑, 필터링 또는 조인과 같은 복잡한 작업을 실행하고 결과를 하나 이상의 출력 스트림에 작성할 수 있습니다. 이는 Red Hat Maven 리포지토리에서 사용할 수 있는 kafka-streams JAR 패키지의 일부입니다.

11.1. Kafka Streams API를 Maven 프로젝트에 종속성으로 추가
링크 복사

다음 절차에서는 AMQ Streams Java 클라이언트를 Maven 프로젝트에 종속성으로 추가하는 방법을 보여줍니다.

사전 요구 사항

  • 기존 pom.xml 이 있는 Maven 프로젝트입니다.

프로세스

  1. pom.xml 파일의 < repositories > 섹션에 Red Hat Maven 리포지토리를 추가합니다. 

    <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <!-- ... -->

    <repositories>
        <repository>
            <id>redhat-maven</id>
            <url>https://maven.repository.redhat.com/ga/</url>
        </repository>
    </repositories>

    <!-- ... -->

</project>
    Copy to Clipboard Toggle word wrap

  2. pom.xml 파일의 < dependencies&gt; 섹션에 kafka-streams 를 추가합니다. 

    <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <!-- ... -->

    <dependencies>
        <dependency>
            <groupId>org.apache.kafka</groupId>
            <artifactId>kafka-streams</artifactId>
            <version>2.8.0.redhat-00005</version>
        </dependency>
    </dependencies>

    <!-- ... -->
</project>
    Copy to Clipboard Toggle word wrap
  3. Maven 프로젝트를 빌드합니다.

12장. Kafka Bridge
링크 복사

이 장에서는 Red Hat Enterprise Linux의 AMQ Streams Kafka Bridge에 대한 개요를 제공하고 AMQ Streams와 상호 작용하기 위해 REST API 사용을 시작하는 데 도움이 됩니다. 로컬 환경에서 Kafka 브리지를 시도하려면 이 장의 뒷부분에 있는 12.2절. “Kafka 브리지 빠른 시작” 를 참조하십시오.

추가 리소스

12.1. Kafka 브리지 개요
링크 복사

Kafka 브리지는 HTTP 기반 클라이언트가 Kafka 클러스터와 상호 작용할 수 있는 RESTful 인터페이스를 제공합니다. 클라이언트 애플리케이션에서 Kafka 프로토콜을 해석할 필요 없이 AMQ Streams에 대한 웹 API 연결의 이점을 제공합니다.

API에는 Kafka 클러스터의소비자 및 생산자와 상호 작용하기 위해 엔드포인트를 통해 노출되고 액세스할 수 있는 두 가지 주요 리소스( 소비자 및 주제)가 있습니다. 리소스는 Kafka 브리지에 직접 연결된 소비자 및 생산자가 아닌 Kafka 브리지와만 관련이 있습니다.

HTTP 요청

Kafka 브리지는 다음과 같은 방법으로 Kafka 클러스터에 대한 HTTP 요청을 지원합니다.

  • 메시지를 주제로 보냅니다.
  • 주제에서 메시지를 검색합니다.
  • 주제의 파티션 목록을 검색합니다.
  • 소비자를 생성하고 삭제합니다.
  • 해당 주제에서 메시지를 수신하기 시작할 수 있도록 소비자를 구독합니다.
  • 소비자가 구독한 주제 목록을 검색합니다.
  • 주제에서 소비자를 서브스크립션 해제합니다.
  • 소비자에게 파티션을 할당합니다.
  • 소비자 오프셋 목록을 커밋합니다.
  • 소비자가 첫 번째 또는 마지막 오프셋 위치 또는 지정된 오프셋 위치에서 메시지를 수신하기 시작할 수 있도록 파티션을 찾습니다.

이 메서드는 JSON 응답 및 HTTP 응답 코드 오류 처리를 제공합니다. 메시지는 JSON 또는 바이너리 형식으로 보낼 수 있습니다.

클라이언트는 네이티브 Kafka 프로토콜을 사용해야 하는 요구 사항 없이 메시지를 생성하고 사용할 수 있습니다.

AMQ Streams 설치와 유사하게 Kafka Bridge 파일을 Red Hat Enterprise Linux에 설치할 수 있습니다. 12.1.5절. “Kafka 브리지 아카이브 다운로드”을 참조하십시오.

KafkaBridge 리소스의 호스트 및 포트 구성에 대한 자세한 내용은 12.1.6절. “Kafka 브리지 속성 구성” 을 참조하십시오.

12.1.1. 인증 및 암호화
링크 복사

HTTP 클라이언트와 Kafka 브리지 간의 인증 및 암호화는 아직 지원되지 않습니다. 즉 클라이언트에서 Kafka 브리지로 전송된 요청은 다음과 같습니다.

  • 암호화되지 않으며 HTTPS 대신 HTTP를 사용해야 합니다.
  • 인증 없이 전송됨

Kafka 브리지와 Kafka 클러스터 간에 TLS 또는 SASL 기반 인증을 구성할 수 있습니다.

속성 파일을 통해 인증을 위해 Kafka 브리지를 구성합니다.

12.1.2. Kafka 브릿지 요청
링크 복사

데이터 형식 및 HTTP 헤더를 지정하여 유효한 요청이 Kafka 브리지에 제출되도록 합니다.

API 요청 및 응답 본문은 항상 JSON으로 인코딩됩니다.

12.1.2.1. 콘텐츠 유형 헤더
링크 복사

모든 요청에 대해 Content-Type 헤더를 제출해야 합니다. 유일한 예외는 POST 요청 본문이 비어 있을 때이며, Content-Type 헤더를 추가하면 요청이 실패합니다.

소비자 작업(/consumers 끝점) 및 생산자 작업(/topics 끝점)에는 다른 Content-Type 헤더가 필요합니다.

소비자 작업을 위한 content-Type 헤더

포함된 데이터 형식에 관계없이 요청 본문에 데이터가 포함된 경우 소비자 작업에 대한POST 요청은 다음 Content-Type 헤더를 제공해야 합니다. 

Content-Type: application/vnd.kafka.v2+json
Copy to Clipboard Toggle word wrap

생산자 작업을 위한 content-Type 헤더

생산자 작업을 수행할 때 POST 요청은 생성된 메시지의 포함된 데이터 형식을 지정하는 Content-Type 헤더를 제공해야 합니다. 이는 json 또는 binary 일 수 있습니다.

Expand
표 12.1. 데이터 형식에 대한 content-Type 헤더
포함된 데이터 형식content-Type 헤더

JSON

Content-Type: application/vnd.kafka.json.v2+json

바이너리

content-Type: application/vnd.kafka.binary.v2+json

포함된 데이터 형식은 다음 섹션에 설명된 대로 소비자별로 설정됩니다.

POST 요청에 빈 본문이 있는 경우 Content-Type 을 설정하지 않아야 합니다. 빈 본문을 사용하여 기본값이 있는 소비자를 생성할 수 있습니다.

12.1.2.2. 포함된 데이터 형식
링크 복사

포함된 데이터 형식은 HTTP를 통해 Kafka 브리지를 사용하여 생산자에서 소비자로 전송되는 Kafka 메시지의 형식입니다. 두 가지 임베디드 데이터 형식(JSON 또는 바이너리)이 지원됩니다.

/consumers/groupid 엔드포인트를 사용하여 소비자를 생성할 때 POST 요청 본문은 JSON 또는 바이너리의 포함된 데이터 형식을 지정해야 합니다. 이는 요청 본문의 format 필드에 지정됩니다. 예를 들면 다음과 같습니다. 

{
  "name": "my-consumer",
  "format": "binary",
1 

...
}
Copy to Clipboard Toggle word wrap
1
바이너리 포함된 데이터 형식입니다.

소비자에 대한 포함된 데이터 형식을 지정하지 않으면 바이너리 형식이 설정됩니다.

소비자를 생성할 때 지정된 포함된 데이터 형식은 사용할 Kafka 메시지의 데이터 형식과 일치해야 합니다.

바이너리 포함 데이터 형식을 지정하도록 선택하는 경우 후속 생산자 요청은 요청 본문에 바이너리 데이터를 Base64로 인코딩된 문자열로 제공해야 합니다. 예를 들어 POST 요청을 /topics/topicname 엔드포인트에 수행하여 메시지를 보낼 때 값은 Base64로 인코딩되어야 합니다. 

{
  "records": [
    {
      "key": "my-key",
      "value": "ZWR3YXJkdGhldGhyZWVsZWdnZWRjYXQ="
    },
  ]
}
Copy to Clipboard Toggle word wrap

생산자 요청은 포함된 데이터 형식에 해당하는 Content-Type 헤더(예: Content-Type: application/vnd.kafka.binary.v2+json )도 제공해야 합니다.

12.1.2.3. 메시지 형식
링크 복사

/topics 엔드포인트를 사용하여 메시지를 보낼 때 요청 본문에 메시지 페이로드를 records 매개변수에 입력합니다.

records 매개변수는 다음 선택적 필드를 포함할 수 있습니다.

  • 메시지 키
  • 메시지 값
  • 대상 파티션
  • 메시지 헤더

/topics에 대한 POST 요청의 예

curl -X POST \
  http://localhost:8080/topics/my-topic \
  -H 'content-type: application/vnd.kafka.json.v2+json' \
  -d '{
    "records": [
        {
            "key": "my-key",
            "value": "sales-lead-0001"
            "partition": 2
            "headers": [
              {
                "key": "key1",
                "value": "QXBhY2hlIEthZmthIGlzIHRoZSBib21iIQ=="
1 

              }
            ]
        },
    ]
}'
Copy to Clipboard Toggle word wrap

1
바이너리 형식의 헤더 값과 Base64로 인코딩됩니다.
12.1.2.4. 헤더 수락
링크 복사

소비자를 생성한 후 모든 후속 GET 요청은 다음 형식으로 Accept 헤더를 제공해야 합니다. 

Accept: application/vnd.kafka.embedded-data-format.v2+json
Copy to Clipboard Toggle word wrap

embedded-data-format 은 json 또는 바이너리 입니다.

예를 들어 JSON의 포함된 데이터 형식을 사용하여 구독된 소비자에 대한 레코드를 검색할 때 다음 Accept 헤더를 포함합니다. 

Accept: application/vnd.kafka.json.v2+json
Copy to Clipboard Toggle word wrap

12.1.3. Kafka 브리지의 로거 구성
링크 복사

AMQ Streams Kafka 브릿지를 사용하면 관련 OpenAPI 사양에 정의된 각 작업에 대해 다른 로그 수준을 설정할 수 있습니다.

각 작업에는 브리지가 HTTP 클라이언트에서 요청을 수신하는 해당 API 끝점이 있습니다. 각 끝점에서 로그 수준을 변경하여 들어오고 나가는 HTTP 요청에 대한 보다 세밀한 로깅 정보를 생성할 수 있습니다.

로거는 log4j.properties 파일에 정의되어 있으며 정상 및 준비된 끝점에 대해 다음과 같은 기본 구성이 있습니다. 

log4j.logger.http.openapi.operation.healthy=WARN, out
log4j.additivity.http.openapi.operation.healthy=false
log4j.logger.http.openapi.operation.ready=WARN, out
log4j.additivity.http.openapi.operation.ready=false
Copy to Clipboard Toggle word wrap

다른 모든 작업의 로그 수준은 기본적으로 INFO 로 설정됩니다. 로거는 다음과 같이 포맷됩니다. 

log4j.logger.http.openapi.operation.<operation-id>
Copy to Clipboard Toggle word wrap

여기서 <operation-id >는 특정 작업의 식별자입니다. 다음은 OpenAPI 사양에서 정의한 작업 목록입니다.

  • createConsumer
  • deleteConsumer
  • 서브스크립션
  • 서브스크립션 취소
  • 폴링
  • 할당
  • 커밋
  • 전송
  • sendToPartition
  • seekToBeginning
  • seekToEnd
  • 검색
  • 상태
  • Ready
  • openAPI

12.1.4. Kafka 브리지 API 리소스
링크 복사

REST API 끝점 및 예제 요청 및 응답을 포함한 설명의 전체 목록은 Kafka Bridge API 참조를 참조하십시오.

12.1.5. Kafka 브리지 아카이브 다운로드
링크 복사

AMQ Streams Kafka Bridge의 압축 배포는 Red Hat 웹 사이트에서 다운로드할 수 있습니다.

프로세스

12.1.6. Kafka 브리지 속성 구성
링크 복사

다음 절차에서는 AMQ Streams Kafka 브리지에서 사용하는 Kafka 및 HTTP 연결 속성을 구성하는 방법을 설명합니다.

Kafka 관련 속성에 적절한 접두사를 사용하여 Kafka 브리지를 다른 Kafka 클라이언트로 구성합니다.

  • Kafka. 서버 연결 및 보안과 같은 생산자 및 소비자에 적용되는 일반 구성의 경우
  • 소비자별 구성의 경우 Kafka.consumer.는 소비자에게만 전달됩니다.
  • 생산자별 구성의 경우 Kafka.producer.는 생산자에게만 전달됩니다.

Kafka 클러스터에 대한 HTTP 액세스를 활성화할 뿐만 아니라 HTTP 속성은 CORS(Cross-Origin Resource Sharing)를 통해 Kafka 브릿지에 대한 액세스 제어를 활성화하고 정의하는 기능을 제공합니다. CORS는 브라우저에서 두 개 이상의 원본에서 선택한 리소스에 액세스할 수 있는 HTTP 메커니즘입니다. CORS를 구성하려면 허용된 리소스 원본 및 HTTP 메서드 목록을 정의하여 액세스할 수 있습니다. 요청의 추가 HTTP 헤더 는 Kafka 클러스터에 액세스할 수 있는 원본을 설명합니다.

사전 요구 사항

프로세스

  1. AMQ Streams Kafka Bridge 설치 아카이브와 함께 제공되는 application.properties 파일을 편집합니다.

    속성 파일을 사용하여 Kafka 및 HTTP 관련 속성을 지정하고 분산 추적을 활성화합니다.

    1. Kafka 소비자 및 생산자와 관련된 속성을 포함하여 표준 Kafka 관련 속성을 구성합니다.

      다음을 사용하십시오.

      • Kafka 클러스터에 대한 호스트/포트 연결을 정의하는 Kafka .bootstrap.servers
      • Kafka.producer.acks HTTP 클라이언트에 승인을 제공

      • Kafka.consumer.auto.offset.reset 에서 오프셋의 재설정을 관리하는 방법

        Kafka 속성 구성에 대한 자세한 내용은 Apache Kafka 웹 사이트를참조하십시오.

    2. Kafka 클러스터에 대한 HTTP 액세스를 활성화하도록 HTTP 관련 속성을 구성합니다.

      예를 들면 다음과 같습니다. 

      http.enabled=true
http.host=0.0.0.0
http.port=8080
      1 
      
http.cors.enabled=true
      2 
      
http.cors.allowedOrigins=https://strimzi.io
      3 
      
http.cors.allowedMethods=GET,POST,PUT,DELETE,OPTIONS,PATCH
      4
      Copy to Clipboard Toggle word wrap
      1
      포트 8080에서 수신 대기할 Kafka 브리지의 기본 HTTP 구성입니다.
      2
      CORS를 활성화하려면 true 로 설정합니다.
      3
      쉼표로 구분된 허용된 CORS 원본 목록입니다. URL 또는 Java 정규식을 사용할 수 있습니다.
      4
      CORS에 허용되는 HTTP 메서드의 쉼표로 구분된 목록입니다.

    3. 분산 추적을 활성화하거나 비활성화합니다. 

      bridge.tracing=jaeger
      Copy to Clipboard Toggle word wrap

      속성에서 코드 주석을 제거하여 분산 추적을 활성화합니다.

추가 리소스

12.1.7. Kafka 브리지 설치
링크 복사

Red Hat Enterprise Linux에 AMQ Streams Kafka Bridge를 설치하려면 다음 절차를 따르십시오.

사전 요구 사항

프로세스

  1. 아직 수행하지 않은 경우 AMQ Streams Kafka Bridge 설치 아카이브의 압축을 임의의 디렉터리에 풉니다.

  2. 구성 속성을 매개변수로 사용하여 Kafka Bridge 스크립트를 실행합니다.

    예를 들면 다음과 같습니다. 

    ./bin/kafka_bridge_run.sh --config-file=_path_/configfile.properties
    Copy to Clipboard Toggle word wrap

  3. 로그에 설치에 성공했는지 확인합니다. 

    HTTP-Kafka Bridge started and listening on port 8080
HTTP-Kafka Bridge bootstrap servers localhost:9092
    Copy to Clipboard Toggle word wrap

12.2. Kafka 브리지 빠른 시작
링크 복사

이 빠른 시작을 사용하여 Red Hat Enterprise Linux에서 AMQ Streams Kafka 브리지를 사용해 보십시오. 다음을 수행하는 방법을 배울 수 있습니다.

  • Kafka 브리지 설치
  • Kafka 클러스터의 주제 및 파티션에 메시지 생성
  • Kafka 브리지 소비자 생성
  • 소비자가 주제에 가입하고 생성한 메시지 검색과 같은 기본 소비자 작업 수행

이 빠른 시작에서는 HTTP 요청이 터미널에 복사하여 붙여넣을 수 있는 curl 명령으로 포맷됩니다.

사전 요구 사항이 있는지 확인한 다음 이 장에 제공된 순서대로 작업을 수행합니다.

데이터 형식 정보

이 빠른 시작에서는 바이너리가 아닌 JSON 형식으로 메시지를 생성하고 사용합니다. 예제 요청에 사용되는 데이터 형식 및 HTTP 헤더에 대한 자세한 내용은 12.1.1절. “인증 및 암호화” 을 참조하십시오.

빠른 시작을 위한 사전 요구 사항

12.2.1. 로컬로 Kafka 브리지 배포
링크 복사

AMQ Streams Kafka Bridge 인스턴스를 호스트에 배포합니다. 설치 아카이브와 함께 제공된 application.properties 파일을 사용하여 기본 구성 설정을 적용합니다.

프로세스

  1. application.properties 파일을 열고 기본 HTTP 관련 설정이 정의되어 있는지 확인합니다. 

    http.enabled=true
http.host=0.0.0.0
http.port=8080
    Copy to Clipboard Toggle word wrap

    이렇게 하면 포트 8080에서 요청을 수신 대기하도록 Kafka 브리지가 구성됩니다.

  2. 구성 속성을 매개변수로 사용하여 Kafka Bridge 스크립트를 실행합니다. 

    ./bin/kafka_bridge_run.sh --config-file=<path>/application.properties
    Copy to Clipboard Toggle word wrap

다음에 수행할 작업

12.2.2. 주제 및 파티션에 메시지 생성
링크 복사

주제 끝점을 사용하여 JSON 형식의 항목에 메시지를 생성합니다.

다음과 같이 요청 본문에 메시지에 대한 대상 파티션을 지정할 수 있습니다. 파티션 끝점은 모든 메시지의 단일 대상 파티션을 경로 매개 변수로 지정하는 대체 방법을 제공합니다.

프로세스

  1. kafka-topics.sh 유틸리티를 사용하여 Kafka 주제를 생성합니다. 

    bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic bridge-quickstart-topic --partitions 3 --replication-factor 1 --config retention.ms=7200000 --config segment.bytes=1073741824
    Copy to Clipboard Toggle word wrap

    파티션을 세 개 지정합니다.

  2. 주제가 생성되었는지 확인합니다. 

    bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic bridge-quickstart-topic
    Copy to Clipboard Toggle word wrap

  3. Kafka 브리지를 사용하여 생성한 항목에 세 개의 메시지를 생성합니다. 

    curl -X POST \
  http://localhost:8080/topics/bridge-quickstart-topic \
  -H 'content-type: application/vnd.kafka.json.v2+json' \
  -d '{
    "records": [
        {
            "key": "my-key",
            "value": "sales-lead-0001"
        },
        {
            "value": "sales-lead-0002",
            "partition": 2
        },
        {
            "value": "sales-lead-0003"
        }
    ]
}'
    Copy to Clipboard Toggle word wrap
    • sales-lead-0001 은 키의 해시를 기반으로 파티션으로 전송됩니다.
    • sales-lead-0002 는 파티션 2로 직접 전송됩니다.
    • sales-lead-0003 은 라운드 로빈 방법을 사용하여 bridge-quickstart-topic 주제의 파티션으로 전송됩니다.

  4. 요청이 성공하면 Kafka 브리지는 200 (OK) 코드 및 application/vnd.kafka.v2+json 의 content-type 헤더와 함께 오프셋 배열을 반환합니다. 각 메시지에 대해 오프셋 배열은 다음을 설명합니다.

    • 메시지가 전송된 파티션

    • 파티션의 현재 메시지 오프셋

      응답 예

      #...
{
  "offsets":[
    {
      "partition":0,
      "offset":0
    },
    {
      "partition":2,
      "offset":0
    },
    {
      "partition":0,
      "offset":1
    }
  ]
}
      Copy to Clipboard Toggle word wrap

다음에 수행할 작업

주제 및 파티션에 메시지를 생성한 후 Kafka Bridge 소비자를 생성합니다.

추가 리소스

12.2.3. Kafka 브리지 소비자 생성
링크 복사

Kafka 클러스터에서 소비자 작업을 수행하려면 먼저 소비자 끝점을 사용하여 소비자를 생성해야 합니다. 소비자를 Kafka 브리지 소비자 라고 합니다.

프로세스

  1. bridge-quickstart-consumer-group 이라는 새 소비자 그룹에 Kafka 브리지 소비자를 생성합니다. 

    curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group \
  -H 'content-type: application/vnd.kafka.v2+json' \
  -d '{
    "name": "bridge-quickstart-consumer",
    "auto.offset.reset": "earliest",
    "format": "json",
    "enable.auto.commit": false,
    "fetch.min.bytes": 512,
    "consumer.request.timeout.ms": 30000
  }'
    Copy to Clipboard Toggle word wrap
    • 소비자의 이름은 bridge-quickstart-consumer 로 지정되며 포함된 데이터 형식은 json 으로 설정됩니다.

    • enable.auto.commit 설정은 false 이므로 소비자는 로그에 오프셋을 자동으로 커밋하지 않습니다. 이 빠른 시작의 뒷부분에서 오프셋을 수동으로 커밋합니다.

      참고

      요청 본문에 소비자 이름을 지정하지 않으면 Kafka Bridge에서 임의의 소비자 이름을 생성합니다.

      요청이 성공하면 Kafka 브리지는 200 (OK) 코드와 함께 응답 본문의 소비자 ID(instance_id) 및 기본 URL(base_uri)을 반환합니다.

      응답 예

      #...
{
  "instance_id": "bridge-quickstart-consumer",
  "base_uri":"http://<bridge-name>-bridge-service:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer"
}
      Copy to Clipboard Toggle word wrap

  2. 이 빠른 시작의 다른 소비자 작업에 사용할 기본 URL(base_uri)을 복사합니다.

다음에 수행할 작업

이제 Kafka 브리지 소비자를 생성했으므로 주제를 구독할 수 있습니다.

추가 리소스

12.2.4. Kafka 브리지 소비자 등록
링크 복사

서브스크립션 엔드포인트를 사용하여 Kafka 브리지 소비자를 하나 이상의 항목에 등록합니다. 가입되면 소비자가 주제로 생성된 모든 메시지를 수신하기 시작합니다.

프로세스

  • 이전에 생성한 bridge-quickstart-topic 항목에 소비자를 구독하면 메시지를 주제 및 파티션에 유도합니다. 

    curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/subscription \
  -H 'content-type: application/vnd.kafka.v2+json' \
  -d '{
    "topics": [
        "bridge-quickstart-topic"
    ]
}'
    Copy to Clipboard Toggle word wrap

    주제 배열에는 위에 표시된 대로 단일 주제 또는 여러 주제가 포함될 수 있습니다. 일반 표현식과 일치하는 여러 항목에 소비자를 서브스크립션하려면 주제 배열 대신 topic_pattern 문자열을 사용할 수 있습니다.

    요청이 성공하면 Kafka 브리지는 204 No Content 코드만 반환합니다.

다음에 수행할 작업

Kafka Bridge 소비자를 항목에 등록한 후 소비자 에서 메시지를 검색할 수 있습니다.

추가 리소스

12.2.5. Kafka 브리지 소비자에서 최신 메시지 검색
링크 복사

레코드 끝점에서 데이터를 요청하여 Kafka Bridge 소비자에서 최신 메시지를 검색합니다. 프로덕션에서 HTTP 클라이언트는 이 끝점을 루프에서 반복적으로 호출할 수 있습니다.

프로세스

  1. 주제 및 파티션에 대한 메시지 전달에 설명된 대로 Kafka Bridge 소비자에 추가 메시지를 생성합니다.

  2. GET 요청을 레코드 끝점에 제출합니다. 

    curl -X GET http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/records \
  -H 'accept: application/vnd.kafka.json.v2+json'
    Copy to Clipboard Toggle word wrap

    Kafka Bridge 소비자를 생성하고 구독하면 첫 번째 GET 요청이 빈 응답을 반환하므로 폴링 작업에서 파티션을 재조정 프로세스를 트리거합니다.

  3. 두 단계를 반복하여 Kafka 브리지 소비자에서 메시지를 검색합니다.

    Kafka Bridge는 200 (OK) 코드와 함께 응답 본문에 있는 주제 이름, 키, 값, 파티션 및 오프셋 function을 설명하는 messages의 배열을 반환합니다. 메시지는 기본적으로 최신 오프셋에서 검색됩니다. 

    HTTP/1.1 200 OK
content-type: application/vnd.kafka.json.v2+json
#...
[
  {
    "topic":"bridge-quickstart-topic",
    "key":"my-key",
    "value":"sales-lead-0001",
    "partition":0,
    "offset":0
  },
  {
    "topic":"bridge-quickstart-topic",
    "key":null,
    "value":"sales-lead-0003",
    "partition":0,
    "offset":1
  },
#...
    Copy to Clipboard Toggle word wrap
    참고

    빈 응답이 반환되면 주제 및 파티션에 대한 메시지 전달에 설명된 대로 소비자에 더 많은 레코드를 생성한 다음 메시지를 다시 검색해 보십시오.

다음에 수행할 작업

Kafka 브리지 소비자에서 메시지를 검색한 후 로그에 오프셋을 커밋합니다.

추가 리소스

12.2.6. 로그에 오프셋 커밋
링크 복사

오프셋 끝점을 사용하여 Kafka Bridge 소비자가 수신한 모든 메시지의 로그에 오프셋을 수동으로 커밋합니다. 이전에 생성한 Kafka 브리지 소비자 생성 에서 enable.auto.commit 설정을 false 로 사용하여 구성되었기 때문에 이 작업이 필요합니다.

프로세스

  • bridge-quickstart-consumer:의 로그에 대한 커밋 오프셋 

    curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/offsets
    Copy to Clipboard Toggle word wrap

    요청 본문이 제출되지 않으므로 소비자가 수신한 모든 레코드에 대해 오프셋이 커밋됩니다. 또는 요청 본문에 오프셋을 커밋할 주제와 파티션을 지정하는 배열(OffsetCommitSeekList)이 포함될 수 있습니다.

    요청이 성공하면 Kafka 브리지는 204 No Content 코드만 반환합니다.

다음에 수행할 작업

로그에 오프셋을 커밋한 후 오프셋을 찾기 위해 끝점을 시도합니다.

추가 리소스

12.2.7. 파티션 오프셋 검색
링크 복사

위치 끝점을 사용하여 특정 오프셋에서 파티션에 대한 메시지를 검색한 다음 최신 오프셋에서 메시지를 검색하도록 Kafka 브리지 소비자를 구성합니다. 이를 Apache Kafka에서 검색 작업이라고 합니다.

프로세스

  1. quickstart-bridge-topic 주제의 파티션 0에 대한 특정 오프셋을 찾습니다. 

    curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/positions \
  -H 'content-type: application/vnd.kafka.v2+json' \
  -d '{
    "offsets": [
        {
            "topic": "bridge-quickstart-topic",
            "partition": 0,
            "offset": 2
        }
    ]
}'
    Copy to Clipboard Toggle word wrap

    요청이 성공하면 Kafka 브리지는 204 No Content 코드만 반환합니다.

  2. GET 요청을 레코드 끝점에 제출합니다. 

    curl -X GET http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/records \
  -H 'accept: application/vnd.kafka.json.v2+json'
    Copy to Clipboard Toggle word wrap

    Kafka 브리지는 원하는 오프셋에서 메시지를 반환합니다.

  3. 동일한 파티션의 마지막 오프셋을 찾아 기본 메시지 검색 동작을 복원합니다. 이번에는 위치/엔드 엔드포인트를 사용합니다. 

    curl -X POST http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer/positions/end \
  -H 'content-type: application/vnd.kafka.v2+json' \
  -d '{
    "partitions": [
        {
            "topic": "bridge-quickstart-topic",
            "partition": 0
        }
    ]
}'
    Copy to Clipboard Toggle word wrap

    요청이 성공하면 Kafka 브리지는 또 다른 204 No Content 코드를 반환합니다.

참고

position/beginning 끝점을 사용하여 하나 이상의 파티션에 대한 첫 번째 오프셋을 검색할 수도 있습니다.

다음에 수행할 작업

이 빠른 시작에서는 AMQ Streams Kafka 브리지를 사용하여 Kafka 클러스터에서 몇 가지 일반적인 작업을 수행했습니다. 이제 이전에 생성한 Kafka 브리지 소비자를 삭제할 수 있습니다.

추가 리소스

12.2.8. Kafka 브리지 소비자 삭제
링크 복사

마지막으로 이 빠른 시작 전체에서 사용한 Kafa Bridge 소비자를 삭제합니다.

프로세스

  • 인스턴스 엔드포인트에 DELETE 요청을 전송하여 Kafka 브리지 소비자를 삭제합니다. 

    curl -X DELETE http://localhost:8080/consumers/bridge-quickstart-consumer-group/instances/bridge-quickstart-consumer
    Copy to Clipboard Toggle word wrap

    요청이 성공하면 Kafka 브리지는 204 No Content 코드만 반환합니다.

추가 리소스

13장. Kerberos(GSSAPI) 인증 사용
링크 복사

AMQ Streams는 Kafka 클러스터에 대한 보안 SSO(Single Sign-On) 액세스를 위해 Kerberos(GSSAPI) 인증 프로토콜 사용을 지원합니다. GSSAPI는 Kerberos 기능을 위한 API 래퍼로, 기본 구현 변경 사항에서 애플리케이션을 격리합니다.

Kerberos는 대칭 암호화 및 신뢰할 수 있는 타사인 KDC(Kerberos Key Distribution Centre)를 사용하여 클라이언트와 서버가 서로 인증할 수 있는 네트워크 인증 시스템입니다.

13.1. Kerberos(GSSAPI) 인증을 사용하도록 AMQ Streams 설정
링크 복사

다음 절차에서는 Kafka 클라이언트가 Kerberos(GSSAPI) 인증을 사용하여 Kafka 및 Zoo Cryostat에 액세스할 수 있도록 AMQ Streams를 구성하는 방법을 보여줍니다.

이 절차에서는 Kerberos krb5 리소스 서버가 Red Hat Enterprise Linux 호스트에 설정되어 있다고 가정합니다.

이 절차에서는 예제를 사용하여 다음을 구성하는 방법을 보여줍니다.

  1. 서비스 주체
  2. Kerberos 로그인을 사용하는 Kafka 브로커
  3. Kerberos 로그인을 사용하는 Zookeeper
  4. Kerberos 인증을 사용하여 Kafka에 액세스할 수 있는 생산자 및 소비자 클라이언트

지침은 생산자 및 소비자 클라이언트에 대한 추가 구성으로 단일 호스트에 단일 Zoo Cryostat 및 Kafka 설치에 대해 설정된 Kerberos를 설명합니다.

사전 요구 사항

Kerberos 자격 증명을 인증하고 인증하도록 Kafka 및 Zoo Cryostat를 구성하려면 다음이 필요합니다.

  • Kerberos 서버에 액세스
  • 각 Kafka 브로커 호스트의 Kerberos 클라이언트

Kerberos 서버 설정 단계에 대한 자세한 내용 및 브로커 호스트에 클라이언트를 보려면 RHEL 설정 구성의 예제 Kerberos 를 참조하십시오.

Kerberos를 배포하는 방법은 운영 체제에 따라 다릅니다. Red Hat Enterprise Linux에서 Kerberos를 설정할 때 IdM(Identity Management)을 사용하는 것이 좋습니다. Oracle 또는 IBM JDK 사용자는 JCE(Java Cryptography Extension)를 설치해야 합니다.

인증을 위한 서비스 주체 추가

Kerberos 서버에서 Zoo Cryostat, Kafka 브로커 및 Kafka 생산자 및 소비자 클라이언트에 대한 서비스 주체(사용자)를 생성합니다.

서비스 주체는 SERVICE-NAME/FULLY-QUALIFIED-HOST-NAME@DOMAIN-REALM 양식을 사용해야 합니다.

  1. Kerberos KDC를 통해 주 키를 저장하는 keytab과 서비스 주체를 생성합니다.

    예를 들면 다음과 같습니다.

    • zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM
    • kafka/node1.example.redhat.com@EXAMPLE.REDHAT.COM
    • producer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM

    • consumer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM

      Zoo Cryostat 서비스 주체는 Kafka config/server.properties 파일의 zookeeper.connect 구성과 동일한 호스트 이름을 사용해야 합니다. 

      zookeeper.connect=node1.example.redhat.com:2181
      Copy to Clipboard Toggle word wrap

      호스트 이름이 동일하지 않으면 localhost 가 사용되고 인증이 실패합니다.

  2. 호스트에 디렉터리를 만들고 keytab 파일을 추가합니다.

    예를 들면 다음과 같습니다. 

    /opt/kafka/krb5/zookeeper-node1.keytab
/opt/kafka/krb5/kafka-node1.keytab
/opt/kafka/krb5/kafka-producer1.keytab
/opt/kafka/krb5/kafka-consumer1.keytab
    Copy to Clipboard Toggle word wrap

  3. kafka 사용자가 디렉터리에 액세스할 수 있는지 확인합니다. 

    chown kafka:kafka -R /opt/kafka/krb5
    Copy to Clipboard Toggle word wrap
Kerberos 로그인을 사용하도록 Zoo Cryostat 구성

Zookeeper를 위해 이전에 생성된 사용자 주체 및 키탭을 사용하여 인증에 Kerberos KDC(Key Distribution Center)를 사용하도록 Zoo Cryostat를 구성합니다.

  1. opt/kafka/config/jaas.conf 파일을 생성하거나 수정하여 Zoo Cryostat 클라이언트 및 서버 작업을 지원합니다. 

    Client {
    com.sun.security.auth.module.Krb5LoginModule required debug=true
    useKeyTab=true
    1 
    
    storeKey=true
    2 
    
    useTicketCache=false
    3 
    
    keyTab="/opt/kafka/krb5/zookeeper-node1.keytab"
    4 
    
    principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
    5 
    
};

Server {
    com.sun.security.auth.module.Krb5LoginModule required debug=true
    useKeyTab=true
    storeKey=true
    useTicketCache=false
    keyTab="/opt/kafka/krb5/zookeeper-node1.keytab"
    principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
};

QuorumServer {
    com.sun.security.auth.module.Krb5LoginModule required debug=true
    useKeyTab=true
    storeKey=true
    keyTab="/opt/kafka/krb5/zookeeper-node1.keytab"
    principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
};

QuorumLearner {
    com.sun.security.auth.module.Krb5LoginModule required debug=true
    useKeyTab=true
    storeKey=true
    keyTab="/opt/kafka/krb5/zookeeper-node1.keytab"
    principal="zookeeper/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
};
    Copy to Clipboard Toggle word wrap
    1
    키탭에서 기본 키를 가져오려면 true 로 설정합니다.
    2
    기본 키를 저장하려면 true 로 설정합니다.
    3
    티켓 캐시에서 티켓 부여 티켓(TGT)을 받으려면 true 로 설정합니다.
    4
    keyTab 속성은 Kerberos KDC에서 복사한 키탭 파일의 위치를 가리킵니다. 위치와 파일은 kafka 사용자가 읽을 수 있어야 합니다.
    5
    principal 속성은 SERVICE-NAME/FULLY-QUALIFIED-HOST-NAME@DOMAIN-NAME 형식을 따르는 KDC 호스트에서 생성된 정규화된 주체 이름과 일치하도록 구성됩니다.

  2. 업데이트된 JAAS 구성을 사용하도록 opt/kafka/config/zookeeper.properties 를 편집합니다. 

    # ...

requireClientAuthScheme=sasl
jaasLoginRenew=3600000
    1 
    
kerberos.removeHostFromPrincipal=false
    2 
    
kerberos.removeRealmFromPrincipal=false
    3 
    
quorum.auth.enableSasl=true
    4 
    
quorum.auth.learnerRequireSasl=true
    5 
    
quorum.auth.serverRequireSasl=true
quorum.auth.learner.loginContext=QuorumLearner
    6 
    
quorum.auth.server.loginContext=QuorumServer
quorum.auth.kerberos.servicePrincipal=zookeeper/_HOST
    7 
    
quorum.cnxn.threads.size=20
    Copy to Clipboard Toggle word wrap
    1
    로그인 갱신 빈도를 밀리초 단위로 제어하며 티켓 갱신 간격에 맞게 조정할 수 있습니다. 기본값은 1시간입니다.
    2
    호스트 이름이 로그인 주체 이름의 일부로 사용되는지 여부를 지정합니다. 클러스터의 모든 노드에 단일 키탭을 사용하는 경우 true 로 설정됩니다. 그러나 문제 해결을 위해 각 브로커 호스트에 대해 별도의 keytab과 정규화된 주체를 생성하는 것이 좋습니다.
    3
    Kerberos 협상의 주체 이름에서 영역 이름이 제거되는지 여부를 제어합니다. 이 설정을 false 로 설정하는 것이 좋습니다.
    4
    Zoo Cryostat 서버 및 클라이언트에 대한 SASL 인증 메커니즘을 활성화합니다.
    5
    RequireSasl 속성은 마스터 선택과 같은 쿼럼 이벤트에 SASL 인증이 필요한지 여부를 제어합니다.
    6
    loginContext 속성은 지정된 구성 요소의 인증 구성에 사용되는 JAAS 구성에서 로그인 컨텍스트의 이름을 식별합니다. loginContext 이름은 opt/kafka/config/jaas.conf 파일의 관련 섹션 이름에 해당합니다.
    7
    식별에 사용되는 보안 주체 이름을 구성하는 데 사용할 이름 지정 규칙을 제어합니다.Controls the naming convention to be used to form the principal name used for identification. 자리 표시자 _HOST 는 런타임 시 server.1 속성에 정의된 호스트 이름으로 자동으로 확인됩니다.

  3. JVM 매개변수로 Zoo Cryostat를 시작하여 Kerberos 로그인 구성을 지정합니다. 

    su - kafka
export EXTRA_ARGS="-Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
    Copy to Clipboard Toggle word wrap

    기본 서비스 이름( Zookeeper )을 사용하지 않는 경우 -Dzookeeper.sasl.client.username=NAME 매개변수를 사용하여 이름을 추가합니다.

    참고

    /etc/krb5.conf 위치를 사용하는 경우 Zoo Cryostat, Kafka 또는 Kafka 생산자 및 소비자를 시작할 때 -Djava.security.krb5.conf=/etc/krb5.conf 를 지정할 필요가 없습니다.

Kerberos 로그인을 사용하도록 Kafka 브로커 서버 구성

이전에 kafka 용으로 생성된 사용자 주체 및 키탭을 사용하여 인증에 KDC(Kerberos Key Distribution Center)를 사용하도록 Kafka를 구성합니다.

  1. 다음 요소를 사용하여 opt/kafka/config/jaas.conf 파일을 수정합니다. 

    KafkaServer {
    com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    storeKey=true
    keyTab="/opt/kafka/krb5/kafka-node1.keytab"
    principal="kafka/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
};
KafkaClient {
    com.sun.security.auth.module.Krb5LoginModule required debug=true
    useKeyTab=true
    storeKey=true
    useTicketCache=false
    keyTab="/opt/kafka/krb5/kafka-node1.keytab"
    principal="kafka/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
};
    Copy to Clipboard Toggle word wrap

  2. 리스너가 SASL/GSSAPI 로그인을 사용하도록 config/server.properties 파일에서 리스너 구성을 수정하여 Kafka 클러스터에서 각 브로커를 구성합니다.

    SASL 프로토콜을 리스너의 보안 프로토콜 맵에 추가하고 원하지 않는 프로토콜을 제거합니다.

    예를 들면 다음과 같습니다. 

    # ...
broker.id=0
# ...
listeners=SECURE://:9092,REPLICATION://:9094
    1 
    
inter.broker.listener.name=REPLICATION
# ...
listener.security.protocol.map=SECURE:SASL_PLAINTEXT,REPLICATION:SASL_PLAINTEXT
    2 
    
# ..
sasl.enabled.mechanisms=GSSAPI
    3 
    
sasl.mechanism.inter.broker.protocol=GSSAPI
    4 
    
sasl.kerberos.service.name=kafka
    5 
    
...
    Copy to Clipboard Toggle word wrap
    1
    두 개의 리스너: 클라이언트와의 범용 통신을 위한 보안 리스너( communication을 위해 TLS 지원) 및 브루커 간 통신을 위한 복제 리스너가 구성됩니다.
    2
    TLS 지원 리스너의 경우 프로토콜 이름은 SASL_PLAINTEXT입니다. TLS 지원 커넥터의 경우 프로토콜 이름은 SASL_PLAINTEXT입니다. SSL이 필요하지 않은 경우 ssl.* 속성을 제거할 수 있습니다.
    3
    Kerberos 인증을 위한 SASL 메커니즘은 GSSAPI 입니다.
    4
    브랜드 간 통신을 위한 Kerberos 인증.
    5
    인증 요청에 사용되는 서비스의 이름은 동일한 Kerberos 구성을 사용하는 다른 서비스와 구별하기 위해 지정됩니다.

  3. JVM 매개변수를 사용하여 Kafka 브로커를 시작하여 Kerberos 로그인 구성을 지정합니다. 

    su - kafka
export KAFKA_OPTS="-Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=/opt/kafka/config/jaas.conf"; /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

    브로커 및 Zoo Cryostat 클러스터가 이전에 구성되어 Kerberos 기반 인증 시스템으로 작업하는 경우 Zoo Cryostat 및 브로커 클러스터를 시작하고 로그에서 구성 오류를 확인할 수 있습니다.

    브로커 및 Zookeeper 인스턴스를 시작한 후 이제 Kerberos 인증을 위해 클러스터가 구성됩니다.

Kerberos 인증을 사용하도록 Kafka 생산자 및 소비자 클라이언트 구성

producer1 및 consumer1 을 위해 이전에 생성된 사용자 주체 및 keytab을 사용하여 인증에 Kerberos KMS(Key Distribution Center)를 사용하도록 Kafka 생산자 및 소비자 클라이언트를 구성합니다.

  1. Kerberos 구성을 생산자 또는 소비자 구성 파일에 추가합니다.

    예를 들면 다음과 같습니다.

    /opt/kafka/config/producer.properties

    # ...
sasl.mechanism=GSSAPI
    1 
    
security.protocol=SASL_PLAINTEXT
    2 
    
sasl.kerberos.service.name=kafka
    3 
    
sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
    4 
    
    useKeyTab=true  \
    useTicketCache=false \
    storeKey=true  \
    keyTab="/opt/kafka/krb5/producer1.keytab" \
    principal="producer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
# ...
    Copy to Clipboard Toggle word wrap

    1
    Kerberos(GSSAPI) 인증을 위한 구성
    2
    Kerberos는 SASL 일반 텍스트(사용자 이름/암호) 보안 프로토콜을 사용합니다.
    3
    Kerberos KDC에 구성된 Kafka의 서비스 주체(사용자)입니다.
    4
    jaas.conf 에 정의된 것과 동일한 속성을 사용하는 JAAS 구성

    /opt/kafka/config/consumer.properties

    # ...
sasl.mechanism=GSSAPI
security.protocol=SASL_PLAINTEXT
sasl.kerberos.service.name=kafka
sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
    useKeyTab=true  \
    useTicketCache=false \
    storeKey=true  \
    keyTab="/opt/kafka/krb5/consumer1.keytab" \
    principal="consumer1/node1.example.redhat.com@EXAMPLE.REDHAT.COM";
# ...
    Copy to Clipboard Toggle word wrap

  2. 클라이언트를 실행하여 Kafka 브로커에서 메시지를 보내고 받을 수 있는지 확인합니다.

    생산자 클라이언트: 

    export KAFKA_HEAP_OPTS="-Djava.security.krb5.conf=/etc/krb5.conf -Dsun.security.krb5.debug=true"; /opt/kafka/bin/kafka-console-producer.sh --producer.config /opt/kafka/config/producer.properties  --topic topic1 --bootstrap-server node1.example.redhat.com:9094
    Copy to Clipboard Toggle word wrap

    소비자 클라이언트: 

    export KAFKA_HEAP_OPTS="-Djava.security.krb5.conf=/etc/krb5.conf -Dsun.security.krb5.debug=true"; /opt/kafka/bin/kafka-console-consumer.sh --consumer.config /opt/kafka/config/consumer.properties  --topic topic1 --bootstrap-server node1.example.redhat.com:9094
    Copy to Clipboard Toggle word wrap

추가 리소스

14장. 클러스터 재조정을 위한 cruise Control
링크 복사

중요

클러스터 재조정을 위한 크루즈 컨트롤은 기술 프리뷰 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. Red Hat은 프로덕션 환경에서 기술 프리뷰 기능을 구현하는 것을 권장하지 않습니다. 이 기술 프리뷰 기능을 통해 향후 제품 혁신에 조기에 액세스할 수 있으므로 개발 프로세스 중에 기능을 테스트하고 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

Cruise Control 을 AMQ Streams 클러스터에 배포하고 이를 사용하여 Kafka 브로커 간에 부하를 재조정할 수 있습니다.

cruise Control은 클러스터 워크로드 모니터링, 사전 정의된 제약 조건에 따라 클러스터 재조정, 예외 감지 및 수정과 같은 Kafka 작업을 자동화하기 위한 오픈 소스 시스템입니다. 4가지 구성 요소(Load Monitor, Analyzer, Anomaly Detector, Executor) 및 REST API로 구성됩니다.

AMQ Streams 및 Cruise Control이 Red Hat Enterprise Linux에 배포되면 Cruise Control REST API를 통해 Cruise Control 기능에 액세스할 수 있습니다. 지원되는 기능은 다음과 같습니다.

  • 최적화 목표 및 용량 제한구성

  • /rebalance 끝점을 사용하여 다음을 수행합니다.

    • 최적화 제안을 생성하십시오. 예행 실행으로, 구성된 최적화 목표 또는 요청 매개변수로 제공된 사용자 제공 목표에 따라
    • Kafka 클러스터를 재조정하기 위한 최적화 제안을 시작합니다.
  • /user_tasks 끝점을 사용하여 활성 리밸런스 작업의 진행 상황 확인
  • /stop_proposal_execution 끝점을 사용하여 활성 리밸런스 작업 중지

다른 Cruise Control 기능은 현재 이상적으로 감지, 알림, 쓰기 사용자 지정 목표, 주제 복제 요소 변경을 포함하여 현재 지원되지 않습니다. 웹 UI 구성 요소(Cruise Control Frontend)는 지원되지 않습니다.

Red Hat Enterprise Linux의 AMQ Streams에 대한 크루즈 컨트롤은 별도의 압축 배포로 제공됩니다. 자세한 내용은 14.2절. “Cruise Control 아카이브 다운로드”의 내용을 참조하십시오.

14.1. Cruise Control을 사용하는 이유는 무엇입니까?
링크 복사

크루즈 컨트롤은 브로커 전체에서 보다 균등하게 균형 잡힌 워크로드를 사용하여 효율적인 Kafka 클러스터를 실행하는 데 필요한 시간과 노력을 줄일 수 있습니다.

일반적인 클러스터는 시간이 지남에 따라 균등하게 로드할 수 있습니다. 대량의 메시지 트래픽을 처리하는 파티션은 사용 가능한 브로커에 균등하게 분산될 수 있습니다. 클러스터를 재조정하려면 관리자가 브로커의 부하를 모니터링하고 사용 중인 파티션을 예비 용량이 있는 브로커에 수동으로 다시 할당해야 합니다.

cruise Control은 이 클러스터 재조정 프로세스를 자동화합니다. CPU, 디스크 및 네트워크 로드를 기반으로 리소스 사용률의 워크로드 모델을 구성합니다. 구성 가능한 최적화 목표 세트를 사용하여 Cruise Control에 균형 있는 파티션 할당에 대한 예행 최적화 제안을 생성하도록 지시할 수 있습니다.

시험 실행 최적화 제안을 검토한 후 Cruise Control에 해당 제안에 따라 클러스터 재조정을 시작하거나 새로운 제안을 생성하도록 지시할 수 있습니다.

클러스터 재조정 작업이 완료되면 브로커가 더 효과적으로 사용되며 Kafka 클러스터의 부하가 균등하게 분산됩니다.

추가 리소스

14.2. Cruise Control 아카이브 다운로드
링크 복사

Red Hat Enterprise Linux에서 Cruise Control for AMQ Streams의 압축 배포는 Red Hat 고객 포털에서 다운로드할 수 있습니다.

프로세스

  1. Red Hat Customer Portal 에서 Red Hat AMQ Streams Cruise Control 아카이브의 최신 버전을 다운로드합니다.

  2. /opt/cruise-control 디렉토리를 만듭니다. 

    sudo mkdir /opt/cruise-control
    Copy to Clipboard Toggle word wrap

  3. Cruise Control ZIP 파일의 내용을 새 디렉터리에 추출합니다. 

    unzip amq-streams-y.y.y-cruise-control-bin.zip -d /opt/cruise-control
    Copy to Clipboard Toggle word wrap

  4. /opt/cruise-control 디렉터리의 소유권을 kafka 사용자로 변경합니다. 

    sudo chown -R kafka:kafka /opt/cruise-control
    Copy to Clipboard Toggle word wrap

14.3. Cruise Control Metrics Reporter 배포
링크 복사

Cruise Control을 시작하기 전에 제공된 Cruise Control Metrics Reporter를 사용하도록 Kafka 브로커를 구성해야 합니다.

런타임 시 로드될 때 Metrics Reporter는 자동으로 생성된 세 가지 주제 중 하나인 __CruiseControlMetrics 주제로 지표를 보냅니다. 크루즈 컨트롤은 이러한 메트릭을 사용하여 워크로드 모델을 생성 및 업데이트하고 최적화 제안을 계산합니다.

사전 요구 사항

프로세스

Kafka 클러스터의 각 브로커와 한 번에 하나씩 다음을 수행합니다.

  1. Kafka 브로커를 중지합니다. 

    /opt/kafka/bin/kafka-server-stop.sh
    Copy to Clipboard Toggle word wrap

  2. Cruise Control Metrics Reporter .jar 파일을 Kafka 라이브러리 디렉터리에 복사합니다. 

    cp /opt/cruise-control/libs/cruise-control-metrics-reporter-y.y.yyy.redhat-0000x.jar /opt/kafka/libs
    Copy to Clipboard Toggle word wrap

  3. Kafka 구성 파일(/opt/kafka/config/server.properties)에서 Cruise Control Metrics Reporter를 구성합니다.

    1. metric.reporters 구성 옵션에 CruiseControlMetricsReporter 클래스를 추가합니다. 기존 지표 보고서를 제거하지 마십시오. 

      metric.reporters=com.linkedin.kafka.cruisecontrol.metricsreporter.CruiseControlMetricsReporter
      Copy to Clipboard Toggle word wrap

    2. Kafka 구성 파일에 다음 구성 옵션 및 값을 추가합니다. 

      cruise.control.metrics.topic.auto.create=true
cruise.control.metrics.topic.num.partitions=1
cruise.control.metrics.topic.replication.factor=1
      Copy to Clipboard Toggle word wrap

      이러한 옵션을 사용하면 Cruise Control Metrics Reporter에서 로그 정리 정책 DELETE 를 사용하여 __CruiseControlMetrics 주제를 만들 수 있습니다. 자세한 내용은 Cruise Control Metrics 항목에 대한 자동 생성 주제 및 로그 정리 정책을 참조하십시오.

  4. 필요한 경우 SSL을 구성합니다.

    1. Kafka 구성 파일(/opt/kafka/config/server.properties)에서 관련 클라이언트 구성 속성을 설정하여 Cruise Control Metrics Reporter와 Kafka 브로커 간의 SSL을 구성합니다.

      Metrics Reporter는 cruise.control.metrics.reporter 접두사를 사용하여 모든 표준 생산자별 구성 속성을 허용합니다. 예: cruise.control.metrics.reporter.ssl.truststore.password.

    2. Cruise Control 속성 파일(/opt/cruise-control/config/cruisecontrol.properties)에서 관련 클라이언트 구성 속성을 설정하여 Kafka 브로커와 Cruise Control 서버 간의 SSL을 구성합니다.

      cruise Control은 Kafka의 SSL 클라이언트 속성 옵션을 상속하고 모든 Cruise Control 서버 클라이언트에 해당 속성을 사용합니다.

  5. Kafka 브로커를 다시 시작합니다. 

    /opt/kafka/bin/kafka-server-start.sh
    Copy to Clipboard Toggle word wrap
  6. 나머지 브로커에 대해 1-5 단계를 반복합니다.

14.4. Cruise Control 구성 및 시작
링크 복사

Cruise Control에서 사용하는 속성을 구성한 다음 cruise-control-start.sh 스크립트를 사용하여 Cruise Control 서버를 시작합니다. 서버는 전체 Kafka 클러스터의 단일 시스템에서 호스팅됩니다.

Cruise Control이 시작될 때 세 가지 주제가 자동으로 생성됩니다. 자세한 내용은 자동 생성 항목을 참조하십시오.

사전 요구 사항

프로세스

  1. Cruise Control 속성 파일(/opt/cruise-control/config/cruisecontrol.properties)을 편집합니다.

  2. 다음 예제 구성에 표시된 속성을 구성합니다. 

    # The Kafka cluster to control.
bootstrap.servers=localhost:9092
    1 
    

# The replication factor of Kafka metric sample store topic
sample.store.topic.replication.factor=2
    2 
    

# The configuration for the BrokerCapacityConfigFileResolver (supports JBOD, non-JBOD, and heterogeneous CPU core capacities)
#capacity.config.file=config/capacity.json
#capacity.config.file=config/capacityCores.json
capacity.config.file=config/capacityJBOD.json
    3 
    

# The list of goals to optimize the Kafka cluster for with pre-computed proposals
default.goals={List of default optimization goals}
    4 
    

# The list of supported goals
goals={list of master optimization goals}
    5 
    

# The list of supported hard goals
hard.goals={List of hard goals}
    6 
    

# How often should the cached proposal be expired and recalculated if necessary
proposal.expiration.ms=60000
    7 
    

# The zookeeper connect of the Kafka cluster
zookeeper.connect=localhost:2181
    8
    Copy to Clipboard Toggle word wrap
    1
    Kafka 브로커의 호스트 및 포트 번호(항상 포트 9092).
    2
    Kafka 지표 샘플 저장소 주제의 복제 인수입니다. 단일 노드 Kafka 및 Zoo Cryostat 클러스터에서 Cruise Control을 평가하는 경우 이 속성을 1로 설정합니다. 프로덕션 용도의 경우 이 속성을 2 이상으로 설정합니다.
    3
    브로커 리소스의 최대 용량 제한을 설정하는 구성 파일입니다. Kafka 배포 구성에 적용되는 파일을 사용합니다. 자세한 내용은 용량 구성 을 참조하십시오.
    4
    FQDN(정규화된 도메인 이름)을 사용하여 콤마로 구분된 기본 최적화 목표 목록입니다. 여러 마스터 최적화 목표 (참조 5)는 이미 기본 최적화 목표로 설정되어 있습니다. 원하는 경우 목표를 추가하거나 제거할 수 있습니다. 자세한 내용은 14.5절. “최적화 목표 개요”의 내용을 참조하십시오.
    5
    FQDN을 사용하여 쉼표로 구분된 마스터 최적화 목표 목록입니다. 최적화 제안을 생성하는 데 사용되는 목표를 완전히 제외하려면 목록에서 제거하십시오. 자세한 내용은 14.5절. “최적화 목표 개요”의 내용을 참조하십시오.
    6
    FQDN을 사용하여 콤마로 구분된 하드 목표 목록입니다. 마스터 최적화 목표 중 7개는 이미 하드 목표로 설정되어 있습니다. 원하는 경우 목표를 추가하거나 제거할 수 있습니다. 자세한 내용은 14.5절. “최적화 목표 개요”의 내용을 참조하십시오.
    7
    기본 최적화 목표에서 생성되는 캐시된 최적화 제안을 새로 고치는 간격(밀리초)입니다. 자세한 내용은 14.6절. “최적화 제안 개요”의 내용을 참조하십시오.
    8
    Zoo Cryostat 연결의 호스트 및 포트 번호(항상 포트 2181).

  3. Cruise Control Server를 시작합니다. 서버는 기본적으로 포트 9092에서 시작합니다. 선택적으로 다른 포트를 지정합니다. 

    cd /opt/cruise-control/
./bin/cruise-control-start.sh config/cruisecontrol.properties PORT
    Copy to Clipboard Toggle word wrap

  4. Cruise Control이 실행 중인지 확인하려면 Cruise Control 서버의 /state 엔드포인트에 GET 요청을 보냅니다. 

    curl 'http://HOST:PORT/kafkacruisecontrol/state'
    Copy to Clipboard Toggle word wrap
자동 생성 주제

다음 표에서는 Cruise Control이 시작될 때 자동으로 생성되는 세 가지 주제를 보여줍니다. 이러한 주제는 크루즈 제어가 제대로 작동하려면 필수이며 삭제하거나 변경하지 않아야 합니다.

Expand
표 14.1. 자동 생성 주제
자동 생성 주제작성자함수

__CruiseControlMetrics

cruise Control Metrics Reporter

각 Kafka 브로커의 Metrics Reporter의 원시 지표를 저장합니다.

__KafkaCruiseControlPartitionMetricSamples

크루즈 제어

각 파티션에 대해 파생된 지표를 저장합니다. 이는 Metric Sample Aggregator 에 의해 생성됩니다.

__KafkaCruiseControlModelTrainingSamples

크루즈 제어

클러스터 워크로드 모델을 생성하는 데 사용되는 메트릭 샘플을 저장합니다.

자동 생성 항목에서 로그 압축이 비활성화되어 있는지 확인하려면 14.3절. “Cruise Control Metrics Reporter 배포” 에 설명된 대로 Cruise Control Metrics Reporter를 구성해야 합니다. 로그 압축은 Cruise Control에 필요한 레코드를 제거하고 제대로 작동하지 못하도록 할 수 있습니다.

추가 리소스

14.5. 최적화 목표 개요
링크 복사

Kafka 클러스터를 재조정하기 위해 Cruise Control은 최적화 목표를 사용하여 최적화 제안을 생성합니다. 최적화 목표는 Kafka 클러스터의 워크로드 재배포 및 리소스 사용률에 대한 제약입니다.

Red Hat Enterprise Linux의 AMQ Streams는 Cruise Control 프로젝트에서 개발한 모든 최적화 목표를 지원합니다. 지원되는 목표는 기본 우선순위 내림차순으로 다음과 같습니다.

  1. Rack-awareness
  2. 주제 집합의 브로커당 최소 리더 복제본 수
  3. 복제본 용량
  4. 용량: 디스크 용량, 네트워크 인바운드 용량, 네트워크 아웃 바운드 용량
  5. CPU 용량
  6. 복제본 배포
  7. 잠재적인 네트워크 출력
  8. 리소스 배포: 디스크 사용률 배포, 네트워크 인바운드 사용률 배포, 네트워크 아웃 바운드 사용 배포
  9. Leader bytes-in rate distribution
  10. 주제 복제본 배포
  11. CPU 사용량 배포
  12. 리더 복제본 배포
  13. 선호하는 리더 선택
  14. Kafka Assigner 디스크 사용량 배포
  15. Intra-broker 디스크 용량
  16. Intra-broker 디스크 사용량

각 최적화 목표에 대한 자세한 내용은 Cruise Control Wiki 의 목표를 참조하십시오.

Cruise Control 속성 파일의 설정 목표

cruisecontrol.properties 파일에서 cruise-control/config/ 디렉터리에 최적화 목표를 구성합니다. 마스터 및 기본 최적화 목표에도 충족해야 하는 하드 최적화 목표에 대한 구성이 있습니다.

선택 사항 인 사용자 제공 최적화 목표는 런타임 시 /rebalance 엔드포인트에 대한 요청의 매개변수로 설정됩니다.

최적화 목표는 브로커 리소스에 대한 모든 용량 제한 의 적용을 받습니다.

다음 섹션에서는 각 목표 구성에 대해 자세히 설명합니다.

마스터 최적화 목표

마스터 최적화 목표는 모든 사용자가 사용할 수 있습니다. 마스터 최적화 목표에 나열되지 않은 목표는 Cruise Control 작업에서 사용할 수 없습니다.

다음 마스터 최적화 목표는 목표 속성의 cruisecontrol.properties 파일에서 내림차순으로 사전 설정됩니다. 

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; CpuUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal; PreferredLeaderElectionGoal
Copy to Clipboard Toggle word wrap

단순화를 위해 최적화 제안을 생성하기 위해 하나 이상의 목표를 완전히 제외할 필요가 없는 경우 사전 설정된 마스터 최적화 목표를 변경하지 않는 것이 좋습니다. 필요한 경우 기본 최적화 목표를 위해 구성에서 마스터 최적화 목표의 우선 순위 순서를 수정할 수 있습니다.

사전 설정된 마스터 최적화 목표를 수정해야 하는 경우 목표 목록을 대상 속성에 내림차순으로 지정합니다. cruisecontrol.properties 파일에 표시된 대로 정규화된 도메인 이름을 사용합니다.

하나 이상의 마스터 목표를 지정해야 합니다. 그렇지 않으면 Cruise Control이 충돌합니다.

참고

사전 설정된 마스터 최적화 목표를 변경하는 경우 구성된 hard.goals 가 구성한 마스터 최적화 목표의 하위 집합인지 확인해야 합니다. 그렇지 않으면 최적화 제안을 생성할 때 오류가 발생합니다.

하드 목표 및 소프트 목적

하드 목표는 최적화 제안에 충족해야 하는 목표입니다. 하드 목표로 구성되지 않은 목표는 소프트 목표 라고 합니다. 소프트 목표는 최선의 노력 목표로 생각할 수 있습니다: 최적화 제안에 만족 할 필요는 없지만 최적화 계산에 포함됩니다.

크루즈 컨트롤은 가능한 한 많은 하드 목표와 가능한 많은 소프트 목표를 충족하는 최적화 제안을 계산합니다. 모든 하드 목표를 충족하지 않는 최적화 제안은 Analyzer에 의해 거부되며 사용자에게 전송되지 않습니다.

참고

예를 들어 클러스터에 주제의 복제본을 균등하게 분배하는 소프트 목표를 가질 수 있습니다(복제 복제본 배포 목표 참조). 크루즈 컨트롤은 구성된 모든 하드 목표를 달성할 수 있도록 하는 경우 이 목표를 무시합니다.

다음 마스터 최적화 목표는 cruisecontrol.properties 파일에서 hard.goals 속성으로 사전 설정됩니다. 

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal
Copy to Clipboard Toggle word wrap

하드 목표를 변경하려면 정규화된 도메인 이름을 사용하여 hard.goals 속성을 편집하고 원하는 목표를 지정합니다.

하드 목표의 수를 늘리면 Cruise Control이 계산되고 유효한 최적화 제안을 생성할 가능성이 줄어듭니다.

기본 최적화 목표

cruise Control은 기본 최적화 목표 목록을 사용하여 캐시된 최적화 제안을 생성합니다. 자세한 내용은 14.6절. “최적화 제안 개요”의 내용을 참조하십시오.

사용자 제공 최적화 목표를 설정하여 런타임 시 기본 최적화 목표를 재정의할 수 있습니다.

다음 기본 최적화 목표는 cruisecontrol.properties 파일에서 default.goals 속성의 내림차순으로 사전 설정됩니다. 

RackAwareGoal; MinTopicLeadersPerBrokerGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; CpuCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; CpuUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal
Copy to Clipboard Toggle word wrap

하나 이상의 기본 목표를 지정해야 합니다. 그렇지 않으면 Cruise Control이 충돌합니다.

기본 최적화 목표를 수정하려면 default.goals 속성에서 목표 목록을 내림차순으로 지정합니다. 기본 목표는 마스터 최적화 목표의 하위 집합이어야 합니다. 정규화된 도메인 이름을 사용합니다.

사용자 제공 최적화 목표

사용자 제공 최적화 목표는 특정 최적화 제안에 대해 구성된 기본 목표를 좁힙니다. 필요에 따라 /rebalance 엔드포인트에 대한 HTTP 요청의 매개변수로 설정할 수 있습니다. 자세한 내용은 14.9절. “최적화 제안 생성”의 내용을 참조하십시오.

사용자 제공 최적화 목표는 다양한 시나리오에 대한 최적화 제안을 생성할 수 있습니다. 예를 들어 디스크 용량 또는 디스크 사용률을 고려하지 않고 Kafka 클러스터에서 리더 복제본 배포를 최적화할 수 있습니다. 따라서 리더 복제본 배포를 위한 단일 목표를 포함하는 /rebalance 엔드포인트에 요청을 보냅니다.

사용자 제공 최적화 목표는 다음과 같아야 합니다.

최적화 제안에서 구성된 하드 목표를 무시하려면 skip_hard_goals_check=true 매개변수를 요청에 추가합니다.

추가 리소스

14.6. 최적화 제안 개요
링크 복사

최적화 제안은 적용되면 파티션 워크로드가 브로커 간에 더 균등하게 분배되는 제안된 변경 사항에 대한 요약입니다. 각 최적화 제안은 브로커 리소스에 대해 구성된 용량 제한에 따라 이를 생성하는 데 사용된 최적화 목표 세트를 기반으로 합니다.

/rebalance 엔드포인트에 POST 요청을 수행하면 최적화 제안이 응답으로 반환됩니다. 제안에 있는 정보를 사용하여 제안서에 따라 클러스터 재조정을 시작할지 여부를 결정합니다. 또는 최적화 목표를 변경한 다음 다른 제안을 생성할 수 있습니다.

기본적으로 최적화 제안은 별도로 시작해야 하는 시험 실행으로 생성됩니다. 생성할 수 있는 최적화 제안 수에는 제한이 없습니다.

캐시된 최적화 제안

cruise Control은 구성된 기본 최적화 목표에 따라 캐시된 최적화 제안을 유지합니다. 워크로드 모델에서 생성된 캐시된 최적화 제안은 Kafka 클러스터의 현재 상태를 반영하도록 15분마다 업데이트됩니다.

가장 최근 캐시된 최적화 제안은 다음과 같은 목표 구성이 사용될 때 반환됩니다.

  • 기본 최적화 목표
  • 현재 캐시된 제안에 의해 충족될 수 있는 사용자 제공 최적화 목표

캐시된 최적화 제안 새로 고침 간격을 변경하려면 cruisecontrol.properties 파일에서 proposal.expiration.ms 설정을 편집합니다. Cruise Control 서버의 로드가 증가하지만 빠르게 변화하는 클러스터의 더 짧은 간격을 고려하십시오.

최적화 제안의 내용

다음 표에서는 최적화 제안에 포함된 속성에 대해 설명합니다.

Expand
표 14.2. 최적화 제안에 포함된 속성
속성설명

N inter-broker 복제본 (yMB) 이동

N : 별도의 브로커 간에 이동할 파티션 복제본의 수입니다.

리밸런스 작업 중 성능에 미치는 영향: Relatively high.

Y MB: 별도의 브로커로 이동할 각 파티션 복제본의 크기 합계입니다.

리밸런스 작업 중 성능에 미치는 영향: 변수. MB 수가 클수록 클러스터가 리밸런스를 완료하는 데 시간이 오래 걸립니다.

N intra-broker 복제본 (yMB) 이동

N : 클러스터 브로커의 디스크 간에 전송되는 총 파티션 복제본 수입니다.

리밸런스 작업 중 성능에 미치는 영향: 기준으로 높지만 리브 로커 복제본보다 적습니다.

Y MB: 동일한 브로커의 디스크 간에 이동할 각 파티션 복제본의 크기 합계입니다.

리밸런스 작업 중 성능에 미치는 영향: 변수. 숫자가 클수록 클러스터 리밸런스를 완료하는 데 시간이 오래 걸립니다. 동일한 브로커의 디스크 간에 대량의 데이터를 이동하는 것은 별도의 브로커 간에 영향을 덜 받습니다(브루버 간 복제본 이동참조).

N 제외된 주제

최적화 제안에서 파티션 복제본/리더 이동 계산에서 제외된 주제의 수입니다.

다음 방법 중 하나로 주제를 제외할 수 있습니다.

cruisecontrol.properties 파일에서 topics.excluded.from.partition.movement 속성에 정규식을 지정합니다.

/rebalance 엔드포인트에 대한 POST 요청에서 excluded_topics 매개변수에 정규식을 지정합니다.

정규식과 일치하는 주제는 응답에 나열되며 클러스터 리밸런스에서 제외됩니다.

N 리더십 이동

N : 리더가 다른 복제본으로 전환될 파티션의 수입니다. 이를 위해서는 Zoo Cryostat 구성을 변경해야 합니다.

리밸런스 작업 중 성능에 미치는 영향: Relatively low.

N recent windows

N : 최적화 제안서를 기반으로 하는 메트릭 창 수입니다.

덮여 있는 파티션의 N%

N %: 최적화 제안이 적용되는 Kafka 클러스터의 파티션 백분율입니다.

On-demand balancedness 점수 전(nn.yy) 이후 (nn.yyy)

Kafka 클러스터의 전체 균형 측정.

크루즈 컨트롤은 우선 순위( default.goals 또는 사용자 제공 대상 목록의 목표 위치)를 포함하여 여러 요소를 기반으로 모든 최적화 목표에 균형성 점수를 할당합니다. On-demand Balancedness 점수는 각 목표의 균형 점수 합계를 100에서 위반하여 계산됩니다.

Before 점수는 Kafka 클러스터의 현재 구성을 기반으로 합니다. After 점수는 생성된 최적화 제안을 기반으로 합니다.

추가 리소스

14.7. 성능 튜닝 개요
링크 복사

클러스터 재조정을 위해 여러 성능 튜닝 옵션을 조정할 수 있습니다. 이러한 옵션은 리밸런스에서의 파티션 복제본 및 리더십 이동 방식 및 리밸런스 작업에 할당된 대역폭을 제어합니다.

파티션 재할당 명령

최적화 제안은 별도의 파티션 재할당 명령으로 구성됩니다. 제안을 시작하면 Cruise Control 서버에서 이러한 명령을 Kafka 클러스터에 적용합니다.

파티션 재할당 명령은 다음 작업 유형 중 하나로 구성됩니다.

  • 파티션 이동: 파티션 복제본과 해당 데이터를 새 위치로 전송합니다. 파티션 모음은 다음 두 가지 형식 중 하나를 수행할 수 있습니다.

    • 브랜드 간 이동: 파티션 복제본이 다른 브로커의 로그 디렉터리로 이동됩니다.
    • Intra-broker 이동: 파티션 복제본은 동일한 브로커의 다른 로그 디렉터리로 이동합니다.
  • 리더십 이동: 파티션 복제본의 리더를 전환시킵니다.

cruise Control은 배치의 Kafka 클러스터에 파티션 재할당 명령을 발행합니다. 리밸런스 중 클러스터 성능은 각 배치에 포함된 각 이동 유형의 영향을 받습니다.

파티션 재할당 명령을 구성하려면 조정 옵션 재조정 을 참조하십시오.

복제본 이동 전략

클러스터 리밸런스 성능은 파티션 재할당 명령의 배치에 적용되는 복제본 이동 전략 의 영향을 받습니다. 기본적으로 Cruise Control은 BaseReplica CryostatmentStrategy 를 사용하여 생성된 순서대로 명령을 적용합니다. 그러나 제안 초기에 매우 큰 파티션 재할당이 있는 경우 이 전략은 다른 재할당의 적용 속도가 느려질 수 있습니다.

cruise Control은 최적화 제안에 적용할 수 있는 세 가지 대체 복제본 이동 전략을 제공합니다.

  • PrioritizeSmallReplica CryostatmentStrategy: 오름차순 크기의 재할당을 주문합니다.
  • PrioritizeLargeReplica CryostatmentStrategy: 내림차순 크기의 재할당을 주문합니다.
  • PostponeUrpReplica>-<mentStrategy: 동기화되지 않은 복제본이 없는 파티션 복제본의 재할당을 우선순위화합니다.

이러한 전략은 시퀀스로 구성할 수 있습니다. 첫 번째 전략은 내부 논리를 사용하여 두 파티션 재할당을 비교하려고 합니다. 재할당이 동일한 경우 순서에서 다음 전략으로 전달하여 순서를 결정하는 등의 작업을 수행합니다.

복제본 이동 전략을 구성하려면 조정 옵션 재조정 을 참조하십시오.

조정 옵션 재조정

cruise Control은 리밸런스 매개변수 튜닝을 위한 몇 가지 구성 옵션을 제공합니다. 이러한 옵션은 다음과 같은 방법으로 설정됩니다.

  • 속성으로, 기본 Cruise Control 구성에서 cruisecontrol.properties 파일의
  • /rebalance 엔드포인트에 대한 POST 요청의 매개변수로

두 방법에 대한 관련 구성은 다음 표에 요약되어 있습니다.

Expand
표 14.3. 성능 튜닝 구성 재조정
속성 및 요청 매개변수 구성설명기본값

num.concurrent.partition.movements.per.broker

각 파티션 재할당 배치의 최대 구성 요소 수

5

concurrent_partition_movements_per_broker

num.concurrent.intra.broker.partition.movements

각 파티션 재할당 배치에서 인트라브러 파티션의 최대 수

2

concurrent_intra_broker_partition_movements

num.concurrent.leader.movements

각 파티션 재할당 배치의 최대 파티션 리더십 변경 수

1000

concurrent_leader_movements

default.replication.throttle

파티션 재할당에 할당할 대역폭(초당 바이트 단위)

null (제한 없음)

replication_throttle

default.replica.movement.strategies

생성된 제안서에 대해 파티션 재할당 명령이 실행되는 순서를 결정하는 데 사용되는 전략 목록(우선순)입니다. PrioritizeSmallReplicamentStrategy , PrioritizeLargeReplicamentStrategy, 및 PostponeUrpReplica mentStrategy 라는 세 가지 전략이 있습니다.

속성의 경우 전략 클래스의 정규화된 이름 목록을 쉼표로 구분하여 사용합니다( 각 클래스 이름 시작에 com.linkedin.kafka.cruisecontrol.executor.strategy. 를 추가합니다).

매개 변수에는 복제본 이동 전략의 클래스 이름 목록을 쉼표로 구분하여 사용합니다.

BaseReplicaMovementStrategy

replica_movement_strategies

기본 설정을 변경하면 리밸런스가 완료하는 데 걸리는 시간과 재조정 중 Kafka 클러스터에 배치된 로드에 영향을 미칩니다. 더 낮은 값을 사용하면 로드가 줄어들지만 사용된 시간이 증가하고 그 반대의 경우도 마찬가지입니다.

추가 리소스

14.8. 크루즈 제어 구성
링크 복사

config/cruisecontrol.properties 파일에는 Cruise Control에 대한 구성이 포함되어 있습니다. 파일은 다음 유형 중 하나에 있는 속성으로 구성됩니다.

  • 문자열
  • 숫자
  • 부울

Cruise Control Wiki의 Configurations 섹션에 나열된 모든 속성을 지정하고 구성할 수 있습니다.

용량 구성

크루즈 컨트롤에서는 용량 제한을 사용하여 특정 리소스 기반 최적화 목표를 손상했는지 확인합니다. 이러한 리소스 기반 목표 중 하나 이상이 하드 목표로 설정된 경우 시도된 최적화가 실패합니다. 이로 인해 최적화 제안을 생성하는 데 최적화가 사용되지 않습니다.

cruise-control/config 의 다음 세 .json 파일 중 하나에서 Kafka 브로커 리소스에 대한 용량 제한을 지정합니다.

  • capacityJBOD.json: JBOD Kafka 배포에서 사용되는 경우(기본 파일).
  • capacity.json: 각 브로커가 동일한 수의 CPU 코어가 있는JBOD Kafka 배포에서 사용하는 경우입니다.
  • capacityCores.json: 각 브로커마다 다양한 CPU 코어 수가 있는JBOD Kafka 배포 이외의 용도로 사용됩니다.

cruisecontrol.properties 의 capacity.config.file 속성에 파일을 설정합니다. 선택한 파일은 브로커 용량 확인에 사용됩니다. 예를 들면 다음과 같습니다. 

capacity.config.file=config/capacityJBOD.json
Copy to Clipboard Toggle word wrap

용량 제한은 설명된 단위로 다음 브로커 리소스에 대해 설정할 수 있습니다.

  • DISK: MB의 디스크 스토리지
  • CPU: CPU 사용률 (0-100) 또는 여러 코어
  • NW_IN: 초당 KB의 인바운드 네트워크 처리량
  • NW_OUT: 초당 KB의 아웃 바운드 네트워크 처리량

Cruise Control에서 모니터링하는 모든 브로커에 동일한 용량 제한을 적용하려면 브로커 ID -1 에 대한 용량 제한을 설정합니다. 개별 브로커에 대해 다른 용량 제한을 설정하려면 각 브로커 ID 및 용량 구성을 지정합니다.

용량 제한 구성의 예

{
  "brokerCapacities":[
    {
      "brokerId": "-1",
      "capacity": {
        "DISK": "100000",
        "CPU": "100",
        "NW_IN": "10000",
        "NW_OUT": "10000"
      },
      "doc": "This is the default capacity. Capacity unit used for disk is in MB, cpu is in percentage, network throughput is in KB."
    },
    {
      "brokerId": "0",
      "capacity": {
        "DISK": "500000",
        "CPU": "100",
        "NW_IN": "50000",
        "NW_OUT": "50000"
      },
      "doc": "This overrides the capacity for broker 0."
    }
  ]
}
Copy to Clipboard Toggle word wrap

자세한 내용은 Cruise Control Wiki 에서 용량 구성 파일 채우기 를 참조하십시오.

Cruise Control Metrics 항목에 대한 로그 정리 정책

자동 생성 __CruiseControlMetrics 주제( 자동 생성 주제참조)에 COMPACT 가 아닌 DELETE 의 로그 정리 정책이 있어야 합니다. 그렇지 않으면 Cruise Control에 필요한 레코드가 제거될 수 있습니다.

14.3절. “Cruise Control Metrics Reporter 배포” 에 설명된 대로 Kafka 구성 파일에서 다음 옵션을 설정하면 COMPACT 로그 정리 정책이 올바르게 설정되어 있습니다.

  • cruise.control.metrics.topic.auto.create=true
  • cruise.control.metrics.topic.num.partitions=1
  • cruise.control.metrics.topic.replication.factor=1

Cruise Control Metrics Reporter(cruise.control.metrics.topic.auto.create=false)에서 주제 자동 생성이 비활성화되어 있지만 Kafka 클러스터에서 활성화되어 있는 경우 __CruiseControlMetrics 주제는 브로커에 의해 자동으로 생성됩니다. 이 경우 __CruiseControlMetrics 항목의 로그 정리 정책을 kafka-configs.sh 도구를 사용하여 DELETE 로 변경해야 합니다.

  1. __CruiseControlMetrics 주제의 현재 구성을 가져옵니다. 

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name __CruiseControlMetrics --describe
    Copy to Clipboard Toggle word wrap

  2. 주제 구성에서 로그 정리 정책을 변경합니다. 

    bin/kafka-configs.sh --bootstrap-server <BrokerAddress> --entity-type topics --entity-name __CruiseControlMetrics --alter --add-config cleanup.policy=delete
    Copy to Clipboard Toggle word wrap

Cruise Control Metrics Reporter 및 Kafka 클러스터에서 주제 자동 생성이 비활성화되어 있는 경우 __CruiseControlMetrics 주제를 수동으로 생성한 다음 kafka-configs.sh 도구를 사용하여 DELETE 로그 정리 정책을 사용하도록 구성해야 합니다.

자세한 내용은 5.9절. “주제 구성 수정”의 내용을 참조하십시오.

로깅 구성

cruise Control은 모든 서버 로깅에 log4j1 을 사용합니다. 기본 구성을 변경하려면 /opt/cruise-control/config/ log4j.properties 에서 log4j.properties 파일을 편집합니다.

변경 사항을 적용하려면 Cruise Control 서버를 다시 시작해야 합니다.

14.9. 최적화 제안 생성
링크 복사

/rebalance 엔드포인트에 대한 POST 요청을 수행할 때 Cruise Control은 제공된 최적화 목표에 따라 Kafka 클러스터를 재조정하기 위한 최적화 제안을 생성합니다.

최적화 제안은 시험 실행 매개 변수를 제공하고 false 로 설정하지 않는 한 시험 실행으로 생성됩니다. "시험 실행 모드"에서 Cruise Control은 최적화 제안과 예상 결과를 생성하지만 클러스터를 재조정하여 제안을 시작하지는 않습니다.

최적화 제안에서 반환된 정보를 분석하고 이를 시작할지 여부를 결정할 수 있습니다.

다음은 /rebalance 엔드포인트에 대한 요청의 주요 매개변수입니다. 사용 가능한 모든 매개변수에 대한 자세한 내용은 Cruise Control Wiki의 REST API 를 참조하십시오.

dryrun

유형: boolean, default: true

Cruise Control에 최적화 제안만 생성하거나 최적화 제안을 생성하고 클러스터 재조정(false)을 수행할지 여부를 제어합니다.

dryrun=true (기본값)인 경우 verbose 매개변수를 전달하여 Kafka 클러스터 상태에 대한 자세한 정보를 반환할 수 있습니다. 여기에는 최적화 제안 전후에 각 Kafka 브로커의 로드 메트릭과 이전 및 이후 값의 차이가 포함됩니다.

excluded_topics

유형: regex

최적화 제안 계산에서 제외할 주제와 일치하는 정규식입니다.

목표

type: 문자열 목록, default: 구성된 default.goals 목록

최적화 제안을 준비하는 데 사용할 사용자 제공 최적화 목표 목록입니다. 목표를 지정하지 않으면 cruisecontrol.properties 파일에 구성된 default.goals 목록이 사용됩니다.

skip_hard_goals_check

유형: boolean, default: false

기본적으로 Cruise Control은 사용자가 제공한 최적화 목표( goals 매개변수에서)에 구성된 모든 하드 목표( hard.goals)가 포함되어 있는지 확인합니다. 구성된 hard.goals 의 서브 세트가 아닌 목표를 제공하면 요청이 실패합니다.

구성된 hard.goals 를 모두 포함하지 않는 사용자 제공 최적화 목표를 사용하여 최적화 제안을 생성하려면 skip_hard_goals_check 를 true 로 설정합니다.

json

유형: boolean, default: false

Cruise Control 서버에서 반환하는 응답 유형을 제어합니다. 제공되지 않거나 false 로 설정하면 Cruise Control은 명령줄에서 표시되도록 포맷된 텍스트를 반환합니다. 반환된 정보의 요소를 프로그래밍 방식으로 추출하려면 json=true 를 설정합니다. 이렇게 하면 jq 와 같은 툴로 파이프하거나 스크립트 및 프로그램에서 구문 분석할 수 있는 JSON 형식의 텍스트가 반환됩니다.

상세 정보

유형: boolean, default: false

Cruise Control 서버에서 반환하는 응답의 세부 수준을 제어합니다. dryrun=true 와 함께 사용할 수 있습니다.

사전 요구 사항

  • Kafka 및 Zoo Cryostat가 실행 중입니다.
  • 크루즈 제어가 실행 중입니다.

프로세스

  1. 콘솔에 대해 포맷된 "시험 실행" 최적화 제안을 생성하려면 POST 요청을 /rebalance 엔드포인트로 보냅니다.

    • 구성된 default.goals 를 사용하려면 다음을 수행합니다. 

      curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
      Copy to Clipboard Toggle word wrap

      캐시된 최적화 제안은 즉시 반환됩니다.

      참고

      NotEnoughValidWindows 가 반환되면 Cruise Control은 최적화 제안을 생성하기 위해 충분한 메트릭 데이터를 기록하지 않았습니다. 몇 분 정도 기다린 후 요청을 다시 보냅니다.

    • 구성된 default.goals 대신 사용자 제공 최적화 목표를 지정하려면 goals 매개변수에 하나 이상의 목표를 제공합니다. 

      curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance?goals=RackAwareGoal,ReplicaCapacityGoal'
      Copy to Clipboard Toggle word wrap

      제공된 목표를 충족하면 캐시된 최적화 제안이 즉시 반환됩니다. 그렇지 않으면 제공된 목표를 사용하여 새로운 최적화 제안이 생성됩니다. 이를 계산하는 데 시간이 오래 걸립니다. ignore_proposal_cache=true 매개변수를 요청에 추가하여 이 동작을 적용할 수 있습니다.

    • 구성된 모든 하드 목표를 포함하지 않는 사용자 제공 최적화 목표를 지정하려면 skip_hard_goal_check=true 매개변수를 요청에 추가합니다. 

      curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance?goals=RackAwareGoal,ReplicaCapacityGoal,ReplicaDistributionGoal&skip_hard_goal_check=true'
      Copy to Clipboard Toggle word wrap

  2. 응답에 포함된 최적화 제안을 검토하십시오. 속성은 보류 중인 클러스터 리밸런스 작업을 설명합니다.

    이 제안에는 제안된 최적화에 대한 높은 수준의 요약과 각 기본 최적화 목표에 대한 요약과 제안서가 실행된 후 예상되는 클러스터 상태가 포함됩니다.

    특히 다음 정보에 유의하십시오.

    • 요약 후 클러스터 로드. 요구 사항을 충족하는 경우 높은 수준의 요약을 사용하여 제안된 변경 사항의 영향을 평가해야 합니다.
    • N inter-broker 복제본 (yMB) 이동 은 브로커 간에 네트워크를 통해 이동할 데이터의 양을 나타냅니다. 값이 클수록 리밸런스 중 Kafka 클러스터에 대한 잠재적인 성능 영향이 커집니다.
    • N intra-broker 복제본(yMB) 은 브로커 자체 내에서 이동할 데이터의 양을 나타냅니다(디스크 간). 값이 클수록 개별 브로커에 대한 잠재적인 성능 영향이 커집니다( n inter-broker 복제본(yMB)보다 적음).
    • 리더십 이동 횟수입니다. 이는 리밸런스 중 클러스터 성능에 부정적인 영향을 미칩니다.
비동기 응답

Cruise Control REST API 엔드포인트는 기본적으로 10초 후에 시간 초과되지만 제안 생성은 서버에서 계속됩니다. 최근 캐시된 최적화 제안이 준비되지 않았거나 ignore_proposal_cache=true 로 사용자 제공 최적화 목표를 지정한 경우 시간 초과가 발생할 수 있습니다.

나중에 최적화 제안을 검색할 수 있도록 하려면 /rebalance 끝점의 응답 헤더에 제공되는 요청의 고유 식별자를 기록해 두십시오.

curl 을 사용하여 응답을 얻으려면 상세 정보 표시(-v) 옵션을 지정합니다. 

curl -v -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
Copy to Clipboard Toggle word wrap

다음은 예제 헤더입니다. 

* Connected to cruise-control-server (::1) port 9090 (#0)
> POST /kafkacruisecontrol/rebalance HTTP/1.1
> Host: cc-host:9090
> User-Agent: curl/7.70.0
> Accept: /
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Mon, 01 Jun 2020 15:19:26 GMT
< Set-Cookie: JSESSIONID=node01wk6vjzjj12go13m81o7no5p7h9.node0; Path=/
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< User-Task-ID: 274b8095-d739-4840-85b9-f4cfaaf5c201
< Content-Type: text/plain;charset=utf-8
< Cruise-Control-Version: 2.0.103.redhat-00002
< Cruise-Control-Commit_Id: 58975c9d5d0a78dd33cd67d4bcb497c9fd42ae7c
< Content-Length: 12368
< Server: Jetty(9.4.26.v20200117-redhat-00001)
Copy to Clipboard Toggle word wrap

시간 초과 내에 최적화 제안이 준비되지 않은 경우 POST 요청을 다시 제출할 수 있습니다. 이번에는 헤더에 원래 요청의 User-Task-ID 를 포함합니다. 

curl -v -X POST -H 'User-Task-ID: 274b8095-d739-4840-85b9-f4cfaaf5c201' 'cruise-control-server:9090/kafkacruisecontrol/rebalance'
Copy to Clipboard Toggle word wrap

다음에 수행할 작업

14.10절. “클러스터 리밸런스 시작”

14.10. 클러스터 리밸런스 시작
링크 복사

최적화 제안에 만족하는 경우 Cruise Control에 클러스터 재조정을 시작하고 제안에 요약된 대로 파티션 재할당을 시작하도록 지시할 수 있습니다.

최적화 제안을 생성하고 클러스터 리밸런스 시작 사이에 가능한 한 적은 시간을 남겨 두십시오. 원래 최적화 제안을 생성한 후 잠시 경과한 경우 클러스터 상태가 변경될 수 있습니다. 따라서 시작된 클러스터 리밸런스가 검토한 것과 다를 수 있습니다. 의심의 여지가있는 경우 먼저 새로운 최적화 제안을 생성합니다.

상태가 "Active"인 하나의 클러스터 리밸런스만 한 번에 진행 중일 수 있습니다.

사전 요구 사항

프로세스

  1. 가장 최근에 생성된 최적화 제안을 실행하려면 dryrun=false 매개변수를 사용하여 /rebalance 엔드포인트에 POST 요청을 보냅니다. 

    curl -X POST 'cruise-control-server:9090/kafkacruisecontrol/rebalance?dryrun=false'
    Copy to Clipboard Toggle word wrap

    크루즈 컨트롤은 클러스터 재조정을 시작하고 최적화 제안을 반환합니다.

  2. 최적화 제안에 요약된 변경 사항을 확인하십시오. 변경 사항이 예상되지 않은 경우 재조정을 중지 할 수 있습니다.

  3. /user_tasks 엔드포인트를 사용하여 클러스터 리밸런스의 진행 상황을 확인합니다. 클러스터 리밸런스 진행 중 상태가 "Active"입니다.

    Cruise Control 서버에서 실행되는 모든 클러스터 재조정 작업을 보려면 다음을 수행합니다. 

    curl 'cruise-control-server:9090/kafkacruisecontrol/user_tasks'

USER TASK ID      CLIENT ADDRESS  START TIME     STATUS  REQUEST URL
c459316f-9eb5-482f-9d2d-97b5a4cd294d  0:0:0:0:0:0:0:1       2020-06-01_16:10:29 UTC  Active      POST /kafkacruisecontrol/rebalance?dryrun=false
445e2fc3-6531-4243-b0a6-36ef7c5059b4  0:0:0:0:0:0:0:1       2020-06-01_14:21:26 UTC  Completed   GET /kafkacruisecontrol/state?json=true
05c37737-16d1-4e33-8e2b-800dee9f1b01  0:0:0:0:0:0:0:1       2020-06-01_14:36:11 UTC  Completed   GET /kafkacruisecontrol/state?json=true
aebae987-985d-4871-8cfb-6134ecd504ab  0:0:0:0:0:0:0:1       2020-06-01_16:10:04 UTC
    Copy to Clipboard Toggle word wrap

  4. 특정 클러스터 리밸런스 작업의 상태를 보려면 user-task-ids 매개변수와 작업 ID를 제공합니다. 

    curl 'cruise-control-server:9090/kafkacruisecontrol/user_tasks?user_task_ids=c459316f-9eb5-482f-9d2d-97b5a4cd294d'
    Copy to Clipboard Toggle word wrap

14.11. 활성 클러스터 리밸런스 중지
링크 복사

현재 진행 중인 클러스터 재조정을 중지할 수 있습니다.

이는 Cruise Control에 현재 파티션 재할당을 완료한 다음 재조정을 중지하도록 지시합니다. 리밸런스가 중지되면 완료된 파티션 재할당이 이미 적용되어 있으므로 리밸런스 작업을 시작하기 전과 비교할 때 Kafka 클러스터의 상태가 다릅니다. 추가 재조정이 필요한 경우 새로운 최적화 제안을 생성해야 합니다.

참고

중간(중지됨) 상태의 Kafka 클러스터의 성능은 초기 상태보다 더 나을 수 있습니다.

사전 요구 사항

  • 클러스터 리밸런스(클러스터 리밸런스)는 "Active" 상태로 표시됩니다.

프로세스

  • POST 요청을 /stop_proposal_execution 엔드포인트에 보냅니다. 

    curl -X POST 'cruise-control-server:9090/kafkacruisecontrol/stop_proposal_execution'
    Copy to Clipboard Toggle word wrap

추가 리소스

15장. 분산 추적
링크 복사

분산 추적을 사용하면 분산 시스템의 애플리케이션 간 트랜잭션 진행 상황을 추적할 수 있습니다. 마이크로 서비스 아키텍처에서 추적은 서비스 간 트랜잭션 진행 상황을 추적합니다. 추적 데이터는 애플리케이션 성능을 모니터링하고 대상 시스템 및 최종 사용자 애플리케이션 관련 문제를 조사하는 데 유용합니다.

Red Hat Enterprise Linux의 AMQ Streams에서 추적을 사용하면 소스 시스템에서 Kafka로 보낸 다음 Kafka에서 대상 시스템 및 애플리케이션에 이르기까지 메시지의 엔드 투 엔드 추적을 용이하게 합니다. 추적은 사용 가능한 Cryostat 지표를 보완합니다.

AMQ Streams에서 추적을 지원하는 방법

추적 지원은 다음 클라이언트 및 구성 요소에 대해 제공됩니다.

Kafka 클라이언트:

  • Kafka 생산자 및 소비자
  • Kafka Streams API 애플리케이션

Kafka 구성 요소:

  • Kafka Connect
  • Kafka Bridge
  • MirrorMaker
  • MirrorMaker 2.0

추적을 활성화하려면 4가지 고급 작업을 수행합니다.

  1. Jaeger 추적기를 활성화합니다.

  2. 인터셉터를 활성화합니다.

    • Kafka 클라이언트의 경우 OpenTracing Apache Kafka Client Instrumentation 라이브러리( AMQ Streams에 포함)를 사용하여 애플리케이션 코드를 계측 합니다.
    • Kafka 구성 요소의 경우 각 구성 요소에 대한 구성 속성을 설정합니다.
  3. 추적 환경 변수를 설정합니다.
  4. 클라이언트 또는 구성 요소를 배포합니다.

조정되면 클라이언트는 추적 데이터를 생성합니다. 예를 들어 메시지를 생성하거나 로그에 오프셋을 쓰는 경우입니다.

추적은 샘플링 전략에 따라 샘플링된 다음 Jaeger 사용자 인터페이스에서 시각화됩니다.

참고

Kafka 브로커에서는 추적이 지원되지 않습니다.

AMQ Streams 이외의 애플리케이션 및 시스템에 대한 추적 설정은 이 장의 범위를 벗어납니다. 이 주제에 대한 자세한 내용은 OpenTracing 문서에서 "inject and extract"를 검색합니다.

절차의 개요

AMQ Streams에 대한 추적을 설정하려면 다음 절차를 순서대로 수행합니다.

  1. 클라이언트의 추적을 설정합니다.

    1. Kafka 클라이언트에 대한 Jaeger 추적 프로그램 초기화
    2. 추적을 위한 장비 생산자 및 소비자
    3. 추적을 위한 instrument Kafka Streams 애플리케이션

  2. MirrorMaker, MirrorMaker 2.0 및 Kafka Connect에 대한 추적을 설정합니다.

    1. MirrorMaker의 추적 활성화
    2. MirrorMaker 2.0의 추적 활성화
    3. Kafka Connect의 추적 활성화
  3. Kafka 브리지의 추적 활성화

사전 요구 사항

  • Jaeger 백엔드 구성 요소는 호스트 운영 체제에 배포됩니다. 배포 지침은 Jaeger 배포 설명서 를 참조하십시오.

15.1. OpenTracing 및 Jaeger 개요
링크 복사

AMQ Streams는 OpenTracing 및 Jaeger 프로젝트를 사용합니다.

OpenTracing은 추적 또는 모니터링 시스템과 독립적인 API 사양입니다.

  • OpenTracing API는 애플리케이션 코드를 조정하는 데 사용됩니다.
  • 조정된 애플리케이션은 분산 시스템에서 개별 트랜잭션에 대한 추적 을 생성합니다.
  • 추적은 시간이 지남에 따라 특정 작업 단위를 정의하는 범위로 구성됩니다.

Jaeger는 마이크로 서비스 기반 분산 시스템의 추적 시스템입니다.

  • Jaeger는 OpenTracing API를 구현하고 계측을 위한 클라이언트 라이브러리를 제공합니다.
  • Jaeger 사용자 인터페이스를 사용하면 추적 데이터를 쿼리, 필터링 및 분석할 수 있습니다.

A simple query in the Jaeger user interface

추가 리소스

15.2. Kafka 클라이언트의 추적 설정
링크 복사

Jaeger 추적기를 초기화하여 분산 추적을 위해 클라이언트 애플리케이션을 계측합니다.

15.2.1. Kafka 클라이언트에 대한 Jaeger 추적 프로그램 초기화
링크 복사

추적 환경 변수 세트를 사용하여 Jaeger 추적기를 구성하고 초기화합니다.

프로세스

각 클라이언트 애플리케이션에서 다음을 수행합니다.

  1. Jaeger의 Maven 종속 항목을 클라이언트 애플리케이션의 pom.xml 파일에 추가합니다. 

    <dependency>
    <groupId>io.jaegertracing</groupId>
    <artifactId>jaeger-client</artifactId>
    <version>1.5.0.redhat-00001</version>
</dependency>
    Copy to Clipboard Toggle word wrap
  2. 추적 환경 변수 를 사용하여 Jaeger 추적기의 구성을 정의합니다.

  3. 2단계에서 정의한 환경 변수에서 Jaeger 추적기를 생성합니다. 

    Tracer tracer = Configuration.fromEnv().getTracer();
    Copy to Clipboard Toggle word wrap
    참고

    Jaeger 추적기를 초기화하는 다른 방법은 Java OpenTracing 라이브러리 설명서를 참조하십시오.

  4. Jaeger 추적기를 글로벌 추적기로 등록합니다. 

    GlobalTracer.register(tracer);
    Copy to Clipboard Toggle word wrap

클라이언트 애플리케이션이 사용할 Jaeger 추적기가 초기화되었습니다.

15.2.2. 추적을 위한 생산자 및 소비자 처리
링크 복사

Decorator 패턴 또는 인터셉터를 사용하여 추적을 위해 Java 생산자 및 소비자 애플리케이션 코드를 계측합니다.

프로세스

각 생산자 및 소비자 애플리케이션의 애플리케이션 코드에서 다음을 수행합니다.

  1. OpenTracing의 Maven 종속성을 생산자 또는 소비자의 pom.xml 파일에 추가합니다. 

    <dependency>
    <groupId>io.opentracing.contrib</groupId>
    <artifactId>opentracing-kafka-client</artifactId>
    <version>0.1.15.redhat-00002</version>
</dependency>
    Copy to Clipboard Toggle word wrap

  2. Decorator 패턴 또는 인터셉터를 사용하여 클라이언트 애플리케이션 코드를 계측합니다.

    • Decorator 패턴을 사용하려면 다음을 수행합니다. 

      // Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Create an instance of the TracingKafkaProducer:
TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
        tracer);

// Send:
tracingProducer.send(...);

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Create an instance of the TracingKafkaConsumer:
TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
        tracer);

// Subscribe:
tracingConsumer.subscribe(Collections.singletonList("messages"));

// Get messages:
ConsumerRecords<Integer, String> records = tracingConsumer.poll(1000);

// Retrieve SpanContext from polled record (consumer side):
ConsumerRecord<Integer, String> record = ...
SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
      Copy to Clipboard Toggle word wrap

    • 인터셉터를 사용하려면 다음을 수행합니다. 

      // Register the tracer with GlobalTracer:
GlobalTracer.register(tracer);

// Add the TracingProducerInterceptor to the sender properties:
senderProps.put(ProducerConfig.INTERCEPTOR_CLASSES_CONFIG,
          TracingProducerInterceptor.class.getName());

// Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Send:
producer.send(...);

// Add the TracingConsumerInterceptor to the consumer properties:
consumerProps.put(ConsumerConfig.INTERCEPTOR_CLASSES_CONFIG,
          TracingConsumerInterceptor.class.getName());

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Subscribe:
consumer.subscribe(Collections.singletonList("messages"));

// Get messages:
ConsumerRecords<Integer, String> records = consumer.poll(1000);

// Retrieve the SpanContext from a polled message (consumer side):
ConsumerRecord<Integer, String> record = ...
SpanContext spanContext = TracingKafkaUtils.extractSpanContext(record.headers(), tracer);
      Copy to Clipboard Toggle word wrap
Decorator 패턴의 사용자 정의 범위 이름

기간은 작업 이름, 시작 시간 및 기간이 있는 Jaeger의 논리적 작업 단위입니다.

생산자 및 소비자 애플리케이션을 계측하는 데 Decorator 패턴을 사용하려면 TracingKafkaProducer 및 TracingKafkaConsumer 오브젝트를 생성할 때 BiFunction 오브젝트를 추가 인수로 전달하여 사용자 정의 범위 이름을 정의합니다. OpenTracing Apache Kafka Client Instrumentation 라이브러리에는 여러 개의 기본 제공 범위 이름이 포함되어 있습니다.

예: 사용자 정의 범위 이름을 사용하여 Decorator 패턴에서 클라이언트 애플리케이션 코드를 조정

// Create a BiFunction for the KafkaProducer that operates on (String operationName, ProducerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ProducerRecord, String> producerSpanNameProvider =
    (operationName, producerRecord) -> "CUSTOM_PRODUCER_NAME";

// Create an instance of the KafkaProducer:
KafkaProducer<Integer, String> producer = new KafkaProducer<>(senderProps);

// Create an instance of the TracingKafkaProducer
TracingKafkaProducer<Integer, String> tracingProducer = new TracingKafkaProducer<>(producer,
        tracer,
        producerSpanNameProvider);

// Spans created by the tracingProducer will now have "CUSTOM_PRODUCER_NAME" as the span name.

// Create a BiFunction for the KafkaConsumer that operates on (String operationName, ConsumerRecord consumerRecord) and returns a String to be used as the name:

BiFunction<String, ConsumerRecord, String> consumerSpanNameProvider =
    (operationName, consumerRecord) -> operationName.toUpperCase();

// Create an instance of the KafkaConsumer:
KafkaConsumer<Integer, String> consumer = new KafkaConsumer<>(consumerProps);

// Create an instance of the TracingKafkaConsumer, passing in the consumerSpanNameProvider BiFunction:

TracingKafkaConsumer<Integer, String> tracingConsumer = new TracingKafkaConsumer<>(consumer,
        tracer,
        consumerSpanNameProvider);

// Spans created by the tracingConsumer will have the operation name as the span name, in upper-case.
// "receive" -> "RECEIVE"
Copy to Clipboard Toggle word wrap

기본 제공 범위 이름

사용자 지정 범위 이름을 정의할 때 ClientSpanNameProvider 클래스에서 다음 BiFunctions 를 사용할 수 있습니다. spanNameProvider 를 지정하지 않으면 CONSUMER_OPERATION_NAME 및 PRODUCER_OPERATION_NAME 이 사용됩니다.

Expand
표 15.1. 사용자 지정 범위 이름을 정의하는 BiFunctions
BiFunction설명

CONSUMER_OPERATION_NAME, PRODUCER_OPERATION_NAME

user Name을 범위의 이름으로 반환합니다. 소비자의 경우 "receive" 및 생산자의 경우 "send"를 반환합니다.

CONSUMER_PREFIXED_OPERATION_NAME(String prefix), PRODUCER_PREFIXED_OPERATION_NAME(String prefix)

접두사 및 operationName 의 문자열 연결을 반환합니다.

CONSUMER_TOPIC, PRODUCER_TOPIC

메시지가 전송된 대상의 이름 또는 형식 (record.topic()) 을 반환합니다.

PREFIXED_CONSUMER_TOPIC(String prefix), PREFIXED_PRODUCER_TOPIC(String prefix)

문자열 접두사 연결과 항목 이름 (record.topic()) 을 반환합니다.

CONSUMER_OPERATION_NAME_TOPIC, PRODUCER_OPERATION_NAME_TOPIC

작업 이름과 주제 이름을 반환합니다. "operationName - record.topic()".

CONSUMER_PREFIXED_OPERATION_NAME_TOPIC(String prefix), PRODUCER_PREFIXED_OPERATION_NAME_TOPIC(String prefix)

접두사 와 "operationName - record.topic()" 문자열 연결을 반환합니다.

15.2.3. 추적을 위한 Kafka Streams 애플리케이션 조정
링크 복사

공급자 인터페이스를 사용하여 분산 추적을 위한 Kafka Streams 애플리케이션입니다. 이를 통해 애플리케이션에서 인터셉터가 활성화됩니다.

프로세스

각 Kafka Streams 애플리케이션에서 다음을 수행합니다.

  1. opentracing-kafka-streams 종속성을 Kafka Streams 애플리케이션의 pom.xml 파일에 추가합니다. 

    <dependency>
    <groupId>io.opentracing.contrib</groupId>
    <artifactId>opentracing-kafka-streams</artifactId>
    <version>0.1.15.redhat-00002</version>
</dependency>
    Copy to Clipboard Toggle word wrap

  2. TracingKafkaClientSupplier 공급자 인터페이스 인스턴스를 생성합니다. 

    KafkaClientSupplier supplier = new TracingKafkaClientSupplier(tracer);
    Copy to Clipboard Toggle word wrap

  3. KafkaStreams 에 공급자 인터페이스를 제공합니다. 

    KafkaStreams streams = new KafkaStreams(builder.build(), new StreamsConfig(config), supplier);
streams.start();
    Copy to Clipboard Toggle word wrap

15.3. MirrorMaker 및 Kafka Connect에 대한 추적 설정
링크 복사

이 섹션에서는 분산 추적을 위해 MirrorMaker, MirrorMaker 2.0 및 Kafka Connect를 구성하는 방법을 설명합니다.

각 구성 요소에 대해 Jaeger 추적기를 활성화해야 합니다.

15.3.1. MirrorMaker의 추적 활성화
링크 복사

Interceptor 속성을 소비자 및 생산자 구성 매개변수로 전달하여 MirrorMaker에 대한 분산 추적을 활성화합니다.

메시지는 소스 클러스터에서 대상 클러스터로 추적됩니다. 추적 데이터는 MirrorMaker 구성 요소를 입력하고 나가는 메시지를 기록합니다.

프로세스

  1. Jaeger 추적기를 구성하고 활성화합니다.

  2. /opt/kafka/config/consumer.properties 파일을 편집합니다.

    다음 Interceptor 속성을 추가합니다. 

    consumer.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor
    Copy to Clipboard Toggle word wrap

  3. /opt/kafka/config/producer.properties 파일을 편집합니다.

    다음 Interceptor 속성을 추가합니다. 

    producer.interceptor.classes=io.opentracing.contrib.kafka.TracingProducerInterceptor
    Copy to Clipboard Toggle word wrap

  4. 소비자 및 생산자 구성 파일을 매개변수로 사용하여 MirrorMaker를 시작합니다. 

    su - kafka
/opt/kafka/bin/kafka-mirror-maker.sh --consumer.config /opt/kafka/config/consumer.properties --producer.config /opt/kafka/config/producer.properties --num.streams=2
    Copy to Clipboard Toggle word wrap

15.3.2. MirrorMaker 2.0의 추적 활성화
링크 복사

MirrorMaker 2.0 속성 파일에서 Interceptor 속성을 정의하여 MirrorMaker 2.0에 대한 분산 추적을 활성화합니다.

Kafka 클러스터 간에 메시지가 추적됩니다. 추적 데이터는 MirrorMaker 2.0 구성 요소를 입력하고 나가는 메시지를 기록합니다.

프로세스

  1. Jaeger 추적기를 구성하고 활성화합니다.

  2. MirrorMaker 2.0 구성 속성 파일 ./config/connect-mirror-maker.properties 를 편집하고 다음 속성을 추가합니다. 

    header.converter=org.apache.kafka.connect.converters.ByteArrayConverter
    1 
    
consumer.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor
    2 
    
producer.interceptor.classes=io.opentracing.contrib.kafka.TracingProducerInterceptor
    Copy to Clipboard Toggle word wrap
    1
    Kafka Connect가 메시지 헤더(추적 ID를 포함)를 base64 인코딩으로 변환하지 못하도록 합니다. 이렇게 하면 소스 및 대상 클러스터에서 메시지가 모두 동일합니다.
    2
    MirrorMaker 2.0에 대한 인터셉터를 활성화합니다.
  3. 9.4절. “MirrorMaker 2.0을 사용하여 Kafka 클러스터 간에 데이터 동기화” 의 지침을 사용하여 MirrorMaker 2.0을 시작합니다.

추가 리소스

15.3.3. Kafka Connect에 대한 추적 활성화
링크 복사

구성 속성을 사용하여 Kafka Connect에 대해 분산 추적을 활성화합니다.

Kafka Connect 자체에서 생성하고 사용하는 메시지만 추적됩니다. Kafka Connect와 외부 시스템 간에 전송된 메시지를 추적하려면 해당 시스템의 커넥터에서 추적을 구성해야 합니다.

프로세스

  1. Jaeger 추적기를 구성하고 활성화합니다.

  2. 관련 Kafka Connect 구성 파일을 편집합니다.

    • 독립 실행형 모드에서 Kafka Connect를 실행하는 경우 /opt/kafka/config/connect-standalone.properties 파일을 편집합니다.
    • 분산 모드에서 Kafka Connect를 실행하는 경우 /opt/kafka/config/connect-distributed.properties 파일을 편집합니다.

  3. 구성 파일에 다음 속성을 추가합니다. 

    producer.interceptor.classes=io.opentracing.contrib.kafka.TracingProducerInterceptor
consumer.interceptor.classes=io.opentracing.contrib.kafka.TracingConsumerInterceptor
    Copy to Clipboard Toggle word wrap
  4. 구성 파일을 저장합니다.
  5. 추적 환경 변수를 설정한 다음 독립 실행형 또는 분산 모드에서 Kafka Connect를 실행합니다.

Kafka Connect의 내부 소비자 및 생산자의 인터셉터가 활성화됩니다.

추가 리소스

15.4. Kafka 브리지의 추적 활성화
링크 복사

Kafka 브리지 구성 파일을 편집하여 Kafka 브리지의 분산 추적을 활성화합니다. 그런 다음 호스트 운영 체제에 분산 추적을 위해 구성된 Kafka Bridge 인스턴스를 배포할 수 있습니다.

다음과 같은 경우 추적이 생성됩니다.

  • Kafka 브리지는 HTTP 클라이언트에 메시지를 전송하고 HTTP 클라이언트에서 메시지를 사용합니다.
  • HTTP 클라이언트는 Kafka 브리지를 통해 메시지를 전송하고 수신하도록 HTTP 요청을 보냅니다.

엔드 투 엔드 추적을 사용하려면 HTTP 클라이언트에서 추적을 구성해야 합니다.

프로세스

  1. Kafka Bridge 설치 디렉터리에서 config/application.properties 파일을 편집합니다.

    다음 줄에서 코드 주석을 제거합니다. 

    bridge.tracing=jaeger
    Copy to Clipboard Toggle word wrap
  2. 구성 파일을 저장합니다.

  3. 구성 속성을 매개변수로 사용하여 bin/kafka_bridge_run.sh 스크립트를 실행합니다. 

    cd kafka-bridge-0.xy.x.redhat-0000x
./bin/kafka_bridge_run.sh --config-file=config/application.properties
    Copy to Clipboard Toggle word wrap

    Kafka Bridge 내부 소비자 및 생산자의 인터셉터가 활성화됩니다.

추가 리소스

15.5. 추적을 위한 환경 변수
링크 복사

Kafka 클라이언트 및 구성 요소에 대한 Jaeger 추적기를 구성할 때 이러한 환경 변수를 사용합니다.

참고

추적 환경 변수는 Jaeger 프로젝트의 일부이며 변경될 수 있습니다. 최신 환경 변수는 Jaeger 설명서를 참조하십시오.

Expand
표 15.2. Jaeger 추적기 환경 변수
속성필수 항목설명

JAEGER_SERVICE_NAME

제공됨

Jaeger 추적기 서비스의 이름입니다.

JAEGER_AGENT_HOST

없음

UDP(User Datagram Protocol)를 통해 jaeger-agent 와 통신하는 호스트 이름입니다.

JAEGER_AGENT_PORT

없음

UDP를 통해 jaeger-agent 와 통신하는 데 사용되는 포트입니다.

JAEGER_ENDPOINT

없음

추적 끝점입니다. 클라이언트 애플리케이션이 jaeger-agent 를 우회하고 jaeger-collector 에 직접 연결하는 경우에만 이 변수를 정의합니다.

JAEGER_AUTH_TOKEN

없음

전달자 토큰으로 엔드포인트에 보낼 인증 토큰입니다.

JAEGER_USER

없음

기본 인증을 사용하는 경우 엔드포인트에 보낼 사용자 이름입니다.

JAEGER_PASSWORD

없음

기본 인증을 사용하는 경우 엔드포인트에 보낼 암호입니다.

JAEGER_PROPAGATION

없음

추적 컨텍스트를 전파하는 데 사용할 쉼표로 구분된 형식 목록입니다. 기본값은 표준 Jaeger 형식입니다. 유효한 값은 jaeger 및 b3 입니다.

JAEGER_REPORTER_LOG_SPANS

없음

보고자가 범위를 기록해야 하는지 여부를 나타냅니다.

JAEGER_REPORTER_MAX_QUEUE_SIZE

없음

보고자의 최대 큐 크기입니다.

JAEGER_REPORTER_FLUSH_INTERVAL

없음

보고자의 플러시 간격(ms)입니다. Jaeger 보고자가 일괄 처리의 빈도를 정의합니다.

JAEGER_SAMPLER_TYPE

없음

클라이언트 추적에 사용할 샘플링 전략입니다.

  • 상수
  • Probabilistic
  • 속도 제한
  • remote(기본값)

모든 추적을 샘플링하려면 매개 변수 1과 함께 Constant 샘플링 전략을 사용합니다.

자세한 내용은 Jaeger 설명서 를 참조하십시오.

JAEGER_SAMPLER_PARAM

없음

sampler 매개변수(number)입니다.

JAEGER_SAMPLER_MANAGER_HOST_PORT

없음

원격 샘플링 전략이 선택된 경우 사용할 호스트 이름 및 포트입니다.

JAEGER_TAGS

없음

보고된 모든 범위에 추가된 쉼표로 구분된 추적 관리자 수준 태그 목록입니다.

이 값은 ${envVarName:default} 형식을 사용하여 환경 변수를 참조할 수도 있습니다. :default 는 선택 사항이며 환경 변수를 찾을 수 없는 경우 사용할 값을 식별합니다.

16장. Kafka Exporter
링크 복사

Kafka Exporter 는 Apache Kafka 브로커 및 클라이언트의 모니터링을 개선하는 오픈 소스 프로젝트입니다.

Kafka Exporter는 Kafka 클러스터를 배포하여 오프셋, 소비자 그룹, 소비자 지연 및 주제와 관련된 Kafka 브로커에서 추가 지표 데이터를 추출하기 위해 AMQ Streams에 제공됩니다.

예를 들어 지표 데이터는 느린 소비자를 식별하는 데 사용됩니다.

지연 데이터는 Prometheus 지표로 노출되며 분석을 위해 Grafana에 표시될 수 있습니다.

이미 Prometheus 및 Grafana를 사용하여 기본 제공 Kafka 메트릭을 모니터링하는 경우 Kafka Exporter Prometheus 끝점을 스크랩하도록 Prometheus를 구성할 수 있습니다.

추가 리소스

Kafka는 Cryostat를 통해 지표를 노출합니다. 이 지표는 Prometheus 지표로 내보낼 수 있습니다.

16.1. 소비자 지연
링크 복사

소비자 지연은 메시지의 프로덕션 속도와 사용 속도의 차이를 나타냅니다. 특히 지정된 소비자 그룹의 소비자 지연은 파티션의 마지막 메시지와 해당 소비자가 현재 선택 중인 메시지 사이의 지연을 나타냅니다. 지연은 파티션 로그의 끝과 관련하여 소비자 오프셋의 위치를 반영합니다.

이러한 차이점은 Kafka 브로커 주제 파티션의 읽기 및 쓰기 위치인 생산자 오프셋과 소비자 오프셋 간의 delta 라고도 합니다.

주제가 1초에 100개의 메시지를 스트리밍한다고 가정합니다. 생산자 오프셋(주파 파티션 헤드)과 소비자가 읽은 마지막 오프셋은 10초 지연을 의미합니다.

소비자 지연 모니터링의 중요성

실시간 데이터의 처리에 의존하는 애플리케이션의 경우 소비자 지연을 모니터링하는 것이 너무 크지 않은지 확인하는 것이 중요합니다. 지연이 많을수록 프로세스가 실시간 처리 목표에서 이동합니다.

예를 들어 소비자 지연은 제거되지 않았거나 계획되지 않은 종료를 통해 오래된 데이터를 너무 많이 소비한 결과일 수 있습니다.

소비자 지연 감소

지연을 줄이기 위한 일반적인 작업은 다음과 같습니다.

  • 새 소비자를 추가하여 소비자 그룹 확장
  • 메시지가 주제에 남아 있도록 보존 시간 늘리기
  • 메시지 버퍼를 늘리기 위해 디스크 용량을 더 추가

소비자 지연을 줄이기 위한 작업은 기본 인프라에 따라 달라지며 AMQ Streams가 지원하는 사용 사례입니다. 예를 들어, 지연된 소비자는 브로커에서 디스크 캐시의 가져오기 요청을 서비스할 수 있는 이점이 줄어듭니다. 또한 특정 경우에는 소비자가 catch될 때까지 메시지를 자동으로 삭제하는 것이 허용될 수 있습니다.

16.2. Kafka Exporter 경고 규칙 예
링크 복사

Kafka Exporter와 관련된 샘플 경고 알림 규칙은 다음과 같습니다.

UnderReplicatedPartition
주제가 복제되지 않았으며 브로커가 충분한 파티션을 복제하지 않는다고 경고하는 경고입니다. 주제의 기본 구성은 하나 이상의 복제된 파티션이 있는 경우 경고용입니다. 경고는 Kafka 인스턴스가 다운되었거나 Kafka 클러스터가 과부하됨을 나타낼 수 있습니다. Kafka 브로커를 다시 시작하려는 경우 복제 프로세스를 다시 시작해야 할 수 있습니다.
TooLargeConsumerGroupLag
소비자 그룹의 지연이 특정 주제 파티션에서 너무 커서 있음을 경고하는 경고입니다. 기본 구성은 1000개의 레코드입니다. 대규모 지연은 소비자가 너무 느리고 생산자 뒤에 속함을 나타낼 수 있습니다.
NoMessageForTooLong
주제가 일정 기간 동안 메시지를 수신하지 않았다고 경고하는 경고입니다. 기간의 기본 설정은 10분입니다. 지연은 구성 문제로 인해 생산자가 메시지를 주제에 게시하지 못할 수 있습니다.

특정 요구 사항에 따라 경고 규칙을 조정할 수 있습니다.

추가 리소스

경고 규칙 설정에 대한 자세한 내용은 Prometheus 문서의 구성 을 참조하십시오.

16.3. Kafka 내보내기 메트릭
링크 복사

지연 정보는 Kafka Exporter에서 Grafana에서 프레젠테이션을 위한 Prometheus 지표로 노출됩니다.

Kafka Exporter는 브로커, 주제 및 소비자 그룹에 대한 메트릭 데이터를 노출합니다.

Expand
표 16.1. 브로커 메트릭 출력
이름정보

kafka_brokers

Kafka 클러스터의 브로커 수

Expand
표 16.2. 주제 지표 출력
이름정보

kafka_topic_partitions

주제의 파티션 수

kafka_topic_partition_current_offset

브로커의 현재 주제 파티션 오프셋

kafka_topic_partition_oldest_offset

브로커의 가장 오래된 주제 파티션 오프셋

kafka_topic_partition_in_sync_replica

주제 파티션의 in-sync 복제본 수

kafka_topic_partition_leader

주제 파티션의 리더 브로커 ID

kafka_topic_partition_leader_is_preferred

주제 파티션이 기본 브로커를 사용하는 경우 1 을 표시합니다.

kafka_topic_partition_replicas

이 주제 파티션의 복제본 수

kafka_topic_partition_under_replicated_partition

주제 파티션이 복제 아래에 있는 경우 1 을 표시합니다.

Expand
표 16.3. 소비자 그룹 지표 출력
이름정보

kafka_consumergroup_current_offset

소비자 그룹의 현재 주제 파티션 오프셋

kafka_consumergroup_lag

주제 파티션에서 소비자 그룹에 대한 현재 대략적인 지연

16.4. Kafka 내보내기 실행
링크 복사

Kafka Exporter는 AMQ Streams 설치에 사용되는 다운로드 아카이브와 함께 제공됩니다.

이를 실행하여 Grafana 대시보드에서 프레젠테이션에 대한 Prometheus 지표를 노출할 수 있습니다.

사전 요구 사항

이 절차에서는 이미 Grafana 사용자 인터페이스에 액세스할 수 있고 Prometheus가 데이터 소스로 배포 및 추가된다고 가정합니다.

프로세스

  1. 적절한 구성 매개변수 값을 사용하여 Kafka Exporter 스크립트를 실행합니다. 

    ./bin/kafka_exporter --kafka.server=<kafka-bootstrap-address>:9092 --kafka.version=3.0.0  --<my-other-parameters>
    Copy to Clipboard Toggle word wrap

    매개변수에는 --kafka.server 와 같은 이중 하이퍼바이저 규칙이 필요합니다.

    Expand
    표 16.4. Kafka Exporter 구성 매개변수
    옵션설명기본

    kafka.server

    Kafka 서버의 호스트/게스트 주소입니다.

    kafka:9092

    kafka.version

    Kafka 브로커 버전.

    1.0.0

    group.filter

    메트릭에 포함할 소비자 그룹을 지정하는 정규식입니다.

    .* (모두)

    topic.filter

    메트릭에 포함할 주제를 지정하는 정규식입니다.

    .* (모두)

    SASL.<매개변수>

    SASL/PLAIN 인증을 사용하여 사용자 이름 및 암호와 함께 Kafka 클러스터에 연결하고 연결하는 매개변수입니다.

    false

    TLS.<매개변수>

    선택적 인증서 및 키와 함께 TLS 인증을 사용하여 Kafka 클러스터에 연결할 수 있는 매개변수입니다.

    false

    web.listen-address

    메트릭을 노출할 포트 주소입니다.

    :9308

    web.telemetry-path

    노출된 메트릭의 경로입니다.

    /metrics

    log.level

    로깅 구성은 심각도가 지정된 메시지(debug, info, warn, error, fatal) 이상을 기록합니다.

    info

    log.enable-sarama

    Kafka Exporter에서 사용하는 Go 클라이언트 라이브러리인 Sarama 로깅을 활성화하는 부울입니다.

    false

    legacy.partitions

    비활성 주제 파티션 및 활성 파티션에서 메트릭을 가져올 수 있는 부울입니다. Kafka Exporter에서 비활성 파티션에 대한 메트릭을 반환하려면 true 로 설정합니다.

    false

    속성에 대한 자세한 내용은 kafka_exporter --help 를 사용할 수 있습니다.

  2. Kafka Exporter 지표를 모니터링하도록 Prometheus를 구성합니다.

    Prometheus 구성에 대한 자세한 내용은 Prometheus 설명서 를 참조하십시오.

  3. Grafana를 활성화하여 Prometheus에서 노출하는 Kafka Exporter 지표 데이터를 제공합니다.

    자세한 내용은 Grafana에서 Kafka 내보내기 메트릭을 참조하십시오.

16.5. Grafana에서 Kafka Exporter 메트릭 표시
링크 복사

Kafka Exporter Prometheus 지표를 데이터 소스로 사용하면 Grafana 차트 대시보드를 생성할 수 있습니다.

예를 들어 메트릭에서 다음 Grafana 차트를 생성할 수 있습니다.

  • 초당 메시지 (주석에서)
  • 분별 메시지 (주석에서)
  • 소비자 그룹의 지연
  • 분당 소비되는 메시지(사용자 그룹별)

메트릭 데이터가 일정 동안 수집되면 Kafka 내보내기 차트가 채워집니다.

Grafana 차트를 사용하여 지연을 분석하고 지연을 줄이는 작업이 영향을 받는 소비자 그룹에 영향을 미치는지 확인합니다. 예를 들어 Kafka 브로커가 지연을 줄이기 위해 조정되면 대시보드에는 소비자 그룹 차트가 중단되고 분별 메시지 차트가 가동되는 메시지가 표시됩니다.

추가 리소스

17장. AMQ Streams 및 Kafka 업그레이드
링크 복사

AMQ Streams는 클러스터 다운타임 없이 업그레이드할 수 있습니다. AMQ Streams의 각 버전은 하나 이상의 Apache Kafka 버전을 지원합니다. AMQ Streams 버전에서 지원하는 경우 더 높은 Kafka 버전으로 업그레이드할 수 있습니다. 최신 버전의 AMQ Streams는 최신 버전의 Kafka를 지원할 수 있지만 지원되는 더 높은 Kafka 버전으로 업그레이드하기 전에 AMQ Streams를 업그레이드해야 합니다.

17.1. 업그레이드 사전 요구 사항
링크 복사

업그레이드 프로세스를 시작하기 전에 다음을 확인하십시오.

17.2. 업그레이드 프로세스
링크 복사

AMQ Streams 업그레이드는 2단계 프로세스입니다. 다운타임 없이 브로커 및 클라이언트를 업그레이드하려면 다음 순서로 업그레이드 절차를 완료해야 합니다.

  1. 최신 AMQ Streams 버전으로 업그레이드합니다.

  2. 모든 Kafka 브로커 및 클라이언트 애플리케이션을 최신 Kafka 버전으로 업그레이드

17.3. Kafka 버전
링크 복사

Kafka의 로그 메시지 형식 버전 및broker 간 프로토콜 버전은 각각 메시지에 추가된 로그 형식 버전과 클러스터에 사용되는 Kafka 프로토콜 버전을 지정합니다. 올바른 버전을 사용하려면 업그레이드 프로세스에서 기존 Kafka 브로커를 구성하고 클라이언트 애플리케이션(소유자 및 생산자)에 대한 코드 변경을 수행해야 합니다.

다음 표는 Kafka 버전의 차이점을 보여줍니다.

Expand
Kafka 버전Interbroker 프로토콜 버전로그 메시지 형식 버전Zookeeper 버전

3.0.0

3.0

3.0

3.6.3

2.8.0

2.8

2.8

3.5.9

broker 프로토콜 버전

Kafka에서broker 간 통신에 사용되는 네트워크 프로토콜을 broker 간 프로토콜 이라고 합니다. Kafka의 각 버전에는 해석 간 프로토콜의 호환 버전이 있습니다. 프로토콜의 마이너 버전은 일반적으로 이전 표에 표시된 대로 Kafka의 마이너 버전과 일치하도록 증가합니다.

broker 프로토콜 버전은 Kafka 리소스에서 클러스터 전체로 설정됩니다. 이를 변경하려면 Kafka.spec.kafka.config 에서 inter.broker.protocol.version 속성을 편집합니다.

로그 메시지 형식 버전

생산자가 Kafka 브로커에 메시지를 보내면 메시지는 특정 형식을 사용하여 인코딩됩니다. 형식은 Kafka 릴리스 간에 변경될 수 있으므로 메시지는 인코딩된 메시지 형식의 버전을 지정합니다.

특정 메시지 형식 버전을 설정하는 데 사용되는 속성은 다음과 같습니다.

  • 주제의 message.format.version 속성
  • Kafka 브로커의 log.message.format.version 속성

Kafka 3.0.0에서 메시지 형식 버전 값은 inter.broker.protocol.version 과 일치하도록 가정되며 설정할 필요가 없습니다. 값은 사용된 Kafka 버전을 반영합니다.

Kafka 3.0.0 이상으로 업그레이드할 때 inter.broker.protocol.version 을 업데이트할 때 이러한 설정을 제거할 수 있습니다. 그러지 않으면 업그레이드할 Kafka 버전에 따라 메시지 형식 버전을 설정합니다.

항목에 대한 message.format.version 의 기본값은 Kafka 브로커에 설정된 log.message.format.version 에 의해 정의됩니다. 주제 구성을 수정하여 주제의 message.format.version 을 수동으로 설정할 수 있습니다.

17.4. AMQ Streams 2.0으로 업그레이드
링크 복사

AMQ Streams 2.0을 사용하도록 배포를 업그레이드하는 단계는 이 섹션에 설명되어 있습니다.

AMQ Streams에서 관리하는 Kafka 클러스터의 가용성은 업그레이드 작업의 영향을 받지 않습니다.

참고

해당 버전으로 업그레이드하는 방법에 대한 정보는 특정 버전의 AMQ Streams를 지원하는 설명서를 참조하십시오.

17.4.1. Kafka 브로커 및 Zoo Cryostat 업그레이드
링크 복사

다음 절차에서는 최신 버전의 AMQ Streams를 사용하도록 호스트 머신에서 Kafka 브로커 및 Zoo Cryostat를 업그레이드하는 방법을 설명합니다.

사전 요구 사항

  • kafka 사용자로 Red Hat Enterprise Linux에 로그인되어 있습니다.

프로세스

AMQ Streams 클러스터의 각 Kafka 브로커와 한 번에 하나씩 다음을 수행합니다.

  1. 고객 포털에서 AMQ Streams 아카이브를 다운로드합니다.

    참고

    메시지가 표시되면 Red Hat 계정에 로그인합니다.

  2. 명령줄에서 임시 디렉터리를 생성하고 amq-streams-x.y.z-bin.zip 파일의 내용을 추출합니다. 

    mkdir /tmp/kafka
unzip amq-streams-x.y.z-bin.zip -d /tmp/kafka
    Copy to Clipboard Toggle word wrap

  3. 실행 중인 경우 호스트에서 실행 중인 Zoo Cryostat 및 Kafka 브로커를 중지합니다. 

    /opt/kafka/bin/zookeeper-server-stop.sh
/opt/kafka/bin/kafka-server-stop.sh
jcmd | grep zookeeper
jcmd | grep kafka
    Copy to Clipboard Toggle word wrap

  4. 기존 설치에서 libs,bin 및 docs 디렉토리를 삭제합니다. 

    rm -rf /opt/kafka/libs /opt/kafka/bin /opt/kafka/docs
    Copy to Clipboard Toggle word wrap

  5. 임시 디렉토리에서 libs,bin 및 docs 디렉토리를 복사합니다. 

    cp -r /tmp/kafka/kafka_y.y-x.x.x/libs /opt/kafka/
cp -r /tmp/kafka/kafka_y.y-x.x.x/bin /opt/kafka/
cp -r /tmp/kafka/kafka_y.y-x.x.x/docs /opt/kafka/
    Copy to Clipboard Toggle word wrap

  6. 임시 디렉터리를 삭제합니다. 

    rm -r /tmp/kafka
    Copy to Clipboard Toggle word wrap
  7. 텍스트 편집기에서 일반적으로 /opt/kafka/config/ 디렉터리에 저장된 브로커 속성 파일을 엽니다.

  8. inter.broker.protocol.version 및 log.message.format.version 속성이 현재 버전으로 설정되어 있는지 확인합니다. 

    inter.broker.protocol.version=2.8
log.message.format.version=2.8
    Copy to Clipboard Toggle word wrap

    inter.broker.protocol.version 을 변경하지 않으면 브로커가 업그레이드 중에 계속 서로 통신할 수 있습니다.

    속성이 구성되지 않은 경우 현재 버전으로 추가합니다.

  9. 업데이트된 Zoo Cryostat 및 Kafka 브로커를 다시 시작하십시오. 

    /opt/kafka/bin/zookeeper-server-start.sh -daemon /opt/kafka/config/zookeeper.properties
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap

    Kafka 브로커 및 Zookeeper는 최신 Kafka 버전에 바이너리를 사용하기 시작합니다.

  10. 재시작한 Kafka 브로커가 다음과 같은 파티션 복제본에 도달했는지 확인합니다. kafka-topics.sh 툴을 사용하여 브로커에 포함된 모든 복제본이 동기화되었는지 확인합니다. 지침은 항목 목록 및 설명을 참조하십시오.
  11. 17.5절. “Kafka 업그레이드” 에 설명된 대로 Kafka를 업그레이드하는 절차를 수행합니다.

17.4.2. Kafka Connect 업그레이드
링크 복사

다음 절차에서는 호스트 시스템에서 Kafka Connect 클러스터를 업그레이드하는 방법을 설명합니다.

사전 요구 사항

  • kafka 사용자로 Red Hat Enterprise Linux에 로그인되어 있습니다.
  • Kafka Connect가 시작되지 않습니다.

프로세스

AMQ Streams 클러스터의 각 Kafka 브로커와 한 번에 하나씩 다음을 수행합니다.

  1. 고객 포털에서 AMQ Streams 아카이브를 다운로드합니다.

    참고

    메시지가 표시되면 Red Hat 계정에 로그인합니다.

  2. 명령줄에서 임시 디렉터리를 생성하고 amq-streams-x.y.z-bin.zip 파일의 내용을 추출합니다. 

    mkdir /tmp/kafka
unzip amq-streams-x.y.z-bin.zip -d /tmp/kafka
    Copy to Clipboard Toggle word wrap

  3. 실행 중인 경우 호스트에서 Kafka 브로커 및 Zoo Cryostat 실행을 중지합니다. 

    /opt/kafka/bin/kafka-server-stop.sh
/opt/kafka/bin/zookeeper-server-stop.sh
    Copy to Clipboard Toggle word wrap

  4. 기존 설치에서 libs,bin 및 docs 디렉토리를 삭제합니다. 

    rm -rf /opt/kafka/libs /opt/kafka/bin /opt/kafka/docs
    Copy to Clipboard Toggle word wrap

  5. 임시 디렉토리에서 libs,bin 및 docs 디렉토리를 복사합니다. 

    cp -r /tmp/kafka/kafka_y.y-x.x.x/libs /opt/kafka/
cp -r /tmp/kafka/kafka_y.y-x.x.x/bin /opt/kafka/
cp -r /tmp/kafka/kafka_y.y-x.x.x/docs /opt/kafka/
    Copy to Clipboard Toggle word wrap

  6. 임시 디렉터리를 삭제합니다. 

    rm -r /tmp/kafka
    Copy to Clipboard Toggle word wrap

  7. 독립 실행형 또는 분산 모드에서 Kafka 연결을 시작합니다.

    • 독립 실행형 모드에서 시작하려면 connect-standalone.sh 스크립트를 실행합니다. Kafka Connect 독립 실행형 구성 파일과 Kafka Connect 커넥터의 구성 파일을 지정합니다. 

      su - kafka
/opt/kafka/bin/connect-standalone.sh /opt/kafka/config/connect-standalone.properties connector1.properties
[connector2.properties ...]
      Copy to Clipboard Toggle word wrap

    • 분산 모드에서 시작하려면 모든 Kafka Connect 노드에서 /opt/kafka/config/connect-distributed.properties 구성 파일을 사용하여 Kafka Connect 작업자를 시작합니다. 

      su - kafka
/opt/kafka/bin/connect-distributed.sh /opt/kafka/config/connect-distributed.properties
      Copy to Clipboard Toggle word wrap

  8. Kafka Connect가 실행 중인지 확인합니다.

    • 독립 실행형 모드에서 다음을 수행합니다. 

      jcmd | grep ConnectStandalone
      Copy to Clipboard Toggle word wrap

    • 분산 모드에서: 

      jcmd | grep ConnectDistributed
      Copy to Clipboard Toggle word wrap
  9. Kafka Connect가 데이터를 예상대로 생성하고 사용하는지 확인합니다.

추가 리소스

17.5. Kafka 업그레이드
링크 복사

최신 버전의 AMQ Streams를 사용하도록 바이너리를 업그레이드한 후 브로커를 업그레이드하여 지원되는 더 높은 버전의 Kafka를 사용할 수 있습니다.

Kafka 업그레이드 후 필요한 경우 Kafka 소비자를 업그레이드하여 증분 협업 재밸런스 프로토콜을 사용할 수 있습니다.

새 브랜드 간 프로토콜 버전을 사용하도록 모든 Kafka 브로커를 수동으로 구성하고 다시 시작합니다. 이러한 단계를 수행한 후 새 브랜드 간 프로토콜 버전을 사용하여 Kafka 브로커 간에 데이터가 전송됩니다.

참고

Kafka 3.0.0에서 메시지 형식 버전 값은 inter.broker.protocol.version 과 일치하도록 가정되며 설정할 필요가 없습니다. 값은 사용된 Kafka 버전을 반영합니다.

수신된 메시지는 이전 메시지 형식 버전의 메시지 로그에 계속 추가됩니다.

주의

이 절차를 완료한 후에는 AMQ Streams를 다운로드할 수 없습니다.

사전 요구 사항

프로세스

AMQ Streams 클러스터의 각 Kafka 브로커와 한 번에 하나씩 다음을 수행합니다.

  1. 텍스트 편집기에서 업데이트할 Kafka 브로커의 브로커 속성 파일을 엽니다. 브로커 속성 파일은 일반적으로 /opt/kafka/config/ 디렉터리에 저장됩니다.

  2. inter.broker.protocol.version 을 3.0 으로 설정합니다. 

    inter.broker.protocol.version=3.0
    Copy to Clipboard Toggle word wrap

  3. 명령줄에서 수정한 Kafka 브로커를 중지합니다. 

    /opt/kafka/bin/kafka-server-stop.sh
jcmd | grep kafka
    Copy to Clipboard Toggle word wrap

  4. 수정한 Kafka 브로커를 다시 시작합니다. 

    /opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
    Copy to Clipboard Toggle word wrap
  5. 재시작한 Kafka 브로커가 다음과 같은 파티션 복제본에 도달했는지 확인합니다. kafka-topics.sh 툴을 사용하여 브로커에 포함된 모든 복제본이 동기화되었는지 확인합니다. 지침은 항목 목록 및 설명을 참조하십시오.

Kafka 소비자 및 Kafka Streams 애플리케이션을 업그레이드하여 기본 eager rebalance 프로토콜 대신 파티션 재조정에 증분 협업 리밸런스 프로토콜을 사용할 수 있습니다. 새 프로토콜이 Kafka 2.4.0에 추가되었습니다.

소비자는 파티션 할당을 협업 재조정에 보관하고 균형 잡힌 클러스터를 달성하는 데 필요한 경우 프로세스 종료 시에만 해당 할당을 취소합니다. 이렇게 하면 소비자 그룹 또는 Kafka Streams 애플리케이션의 가용성을 줄일 수 있습니다.

참고

증분 협업 리밸런스 프로토콜로 업그레이드하는 것은 선택 사항입니다. eager rebalance 프로토콜은 계속 지원됩니다.

사전 요구 사항

프로세스

incremental cooperative rebalance 프로토콜을 사용하도록 Kafka 소비자를 업그레이드하려면 다음을 수행합니다.

  1. Kafka 클라이언트 .jar 파일을 새 버전으로 교체합니다.
  2. 소비자 구성에서 cooperative-sticky 를 partition.assignment.strategy 에 추가합니다. 예를 들어 범위 전략이 설정된 경우 구성을 범위, cooperative-sticky 로 변경합니다.
  3. 그룹의 각 소비자를 다시 시작하여 다시 시작한 후 소비자가 그룹에 다시 참여할 때까지 기다립니다.
  4. 소비자 구성에서 이전 partition.assignment.strategy 를 제거하여 그룹의 각 소비자를 재구성하여 cooperative-sticky 전략만 남겨 둡니다.
  5. 그룹의 각 소비자를 다시 시작하여 다시 시작한 후 소비자가 그룹에 다시 참여할 때까지 기다립니다.

incremental cooperative rebalance 프로토콜을 사용하도록 Kafka Streams 애플리케이션을 업그레이드하려면 다음을 수행합니다.

  1. Kafka Streams .jar 파일을 새 버전으로 교체합니다.
  2. Kafka Streams 구성에서 upgrade.from 구성 매개변수를 업그레이드 중인 Kafka 버전(예: 2.3)으로 설정합니다.
  3. 각 스트림 프로세서(노드)를 차례로 다시 시작합니다.
  4. Kafka Streams 구성에서 upgrade.from 구성 매개변수를 제거합니다.
  5. 그룹의 각 소비자를 차례로 다시 시작합니다.

부록 A. 브로커 구성 매개변수
링크 복사

advertised.listeners

type: string
default: null
Importance: high
Dynamic update: per-broker

리스너 config 속성과 다른 경우 클라이언트가 사용할 수 있도록 Zoo Cryostat에 게시하는 리스너 입니다. IaaS 환경에서는 브로커가 바인딩하는 인터페이스와 다를 수 있습니다. 이 값을 설정하지 않으면 리스너 값이 사용됩니다. 리스너 와 달리 0.0.0.0 메타 주소를 알리는 것은 유효하지 않습니다. 또한 리스너 와 달리 이 속성에 중복된 포트가 있으므로 다른 리스너의 주소를 알리도록 하나의 리스너를 구성할 수 있습니다. 이는 외부 로드 밸런서가 사용되는 경우에 유용할 수 있습니다.

auto.create.topics.enable

유형: boolean
Default: true
Importance: high
Dynamic update: read-only

서버에서 주제 자동 생성을 활성화합니다.

auto.leader.rebalance.enable

유형: boolean
Default: true
Importance: high
Dynamic update: read-only

자동 리더의 균형을 활성화합니다. 백그라운드 스레드는 정기적으로 파티션 리더의 배포를 확인하고 leader.imbalance.check.interval.seconds 로 구성할 수 있습니다. 리더의 불균형이 leader.imbalance.per.broker.percentage 를 초과하는 경우 리더는 파티션의 기본 리더에 재조정됩니다.

background.threads

유형: int
default: 10
유효한 값: [1,…​]
Importance: high
동적 업데이트: 클러스터 전체

다양한 백그라운드 처리 작업에 사용할 스레드 수입니다.

broker.id

유형: int
Default: -1
Importance: high
Dynamic update: read-only

이 서버의 브로커 ID입니다. 설정되지 않으면 고유 브로커 ID가 생성됩니다. zookeeper 생성 브로커 ID와 사용자 구성된 브로커 ID 간의 충돌을 방지하려면 reserved.broker.max.max.id에서 시작되는 브로커 ID가 시작됩니다.

compression.type

유형: 문자열
Default: producer
Importance: high
Dynamic update: cluster-wide

지정된 항목에 대한 최종 압축 유형을 지정합니다. 이 구성에서는 표준 압축 codecs('gzip', 'snappy', 'lz4', 'zstd')를 허용합니다. 압축하지 않은 것과 동일한 '압축되지 않음' 및 'producer'도 사용할 수 있습니다. 즉, 생산자가 설정한 원래 압축 codec를 유지합니다.

control.plane.listener.name

type: string
default: null
Importance: high
Dynamic update: read-only

컨트롤러와 브로커 간 통신에 사용되는 리스너 이름입니다. 브로커는 control.plane.listener.name을 사용하여 리스너 목록에서 끝점을 찾아 컨트롤러의 연결을 수신 대기합니다. 예를 들어 브로커의 구성이 : listeners = INTERNAL://192.1.1.8:9092, EXTERNAL://10.1.1.5:9093, CONTROLLER://192.1.1.8:9094 listener.9094 listener.9094 listener.protocol.map = INTERNAL:PLAINTEXT, EXTERNAL:SSL, CONTROLLER:SSL control.plane.listener.name = CONTROLLER를 시작 시 브로커는 보안 프로토콜 "SSL"을 사용하여 "192.1.1.8:9094"에서 수신 대기 시작합니다. 컨트롤러 측에서 Zookeeper를 통해 브로커의 게시된 엔드포인트를 검색할 때 control.plane.listener.name을 사용하여 브로커에 대한 연결을 설정하는 데 사용할 엔드포인트를 찾습니다. 예를 들어, Zookeeper에 대한 브로커의 게시된 끝점이 : "endpoints" : ["INTERNAL://broker1.example.com:9092","EXTERNAL://broker1.example.com:9093","CONTROLLER://broker1.example.com:9094" 및 컨트롤러의 구성은 : listener.security.protocol =NPLLAL입니다. EXTERNAL:SSL, CONTROLLER:SSL control.plane.listener.name = CONTROLLER는 브로커에 연결하기 위해 보안 프로토콜 "SSL"과 함께 "broker1.example.com:9094"를 사용합니다. 명시적으로 구성되지 않은 경우 기본값은 null이며 컨트롤러 연결에 대한 전용 끝점이 없습니다.

controller.listener.names

type: string
default: null
Importance: high
Dynamic update: read-only

컨트롤러에서 사용하는 리스너 이름 쉼표로 구분된 목록입니다. 이는 KRaft 모드에서 실행되는 경우 필요합니다. ZK 기반 컨트롤러는 이 구성을 사용하지 않습니다.

controller.quorum.election.backoff.max.ms

유형: int
Default: 1000 (1 second)
Importance: high
Dynamic update: read-only

새 선택을 시작하기 전의 최대 시간(밀리초)입니다. 이는 그리드 잠금 선택을 방지하는 데 도움이 되는 바이너리 지수 백오프 메커니즘에 사용됩니다.

controller.quorum.election.timeout.ms

유형: int
Default: 1000 (1 second)
Importance: high
Dynamic update: read-only

새 선택을 트리거하기 전에 리더에서 가져오지 않고 대기하는 최대 시간(밀리초)입니다.

controller.quorum.fetch.timeout.ms

유형: int
기본값: 2000(2초)
중요도: high
동적 업데이트: 읽기 전용

후보가 되기 전에 현재 리더로부터 성공적으로 가져오지 않고 선택을 트리거하는 최대 시간; 리더의 새로운 에포크가 있는지 요청하기 전에 대부분의 쿼럼에서 가져오기를 받지 못한 최대 시간.

controller.quorum.voters

type: list
default: ""
Valid Values: non-empty list
Importance: high
Dynamic update: read-only

{id}@{host}:{port} 항목의 쉼표로 구분된 목록에 있는 후보 집합의 ID/endpoint 정보를 매핑합니다. 예: 1@localhost:9092,2@localhost:9093,3@localhost:9094.

delete.topic.enable

유형: boolean
Default: true
Importance: high
Dynamic update: read-only

주제 삭제를 활성화합니다. 이 구성이 꺼져 있으면 관리자 툴을 통해 주제를 삭제해도 적용되지 않습니다.

leader.imbalance.check.interval.seconds

유형: long
Default: 300
Importance: high
Dynamic update: read-only

파티션 재조정 검사를 수행하는 빈도는 컨트롤러에 의해 트리거됩니다.

leader.imbalance.per.broker.percentage

유형: int
Default: 10
Importance: high
Dynamic update: read-only

브로커당 허용되는 리더 불균형의 비율입니다. 컨트롤러는 브로커당 이 값을 초과하면 리더 균형을 트리거합니다. 이 값은 백분율로 지정됩니다.

리스너

유형: 문자열
기본값: PLAINTEXT://:9092
가져오기: high
동적 업데이트: per-broker

리스너 목록 - 당사가 수신 대기할 URI와 리스너 이름을 쉼표로 구분한 목록입니다. 리스너 이름이 보안 프로토콜이 아닌 경우 listener.security.protocol.map 도 설정해야 합니다. 리스너 이름과 포트 번호는 고유해야 합니다. 모든 인터페이스에 바인딩하려면 호스트 이름을 0.0.0.0으로 지정합니다. 기본 인터페이스에 바인딩하려면 호스트 이름을 비워 둡니다. 법적 리스너 목록의 예로는 PLAINTEXT://myhost:9092,SSL://:9091 CLIENT://0.0.0.0:9092,REPLICATION://localhost:9093.

log.dir

type: string
Default: /tmp/kafka-logs
Importance: high
Dynamic update: read-only

로그 데이터가 보관되는 디렉터리입니다(log.dirs 속성의 경우 추가 기능).

log.dirs

type: string
default: null
Importance: high
Dynamic update: read-only

로그 데이터가 유지되는 디렉터리입니다. 설정되지 않은 경우 log.dir의 값이 사용됩니다.

log.flush.interval.messages

유형: long
기본값: 92233720368775807
유효한 값: [1,…​]
Importance: high
동적 업데이트: cluster-wide

메시지가 디스크에 플러시되기 전에 로그 파티션에 누적된 메시지 수입니다.

log.flush.interval.ms

유형: long
default: null
Importance: high
Dynamic update: cluster-wide

모든 주제의 메시지가 디스크에 플러시되기 전에 메모리에 유지되는 ms의 최대 시간입니다. 설정되지 않은 경우 log.flush.scheduler.interval.ms의 값이 사용됩니다.

log.flush.offset.checkpoint.interval.ms

유형: int
Default: 60000 (1 minute)
유효한 값: [0,…​]
중요도: high
동적 업데이트: 읽기 전용

로그 복구 지점 역할을 하는 마지막 플러시의 영구 레코드를 업데이트하는 빈도입니다.

log.flush.scheduler.interval.ms

유형: long
기본값: 9223372036854775807
중요: high
동적 업데이트: 읽기 전용

로그 플러시기가 로그를 디스크에 플러시해야 하는지 확인하는 ms의 빈도입니다.

log.flush.start.offset.checkpoint.interval.ms

유형: int
Default: 60000 (1 minute)
유효한 값: [0,…​]
중요도: high
동적 업데이트: 읽기 전용

로그 시작 오프셋의 영구 레코드를 업데이트하는 빈도입니다.

log.retention.bytes

유형: long
기본값: -1
Importance: high
동적 업데이트: 클러스터 전체

삭제하기 전에 로그의 최대 크기입니다.

log.retention.hours

유형: int
Default: 168
Importance: high
Dynamic update: read-only

로그 파일을 삭제하기 전에(시간 단위), log.retention.ms 속성을 삭제하는 시간(시간)입니다.

log.retention.minutes

유형: int
default: null
Importance: high
Dynamic update: read-only

로그 파일을 삭제하기 전에 로그 파일을 유지하는 분 수(분 단위), secondary to log.retention.ms 속성입니다. 설정되지 않은 경우 log.retention.hours의 값이 사용됩니다.

log.retention.ms

유형: long
default: null
Importance: high
Dynamic update: cluster-wide

로그 파일을 삭제하기 전에 로그 파일을 유지하는 시간(밀리초)입니다. 설정되지 않은 경우 log.retention.minutes의 값이 사용됩니다. -1로 설정하면 시간 제한이 적용되지 않습니다.

log.roll.hours

유형: int
기본값: 168
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

새 로그 세그먼트가 롤아웃되기 전의 최대 시간(시간 단위), log.roll.ms 속성의 보조입니다.

log.roll.jitter.hours

type: int
Default: 0
Valid Values: [0,…​]
Importance: high
Dynamic update: read-only

logRollTimeMillis (시간 단위), log.roll.jitter.ms 속성을 뺀 최대 jitter입니다.

log.roll.jitter.ms

유형: long
default: null
Importance: high
Dynamic update: cluster-wide

logRollTimeMillis(밀리초)에서 뺀 최대 jitter입니다. 설정되지 않은 경우 log.roll.jitter.hours의 값이 사용됩니다.

log.roll.ms

유형: long
default: null
Importance: high
Dynamic update: cluster-wide

새 로그 세그먼트가 롤아웃되기 전의 최대 시간(밀리초)입니다. 설정되지 않은 경우 log.roll.hours의 값이 사용됩니다.

log.segment.bytes

유형: int
기본값: 1073741824 (1gibibyte)
유효한 값: [14,…​]
Importance: high
동적 업데이트: 클러스터 전체

단일 로그 파일의 최대 크기입니다.

log.segment.delete.delay.ms

유형: long
기본값: 60000 (1 minute)
유효한 값: [0,…​]
중요도: high
동적 업데이트: 클러스터 전체

파일 시스템에서 파일을 삭제하기 전에 대기하는 시간입니다.

message.max.bytes

유형: int
기본값: 1048588
유효한 값: [0,…​]
중요도: high
동적 업데이트: 클러스터 전체

Kafka에서 허용하는 가장 큰 레코드 배치 크기입니다(압축이 활성화된 경우 압축 후). 이 문제가 증가되고 0.10.2보다 오래된 소비자가 있는 경우 이 대규모 레코드 일괄 처리를 가져올 수 있도록 소비자의 가져오기 크기도 늘려야 합니다. 최신 메시지 형식 버전에서는 효율성을 위해 항상 레코드를 일괄 처리로 그룹화합니다. 이전 메시지 형식 버전에서는 압축되지 않은 레코드가 일괄 처리로 그룹화되지 않으며 이 제한은 단일 레코드에만 적용됩니다. 이는 주제 수준 max.message.bytes 구성을 사용하여 주제별로 설정할 수 있습니다.

metadata.log.dir

type: string
default: null
Importance: high
Dynamic update: read-only

이 구성은 KRaft 모드에서 클러스터의 메타데이터 로그를 배치할 위치를 결정합니다. 설정되지 않은 경우 메타데이터 로그는 log.dirs의 첫 번째 로그 디렉터리에 배치됩니다.

metadata.log.max.record.bytes.between.snapshots

유형: long
기본값: 20971520
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

이는 새 스냅샷을 생성하기 전에 필요한 최신 스냅샷과 high-watermark 간의 로그의 최대 바이트 수입니다.

metadata.log.segment.bytes

유형: int
기본값: 1073741824 (1gibibyte)
유효한 값: [12,…​]
Importance: high
동적 업데이트: 읽기 전용

단일 메타데이터 로그 파일의 최대 크기입니다.

metadata.log.segment.ms

유형: long
Default: 604800000 (7 days)
Importance: high
Dynamic update: read-only

새 메타데이터 로그 파일이 롤아웃되기 전의 최대 시간(밀리초)입니다.

metadata.max.retention.bytes

유형: long
default: -1
Importance: high
Dynamic update: read-only

이전 스냅샷 및 로그 파일을 삭제하기 전에 메타데이터 로그 및 스냅샷의 최대 결합된 크기입니다. 로그를 삭제하기 전에 하나 이상의 스냅샷이 있어야 하므로 이는 소프트 제한입니다.

metadata.max.retention.ms

유형: long
Default: 604800000 (7 days)
Importance: high
Dynamic update: read-only

메타데이터 로그 파일 또는 스냅샷을 삭제하기 전에 유지하는 시간(밀리초)입니다. 로그를 삭제하기 전에 하나 이상의 스냅샷이 있어야 하므로 이는 소프트 제한입니다.

min.insync.replicas

유형: int
default: 1
유효한 값: [1,…​]
Importance: high
동적 업데이트: 클러스터 전체

생산자가 소켓을 "all"(또는 "-1")로 설정하면 min.insync.replicas는 쓰기가 성공으로 간주되기 위해 쓰기를 승인해야 하는 최소 복제본 수를 지정합니다. 이 최소값을 충족할 수 없는 경우 생산자는 예외를 발생시킵니다(NotEnoughReplicas 또는 NotEnoughReplicasAfterAppend). min.insync.replicas 및 acks를 함께 사용하면 더 큰 지속성 보장을 적용할 수 있습니다. 일반적인 시나리오는 복제 인수가 3인 주제를 만들고 min.insync.replicas를 2로 설정하고, acks of "all"을 생성하는 것입니다. 이렇게 하면 대부분의 복제본에서 쓰기를 수신하지 못하는 경우 생산자가 예외를 발생시킵니다.

node.id

유형: int
Default: -1
Importance: high
Dynamic update: read-only

process.roles 가 비어 있지 않을 때 이 프로세스가 수행하는 역할과 연결된 노드 ID입니다. 이는 KRaft 모드에서 실행할 때 필요한 구성입니다.

num.io.threads

유형: int
기본값: 8
유효한 값: [1,…​]
Importance: high
동적 업데이트: 클러스터 전체

서버가 요청을 처리하는 데 사용하는 스레드 수이며 디스크 I/O를 포함할 수 있습니다.

num.network.threads

유형: int
default: 3
유효한 값: [1,…​]
Importance: high
동적 업데이트: 클러스터 전체

서버가 네트워크에서 요청을 수신하고 네트워크에 응답을 전송하는 데 사용하는 스레드 수입니다.

num.recovery.threads.per.data.dir

유형: int
default: 1
유효한 값: [1,…​]
Importance: high
동적 업데이트: 클러스터 전체

시작 시 로그 복구 및 종료 시 플러시에 사용할 데이터 디렉터리당 스레드 수입니다.

num.replica.alter.log.dirs.threads

유형: int
default: null
Importance: high
Dynamic update: read-only

로그 디렉토리 간에 복제본을 이동할 수 있는 스레드 수로, 디스크 I/O를 포함할 수 있습니다.

num.replica.fetchers

유형: int
Default: 1
Importance: high
Dynamic update: cluster-wide

소스 브로커에서 메시지를 복제하는 데 사용되는 가져오기 스레드 수입니다. 이 값을 늘리면 후속 브로커에서 I/O 병렬 처리 수준이 증가할 수 있습니다.

offset.metadata.max.bytes

유형: int
Default: 4096 (4kibibytes)
Importance: high
Dynamic update: read-only

오프셋 커밋과 연결된 메타데이터 항목의 최대 크기입니다.

offsets.commit.required.acks

유형: short
기본값: -1
Importance: high
Dynamic update: read-only

커밋을 승인하기 전에 필요한 양말입니다. 일반적으로 기본값(-1)을 재정의해서는 안 됩니다.

offsets.commit.timeout.ms

유형: int
Default: 5000 (5 seconds)
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

오프셋된 주제의 모든 복제본이 커밋을 수신하거나 이 시간 초과에 도달할 때까지 오프셋 커밋이 지연됩니다. 이는 생산자 요청 시간 초과와 유사합니다.

offsets.load.buffer.size

유형: int
기본값: 5242880
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

오프셋을 캐시에 로드할 때 오프셋 세그먼트에서 읽기 위한 배치 크기입니다(기록이 너무 큰 경우soft-limit, 재정의).

offsets.retention.check.interval.ms

유형: long
기본값: 600000(10분)
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

오래된 오프셋을 확인하는 빈도입니다.

offsets.retention.minutes

type: int
default: 10080
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

소비자 그룹이 모든 소비자(예: 비어 있음)를 손실하면 취소되기 전에 이 보존 기간 동안 오프셋이 유지됩니다. 독립 실행형 소비자의 경우(수동 할당 사용) 마지막 커밋 시간과 이 보존 기간이 지나면 오프셋이 만료됩니다.

offsets.topic.compression.codec

유형: int
Default: 0
Importance: high
Dynamic update: read-only

오프셋 항목에 대한 압축 코드c - 압축이 "atomic" 커밋을 달성하는 데 사용될 수 있습니다.

offsets.topic.num.partitions

유형: int
default: 50
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

오프셋 커밋 주제의 파티션 수(배포 후 변경되지 않음).

offsets.topic.replication.factor

유형: short
기본값: 3
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

오프셋 주제의 복제 요소(가용성을 보장하기 위해 더 높은 설정). 클러스터 크기가 이 복제 요인 요구 사항을 충족할 때까지 내부 주제 생성이 실패합니다.

offsets.topic.segment.bytes

유형: int
기본값: 104857600(100 메비바이트)
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

더 빠른 로그 압축 및 캐시 로드를 용이하게 하려면 오프셋 주제 세그먼트 바이트는 상대적으로 작아야 합니다.

process.roles

type: list
default: ""
유효한 값: [broker, controller]
Importance: high
동적 업데이트: 읽기 전용

이 프로세스가 수행하는 역할: 'broker', 'controller' 또는 'broker,controller'가 둘 다 있는 경우입니다. 이 구성은 KRaft(Kafka Raft) 모드의 클러스터(파운드 대신)에만 적용됩니다. Zookeeper 클러스터에 대해 이 구성을 정의되지 않았거나 비워 둡니다.

queued.max.requests

type: int
Default: 500
Valid Values: [1,…​]
Importance: high
Dynamic update: read-only

네트워크 스레드를 차단하기 전에 데이터 플레인에 허용되는 대기 중인 요청 수입니다.

replica.fetch.min.bytes

유형: int
Default: 1
Importance: high
Dynamic update: read-only

각 가져오기 응답에 예상되는 최소 바이트 수입니다. 바이트가 충분하지 않은 경우 replica.fetch.wait.max.ms (broker config)까지 기다립니다.

replica.fetch.wait.max.ms

유형: int
Default: 500
Importance: high
Dynamic update: read-only

follower 복제본에서 발행한 각 fetcher 요청에 대해 최대 대기 시간입니다. 처리량이 낮은 항목에 대해 ISR을 자주 축소하지 않도록 이 값은 항상 replica.lag.time.max.ms보다 작아야 합니다.

replica.high.watermark.checkpoint.interval.ms

유형: long
Default: 5000 (5초)
중요: high
Dynamic update: read-only

높은 워터마크가 디스크에 저장되는 빈도입니다.

replica.lag.time.max.ms

유형: long
기본값: 30000(30초)
중요도: high
동적 업데이트: 읽기 전용

후속자가 가져오기 요청을 보내지 않았거나 적어도 현재 리더 로그 엔드 오프셋까지 소비하지 않은 경우 리더는 isr에서 후속 요청을 제거합니다.

replica.socket.receive.buffer.bytes

유형: int
기본값: 65536 (64 kibibytes)
중요성: high
동적 업데이트: 읽기 전용

소켓은 네트워크 요청에 대한 수신 버퍼입니다.

replica.socket.timeout.ms

유형: int
Default: 30000 (30 seconds)
Importance: high
Dynamic update: read-only

네트워크 요청에 대한 소켓 제한 시간입니다. 해당 값은 replica.fetch.wait.max.ms 이상이어야 합니다.

request.timeout.ms

유형: int
Default: 30000 (30 seconds)
Importance: high
Dynamic update: read-only

구성은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어합니다. 시간 초과가 경과하기 전에 응답을 수신하지 않으면 필요한 경우 클라이언트가 요청을 다시 전송하거나 재시도가 소진되면 요청을 다시 보냅니다.

sasl.mechanism.controller.protocol

유형: 문자열
기본값: GSSAPI
Importance: high
Dynamic update: read-only

컨트롤러와의 통신에 사용되는 SASL 메커니즘입니다. 기본값은 GSSAPI입니다.

socket.receive.buffer.bytes

유형: int
Default: 102400 (100 kibibytes)
Importance: high
Dynamic update: read-only

소켓 서버 소켓의 SO_RCVBUF 버퍼입니다. 값이 -1이면 OS 기본값이 사용됩니다.

socket.request.max.bytes

유형: int
기본값: 104857600(100 메비바이트)
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

소켓 요청의 최대 바이트 수입니다.

socket.send.buffer.bytes

유형: int
Default: 102400 (100 kibibytes)
Importance: high
Dynamic update: read-only

소켓 서버 소켓의 SO_SNDBUF 버퍼입니다. 값이 -1이면 OS 기본값이 사용됩니다.

transaction.max.timeout.ms

유형: int
기본값: 900000 (15 분)
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

트랜잭션에 허용되는 최대 시간 초과입니다. 클라이언트의 요청된 트랜잭션 시간이 이 값을 초과하면 브로커는 InitProducerIdRequest에서 오류를 반환합니다. 이렇게 하면 클라이언트가 시간 초과가 너무 커지므로 트랜잭션에 포함된 항목에서 읽는 모든 소비자를 중단할 수 있습니다.

transaction.state.log.load.buffer.size

유형: int
기본값: 5242880
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

생산자 ID 및 트랜잭션을 캐시에 로드할 때 트랜잭션 로그 세그먼트에서 읽기 위한 배치 크기입니다(기록이 너무 큰 경우soft-limit, 재정의).

transaction.state.log.min.isr

유형: int
default: 2
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

트랜잭션 주제의 min.insync.replicas 구성을 덮어씁니다.

transaction.state.log.num.partitions

유형: int
default: 50
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

트랜잭션 주제의 파티션 수(배포 후 변경되지 않음).

transaction.state.log.replication.factor

유형: short
기본값: 3
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

트랜잭션 주제의 복제 요소(가용성을 보장하기 위해 더 높은 설정). 클러스터 크기가 이 복제 요인 요구 사항을 충족할 때까지 내부 주제 생성이 실패합니다.

transaction.state.log.segment.bytes

유형: int
기본값: 104857600(100 메비바이트)
유효한 값: [1,…​]
Importance: high
동적 업데이트: 읽기 전용

더 빠른 로그 압축 및 캐시 로드를 용이하게 하려면 트랜잭션 주제 세그먼트 바이트는 비교적 작게 유지되어야 합니다.

transactional.id.expiration.ms

유형: int
Default: 604800000 (7 days)
유효한 값: [1,…​]
Importance: high
Dynamic update: read-only

트랜잭션 코디네이터가 트랜잭션 ID를 만료하기 전에 현재 트랜잭션에 대한 트랜잭션 상태를 업데이트하지 않고 대기하는 ms의 시간입니다. 이 설정은 또한 생산자 ID 만료에 영향을 미칩니다. 지정된 생산자 ID를 사용하여 마지막 쓰기 후 경과하면 생산자 ID가 만료됩니다. 주제의 보존 설정으로 인해 생산자 ID에서 마지막 쓰기가 삭제되면 생산자 ID가 더 빨리 만료될 수 있습니다.

unclean.leader.election.enable

유형: 부울
기본값: false
중요성: high
동적 업데이트: 클러스터 전체

ISR 세트의 복제본이 마지막 수단으로 리더로 선택되지 않도록 활성화할지 여부를 나타내며, 이렇게 하면 데이터가 손실될 수 있습니다.

zookeeper.connect

type: string
default: null
Importance: high
Dynamic update: read-only

hostname:port 형식으로 Zoo Cryostat 연결 문자열을 지정합니다. 여기서 호스트와 포트는 Zoo Cryostat 서버의 호스트 및 포트입니다. Zoo Cryostat 머신이 다운되었을 때 다른 Zoo Cryostat 노드를 통해 연결할 수 있도록 hostname1:port1,hostname2:port2,hostname3:port3 형식으로 여러 호스트를 지정할 수도 있습니다. 서버는 또한 Zoo Cryostat 연결 문자열의 일부로 Zoo Cryostat chroot 경로를 가질 수 있으며, 이는 글로벌 Zoo Cryostat 네임스페이스의 경로 아래에 해당 데이터를 넣습니다. 예를 들어 chroot 경로 /chroot/path 를 제공하려면 연결 문자열을 hostname1:port1,hostname2:port2,hostname3:port3/chroot/path 로 지정합니다.

zookeeper.connection.timeout.ms

유형: int
default: null
Importance: high
Dynamic update: read-only

클라이언트가 Zookeeper에 대한 연결을 설정하는 데 대기하는 최대 시간입니다. 설정되지 않은 경우 zookeeper.session.timeout.ms의 값이 사용됩니다.

zookeeper.max.in.flight.requests

유형: int
기본값: 10
유효한 값: [1,…​]
중요도: high
동적 업데이트: 읽기 전용

클라이언트가 차단하기 전에 Zookeeper에 전송할 승인되지 않은 요청의 최대 수입니다.

zookeeper.session.timeout.ms

유형: int
기본값: 18000(18초)
중요도: high
동적 업데이트: 읽기 전용

Zookeeper 세션 시간 초과

zookeeper.set.acl

유형: 부울
기본값: false
중요성: high
Dynamic update: read-only

보안 ACL을 사용하도록 클라이언트를 설정합니다.

broker.heartbeat.interval.ms

유형: int
기본값: 2000(2초)
중요도: 중간
동적 업데이트: 읽기 전용

브로커 하트비트 사이의 시간(밀리초)입니다. KRaft 모드에서 실행할 때 사용됩니다.

broker.id.generation.enable

type: boolean
Default: true
Importance: medium
Dynamic update: read-only

서버에서 자동 브로커 ID 생성을 활성화합니다. reserved.broker.max.id에 대해 구성된 값을 검토해야 합니다.

broker.rack

type: string
Default: null
Importance: medium
Dynamic update: read-only

브로커의 Rack of the Broker 이는 랙에서 내결함성에 대한 복제 할당을 인식하는 데 사용됩니다. 예: RACK1,us-east-1d.

broker.session.timeout.ms

유형: int
Default: 9000 (9 seconds)
Importance: medium
Dynamic update: read-only

하트비트가 이루어지지 않은 경우 브로커 리스가 지속되는 시간(밀리초)입니다. KRaft 모드에서 실행할 때 사용됩니다.

connections.max.idle.ms

유형: long
기본값: 600000(10분)
중요도: 중간
동적 업데이트: 읽기 전용

유휴 연결 시간 초과: 서버 소켓 프로세서 스레드는 이 이상의 유휴 연결을 종료합니다.

connections.max.reauth.ms

type: long
Default: 0
Importance: medium
Dynamic update: read-only

명시적으로 양수로 설정되는 경우(기본값은 양수가 아님), 구성된 값을 초과하지 않는 세션 수명은 v2.2.0 이상 클라이언트에 전달됩니다. 브로커는 세션 수명 내에 재인증되지 않은 이러한 연결을 끊고 나중에 재인증 이외의 용도로 사용됩니다. 구성 이름 앞에는 필요한 경우 리스너 접두사 및 SASL 메커니즘 이름 접두어를 사용할 수 있습니다. 예를 들어 listener.name.sasl_ssl.oauthbearer.connections.max.reauth.ms=3600000입니다.

controlled.shutdown.enable

type: boolean
Default: true
Importance: medium
Dynamic update: read-only

서버의 제어된 종료를 활성화합니다.

controlled.shutdown.max.retries

유형: int
Default: 3
Importance: medium
Dynamic update: read-only

제어 종료는 여러 가지 이유로 실패할 수 있습니다. 이렇게 하면 이러한 오류가 발생할 때 재시도 횟수가 결정됩니다.

controlled.shutdown.retry.backoff.ms

유형: long
Default: 5000 (5초)
중요: 중간
동적 업데이트: 읽기 전용

각 재시도 전에 시스템은 이전 실패 (Controller fail over, replica delay 등)를 발생시킨 상태에서 복구할 시간이 필요합니다. 이 구성에서는 재시도하기 전에 대기할 시간을 결정합니다.

controller.quorum.append.linger.ms

유형: int
Default: 25
Importance: medium
Dynamic update: read-only

리더가 디스크에 플러시하기 전에 누적 쓰기를 기다리는 시간(밀리초)입니다.

controller.quorum.request.timeout.ms

유형: int
기본값: 2000(2초)
중요도: 중간
동적 업데이트: 읽기 전용

구성은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어합니다. 시간 초과가 경과하기 전에 응답을 수신하지 않으면 필요한 경우 클라이언트가 요청을 다시 전송하거나 재시도가 소진되면 요청을 다시 보냅니다.

controller.socket.timeout.ms

유형: int
기본값: 30000(30초)
중요도: 매체
동적 업데이트: 읽기 전용

controller-to-broker 채널의 소켓 시간 초과입니다.

default.replication.factor

유형: int
Default: 1
Importance: medium
Dynamic update: read-only

자동으로 생성된 주제의 기본 복제 요인입니다.

delegation.token.expiry.time.ms

유형: long
기본값: 86400000 (1 day)
유효한 값: [1,…​]
중요도: 중간
동적 업데이트: 읽기 전용

토큰을 갱신해야 하기 전에 토큰 유효 시간(miliseconds)입니다. 기본값은 1일입니다.

delegation.token.master.key

유형: password
Default: null
Importance: medium
Dynamic update: read-only

DEPRECATED: 이 구성 대신 사용해야 하는 delegation.token.secret.key의 별칭입니다.

delegation.token.max.lifetime.ms

유형: long
Default: 604800000 (7 days)
유효한 값: [1,…​]
Importance: medium
Dynamic update: read-only

토큰은 최대 수명을 가지며 더 이상 갱신할 수 없습니다. 기본값은 7일입니다.

delegation.token.secret.key

유형: password
Default: null
Importance: medium
Dynamic update: read-only

위임 토큰을 생성하고 확인하는 시크릿 키입니다. 동일한 키는 모든 브로커에 걸쳐 구성되어야 합니다. 키를 설정하지 않거나 빈 문자열로 설정하면 브로커에서 위임 토큰 지원을 비활성화합니다.

delete.records.purgatory.purge.interval.requests

유형: int
Default: 1
Importance: medium
Dynamic update: read-only

삭제 레코드의 제거 간격(요청 수)입니다.

fetch.max.bytes

유형: int
기본값: 57671680 (55 메비바이트)
유효한 값: [1024,…​]
가져오기: 중간
동적 업데이트: 읽기 전용

fetch 요청에 대해 반환할 최대 바이트 수입니다. 1024 이상이어야 합니다.

fetch.purgatory.purge.interval.requests

유형: int
Default: 1000
Importance: medium
Dynamic update: read-only

fetch 요청 시행의 제거 간격(요청 수)입니다.

group.initial.rebalance.delay.ms

유형: int
Default: 3000 (3초)
Importance: medium
Dynamic update: read-only

그룹 코디네이터가 첫 번째 리밸런스를 수행하기 전에 더 많은 소비자가 새 그룹에 참여할 때까지 기다립니다. 지연 시간이 길어지면 잠재적으로 리밸런스가 줄어들지만 처리가 시작될 때까지 시간이 증가합니다.

group.max.session.timeout.ms

유형: int
Default: 1800000 (30 분)
중요도: 중간
동적 업데이트: 읽기 전용

등록된 소비자에 대해 허용되는 최대 세션 시간 초과입니다. 시간 초과 시간이 길어짐에 따라 소비자가 오류를 감지하는 데 더 오랜 시간 동안 하트비트 간에 메시지를 처리할 수 있는 시간을 확보할 수 있습니다.

group.max.size

유형: int
기본값: 2147483647
유효한 값: [1,…​]
중요도: 중간
동적 업데이트: 읽기 전용

단일 소비자 그룹이 수용할 수 있는 최대 소비자 수입니다.

group.min.session.timeout.ms

유형: int
기본값: 6000 (6 초)
중요도: 중간
동적 업데이트: 읽기 전용

등록된 소비자에 대해 허용되는 최소 세션 시간 초과입니다. 짧은 시간 초과로 인해 더 빈번한 소비자 하트비 상태 발생 시 실패 탐지가 빨라지므로 브로커 리소스를 덮어쓸 수 있습니다.

initial.broker.registration.timeout.ms

유형: int
Default: 60000 (1 minute)
Importance: medium
Dynamic update: read-only

처음에 컨트롤러 쿼럼에 등록할 때 실패로 선언하고 브로커 프로세스를 종료하기 전에 대기할 시간(밀리초)입니다.

inter.broker.listener.name

type: string
Default: null
Importance: medium
Dynamic update: read-only

브로커 간 통신에 사용되는 리스너 이름입니다. 설정되지 않은 경우 리스너 이름은 security.inter.broker.protocol에 의해 정의됩니다. 이 및 security.broker.protocol 속성을 동시에 설정하는 것은 오류입니다.

inter.broker.protocol.version

유형: 문자열
기본값: 3.0-IV1
유효한 값: [0.8.0, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV0, 0.10.0-IV0, 0.10.1-IV0, 0.10.1-IV2, 0.10.1-IV2, 0.10.1-IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV1, 0.10.0-IV0, 0.10.0 0.11.0-iv2, 1.0-iv0, 1.1-iv0, 2.0-iv0, 2.0-iv0, 2.0-iv0, 2.1-iv0, 2.1-iv2, 2.2-iv1, 2.2-iv1, 2.3-iv0, 2.3-iv1, 2.4-iv0, 2.4-iv0, 2.4-iv0, 2.0-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv2, 2.8-IV0, 2.8-IV1, 3.0-IV0, 3.0-IV1]
중요도: 매체
동적 업데이트: 읽기 전용

사용할 inter-broker 프로토콜 버전을 지정합니다. 일반적으로 모든 브로커가 새 버전으로 업그레이드된 후 이 문제가 발생합니다. 일부 유효한 값의 예로는 0.8.0, 0.8.1, 0.8.1.1, 0.8.2, 0.8.2.0, 0.8.2.1, 0.9.0.0, 0.9.0.1 Check ApiVersion이 있습니다.

log.cleaner.backoff.ms

유형: long
Default: 15000 (15 seconds)
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 클러스터 전체

정리할 로그가 없을 때 유휴 상태의 시간입니다.

log.cleaner.dedupe.buffer.size

유형: long
기본값: 134217728
Importance: medium
Dynamic update: cluster-wide

모든 정리된 스레드에서 로그 중복 제거에 사용되는 총 메모리입니다.

log.cleaner.delete.retention.ms

유형: long
기본값: 86400000 (1 day)
중요도: 매체
동적 업데이트: 클러스터 전체

레코드 삭제 기간은 얼마나 됩니까?

log.cleaner.enable

type: boolean
Default: true
Importance: medium
Dynamic update: read-only

로그 정리 프로세스를 서버에서 실행할 수 있도록 활성화합니다. 내부 오프셋 주제를 포함하여 cleanup.policy=compact과 함께 주제를 사용하는 경우 활성화해야 합니다. 비활성화된 경우 해당 주제는 압축되지 않고 크기가 지속적으로 증가합니다.

log.cleaner.io.buffer.load.factor

유형: double
Default: 0.9
Importance: medium
Dynamic update: cluster-wide

로그 정리 dedupe 버퍼 로드 요소. dedupe 버퍼가 가득 찬 백분율이 될 수 있습니다. 값이 클수록 더 많은 로그를 한 번에 정리할 수 있지만 해시 충돌이 발생할 수 있습니다.

log.cleaner.io.buffer.size

유형: int
기본값: 524288
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 클러스터 전체

모든 정리된 스레드에서 로그 정리 I/O 버퍼에 사용되는 총 메모리입니다.

log.cleaner.io.max.bytes.per.second

유형: double
기본값: 1.7976931348623157E308
중요: 중간
동적 업데이트: 클러스터 전체

로그 정리기가 제한되므로 읽기 및 쓰기 i/o의 합계가 평균 이 값보다 작아집니다.

log.cleaner.max.compaction.lag.ms

유형: long
기본값: 92233720368775807
중요: 중간
동적 업데이트: 클러스터 전체

메시지가 로그에 압축할 수 없는 최대 시간입니다. 압축되는 로그에만 적용할 수 있습니다.

log.cleaner.min.cleanable.ratio

유형: 두 번
기본값: 0.5
중요도: 중간
동적 업데이트: 클러스터 전체

로그의 총 로그에 대한 더티 로그의 최소 비율로 정리할 수 있습니다. log.cleaner.max.compaction.lag.ms 또는 log.cleaner.min.compaction.lag.ms 구성도 지정되면 로그 압축기는 로그를 즉시 압축할 수 있는 것으로 간주합니다. (i) 더티 비율 임계값이 충족되고 로그는 최소 log.cleaner.min.compaction.glams, durationlams에 대한 더티(uncompacted) 레코드가 있는 것으로 간주합니다. 또는 (ii) 로그에 대부분의 log.cleaner.max.compaction.lag.ms 기간에 대해 더티(복합되지 않음) 레코드가 있는 경우

log.cleaner.min.compaction.lag.ms

유형: long
기본값: 0
Importance: medium
Dynamic update: cluster-wide

메시지가 로그에 컴파일되지 않은 상태로 유지되는 최소 시간입니다. 압축되는 로그에만 적용할 수 있습니다.

log.cleaner.threads

유형: int
기본값: 1
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 클러스터 전체

로그 정리에 사용할 백그라운드 스레드 수입니다.

log.cleanup.policy

type: list
default: delete
유효한 값: [compact, delete]
Importance: medium
Dynamic update: cluster-wide

보존 창 이외의 세그먼트의 기본 정리 정책입니다. 쉼표로 구분된 유효한 정책 목록입니다. 유효한 정책은 "삭제" 및 "복제"입니다.

log.index.interval.bytes

유형: int
Default: 4096 (4kibibytes)
유효한 값: [0,…​]
Importance: medium
Dynamic update: cluster-wide

오프셋 인덱스에 항목을 추가하는 간격입니다.

log.index.size.max.bytes

유형: int
기본값: 10485760(10MB)
유효한 값: [4,…​]
Importance: medium
Dynamic update: cluster-wide

오프셋 인덱스의 최대 크기(바이트)입니다.

log.message.format.version

유형: 문자열
기본값: 3.0-IV1
유효한 값: [0.8.0, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV0, 0.10.0-IV0, 0.10.1-IV0, 0.10.1-IV2, 0.10.1-IV2, 0.10.1-IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV1, 0.10.0-IV0, 0.10.0 0.11.0-iv2, 1.0-iv0, 1.1-iv0, 2.0-iv0, 2.0-iv0, 2.0-iv0, 2.1-iv0, 2.1-iv2, 2.2-iv1, 2.2-iv1, 2.3-iv0, 2.3-iv1, 2.4-iv0, 2.4-iv0, 2.4-iv0, 2.0-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv2, 2.8-IV0, 2.8-IV1, 3.0-IV0, 3.0-IV1]
중요도: 매체
동적 업데이트: 읽기 전용

브로커가 로그에 메시지를 추가하는 데 사용할 메시지 형식 버전을 지정합니다. 값은 유효한 ApiVersion이어야 합니다. 몇 가지 예는 0.8.2, 0.9.0.0, 0.10.0, ApiVersion 확인입니다. 특정 메시지 형식 버전을 설정하면 디스크의 기존 메시지가 지정된 버전보다 작거나 같은지 사용자가 인증하고 있습니다. 이 값을 잘못 설정하면 이전 버전의 소비자가 이해할 수 없는 형식의 메시지를 수신하므로 중단됩니다.

log.message.timestamp.difference.max.ms

유형: long
기본값: 92233720368775807
중요: 중간
동적 업데이트: 클러스터 전체

브로커가 메시지를 수신할 때 타임스탬프와 메시지에 지정된 타임스탬프 간에 허용되는 최대 차이점입니다. log.message.timestamp.type=CreateTime은 타임스탬프의 차이가 이 임계값을 초과하면 메시지가 거부됩니다. log.message.timestamp.type=LogAppendTime.

log.message.timestamp.type

유형: 문자열
기본값: CreateTime
유효한 값: [CreateTime, LogAppendTime]
Importance: medium
Dynamic update: cluster-wide

메시지의 타임 스탬프가 메시지 생성 시간인지 또는 로그 추가 시간을 정의합니다. 값은 CreateTime 또는 LogAppendTime 이어야 합니다.

log.preallocate

유형: 부울
기본값: false
Importance: medium
Dynamic update: cluster-wide

새 세그먼트를 만들 때 파일을 미리 할당해야 합니까? Windows에서 Kafka를 사용하는 경우 true로 설정해야 합니다.

log.retention.check.interval.ms

유형: long
기본값: 300000 (5 분)
유효한 값: [1,…​]
중요도: 중간
동적 업데이트: 읽기 전용

로그 정리기가 로그를 삭제할 수 있는지 확인하는 빈도(밀리초)입니다.

max.connection.creation.rate

유형: int
기본값: 2147483647
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 클러스터 전체

브로커에서 언제든지 허용하는 최대 연결 생성 속도입니다. 리스너 수준 제한은 리스너 접두사를 사용하여 구성 이름을 접두사로 지정하여 구성할 수도 있습니다(예: listener.name.internal.max.connection.rate.Broker-wide 연결 속도 제한은 애플리케이션 요구 사항에 따라 브로커 용량을 기반으로 구성되어야 합니다. broker 리스너를 제외하고 리스너 또는 브로커 제한에 도달하면 새 연결이 제한됩니다. broker 리스너 간 연결은 리스너 수준 제한에 도달할 때만 제한됩니다.

max.connections

유형: int
기본값: 2147483647
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 클러스터 전체

브로커에서 언제든지 허용하는 최대 연결 수입니다. 이 제한은 max.connections.per.ip를 사용하여 구성된 모든 per-ip 제한에 더하여 적용됩니다. 리스너 수준 제한은 구성 이름 앞에 리스너 접두사(예: listener.name.internal.max.connections )를 추가하여 구성할 수도 있습니다. 브로커 전체 제한은 브로커 용량을 기반으로 구성되어야 하지만 애플리케이션 요구 사항에 따라 리스너 제한을 구성해야 합니다. 리스너 또는 브로커 제한에 도달하면 새 연결이 차단됩니다. 브로커 전체 제한에 도달한 경우에도broker 리스너의 연결이 허용됩니다. 이 경우 다른 리스너에서 가장 최근에 사용된 연결이 종료됩니다.

max.connections.per.ip

유형: int
기본값: 2147483647
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 클러스터 전체

각 IP 주소에서 허용하는 최대 연결 수입니다. max.connections.per.ip.overrides 속성을 사용하여 재정의하는 경우 0으로 설정할 수 있습니다. 제한에 도달하면 ip 주소의 새 연결이 삭제됩니다.

max.connections.per.ip.overrides

type: string
Default: ""
Importance: medium
Dynamic update: cluster-wide

콤마로 구분된 IP 또는 호스트 이름 목록은 기본 최대 연결 수를 덮어씁니다. 예제 값은 "hostName:100,127.0.0.1:200"입니다.

max.incremental.fetch.session.cache.slots

유형: int
기본값: 1000
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 읽기 전용

유지 관리할 최대 증분 가져오기 세션 수입니다.

num.partitions

유형: int
default: 1
유효한 값: [1,…​]
Importance: medium
Dynamic update: read-only

주제당 기본 로그 파티션 수입니다.

password.encoder.old.secret

유형: password
Default: null
Importance: medium
Dynamic update: read-only

동적으로 구성된 암호를 인코딩하는 데 사용된 이전 시크릿입니다. 이는 시크릿을 업데이트할 때만 필요합니다. 지정하면 동적으로 인코딩된 모든 암호가 이 이전 시크릿을 사용하여 디코딩되고 브로커가 시작될 때 password.encoder.secret을 사용하여 다시 인코딩됩니다.

password.encoder.secret

유형: password
Default: null
Importance: medium
Dynamic update: read-only

이 브로커에 대해 동적으로 구성된 암호를 인코딩하는 데 사용되는 시크릿입니다.

principal.builder.class

유형: class
Default: apache.kafka.common.security.security.authenticator.DefaultKafkaPrincipalBuilder
Importance: medium
Dynamic update: per-broker

권한 부여 중에 사용되는 KafkaPrincipalBuilder 인터페이스를 구현하는 데 사용되는 정규화된 클래스의 이름입니다. 보안 주체 빌더가 정의되지 않은 경우 기본 동작은 사용 중인 보안 프로토콜에 따라 달라집니다. SSL 인증의 경우 주체는 클라이언트 인증서와 고유 이름에 적용된 ssl.principal.mapping.rules 에서 정의한 규칙을 사용하여 파생됩니다. 그렇지 않으면 클라이언트 인증이 필요하지 않은 경우 주 이름은 ANONYMOUS가 됩니다. SASL 인증의 경우 GSSAPI가 사용 중인 경우 sasl.kerberos.principal.to.local.rules 에서 정의한 규칙을 사용하고 다른 메커니즘에 대해 SASL 인증 ID를 사용하여 파생됩니다. PLAINTEXT의 경우 주체는 ANONYMOUS가 됩니다.

producer.purgatory.purge.interval.requests

유형: int
Default: 1000
Importance: medium
Dynamic update: read-only

생산자 요청 순차(요청 수)의 제거 간격(요청 수)입니다.

queued.max.request.bytes

유형: long
기본값: -1
Importance: medium
Dynamic update: read-only

더 이상 요청을 읽지 않기 전에 허용되는 대기 중인 바이트 수입니다.

replica.fetch.backoff.ms

유형: int
기본값: 1000 (1 second)
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 읽기 전용

파티션 가져오기 오류가 발생할 때 유휴 상태로 설정할 시간입니다.

replica.fetch.max.bytes

유형: int
기본값: 1048576 (1bibyte)
유효한 값: [0,…​]
가져오기: 중간
동적 업데이트: 읽기 전용

각 파티션에 대해 가져올 메시지의 바이트 수입니다. 이는 절대 최대값이 아니며, pull의 첫 번째 레코드 배치가 이 값보다 크면 레코드 일괄 처리가 여전히 반환되어 진행 상황을 확인할 수 있습니다. 브로커가 허용하는 최대 레코드 배치 크기는 message.max.bytes (broker config) 또는 max.message.bytes (topic config)를 통해 정의됩니다.

replica.fetch.response.max.bytes

유형: int
기본값: 10485760(10MB)
유효한 값: [0,…​]
Importance: medium
Dynamic update: read-only

전체 가져오기 응답에 예상되는 최대 바이트 수입니다. 레코드는 일괄적으로 가져오고, 비어 있지 않은 첫 번째 파티션의 첫 번째 레코드 배치가 이 값보다 크면 레코드 배치가 계속 반환되어 진행 상황을 확인할 수 있습니다. 따라서 이는 절대 최대값이 아닙니다. 브로커가 허용하는 최대 레코드 배치 크기는 message.max.bytes (broker config) 또는 max.message.bytes (topic config)를 통해 정의됩니다.

replica.selector.class

type: string
Default: null
Importance: medium
Dynamic update: read-only

ReplicaSelector를 구현하는 정규화된 클래스 이름입니다. 브로커에서 선호하는 읽기 복제본을 찾는 데 사용됩니다. 기본적으로 리더를 반환하는 구현을 사용합니다.

reserved.broker.max.id

유형: int
기본값: 1000
유효한 값: [0,…​]
중요도: 중간
동적 업데이트: 읽기 전용

broker.id에 사용할 수 있는 최대 번호입니다.

sasl.client.callback.handler.class

유형: class
Default: null
Importance: medium
Dynamic update: read-only

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 클라이언트 콜백 처리기 클래스의 정규화된 이름입니다.

sasl.enabled.mechanisms

type: list
Default: GSSAPI
Importance: medium
Dynamic update: per-broker

Kafka 서버에서 활성화된 SASL 메커니즘 목록입니다. 목록에는 보안 공급자를 사용할 수 있는 모든 메커니즘이 포함될 수 있습니다. 기본적으로 GSSAPI만 활성화됩니다.

sasl.jaas.config

유형: password
Default: null
Importance: medium
Dynamic update: per-broker

JAAS 구성 파일에서 사용하는 형식의 SASL 연결에 대한 JAAS 로그인 컨텍스트 매개변수입니다. JAAS 구성 파일 형식은 여기에 설명되어 있습니다. 값 형식은 loginModuleClass controlFlag (optionName=optionValue)*; 입니다. 브로커의 경우 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule이 필요합니다.

sasl.kerberos.kinit.cmd

type: string
Default: /usr/bin/kinit
Importance: medium
Dynamic update: per-broker

Kerberos kinit 명령 경로입니다.

sasl.kerberos.min.time.before.relogin

유형: long
기본값: 60000
Importance: medium
Dynamic update: per-broker

새로 고침 시도 사이의 로그인 스레드 수면 시간입니다.

sasl.kerberos.principal.to.local.rules

type: list
default: DEFAULT
Importance: medium
Dynamic update: per-broker

보안 주체 이름에서 짧은 이름(일반적으로 운영 체제 사용자 이름)으로 매핑하기 위한 규칙 목록입니다. 규칙은 순서대로 평가되며 보안 주체 이름과 일치하는 첫 번째 규칙은 짧은 이름에 매핑됩니다. 목록의 이후 규칙은 무시됩니다. 기본적으로 {username}/{hostname}@{REALM} 형식의 주체 이름은 {username}에 매핑됩니다. 형식에 대한 자세한 내용은 보안 권한 부여 및 acl을 참조하십시오. KafkaPrincipalBuilder의 확장 기능이 principal.builder.class 구성에서 제공하는 경우 이 구성은 무시됩니다.

sasl.kerberos.service.name

type: string
default: null
Importance: medium
Dynamic update: per-broker

Kafka가 실행되는 Kerberos 주체 이름입니다. Kafka의 JAAS config 또는 Kafka의 config에서 정의할 수 있습니다.

sasl.kerberos.ticket.renew.jitter

유형: 두 번
기본값: 0.05
Importance: medium
Dynamic update: per-broker

갱신 시간에 임의 지터의 백분율이 추가되었습니다.

sasl.kerberos.ticket.renew.window.factor

유형: double
Default: 0.8
Importance: medium
Dynamic update: per-broker

로그인 스레드는 지정된 시간 요소가 마지막으로 새로 고침에서 티켓 만료로 도달할 때까지 유휴 상태가 되고 이 기간 동안 티켓을 갱신하려고 합니다.

sasl.login.callback.handler.class

유형: class
Default: null
Importance: medium
Dynamic update: read-only

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 로그인 콜백 처리기 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 콜백 처리기 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler입니다.

sasl.login.class

유형: class
Default: null
Importance: medium
Dynamic update: read-only

로그인 인터페이스를 구현하는 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 구성 앞에는 리스너 접두사와 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin입니다.

sasl.login.refresh.buffer.seconds

유형: short
Default: 300
Importance: medium
Dynamic update: per-broker

인증 정보를 새로 고칠 때 유지 관리하는 인증 정보 만료 전의 버퍼 시간(초)입니다. 새로 고침이 버퍼 초 수보다 만료되는 경우 새로 고침은 가능한 한 많은 버퍼 시간을 유지하기 위해 이동합니다. 법적 값은 0에서 3600(1시간) 사이입니다. 값이 지정되지 않은 경우 기본값 300(5분)이 사용됩니다. 이 값과 sasl.login.refresh.min.period.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.min.period.seconds

유형: short
기본값: 60
Importance: medium
Dynamic update: per-broker

로그인 새로 고침 스레드가 인증 정보를 새로 고치기 전에 대기하는 최소 시간(초)입니다. 법적 값은 0에서 900 (15 분) 사이입니다. 값이 지정되지 않은 경우 기본값 60 (1 분)이 사용됩니다. 이 값과 sasl.login.refresh.buffer.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.factor

유형: double
Default: 0.8
Importance: medium
Dynamic update: per-broker

로그인 새로 고침 스레드는 인증 정보의 수명을 기준으로 지정된 창 요인에 도달할 때까지 유휴 상태가 되어 인증 정보를 새로 고치려고 합니다. 법적 값은 0.5(50%)와 1.0(100%)을 포함합니다. 값이 지정되지 않은 경우 기본값 0.8(80%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.jitter

유형: 두 번
기본값: 0.05
Importance: medium
Dynamic update: per-broker

로그인 새로 고침 스레드의 수면 시간에 추가되는 인증 정보의 수명을 기준으로 임의 지터의 최대 양입니다. 법적 값은 0에서 0.25 (25 %) 사이이며, 값이 지정되지 않은 경우 기본값 0.05 (5%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.mechanism.inter.broker.protocol

유형: 문자열
기본값: GSSAPI
Importance: medium
Dynamic update: per-broker

broker 간 통신에 사용되는 SASL 메커니즘입니다. 기본값은 GSSAPI입니다.

sasl.server.callback.handler.class

유형: class
Default: null
Importance: medium
Dynamic update: read-only

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 서버 콜백 처리기 클래스의 정규화된 이름입니다. 서버 콜백 처리기는 소문자로 리스너 접두사 및 SASL 메커니즘 이름을 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.plain.sasl.server.callback.handler.class=com.example.CustomPlainCallbackHandler입니다.

security.inter.broker.protocol

type: string
Default: PLAINTEXT
Importance: medium
Dynamic update: read-only

브로커 간 통신에 사용되는 보안 프로토콜입니다. 유효한 값은 PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL입니다. 이 속성과 inter.broker.listener.name 속성을 동시에 설정하는 것은 오류입니다.

socket.connection.setup.timeout.max.ms

유형: long
기본값: 30000(30초)
중요도: 매체
동적 업데이트: 읽기 전용

클라이언트가 소켓 연결이 설정될 때까지 대기하는 최대 시간입니다. 연결 설정 시간 초과는 연속 연결 오류마다 이 최대값까지 기하급수적으로 증가합니다. 연결 불란을 방지하기 위해 0.2의 무작위화 요소가 시간 초과에 적용되어 계산된 값보다 20% 이하에서 20% 사이의 임의 범위가 됩니다.

socket.connection.setup.timeout.ms

유형: long
기본값: 10000(10초)
중요도: 중간
동적 업데이트: 읽기 전용

클라이언트가 소켓 연결이 설정될 때까지 대기하는 시간입니다. 시간 초과가 경과하기 전에 연결이 빌드되지 않으면 클라이언트가 소켓 채널을 종료합니다.

ssl.cipher.suites

type: list
Default: ""
Importance: medium
Dynamic update: per-broker

암호화 제품군 목록입니다. 이는 TLS 또는 SSL 네트워크 프로토콜을 사용하여 네트워크 연결에 대한 보안 설정을 협상하는 데 사용되는 인증, 암호화, MAC 및 키 교환 알고리즘의 이름이 지정된 조합입니다. 기본적으로 사용 가능한 모든 암호화 제품군이 지원됩니다.

ssl.client.auth

type: string
default: none
유효한 값: [required, requested, none]
Importance: medium
Dynamic update: per-broker

클라이언트 인증을 요청하도록 kafka 브로커를 구성합니다. 다음은 일반적인 설정입니다.

  • SSL.client.auth=required 필수 클라이언트 인증으로 설정된 경우.
  • SSL.client.auth=requested 이는 클라이언트 인증이 선택 사항임을 의미합니다. 이 옵션이 설정된 경우 클라이언트는 자체적으로 인증 정보를 제공하지 않도록 선택할 수 있습니다.
  • SSL.client.auth=none 이는 클라이언트 인증이 필요하지 않음을 의미합니다.
ssl.enabled.protocols

type: list: list
default: TLSv1.2,TLSv1.3
Importance: medium
Dynamic update: per-broker

SSL 연결에 활성화된 프로토콜 목록입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.2,TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. Java 11의 기본값을 사용하면 클라이언트와 서버는 TLSv1.2를 지원하고 그 대신 TLSv1.2를 모두 지원하는 경우 TLSv1.3을 선호합니다(적어도 TLSv1.2 이상 지원). 대부분의 경우 이 기본값은 정상이어야 합니다. ssl.protocol 의 구성 문서를 참조하십시오.

ssl.key.password

유형: password
Default: null
Importance: medium
Dynamic update: per-broker

키 저장소 파일에 있는 개인 키의 암호 또는 'ssl.keystore.key'에 지정된 PEM 키입니다. 이는 양방향 인증이 구성된 경우에만 클라이언트에 필요합니다.

ssl.keymanager.algorithm

type: string
Default: SunX509
Importance: medium
Dynamic update: per-broker

SSL 연결에 대해 키 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java Virtual Machine에 대해 구성된 키 관리자 팩토리 알고리즘입니다.

ssl.keystore.certificate.chain

유형: password
Default: null
Importance: medium
Dynamic update: per-broker

'ssl.keystore.type'에 지정된 형식의 인증서 체인입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서 목록이 있는 PEM 형식만 지원합니다.

ssl.keystore.key

유형: password
Default: null
Importance: medium
Dynamic update: per-broker

'ssl.keystore.type'에 지정된 형식의 개인 키입니다. 기본 SSL 엔진 팩토리에서는 PKCS#8 키가 있는 PEM 형식만 지원합니다. 키가 암호화된 경우 'ssl.key.password'를 사용하여 키 암호를 지정해야 합니다.

ssl.keystore.location

type: string
default: null
Importance: medium
Dynamic update: per-broker

키 저장소 파일의 위치입니다. 클라이언트의 경우 선택 사항이며 클라이언트의 양방향 인증에 사용할 수 있습니다.

ssl.keystore.password

유형: password
Default: null
Importance: medium
Dynamic update: per-broker

키 저장소 파일의 저장소 암호입니다. 이는 클라이언트에 선택 사항이며 'ssl.keystore.location'이 구성된 경우에만 필요합니다. PEM 형식에는 키 저장소 암호가 지원되지 않습니다.

ssl.keystore.type

type: string
Default: JKS
Importance: medium
Dynamic update: per-broker

키 저장소 파일의 파일 형식입니다. 클라이언트에는 선택 사항입니다.

ssl.protocol

유형: 문자열
기본값: TLSv1.3
Importance: medium
Dynamic update: per-broker

SSLContext를 생성하는 데 사용되는 SSL 프로토콜입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. 이 값은 대부분의 사용 사례에 적합해야 합니다. 최근 JVM에서 허용되는 값은 'TLSv1.2' 및 'TLSv1.3'입니다. 'TLS', 'TLSv1.1', 'SSL', 'SSLv2' 및 'SSLv3'은 이전 JVM에서 지원되지 않을 수 있지만 알려진 보안 취약점으로 인해 사용이 권장되지 않습니다. 이 구성 및 'ssl.enabled.protocols'의 기본값을 사용하면 서버가 'TLSv1.3'을 지원하지 않는 경우 클라이언트가 'TLSv1.2'로 다운그레이드됩니다. 이 구성이 'TLSv1.2'로 설정된 경우 클라이언트는 ssl.enabled.protocols의 값 중 하나이고 서버가 'TLSv1.3'만 지원하는 경우에도 'TLSv1.3'을 사용하지 않습니다.

ssl.provider

type: string
default: null
Importance: medium
Dynamic update: per-broker

SSL 연결에 사용되는 보안 공급자의 이름입니다. 기본값은 JVM의 기본 보안 공급자입니다.

ssl.trustmanager.algorithm

type: string
Default: PKIX
Importance: medium
Dynamic update: per-broker

SSL 연결에 대해 신뢰 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java 가상 머신에 대해 구성된 신뢰 관리자 팩토리 알고리즘입니다.

ssl.truststore.certificates

유형: password
Default: null
Importance: medium
Dynamic update: per-broker

'ssl.truststore.type'에서 지정한 형식의 신뢰할 수 있는 인증서입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서가 있는 PEM 형식만 지원합니다.

ssl.truststore.location

type: string
default: null
Importance: medium
Dynamic update: per-broker

신뢰 저장소 파일의 위치입니다.

ssl.truststore.password

유형: password
Default: null
Importance: medium
Dynamic update: per-broker

신뢰 저장소 파일의 암호입니다. 암호를 설정하지 않으면 구성된 신뢰 저장소 파일이 계속 사용되지만 무결성 검사가 비활성화됩니다. PEM 형식에 대해 신뢰 저장소 암호가 지원되지 않습니다.

ssl.truststore.type

type: string
Default: JKS
Importance: medium
Dynamic update: per-broker

신뢰 저장소 파일의 파일 형식입니다.

zookeeper.clientCnxnSocket

type: string
Default: null
Importance: medium
Dynamic update: read-only

일반적으로 Zoo Cryostat에 TLS 연결을 사용할 때 org.apache.zookeeper.ClientCnxnSocketNetty 로 설정합니다. 동일한 이름의 Zookeeper .clientCnxnSocket 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다.

zookeeper.ssl.client.enable

type: boolean
Default: false
Importance: medium
Dynamic update: read-only

Zoo Cryostat에 연결할 때 TLS를 사용하도록 클라이언트를 설정합니다. 명시적 값은 zookeeper.client.secure 시스템 속성을 통해 설정된 모든 값을 재정의합니다(다른 이름 참조). 설정되지 않은 경우 기본값은 false입니다. true인 경우 Zookeeper .clientCnxnSocket을 설정해야 합니다(일반적으로 org.apache.zookeeper.ClientCnxnSocketNetty). 설정할 다른 값에는 zookeeper.ssl.cipher.suites,zookeeper.ssl.crl.enable, , , Zookeeper .ssl.enabled.protocols, Zookeeper.ssl.endpoint.identification.algorithm, Zookeeper.ssl.keystore.location ,zookeeper. ssl.keystore.password,zookeeper.ssl.ssl.keystore.type, , Zookeeper .ssl.ocsp.enable, Zookeeper.ssl.protocol, Zookeeper.ssl.truststore.location,zookeeper.ssl.truststore.password,zookeeper.ssl.truststore.type.

zookeeper.ssl.keystore.location

type: string
Default: null
Importance: medium
Dynamic update: read-only

Zoo Cryostat에 TLS 연결이 있는 클라이언트 측 인증서를 사용할 때 키 저장소 위치입니다. Zookeeper .ssl.keyStore.location 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다( camelCase 참조).

zookeeper.ssl.keystore.password

유형: password
Default: null
Importance: medium
Dynamic update: read-only

Zoo Cryostat에 TLS 연결이 있는 클라이언트 측 인증서를 사용하는 경우 키 저장소 암호입니다. Zookeeper .ssl.keyStore.password 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다( camelCase 참조). Zoo Cryostat는 키 저장소 암호와 다른 키 암호를 지원하지 않으므로 키 저장소의 키 암호를 키 저장소 암호와 동일하게 설정해야 합니다. 그렇지 않으면 Zookeeper에 대한 연결 시도가 실패합니다.

zookeeper.ssl.keystore.type

type: string
Default: null
Importance: medium
Dynamic update: read-only

Zoo Cryostat에 대한 TLS 연결이 있는 클라이언트 측 인증서를 사용하는 경우 키 저장소 유형입니다. Zookeeper .ssl.keyStore.type 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다( camelCase 참조). null 의 기본값은 키 저장소의 파일 이름 확장에 따라 유형이 자동으로 감지됨을 의미합니다.

zookeeper.ssl.truststore.location

type: string
Default: null
Importance: medium
Dynamic update: read-only

Zoo Cryostat에 TLS 연결을 사용할 때 신뢰 저장소 위치입니다. Zookeeper .ssl.trustStore.location 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다( camelCase 참조).

zookeeper.ssl.truststore.password

유형: password
Default: null
Importance: medium
Dynamic update: read-only

Zoo Cryostat에 TLS 연결을 사용하는 경우 신뢰 저장소 암호입니다. Zookeeper .ssl.trustStore.password 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다( camelCase 참조).

zookeeper.ssl.truststore.type

type: string
Default: null
Importance: medium
Dynamic update: read-only

Zoo Cryostat에 TLS 연결을 사용할 때 신뢰 저장소 유형입니다. Zookeeper .ssl.trustStore.type 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다( camelCase 참조). null 의 기본값은 truststore의 파일 이름 확장에 따라 유형이 자동으로 감지됨을 의미합니다.

alter.config.policy.class.name

유형: class
Default: null
Importance: low
Dynamic update: read-only

검증에 사용해야 하는 alter configs 정책 클래스입니다. 클래스는 org.apache.kafka.server.policy.AlterConfigPolicy 인터페이스를 구현해야 합니다.

alter.log.dirs.replication.quota.window.num

유형: int
기본값: 11
유효한 값: [1,…​]
중요도: 낮음
동적 업데이트: 읽기 전용

로그 다이버 복제 할당량을 변경하기 위해 메모리에 유지할 샘플 수입니다.

alter.log.dirs.replication.quota.window.size.seconds

유형: int
default: 1
유효한 값: [1,…​]
Importance: low
동적 업데이트: 읽기 전용

로그 다이저 복제 할당량을 변경하기 위한 각 샘플의 시간 범위입니다.

authorizer.class.name

유형: 문자열
기본값: ""
중요: 낮음
동적 업데이트: 읽기 전용

브로커에서 권한 부여에 사용하는 sorg.apache.kafka.server.authorizer.Authorizer 인터페이스를 구현하는 클래스의 정규화된 이름입니다.

client.quota.callback.class

유형: class
Default: null
Importance: low
Dynamic update: read-only

클라이언트 요청에 적용되는 할당량 제한을 결정하는 데 사용되는 ClientQuotaCallback 인터페이스를 구현하는 클래스의 정규화된 이름입니다. 기본적으로 Zoo Cryostat에 저장된 <user, client-id>, <user> 또는 <client-id> 할당량이 적용됩니다. 지정된 요청에 대해 세션의 사용자 주체와 일치하는 가장 구체적인 할당량과 요청의 클라이언트 ID가 적용됩니다.

connection.failed.authentication.delay.ms

유형: int
기본값: 100
유효한 값: [0,…​]
중요도: 낮음
동적 업데이트: 읽기 전용

인증 실패 시 연결 닫기 지연: 이는 인증 실패 시 연결 닫기가 지연되는 시간(밀리초)입니다. 연결 제한 시간을 방지하려면 connections.max.idle.ms보다 작아야 합니다.

controller.quorum.retry.backoff.ms

유형: int
Default: 20
Importance: low
Dynamic update: read-only

지정된 주제 파티션에 대한 실패한 요청을 재시도하기 전에 대기하는 시간입니다. 이렇게 하면 일부 실패 시나리오에서 엄격한 루프로 요청을 반복적으로 보내는 것을 방지할 수 있습니다.

controller.quota.window.num

유형: int
기본값: 11
유효한 값: [1,…​]
중요도: 낮음
동적 업데이트: 읽기 전용

컨트롤러 변경 할당량을 위해 메모리에 저장할 샘플 수입니다.

controller.quota.window.size.seconds

유형: int
default: 1
유효한 값: [1,…​]
Importance: low
동적 업데이트: 읽기 전용

컨트롤러의 각 샘플의 시간 범위는 할당량을 변경합니다.

create.topic.policy.class.name

유형: class
Default: null
Importance: low
Dynamic update: read-only

검증에 사용해야 하는 주제 정책 클래스를 생성합니다. 클래스는 org.apache.kafka.server.policy.CreateTopicPolicy 인터페이스를 구현해야 합니다.

delegation.token.expiry.check.interval.ms

유형: long
Default: 3600000 (1 hour)
유효한 값: [1,…​]
중요도: low
동적 업데이트: 읽기 전용

만료된 위임 토큰을 제거하기 위한 간격입니다.

kafka.metrics.polling.interval.secs

유형: int
기본값: 10
유효한 값: [1,…​]
중요도: 낮음
동적 업데이트: 읽기 전용

kafka.metrics.reporters 구현에서 사용할 수 있는 지표 폴링 간격(초)입니다.

kafka.metrics.reporters

type: list: list
default: ""
Importance: low
Dynamic update: read-only

사용자 지정 보고자로 사용할 클래스 목록입니다. 보고자는 kafka.metrics.KafkaMetricsReporter 특성을 구현해야 합니다. 클라이언트가 사용자 지정 보고자에서 Cryostat 작업을 노출하려는 경우 사용자 지정 보고자는 등록된 Cryostat 규칙을 준수하도록 kafka.metrics.KafkaMetricsReporterMBean 특성을 확장하는 Cryostat 특성을 추가로 구현해야 합니다.

listener.security.protocol.map

유형: 문자열
기본값: PLAINTEXT:PLAINTEXT:SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
Importance: low
Dynamic update: per-broker

리스너 이름과 보안 프로토콜 간에 매핑합니다. 동일한 보안 프로토콜을 두 개 이상의 포트 또는 IP에서 사용할 수 있도록 정의해야 합니다. 예를 들어 둘 다 SSL이 필요한 경우에도 내부 및 외부 트래픽을 분리할 수 있습니다. 구체적으로는 사용자가 INTERNAL 및 EXTERNAL이라는 이름으로 리스너를 정의할 수 있으며 이 속성은 INTERNAL:SSL,EXTERNAL:SSL. 표시된 대로 키와 값은 콜론으로 구분되고 맵 항목은 쉼표로 구분됩니다. 각 리스너 이름은 맵에 한 번만 표시되어야 합니다. 일반 접두사( listener name is lowercased)를 구성 이름에 추가하여 각 리스너에 다른 보안(SSL 및 SASL) 설정을 구성할 수 있습니다. 예를 들어 INTERNAL 리스너에 대해 다른 키 저장소를 설정하려면 이름 listener.name.internal.ssl.keystore.location 이 설정된 구성이 설정됩니다. 리스너 이름의 구성이 설정되지 않은 경우 구성이 일반 구성(예: ssl.keystore.location)으로 대체됩니다.

log.message.downconversion.enable

유형: 부울
기본값: true
Importance: low
Dynamic update: cluster-wide

이 구성은 사용 요청을 충족하기 위해 메시지 형식의 다운-버전이 활성화되어 있는지 여부를 제어합니다. false 로 설정하면 브로커는 이전 메시지 형식을 예상하는 소비자에 대해 다운-버전을 수행하지 않습니다. 브로커는 이러한 이전 클라이언트의 요청 소비에 대한 UNSUPPORTED_VERSION 오류로 응답합니다. 이 구성은 참여자에게 복제에 필요할 수 있는 메시지 형식 변환에는 적용되지 않습니다.

metric.reporters

type: list: list
default: ""
Importance: low
Dynamic update: cluster-wide

메트릭 보고자로 사용할 클래스 목록입니다. org.apache.kafka.common.metrics.MetricsReporter 인터페이스를 구현하면 새 메트릭 생성을 알리는 클래스를 연결할 수 있습니다. JmxReporter는 항상 statistics를 등록하기 위해 포함되어 있습니다.

metrics.num.samples

유형: int
default: 2
유효한 값: [1,…​]
Importance: low
동적 업데이트: 읽기 전용

컴퓨팅 메트릭에 유지 관리되는 샘플 수입니다.

metrics.recording.level

type: string
Default: INFO
Importance: low
Dynamic update: read-only

메트릭의 가장 높은 레코딩 수준입니다.

metrics.sample.window.ms

유형: long
기본값: 30000(30초)
유효한 값: [1,…​]
Importance: low
Dynamic update: read-only

메트릭 샘플이 계산되는 시간입니다.

password.encoder.cipher.algorithm

유형: 문자열
기본값: AES/CBC/PKCS5Padding
Importance: low
Dynamic update: read-only

동적으로 구성된 암호를 인코딩하는 데 사용되는 Cipher 알고리즘입니다.

password.encoder.iterations

유형: int
default: 4096
유효한 값: [1024,…​]
중요도: low
동적 업데이트: 읽기 전용

동적으로 구성된 암호를 인코딩하는 데 사용되는 반복 횟수입니다.

password.encoder.key.length

유형: int
default: 128
유효한 값: [8,…​]
Importance: low
동적 업데이트: 읽기 전용

동적으로 구성된 암호를 인코딩하는 데 사용되는 키 길이입니다.

password.encoder.keyfactory.algorithm

type: string
default: null
Importance: low
Dynamic update: read-only

동적으로 구성된 암호를 인코딩하는 데 사용되는 SecretKeyFactory 알고리즘입니다. 사용 가능한 경우 기본값은 PBKDF2WithHmacSHA512이고 PBKDF2WithHmacSHA1은 그렇지 않습니다.

quota.window.num

유형: int
기본값: 11
유효한 값: [1,…​]
중요도: 낮음
동적 업데이트: 읽기 전용

클라이언트 할당량의 메모리에 유지할 샘플 수입니다.

quota.window.size.seconds

유형: int
default: 1
유효한 값: [1,…​]
Importance: low
동적 업데이트: 읽기 전용

클라이언트 할당량에 대한 각 샘플의 시간 범위입니다.

replication.quota.window.num

유형: int
기본값: 11
유효한 값: [1,…​]
중요도: 낮음
동적 업데이트: 읽기 전용

복제 할당량을 위해 메모리에 유지할 샘플 수입니다.

replication.quota.window.size.seconds

유형: int
default: 1
유효한 값: [1,…​]
Importance: low
동적 업데이트: 읽기 전용

복제 할당량에 대한 각 샘플의 시간 범위입니다.

security.providers

type: string
default: null
Importance: low
Dynamic update: read-only

구성 가능한 작성자 클래스 목록은 각각 보안 알고리즘을 구현하는 공급자를 반환합니다. 이러한 클래스는 org.apache.kafka.common.security.auth.SecurityProviderCreator 인터페이스를 구현해야 합니다.

ssl.endpoint.identification.algorithm

type: string
default: https
Importance: low
Dynamic update: per-broker

서버 인증서를 사용하여 서버 호스트 이름을 확인하는 끝점 식별 알고리즘입니다.

ssl.engine.factory.class

유형: class
Default: null
Importance: low
Dynamic update: per-broker

SSLEngine 개체를 제공하는 org.apache.kafka.common.security.auth.SslEngineFactory 유형의 클래스입니다. 기본값은 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory입니다.

ssl.principal.mapping.rules

type: string
Default: DEFAULT
Importance: low
Dynamic update: read-only

클라이언트 인증서에서 짧은 이름으로 구분되는 이름과 매핑하기 위한 규칙 목록입니다. 규칙은 순서대로 평가되며 보안 주체 이름과 일치하는 첫 번째 규칙은 짧은 이름에 매핑됩니다. 목록의 이후 규칙은 무시됩니다. 기본적으로 X.500 인증서의 고유 이름은 주체가 됩니다. 형식에 대한 자세한 내용은 보안 권한 부여 및 acl을 참조하십시오. KafkaPrincipalBuilder의 확장 기능이 principal.builder.class 구성에서 제공하는 경우 이 구성은 무시됩니다.

ssl.secure.random.implementation

type: string
default: null
Importance: low
Dynamic update: per-broker

SSL 암호화 작업에 사용할 SecureRandom PRNG 구현

transaction.abort.timed.out.transaction.cleanup.interval.ms

유형: int
기본값: 10000(10초)
유효한 값: [1,…​]
중요도: low
동적 업데이트: 읽기 전용

시간 초과된 트랜잭션을 롤백하는 간격입니다.

transaction.remove.expired.transaction.cleanup.interval.ms

유형: int
Default: 3600000 (1 hour)
유효한 값: [1,…​]
Importance: low
Dynamic update: read-only

transactional.id.expiration.ms pass로 인해 만료된 트랜잭션을 제거하는 간격입니다.

zookeeper.ssl.cipher.suites

type: list: list
default: null
Importance: low
Dynamic update: read-only

Zoo Cryostat TLS 협상(csv)에서 사용할 활성화된 암호화 제품군을 지정합니다. Zookeeper .ssl.ciphersuites 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다(단일 "ciphersuites"). null 의 기본값은 활성화된 암호화 제품군 목록은 사용 중인 Java 런타임에 따라 결정됩니다.

zookeeper.ssl.crl.enable

유형: 부울
기본값: false
중요: 낮음
동적 업데이트: 읽기 전용

Zoo Cryostat TLS 프로토콜에서 인증서 해지 목록을 활성화할지 여부를 지정합니다. zookeeper.ssl.crl 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다(더 짧은 이름 참조).

zookeeper.ssl.enabled.protocols

type: list: list
default: null
Importance: low
Dynamic update: read-only

Zoo Cryostat TLS 협상(csv)에서 활성화된 프로토콜을 지정합니다. Zookeeper .ssl.enabledProtocols 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다( camelCase 참조). null 의 기본값은 활성화된 프로토콜이 zookeeper.ssl.protocol 구성 속성의 값이 됨을 의미합니다.

zookeeper.ssl.endpoint.identification.algorithm

type: string
default: HTTPS
Importance: low
Dynamic update: read-only

Zoo Cryostat TLS 협상 프로세스에서 호스트 이름 확인을 활성화할지 여부를 지정합니다(예: 대소문자를 구분하지 않는 경우) "https"는 "https"로 설정되어 있고, 명시적으로 비어 있는 값이 사용되도록 지정합니다. 즉, 명시적으로 비어 있는 값은 비활성화되어 있습니다(테스트 목적으로만 권장됨). 명시적 값은 zookeeper.ssl.hostnameVerification 시스템 속성을 통해 설정된 "true" 또는 "false" 값을 재정의합니다(다른 이름과 값이 있음을 나타냅니다. true는 비어 있음을 의미합니다).

zookeeper.ssl.ocsp.enable

유형: 부울
기본값: false
중요: 낮음
동적 업데이트: 읽기 전용

Zoo Cryostat TLS 프로토콜에서 온라인 인증서 상태 프로토콜을 활성화할지 여부를 지정합니다. zookeeper.ssl.ocsp 시스템 속성을 통해 설정된 모든 명시적 값을 재정의합니다(더 짧은 이름 참조).

zookeeper.ssl.protocol

type: string
Default: TLSv1.2
Importance: low
Dynamic update: read-only

Zoo Cryostat TLS 협상에서 사용할 프로토콜을 지정합니다. 명시적 값은 동일한 이름의 zookeeper.ssl.protocol 시스템 속성을 통해 설정된 모든 값을 재정의합니다.

zookeeper.sync.time.ms

유형: int
기본값: 2000(2초)
중요도: 낮음
동적 업데이트: 읽기 전용

ZK 팔로워가 ZK 리더 뒤에 있을 수 있는 정도입니다.

부록 B. 주제 구성 매개변수
링크 복사

cleanup.policy

type: list
default: delete
유효한 값: [compact, delete]
Server Default Property: log.cleanup.policy
Importance: medium

"delete" 또는 "compact" 또는 둘 다인 문자열입니다. 이 문자열은 이전 로그 세그먼트에 사용할 보존 정책을 지정합니다. 기본 정책("삭제")은 보존 시간 또는 크기 제한에 도달하면 이전 세그먼트를 삭제합니다. "콤팩트" 설정을 사용하면 주제에서 로그 압축 이 가능합니다.

compression.type

유형: 문자열
Default: producer
유효한 값: [uncompressed, zstd, lz4, snappy, gzip, producer]
Server Default Property: compression.type
Importance: medium

지정된 항목에 대한 최종 압축 유형을 지정합니다. 이 구성에서는 표준 압축 codecs('gzip', 'snappy', 'lz4', 'zstd')를 허용합니다. 압축하지 않은 것과 동일한 '압축되지 않음' 및 'producer'도 사용할 수 있습니다. 즉, 생산자가 설정한 원래 압축 codec를 유지합니다.

delete.retention.ms

유형: long
기본값: 86400000 (1 day)
유효한 값: [0,…​]
서버 기본 속성: log.cleaner.delete.retention.ms
Importance: medium

로그 압축 주제를 위해 삭제 tombstone 마커를 유지하는 시간입니다. 또한 이 설정은 최종 단계의 유효한 스냅샷을 얻기 위해 오프셋 0에서 시작하는 경우 소비자가 읽기를 완료해야 하는 시간에 바인딩됩니다(기타 삭제 tombstones는 스캔을 완료하기 전에 수집될 수 있음).

file.delete.delay.ms

유형: long
Default: 60000 (1 minute)
유효한 값: [0,…​]
서버 기본 속성: log.segment.delete.delay.ms
가져오기: 중간

파일 시스템에서 파일을 삭제하기 전에 대기하는 시간입니다.

flush.messages

유형: long
기본값: 92233720368775807
유효한 값: [0,…​]
서버 기본 속성: log.flush.interval.messages
가져오기: 중간

이 설정을 사용하면 로그에 기록된 데이터의 fsync를 강제 적용하는 간격을 지정할 수 있습니다. 예를 들어 이 값이 1로 설정된 경우 모든 메시지 뒤에 fsync가 됩니다. 5개 메시지마다 fsync인 경우 fsync가 됩니다. 일반적으로 이 설정을 설정하지 않고 지속성에 복제를 사용하고 운영 체제의 백그라운드 플러시 기능을 보다 효율적으로 허용하는 것이 좋습니다. 이 설정은 주제별 기준으로 재정의할 수 있습니다( 주별 구성 섹션참조).

flush.ms

유형: long
기본값: 92233720368775807
유효한 값: [0,…​]
서버 기본 속성: log.flush.interval.ms
가져오기: 중간

이 설정을 사용하면 로그에 기록된 데이터의 fsync를 강제 적용하는 시간 간격을 지정할 수 있습니다. 예를 들어 이 값이 1000으로 설정된 경우 1000ms 후에 fsync가 전달됩니다. 일반적으로 이 설정을 설정하지 않고 지속성에 복제를 사용하고 운영 체제의 백그라운드 플러시 기능을 보다 효율적으로 허용하는 것이 좋습니다.

follower.replication.throttled.replicas

type : list
default: ""
Valid Values: [partitionId]:[brokerId],[partitionId]:[brokerId],…​
서버 기본 속성: follower.replication.throttled.replicas
Importance: medium

로그 복제를 후속쪽에서 제한해야 하는 복제본 목록입니다. 목록은 [#159Id]:[BrokerId],[BrokerId]:[BrokerId]:…​ 형식의 복제본 세트를 설명해야 합니다. 그렇지 않으면 이 항목의 모든 복제본을 차단하는 데 와일드카드 '*'를 사용할 수 있습니다.

index.interval.bytes

type : int
Default: 4096 (4kibibytes)
Valid Values: [0,…​]
Server Default Property: log.index.interval.bytes
Importance: medium

이 설정은 Kafka가 인덱스 항목을 오프셋 인덱스에 추가하는 빈도를 제어합니다. 기본 설정을 사용하면 약 4096바이트마다 메시지를 인덱싱할 수 있습니다. 더 많은 인덱싱을 사용하면 로그의 정확한 위치에 읽기가 가까워지지만 인덱스를 더 크게 만들 수 있습니다. 이것을 변경할 필요가 없을 수도 있습니다.

leader.replication.throttled.replicas

type : list
default: ""
Valid Values: [partitionId]:[brokerId],[partitionId]:[brokerId],…​
서버 기본 속성: leader.replication.throttled.replicas
Importance: medium

로그 복제를 리더 측에서 제한해야 하는 복제본 목록입니다. 목록은 [#159Id]:[BrokerId],[BrokerId]:[BrokerId]:…​ 형식의 복제본 세트를 설명해야 합니다. 그렇지 않으면 이 항목의 모든 복제본을 차단하는 데 와일드카드 '*'를 사용할 수 있습니다.

local.retention.bytes

유형: long
기본값: -2
유효한 값: [-2,…​]
서버 기본 속성: null
Importance: medium

이전 세그먼트를 삭제하기 전에 파티션에 대해 증가할 수 있는 로컬 로그 세그먼트의 최대 크기입니다. 기본값은 -2이며 사용할 retention.bytes 값을 나타냅니다. 유효 값은 항상 retention.bytes 값보다 작거나 같아야 합니다.

local.retention.ms

유형: long
기본값: -2
유효한 값: [-2,…​]
서버 기본 속성: null
Importance: medium

삭제하기 전에 로컬 로그 세그먼트를 유지하는 밀리 초입니다. 기본값은 -2입니다. 이 값은 retention.ms 값을 사용해야 합니다. 유효 값은 항상 retention.ms 값보다 작거나 같아야 합니다.

max.compaction.lag.ms

유형: long
기본값: 92233720368775807
유효한 값: [1,…​]
서버 기본 속성: log.cleaner.max.compaction.lag.ms
가져오기: 매체

메시지가 로그에 압축할 수 없는 최대 시간입니다. 압축되는 로그에만 적용할 수 있습니다.

max.message.bytes

type: int
Default: 1048588
Valid Values: [0,…​]
Server Default Property: message.max.bytes
Importance: medium

Kafka에서 허용하는 가장 큰 레코드 배치 크기입니다(압축이 활성화된 경우 압축 후). 이 문제가 증가되고 0.10.2보다 오래된 소비자가 있는 경우 이 대규모 레코드 일괄 처리를 가져올 수 있도록 소비자의 가져오기 크기도 늘려야 합니다. 최신 메시지 형식 버전에서는 효율성을 위해 항상 레코드를 일괄 처리로 그룹화합니다. 이전 메시지 형식 버전에서는 압축되지 않은 레코드가 일괄 처리로 그룹화되지 않으며 이 제한은 이 경우 단일 레코드에만 적용됩니다.

message.format.version

유형: 문자열
기본값: 3.0-IV1
유효한 값: [0.8.0, 0.8.2, 0.9.0, 0.10.0-IV0, 0.10.0-IV0, 0.10.0-IV0, 0.10.1-IV0, 0.10.1-IV2, 0.10.1-IV2, 0.10.1-IV0, 0.11.0-IV0, 0.11.0-IV1, 0.11.0-IV1, 0.10.0-IV0, 0.10.0 0.11.0-iv2, 1.0-iv0, 1.1-iv0, 2.0-iv0, 2.0-iv0, 2.0-iv0, 2.1-iv0, 2.1-iv2, 2.2-iv1, 2.2-iv1, 2.3-iv0, 2.3-iv1, 2.4-iv0, 2.4-iv0, 2.4-iv0, 2.0-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv0, 2.7-iv2, 2.8-IV0, 2.8-IV1, 3.0-IV0, 3.0-IV1]
Server Default Property: log.message.format.version
Importance: medium

[DEPRECATED] 브로커가 로그에 메시지를 추가하는 데 사용할 메시지 형식 버전을 지정합니다. 이 구성의 값은 inter.broker.protocol.version 이 3.0 이상인 경우 항상 3.0이라고 가정합니다(실제 구성 값은 무시됨). 그렇지 않으면 값은 유효한 ApiVersion이어야 합니다. 일부 예로는 0.10.0, 1.1, 2.8, 3.0이 있습니다. 특정 메시지 형식 버전을 설정하면 디스크의 기존 메시지가 지정된 버전보다 작거나 같은지 사용자가 인증하고 있습니다. 이 값을 잘못 설정하면 이전 버전의 소비자가 이해할 수 없는 형식의 메시지를 수신하므로 중단됩니다.

message.timestamp.difference.max.ms

유형: long
기본값: 92233720368775807
유효한 값: [0,…​]
서버 기본 속성: log.message.timestamp.difference.max.ms
가져오기: 중간

브로커가 메시지를 수신할 때 타임스탬프와 메시지에 지정된 타임스탬프 간에 허용되는 최대 차이점입니다. message.timestamp.type=CreateTime인 경우 타임스탬프의 차이가 이 임계값을 초과하면 메시지가 거부됩니다. message.timestamp.type=LogAppendTime인 경우 이 구성은 무시됩니다.

message.timestamp.type

유형: 문자열
기본값: CreateTime
유효한 값: [CreateTime, LogAppendTime]
서버 기본 속성: log.message.timestamp.type
가져오기: 중간

메시지의 타임 스탬프가 메시지 생성 시간인지 또는 로그 추가 시간을 정의합니다. 값은 CreateTime 또는 LogAppendTime 이어야 합니다.

min.cleanable.dirty.ratio

유형: double
Default: 0.5
Valid Values: [0,…​,1]
Server Default Property: log.cleaner.min.cleanable.ratio
Importance: medium

이 구성은 로그 압축기가 로그를 정리하는 빈도를 제어합니다( 로그 압축 이 활성화된 것으로 가정). 기본적으로 로그의 50% 이상이 압축되는 로그 정리를 방지합니다. 이 비율은 중복으로 로그에서 손실되는 최대 공간을 바인딩합니다(로그의 최대 50%에서 중복될 수 있음). 비율이 높을수록 효율적인 정리가 줄어들지만 로그에서 더 많은 공간을 낭비하게 됩니다. max.compaction.lag.ms 또는 min.compaction.lag.ms 구성도 지정하는 경우 로그 압축기는 더티 비율 임계값이 충족되고 로그가 최소 min.compaction.lag.ms 기간, 기간, 기간 중 하나로 압축할 수 있도록 로그를 압축할 수 있다고 간주합니다. 또는 (ii) 로그에 최대 max.compaction.lag.ms 기간 동안 더티(복합되지 않은) 레코드가 있는 경우

min.compaction.lag.ms

type : long
Default: 0
Valid Values: [0,…​]
Server Default Property: log.cleaner.min.compaction.lag.ms
Importance: medium

메시지가 로그에 컴파일되지 않은 상태로 유지되는 최소 시간입니다. 압축되는 로그에만 적용할 수 있습니다.

min.insync.replicas

type: int
default: 1
Valid Values: [1,…​]
Server Default Property: min.insync.replicas
Importance: medium

생산자가 도크를 "all"(또는 "-1")로 설정하면 이 구성은 쓰기가 성공으로 간주되기 위해 쓰기를 승인해야 하는 최소 복제본 수를 지정합니다. 이 최소값을 충족할 수 없는 경우 생산자는 예외를 발생시킵니다(NotEnoughReplicas 또는 NotEnoughReplicasAfterAppend). min.insync.replicas 및 acks 를 함께 사용하면 더 큰 지속성 보장을 적용할 수 있습니다. 일반적인 시나리오는 복제 인수가 3인 주제를 만들고 min.insync.replicas 를 2로 설정하고, acks of "all"을 생성하는 것입니다. 이렇게 하면 대부분의 복제본에서 쓰기를 수신하지 못하는 경우 생산자가 예외를 발생시킵니다.

preallocate

type: boolean
default: false
Server Default Property: log.preallocate
Importance: medium

새 로그 세그먼트를 생성할 때 디스크에 파일을 미리 할당해야 하는 경우 True입니다.

remote.storage.enable

유형: 부울
기본값: false
서버 기본 속성: null
Importance: medium

주제의 계층 스토리지를 활성화하려면 remote.storage.enable 을 true로 설정합니다. 이 구성이 활성화된 후에는 비활성화할 수 없습니다. 이는 향후 버전에서 제공될 예정입니다.

retention.bytes

type: long
default: -1
서버 기본 속성: log.retention.bytes
Importance: medium

이 구성은 "삭제" 보존 정책을 사용하는 경우 이전 로그 세그먼트를 확보하기 위해 이전 로그 세그먼트를 삭제하기 전에 파티션(로그 세그먼트로 구성)의 최대 크기를 제어합니다. 기본적으로 크기 제한은 제한 시간만 없습니다. 이 제한은 파티션 수준에서 적용되므로 파티션 수를 곱하여 주제 보존을 바이트 단위로 계산합니다.

retention.ms

유형: long
default: 604800000 (7 days)
유효한 값: [-1,…​]
서버 기본 속성: log.retention.ms
Importance: medium

이 구성은 "삭제" 보존 정책을 사용하는 경우 이전 로그 세그먼트를 삭제하기 전에 로그를 보존하는 최대 시간을 제어합니다. 이는 소비자가 데이터를 얼마나 빨리 읽어야 하는지에 대한 SLA를 나타냅니다. -1로 설정하면 시간 제한이 적용되지 않습니다.

segment.bytes

유형: int
기본값: 1073741824 (1gibibyte)
유효한 값: [14,…​]
서버 기본 속성: log.segment.bytes
가져오기: 중간

이 구성은 로그의 세그먼트 파일 크기를 제어합니다. 보존 및 정리는 한 번에 항상 파일을 수행하므로 더 큰 세그먼트 크기는 파일 수가 줄어들지만 보존에 대한 세분화된 제어는 줄어듭니다.

segment.index.bytes

유형: int
기본값: 10485760(10MB)
유효한 값: [0,…​]
서버 기본 속성: log.index.size.max.bytes
가져오기: 매체

이 구성은 오프셋을 파일 위치에 매핑하는 인덱스의 크기를 제어합니다. 이 인덱스 파일을 사전 할당하고 로그 목록 후에만 축소합니다. 일반적으로 이 설정을 변경할 필요가 없습니다.

segment.jitter.ms

type: long
Default: 0
Valid Values: [0,…​]
Server Default Property: log.roll.jitter.ms
Importance: medium

세그먼트 롤링의 허브가 영향을 받지 않도록 예약된 세그먼트 롤 시간에서 최대 임의 지터를 뺀 수입니다.

segment.ms

유형: long
Default: 604800000 (7 days)
유효한 값: [1,…​]
서버 기본 속성: log.roll.ms
중요도: 중간

이 설정은 세그먼트 파일이 가득 차지 않은 경우에도 Kafka가 강제로 로그를 롤백하는 기간을 제어하여 보존이 오래된 데이터를 삭제하거나 압축할 수 있도록 합니다.

unclean.leader.election.enable

type: boolean
default: false
서버 기본 속성: unclean.leader.election.enable
Importance: medium

ISR 세트의 복제본이 마지막 수단으로 리더로 선택되지 않도록 활성화할지 여부를 나타내며, 이렇게 하면 데이터가 손실될 수 있습니다.

message.downconversion.enable

type: boolean
Default: true
Server Default Property: log.message.downconversion.enable
Importance: low

이 구성은 사용 요청을 충족하기 위해 메시지 형식의 다운-버전이 활성화되어 있는지 여부를 제어합니다. false 로 설정하면 브로커는 이전 메시지 형식을 예상하는 소비자에 대해 다운-버전을 수행하지 않습니다. 브로커는 이러한 이전 클라이언트의 요청 소비에 대한 UNSUPPORTED_VERSION 오류로 응답합니다. 이 구성은 참여자에게 복제에 필요할 수 있는 메시지 형식 변환에는 적용되지 않습니다.

부록 C. 소비자 구성 매개변수
링크 복사

key.deserializer

유형: class
Importance: high

org.apache.kafka.common.serialization.Deserializer 인터페이스를 구현하는 키에 대한 Deserializer 클래스입니다.

value.deserializer

유형: class
Importance: high

org.apache.kafka.common.serialization.Deserializer 인터페이스를 구현하는 value의 Deserializer 클래스입니다.

bootstrap.servers

type: list
default: ""
유효한 값: non-null string
Importance: high

Kafka 클러스터에 대한 초기 연결을 설정하는 데 사용할 호스트/포트 쌍 목록입니다. 클라이언트는 부트스트랩을 위해 여기에 지정된 서버를 여기에 관계없이 모든 서버를 사용합니다. 이 목록은 전체 서버 세트를 검색하는 데 사용되는 초기 호스트에만 영향을 미칩니다. 이 목록은 host1:port1,host2:port2,…​ 이어야 합니다. 이러한 서버는 초기 연결에서 전체 클러스터 멤버십을 검색하는 데만 사용되므로(동적으로 변경될 수 있음) 이 목록에는 전체 서버 세트가 포함되지 않아도 됩니다(서버가 다운된 경우 하나 이상 필요).

fetch.min.bytes

유형: int
기본값: 1
유효한 값: [0,…​]
중요도: high

서버에서 가져오기 요청에 대해 반환해야 하는 최소 데이터 양입니다. 데이터가 충분하지 않은 경우 요청은 요청에 응답하기 전에 많은 데이터가 누적될 때까지 기다립니다. 기본 설정은 1바이트의 데이터를 사용할 수 있는 즉시 가져오기 요청이 응답되거나 가져오기 요청 시간이 초과되는 즉시 응답됨을 의미합니다. 이 값을 1보다 큰 값으로 설정하면 서버가 더 많은 양의 데이터가 누적될 때까지 대기하므로 추가 대기 시간이 지남에 따라 서버 처리량을 약간 개선할 수 있습니다.

group.id

유형: 문자열
기본값: null
Importance: high

이 소비자가 속하는 소비자 그룹을 식별하는 고유한 문자열입니다. 이 속성은 소비자가 subscribe(topic) 또는 Kafka 기반 오프셋 관리 전략을 사용하여 그룹 관리 기능을 사용하는 경우 필요합니다.

heartbeat.interval.ms

유형: int
기본값: 3000 (3초)
중요도: high

Kafka의 그룹 관리 기능을 사용할 때 하트비트와 소비자 코디네이터 간 예상 시간입니다. 하트비트는 사용자의 세션이 활성 상태를 유지하고 새 소비자가 그룹에 참여하거나 나가면 재조정을 용이하게 하는 데 사용됩니다. 값은 session.timeout.ms 보다 작아야 하지만 일반적으로 해당 값의 1/3 이상을 설정하지 않아야 합니다. 정상적인 리밸런스에 필요한 시간을 제어하도록 더욱 낮게 조정할 수 있습니다.

max.partition.fetch.bytes

유형: int
기본값: 1048576 (1bibyte)
유효한 값: [0,…​]
Importance: high

서버가 반환할 파티션당 최대 데이터 양입니다. 레코드는 소비자가 배치로 가져옵니다. 가져오기의 첫 번째 비어 있지 않은 파티션의 첫 번째 레코드 배치가 이 제한보다 크면 소비자가 진행할 수 있도록 배치가 반환됩니다. 브로커가 허용하는 최대 레코드 배치 크기는 message.max.bytes (broker config) 또는 max.message.bytes (topic config)를 통해 정의됩니다. 소비자 요청 크기를 제한하려면 fetch.max.bytes를 참조하십시오.

session.timeout.ms

유형: int
기본값: 45000 (45 초)
중요도: high

Kafka의 그룹 관리 기능을 사용할 때 클라이언트 오류를 감지하는 데 사용되는 시간 초과입니다. 클라이언트는 주기적인 하트비트를 전송하여 브로커에 활성을 나타냅니다. 이 세션 시간 제한이 만료되기 전에 브로커가 하트비트를 수신하지 않으면 브로커는 이 클라이언트를 그룹에서 제거하고 재조정을 시작합니다. 값은 브로커 구성에 구성된 대로 허용 범위에 있어야 합니다 .min.session.timeout.ms 및 group.max.session.timeout.ms.ms .

ssl.key.password

유형: password
기본값: null
Importance: high

키 저장소 파일에 있는 개인 키의 암호 또는 'ssl.keystore.key'에 지정된 PEM 키입니다. 이는 양방향 인증이 구성된 경우에만 클라이언트에 필요합니다.

ssl.keystore.certificate.chain

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 인증서 체인입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서 목록이 있는 PEM 형식만 지원합니다.

ssl.keystore.key

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 개인 키입니다. 기본 SSL 엔진 팩토리에서는 PKCS#8 키가 있는 PEM 형식만 지원합니다. 키가 암호화된 경우 'ssl.key.password'를 사용하여 키 암호를 지정해야 합니다.

ssl.keystore.location

유형: 문자열
기본값: null
Importance: high

키 저장소 파일의 위치입니다. 클라이언트의 경우 선택 사항이며 클라이언트의 양방향 인증에 사용할 수 있습니다.

ssl.keystore.password

유형: password
기본값: null
Importance: high

키 저장소 파일의 저장소 암호입니다. 이는 클라이언트에 선택 사항이며 'ssl.keystore.location'이 구성된 경우에만 필요합니다. PEM 형식에는 키 저장소 암호가 지원되지 않습니다.

ssl.truststore.certificates

유형: password
기본값: null
Importance: high

'ssl.truststore.type'에서 지정한 형식의 신뢰할 수 있는 인증서입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서가 있는 PEM 형식만 지원합니다.

ssl.truststore.location

유형: 문자열
기본값: null
Importance: high

신뢰 저장소 파일의 위치입니다.

ssl.truststore.password

유형: password
기본값: null
Importance: high

신뢰 저장소 파일의 암호입니다. 암호를 설정하지 않으면 구성된 신뢰 저장소 파일이 계속 사용되지만 무결성 검사가 비활성화됩니다. PEM 형식에 대해 신뢰 저장소 암호가 지원되지 않습니다.

allow.auto.create.topics

유형: 부울
기본값: true
Importance: medium

주제를 구독하거나 할당할 때 브로커에 자동 주제 생성을 허용합니다. 서브스크립션되는 주제는 브로커가 auto.create.topics.enable 브로커 구성을 사용하는 경우에만 자동으로 생성됩니다. 0.11.0 미만의 브로커를 사용하는 경우 이 구성을 false 로 설정해야 합니다.

auto.offset.reset

유형: 문자열
default: latest
올바른 값: [latest, earliest, none]
중요도: 중간

Kafka에 초기 오프셋이 없거나 현재 오프셋이 서버에 더 이상 존재하지 않는 경우 수행할 작업(예: 해당 데이터가 삭제되었기 때문에).

  • 가장 빠른 시간: 오프셋을 가장 초기 오프셋으로 자동 재설정
  • latest: 오프셋을 최신 오프셋으로 자동 재설정
  • none: 소비자 그룹에 대한 이전 오프셋이 없는 경우 사용자에게 예외를 발생시킵니다.
  • 기타 모든 항목: 사용자에게 예외를 throw합니다.
client.dns.lookup

type : string
default: use_all_dns_ips
유효한 값: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

클라이언트에서 DNS 조회를 사용하는 방법을 제어합니다. use_all_dns_ips 로 설정된 경우 성공적인 연결이 설정될 때까지 반환된 각 IP 주소에 순서대로 연결합니다. 연결 해제 후 다음 IP가 사용됩니다. 모든 IP가 한 번 사용되면 클라이언트는 호스트 이름에서 IP를 다시 확인합니다(JVM 및 OS 캐시 DNS 이름 조회 모두). resolve_canonical_bootstrap_servers_only 로 설정된 경우 각 부트스트랩 주소를 정식 이름 목록으로 확인합니다. 부트스트랩 단계 후 use_all_dns_ips 와 동일하게 작동합니다.

connections.max.idle.ms

유형: long
기본값: 540000 (9 분)
중요도: 중간

이 구성에서 지정한 시간(밀리초) 후에 유휴 연결을 종료합니다.

default.api.timeout.ms

유형: int
기본값: 60000 (1분)
유효한 값: [0,…​]
중요: 중간

클라이언트 API의 시간 초과(밀리초)를 지정합니다. 이 구성은 timeout 매개변수를 지정하지 않는 모든 클라이언트 작업의 기본 시간 초과로 사용됩니다.

enable.auto.commit

유형: 부울
기본값: true
Importance: medium

true인 경우 소비자 오프셋은 백그라운드에서 정기적으로 커밋됩니다.

exclude.internal.topics

유형: 부울
기본값: true
Importance: medium

서브스크립션 패턴과 일치하는 내부 주제를 서브스크립션에서 제외해야 하는지 여부입니다. 항상 내부 주제를 명시적으로 구독할 수 있습니다.

fetch.max.bytes

유형: int
기본값: 52428800(50 메비바이트)
유효한 값: [0,…​]
Importance: medium

서버에서 가져오기 요청에 대해 반환해야 하는 최대 데이터 양입니다. 레코드는 소비자가 배치로 가져오고, 풀의 첫 번째 비어 있지 않은 파티션의 첫 번째 레코드 배치가 이 값보다 크면 소비자를 진행할 수 있도록 레코드 배치가 반환됩니다. 따라서 이는 절대 최대값이 아닙니다. 브로커가 허용하는 최대 레코드 배치 크기는 message.max.bytes (broker config) 또는 max.message.bytes (topic config)를 통해 정의됩니다. 소비자는 병렬로 여러 가져오기를 수행합니다.

group.instance.id

유형: 문자열
기본값: null
Importance: medium

최종 사용자가 제공하는 소비자 인스턴스의 고유 식별자입니다. 비어 있지 않은 문자열만 허용됩니다. 설정된 경우 소비자는 정적 멤버로 처리되므로 언제든지 이 ID가 있는 하나의 인스턴스만 소비자 그룹에서 허용됩니다. 이는 더 큰 세션 시간 초과와 함께 사용되어 일시적인 사용 불가(예: 프로세스 재시작)로 인한 그룹 재조정을 방지할 수 있습니다. 설정되지 않은 경우 소비자는 기존 동작인 동적 멤버로 그룹에 참여합니다.

isolation.level

type: string
Default: read_uncommitted
올바른 값: [read_committed, read_uncommitted]
Importance: medium

트랜잭션으로 작성된 메시지를 읽는 방법을 제어합니다. read_committed 로 설정하면 consumer.poll()은 커밋된 트랜잭션 메시지만 반환합니다. read_uncommitted (기본값)로 설정하면 consumer.poll()이 중단된 트랜잭션 메시지인 모든 메시지를 반환합니다. 비-전용 메시지는 두 모드에서 무조건 반환됩니다.

메시지는 항상 오프셋 순서대로 반환됩니다. 따라서 read_committed 모드에서 consumer.poll()은 첫 번째 오픈 트랜잭션의 오프셋보다 적은 LSO(마지막 stable offset)까지만 메시지를 반환합니다. 특히 진행중인 트랜잭션에 속하는 메시지가 표시된 모든 메시지는 관련 트랜잭션이 완료될 때까지 유지됩니다. 결과적으로 read_committed 소비자는 일선 거래에서 높은 워터마크까지 읽을 수 없습니다. 

Further, when in `read_committed` the seekToEnd method will return the LSO.
Copy to Clipboard Toggle word wrap
max.poll.interval.ms

유형: int
기본값: 300000 (5 분)
유효한 값: [1,…​]
중요도: 중간

소비자 그룹 관리를 사용할 때 poll() 호출 사이의 최대 지연입니다. 이렇게 하면 더 많은 레코드를 가져오기 전에 소비자를 유휴 상태로 설정할 수 있는 시간에 상한이 발생합니다. 이 시간 초과가 만료되기 전에 poll()를 호출하지 않으면 소비자가 실패한 것으로 간주되고 그룹이 파티션을 다른 멤버에 다시 할당하기 위해 재조정됩니다. 이 시간 초과에 도달하는 null이 아닌 group.instance.id 를 사용하는 소비자의 경우 즉시 파티션이 다시 할당되지 않습니다. 대신, 소비자는 하트비트 전송을 중지하고 session.timeout.ms 의 만료 후 파티션이 다시 할당됩니다. 이렇게 하면 종료가 있는 정적 소비자의 동작이 미러링됩니다.

max.poll.records

유형: int
기본값: 500
올바른 값: [1,…​]
중요도: 중간

poll()에 대한 단일 호출에서 반환되는 최대 레코드 수입니다. max.poll.records 는 기본 가져오기 동작에 영향을 미치지 않습니다. 소비자는 각 가져오기 요청의 레코드를 캐시하고 각 폴링에서 증분 방식으로 반환합니다.

partition.assignment.strategy

type : list
Default: apache.kafka.clients.consumer.RangeAssignor,class org.apache.kafka.clients.consumer.consumer.CooperativeStickyAssignor
Valid Values: non-null string
Importance: medium

그룹 관리가 사용될 때 클라이언트가 소비자 인스턴스 간에 파티션 소유권을 배포하는 데 사용할 지원되는 파티션 할당 전략의 기본 설정에 따라 정렬되는 클래스 이름 또는 클래스 유형 목록입니다. 사용 가능한 옵션은 다음과 같습니다.

  • org.apache.kafka.clients.consumer.RangeAssignor: 주제별로 파티션을 할당합니다.
  • org.apache.kafka.clients.consumer.RoundRobinAssignor: 라운드 로빈 방식으로 파티션을 소비자에게 할당합니다.
  • org.apache.kafka.clients.consumer.StickyAssignor: 가능한 한 많은 기존 파티션 할당을 유지하면서 maximally balanced 할당을 보장합니다.

  • org.apache.kafka.clients.consumer.CooperativeStickyAssignor: 동일한 CryostatAssignor 논리를 따르지만 cooperative 재조정을 허용합니다.

    기본 할당자는 [RangeAssignor, CooperativeStickyAssignor]이며 기본적으로 RangeAssignor를 사용하지만 목록에서 RangeAssignor를 제거하는 단일 롤링 바운더로 CooperativeStickyAssignor로 업그레이드할 수 있습니다.

    org.apache.kafka.clients.consumer.Consumer CryostatAssignor 인터페이스를 구현하면 사용자 지정 할당 전략을 연결할 수 있습니다.

receive.buffer.bytes

유형: int
기본값: 65536 (64 kibibytes)
유효한 값: [-1,…​]
Importance: medium

데이터를 읽을 때 사용할 TCP 수신 버퍼(SO_RCVBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

request.timeout.ms

유형: int
기본값: 30000(30초)
유효한 값: [0,…​]
Importance: medium

구성은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어합니다. 시간 초과가 경과하기 전에 응답을 수신하지 않으면 필요한 경우 클라이언트가 요청을 다시 전송하거나 재시도가 소진되면 요청을 다시 보냅니다.

sasl.client.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 클라이언트 콜백 처리기 클래스의 정규화된 이름입니다.

sasl.jaas.config

유형: password
기본값: null
Importance: medium

JAAS 구성 파일에서 사용하는 형식의 SASL 연결에 대한 JAAS 로그인 컨텍스트 매개변수입니다. JAAS 구성 파일 형식은 여기에 설명되어 있습니다. 값 형식은 loginModuleClass controlFlag (optionName=optionValue)*; 입니다. 브로커의 경우 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule이 필요합니다.

sasl.kerberos.service.name

유형: 문자열
기본값: null
Importance: medium

Kafka가 실행되는 Kerberos 주체 이름입니다. Kafka의 JAAS config 또는 Kafka의 config에서 정의할 수 있습니다.

sasl.login.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 로그인 콜백 처리기 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 콜백 처리기 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler입니다.

sasl.login.class

유형: class
Default: null
Importance: medium

로그인 인터페이스를 구현하는 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 구성 앞에는 리스너 접두사와 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin입니다.

sasl.mechanism

유형: 문자열
기본값: GSSAPI
Importance: medium

클라이언트 연결에 사용되는 SASL 메커니즘입니다. 이는 보안 공급자를 사용할 수 있는 메커니즘일 수 있습니다. GSSAPI는 기본 메커니즘입니다.

security.protocol

유형: 문자열
기본값: PLAINTEXT
Importance: medium

브로커와 통신하는 데 사용되는 프로토콜입니다. 유효한 값은 PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL입니다.

send.buffer.bytes

유형: int
기본값: 131072(128 kibibytes)
유효한 값: [-1,…​]
Importance: medium

데이터를 전송할 때 사용할 TCP 전송 버퍼(SO_SNDBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

socket.connection.setup.timeout.max.ms

유형: long
기본값: 30000 (30 초)
중요도: 중간

클라이언트가 소켓 연결이 설정될 때까지 대기하는 최대 시간입니다. 연결 설정 시간 초과는 연속 연결 오류마다 이 최대값까지 기하급수적으로 증가합니다. 연결 불란을 방지하기 위해 0.2의 무작위화 요소가 시간 초과에 적용되어 계산된 값보다 20% 이하에서 20% 사이의 임의 범위가 됩니다.

socket.connection.setup.timeout.ms

유형: long
기본값: 10000(10초)
중요도: 중간

클라이언트가 소켓 연결이 설정될 때까지 대기하는 시간입니다. 시간 초과가 경과하기 전에 연결이 빌드되지 않으면 클라이언트가 소켓 채널을 종료합니다.

ssl.enabled.protocols

type: list: list
default: TLSv1.2,TLSv1.3
Importance: medium

SSL 연결에 활성화된 프로토콜 목록입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.2,TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. Java 11의 기본값을 사용하면 클라이언트와 서버는 TLSv1.2를 지원하고 그 대신 TLSv1.2를 모두 지원하는 경우 TLSv1.3을 선호합니다(적어도 TLSv1.2 이상 지원). 대부분의 경우 이 기본값은 정상이어야 합니다. ssl.protocol 의 구성 문서를 참조하십시오.

ssl.keystore.type

유형: 문자열
기본값: JKS
중요도: 중간

키 저장소 파일의 파일 형식입니다. 클라이언트에는 선택 사항입니다.

ssl.protocol

유형: 문자열
기본값: TLSv1.3
중요도: 중간

SSLContext를 생성하는 데 사용되는 SSL 프로토콜입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. 이 값은 대부분의 사용 사례에 적합해야 합니다. 최근 JVM에서 허용되는 값은 'TLSv1.2' 및 'TLSv1.3'입니다. 'TLS', 'TLSv1.1', 'SSL', 'SSLv2' 및 'SSLv3'은 이전 JVM에서 지원되지 않을 수 있지만 알려진 보안 취약점으로 인해 사용이 권장되지 않습니다. 이 구성 및 'ssl.enabled.protocols'의 기본값을 사용하면 서버가 'TLSv1.3'을 지원하지 않는 경우 클라이언트가 'TLSv1.2'로 다운그레이드됩니다. 이 구성이 'TLSv1.2'로 설정된 경우 클라이언트는 ssl.enabled.protocols의 값 중 하나이고 서버가 'TLSv1.3'만 지원하는 경우에도 'TLSv1.3'을 사용하지 않습니다.

ssl.provider

유형: 문자열
기본값: null
Importance: medium

SSL 연결에 사용되는 보안 공급자의 이름입니다. 기본값은 JVM의 기본 보안 공급자입니다.

ssl.truststore.type

유형: 문자열
기본값: JKS
중요도: 중간

신뢰 저장소 파일의 파일 형식입니다.

auto.commit.interval.ms

유형: int
기본값: 5000 (5초)
유효한 값: [0,…​]
중요: 낮음

enable.auto.commit 가 true 로 설정된 경우 소비자 오프셋이 Kafka로 자동 커밋되는 빈도(밀리초)입니다.

check.crcs

유형: 부울
기본값: true
Importance: low

사용된 레코드의 CRC32를 자동으로 확인합니다. 이렇게 하면 메시지에 대한 on-the-wire 또는 온-디스크 손상이 발생하지 않았습니다. 이 검사에는 오버헤드가 추가되므로 극단적인 성능을 원하는 경우 비활성화될 수 있습니다.

client.id

유형: 문자열
기본값: ""
중요도: 낮음

요청을 수행할 때 서버에 전달할 id 문자열입니다. 이를 위해 논리적 애플리케이션 이름을 서버 측 요청 로깅에 포함하도록 허용하여 ip/port 이외의 요청 소스를 추적할 수 있습니다.

client.rack

유형: 문자열
기본값: ""
중요도: 낮음

이 클라이언트의 랙 식별자입니다. 이 값은 이 클라이언트가 물리적으로 위치한 위치를 나타내는 모든 문자열 값일 수 있습니다. 브로커 구성 'broker.rack'에 해당합니다.

fetch.max.wait.ms

유형: int
기본값: 500
유효한 값: [0,…​]
중요도: 낮음

fetch.min.bytes에서 제공한 요구 사항을 즉시 충족할 수 있는 데이터가 충분하지 않은 경우 서버가 가져오기 요청에 응답하기 전에 차단되는 최대 시간입니다.

interceptor.classes

type: list
default: ""
유효한 값: non-null string
Importance: low

인터셉터로 사용할 클래스 목록입니다. org.apache.kafka.clients.consumerInterceptor 인터페이스를 구현하면 소비자가 수신한 레코드를 가로챌 수 있습니다. 기본적으로 인터셉터가 없습니다.

metadata.max.age.ms

유형: long
기본값: 300000 (5분)
유효한 값: [0,…​]
중요: 낮음

파티션 리더십 변경 사항을 보지 못하더라도 새 브로커 또는 파티션을 사전에 검색하지 못한 경우에도 메타데이터를 강제로 새로 고침한 후 밀리초 단위입니다.

metric.reporters

type: list
default: ""
유효한 값: non-null string
Importance: low

메트릭 보고자로 사용할 클래스 목록입니다. org.apache.kafka.common.metrics.MetricsReporter 인터페이스를 구현하면 새 메트릭 생성을 알리는 클래스를 연결할 수 있습니다. JmxReporter는 항상 statistics를 등록하기 위해 포함되어 있습니다.

metrics.num.samples

유형: int
기본값: 2
유효한 값: [1,…​]
중요도: 낮음

컴퓨팅 메트릭에 유지 관리되는 샘플 수입니다.

metrics.recording.level

유형: 문자열
기본값: INFO
유효한 값: [INFO, DEBUG, TRACE]
Importance: low

메트릭의 가장 높은 레코딩 수준입니다.

metrics.sample.window.ms

유형: long
기본값: 30000(30초)
유효한 값: [0,…​]
중요도: 낮음

메트릭 샘플이 계산되는 시간입니다.

reconnect.backoff.max.ms

유형: long
기본값: 1000 (1 second)
유효한 값: [0,…​]
중요도: 낮음

반복적으로 연결하지 못한 브로커에 다시 연결할 때 대기하는 최대 시간(밀리초)입니다. 제공된 경우 호스트당 백오프는 연속되는 각 연결 오류에 대해 이 최대값까지 기하급수적으로 증가합니다. 백오프 증가를 계산한 후 연결 측정을 방지하기 위해 20%의 임의 지터가 추가됩니다.

reconnect.backoff.ms

유형: long
기본값: 50
유효한 값: [0,…​]
중요도: 낮음

지정된 호스트에 다시 연결하기 전에 대기하는 기본 시간입니다. 이렇게 하면 하드 루프로 호스트에 반복적으로 연결하는 것을 방지할 수 있습니다. 이 백오프는 클라이언트가 브로커에 대한 모든 연결 시도에 적용됩니다.

retry.backoff.ms

유형: long
기본값: 100
유효한 값: [0,…​]
중요도: 낮음

지정된 주제 파티션에 대한 실패한 요청을 재시도하기 전에 대기하는 시간입니다. 이렇게 하면 일부 실패 시나리오에서 엄격한 루프로 요청을 반복적으로 보내는 것을 방지할 수 있습니다.

sasl.kerberos.kinit.cmd

유형: 문자열
기본값: /usr/bin/kinit
Importance: low

Kerberos kinit 명령 경로입니다.

sasl.kerberos.min.time.before.relogin

유형: long
기본값: 60000
중요도: 낮음

새로 고침 시도 사이의 로그인 스레드 수면 시간입니다.

sasl.kerberos.ticket.renew.jitter

유형: 두 번
기본값: 0.05
중요도: 낮음

갱신 시간에 임의 지터의 백분율이 추가되었습니다.

sasl.kerberos.ticket.renew.window.factor

유형: double
기본값: 0.8
중요도: 낮음

로그인 스레드는 지정된 시간 요소가 마지막으로 새로 고침에서 티켓 만료로 도달할 때까지 유휴 상태가 되고 이 기간 동안 티켓을 갱신하려고 합니다.

sasl.login.refresh.buffer.seconds

유형: short
기본값: 300
유효한 값: [0,…​,3600]
중요도: 낮음

인증 정보를 새로 고칠 때 유지 관리하는 인증 정보 만료 전의 버퍼 시간(초)입니다. 새로 고침이 버퍼 초 수보다 만료되는 경우 새로 고침은 가능한 한 많은 버퍼 시간을 유지하기 위해 이동합니다. 법적 값은 0에서 3600(1시간) 사이입니다. 값이 지정되지 않은 경우 기본값 300(5분)이 사용됩니다. 이 값과 sasl.login.refresh.min.period.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.min.period.seconds

유형: short
기본값: 60
유효한 값: [0,…​,900]
중요도: 낮음

로그인 새로 고침 스레드가 인증 정보를 새로 고치기 전에 대기하는 최소 시간(초)입니다. 법적 값은 0에서 900 (15 분) 사이입니다. 값이 지정되지 않은 경우 기본값 60 (1 분)이 사용됩니다. 이 값과 sasl.login.refresh.buffer.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.factor

유형: double
기본값: 0.8
유효한 값: [0.5,…​,1.0]
중요: 낮음

로그인 새로 고침 스레드는 인증 정보의 수명을 기준으로 지정된 창 요인에 도달할 때까지 유휴 상태가 되어 인증 정보를 새로 고치려고 합니다. 법적 값은 0.5(50%)와 1.0(100%)을 포함합니다. 값이 지정되지 않은 경우 기본값 0.8(80%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.jitter

유형: double
기본값: 0.05
유효한 값: [0.0,…​,0.25]
중요도: 낮음

로그인 새로 고침 스레드의 수면 시간에 추가되는 인증 정보의 수명을 기준으로 임의 지터의 최대 양입니다. 법적 값은 0에서 0.25 (25 %) 사이이며, 값이 지정되지 않은 경우 기본값 0.05 (5%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

security.providers

유형: 문자열
기본값: null
Importance: low

구성 가능한 작성자 클래스 목록은 각각 보안 알고리즘을 구현하는 공급자를 반환합니다. 이러한 클래스는 org.apache.kafka.common.security.auth.SecurityProviderCreator 인터페이스를 구현해야 합니다.

ssl.cipher.suites

type: list
default: null
Importance: low

암호화 제품군 목록입니다. 이는 TLS 또는 SSL 네트워크 프로토콜을 사용하여 네트워크 연결에 대한 보안 설정을 협상하는 데 사용되는 인증, 암호화, MAC 및 키 교환 알고리즘의 이름이 지정된 조합입니다. 기본적으로 사용 가능한 모든 암호화 제품군이 지원됩니다.

ssl.endpoint.identification.algorithm

유형: 문자열
기본값: https
Importance: low

서버 인증서를 사용하여 서버 호스트 이름을 확인하는 끝점 식별 알고리즘입니다.

ssl.engine.factory.class

유형: class
Default: null
Importance: low

SSLEngine 개체를 제공하는 org.apache.kafka.common.security.auth.SslEngineFactory 유형의 클래스입니다. 기본값은 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory입니다.

ssl.keymanager.algorithm

유형: 문자열
기본값: SunX509
중요: 낮음

SSL 연결에 대해 키 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java Virtual Machine에 대해 구성된 키 관리자 팩토리 알고리즘입니다.

ssl.secure.random.implementation

유형: 문자열
기본값: null
Importance: low

SSL 암호화 작업에 사용할 SecureRandom PRNG 구현

ssl.trustmanager.algorithm

유형: 문자열
기본값: PKIX
Importance: low

SSL 연결에 대해 신뢰 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java 가상 머신에 대해 구성된 신뢰 관리자 팩토리 알고리즘입니다.

부록 D. 생산자 구성 매개변수
링크 복사

key.serializer

유형: class
Importance: high

org.apache.kafka.common.serialization.Serializer 인터페이스를 구현하는 키에 대한 serializer 클래스입니다.

value.serializer

유형: class
Importance: high

org.apache.kafka.common.serialization.Serializer 인터페이스를 구현하는 값에 대한 serializer 클래스입니다.

bootstrap.servers

type: list
default: ""
유효한 값: non-null string
Importance: high

Kafka 클러스터에 대한 초기 연결을 설정하는 데 사용할 호스트/포트 쌍 목록입니다. 클라이언트는 부트스트랩을 위해 여기에 지정된 서버를 여기에 관계없이 모든 서버를 사용합니다. 이 목록은 전체 서버 세트를 검색하는 데 사용되는 초기 호스트에만 영향을 미칩니다. 이 목록은 host1:port1,host2:port2,…​ 이어야 합니다. 이러한 서버는 초기 연결에서 전체 클러스터 멤버십을 검색하는 데만 사용되므로(동적으로 변경될 수 있음) 이 목록에는 전체 서버 세트가 포함되지 않아도 됩니다(서버가 다운된 경우 하나 이상 필요).

buffer.memory

유형: long
기본값: 33554432
유효한 값: [0,…​]
중요: high

생산자가 서버로 전송되는 대기 중인 레코드를 버퍼링하는 데 사용할 수 있는 총 메모리 바이트입니다. 레코드를 서버에 전달할 수 있는 속도보다 빠르게 전송되는 경우 생산자는 max.block.ms 를 차단한 후 예외가 발생합니다.

이 설정은 생산자가 사용할 총 메모리에 해당해야 하지만 생산자가 사용하는 모든 메모리가 버퍼링에 사용되는 것은 아니므로 하드 바운드가 아닙니다. 일부 추가 메모리는 압축(압축이 활성화된 경우) 및 진행 중인 요청을 유지 관리하는 데 사용됩니다.

compression.type

유형: 문자열
기본값: none
Importance: high

생산자가 생성한 모든 데이터의 압축 유형입니다. 기본값은 none입니다(즉, 압축이 없음). 유효한 값은 none,gzip,snappy,lz4 또는 zstd 입니다. 압축은 데이터의 전체 배치이므로 일괄 처리의 효율성도 압축 비율에 영향을 미칩니다(추가로 압축하면 압축 속도가 향상됨).

재시도

유형: int
기본값: 2147483647
유효한 값: [0,…​,2147483647]
Importance: high

값이 0보다 크면 클라이언트가 일시적인 오류와 함께 전송에 실패하는 모든 레코드를 다시 보냅니다. 이 재시도는 클라이언트가 오류를 수신할 때 레코드를 다시 요청하는 경우와 다릅니다. max.in.flight.requests.per.connection 을 1로 설정하지 않고 재시도하면 두 개의 배치가 단일 파티션으로 전송되고 첫 번째 일괄 처리가 실패하며 두 번째 배치의 레코드가 먼저 표시될 수 있으므로 레코드 순서가 변경될 수 있습니다. 또한, 성공적으로 승인하기 전에 delivery.timeout.ms 로 구성된 타임아웃이 먼저 만료되면 재시도 횟수가 소진되기 전에 요청 생성이 실패합니다. 사용자는 일반적으로 이 구성을 설정되지 않은 상태로 두는 것을 선호하고 대신 delivery.timeout.ms 를 사용하여 재시도 동작을 제어해야 합니다.

ssl.key.password

유형: password
기본값: null
Importance: high

키 저장소 파일에 있는 개인 키의 암호 또는 'ssl.keystore.key'에 지정된 PEM 키입니다. 이는 양방향 인증이 구성된 경우에만 클라이언트에 필요합니다.

ssl.keystore.certificate.chain

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 인증서 체인입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서 목록이 있는 PEM 형식만 지원합니다.

ssl.keystore.key

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 개인 키입니다. 기본 SSL 엔진 팩토리에서는 PKCS#8 키가 있는 PEM 형식만 지원합니다. 키가 암호화된 경우 'ssl.key.password'를 사용하여 키 암호를 지정해야 합니다.

ssl.keystore.location

유형: 문자열
기본값: null
Importance: high

키 저장소 파일의 위치입니다. 클라이언트의 경우 선택 사항이며 클라이언트의 양방향 인증에 사용할 수 있습니다.

ssl.keystore.password

유형: password
기본값: null
Importance: high

키 저장소 파일의 저장소 암호입니다. 이는 클라이언트에 선택 사항이며 'ssl.keystore.location'이 구성된 경우에만 필요합니다. PEM 형식에는 키 저장소 암호가 지원되지 않습니다.

ssl.truststore.certificates

유형: password
기본값: null
Importance: high

'ssl.truststore.type'에서 지정한 형식의 신뢰할 수 있는 인증서입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서가 있는 PEM 형식만 지원합니다.

ssl.truststore.location

유형: 문자열
기본값: null
Importance: high

신뢰 저장소 파일의 위치입니다.

ssl.truststore.password

유형: password
기본값: null
Importance: high

신뢰 저장소 파일의 암호입니다. 암호를 설정하지 않으면 구성된 신뢰 저장소 파일이 계속 사용되지만 무결성 검사가 비활성화됩니다. PEM 형식에 대해 신뢰 저장소 암호가 지원되지 않습니다.

batch.size

유형: int
기본값: 16384
유효한 값: [0,…​]
중요도: 중간

생산자는 여러 레코드가 동일한 파티션으로 전송될 때마다 더 적은 수의 요청에 함께 레코드를 배치하려고 합니다. 이렇게 하면 클라이언트와 서버 모두에서 성능이 향상됩니다. 이 구성은 기본 배치 크기를 바이트 단위로 제어합니다.

이 크기보다 큰 레코드를 배치하려고 시도하지 않습니다.

브로커로 전송된 요청에는 전송할 수 있는 데이터가 있는 각 파티션에 대해 여러 배치가 포함됩니다.

배치 크기가 작으면 일괄 처리가 덜 일반화되고 처리량을 줄일 수 있습니다(배치 크기가 0이면 일괄 처리가 완전히 비활성화됩니다). 매우 큰 배치 크기는 추가 레코드의 예상에 지정된 배치 크기의 버퍼를 항상 할당하므로 메모리를 조금 더 무례하게 사용할 수 있습니다.

client.dns.lookup

type : string
default: use_all_dns_ips
유효한 값: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

클라이언트에서 DNS 조회를 사용하는 방법을 제어합니다. use_all_dns_ips 로 설정된 경우 성공적인 연결이 설정될 때까지 반환된 각 IP 주소에 순서대로 연결합니다. 연결 해제 후 다음 IP가 사용됩니다. 모든 IP가 한 번 사용되면 클라이언트는 호스트 이름에서 IP를 다시 확인합니다(JVM 및 OS 캐시 DNS 이름 조회 모두). resolve_canonical_bootstrap_servers_only 로 설정된 경우 각 부트스트랩 주소를 정식 이름 목록으로 확인합니다. 부트스트랩 단계 후 use_all_dns_ips 와 동일하게 작동합니다.

client.id

type: string
Default: ""
Importance: medium

요청을 수행할 때 서버에 전달할 id 문자열입니다. 이를 위해 논리적 애플리케이션 이름을 서버 측 요청 로깅에 포함하도록 허용하여 ip/port 이외의 요청 소스를 추적할 수 있습니다.

connections.max.idle.ms

유형: long
기본값: 540000 (9 분)
중요도: 중간

이 구성에서 지정한 시간(밀리초) 후에 유휴 연결을 종료합니다.

delivery.timeout.ms

유형: int
기본값: 120000 (2 분)
유효한 값: [0,…​]
중요도: 중간

send() 반환 호출 후 성공 또는 실패를 보고하는 상한입니다. 이렇게 하면 레코드가 전송 전에 지연되는 총 시간, 브로커의 승인을 기다리는 시간(예: 예상한 경우) 및 재시도할 수 있는 전송에 허용되는 시간이 제한됩니다. 생산자는 복구할 수 없는 오류가 발생하거나 재시도가 소진된 경우 이 구성보다 일찍 레코드를 전송하지 못하거나, 이전 전달 만료 기한에 도달한 배치에 레코드가 추가됩니다. 이 구성의 값은 request.timeout.ms 및 linger.ms 의 합계보다 크거나 같아야 합니다.

linger.ms

유형: long
기본값: 0
유효한 값: [0,…​]
중요도: 중간

생산자는 단일 일괄 처리 요청으로 요청 전송 사이에 도달하는 모든 레코드를 그룹화합니다. 일반적으로 이 작업은 레코드가 전송될 수 있는 것보다 더 빨리 도달하는 경우에만 발생합니다. 그러나 경우에 따라 클라이언트는 중간 로드 상태에서도 요청 수를 줄여야 할 수 있습니다. 이 설정은 적은 양의 인위적인 지연을 추가하여 이를 수행합니다. 즉, 작성자가 전송이 함께 배치될 수 있도록 다른 레코드가 전송될 수 있도록 지정된 지연을 즉시 전송하는 대신 지정된 지연까지 대기합니다. 이는 TCP에서 나글 알고리즘과 유사한 것으로 간주될 수 있습니다. 이 설정은 일괄 처리 지연에 대한 상한을 부여합니다. 파티션에 대한 batch.size 의 가치가 있는 레코드가 즉시 전송되지만, 이 파티션에 대해 누적된 이 많은 바이트보다 적은 경우 이 파티션에 대해 누적된 바이트보다 적으면 지정된 시간이 더 많은 레코드가 표시될 때까지 'linger'합니다. 이 설정의 기본값은 0입니다(예: 지연 없음). 예를 들어 linger.ms=5 를 설정하면 전송된 요청 수를 줄이는 효과가 있지만 로드가 없는 상태에서 전송된 레코드에 최대 5ms의 대기 시간이 추가됩니다.

max.block.ms

유형: long
기본값: 60000(1분)
유효한 값: [0,…​]
중요: 중간

이 설정은 KafkaProducer의 'send() , partitionsFor() , initTransactions(), sendOffsetsToTransaction(), commitTransaction() 및 abortTransaction() 메서드가 차단하는 시간을 제어합니다. send() 의 경우 이 시간 초과는 메타데이터 가져오기 및 버퍼 할당(사용자 제공 직렬화 또는 파티션의 차단은 이 시간 초과에 대해 계산되지 않음) 둘 다 대기하는 총 시간을 바인딩합니다. partitionsFor() 의 경우 이 시간 초과는 사용할 수 없는 경우 메타데이터를 기다리는 데 걸리는 시간을 바인딩합니다. 트랜잭션 관련 메서드는 항상 차단되지만 트랜잭션 코디네이터를 검색할 수 없거나 시간 초과 내에 응답하지 않으면 시간 초과가 시간 초과될 수 있습니다.

max.request.size

유형: int
기본값: 1048576
유효한 값: [0,…​]
중요도: 중간

요청의 최대 크기(바이트)입니다. 이 설정은 대규모 요청을 보내지 않도록 생산자가 단일 요청으로 보낼 레코드 배치 수를 제한합니다. 이는 효과적으로 압축되지 않은 최대 레코드 배치 크기에 대한 제한이기도 합니다. 서버에는 레코드 배치 크기에 대한 자체 제한(압축이 활성화된 경우 압축 후)이 있습니다.

partitioner.class

유형: class
Default: org.apache.kafka.clients.producer.internals.Default Cryostater
Importance: medium

org.apache.kafka.clients.producer. Cryostater 인터페이스를 구현하는 partitioner 클래스입니다.

receive.buffer.bytes

유형: int
기본값: 32768(32 키비바이트)
유효한 값: [-1,…​]
Importance: medium

데이터를 읽을 때 사용할 TCP 수신 버퍼(SO_RCVBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

request.timeout.ms

유형: int
기본값: 30000(30초)
유효한 값: [0,…​]
Importance: medium

구성은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어합니다. 시간 초과가 경과하기 전에 응답을 수신하지 않으면 필요한 경우 클라이언트가 요청을 다시 전송하거나 재시도가 소진되면 요청을 다시 보냅니다. 불필요한 생산자 재시도로 인해 메시지 중복 가능성을 줄이기 위해 replica.lag.time.max.ms (중간 구성)보다 커야 합니다.

sasl.client.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 클라이언트 콜백 처리기 클래스의 정규화된 이름입니다.

sasl.jaas.config

유형: password
기본값: null
Importance: medium

JAAS 구성 파일에서 사용하는 형식의 SASL 연결에 대한 JAAS 로그인 컨텍스트 매개변수입니다. JAAS 구성 파일 형식은 여기에 설명되어 있습니다. 값 형식은 loginModuleClass controlFlag (optionName=optionValue)*; 입니다. 브로커의 경우 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule이 필요합니다.

sasl.kerberos.service.name

유형: 문자열
기본값: null
Importance: medium

Kafka가 실행되는 Kerberos 주체 이름입니다. Kafka의 JAAS config 또는 Kafka의 config에서 정의할 수 있습니다.

sasl.login.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 로그인 콜백 처리기 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 콜백 처리기 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler입니다.

sasl.login.class

유형: class
Default: null
Importance: medium

로그인 인터페이스를 구현하는 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 구성 앞에는 리스너 접두사와 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin입니다.

sasl.mechanism

유형: 문자열
기본값: GSSAPI
Importance: medium

클라이언트 연결에 사용되는 SASL 메커니즘입니다. 이는 보안 공급자를 사용할 수 있는 메커니즘일 수 있습니다. GSSAPI는 기본 메커니즘입니다.

security.protocol

유형: 문자열
기본값: PLAINTEXT
Importance: medium

브로커와 통신하는 데 사용되는 프로토콜입니다. 유효한 값은 PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL입니다.

send.buffer.bytes

유형: int
기본값: 131072(128 kibibytes)
유효한 값: [-1,…​]
Importance: medium

데이터를 전송할 때 사용할 TCP 전송 버퍼(SO_SNDBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

socket.connection.setup.timeout.max.ms

유형: long
기본값: 30000 (30 초)
중요도: 중간

클라이언트가 소켓 연결이 설정될 때까지 대기하는 최대 시간입니다. 연결 설정 시간 초과는 연속 연결 오류마다 이 최대값까지 기하급수적으로 증가합니다. 연결 불란을 방지하기 위해 0.2의 무작위화 요소가 시간 초과에 적용되어 계산된 값보다 20% 이하에서 20% 사이의 임의 범위가 됩니다.

socket.connection.setup.timeout.ms

유형: long
기본값: 10000(10초)
중요도: 중간

클라이언트가 소켓 연결이 설정될 때까지 대기하는 시간입니다. 시간 초과가 경과하기 전에 연결이 빌드되지 않으면 클라이언트가 소켓 채널을 종료합니다.

ssl.enabled.protocols

type: list: list
default: TLSv1.2,TLSv1.3
Importance: medium

SSL 연결에 활성화된 프로토콜 목록입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.2,TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. Java 11의 기본값을 사용하면 클라이언트와 서버는 TLSv1.2를 지원하고 그 대신 TLSv1.2를 모두 지원하는 경우 TLSv1.3을 선호합니다(적어도 TLSv1.2 이상 지원). 대부분의 경우 이 기본값은 정상이어야 합니다. ssl.protocol 의 구성 문서를 참조하십시오.

ssl.keystore.type

유형: 문자열
기본값: JKS
중요도: 중간

키 저장소 파일의 파일 형식입니다. 클라이언트에는 선택 사항입니다.

ssl.protocol

유형: 문자열
기본값: TLSv1.3
중요도: 중간

SSLContext를 생성하는 데 사용되는 SSL 프로토콜입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. 이 값은 대부분의 사용 사례에 적합해야 합니다. 최근 JVM에서 허용되는 값은 'TLSv1.2' 및 'TLSv1.3'입니다. 'TLS', 'TLSv1.1', 'SSL', 'SSLv2' 및 'SSLv3'은 이전 JVM에서 지원되지 않을 수 있지만 알려진 보안 취약점으로 인해 사용이 권장되지 않습니다. 이 구성 및 'ssl.enabled.protocols'의 기본값을 사용하면 서버가 'TLSv1.3'을 지원하지 않는 경우 클라이언트가 'TLSv1.2'로 다운그레이드됩니다. 이 구성이 'TLSv1.2'로 설정된 경우 클라이언트는 ssl.enabled.protocols의 값 중 하나이고 서버가 'TLSv1.3'만 지원하는 경우에도 'TLSv1.3'을 사용하지 않습니다.

ssl.provider

유형: 문자열
기본값: null
Importance: medium

SSL 연결에 사용되는 보안 공급자의 이름입니다. 기본값은 JVM의 기본 보안 공급자입니다.

ssl.truststore.type

유형: 문자열
기본값: JKS
중요도: 중간

신뢰 저장소 파일의 파일 형식입니다.

ACKS

유형: 문자열
기본값: all
유효한 값: [all, -1, 0, 1]
중요: 낮음

생산자가 요청 완료를 검토하기 전에 리더에게 받아야 한다는 확인의 수입니다. 이는 전송되는 레코드의 지속성을 제어합니다. 다음 설정이 허용됩니다.

  • ACKS=0 0으로 설정하면 생산자가 서버의 승인을 전혀 기다리지 않습니다. 레코드는 소켓 버퍼에 즉시 추가되고 전송된 것으로 간주됩니다. 이 경우 서버가 레코드를 수신했음을 보장할 수 없으며 재시도 구성이 적용되지 않습니다(클라이언트는 일반적으로 오류를 알 수 없음). 각 레코드에 대해 다시 주어진 오프셋은 항상 -1 로 설정됩니다.
  • ACKS=1 이것은 리더가 로컬 로그에 기록을 작성하지만 모든 뮤지터의 완전한 승인을 기다리지 않고 응답한다는 것을 의미합니다. 이 경우 기록을 승인한 직후 리더는 실패해야 하지만, 팔로워가 복제되기 전에 기록이 손실됩니다.
  • ACKS=all: 이는 리더가 in-sync 복제본의 전체 세트가 레코드를 승인할 때까지 대기한다는 것을 의미합니다. 이렇게 하면 하나 이상의 in-sync 복제본이 활성 상태로 유지되는 한 레코드가 손실되지 않습니다. 이는 가능한 가장 강력한 보증입니다. 이는 acks=-1 설정과 동일합니다.
enable.idempotence

유형: 부울
기본값: true
Importance: low

'true'로 설정하면 생산자가 각 메시지의 복사본이 스트림에 기록되도록 합니다. 'false'인 경우 브로커 실패 등으로 인한 생산자 재시도는 스트림에서 재시도한 메시지의 중복을 작성할 수 있습니다. idempotence를 활성화하려면 max.in.flight.requests.per.connection 이 5보다 작거나 같아야 합니다(허용 가능한 값에 대해 메시지 순서가 유지됨), 재시도 횟수 는 0보다 크고 acks 는 'all'이어야 합니다. 사용자가 이러한 값을 명시적으로 설정하지 않으면 적절한 값이 선택됩니다. 호환되지 않는 값이 설정되면 ConfigException 이 발생합니다.

interceptor.classes

type: list
default: ""
유효한 값: non-null string
Importance: low

인터셉터로 사용할 클래스 목록입니다. org.apache.kafka.clients.producer.ProducerInterceptor 인터페이스를 구현하면 Kafka 클러스터에 게시되기 전에 생산자가 수신한 레코드를 인터셉트(및 변경 가능)할 수 있습니다. 기본적으로 인터셉터가 없습니다.

max.in.flight.requests.per.connection

유형: int
기본값: 5
유효한 값: [1,…​]
Importance: low

클라이언트가 차단하기 전에 단일 연결로 전송할 수 없는 최대 요청 수입니다. 이 구성이 1보다 크고 enable.idempotence 가 false로 설정된 경우 재시도로 인해 전송 실패 후 메시지 순서를 다시 정렬할 위험이 있습니다(예: 재시도가 활성화된 경우).

metadata.max.age.ms

유형: long
기본값: 300000 (5분)
유효한 값: [0,…​]
중요: 낮음

파티션 리더십 변경 사항을 보지 못하더라도 새 브로커 또는 파티션을 사전에 검색하지 못한 경우에도 메타데이터를 강제로 새로 고침한 후 밀리초 단위입니다.

metadata.max.idle.ms

유형: long
기본값: 300000 (5 분)
유효한 값: [5000,…​]
중요도: 낮음

생산자가 유휴 상태인 항목의 메타데이터를 캐시하는 기간을 제어합니다. 메타데이터 유휴 기간을 초과하기 위해 주제를 마지막으로 생성한 후 경과된 시간이 지나면 주제의 메타데이터가 손상되고 이에 대한 다음 액세스는 메타데이터 가져오기 요청을 강제 적용합니다.

metric.reporters

type: list
default: ""
유효한 값: non-null string
Importance: low

메트릭 보고자로 사용할 클래스 목록입니다. org.apache.kafka.common.metrics.MetricsReporter 인터페이스를 구현하면 새 메트릭 생성을 알리는 클래스를 연결할 수 있습니다. JmxReporter는 항상 statistics를 등록하기 위해 포함되어 있습니다.

metrics.num.samples

유형: int
기본값: 2
유효한 값: [1,…​]
중요도: 낮음

컴퓨팅 메트릭에 유지 관리되는 샘플 수입니다.

metrics.recording.level

유형: 문자열
기본값: INFO
유효한 값: [INFO, DEBUG, TRACE]
Importance: low

메트릭의 가장 높은 레코딩 수준입니다.

metrics.sample.window.ms

유형: long
기본값: 30000(30초)
유효한 값: [0,…​]
중요도: 낮음

메트릭 샘플이 계산되는 시간입니다.

reconnect.backoff.max.ms

유형: long
기본값: 1000 (1 second)
유효한 값: [0,…​]
중요도: 낮음

반복적으로 연결하지 못한 브로커에 다시 연결할 때 대기하는 최대 시간(밀리초)입니다. 제공된 경우 호스트당 백오프는 연속되는 각 연결 오류에 대해 이 최대값까지 기하급수적으로 증가합니다. 백오프 증가를 계산한 후 연결 측정을 방지하기 위해 20%의 임의 지터가 추가됩니다.

reconnect.backoff.ms

유형: long
기본값: 50
유효한 값: [0,…​]
중요도: 낮음

지정된 호스트에 다시 연결하기 전에 대기하는 기본 시간입니다. 이렇게 하면 하드 루프로 호스트에 반복적으로 연결하는 것을 방지할 수 있습니다. 이 백오프는 클라이언트가 브로커에 대한 모든 연결 시도에 적용됩니다.

retry.backoff.ms

유형: long
기본값: 100
유효한 값: [0,…​]
중요도: 낮음

지정된 주제 파티션에 대한 실패한 요청을 재시도하기 전에 대기하는 시간입니다. 이렇게 하면 일부 실패 시나리오에서 엄격한 루프로 요청을 반복적으로 보내는 것을 방지할 수 있습니다.

sasl.kerberos.kinit.cmd

유형: 문자열
기본값: /usr/bin/kinit
Importance: low

Kerberos kinit 명령 경로입니다.

sasl.kerberos.min.time.before.relogin

유형: long
기본값: 60000
중요도: 낮음

새로 고침 시도 사이의 로그인 스레드 수면 시간입니다.

sasl.kerberos.ticket.renew.jitter

유형: 두 번
기본값: 0.05
중요도: 낮음

갱신 시간에 임의 지터의 백분율이 추가되었습니다.

sasl.kerberos.ticket.renew.window.factor

유형: double
기본값: 0.8
중요도: 낮음

로그인 스레드는 지정된 시간 요소가 마지막으로 새로 고침에서 티켓 만료로 도달할 때까지 유휴 상태가 되고 이 기간 동안 티켓을 갱신하려고 합니다.

sasl.login.refresh.buffer.seconds

유형: short
기본값: 300
유효한 값: [0,…​,3600]
중요도: 낮음

인증 정보를 새로 고칠 때 유지 관리하는 인증 정보 만료 전의 버퍼 시간(초)입니다. 새로 고침이 버퍼 초 수보다 만료되는 경우 새로 고침은 가능한 한 많은 버퍼 시간을 유지하기 위해 이동합니다. 법적 값은 0에서 3600(1시간) 사이입니다. 값이 지정되지 않은 경우 기본값 300(5분)이 사용됩니다. 이 값과 sasl.login.refresh.min.period.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.min.period.seconds

유형: short
기본값: 60
유효한 값: [0,…​,900]
중요도: 낮음

로그인 새로 고침 스레드가 인증 정보를 새로 고치기 전에 대기하는 최소 시간(초)입니다. 법적 값은 0에서 900 (15 분) 사이입니다. 값이 지정되지 않은 경우 기본값 60 (1 분)이 사용됩니다. 이 값과 sasl.login.refresh.buffer.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.factor

유형: double
기본값: 0.8
유효한 값: [0.5,…​,1.0]
중요: 낮음

로그인 새로 고침 스레드는 인증 정보의 수명을 기준으로 지정된 창 요인에 도달할 때까지 유휴 상태가 되어 인증 정보를 새로 고치려고 합니다. 법적 값은 0.5(50%)와 1.0(100%)을 포함합니다. 값이 지정되지 않은 경우 기본값 0.8(80%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.jitter

유형: double
기본값: 0.05
유효한 값: [0.0,…​,0.25]
중요도: 낮음

로그인 새로 고침 스레드의 수면 시간에 추가되는 인증 정보의 수명을 기준으로 임의 지터의 최대 양입니다. 법적 값은 0에서 0.25 (25 %) 사이이며, 값이 지정되지 않은 경우 기본값 0.05 (5%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

security.providers

유형: 문자열
기본값: null
Importance: low

구성 가능한 작성자 클래스 목록은 각각 보안 알고리즘을 구현하는 공급자를 반환합니다. 이러한 클래스는 org.apache.kafka.common.security.auth.SecurityProviderCreator 인터페이스를 구현해야 합니다.

ssl.cipher.suites

type: list
default: null
Importance: low

암호화 제품군 목록입니다. 이는 TLS 또는 SSL 네트워크 프로토콜을 사용하여 네트워크 연결에 대한 보안 설정을 협상하는 데 사용되는 인증, 암호화, MAC 및 키 교환 알고리즘의 이름이 지정된 조합입니다. 기본적으로 사용 가능한 모든 암호화 제품군이 지원됩니다.

ssl.endpoint.identification.algorithm

유형: 문자열
기본값: https
Importance: low

서버 인증서를 사용하여 서버 호스트 이름을 확인하는 끝점 식별 알고리즘입니다.

ssl.engine.factory.class

유형: class
Default: null
Importance: low

SSLEngine 개체를 제공하는 org.apache.kafka.common.security.auth.SslEngineFactory 유형의 클래스입니다. 기본값은 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory입니다.

ssl.keymanager.algorithm

유형: 문자열
기본값: SunX509
중요: 낮음

SSL 연결에 대해 키 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java Virtual Machine에 대해 구성된 키 관리자 팩토리 알고리즘입니다.

ssl.secure.random.implementation

유형: 문자열
기본값: null
Importance: low

SSL 암호화 작업에 사용할 SecureRandom PRNG 구현

ssl.trustmanager.algorithm

유형: 문자열
기본값: PKIX
Importance: low

SSL 연결에 대해 신뢰 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java 가상 머신에 대해 구성된 신뢰 관리자 팩토리 알고리즘입니다.

transaction.timeout.ms

유형: int
기본값: 60000 (1분)
중요도: 낮음

트랜잭션 코디네이터가 진행 중인 트랜잭션을 사전에 중단하기 전에 생산자의 트랜잭션 상태 업데이트를 대기하는 ms의 최대 시간입니다. 이 값이 브로커의 transaction.max.timeout.ms 설정보다 크면 요청이 InvalidTxnTimeoutException 오류로 인해 실패합니다.

transactional.id

type: string
default: null
Valid Values: non-empty string
Importance: low

트랜잭션 전달에 사용할 TransactionalId입니다. 이를 통해 클라이언트가 새 트랜잭션을 시작하기 전에 동일한 TransactionalId를 사용하는 트랜잭션이 완료되었음을 보장할 수 있으므로 여러 프로듀서 세션에 걸쳐 있는 안정성 의미 체계가 활성화됩니다. TransactionalId를 제공하지 않으면 생산자는 멱등 제공으로 제한됩니다. TransactionalId가 구성된 경우 enable.idempotence 가 우선합니다. 기본적으로 TransactionId는 구성되지 않으므로 트랜잭션을 사용할 수 없습니다. 기본적으로 트랜잭션에는 권장되는 프로덕션 설정인 3개 이상의 브로커 클러스터가 필요합니다. 개발의 경우 broker 설정 transaction.state.log.replication.factor 를 조정하여 이 설정을 변경할 수 있습니다.

부록 E. 관리자 클라이언트 구성 매개변수
링크 복사

bootstrap.servers

유형: list
Importance: high

Kafka 클러스터에 대한 초기 연결을 설정하는 데 사용할 호스트/포트 쌍 목록입니다. 클라이언트는 부트스트랩을 위해 여기에 지정된 서버를 여기에 관계없이 모든 서버를 사용합니다. 이 목록은 전체 서버 세트를 검색하는 데 사용되는 초기 호스트에만 영향을 미칩니다. 이 목록은 host1:port1,host2:port2,…​ 이어야 합니다. 이러한 서버는 초기 연결에서 전체 클러스터 멤버십을 검색하는 데만 사용되므로(동적으로 변경될 수 있음) 이 목록에는 전체 서버 세트가 포함되지 않아도 됩니다(서버가 다운된 경우 하나 이상 필요).

ssl.key.password

유형: password
기본값: null
Importance: high

키 저장소 파일에 있는 개인 키의 암호 또는 'ssl.keystore.key'에 지정된 PEM 키입니다. 이는 양방향 인증이 구성된 경우에만 클라이언트에 필요합니다.

ssl.keystore.certificate.chain

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 인증서 체인입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서 목록이 있는 PEM 형식만 지원합니다.

ssl.keystore.key

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 개인 키입니다. 기본 SSL 엔진 팩토리에서는 PKCS#8 키가 있는 PEM 형식만 지원합니다. 키가 암호화된 경우 'ssl.key.password'를 사용하여 키 암호를 지정해야 합니다.

ssl.keystore.location

유형: 문자열
기본값: null
Importance: high

키 저장소 파일의 위치입니다. 클라이언트의 경우 선택 사항이며 클라이언트의 양방향 인증에 사용할 수 있습니다.

ssl.keystore.password

유형: password
기본값: null
Importance: high

키 저장소 파일의 저장소 암호입니다. 이는 클라이언트에 선택 사항이며 'ssl.keystore.location'이 구성된 경우에만 필요합니다. PEM 형식에는 키 저장소 암호가 지원되지 않습니다.

ssl.truststore.certificates

유형: password
기본값: null
Importance: high

'ssl.truststore.type'에서 지정한 형식의 신뢰할 수 있는 인증서입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서가 있는 PEM 형식만 지원합니다.

ssl.truststore.location

유형: 문자열
기본값: null
Importance: high

신뢰 저장소 파일의 위치입니다.

ssl.truststore.password

유형: password
기본값: null
Importance: high

신뢰 저장소 파일의 암호입니다. 암호를 설정하지 않으면 구성된 신뢰 저장소 파일이 계속 사용되지만 무결성 검사가 비활성화됩니다. PEM 형식에 대해 신뢰 저장소 암호가 지원되지 않습니다.

client.dns.lookup

type : string
default: use_all_dns_ips
유효한 값: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

클라이언트에서 DNS 조회를 사용하는 방법을 제어합니다. use_all_dns_ips 로 설정된 경우 성공적인 연결이 설정될 때까지 반환된 각 IP 주소에 순서대로 연결합니다. 연결 해제 후 다음 IP가 사용됩니다. 모든 IP가 한 번 사용되면 클라이언트는 호스트 이름에서 IP를 다시 확인합니다(JVM 및 OS 캐시 DNS 이름 조회 모두). resolve_canonical_bootstrap_servers_only 로 설정된 경우 각 부트스트랩 주소를 정식 이름 목록으로 확인합니다. 부트스트랩 단계 후 use_all_dns_ips 와 동일하게 작동합니다.

client.id

type: string
Default: ""
Importance: medium

요청을 수행할 때 서버에 전달할 id 문자열입니다. 이를 위해 논리적 애플리케이션 이름을 서버 측 요청 로깅에 포함하도록 허용하여 ip/port 이외의 요청 소스를 추적할 수 있습니다.

connections.max.idle.ms

유형: long
기본값: 300000 (5분)
중요도: 중간

이 구성에서 지정한 시간(밀리초) 후에 유휴 연결을 종료합니다.

default.api.timeout.ms

유형: int
기본값: 60000 (1분)
유효한 값: [0,…​]
중요: 중간

클라이언트 API의 시간 초과(밀리초)를 지정합니다. 이 구성은 timeout 매개변수를 지정하지 않는 모든 클라이언트 작업의 기본 시간 초과로 사용됩니다.

receive.buffer.bytes

유형: int
기본값: 65536 (64 kibibytes)
유효한 값: [-1,…​]
Importance: medium

데이터를 읽을 때 사용할 TCP 수신 버퍼(SO_RCVBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

request.timeout.ms

유형: int
기본값: 30000(30초)
유효한 값: [0,…​]
Importance: medium

구성은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어합니다. 시간 초과가 경과하기 전에 응답을 수신하지 않으면 필요한 경우 클라이언트가 요청을 다시 전송하거나 재시도가 소진되면 요청을 다시 보냅니다.

sasl.client.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 클라이언트 콜백 처리기 클래스의 정규화된 이름입니다.

sasl.jaas.config

유형: password
기본값: null
Importance: medium

JAAS 구성 파일에서 사용하는 형식의 SASL 연결에 대한 JAAS 로그인 컨텍스트 매개변수입니다. JAAS 구성 파일 형식은 여기에 설명되어 있습니다. 값 형식은 loginModuleClass controlFlag (optionName=optionValue)*; 입니다. 브로커의 경우 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule이 필요합니다.

sasl.kerberos.service.name

유형: 문자열
기본값: null
Importance: medium

Kafka가 실행되는 Kerberos 주체 이름입니다. Kafka의 JAAS config 또는 Kafka의 config에서 정의할 수 있습니다.

sasl.login.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 로그인 콜백 처리기 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 콜백 처리기 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler입니다.

sasl.login.class

유형: class
Default: null
Importance: medium

로그인 인터페이스를 구현하는 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 구성 앞에는 리스너 접두사와 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin입니다.

sasl.mechanism

유형: 문자열
기본값: GSSAPI
Importance: medium

클라이언트 연결에 사용되는 SASL 메커니즘입니다. 이는 보안 공급자를 사용할 수 있는 메커니즘일 수 있습니다. GSSAPI는 기본 메커니즘입니다.

security.protocol

유형: 문자열
기본값: PLAINTEXT
Importance: medium

브로커와 통신하는 데 사용되는 프로토콜입니다. 유효한 값은 PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL입니다.

send.buffer.bytes

유형: int
기본값: 131072(128 kibibytes)
유효한 값: [-1,…​]
Importance: medium

데이터를 전송할 때 사용할 TCP 전송 버퍼(SO_SNDBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

socket.connection.setup.timeout.max.ms

유형: long
기본값: 30000 (30 초)
중요도: 중간

클라이언트가 소켓 연결이 설정될 때까지 대기하는 최대 시간입니다. 연결 설정 시간 초과는 연속 연결 오류마다 이 최대값까지 기하급수적으로 증가합니다. 연결 불란을 방지하기 위해 0.2의 무작위화 요소가 시간 초과에 적용되어 계산된 값보다 20% 이하에서 20% 사이의 임의 범위가 됩니다.

socket.connection.setup.timeout.ms

유형: long
기본값: 10000(10초)
중요도: 중간

클라이언트가 소켓 연결이 설정될 때까지 대기하는 시간입니다. 시간 초과가 경과하기 전에 연결이 빌드되지 않으면 클라이언트가 소켓 채널을 종료합니다.

ssl.enabled.protocols

type: list: list
default: TLSv1.2,TLSv1.3
Importance: medium

SSL 연결에 활성화된 프로토콜 목록입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.2,TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. Java 11의 기본값을 사용하면 클라이언트와 서버는 TLSv1.2를 지원하고 그 대신 TLSv1.2를 모두 지원하는 경우 TLSv1.3을 선호합니다(적어도 TLSv1.2 이상 지원). 대부분의 경우 이 기본값은 정상이어야 합니다. ssl.protocol 의 구성 문서를 참조하십시오.

ssl.keystore.type

유형: 문자열
기본값: JKS
중요도: 중간

키 저장소 파일의 파일 형식입니다. 클라이언트에는 선택 사항입니다.

ssl.protocol

유형: 문자열
기본값: TLSv1.3
중요도: 중간

SSLContext를 생성하는 데 사용되는 SSL 프로토콜입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. 이 값은 대부분의 사용 사례에 적합해야 합니다. 최근 JVM에서 허용되는 값은 'TLSv1.2' 및 'TLSv1.3'입니다. 'TLS', 'TLSv1.1', 'SSL', 'SSLv2' 및 'SSLv3'은 이전 JVM에서 지원되지 않을 수 있지만 알려진 보안 취약점으로 인해 사용이 권장되지 않습니다. 이 구성 및 'ssl.enabled.protocols'의 기본값을 사용하면 서버가 'TLSv1.3'을 지원하지 않는 경우 클라이언트가 'TLSv1.2'로 다운그레이드됩니다. 이 구성이 'TLSv1.2'로 설정된 경우 클라이언트는 ssl.enabled.protocols의 값 중 하나이고 서버가 'TLSv1.3'만 지원하는 경우에도 'TLSv1.3'을 사용하지 않습니다.

ssl.provider

유형: 문자열
기본값: null
Importance: medium

SSL 연결에 사용되는 보안 공급자의 이름입니다. 기본값은 JVM의 기본 보안 공급자입니다.

ssl.truststore.type

유형: 문자열
기본값: JKS
중요도: 중간

신뢰 저장소 파일의 파일 형식입니다.

metadata.max.age.ms

유형: long
기본값: 300000 (5분)
유효한 값: [0,…​]
중요: 낮음

파티션 리더십 변경 사항을 보지 못하더라도 새 브로커 또는 파티션을 사전에 검색하지 못한 경우에도 메타데이터를 강제로 새로 고침한 후 밀리초 단위입니다.

metric.reporters

type: list
default: ""
Importance: low

메트릭 보고자로 사용할 클래스 목록입니다. org.apache.kafka.common.metrics.MetricsReporter 인터페이스를 구현하면 새 메트릭 생성을 알리는 클래스를 연결할 수 있습니다. JmxReporter는 항상 statistics를 등록하기 위해 포함되어 있습니다.

metrics.num.samples

유형: int
기본값: 2
유효한 값: [1,…​]
중요도: 낮음

컴퓨팅 메트릭에 유지 관리되는 샘플 수입니다.

metrics.recording.level

유형: 문자열
기본값: INFO
유효한 값: [INFO, DEBUG, TRACE]
Importance: low

메트릭의 가장 높은 레코딩 수준입니다.

metrics.sample.window.ms

유형: long
기본값: 30000(30초)
유효한 값: [0,…​]
중요도: 낮음

메트릭 샘플이 계산되는 시간입니다.

reconnect.backoff.max.ms

유형: long
기본값: 1000 (1 second)
유효한 값: [0,…​]
중요도: 낮음

반복적으로 연결하지 못한 브로커에 다시 연결할 때 대기하는 최대 시간(밀리초)입니다. 제공된 경우 호스트당 백오프는 연속되는 각 연결 오류에 대해 이 최대값까지 기하급수적으로 증가합니다. 백오프 증가를 계산한 후 연결 측정을 방지하기 위해 20%의 임의 지터가 추가됩니다.

reconnect.backoff.ms

유형: long
기본값: 50
유효한 값: [0,…​]
중요도: 낮음

지정된 호스트에 다시 연결하기 전에 대기하는 기본 시간입니다. 이렇게 하면 하드 루프로 호스트에 반복적으로 연결하는 것을 방지할 수 있습니다. 이 백오프는 클라이언트가 브로커에 대한 모든 연결 시도에 적용됩니다.

재시도

유형: int
기본값: 2147483647
유효한 값: [0,…​,2147483647]
Importance: low

값을 0보다 크게 설정하면 클라이언트가 일시적인 오류와 함께 실패하는 모든 요청을 다시 보냅니다. 값을 0 또는 MAX_VALUE 로 설정하고 해당 시간 초과 매개변수를 사용하여 클라이언트가 요청을 재시도하는 기간을 제어하는 것이 좋습니다.

retry.backoff.ms

유형: long
기본값: 100
유효한 값: [0,…​]
중요도: 낮음

실패한 요청을 재시도하기 전에 대기하는 시간입니다. 이렇게 하면 일부 실패 시나리오에서 엄격한 루프로 요청을 반복적으로 보내는 것을 방지할 수 있습니다.

sasl.kerberos.kinit.cmd

유형: 문자열
기본값: /usr/bin/kinit
Importance: low

Kerberos kinit 명령 경로입니다.

sasl.kerberos.min.time.before.relogin

유형: long
기본값: 60000
중요도: 낮음

새로 고침 시도 사이의 로그인 스레드 수면 시간입니다.

sasl.kerberos.ticket.renew.jitter

유형: 두 번
기본값: 0.05
중요도: 낮음

갱신 시간에 임의 지터의 백분율이 추가되었습니다.

sasl.kerberos.ticket.renew.window.factor

유형: double
기본값: 0.8
중요도: 낮음

로그인 스레드는 지정된 시간 요소가 마지막으로 새로 고침에서 티켓 만료로 도달할 때까지 유휴 상태가 되고 이 기간 동안 티켓을 갱신하려고 합니다.

sasl.login.refresh.buffer.seconds

유형: short
기본값: 300
유효한 값: [0,…​,3600]
중요도: 낮음

인증 정보를 새로 고칠 때 유지 관리하는 인증 정보 만료 전의 버퍼 시간(초)입니다. 새로 고침이 버퍼 초 수보다 만료되는 경우 새로 고침은 가능한 한 많은 버퍼 시간을 유지하기 위해 이동합니다. 법적 값은 0에서 3600(1시간) 사이입니다. 값이 지정되지 않은 경우 기본값 300(5분)이 사용됩니다. 이 값과 sasl.login.refresh.min.period.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.min.period.seconds

유형: short
기본값: 60
유효한 값: [0,…​,900]
중요도: 낮음

로그인 새로 고침 스레드가 인증 정보를 새로 고치기 전에 대기하는 최소 시간(초)입니다. 법적 값은 0에서 900 (15 분) 사이입니다. 값이 지정되지 않은 경우 기본값 60 (1 분)이 사용됩니다. 이 값과 sasl.login.refresh.buffer.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.factor

유형: double
기본값: 0.8
유효한 값: [0.5,…​,1.0]
중요: 낮음

로그인 새로 고침 스레드는 인증 정보의 수명을 기준으로 지정된 창 요인에 도달할 때까지 유휴 상태가 되어 인증 정보를 새로 고치려고 합니다. 법적 값은 0.5(50%)와 1.0(100%)을 포함합니다. 값이 지정되지 않은 경우 기본값 0.8(80%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.jitter

유형: double
기본값: 0.05
유효한 값: [0.0,…​,0.25]
중요도: 낮음

로그인 새로 고침 스레드의 수면 시간에 추가되는 인증 정보의 수명을 기준으로 임의 지터의 최대 양입니다. 법적 값은 0에서 0.25 (25 %) 사이이며, 값이 지정되지 않은 경우 기본값 0.05 (5%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

security.providers

유형: 문자열
기본값: null
Importance: low

구성 가능한 작성자 클래스 목록은 각각 보안 알고리즘을 구현하는 공급자를 반환합니다. 이러한 클래스는 org.apache.kafka.common.security.auth.SecurityProviderCreator 인터페이스를 구현해야 합니다.

ssl.cipher.suites

type: list
default: null
Importance: low

암호화 제품군 목록입니다. 이는 TLS 또는 SSL 네트워크 프로토콜을 사용하여 네트워크 연결에 대한 보안 설정을 협상하는 데 사용되는 인증, 암호화, MAC 및 키 교환 알고리즘의 이름이 지정된 조합입니다. 기본적으로 사용 가능한 모든 암호화 제품군이 지원됩니다.

ssl.endpoint.identification.algorithm

유형: 문자열
기본값: https
Importance: low

서버 인증서를 사용하여 서버 호스트 이름을 확인하는 끝점 식별 알고리즘입니다.

ssl.engine.factory.class

유형: class
Default: null
Importance: low

SSLEngine 개체를 제공하는 org.apache.kafka.common.security.auth.SslEngineFactory 유형의 클래스입니다. 기본값은 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory입니다.

ssl.keymanager.algorithm

유형: 문자열
기본값: SunX509
중요: 낮음

SSL 연결에 대해 키 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java Virtual Machine에 대해 구성된 키 관리자 팩토리 알고리즘입니다.

ssl.secure.random.implementation

유형: 문자열
기본값: null
Importance: low

SSL 암호화 작업에 사용할 SecureRandom PRNG 구현

ssl.trustmanager.algorithm

유형: 문자열
기본값: PKIX
Importance: low

SSL 연결에 대해 신뢰 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java 가상 머신에 대해 구성된 신뢰 관리자 팩토리 알고리즘입니다.

부록 F. Kafka Connect 구성 매개변수
링크 복사

config.storage.topic

유형: 문자열
Importance: high

커넥터 구성이 저장되는 Kafka 항목의 이름입니다.

group.id

유형: 문자열
Importance: high

이 작업자가 속한 Connect 클러스터 그룹을 식별하는 고유한 문자열입니다.

key.converter

유형: class
Importance: high

Kafka Connect 형식과 Kafka에 기록된 직렬화 형식 간에 변환하는 데 사용되는 Cryostat 클래스입니다. 이는 Kafka로 작성되거나 읽혀진 메시지의 키 형식을 제어하며 커넥터와 독립적이므로 모든 커넥터가 직렬화 형식으로 작동할 수 있습니다. 일반적인 형식의 예로는 JSON 및 Avro가 있습니다.

offset.storage.topic

유형: 문자열
Importance: high

커넥터 오프셋이 저장되는 Kafka 항목의 이름입니다.

status.storage.topic

유형: 문자열
Importance: high

커넥터 및 작업 상태가 저장되는 Kafka 항목의 이름입니다.

value.converter

유형: class
Importance: high

Kafka Connect 형식과 Kafka에 기록된 직렬화 형식 간에 변환하는 데 사용되는 Cryostat 클래스입니다. 이는 Kafka로 작성되거나 읽혀진 메시지의 값 형식을 제어하며 커넥터와 독립적이므로 모든 커넥터가 직렬화 형식으로 작동할 수 있습니다. 일반적인 형식의 예로는 JSON 및 Avro가 있습니다.

bootstrap.servers

type: list
default: localhost:9092
Importance: high

Kafka 클러스터에 대한 초기 연결을 설정하는 데 사용할 호스트/포트 쌍 목록입니다. 클라이언트는 부트스트랩을 위해 여기에 지정된 서버를 여기에 관계없이 모든 서버를 사용합니다. 이 목록은 전체 서버 세트를 검색하는 데 사용되는 초기 호스트에만 영향을 미칩니다. 이 목록은 host1:port1,host2:port2,…​ 이어야 합니다. 이러한 서버는 초기 연결에서 전체 클러스터 멤버십을 검색하는 데만 사용되므로(동적으로 변경될 수 있음) 이 목록에는 전체 서버 세트가 포함되지 않아도 됩니다(서버가 다운된 경우 하나 이상 필요).

heartbeat.interval.ms

유형: int
기본값: 3000 (3초)
중요도: high

Kafka의 그룹 관리 기능을 사용할 때 하트비트 간 그룹 코디네이터 간 예상 시간입니다. 하트비트는 작업자의 세션이 활성 상태를 유지하고 새 멤버가 그룹에 참여하거나 나가면 재조정을 용이하게 하는 데 사용됩니다. 값은 session.timeout.ms 보다 작아야 하지만 일반적으로 해당 값의 1/3 이상을 설정하지 않아야 합니다. 정상적인 리밸런스에 필요한 시간을 제어하도록 더욱 낮게 조정할 수 있습니다.

rebalance.timeout.ms

유형: int
기본값: 60000(1분)
중요도: high

리밸런스가 시작된 후 각 작업자가 그룹에 참여할 수 있는 최대 시간입니다. 이는 기본적으로 모든 작업에서 보류 중인 데이터 및 커밋 오프셋을 플러시하는 데 필요한 시간 제한입니다. 시간 초과를 초과하면 작업자가 그룹에서 제거되어 오프셋 커밋이 실패합니다.

session.timeout.ms

유형: int
기본값: 10000(10초)
중요도: high

작업자 오류를 감지하는 데 사용되는 타임아웃입니다. 작업자는 주기적인 하트비트를 전송하여 브로커에 활성을 나타냅니다. 이 세션이 만료되기 전에 브로커가 하트비트를 수신하지 않으면 브로커는 그룹에서 작업자를 제거하고 재조정을 시작합니다. 값은 브로커 구성에 구성된 대로 허용 범위에 있어야 합니다 .min.session.timeout.ms 및 group.max.session.timeout.ms.ms .

ssl.key.password

유형: password
기본값: null
Importance: high

키 저장소 파일에 있는 개인 키의 암호 또는 'ssl.keystore.key'에 지정된 PEM 키입니다. 이는 양방향 인증이 구성된 경우에만 클라이언트에 필요합니다.

ssl.keystore.certificate.chain

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 인증서 체인입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서 목록이 있는 PEM 형식만 지원합니다.

ssl.keystore.key

유형: password
기본값: null
Importance: high

'ssl.keystore.type'에 지정된 형식의 개인 키입니다. 기본 SSL 엔진 팩토리에서는 PKCS#8 키가 있는 PEM 형식만 지원합니다. 키가 암호화된 경우 'ssl.key.password'를 사용하여 키 암호를 지정해야 합니다.

ssl.keystore.location

유형: 문자열
기본값: null
Importance: high

키 저장소 파일의 위치입니다. 클라이언트의 경우 선택 사항이며 클라이언트의 양방향 인증에 사용할 수 있습니다.

ssl.keystore.password

유형: password
기본값: null
Importance: high

키 저장소 파일의 저장소 암호입니다. 이는 클라이언트에 선택 사항이며 'ssl.keystore.location'이 구성된 경우에만 필요합니다. PEM 형식에는 키 저장소 암호가 지원되지 않습니다.

ssl.truststore.certificates

유형: password
기본값: null
Importance: high

'ssl.truststore.type'에서 지정한 형식의 신뢰할 수 있는 인증서입니다. 기본 SSL 엔진 팩토리에서는 X.509 인증서가 있는 PEM 형식만 지원합니다.

ssl.truststore.location

유형: 문자열
기본값: null
Importance: high

신뢰 저장소 파일의 위치입니다.

ssl.truststore.password

유형: password
기본값: null
Importance: high

신뢰 저장소 파일의 암호입니다. 암호를 설정하지 않으면 구성된 신뢰 저장소 파일이 계속 사용되지만 무결성 검사가 비활성화됩니다. PEM 형식에 대해 신뢰 저장소 암호가 지원되지 않습니다.

client.dns.lookup

type : string
default: use_all_dns_ips
유효한 값: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Importance: medium

클라이언트에서 DNS 조회를 사용하는 방법을 제어합니다. use_all_dns_ips 로 설정된 경우 성공적인 연결이 설정될 때까지 반환된 각 IP 주소에 순서대로 연결합니다. 연결 해제 후 다음 IP가 사용됩니다. 모든 IP가 한 번 사용되면 클라이언트는 호스트 이름에서 IP를 다시 확인합니다(JVM 및 OS 캐시 DNS 이름 조회 모두). resolve_canonical_bootstrap_servers_only 로 설정된 경우 각 부트스트랩 주소를 정식 이름 목록으로 확인합니다. 부트스트랩 단계 후 use_all_dns_ips 와 동일하게 작동합니다.

connections.max.idle.ms

유형: long
기본값: 540000 (9 분)
중요도: 중간

이 구성에서 지정한 시간(밀리초) 후에 유휴 연결을 종료합니다.

connector.client.config.override.policy

유형: 문자열
기본값: All
Importance: medium

ConnectorClientConfigOverridePolicy 의 구현의 클래스 이름 또는 별칭입니다. 커넥터에서 재정의할 수 있는 클라이언트 구성을 정의합니다. 기본 구현은 모두 입니다. 즉, 커넥터 구성이 모든 클라이언트 속성을 재정의할 수 있습니다. 프레임워크의 다른 가능한 정책에는 클라이언트 속성을 재정의하지 못하도록 하는 None 이 포함되며, 커넥터가 클라이언트 주체 만 재정의할 수 있도록 하는 보안 주체가 포함됩니다.

receive.buffer.bytes

유형: int
기본값: 32768(32 키비바이트)
유효한 값: [0,…​]
Importance: medium

데이터를 읽을 때 사용할 TCP 수신 버퍼(SO_RCVBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

request.timeout.ms

유형: int
기본값: 40000(40초)
유효한 값: [0,…​]
Importance: medium

구성은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어합니다. 시간 초과가 경과하기 전에 응답을 수신하지 않으면 필요한 경우 클라이언트가 요청을 다시 전송하거나 재시도가 소진되면 요청을 다시 보냅니다.

sasl.client.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 클라이언트 콜백 처리기 클래스의 정규화된 이름입니다.

sasl.jaas.config

유형: password
기본값: null
Importance: medium

JAAS 구성 파일에서 사용하는 형식의 SASL 연결에 대한 JAAS 로그인 컨텍스트 매개변수입니다. JAAS 구성 파일 형식은 여기에 설명되어 있습니다. 값 형식은 loginModuleClass controlFlag (optionName=optionValue)*; 입니다. 브로커의 경우 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule이 필요합니다.

sasl.kerberos.service.name

유형: 문자열
기본값: null
Importance: medium

Kafka가 실행되는 Kerberos 주체 이름입니다. Kafka의 JAAS config 또는 Kafka의 config에서 정의할 수 있습니다.

sasl.login.callback.handler.class

유형: class
Default: null
Importance: medium

AuthenticateCallbackHandler 인터페이스를 구현하는 SASL 로그인 콜백 처리기 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 콜백 처리기 구성 앞에 리스너 접두사 및 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler입니다.

sasl.login.class

유형: class
Default: null
Importance: medium

로그인 인터페이스를 구현하는 클래스의 정규화된 이름입니다. 브로커의 경우 로그인 구성 앞에는 리스너 접두사와 SASL 메커니즘 이름 앞에 소문자를 붙여야 합니다. 예를 들어 listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin입니다.

sasl.mechanism

유형: 문자열
기본값: GSSAPI
Importance: medium

클라이언트 연결에 사용되는 SASL 메커니즘입니다. 이는 보안 공급자를 사용할 수 있는 메커니즘일 수 있습니다. GSSAPI는 기본 메커니즘입니다.

security.protocol

유형: 문자열
기본값: PLAINTEXT
Importance: medium

브로커와 통신하는 데 사용되는 프로토콜입니다. 유효한 값은 PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL입니다.

send.buffer.bytes

유형: int
기본값: 131072(128 kibibytes)
유효한 값: [0,…​]
Importance: medium

데이터를 전송할 때 사용할 TCP 전송 버퍼(SO_SNDBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

ssl.enabled.protocols

type: list: list
default: TLSv1.2,TLSv1.3
Importance: medium

SSL 연결에 활성화된 프로토콜 목록입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.2,TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. Java 11의 기본값을 사용하면 클라이언트와 서버는 TLSv1.2를 지원하고 그 대신 TLSv1.2를 모두 지원하는 경우 TLSv1.3을 선호합니다(적어도 TLSv1.2 이상 지원). 대부분의 경우 이 기본값은 정상이어야 합니다. ssl.protocol 의 구성 문서를 참조하십시오.

ssl.keystore.type

유형: 문자열
기본값: JKS
중요도: 중간

키 저장소 파일의 파일 형식입니다. 클라이언트에는 선택 사항입니다.

ssl.protocol

유형: 문자열
기본값: TLSv1.3
중요도: 중간

SSLContext를 생성하는 데 사용되는 SSL 프로토콜입니다. Java 11 이상에서 실행하는 경우 기본값은 'TLSv1.3'이며, 그렇지 않으면 'TLSv1.2'입니다. 이 값은 대부분의 사용 사례에 적합해야 합니다. 최근 JVM에서 허용되는 값은 'TLSv1.2' 및 'TLSv1.3'입니다. 'TLS', 'TLSv1.1', 'SSL', 'SSLv2' 및 'SSLv3'은 이전 JVM에서 지원되지 않을 수 있지만 알려진 보안 취약점으로 인해 사용이 권장되지 않습니다. 이 구성 및 'ssl.enabled.protocols'의 기본값을 사용하면 서버가 'TLSv1.3'을 지원하지 않는 경우 클라이언트가 'TLSv1.2'로 다운그레이드됩니다. 이 구성이 'TLSv1.2'로 설정된 경우 클라이언트는 ssl.enabled.protocols의 값 중 하나이고 서버가 'TLSv1.3'만 지원하는 경우에도 'TLSv1.3'을 사용하지 않습니다.

ssl.provider

유형: 문자열
기본값: null
Importance: medium

SSL 연결에 사용되는 보안 공급자의 이름입니다. 기본값은 JVM의 기본 보안 공급자입니다.

ssl.truststore.type

유형: 문자열
기본값: JKS
중요도: 중간

신뢰 저장소 파일의 파일 형식입니다.

worker.sync.timeout.ms

유형: int
기본값: 3000 (3초)
중요도: 중간

작업자가 다른 작업자와 동기화되지 않고 구성을 다시 동기화해야 하는 경우, 포기하기 전에 이 시간까지 기다린 후 그룹을 종료한 후 다시 가입하기 전에 백오프 기간을 기다립니다.

worker.unsync.backoff.ms

유형: int
기본값: 300000 (5분)
중요도: 중간

작업자가 다른 작업자와 동기화되지 않고 worker.sync.timeout.ms 내에서 catch하지 못하면 다시 가입하기 전에 이 기간 동안 연결 클러스터를 남겨 둡니다.

access.control.allow.methods

유형: 문자열
기본값: ""
중요도: 낮음

Access-Control-Allow-Methods 헤더를 설정하여 교차 원본 요청에 지원되는 메서드를 설정합니다. Access-Control-Allow-Methods 헤더의 기본값은 GET, POST 및 HEAD에 대한 교차 원본 요청을 허용합니다.

access.control.allow.origin

유형: 문자열
기본값: ""
중요도: 낮음

값을 REST API 요청에 대해 Access-Control-Allow-Origin 헤더를 설정하여 교차 원본 액세스를 활성화하려면 이 헤더를 API에 액세스하도록 허용하거나 '*'를 사용하여 모든 도메인의 액세스를 허용합니다. 기본값은 REST API의 도메인에서만 액세스할 수 있습니다.

admin.listeners

type: list
default: null
유효한 값: 쉼표로 구분된 URL 목록, 예: http://localhost:8080,https://localhost:8443.
가져오기: 낮음

Admin REST API가 수신 대기할 쉼표로 구분된 URI 목록입니다. 지원되는 프로토콜은 HTTP 및 HTTPS입니다. 빈 문자열 또는 빈 문자열은 이 기능을 비활성화합니다. 기본 동작은 일반 리스너를 사용하는 것입니다( 'listeners' 속성으로 지정됨).

client.id

유형: 문자열
기본값: ""
중요도: 낮음

요청을 수행할 때 서버에 전달할 id 문자열입니다. 이를 위해 논리적 애플리케이션 이름을 서버 측 요청 로깅에 포함하도록 허용하여 ip/port 이외의 요청 소스를 추적할 수 있습니다.

config.providers

type: list
default: ""
Importance: low

ConfigProvider 클래스의 쉼표로 구분된 이름은 지정된 순서로 로드 및 사용됩니다. ConfigProvider 인터페이스를 구현하면 외부화된 보안과 같은 커넥터 구성에서 변수 참조를 교체할 수 있습니다.

config.storage.replication.factor

유형: short
default: 3
유효한 값: Kafka 클러스터의 브로커 수보다 크지 않은 잠재적 숫자 또는 -1을 입력하여 브로커의 기본값
가져오기를 사용합니다.

구성 스토리지 주제를 생성할 때 사용되는 복제 요인입니다.

connect.protocol

유형: 문자열
기본값: sessioned
유효한 값: [eager, compatible, sessioned]
Importance: low

Kafka Connect 프로토콜의 호환성 모드입니다.

header.converter

유형: class
Default: org.apache.kafka.connect.storage.SimpleHeaderConverter
Importance: low

Kafka Connect 형식과 Kafka에 작성된 직렬화 형식 간에 변환하는 데 사용되는 HeaderConverter 클래스입니다. 이는 Kafka로 작성되거나 읽혀진 메시지의 헤더 값 형식을 제어하며, 커넥터가 커넥터와 독립적이므로 모든 커넥터가 직렬화 형식으로 작동할 수 있습니다. 일반적인 형식의 예로는 JSON 및 Avro가 있습니다. 기본적으로 SimpleHeaderConverter는 헤더 값을 문자열로 직렬화하고 스키마를 유추하여 역직렬화하는 데 사용됩니다.

inter.worker.key.generation.algorithm

유형: 문자열
기본값: HmacSHA256
유효한 값: 작업자 JVM에서 지원하는 모든 키 생성기 알고리즘
Importance: low

내부 요청 키를 생성하는 데 사용할 알고리즘입니다.

inter.worker.key.size

유형: int
default: null
Importance: low

내부 요청에 서명하는 데 사용할 키의 크기(비트)입니다. null인 경우 키 생성 알고리즘의 기본 키 크기가 사용됩니다.

inter.worker.key.ttl.ms

유형: int
Default: 3600000 (1 hour)
유효한 값: [0,…​,2147483647]
Importance: low

내부 요청 검증(밀리초)에 사용되는 생성된 세션 키의 TTL입니다.

inter.worker.signature.algorithm

유형: 문자열
기본값: HmacSHA256
유효한 값: 작업자 JVM에서 지원하는 모든 MAC 알고리즘
Importance: low

내부 요청에 서명하는 데 사용되는 알고리즘입니다.

inter.worker.verification.algorithms

type: list: list
Default: HmacSHA256
Valid Values: 하나 이상의 MAC 알고리즘 목록으로, 각각 작업자 JVM에서 지원하는중요도: 낮음

내부 요청을 확인하는 허용된 알고리즘 목록입니다.

리스너

type: list
default: http://:8083
유효한 값: 쉼표로 구분된 URL 목록, 예: http://localhost:8080,https://localhost:8443.
Importance: low

REST API가 수신 대기할 쉼표로 구분된 URI 목록입니다. 지원되는 프로토콜은 HTTP 및 HTTPS입니다. 모든 인터페이스에 바인딩하려면 호스트 이름을 0.0.0.0으로 지정합니다. 기본 인터페이스에 바인딩하려면 호스트 이름을 비워 둡니다. 법적 리스너 목록의 예: HTTP://myhost:8083,HTTPS://myhost:8084.

metadata.max.age.ms

유형: long
기본값: 300000 (5분)
유효한 값: [0,…​]
중요: 낮음

파티션 리더십 변경 사항을 보지 못하더라도 새 브로커 또는 파티션을 사전에 검색하지 못한 경우에도 메타데이터를 강제로 새로 고침한 후 밀리초 단위입니다.

metric.reporters

type: list
default: ""
Importance: low

메트릭 보고자로 사용할 클래스 목록입니다. org.apache.kafka.common.metrics.MetricsReporter 인터페이스를 구현하면 새 메트릭 생성을 알리는 클래스를 연결할 수 있습니다. JmxReporter는 항상 statistics를 등록하기 위해 포함되어 있습니다.

metrics.num.samples

유형: int
기본값: 2
유효한 값: [1,…​]
중요도: 낮음

컴퓨팅 메트릭에 유지 관리되는 샘플 수입니다.

metrics.recording.level

유형: 문자열
기본값: INFO
유효한 값: [INFO, DEBUG]
Importance: low

메트릭의 가장 높은 레코딩 수준입니다.

metrics.sample.window.ms

유형: long
기본값: 30000(30초)
유효한 값: [0,…​]
중요도: 낮음

메트릭 샘플이 계산되는 시간입니다.

offset.flush.interval.ms

유형: long
기본값: 60000(1분)
중요도: 낮음

작업에 대한 오프셋을 커밋하는 간격입니다.

offset.flush.timeout.ms

유형: long
기본값: 5000 (5초)
중요도: 낮음

레코드를 플러시하고 파티션 오프셋 데이터가 프로세스를 취소하고 나중에 커밋할 오프셋 데이터를 복원하기 전에 레코드가 플러시 및 파티션 오프셋 데이터를 커밋할 때까지 대기하는 최대 시간(밀리초)입니다.

offset.storage.partitions

유형: int
default: 25
유효한 값: Positive number 또는 -1 to use the broker's default
Importance: low

오프셋 스토리지 주제를 생성할 때 사용되는 파티션 수입니다.

offset.storage.replication.factor

유형: short
default: 3
유효한 값: Kafka 클러스터의 브로커 수보다 크지 않은 잠재적 숫자 또는 -1을 입력하여 브로커의 기본값
가져오기를 사용합니다.

오프셋 스토리지 주제를 생성할 때 사용되는 복제 요인입니다.

plugin.path

type: list
default: null
Importance: low

플러그인(연결자, 변환기, 변환)을 포함하는 쉼표(,)로 구분된 경로 목록입니다. 목록은 플러그인과 종속 항목 b가 있는 KubeletConfigs를 즉시 포함하는 상위 수준 디렉터리로 구성되어야 합니다. b) 플러그인 및 종속 항목 c가 포함된 uber-jars는 플러그인 클래스의 패키지 디렉토리 구조와 해당 종속 항목 Note: symlinks를 검색하여 종속 항목 또는 플러그인을 검색하도록 따릅니다. 예: plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors 구성 공급자 변수를 사용하지 않습니다. 구성 공급자가 초기화되고 변수를 교체하기 전에 작업자의 스캐너에서 원시 경로를 사용하므로 이 속성의 구성 공급자 변수를 사용하지 않습니다.

reconnect.backoff.max.ms

유형: long
기본값: 1000 (1 second)
유효한 값: [0,…​]
중요도: 낮음

반복적으로 연결하지 못한 브로커에 다시 연결할 때 대기하는 최대 시간(밀리초)입니다. 제공된 경우 호스트당 백오프는 연속되는 각 연결 오류에 대해 이 최대값까지 기하급수적으로 증가합니다. 백오프 증가를 계산한 후 연결 측정을 방지하기 위해 20%의 임의 지터가 추가됩니다.

reconnect.backoff.ms

유형: long
기본값: 50
유효한 값: [0,…​]
중요도: 낮음

지정된 호스트에 다시 연결하기 전에 대기하는 기본 시간입니다. 이렇게 하면 하드 루프로 호스트에 반복적으로 연결하는 것을 방지할 수 있습니다. 이 백오프는 클라이언트가 브로커에 대한 모든 연결 시도에 적용됩니다.

response.http.headers.config

type : string
Default: ""
Valid Values: Comma-separated header rules, 여기서 각 헤더 규칙은 '[action] [header name]:[header name]:[header value]' 형식으로 묶고, 필요에 따라 헤더 규칙의 일부가 쉼표
Importance 가 포함된 경우 큰따옴표로 묶습니다.

REST API HTTP 응답 헤더에 대한 규칙입니다.

rest.advertised.host.name

유형: 문자열
기본값: null
Importance: low

이 값이 설정되면 연결할 다른 작업자에게 제공되는 호스트 이름입니다.

rest.advertised.listener

유형: 문자열
기본값: null
Importance: low

사용할 다른 작업자에게 제공될 공개된 리스너(HTTP 또는 HTTPS)를 설정합니다.

rest.advertised.port

유형: int
default: null
Importance: low

이 값이 설정되면 연결할 다른 작업자에게 제공될 포트입니다.

rest.extension.classes

type: list
default: ""
Importance: low

ConnectRestExtension 클래스의 쉼표로 구분된 이름은 지정된 순서로 로드 및 호출됩니다. ConnectRestExtension 인터페이스를 구현하면 필터와 같은 Connect의 REST API 사용자 정의 리소스에 삽입할 수 있습니다. 일반적으로 로깅, 보안 등과 같은 사용자 지정 기능을 추가하는 데 사용됩니다.

retry.backoff.ms

유형: long
기본값: 100
유효한 값: [0,…​]
중요도: 낮음

지정된 주제 파티션에 대한 실패한 요청을 재시도하기 전에 대기하는 시간입니다. 이렇게 하면 일부 실패 시나리오에서 엄격한 루프로 요청을 반복적으로 보내는 것을 방지할 수 있습니다.

sasl.kerberos.kinit.cmd

유형: 문자열
기본값: /usr/bin/kinit
Importance: low

Kerberos kinit 명령 경로입니다.

sasl.kerberos.min.time.before.relogin

유형: long
기본값: 60000
중요도: 낮음

새로 고침 시도 사이의 로그인 스레드 수면 시간입니다.

sasl.kerberos.ticket.renew.jitter

유형: 두 번
기본값: 0.05
중요도: 낮음

갱신 시간에 임의 지터의 백분율이 추가되었습니다.

sasl.kerberos.ticket.renew.window.factor

유형: double
기본값: 0.8
중요도: 낮음

로그인 스레드는 지정된 시간 요소가 마지막으로 새로 고침에서 티켓 만료로 도달할 때까지 유휴 상태가 되고 이 기간 동안 티켓을 갱신하려고 합니다.

sasl.login.refresh.buffer.seconds

유형: short
기본값: 300
유효한 값: [0,…​,3600]
중요도: 낮음

인증 정보를 새로 고칠 때 유지 관리하는 인증 정보 만료 전의 버퍼 시간(초)입니다. 새로 고침이 버퍼 초 수보다 만료되는 경우 새로 고침은 가능한 한 많은 버퍼 시간을 유지하기 위해 이동합니다. 법적 값은 0에서 3600(1시간) 사이입니다. 값이 지정되지 않은 경우 기본값 300(5분)이 사용됩니다. 이 값과 sasl.login.refresh.min.period.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.min.period.seconds

유형: short
기본값: 60
유효한 값: [0,…​,900]
중요도: 낮음

로그인 새로 고침 스레드가 인증 정보를 새로 고치기 전에 대기하는 최소 시간(초)입니다. 법적 값은 0에서 900 (15 분) 사이입니다. 값이 지정되지 않은 경우 기본값 60 (1 분)이 사용됩니다. 이 값과 sasl.login.refresh.buffer.seconds 값은 합계가 인증 정보의 나머지 수명을 초과하면 둘 다 무시됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.factor

유형: double
기본값: 0.8
유효한 값: [0.5,…​,1.0]
중요: 낮음

로그인 새로 고침 스레드는 인증 정보의 수명을 기준으로 지정된 창 요인에 도달할 때까지 유휴 상태가 되어 인증 정보를 새로 고치려고 합니다. 법적 값은 0.5(50%)와 1.0(100%)을 포함합니다. 값이 지정되지 않은 경우 기본값 0.8(80%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

sasl.login.refresh.window.jitter

유형: double
기본값: 0.05
유효한 값: [0.0,…​,0.25]
중요도: 낮음

로그인 새로 고침 스레드의 수면 시간에 추가되는 인증 정보의 수명을 기준으로 임의 지터의 최대 양입니다. 법적 값은 0에서 0.25 (25 %) 사이이며, 값이 지정되지 않은 경우 기본값 0.05 (5%)가 사용됩니다. 현재 OAUTHBEARER에만 적용됩니다.

scheduled.rebalance.max.delay.ms

유형: int
기본값: 300000 (5분)
유효한 값: [0,…​,2147483647]
Importance: low

커넥터와 작업을 그룹에 재조정하고 다시 할당하기 전에 하나 이상의 분리된 작업자의 반환을 대기하도록 예약된 최대 지연입니다. 이 기간 동안 분리된 작업자의 커넥터와 작업은 할당되지 않은 상태로 유지됩니다.

socket.connection.setup.timeout.max.ms

유형: long
기본값: 30000(30초)
유효한 값: [0,…​]
중요도: 낮음

클라이언트가 소켓 연결이 설정될 때까지 대기하는 최대 시간입니다. 연결 설정 시간 초과는 연속 연결 오류마다 이 최대값까지 기하급수적으로 증가합니다. 연결 불란을 방지하기 위해 0.2의 무작위화 요소가 시간 초과에 적용되어 계산된 값보다 20% 이하에서 20% 사이의 임의 범위가 됩니다.

socket.connection.setup.timeout.ms

유형: long
기본값: 10000(10초)
유효한 값: [0,…​]
중요도: 낮음

클라이언트가 소켓 연결이 설정될 때까지 대기하는 시간입니다. 시간 초과가 경과하기 전에 연결이 빌드되지 않으면 클라이언트가 소켓 채널을 종료합니다.

ssl.cipher.suites

type: list
default: null
Importance: low

암호화 제품군 목록입니다. 이는 TLS 또는 SSL 네트워크 프로토콜을 사용하여 네트워크 연결에 대한 보안 설정을 협상하는 데 사용되는 인증, 암호화, MAC 및 키 교환 알고리즘의 이름이 지정된 조합입니다. 기본적으로 사용 가능한 모든 암호화 제품군이 지원됩니다.

ssl.client.auth

유형: 문자열
기본값: none
Importance: low

클라이언트 인증을 요청하도록 kafka 브로커를 구성합니다. 다음은 일반적인 설정입니다.

  • SSL.client.auth=required 필수 클라이언트 인증으로 설정된 경우.
  • SSL.client.auth=requested 이는 클라이언트 인증이 선택 사항임을 의미합니다. 이 옵션이 설정된 경우 클라이언트는 자체적으로 인증 정보를 제공하지 않도록 선택할 수 있습니다.
  • SSL.client.auth=none 이는 클라이언트 인증이 필요하지 않음을 의미합니다.
ssl.endpoint.identification.algorithm

유형: 문자열
기본값: https
Importance: low

서버 인증서를 사용하여 서버 호스트 이름을 확인하는 끝점 식별 알고리즘입니다.

ssl.engine.factory.class

유형: class
Default: null
Importance: low

SSLEngine 개체를 제공하는 org.apache.kafka.common.security.auth.SslEngineFactory 유형의 클래스입니다. 기본값은 org.apache.kafka.common.security.ssl.DefaultSslEngineFactory입니다.

ssl.keymanager.algorithm

유형: 문자열
기본값: SunX509
중요: 낮음

SSL 연결에 대해 키 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java Virtual Machine에 대해 구성된 키 관리자 팩토리 알고리즘입니다.

ssl.secure.random.implementation

유형: 문자열
기본값: null
Importance: low

SSL 암호화 작업에 사용할 SecureRandom PRNG 구현

ssl.trustmanager.algorithm

유형: 문자열
기본값: PKIX
Importance: low

SSL 연결에 대해 신뢰 관리자 팩토리에서 사용하는 알고리즘입니다. 기본값은 Java 가상 머신에 대해 구성된 신뢰 관리자 팩토리 알고리즘입니다.

status.storage.partitions

유형: int
default: 5
유효한 값: Positive number, -1 to use the broker's default
Importance: low

상태 스토리지 주제를 생성할 때 사용되는 파티션 수입니다.

status.storage.replication.factor

유형: short
default: 3
유효한 값: Kafka 클러스터의 브로커 수보다 크지 않은 잠재적 숫자 또는 -1을 입력하여 브로커의 기본값
가져오기를 사용합니다.

상태 스토리지 주제를 생성할 때 사용되는 복제 요인입니다.

task.shutdown.graceful.timeout.ms

유형: long
기본값: 5000 (5초)
중요도: 낮음

작업이 정상적으로 종료될 때까지 대기하는 시간입니다. 이는 작업이 아닌 총 시간입니다. 모든 작업이 중단된 후 순차적으로 대기합니다.

topic.creation.enable

유형: 부울
기본값: true
Importance: low

소스 커넥터에서 사용하는 주제 자동 생성을 허용할지 여부, 소스 커넥터가 topic.creation. 속성으로 구성되는 경우. 각 작업에서는 관리 클라이언트를 사용하여 주제를 생성하고 Kafka 브로커에 따라 주제를 자동으로 생성하지 않습니다.

topic.tracking.allow.reset

유형: 부울
기본값: true
Importance: low

true로 설정하면 사용자 요청이 커넥터당 활성 항목 집합을 재설정할 수 있습니다.

topic.tracking.enable

유형: 부울
기본값: true
Importance: low

런타임 중에 커넥터당 활성 항목 집합을 추적할 수 있습니다.

부록 G. Kafka Streams 구성 매개변수
링크 복사

application.id

유형: 문자열
Importance: high

스트림 처리 애플리케이션의 식별자입니다. Kafka 클러스터 내에서 고유해야 합니다. 1) 기본 클라이언트-id 접두사, 2) 멤버십 관리의 group-id, 3) 변경 로그 주제 접두사로 사용됩니다.

bootstrap.servers

유형: list
Importance: high

Kafka 클러스터에 대한 초기 연결을 설정하는 데 사용할 호스트/포트 쌍 목록입니다. 클라이언트는 부트스트랩을 위해 여기에 지정된 서버를 여기에 관계없이 모든 서버를 사용합니다. 이 목록은 전체 서버 세트를 검색하는 데 사용되는 초기 호스트에만 영향을 미칩니다. 이 목록은 host1:port1,host2:port2,…​ 이어야 합니다. 이러한 서버는 초기 연결에서 전체 클러스터 멤버십을 검색하는 데만 사용되므로(동적으로 변경될 수 있음) 이 목록에는 전체 서버 세트가 포함되지 않아도 됩니다(서버가 다운된 경우 하나 이상 필요).

state.dir

type: string
Default: /tmp/kafka-streams
Importance: high

상태 저장소의 디렉터리 위치입니다. 이 경로는 동일한 기본 파일 시스템을 공유하는 각 스트림 인스턴스에 대해 고유해야 합니다.

acceptable.recovery.lag

유형: long
기본값: 10000
유효한 값: [0,…​]
중요도: 중간

클라이언트가 활성 작업에 대해 고집된 것으로 간주되는 최대 허용 지연( offsets to catch)입니다.Should는 지정된 워크로드에 대해 1분 미만의 복구 시간에 해당합니다. 최소 0이어야 합니다.

cache.max.bytes.buffering

유형: long
기본값: 10485760
유효한 값: [0,…​]
중요: 중간

모든 스레드에서 버퍼링에 사용할 최대 메모리 바이트 수입니다.

client.id

type: string
Default: ""
Importance: medium

내부 소비자, 생산자 및 restore-consumer의 클라이언트 ID에 사용되는 ID 접두사 문자열과 패턴 '<client.id>-StreamThread-<threadSequenceNumber>-<consumer|producer|restore-consumer>'입니다.

default.deserialization.exception.handler

유형: class
Default: org.apache.kafka.streams.errors.LogAndFailExceptionHandler
Importance: medium

org.apache.kafka.streams.errors.DeserializationExceptionHandler 인터페이스를 구현하는 예외 처리 클래스입니다.

default.key.serde

유형: class
Default: null
Importance: medium

org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 키에 대한 기본 serializer / deserializer 클래스입니다. windowed serde 클래스를 사용할 때 'default.windowed.key.serde.inner' 또는 'default.windowed.value.serde.inner'를 통해 org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 내부 serde 클래스를 설정해야 합니다.

default.list.key.serde.inner

유형: class
Default: null
Importance: medium

org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 키에 대한 기본 내부 목록 serde 클래스입니다. 이 구성은 default.key.serde 구성이 org.apache.kafka.common.serialization.Serdes.ListSerde 로 설정된 경우에만 읽습니다.

default.list.key.serde.type

유형: class
Default: null
Importance: medium

java.util.List 인터페이스를 구현하는 키에 대한 기본 클래스입니다. 이 구성은 목록 serde 클래스를 사용할 때 default.key.serde 구성이 org.apache.kafka.common.serialization.ListSerde 로 설정된 경우에만 읽습니다. 'default.key.common.serialization.Serde'를 통해 org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 내부 serde 클래스를 설정해야 합니다.

default.list.value.serde.inner

유형: class
Default: null
Importance: medium

org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 값에 대한 기본 내부 목록 serde 클래스입니다. 이 구성은 default.value.serde 구성이 org.apache.kafka.common.serialization.Serdes.ListSerde 로 설정된 경우에만 읽습니다.

default.list.value.serde.type

유형: class
Default: null
Importance: medium

java.util.List 인터페이스를 구현하는 값의 기본 클래스입니다. 이 구성은 목록 serde 클래스를 사용할 때 default.value.serde 구성이 org.apache.kafka.common.serialization.Serde로 설정된 경우에만 읽기됩니다. 목록 serde 클래스를 사용하면 'default.list.common.serialization.Serde 인터페이스를 통해 org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 내부 serde 클래스를 설정해야 합니다.

default.production.exception.handler

유형: class
Default: org.apache.kafka.streams.errors.DefaultProductionExceptionHandler
Importance: medium

org.apache.kafka.streams.errors.ProductionExceptionHandler 인터페이스를 구현하는 예외 처리 클래스입니다.

default.timestamp.extractor

유형: class
Default: org.apache.kafka.streams.processor.FailOnInvalidTimestamp
Importance: medium

org.apache.kafka.streams.processor.TimestampExtractor 인터페이스를 구현하는 기본 타임스탬프 추출기 클래스입니다.

default.value.serde

유형: class
Default: null
Importance: medium

org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 값에 대한 기본 serializer / deserializer 클래스입니다. windowed serde 클래스를 사용할 때 'default.windowed.key.serde.inner' 또는 'default.windowed.value.serde.inner'를 통해 org.apache.kafka.common.serialization.Serde 인터페이스를 구현하는 내부 serde 클래스를 설정해야 합니다.

max.task.idle.ms

유형: long
기본값: 0
Importance: medium

이 구성에서는 조인과 병합이 순서가 없는 결과를 생성할 수 있는지 여부를 제어합니다. config 값은 스트림 작업이 일부(모든) 입력 파티션이 추가 레코드를 보내고 여러 입력 스트림에서 주문 아웃 레코드 처리를 방지할 때까지 대기할 때 스트림 작업이 유휴 상태로 유지되는 최대 시간(밀리초)입니다. 기본값(영)은 생산자가 더 많은 레코드를 보낼 때까지 기다리지 않지만 브로커에 이미 존재하는 데이터를 가져올 때까지 기다립니다. 이 기본값은 브로커에 이미 존재하는 레코드의 경우 Streams가 타임스탬프 순서로 처리합니다. 유휴 상태를 완전히 비활성화하고 로컬에서 사용 가능한 데이터를 처리하려면 -1로 설정합니다. 이렇게 하면 순서가 부족해질 수 있습니다.

max.warmup.replicas

유형: int
기본값: 2
유효한 값: [1,…​]
Importance: medium

하나의 인스턴스에서 작업을 사용할 수 있도록 한 번에 할당할 수 있는 최대 웜업 복제본 수(구성된 num.standbys 이외의 추가 대기 시간)는 다시 할당되었습니다. 고가용성에 사용할 수 있는 추가 브로커 트래픽 및 클러스터 상태를 제한하는 데 사용됩니다. 최소 1개여야 합니다.

num.standby.replicas

유형: int
기본값: 0
Importance: medium

각 작업의 대기 복제본 수입니다.

num.stream.threads

유형: int
기본값: 1
Importance: medium

스트림 처리를 실행할 스레드 수입니다.

processing.guarantee

type : string
default: at_least_once
유효한 값: [at_least_once, exactly_once, exactly_once_beta, exactly_once_v2]
Importance: medium

이를 사용해야 하는 처리 보증입니다. 가능한 값은 at_least_once (기본값) 및 exactly_once_v2 입니다(개체 버전 2.5 이상 필요). 더 이상 사용되지 않는 옵션은 exactly_once ( 브로커 버전 0.11.0 이상 필요) 및 exactly_once_beta (개체 버전 2.5 이상 필요)입니다. exactly-once 처리에는 기본적으로 3개 이상의 브로커 클러스터가 필요합니다. 개발의 경우 브로커 설정 transaction.state.log.replication.factor 및 transaction.state.log.min.isr 을 조정하여 이 설정을 변경할 수 있습니다.

replication.factor

유형: int
기본값: -1
Importance: medium

스트림 처리 애플리케이션에서 만든 변경 로그 주제 및 다시 분할 주제의 복제 요소입니다. 기본값 -1 (즉, 브로커 기본 복제 요소 사용)에는 브로커 버전 2.4 이상이 필요합니다.

security.protocol

유형: 문자열
기본값: PLAINTEXT
Importance: medium

브로커와 통신하는 데 사용되는 프로토콜입니다. 유효한 값은 PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL입니다.

task.timeout.ms

유형: long
기본값: 300000 (5분)
유효한 값: [0,…​]
중요: 중간

내부 오류로 인해 작업이 중단될 수 있는 최대 시간(밀리초)입니다. 오류가 발생할 때까지 재시도할 수 있습니다. 시간 초과 0ms의 경우 작업에서 첫 번째 내부 오류에 오류가 발생했습니다. 0ms보다 큰 시간 초과의 경우 오류가 발생하기 전에 작업은 한 번 이상 재시도합니다.

topology.optimization

type: string
default: none
유효한 값: [none, all]
Importance: medium

기본적으로 비활성화된 토폴로지를 최적화해야 하는 경우 Kafka Streams에 지시하는 구성입니다.

application.server

유형: 문자열
기본값: ""
중요도: 낮음

이 KafkaStreams 인스턴스의 상태 저장소 검색 및 대화형 쿼리에 사용할 수 있는 사용자 정의 엔드포인트를 가리키는 host:port 쌍입니다.

buffered.records.per.partition

유형: int
기본값: 1000
Importance: low

파티션당 버퍼링할 최대 레코드 수입니다.

built.in.metrics.version

유형: 문자열
기본값: latest
올바른 값: [latest]
Importance: low

사용할 기본 제공 메트릭의 버전입니다.

commit.interval.ms

유형: long
기본값: 30000(30초)
유효한 값: [0,…​]
중요도: 낮음

프로세서 위치를 저장할 빈도(밀리초)입니다. (참고: processing.guarantee 가 exactly_once_v2,exactly_once, 기본값은 100, 그렇지 않으면 기본값은 30000.

connections.max.idle.ms

유형: long
기본값: 540000 (9 분)
중요도: 낮음

이 구성에서 지정한 시간(밀리초) 후에 유휴 연결을 종료합니다.

metadata.max.age.ms

유형: long
기본값: 300000 (5분)
유효한 값: [0,…​]
중요: 낮음

파티션 리더십 변경 사항을 보지 못하더라도 새 브로커 또는 파티션을 사전에 검색하지 못한 경우에도 메타데이터를 강제로 새로 고침한 후 밀리초 단위입니다.

metric.reporters

type: list
default: ""
Importance: low

메트릭 보고자로 사용할 클래스 목록입니다. org.apache.kafka.common.metrics.MetricsReporter 인터페이스를 구현하면 새 메트릭 생성을 알리는 클래스를 연결할 수 있습니다. JmxReporter는 항상 statistics를 등록하기 위해 포함되어 있습니다.

metrics.num.samples

유형: int
기본값: 2
유효한 값: [1,…​]
중요도: 낮음

컴퓨팅 메트릭에 유지 관리되는 샘플 수입니다.

metrics.recording.level

유형: 문자열
기본값: INFO
유효한 값: [INFO, DEBUG, TRACE]
Importance: low

메트릭의 가장 높은 레코딩 수준입니다.

metrics.sample.window.ms

유형: long
기본값: 30000(30초)
유효한 값: [0,…​]
중요도: 낮음

메트릭 샘플이 계산되는 시간입니다.

poll.ms

유형: long
기본값: 100
중요도: 낮음

입력 대기를 차단하는 시간(밀리초)입니다.

probing.rebalance.interval.ms

유형: long
기본값: 600000(10분)
유효한 값: [60000,…​]
Importance: low

온난화를 완료하고 활성화될 준비가 된 웜업 복제본을 프로브하도록 리밸런스를 트리거하기 전에 대기하는 최대 시간(밀리초)입니다. 재조정은 할당의 균형을 조정할 때까지 계속 트리거됩니다. 최소 1분 이상이어야 합니다.

receive.buffer.bytes

유형: int
기본값: 32768(32kibibytes)
유효한 값: [-1,…​]
Importance: low

데이터를 읽을 때 사용할 TCP 수신 버퍼(SO_RCVBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

reconnect.backoff.max.ms

유형: long
기본값: 1000 (1 second)
유효한 값: [0,…​]
중요도: 낮음

반복적으로 연결하지 못한 브로커에 다시 연결할 때 대기하는 최대 시간(밀리초)입니다. 제공된 경우 호스트당 백오프는 연속되는 각 연결 오류에 대해 이 최대값까지 기하급수적으로 증가합니다. 백오프 증가를 계산한 후 연결 측정을 방지하기 위해 20%의 임의 지터가 추가됩니다.

reconnect.backoff.ms

유형: long
기본값: 50
유효한 값: [0,…​]
중요도: 낮음

지정된 호스트에 다시 연결하기 전에 대기하는 기본 시간입니다. 이렇게 하면 하드 루프로 호스트에 반복적으로 연결하는 것을 방지할 수 있습니다. 이 백오프는 클라이언트가 브로커에 대한 모든 연결 시도에 적용됩니다.

request.timeout.ms

유형: int
기본값: 40000(40초)
유효한 값: [0,…​]
중요: 낮음

구성은 클라이언트가 요청 응답을 기다리는 최대 시간을 제어합니다. 시간 초과가 경과하기 전에 응답을 수신하지 않으면 필요한 경우 클라이언트가 요청을 다시 전송하거나 재시도가 소진되면 요청을 다시 보냅니다.

재시도

유형: int
기본값: 0
유효한 값: [0,…​,2147483647]
Importance: low

값을 0보다 크게 설정하면 클라이언트가 일시적인 오류와 함께 실패하는 모든 요청을 다시 보냅니다. 값을 0 또는 MAX_VALUE 로 설정하고 해당 시간 초과 매개변수를 사용하여 클라이언트가 요청을 재시도하는 기간을 제어하는 것이 좋습니다.

retry.backoff.ms

유형: long
기본값: 100
유효한 값: [0,…​]
중요도: 낮음

지정된 주제 파티션에 대한 실패한 요청을 재시도하기 전에 대기하는 시간입니다. 이렇게 하면 일부 실패 시나리오에서 엄격한 루프로 요청을 반복적으로 보내는 것을 방지할 수 있습니다.

rocksdb.config.setter

유형: class
Default: null
Importance: low

org.apache.kafka.streams.state.RocksDBConfigSetter 인터페이스를 구현하는 Rocks DB 구성 setter 클래스 또는 클래스 이름입니다.

send.buffer.bytes

유형: int
기본값: 131072(128 kibibytes)
유효한 값: [-1,…​]
Importance: low

데이터를 전송할 때 사용할 TCP 전송 버퍼(SO_SNDBUF)의 크기입니다. 값이 -1이면 OS 기본값이 사용됩니다.

state.cleanup.delay.ms

유형: long
기본값: 600000 (10분)
중요도: 낮음

파티션이 마이그레이션될 때 상태를 삭제하기 전에 대기하는 시간(밀리초)입니다. 적어도 state.cleanup.delay.ms 에 대해 수정되지 않은 상태 디렉터리만 제거됩니다.

upgrade.from

유형: 문자열
null
올바른 값: [null, 0.10.0, 0.10.1, 0.10.2, 0.11.0, 1.0, 1.1, 2.0, 2.1, 2.2, 2.3]
중요도: 낮음

이전 버전과 호환되는 방식으로 업그레이드할 수 있습니다. 이는 [0.10.0, 1.1]에서 2.0 이상으로 업그레이드하거나 [2.0, 2.3]에서 2.4+로 업그레이드할 때 필요합니다. 2.4에서 최신 버전으로 업그레이드할 때 이 구성을 지정할 필요가 없습니다. 기본값은 null 입니다. 허용되는 값은 "0.10.0", "0.10.1", "0.10.2", "0.11.0", "1.0", "1.1", "2.0", "2.1", "2.2", "2.3"(해당 이전 버전에서 업그레이드할 때)입니다.

window.size.ms

유형: long
default: null
Importance: low

창 끝 시간을 계산하기 위해 역직렬화기의 창 크기를 설정합니다.

windowed.inner.class.serde

유형: 문자열
기본값: null
Importance: low

창 지정된 레코드의 내부 클래스에 대한 기본 직렬화기 / deserializer입니다. "
"'org.apache.kafka.common.serialization.Serde' 인터페이스를 구현해야 합니다. 이 구성을 KafkaStreams 애플리케이션에서 설정하면 Plain 소비자 클라이언트에서만 사용하므로 오류가 발생합니다.

windowstore.changelog.additional.retention.ms

유형: long
기본값: 86400000 (1 day)
중요: 낮음

로그에 조기에 데이터가 삭제되지 않도록 Windows maintainMs에 추가되었습니다. 클럭 드리프트를 허용합니다. 기본값은 1일입니다.

부록 H. 서브스크립션 사용
링크 복사

AMQ Streams는 소프트웨어 서브스크립션을 통해 제공됩니다. 서브스크립션을 관리하려면 Red Hat 고객 포털에서 계정에 액세스하십시오.

계정 액세스

  1. access.redhat.com 으로 이동합니다.
  2. 계정이 없는 경우 계정을 생성합니다.
  3. 계정에 로그인합니다.

서브스크립션 활성화

  1. access.redhat.com 으로 이동합니다.
  2. 내 서브스크립션 으로 이동합니다.
  3. 서브스크립션 활성화로 이동하여 16자리 활성화 번호를 입력합니다.

Zip 및 Tar 파일 다운로드

zip 또는 tar 파일에 액세스하려면 고객 포털을 사용하여 다운로드할 관련 파일을 찾습니다. RPM 패키지를 사용하는 경우 이 단계는 필요하지 않습니다.

  1. 브라우저를 열고 Red Hat Customer Portal 제품 다운로드 페이지에 access.redhat.com/downloads.
  2. JBOSS INTEGRATION 및 AUTOMATION 카테고리에서 Red Hat AMQ Streams 항목을 찾습니다.
  3. 원하는 AMQ Streams 제품을 선택합니다. 소프트웨어 다운로드 페이지가 열립니다.
  4. 구성 요소에 대한 다운로드 링크를 클릭합니다.

패키지용 시스템 등록

Red Hat Enterprise Linux에 RPM 패키지를 설치하려면 시스템을 등록해야 합니다. zip 또는 tar 파일을 사용하는 경우 이 단계가 필요하지 않습니다.

  1. access.redhat.com 으로 이동합니다.
  2. Registration Assistant 로 이동합니다.
  3. OS 버전을 선택하고 다음 페이지로 이동합니다.
  4. 시스템 터미널에서 나열된 명령을 사용하여 등록을 완료합니다.

자세한 내용은 Red Hat 고객 포털에 시스템 등록 및 서브스크립션 방법을 참조하십시오.

2024-03-20에 최종 업데이트된 문서

법적 공지
링크 복사

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat