OpenShift의 AMQ Streams 개요
OpenShift Container Platform에서 AMQ Streams 2.3의 기능 및 기능 검색
초록
보다 포괄적 수용을 위한 오픈 소스 용어 교체
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
1장. 주요 기능
AMQ Streams는 OpenShift 클러스터에서 Apache Kafka를 실행하는 프로세스를 간소화합니다.
이 안내서는 AMQ Streams에 대한 이해를 구축하기 위한 시작점으로 작성되었습니다. 이 가이드에서는 AMQ Streams의 핵심인 Kafka의 몇 가지 주요 개념을 도입하여 Kafka 구성 요소의 목적을 간략하게 설명합니다. Kafka를 보호하고 모니터링할 수 있는 옵션을 포함하여 구성 포인트가 요약되어 있습니다. AMQ Streams 배포에서는 Kafka 클러스터를 배포 및 관리할 수 있는 파일과 배포 구성 및 모니터링을 위한 예제 파일을 제공합니다.
Kafka를 배포 및 관리하는 데 사용되는 툴 외에도 일반적인 Kafka 배포가 설명되어 있습니다.
1.1. Kafka 기능
Kafka의 기본 데이터 스트림 처리 기능 및 구성 요소 아키텍처는 다음을 제공할 수 있습니다.
- 매우 높은 처리량과 짧은 대기 시간으로 데이터를 공유하는 마이크로 서비스 및 기타 애플리케이션
- 메시지 순서 보장
- 데이터 스토리지에서 애플리케이션 상태 재구성에 대한 메시지 되감기/재플레이
- 키-값 로그를 사용할 때 이전 레코드를 제거하는 메시지 압축
- 클러스터 구성의 수평 확장성
- 내결함성을 제어하기 위해 데이터 복제
- 즉시 액세스하기 위해 대량의 데이터 보존
1.2. Kafka 사용 사례
Kafka의 기능은 다음에 적합합니다.
- 이벤트 중심 아키텍처
- 이벤트 로그로 애플리케이션 상태에 대한 변경 사항을 캡처하기 위한 이벤트 소싱
- 메시지 브로커링
- 웹 사이트 활동 추적
- 메트릭을 통한 운영 모니터링
- 로그 수집 및 집계
- 분산 시스템에 대한 로그 커밋
- 애플리케이션이 데이터에 실시간으로 응답할 수 있도록 스트림 처리
1.3. AMQ Streams가 Kafka를 지원하는 방법
AMQ Streams는 OpenShift에서 Kafka를 실행하기 위한 컨테이너 이미지 및 Operator를 제공합니다. AMQ Streams Operator는 AMQ Streams의 실행의 기본입니다. AMQ Streams와 함께 제공되는 Operator는 Kafka를 효과적으로 관리하기 위해 전문가의 운영 지식을 기반으로 합니다.
Operator는 다음과 같은 프로세스를 단순화합니다.
- Kafka 클러스터 배포 및 실행
- Kafka 구성 요소 배포 및 실행
- Kafka에 대한 액세스 구성
- Kafka에 대한 액세스 보안
- Kafka 업그레이드
- 브로커 관리
- 주제 생성 및 관리
- 사용자 생성 및 관리
2장. Kafka의 AMQ Streams 배포
Apache Kafka 구성 요소는 AMQ Streams 배포를 사용하여 OpenShift에 배포할 수 있도록 제공됩니다. Kafka 구성 요소는 일반적으로 가용성을 위해 클러스터로 실행됩니다.
Kafka 구성 요소를 통합하는 일반적인 배포에는 다음이 포함될 수 있습니다.
- 브로커 노드의 Kafka 클러스터
- 복제된 ZooKeeper 인스턴스의 zookeeper 클러스터
- 외부 데이터 연결을 위한 Kafka Connect 클러스터
- 보조 클러스터에서 Kafka 클러스터를 미러링할 Kafka MirrorMaker 클러스터
- 모니터링을 위한 추가 Kafka 메트릭 데이터를 추출하기 위한 Kafka 내보내기
- Kafka 클러스터에 대한 HTTP 기반 요청 생성
이러한 구성 요소가 모두 필수는 아니지만 Kafka 및 ZooKeeper가 최소한 필요합니다. 일부 구성 요소는 MirrorMaker 또는 Kafka Connect와 같은 Kafka 없이 배포할 수 있습니다.
2.1. Kafka 구성 요소 아키텍처
Kafka 브로커의 클러스터는 메시지 전달을 처리합니다.
브로커는 구성 데이터를 저장하고 클러스터 조정을 위해 Apache ZooKeeper를 사용합니다. Apache Kafka를 실행하기 전에 Apache ZooKeeper 클러스터가 준비되어 있어야 합니다.
각 다른 Kafka 구성 요소는 Kafka 클러스터와 상호 작용하여 특정 역할을 수행합니다.
Kafka 구성 요소 상호 작용
- Apache ZooKeeper
- Apache ZooKeeper는 Kafka의 핵심 종속성으로, 클러스터 조정 서비스를 제공하고 브로커와 소비자의 상태를 저장하고 추적합니다. zookeeper는 컨트롤러 선택에도 사용됩니다.
- Kafka Connect
Kafka Connect는 커넥터 플러그인을 사용하여 Kafka 브로커와 기타 시스템 간에 데이터를 스트리밍하기 위한 통합 툴킷입니다. Kafka Connect는 커넥터를 사용하여 데이터를 가져오거나 내보내기 위해 데이터베이스 등의 외부 데이터 소스 또는 대상과 Kafka를 통합하기 위한 프레임워크를 제공합니다. 커넥터는 필요한 연결 구성을 제공하는 플러그인입니다.
- 소스 커넥터는 외부 데이터를 Kafka로 푸시합니다.
싱크 커넥터가 Kafka에서 데이터를 추출
외부 데이터가 변환되고 적절한 형식으로 변환됩니다.
데이터 연결에 필요한 커넥터 플러그인으로 컨테이너 이미지를 자동으로 빌드하는 빌드 구성으로 Kafka Connect를 배포할 수 있습니다.
- Kafka MirrorMaker
Kafka MirrorMaker는 데이터 센터 내부 또는 여러 Kafka 클러스터 간에 데이터를 복제합니다.
MirrorMaker는 소스 Kafka 클러스터에서 메시지를 가져와서 대상 Kafka 클러스터에 씁니다.
- Kafka 브리지
- Kafka 브리지는 HTTP 기반 클라이언트를 Kafka 클러스터와 통합하는 API를 제공합니다.
- Kafka Exporter
- Kafka Exporter는 분석을 위한 데이터를 Prometheus 지표, 주로 오프셋, 소비자 그룹, 소비자 지연 및 주제와 관련된 데이터를 추출합니다. 소비자 지연은 파티션에 기록된 마지막 메시지와 현재 소비자가 해당 파티션에서 선택 중인 메시지 간의 지연입니다.
3장. Kafka 정보
Apache Kafka는 내결함성 실시간 데이터 피드를 위한 오픈 소스 분산 게시-구독 메시징 시스템입니다.
Apache Kafka에 대한 자세한 내용은 Apache Kafka 설명서 를 참조하십시오.
3.1. Kafka가 메시지 브로커로 작동하는 방법
AMQ Streams 사용 환경을 극대화하려면 Kafka가 메시지 브로커로 작동하는 방식을 이해해야 합니다.
Kafka 클러스터는 여러 브로커로 구성됩니다. 브로커에는 데이터를 수신하고 저장하는 항목이 포함되어 있습니다. 주제는 데이터가 기록되는 파티션별로 나뉩니다. 파티션은 내결함성을 위해 주제 전체에 복제됩니다.
Kafka 브로커 및 주제
- broker
- 서버 또는 노드라고도 하는 브로커는 스토리지와 메시지 전달을 오케스트레이션합니다.
- 주제
- 주제에서는 데이터 스토리지의 대상을 제공합니다. 각 주제는 하나 이상의 파티션으로 나뉩니다.
- Cluster
- 브로커 인스턴스 그룹입니다.
- partition
- 주제 파티션 수는 주제 파티션 수 에 따라 정의됩니다.
- 파티션 리더
- 파티션 리더는 항목에 대한 모든 생산자 요청을 처리합니다.
- 파티션 추적기
파티션 추적자는 파티션 리더의 파티션 데이터를 복제하고 선택적으로 소비자 요청을 처리합니다.
항목에서는 복제 요소를 사용하여 클러스터 내 각 파티션의 복제본 수를 구성합니다. 주제는 하나 이상의 파티션을 포함합니다.
in-sync 복제본에는 리더와 동일한 메시지 수가 있습니다. 구성 에서는 메시지를 생성할 수 있도록 동기화 내 복제본 수를 정의하여 해당 메시지가 복제본 파티션에 성공적으로 복사된 후에만 커밋됩니다. 이렇게 하면 리더가 실패하면 메시지가 손실되지 않습니다.
Kafka 브로커 및 주제 다이어그램에서는 복제된 주제에서 번호가 매겨진 각 파티션에 리더와 두 개의 팔로워가 있음을 확인할 수 있습니다.
3.2. 생산자 및 소비자
생산자와 소비자는 브로커를 통해 메시지를 보내고 수신(게시 및 구독)합니다. 메시지는 선택적 키 와 메시지 데이터를 포함하는 값과 헤더 및 관련 메타데이터를 포함합니다. 키는 메시지 제목 또는 메시지의 속성을 식별하는 데 사용됩니다. 메시지는 일괄 처리로 전달되며, 일괄 처리 및 레코드에는 헤더와 메타데이터가 포함되어 있으며 여기에는 레코드의 타임스탬프 및 오프셋 위치와 같이 클라이언트가 필터링하고 라우팅하는 데 유용한 세부 정보가 있습니다.
생산자 및 소비자
- 프로듀서
- 생산자는 파티션의 마지막 오프셋에 쓸 브로커 항목에 메시지를 보냅니다. 메시지는 라운드 로빈 기반으로 프로듀서 또는 메시지 키를 기반으로 특정 파티션에 의해 파티션에 기록됩니다.
- 소비자
- 소비자는 주제를 구독하고 주제, 파티션 및 오프셋에 따라 메시지를 읽습니다.
- 소비자 그룹
-
소비자 그룹은 지정된 주제에서 여러 생산자가 생성하는 일반적으로 큰 데이터 스트림을 공유하는 데 사용됩니다. Consumer는
group.id를 사용하여 그룹화되므로 메시지가 멤버 전체에 분산됩니다. 그룹 내의 소비자는 동일한 파티션에서 데이터를 읽지 않지만 하나 이상의 파티션에서 데이터를 수신할 수 있습니다. - offsets
오프셋은 파티션 내의 메시지 위치를 설명합니다. 지정된 파티션의 각 메시지에는 고유한 오프셋이 있으므로 파티션 내에서 소비자의 위치를 식별하여 소비된 레코드 수를 추적하는 데 도움이 됩니다.
커밋된 오프셋은 오프셋 커밋 로그에 기록됩니다.
__consumer_offsets주제에서는 소비자 그룹에 따라 커밋된 오프셋, 마지막 및 다음 오프셋의 위치에 대한 정보를 저장합니다.
데이터 생성 및 사용
4장. Kafka Connect 정보
Kafka Connect는 Kafka 브로커와 기타 시스템 간에 데이터를 스트리밍하기 위한 통합 툴킷입니다. 다른 시스템은 일반적으로 데이터베이스 같은 외부 데이터 소스 또는 대상입니다.
Kafka Connect에서는 플러그인 아키텍처를 사용합니다. 플러그인을 사용하면 다른 시스템에 연결하고 데이터를 조작할 수 있는 추가 구성을 제공할 수 있습니다. 플러그인에는 커넥터 및 기타 구성 요소(예: 데이터 변환기 및 변환)가 포함됩니다. 커넥터는 특정 유형의 외부 시스템에서 작동합니다. 각 커넥터는 해당 구성의 스키마를 정의합니다. Kafka Connect에 구성을 제공하여 Kafka Connect 내에서 커넥터 인스턴스를 생성합니다. 그런 다음 커넥터 인스턴스는 시스템 간에 데이터를 이동하기 위한 일련의 작업을 정의합니다.
AMQ Streams는 분산 모드에서 Kafka Connect를 작동하여 하나 이상의 작업자 Pod에 데이터 스트리밍 작업을 배포합니다. Kafka Connect 클러스터는 작업자 Pod 그룹으로 구성됩니다. 각 커넥터는 단일 작업자에서 인스턴스화됩니다. 각 커넥터는 작업자 그룹에 배포되는 하나 이상의 작업으로 구성됩니다. 작업자 전체에 분산하면 확장성이 높은 파이프라인이 허용됩니다.
작업자는 한 형식의 데이터를 소스 또는 대상 시스템에 적합한 다른 형식으로 변환합니다. 커넥터 인스턴스의 구성에 따라 작업자도 변환을 적용할 수 있습니다(Single Message Transforms 또는 SMT라고도 함). 변환은 변환되기 전에 특정 데이터 필터링과 같은 메시지를 조정합니다. Kafka Connect에는 몇 가지 기본 제공 변환이 있지만 필요한 경우 플러그인으로 다른 변환을 제공할 수 있습니다.
4.1. Kafka Connect에서 데이터를 스트리밍하는 방법
Kafka Connect는 커넥터 인스턴스를 사용하여 다른 시스템과 통합하여 데이터를 스트리밍합니다.
Kafka Connect가 시작 시 기존 커넥터 인스턴스를 로드하고 작업자 pod 간에 데이터 스트리밍 작업 및 커넥터 구성을 배포합니다. 작업자는 커넥터 인스턴스에 대한 작업을 실행합니다. 각 작업자는 Kafka Connect 클러스터의 내결함성을 높이기 위해 별도의 Pod로 실행됩니다. 작업자보다 많은 작업이 있는 경우 작업자에는 여러 작업이 할당됩니다. 작업자가 실패하면 해당 작업은 Kafka Connect 클러스터의 활성 작업자에 자동으로 할당됩니다.
스트리밍 데이터에 사용되는 주요 Kafka Connect 구성 요소는 다음과 같습니다.
- 작업을 생성하는 커넥터
- 데이터 이동 작업
- 작업 실행 작업자
- 데이터를 조작하기 위한 변환
- 데이터를 변환할 변환기
4.1.1. 커넥터
커넥터는 다음 유형 중 하나일 수 있습니다.
- Kafka로 데이터를 푸시하는 소스 커넥터
- Kafka에서 데이터를 추출하는 싱크 커넥터
플러그인은 Kafka Connect에 대한 구현을 제공하여 커넥터 인스턴스를 실행합니다. 커넥터 인스턴스는 Kafka 내부 및 외부에서 데이터를 전송하는 데 필요한 작업을 생성합니다. Kafka Connect 런타임은 작업자 Pod 간에 필요한 작업을 분할하는 작업을 오케스트레이션합니다.
MirrorMaker 2.0도 Kafka Connect 프레임워크를 사용합니다. 이 경우 외부 데이터 시스템은 다른 Kafka 클러스터입니다. MirrorMaker 2.0의 특수 커넥터는 소스와 대상 Kafka 클러스터 간의 데이터 복제를 관리합니다.
MirrorMaker 2.0 커넥터 외에도 Kafka는 두 개의 커넥터를 예로 제공합니다.
-
gRPCSourceConnector는 작업자 파일 시스템의 파일에서 Kafka로 데이터를 스트리밍하여 입력 파일을 읽고 각 행을 지정된 Kafka 주제로 보냅니다. -
Kafka에서 작업자의 파일 시스템으로 데이터를 스트리밍하고, Kafka 주제에서 메시지를 읽고, 출력 파일의 각각에 대한 행을 작성합니다.
다음 소스 커넥터 다이어그램은 외부 데이터 시스템에서 레코드를 스트리밍하는 소스 커넥터의 프로세스 흐름을 보여줍니다. Kafka Connect 클러스터는 소스 및 싱크 커넥터를 동시에 작동할 수 있습니다. 작업자는 클러스터의 분산 모드에서 실행되고 있습니다. 작업자는 두 개 이상의 커넥터 인스턴스에 대해 하나 이상의 작업을 실행할 수 있습니다.
Kafka로 데이터를 스트리밍하는 소스 커넥터
- 플러그인은 소스 커넥터의 구현 아티팩트를 제공합니다.
- 단일 작업자가 소스 커넥터 인스턴스를 시작합니다.
- 소스 커넥터는 데이터를 스트리밍하는 작업을 생성
- 작업은 병렬로 실행되어 외부 데이터 시스템을 폴링하고 레코드를 반환합니다.
- 변환된 레코드 조정(예: 필터링 또는 레이블 재지정)
- 변환기는 레코드를 Kafka에 적합한 형식으로 배치합니다.
- 소스 커넥터는 KafkaConnectors 또는 Kafka Connect API를 사용하여 관리합니다.
다음 싱크 커넥터 다이어그램은 Kafka에서 외부 데이터 시스템으로 데이터를 스트리밍할 때 프로세스 흐름을 보여줍니다.
Kafka의 싱크 커넥터 스트리밍 데이터
- 플러그인은 싱크 커넥터의 구현 아티팩트를 제공합니다.
- 단일 작업자가 싱크 커넥터 인스턴스를 시작합니다.
- 싱크 커넥터가 데이터를 스트리밍하는 작업을 생성
- Task는 Kafka를 폴링하고 레코드를 반환하기 위해 병렬로 실행됩니다.
- 변환기는 레코드를 외부 데이터 시스템에 적합한 형식으로 배치합니다.
- 변환된 레코드 조정(예: 필터링 또는 레이블 재지정)
- 싱크 커넥터는 KafkaConnectors 또는 Kafka Connect API를 사용하여 관리합니다.
4.1.2. 작업
Kafka Connect 런타임에서 오케스트레이션한 데이터 전송은 병렬로 실행되는 작업으로 나뉩니다. 작업은 커넥터 인스턴스에서 제공하는 구성을 사용하여 시작됩니다. Kafka Connect는 작업을 인스턴스화하고 실행하는 작업자에 작업 구성을 배포합니다.
- 소스 커넥터 작업은 외부 데이터 시스템을 폴링하고 작업자가 Kafka 브로커에 전송하는 레코드 목록을 반환합니다.
- 싱크 커넥터 작업은 외부 데이터 시스템에 쓰기 위해 작업자로부터 Kafka 레코드를 수신합니다.
싱크 커넥터의 경우 생성된 작업 수는 소비되는 파티션 수와 관련이 있습니다. 소스 커넥터의 경우 소스 데이터를 분할하는 방법은 커넥터에 의해 정의됩니다. 커넥터 구성에서 tasksMax 를 설정하여 병렬로 실행할 수 있는 최대 작업 수를 제어할 수 있습니다. 커넥터는 최대 설정보다 적은 작업을 생성할 수 있습니다. 예를 들어 소스 데이터를 파티션 수로 분할할 수 없는 경우 커넥터는 더 적은 작업을 생성할 수 있습니다.
Kafka Connect의 컨텍스트에서 파티션 은 외부 시스템의 주제 파티션 또는 데이터 shard 를 의미할 수 있습니다.
4.1.3. Worker
작업자는 Kafka Connect 클러스터에 배포된 커넥터 구성을 사용합니다. 구성은 Kafka Connect에서 사용하는 내부 Kafka 항목에 저장됩니다. 작업자는 커넥터 및 해당 작업도 실행합니다.
Kafka Connect 클러스터에는 동일한 group.id 가 있는 작업자 그룹이 포함되어 있습니다. ID는 Kafka 내에서 클러스터를 식별합니다. ID는 KafkaConnect 리소스를 통해 작업자 구성에서 할당됩니다. 작업자 구성은 내부 Kafka Connect 주제의 이름도 지정합니다. 주제에서는 커넥터 구성, 오프셋 및 상태 정보를 저장합니다. 이 항목의 그룹 ID와 이름도 Kafka Connect 클러스터에 고유해야 합니다.
작업자에는 하나 이상의 커넥터 인스턴스 및 작업이 할당됩니다. Kafka Connect 배포에 대한 분산 접근 방식은 내결함성이며 확장 가능합니다. 작업자 Pod가 실패하면 실행 중인 작업이 활성 작업자에 다시 할당됩니다. KafkaConnect 리소스의 replicas 속성 구성을 통해 작업자 Pod 그룹에 추가할 수 있습니다.
4.1.4. 변환
Kafka Connect는 외부 데이터를 변환하고 변환합니다. 단일 메시지 변환은 메시지를 대상 대상에 적합한 형식으로 변환합니다. 예를 들어 변환에서 필드를 삽입하거나 이름을 변경할 수 있습니다.For example, a transform might insert or rename a field. 변환은 데이터를 필터링하고 라우팅할 수도 있습니다. 플러그인에는 작업자가 하나 이상의 변환을 수행하는 데 필요한 구현이 포함되어 있습니다.
- 소스 커넥터는 Kafka에서 지원하는 형식으로 데이터를 변환하기 전에 변환을 적용합니다.
- 싱크 커넥터는 데이터를 외부 데이터 시스템에 적합한 형식으로 변환한 후 적용합니다.
변환은 커넥터 플러그인에 포함하기 위해 JAR 파일에 패키지된 Java 클래스 파일 세트로 구성됩니다. Kafka Connect에서는 표준 변환 집합을 제공하지만 사용자 고유의 변환도 생성할 수 있습니다.
4.1.5. 변환기
작업자가 데이터를 수신할 때 변환기를 사용하여 데이터를 적절한 형식으로 변환합니다. KafkaConnect 리소스의 작업자 구성의 작업자 변환기를 지정합니다.
Kafka Connect는 JSON 또는 Avro와 같은 Kafka에서 지원하는 형식으로 데이터를 변환할 수 있습니다. 또한 데이터 구조를 위한 스키마도 지원합니다. 데이터를 구조화된 형식으로 변환하지 않으면 스키마를 활성화할 필요가 없습니다.
특정 커넥터의 변환기를 지정하여 모든 작업자에 적용되는 일반 Kafka Connect 작업자 구성을 덮어쓸 수도 있습니다.
5장. Kafka 브리지 인터페이스
Kafka 브리지는 HTTP 기반 클라이언트가 Kafka 클러스터와 상호 작용할 수 있는 RESTful 인터페이스를 제공합니다. 클라이언트 애플리케이션이 Kafka 프로토콜을 해석할 필요 없이 AMQ Streams에 웹 API 연결의 이점을 제공합니다.
API에는 Kafka 클러스터의 소비자 및 생산자와 상호 작용하기 위해 끝점을 통해 노출되고 액세스할 수 있는 두 가지 주요 리소스가 있습니다. 리소스는 Kafka에 직접 연결된 소비자 및 생산자가 아닌 Kafka 브릿지에만 관련이 있습니다.
5.1. HTTP 요청
Kafka 브리지는 다음을 수행하는 방법을 사용하여 Kafka 클러스터에 대한 HTTP 요청을 지원합니다.
- 메시지를 주제로 보냅니다.
- 주제에서 메시지 검색.
- 주제의 파티션 목록을 검색합니다.
- 소비자를 생성 및 삭제합니다.
- 소비자는 이러한 주제에서 메시지를 수신하기 시작할 수 있도록 주제를 구독하십시오.
- 소비자가 서브스크립션하는 주제 목록을 검색합니다.
- 주제에서 소비자의 구독을 취소합니다.
- 소비자에 파티션을 할당합니다.
- 소비자 오프셋 목록을 커밋합니다.
- 소비자가 첫 번째 또는 마지막 오프셋 위치 또는 지정된 오프셋 위치에서 메시지를 수신하기 시작하도록 파티션을 찾습니다.
이 방법은 JSON 응답 및 HTTP 응답 코드 오류 처리를 제공합니다. 메시지는 JSON 또는 바이너리 형식으로 보낼 수 있습니다.
클라이언트는 네이티브 Kafka 프로토콜을 사용해야 하는 요구 사항 없이 메시지를 생성하고 사용할 수 있습니다.
추가 리소스
- 요청 및 응답 예제를 포함하여 API 문서를 보려면 AMQ Streams Kafka Bridge 사용을 참조하십시오.
5.2. Kafka 브릿지에 지원되는 클라이언트
Kafka Bridge를 사용하여 내부 및 외부 HTTP 클라이언트 애플리케이션을 Kafka 클러스터와 통합할 수 있습니다.
- 내부 클라이언트
-
내부 클라이언트는 Kafka Bridge 자체와 동일한 OpenShift 클러스터에서 실행되는 컨테이너 기반 HTTP 클라이언트입니다. 내부 클라이언트는 KafkaBridge 사용자 정의 리소스에 정의된 호스트 및 포트에서
Kafka Bridge에 액세스할 수 있습니다. - 외부 클라이언트
- 외부 클라이언트는 Kafka 브리지가 배포되어 실행 중인 OpenShift 클러스터 외부에서 실행되는 HTTP 클라이언트입니다. 외부 클라이언트는 OpenShift 경로, 로드 밸런서 서비스 또는 Ingress를 사용하여 Kafka 브릿지에 액세스할 수 있습니다.
HTTP 내부 및 외부 클라이언트 통합
6장. AMQ Streams Operator
AMQ Streams는 Operator 를 사용하는 Kafka를 지원하여 OpenShift에 Kafka의 구성 요소 및 종속 항목을 배포하고 관리합니다.
Operator는 OpenShift 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. AMQ Streams Operator는 OpenShift 기능을 확장하여 Kafka 배포와 관련된 일반 및 복잡한 작업을 자동화합니다. 코드에서 Kafka 작업에 대한 지식을 구현하면 Kafka 관리 작업이 간소화되고 수동 개입이 줄어듭니다.
Operator
AMQ Streams는 OpenShift 클러스터 내에서 실행 중인 Kafka 클러스터를 관리하기 위한 Operator를 제공합니다.
- Cluster Operator
- Apache Kafka 클러스터, Kafka Connect, Kafka MirrorMaker, Kafka Bridge, Kafka Exporter, Cruise Control 및 Entity Operator를 배포 및 관리합니다.
- 엔터티 Operator
- 주제 Operator 및 사용자 Operator로 구성
- 주제 Operator
- Kafka 주제 관리
- User Operator
- Kafka 사용자 관리
Cluster Operator는 Kafka 클러스터와 동시에 Topic Operator 및 User Operator를 Entity Operator 구성의 일부로 배포할 수 있습니다.
AMQ Streams 아키텍처 내의 Operator
6.1. Cluster Operator
AMQ Streams는 Cluster Operator를 사용하여 클러스터를 배포 및 관리합니다. 기본적으로 AMQ Streams를 배포할 때 단일 Cluster Operator 복제본이 배포됩니다. 중단 시 추가 Cluster Operator가 제공되도록 리더 선택으로 복제본을 추가할 수 있습니다.
Cluster Operator는 다음 Kafka 구성 요소의 클러스터를 관리합니다.
- Kafka( ZooKeeper, Entity Operator, Kafka Exporter, Cruise Control 포함)
- Kafka Connect
- Kafka MirrorMaker
- Kafka 브리지
클러스터는 사용자 정의 리소스를 사용하여 배포됩니다.
예를 들어 Kafka 클러스터를 배포하려면 다음을 수행합니다.
-
클러스터 구성이 있는
Kafka리소스는 OpenShift 클러스터 내에서 생성됩니다. -
Cluster Operator는 Kafka 리소스에 선언된 내용에 따라 해당
Kafka클러스터를 배포합니다.
Cluster Operator는 Kafka 리소스의 구성을 통해 다음 AMQ Streams Operator를 배포할 수도 있습니다.
-
KafkaTopic사용자 정의 리소스를 통해 Operator 스타일 주제 관리를 제공하는 topic Operator -
KafkaUser사용자 정의 리소스를 통해 Operator 스타일 사용자 관리 제공
Topic Operator 및 User Operator는 배포 시 Entity Operator 내에서 작동합니다.
AMQ Streams DrainCleaner 배포와 함께 Cluster Operator를 사용하여 Pod 제거를 지원할 수 있습니다. AMQ Streams DrainCleaner를 배포하면 Cluster Operator를 사용하여 OpenShift 대신 Kafka Pod를 이동할 수 있습니다. AMQ Streams Drain Clearer는 롤링 업데이트 주석으로 제거되는 Pod에 주석을 답니다. 주석은 Cluster Operator에 롤링 업데이트를 수행하도록 알립니다.
Cluster Operator의 아키텍처 예
6.2. 주제 Operator
Topic Operator는 OpenShift 리소스를 통해 Kafka 클러스터에서 주제를 관리하는 방법을 제공합니다.
Topic Operator의 아키텍처 예
Topic Operator의 역할은 해당 Kafka 주제와의 동기화에서 Kafka 주제를 설명하는 KafkaTopic OpenShift 리소스 세트를 유지하는 것입니다.
특히 KafkaTopic 이 있는 경우:
- 생성된 주제 Operator에서 주제를 생성합니다.
- 삭제된 주제를 삭제합니다.
- 변경되어 Topic Operator에서 주제를 업데이트합니다.
주제가 있는 경우 다른 방향으로 작업합니다.
-
Kafka 클러스터 내에서 생성된 Operator는
KafkaTopic을 생성합니다. -
Kafka 클러스터에서 삭제된 Operator는
KafkaTopic을 삭제합니다. -
Kafka 클러스터에서 변경되어 Operator는
KafkaTopic을 업데이트합니다.
이를 통해 KafkaTopic 을 애플리케이션 배포의 일부로 선언할 수 있으며 Topic Operator는 해당 주제를 생성합니다. 애플리케이션은 필요한 주제를 생성하거나 소비하기만 하면 됩니다.
Topic Operator는 Kafka 주제 또는 OpenShift KafkaTopic 사용자 정의 리소스의 업데이트와 지속적으로 동기화되는 주제 저장소 의 각 항목에 대한 정보를 유지 관리합니다. 로컬 메모리 내 주제 저장소에 적용되는 작업에서의 업데이트는 디스크의 백업 주제 저장소에 유지됩니다. 주제를 재구성하거나 다른 브로커에 다시 할당하면 KafkaTopic 이 항상 최신 상태가 됩니다.
6.3. User Operator
User Operator는 Kafka 사용자를 설명하는 KafkaUser 리소스를 조사하고 Kafka 클러스터에 올바르게 구성되었는지 확인하여 Kafka 클러스터의 Kafka 사용자를 관리합니다.
예를 들어 KafkaUser 가 다음과 같습니다.
- 생성된 User Operator에서 설명하는 사용자를 생성합니다.
- 삭제되어 User Operator가 설명하는 사용자를 삭제합니다.
- 변경되어 User Operator가 설명하는 사용자를 업데이트합니다.
Topic Operator와 달리 User Operator는 Kafka 클러스터의 변경 사항을 OpenShift 리소스와 동기화하지 않습니다. Kafka 주제는 Kafka에서 직접 애플리케이션에서 생성할 수 있지만 사용자가 User Operator와 병렬로 Kafka 클러스터에서 직접 관리할 필요는 없습니다.
User Operator를 사용하면 애플리케이션 배포의 일부로 KafkaUser 리소스를 선언할 수 있습니다. 사용자에 대한 인증 및 권한 부여 메커니즘을 지정할 수 있습니다. 예를 들어 사용자가 브로커에 대한 액세스를 독점하지 않도록 Kafka 리소스 사용을 제어하는 사용자 할당량 을 구성할 수도 있습니다.
사용자가 생성되면 사용자 인증 정보가 시크릿에 생성됩니다. 애플리케이션에서 인증을 위해 사용자 및 해당 자격 증명을 사용하고 메시지를 생성하거나 사용해야 합니다.
인증에 대한 자격 증명을 관리하는 것 외에도 User Operator는 KafkaUser 선언에 사용자 액세스 권한에 대한 설명을 포함하여 권한 부여 규칙도 관리합니다.
6.4. AMQ Streams Operator의 기능 게이트
기능 게이트 를 사용하여 연산자의 일부 기능을 활성화하고 비활성화할 수 있습니다.
기능 게이트는 Operator 구성에서 설정되며 알파, 베타 또는 GA(General Availability)의 세 단계로 구성됩니다.
자세한 내용은 Feature gates 를 참조하십시오.
7장. Kafka 구성
AMQ Streams를 사용하여 OpenShift 클러스터에 Kafka 구성 요소를 배포하는 것은 사용자 정의 리소스 애플리케이션을 통해 구성할 수 있습니다. 사용자 정의 리소스는 OpenShift 리소스를 확장하기 위해 CRD(Custom Resource Definitions)에서 추가한 API 인스턴스로 생성됩니다.
CRD는 OpenShift 클러스터의 사용자 정의 리소스를 설명하는 구성 지침 역할을 하며, 배포에 사용된 각 Kafka 구성 요소에 대해 AMQ Streams와 사용자 및 주제를 제공합니다. CRD 및 사용자 정의 리소스는 YAML 파일로 정의됩니다. YAML 파일의 예는 AMQ Streams 배포와 함께 제공됩니다.
또한 CRD를 사용하면 AMQ Streams 리소스가 CLI 접근성 및 구성 검증과 같은 기본 OpenShift 기능을 활용할 수 있습니다.
이 섹션에서는 공통 구성 지점부터 시작하여 구성 요소와 관련된 중요한 구성 고려 사항부터 Kafka 구성 요소를 사용자 정의 리소스를 통해 구성하는 방법을 살펴보겠습니다.
AMQ Streams는 배포를 위해 자체 Kafka 구성 요소 구성을 빌드할 때 시작점으로 사용될 수 있는 설정 파일 예제 를 제공합니다.
7.1. 사용자 정의 리소스
CRD를 설치하여 새 사용자 정의 리소스 유형을 클러스터에 추가한 후 사양을 기반으로 리소스 인스턴스를 생성할 수 있습니다.
AMQ Streams 구성 요소에 대한 사용자 정의 리소스에는 사양에 정의된 공통 구성 속성이 있습니다.
Kafka 주제 사용자 정의 리소스의 이 조각에서 apiVersion 및 kind 속성은 관련 CRD를 식별합니다. spec 속성은 주제의 파티션 및 복제본 수를 정의하는 구성을 표시합니다.
Kafka 주제 사용자 정의 리소스
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
name: my-topic
labels:
strimzi.io/cluster: my-cluster
spec:
partitions: 1
replicas: 1
# ...YAML 정의에 통합할 수 있는 많은 추가 구성 옵션이 있으며 일부 특정 구성 요소는 특정 구성 요소와 관련이 있습니다.
7.2. 공통 설정
리소스에 공통되는 일부 설정 옵션은 여기에 설명되어 있습니다. 보안 및 메트릭 수집이 적용 가능한 경우 채택될 수도 있습니다.
- 부트스트랩 서버
부트스트랩 서버는 Kafka 클러스터에 대한 호스트/포트 연결에 사용됩니다.
- Kafka Connect
- Kafka 브리지
- Kafka MirrorMaker 생산자 및 소비자
- CPU 및 메모리 리소스
구성 요소에 대한 CPU 및 메모리 리소스를 요청합니다. limits는 지정된 컨테이너에서 사용할 수 있는 최대 리소스를 지정합니다.
Topic Operator 및 User Operator에 대한 리소스 요청 및 제한은
Kafka리소스에 설정됩니다.- 로깅
- 구성 요소의 로깅 수준을 정의합니다. 로깅은 구성 맵을 사용하여 직접(인라인) 정의하거나 외부에서 정의할 수 있습니다.
- 상태 점검
- 상태 점검 구성에서는 컨테이너( liveness )를 다시 시작할 시기와 컨테이너가 트래픽(정확성)을 수락할 수 있는 시기를 알 수 있는 활성 프로브 및 준비 상태 프로브가 도입되었습니다.
- JVM 옵션
- JVM 옵션은 실행 중인 플랫폼에 따라 구성 요소의 성능을 최적화하기 위해 최대 및 최소 메모리 할당을 제공합니다.
- Pod 예약
- Pod 예약은 유사성/유사성 방지 규칙을 사용하여 Pod가 노드에 예약되는 상황에 따라 결정됩니다.
공통 구성을 보여주는 YAML의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
name: my-cluster
spec:
# ...
bootstrapServers: my-cluster-kafka-bootstrap:9092
resources:
requests:
cpu: 12
memory: 64Gi
limits:
cpu: 12
memory: 64Gi
logging:
type: inline
loggers:
connect.root.logger.level: "INFO"
readinessProbe:
initialDelaySeconds: 15
timeoutSeconds: 5
livenessProbe:
initialDelaySeconds: 15
timeoutSeconds: 5
jvmOptions:
"-Xmx": "2g"
"-Xms": "2g"
template:
pod:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-type
operator: In
values:
- fast-network
# ...7.3. Kafka 클러스터 구성
kafka 클러스터는 하나 이상의 브로커로 구성됩니다. 생산자와 소비자가 브로커 내의 항목에 액세스할 수 있도록 Kafka 구성은 클러스터에 저장된 데이터와 데이터 액세스 방법을 정의해야 합니다. 랙의 여러 브로커 노드에서 실행되도록 Kafka 클러스터를 구성할 수 있습니다.
- 스토리지
Kafka 및 ZooKeeper는 디스크에 데이터를 저장합니다.
AMQ Streams에는
StorageClass를 통해 프로비저닝된 블록 스토리지가 필요합니다. 스토리지의 파일 시스템 형식은 XFS 또는 EXT4 여야 합니다. 세 가지 유형의 데이터 스토리지가 지원됩니다.- 임시 (개발 전용 권장)
- 임시 스토리지는 인스턴스의 수명 동안 데이터를 저장합니다. 인스턴스를 다시 시작하면 데이터가 손실됩니다.
- 영구
- 영구 스토리지는 인스턴스의 라이프사이클과 관계없이 장기 데이터 스토리지와 관련이 있습니다.
- Just a Bunch of Disks, suitable for Kafka only)
- JBOD를 사용하면 여러 디스크를 사용하여 각 브로커에 커밋 로그를 저장할 수 있습니다.
인프라에서 지원하는 경우 기존 Kafka 클러스터에서 사용하는 디스크 용량을 늘릴 수 있습니다.
- 리스너
리스너는 클라이언트가 Kafka 클러스터에 연결하는 방법을 구성합니다.
Kafka 클러스터 내의 각 리스너의 고유한 이름과 포트를 지정하면 여러 리스너를 구성할 수 있습니다.
다음 유형의 리스너가 지원됩니다.
- OpenShift 내에서 액세스할 내부 리스너
- OpenShift 외부에서 액세스할 수 있는 외부 리스너
리스너에 대해 TLS 암호화를 활성화하고 인증을 구성할 수 있습니다.
내부 리스너는
내부유형을 지정하여 Kafka를 노출합니다.-
내부와 동일한 OpenShift 클러스터 내에서 연결 -
broker별
ClusterIP서비스를 사용하여 Kafka를 노출하는cluster-ip
외부 리스너는 외부
유형을지정하여 Kafka를 노출합니다.-
OpenShift
경로및 기본 HAProxy 라우터를 사용하는 경로 -
LoadBalancer를 사용하여 로드 밸런서 서비스를 사용 -
OpenShift
노드에서 포트를사용하는 NodePort -
OpenShift Ingress 및 Kubernetes용 Ingress NGINX Controller를 사용하기 위한Ingress
참고cluster-ip유형을 사용하면 자체 액세스 메커니즘을 추가할 수 있습니다. 예를 들어 사용자 정의 Ingress 컨트롤러 또는 OpenShift 게이트웨이 API와 함께 리스너를 사용할 수 있습니다.
토큰 기반 인증에 OAuth 2.0을 사용하는 경우 권한 부여 서버를 사용하도록 리스너를 구성할 수 있습니다.
- Rack 인식
-
Racks는 데이터 센터 또는 데이터 센터 또는 가용 영역의 랙을 나타냅니다. 랙에 Kafka 브로커 Pod 및 주제 복제본을 배포하도록 랙을 구성합니다.
rack속성을 사용하여 rack 인식 기능을 활성화하여topologyKey를 지정할 수 있습니다.topologyKey는 랙을 식별하는 OpenShift 작업자 노드에 할당된 라벨의 이름입니다. AMQ Streams는 각 Kafka 브로커에 랙 ID를 할당합니다. Kafka 브로커는 ID를 사용하여 랙에 파티션 복제본을 분배합니다. 또한 랙 인식과 함께 사용할RackAwareReplicaSelector플러그인을 지정할 수도 있습니다. 플러그인은 브로커와 소비자의 랙 ID와 일치하므로 가장 가까운 복제본에서 메시지가 소비됩니다. 플러그인을 사용하려면 소비자도 랙 인식 기능을 활성화해야합니다. Kafka Connect, MirrorMaker 2.0 및 Kafka Bridge에서 랙 인식 기능을 활성화할 수 있습니다.
Kafka 구성을 표시하는 YAML의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
kafka:
# ...
listeners:
- name: tls
port: 9093
type: internal
tls: true
authentication:
type: tls
- name: external1
port: 9094
type: route
tls: true
authentication:
type: tls
# ...
storage:
type: persistent-claim
size: 10000Gi
# ...
rack:
topologyKey: topology.kubernetes.io/zone
config:
replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
# ...7.4. Kafka MirrorMaker 구성
MirrorMaker를 설정하려면 소스 및 대상(대상) Kafka 클러스터가 실행 중이어야 합니다.
MirrorMaker 2.0과 함께 AMQ Streams를 사용할 수 있지만 이전 버전의 MirrorMaker는 계속 지원됩니다.
7.4.1. MirrorMaker 2.0 구성
MirrorMaker 2.0은 소스 Kafka 클러스터의 메시지를 사용하여 대상 Kafka 클러스터에 씁니다.
MirrorMaker 2.0은 다음과 같은 기능을 사용합니다.
- 소스 클러스터의 데이터를 사용하기 위한 소스 클러스터 구성
- 대상 클러스터로 데이터를 출력하는 대상 클러스터 구성
MirrorMaker 2.0은 클러스터 간 데이터 전송을 관리하는 Kafka Connect 프레임워크를 기반으로 합니다.
소스 및 대상 클러스터의 연결 세부 정보를 포함하여 Kafka Connect 배포를 정의하도록 MirrorMaker 2.0을 구성한 다음 일련의 MirrorMaker 2.0 커넥터를 실행하여 연결을 수행합니다.
MirrorMaker 2.0은 다음 커넥터로 구성됩니다.
MirrorSourceConnector-
소스 커넥터는 소스 클러스터에서 대상 클러스터로 항목을 복제합니다. 또한 ACL을 복제하며
MirrorCheckpointConnector를 실행하는 데 필요합니다. MirrorCheckpointConnector- 체크포인트 커넥터는 오프셋을 주기적으로 추적합니다. 활성화된 경우 소스 클러스터와 대상 클러스터 간의 소비자 그룹 오프셋도 동기화합니다.
MirrorHeartbeatConnector- 하트비트 커넥터는 소스 클러스터와 대상 클러스터 간의 연결을 주기적으로 확인합니다.
User Operator를 사용하여 ACL을 관리하는 경우 커넥터를 통해 ACL을 복제할 수 없습니다.
소스 클러스터에서 대상 클러스터로 데이터를 미러링 하는 프로세스는 비동기식입니다. 각 MirrorMaker 2.0 인스턴스는 하나의 소스 클러스터에서 하나의 대상 클러스터로 데이터를 미러링합니다. 둘 이상의 MirrorMaker 2.0 인스턴스를 사용하여 여러 클러스터 간에 데이터를 미러링할 수 있습니다.
그림 7.1. 두 클러스터에서 복제

기본적으로 소스 클러스터의 새 주제를 10분마다 점검합니다. 소스 커넥터 구성에 refresh.topics.interval.seconds 를 추가하여 빈도를 변경할 수 있습니다.
7.4.1.1. 클러스터 구성
MirrorMaker 2.0은 활성/수동 또는 활성 / 활성 클러스터 구성에서 사용할 수 있습니다.
- 활성/활성 클러스터 구성
- 활성/활성 구성에는 데이터를 양방향으로 복제하는 두 개의 활성 클러스터가 있습니다. 애플리케이션은 클러스터 중 하나를 사용할 수 있습니다. 각 클러스터는 동일한 데이터를 제공할 수 있습니다. 이러한 방식으로 서로 다른 지리적 위치에서 동일한 데이터를 사용할 수 있습니다. 소비자 그룹은 두 클러스터에서 모두 활성화되므로 복제된 항목에 대한 소비자 오프셋은 소스 클러스터와 다시 동기화되지 않습니다.
- 활성/수동 클러스터 구성
- Active/passive 구성에는 활성 클러스터 복제 데이터가 패시브 클러스터에 있습니다. 패시브 클러스터는 state에 남아 있습니다. 시스템 장애가 발생할 경우 데이터 복구에 수동 클러스터를 사용할 수 있습니다.
생산자와 소비자는 활성 클러스터에만 연결됩니다. 각 대상 대상에는 MirrorMaker 2.0 클러스터가 필요합니다.
7.4.1.2. 양방향 복제(활성/활성)
MirrorMaker 2.0 아키텍처는 활성/활성 클러스터 구성에서 양방향 복제를 지원합니다.
각 클러스터는 소스 및 원격 주제의 개념을 사용하여 다른 클러스터의 데이터를 복제합니다. 각 클러스터에 동일한 항목이 저장되므로 원격 주제의 이름이 MirrorMaker 2.0에 의해 소스 클러스터를 나타내기 위해 자동으로 이름이 변경됩니다. 원래 클러스터의 이름이 주제 이름 앞에 추가됩니다.
그림 7.2. 주제 이름 변경

원래 클러스터를 플래그하여 항목이 해당 클러스터로 다시 복제되지 않습니다.
원격 주제를 통한 복제 개념은 데이터 집계가 필요한 아키텍처를 구성할 때 유용합니다. 소비자는 별도의 집계 클러스터를 사용하지 않고도 동일한 클러스터 내의 소스 및 원격 주제를 구독할 수 있습니다.
7.4.1.3. Unidirectional 복제(활성/수동)
MirrorMaker 2.0 아키텍처는 활성/수동 클러스터 구성에서 단방향 복제를 지원합니다.
활성/수동 클러스터 구성을 사용하여 백업을 수행하거나 데이터를 다른 클러스터로 마이그레이션할 수 있습니다. 이 경우 원격 주제의 자동 이름 변경을 수행하지 않을 수 있습니다.
소스 커넥터 구성에 IdentityReplicationPolicy 를 추가하여 자동 이름 변경 사항을 덮어쓸 수 있습니다. 이 구성을 적용하면 주제는 원래 이름을 유지합니다.
MirrorMaker 2.0 구성 표시 YAML의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
name: my-mirror-maker2
spec:
version: 3.3.1
connectCluster: "my-cluster-target"
clusters:
- alias: "my-cluster-source"
bootstrapServers: my-cluster-source-kafka-bootstrap:9092
- alias: "my-cluster-target"
bootstrapServers: my-cluster-target-kafka-bootstrap:9092
mirrors:
- sourceCluster: "my-cluster-source"
targetCluster: "my-cluster-target"
sourceConnector: {}
topicsPattern: ".*"
groupsPattern: "group1|group2|group3"7.4.2. MirrorMaker 구성
이전 버전의 MirrorMaker에서는 생산자와 소비자를 사용하여 클러스터 간에 데이터를 복제합니다.
MirrorMaker는 다음을 사용합니다.
- 소스 클러스터의 데이터를 사용하기 위한 소비자 구성
- 대상 클러스터로 데이터를 출력하기 위한 생산자 구성
소비자 및 생산자 구성에는 인증 및 암호화 설정이 포함됩니다.
include 필드는 소스에서 대상 클러스터로 미러링할 주제를 정의합니다.
키 소비자 구성
- 소비자 그룹 식별자
- 사용된 메시지가 소비자 그룹에 할당되도록 MirrorMaker 소비자의 소비자 그룹 ID입니다.
- 소비자 스트림 수
- 메시지를 병렬로 사용하는 소비자 그룹의 소비자 수를 결정하는 값입니다.
- 커밋 간격 오프셋
- 메시지 사용 및 커밋 사이의 시간을 설정하는 오프셋 커밋 간격입니다.
주요 Producer 구성
- 송신 실패의 취소 옵션
- 메시지 보내기 실패가 무시되는지 또는 MirrorMaker가 종료되고 다시 생성되었는지 여부를 정의할 수 있습니다.
MirrorMaker 구성을 표시하는 YAML의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaMirrorMaker
metadata:
name: my-mirror-maker
spec:
# ...
consumer:
bootstrapServers: my-source-cluster-kafka-bootstrap:9092
groupId: "my-group"
numStreams: 2
offsetCommitInterval: 120000
# ...
producer:
# ...
abortOnSendFailure: false
# ...
include: "my-topic|other-topic"
# ...7.5. Kafka Connect 구성
AMQ Streams의 KafkaConnect 리소스를 사용하여 새 Kafka Connect 클러스터를 빠르고 쉽게 생성할 수 있습니다.
KafkaConnect 리소스를 사용하여 Kafka Connect를 배포할 때 Kafka 클러스터에 연결하기 위해 부트스트랩 서버 주소( spec.bootstrapServers)를 지정합니다. 서버가 중단된 경우 둘 이상의 주소를 지정할 수 있습니다. 또한 보안 연결을 위해 인증 자격 증명 및 TLS 암호화 인증서를 지정합니다.
Kafka 클러스터는 AMQ Streams에서 관리하거나 OpenShift 클러스터에 배포할 필요가 없습니다.
KafkaConnect 리소스를 사용하여 다음을 지정할 수도 있습니다.
- 연결을 위해 플러그인이 포함된 컨테이너 이미지를 빌드하는 플러그인 구성
- Kafka Connect 클러스터에 속한 작업자 Pod 구성
-
KafkaConnector리소스를 사용하여 플러그인을 관리할 수 있는 주석
Cluster Operator는 KafkaConnector 리소스를 사용하여 생성된 KafkaConnect 리소스 및 커넥터를 사용하여 배포된 Kafka Connect 클러스터를 관리합니다.
플러그인 구성
플러그인에서는 커넥터 인스턴스 생성을 위한 구현을 제공합니다. 플러그인이 인스턴스화되면 특정 유형의 외부 데이터 시스템에 연결하기 위해 구성이 제공됩니다. 플러그인은 지정된 종류의 데이터 소스에 연결하기 위해 커넥터 및 작업 구현을 정의하는 하나 이상의 JAR 파일 세트를 제공합니다. 여러 외부 시스템용 플러그인은 Kafka Connect에서 사용할 수 있습니다. 자체 플러그인을 만들 수도 있습니다.
이 구성에서는 Kafka Connect에 공급할 소스 입력 데이터 및 대상 출력 데이터를 설명합니다. 소스 커넥터의 경우 외부 소스 데이터는 메시지를 저장할 특정 항목을 참조해야 합니다. 플러그인에는 데이터를 변환하는 데 필요한 라이브러리와 파일도 포함될 수 있습니다.
Kafka Connect 배포에는 하나 이상의 플러그인이 있을 수 있지만 각 플러그인마다 하나의 버전만 사용할 수 있습니다.
선택한 플러그인을 포함하는 사용자 지정 Kafka Connect 이미지를 생성할 수 있습니다. 다음 두 가지 방법으로 이미지를 생성할 수 있습니다.
컨테이너 이미지를 자동으로 생성하려면 KafkaConnect 리소스의 build 속성을 사용하여 Kafka Connect 클러스터에 추가할 플러그인을 지정합니다. AMQ Streams는 플러그인 아티팩트를 자동으로 다운로드하여 새 컨테이너 이미지에 추가합니다.
플러그인 구성 예
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
name: my-connect-cluster
annotations:
strimzi.io/use-connector-resources: "true"
spec:
# ...
build: 1
output: 2
type: docker
image: my-registry.io/my-org/my-connect-cluster:latest
pushSecret: my-registry-credentials
plugins: 3
- name: debezium-postgres-connector
artifacts:
- type: tgz
url: https://ARTIFACT-ADDRESS.tgz
sha512sum: HASH-NUMBER-TO-VERIFY-ARTIFACT
# ...
# ...
- 1
- 플러그인이 자동으로 컨테이너 이미지를 빌드하기 위한 구성 속성을 빌드 합니다.
- 2
- 새 이미지가 푸시되는 컨테이너 레지스트리의 구성
출력속성은 이미지의 유형 및 이름과 선택적으로 컨테이너 레지스트리에 액세스하는 데 필요한 인증 정보가 포함된 시크릿 이름을 설명합니다. - 3
- 새 컨테이너 이미지에 추가할 플러그인 및 아티팩트 목록입니다.
plugins속성은 아티팩트 유형과 아티팩트가 다운로드되는 URL을 설명합니다. 각 플러그인은 하나 이상의 아티팩트로 구성해야 합니다. 또한 SHA-512 체크섬을 지정하여 아티팩트의 압축을 풀기 전에 아티팩트를 확인할 수 있습니다.
Dockerfile을 사용하여 이미지를 빌드하는 경우 AMQ Streams의 최신 컨테이너 이미지를 기본 이미지로 사용하여 플러그인 구성 파일을 추가할 수 있습니다.
플러그인 구성 수동 추가 표시 예
FROM registry.redhat.io/amq7/amq-streams-kafka-33-rhel8:2.3.0
USER root:root
COPY ./my-plugins/ /opt/kafka/plugins/
USER 1001
작업자를 위한 Kafka Connect 클러스터 구성
KafkaConnect 리소스의 config 속성에서 작업자에 대한 구성을 지정합니다.
분산 Kafka Connect 클러스터에는 그룹 ID와 내부 구성 주제 세트가 있습니다.
-
group.id -
offset.storage.topic -
config.storage.topic -
status.storage.topic
Kafka Connect 클러스터는 기본적으로 이러한 속성에 대해 동일한 값으로 구성됩니다. Kafka Connect 클러스터는 오류를 생성할 때 그룹 ID 또는 주제 이름을 공유할 수 없습니다. 여러 개의 Kafka Connect 클러스터를 사용하는 경우 이러한 설정은 생성된 각 Kafka Connect 클러스터의 작업자에 고유해야 합니다.
각 Kafka Connect 클러스터에서 사용하는 커넥터의 이름도 고유해야 합니다.
다음 예제 작업자 구성에서는 JSON 변환기가 지정됩니다. 복제 요소는 Kafka Connect에서 사용하는 내부 Kafka 항목에 대해 설정됩니다. 프로덕션 환경의 경우 최소 3개여야 합니다. 주제를 만든 후 복제 요소를 변경하면 적용되지 않습니다.
작업자 구성 예
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
# ...
spec:
config:
# ...
group.id: my-connect-cluster 1
offset.storage.topic: my-connect-cluster-offsets 2
config.storage.topic: my-connect-cluster-configs 3
status.storage.topic: my-connect-cluster-status 4
key.converter: org.apache.kafka.connect.json.JsonConverter 5
value.converter: org.apache.kafka.connect.json.JsonConverter 6
key.converter.schemas.enable: true 7
value.converter.schemas.enable: true 8
config.storage.replication.factor: 3 9
offset.storage.replication.factor: 3 10
status.storage.replication.factor: 3 11
# ...
- 1
- Kafka 내의 Kafka Connect 클러스터 ID입니다. 각 Kafka Connect 클러스터에 대해 고유해야 합니다.
- 2
- 커넥터 오프셋을 저장하는 Kafka 주제입니다. 각 Kafka Connect 클러스터에 대해 고유해야 합니다.
- 3
- 커넥터 및 작업 상태 구성을 저장하는 Kafka 주제입니다. 각 Kafka Connect 클러스터에 대해 고유해야 합니다.
- 4
- 커넥터 및 작업 상태 업데이트를 저장하는 Kafka 주제입니다. 각 Kafka Connect 클러스터에 대해 고유해야 합니다.
- 5
- Kafka에서 저장하기 위해 메시지 키를 JSON 형식으로 변환하는 데 사용됩니다.
- 6
- Kafka에서 저장하기 위해 메시지 값을 JSON 형식으로 변환하는 데 사용됩니다.
- 7
- 메시지 키를 구조화된 JSON 형식으로 변환하는 데 활성화된 스키마입니다.
- 8
- 메시지 값을 구조화된 JSON 형식으로 변환하는 데 활성화된 스키마입니다.
- 9
- 커넥터 오프셋을 저장하는 Kafka 항목에 대한 복제 요인입니다.
- 10
- 커넥터 및 작업 상태 구성을 저장하는 Kafka 항목에 대한 복제 요인입니다.
- 11
- 커넥터 및 작업 상태 업데이트를 저장하는 Kafka 항목에 대한 복제 요인입니다.
커넥터의 KafkaConnector 관리
배포의 작업자 Pod에 사용되는 컨테이너 이미지에 플러그인을 추가한 후 AMQ Streams의 KafkaConnector 사용자 정의 리소스 또는 Kafka Connect API를 사용하여 커넥터 인스턴스를 관리할 수 있습니다. 이러한 옵션을 사용하여 새 커넥터 인스턴스를 만들 수도 있습니다.
KafkaConnector 리소스는 Cluster Operator의 커넥터 관리에 OpenShift 네이티브 접근 방식을 제공합니다. KafkaConnector 리소스를 사용하여 커넥터를 관리하려면 KafkaConnect 사용자 정의 리소스에 주석을 지정해야 합니다.
KafkaConnectors를 활성화하는 주석
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
name: my-connect-cluster
annotations:
strimzi.io/use-connector-resources: "true"
# ...
use-connector-resources 를 true 로 설정하면 KafkaConnectors가 커넥터를 생성, 삭제 및 재구성할 수 있습니다.
KafkaConnect 구성에서 use-connector-resources 가 활성화된 경우 KafkaConnector 리소스를 사용하여 커넥터를 정의하고 관리해야 합니다. KafkaConnector 리소스는 외부 시스템에 연결하도록 구성됩니다. Kafka Connect 클러스터 및 외부 데이터 시스템과 상호 작용하는 Kafka 클러스터와 동일한 OpenShift 클러스터에 배포됩니다.
Kafka 구성 요소는 동일한 OpenShift 클러스터에 포함되어 있습니다.
이 구성은 인증을 포함하여 커넥터 인스턴스가 외부 데이터 시스템에 연결하는 방법을 지정합니다. 또한 조사할 데이터를 기록해야 합니다. 소스 커넥터의 경우 구성에 데이터베이스 이름을 제공할 수 있습니다. 대상 주제 이름을 지정하여 데이터가 Kafka에 있는 위치를 지정할 수도 있습니다.
tasksMax 를 사용하여 최대 작업 수를 지정합니다. 예를 들어 tasksMax: 2 가 있는 소스 커넥터는 소스 데이터 가져오기를 두 개의 작업으로 분할할 수 있습니다.
KafkaConnector 소스 커넥터 구성의 예
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnector metadata: name: my-source-connector 1 labels: strimzi.io/cluster: my-connect-cluster 2 spec: class: org.apache.kafka.connect.file.FileStreamSourceConnector 3 tasksMax: 2 4 config: 5 file: "/opt/kafka/LICENSE" 6 topic: my-topic 7 # ...
- 1
- 커넥터의 이름으로 사용되는
KafkaConnector리소스의 이름입니다. OpenShift 리소스에 유효한 이름을 사용합니다. - 2
- Kafka Connect 클러스터의 이름이 에서 커넥터 인스턴스를 생성합니다. 커넥터를 연결하는 Kafka Connect 클러스터와 동일한 네임스페이스에 배포해야 합니다.
- 3
- 커넥터 클래스의 전체 이름입니다. Kafka Connect 클러스터에서 사용하는 이미지에 있어야 합니다.
- 4
- 커넥터가 생성할 수 있는 최대 Kafka Connect 작업 수입니다.
- 5
- 커넥터 구성은 키-값 쌍으로 설정됩니다.
- 6
- 외부 데이터 파일의 위치입니다. 이 예제에서는
/opt/kafka/LICENSE파일에서 읽을 수 있도록 CloudEventSourceConnector를 구성하고 있습니다. - 7
- 소스 데이터를 게시하는 Kafka 주제입니다.
OpenShift Secrets 또는 ConfigMaps에서 커넥터의 기밀 구성 값을 로드 할 수 있습니다.
Kafka Connect API
KafkaConnector 리소스를 사용하여 커넥터를 관리하는 대신 Kafka Connect REST API를 사용합니다. Kafka Connect REST API는 < connect_cluster_name> -connect-api:8083 에서 실행되는 서비스로 사용할 수 있습니다. 여기서 < connect_cluster_name >은 Kafka Connect 클러스터의 이름입니다.
커넥터 구성을 JSON 오브젝트로 추가합니다.
커넥터 구성 추가에 대한 curl 요청의 예
curl -X POST \
http://my-connect-cluster-connect-api:8083/connectors \
-H 'Content-Type: application/json' \
-d '{ "name": "my-source-connector",
"config":
{
"connector.class":"org.apache.kafka.connect.file.FileStreamSourceConnector",
"file": "/opt/kafka/LICENSE",
"topic":"my-topic",
"tasksMax": "4",
"type": "source"
}
}'
KafkaConnectors가 활성화된 경우 Kafka Connect REST API를 직접 사용하여 변경한 수동 변경 사항을 Cluster Operator에 의해 되돌립니다.
REST API에서 지원하는 작업은 Apache Kafka 설명서에 설명되어 있습니다.
OpenShift 외부에서 Kafka Connect API 서비스를 노출할 수 있습니다. 수신 또는 경로와 같은 액세스를 제공하는 연결 메커니즘을 사용하는 서비스를 생성하여 이 작업을 수행합니다. 연결이 안전하지 않으므로 advisedly를 사용합니다.
7.6. Kafka 브리지 구성
Kafka 브리지 구성에는 연결하는 Kafka 클러스터에 대한 부트스트랩 서버 사양과 필요한 암호화 및 인증 옵션이 필요합니다.
Kafka Bridge 소비자 및 생산자 구성은 생산자에 대한 소비자 및 Apache Kafka 구성 문서에 설명된 대로 표준입니다.
HTTP 관련 구성 옵션은 서버가 수신 대기하는 포트 연결을 설정합니다.
CORS
Kafka 브리지는 CORS(Cross-Origin Resource Sharing) 사용을 지원합니다. CORS는 브라우저에서 하나 이상의 원본에서 선택된 리소스에 액세스할 수 있는 HTTP 메커니즘입니다(예: 다른 도메인의 리소스). CORS를 사용하도록 선택하는 경우 Kafka Bridge를 통해 Kafka 클러스터와 상호 작용하기 위해 허용된 리소스 원본 및 HTTP 메서드 목록을 정의할 수 있습니다. 목록은 Kafka 브리지 구성의 http 사양에 정의되어 있습니다.
CORS를 사용하면 서로 다른 도메인의 원본 소스 간에 간단한 및 사전 진행 중인 요청을 수행할 수 있습니다.
- 간단한 요청은 헤더에 허용된 원본이 정의되어 있어야 하는 HTTP 요청입니다.
- 사전 진행된 요청은 실제 요청보다 원본 및 메서드가 허용되는지 확인하기 전에 초기 OPTIONS HTTP 요청을 보냅니다.
Kafka 브리지 구성을 표시하는 YAML의 예
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
name: my-bridge
spec:
# ...
bootstrapServers: my-cluster-kafka:9092
http:
port: 8080
cors:
allowedOrigins: "https://strimzi.io"
allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH"
consumer:
config:
auto.offset.reset: earliest
producer:
config:
delivery.timeout.ms: 300000
# ...추가 리소스
8장. Securing Kafka
AMQ Streams의 보안 배포는 다음을 포함할 수 있습니다.
- 데이터 교환의 암호화
- ID를 증명하기 위한 인증
- 사용자가 실행하는 작업을 허용 또는 거부할 수 있는 권한 부여
8.1. 암호화
AMQ Streams는 암호화된 통신을 위한 프로토콜인 TLS(Transport Layer Security)를 지원합니다.
통신은 다음 간의 통신을 위해 항상 암호화됩니다.
- Kafka 브로커
- zookeeper 노드
- Operator 및 Kafka 브로커
- Operator 및 ZooKeeper 노드
- Kafka Exporter
Kafka 브로커와 클라이언트 간의 TLS 암호화를 구성할 수도 있습니다. Kafka 브로커에 대한 외부 리스너를 구성할 때 외부 클라이언트에 대해 TLS가 지정됩니다.
AMQ Streams 구성 요소 및 Kafka 클라이언트는 암호화를 위해 디지털 인증서를 사용합니다. Cluster Operator는 Kafka 클러스터 내에서 암호화를 활성화하도록 인증서를 설정합니다. Kafka 클라이언트 및 Kafka 브로커 간 통신 및 클러스터 간 통신을 위해 Kafka 리스너 인증서 라고 하는 고유한 서버 인증서를 제공할 수 있습니다.
AMQ Streams는 보안을 사용하여 mTLS에 필요한 인증서 및 개인 키를 PEM 및 PKCS #12 형식으로 저장합니다.
TLS CA(인증 기관)는 구성 요소의 ID를 인증하기 위해 인증서를 발행합니다. AMQ Streams는 CA 인증서에 대한 구성 요소의 인증서를 확인합니다.
- AMQ Streams 구성 요소는 클러스터 CA 에 대해 확인
- Kafka 클라이언트는 클라이언트 CA 에 대해 확인
8.2. 인증
Kafka 리스너는 인증을 사용하여 Kafka 클러스터에 대한 보안 클라이언트 연결을 보장합니다.
지원되는 인증 메커니즘:
- mTLS 인증(TLS 지원 암호화를 사용하는 리스너의 경우)
- SASL SCRAM-SHA-512
- OAuth 2.0 토큰 기반 인증
- 사용자 정의 인증
User Operator는 OAuth 2.0이 아닌 mTLS 및 SCRAM 인증에 대한 사용자 인증 정보를 관리합니다. 예를 들어 User Operator를 통해 Kafka 클러스터에 액세스해야 하는 클라이언트를 나타내는 사용자를 생성하고 tls 를 인증 유형으로 지정할 수 있습니다.
애플리케이션 클라이언트는 OAuth 2.0 토큰 기반 인증을 사용하여 계정 자격 증명을 노출하지 않고 Kafka 브로커에 액세스할 수 있습니다. 권한 부여 서버는 액세스 권한 부여 및 문의를 처리합니다.
사용자 정의 인증은 모든 유형의 kafka 지원 인증을 허용합니다. 더 많은 유연성을 제공할 수 있지만 복잡성을 더할 수도 있습니다.
8.3. 권한 부여
Kafka 클러스터는 권한을 사용하여 특정 클라이언트 또는 사용자에 의해 Kafka 브로커에서 허용되는 작업을 제어합니다. Kafka 클러스터에 적용되는 경우 클라이언트 연결에 사용되는 모든 리스너에 대한 권한 부여가 활성화됩니다.
Kafka 브로커 구성의 슈퍼 사용자 목록에 사용자를 추가하면 권한 부여 메커니즘을 통해 구현되는 권한 부여 제약 조건에 관계없이 사용자가 클러스터에 대한 무제한 액세스를 허용합니다.
지원되는 권한 부여 메커니즘:
- 간단한 권한 부여
- OAuth 2.0 인증( OAuth 2.0 토큰 기반 인증을 사용하는 경우)
- OOPA(Open Policy Agent) 권한 부여
- 사용자 정의 권한 부여
간단한 권한 부여 기능은 기본 Kafka 인증 플러그인인 AclAuthorizer 를 사용합니다. AclAuthorizer 는 ACL(액세스 제어 목록)을 사용하여 리소스에 액세스할 수 있는 사용자를 정의합니다. 사용자 정의 권한 부여의 경우 ACL 규칙을 적용하도록 자체 Authorizer 플러그인을 구성합니다.
OAuth 2.0 및 OPA는 권한 부여 서버에서 정책 기반 제어를 제공합니다. Kafka 브로커의 리소스에 대한 액세스 권한을 부여하는 데 사용되는 보안 정책 및 권한은 권한 부여 서버에 정의됩니다.
URL은 권한 부여 서버에 연결하고 클라이언트 또는 사용자가 요청한 작업이 허용 또는 거부되는지 확인하는 데 사용됩니다. 사용자와 클라이언트는 Kafka 브로커에서 특정 작업을 수행하기 위해 액세스를 허용하는 권한 부여 서버에서 생성된 정책과 대조됩니다.
9장. 모니터링
데이터 모니터링을 사용하면 AMQ Streams의 성능과 상태를 모니터링할 수 있습니다. 분석 및 알림에 대한 메트릭 데이터를 캡처하도록 배포를 구성할 수 있습니다.
지표 데이터는 연결 및 데이터 전달 문제를 조사할 때 유용합니다. 예를 들어 지표 데이터는 복제 대상 파티션 또는 메시지가 사용되는 속도를 식별할 수 있습니다. 경고 규칙은 지정된 통신 채널을 통해 이러한 메트릭에 대한 시간에 중요한 알림을 제공할 수 있습니다. 시각화를 모니터링하면 배포 구성을 업데이트할 시기와 방법을 결정하는 데 도움이 되는 실시간 지표 데이터를 제공합니다. 지표 구성 파일의 예는 AMQ Streams에서 제공됩니다.
분산 추적은 AMQ Streams를 통해 메시지의 엔드 투 엔드 추적 기능을 제공하여 지표 데이터 수집을 보완합니다.
cruise Control은 워크로드 데이터를 기반으로 Kafka 클러스터의 재조정을 지원합니다.
메트릭 및 모니터링 툴
AMQ Streams는 메트릭 및 모니터링에 다음 툴을 사용할 수 있습니다.
- Prometheus
- Prometheus 는 Kafka, ZooKeeper 및 Kafka Connect 클러스터에서 메트릭을 가져옵니다. Prometheus Alertmanager 플러그인은 경고를 처리하고 알림 서비스로 라우팅합니다.
- Kafka Exporter
- Kafka Exporter 는 추가 Prometheus 메트릭을 추가합니다.
- Grafana
- Grafana Labs 는 Prometheus 지표의 대시보드 시각화를 제공합니다.
- Jaeger
- Jaeger 문서는 애플리케이션 간 트랜잭션을 추적하는 분산 추적 지원을 제공합니다.
- 크루즈 컨트롤
- cruise Control 은 데이터 배포를 모니터링하고 Kafka 클러스터에서 데이터 재조정을 수행합니다.
9.1. Prometheus
Prometheus는 Kafka 구성 요소 및 AMQ Streams Operator에서 메트릭 데이터를 추출할 수 있습니다.
Prometheus를 사용하여 지표 데이터를 가져오고 경고를 제공하려면 Prometheus 및 Prometheus Alertmanager 플러그인을 배포해야 합니다. 지표 데이터를 노출하려면 Kafka 리소스를 지표 구성으로 배포하거나 재배포해야 합니다.
Prometheus는 모니터링을 위해 노출된 지표 데이터를 스크랩합니다. Alertmanager는 사전 정의된 경고 규칙에 따라 조건이 잠재적인 문제를 나타내는 경우 경고를 발행합니다.
샘플 메트릭 및 경고 규칙 구성 파일은 AMQ Streams와 함께 제공됩니다. AMQ Streams와 함께 제공되는 샘플 경고 메커니즘은 Slack 채널에 알림을 전송하도록 구성됩니다.
9.2. Grafana
Grafana는 Prometheus에서 노출하는 지표 데이터를 사용하여 모니터링을 위해 대시보드 시각화를 제공합니다.
Prometheus가 데이터 소스로 추가되어 Grafana를 배포해야 합니다. AMQ Streams와 함께 JSON 파일로 제공되는 대시보드의 예는 Grafana 인터페이스를 통해 가져와 모니터링 데이터를 제공합니다.
9.3. Kafka Exporter
Kafka 내보내기는 Apache Kafka 브로커 및 클라이언트의 모니터링을 개선하는 오픈 소스 프로젝트입니다. Kafka 내보내기는 Kafka 클러스터와 함께 배포하여 오프셋, 소비자 그룹, 소비자 지연 및 주제와 관련된 Kafka 브로커에서 추가 Prometheus 지표 데이터를 추출합니다. 제공된 Grafana 대시보드를 사용하여 Kafka Exporter에서 Prometheus에서 수집한 데이터를 시각화할 수 있습니다.
Kafka Exporter의 샘플 구성 파일, 경고 규칙 및 Grafana 대시보드가 AMQ Streams를 통해 제공됩니다.
9.4. 분산 추적
분산 추적은 분산 시스템의 애플리케이션 간 트랜잭션 진행 상황을 추적합니다. 마이크로 서비스 아키텍처에서 추적은 서비스 간 트랜잭션 진행 상황을 추적합니다. 추적 데이터는 애플리케이션 성능을 모니터링하고 대상 시스템 및 최종 사용자 애플리케이션 관련 문제를 조사하는 데 유용합니다.
AMQ Streams에서 추적을 사용하면 소스 시스템에서 Kafka로의 메시지 엔드 투 엔드 추적을 용이하게 하고 Kafka에서 시스템 및 애플리케이션을 대상으로 지정할 수 있습니다. 분산 추적은 Grafana 대시보드의 메트릭 모니터링과 구성 요소 로거를 보완합니다.
추적 지원은 다음 Kafka 구성 요소에 빌드됩니다.
- 소스 클러스터에서 대상 클러스터로 메시지를 추적할 MirrorMaker
- Kafka Connect에서 사용하고 생성한 메시지를 추적하기 위한 Kafka Connect
- Kafka 및 HTTP 클라이언트 애플리케이션 간 메시지 추적을 위한 Kafka Bridge
Kafka 브로커에서는 추적이 지원되지 않습니다.
사용자 정의 리소스를 통해 이러한 구성 요소의 추적을 활성화하고 구성합니다. spec.template 속성을 사용하여 추적 구성을 추가합니다.
spec.tracing.type 속성을 사용하여 추적 유형을 지정하여 추적을 활성화합니다.
OpenTelemetry-
type: opentelemetry를 지정하여 OpenTelemetry를 사용합니다. 기본적으로 OpenTelemetry는 OTLP (OpenTelemetry Protocol) 내보내기 및 끝점을 사용하여 추적 데이터를 가져옵니다. Jaeger 추적을 포함하여 OpenTelemetry에서 지원하는 다른 추적 시스템을 지정할 수 있습니다. 이를 위해 추적 구성에서 OpenTelemetry 내보내기 및 끝점을 변경합니다. jaeger-
OpenTracing 및 Jaeger 클라이언트를 사용하여 추적 데이터를 가져오려면
type:jaeger를 지정합니다.
type: jaeger tracing에 대한 지원은 더 이상 사용되지 않습니다. 이제 Jaeger 클라이언트가 사용 중지되고 OpenTracing 프로젝트가 아카이브됩니다. 따라서 향후 Kafka 버전에 대한 지원을 보장할 수 없습니다. 가능한 경우 type: jaeger 추적은 2023년 6월까지 유지 관리하고 나중에 삭제합니다. 최대한 빨리 OpenTelemetry로 마이그레이션하십시오.
Kafka 클라이언트 추적
Kafka 생산자 및 소비자와 같은 클라이언트 애플리케이션도 트랜잭션을 모니터링하도록 설정할 수 있습니다. 클라이언트는 추적 프로필로 구성되며 클라이언트 애플리케이션이 사용할 추적기가 초기화됩니다.
9.5. 크루즈 컨트롤
Cruise Control은 다음 Kafka 작업을 지원하는 오픈 소스 시스템입니다.
- 클러스터 워크로드 모니터링
- 사전 정의된 제약 조건을 기반으로 클러스터 재조정
이 작업은 브로커 Pod를 보다 효율적으로 사용하는 더 균형 있는 Kafka 클러스터를 실행하는 데 도움이 됩니다.
일반적인 클러스터는 시간이 지남에 따라 균등하게 로드될 수 있습니다. 대량의 메시지 트래픽을 처리하는 파티션이 사용 가능한 브로커에 균등하게 분배되지 않을 수 있습니다. 클러스터를 재조정하려면 관리자는 브로커의 부하를 모니터링하고 사용 중인 파티션을 여유 용량이 있는 브로커에 수동으로 다시 할당해야 합니다.
Cruise Control은 클러스터 재조정 프로세스를 자동화합니다. CPU, 디스크 및 네트워크 로드를 기반으로 클러스터의 리소스 사용률의 워크로드 모델을 구성하고 더 균형 있는 파티션 할당에 대한 최적화 제안(승인 또는 거부할 수 있음)을 생성합니다. 구성 가능한 최적화 목표 세트는 이러한 제안을 계산하는 데 사용됩니다.
특정 모드에서 최적화 제안을 생성할 수 있습니다. 기본 전체 모드는 모든 브로커에서 파티션을 재조정합니다. add-brokers 및 remove-brokers 모드를 사용하여 클러스터를 확장 또는 축소할 때 변경 사항을 수용할 수도 있습니다.
최적화 제안을 승인하면 Cruise Control을 Kafka 클러스터에 적용합니다. KafkaRebalance 리소스를 사용하여 최적화 제안을 구성하고 생성합니다. 최적화 제안이 자동으로 또는 수동으로 승인되도록 주석을 사용하여 리소스를 구성할 수 있습니다.
Prometheus는 최적화 제안 및 재조정 작업과 관련된 데이터를 포함하여 Cruise Control 지표 데이터를 추출할 수 있습니다. Cruise Control의 샘플 구성 파일 및 Grafana 대시보드는 AMQ Streams를 통해 제공됩니다.
부록 A. 서브스크립션 사용
AMQ Streams는 소프트웨어 서브스크립션을 통해 제공됩니다. 서브스크립션을 관리하려면 Red Hat 고객 포털에서 계정에 액세스하십시오.
귀하의 계정에 액세스
- access.redhat.com 으로 이동합니다.
- 아직 계정이 없는 경우 계정을 생성합니다.
- 계정에 로그인합니다.
서브스크립션 활성화
- access.redhat.com 으로 이동합니다.
- 내 서브스크립션으로 이동합니다.
- 서브스크립션을 활성화하여 16자리 활성화 번호를 입력합니다.
Zip 및 Tar 파일 다운로드
zip 또는 tar 파일에 액세스하려면 고객 포털을 사용하여 다운로드할 관련 파일을 찾습니다. RPM 패키지를 사용하는 경우에는 이 단계가 필요하지 않습니다.
- 브라우저를 열고 access.redhat.com/downloads 에서 Red Hat 고객 포털 제품 다운로드 페이지에 로그인합니다.
- INTEGRAT ION 및 AUTOMATION 카테고리에서 Apache Kafka의 AMQ Streams 를 찾습니다.
- 원하는 AMQ Streams 제품을 선택합니다. Software Download 페이지가 열립니다.
- 구성 요소에 대한 다운로드 링크를 클릭합니다.
DNF로 패키지 설치
패키지 및 모든 패키지 종속 항목을 설치하려면 다음을 사용합니다.
dnf install <package_name>로컬 디렉터리에서 이전에 다운로드한 패키지를 설치하려면 다음을 사용합니다.
dnf install <path_to_download_package>2023-04-06에 최종 업데이트된 문서