02 · 초대규모 운영기 — 멀티버스와 무중단 장비 전환

네이버 검색은 5년에 걸쳐 VictoriaMetrics를 굴리며 12.5억 시계열·555조 데이터포인트·180노드라는 초대규모에 도달했습니다. 그 현장 이야기입니다. 단일 클러스터가 무너지는 지점, 여러 클러스터로 쪼갠 “멀티버스”, Hot/Warm 2계층, 180대를 무중단으로 갈아 끼운 전환 설계를 다룹니다.

관련 문서: 개념 02 아키텍처, 개념 03 수집, 개념 04 저장·압축, 개념 05 쿼리·운영 컴포넌트, 01 카디널리티

대혼돈의 멀티버스 — 멀티클러스터 운영기

SingleNode에서 Cluster로

출발점은 SingleNode 모드였습니다. 바이너리 하나가 모든 기능을 담당하니 구축도 사용도 간편했습니다. VM 특유의 최적화 덕에 Prometheus보다 빠른 성능도 체감했습니다. 대가는 구조였습니다. 모든 데이터를 하나에 넣고 쓰다 보니 이 SingleNode가 다운되면 네이버 검색 전체의 모니터링이 중단되는 단일 장애점(SPOF)이 됐습니다.

이 SPOF를 극복하려 Cluster 모드로 옮겼습니다. 저장(vmstorage)·읽기(vmselect)·쓰기(vminsert) 세 컴포넌트로 나뉘는 구성입니다. 다른 Prometheus 호환 스케일러블 DB보다 의존성이 적어 운영이 편했습니다. 컴포넌트만 추가하면 수평 확장이 되니 Prometheus의 scale-out 한계도 풀렸습니다(구성·데이터 흐름은 개념 02 아키텍처, 랑데부 해싱·replicationFactor 복제는 개념 03 수집).

배치 전략은 컴포넌트 성격에 맞췄습니다.

• stateless(vminsert·vmselect) → 쿠버네티스 위에 올려 scale-out을 편하게 합니다.
• stateful(vmstorage) → 물리 장비에서 운영합니다. 컨테이너에 올릴 수도 있으나 디스크 I/O가 큰 저장 계층은 물리 장비가 이점이 더 컸습니다. -replicationFactor로 여러 노드에 복제해 저장 노드 한두 대가 다운돼도 조회에 문제가 없게 했습니다.

하나의 클러스터가 감당 못 한 4가지 접근 패턴

클러스터의 첫 용도는 서비스 레벨 모니터링 대시보드였고 여기서 유용하게 썼습니다. 잘 되니 알람 시스템에도 붙였고 이어 호스트 레벨 대시보드·호스트 레벨 알람까지, 각각의 개발·테스트 환경까지 확장했습니다. 그렇게 많은 대시보드·시스템이 하나의 클러스터를 두드리자 과부하가 시작됐습니다. 근본 원인은 요청량이 아니었습니다. 네 시스템의 데이터 접근 패턴이 서로 달랐습니다.

한 클러스터가 이렇게 제각각인 패턴을 동시에 받아 내니 캐시 미스가 잦아지고 메모리를 비효율적으로 썼습니다(rollup result cache 동작은 개념 05 쿼리 참고). 그 결과가 과부하였습니다.

캐시 미스가 오경보를 부른 사례

과부하는 서로가 서로를 해치는 방식으로 번졌습니다.

• 경보를 받고 대시보드에 접속했더니 그래프가 느리거나 아예 안 그려지는 문제.
• 누군가 실수로 너무 넓은 범위·너무 많은 지표를 조회하면 클러스터의 쓰기 성능까지 영향을 받아 지표가 지연 유입되고 이 지연이 곧 오경보로 이어졌습니다.
• 대시보드를 개발하며 과거 지표를 대량 조회하면 메모리 사용이 치솟아 클러스터가 OOM으로 다운되기도 했습니다.

heavy query를 던지는 대시보드가 경보 시스템의 조회를 흔들어 실제 장애가 없는데도 경보가 나가는 상황이 벌어졌습니다. 비상등(모니터링·경보)은 불이 났을 때 반드시 켜져야 하고, 불이 없으면 울려선 안 됩니다 — 이 원칙이 깨졌습니다.

해결책: 멀티버스로 분리

극복책은 멀티버스였습니다. 대시보드·시스템별로 클러스터 자체를 나눴습니다.

• 데이터 파이프라인에서부터 각 클러스터로 따로 write 합니다.
• 각 모니터링·알람 시스템은 자기 전용 클러스터만 조회합니다.

덕분에 각 애플리케이션이 서로 메모리·성능에 간섭하지 않게 됐습니다. 현재 스테이지 3(수백만 시계열)~스테이지 4(수천만 시계열) 규모의 클러스터를 10개 내외로 운영합니다.

이 멀티버스는 vmalert와 vmauth가 떠받칩니다(상세 동작은 개념 05 쿼리·운영 컴포넌트).

• vmalert 선계산: heavy query 결과를 미리 계산해 별도 시계열(recording rule)로 저장합니다. 대시보드는 가벼운 쿼리만으로 요약 정보를 그려 read로 인한 OOM을 방지합니다. 이후엔 write 시점에 요약을 만드는 스트리밍 어그리게이션도 도입 준비 중입니다.
• vmauth 라우팅 게이트웨이: 여러 클러스터 앞단에서 요청을 알맞은 클러스터로 라우팅해 멀티버스를 단일 진입점처럼 쓰게 합니다.

초대규모 현황

쿠버네티스 전환과 카디널리티 폭증

2022~2026년 사이 검색 인프라는 급성장했습니다. 결정타는 쿠버네티스 전환이었습니다. 물리 서버 한 대에 수십 개 컨테이너가 뜨고 각자 메트릭을 생성하면서 수집 대상 시계열이 가파르게 늘었습니다.

컨테이너가 약 58배 늘었습니다. 쿠버네티스에서는 컨테이너 ID·파드 이름·네임스페이스 레이블 조합에 따라 같은 메트릭도 서로 다른 시계열로 저장됩니다. 컨테이너 증가가 곧바로 카디널리티 폭증으로 이어진 이유입니다(원리는 01 카디널리티).

현재 클러스터 규모

2026년 3월 1~7일 주간 평균 기준입니다. 먼저 구성과 할당 리소스, 이어서 시계열 규모와 처리량입니다.

555조 개가 약 510TB에 담깁니다. 데이터포인트당 0.92바이트입니다. VM 압축 성능이 실운영에서도 강력하다는 증거입니다(압축 원리는 개념 04 저장·압축). 쿠버네티스 환경의 컨테이너는 하루 약 7.4억 개의 신규 시계열을 남길 만큼 자주 나고 사라집니다.

Hot/Warm 2계층 아키텍처

이 규모에서 가장 먼저 부딪히는 건 성능과 비용의 균형입니다. 전부 SSD면 조회는 빠르지만 비용이 폭증합니다. 전부 HDD면 장기 보관은 싸지만 실시간 쿼리 성능을 보장할 수 없습니다. 그래서 Hot과 Warm을 각각 독립된 VM 클러스터로 구성했습니다.

• 쓰기(dual write): vmagent가 수집한 메트릭을 Hot·Warm 두 클러스터의 vminsert로 동시에 보냅니다. remote write 대상마다 큐를 따로 유지하므로 한쪽에 장애가 나도 다른 쪽 전송은 무사합니다(큐 동작은 개념 03 수집). 두 클러스터는 같은 원본을 실시간 수신하고 각자의 보관 정책으로 독립 관리합니다.
• 읽기(시간 범위 분기): 클라이언트 API가 요청의 시간 범위를 보고 최근 12개월 이내는 Hot, 그 이전은 Warm으로 보냅니다. 사용자는 단일 쿼리 인터페이스만 쓰므로 분기를 의식하지 않습니다.

완전히 분리된 두 클러스터라 계층 간 장애 전파를 막고 각 계층 리소스를 따로 관리·확장할 수 있습니다.

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

세 가지가 연쇄한 메모리 위기

vmstorage는 활성 시계열 정보를 메모리에 캐시해 검색을 빠르게 처리합니다. 카디널리티가 급증하자 바로 여기서 세 문제가 사슬처럼 엮여 터졌습니다.

카디널리티 ↑ → indexdb 메모리 ↑
        ├─ OOM 위험 증가
        └─ 캐시 효율 저하 → 디스크 I/O ↑ → 쿼리 지연 ↑

메모리 부족에 그치지 않고 수집 안정성과 조회 성능을 동시에 흔드는 상태였습니다. VM 공식 문서는 이런 상황을 피하려 전체 노드 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 … very likely you’d see no problems with stability if you’ll get 50% RSS anon usage.”). 기존 장비는 카디널리티 증가로 RSS anonymous 사용률이 계속 올라 권장 여유를 지키기 어려웠습니다. vmstorage 메모리를 128GB → 512GB로 늘리기로 했습니다.

진짜 과제는 무중단 전환이었습니다. 이 클러스터는 네이버 검색 전체의 핵심 비상등이라 교체 중 메트릭 누락이나 알림 정지가 곧 서비스 영향입니다. 180노드 교체를 계층 특성에 맞춰 서로 다른 전략으로 풀었습니다.

Hot Tier: 랑데부 역순 추가

Hot은 보관 기간이 12개월로 짧습니다. 기존 128GB 장비를 둔 채 512GB 신규 장비를 추가하고 기존 데이터가 만료되면 걷어내는 방식이 현실적이었습니다. 절차는 3단계입니다.

1. vmselect가 기존·신규 장비를 모두 읽도록 설정.
2. vminsert는 신규 장비에만 새 데이터를 쓰도록 수정.
3. 12개월 뒤 기존 장비 데이터가 모두 만료되면 vmselect에서도 기존 장비 제거.

함정은 2단계입니다. vminsert가 시계열을 어떻게 분산·복제하는지(랑데부 해싱·replicationFactor, 원리는 개념 03 수집) 모른 채 -storageNode 목록만 바꾸면 전환 자체가 장애를 냅니다.

왜 통째 교체가 위험할까요? 신규 장비군에는 기존 시계열 정보가 전혀 없습니다. 목록을 한 번에 갈아 끼우면 모든 시계열의 저장 위치가 재계산돼 들어오는 거의 모든 시계열이 New TSID로 재등록됩니다. New TSID 등록은 indexdb 쓰기 연산이라 단순 데이터포인트 추가보다 CPU·메모리를 훨씬 많이 먹습니다. 이게 클러스터 전 vmstorage에서 동시에 터지면 수집 파이프라인이 정체되고 메트릭 유실·모니터링 공백으로 이어집니다.

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

전환 중에 지켜볼 지표는 다음과 같습니다(정의는 01 카디널리티).

• 시계열 교체율(churn rate) · 24시간 안에 새로 생성된 시계열의 수와 비율 — 값이 커질수록 indexdb 부하가 늘고 OOM·쿼리 성능 저하로 이어집니다.
• 지연 삽입 비율(slow insert rate) · 최근 5분간 전체 수집량 대비 지연된 삽입 비율 — 지속적으로 10% 초과 시 활성 시계열 대비 메모리 부족 신호입니다.

# replicationFactor=3, -storageNode=[A, B, C, D, E]
시계열 X → primary C(2) → 복제 D(3), E(4)
시계열 Y → primary E(4) → 복제 A(0), B(1)   ← 끝에서 앞으로 순환

# 순방향 추가 (위험) — new-A primary의 복제가 매번 앞쪽 old-A, old-B로 향함
Step 1  -storageNode=old-A, ..., old-E, new-A
Step 2  -storageNode=old-A, ..., old-E, new-A, new-B
Step 3  -storageNode=old-A, ..., old-E, new-A, new-B, new-C

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

Warm Tier: vmbackup / vmrestore

Warm은 성격이 달랐습니다. 보관 36개월이라 Hot처럼 만료를 기다리면 두 장비군이 3년간 공존해야 합니다. 장비당 수십 TB, 전체 수백 TB가 넘으니 단순 순차 교체만으로도 마이그레이션에 30일 이상 걸릴 것으로 예상됐습니다. VM에는 마이그레이션용 공식 도구로 vmbackup·vmrestore·vmctl이 있습니다.

• vmbackup · 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 장시간 작업도 안정적으로 이어 갑니다.

API 기반 vmctl과 달리 파일 시스템 수준으로 동작해 운영 클러스터 부하가 거의 없습니다. 전체 작업은 안전하게 두 단계로 나눴습니다.

• 1단계 — 사전 데이터 복제: 전환 당일 옮길 양을 최소화합니다. 기존 장비 전체에서 vmbackup을 병렬 실행해 스냅샷을 만들고 신규 장비에서 vmrestore로 미리 복원합니다. 운영 영향을 막으려 네트워크 팀과 협의해 장비당 대역폭을 1Gbps로 엄격 제한했습니다. 정합성은 자동 검증 스크립트로 확인했고 2021~2024년 각 해의 임의 시점 쿼리 결과를 대조해 복원을 검증했습니다.
• 2단계 — 세트 단위 점진 전환: 대부분 데이터가 이미 신규 장비에 있으니 그 사이 쌓인 공백만 증분 vmbackup으로 채웁니다. 전체를 한 번에 바꾸지 않고 세트 단위로 (① vminsert에서 해당 세트 기존 장비 제외 → ② 증분 vmbackup/vmrestore로 공백 채움 → ③ vmselect에서 기존 제거·신규 투입 → ④ vminsert에 신규 투입으로 실시간 수집 재개) 진행해 전환 중에도 클러스터 가용성을 유지했습니다. replicationFactor를 고려해 서비스 영향이 없는 범위에서 이 과정을 반복하며 Warm 전체를 순차 교체했습니다.

전환 결과

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

이 규모에 이르면 공식 문서나 커뮤니티에서 바로 참고할 사례가 없습니다. 소스 코드를 직접 읽고, 운영 메트릭으로 가설을 세우고, 실제 환경에서 검증하는 과정을 반복할 수밖에 없습니다. 무중단 전환이 그 전형이었습니다. 랑데부 해싱과 복제 계수의 내부 동작을 이해했기에 단순 증설을 넘어 장애를 만들지 않는 전환까지 설계할 수 있었습니다. 모니터링은 서비스 운영의 기반 인프라입니다. 모니터링이 안정적일수록 전체 서비스도 그만큼 안정적으로 굴러갑니다.

출처

• 01_대사집_VictoriaMetrics_시계열데이터_대혼돈의_멀티버스.md (DEVIEW 2023, 이선규 파트 대략 20:30~33:50): SingleNode→Cluster 전환, stateless/stateful 배치, 단일 클러스터의 4가지 접근 패턴 과부하, 캐시 미스·오경보 사례, 멀티버스 분리, 쌍둥이 클러스터(멀티레벨), 백업·리스토어 vs 셀렉트·인서트 마이그레이션.
• 03_기사_6475419_대규모메트릭저장소.md (네이버 D2, 2026-04-22): 쿠버네티스 전환과 카디널리티 폭증, 현재 규모·글로벌 비교, Hot/Warm 2계층, 메모리 한계·128→512GB, Hot 랑데부 역순 추가, Warm vmbackup/vmrestore 마이그레이션, 전환 결과.