pile·
인프라 / DevOps·네이버 D2네이버 D2·

VictoriaMetrics 운영기 2편 — 장비 증설 없이 리소스 위기를 해결한 3단계 최적화 전략

네이버 검색의 대규모 메트릭 저장소인 VictoriaMetrics 클러스터를 장비 증설 없이 소프트웨어 최적화만으로 리소스 위기에서 구한 과정을 다룬다. 쿠버네티스 전환으로 컨테이너가 수백만 개를 넘고 카디널리티가 폭증하면서 조회 컴포넌트 OOM과 저장소 디스크 고갈이 동시에 터졌다. 데이터 파이프라인을 조회·저장·수집 세 레이어로 나눠 각 구간을 따로 최적화했다.

핵심 포인트
  • 매분 도는 전체 컨테이너 집계 쿼리가 수백만 시계열을 vmselect 한 대에 몰아 OOM을 유발, container 레이블 첫 글자 기준 36개 쿼리로 분할해 해결했다.
  • 쿼리 분할로 쿼리 1건당 vmselect 메모리 점유율을 45%에서 12%로, API 응답 시간을 최대 40초에서 7초로 줄였다.
  • 저장 디스크 고갈은 Hot Tier RetentionPeriod를 12개월에서 6개월로 축소해 대응, IndexDB 3-슬롯 로테이션 구조를 먼저 분석해 영향 시점을 예측했다.
  • 조회 로그 전수 조사 결과 99.997%가 최근 1개월 데이터 조회라, 보관 기간 축소의 서비스 영향이 미미함을 정량으로 검증했다.
  • 수집 대상의 90% 이상을 차지하던 비서비스 컨테이너를 수집에서 제외해 수집 컨테이너 91.6%, Ingestion Rate 64.4%를 감소시켰다.
상세 정리
  • 배경: 1편은 180대 노드의 2계층 아키텍처와 무중단 장비 교체를 다뤘고, 2편은 장비를 더 늘리지 않고 소프트웨어로만 푸는 최적화를 다룬다.
  • 문제 확산: k8s 전환 가속으로 컨테이너가 수백만 개를 넘고 카디널리티가 급증, 조회 메모리 급등과 저장소 디스크 고갈이 특정 컴포넌트가 아니라 파이프라인 전반에서 동시에 발생했다.
  • 조회 병목 진단: vmselect 메모리 90% 초과 알람이 잦았고 공통 원인은 매분 실행되는 전체 컨테이너 집계 쿼리였다. 수백만 시계열 결과가 한 Pod에서 병합되며 단일 Pod 메모리 한계를 넘겼다.
  • 리소스 제한의 한계: maxUniqueTimeseries·maxMemoryPerQuery 등 플래그로 방어했지만, 이는 과사용을 막을 뿐 결과셋 자체를 줄이지 못하고 제한에 걸리면 쿼리가 오류로 실패할 뿐이라 근본 해결이 아니었다.
  • vmstorage 구조 파악: IndexDB는 역색인으로 TSID를 조회하고 Data 영역은 TSID·타임스탬프로 정렬된 압축 블록을 Part 단위로 보관한다. vmselect는 시계열 위치를 몰라 모든 vmstorage에 팬아웃한 뒤 결과를 한 Pod 메모리에서 병합·dedup하는데, 이 구조가 OOM의 근원이었다.
  • 쿼리 분할 대응: container 레이블 첫 글자(a-z, 0-9) 기준 36개 쿼리로 쪼개 부하를 클러스터 전체로 분산했다. 결과는 쿼리당 메모리 45%에서 12%, 응답 40초에서 7초.
  • 저장 위기: 초기 투입 vmstorage 노드의 디스크가 먼저 임계치에 도달했고, 서버 단가 급등으로 증설·교체가 비현실적이라 RetentionPeriod 축소를 검토했다.
  • IndexDB 로테이션 분석: prev/current/next 3-슬롯이 순환한다. 로테이션은 프로세스 기동이 아니라 UNIX 타임스탬프 0 기준 RetentionPeriod 주기마다 발생하며(1개월을 31일로 계산해 12개월은 372일), vm_next_retention_seconds로 다음 시점을 예측할 수 있다.
  • 영향 예측: 12에서 6개월로 줄이면 단기엔 Data 영역의 초과 월별 파티션이 즉시 삭제되고, 장기엔 다음 로테이션에서 거대한 12개월 prev 슬롯이 작은 6개월 슬롯으로 교체되며 IndexDB의 디스크·메모리 점유가 급감한다.
  • 정량 검증: API 조회 로그 전수 조사로 99.997%가 1개월 미만, 6개월 이후 조회는 하루 평균 3건 미만이라 Warm Tier(HDD)로 수용 가능하다고 판단, 6개월 축소의 영향이 미미함을 확인했다.
  • 수집 축소: 수집 대상의 90% 이상이 서비스 지표 없이 시스템 지표만 내는 비서비스 컨테이너였고, 사내 사용 패턴상 필수가 아니라 판단해 서비스 컨테이너만 수집하도록 정책을 바꿨다.
  • 수집 결과: 수집 컨테이너 -91.6%, Active Time Series -63.6%, Ingestion Rate -64.4%, vmagent 등 파이프라인 부하 -69.6%. 컨테이너 감소폭보다 시계열 감소폭이 작은 건 노드 등 다른 수집 대상의 시계열이 섞였기 때문이다.
  • 디스크 추세 반전: 만료 삭제량이 신규 유입량을 넘어서며 우상향하던 Data 영역 사용량이 감소로 전환, 배포 후 약 1.5개월간 8.7% 감소했다. 만료가 완전히 반영되면 최대 58%까지 줄 것으로 예상한다.
  • 종합 성과: 조회 응답 82% 개선과 vmselect 메모리 안정화, 저장 증설 비용 절감, 수집 단계 정책 변경으로 디스크 일별 증가율 43% 감소를 얻었다.
왜 읽나대규모 시계열·메트릭 인프라(VictoriaMetrics·Prometheus 계열)를 운영하며 카디널리티 폭증과 OOM·디스크 위기를 장비 증설 없이 풀어야 하는 SRE·플랫폼 엔지니어에게 실전 튜닝 레퍼런스.
네이버 D2
네이버 D2 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    Claude Apps Gateway on AWS 자세히 알아보기

    Anthropic의 Claude Code 바이너리에 내장된 LLM 게이트웨이 솔루션 Claude Apps Gateway의 AWS 인프라 배포 방법과 엔터프라이즈 기능을 다룬다. API 키 대신 IdP(Identity Provider) 기반 SSO를 사용해 Okta, Microsoft Entra ID, Keycloak과 연동하며, 그룹별 권한 정책, 예산 관리, OpenTelemetry 기반 관측성을 제공한다.

    #claude#bedrock#opentelemetry+2
  2. 인프라 / DevOps·AWS KoreaAWS Korea Tech·

    금융 클라우드 길라잡이 A to Z Part 2 – 연구개발망 예외와 망분리 개선 로드맵

    2024년 8월 금융위원회의 망분리 개선 로드맵에 따라 허용된 연구개발망(R&D 망)을 AWS 멀티 계정 아키텍처로 구현하는 방법을 다룬다. 물리적 망분리 대신 논리적 분리로 전환되면서 생성형 AI와 SaaS 서비스 사용이 R&D 망에서 허용됐다. 3계층 VPC 설계, AI 도구 통합, 아티팩트 이전 파이프라인 등 실무 구현 사례를 포함한다.

    #aws#network-security#compliance+2