잘 쓰는 방법 — 설계 원칙과 운영 패턴
- 개념을 알고 난 뒤 “어떻게 써야 잘 쓰는가"를 다룹니다. 주제는 도구의 동작이 아니라 설계·운영에서 내리는 판단 기준입니다.
- 카디널리티 설계: 시계열 폭발은 쿼리 튜닝이 아니라 설계 단계에서 막습니다. 자주 바뀌는 값을 레이블로 넣지 않으면 그게 가장 싼 최적화입니다.
- 초대규모 운영 패턴: 네이버 검색의 12.5억 시계열·180노드 현장에서 뽑은 멀티클러스터 분리, Hot/Warm 2계층, 무중단 장비 전환 설계.
- 기본 개념의 03(랑데부 해싱·복제)을 전제 지식으로 먼저 읽어야 02의 무중단 전략이 눈에 들어옵니다.
기본 개념이 VM의 내부 동작을 다뤘다면, 이 문서는 그 동작을 아는 상태에서 “어떻게 써야 잘 쓰는가"를 다룹니다. 시계열 폭발을 예방하는 카디널리티 설계 원칙, 네이버 검색이 초대규모 운영과 무중단 전환을 겪으며 쌓은 운영 패턴, 저장된 시계열을 올바르고 가볍게 꺼내 쓰는 쿼리 패턴이 차례로 나옵니다. 모두 특정 환경에 매이지 않는 일반 원칙으로 정리했습니다. 규모가 커질수록 더 크게 작동합니다.
문서 지도
- 01 카디널리티 — 시계열은 지표 이름 + 레이블 집합입니다. New TSID 발급이 곧 폭발이라 설계 단계에서 미리 걸러내는 편이 최선입니다. 런타임 감시는 churn·slow insert로 합니다.
- 02 초대규모 운영과 무중단 전환 — 멀티버스(멀티클러스터 분리), Hot/Warm 2계층, 12.5억 시계열 규모, 랑데부 역순 추가·vmbackup 무중단 장비 전환.
- 03 쿼리 패턴 — PromQL 기본 패턴(counter rate/increase·gauge 집계·histogram_quantile·sum by)과 MetricsQL 확장(default_rollup·rate 차이·keep_metric_names·WITH·topk_avg). 무거운 쿼리 안티패턴을 피하는 법, 카디널리티를 점검하는 쿼리와 API.
읽기 전에
- 01 카디널리티는 기본 개념의 04(저장·압축)에서 본 New TSID 발급 경로를 실무 관점으로 잇습니다. 04를 먼저 읽으면 “왜 카디널리티가 곧 메모리·인덱스 폭발인가"가 분명해집니다.
- 02 무중단 전환은 랑데부 역순 추가로 푸는데, 기본 개념의 03 수집에서 다룬 랑데부 해싱·복제 원리를 먼저 알아야 와닿습니다. 03을 건너뛰면 “왜
-storageNode목록을 통째로 바꾸면 장애가 나는가"가 손에 잡히지 않습니다.
우리 환경에 이 원칙들을 어떻게 적용했는지는 우리의 운영에서 이어 다룹니다.
마지막 수정 일자