Prometheus 를 스케일링 하기 위한 Thanos (타노스)

문제 정의 

프로메테우스가 좋은 모니터링 시스템이긴 하지만 두가지 결정적인 문제점을 가지고 있다. 결정적으로 클러스터링 구조를 지원하지 않기 때문에, 확장성과 가용성 문제를 가지고 있다. 

확장성 측면에서는 디스크를 증설하거는 것과 같은 하드웨어 스펙 증설로 어느정도는 해결이 가능하지만 데이타 볼륨이 늘어나고 모니터링 대상이 늘어나면 하나의 프로메테우스 인스턴스로는 감당이 어렵다. 

이런 문제를 해결하는 방법으로는 Federation 이라는 방법을 사용한다. 프로메테우스 인스턴스를 여러개를 기동한 다음에, 중앙에 다른 프로메테우스로 부터 메트릭을 수집하는 다른 프로메테우스를 놓는 방식이고, 데이타 양에 대한 문제는 데이타의 해상도 (예를 들어 전면에 데이타 수집 서버가 10초 단위로 수집 했다면, 중앙 서버에서는 1분 단위로 수집 한다는 등)를 줄이거나 평균이나 합과 같은 대표값을 사용해서 해결할 수 있다. 

다른 문제로는 가용성 문제를 들 수 있다. 프로메테우스는 하나의 서버로 기동되기 때문에 그 서버가 장애로 내려가거나 또는 패치나 서버 리스타트와 같은 유지보수 업무에 의해서 프로메테우스 서버가 내려가더라도 그 시간동안에는 매트릭을 수집할 수 없다는 단점을 가지고 있다. 클러스터링 기능이 없기 때문에 이를 해결하기 위해서는 프로메테우스 인스턴스를 두개 이상 띄운 다음에 같은 대상 시스템으로 부터 매트릭을 수집하는 방식인데, 이렇게 하면, 한 서버가 내려가더라도 다른 서버에 매트릭정보가 수집이 된다.

그러나 역시 불편하고 아키텍쳐가 왠지 제대로 되어 보이지는 않는다.

Thanos (타노스)

그래서 이런 문제를 해결하기 위한 오픈소스가 타노스이다.

기본적인 구조는 다음과 같은 컨셉이다.

여러개의 프로메테우스로 부터 매트릭을 조합해서 타노스에서 전체 프로메테우스의 메트릭을 볼 수 있도록 해주고, 수집된 메트릭을 스케일이 가능한 스토리지에 저장해서 특정 프로메테우스 인스턴스가 다운이 되더라도 그 인스턴스가 담당하는 메트릭을 조회할 수 있도록 해준다. 

개념 이해를 돕기 위해서 아키텍쳐를 살펴보자

Thanos Side car & Querier

먼저 데이타 수집과 쿼리 방식을 보면, 프로메테우스 서버에 타노스 에이전트가 인스톨 되서 데이타를 조회할 수 있게 해준다. 프로메테우스는 데이타를 로컬 디스크에 저장하기 때문에 타노스 에이전트 (Thanos Sidecar : 마이크로 서비스 아키텍쳐 패턴중 사이드카 패턴을 사용하기 때문에, 타노스 사이드카라고 부른다.)는 디스크에 저장된 내용을 읽어서 필요시에 쿼리 엔진 (Thanos Querier)에 전달한다. 

여러개의 프로메테우스 인스턴스가 있더라도, 각 프로메테우스 마다 사이드카 에이전트가 설치되서 쿼리 엔진에 전달하기 때문에 사용자 입장에서는 하나의 타노스 쿼리 엔진(UI)만 가지고도 전체 프로메테우스를 통해서 모든 모니터링 대상의 메트릭을 조회할 수 있도록 되는 것이다. 

HA 지원

기본적인 HA 지원 방식은 기존 방식과 다르지 않다. 아래 그림과 같이 프로메테우스 인스턴스를 동시에 두개를 띄워서 같은 모니터링 대상을 모니터링 해서 각각의 지표를 저장하는 방식이다.

그러면 타노스로 인해 오는 장점은 무엇인가? 기존 방식의 경우에는 프로메테우스 인스턴스 각각의 메트릭으로 모니터링 해야 하지만 타노스는 특정 그룹의 프로메테우스 인스턴스들의 지표들의 하나의 인스턴스로 처리해서 메트릭을 보여준다. 즉 두개의 인스턴스에서 수집된 메트릭을 합쳐서(merge) 해서 볼 수 있도록 해주고, 당연히 같은 모니터링 대상을 모니터링 하기 때문에 중복되는 메트릭 값이 있을 수 있는데, 이 중복 값을 제거 해주는 De-duplication 기능을 가지고 있다. 

오랜된 값 저장

앞에서 언급은 하지 않았지만 프로메테우스의 다른 문제점 중의 하나는 로컬 디스크를 사용하기 때문에 일정 기간이 지난 오래된 데이터는 삭제가 된다. 그래서 오래된 데이터에 대한 조회가 불가능하다. 

타노스 입장에서는 오래된 데이터 저장 문제 뿐만 아니라 여러 프로메테우스를 동시에 모니터링 하게 되면 마찬가지로 메모리와 로컬 디스크의 용량 문제로 인해서 여러 프로메테우스를 모니터링 할 수 없는 문제가 발생하는데, 이를 해결하기 위해서 타노스는 외부 스토리지를 사용한다. 

프로메테우스에서 수집된 데이타는 2시간 정도 메모리에 저장이 되었다가 로컬 디스크로 덤프가 된다. 저장된 파일을 타노스 에이전트가 수집해서 외부 스토리지에 저장한다. 외부 스토리지는 Ceph와 같은 분산형 파일 시스템이나 Google Cloud Storage, AWS S3와 같은 클라우드 오브젝트 스토리지를 사용한다. 

그리고 쿼리 엔진에서 근래의 데이타를 조회할때는 프로메테우스 인스턴스에 설치된 타노스 사이드카 에이전트를 통하지만 오래된 데이터는 스토리지에 저장된 데이터는 Thano Storage Gateway라는 컴포넌트를 통해서 조회된다. 이 컴포넌트는 스토리지에 저장된 데이타를 Storage API를 통해서 쿼리엔진과 통신 하는 역할을 한다. Gateway는 단순 쿼리를 API로 저장하는 역할뿐만 아니라 중간에 캐쉬를 제공하여, 빠른 응답 시간을 제공한다. 

이 구조를 이용함으로써 메트릭 데이터의 보관 주기를 늘릴 수 있게 된다. 

스토리지에 저장된 메트릭을 장기 보관하게 되면, 디스크 용량에 대한 문제도 있지만 아주 오래된 데이타(1~2년전)의 데이터를 조회하고자 하면, 많은 데이터를 스캔해야하기 때문에 성능에 있어서 많은 문제가 생길 수 있다. 그래서 스토리지에 저장된 데이타를 관리하는 컴포넌트로 Compactor 라는 컴포넌트가 있다. 기본적으로 데이타 파일을 압축할 뿐만 아니라, 다운 샘플링을 하는데, 다운 샘플링이란, 매트릭이 1분 단위로 샘플링 되었다면, 10분이나 1시간 단위로 샘플링 기준을 다운해서 (해상도를 낮춰서) 전체 데이타 저장 용량을 낮추는 방법이다. 

이외에도 Alert과 룰 관리, UI를 관리하는 Thanos Ruler 라는 컴포넌트가 있으나 여기서는 자세히 설명하지 않는다. 상세한 설명은 타노스 공식 문서를 참고하기 바란다. https://thanos.io

사실 프로메테우스의 한계를 해결하기 위해서 오픈소스 쪽에서 타노스가 좋은 솔루션이기는 하지만, 개인적으로 운영환경에 올린다면 이렇게 복잡한 설정 대신 프로메테우스를 앞에 놓고 (구글 클라우드 엔지니어니까는) 뒤에 타노스 대신 구글 스택 드라이버를 놓는 것이 여러모로 편하겠다는 생각은 좀 든다. https://cloud.google.com/monitoring/kubernetes-engine/prometheus

타노스 온라인 튜토리얼 https://katacoda.com/bwplotka/courses/thanos

참고 자료 : https://www.youtube.com/watch?v=Fb_lYX01IX4