01 · 네이버 검색 SRE의 시계열 데이터베이스 운영기 (2024-02)

네이버 검색 SRE가 DEVIEW 2023에서 발표한 VictoriaMetrics 도입·운영 이야기를 텍스트로 정리한 글입니다. SingleNode/Cluster를 고른 과정, 단일 클러스터가 무너진 이유, 멀티 클러스터와 지표 선계산으로 이를 푼 과정, 여러 클러스터를 다시 하나의 진입점처럼 쓰게 해 준 라우팅 게이트웨이까지 원문의 흐름을 그대로 따라갑니다.

시계열 데이터란

시계열 데이터란 시간 순서대로 나열된 숫자 데이터입니다. 네이버 검색 SRE는 모니터링하려고 장비 지표와 서비스 지표를 일정 주기로 수집·저장·분석합니다. 그 기반이 Prometheus 호환 시계열 데이터베이스인 VictoriaMetrics입니다. 저장·분석·대시보드(시각화)·알림 시스템은 여기서 데이터를 받아 갑니다. 시계열 데이터와 지표 타입의 기본 개념은 /monitoring/victoriametrics/concepts/01-tsdb-and-victoriametrics/에서 더 자세히 다룹니다.

시계열 데이터(지표) 저장 — SingleNode vs Cluster

VictoriaMetrics에는 SingleNode 버전과 Cluster 버전이 있습니다.

SingleNode 버전

• 장점 — 단일 바이너리로 손쉽게 실행합니다. Prometheus보다 2~10배 가량 빠르고 리소스도 적게 씁니다.
• 단점 — 수집 데이터가 수천만 개 이상으로 늘면 단일 장비로 감당이 안 될 수 있고 그 단일 장비가 SPOF(single point of failure)로 작용합니다.
• 결론 — 네이버 검색 SRE는 SingleNode 버전만으로는 시계열 데이터를 저장하고 제공할 수 없다고 결론지었습니다.

Cluster 버전

• 장점 — 저장되는 시계열 스케일에 맞춰 read·write·storage 컴포넌트를 선형적으로 scale out 할 수 있습니다(Prometheus의 가장 큰 한계를 해소). replication factor를 적용해 시계열 데이터 유실을 일정 부분 막습니다.
• 단점 — SingleNode 버전보다 구조가 복잡하고 운영이 어렵습니다.
• 결론 — stateless 컴포넌트인 vminsert(write)·vmselect(read)는 Kubernetes에, stateful 컴포넌트인 vmstorage는 물리 장비를 쓴 클러스터로 구성해 운영합니다.

Cluster 버전의 컴포넌트 구성과 stateless/stateful 배치 이유는 /monitoring/victoriametrics/concepts/02-architecture/에서 더 깊이 다룹니다.

이 문서가 따라가는 진화 흐름을 먼저 그림으로 보면 다음과 같습니다.

단일 클러스터 과부하

Cluster 버전을 쓰기로 했지만 단일 클러스터만으로는 여전히 풀리지 않는 문제가 있었습니다. 네이버 검색 SRE는 검색 서비스를 안정적으로 돌리려고 수십만 대의 장비와 수백 개의 서비스에 대시보드(시각화)와 경보·알림을 제공하는데 하나의 클러스터로는 다음 4가지 서로 다른 데이터 접근 패턴의 부하를 감당할 수 없었습니다.

• 서비스 레벨의 시각화: 특정 지표를 넓은 범위로 조회
• 서비스 레벨의 알림: 특정 지표를 최신 범위로 조회
• 호스트 레벨의 시각화: 모든 지표를 일부 범위에서 조회
• 호스트 레벨의 알림: 모든 지표를 최신 범위로 조회

서로 다른 데이터 접근 패턴의 컴포넌트가 한 클러스터에 공존하면서 VictoriaMetrics의 캐시 미스와 과부하가 자주 났습니다. 경보가 떠서 대시보드에 접속하면 지표 조회 중 타임아웃이 나기도 했습니다. 대시보드에서 실수로 heavy query를 요청하면 경보 시스템의 지표 조회가 실패해 오경보를 수십 명에게 발송하는 경우도 있었습니다. 지표를 백테스트하느라 과거 데이터를 대량 조회할 때도 하나의 클러스터로는 부담이 컸습니다.

해결책

장애 관제 및 모니터링 시스템은 비상구와 같아서 지표 유실과 중단 시간을 최소화해야 합니다. 네이버 검색 SRE는 단일 클러스터 과부하를 다음 2가지 방법으로 풀었습니다.

1. 멀티 클러스터 운영

앞서 나열한 추상화 레벨과 시각화/알림의 접근 패턴별로 클러스터를 분리했습니다. 사용자 컴포넌트가 서로 영향을 주고받던 부분이 사라져 클러스터 장애 시 영향 범위가 좁아졌습니다. 현재 시계열 데이터 수천만 개 규모의 클러스터를 4+α개 운영합니다.

접근 패턴별로 클러스터를 나눠 초대규모(180대 · 12.5억 시계열)까지 확장한 사례는 /monitoring/victoriametrics/practice/02-operations-at-scale/에서 이어서 다룹니다.

2. 지표 선계산

시각화 대시보드에서 서비스 지표를 하루 혹은 그 이상의 범위로 조회하는 요청은 부하가 큽니다. 장비 5,000대를 쓰는 특정 서비스에서 매 분 발생하는 검색 요청 수의 합을 하루 혹은 그 이상의 범위로 시각화 대시보드에 표시한다면 조회해야 하는 데이터 포인트 수는 다음과 같습니다.

• 데이터 수집 간격: 1분
• 매 분 장비별 검색 요청 수 시계열 데이터: 5,000개
• 1일 데이터 포인트 수: 데이터 5,000개/분 × 60분/시간 × 24시간/일 = 7,200,000개/일

수백만 개의 데이터 포인트를 반환해야 하는 상황입니다. 검색 요청 수의 합을 미리 계산하면 시계열 데이터를 1개로 압축해 7,200,000개 대신 1,440개 데이터 포인트만 조회해도 시각화가 됩니다. 네이버 검색 SRE는 지표 선계산에 Prometheus의 Recording rules 호환 툴인 VictoriaMetrics의 컴포넌트 vmalert를 씁니다. vmalert의 동작 방식은 /monitoring/victoriametrics/concepts/05-query-and-ops-components/에서 더 자세히 다룹니다.

멀티 클러스터 운영의 어려움

단일 클러스터 과부하를 풀려고 도입한 멀티 클러스터 운영에도 어려움이 있습니다. 시계열 데이터베이스에 운영 이슈(버전 업그레이드, 장비 교체, 배포, IDC 장애 등)가 생기면 사용자는 엔드포인트를 바꿔 대체 클러스터를 써야 합니다.

이 과정에서 내부 운영 이슈를 처리하려면 사용자와 주고받는 커뮤니케이션 비용이 듭니다. 이슈 상황마다 배포하거나 대체 클러스터로 엔드포인트를 바꿔 달라고 요청해야 하고 사용자는 그때마다 변경 배포를 해야 합니다. 최악의 경우 특정 IDC 인프라 장애로 네이버 검색의 장애 관제 및 모니터링 자체가 중단되면 사용자 배포 전까지 복구가 지연될 수 있습니다.

해결책: 라우팅 게이트웨이 적용

사용자가 직접 엔드포인트를 바꾸는 대신 시계열 데이터베이스 클러스터 운영자가 사용자를 적절한 클러스터로 라우팅하는 게이트웨이를 적용했습니다. 라우팅 게이트웨이로는 VictoriaMetrics의 vmauth를 래핑해 씁니다.

vmauth 라우팅 게이트웨이의 장점은 다음과 같습니다.

• 사용자별 데이터 접근 패턴과 부하 발생량에 맞춰 라우팅과 로드밸런싱 제공
• 인증된 사용자만 클러스터에 접근하므로(vmauth의 basic auth 기능 사용) 예상하지 못한 부하에 대처 가능
• 사용자별 부하 발생 및 요청 수 모니터링 가능
• 버전 업그레이드, 장비 교체 등 운영 이슈가 생기면 내부 라우팅 설정 변경만으로 대체 클러스터로 라우팅 제공
• 특정 IDC 인프라 장애 등 비상 상황에서 사용자의 배포 없이 빠르게 라우팅 포인트 변경 가능

게이트웨이 덕분에 클러스터를 여러 개 운영하면서도 사용자와 주고받는 커뮤니케이션 비용이 줄고 내부 유지 보수도 수월해졌습니다. vmauth를 포함한 쿼리·운영 컴포넌트의 역할은 /monitoring/victoriametrics/concepts/05-query-and-ops-components/에서 이어집니다.

마치며

네이버 검색 SRE가 시계열 데이터베이스를 운영하면서 겪은 어려움과 해결책은 다음과 같습니다.

• 지표 유실 및 중단 시간 최소화
• 시계열 데이터베이스 클러스터 과부하를 막는 멀티 클러스터 운영
• 컴포넌트별 데이터 접근 패턴에 맞춘 클러스터 제공
• 선계산을 활용해 heavy query 완화
• 라우팅 게이트웨이를 적용해 멀티 클러스터 운영 난도 낮춤

출처

• 원문: 네이버 검색 SRE의 시계열 데이터베이스 운영기 — VictoriaMetrics로 수천만 개의 시계열 데이터 다루기 (D2, DEVIEW 2023 발표 기반, 2024-02-07, 이선규)
• 작업 저장소 원본: 04_기사_6867189_SRE시계열운영기.md
• 반영 범위: 원문 전체 — 시계열 데이터 정의, SingleNode/Cluster 장단점과 결론, 단일 클러스터 과부하(4가지 접근 패턴), 해결책(멀티 클러스터 운영·vmalert 지표 선계산), 멀티 클러스터 운영의 어려움과 vmauth 라우팅 게이트웨이, 마치며 요약까지 빠짐없이 정리했습니다.