Ops Insights – RUM 내재화

HyperDX / ClickStack 심층 분석

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

HyperDX / ClickStack 심층 분석 — RUM/플랫폼 도입 실사

웹 RUM 대체 후보로는 사실상 유일하지만 OSS 접근통제 공백(SSO·RBAC·멀티테넌시·감사로그 전무)이 다중 팀 도입의 결정적 게이트입니다.
3 코어(ClickHouse·HyperDX·OTel Collector)에 메타데이터 전용 MongoDB가 필수 의존성으로 붙습니다. 자체(self-hosted) ClickHouse에 연결하는 ‘HyperDX Only’ 모드에서도 사라지지 않습니다.
배포 6모드 중 프로덕션 적합은 Managed 또는 Helm뿐이고 자체 인프라를 지키려면 HyperDX Only가 정답 축입니다.
기능 성숙도: 로그검색·트레이스·웹 세션 리플레이는 🟢, 모바일 RUM은 🔴(네이티브 리플레이 없음), 메트릭은 🟡(PromQL은 실험 기능이며 기본 비활성).
RBAC는 Managed(ClickHouse Cloud) 전용으로만 GA됐고 OSS는 SSO/RBAC/멀티테넌시/감사로그가 전무합니다. self-host를 고수하려면 oauth2-proxy·팀별 인스턴스·row policy를 조합해야 합니다.

HyperDX/ClickStack을 “Datadog RUM 대체 + 통합 관측성 플랫폼” 후보로 도입할 때의 실사(due-diligence) 페이지입니다. “로그 스토어 선택지로서의 요약 판단"은 로깅 챕터의 HyperDX / ClickStack가 이미 다루므로 강점·약점은 다시 늘어놓지 않습니다. 이 페이지는 도입 결정에 필요한 팩트 — 연혁·아키텍처·배포 모드·기능 성숙도·라이선스·거버넌스 갭 — 을 플랫폼 실사 관점에서 심화합니다.

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

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

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 +0000

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 +0000

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 +0000

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

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

RUM 참고 자료

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

출처 — 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 +0000

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

HyperDX의 Datadog 대체 범위는 넓어졌습니다. PromQL은 실험적 경로가 생겼고, Terraform은 셀프호스트도 지원하는 Beta입니다. 알림 평가 이력과 그룹별 발화도 있습니다.
Datadog Agent의 로그·메트릭·트레이스를 받는 것과 Datadog RUM·세션 리플레이·모니터 설정을 그대로 옮기는 것은 별도 문제입니다.
이 글은 2026-09-08에 확인한 공식 문서·upstream 소스 기준입니다. 우리 배포의 이미지 버전과 자체 컨버터를 실행 검증한 결과는 아닙니다.

플랫폼 심층 분석, RUM 커버리지, 전 제품군 대체 매트릭스의 2026-07 조사에서 바뀐 판단을 정리합니다. 기능의 존재, Datadog과의 동등성, 우리 배포에서의 가용성을 따로 확인합니다.

HyperDX의 MongoDB — 역할·부하 프로파일·운영

Wed, 15 Jul 2026 00:00:00 +0000

HyperDX의 MongoDB — 역할·부하 프로파일·운영

MongoDB에 들어가는 것은 전량 메타데이터(대시보드·저장검색·사용자·알림)뿐입니다 — 로그·트레이스·RUM 세션 같은 관측 데이터는 전부 ClickHouse로 갑니다.
그래서 부하가 적재량이 아니라 사용자·대시보드·알림 수에 비례합니다. 유일하게 시계열처럼 보이는 alertHistory도 30일 TTL 인덱스로 자동 소거됩니다.
형태는 배포 경로마다 다릅니다. docker-compose는 기본 무인증(단 포트 비노출), Helm은 SCRAM 인증이 기본이지만 기본값이 members: 1(단일 멤버, HA 아님)입니다.
공식 운영 가이드는 사실상 한 문장뿐이라 사이징·백업·HA는 자체 설계가 필요합니다.
무인증 상태로 포트를 노출했다가 스캐너가 데이터를 지운 실사고 사례가 있습니다 — 인증과 NetworkPolicy 격리가 필수입니다.

HyperDX / ClickStack 심층 분석은 3 코어 컴포넌트(ClickHouse·HyperDX·OTel Collector)에 메타데이터 저장용 MongoDB가 필수 의존성으로 붙는다고 아키텍처 레벨에서 짚었습니다. 이 페이지의 범위는 그 “필수 의존성 하나"입니다. 실무에서 걸리는 질문은 MongoDB의 역할이 뭔가, 그리고 로그·트레이스·RUM 같은 관측 데이터를 장기간 대량으로 적재하면 MongoDB 부하도 같이 커지는가입니다. 근거는 모두 딥리서치 적대검증(3-vote)을 통과했습니다.