02 · 네이버 검색의 대규모 메트릭 저장소, VictoriaMetrics 운영기 1편 (2026-04)

네이버 검색 인프라는 수만 대의 물리 서버와 수백만 개의 컨테이너에서 나오는 메트릭을 실시간으로 수집·저장·조회해야 합니다. 그 요구를 받아 낼 오픈소스 TSDB로 VictoriaMetrics를 골랐습니다. 배경과 컴포넌트 구조는 /monitoring/victoriametrics/concepts/01-tsdb-and-victoriametrics/에서 다룹니다. 여기서는 D2 원문 1편을 정리합니다. 5년간 이 클러스터를 운영하며 마주친 인프라 성장, 메모리 한계, 180대 규모의 무중단 장비 전환을 담은 글입니다. 같은 팀이 이어서 공유한 2편(2026-07, 3단계 최적화)은 /monitoring/victoriametrics/by-source/04-2026-07-three-stage-optimization/에서 다룹니다.

인프라 규모와 아키텍처

쿠버네티스 전환과 메트릭 폭증

2022년부터 2026년까지 네이버 검색 인프라는 급격히 성장했습니다.

컨테이너는 4년 만에 약 58배 늘었습니다. 쿠버네티스 전환이 본격 가속화된 결과입니다. 물리 서버 한 대에 수십 개의 컨테이너가 올라가고 각 컨테이너가 독립적으로 메트릭을 만들면서 수집 대상 시계열도 기하급수적으로 늘었습니다. 문제는 수집량 증가에 그치지 않았습니다. 컨테이너 ID, 파드 이름, 네임스페이스 같은 레이블 조합이 달라지면 같은 메트릭도 서로 다른 시계열로 저장됩니다. 그래서 컨테이너가 늘면 메트릭 카디널리티도 늘고 검색용 인덱스 크기와 디스크 사용량까지 함께 밀려 올라갑니다.

현재 클러스터 규모

아래 수치는 2026년 3월 1일부터 7일까지의 주간 평균 기준입니다. 먼저 클러스터 구성과 할당 리소스입니다.

이어서 실제 시계열 규모와 처리량입니다.

555조 개의 데이터포인트가 약 510TB 안에 들어갑니다. 데이터포인트당 0.92바이트까지 줄이는 압축이 이 규모를 지탱합니다. 그 원리는 /monitoring/victoriametrics/concepts/04-storage-and-compression/에서 다룹니다. 신규 시계열은 하루 약 7.4억 개씩 생깁니다. 쿠버네티스 환경에서 컨테이너가 그만큼 자주 생기고 사라집니다.

Hot/Warm 2계층 아키텍처

이 규모에서 가장 먼저 부딪히는 문제는 성능을 지키면서 비용을 감당하는 일입니다. 전부 SSD에 두면 조회는 빠르지만 비용이 빠르게 불어나고 HDD만 쓰면 장기 보관 비용은 줄어도 실시간 모니터링에 필요한 쿼리 성능을 보장할 수 없습니다. 그래서 Hot과 Warm을 각각 독립된 VictoriaMetrics 클러스터로 세웠습니다. 쓰기 경로에서는 두 클러스터에 같은 데이터를 동시에 넣고 읽기 경로에서는 조회 기간에 따라 적절한 계층으로 분기합니다.

• vmagent의 이중 쓰기(dual write): 수집한 메트릭을 Hot과 Warm 두 클러스터의 vminsert로 동시에 보냅니다. 각 원격 쓰기(remote write) 대상마다 큐를 따로 두므로 한쪽에 장애가 생겨도 다른 쪽 전송에는 영향이 없습니다.
• 시간 범위 기반 분기: 클라이언트 API가 요청 시간 범위를 보고 최근 12개월 이내 쿼리는 Hot으로, 그 이전 기간의 쿼리는 Warm으로 보냅니다. 사용자가 쓰는 쿼리 인터페이스는 하나이므로 이 분기를 의식할 필요가 없습니다.

독립 클러스터 두 개로 완전히 떼어 두면 Hot과 Warm 사이의 장애 전파를 막을 수 있습니다. 각 계층의 리소스를 따로 관리·확장할 수 있다는 운영상 이점도 따라옵니다. 이 설계를 더 깊이 살펴보고 싶다면 /monitoring/victoriametrics/practice/02-operations-at-scale/의 멀티버스·2계층 논의를 참고합니다.

메모리 한계와 무중단 장비 전환

vmstorage는 활성 시계열 정보를 메모리에 캐시해 두고 검색을 빠르게 처리합니다. 하지만 카디널리티가 급격히 늘면서 기존 장비로는 이를 안정적으로 감당하기 어려워졌습니다. 곧 문제가 드러났습니다.

• indexdb 메모리 사용량이 늘면서 OOM(Out of Memory) 위험이 높아졌습니다.
• 메모리 여유가 줄어 캐시 효율이 떨어졌고 그만큼 디스크 I/O 부담이 커졌습니다.
• 메모리 압박과 디스크 I/O 증가는 쿼리 지연으로 이어졌습니다.

VictoriaMetrics 공식 문서는 이런 상황을 피하려면 전체 노드 RAM의 50%를 여유 공간으로 남겨 두라고 권장합니다.

“50% of free RAM across all the node types for reducing the probability of OOM crashes and slowdowns during temporary spikes in workload.”

메인테이너의 추가 설명에 따르면 이 수치는 RSS anonymous 메모리를 기준으로 한 보수적인 권장값입니다.

“The 50% recommendation is for RSS anonymous. It is conservative, but it is very likely you’d see no problems with stability if you’ll get 50% RSS anon usage.”

기존 장비에서는 카디널리티가 늘어나는 만큼 RSS anonymous 메모리 사용률도 꾸준히 올라 권장 수준의 여유를 안정적으로 유지하기 어려웠습니다. 그래서 vmstorage 장비 메모리를 128GB에서 512GB로 늘리기로 결정했습니다. 사양 업그레이드 자체보다 더 중요한 과제는 무중단 전환이었습니다. 이 VictoriaMetrics 클러스터는 네이버 검색 전체의 핵심 모니터링 인프라입니다. 장비 교체 중에 메트릭이 누락되거나 알림이 멈추면 곧바로 서비스 안정성에 영향을 줍니다. 180대 노드에 걸친 대규모 장비 교체를 서비스 영향 없이 끝내야 했습니다. 계층별 특성에 맞춰 Hot과 Warm에 서로 다른 전환 전략을 설계했습니다.

Hot Tier: 랑데부 해싱을 고려한 무중단 장비 추가

Hot Tier는 보관 기간이 12개월로 상대적으로 짧았습니다. 그래서 기존 128GB 장비군을 그대로 둔 채 512GB 신규 장비군을 붙이고 기존 장비의 데이터가 만료되면 순차적으로 걷어내는 방식을 택했습니다. 절차는 3단계입니다.

1. vmselect가 기존 장비와 신규 장비를 모두 읽도록 설정
2. vminsert는 신규 장비에만 새 데이터를 쓰도록 수정
3. 12개월이 지나 기존 장비 데이터가 모두 만료된 시점에 vmselect에서도 기존 장비 제거

절차는 단순해 보이지만 2단계에 함정이 있습니다. vminsert는 랑데부 해싱으로 저장 노드를 정하고 -replicationFactor=N 설정으로 복제본 위치를 정합니다. 이 배치 방식을 이해하지 못한 채 -storageNode 설정 목록만 바꾸면 전환 과정 자체가 장애를 일으킬 수 있습니다. 이 샤딩·복제 메커니즘의 원리는 /monitoring/victoriametrics/concepts/03-ingestion/에서 자세히 다룹니다.

# 변경 전
-storageNode=old-A, old-B, ..., old-E

# 변경 후 (한 번에 교체) — 위험
-storageNode=new-A, new-B, ..., new-E

이 문제를 피하려고 기존 -storageNode 목록에 신규 장비를 점진적으로, 그것도 역순으로 추가하는 방식을 택했습니다. 랑데부 해싱의 특성상 노드를 1대씩 추가하면 일부 시계열만 새 장비로 옮겨 가므로 시계열 교체율 증가를 제한할 수 있습니다. 복제본이 전달되는 순서 탓에 신규 장비를 붙이는 순서에 따라 기존 장비에 추가 부하가 집중될 수 있었습니다.

# 순방향 추가 — new-A가 primary가 되면 복제는 old-A, old-B로 향한다
Step 1  -storageNode=old-A, old-B, ..., old-E, new-A
Step 2  -storageNode=old-A, old-B, ..., old-E, new-A, new-B
Step 3  -storageNode=old-A, old-B, ..., old-E, new-A, new-B, new-C

# 역순 추가 — 신규 장비를 목록 뒤에서부터 한 대씩 붙인다
Step 1  -storageNode=old-A, old-B, ..., old-E, new-E
Step 2  -storageNode=old-A, old-B, ..., old-E, new-D, new-E
Step 3  -storageNode=old-A, old-B, ..., old-E, new-C, new-D, new-E
# 이후 신규 장비 추가 반복

Warm Tier: vmbackup과 vmrestore를 이용한 무중단 마이그레이션

Warm Tier는 성격이 달랐습니다. 보관 기간이 36개월이라 Hot Tier처럼 기존 장비와 신규 장비를 함께 두고 데이터 만료를 기다리면 두 장비군이 3년 동안 공존해야 합니다. 장비당 수십 TB, 전체로는 수백 TB가 넘는 데이터를 들고 있어 단순 순차 교체만으로는 전체 마이그레이션에 30일 이상 걸릴 것으로 예상됐습니다.

VictoriaMetrics가 제공하는 공식 마이그레이션 도구를 비교해 봤습니다.

• vmbackup · vmstorage 스냅샷을 백업 저장소로 복사 — 운영 중인 vmstorage에 낮은 부하로 스냅샷을 만들 수 있고 증분 백업을 지원합니다. 제약은 없습니다.
• vmrestore · 백업 저장소의 스냅샷을 대상 vmstorage에 복원 — 대용량 데이터를 파일 시스템 수준에서 빠르게 복원할 수 있습니다. 단, 복원 중에는 대상 vmstorage를 중지해야 합니다.
• vmctl · vmselect → vminsert API 호출 — vmstorage를 중지하지 않고 데이터를 옮길 수 있습니다. API 부하가 높고 대규모 환경에서는 속도 한계가 뚜렷합니다.

처음 검토한 안은 vmbackup과 vmrestore로 대부분의 데이터를 옮기고 전환 과정에서 생기는 데이터 공백을 vmctl로 채우는 방식이었습니다. 그러나 555조 개의 데이터포인트를 API 기반으로 다시 읽는 작업은 운영 클러스터에 지나치게 큰 부하를 줍니다. 여기에 -search.maxPointsPerTimeseries 제한까지 있어서 전체 메트릭을 대상으로 1분의 시간 범위조차 조회할 수 없었습니다. vmctl을 배제하고 vmbackup과 vmrestore만으로 무중단 전환을 완성하기로 했습니다. 이렇게 고를 수 있었던 것은 vmbackup의 다음 특성 덕분입니다.

• Instant Snapshot: 운영 중인 vmstorage 성능에 큰 영향을 주지 않으면서 불변 상태의 파일 청크를 직접 복사합니다.
• Incremental Sync: 이미 복사된 데이터가 있으면 변경분만 전송하므로 며칠 동안 쌓인 데이터 공백도 전환 당일에 빠르게 따라잡을 수 있습니다.
• Resumable Transfer: 전송 중 오류가 발생해도 중단된 지점부터 다시 시작할 수 있어, 장비당 수십 TB 단위의 장시간 작업도 안정적으로 이어 갈 수 있습니다.

전체 작업은 안전하게 진행하려고 두 단계로 나눴습니다.

1. 사전 데이터 복제: 전환 당일에 옮겨야 할 데이터 양을 최소화하려고 기존 장비 전체에서 vmbackup을 병렬로 실행해 스냅샷을 만들고 신규 장비에서는 vmrestore로 이를 미리 복원했습니다. 운영 서비스에 영향을 주지 않도록 네트워크 팀과 협의해 장비당 전송 대역폭을 1Gbps로 엄격히 제한했습니다. 복원 상태는 자동화된 검증 스크립트로 확인했습니다. 2021년부터 2024년까지 해마다 임의 시점을 골라 쿼리 결과를 대조했습니다.
2. 세트 단위 점진 전환: 사전 복제 후 남은 데이터 공백만 증분 vmbackup으로 채우면서 전체 장비를 한 번에 바꾸지 않고 세트 단위로 진행했습니다. 세트 하나를 전환할 때는 (1) vminsert에서 해당 세트의 기존 장비를 제외해 새 데이터 유입을 중단하고, (2) 누적된 데이터 공백을 증분 vmbackup/vmrestore로 채우고, (3) vmselect에서 기존 장비를 제거하고 신규 장비를 투입하고, (4) vminsert에 신규 장비를 투입해 실시간 수집을 재개하는 네 단계를 거쳤습니다. -replicationFactor를 고려해 서비스에 영향을 주지 않는 범위에서 이 과정을 세트 단위로 반복하며 Warm Tier 전체를 순차적으로 교체했습니다.

전환 결과

Hot Tier는 역순 추가 전략을 모두 마친 뒤 vminsert에서 기존 장비군을 제거하는 방식으로, Warm Tier는 세트 단위 점진 전환을 반복하는 방식으로 각각 교체를 마쳤습니다. 두 전략은 방식이 달랐지만 수집 누락과 조회 실패 없이 장비를 바꾸는 목표는 같았습니다.

두 계층 모두 서비스 중단 시간 0분, 메트릭 수집 누락 0건으로 교체를 완료했습니다. 교체 기간 동안 알림 공백은 없었고 대시보드 조회 실패도 발생하지 않았습니다. 현재 클러스터는 Hot Tier 120대(SSD, 512GB), Warm Tier 60대(HDD, 512GB)로 안정적으로 돌아갑니다. RSS anonymous 메모리 사용률도 권장 기준보다 충분히 낮아 앞으로 수년간 이어질 카디널리티 증가에도 대응할 수 있는 상태입니다. 성능도 안정적입니다. Hot Tier의 vmselect 기준으로 초당 500건 이상의 레인지 쿼리(range query)를 처리하면서도 p99 응답 시간은 약 300ms 이내를 유지합니다.

이 규모에서는 공식 문서나 커뮤니티에서 바로 참고할 사례를 찾기 어려웠습니다. 소스 코드를 직접 읽고 운영 메트릭으로 가설을 세우고 실제 환경에서 검증하는 과정을 반복해야 했습니다. 랑데부 해싱과 복제 계수의 내부 동작을 이해한 뒤에야 단순한 장비 증설이 아니라 장애를 만들지 않는 전환 전략을 설계할 수 있었습니다. 이 클러스터가 이후 어떤 방향으로 더 최적화됐는지는 후속편인 /monitoring/victoriametrics/by-source/04-2026-07-three-stage-optimization/에서 이어집니다.

출처

• 원문: 네이버 검색의 대규모 메트릭 저장소, VictoriaMetrics 운영기 (네이버 D2, 2026-04-22, 저자: 강지훈·이윤석 / NAVER Metric&Monitoring)
• 원본 저장 파일: 03_기사_6475419_대규모메트릭저장소.md
• 이 문서는 원문 전체(도입의 규모 수치, 쿠버네티스 전환과 카디널리티 폭증, 현재 클러스터 규모·글로벌 사례 비교, Hot/Warm 2계층 아키텍처, 메모리 한계와 128→512GB 전환 배경, Hot Tier 랑데부 해싱 역순 추가, Warm Tier vmbackup/vmrestore 2단계 마이그레이션, 전환 결과)를 반영했습니다.