makgol's note – 관측성

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편의 결정과 대조한 설계 검토입니다.

대규모 메트릭 운영, Prometheus와 VictoriaMetrics 중 무엇을 고를까

Wed, 21 Oct 2026 00:00:00 +0900

대규모 메트릭 운영, Prometheus와 VictoriaMetrics 중 무엇을 고를까

메트릭이 많아지면 Prometheus의 익숙함만으로는 선택을 설명하기 어려워집니다. VictoriaMetrics는 저장 효율을 강조하고, 클러스터 모드에서는 수집·저장·쿼리를 따로 늘릴 수 있습니다. 이때 단일 서버로 동작하는 Prometheus에 어떤 이점이 남는지 궁금해집니다.

멀티클러스터 메트릭: Thanos와 VictoriaMetrics 구성

Wed, 21 Oct 2026 00:00:00 +0900

멀티클러스터 메트릭: Thanos와 VictoriaMetrics 구성

여러 Kubernetes 클러스터의 메트릭을 모을 때, 중앙에서 장기간 한 번에 조회하는 것과 WAN이 끊겨도 각 지역에서 경보를 계속 내는 것은 별개의 요구입니다. 대규모 중앙 운영이 목적이라면 각 클러스터의 HA vmagent가 하나의 중앙 리전에 둔 VMCluster로 보내는 구성을 출발점으로 삼을 수 있습니다. 지역 자립이 필수라면 현장 저장소와 vmalert가 필요하고, 중앙 데이터 사본을 만들지 조회만 합칠지를 추가로 정합니다.

부록 · EBS gp2·gp3 fio 실측은 gp3 선택을 어디까지 뒷받침하는가

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

부록 · EBS gp2·gp3 fio 실측은 gp3 선택을 어디까지 뒷받침하는가

100 GiB gp2에서 짧은 부하 시험만 하면 버스트 소진 뒤의 성능을 놓칠 수 있습니다. atomai의 EBS gp2 vs gp3 실측 벤치마크는 m5.xlarge 노드에 gp2와 gp3를 붙여 각각 fio로 측정했습니다. gp2는 2,700초 실행 중 약 33분이 지난 뒤 3,000 IOPS에서 300 IOPS로 내려갔습니다. 별도로 600초 측정한 gp3는 3,000 IOPS 근처를 유지했습니다.

부록 · 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%입니다(계산).

수집 경로 다시 그리기 — Vector와 ClickHouse

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

수집 경로 다시 그리기 — Fluent Bit·Firehose를 Vector로, 저장소를 ClickHouse로

fluent-bit → Firehose → OpenSearch에서 Firehose를 빼면 수집 요금과 버퍼 지연을 줄일 수 있지만, 버퍼·재시도·실패 로그 보관을 직접 운영해야 합니다. Fluent Bit까지 교체할지는 별도로 정할 수 있습니다. 저장소를 ClickHouse로 옮긴다면 배치 크기와 테이블 스키마도 함께 바뀝니다.

스택 구성

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 전송 튜닝에서, 장기보관 아키텍처는 메트릭 장기보관 챕터에서 따로 다룹니다.

카디널리티

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

01 · 카디널리티 — 시계열 폭발의 원리와 설계 원칙

시계열 = 지표 이름 + 레이블 집합. 레이블 값 하나만 달라도 완전히 다른 시계열이 됩니다.
New TSID 발급(=처음 보는 시계열)이 곧 카디널리티 폭발입니다. IndexDB에 인덱스를 쓰는 연산이라 데이터포인트 추가보다 CPU·메모리를 훨씬 많이 먹습니다.
Worst case는 pod_name·session_id처럼 자주 바뀌는 값을 레이블로 쓰는 것입니다. Best case는 설계 단계에서 배제하는 것 — 서비스 이름 같은 안정 레이블만 쓰고 자주 바뀌는 값은 로그·트레이스로 뺍니다.
런타임에는 churn rate(신규 시계열 생성 속도)와 slow insert rate(지속 10% 초과 시 메모리 부족 경고)를 봅니다.

VM 운영에서 가장 자주 사고를 내는 개념이 카디널리티입니다. 출발점은 “한 시계열이 무엇으로 정의되는가"입니다. 거기서 카디널리티 폭발이 왜 곧 메모리·인덱스 폭발인지, 설계 단계에서 어떻게 막는지까지 이어 봅니다.

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

03 · 쿼리 패턴 — PromQL에서 MetricsQL까지

지표 타입이 쿼리를 결정합니다 — Counter는 rate/increase, Gauge는 순간값·sum/avg_over_time, 지연 분포는 histogram_quantile, 차원을 접는 sum by 가 실전 4대 패턴입니다.
VM 계열 클라이언트의 히스토그램은 le 대신 vmrange 버킷을 씁니다(클래식 le 히스토그램도 그대로 저장·쿼리됩니다) — MetricsQL histogram_quantile는 vmrange를 그대로 받고 Prometheus 형식이 필요하면 prometheus_buckets() 로 변환합니다.
MetricsQL은 PromQL 상위호환입니다 — rate/increase가 외삽하지 않고 range를 생략하면 창을 max(step, scrape_interval)로 자동 결정하며 default_rollup·keep_metric_names·WITH·topk_avg 등 확장을 더합니다.
무거운 쿼리(넓은 시간범위 × 고카디널리티)는 vmselect 메모리를 먹습니다 — 차원 축소·recording rule 선계산·캐시로 회피하고 카디널리티는 /api/v1/status/tsdb 와 vmui 카디널리티 익스플로러로 점검합니다.

01 카디널리티와 02 대규모 운영이 “무엇을 저장하고 어떻게 운영하는가"였다면, 이 문서의 주제는 저장한 것을 어떻게 꺼내 읽는가 — 곧 쿼리입니다. VM은 PromQL을 그대로 받으면서 그 상위호환인 MetricsQL로 확장합니다. 지표 타입별 실전 패턴, MetricsQL만의 확장, 무거운 쿼리의 회피, 카디널리티 점검 쿼리를 차례로 정리합니다.

스케일링·용량 기준치

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·메모리 임계를 어떤 근거로 잡는지 적어 둡니다. 확정 숫자보다 판단 기준과 산정식에 무게를 둡니다 — 실제 값은 실측으로 조정합니다.

우리 배포 형상 — 자체 RUM 컨버터·6 실행 단위·stage/prod 격차

Thu, 13 Aug 2026 00:00:00 +0900

우리 배포 형상

우리 RUM 데이터는 자체 컨버터를 거쳐 ClickHouse에 들어갑니다. 브라우저 SDK와 Mobile RUM이 보내는 데이터를 받기 위해 Datadog Agent의 RUM 전송 방식을 참고해 구현했습니다. 표준 로그·트레이스·메트릭은 별도의 OTel Collector로 수집합니다. 두 수집기는 서로 호출하지 않고 ClickHouse에서 데이터를 합칩니다 ✓.

HyperDX / ClickStack 심층 분석

Mon, 13 Jul 2026 00:00:00 +0900

HyperDX / ClickStack을 RUM에 도입하기 전에

HyperDX는 브라우저 세션 리플레이에서 백엔드 트레이스와 로그로 이어지는 조사 흐름을 제공합니다. Datadog 웹 RUM을 옮기려는 이유가 이 흐름이라면 검토할 만합니다. 다만 SDK로 수집할 수 있는 범위, 기존 녹화와 설정의 이관, 여러 팀의 접근 권한은 각각 확인해야 합니다.

Datadog RUM 커버리지 — 어디까지 대체되나

Mon, 13 Jul 2026 00:00:00 +0900

Datadog RUM 커버리지 — 어디까지 대체되나

RUM을 하나로 묶어 “대체된다/안 된다"고 답하면 틀립니다 — 성격이 다른 하위 제품 4개로 쪼개야 판정이 섭니다.
RUM-Core(세션 리플레이+CWV 수집/에러+트레이스 상관) 🟢 PoC(Wave 1) · RUM-Frustration 🟡 SQL 사후계산 · RUM-PA(퍼널/리텐션) 🔴 자작/PostHog 병행 · RUM-Mobile 🔴 OTel+Embrace/OpenReplay.
대체는 프록시가 아니라 @hyperdx/browser SDK 교체입니다 — datadogreceiver는 브라우저 RUM intake(/api/v2/rum)를 아예 수신하지 않습니다.
좌절 신호·모바일 리플레이는 네이티브 프리미티브가 없다고 확인했습니다(추측 격상 아님) — ClickHouse SQL(sequenceMatch/windowFunnel) 자작 또는 전용 툴이 필요합니다.
“Datadog RUM을 HyperDX로 대체한 공개 프로덕션 사례"는 찾지 못했습니다 → dual-instrument PoC 성공을 Wave 1 진입 게이트로 명문화합니다.

“coverage가 어디까지 되나"에 답하는 페이지입니다. HyperDX 심층 실사가 플랫폼 관점(연혁·아키텍처·거버넌스 갭)을 다뤘다면 여기서는 Datadog RUM의 기능을 하나씩 @hyperdx/browser와 대조해 어디까지 1:1로 넘어오고 어디서 끊기는지를 확정합니다.

Datadog 프로토콜 프록시 매핑

Mon, 13 Jul 2026 00:00:00 +0900

Datadog 프로토콜 프록시 매핑 — 어디까지 성립하나

프록시는 Agent intake(로그·인프라 메트릭·APM 트레이스)에서만 성립하고 브라우저 RUM·세션 리플레이 intake에는 성립하지 않습니다 — RUM은 @hyperdx/browser SDK 교체가 정답입니다.
성립하는 영역조차 datadogreceiver가 전 신호 alpha라 과도기 무중단 브릿지로만 쓸 만하고 영구 아키텍처로는 맞지 않습니다.
dd browser-sdk의 proxy 옵션은 트래픽을 우회시키는 진입점일 뿐 변환용은 아닙니다 — 본문 불변(바이너리 그대로 포워딩)이 설계 전제입니다.
변환 계층은 native 대비 최대 ~200배 CPU, delta 메트릭 30~70% 손실(#44907) 등 fidelity 결함이 실증됐습니다.
“dd 인테이크를 ClickHouse/HyperDX로 변환해 프로덕션 운영한다"는 회사명이 붙은 1차 사례를 찾지 못했습니다.

“dd agent/dd-trace 오픈소스 코드를 참조해 Datadog 인테이크 트래픽을 그대로 받아 HyperDX/ClickHouse로 변환하는 프록시 계층"을 직접 만들 수 있는지 검증합니다. 결론부터: 프록시는 Agent intake(로그·인프라 메트릭·APM 트레이스)에서만 성립하고 브라우저 RUM·세션 리플레이 intake에는 성립하지 않습니다. RUM은 SDK 교체가 정답입니다(Datadog RUM 커버리지). 로그/메트릭/APM에서 성립하는 프록시도 과도기 무중단 브릿지까지만 합당하고 영구 아키텍처로 두기엔 무리입니다 — 성숙도(alpha), 변환 CPU 세금, 프로덕션 전례 부재 때문입니다.

Datadog 전 제품군 대체 매트릭스

Mon, 13 Jul 2026 00:00:00 +0900

Datadog 전 제품군 대체 매트릭스 — RUM 너머로 확장하기

HyperDX/ClickStack은 Datadog의 MELT+세션리플레이 코어(Logs·Traces·RUM 웹코어·Session Replay)를 커버하지만 나머지 절반(Security·Synthetics·NPM/DBM·CI·On-Call 등)은 범위 밖 — 전용 OSS 개별 이관 또는 Datadog 잔류.
메트릭 계층은 VictoriaMetrics+Grafana로 분리합니다 — HyperDX의 PromQL은 실험 기능이고 일반 otel_metrics_*에 자동 적용되지 않으며 ClickHouse SQL을 겨냥한 변환기도 없습니다.
Wave 이관: 1 RUM웹코어 → 2 Logs → 3 APM → 4 Metrics(VM) → 5 나머지 개별. Wave 4를 HyperDX로 잡으면 공수가 2~4배 팽창합니다.
절감은 대부분 스토리지 이관에서 나오지만 host high-water mark·custom metrics tax 같은 과금 함정과 인건비 상쇄를 함께 계산해야 합니다.
Grafana OnCall OSS는 2026-03-24 아카이브 예정이므로 On-Call 대안으로 신규 채택하지 않습니다.

RUM 하나만 빼오는 것으로는 Datadog 청구서가 크게 줄지 않습니다. RUM은 진입점이고 실제 절감은 로그·트레이스·메트릭 “스토리지"를 옮길 때 나옵니다. 이 페이지는 웹 RUM 내재화(RUM 대체 커버리지)를 넘어 Datadog 전 제품군을 어디까지, 무엇으로 대체하는가를 의사결정 관점에서 정리합니다.

마이그레이션 로드맵

Mon, 13 Jul 2026 00:00:00 +0900

마이그레이션 로드맵 — Datadog 이관 실행 계획

이 로드맵은 2026-07의 표준 SDK 교체·로컬 NVMe 전제에 따른 계획입니다. 아래 체크리스트는 실행 완료 기록이 아닙니다. 이후의 우리 배포 형상은 자체 RUM 컨버터·EBS 기반 stage를 기록하므로 그 경로에 맞춰 검증 항목을 조정해야 합니다. 2026-09의 PromQL·Terraform·Datadog 수신 변경은 커버리지 재판정을 기준으로 읽습니다.

RUM 참고 자료

Mon, 13 Jul 2026 00:00:00 +0900

출처 — RUM 섹션 조사 문서 원본 링크

RUM 섹션(01~05)의 근거는 research/hyperdx-clickhouse/ 아래 조사 문서 8개입니다 — 01-hyperdx-deep-dive, 02-rum-replacement, 03-datadog-replacement-matrix, 07-recommendation, 08-supplement-1~2·4~5. 이 페이지는 그 문서들의 “## 출처” 섹션에 나열된 URL을 전부 모아 중복을 걷어내고 주제별로 재정리했습니다. 개별 URL이 본문 어느 주장을 뒷받침하는지는 각 조사 문서를 직접 대조해야 합니다. 이 페이지는 색인 목적으로만 씁니다. HyperDX의 MongoDB(07)는 별도 딥리서치(3-vote 적대검증, 2026-07-15) 기반입니다. 그 근거 URL도 아래 표에 포함했습니다. 조사 기준 2026-07.

HyperDX 커버리지 재판정 — Datadog 대비 2026-09

Tue, 08 Sep 2026 00:00:00 +0900

HyperDX 커버리지 재판정 — Datadog 대비 2026-09

2026-07 조사에서 미지원으로 적거나 범위를 좁게 보았던 PromQL·Terraform·알림 기능을 2026-09에 다시 확인했습니다. 이 변화는 Datadog에서 옮길 수 있는 작업을 늘려 주지만, 기존 RUM 녹화와 모니터 설정을 그대로 가져올 수 있다는 뜻은 아닙니다.

Prometheus가 하지 않는 일

Sun, 30 Aug 2026 00:00:00 +0900

Prometheus가 하지 않는 일 — 리텐션의 경계

Prometheus 리텐션을 늘려 장기 보관을 해결하려다 보면 곧 벽을 만납니다. 기간을 늘리면 용량이 선형으로 늡니다. 해상도를 깎아 완만하게 만들 방법이 Prometheus 안에는 없습니다.

Thanos Compactor가 채우는 자리

Sun, 30 Aug 2026 00:00:00 +0900

Thanos Compactor가 채우는 자리 — 다운샘플링의 실제 동작

Prometheus에 없는 해상도 티어링은 Thanos Compactor가 맡습니다. 오브젝트 스토리지 버킷을 훑으면서 블록을 병합하고 해상도를 깎은 블록을 새로 만들고 만료된 블록을 지웁니다.

Sidecar vs Receive

Sun, 30 Aug 2026 00:00:00 +0900

Prometheus에 붙이는 두 방식 — Sidecar vs Receive

“Thanos를 붙인다"는 한마디가 전혀 다른 배치 둘을 가리킵니다. 어느 쪽을 고르느냐에 따라 방화벽 정책과 장애 반경이 달라집니다.

VictoriaMetrics에 Thanos를 붙일 수 있나

Sun, 30 Aug 2026 00:00:00 +0900

VictoriaMetrics에 Thanos를 붙일 수 있나

“Prometheus를 VictoriaMetrics로 바꾸고 뒤에 Thanos를 붙여 S3 장기 보관을 한다"는 그림이 자연스러워 보입니다. 성립하지 않습니다.

Receive 실전 구성

Sun, 30 Aug 2026 00:00:00 +0900

Thanos Receive 실전 구성

앞 문서들의 결론을 배치로 옮깁니다. 파드 넷이 뜹니다 — Receive, Compactor, Store Gateway, Querier. 여기에 캐시를 붙이면 다섯입니다.

vmagent / Prometheus(agent) ──remote write──▶ Receive (로컬 TSDB → 2h마다 업로드)
│
▼
오브젝트 스토리지
▲
Compactor (병합·다운샘플·리텐션, 싱글턴)
│
Grafana ◀── Querier ◀── Store Gateway ────────────┘
└────── Receive (최근 구간)

버킷 설정 (공통)

네 컴포넌트가 같은 파일을 Secret으로 마운트합니다.

Thanos·VM·Mimir 선택 가이드

Sun, 30 Aug 2026 00:00:00 +0900

무엇을 고를 것인가

앞의 다섯 문서를 판단 순서로 압축합니다.

첫 질문 — 해상도 티어링이 정말 필요한가

필요 없을 수 있습니다. 카디널리티가 크지 않으면 raw를 그대로 오래 들고 가는 편이 단순하고 쌉니다.

스택 토폴로지 — 4컴포넌트 배치·데이터 흐름·MongoDB 최소 배포

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

ClickStack을 Kubernetes에 배치하기

ClickStack을 Kubernetes에 올릴 때는 텔레메트리가 저장되는 경로와 HyperDX의 설정이 저장되는 경로를 따로 따라가면 배치가 이해됩니다. 브라우저가 보낸 이벤트는 Collector를 거쳐 ClickHouse로 들어가고, 사용자·대시보드·알럿 설정은 HyperDX API가 MongoDB에 저장합니다. 두 데이터베이스의 크기와 장애 영향이 다른 이유도 이 흐름에 있습니다.

OpenSearch (EFK)

Sun, 12 Jul 2026 00:00:00 +0900

OpenSearch (EFK) — 지금 쓰는 것, 왜 뚱뚱해 보이는가

강점은 임의 필드 ad-hoc 풀텍스트·고카디널리티 검색, SIEM/보안 완제품, 관리형 운영의 낮은 인건비입니다.
약점은 로그 저장 목적에 비해 컴퓨트가 무겁다는 점입니다 — 비용의 ~90%가 인스턴스 시간이고 스토리지는 ~10%뿐입니다.
UltraWarm은 예약(RI) 불가(hot만 예약 가능)라 전 클러스터 블렌디드 절감 상한이 ~25%에 그칩니다 — “40% 절감” 기대는 성립하지 않습니다.
진짜 절감은 보존 tail을 컬럼나+S3로 옮기고 hot을 축소·OR로 전환하는 데서 나옵니다. 이게 hot RI 최대 절감보다 큽니다.
우리 케이스: 90일 보존이 정말 필요한지부터 되묻습니다. tail 이전 + in-place 최적화를 먼저 합니다.

Apache Lucene 기반 분산 검색·분석 엔진입니다. 2021년 Elastic이 SSPL로 전환한 뒤 Elasticsearch 7.10.2 / Kibana를 포크해 만들었습니다. 라이선스는 Apache 2.0이고 지금은 OpenSearch Software Foundation(Linux Foundation)이 관리합니다 — 성숙도·생태계가 넓고 프로덕션 채택이 두텁습니다. AWS에서는 관리형 Amazon OpenSearch Service로 제공됩니다. 고객사는 fluent-bit → Firehose → OpenSearch(+ UltraWarm)로 운영 중입니다. 파이프라인 구성 자체는 정석입니다. 쟁점은 로그 저장 용도에 비춘 요금 구조입니다.

TSDB와 VictoriaMetrics

Sun, 12 Jul 2026 00:00:00 +0900

01 · 시계열 데이터와 VictoriaMetrics

시계열은 “언제 어떤 숫자가 찍혔나"가 이어지는 데이터입니다. 지표에는 Counter/Gauge/Histogram/Summary 4타입이 있습니다. 그중 Counter류 단조증가값이 압축이 가장 잘 됩니다.
“대용량"을 나누는 기준은 시계열 개수와 보관 기간입니다. 수백만 개까지는 Prometheus 단일로 충분하지만 수천만~수십억 개부터는 별도 솔루션이 필요합니다.
TSDB 계보: Prometheus(2012) → Gorilla 압축(2015, Facebook) → Thanos/Cortex(Prometheus 확장) vs VictoriaMetrics(완전히 다른 계열).
VM은 Prometheus 호환(PromQL·remote_write 그대로)을 지키면서 자체 벤치마크 기준 메모리 5배·스토리지 7배 효율을 주장하는 오픈소스 TSDB입니다.

시계열 데이터가 무엇인지, 왜 “대용량"이 별도의 문제로 떨어져 나오는지, 그 문제를 푸는 도구로서 VictoriaMetrics(이하 VM)가 어디에 서 있는지를 정리합니다. VM 내부의 컴포넌트 구조는 02 아키텍처로 넘깁니다.

문제와 결정 2축

Sun, 12 Jul 2026 00:00:00 +0900

문제 정의와 결정 2축

목적은 과거 장애 재조사용 메트릭 400일 보관. >90d 구간은 5m 해상도 허용(확정), 전 메트릭 커버리지 필요, OSS 우선.
결정은 2축: (1) 무엇을 보관하나(raw 400d 전부 vs raw 90d + 5m 집계 400d — 후자가 비용을 자릿수로 낮춥니다) · (2) 어디에 저장하나(VM은 S3를 primary로 지원하지 않아 EBS 위에 둡니다).
서울 리전 단가는 sc1 < S3 Standard < st1 < gp3 — “S3라서 싸다"는 성립하지 않습니다.
확정 시나리오(raw 90d + 5m 집계 400d) 기준 VM 아카이브안이 월 $385~416로 최저, 단순 확장($1,642)보다 자릿수로 쌉니다.

메트릭 400일 보관 문제를 정의하고 비용을 자릿수 단위로 좌우하는 두 결정축(무엇을 보관 / 어디에 저장)을 정리합니다. 시나리오별 저장량·비용 규모와 검증된 서울 리전 단가 요약표를 함께 싣습니다.

운영 런북 — 장애·변경이 났을 때 무엇을 어떤 순서로

Thu, 13 Aug 2026 00:00:00 +0900

HyperDX 운영 런북

장애가 나면 조회와 적재 중 어느 쪽이 멈췄는지 확인합니다. 우리 구성은 RUM 컨버터와 OTel Collector가 별도로 ClickHouse에 쓰므로, 수집 장애도 두 경로를 나누어 확인해야 합니다.

hot 스토리지 — EBS gp3 / io2 실전 (로컬 NVMe는 옵셔널)

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

ClickHouse hot 데이터를 gp3에 저장하기

월 0.7TB의 RUM 데이터를 저장하는 ClickHouse라면 노드마다 gp3 볼륨 하나를 붙이는 구성으로 시작할 수 있습니다. 볼륨의 최대 IOPS를 높이기 전에 확인할 것은 EC2 인스턴스가 지속적으로 처리할 수 있는 EBS 대역폭입니다. 중간 크기의 r7g에서는 볼륨보다 인스턴스 쪽 한도에 먼저 닿을 수 있습니다.

아키텍처

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

02 · 아키텍처 — 4개 컴포넌트와 저장 원리

VM 클러스터는 vmagent(수집) → vminsert(라우팅·샤딩) → vmstorage(저장, n노드) → vmselect(fanout+merge 쿼리) 4컴포넌트로 흐릅니다.
배포 모드는 SingleNode(간편, SPOF)와 Cluster(수평확장, replicationFactor로 유실 방지) 둘입니다. vminsert/vmselect는 stateless라 k8s에, vmstorage는 stateful이라 물리 장비에 두는 편이 유리합니다.
대용량 write와 read를 함께 만족시키는 자료구조가 LSM 트리(append로 빠른 write, 정렬 유지로 빠른 read, merge는 백그라운드)입니다. VM의 파티션 구조가 이 구체화입니다.
IndexDB(거의 불변, 지표이름+레이블 역색인)와 DataDB(TSID → timestamp+value, 계속 쌓임)를 나눠 두면 정규화 효과로 압축 효율이 크게 올라갑니다.

여기서는 VM 클러스터를 이루는 컴포넌트, 그 사이를 흐르는 데이터, 그 아래를 떠받치는 두 아이디어 — LSM 트리와 IndexDB/DataDB 분리 — 를 정리합니다. 컴포넌트 하나하나의 내부 동작은 뒤 문서에서 따로 깊게 파고듭니다.

초대규모 운영과 무중단 전환

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

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

진화 경로: SingleNode(SPOF) → Cluster(이질적 접근 패턴이 한 클러스터를 과부하) → 멀티버스(대시보드·알람별 클러스터 분리) + vmauth 라우팅.
현재 규모: 180노드(Hot 120·Warm 60), 12.5억 활성 시계열, 555조 데이터포인트(0.92바이트/DP) — 공개 사례 중 최상위권.
Hot/Warm 2계층(SSD 12개월/HDD 36개월)으로 성능·비용 균형을 잡습니다 — dual write + 쿼리 시간범위 기반 읽기 분기.
무중단 128GB→512GB 장비 전환: Hot은 랑데부 해싱 역순 추가(기존 장비 부하 최소화), Warm은 vmbackup/vmrestore(vmctl은 API 부하로 배제) — 서비스 중단 0분·메트릭 유실 0건.

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

Loki + Alloy

Sun, 12 Jul 2026 00:00:00 +0900

Loki + Alloy — PLG를 ALG로 되살리기

object storage 네이티브 + 공격적 압축으로 장기 보존 비용이 낮습니다. Lucene/OpenSearch 대비 스토리지가 ~10–15× 적습니다.
카디널리티는 foot-gun입니다. 나쁜 라벨 하나가 수백만 스트림·ingester OOM으로 이어집니다. structured metadata가 완화하지만 그 규율은 팀이 지켜야 합니다.
풀텍스트/미지값 검색이 느립니다. label+time으로 못 좁히면 brute-force decompress-scan이라 VictoriaLogs 대비 최대 십수 배 느리다는 벤치가 있습니다.
promtail은 EOL 확정(2026-03-02)이고 Simple Scalable(SSD) 모드는 Loki 4.0에서 제거 예정입니다. 지금 SSD 위에 새로 지으면 sunset feature 위에 짓게 됩니다.
우리 케이스: istio access-log엔 잘 맞지만 스택을 하나 더 들이는 것 자체가 방치(rot) 리스크라 보류합니다.

Grafana 진영의 로그 집계 스택(AGPLv3). 로그 본문이 아니라 라벨 집합(스트림)만 인덱싱합니다. 압축 청크는 object storage에 두어 값싸게 보존하는 설계입니다. 2018년 공개 후 3.7.x로 성숙했고(최신 패치 v3.7.3, 2026-06-24), promtail이 EOL되며 Alloy가 자리를 넘겨받아 PLG(Promtail-Loki-Grafana)가 ALG(Alloy-Loki-Grafana)로 재편됐습니다.

VictoriaMetrics 아카이브

Sun, 12 Jul 2026 00:00:00 +0900

VictoriaMetrics 아카이브 — 라우터 RW#4 + streamAggr 5m → vmsingle 400d

권장안: 기존 라우터 vmagent에 RW#4를 추가하고 streamAggr로 전 메트릭을 5m 집계해 별도 vmsingle-archive(400d, RF1)에 적재합니다 — 신규 기술 0.
월 $385~416, 단순 확장안($1,642) 대비 ~70% 절감. hot(raw 90d)은 그대로 남습니다. keep_metric_names로 기존 쿼리·대시보드도 그대로 동작합니다.
리스크: 집계는 인제스트 시점에 확정돼 사후 재계산이 불가, RF1이라 vmbackup으로 이중화를 보완, 접미사 휴리스틱 오분류 가능성.
구조는 가역적입니다 — RW#4를 Thanos Receive로 교체하면 Thanos안으로 전환됩니다. 드라이런 2주로 집계 축소율(f)을 실측한 뒤 확정합니다.

관련 문서: 01 문제·2축, 03 Thanos, 05 VMCluster 확장, 06 스토리지 단가, 07 streamAggr vs downsampling, 08 권장·하지말것

S3 콜드 티어링 — storage_configuration

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

ClickHouse의 오래된 데이터를 S3로 옮기기

보존 기간을 늘리면 오래된 로그와 트레이스가 EBS 용량을 계속 차지합니다. 이 구성에서는 최근 데이터는 gp3에 남기고, 일정 시간이 지난 파트를 S3 Standard로 옮깁니다. ClickHouse가 두 위치를 함께 조회하므로 HyperDX에서 저장 위치를 나눠 다룰 필요는 없습니다.

수집 (vmagent·vminsert)

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

03 · 수집 — vmagent와 vminsert

vmagent는 OTel·InfluxDB·Datadog 등 다양한 프로토콜을 받아 릴레이블·dedup·스트리밍 집계 후 remote_write로 내보내는 만능 어댑터입니다. Fast Queue(메모리)→Persistent Queue(디스크) 버퍼링으로 지표를 잃지 않습니다.
vminsert는 저장하지 않고 랑데부 해싱으로 vmstorage에 라우팅만 합니다 — 노드를 추가해도 재배치가 약 1/(N+1)에 그쳐 리밸런싱 폭풍을 피합니다.
노드 다운 시 페일오버(살아있는 노드로 균등 재분배), replicationFactor로 복제 후 vmselect 쿼리 시 dedup — 쓰기 시점 복제(안정성)와 읽기 시점 dedup(정확성)이 짝을 이룹니다.
vminsert↔vmstorage 연결은 압축 방식을 협의하며 rpc.disableCompression으로 CPU↔대역폭 트레이드오프를 조절할 수 있습니다.

VM에서 데이터가 들어오는 관문은 둘입니다. vmagent는 무엇이든 받아 정제해 리모트로 흘려보내는 만능 어댑터이자 버퍼입니다. vminsert는 그렇게 받은 데이터를 여러 vmstorage 노드로 흩뿌리는 라우팅 게이트웨이입니다. 이 둘을 차례로 봅니다.

의사결정 가이드 — 기본값·승급 트리거·실측 체크리스트

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

HyperDX 구성을 언제 바꿀 것인가

디스크가 느려졌다고 곧바로 io2로 옮기거나, Keeper 부하가 늘었다고 노드를 두 대 더 추가할 필요는 없습니다. 볼륨 대역폭, 인스턴스 한계, 작은 INSERT가 만드는 part 수처럼 원인에 따라 조치가 달라집니다. 반면 AZ 장애 중에도 쓰기를 계속해야 한다는 요구는 현재 부하가 작아도 replica 구성을 바꿀 이유가 됩니다.

Thanos

Sun, 12 Jul 2026 00:00:00 +0900

Thanos — Receive → S3 (cold 400d, compactor downsampling)

raw는 S3에 짧게(7~30d)만 두고 400d 보관은 compactor가 사후에 만들어내는 5m/1h 다운샘플 블록이 맡습니다 — S3 내구성(11-nines) + 사후 재계산 보험을 얻는 대신 stateful 컴포넌트 3~4종과 더 높은 비용을 치릅니다.
다운샘플링은 저장 절감 수단이 아닙니다(공식 명시) — 해상도가 공존하는 구간이 ~3x로 부풀어 총액이 월 $780~1,200 + 컴퓨트가 됩니다.
Receive는 hashring 상태를 쥔 StatefulSet이라 반드시 chain에 둬야 하고 Compactor는 오류를 만나면 알림 없이 halt하므로 감시 알림이 필수입니다.
아카이브 쿼리는 PromQL 전용이 되어 MetricsQL 전 기능을 상실합니다 — 대신 VM 아카이브안에서 RW#4 대상만 교체하면 언제든 이 안으로 전환 가능합니다.

VM hot은 단기로 유지하고 raw는 S3에 짧게만 쌓습니다. 400d를 채우는 쪽은 Thanos compactor가 사후에 생성하는 5m/1h 다운샘플 블록입니다. 이 구성으로 S3 내구성 + 사후 재계산 보험을 얻고 대가로 stateful 컴포넌트 3~4종과 더 높은 저장비를 치릅니다.

VictoriaLogs

Sun, 12 Jul 2026 00:00:00 +0900

VictoriaLogs — VM을 이미 쓴다면 가장 자연스러운 선택

단일 static Go 바이너리·외부 의존성 0 — 벤더 주장으로 RAM 최대 30x·디스크 최대 15x 절감, 소규모 3rd-party 벤치도 같은 방향을 확인합니다.
쿼리 가능한 오브젝트 스토리지 티어가 없습니다(headline gap). 현재 local-disk-only이고 S3/GCS 백엔드는 로드맵 WIP·확정 일정 없음.
클러스터 내 복제(HA)가 없습니다 — 진짜 HA는 독립 클러스터 2벌 + mirror가 필요해 스토리지 비용이 대략 2배가 됩니다.
넓은 수집 호환(Loki push API 포함)에 VictoriaMetrics와 동일한 운영 모델 — 이미 VM을 운영 중이면 학습·rot 비용이 0에 가깝습니다.
우리 케이스: istio 로그부터 넣으면 오브젝트 스토리지 부재가 걸리지 않고 cold tail만 S3 Parquet로 분리하면 됩니다.

VictoriaMetrics 패밀리의 로그 전용 저장소로, 단일 static Go 바이너리 · 외부 의존성 0으로 돌아갑니다. 코어는 오픈소스(Apache-2.0)이고 일부 기능(vlagent의 Kafka 소스, 테넌트별 stats/quota 등)만 Enterprise-gated입니다. 단일 노드는 v1.0.0(2024-11-12)에서 GA(“production-ready”)에 도달했고 클러스터 모드는 2025-06에 공개돼 아직 ~1년 된 젊은 축입니다. 릴리스가 잦아(2026년에도 v1.50·v1.51 등 분기당 수 회) 활발하지만 그만큼 버전 pin이 필요합니다.

operator 토폴로지·다운타임 — EBS 재부착이 바꾸는 복구 모델

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

EBS 기반 ClickHouse의 장애와 복구

ClickHouse 노드가 내려갔을 때 EBS 볼륨에 데이터가 남아 있다면 새 노드에서 처음부터 채울 필요는 없습니다. 같은 AZ에 볼륨을 다시 붙이고 ClickHouse를 시작한 뒤, 중단 중 쌓인 파트만 따라잡으면 됩니다. 다만 볼륨이 살아 있다는 사실과 요청을 처리할 수 있다는 사실은 다릅니다. 재부착이 끝날 때까지는 남은 replica가 부하를 맡습니다.

저장과 압축

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

04 · 저장과 압축 — vmstorage와 Gorilla 계열 압축

지표는 Time Series(이름+레이블, 거의 불변)와 Sample(timestamp+value, 계속 쌓임)로 분리 저장됩니다 — IndexDB/DataDB 정규화의 근거.
저장 경로: 로우 파싱 → Canonical Name 정규화 → TSID 변환(캐시 hit=빠른 경로, miss=New TSID 발급=카디널리티 폭발 원인) → 압축 → 파티션(인메모리→Small→Big, Merge Multiplier로 비슷한 크기끼리 합침).
압축 비결은 Gorilla 계열 차분 인코딩: Gauge→Delta, Counter→Delta-of-Delta(단조증가값이 압축에 극단적으로 유리) + ZigZag/Varint로 바이트 절약. 네이버 실운영 실측 0.92바이트/데이터포인트(원래 16바이트 대비 ~17배 압축).
retention은 기본 1개월, IndexDB는 단건 삭제 비용을 피하려 3단계(Current/Previous/Next) 로테이션으로 통째로 드롭합니다.

vminsert가 흩뿌린 데이터를 실제로 디스크에 눕히는 컴포넌트가 vmstorage입니다. 여기서는 지표 하나가 TSID로 바뀌어 파티션에 저장되기까지의 경로를 따라갑니다. 이어서 VM의 메모리·스토리지 효율을 떠받치는 Gorilla 계열 차분 압축을 다룹니다.

ClickHouse (self-hosted)

Sun, 12 Jul 2026 00:00:00 +0900

ClickHouse를 로그 저장소로 운영한다면

ClickHouse는 로그를 SQL로 검색하고 집계할 수 있는 컬럼형 OLAP 데이터베이스입니다. Yandex에서 시작한 Apache-2.0 프로젝트로, 로그·트레이스·이벤트를 함께 저장하는 용도로도 쓰입니다. 저장량을 줄이고 대규모 집계를 빠르게 처리할 여지가 있지만, 직접 운영하려면 스키마와 복제, 백업을 담당할 사람이 필요합니다.

Mimir

Sun, 12 Jul 2026 00:00:00 +0900

Mimir — Grafana Mimir 장기 tier

Mimir는 다운샘플링이 OSS·GEM·3.0 어디에도 없어 “5m 해상도 400d” 요구를 원리적으로 충족할 수 없습니다 — 이 시나리오에서 탈락.
유일한 실현 형태는 raw 400d 전부 S3 — 경제성이 시나리오 ①(전 구간 raw)로 되돌아가 월 ~$740 + Kafka·컴퓨트.
운영 footprint가 최대입니다 — distributor/ingester/compactor/store-gateway/querier/query-frontend에 3.0부터 Kafka 기본 의존까지 8~10종.
PromQL 전용이라 MetricsQL을 잃는 건 Thanos안과 같습니다. 재검토는 대규모 멀티테넌시·Grafana 스택 표준화가 독립 목표일 때만.

관련 문서: 01 문제·2축, 02 VictoriaMetrics, 03 Thanos, 07 핵심논점 · PromQL vs MetricsQL은 VM 쿼리·컴포넌트

ClickHouse Keeper — 조정 계층이지 durable queue가 아니다

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

ClickHouse Keeper와 수집 데이터의 내구성

ClickHouse에 이벤트를 보낸 직후 서버가 꺼졌다고 가정해 봅니다. Keeper 세 대가 모두 살아 있어도 수신 중이던 이벤트를 대신 보관해 주지는 않습니다. 이벤트 본문은 ClickHouse 서버로 직접 들어가고, Keeper에는 복제를 진행하는 데 필요한 메타데이터만 남기 때문입니다.

쿼리·운영 컴포넌트

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

05 · 쿼리·운영 컴포넌트 — vmselect / vmalert / vmauth

vmselect는 저장을 하지 않는 stateless 쿼리 엔진입니다. 모든 vmstorage에 Fanout으로 던지고 돌아온 결과를 Merge·Sort해 반환합니다.
쿼리는 3-Prefix(태그→Metric ID→TSID→값·이름 복원)로 풀립니다. 쓰기 시점 정규화를 역방향으로 되짚는 대칭 구조입니다.
메모리 관리 3포인트: 쿼리 시점 dedup, Rollup Result Cache(허용 메모리 12.5%, 최근 5분 제외), Query Latency Offset(기본 30초, 정확성↔실시간성 트레이드오프).
vmalert는 Recording rules로 무거운 집계를 미리 계산해 조회 부하를 쓰기 시점으로 옮깁니다. vmauth는 멀티 클러스터 앞단 라우팅 게이트웨이로 사용자 배포 없이 장애 전환을 처리합니다.

데이터가 들어가는 길(03 수집·04 저장)은 이미 다뤘습니다. 이 문서는 데이터가 빠지는 길, 그리고 그 주변에 붙는 운영 컴포넌트를 봅니다. 쿼리 엔진 vmselect, 지표를 미리 계산해 두는 vmalert, 멀티 클러스터의 앞단을 지키는 라우팅 게이트웨이 vmauth 셋입니다.

HyperDX / ClickStack

Sun, 12 Jul 2026 00:00:00 +0900

HyperDX / ClickStack으로 로그와 RUM을 함께 보기

HyperDX는 로그를 찾다가 같은 요청의 트레이스와 브라우저 세션 리플레이까지 이어 보는 데 유용합니다. ClickHouse를 저장소로 쓰고, HyperDX UI·API, 전용 OTel Collector, 앱 설정용 MongoDB를 함께 운영합니다. ClickHouse Inc.가 2025-03에 HyperDX를 인수한 뒤 2025-05에 이 조합을 ClickStack으로 출시했습니다.