Kafka cluster 구성 및 failover 테스트

이번 포스팅에서는 kafka cluster를 구성해보고 failover 테스트를 진행한다.

환경은 AWS EC2 인스턴스 하나에 kafka broker를 3대 띄워 진행한다.

---

1. cluster 구성 config

• zookeeper.properties

tickTime=2000
dataDir=/webwas/kafka/zookeeper1(zookeeper2, zookeeper3)
clientPort=2181(2182, 2183)

server.0=127.0.0.1:2887:3887
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889

initLimit=5
syncLimit=5

 

옵션명	설명
tickTime	zookeeper가 사용하는 기본 시간으로 ms단위이다. health check에 사용되며 tickTime * 2의 값을 minimum session timeout의 default값으로 사용한다.
dataDir	메모리의 snapshot을 저장하는 위치로 단일서버이기 때문에 zookeeper별로 다른 위치를 지정한다.
clientPort	client connection에 사용될 port정보이다. 마찬가지로 단일서버이기 때문에 포트분리를 해줘야 한다.
initLimit	초기에 팔로워가 리더에 접속하는 tick의 횟수로 initLimit * tickTime 으로 계산된다. 위의 예시에선 2초 간격으로 5번 시도(즉 10초)를 한다.
syncLimit	leader와 sync를 맞추는데 사용되는 tick의 횟수이다. 위 예시에서는 2초씩 5번 시도(즉 10초)를 한다.
server.x	x의 값이 맵핑되는 kafka server의 id와 일치해야 한다. 단일서버에 구축했기 때문에 port를 분리해줬다. 앞에있는 포트는 동기화에 사용되며 뒤에있는 포트는 leader를 선출하는 포트이다. 또한 dataDir아래 kafka server의 id값을 myid란 파일에 작성해 주어야 한다

[webwas@ip-172-31-39-9 ~]$ cat /webwas/kafka/zookeeper1/myid
0
[webwas@ip-172-31-39-9 ~]$ cat /webwas/kafka/zookeeper2/myid
1
[webwas@ip-172-31-39-9 ~]$ cat /webwas/kafka/zookeeper3/myid
2

 

• server.properties

broker.id=0(1,2)

listeners=PLAINTEXT://:9092(9093,9094)
advertised.listeners=PLAINTEXT://localhost:9092(9093,9094)

log.dirs=/log_data/kafka1(kafka2,kafka3)
num.partitions=1

log.retention.hours=168
log.retention.check.interval.ms=300000

zookeeper.connect=localhost:2181,localhost:2182,localhost:2183/cluster1
zookeeper.connection.timeout.ms=18000

옵션명	설명
broker.id	Broker의 id값으로 Cluster내에서 Broker를 구분하기 위해 사용한다.
listeners	Broker가 사용할 host와 port정보이다.
advertised.listeners	외부 client를 위한 endpoint 정보이다. 기본값은 listener를 따른다.
log.dirs	Broker가 받은 데이터를 저장할 위치를 지정한다. segment file, index file, timestamp 기반index file, offset 정보 파일이 있다.
num.partitions	topic당 partition의 기본값을 지정한다.
log.retention.hours	로그파일의 수명으로 시간단위이다.
log.retention.check.interval.ms	로그수명 체크를 위한 간격으로 ms단위이다.
zookeeper.connect	zookeeper의 연결정보이다.
zookeeper.connection.timeout.ms	zookeeper와 연결의 최대 대기 시간이다.

 

• log4j.properties : 서버로그 설정파일이다.

 

2. failover test

• zookeeper와 kafka를 기동한다.

zookeeper-server-start.sh -daemon /webwas/kafka/config/zookeeper1.properties
zookeeper-server-start.sh -daemon /webwas/kafka/config/zookeeper2.properties
zookeeper-server-start.sh -daemon /webwas/kafka/config/zookeeper2.properties

kafka-server-start.sh -daemon /webwas/kafka/config/server1.properties
kafka-server-start.sh -daemon /webwas/kafka/config/server2.properties
kafka-server-start.sh -daemon /webwas/kafka/config/server3.properties

 

• topic을 생성한다.

[webwas@ip-172-31-39-9 ~]$ kafka-topics.sh --create --bootstrap-server localhost:9092 --topic fotest --replication-factor 3

[webwas@ip-172-31-39-9 ~]$ kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic fotest
Topic: fotest   TopicId: Qha2oDWKQGCXhwhHLl8pog PartitionCount: 1       ReplicationFactor: 3    Configs: 
        Topic: fotest   Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0,2

• replication-factor를 3으로 줘서 topic의 replica를 broker마다 생성한다.
• 현재 Leader가 Broker1번인것을 확인한다.(9093포트를 사용하는 서버이다)

 

• producer를 통해 메시지를 저장한다.

[webwas@ip-172-31-39-9 ~]$ kafka-console-producer.sh --bootstrap-server localhost:9092 --topic fotest
>failover test
>kafka study
>good bam

 

• consumer로 메시지를 확인한다.

[webwas@ip-172-31-39-9 ~]$ kafka-console-consumer.sh --bootstrap-server localhost:9092,localhost:9093,localhost:9094 --topic fotest --from-beginning
failover test
kafka study
good bam

• bootstrap-server에 서버들의 정보를 ','로 구분하여 모두 넣어주며 순서대로 접속을 시도한다.

 

• leader를 kill시키고 다시 메시지를 확인해 본다.

[webwas@ip-172-31-39-9 ~]$ kill -9 29699

[webwas@ip-172-31-39-9 ~]$ kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic fotest
Topic: fotest   TopicId: Qha2oDWKQGCXhwhHLl8pog PartitionCount: 1       ReplicationFactor: 3    Configs: 
        Topic: fotest   Partition: 0    Leader: 0       Replicas: 1,0,2 Isr: 2,0
        
[webwas@ip-172-31-39-9 ~]$ kafka-console-consumer.sh --bootstrap-server localhost:9092,localhost:9093,localhost:9094 --topic fotest --from-beginning
failover test
kafka study
good bam

• 기존 Leader인 Broker1을 kill로 종료 후 다시 fotest topic을 조회해보면 Leader가 0으로 바꼈다.
• 이 후 다시 consumer를 통해 메시지를 확인해보면 정상적으로 조회되는 것을 볼 수 있다.

반응형

---

추가적으로 튜닝포인트들이 많은 것 같다.

관련해서는 다음 포스팅때 정리해 보도록 하겠다.