12.5억 개의 시계열과 555조 개의 데이터포인트를 다루는 VictoriaMetrics 아키텍처와 무중단 장비 전환
네이버 검색 서비스를 안정적으로 운영하려면, 수만 대의 물리 서버와 수백만 개의 컨테이너에서 발생하는 메트릭을 실시간으로 수집·저장·조회할 수 있는 대규모 시계열 데이터베이스(TSDB)가 필요합니다.
저희 팀은 이 요구사항을 충족하기 위해 오픈소스 TSDB인 VictoriaMetrics를 선택했습니다. VictoriaMetrics는 Prometheus 호환 API를 제공하면서도 높은 압축 효율과 대규모 클러스터링, 장기 보관을 지원하며, 특히 다음과 같은 특성이 네이버 검색의 요구사항에 부합했습니다.
수평 확장성: vminsert → vmstorage → vmselect 구조로 컴포넌트를 독립적으로 확장 가능
높은 압축 효율: 데이터포인트당 0.92바이트 수준으로 저장해 스토리지 비용 최적화
Prometheus 생태계 호환성: 기존 Prometheus 기반 수집 파이프라인과 Grafana 대시보드를 그대로 활용 가능
네이버 검색은 VictoriaMetrics 클러스터를 5년간 운영해 온 결과, 현재 12.5억 개의 활성 시계열과 555조 개의 데이터포인트를 안정적으로 관리하고 있습니다. 이 글에서는 먼저 인프라의 성장 과정과 현재 아키텍처를 설명하고, 이어서 그 과정에서 마주친 메모리 한계를 어떻게 해결했는지, 그리고 180대 규모의 장비 교체를 어떻게 서비스 중단 없이 마칠 수 있었는지 공유하겠습니다.
인프라 규모와 아키텍처
쿠버네티스 전환과 메트릭 폭증
네이버 검색 인프라는 2022년부터 2026년까지 급격하게 규모가 성장했습니다. 다음 그림은 이 기간의 인프라 규모 성장 추이를 보여 줍니다.
같은 내용을 수치로 정리하면 다음과 같습니다.
항목2022년 1월2024년 1월2026년 1월4년간 증가율물리 서버수만 대수만 대수만 대약 1.9배컨테이너수만 개수만 개수백만 개약 58배
2022년에는 수만 개 수준이던 컨테이너가 4년 만에 수백만 개로 늘었습니다. 특히 2022년부터 2026년 사이에 컨테이너가 58배 증가한 것은 네이버 검색의 쿠버네티스 전환이 본격 가속화된 결과입니다. 하나의 물리 서버에 수십 개의 컨테이너가 배치되고, 각 컨테이너가 독립적으로 메트릭을 생성하면서 수집 대상 시계열도 기하급수적으로 증가했습니다.
이때 문제는 단순한 수집량 증가에 그치지 않았습니다. 쿠버네티스 환경에서는 컨테이너 ID, 파드 이름, 네임스페이스 같은 레이블 조합에 따라 같은 메트릭도 서로 다른 시계열로 저장됩니다. 즉, 컨테이너 증가는 곧바로 메트릭 카디널리티 증가로 이어지고, 이는 검색용 인덱스 크기와 디스크 사용량까지 함께 증가시킵니다.
현재 클러스터 규모
이러한 성장의 결과, 2026년 3월 1일부터 7일까지의 주간 평균 기준으로 네이버 VictoriaMetrics 클러스터는 다음과 같은 규모에 이르렀습니다.
먼저 클러스터 구성과 할당 리소스를 보면 다음과 같습니다.
구분vmstoragevminsert · vmselect비고규모180대 (Hot 120대, Warm 60대)256개 컨테이너-CPU8,640코어2,048코어전체 코어 수메모리약 88TB약 3.75TB전체 가용 메모리디스크약 2.77PB약 2TB (임시 스토리지)전체 할당 스토리지
이어서 실제 시계열 규모와 처리량을 보면 다음과 같습니다.
항목값설명실제 디스크 사용량약 510TB실제 데이터 저장량활성 시계열12.5억 개최근 1시간 안에 수신 중인 시계열시계열 교체율(churn rate)초당 약 8,700개초당 새로 생기는 시계열 수24시간 신규 시계열약 7.4억 개24시간 동안 생성된 신규 시계열 총합전체 데이터포인트555조 개Hot과 Warm을 합친 전체 저장량수집 처리량초당 약 2,000만 개클러스터 전체 수집 처리량데이터포인트당 저장 크기0.92바이트압축 후 평균 저장 크기
이 수치에서 가장 눈에 띄는 점은 555조 개의 데이터포인트가 약 510TB에 저장된다는 사실(데이터포인트당 0.