APM 수집 - Service Discovery에 관하여(metricbeat autodiscovery)

 

모니터링 업무 중 Kubernetes 환경에서 동작하는 application의 APM을 수집하기 위해 고민했던 포인트와 해결 방법을 기록한다.

 

일단, VM 환경과 Kubernetes 환경이 어떻게 다른지부터 이해하고 가야한다.

사실 방금 위 문장을 읽었을때 이상하다고 느꼈다면, 어느 정도 이해도가 있다고 판단되기 때문에 이 부분은 넘어가도 될 것 같긴하다.

 먼저 VM 환경에서 생각해보자. (엄밀히 말하면 오픈스택 환경이라고 표현하는 것이 맞겠다.) APM을 수집하기 위해서 prometheus에서 제공하는 라이브러리를 각 application에 import하고, /metrics라는 API를 열었다. 그 다음으로는 주기적으로 이를 scraping하는 기능이 필요한데, 사실 자체 구축하는 것도 좋긴 하지만 해당 기능이 이미 metricbeat에 구현이 되어 있기 때문에 metricbeat를 활용하여 /metrics API를 설정하는 시간에 따라 주기적으로 호출한다. 그리고 해당 결과 즉, return 값은 Kafka로 보내진다. 이와 같은 과정이 VM에서는 전혀 어려울 것이 없다. 보통 VM을 관리하기 위해 기업에서는 오픈스택을 많이 사용하는데, 오픈스택에서 오토스케일링이 되는지 안되는지는 모르지만 높은 비율로 오토스케일링을 지원하지 않는다. (적어도, 우리 회사는 오토스케일링 지원이 안됨. 오픈스택의 문제인지, 이를 운영하는 사람의 문제인지는 모르겠다.) 한 마디로 VM 환경은 정적 환경이고 간단하게 VM마다 agent(metricbeat)을 같은 형상으로 설치해주면 된다.

 그런데 Kubernetes 환경에서는, 문제가 복잡해진다. 애초에 컨테이너와 파드라는 개념을 도커와 쿠버네티스에서는 언제든지 죽을 수 있는 개념으로 정의하기 때문에 실제 application은 아무런 이유가 없이 재배치 될 수가 있고, 또 오토스케일링 기능을 적용하기 때문에 언제든지 pod의 수가 정해진 HPA의 수에 따라 증가할 수 있따. 즉, APM을 모니터링해야되는 application의 수와 위치가 동적으로 변화한다는 뜻이 된다. 이렇게 동적으로 변하는 application을 개발자가 운영자가 항상 찾아보며 agent를 설치해줄 수 없는 노릇이기 때문에, 가장 먼저 떠오르는 방법은 sidecar 패턴을 이용하는 방법이다. sidecar 패턴이란 특정 application을 pod로 배포할 때, 모니터링과 같이 사이드 기능을 하는 컨테이너를 함께 배포하는 것인다. 하지만 sidecar 패턴의 원리를 생각해보면 application의 pod 수 마다 모니터링 기능을 하는 컨테이너가 같이 생성된다는 뜻이 된다. 아무리 작은 기능을 하는 컨테이너라도 자원을 많이 차지할 수 밖에 없다.

 그래서 daemonset을 활용한다. daemonset은 Kubernetes 클러스터를 구성하고 있는 노드에 단 하나씩 배포되는 컨테이너이고, 각 노드에 생성된 pod를 담당한다. 이 daemonset 개념에 metricbeat를 대입하면, Kubernetes 클러스터를 구성하고 있는 노드에 하나씩 metricbeat container를 생성하고, 각각의 metricbeat container는 각 노드에 떠있는 pod를 검사하여 특정 조건에 맞는 pod를 판별하고 조건이 맞는 pod에 /metrics API로 APM 수집 메트릭을 호출한다. 여기서 pod를 판별하는 기준으로는 annotation을 사용한다.

 metricbeat에서는 이러한 기능을 autodiscovery로 제공한다. 아래는 metricbeat의 상세 yaml 파일이다.