6.3. ZooKeeper 구성
Kafka는 ZooKeeper를 사용하여 구성 데이터를 저장하고 클러스터 조정을 위해 사용합니다. 복제된 ZooKeeper 인스턴스의 클러스터를 실행하는 것이 좋습니다.
6.3.1. 기본 구성
ZooKeeper의 가장 중요한 설정 옵션은 다음과 같습니다.
tickTime
- zookeeper의 기본 시간 단위(밀리초)입니다. 하트비트 및 세션 시간 초과에 사용됩니다. 예를 들어 최소 세션 시간 제한은 두 개의 눈금입니다.
dataDir
-
ZooKeeper가 메모리 내 데이터베이스의 트랜잭션 로그 및 스냅샷을 저장하는 디렉터리입니다. 설치 중에 생성된
/var/lib/zookeeper/
디렉터리로 설정해야 합니다. clientPort
-
클라이언트가 연결할 수 있는 포트 번호입니다. 기본값은
2181
입니다.
config/zookeeper.properties
라는 ZooKeeper 구성 파일의 예는 AMQ Streams 설치 디렉터리에 있습니다. ZooKeeper의 대기 시간을 최소화하기 위해 dataDir
디렉터리를 별도의 디스크 장치에 배치하는 것이 좋습니다.
zookeeper 구성 파일은 /opt/kafka/config/zookeeper.properties
에 있어야 합니다. 구성 파일의 기본 예는 다음과 같습니다. kafka
사용자가 구성 파일을 읽을 수 있어야 합니다.
tickTime=2000 dataDir=/var/lib/zookeeper/ clientPort=2181
6.3.2. zookeeper 클러스터 구성
대부분의 프로덕션 환경에서는 복제된 ZooKeeper 인스턴스 클러스터를 배포하는 것이 좋습니다. 안정적이고 가용성이 높은 ZooKeeper 클러스터는 신뢰할 수 있는 ZooKeeper 서비스를 실행하는 데 중요합니다. zookeeper 클러스터를 ensembles 라고도 합니다.
zookeeper 클러스터는 일반적으로 홀수의 노드로 구성됩니다. zookeeper를 사용하려면 클러스터의 대다수 노드가 가동되어 실행 중이어야 합니다. 예를 들면 다음과 같습니다.
- 3개의 노드가 있는 클러스터에서 노드 중 두 개 이상이 실행 중이어야 합니다. 즉, 하나의 노드가 다운될 수 있습니다.
- 5개의 노드로 구성된 클러스터에서는 3개 이상의 노드를 사용할 수 있어야 합니다. 즉, 두 개의 노드가 다운될 수 있습니다.
- 7개의 노드로 구성된 클러스터에서는 4개 이상의 노드를 사용할 수 있어야 합니다. 즉, 중단된 세 개의 노드를 허용할 수 있습니다.
ZooKeeper 클러스터에 더 많은 노드가 있으면 전체 클러스터의 복원력과 신뢰성이 향상됩니다.
zookeeper는 노드가 짝수인 클러스터에서 실행할 수 있습니다. 그러나 추가 노드는 클러스터의 복원력을 증가시키지 않습니다. 4개의 노드가 있는 클러스터에는 사용 가능한 노드를 3개 이상 사용할 수 있어야 하며 하나의 노드만 중단할 수 있습니다. 따라서 노드가 3개뿐인 클러스터와 정확히 복원력이 동일합니다.
이상적으로 다른 ZooKeeper 노드는 다른 데이터 센터 또는 네트워크 세그먼트에 있어야 합니다. ZooKeeper 노드 수를 늘리면 클러스터 동기화에 소요되는 워크로드가 증가합니다. 대부분의 Kafka 사용 사례의 경우 3, 5 또는 7 개의 노드가 있는 ZooKeeper 클러스터로 충분합니다.
노드가 3개인 ZooKeeper 클러스터는 사용할 수 없는 노드가 1개만 허용할 수 있습니다. 즉, 다른 노드에서 유지보수를 수행하는 동안 클러스터 노드가 충돌하는 경우 ZooKeeper 클러스터를 사용할 수 없습니다.
복제된 ZooKeeper 구성은 독립 실행형 구성에서 지원하는 모든 구성 옵션을 지원합니다. 클러스터링 구성에 대한 추가 옵션이 추가되었습니다.
initLimit
-
클러스터 리더에 연결하고 동기화할 수 있는 배지를 허용하는 시간입니다. 시간은 여러 개의 눈금으로 지정됩니다(자세한 내용은
tickTime
옵션 참조). syncLimit
-
팔로워가 리더 뒤에 있을 수 있는 시간. 시간은 여러 개의 눈금으로 지정됩니다(자세한 내용은
tickTime
옵션 참조). reconfigEnabled
- 동적 재구성을 활성화하거나 비활성화합니다. 서버를 ZooKeeper 클러스터에 추가하거나 제거하려면 이를 활성화해야 합니다.
standaloneEnabled
- ZooKeeper가 하나의 서버에서만 실행되는 독립 실행형 모드를 활성화하거나 비활성화합니다.
위의 옵션 외에도 모든 구성 파일에는 ZooKeeper 클러스터의 멤버여야 하는 서버 목록이 포함되어야 합니다. 서버 레코드는 server.id=hostname:port1:port2
형식으로 지정해야 합니다.
id
- ZooKeeper 클러스터 노드의 ID입니다.
hostname
- 노드가 연결을 청취하는 호스트 이름 또는 IP 주소입니다.
port1
- 클러스터 내부 통신에 사용되는 포트 번호입니다.
port2
- 리더 선택을 위해 사용되는 포트 번호입니다.
다음은 3개의 노드가 있는 ZooKeeper 클러스터의 구성 파일 예제입니다.
tickTime=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
4개의 문자 단어 명령을 사용하려면 zookeeper.properties
에서 4lw.commands.whitelist=*
를 지정합니다.
MyID
파일
ZooKeeper 클러스터의 각 노드에는 고유 ID
가 할당되어야 합니다. 각 노드의 ID
는 myid
파일에 구성하고 dataDir
폴더에 (예: /var/lib/zookeeper/
)에 저장해야 합니다. myid
파일에는 기록된 ID
가 텍스트로 한 줄만 포함되어야 합니다. ID
는 1에서 255 사이의 정수일 수 있습니다. 각 클러스터 노드에서 이 파일을 수동으로 생성해야 합니다. 이 파일을 사용하여 각 ZooKeeper 인스턴스는 구성 파일의 해당 서버
의 구성을 사용하여 리스너를 구성합니다. 또한 다른 모든 server.
행을 사용하여 다른 클러스터 구성원을 식별합니다.
위의 예에서는 3개의 노드가 있으므로 각각 1
개,2
개, 3
개의 값이 각각 다른 myid
를 갖습니다.
6.3.3. 인증
기본적으로 ZooKeeper는 어떠한 형태의 인증도 사용하지 않으며 익명 연결을 허용합니다. 그러나 SASL(Simple Authentication and Security Layer)을 사용하여 인증을 설정하는 데 사용할 수 있는 JAAS(Java Authentication and Authorization Service)를 지원합니다. zookeeper는 로컬에 저장된 인증 정보가 있는 DIGEST-knative5 SASL 메커니즘을 사용한 인증을 지원합니다.
6.3.3.1. SASL을 사용한 인증
CloudEvent는 별도의 구성 파일을 사용하여 구성됩니다. ScanSetting 구성 파일을 ZooKeeper 구성과 동일한 디렉터리에 배치하는 것이 좋습니다(/opt/kafka/config/
). 권장 파일 이름은 zookeeper-jaas.conf
입니다. 여러 노드가 있는 ZooKeeper 클러스터를 사용할 때 모든 클러스터 노드에 CloudEvent 구성 파일을 생성해야 합니다.
context를 사용하여 구성됩니다. 서버 및 클라이언트와 같은 별도의 부분은 항상 별도의 컨텍스트 로 구성됩니다. 컨텍스트는 구성 옵션이며 다음 형식이 있습니다.
ContextName { param1 param2; };
SASL 인증은 서버 간 통신( ZooKeeper 인스턴스 간 통신) 및 클라이언트-서버 간 통신( Kafka와 ZooKeeper 간의 통신)을 위해 별도로 구성됩니다. 서버 간 인증은 여러 노드가 있는 ZooKeeper 클러스터에만 관련이 있습니다.
서버 간 인증
서버 간 인증의 경우 CloudEvent 구성 파일에는 다음 두 부분이 포함됩니다.
- 서버 구성
- 클라이언트 구성
DIGEST-ECDHE5 SASL 메커니즘을 사용하는 경우 QuorumServer
컨텍스트를 사용하여 인증 서버를 구성합니다. 암호화되지 않은 형태로 암호와 함께 연결할 수 있는 모든 사용자 이름을 포함해야 합니다. 두 번째 컨텍스트 인 Quorum
learner는 ZooKeeper에 빌드된 클라이언트를 위해 구성해야 합니다. 또한 암호화되지 않은 형식의 암호를 포함합니다. DIGEST-ECDHE5 메커니즘에 대한 CloudEvent 구성 파일의 예는 다음과 같습니다.
QuorumServer { org.apache.zookeeper.server.auth.DigestLoginModule required user_zookeeper="123456"; }; QuorumLearner { org.apache.zookeeper.server.auth.DigestLoginModule required username="zookeeper" password="123456"; };
10.0.0.1 구성 파일 외에도 다음 옵션을 지정하여 일반 ZooKeeper 구성 파일에서 서버 간 인증을 활성화해야 합니다.
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
KAFKA_OPTS
환경 변수를 사용하여 CloudEvent 구성 파일을 Java 속성으로 ZooKeeper 서버에 전달합니다.
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
서버 간 인증에 대한 자세한 내용은 ZooKeeper journalctl을 참조하십시오.
클라이언트-서버 간 인증
클라이언트-서버 간 인증은 서버-서버 인증과 동일한 10.0.0.1 파일에 구성되어 있습니다. 그러나 서버 간 인증과 달리 서버 구성만 포함됩니다. 구성의 클라이언트 부분은 클라이언트에서 수행해야 합니다. 인증을 사용하여 ZooKeeper에 연결하도록 Kafka 브로커를 구성하는 방법에 대한 자세한 내용은 Kafka 설치 섹션을 참조하십시오.
Server 컨텍스트를 10.0.0.1 구성 파일에 추가하여 클라이언트 간 인증을 구성합니다. DIGEST-ECDHE5 메커니즘의 경우 모든 사용자 이름과 암호를 구성합니다.
Server { org.apache.zookeeper.server.auth.DigestLoginModule required user_super="123456" user_kafka="123456" user_someoneelse="123456"; };
CloudEvent 컨텍스트를 구성한 후 다음 행을 추가하여 ZooKeeper 구성 파일에서 클라이언트 간 인증을 활성화합니다.
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
ZooKeeper 클러스터의 일부인 모든 서버에 대해 authProvider. <ID
> 속성을 추가해야 합니다.
KAFKA_OPTS
환경 변수를 사용하여 CloudEvent 구성 파일을 Java 속성으로 ZooKeeper 서버에 전달합니다.
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
Kafka 브로커에서 ZooKeeper 인증을 구성하는 방법에 대한 자세한 내용은 6.4.5절. “zookeeper 인증” 을 참조하십시오.
6.3.3.2. DIGEST-ECDHE5를 사용하여 서버 간 인증 활성화
다음 절차에서는 ZooKeeper 클러스터의 노드 간에 SASL DIGEST-ECDHE5 메커니즘을 사용하여 인증을 활성화하는 방법을 설명합니다.
사전 요구 사항
- AMQ Streams가 호스트에 설치됨
- zookeeper 클러스터는 여러 노드로 구성됩니다.
SASL DIGEST- CHAP5 인증 활성화
모든 ZooKeeper 노드에서
/opt/kafka/config/zookeeper-jaas.conf
settings 파일을 생성하거나 편집하고 다음 컨텍스트를 추가합니다.QuorumServer { org.apache.zookeeper.server.auth.DigestLoginModule required user_<Username>="<Password>"; }; QuorumLearner { org.apache.zookeeper.server.auth.DigestLoginModule required username="<Username>" password="<Password>"; };
사용자 이름과 암호는 CloudEvent 컨텍스트 모두에서 동일해야 합니다. 예를 들면 다음과 같습니다.
QuorumServer { org.apache.zookeeper.server.auth.DigestLoginModule required user_zookeeper="123456"; }; QuorumLearner { org.apache.zookeeper.server.auth.DigestLoginModule required username="zookeeper" password="123456"; };
모든 ZooKeeper 노드에서
/opt/kafka/config/zookeeper.properties
ZooKeeper 구성 파일을 편집하고 다음 옵션을 설정합니다.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
모든 ZooKeeper 노드를 하나씩 다시 시작합니다. CloudEvent 구성을 ZooKeeper에 전달하려면
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
6.3.3.3. DIGEST-ECDHE5를 사용하여 클라이언트 간 인증 활성화
다음 절차에서는 ZooKeeper 클라이언트와 ZooKeeper 간의 SASL DIGEST-ECDHE5 메커니즘을 사용하여 인증을 활성화하는 방법을 설명합니다.
사전 요구 사항
- AMQ Streams가 호스트에 설치됨
- zookeeper 클러스터가 구성 및 실행 중입니다.
SASL DIGEST- CHAP5 인증 활성화
모든 ZooKeeper 노드에서
/opt/kafka/config/zookeeper-jaas.conf
settings 파일을 생성하거나 편집하여 다음 컨텍스트를 추가합니다.Server { org.apache.zookeeper.server.auth.DigestLoginModule required user_super="<SuperUserPassword>" user<Username1>_="<Password1>" user<USername2>_="<Password2>"; };
슈퍼
에는 자동으로 관리자 권한이 있습니다. 이 파일은 여러 사용자를 포함할 수 있지만 Kafka 브로커에 의해 하나의 추가 사용자만 필요합니다. Kafka 사용자의 권장 이름은kafka
입니다.다음 예제는 클라이언트-서버 간 인증에 대한
Server
컨텍스트를 보여줍니다.Server { org.apache.zookeeper.server.auth.DigestLoginModule required user_super="123456" user_kafka="123456"; };
모든 ZooKeeper 노드에서
/opt/kafka/config/zookeeper.properties
ZooKeeper 구성 파일을 편집하고 다음 옵션을 설정합니다.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
authProvider. <ID
> 속성은 ZooKeeper 클러스터의 일부인 모든 노드에 대해 추가해야 합니다. 예제 3 노드 ZooKeeper 클러스터 구성은 다음과 같아야 합니다.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
모든 ZooKeeper 노드를 하나씩 다시 시작합니다. CloudEvent 구성을 ZooKeeper에 전달하려면
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
6.3.4. 권한 부여
Zookeeper는 ACL(액세스 제어 목록)을 지원하여 내부에 저장된 데이터를 보호합니다. Kafka 브로커는 생성하는 모든 ZooKeeper 레코드에 대한 ACL 권한을 자동으로 구성하여 다른 ZooKeeper 사용자가 수정할 수 없도록 합니다.
Kafka 브로커에서 ZooKeeper ACL 활성화에 대한 자세한 내용은 6.4.7절. “zookeeper 권한 부여” 을 참조하십시오.
6.3.5. TLS
zookeeper는 암호화 또는 인증을 위해 TLS를 지원합니다.
6.3.6. 추가 구성 옵션
사용 사례에 따라 다음과 같은 추가 ZooKeeper 구성 옵션을 설정할 수 있습니다.
maxClientCnxns
- ZooKeeper 클러스터의 단일 멤버에 대한 최대 동시 클라이언트 연결 수입니다.
autopurge.snapRetainCount
-
유지되는 ZooKeeper의 메모리 내 데이터베이스 스냅샷 수입니다. 기본값은
3
입니다. autopurge.purgeInterval
-
스냅샷 삭제의 시간 간격(시간)입니다. 기본값은
0
이며 이 옵션은 비활성화되어 있습니다.
사용 가능한 모든 구성 옵션은 ZooKeeper 설명서에서 확인할 수 있습니다.