프로메테우스(Prometheus) 의 고 가용성 - Thanos

Prometheus 의 한계

Prometheus는 단일 노드 시스템으로 설계되어 있어 클러스터링 구조를 직접 지원하지 않아서,

다음과 같은 문제가 있습니다.

• 확장성 문제
  • 단일 노드에서 모든 메트릭을 처리하려 할 때 노드의 자원이 고갈되어 성능 저하를 초래할 수 있다.
  • 대규모 인프라에서 많은 수의 메트릭을 수집하고 처리하는 데 있어 성능 저하와 저장소 부족 문제가 발생할 수 있다. 외부 스토리지 연결이 필요하다.
• 고가용성 문제
  • 단일 노드에서 발생하는 장애나 다운타임이 생겨 프로메테우스 서버가 내려가면 그 시간 동안에는 메트릭을 수집할 수 없다.
  • 볼륨이 AWS EBS 를 사용해도 단일 노드에서만 연결이 가능하다. 연결 노드에 다운 타임이 발생하면 메트릭을 가져올 수 없다.

즉 대규모 인프라를 감당하지못함+ 다운될 경우 그 시간 동안 메트릭 수집 불가

 

 

Thanos의 등장

thanos 홈페이지에 떡하니 있는 Prometheus

Thanos는 Prometheus의 확장 솔루션으로, 장기 데이터 저장, 고가용성(HA), 다중 클러스터 모니터링 및 글로벌 시계열 데이터 조회를 가능하게 해주는 오픈소스 프로젝트입니다.

thanos 는 홈페이지 대문에 적혀있는 만큼 Prometheus를 겨냥하고 나왔다고 할 수 있습니다.

 

 

그래서 어떻게 문제를 해결하는가?

파란 네모가 타노스 구성 컴포넌트이다.

• Thanos Sidecar : Prometheus에 연결되어 메트릭 데이터를 쿼리하고 클라우드 스토리지에 업로드한다. 노드마다 사이드카가 연결되며 외부 스토리지 저장을 통해 확장성을 개선시키는 역할의 컴포넌트이다.
• Thanos Store Gateway : 외부 스토리지에 메트릭 데이터를 읽어 Thanos Query로 전달한다. 해당 컴포넌트를 통해 외부 스토리지에서 과거 데이터도 쿼리할 수 있게 된다.
• Thanos Query : 사용자 쿼리를 요청 처리하며 짧은 시간의 데이터는 타노스 사이드카에서 가져오며, 오래된 데이터는 스토어 게이트웨이를 통해 외부 스토리지에서 가져온다. Prometheus Query API를 구현하여 사용자가 기존의 Prometheus 쿼리를 그대로 사용할 수 있게 한다.

 

 

반면 유사한 오픈소스로 Grafana의 Mimir프로젝트가 있습니다.

이는 Thanos와 매우 유사하지만 몇몇 평가에선 Mimir가 약간더 최적화가 잘 되어있다고 합니다. (아무래도 Grafana 그룹이다보니..)

둘다 비슷한 기능이지만 어느쪽에 더 친화적인가가 차이인듯 합니다.

Thanos = Prometheus친화적

Mimir = Grafana친화적

(주관적인 생각)