makgol's note – VictoriaMetrics 사용기

vmagent AZ 분할로 AZ 간 scrape 전송 줄이기

Sun, 27 Sep 2026 00:00:00 +0900

05 · vmagent AZ 분할로 AZ 간 scrape 전송 줄이기

AZ a/c에 agent 1대씩 배치·수치는 대략적인 규모로 표시

전체 트래픽 중 inter-AZ 비중 약 90% AZ 간 내부 통신

전체 네트워크 사용량 감소 약 13% 수집 클러스터 전체에 적용할 때의 예상

agent 경로의 AZ 간 전송 약 95% 감소 먼저 적용한 클러스터 · 실측

먼저 적용한 결과와 전체 적용 시 예상 효과

전체 네트워크 트래픽의 **약 90%가 AZ 간 내부 통신(inter-AZ traffic)**이었습니다. 청구 사용량으로 계산한 비율입니다. 내부 컴포넌트 사이에서 어떤 데이터가 AZ 경계를 넘는지 확인하다가 vmagent의 수집 경로를 살펴봤습니다.

부록 · 같은 AZ 분할을 Prometheus로 하면

Thu, 22 Oct 2026 00:00:00 +0900

부록 · 같은 AZ 분할을 Prometheus로 하면

05 vmagent AZ 분할은 vmagent 두 대를 AZ a/c에 한 대씩 두고 Node 메타라벨로 담당 타깃을 나눴습니다. 같은 분할을 Prometheus로 해야 한다면 어떤 재료가 있고 어디가 달라지는지 정리합니다. 우리 환경에 적용한 구성은 아니며, Prometheus Operator의 문서와 설정 생성 코드를 읽고 05편의 결정과 대조한 설계 검토입니다.

부록 · AZ를 건너면 Pod 간 지연은 얼마나 늘어나는가

Mon, 05 Oct 2026 00:00:00 +0900

부록 · AZ를 건너면 Pod 간 지연은 얼마나 늘어나는가

같은 AZ의 다른 노드와 다른 AZ의 노드에 있는 Pod를 비교했을 때, ping 평균 RTT는 0.339ms에서 0.544ms로 늘었지만 단일 TCP 플로우는 모두 4.96Gbps였습니다. atomai의 Pod 네트워크 실측 벤치마크가 m5.xlarge 노드에서 보고한 결과입니다. 같은 노드의 Pod 사이 RTT는 0.040ms였습니다.

Istio 히스토그램 3종이 시리즈의 44%: vmstorage 인덱스 줄이기

Sun, 04 Oct 2026 00:00:00 +0900

06 · Istio 히스토그램 3종이 시리즈의 44%: vmstorage 인덱스 줄이기

약 1년 보관 · 복제 2벌·시리즈 비중은 실측 · 용량 효과는 적용 전 계산

디스크 중 인덱스 비중 약 3분의 2 실측

Istio 히스토그램 3종 약 44% 하루 고유 시리즈 중 · 실측

파드 신원 라벨을 접으면 약 90% 감소 하루 고유 시리즈 전체 · 실측

용량을 차지하는 것은 샘플보다 인덱스

현재 vmstorage 디스크의 약 3분의 2는 인덱스입니다(실측). 하루 증가량도 인덱스가 데이터의 두 배쯤 됩니다. 지금 증가 속도로 약 1년의 보관 기간을 채우면 장기 필요량은 증설을 마친 볼륨 운영 한도의 약 130%입니다(계산).

스택 구성

Sat, 01 Aug 2026 00:00:00 +0900

01 · 우리 스택 구성

k8s 위 VM operator가 vmagent를 Deployment(stateless)로 띄우고 중앙 VM 클러스터의 vminsert 엔드포인트로 remote_write 합니다.
목적지 경로 /insert/0/prometheus는 클러스터 모드 · tenant 0을 뜻합니다.
stage/prod는 값이 다릅니다 — 리소스·maxDiskUsagePerURL이 환경별로 달라지고 prod는 vmagent가 두 계열(용도별 분리)이라 extraArgs가 양쪽에 함께 걸립니다.
공통 수집 설정은 scrapeInterval 30s · promscrape.streamParse=true · promscrape.maxScrapeSize=24GiB.

우리 환경에서 지표가 어디서 만들어져 어디로 흘러가는지, 그 구조와 stage/prod 값 차이를 정리합니다. 전송 안정화 Phase 1 튜닝은 02 vmagent 전송 튜닝에서, 장기보관 아키텍처는 메트릭 장기보관 챕터에서 따로 다룹니다.

vmagent 전송 튜닝

Sat, 18 Jul 2026 00:00:00 +0900

02 · vmagent 전송 안정화 (Phase 1)

remoteWrite.forceVMProto=true — 자동 협상을 없애고 VM native protocol(zstd)로 고정합니다. 로그 없이 일어나던 snappy 다운그레이드가 사라지므로 전송량 2~4x 절감을 보장합니다. 수신측 vminsert v1.88+ 필요.
remoteWriteSettings.maxDiskUsagePerURL — 기본값 0(무제한)이라 링크 장애가 길어지면 노드 디스크가 고갈됩니다. 상한에 도달하면 오래된 블록부터 FIFO drop합니다. 적용값은 stage 1000MiB / prod 2000MiB.
대안(미적용) statefulMode=true — 큐를 PVC로 옮기면 유실이 없어집니다. 그런데 무상태 원칙의 예외라서 그 예외를 인정할 때만 택합니다.
적용 순서는 stage 먼저 → 수일 관찰 → prod 순입니다. 적용 후 확인은 03 자기감시 메트릭.

Phase 1의 목표는 전송 안정화입니다. 전송 프로토콜을 zstd로 고정했고 디스크 큐에 상한을 명시했습니다. 각 변경의 근거와 트레이드오프, 적용 순서를 아래에 정리했습니다.

자기감시 메트릭

Sat, 18 Jul 2026 00:00:00 +0900

03 · 우리가 보는 자기감시 메트릭

전송 상태는 네 지표로 봅니다 — retries(재시도), packets_dropped(드랍), bytes_sent(전송량), pending_data_bytes(대기 큐).
bytes_sent로 forceVMProto 효과를 판정합니다 — 적용 후 뚝 떨어졌으면 여태 snappy로 나갔고 그대로면 이미 zstd였습니다. 둘 다 정상입니다.
pending_data_bytes가 평시 0 근처를 벗어나 계속 증가하면 목적지 병목 신호입니다.
카디널리티 감시(churn rate · slow insert)는 D2 개념을 계승합니다 → 실전 01 카디널리티. 인벤토리는 vmui + metric_names_stats로 뽑습니다.

Phase 1이 제대로 적용됐는지 전송이 건강한지 판정할 때 보는 자기감시(self-monitoring) 메트릭을 정리합니다. 02의 적용 후 확인이 여기로 이어집니다.

스케일링·용량 기준치

Sat, 18 Jul 2026 00:00:00 +0900

04 · 스케일링·용량 기준치

디스크 큐 상한 산정식: sum(rate(vmagent_remotewrite_bytes_sent_total[1h])) × 버틸 장애 시간 (실측 후 조정). 현행 stage 1000MiB / prod 2000MiB.
vmagent 리소스는 현행값을 기준치로 두고, 실측 후 조정은 TODO로 남깁니다.
HA(replicaCount: 2)는 의도적 미적용 — replica가 각자 전량 전송해 cross-cluster 트래픽이 2배가 되고 dedup은 저장만 절약하므로 전송 절감 목표와 상충합니다.
slow insert 지속 10% 초과 = 메모리 부족 경고 (D2 계승) → 실전 01 카디널리티.

큐 상한·리소스·HA·메모리 임계를 어떤 근거로 잡는지 적어 둡니다. 확정 숫자보다 판단 기준과 산정식에 무게를 둡니다 — 실제 값은 실측으로 조정합니다.