[Kafka] KRaft 설정 파일 및 기본 속성 정의 알아보기

[Kafka] KRaft 설정 파일 및 기본 속성 정의 알아보기

 

l  Kafka 3.6.1 with KRaft

 

Apache Kafka Raft(KRaft)는 메타데이터 관리를 위해 ZooKeeper에 대한 Apache Kafka의 종속성을 제거하기 위해 KIP-500에 도입된 합의 프로토콜이다. 이는 메타데이터에 대한 책임을 ZooKeeper와 Kafka라는 두 개의 다른 시스템으로 분할하는 대신 Kafka 자체에 통합함으로써 Kafka의 아키텍처를 크게 단순화한다. KRaft 모드는 이전 컨트롤러를 대체하고 Raft 합의 프로토콜의 이벤트 기반 변형을 사용하는 Kafka의 새로운 쿼럼 컨트롤러 서비스를 사용한다.

 

Kafka의 새로운 쿼럼 컨트롤러의 이점은 아래와 같다.

1.          KRaft는 적절한 크기의 클러스터를 지원한다. 즉, 적절한 수의 브로커로 크기가 조정되고 사용 사례의 처리량 및 대기 시간 요구 사항을 충족하도록 컴퓨팅되는 클러스터를 의미하며 수백만 개의 파티션까지 확장할 수 있는 가능성이 있다.

2.          안정성을 향상시키고 소프트웨어를 단순화하며 Kafka를 보다 쉽게 모니터링, 관리 및 지원할 수 있다.

3.          Kafka가 전체 시스템에 대해 단일 보안 모델을 가질 수 있도록 한다.

4.          구성, 네트워킹 설정, 통신 프로토콜에 대한 통합 관리 모델을 제공한다.

5.          Kafka를 시작하기 위한 경량의 단일 프로세스 방법을 제공한다.

6.          컨트롤러 장애 조치를 거의 즉각적으로 수행한다.

 

쿼럼 컨트롤러는 새로운 KRaft 프로토콜을 사용하여 메타데이터가 쿼럼 전체에 정확하게 복제되도록 한다. 쿼럼 컨트롤러는 이벤트 소스 저장소 모델을 사용하여 상태를 저장하므로 내부 상태 머신이 항상 정확하게 다시 생성될 수 있다. 이 상태를 저장하는 데 사용되는 이벤트 로그(메타데이터 주제라고도 함)는 로그가 무한정 커지지 않도록 정기적으로 스냅샷으로 요약된다. 쿼럼 내의 다른 컨트롤러는 활성 컨트롤러가 생성하고 해당 로그에 저장하는 이벤트에 응답하여 활성 컨트롤러를 따른다. 따라서 분할 이벤트로 인해 한 노드가 일시 중지되면 다시 참여할 때 로그에 액세스하여 놓친 이벤트를 빠르게 따라잡을 수 있다.

 

KRaft 프로토콜의 이벤트 중심 특성은 ZooKeeper 기반 컨트롤러와 달리 쿼럼 컨트롤러가 활성화되기 전에 ZooKeeper에서 상태를 로드할 필요가 없음을 의미한다. 리더십이 변경되면 새 활성 컨트롤러에는 이미 커밋된 모든 메타데이터 레코드가 메모리에 있다. 게다가 KRaft 프로토콜에 사용되는 것과 동일한 이벤트 중심 메커니즘이 클러스터 전체의 메타데이터를 추적하는 데 사용된다. 이전에 RPC로 처리되었던 작업은 이제 통신을 위해 실제 로그를 사용하는 것뿐만 아니라 이벤트 중심으로 처리되는 이점도 있다.

 

	WITH ZOOKEEPER	WITH KRAFT (NO ZOOKEEPER)
Configuring Clients and Services	zookeeper.connect=zookeeper:2181	bootstrap.servers=broker:9092
Configuring Schema Registry	kafkastore.connection.url=zookeeper:2181	kafkastore.bootstrap.servers=broker:9092
Kafka administrative tools	kafka-topics --zookeeper zookeeper:2181	kafka-topics --bootstrap-server broker:9092 ... --command-config properties to connect to brokers
REST Proxy API	v1	v2 or v3
Getting the Kafka Cluster ID	zookeeper-shell zookeeper:2181 get/cluster/id	kafka-metadata-quorum or view metadata.properties or confluent cluster describe --url http://broker:8090 --output json

 

 

KRaft의 구성 파일 내용은 서버가 브로커인지 컨트롤러인지 또는 둘 다인지에 따라 다르다. 서버를 실행할 때, 어떤 구성 파일을 로드하여 사용하느냐에 따라 서버의 역할을 정의할 수 있다. 일반적으로 구성 파일은 아래 경로에 있다.

/kafka/config/kraft/

 

모든 파일에 대해 서버 기본 섹션의 설정이 포함되어야 한다. 추가 설정은 서버가 브로커인지, 컨트롤러인지, 아니면 둘 다인지에 따라 달라진다.

l  broker.properties- 서버가 브로커 전용일 때 사용하는 설정파일

l  controller.properties- 서버가 컨트롤러일 때 사용하는 설정파일

l  server.properties- 서버가 브로커이자 컨트롤러인 경우에 사용하는 설정 파일이며, 프로덕션에서는 가급적 용도를 분리하여 사용하는 것을 권장

 

각 파일에서 사용되는 기본 속성과 정의에 대해서 알아보자.

[#####Server basics#####]

[process.roles = {broker | controller | broker, controller}]

이 속성은 서버가 컨트롤러, 브로커 또는 둘 다의 역할을 하는지 여부를 지정한다. KRaft 모드에서는 특정 Kafka 서버가 컨트롤러로 선택되어 클러스터에 대한 메타데이터를 메타데이터 로그에 저장하고 다른 서버는 브로커로 선택된다. 컨트롤러로 선택된 서버는 메타데이터 쿼럼에 참여하게 된다. 각 컨트롤러는 현재 활성 컨트롤러에 대한 활성 또는 상시 대기 상태이다.

 

프로덕션 환경에서는 컨트롤러 쿼럼이 여러 노드에 배포된다. 이것을 앙상블이라고한다. 앙상블은 2n + 1 컨트롤러 세트이다. 여기서 n은 0보다 큰 임의의 숫자이며, 홀수 개의 컨트롤러를 사용하면 컨트롤러 쿼럼이 리더십에 대한 다수 선거를 수행할 수 있다. 언제든지 앙상블에는 최대 n개의 실패한 서버가 있을 수 있으며 클러스터는 쿼럼을 유지한다. 예를 들어 컨트롤러가 3개인 경우 클러스터는 하나의 컨트롤러 오류를 허용할 수 있다. 5개의 컨트롤러를 사용하면 클러스터는 2개의 컨트롤러 오류를 허용할 수 있다. 전체 쿼럼이 손실되면 클러스터가 다운된다.

 

[node.id ]

서버의 고유 식별자로, 각 노드 ID는 특정 클러스터의 모든 서버에서 고유해야 한다.

 

[controller.quorum.voters=1@localhost:9093]

쿼럼 투표자 목록으로, 다수의 서버일 경우 쉼표로 구분한다. Kafka 클러스터의 모든 서버(컨트롤러 및 브로커)는 이 속성을 사용하여 쿼럼 투표자를 검색하며 속성에 제공하는 목록에 컨트롤러를 포함하여 모든 컨트롤러를 식별해야 한다.

 

각 컨트롤러는 {id}@{host}:{port} 형식을 사용하며, 여러 항목을 사용할 경우 쉼표로 구분한다.

controller.quorum.voters=1@host1:port1,2@host2:port2,3@host3:port3

 

속성에 제공된 노드 ID는 controller.quorum.voters컨트롤러 서버의 해당 ID와 일치해야 한다. 예를 들어, 컨트롤러1에서는 node.id를 반드시 1 로 설정해야 한다. 서버가 브로커 전용인 경우 해당 노드 ID가 목록에 표시되어서는 안 된다.

 

 

[#####Socket server settings#####]

[listeners]

소켓 서버가 수신하는 주소 목록으로 쉼표로 구분한다. 서버가 격리 모드의 컨트롤러 역할(process.roles=controller)인 경우, 이 목록에는 컨트롤러 리스너만 허용되며 이 리스너는 controller.quorum.voters 값과 일치해야 한다.

 

호스트 이름이 java.net.InetAddress.getCanonicalHostName()구성파일과 같을 경우 호스트 이름은 리스너 이름 및 포트 값과 동일하다.

listeners=PLAINTEXT://your.host.name:9092

 

결합 모드의 컨트롤러의 경우 컨트롤러 수신기와 브로커 수신기를 나열해야 합니다.

 

[controller.listener.names]

컨트롤러에서 listener_name에 사용하는 목록은 쉼표로 구분한다. process.roles=broker목록의 첫 번째 리스너만 브로커에서 사용된다. ZooKeeper 기반 브로커는 이 값을 설정하면 안 된다. 격리 모드 또는 결합 모드의 KRaft 컨트롤러의 경우 노드는 이 속성에 대해 나열된 모든 리스너에서 KRaft 컨트롤러로 수신하며 각각은 listeners 속성에 나타나야 한다. ZooKeeper 모드에서는 advertised.listeners 속성이 사용되지 않는다.

 

 

[#####Log settings#####]

[log.dirs]

로그 파일을 저장할 디렉터리의 이며, 여러 디렉터리를 사용할 경우 쉼표로 구분한다. KRaft 컨트롤러를 사용할 때 메타데이터 로그에 대해 이 속성을 재정의하려면 메타데이터 보존 설정을 참조한다. KRaft 모드의 경우 JBOD가 지원되지 않으므로 현재 하나의 로그 디렉터리만 나열해야 한다.

 

[num.partitions]

주제당 기본 로그 파티션 개수이다. 파티션이 많을수록 더 많은 병렬 처리가 가능하지만 이로 인해 브로커 전체에 더 많은 파일이 생성된다. 브로커에 대해서만 이 구성을 설정이 적용되며, KRaft 컨트롤러에서 무시된다.

 

 

 

[참고자료]

l  https://developer.confluent.io/learn/kraft/

l  Configure KRaft in Production : https://docs.confluent.io/platform/current/kafka-metadata/config-kraft.html

 

 

 

2024-01-11 / Sungwook Kang / https://sungwookkang.com

 

 

KAFKA, 아파치 카프카, Apache Kafka, KRaft, 크래프트