3. Ⅰ.Apahe Kafka 필수 명령어
토픽생성
[root@mykaf01 ~]# ./kafka-topics.sh –zookeeper mykaf01:2181, mykaf02:2181/frankaf
--replication-factor 1 –partitions 1 –topic mytopic --create
Created topic “ mytopic”.
토픽 리스트 확인
[root@mykaf01 ~]# ./kafka-topics.sh –zookeeper mykaf01:2181, mykaf02:2181/frankaf --list
……consuumer_offsets
Mytopic
토픽 상세보기
[root@mykaf01 ~]# ./kafka-topics.sh –zookeeper mykaf01:2181, mykaf02:2181/frankaf
--topic mytopic --describe
Topic : mytopic PartitionCount: 1 ReplicationFactor : 1 configs :
Topic : mytopic Partition : 0 Leader : 1 Replica : 1 lsr: 1
토픽 삭제
[root@mykaf01 ~]# ./kafka-topics.sh –zookeeper mykaf01:2181, mykaf02:2181/frankaf
--delete –topic mytopic
Topic mytopic is marked for deletion
Note : This will have no impact if delete, topic, enable is not set to true
4. Ⅰ.Apahe Kafka 필수 명령어
토픽의 파티션 수 변경
[root@mykaf01 ~]# ./kafka-topics.sh –zookeeper mykaf01:2181, mykaf02:2181/frankaf
--after –topic mytopic –partitions 2
WARNNING: if partitions are increased for a topic that has a key, the partition
Logic or ordering of the messages will be affected
Adding partitions succeded!
토픽의 리플리케이션 팩터 변경
=> Json 형식의 파일 생성 필요
{“version” : 1,
“partitions”:[
{“topic”:”mytopic”,”partition”:0,”replicas”:[1,2]},
{“topic”:”mytopic”,”partition”:1,”replicas”:[2,3]},
{“topic”:”mytopic”,”partition”:2,”replicas”:[1,3]}
]}
컨슈머 그룹 리스트 확인
[root@mykaf01 ~]# ./kafka-topics.sh –zookeeper mykaf01:2181, mykaf02:2181/frankaf --list
myconsumer
[root@mykaf01 ~]# ./kafka-topics.sh –zookeeper mykaf01:2181, mykaf02:2181/frankaf
--ressignment-json-file ./rf.json --execute
5. Ⅱ.Apahe Kafka 주요 옵션
Producer
▶batch.size : 메시지 데이터를 미리 설정된 사이즈가 될 때까지 모아 한번에 배치로 전송
- 빈번한 I/O와 네트워크 왕복의 오버헤드를 줄여 서버와 클라이언트 모두 성능 향상
- 장애 발생 시 메시지가 유실될 가능성이 있어 고가용성이 필요한 시스템의 경우 해당 설정값을 주지 않기도 함
▶linger.ms : batch.size에 도달하지 못한 상황에서 linger.ms 제한시간에 도달하면 메시지를 전송
- 프로듀서의 전송속도와 전송량을 감안해 batch.size가 충분히 찰 수 있도록 시간 조정 필요
▶ compression.type : 프로듀서가 데이터를 압축해서 보낼 때 사용할 압축 포맷
- 보통 압축된 포맷을 사용하는 것이 성능에 유리하며 gzip, snappy, lz4 등의 포맷 지원
▶ retries : 오류로 인해 전송이 실패한 경우 데이터를 다시 보내는 횟수
- 재전송으로 인해 레코드의 순서가 바뀔 수 있음
▶ buffer.memory : Kafka 서버로 전송을 기다리는 메시지를 위해 프로듀서가 사용할 버퍼 메모리 크기
- 브로커로 전송하는 속도보다 버퍼에 쌓이는 속도가 더 빨리 buffer.memory만큼 쌓이면 메시지 전송은 블락되고
max.block.ms 시간이 넘어가면 exception이 발생
▶ acks : 프로듀서가 토픽의 리더에게 메시지를 보낸 후 요청을 완료하기 전까지 받는 ack의 수
- 옵션의 수가 작으면 성능이 좋지만 메시지 손실 가능성이 있고 수가 크면 그 반대임.
6. Ⅱ.Apahe Kafka 주요 옵션
Broker
▶ auto. Create. Topic. Enable
- 존재하지 않는 토픽으로 메시지를 전송 시 자동으로 토픽을 생성할지 여부
▶ num.replica.fetchers : 리더에서 메시지를 복제할 때 사용할 Thread 수, 기본값은 1
▶ default.replication.factor : 토픽을 자동으로 생성할 때 설정할 replica의 개수, 기본값은 1
▶ unclean. Leader. Election. Enable : ISR이 아닌 브로커를 리더로 선출할 수 있는지 여부
▶ log. Retention.{ms,minutes,hours} : 메시지 데이터를 디스크에 보관할 시간
- 기본값은 7일(168시간)
▶ log.flush. Interval message : 메시지를 디스크로 내보내기 전 메모리에 보유할 메시지 개수
▶ min. insync. Replicas : 최소 replication factor 수
- 리더 파티션이 프로듀서에게 ack를 보내기 전 이 설정만큼의 replication이 유지되는지 확인
7. Ⅱ.Apahe Kafka 주요 옵션
Consumer
▶fetch. Min(max). Bytes
- 한번에 가져올 수 있는 최소/최대 사이즈. 지정 사이즈보다 작으면 누적될 때까지 대기
▶enable.auto.commit: 백그라운드로 주기적인 오프셋 커밋을 수행할 지 여부(auto.commit.interval.ms)
▶ auto.offset.reset: 초기 오프셋이 없거나 현재 오프셋이 없는 경우 어떻게 리셋할 것인지 설정
- earliest : 가장 초기의 오프셋 값으로 설정한다
- lastest : 가장 마지막의 오프셋 값으로 설정한다
- none : 이전 오프셋 값을 찾지 못하면 에러를 발생한다
▶ session.timeout.ms: 세션 타임아웃 시간으로 컨슈머가 살아있는 것으로 판단하는 시간
- 컨슈머가 해당 시간 안에 그룹 코디네이터에게 하트비트를 보내지 않으면 컨슈머 그룹은 리밸런싱을 시도
- 낮게 설정하면 실패를 빨리 감지하지만 GC나 루프처리로 인해 원하지 않는 리밸런싱이 일어날 수 있으며, 높게
설정하면 리밸런싱의 가능성은 줄어 들지만 실패를 빨리 감지할 수 없음
▶ heartbeat.interval.ms: 그룹 코디네이터에게 얼마나 자주 하트비트를 보낼 것인지 조정
- session.timeout.ms와 밀접한 관계가 있으며 session.timeout.ms보다 더 낮아야함.
- 일반적으로 session.timeout.ms의 3분의 1정도로 설정한다. 기본값은 3초
▶ max.poli.interval.ms: 컨슈머가 메시지를 가져간 후 다음 작업까지 얼마나 기다리는지에 대한 설정
- 컨슈머가 하트비트만 보내고 메시지를 가져가지 않는 경우에 대해 무한정 해당 파티션을 점유할 수 없도록
추가적으로 메시지를 가져가지 않으면 장애라고 판단
8. Ⅱ.Apahe Kafka 주요 옵션
acks
▶acks=0 : 프로듀서는 서버로부터 어떠한 ack도 기다리지 않음
▶acks=1 : 리더는 데이터를 기록하지만 팔로워의 처리결과는 확인하지 않음
▶acks=all or -1 : 리더는 ISR의 모든 팔로워로부터 ack를 기다림
9. Ⅱ.Apahe Kafka 주요 옵션
Unclean.leader.election.enable
▶고가용성을 위한 replication
10. Ⅱ.Apahe Kafka 주요 옵션
Unclean.leader.election.enable
▶ISR이 아닌 OSR(out-of-Sync Replica) 상태의 Broker가 Leader가 될 수 있음.
11. Ⅲ.Apache Kafka 모니터링
Kafka 모니터링을 위한 Metrics 이해
▶Metrics(metric) : 성능이나 상태를 모니터링하기 위한 측정 지표
- Kafka application의 메트릭은 실제로 너무 많아 무엇을 잘 지켜봐야 하는지 혼란스러움
- Kafka application에서 생성되고 제공하는 내부 메트릭 (프로듀서, 브로커, 컨슈머 등)
- OS, 디스크 사용률, 네트워크 부하, 웹서버의 상태 등의 외부 메트릭
▶Metric 선정의 중요성
- 너무 적으면 문제가 발생해도 알지 못하는 상황이 생길 수 있음
- 너무 많으면 알람이 많아 얼마나 심각한 문제인지 알기 어려움
- 모든 메트릭의 임계값을 적합하게 정의하기도 어렵고 최신으로 유지하기도 어렵다.
고수준의 범위를 갖는 소수의 메트릭을 선택해야 한다.
12. Ⅲ.Apache Kafka 모니터링
JMX 인터페이스를 이용한 모니터링
▶JMX(Java Management eXtensions) : 자바로 만든 Application의 모니터링 도구를
제공하는 자바 API
- JVM 기반에서 동작하는 모든 프로세스는 JMX metrics 정보를 제공
- Mbean(Managed Bean) 이라는 객체로 표현됨
▶JMX를 이용하기 위해서 Kafka 실행파일에 JMX 관련 설정을 추가
- Kafka-server-start.sh 파일을 열고 export JMX_PORT=9999 구문을 추가 후 재시작
▶JMX metrics 정보를 Prometheus, Elasticsearch, InfluxDB 등을 이용해 수집하고,
ELK Stack, Grafana 같은 시각화 도구를 이용해 모니터링 수행
▶JMX를 이용한 모니터링 수행 시 현실적인 어려움과 한계가 존재
- Kafka Client가 JVM 기반 언어로 한정됨
- 프로듀서와 컨슈머 추가/삭제 시 모니터링을 위한 추가 작업 필요
14. Ⅲ.Apache Kafka 모니터링
LAG를 이용한 컨슈머 모니터링
▶LAG : 현재 토픽에 저장된 메시지와 컨슈머가 가져간 메시지의 차이
- 프로듀서가 Kafka 토픽으로 10개의 메시지를 모냈는데 컨슈머가 5개만 가져갔으면 LAG는 5가 됨.
▶컨슈머의 처리시간이 지연되면 토픽 내부의 파티션 LAG가 증가
- LAG 모니터링을 통해 어느 파티션의 LAG가 증가하고 있는지, 어느 컨슈머에 문제가 있는지 확인 가능
▶LAG가 중요한 지표이긴 하나 MAX LAG 숫자 그 자체로서 장애/비장애를 구별할 수 없음
15. Ⅲ.Apache Kafka 모니터링
버로우(Burrow)를 이용한 LAG 모니터링
▶버로우 : Kafka를 개발한 링크드인에서 만든 컨슈머 LAG 모니터링 툴
▶아래의 한계로 인해 외부 지연 모니터링 Application을 사용하기 위해 개발됨
- 컨슈머 fetch 관련 Mbean에서 보여주는 LAG metric 정보는 가장 뒤쳐진 파티션의 지연상태만 보여줌
- 하나의 파티션에 대한 컨슈머 지연만 보여주기 때문에 타 파티션의 상태 확인이 어려움
- 컨슈머 자체가 정상 작동되지 않고 멈춘 경우 LAG 감지가 불가능
▶버로우는 지연이 실제 문제발생을 의미하는지 결정하는 것에 있어 상대적으로 정확함
- 버로우 Evaluator 모듈이 내부의 Consumer LAG Evaluation Rules에 따라 컨슈머 그룹의 상태를 평가
▶Consumer LAG Evaluation Rules
- 0인 lag가 존재하면 상태는 ‘OK’
- 컨슈머 오프셋이 변경되지 않고, lag가 고정 혹은 증가하는 경우 컨슈머는 ‘ERROR’이고, 해당 파티션은
‘STALLED’
- 컨슈머 오프셋이 증가하지만 lag가 고정 혹은 증가하는 경우 컨슈머는 ‘WARNING’ 임
- 가장 최근 오프셋 시간과 현재시간(측정시간)의 차이가 가장 최근과 가장 오래된 오프셋 시간의 차이
보다 클 경우 컨슈머는 ‘ERROR’ 이고 파티션은 ‘STOPPED’
- lag가 -1인 경우 특수한 값이므로 브로커의 오프셋이 존재하지 않음을 의마하며 정상으로 간주함
