2장. KRaft 모드에서 Kafka 사용
Kraft (Kafka Raft metadata) 모드는 클러스터 관리를 위해 Kafka의 종속성을 Zoo Cryostat로 대체합니다. Kraft 모드는 메타데이터 관리 및 클러스터를 Kafka로 조정하여 Kafka 클러스터의 배포 및 관리를 간소화합니다.
KRaft 모드의 Kafka는 향상된 안정성, 확장성 및 처리량을 제공하도록 설계되었습니다. 메타데이터 작업이 직접 통합될 때 더 효율적이 됩니다. 또한 Zoo Cryostat 클러스터를 유지 관리할 필요가 없어 운영 및 보안 오버헤드가 줄어 듭니다.
KRaft 모드에서 Kafka 클러스터를 배포하려면 Kafka 및 KafkaNodePool 사용자 정의 리소스를 사용해야 합니다. KRaft 모드를 사용하는 Kafka 리소스에도 주석 strimzi.io/kraft: enabled 및 strimzi.io/node-pools: enabled 가 있어야 합니다. 자세한 내용 및 예제는 8.2.1절. “KRaft 모드에서 Kafka 클러스터 배포” 에서 참조하십시오.
KafkaNodePool 리소스를 사용한 노드 풀 구성 을 통해 노드에 브로커, 컨트롤러 또는 둘 다의 역할이 할당됩니다.
- 컨트롤러 노드는 Raft 기반 합의 프로토콜을 사용하여 클러스터 메타데이터 및 클러스터 상태를 관리하기 위해 컨트롤 플레인에서 작동합니다.
- 브로커 노드는 데이터 플레인에서 작동하여 메시지 스트리밍을 관리하고, 주제 파티션에서 데이터를 수신하고 저장합니다.
- 듀얼 역할 노드는 컨트롤러 및 브로커의 역할을 수행합니다.
컨트롤러는 클러스터 상태를 기록하는 모든 노드에서 단일 파티션 주제(__cluster_metadata)로 저장된 메타데이터 로그를 사용합니다. 클러스터 구성을 변경하라는 요청이 생성되면 활성(리드) 컨트롤러에서 메타데이터 로그 업데이트를 관리하고 후속 컨트롤러는 이러한 업데이트를 복제합니다. 메타데이터 로그는 동기화 중인 복제본 상태 및 파티션 리더십을 포함하여 브로커, 복제본, 주제 및 파티션에 대한 정보를 저장합니다. Kafka는 이 메타데이터를 사용하여 변경 사항을 조정하고 클러스터를 효과적으로 관리합니다.
브로커 노드는 관찰자 역할을 하며, 클러스터 상태와 최신 상태를 유지하기 위해 메타데이터 로그를 수동적으로 저장합니다. 각 노드는 개별적으로 로그에 대한 업데이트를 가져옵니다. JBOD 스토리지를 사용하는 경우 메타데이터 로그를 저장하는 볼륨을 변경할 수 있습니다.
Kafka 클러스터에 사용된 KRaft 메타데이터 버전은 사용 중인 Kafka 버전에서 지원해야 합니다. 두 버전 모두 Kafka 리소스 구성을 통해 관리됩니다. 자세한 내용은 10.2절. “Kafka 구성”의 내용을 참조하십시오.
다음 예에서 Kafka 클러스터는 내결함성 및 고가용성을 위해 컨트롤러 및 브로커 노드의 쿼럼으로 구성됩니다.
그림 2.1. 별도의 브로커 및 컨트롤러 노드가 있는 클러스터의 예
일반적인 프로덕션 환경에서는 전용 브로커 및 컨트롤러 노드를 사용합니다. 그러나 개발 또는 테스트에 듀얼 역할 구성에서 노드를 사용할 수 있습니다.
역할을 단일 역할을 수행하는 노드와 결합하는 노드를 조합할 수 있습니다. 다음 예제에서는 세 개의 노드가 듀얼 역할을 수행하고 두 개의 노드가 브로커로만 작동합니다.
그림 2.2. 이중 역할 노드 및 전용 브로커 노드가 있는 클러스터의 예
2.1. Kraft 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
Kraft 제한은 주로 클러스터 작업에 영향을 미치는 컨트롤러 스케일링과 관련이 있습니다.
2.1.1. 컨트롤러 스케일링 링크 복사링크가 클립보드에 복사되었습니다!
Kraft 모드는 두 가지 유형의 컨트롤러 쿼럼을 지원합니다.
-
정적 컨트롤러 쿼럼
이 모드에서 컨트롤러 수는 수정되었으며 확장에는 다운타임이 필요합니다. -
동적 컨트롤러 쿼럼
이 모드를 사용하면 다운타임 없이 컨트롤러를 동적으로 확장할 수 있습니다. 새 컨트롤러는 관찰자로 가입하고 메타데이터 로그를 복제하며 결국 쿼럼에 참여할 수 있습니다. 제거 중인 컨트롤러가 활성 컨트롤러인 경우 새 쿼럼을 확인한 후에만 쿼럼에서 다운됩니다.
확장은 컨트롤러 추가 또는 제거뿐만 아니라 다음 작업을 지원합니다.
- 원하는 이름으로 새 노드 풀을 추가하고 이전 노드 풀을 삭제해야 하는 노드 풀의 이름을 변경합니다.
- 업데이트된 스토리지 구성으로 새 노드 풀을 생성하고 이전 노드를 제거해야 하는 비JBOD 스토리지 변경.
동적 컨트롤러 쿼럼은 이러한 작업을 훨씬 쉽게 수행할 수 있는 유연성을 제공합니다.
2.1.2. 정적 컨트롤러 쿼럼의 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
정적 및 동적 컨트롤러 쿼럼 간 마이그레이션은 현재 Apache Kafka에서 지원되지 않지만 향후 릴리스에서 도입될 것으로 예상됩니다. 결과적으로 Apache Kafka의 Streams는 새 설치를 포함하여 모든 배포에 정적 컨트롤러 쿼럼을 사용합니다. 정적 컨트롤러 쿼럼을 사용하는 기존 KRaft 기반 Apache Kafka 클러스터는 모두 계속 사용해야 합니다. 기존 KRaft 기반 클러스터와의 호환성을 보장하기 위해 Apache Kafka의 Streams는 정적 컨트롤러 쿼럼도 계속 사용합니다.
이 제한은 컨트롤러 쿼럼의 동적 확장은 다음을 지원하는 데 사용할 수 없음을 의미합니다.
- 컨트롤러 역할을 사용하여 노드 풀 추가 또는 제거
- 기존 노드 풀에 컨트롤러 역할 추가
- 기존 노드 풀에서 컨트롤러 역할 제거
- 컨트롤러 역할을 사용하여 노드 풀 확장
- 컨트롤러 역할로 노드 풀 이름 변경
정적 컨트롤러 쿼럼은 스케일링이 필요한 작업도 제한합니다. 예를 들어 컨트롤러 쿼럼을 확장해야 하므로 컨트롤러 역할을 사용하여 노드 풀의 스토리지 유형을 변경할 수 없습니다. 비JBOD 스토리지의 경우 원하는 스토리지 유형을 사용하여 새 노드 풀을 생성하고 클러스터에 추가하고 기존 노드를 제거하려면 확장 작업이 필요합니다. 경우에 따라 해결방법이 있을 수 있습니다. 예를 들어 컨트롤러 및 브로커 기능을 결합하도록 노드 풀 역할을 수정할 때 컨트롤러 노드에 컨트롤러 역할을 추가하여 컨트롤러 스케일링을 방지하기 위해 컨트롤러 역할을 컨트롤러 노드에 추가할 수 있습니다. 그러나 이 접근 방식에서는 더 많은 데이터를 다시 할당해야 하므로 클러스터 성능에 일시적으로 영향을 미칠 수 있습니다.
마이그레이션이 가능한 경우 Streams for Apache Kafka는 동적 쿼럼에 대한 지원 도입을 평가할 계획입니다.