Amazon Managed Streaming for Apache Kafka (Amazon MSK)

Amazon MSK란?

Amazon MSK (Managed Streaming for Apache Kafka) 는 Apache Kafka를 사용하여 스트리밍 데이터를 처리하는 애플리케이션을 빌드하고 실행할 수 있는 완전관리형 서비스입니다. Amazon MSK는 클러스터 생성, 업데이트 및 삭제 등에 필요한 작업을 제공합니다.

데이터 생성 및 소비와 같은 Apache Kafka 데이터 영역 작업을 사용할 수 있습니다. Apache Kafka의 오픈 소스 버전을 실행합니다. 즉, 파트너와 Apache Kafka 커뮤니티의 기존 애플리케이션, 도구 및 플러그인이 지원되므로 애플리케이션 코드를 변경할 필요가 없습니다. Amazon MSK를 사용하면 Apache Kafka 를 사용하는 클러스터를 생성할 수 있습니다.

다음 다이어그램은 Amazon MSK의 작동 방식에 대한 개요입니다.

다이어그램은 다음 구성 요소 간의 상호 작용을 보여 줍니다.

• 브로커 노드— Amazon MSK 클러스터를 생성할 때 Amazon MSK가 각 가용 영역에 생성할 브로커 노드 수를 지정합니다. 이 다이어그램에 표시된 예제 클러스터에는 가용 영역당 하나의 브로커가 있습니다. 각 가용 영역에는 고유한 virtual private cloud(VPC) 서브넷이 있습니다.
• ZooKeeper 노드— Amazon MSK는 Apache ZooKeeper 노드도 만듭니다. Apache ZooKeeper는 안정성이 뛰어난 분산 조정을 지원하는 오픈 소스 서버입니다.
• 생산자, 소비자 및 주제— Amazon MSK를 사용하면 Apache Kafka topic을 만들고, 데이터를 생산하고 소비할 수 있습니다.
• 클러스터 작업은 다음을 수행할 수 있습니다.AWS Management Console,AWS Command Line Interface(AWS CLI) 또는 SDK의 API를 사용하여 제어 영역 작업을 수행할 수 있습니다. 예를 들어 Amazon MSK 클러스터를 만들거나 삭제하고, 계정의 모든 클러스터를 나열하고, 클러스터의 속성을 보고, 클러스터의 브로커 수와 유형을 업데이트할 수 있습니다.

Amazon MSK는 클러스터에 대한 가장 일반적인 결함 시나리오를 감지하고 자동으로 복구하므로 생산자와 소비자 애플리케이션이 최소한의 영향을 받으면서 쓰기 및 읽기 작업을 계속할 수 있습니다. Amazon MSK가 브로커 결함을 감지하면 해당 결함을 완화하거나 비정상적 또는 연결할 수 없는 브로커를 새 브로커로 바꿉니다. 또한 가능한 경우 이전 브로커의 스토리지를 재사용하여 Apache Kafka가 복제해야 하는 데이터를 줄입니다. 가용성에 미치는 영향은 Amazon MSK가 감지 및 복구를 완료하는 소요되는 시간입니다.복구 후 생산자와 소비자 앱은 결함 이전에 사용한 것과 동일한 브로커 IP 주소와 계속 통신할 수 있습니다.

 

 

 

 

 

3단계: Amazon MSK 클러스터

 

 

AWS 콘솔 검색창에 msk를 입력하면 아래 화면과 같이 MSK 서비스가 조회되는데, MSK를 클릭합니다.

 

MSK 시작화면이 나오면 "Create cluster" 버튼을 클릭합니다.

 

1번째

2번째

3번째

Step 2

OR

Step 4 : Monitoring and tags

• Step 5
  Review and create

client 정보 확인

4단계: 클라이언트 머신 만들기

이 단계에서는Amazon MSK 사용 시작하기클라이언트 머신을 생성합니다. 이 클라이언트 머신을 사용하여 데이터를 생산하고 소비하는 주제를 만듭니다. 단순하게 설명하기 위해 이 클라이언트 머신을 Amazon MSK 클러스터와 동일한 VPC 배치합니다. 그러나 클라이언트 머신이 클러스터와 동일한 VPC에 있을 필요는 없습니다.

5단계: 주제 생성

이 단계에서는Amazon MSK 사용 시작하기를 클라이언트 머신에 Apache Kafka 클라이언트 라이브러리 및 도구를 설치한 다음, 주제를 만듭니다.

다음 단계

ZooKeeper 명령줄 인터페이스에 대해 알아봅니다.

zookeeper 접속

아래 명령어로 로컬 ZooKeeper 서버에 접속합니다.

bin/zkCli.sh -server 127.0.0.1:2181

아래와 같이 CONNECTED 프롬프트가 나오면 정상입니다.

Connecting to 127.0.0.1:2181
...
...
[zk: 127.0.0.1:2181(CONNECTED) 0]

혹시, 

WATCHER::

WatchedEvent state:SyncConnected type:None path:null

메시지 상태에 멈추어 있으면 엔터키를 칩니다.

위 프롬프트에서 help 명령어를 입력하고 엔터를 칩니다. 그럼 아래와 같이 표시됩니다.

[zk: 127.0.0.1:2181(CONNECTED) 0] help
ZooKeeper -server host:port cmd args
    stat path [watch]
    set path data [version]
...  ...
    close
    connect host:port

ls 명령으로 전체 znode를 확인할 수 있습니다.

[zk: 127.0.0.1:2181(CONNECTED) 21] ls /
[admin, brokers, cluster, config, consumers,... ... zookeeper]

1. Create Znodes

주어진 경로로 znode를 생성합니다. znode 명은 대소문자를 구분합니다.

플래그는 생성할 Znode가 임시(flag:e), 영구 또는 순차(flag:e)인지를 지정합니다. 모든 znode는 기본적으로 영구입니다.
임시 znode(flag:e)는 세션이 만료되거나 클라이언트 연결이 끊어지면 자동으로 삭제됩니다. 
순차 znode는 znode 경로에 10자리로  시퀀스 번호를 추가합니다. 예를 들어, znode 경로 /myapp를 순차노드로 생성하게 되면  /myapp0000000001로 변환되되어 생성됩니다.

플래그가 지정되지 않은 znode는 영구로 간주합니다.

flag

-s : 순차 znode

-e : 임시 znode

참고로 한글 znode도 생성할 수 있습니다. data는 공백이 있는 경우 " " 로 묶어줍니다.

1.1 영구 znode를 생성합니다.

a. Syntax(문법) : create /path data

b. Sample(예제)

create /zk_test my_data를 실행하여 새 znode를 만듭니다. 그러면 새 znode가 생성되고 "my_data" 문자열이 노드와 연결됩니다.

[zk: 127.0.0.1:2181(CONNECTED) 22] create /zk_test my_data
Created /zk_test

1.2 순차 znode를 생성합니다. 순차 znode를 생성하기 위해 -s 플래그를 추가합니다.

a. Syntax : create -s /path data

b. Sample

[zk: 127.0.0.1:2181(CONNECTED) 6] create -s /FirstZnode second-data
Created /FirstZnode0000000041

a. Syntax : create -e /path data

b. 예제

[zk: 127.0.0.1:2181(CONNECTED) 7] create -e /SecondZnode "Ephemeral-data"
Created /SecondZnode

클라이언트 연결이 끊어지면 임시 znode가 삭제되는지 확인하려면 ZooKeeper CLI를 종료한 다음 CLI를 다시 열면 확인할 수 있습니다.

2. Get Data

znode의 관련 데이터와 지정된 znode의 메타데이터를 가져오기 위해 이 명령어를 사용합니다. 데이터가 마지막으로 수정된 시간, 수정된 위치 및 데이터에 대한 모든 정보와 같은 정보를 얻을 수 있습니다.
이 명령으로 데이터에 대한 알림을 표시하도록 합니다.

2.1 영구노드 조회

a. Syntax : get -s /path

b. Sample

get -s /FirstZnode 명령어로 /FirstZnode 에 있는 데이터에 대한 정보를 보여줍니다.

[zk: 127.0.0.1:2181(CONNECTED) 14] get -s /FirstZnode
Myfirstzookeeper-app
cZxid = 0x877
ctime = Sun Jan 09 21:23:53 KST 2022
mZxid = 0x877
mtime = Sun Jan 09 21:23:53 KST 2022
pZxid = 0x877
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 20
numChildren = 0

a. Syntax : get -s /path

b. Sample

get -s /FirstZnode0000000041 명령어로  /FirstZnode0000000041 에 있는 데이터에 대한 정보를 보여줍니다.

[zk: 127.0.0.1:2181(CONNECTED) 20] get -s /FirstZnode0000000041
second-data
cZxid = 0x878
ctime = Sun Jan 09 21:24:52 KST 2022
mZxid = 0x878
mtime = Sun Jan 09 21:24:52 KST 2022
pZxid = 0x878
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 11
numChildren = 0

a. Syntax : getEphemerals -s /path

b. Sample

getEphemerals  / 명령어로  임시노드를 조회합니다.

[zk: 127.0.0.1:2181(CONNECTED) 22] getEphemerals /
[/SecondZnode]

3. Watch

지정된 znode 또는 znode의 자식 데이터가 변경되면 "Watches" 오퍼레이터가 알림을 표시합니다. get 명령에서만 감시를 설정할 수 있습니다. -w 옵션입니다.

a. Syntax : get -w /path

b. Sample

[zk: 127.0.0.1:2181(CONNECTED) 2] get -w /FirstZnode
Myfirstzookeeper-app

watch가 설정되면 znode 변경 시 get 으로 data를 가져오면 아래와 같은 메시지가 출력됩니다.

WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChanged path:/zk_test

4. Set Data

이 명령은 znode의 데이터를 설정합니다. 이 ZooKeeper 설정 작업을 마치면 ZooKeeper에서 get CLI 명령을 사용하여 데이터를 확인할 수 있습니다.

a. Syntax : set /path /data

b. Sample

다음과 같이 set 명령을 실행하여 zk_test와 관련된 데이터를 변경합니다. get 으로 변경된 데이터를 확인합니다.

[zk: 127.0.0.1:2181(CONNECTED) 18] set /zk_test junk

[zk: 127.0.0.1:2181(CONNECTED) 34] get -s /zk_test
junk
cZxid = 0x890
ctime = Sun Jan 09 23:06:22 KST 2022
mZxid = 0x891
mtime = Sun Jan 09 23:06:24 KST 2022
pZxid = 0x890
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

set data 명령 시 znode에 watch 옵션이 설정되어 있으면 아래와 같이 메시지가 같이 출력됩니다.

5. 자식 znode 생성(subznode or children znode)

자식 znode를 만드는 것은 새 znode를 만드는 것과 같습니다. 둘의 차이점은 자식 znode의 경로에 부모 경로가 있다는 것입니다.

a. Syntax : create /parent/subnode data

b. Sample : create /FirstZnode/Child1 firstchildren 명령어로 자식 노드를 생성합니다.

[zk: 127.0.0.1:2181(CONNECTED) 61] create /FirstZnode/Child1 "firstchildren"
Created /FirstZnode/Child1
[zk: 127.0.0.1:2181(CONNECTED) 62] create /FirstZnode/Child2 "secondchildren"
Created /FirstZnode/Child2

6. 노드 조회

ls 명령어로 znode를 조회합니다.

a. Syntax : ls /path

b. Sample

[zk: 127.0.0.1:2181(CONNECTED) 63] ls /FirstZnode
[Child1, Child2]

7. 상태 체크

Status는 지정된 znode의 메타데이터를 조회합니다. 타임스탬프, 버전 번호, ACL, 데이터 길이 및 하위 znode와 같은 여러 세부 정보를 보여줍니다.

a. Syntax : stat /path

b. Sample

stat /FirstZnode 명령어로 /FirstZnode 에 대한 세부 정보를 조회합니다.

[zk: 127.0.0.1:2181(CONNECTED) 64] stat /FirstZnode
cZxid = 0x89e
ctime = Sun Jan 09 23:32:55 KST 2022
mZxid = 0x89e
mtime = Sun Jan 09 23:32:55 KST 2022
pZxid = 0x8a0
cversion = 2
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 2

8. Znode 삭제

a. Syntax : delete /path

b. Sample

[zk: 127.0.0.1:2181(CONNECTED) 49] delete /zk_test
[zk: 127.0.0.1:2181(CONNECTED) 51] get /zk_test
Node does not exist: /zk_test

단, delete 명령은 자식이 없는 znode에서만 작동합니다. 자식이 있는 znode를 삭제하려면 deleteall 명령을 사용합니다.

[zk: 127.0.0.1:2181(CONNECTED) 56] delete /FirstZnode
Node not empty: /FirstZnode

자식이 있는 znode를 삭제하려면 deleteall 명령을 사용합니다.

[zk: 127.0.0.1:2181(CONNECTED) 56] deleteall /FirstZnode
[zk: 127.0.0.1:2181(CONNECTED) 58] get /FirstZnode
Node does not exist: /FirstZnode

본 문서에서는 ZooKeeper 서버의 Silgle-node 설치 및 Multi-node 설치에 대해 설명합니다.

주키퍼를 단독으로 구성할 수도 있지만, 주키퍼를 클러스터로 구성하여 고가용성을 확보한 것을 주키퍼 앙상블(Zookeeper Ensemble)이라고 합니다.

[설치환경] : Window10 WSL2(Ubuntu 20.04)

주키퍼 다운로드 및 설치하기

윈도우 WSL2 에 접속하여 아래 명령어를 수행하여 다운로드 합니다. 아래 다운로드 사이트에서 직접 다운로드해도 됩니다.

다운로드 : https://zookeeper.apache.org/releases.html#download

$ wget http://apache.mirror.cdnetworks.com/zookeeper/stable/apache-zookeeper-3.6.3-bin.tar.gz
$ tar xzvf apache-zookeeper-3.6.3-bin.tar.gz
$ ln -s apache-zookeeper-3.6.3-bin zookeeper

바이너리 버전(apache-zookeeper-3.6.3-bin.tar.gz)과 소스 버전(apache-zookeeper-3.6.3.tar.gz)이 있는데 바이너리 버전으로 다운로드합니다.

주키퍼 환경설정 - 싱글노드 

데이터 디렉토리 생성

지노드의 복사본인 스냅샷과 트랜잭션 로그를  저장할 데이터 디렉토리 또는 파일시스템을 생성합니다.

디렉토리명 또는 파일시스템명은 사용자가 원하는 이름으로 생성합니다.

본 문서에서는 data 디렉토리로 사용할 디렉토리를 /zkdata 로 생성했습니다. 

## For ZooKeeper server in standalone mode

$ mkdir -p /zkdata

config 파일 설정

주키퍼 환경설정 sample 파일은 zookeeper/conf  아래에 있습니다. sample 파일을 복사해서 사용합니다. 아래의 {ZOOKEEPER_HOME}은 다운로드 후 압축을 푼 디렉토리입니다. 각자의 위치가 다를 수 있습니다.

$ cd {ZOOKEEPER_HOME}/zookeeper/conf/
$ cp zoo_sample.cfg zoo.cfg

zoo.cfg 파일을 열어 아래와 같이 환경설정을 해줍니다.

## zoo.cfg 파일

## datdaDir 은 각각의 서버에 맞게 설정하는데 
dataDir=/zkdata

# the port at which the clients will connect
clientPort=2181

• dataDir : 주키퍼의 트랜잭션 로그와 스냅샷이 저장되는 경로(위에서 생성한 경로 지정)
• clientPort : Client 접속 포트(Default로 설정되어 있습니다.)

주키퍼 실행

{ZOOKEEPER_HOME}/zookeeper 디렉토리에서 실행합니다.

{ZOOKEEPER_HOME} 는 다운로드 후 압축을 푼 경로입니다. 각자 경로가 다를 수 있습니다.

기본적으로 localhost(127.0.0.1) 주소로 서버를 기동하게 되어 있으니, 다른 IP 주소를 설정하고 싶은 경우에는 zkServer.sh 파일을 열어 localhost 부분을 원하는 IP Address로 변경하면 됩니다.

$ bin/zkServer.sh start

아래와 같은 실행결과가 화면에 표시되면 정상입니다.

ZooKeeper JMX enabled by default
Using config: /apach/zookeeper/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED

주키퍼는 default로 admin server를 기동하는데 8080 port를 사용합니다.

만일, 주키퍼 기동 시 port 오류가 발생할 경우 충돌한 port를 확인한 후 8080 por 이면

admin.enableServer=false 로 설정하던지, admin.serverPort를 충돌이 되지않는 다른 port를 사용합니다.

zoo.cfg 파일 설정 내용

admin.enableServer=false 또는
admin.serverPort=8888 

zookeeper 접속

아래 명령어로 로컬 ZooKeeper 서버에 접속합니다.

bin/zkCli.sh -server 127.0.0.1:2181

아래와 같이 CONNECTED 프롬프트가 나오면 정상입니다.

Connecting to 127.0.0.1:2181
...
...
[zk: 127.0.0.1:2181(CONNECTED) 0]

혹시, 

WATCHER::

WatchedEvent state:SyncConnected type:None path:null

메시지 상태에 멈추어 있으면 엔터키를 칩니다.

위 프롬프트에서 help 명령어를 입력하고 엔터를 칩니다. 그럼 아래와 같이 표시됩니다.

[zk: 127.0.0.1:2181(CONNECTED) 0] help
ZooKeeper -server host:port cmd args
    stat path [watch]
    set path data [version]
...  ...
    close
    connect host:port

zookeeper 접속 종료

quit 명령어로 로컬 ZooKeeper 서버에 접속을 종료합니다.

[zk: 127.0.0.1:2181(CONNECTED) 0] quit

zookeeper 서비스 종료

아래 명령어로 ZooKeeper 서비스를 종료합니다.

bin/zkServer.sh stop

주키퍼 환경설정 - 멀티노드 

주키퍼 다운로드 및 설치는 위에서 설명한 주키퍼 환경설정 - 싱글노드 과 동일합니다.

주키퍼 환경설정 sample 파일은 zookeeper/conf  아래에 있습니다. sample 파일을 복사해서 사용합니다.

$ cd {ZOOKEEPER_HOME}/zookeeper/conf/

$ cp zoo_sample.cfg zoo1.cfg
$ cp zoo_sample.cfg zoo2.cfg
$ cp zoo_sample.cfg zoo3.cfg

3개 노드로 구성할 경우 아래와 같이 환경설정을 해준다.

(zoo1.cfg 예, 다른 2개의 cfg 파일도 동일하게 작성합니다. 단, dataDir과 clientPor는 각 다르게 작성합니다.)

환경파일 설정

zoo1.cfg 파일 내용

## zoo1.cfg 파일

## datdaDir 은 각각의 서버에 맞게 설정하는데 
## 하나의 서버에 3개의 node를 구성할 경우 각 디렉토리를 다르게 설정
dataDir=/zkdata1
# the port at which the clients will connect
clientPort=2181

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

zoo2.cfg 파일 내용

## zoo2.cfg 파일

## datdaDir 은 각각의 서버에 맞게 설정하는데 
## 하나의 서버에 3개의 node를 구성할 경우 각 디렉토리를 다르게 설정
dataDir=/zkdata2
# the port at which the clients will connect
clientPort=2182

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

zoo3.cfg 파일 내용

## zoo3.cfg 파일

## datdaDir 은 각각의 서버에 맞게 설정하는데 
## 하나의 서버에 3개의 node를 구성할 경우 각 디렉토리를 다르게 설정
dataDir=/zkdata3
# the port at which the clients will connect
clientPort=2183

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

주키퍼 실행

아래 명령어로 3개의 주키퍼 서버를 기동합니다.

$ bin/zkServer.sh start conf/zoo1.cfg
$ bin/zkServer.sh start conf/zoo2.cfg
$ bin/zkServer.sh start conf/zoo3.cfg

가각의 서버 기동 시 아래와 같은 실행결과가 화면에 표시되면 정상입니다.

ZooKeeper JMX enabled by default
Using config: /apach/zookeeper/bin/../conf/zoo1.cfg
Starting zookeeper ... STARTED

zookeeper 접속

주키퍼 서버가 정상 기동인지 확인하기 위해 아래 명령어로 가각의 ZooKeeper 서버에 접속합니다.

서버별 접속 port를 달리하면서 접속확인하면 됩니다.

bin/zkCli.sh -server 127.0.0.1:2181
bin/zkCli.sh -server 127.0.0.1:2182
bin/zkCli.sh -server 127.0.0.1:2183

아래와 같이 CONNECTED 프롬프트가 나오면 정상입니다.

Connecting to 127.0.0.1:2181
...
...
[zk: 127.0.0.1:2181(CONNECTED) 0]

혹시, 

WATCHER::

WatchedEvent state:SyncConnected type:None path:null

메시지 상태에 멈추어 있으면 엔터키를 칩니다.

위 프롬프트에서 help 명령어를 입력하고 엔터를 칩니다. 그럼 아래와 같이 표시됩니다.

[zk: 127.0.0.1:2181(CONNECTED) 0] help
ZooKeeper -server host:port cmd args
    stat path [watch]
    set path data [version]
...  ...
    close
    connect host:port

zookeeper 명령창에서 ls 명령어 znode를 조회합니다.

[zk: 127.0.0.1:2181(CONNECTED) 0] ls /
[zookeeper]

* 참고로, 아파치 broker 서버가 기동되면 zookeeper에서 생성한 zookeeper znode를 제외한 많은 수의 znode들이 생성된다. 

다음은 아파치 브로커 3개의 node를 기동시키고 znode를 조회한 결과입니다.

추가로 /brokers/ids znode 를 조회해보면 3개의 broker가 등록된 것을 확인할 수 있습니다. 

[zk: 127.0.0.1:2182(CONNECTED) 21] ls /
[admin, brokers, cluster, config, consumers, controller, controller_epoch, feature, 
isr_change_notification, latest_producer_id_block, log_dir_event_notification, zookeeper]

[zk: 127.0.0.1:2182(CONNECTED) 19] ls /brokers/ids
[1, 2, 3]

zookeeper 서비스 종료

아래 명령어로 3개의 ZooKeeper 서비스를 종료합니다.

bin/zkServer.sh stop conf/zoo1.cfg
bin/zkServer.sh stop conf/zoo2.cfg
bin/zkServer.sh stop conf/zoo3.cfg

ZooKeeper 란

ZooKeeper는 분산 어플리케이션들에 대한 분산 조정 서비스를 제공하는 프로그램으로 표준 파일 시스템과 유사하게 구성되어 공유된 계층적 공간을 통해서 분산된 프로세스들이 서로 조정할 수 있는 기능을 관리한다. 공유되는 공간은 ZooKeepr의 용어로 zNodes라고 불리는 데이터 등록의 집합으로 구성 되어 있으며 이 구조는 폴더들과 파일들의 구성과 유사하다. 파일 시스템과는 달리 ZooKeeper는 자바로 실행되며 자바와 C에 대한 바인딩을 가지고 있다.

ZooKeeper Cluster 기본 구성

ZooKeeper Service 는 “Ensemble” 이라고 불리는 Host 들의 집합들을 통해서 복제되며, 동일한 어플리케이션을 구성하는 서버들의 복제된 그룹을 “Quorum” 이라고 부른다. Quorum 내의 모든 서버는 동일한 설정 파일들의 복제본을 가지고 있다. 

ZooKepper의 서버 구성의 수는 절반이 실패해도 기능을 수행할 수 있도록 항상 홀수로 구성하는 것을 권장한다. 예를 들어 2대의 서버가 장애 상태가 되어도 나머지 서버들이 동작할 수 있도록 5대의 서버로 구성하는 것이다. 이 중에 한 대는 Leader가 된다. 최소한의 구성은 3 대가 된다.

ZooKeeper Cluster의 구성은 아래의 그림과 같이 기본적으로 Leader를 포함하는 홀 수의 서버 구성이 되어야 한다.

본 문서에서는 한 대의 서버에 3개의 주키퍼 서버 구성을 설명한다.

• ZooKeeper 서버 구성의 수는  - 위에서 언급한 것과 같이 홀수를 기준으로 구성하며, 테스트 환경이므로 3대의 서버로 구성한다.
• 물리적인 서버의 수는 - 물리적인 장애가 발생하는 경우를 대비해서 가능하면 물리적으로 존재하는 서버로 구성하는 것이 좋다. 그러나 본 문서에서는 단일 서버를 사용하도록 한다.
• 운영을 위한 포트의 구성은 - 별도의 서버로 존재하면 Port를 크게 신경쓰지 않아도 되지만 테스트를 위해서 단일 서버에 구성하는 것이기 때문에 아래와 같이 구성한다.
  
  • Client Port  - 클러스터에서 운영할 어플리케이션에 ZooKeeper로 접속하기 위한 포트를 의미한다.
  • Qourum Port  - 클러스터내의 ZooKeeper 서버간에 통신을 위한 포트를 의미한다.
  • Leader election Port  - 클러스터내의 ZooKeeper 서버간에 Leader를 선출하기 위한 통신 포트를 의미한다.

단일 서버에 3개의 ZooKeeper 서버를 구성하기 위해 아래와 같이 포트 구성과 경로를 설정해 준다.

• dataDir 은 in-memory database snapshots을 저장하기 위한 경로이다.
• dataLogDir 은  트랜잭션 Log 저장을 위한 경로이다.

ZooKeeper에 대한 메모리 설정은 - 테스트 시에는 기본 Heap size를 사용해도 되지만 운영 서버 구성 시에는 ZooKeeper 설치 경로의 “/conf/java.env” 파일을 생성해서 메모리 설정을 조정해 준다.

ZooKeeper Multiple Server 구성하기

각각의 주키퍼 서버를 구성하기 위해 환경파일(cfg) 을 구성한다.

주키퍼가 설치된 경로 밑에 conf 디렉토리에 있는 zoo_sample.cfg 을 복사해서 3개의 zoo1.cfg, zoo2.cfg, zoo3.cfg 파일을 생성하고 아래와 같이 각각의 파일을 수정한다.

dataDir과 clientPort 파라미터는 각 주키퍼 서버에 맞도록 설정한다.

zoo1.cfg 파일 내용

dataDir=/zkdata/zkdata1
dataLogDir=/zktlogs/zktlog1
# the port at which the clients will connect
clientPort=2181

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

zoo2.cfg 파일 내용

dataDir=/zkdata/zkdata2
dataLogDir=/zktlogs/zktlog2
# the port at which the clients will connect
clientPort=2182

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

zoo3.cfg 파일 내용

dataDir=/zkdata/zkdata3
dataLogDir=/zktlogs/zktlog3
# the port at which the clients will connect
clientPort=2183

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

myid 파일 생성

각 주키퍼 서버의 dataDir 디렉토리 밑에 myid 파일을 만들고 각 서버를 구별할 수 있도록 1번 서버에는 1, 2번 서버에는 2, 3번 서버에는 3이 기록된 myid 파일을 생성한다.

$ echo 1 > /zkdata/zkdata1/myid
$ echo 2 > /zkdata/zkdata2/myid
$ echo 3 > /zkdata/zkdata3/myid

ZooKeeper Multiple Server 실행하기

각각의 환경파일로 주키퍼 서버를 기동한다.

$ bin/zkServer.sh start conf/zoo1.cfg
$ bin/zkServer.sh start conf/zoo2.cfg
$ bin/zkServer.sh start conf/zoo3.cfg

프로세스가 정상적으로 구동했는지 확인한다.

netstat -an | grep 218
tcp6       0      0 :::2181                 :::*                    LISTEN
tcp6       0      0 :::2182                 :::*                    LISTEN
tcp6       0      0 :::2183                 :::*                    LISTEN

zkServer.sh 명령어로 주키퍼 서버의 상태를 조회한다. 예제에서는 2번 주키퍼 서버가 leader이고 1번, 3번 서버가 follower 인 것을 볼 수 있다.

$ bin/zkServer.sh status conf/zoo3.cfg
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: conf/zoo3.cfg
Client port found: 2183. Client address: 172.24.121.239. Client SSL: false.
Mode: follower

$ bin/zkServer.sh status conf/zoo2.cfg
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: conf/zoo2.cfg
Client port found: 2182. Client address: 172.24.121.239. Client SSL: false.
Mode: leader

$ bin/zkServer.sh status conf/zoo1.cfg
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: conf/zoo1.cfg
Client port found: 2181. Client address: 172.24.121.239. Client SSL: false.
Mode: follower

start the server in the foreground for debugging

주키퍼 서버를 foreground 모드로 실행한다.

bin/zkServer.sh start-foreground conf/zoo1.cfg
bin/zkServer.sh start-foreground conf/zoo2.cfg
bin/zkServer.sh start-foreground conf/zoo3.cfg

stop the server

주키퍼 서버를 중지한다.

bin/zkServer.sh stop conf/zoo1.cfg
bin/zkServer.sh stop conf/zoo2.cfg
bin/zkServer.sh stop conf/zoo3.cfg

restart the server

주키퍼 서버를 재시작한다.

bin/zkServer.sh restart conf/zoo1.cfg
bin/zkServer.sh restart conf/zoo2.cfg
bin/zkServer.sh restart conf/zoo3.cfg

Notes
zk-server1 을 실행하면 Log 상에 2번과 3번 서버로의 통신이 실패했다는 Log를 볼 수 있다. zk-server2 를 실행하면 3 번 서버로의 통신이 실패했다는 Log를 볼 수 있다. 1번과 2번이 실행되었으므로 1번과 2번 모두 3번과 연결할 수 없다는 Log를 확인할 수 있다. 마지막으로 zk-server3 을 실행하면 연결이 모두 되어 동작하는 것을 확인할 수 있다.
zkServer.sh 스크립트는 다양한 명령을 제공한다.

• start
• start-foreground
• stop
• restart
• status
• upgrade
• print-cmd

ZooKeeper CLI Client 사용법

ZooKeeper CLI 는 Command Line 으로 ZooKeeper를 관리할 수 있는 도구로 주키퍼 CLI 문서를 참고한다. 

[ 추가 참고문서 ]

 “How to connect ZooKeeper through CLI?” 와 “Famous Four letter commands” 를 참조하면 된다.

ZooKeeper Commands: The Four Letter Words 수행

nc 나 telnet 로 서비스 port에 4자리 주키퍼 명령어를 보낸다.

아래 ruok 명령어를 주키퍼 서버에 보내는 예제이다.

nc(Netcat)은 TCP/UDP 프로토콜로 연결된 네크워크 상에서 데이터를 읽고 쓸 수 있는 간단한 리눅스 유틸리티이다. 네크워크에 연결된 서버 간의 포트 오픈을 확인할 수 있고, listen 모드로 자신이 서버가 되는 기능을 제공하기도 한다.

$  echo ruok | nc 127.0.0.1 2181
ruok is not executed because it is not in the whitelist.

$ nc 127.0.0.1 2181
ruok
ruok is not executed because it is not in the whitelist.

$ telnet localhost 2181
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ruok
ruok is not executed because it is not in the whitelist.
Connection closed by foreign host.

위 예제에서는 "ruok is not executed because it is not in the whitelist." 메시지가 출력되었는데

환경설정 파일에(zoo1.cfg, zoo2.cfg, zoo3.cfg 또는 zookeeper.properties 파일) 아래 내용을 추가하고 주키퍼 서버를 재기동 하면 정상적인 메시지를 받을 수 있다.

• 4lw.commands.whitelist=*

$  echo ruok | nc 127.0.0.1 2181
imok

$ nc 127.0.0.1 2181
ruok
imok

$ telnet localhost 2181
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ruok
imok

ZooKeeper Cluster를 어플리케이션에서 사용하는 방법

ZooKeeper Cluster 를 이용할 어플리케이션은 ZooKeeper Cluster 구성 후에는 바로 연결할 수 있다.

이 때 필요한 정보는 다음과 같다.

• ZooKeeper Server 의 Host Address / Host IP
• ZooKeeper Server 의 Client Access Port No

기본적인 유지 관리 부분

별다른 작업이 필요한 것은 아니고 다음과 같은 정보를 정리하면 된다.

• 데이터 디렉토리 정리
• 디버그 Log 정리

ZooKeeper는 “autopurge.snapRetainCount” 와 “autopurge.purgeInterval” 과 같은 설정을 통해서 자동으로 정리하는 기능 (Autopurge) 을 제공하고 있다.  “ZooKeeper maintenance” 를 참고하여 적절한 방침과 방법을 수립한다.

성능과 가용성에 대한 검토 사항들

• Ensemble 을 구성하는 서버들의 대부분이 가동되면 ZooKeeper 서비스를 이용할 수 있다. 위에서도 계속 언급을 했지만 절반이 실패하더라도 구성이 가능할 수 있도록 홀 수를 유지하는 것이 중요하다. 예를 들어 짝수로 구성된 4개의 서버 중에서 2개의 서버가 실패하면 나머지 2개의 서버 중에서 1개의 서버는 리더가 되고 1개의 서버가 복제 상태가 되는데 이런 경우는 복제가 실패했을 때 대응을 할 수 없는 상태가 된다. 여기서 리더는 복제 단위가 아니기 때문에 1개 서버 만으로 복제를 운영할 수 없는 상태가 된다.
• ZooKeeper는 오류가 발생하면 프로세스가 종료되는 Fail-Fast 정책으로 운영된다. 따라서 자동으로 복원을 하는 것이 아니기 때문에 관리자의 감독하에서 실행하는 것이 상당히 중요하다. 
• ZooKeeper의 데이터 디렉토리는 Emsemble 에서 처리되는 zNodes 들의 정보 복사본들이 저장된다. 이 파일들은 Snapshot 파일들로 zNodes 들에서 처리된 변경들을 트랜잭션 로드로 추가하며, 때때로 Log들이 커지게 되면 모든 zNode 들의 현재 상태의 Snapshot 들을 파일 시스템에 기록하고 기존의 Log들을 대체한다.
• ZooKeeper의 Transaction Log는 전용 장치에 존재해야 하며, 파티션으로 처리된 전용 공간으로는 충분하지 않다고 명시되어 있다. 즉 ZooKeeper는 Log를 순차적으로 기록하며, 다른 프로세스들과 탐색이 경합이 발생할 수 있는 Log 장치의 공유를 허용하지 않는 것을 원칙으로 해야 한다.
• ZooKeeper 을 Swap이 발생할 수 있는 상황으로 관리하면 안 된다. ZooKeeper가 기능을 제대로 발휘할 수 있도록 하기 위해서는 Swap 발생을 미리 차단해 놓아야 한다. 예를 들어 ZooKeeper가 사용할 수 있는 Heap Size를 물리적인 사용 가능 메모리보다 크게 지정하면 나중에 메모리 Swap이 발생하므로 이런 설정은 피해야 한다. 이와 같은 피해야 할 부분들은 여기를 참고하면 된다.

아파치 주키퍼란?

ZooKeeper는 분산 애플리케이션의 구성 정보를 유지.관리하고, 이름을 지정하고, 분산 동기화를 하고, 그룹 서비스를 제공하는 서비스입니다. 디렉토리 트리 구조의 데이터 모델을 사용합니다.

ZooKeeper는 표준 파일 시스템과 유사하게 구성된 계층적 공유 네임스페이스를 통해 분산 프로세스를 조정할 수 있습니다. 네임스페이스는 znodes라고 하는 데이터 레지스터로 구성되며 파일 및 디렉토리와 유사합니다. 저장용으로 설계된 일반적인 파일 시스템과 달리 ZooKeeper 데이터는 메모리에 보관됩니다.
분산 프로세스와 마찬가지로 ZooKeeper 자체도 앙상블이라는 호스트 집합을 통해 복제되도록 되어 있습니다.

ZooKeeper 서비스를 구성하는 서버는 모두 서로의 상태에 대해 알고 있어야 하므로 영구 저장소의 트랜잭션 로그 및 스냅샷과 함께 메모리 내 상태 이미지를 유지 관리합니다. 
클라이언트는 단일 ZooKeeper 서버에 연결합니다. 클라이언트는 요청을 보내고, 응답을 받고, 감시 이벤트를 받고, heart bit을 보내는 TCP 연결을 유지 관리합니다. 서버에 대한 TCP 연결이 끊어지면 클라이언트는 다른 서버에 연결합니다.

ZooKeeper는 트랜잭션의 순서를 반영하는 번호로 순서를 유지합니다. 

데이터 모델 및 계층적 네임스페이스

ZooKeeper에서 제공하는 네임스페이스는 표준 파일 시스템과 매우 유사합니다. 이름은 슬래시(/)로 구분된 경로 입니다. ZooKeeper의 네임스페이스에 있는 모든 노드는 경로로 식별됩니다.

계층적 네임스페이스

노드 및 임시 노드
표준 파일 시스템과 달리 ZooKeeper 네임스페이스의 각 노드는 자식뿐만 아니라 연결된 데이터를 가질 수 있습니다. ZooKeeper는 상태 정보, 구성, 위치 정보 등의 조정 데이터를 저장하도록 설계되었으므로 각 노드에 저장된 데이터는 일반적으로 바이트에서 킬로바이트로 작습니다.  ZooKeeper 데이터 노드를 znode라고 합니다.

Znode는 데이터 변경, ACL 변경 및 타임스탬프에 대한 버전 번호를 포함하는 통계 구조를 유지하여 캐시 유효성 검사 및 조정된 업데이트를 허용합니다. znode의 데이터가 변경될 때마다 버전 번호가 증가합니다. 예를 들어 클라이언트가 데이터를 검색할 때마다 데이터 버전도 받습니다.
각 노드에는 누가 무엇을 할 수 있는지를 제한하는 ACL(액세스 제어 목록)이 있습니다.

ZooKeeper에는 임시 노드 개념도 있습니다. 이러한 임시 znode는 znode를 생성한 세션이 활성 상태일 떄만 존재합니다. 세션이 종료되면 znode가 삭제됩니다.

조건부 업데이트 및 감시
클라이언트는 znode에서 감시를 설정할 수 있습니다. znode가 변경되면 watch가 트리거되고 제거됩니다. watch가 트리거되면 클라이언트는 znode가 변경되었다는 패킷을 수신합니다. 클라이언트와 ZooKeeper 서버 중 하나 간의 연결이 끊어지면 클라이언트는 로컬 알림을 받습니다.

3.6.0의 새로운 기능: 클라이언트는 트리거될 때 제거되지 않고 등록된 znode 및 모든 자식 znode에 대한 변경을 재귀적으로 트리거하는 znode에 영구적이고 재귀적인 감시를 설정할 수 있습니다.

보증

• 순차 일관성 - 클라이언트의 업데이트는 전송된 순서대로 적용됩니다.
• 원자성 - 업데이트가 성공하거나 실패합니다. 
• 단일 시스템 이미지 - 클라이언트는 연결하는 서버에 관계없이 동일한 서비스 보기를 볼 수 있습니다. 
• 안정성 - 업데이트가 적용된 후에는 클라이언트가 업데이트를 덮어쓸 때까지 계속 유지됩니다.
• 적시성 - 시스템에 대한 클라이언트 보기는 특정 시간 범위 내에서 최신 상태로 유지되도록 보장됩니다.

Simple API

ZooKeeper는 간결한 프로그래밍 인터페이스를 제공합니다.

• create : 트리의 한 위치에 노드를 생성합니다.
• delete : 노드를 삭제
• exists : 노드가 위치에 존재하는지 테스트
• get data : 노드에서 데이터를 읽습니다.
• set data : 노드에 데이터를 씁니다.
• get children : 노드의 자식 목록을 검색합니다.
• sync : 데이터가 전파될 때까지 기다립니다.

Implementation

ZooKeeper 서비스를 구성하는 각 서버는 요청 프로세서를 제외하고 각 구성 요소를 복제합니다.

복제된 데이터베이스는 전체 데이터 트리를 포함하는 메모리 내 데이터베이스입니다. 업데이트는 복구를 위해 디스크에 기록하고 데이터 쓰기는 메모리 내 데이터베이스에 적용되기 전에 디스크에 씁니다.
모든 ZooKeeper 서버는 클라이언트에 서비스를 제공합니다. 클라이언트는 하나의 서버에 연결하여 요청을 합니다. 읽기 요청은 각 서버 데이터베이스의 로컬 복제본에서 처리됩니다. 서비스 상태를 변경하는 요청인 쓰기 요청은 agreement protoco에 의해 처리됩니다.

클라이언트의 모든 쓰기 요청은 리더로 전달됩니다. 팔로워라고 하는 나머지 ZooKeeper 서버는 리더로부터 메시지 제안을 수신하고 메시지 전달에 동의합니다. 메시징 계층은 실패 시 리더를 교체하고 팔로어를 리더와 동기화하는 작업을 처리합니다.

ZooKeeper는 맞춤형 원자 메시징 프로토콜을 사용합니다. 메시징 계층은 원자성이므로 ZooKeeper는 로컬 복제본이 절대 분기되지 않도록 보장할 수 있습니다. 리더는 쓰기 요청을 받으면 쓰기가 적용될 때 시스템의 상태를 계산하고 이를 이 새로운 상태를 캡처하는 트랜잭션으로 변환합니다.

Uses

ZooKeeper에 대한 프로그래밍 인터페이스는 간단하지만 이를 사용하여 동기화, 그룹 구성원 자격, 소유권 등과 같은 고차원 작업을 구현할 수 있습니다.

주키퍼를 단독으로 구성할 수도 있지만, 주키퍼를 클러스터로 구성하여 고가용성을 확보한 것을 주키퍼 앙상블(Zookeeper Ensemble)이라고 한다.

주키퍼 서버는 홀수로 구성하는 것을 권고하고 있기 때문에 3대로 구성하려고 합니다. 홀수로 구성하는 이유는 예를 들어서 4대로 구성을 했을 때 결함에 대한 장애 대비 기능(failover)가 3대로 구성한 것과 동일합니다.

하나의 OS에서 3개의 주키퍼를 구성합니다.

카프카 브로커에서 브로커와 토픽의 메타데이터를 저장하기 위해 주키퍼를 사용합니다.

주키퍼 설치하기

$ wget http://apache.mirror.cdnetworks.com/zookeeper/stable/apache-zookeeper-3.6.3-bin.tar.gz
$ tar xzvf apache-zookeeper-3.6.3-bin.tar.gz
$ ln -s apache-zookeeper-3.6.3-bin zookeeper

바이너리 버전(apache-zookeeper-3.5.5-bin.tar.gz)과 소스 버전(apache-zookeeper-3.5.5.tar.gz)이 있는데 바이너리 버전으로 다운로드합니다.

주키퍼는 별도의 데이터 디렉토리를 사용합니다.
이 디렉토리에는 지노드의 복사본인 스냅샷과 트랜잭션 로그들이 저장됩니다.

주키퍼의 지노드는 데이터를 저장하기 위한 공간이고 상태정보. 글로벌락, 동기화, 리더채택, 설정관리 등의 정보를 Key-Value 형태로 저장합니다.

1. 지노드의 변경사항이 발생하면, 변경사항은 트랜잭션 로그에 추가
2. 로그가 어느 정도 커지면, 현재 모든 지노드의 상태 스냅샷이 파일시스템에 저장

1. 주키퍼 환경설정 - single 노드

모든 설정 작업은 주키퍼 설치 디렉토리 "apache-zookeeper-3.6.3-bin" 에서 수행합니다.

1.1 zookeeper 환경설정

data 디렉토리 생성

data 디렉토리로 /zkdata 를 생성하고 log 디렉토리를 위해 /zkdatalog 디렉토리를 생성합니다. 디렉토리명 또는 파일시스템명은 사용자가 원하는 이름으로 생성합니다.

$ mkdir -p /zkdata
$ mkdir -p /zkdatalog

zoo.cfg 파일 설정

주키퍼 환경설정 sample 파일을 zoo.cfg 파일로 복사하고 내용을 수정합니다.

cp conf/zoo_sample.cfg conf/zoo.cfg
vi conf/zoo.cfg

아래와 같이 dataDir를 위에서 생성한 디렉토리명으로 수정합니다.

## zoo.cfg 파일

dataDir=/zkdata
dataLogDir=/zkdatalog

1.2 zookeeper 실행

주키퍼 서버를 standalone 모드로 실행합니다.

conf/zoo.cfg 인자를 입력하지 않아도 default로 zoo.cfg 환경파일로 주키퍼를 실행합니다.

$ bin/zkServer.sh start conf/zoo.cfg

아래와 같은 실행결과가 화면에 표시되면 정상입니다.

ZooKeeper JMX enabled by default
Using config: /apach/zookeeper/bin/../conf/zoo.cfg
Starting zookeeper ... STARTED

주키퍼 서버 port가 LISTEN 상태인지 확인합니다.

$ netstat -an | grep 2181
tcp6       0      0 :::2181                 :::*                    LISTEN

1.3 zookeeper 접속

아래 명령어로 로컬 ZooKeeper 서버에 접속합니다.

bin/zkCli.sh -server 127.0.0.1:2181

아래와 같이 CONNECTED 프롬프트가 나오면 정상입니다.

Connecting to 127.0.0.1:2181
...
...
[zk: 127.0.0.1:2181(CONNECTED) 0]

혹시, 

WATCHER::

WatchedEvent state:SyncConnected type:None path:null

메시지 상태에 멈추어 있으면 엔터키를 칩니다.

zookeeper 명령 프롬프트에서 help 명령어를 입력하면 사용할 수 있는 명령어들이 표시됩니다.

[zk: 127.0.0.1:2181(CONNECTED) 0] help
ZooKeeper -server host:port cmd args
    stat path [watch]
    set path data [version]
...  ...
    close
    connect host:port

zookeeper 명령창에서 version 을 입력하고 엔터를 치면 version 정보를 확인할 수 있습니다.

[zk: 127.0.0.1:2181(CONNECTED) 2] version
ZooKeeper CLI version: 3.6.3--6401e4ad2087061bc6b9f80dec2d69f2e3c8660a, built on 04/08/2021 16:35 GMT

ls 명령어로 zookeeper znode를 조회합니다. 

[zk: 127.0.0.1:2181(CONNECTED) 2] ls /
[zookeeper]

[zk: 127.0.0.1:2181(CONNECTED) 2] ls /zookeeper
[config, quota]

quit명령어로 zookeeper 명령창을 종료합니다.

[zk: 127.0.0.1:2181(CONNECTED) 2] quit

1.4 zookeeper 서비스 종료

아래 명령어로 ZooKeeper 서비스를 종료합니다. 

bin/zkServer.sh stop conf/zoo.cfg

1.5. Zookeeper 시스템 서비스 파일 생성

systemd 서비스를 이용해서 시작/종료를 할 수 있도록 서비스 파일을 생성합니다. 단, WSL 에서는 등록이 안됩니다(There is lack of support in WSL for systemd).

아래 명령어로 시스템 서비스 파일을 편집합니다.

sudo vi /etc/systemd/system/zk.service

아래 내용을 입력합니다.

[Unit]
Description=Zookeeper Daemon
Documentation=http://zookeeper.apache.org
Requires=network.target
After=network.target

[Service]    
Type=forking
WorkingDirectory=/opt/zookeeper
User=zk
Group=zk
ExecStart=/opt/zookeeper/bin/zkServer.sh start /opt/zookeeper/conf/zoo.cfg
ExecStop=/opt/zookeeper/bin/zkServer.sh stop /opt/zookeeper/conf/zoo.cfg
ExecReload=/opt/zookeeper/bin/zkServer.sh restart /opt/zookeeper/conf/zoo.cfg
TimeoutSec=30
Restart=on-failure

[Install]
WantedBy=default.target

이제 다음 명령어로 ZooKeeper를 실행해 봅니다.

sudo systemctl start zk

아래 명령으로 정상적으로 실행 중인지 확인 합니다.

sudo systemctl status zk

정상적으로 실행이 되면, 시스템이 부팅 시에도 자동으로 실행되도록 아래와 같이 등록해 줍니다.

sudo systemctl enable zk

다음 명령으로 서비스를 종료합니다.

sudo systemctl stop zk

2. 주키퍼 환경설정 - 멀티노드 

2.1 zookeeper 환경설정

data 디렉토리 생성

$ mkdir -p /zkdata1
$ mkdir -p /zkdatalog1
$ mkdir -p /zkdata2
$ mkdir -p /zkdatalog2
$ mkdir -p /zkdata3
$ mkdir -p /zkdatalog3

멀티 노드 설정입니다. ZooKeeper 는 홀수대의 노드로 구성을 해야 하므로, 3대 혹은 5대와 같이 구성을 합니다. 여기서는 3대 구성을 설명합니다.아래 명령어로 설정파일을 편집합니다.

본 문서는 3개의 zookeeper 서버 구성을 위해 각가의 디렉토리를 만듭니다.

모든 설정 작업은 주키퍼 설치 디렉토리 "apache-zookeeper-3.6.3-bin" 에서 수행합니다.

$ cp conf/zoo_sample.cfg conf/zoo1.cfg
$ cp conf/zoo_sample.cfg conf/zoo2.cfg
$ cp conf/zoo_sample.cfg conf/zoo3.cfg

vi conf/zoo1.cfg

아래 내용을 입력합니다. zoo1.cfg 입니다. 다른 2개의 cfg 파일도 동일하게 작성합니다. 단, dataDir, dataLogDir 및 clientPort는 각 서버에 맞게 작성합니다. 본 문서에서는 한 대의 서버에 3개의 zookeeper 서버를 구성하는 예이므로 port 및 directory 경로를 상이하게 설정했습니다. 물리적으로 분리된 서버를 별도로 구성할 경우 동일한 경로와 port로 설정할 수 있습니다.

## zoo1.cfg 파일

## datdaDir 은 각각의 서버에 맞게 설정하는데 
dataDir=/zkdata1
dataLogDir=/zkdatalog1
clientPort=2181

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

• dataDir : 주키퍼의 스냅샷이 저장되는 경로
• dataLogDir : 주키퍼의 트랜잭션가 저장되는경로
• clientPort : Client 접속 포트
• server.myid : 주키퍼 앙상블 구성을 위한 서버 설정, server.myid 형식으로 사용. 2888 : 서버 노드끼리 통신을 위해 사용, 3888 리더 선출을 위해 사용

zoo2.cfg 파일 예제입니다.

## zoo2.cfg 파일

## datdaDir 은 각각의 서버에 맞게 설정하는데 
dataDir=/zkdata2
dataLogDir=/zkdatalog2
clientPort=2182

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

zoo3.cfg 파일 예제입니다.

## zoo3.cfg 파일

## datdaDir 은 각각의 서버에 맞게 설정하는데 
dataDir=/zkdata3
dataLogDir=/zkdatalog3
clientPort=2183

server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890

설정이 완료되면 각각의 노드의 dataDir 디렉토리에 myid 라는 파일을 생성하고 각각의 파일에 1, 2, 3 과 같이 입력해 줍니다.

아래와 같이 각각의 노드에 따라 숫자를 입력하고 저장합니다.

1번째 노드 

sudo vi /zkdata1/myid
1

2번째 노드 

sudo vi /zkdata2/myid
2

3번째 노드 

sudo vi /zkdata3/myid
3

2.2 zookeeper 실행

주키퍼 서버를 앙상블(멀티노드) 모드로 실행합니다.

$ bin/zkServer.sh start conf/zoo1.cfg
$ bin/zkServer.sh start conf/zoo2.cfg
$ bin/zkServer.sh start conf/zoo3.cfg

아래와 같은 실행결과가 화면에 표시되면 정상입니다.

$ bin/zkServer.sh start  conf/zoo1.cfg
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: conf/zoo1.cfg
Starting zookeeper ... STARTED

$ bin/zkServer.sh start  conf/zoo2.cfg
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: conf/zoo2.cfg
Starting zookeeper ... STARTED

r$ bin/zkServer.sh start  conf/zoo3.cfg
/usr/bin/java
ZooKeeper JMX enabled by default
Using config: conf/zoo3.cfg
Starting zookeeper ... STARTED

주키퍼 서버 port가 LISTEN 상태인지 확인합니다.

$ netstat -an | egrep "2181|2182|2183"
tcp6       0      0 :::2181                 :::*                    LISTEN
tcp6       0      0 :::2182                 :::*                    LISTEN
tcp6       0      0 :::2183                 :::*                    LISTEN

2.3 zookeeper 접속

아래 명령어로 로컬 ZooKeeper 서버에 접속합니다.

bin/zkCli.sh -server 127.0.0.1:2181

아래와 같이 CONNECTED 프롬프트가 나오면 정상입니다.

Connecting to 127.0.0.1:2181
...
...
[zk: 127.0.0.1:2181(CONNECTED) 0]

혹시, 

WATCHER::

WatchedEvent state:SyncConnected type:None path:null

메시지 상태에 멈추어 있으면 엔터키를 칩니다.

zookeeper 명령 프롬프트에서 help 명령어를 입력하면 사용할 수 있는 명령어들이 표시됩니다.

[zk: 127.0.0.1:2181(CONNECTED) 0] help
ZooKeeper -server host:port cmd args
    stat path [watch]
    set path data [version]
...  ...
    close
    connect host:port

노드 1에서 아래 명령을 입력합니다.

[zkshell:] create /zk_znode_1 sample_data

노드 1에서 다음 명령으로 생성된 내용을 확인해 봅니다.

[zkshell: ] get /zk_znode_1

다른 터미널 창에서 노드 2에서 접속하여 노드 1에서 생성한 데이터를 조회합니다.

$ bin/zkCli.sh -server 127.0.0.1:2182

[zkshell: ] get /zk_znode_1
sample_data

노드 1, 노드 2 양쪽 모두 동일한 결과가 나와서 동기화가 되는 것을 확인하면 정상입니다.

아래 명령으로 znode를 삭제해 줍니다.

[zkshell: ] delete /zk_znode_1

quit명령어로 zookeeper 명령창을 종료합니다.

[zk: 127.0.0.1:2181(CONNECTED) 2] quit

* 참고로, 아파치 broker 서버가 기동되면 zookeeper에서 생성한 zookeeper znode를 제외한 많은 수의 znode들이 생성된다. [admin, brokers, cluster, config, consumers, controller, controller_epoch, feature, isr_change_notification, latest_producer_id_block, log_dir_event_notification, zookeeper]

2.4 zookeeper 서비스 종료

아래 명령어로 ZooKeeper 서비스를 종료합니다. 

bin/zkServer.sh stop conf/zoo1.cfg
bin/zkServer.sh stop conf/zoo2.cfg
bin/zkServer.sh stop conf/zoo3.cfg

The Complete Event Streaming Platform for Apache Kafka®

 

데이터량이 급격히 증가하면서 빅데이터 처리 기술이 매우 중요해졌습니다.
기존의 데이터 처리방식은 시스템 A가 데이터를 DB나 파일에 저장하면, 다른 시스템 B,C,D가 그 파일을 읽는 순서 였지만
전송속도 증가와 빅데이터 처리기술의 고도화로 파일 저장과 동시에 읽을수 있게 되었으며,
이런 기술을 "이벤트 스트리밍" 서비스라고 부릅니다..

 

기존 정지되어 있는 데이터(Relational DB)가 움직이는 데이터(Event Streaming)로 바뀌고
Static, Slow, Batch Processing이 Realtime Event Processing 으로 바뀌고 있습니다.

 

 

 

 

아파치 카프카

 

아파치 카프카는 'LinkedIn'에서 개발 후 2010년 오픈소스화한 "이벤트 스트리밍 플랫폼"이며,
특정한 이벤트 전송통로(파이프라인)를 통해 여러 시스템간의 연결을 통합,관리하는 프로그램 입니다.

 

즉, 이벤트 전송(Pubilsh & Subscribe), 이벤트 저장, 이벤트 처리분석 등 대량의 데이터를 분산관리하는 시스템입니다.
높은 처리량(High throughput), 낮은 지연(Low latency), 실시간처리(realtime processing) 가 장점입니다.

 

 

컨플루언트 플랫폼 주요 기능

 

컨플루언트는 아파치 카프카의 창시자들에 의해 만들어진 Event streaming 솔루션이며,
리스크 제거, Time to market 가속화 등 아파치 카프카를 기업용으로 확장한 소프트웨어 입니다.

개발자 측면

Java 뿐 아니라 다양한 랭귀지(C, .Net, Python)로 개발 가능하며,
REST Proxy 통해 모든 어플리케이션 연결과 MQTT Proxy 통해 IoT 데이터 소스 연결이 가능합니다.
100+ Pre-built Connectors 이용 가능하고, 표준 Schema 통한 개발로 운영 복잡성을 제거했습니다.
익숙한 SQL Syntax (ksqlDB) 사용하여 개발이 용이하고, 아키텍처를 단순화 시켰습니다.

운영자 측면

GUI 기반의 Confluent Control Center 제공하여 중앙에서 전체 모니터링 및 운영관리가 가능합니다.
kubernates 위에 설치가 가능하고 ansible playbooks 등 DevOps 를 통한 운영 자동화를 제공됩니다.
Auto Data Balancer로 전체 브로커들의 처리량을 dynamic하게 최적화하고,
Tier Storage 통한 스토리지 비용 효율화를 제공합니다.

아키텍트 측면

Role based Access Control, Secret Protection 등 기밀 및 규정을 준수합니다.
Replicator를 통한 Multi-region 클러스터로 단순화된 재해복구체계 구현하여 빠른 복구가 가능합니다.

 

 

 

 

 

Confluent Connectors

 

컨플루언트는 100개 이상의 데이터 소스와 즉시 연결 가능한 커넥터를 제공합니다

https://www.confluent.io/hub

UI for Apache Kafka is a free, open-source web UI
to monitor and manage Apache Kafka clusters.

Apache Kafka용 UI는 Apache Kafka 클러스터를 모니터링하고 관리하기 위한 무료 오픈 소스 웹 UI입니다.
대시보드를 사용하면 브로커, 주제, 파티션, consumer와 같은 Kafka 클러스터의 메트릭을 추적할 수 있습니다.
Apache Kafka용 UI는 Kafka 데이터를 시각화합니다. 로컬 또는 클라우드에서 실행할 수 있습니다.

특징

• 다중 클러스터 관리 — 모든 클러스터를 한 곳에서 모니터링 및 관리
  
• 메트릭 대시보드를 통한 성능 모니터링 — 대시보드로 주요 Kafka 메트릭 추적
  
• Kafka Broker 보기 — 주제 및 파티션 할당, 컨트롤러 상태 보기
  
• Kafka 주제 보기 — 파티션 수, 복제 상태 및 사용자 정의 구성 보기
  
• 소비자 그룹 보기 — 파티션별 고정 오프셋, 결합 및 파티션별 지연 보기
  
• 메시지 찾아보기 — JSON, 일반 텍스트 및 Avro 인코딩으로 메시지 찾아보기
  
• 동적 주제 구성 — 동적 구성으로 새 주제 생성 및 구성
  
• 구성 가능한 인증 — Github/Gitlab/Google OAuth 2.0(옵션)으로 설치 보안

시작하기

Apache Kafka용 UI를 실행하려면 사전 빌드된 Docker 이미지를 사용하거나 로컬에 빌드할 수 있습니다.

[ 수행환경 ]

- Microsoft Windows 10 Pro(10.0.19041 N/A 빌드 19041)

- WSL 2

- zookeeper : 3.6.3

- kafka broker : 

Docker Image 실행

Apache Kafka용 UI의 공식 Docker 이미지는 다음 위치에서 호스팅됩니다.hub.docker.com/r/provectuslabs/kafka-ui.
백그라운드에서 Docker 컨테이너를 시작합니다.

docker run -p 8080:8080 \
	-e KAFKA_CLUSTERS_0_NAME=local \
	-e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=kafka:9092 \
	-d provectuslabs/kafka-ui:latest

http://localhost:8080.에서 웹 UI에 접속합니다.
환경 변수를 사용한 추가 구성은 환경 변수 참조합니다.- see environment variables

위와 같이 환경변수를 설정했을 때, 카프카 UI 접속 시 UI 화면은 보이지만, borker, topic 등에 대한 정보가 정상적으로 보이지 않았습니다. 그래서 2가지를 수정했는데, 수정 후 재기동 하니 정상적으로 보였습니다.

첫번 째 수정한 부분

카프카 브로커의 server.properties 에서 listeners 내용을 수정했습니다. 

기존 0.0.0.0 에서 WSL 의 IP Address로 변경했습니다. 수정 후 카프카 브로커를 재기동합니다.

# listeners=PLAINTEXT://0.0.0.0:9092

## 아래처럼 WSL IP Address로 수정
listeners=PLAINTEXT://172.24.121.239:9092

두번 째 수정한 부분

카프카 UI 의 환경변수 중 KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=0.0.0.0:9092 부분을 KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=172.24.118.82:9093 로 수정했습니다. 여기서의 IP는 WSL 의 IP 이자 카프카 브로커에서 설정한 listeners IP와 동일한 IP 입니다. 

수정 후 실행된 컨테이너가 있으면 중지시키고 카프카 UI 컨테이너를 실행합니다.

여기에서 8080 port가 사용 중이라고 나올 경우, 카프카 브로커에서 admin port를 사용할 가능성이 크므로 카프카 브로커의 admin port를 변경하던지, UI 컨테이너의 앞 쪽 port를 변경합니다. 필자의 경우에 port 충돌이 발생해서 카프카 브로커의 admin port를 disable 시켰습니다.

docker run -p 8080:8080 \
	-e KAFKA_CLUSTERS_0_NAME=local \
	-e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=172.24.118.82:9092 \
	-d provectuslabs/kafka-ui:latest

[ 참고 ]

필자의 경우에는 zookeeper cluster와도 연동되어 있고 podman을 사용해서 아래와 같이 수행했습니다. 주키퍼를 사용하는 경우 참고하면 될 것 같습니다.

podman run -p 8080:8080 --name ui_kafka --rm \
	-e KAFKA_CLUSTERS_0_NAME=local \
	-e KAFKA_CLUSTERS_0_ZOOKEEPER=172.24.118.82:2181,172.24.118.82:2182,172.24.118.82:2183 \
	-e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=172.24.118.82:9093,172.24.118.82:9094,172.24.118.82:9095 \
	-d provectuslabs/kafka-ui:latest

위 사항을 수정한 후 UI for Apache Kafka 에 접속한 화면입니다. clusters, Brokers, Topics 등에 대한 정보가 잘 표시됩니다.

Topic을 하나 생성한 후 카프카 브로커에서 조회해 봅니다. topic 이름은 ui_topic 이름으로 설정하고 partitions은 3, Replication Factor도 3으로 설정한 후 생성했습니다.

카프카 브로커 명령어로 topic을 조회해 봅니다. 3대 모두 정상적으로 조회가 되고 있습니다.

$ bin/kafka-topics.sh --list --bootstrap-server 172.24.118.82:9092
ui_topic
$ bin/kafka-topics.sh --list --bootstrap-server 172.24.118.82:9093
ui_topic
$ bin/kafka-topics.sh --list --bootstrap-server 172.24.118.82:9094
ui_topic

카프카 브로커 명령어로 topic을 생성한 후 UI 화면으로 조회해 봅니다.

$ bin/kafka-topics.sh create --topic my-kafka-topic --bootstrap-server 172.24.118.82:9092 --part
itions 3 --replication-factor 3

Created topic my-kafka-topic.

아래 화면처럼 정상적으로 조회됩니다.

참고 : UI for Apache kafka 환경변수

yml 파일의 각 변수를 환경 변수로 설정할 수 있습니다. 예를 들어 환경 변수를 사용하여 name 매개변수를 설정하려면 KAFKA_CLUSTERS_2_NAME과 같이 작성할 수 있습니다.

What are the best tools engineers can use to observe data flows, track key metrics, and troubleshoot issues in Apache Kafka?

Apache Kafka is an open-source distributed event streaming platform that enables organizations to implement and handle high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. It is used by thousands of companies, 80% of which are Fortune 100 companies.

Though Apache Kafka is the go-to service for scenarios requiring real-time data processing and application activity tracking, the monitoring and management of clusters in Apache Kafka often pose a challenge. To make these tasks more efficient and transparent, you may need third-party, open-source, or commercial graphical tools that offer additional administrative and monitoring features.

This article provides an overview of such UI tools, including:

1. AKHQ
2. Kowl
3. Kafdrop
4. UI for Apache Kafka
5. Lenses
6. CMAK
7. Confluent CC
8. Conduktor

But first, let’s delve a bit into the problems of observability and monitoring in Apache Kafka.

Observability and Monitoring in Apache Kafka

Apache Kafka is a critical service for any data-driven organization. But handling vanilla Apache Kafka clusters can be quite painful. Kafka clusters are difficult to set up, tricky to scale, and expensive to maintain. Most importantly, they are error-prone and complicated to observe, which may cause various business-critical issues in data streams and prevent engineers from tracking and solving them.

To reduce errors and avoid critical issues, it is important for organizations to foolproof their Apache Kafka clusters by adding a robust observability component. Better observability can help to:

• Troubleshoot data streams much faster
• Improve collaboration among engineers by having a shared understanding of the data streams they manage through metadata.
• Discover sensitive data within data streams more easily, to meet compliance requirements.
• Clean data more quickly and efficiently. Fewer incorrect dashboards mean happier customers.

The challenge with cluster observability is that Apache Kafka comes with CLI tools for all necessary administrative tasks. But because they are not integrated into a single service, you have to run different tools separately for different tasks, which causes inconvenience and time loss. The problem can escalate quickly as your clusters grow in size, or if you have multiple clusters, simply because you lack the ability to properly observe them.

This brings us back to UI monitoring tools that can help organizations simplify and accelerate development, minimize time to resolution, and speed up the reporting process, to improve operational efficiency within and between engineering teams.

Top 8 UI Monitoring Tools for Apache Kafka Clusters

To begin with, a quick comparison of the Apache Kafka cluster monitoring tools.

 

Image by Author

AKHQ

• GitHub: https://github.com/tchiotludo/akhq
• License: Apache 2
• Availability: Free
• Pros: A lot of useful features
• Cons: Bad UI; Lacks KSQL integration; Partial support of Protobuf schema registry

AKHQ (previously known as KafkaHQ) is a Kafka GUI for Apache Kafka that gives engineering teams the ability to search and explore data in a unified console. With AKHQ, developers and DevOps can manage topics, topic data, consumer groups, schema registry, connectivity, and more.

 

Image by Author

AKHQ offers tons of useful features, including multi-cluster management, message browsing, live tailing, authentication, authorization, read-only mode, schema registry, and Kafka Connect management. It supports Avro and is compatible with LDAP and RBAC.

But AKHQ’s UI is not the most convenient. You will definitely need to allocate some time to scale the learning curve.

On top of that, AKHQ does not have KSQL integration and provides only partial support of the Protobuf schema registry. Nor does it work with Dynamic Topic Configuration, Partition Increase, Replica Change, Kafka Streams Topologies, or JMX metrics visualization and charts.

Those who are looking to use AKHQ as part of their data streaming solutions on AWS should know that it does not support AWS Identity and Access Management (IAM) Access Control for Amazon MSK.

Kowl

• GitHub: https://github.com/cloudhut/kowl
• License: Apache 2
• Availability: Partially paid
• Pros: Good UI
• Cons: Lacks many features

Kowl (previously known as Kafka Owl) is a web application designed to help developers explore messages in Apache Kafka clusters and gain better insights into what is actually happening in these clusters.

 

Image by Author

The biggest advantage of Kowl is its fantastic UI. It is convenient, user-friendly, and quite straightforward to use. It does not come with a lot of features, though.

For instance, Kowl offers message browsing, live tailing, and support of Protobuf, Avro, and Amazon MSK IAM, but login system (Google, GitHub, Okta) and RBAC permissions with group syncing is available only with a paid Kowl Business plan.

Kowl is also missing such features as multi-cluster management, dynamic topic configuration, partition increase, replica change, Kafka Connect management, schema registry, KSQL integration, Kafka Streams topologies, read-only mode, and visualization and charts for JMX metrics. If these were included in the package, Kowl would be preferable to any other tool.

Kafdrop

• GitHub: https://github.com/obsidiandynamics/kafdrop
• License: Apache 2
• Availability: Free
• Pros: Nice community
• Cons: Average UI; Lacks a lot of features

Kafdrop is a web UI for viewing Apache Kafka topics and browsing consumer groups. The tool enables developers to more easily display and handle cluster information such as brokers, topics, partitions, and consumers. It also allows for viewing messages.

 

Image by Author

For the most part, Kafdrop is a pretty average tool. Its UI is not spectacular, and it lacks a lot of features. It does allow you to view Kafka brokers and consumer groups, create and view topics, browse messages, and monitor ACLs. It also provides support for Azure Event Hubs. But what about other useful features like live tailing, schema registry, or read-only mode?

The good news is that Kafdrop is highly rated on GitHub, and if you are looking for a helpful and immersive community, this may well be the tool for you.

UI for Apache Kafka

• GitHub: https://github.com/provectus/kafka-ui
• License: Apache 2
• Availability: Free
• Pros: Good UI; Flexible; Lots of features
• Cons: Development in progress

UI for Apache Kafka is a free open-source web service that offers developers a clear UI for handling Apache Kafka clusters. It enables developers to monitor data flows and find and troubleshoot issues in data while delivering optimal performance. The lightweight dashboard makes it easy to keep track of key metrics of Apache Kafka clusters, including Brokers, Topics, Partitions, Production, and Consumption.

 

Image by Author

UI for Apache Kafka stands out from the crowd thanks to its convenient UI, free availability, and sheer number of features. It boasts such capabilities as:

• Browse Messages — browse messages with Avro, Protobuf, JSON, and plain text encoding
• View Consumer Groups — view per-partition parked offsets, and combined and per-partition lag
• Configurable Authentification — secure your installation with optional Github/Gitlab/Google OAuth 2.0
• View Kafka Brokers — view topic and partition assignments, and controller status
• View Kafka Topics — view partition count, replication status, and custom configuration
• Multi-Cluster Management — monitor and manage all your clusters in one place
• Dynamic Topic Configuration — create and configure new topics with dynamic configuration

Provectus, the AI consultancy that is designing and building the tool, claims that it will add more features, including live tailing, KSQL integration, Kafka Streams topologies, and JMX metrics visualization and charts, as early as the end of August.

Lenses

• GitHub: https://github.com/lensesio
• License: BSL
• Availability: Free
• Pros: Awesome with fast-kafka-dev and for local development
• Cons: Lacks many features

Lenses positions itself as a DataOps platform for real-time applications and data operations for Apache Kafka and Kubernetes. It can help engineers make data more usable and secure, and eliminate data silos. Lenses appear to be the highest-rated product for real-time stream analytics.

But Lenses is arguably a fairly average tool. It makes perfect sense to use Lenses with fast-kafka-dev. It is also good for local development. However, it lacks certain features; multi-cluster management, message browsing, and avro support are simply not enough to make it work for many tasks. Offering Kafka Connect management as a separate service does not help, either.

 

Image by Author

But if you are content without a lot of features, Lenses’s UI will absolutely fit the bill. It is a truly stunning tool that is very sleek and intuitive.

CMAK

• GitHub: https://github.com/yahoo/CMAK
• License: Apache 2
• Availability: Free
• Pros: Great for partition reassignment; Ops tool
• Cons: Limited to Ops tasks

CMAK (previously known as Kafka Manager) is a comprehensive tool that enables engineers to manage Apache Kafka clusters for various Ops tasks.

 

Image by Author

CMAK boasts a good and fairly straightforward UI. Though it does not provide a lot of features, multi-cluster management, dynamic topic configuration, partition creation, and replica change will cover most of your tasks.

For the most part, CMAK is primarily an Ops tool. It is also really good at partition reassignment.

Confluent CC

• GitHub: https://github.com/confluentinc
• License: Paid
• Availability: Paid
• Pros: Part of Confluent Enterprise
• Cons: Part of Confluent Enterprise

Confluent Control Center is a web-based user interface that allows developers and operators to manage and monitor Apache Kafka clusters, including checking cluster health, observing and controlling messages, topics, and Schema Registry. It can also be used to develop and run ksqlDB queries.

The important thing about Confluent CC is that it is offered as part of Confluent Enterprise, meaning it is a paid service only. It comes with lots of features and a really good user interface. If you don’t mind being locked into the Confluent ecosystem, this UI tool will more than meet your needs.

Overall, Confluent CCS is more than just an ordinary topic checking tool. Its features are superb, and all of them work perfectly, without any glitches.

Conduktor

• GitHub: https://github.com/conduktor
• License: Paid
• Availability: Paid
• Pros: Tons of features
• Cons: Desktop tool

Conduktor is a desktop client for Apache Kafka that provides engineers with a user-friendly interface to work with the Kafka ecosystem. The client is native to Windows, Linux, and Mac. It can handle any type of Apache Kafka cluster and boasts every feature you could ask for.

Image by Author

But Conduktor may not be as convenient as other UI tools in this list, because it is a desktop application. If you are OK with that, Conduktor can be a viable alternative to Confluent CC.

Conclusion

Having the right UI tools for monitoring and management of Apache Kafka clusters is key to cluster health. With a simple and convenient user interface, you can observe data flows, track metrics, and troubleshoot issues more efficiently, without having to use dozens of additional CLI tools. This results in fewer bottlenecks, faster reporting, and more cost-efficient development.

This article offers my perspective on major UI tools for monitoring and management of clusters in Apache Kafka. I did my best to be objective, but the community is sure to have something to add.

Feel free to share your feedback and opinions about these UI tools for Apache Kafka, and my overview of them, in the comment section.