VictoriaMetrics vs Mimir, 1년 굴려보고 뭘 쓸까
작년 이맘때쯤 우리 팀은 Prometheus 단일 인스턴스로 버티는 게 한계에 다다랐다. 노드 800대, 활성 시리즈 3천만개를 넘기면서 메모리는 80GB를 넘어가고, 재시작 시 WAL 리플레이에 20분이 걸렸다. 장기 저장도 필요했다. 그래서 VictoriaMetrics 클러스터와 Grafana Mimir 두 개를 PoC로 띄워서 6개월씩 돌려봤고, 결국 메인을 VictoriaMetrics로 갔다. 이 글은 그 1년치 의사결정 기록이다.
근데 미리 말해두면, 이건 "VM이 무조건 좋다"는 글이 아니다. 우리 팀 상황에 VM이 맞았던 거지, 다른 팀은 Mimir가 더 나을 수 있다. 그 경계가 어디인지 정리해보려고 한다.
리소스 사용량 차이가 진짜였다
벤치마크 자료들이 "VM이 메모리 5배 효율"이라고 떠드는 걸 처음엔 솔직히 반신반의했다. 벤더 마케팅 아닌가 싶었거든. 근데 같은 시리즈 3천만개를 두 시스템에 동시에 인입해보니, 그 격차는 진짜였다.
우리 환경 기준으로 비교하면 이렇다.
- Mimir: ingester 6개에 메모리 32GB씩 + distributor, query-frontend, store-gateway, compactor, ruler까지 합쳐서 전체 약 290GB RAM
- VictoriaMetrics: vmstorage 3대에 32GB씩 + vminsert, vmselect 각 2대 16GB. 전체 약 150GB RAM
엇비슷한 워크로드에 거의 절반이다. CPU도 비슷한 비율로 차이가 났다. 이게 6개월 누적되면 클라우드 청구서에서 무시 못할 숫자다.
이유는 아키텍처가 단순하기 때문인 것 같다. Mimir는 distributor → ingester → store-gateway → query-frontend → querier → compactor → ruler 같은 컴포넌트가 7개쯤 된다. 각자 따로 스케일되고 각자 메모리를 먹는다. VM은 vminsert / vmstorage / vmselect 셋이면 끝이다. 같은 일을 하는데 부품이 적으니 합계가 적게 나오는 거다.
운영 복잡도, 이게 결정적이었다
리소스 차이보다 더 컸던 건 운영 부담이다.
Mimir 장애가 한번 났을 때 디버깅 흐름이 이랬다. "메트릭이 안 보인다" 알람 → distributor 로그 확인 → 정상 → ingester 헬스체크 → 한 replica가 OOM → 근데 다른 replica로 페일오버는 됐는데 query는 왜 안 되지 → store-gateway의 블록 인덱스 캐시가 stale → 캐시 무효화 → 그래도 안 됨 → consistency-checker가 한 ingester를 unhealthy로 보고 있음 → 결국 ring 상태 확인하러 들어감. 새벽에 이걸 따라가다 보면 "내가 모니터링 시스템을 모니터링하고 있구나" 싶다.
VM도 장애가 없는 건 아니다. 한번은 vmstorage 디스크가 가득 차서 -storageDataPath 쪽이 read-only로 떨어진 적 있다. 근데 디버깅이 단순했다. 컴포넌트 3개 중 어디가 빨간지 보고, 로그 한군데만 보면 됐다. 30분이면 원인 잡혔다.
이게 SRE 입장에서 보면 큰 차이다. 우리 팀은 인프라 인원이 4명인데, Mimir였으면 한명은 거의 풀타임으로 모니터링 스택만 봐야 했을 거다.
그럼 언제 Mimir가 더 나을까
그렇다고 Mimir가 별로다는 얘기는 아니다. 솔직히 두 가지 케이스에선 Mimir가 더 맞다.
첫째, 진짜 멀티테넌트가 필요한 경우. 우리는 회사 전체에서 모니터링 클러스터 하나만 운영하니까 멀티테넌트가 큰 의미가 없었다. 근데 SaaS 회사처럼 고객별로 격리된 메트릭 공간이 필요하면 Mimir의 tenant ID 기반 격리가 훨씬 잘 되어 있다. VM도 -httpAuth.tenantID로 멀티테넌시를 지원하긴 하는데, Mimir 쪽이 query limit이나 ingest rate limit 같은 세밀한 제어가 더 풍부하다.
둘째, Grafana 스택에 모든 걸 묻은 경우. Mimir + Loki + Tempo + Pyroscope를 하나의 운영 모델로 통합해서 쓰는 조직이면, Mimir의 일관성이 이득이다. helm chart도 비슷하고, alloy 같은 collector도 공통이고, 운영 노하우가 그대로 이전된다. 우리는 어차피 Loki를 안 써서 이 시너지가 없었다.
마이그레이션에서 고생한 부분
PoC에서 본격 도입으로 넘어갈 때 두 번 삽질했다.
첫번째는 PromQL 호환성. VM은 MetricsQL이라는 자체 확장 쿼리 언어를 쓰는데, PromQL과 99% 호환이라고 광고한다. 근데 그 1%에 우리 팀의 핵심 알람 룰이 걸렸다. histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) 같은 표준 쿼리는 잘 도는데, 일부 topk()와 bottomk() 동작이 미묘하게 다른 경우가 있었다. 정확히 말하면 NaN 처리 방식이 다른 거였다. 이 부분은 결국 룰을 살짝 수정해서 해결했지만, 마이그레이션 전에 모든 알람 룰을 두 시스템에 동시에 돌려보고 결과를 비교하는 스크립트를 만들어야 했다.
두번째는 remote_write 백압(backpressure) 동작이다. Mimir는 distributor가 부하 받으면 429를 잘 돌려주는데, VM의 vminsert는 응답 패턴이 살짝 달랐다. Prometheus의 remote_write 큐가 다른 패턴으로 쌓이는 걸 보고 처음엔 데이터 손실인 줄 알았다. 알고 보니 vminsert가 입력 측의 batch 사이즈를 더 크게 받아서 단순히 큐 길이가 다르게 보이는 거였다. prometheus_remote_storage_samples_pending 메트릭만 보면 안 되고 실제 수신 측 카운터도 함께 봐야 한다.
결국 우리는 VM을 골랐다
1년 운영해보고 내린 결론은 이렇다. 인프라 인원이 5명 이하이고, 멀티테넌트가 강하게 필요하지 않다면 VictoriaMetrics가 ROI가 더 좋다. 운영 부담이 절반 이하고, 같은 하드웨어로 더 많은 시리즈를 처리한다. 압축도 더 공격적이라서 100GB SSD에 1년치 메트릭이 들어간다는 말이 과장이 아니다.
반대로 조직 규모가 크고, 여러 팀에 격리된 환경을 제공해야 하고, Grafana 스택을 풀로 가져가는 조직이면 Mimir 쪽이 장기적으로 맞을 수 있다. 그 경우 운영 복잡도는 더 큰 조직 규모로 흡수되니까.
여기까지 쓰고 보니, 결국 도구 선택은 도구 자체보다 우리 팀이 어떤 운영 모델을 갖고 있는지에 따라 갈리는 것 같다. 6개월씩 진짜로 굴려본 사람만이 그 차이를 안다. 벤치마크 숫자만 보고 결정하면 다음 분기에 후회한다.
혹시 두 시스템 다 운영해보신 분 있으면 어떤 기준으로 고르셨는지 댓글로 알려주세요. 특히 Mimir로 멀티테넌트 잘 굴리는 케이스가 궁금합니다.