Thanos vs Mimir vs VictoriaMetrics, 뭘 쓸까
Thanos vs Mimir vs VictoriaMetrics, 뭘 쓸까
Prometheus를 몇 년 쓰다 보면 결국 한 번은 마주치는 벽이 있다. 로컬 TSDB에 15일치 담아두는 걸로는 부족해지는 시점. 팀에서 "작년 이맘때 CPU 트렌드 어땠어요?"라고 물어보는데 답을 못 하고, 알림 튜닝하려고 6개월 전 데이터 뒤지려니 이미 사라지고 없다. 이때부터 장기 스토리지 얘기가 시작된다.
선택지는 사실상 셋으로 좁혀진다. Thanos, Mimir, VictoriaMetrics. 이 글은 우리 팀이 세 개를 다 만져보고 하나로 정착한 과정 정리다. 절대적인 정답은 없다는 말을 먼저 해두고 싶다. 근데 그렇다고 "상황에 따라 다릅니다"로 끝내는 글도 별로 도움이 안 되니까, 어떤 상황에서 뭘 골랐고 왜 그랬는지 최대한 구체적으로 적어보려 한다.
뭐가 어떻게 다른가
세 개가 같은 문제를 푸는데 접근 방식이 꽤 다르다.
Thanos는 사이드카 모델이다. 기존 Prometheus 옆에 사이드카를 붙여서 오브젝트 스토리지(S3/GCS)로 블록을 밀어 넣는다. Prometheus 쪽 write path는 안 건드린다. Store Gateway, Compactor, Querier가 오브젝트 스토리지 위에서 동작한다. 지금 굴리는 Prometheus를 바꾸기 싫을 때 자연스럽게 얹을 수 있다.
Mimir는 Cortex에서 파생된, 처음부터 스케일아웃을 전제로 만들어진 놈이다. Distributor, Ingester, Store Gateway, Querier, Compactor... 컴포넌트 개수가 꽤 된다. 그래도 이걸 감수하는 이유는 멀티테넌시다. X-Scope-OrgID 헤더로 테넌트를 분리하고, 테넌트별 quota와 rate limit을 딱딱 걸 수 있다. 여러 팀에 관측성을 서비스로 제공하는 조직에 딱 맞는다.
VictoriaMetrics는 아예 새로 짠 TSDB다. 단일 바이너리로도 굴러가고, 클러스터 모드도 있다. 자체 컬럼 스토어와 MetricsQL(PromQL 슈퍼셋)을 쓰는데, 실측 벤치에서 같은 워크로드에 Mimir 대비 메모리 1/5, CPU 1.7배 적게 쓴다는 결과가 계속 나온다. 최근에 나온 Greptime의 2026년 6월 비교 글에서도 VM의 리소스 효율은 다른 두 개랑 비교가 안 될 정도라고 못을 박는다.
우리 팀이 각각 얼마나 굴려봤나
먼저 Thanos부터. 노드 40대짜리 클러스터 셋을 운영하던 시절, Prometheus HA 페어에 사이드카 붙여서 S3로 쏘는 구성으로 1년 정도 굴렸다. 좋았던 점은 도입 부담이 정말 작았다는 거다. 기존 Prometheus rule, dashboard, alertmanager 세팅을 하나도 안 건드리고 그냥 사이드카만 붙였다. 힘들었던 건 Store Gateway 캐시 튜닝이었다. index-cache 크기랑 chunk-pool 잡느라 몇 번 삽질했다. 특히 --index-cache-size 기본값으로 두면 큰 시계열 쿼리 돌릴 때마다 OOM이 나서 P1 알림이 새벽에 두어 번 울렸다. 그리고 Compactor. 얘가 downsampling까지 담당하는데, 하루 넘게 걸리는 compaction job이 중간에 죽으면 다시 처음부터 도는 케이스가 있어서 이걸 감시하는 알림을 따로 만들어야 했다.
Mimir는 관측성 팀이 생기면서 3개월 정도 파일럿을 돌렸다. 여러 서비스 팀 메트릭을 한 클러스터에 몰아넣고 각 팀에 테넌트 하나씩 배정하는 구조. 이게 정말 잘 됐다. 팀 A의 잘못 짠 recording rule이 팀 B에 영향을 안 준다. 근데 운영 난이도가... 컴포넌트가 많다 보니 하나 문제 생겼을 때 어디부터 봐야 할지 감이 잘 안 온다. Ingester가 죽으면 hash ring 재분배가 일어나는데 이게 몇 분 걸리는 동안 짧게 write failure가 튀기도 했다. Grafana Labs 문서를 아무리 봐도 실제 프로덕션 이슈에 그대로 매핑되는 케이스가 잘 없어서, 사내에 Mimir 잘 아는 사람 하나는 반드시 있어야 한다는 결론이 나왔다.
VictoriaMetrics는 두 번째 서비스에서 처음부터 도입했다. 단일 바이너리 모드로 시작해서, 트래픽 늘어난 뒤에 cluster 모드로 갈아탔다. 첫 인상은 "이렇게 조용해도 되나" 싶을 정도였다. 리소스 사용량이 정말 적다. Prometheus + Thanos 조합에서 넘어왔을 때 EC2 요금이 절반 넘게 떨어졌다. vmagent로 Prometheus를 대체하니 remote_write 큐 관리 이슈도 사라졌다. 단점은 두 개 정도. 하나는 커뮤니티가 Grafana/CNCF 진영보다 작다는 거. Stack Overflow에 질문 올리면 답이 잘 안 달린다. 다른 하나는 MetricsQL이 PromQL 슈퍼셋이라 대부분 잘 도는데, 몇몇 recording rule이나 alerting rule에서 미묘하게 다른 동작이 나온 적이 두어 번 있었다. 대세엔 영향 없지만 알고는 있어야 한다.
그래서 어떻게 골라야 하나
우리 팀의 결론은 이렇다.
지금 Prometheus를 잘 쓰고 있고 그냥 장기 저장만 필요한 상황이면 Thanos가 여전히 무난한 첫 걸음이다. 이미 굴러가는 Prometheus를 안 건드리는 게 가장 큰 장점이고, 트러블슈팅 자료도 인터넷에 제일 많다. 다만 Store Gateway/Compactor 운영이 은근 손이 간다는 걸 각오해야 한다.
여러 팀에 관측성을 서비스로 제공해야 하고, distributed systems 운영에 자신 있는 인력이 팀에 있다면 Mimir가 답이다. 근데 이 두 조건이 다 맞아야 한다. 한쪽만 맞으면 후회한다. 특히 인력. Mimir는 혼자 굴리면 안 되는 시스템이라는 느낌이 강하다.
메트릭만 다루면 되고 리소스 비용을 정말 줄이고 싶다면 VictoriaMetrics가 진심으로 좋다. 우리 팀이 최근 신규 클러스터엔 다 VM으로 간다. 단일 바이너리로 시작해서 필요하면 cluster로 갈아탈 수 있는 유연성도 크다. 다만 사내에 VM 도입한 첫 팀이 되는 부담은 있다. 참고할 사내 표준 대시보드나 알림 템플릿이 없으니까.
한 가지 덧붙이자면, "PromQL이 아니라 로그/트레이스까지 같이 봐야 한다"는 요구가 있으면 그건 이 세 개 비교의 축이 아니다. 그 경우는 Grafana LGTM 스택으로 갈지, OpenTelemetry Collector로 통합할지 같은 다른 결정이 앞선다. 여기선 순수 메트릭 장기 저장 얘기만 한다.
아직 검증 중인 것
우리 팀에서 최근 붙어보고 있는 건 VM cluster 모드에서 vmstorage 노드 수를 어디까지 줄일 수 있냐는 문제다. 리소스 여유가 워낙 많아서 노드 수를 줄여도 여유가 있어 보이는데, 스토리지 리밸런싱이 어떻게 도는지 프로덕션 규모로는 아직 확신이 없다. 이건 좀 더 데이터 쌓이면 별도 글로 정리해보려 한다.
혹시 세 개 다 굴려보시고 다른 결론 나신 분 있으면 댓글로 남겨주세요. 특히 Mimir 장기 운영 경험 쪽이 궁금합니다.