카카오에서는 100개가 넘는 클러스터를 모니터링하고 장애 시 알림을 받을 수 있도록 오픈소스와 자체 제작한 기능을 종합한 모니터링 및 알림 기능을 사용하고 있습니다. KHP 모니터링과 알림 시리즈는 개발진이 모니터링을 구축하기 위해서 고민했던 지점들을 공유하고, 문제점을 해결한 방법을 소개함으로써 현재 모니터링과 알림 체계 때문에 고민하는 현업의 많은 개발자분들에게 도움이 되고자 작성하였습니다.

1부에서는 KHP에서는 모니터링 체계에서 사용하는 기반 데이터로 메트릭(metric)과 로그(log)를 어떻게 수집하고 시각화하는지 소개하고, 2부에서는 수집한 메트릭과 로그를 활용하여 구현한 KHP 알림 시스템을 소개하겠습니다.

원천 데이터: ‘metric’과 ‘log’

KHP는 여러 가지 서비스를 다수의 호스트에서 동시에 실행합니다. 이러한 특성 때문에 다양한 이유로 비정상적인 상황이 발생할 수 있습니다. 가끔은 이런 상황이 클러스터의 성능에 영향을 줘서 서비스의 품질을 떨어뜨립니다. 사용자에게 제공하는 서비스의 품질을 유지하기 위해서는 클러스터 관리자의 역할이 중요합니다. 클러스터 관리자는 문제 상황을 빠르게 감지하고 원인을 정확히 짚어, 이를 올바르고 신속하게 대응할 수 있어야 합니다.

모니터링 체계에서 전통적인 방식은 메트릭만 활용해서 상황을 판단하는 방식입니다. KHP 모니터링 체계는 메트릭뿐만 아니라 로그도 지속적으로 확인해서 메트릭으로는 드러나지 않는 현상들도 지켜보고 있습니다. KHP 모니터링 체계의 목표는 전통적인 방식도 잘 수행하면서, 새로운 방식도 도입해 전통적인 방식의 단점을 보완해 더욱 완성도 높은 모니터링 체계를 구축하고 운용하는 것입니다. 이제 KHP 모니터링에서 메트릭과 로그를 어떻게 처리하는지 살펴보겠습니다.

메트릭 처리

KHP 모니터링 체계는 CPU, Disk, Memory의 사용률과 같은 각 호스트 단위 지표부터, HDFS 사용량, HBase RW(Read and Write) 요청량과 같은 서비스 단위 지표까지 다양한 지표를 실시간으로 수집하고 전처리합니다. KHP 모니터링 체계에서는 메트릭을 어떻게 수집하고 처리하고 시각화하는지 살펴보겠습니다.

아키텍처

메트릭의 최종 저장소로 Apache Druid(이하 드루이드)를 선정했습니다. 드루이드는 확장성과 고가용성을 확보한 데이터 저장소입니다. 카카오에서는 카카오 내 모든 크루를 대상으로 공용 드루이드 클러스터를 운영하고 있어서, 축적된 기술 노하우를 활용할 수 있는 장점도 있습니다. 그뿐만 아니라 드루이드는 시계열 수치 데이터의 처리와 연산에 큰 강점이 있기에, 메트릭 질의 시 훌륭한 성능을 기대할 수 있다는 장점도 있습니다.

클러스터 관리자가 수집해야 하는 메트릭의 출처와 포맷은 매우 다양합니다. 그래서 이를 일괄적으로 수집하고 정제하는 역할이 필요합니다. KHP 모니터링 체계에서는 KHP Agent라는 메트릭 수집기를 자체 구현해 각 서버에 설치했습니다. KHP Agent는 클러스터 관리자가 지정한 이름의 메트릭을 지정한 방식으로 수집하고, 수집한 메트릭을 지정한 포맷으로 재구성한 뒤, 관리자가 지정한 목적지로 전송합니다. 메트릭 처리에 핵심인 KHP Agent는 아래에서 자세히 설명하겠습니다.

이렇게 데이터 수집 과정에서 산출되는 시계열 데이터 처리에 지연이 발생할 경우 동시성 확보를 통해 문제를 해결할 수 있습니다. KHP 모니터링 체계는 이 중에서도 분산 큐인 Kafka(이하 카프카)를 도입해 트래픽이 높은 상황에서도 동시성을 확보하고 시간 지연 없이 즉시 데이터를 처리하도록 구현되었습니다. 드루이드에서 주목할 만한 기능은 실시간 처리 파이프라인을 손쉽게 구성하고 관리할 수 있는 kafka indexing service라는 기능입니다. KHP 모니터링 체계에 카프카를 도입해 드루이드의 maintainer가 기능과 성능을 보장하는 이 실시간 처리 기술도 활용할 수 있도록 했습니다.

KHP Agent: KHP 클러스터의 메트릭 수집기

KHP 모니터링 체계에서 사용할 메트릭 수집기는 두 가지 요구사항을 모두 만족해야 합니다.

수집기에서 원시 데이터를 보정하거나 후처리해야 함
수집한 데이터를 드루이드에서 처리할 수 있는 포맷으로 가공해 카프카에 적재해야 함

수집기가 수집하는 원천 데이터는 데이터 값의 종류를 기준으로 크게 두 가지로 나눌 수 있습니다. 바로 절댓값과 누적값입니다. CPU 사용량, Disk 사용량과 같은 대부분의 메트릭은 측정 당시의 절댓값을 바로 수집할 수 있습니다. 그러나 HDFS의 FSNamesystem numOps, HBase의 Replication shippedBatches와 같은 메트릭은 프로세스 실행 후부터 누적된 누적값만을 수집할 수 있습니다. 누적값은 절댓값과 다르게 프로세스가 재시작하면 0으로 초기화됩니다. 메트릭 수집기가 위의 두 가지 요구사항을 만족해야 하는 이유는, 다양한 종류의 메트릭을 관리자가 정의한 명세에 따라 일관성 있게 메트릭을 보정하고, 저장소에 보정한 메트릭을 적재할 수 있어야 하기 때문입니다.

메트릭이 최종적으로 저장되는 저장소는 드루이드입니다. 그러므로, 수집된 원천 데이터는 드루이드에서 사용할 수 있는 형태여야 합니다. 수집기가 원천 데이터를 수집한 후 드루이드에서 처리할 수 있는 형태로 바로 가공해서 카프카에 적재할 수 있다면, 드루이드가 카프카에 적재된 데이터를 바로 사용할 수 있기 때문에 추가적인 데이터 가공과 컴퓨팅 리소스가 필요하지 않습니다.

메트릭 수집기를 도입하기 위해 대표적으로 널리 쓰이는 졸로키아(jolokia)와 메트릭비트(Metricbeat) 두 가지 서비스를 검토했습니다. 그러나 두 서비스 모두 현재 제공 중인 기능으로는 위에서 언급한 두 개의 요구사항에 부합하는 가공 과정을 구성할 수 없었습니다. 또한, 다음과 같은 단점들이 존재했기 때문에 최종적으로 도입을 보류하게 되었습니다. 졸로키아는 JMX 데이터를 효율적으로 다룰 수 있는 클라이언트를 제공하지만, 그 외 모든 과정은 자체적으로 구현해야 합니다. 메트릭비트는 설정 파일을 수정하는 것만으로는 위의 요구사항을 부합하는 로직을 구현할 수 없었습니다. 모듈을 자체적으로 구현하고 관리해야 하는데 이 과정이 꽤 번거롭습니다.

그래서 위 요구사항을 모두 만족하면서 관리하기 쉬운 메트릭 수집기를 자체적으로 구현했습니다.

실시간 대시보드 구축

위 이미지는 그라파나(Grafana)를 활용하여 구축한 실시간 지표 확인 대시보드입니다. 초기 구현 단계에서 드루이드 데이터를 조회할 수 있는 시각화 툴로 슈퍼셋(Apache Superset)과 그라파나를 검토했습니다. 이 중에서 그라파나의 UI가 직관적이고, 차트 생성과 조회가 편리하며 차트 렌더링 속도가 빨라서 그라파나를 선택했습니다. 그라파나로 KHP에서 제공하는 각 서비스의 품질을 확인할 수 있는 거의 모든 차트를 구성하고, 특이사항이 발생하면 문제의 원인을 파악하는 데 차트를 적극적으로 활용하고 있습니다.

Turnilo도 활용하고 있습니다. 클러스터 관리자는 때에 따라 drill down 방식, 즉, 시간 범위를 조정하면서 여러 메트릭을 유연하게 조합하는 ad-hoc 질의로 문제 상황을 조사해야 할 수도 있습니다. 그라파나로 구축한 대시보드는 이 ad-hoc 질의가 다소 번거롭다는 단점이 있습니다. Turnilo는 ad-hoc 질의에 특화된 툴입니다. 클러스터 관리자가 Turnilo를 바로 사용할 수 있도록, 즉시 활용 가능한 상태의 인스턴스를 상시 운영해 클러스터 관리자가 문제를 해결하는 데 도움을 줍니다.

로그 처리

지금까지 메트릭을 수집하고, 수집된 메트릭을 시각화한 대시보드를 구축하는 과정을 살펴보았습니다. 때로는 클러스터 관리자가 문제의 인과관계를 완전히 파악하는데 대시보드만으로는 부족한 경우가 있습니다. 예를 들어, HBase의 responseTooLarge, responseTooSlow와 같은 특이사항은 로그로만 확인할 수 있습니다. 그렇기 때문에 클러스터 관리자는 로그도 중요하게 살펴봐야 합니다. 그러나, 클러스터의 규모가 크고 워크로드가 무거울수록 로그 양은 급격히 많아집니다. 따라서 여러 서버의 로그로부터 필요한 정보를 찾아내기까지 오랜 시간이 걸릴 수 있습니다. 이는 클러스터의 품질을 관리하는 데 부정적 영향을 줍니다. 클러스터 관리자가 문제를 해결하는 데 도움이 될 수 있도록, KHP 모니터링 체계는 로그도 수집하고, 이를 즉시 검색할 수 있는 상태로 처리합니다. 지금부터 KHP 모니터링 체계가 로그를 어떻게 처리하고 시각화하는지 살펴보겠습니다.

아키텍처

로그 수집기가 수집한 텍스트 로그는 클러스터 관리자가 검색할 수 있는 상태로 처리해야 합니다. 그러려면 전문 검색(full-text search)이 가능한 검색엔진이 필요합니다. 검색엔진 중 메인 스폰서 기업의 주도하에 가장 활발하게 개발하고 있는 오픈소스인 엘라스틱서치(Elasticsearch)를 검색엔진으로 선정했습니다. 마침 사내에도 전담 부서가 있어, 엘라스틱서치를 사용하게 된다면 KHP 용 클러스터 운영을 위임하고 기술 지원을 받을 수 있다는 장점도 있었습니다.

로그 저장소로 엘라스틱서치를 선정한 뒤에는, 로그 파일 수집과 구조화, 시각화를 담당할 도구를 빠르게 선정할 수 있었습니다. 엘라스틱 서치를 사용할 때 파일비트(Filebeat), 로그스태시(Logstash)를 함께 도입해 사용한 사례는 많이 찾아볼 수 있으며, 이미 그 사용성이 검증된 조합입니다. 파일비트는 개별 서버에 txt 파일로 기록 중인 로그 파일을 line-by-line으로 실시간 전송합니다. 로그스태시는 비정형 로그 데이터에서 구조를 도출하고 패턴화 해, 어떤 형태의 데이터이든지 사용이 가능하도록 준비합니다. 메트릭 처리 아키텍처를 고민할 때와는 다르게, 최초에 목표한 기능을 모두 파일비트, 로그스태시로 구현할 수 있어서 별도의 추가 구현은 하지 않았습니다.

다만 어떠한 이유로 로그스태시의 persistence queue가 유실되는 상황이 발생하더라도 유실 없는 로그 처리가 가능하도록 파일비트와 로그스태시 사이에 분산 큐인 카프카를 도입했습니다. 카프카의 offset 관리 기능을 사용해 토픽 별 데이터 재처리를 지시할 수 있으므로 로그가 유실될 가능성을 줄일 수 있습니다. 또한 카프카를 사용함으로써 안정적으로 동시성을 확보할 수 있는 구조가 되었습니다.

실시간 대시보드 구축

위 이미지는 엘라스틱서치에 저장된 데이터를 가장 쉽고 효과적으로 조회할 수 있는 오픈소스인 키바나(Kibana)를 사용해 구축한 실시간 검색 대시보드입니다. 위 대시보드를 구축한 뒤부터는 더 이상 해당 서버에 ssh 접속하여 로그 파일에 tail, grep 명령어를 사용하지 않아도 필요한 내용을 쉽게 조회할 수 있습니다. 관리자가 문제를 신속하게 파악하고 대응할 수 있도록, 로그 레벨별로 차트를 구성할 수 있고 특정 로그 레벨만 추출하거나 필터링해 볼 수 있는 기능을 제공합니다. 그리고 빈번히 조회하는 키워드 등을 기준으로 시각화된 차트도 구현했습니다.

Java GC 실시간 모니터링 대시보드 구축

GC는 자바 애플리케이션의 성능에 큰 영향을 줍니다. GC 설정이 워크로드에 적합하지 않으면, GC 부하가 과도해지거나, stop-the-world 시간이 길어지고 빈번해질 수 있습니다. 그러면 자바 애플리케이션의 최적 성능을 보장할 수 없습니다. KHP에서 제공하는 서비스는 대부분 자바 애플리케이션이기에, 성능을 최적화하려면 GC를 잘 모니터링하고 적절히 튜닝해서 비효율적인 부분들을 줄여야 합니다.

gceasy와 같은 외부 프로파일링 도구를 사용하면 GC를 모니터링하는데 큰 도움을 받을 수 있습니다. 그러나 gceasy를 사용하려면 GC 로그를 서버에서 다운로드 후 이를 외부 분석 환경으로 업로드해야 하고, 이 절차는 꽤 번거로운 일입니다. GC 로그를 실시간으로 처리할 수 있다면 gceasy에서 제공하는 대부분의 차트를 구현할 수 있을 거라고 생각했고 gceasy의 거의 모든 차트를 포함하는 대시보드를 구축하였습니다. 클러스터 관리자들은 KHP 모니터링에 있는 GC 대시보드를 통해 GC 정보를 실시간으로 파악하고, 자바 애플리케이션이 최적의 성능을 유지할 수 있도록 지속적으로 GC를 튜닝하고 있습니다.

마무리하며

지금까지 KHP 모니터링 체계가 메트릭과 로그를 처리하고 시각화하는 방법에 대해서 알아보았습니다. 더불어서 KHP 모니터링을 현재의 형태로 구축하기까지, 개발진이 고민했던 지점들도 함께 소개했습니다.

모쪼록 이와 유사한 시스템을 운영 중이거나 구축을 계획 중인 분들께 조금이나마 도움이 되었길 바랍니다.

2부에서는 KHP 모니터링 체계가 문제 상황을 인지하고 이를 클러스터 관리자에게 전파하는 방법에 대해 자세히 살펴보도록 하겠습니다.

KHP 모니터링과 알림 - 1부