PaaS/MQ

kafka 운영과 모니터링

armyost 2022. 6. 24. 18:42
728x90

그라파나와 프로메테우스를 기반으로 카프카와 하드웨어 리소스를 모니터링 하는 방법등을 살펴보겠습니다. 

 

주키퍼

주키퍼는 높은 하드웨어 리소스를 요구하지 않으므로 주키퍼의 물리적인 메모리 크기는 4~8GB로 구성하고 디스크는 240, 480GB SSD를 사용하는 것을 추천합니다. 주키퍼에서 필요로 하는 힙 메모리 크기는 일반적으로 1~2GB이며 나머지는 운영체제 영역등에서 사용하게 됩니다. 따라서 주키퍼 서버에 과도한 물리 메모리를 장착하는 것은 오히려 메모리를 낭비하는 일이 될 수 있습니다. 주키퍼는 트랜젝션이나 스냅샷 로그들을 로컬 디스크에 저장하는데 일반적인 SAS 디스크 보다는 SSD디스크를 추천합니다. 

 

물리서버를 배치하는 경우에는 일반적으로 데이터센터 내에 랙 마운트를 하게 됩니다. 이때 하나의 랙에 모든 주키퍼 서버를 마운트해 배치하는 것은 매우 위험합니다. AWS라면 분산 배치를 위해 가용영역 2개 또는 3개 이상에서 운영합니다. QUORUM 방식의 정족수 방식의 데이터 정합성을 체크합니다.

 

kafka

주키퍼와는 다르게 QUORUM 방식의 구성이 필요하지 않습니다. 홀수가 아닌 4대 6대 등으로도 구성이 가능합니다. 최소수량으로 kafka를 구성한다면 짝수인 2대도 가능하지만 kafka에서 추천하는 안정적ㅇ니 리플리케이션 팩터 수인 3으로 토픽을 구성하기 위해서는 최소 3대의 브로커가 필요합니다. 따라서 카프카를 최소로 구성하기를 원한다면 3대가 가장 적당합니다. 예측하기 어려운 서비스 트래픽의 발생 가능성에 대비해 처음부터 과도하게 수량을 산정해 구성하는 경우도 있는데, kafka의 장점 중 하나가 바로 손쉬운 서버 확장이므로 현재 꼭 필요한 수량만큼만 구성하는 편이 좋습니다. 

 

카프카는 CPU사용률이 높은 편입니다. 프로듀서나 컨슈머의 처리량을 높이기 위해 배치와 압축기능을 많이 적용하게 되는데, 그에 따른 압축이나 해제에도 많은 리소스가 소모됩니다. 고성능 CPU만을 고집할 필요는 없으며 코어수가 많은 CPU로 구성할 것을 권장합니다. 

 

메모리는 32GB부터 256GB까지 다양하게 선택할 수 있는데 kafka에서 요구하는 JVM 힙 크기는 일반적으로 6GB 정도이므로 이보다 큰 물리 메모리가 필요합니다. kafka에서는 힙 크기를 제외한 나머지 물리 메모리는 모두 페이지 캐시로 사용해서 빠른 처리를 돕고 있습니다. 따라서 어느 정도 메모리 여유가 있어야 성능에 도움이 됩니다. 128GB, 256GB  등 가용할 수 있는 서버 메모리가 있다면 이 메모리를 그대로 사용하고 메모리를 조금 타이트하게 운영한다면 최소 32이상 구성하는 것을 추천합니다. 

 

디스크의 경우 성능이 가장 낮은 SATA 디스크를 선택해도 괜찮습니다. 저성능의 SATA 디스크를 사용해도 kafka가 높은 성능을 보장할 수 있는 이유는 로그 마지막에 순차적으로 쓰는 방식으로 로그를 기록하기 때문입니다. 다만 브로커 한 대에 하나의 물리적 디스크를 사용하는 것이 아니라 병렬 처리를 위해 서버에 약 10개 정도의 디스크를 장착합니다. 간혹 kafka의 물리적 디스크 크기가 너무 작아 토픽 파티션의 로그가 가득차는 경우가 있는데, 토픽의 보관주기를 충분하게 설정하려면 4TB 용량 이상의 디스크로 선정하는 것을 추천합니다. NAS는 사용하지 않는 것을 권장합니다. 

 

kafka의 네트워크 카드는 10G 이더넷 카드로 구성하는 것을 추천드리며 브로커 한대당 네트워크 사용량 비율이 50%가 넘지 않도록 최대한 토픽을 분산해 운영해야 합니다 .디스크의 장애 복구 또는 신규 브로커 추가로 인해 kafka 클러스터 사이에서는 대량의 데이터 이동이 발생하게 되기 때문입니다. 

 

주키퍼와 마찬가지로 모든 kafka 서버를 하나의 렉에 마운트 하는 것은 매우 위험합니다. 따라서 여러 렉에 분산시켜 kafka서버를 배치하는 방식을 추천합니다. AWS에서 kafka를 구성하는 경우도 주키퍼와 동일하게 멀티 가용 영역으로 구성하는 것을 추천합니다. 

 

애플리케이션으로서 kafka의 로그 관리와 분석

kafka는 kafka 애플리케이션에서 발생하는 모든 로그를 브로커의 로컬 디스크에 기록하고 있습니다. 관리자는 이 로그르르 활용해 kafka의 현재 상태나 이상 징후 등을 발견하거나 이상 증상 발생 시 원인을 찾습니다. kafka는 애플리케이션 로그 관리를 위해 자바 기반의 로깅 유틸리티인 아파치 log4j를 이용합니다. log4j는 애플리케이션의 레벨별로 로깅이 가능하며, 관리자는 로그의 레벨을 보고 상황의 심각성 등을 유추할 수 있습니다. kafka에서는 TRACE, DEBUG, INFO, WARN, ERROR, FATAL 이라는 로그 레벨을 사용하고 있습니다. 

 

# sudo vi $KAFKA_HOME/config/log4j.properties

// log4j.logger.kafka=DEBUG
// log4j.org.apache.kafka=DEBUG

# sudo systemctl restart kafka-server

로그를 확인하는 경로는 $KAFKA_HOME/logs/server.log 입니다. 

로그파일 이름 설명
server.log 브로커 설정 정보와 정보성 로그등을 기록함. 브로커를 재시작하는 경우 브로커의 옵션 정보가 기록됨
state-change.log 컨트롤러로부터 받은 정보를 기록함
kafka-request.log 클라이언트로부터 받은 정보를 기록함
log-cleaner.log 로그 컴팩션 동작들을 기록함
controller.log 컨트롤러 관련 정보를 기록함
kafka-authorizer.log 인증과 관련된 정보를 기록함

 

kafka를 안정적으로 모니터링 하기위해서는 애플리케이션에서 발생하는 로그의 내용을 분석하는 것 뿐만아니라 현재 kafka클러스터의 상태 및 이상 유무를 한눈에 빠르게 확인할수 있어야 합니다. JMX(Java Management eXtensions)는 자바로 만든 애플리케이션의 모니터링을 위한 도구를 제공하는 자바 API로써 MBean(Managed Bean)이라는 객체로 표현됩니다. 그리고 kafka관리자는 JMX를 이용해 kafka의 주요 메트릭들을 그래프와 같은 형태로 한눈에 확인할 수 있습니다.  JMX를 이용해 kafka의 주요 메트릭을 확인하려면 몇가지 준비 절차가 필요합니다. 먼저 브로커에 JMX 포트를 오픈한 다음, JMX에서 제공하는 메트릭 정보를 관리자가 GUI 형태로 볼수 있도록 구성해야 합니다. 여기서는 최근 가장 많이 쓰이는 프로메테우스와 익스포터를 이용해 JMX 모니터링 시스템을 구성해보겠습니다. 

 

kafka JMX 설정방법

kafka에서 JMX를 사용할 수 있도록 설정하는 방법은 여러가지가 있지만, 이 책에서는 systemd의 환경변수 옵션을 추가하는 방법으로 진행하겠습니다. 

 

# cat $KAFKA_HOME/config/jmx
// JMX_PORT=9999

# netstat -ntl | grep 9999

 

프로메테우스 설치

/etc/prometheus 경로에 다음 환경설정을 적용합니다. 

# prometheus config
global:
  scrape_interval:     5s
  evaluation_interval: 5s

scrape_configs:
  - job_name: 'peter-jmx-kafka'
    static_configs:
      - targets:
        - peter-kafka01.foo.bar:7071
        - peter-kafka02.foo.bar:7071
        - peter-kafka03.foo.bar:7071

  - job_name: 'peter-kafka-nodes'
    static_configs:
      - targets:
          - peter-kafka01.foo.bar:9100
          - peter-kafka02.foo.bar:9100
          - peter-kafka03.foo.bar:9100

  - job_name: 'peter-kafka-exporter'
    static_configs:
      - targets:
          - peter-kafka01.foo.bar:9308
          - peter-kafka02.foo.bar:9308
          - peter-kafka03.foo.bar:9308

 

참고 링크 : https://github.com/onlybooks/kafka2/blob/main/chapter7/prometheus.yml

 

GitHub - onlybooks/kafka2: 실전 카프카 개발부터 운영까지

실전 카프카 개발부터 운영까지. Contribute to onlybooks/kafka2 development by creating an account on GitHub.

github.com

 

프로메테우스의 모니터링 방식은 Push가 아니라 Pull 방식입니다. 따라서 모니터링 하고자 하는 대상 서버에 자신의 메트릭 정보를 보여줄 수 있는 Exporter를 설치해야 합니다. 익스포터란 다양한 애플리케이션에서 수집되는 메트릭들을 프로메테우스가 인식할 수 있는 형태로 나타내는 에이전트를 말합니다. 프로메테우스로 모니터링할 대상 서버와 포트정보를 프로메테우스 환경 설정 파일에 등록하면 프로메테우스는 주기적으로 대상 서버의 메트릭값을 가져와 자신의 데이터베이스에 저장합니다. 

 

http 클라이언트 요청에 응답하는 형태로 로컬 JVM의 메트릭을 보여주기 위해서 독립적인 HTTP 서버로 설정하거나 자바 에이전트로 설정할 수 있는데 여기서는 전자의 방식인 독립적인 HTTP 서버로 설정하는 방법을 이용하겠습니다. 먼저 JMX 익스포터를 저장할 디렉토리를 생성하고 해당 JAR 및 설정파일을 다운로드 받습니다. 

 

- JAR : https://github.com/onlybooks/kafka2/blob/main/chapter7/jmx_prometheus_httpserver-0.13.1-SNAPSHOT-jar-with-dependencies.jar

 

GitHub - onlybooks/kafka2: 실전 카프카 개발부터 운영까지

실전 카프카 개발부터 운영까지. Contribute to onlybooks/kafka2 development by creating an account on GitHub.

github.com

- 환경설정 yml : https://github.com/onlybooks/kafka2/blob/main/chapter7/jmx_prometheus_httpserver.yml

 

GitHub - onlybooks/kafka2: 실전 카프카 개발부터 운영까지

실전 카프카 개발부터 운영까지. Contribute to onlybooks/kafka2 development by creating an account on GitHub.

github.com

- systemctl 등록 파일 : https://github.com/onlybooks/kafka2/blob/main/chapter7/jmx-exporter.service

 

GitHub - onlybooks/kafka2: 실전 카프카 개발부터 운영까지

실전 카프카 개발부터 운영까지. Contribute to onlybooks/kafka2 development by creating an account on GitHub.

github.com

 

참고로 JMX 익스포터는 브로커 한 대에만 설치하는 것이 아니라 kafka 클러스터 내 모든 브로커에 설치해야 합니다 이제 각 브로커에 JMX 익스포터 설치가 완료됐습니다. 익스포터가 설치됐다고 해서 즉시 모니터링이 가능한 것은 아닙니다. 프로메테우스의 환경 설정 파일에서 수집대상 서버들을 명시해야 이후부터 프로메테우스에 메트릭들이 수집, 저장됩니다. 프로메테우스의 환경 설정파일에 대상 서버들을 등록하기에 앞서 브로커 서버의 하드웨어 리소스 모니터링을 위해 노드 익스포터도 설치해야 합니다. 

 

그라파나 설치

프로메테우스는 훌륭한 모니터링 도구이지만 성능이나 메트릭 등을 대시보드 형태로 보기에는 용이하지 않습니다. 오픈소스인 프로메테우스와 그라파나를 이용하면 누구라도 단 몇분만에 잘 만들어진 대시보드를 손쉽게 만들 수 있습니다. 표시해야할 내용은

 

- kafka 클러스터의 전반적인 내용

  • 전체 브로커 수 
  • 토픽 수 
  • 파티션 수
  • 현재 실시간 초당 인입 메시지 수
  • 응답시간

- 브로커 별로 리더수나 파티션 수가 고르게 분포됐는지 등의 의 세부사항

  • kafka 클러스터로 유입되는 전체 초당 메시지 건수
  • Byte 수
  • 요청 비융

- 프로듀서, 컨슈머, 팔로워에 관해 전체적인 지연시간이 발생할 경우 어느 구간에서 지연이 발생하는지를 상세하고 추적하고 관리할 수 있습니다. 

 

카프라 익스포터

kafka를 모니터링 하기 위해서는 앞서 살펴본 JMX 메트릭 브로커의 리소스 모니터링도 중요하지만 컨슈머의 LAG을 모니터링 하는 것이 가장 중요합니다. 여기서는 프로메테우스와 그라파나로 모니터링 하는 방법을 알려드리겠습니다. 해당 git 에서 제공하는 익스포터를 실행합니다. 


https://github.com/danielqsj/kafka_exporter/releases

 

Releases · danielqsj/kafka_exporter

Kafka exporter for Prometheus. Contribute to danielqsj/kafka_exporter development by creating an account on GitHub.

github.com

이 대시보드는 

  • Message in per second
  • Message in per minute
  • Lag by Consumer Group
  • Partition per topic

 

그리고 임계치를 조정하여 알람을 받을 수 있게 해야 합니다.