카프카 - 03 - 운영가이드

토픽 생성

/usr/local/kafka/bin/kafka-topics.sh --zookeeper my-zk001:2181,my-zk002:2181,my-zk003:2181/my-kafka -replication-factor 1 --partitions 1 --topic my-topic --create

 

 

 

토픽 상세 조회

/usr/local/kafka/bin/kafka-topics.sh --zookeeper my-zk001:2181,my-zk002:2181,my-zk003:2181/my-kafka --topic my-topic --describe

토픽의 파티션수, 리더인지 확인 가능하다.

 

 

 

토픽 리스트 조회

/usr/local/kafka/bin/kafka-topics.sh --zookeeper my-zk001:2181,my-zk002:2181,my-zk003:2181/my-kafka --list

 

 

 

토픽의 설정 변경 (보관 주기 변경)

/usr/local/kafka/bin/kafka-topics.sh --zookeeper my-zk001:2181,my-zk002:2181,my-zk003:2181/my-kafka --alter --entity-type topics --entity-name my-topic --add-config retention.ms=3600000
/usr/local/kafka/bin/kafka-topics.sh --zookeeper my-zk001:2181,my-zk002:2181,my-zk003:2181/my-kafka --alter --entity-type topics --entity-name my-topic --delete-config retention.ms

 

 

 

토픽의 파티션 수 변경

/usr/local/kafka/bin/kafka-topics.sh --zookeeper my-zk001:2181,my-zk002:2181,my-zk003:2181/my-kafka --alter --topic my-topic --partitions 2

파티션 수가 정확히 판단이 어렵다면 가능한 작은 수부터 시작해서 파티션을 늘려주는 방법으로 대응하라
파티션이 증가했다고 메시지의 성능이 좋아지는 것은 아니다. 파티션 수만큼 컨슈머의 수도 증가해야한다.
파티션의 증가는 메시지 순서에 영향을 끼칠 수 있다.

 

 

 

토픽의 리플리케이션 팩터 변경

my-replication-factor.json
{
   "version" : 1,
   "partitions":[
       {"topic":"my-topic", "partition":0, "replicas":[1,2]},
       {"topic":"my-topic", "partition":1, "replicas":[2,3]},
   ] 
}

/usr/local/kafka/bin/kafka-reassign-partitions.sh --zookeeper kafka-zk001:2181,kafka-zk002:2181,kafka-zk003:2181/my-kafka --reassignment-json-fle ./my-replication-factor.json --execute

 

 

 

컨슈머 그룹 리스트 확인

/usr/local/kafka/bin/kafka-consumer-groups.sh --bootstrap-server my-kafka001:9092,my-kafka002:9092,my-kafka003:9092 --list

 

 

 

컨슈머 상태, 오프셋 확인

/usr/local/kafka/bin/kafka-consumer-groups.sh --bootstrap-server my-kafka001:9092,my-kafka002:9092,my-kafka003:9092 --group my-consumer --describe

LAG 값을 확인할 수 있는데, LAG 는 카프카에서 가져가야할 추가 메시지의 양을 의미한다.
LAG = 0 은 더이상 가져갈 메시지가 없다는 의미이다.
LAG 가 계속해서 증가하는 상황이라면 컨슈머의 처리가 늦어지고 있다는 것이다.
컨슈머와 파티션의 수를 늘려 대응해야하고 만약 특정 파티션의 LAG 만 증가하고 있다면 해당 컨디션에 연결된 컨슈머를 의심해봐야한다.

 

 

 

주키퍼 스케일 아웃

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/data
clientPort=2181
server.1=my-zk001:2888:3888
server.2=my-zk002:2888:3888
server.3=my-zk003:2888:3888
server.4=my-zk004:2888:3888
server.5=my-zk005:2888:3888

zoo.cfg 의 변경사항을 를 모든 주키퍼 서버에 반영해야한다.
zoo.cfg 파일 반영시 서버를 재시작 해줘야하는데, 리더가 변경되면서 문제가 발생할 수 있기 때문에 주키퍼 앙상블의 리더는 가장 마지막에 반영해주는 것이 좋다.

/usr/local/zookeeper/bin/zkServer.sh status

리더인지 판별하 수 있다.

 

 

 

카프카 스케일 아웃

새롭게 추가하는 서버의 카프카 설정 파일에 broker.id 부분만 안겹치게 추가하고 실행하면 카프카 클러스터에 추가된다.

신규 브로커를 추가한 경우 토픽의 파티션을 해당 브로커에도 분산시켜주는 작업을 해줘야만 같은 클러스터로서 역할을 할 수 있다.

 

 

 

카프카 모니터링

1. JMX 로 모니터링 하기
   JMX는 자바로 만든 어플리케이션 모니터링 등을 위한 도구를 제공하는 자바 API 이다.
   MBEAN 이라는 객체로 표현된다.
   JMX 설정을 하는 방법은 크게 두가지 방법이 있다.
   
   1. 카프카 실행 파일에 JMX 관련 설정 추가하기
   2. systemd 를 이용한 환경변수 추가하기
2. 카프카 매니저로 모니터링 하기
   카프카 매니저는 토픽의 추가, 삭제, 설정 변경등을 웹 GUI 로 할 수 있다.
   토픽 파티션들이 몇개의 브로커에 분산되어 있는지 비율을 확인할 수 있다.
   파티션이 브로커에 균등하게 분산되어 있는지 확인할 수 있다.
   리더가 브로커에 균등하게 분산되어 있는지 확인할 수 있다.
   리플리케이션 수를 확인할 수 있다.

 

 

 

기타 

카프카는 여러대의 서버에 분산되어 실행되고 토픽은 여러개의 파티션으로 분리되어 있다.
카프카의 브로커에는 파티션이 복제되어 분산 저장된다.