Skip to Content
Data EngineeringKafka Custom Metrics Reporter를 활용한 JMX 모니터링 부하 최소화 (Ambari 모델 차용)
📊 Data Engineering2017년 4월 14일

Kafka Custom Metrics Reporter를 활용한 JMX 모니터링 부하 최소화 (Ambari 모델 차용)

#kafka#ambari#metrics#data-engineering#flamingo

빅데이터 인프라를 지탱하는 핵심 뼈대인 실시간 메시징 플랫폼 Kafka는, 수백 MB/s의 데이터를 처리하는 만큼 프로커 노드 자체의 상태 모니터링(TPS, BytesIn/Out, CPU, Network 등)이 매우 중요합니다.

과거 당사의 빅데이터 모니터링 솔루션 빅데이터 모니터링 플랫폼 엔진을 개발하면서 만난 큰 허들이 있었습니다. Kafka가 내부적으로 제공하는 수많은 헬스 지표는 기본적으로 Java의 JMX(Java Management Extensions)를 통해 노출되는데, 플랫폼 수집 에이전트가 1초 또는 5초 주기로 원격 JMX 포트에 붙어 수천 개의 객체(MBeans) 트리를 순회하면서 지표를 Pull 해오는 행위 자체가 브로커 서버(JVM)에 무시 못 할 성능 오버헤드(Garbage Collection 유발, CPU 스파이크)를 일으켰다는 점입니다.

1. 해결책의 영감: Ambari Metrics Kafka Sink

관제 대상(Kafka)에 부담을 주는 Pull 방식 대신, Kafka 런타임 내부에 작은 플러그인을 심어서 “Kafka가 자신의 지표를 모아다가 모니터링 서버(플랫폼)로 주기적으로 Push 쏴주는 방식”으로 패러다임을 바꿀 필요가 있었습니다.

이를 위해 참조했던 아키텍처가 바로 Hortonworks의 관리 툴인 Ambari Metrics System (AMS)의 구동 원리였습니다. Ambari는 Kafka의 자체 기능인 kafka.metrics.reporters 인터페이스를 확장(Extend)하여 메트릭을 가로채는 방식(ambari-metrics-kafka-sink)을 개척해 두었습니다.

이 오픈소스 코드를 딥다이브(Deep Dive)하고 벤치마킹하여, 저희 팀만의 독자적인 플랫폼 전용 Kafka Sink Reporter 클래스를 개발(Java)하게 되었습니다.

2. Kafka Sink Reporter 개발 및 환경 구성

이 방식은 Kafka 코어 코드 수정 없이 외부 Jar 하나만 Plugin 형태로 제공하면 된다는 엄청난 장점이 있었습니다.

1. Maven 빌드 의존성 및 개발 플랫폼 전용 리포터 로직을 짜기 위해 Ambari 의존성을 참조하거나 야후(Yahoo), 링크드인(LinkedIn) 등에서 쓰는 Reporter 인터페이스 규약을 분석했습니다.

xml
<dependency>
    <groupId>org.apache.ambari</groupId>
    <artifactId>ambari-metrics-kafka-sink</artifactId>
    <version>2.4.2.2.1</version>
</dependency>

직접 구현한 Java 클래스 라이브러리(flamingo-kafka-sink.jar)를 컴파일하여, 현장에 있는 모든 Kafka Broker 서버의 $KAFKA_HOME/libs/ 폴더에 복사해 넣습니다.

2. Kafka 설정(server.properties) 반영 그런 다음 Kafka 서버 설정 파일의 파라미터 2줄을 추가해주면 준비가 완료됩니다.

text
kafka.metrics.reporters=com.exem.flamingo.management.kafka.hadoop.metrics

# 플라밍고 백엔드 API로 지표를 Push할 주기 (Seconds)
kafka.metrics.polling.interval.secs=60

3. 적용 효과

적용 완료 후 클러스터를 재구동시키자, 기존 거대한 JMX 폴링 체제에서 발생하던 연결 세션 맺기/끊기 스레드 낭비가 완벽히 차단되었습니다.

Kafka 백그라운드 데몬이 자체적으로 데이터를 취합한 뒤 플랫폼 콜렉터 서버의 가벼운 REST API Endpoint로 HTTP POST 페이로드(JSON)를 툭툭 던져주는 구조로 바뀌면서, 모니터링 주기를 더 짧게 가져가더라도 Kafka 브로커의 서비스 품질 저하(Latency)가 전혀 발생하지 않는 극적인 안정화를 이뤄냈던 기억 깊은 프로파일링 고도화 작업이었습니다.

Last updated on