Ops Insights – HyperDX 내재화

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

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

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

ClickStack은 HyperDX(app+api) · OTel Collector · ClickHouse · MongoDB 4컴포넌트를 2개 Helm 차트(clickstack-operators → clickstack)로 올립니다. 차트 기본은 모든 스테이트풀 컴포넌트가 단일 인스턴스(PoC용) 이지 HA가 아닙니다 ✓.
operator 분기(중요): 표준 차트가 딸려오는 ClickHouse operator는 ClickHouse Inc. 공식 operator(ClickHouseCluster/KeeperCluster CRD)입니다. 우리는 이걸 그대로 쓰지 않고 clickhouse.enabled: false(자체(self-hosted) ClickHouse에 연결하는 ‘HyperDX Only’)로 CH/Keeper를 Altinity CHI/CHK로 분리 운영합니다 → /hyperdx/04-operator-topology-downtime/.
RUM 인제스트 경로에 MongoDB는 없습니다. 브라우저 → OTLP/HTTP :4318 → Collector → ClickHouse. MongoDB는 UI에서 대시보드/알럿/소스를 만들 때만 쓰입니다 — 인제스트 경로에 없으니 아주 작게 돌려도 됩니다.
MongoDB 최소 배포 형상: 메타데이터 전용이라 단일 멤버 실효 바닥 ~~0.4 vCPU / 0.75~~1.25Gi / gp3 10Gi. prod는 members:3(≈1.2 vCPU/3Gi, 값싼 보험)에 SCRAM + mongodump CronJob이 실전 권고입니다.

이 페이지는 HyperDX ClickStack을 실제 K8s에 조립하는 배치 청사진을 다룹니다. 4컴포넌트의 정체성·배포 6모드·HyperDX Only 개념은 HyperDX / ClickStack 심층 분석이, 로그 스토어로서의 요약 판단은 로깅 챕터가 이미 다뤘으므로 재나열하지 않습니다. 여기서는 각 컴포넌트를 어느 파드로 어디에 올리고 데이터가 어디로 흐르며 MongoDB를 얼마나 작게 배포할 수 있는지에 집중합니다.

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

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

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

hot 데이터의 정답은 노드당 단일 gp3 볼륨 + 인스턴스 baseline에 맞춘 소량 provisioned throughput입니다. 0.7TB/월 RUM 스케일에서 gp3를 80,000 IOPS/2,000 MiB/s까지 올릴 이유도, 여러 개 스트라이핑할 이유도 없습니다.
ClickHouse는 대형 순차 머지가 지배적인 throughput-bound 워크로드이고 인스턴스 EBS 파이프(mid-size는 baseline 수백 MB/s)가 볼륨보다 먼저 병목입니다 — 볼륨을 더 붙여도 인스턴스 파이프 이상은 못 냅니다.
io2 / io2 Block Express(256,000 IOPS·4,000 MiB/s·99.999%·<500µs)는 이 스케일엔 과잉입니다. 극한 IOPS·sub-ms·볼륨 단위 초고내구성이 걸릴 때만 각주.
EBS-first의 값어치는 성능보다 운영 단순성·내구성입니다 — 재부팅·재스케줄 시 재수화 불필요(볼륨 detach/attach). 로컬 NVMe와 근본적으로 다른 다운타임 프로파일은 /hyperdx/04-operator-topology-downtime/에서 이어받습니다.
operator 연동은 gp3 StorageClass(EBS CSI) + volumeClaimTemplate reclaimPolicy: Retain + allowVolumeExpansion(온라인 확장) 세 축입니다.

이 카테고리는 EBS(gp3/io2) 1차 전제입니다. 로컬 NVMe(i7i/i8g) 1차 전제와 스토리지 4전략·티어링≠내구성·재수화 위험 창의 정의와 MTTR 산식은 /clickhouse/02-storage-local-nvme/가 기준 문서라 여기서 반복하지 않습니다. 이 페이지는 왜 우리 스케일에선 EBS가 1차인지와 gp3/io2를 operator에 어떻게 붙이는지만 실전 관점으로 깊게 팝니다. cold 티어링(S3)은 /hyperdx/03-s3-cold-tiering/, hot 창별 캐파 산정은 /hyperdx/07-capacity-planning/가 전담합니다.

S3 콜드 티어링 — storage_configuration

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

S3 콜드 티어링 — storage_configuration·TTL·IRSA worked example

이 장의 경계: “cold를 켤 것인가"는 블록 온리 튜닝 §6의 결정표와 운영 트랙 의사결정 가이드의 cold 축이 소유합니다. 이 장은 켠다고 결정한 뒤의 조립을 소유합니다(§0).
hot = EBS default 디스크(gp3/io2), cold = S3 Standard + cache 디스크(EBS 위 LRU, max_size 150Gi). 로컬 NVMe 예제의 hot 자리를 EBS로 계승할 뿐, cold(S3) 조립은 동일합니다.
storage_configuration 기준 문서: 내장 default + s3(신문법 object_storage) + cache. 정책 rum_hot_cold는 move_factor=0.1(안전판만), prefer_not_to_merge 미설정(기본 false 유지).
이 페이지가 TTL 단일 기준 문서입니다(07 용량 산정이 이 표를 relref): otel_logs/otel_traces hot 14일→S3→DELETE(지평 90/180/365), otel_metrics_* hot 30일→S3→DELETE(180/365), hyperdx_sessions는 S3에 안 내리고 hot만·DELETE 30일.
인증 = IRSA(정적 키 금지) + use_environment_credentials=1 + region 명시 + {replica} 경로 분리(shared-nothing 필수). 주입 = CHI files의 config.d/storage_configuration.xml. 그 다음이 네트워크 경로 — S3 Gateway VPC Endpoint(무료, 없으면 NAT 처리요금이 절감액을 먹습니다, §3.4).
함정: part 메타데이터·cache가 EBS를 먹습니다(사이징 반영) · S3 lifecycle→Glacier 금지 · zero-copy 금지 · cold=캐시 미스 지연 · 요청 비용은 “머지를 hot에서 끝내는” 설계 덕에 작습니다(§5.6).

로컬 NVMe 스토리지가 hot을 로컬 NVMe로 두는 전제였다면, 이 카테고리는 hot = EBS(gp3/io2) 전제입니다(/hyperdx/02-hot-storage-ebs/). 티어링의 골격은 같습니다 — TTL로 오래된 part를 S3로 밀고 최근 데이터만 로컬에 둡니다. ClickHouse storage_configuration에서 hot 볼륨의 disk만 로컬 SC PVC 대신 내장 default 디스크(=/var/lib/clickhouse = gp3/io2 PVC) 입니다. 이 페이지는 그 hot=EBS 전제로 복붙 가능한 storage XML·CHI 매니페스트·TTL DDL을 조립하고 HyperDX/ClickStack이 자동 생성하는 관리 테이블(otel_*/hyperdx_sessions)에 실제로 티어링을 적용합니다. 티어링 ≠ 내구성·zero-copy 금지·S3 lifecycle 함정의 배경은 이미 클릭하우스 챕터가 깊게 다뤘으므로 여기선 relref로 위임하고 EBS-first worked example의 새 각도만 팝니다.

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

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

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

operator 선택이 “어느 operator를 쓸지"를, 배포 플레이북이 CHI/CHK 매니페스트 필드·RF 선택 확률·insert_quorum 주입 위치를, operator 운영이 스케일 in/out 함정·롤링 업그레이드 순서·CRD 삭제 금지를 이미 깊게 다뤘습니다. 이 페이지는 그 내용을 반복하지 않습니다. 전제 스토리지를 EBS(gp3/io2)로 바꾸면 다운타임 프로파일이 어떻게 뒤집히는지, 그 한 축만 봅니다. 필드 전수·스케일·업그레이드는 위 세 페이지에 맡기고 여기서는 EBS 재부착 역학, 시나리오별 다운타임, EBS 특유의 함정만 본문으로 씁니다.

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

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

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

HyperDX 스택의 ClickHouse는 self-host이므로 ReplicatedMergeTree가 강제되고 복제를 조정할 계층으로 ClickHouse Keeper가 반드시 붙습니다. 우리는 이 Keeper를 표준 ClickStack 차트의 공식 operator(KeeperCluster CRD) 대신 Altinity CHK(ClickHouseKeeperInstallation)로 분리 운영합니다 — 그 배치·gp3 영속 볼륨·정족수 매니페스트·업그레이드는 clickhouse 카테고리가 이미 깊게 다뤘으니 여기서 되풀이하지 않고 스토리지 · 로컬 NVMe(Keeper gp3 영속·내구성 3종세트), operator 배포 플레이북(정족수 산술·insert_quorum 주입·쓰기 내구성 노브), Altinity operator 운영(CHK 롤링 업그레이드), 그리고 같은 카테고리의 operator 토폴로지·다운타임에 넘깁니다.

복제·멀티마스터·failover — 승격 없는 다중 마스터 복구 모델

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

복제·멀티마스터·failover — 승격 없는 다중 마스터 복구 모델

HyperDX 스택의 self-host ClickHouse는 ReplicatedMergeTree(RMT)가 강제됩니다. 그 복제 모델은 PostgreSQL·MySQL의 primary-replica와 아예 다릅니다 — 멀티마스터입니다. 이 차이가 우리 운영에서 무엇을 바꾸는지, 특히 “노드 하나가 죽으면 무슨 일이 벌어지나"와 “RF2에서 노드 작업이 안전한가"에 답하려고 이 페이지를 씁니다.

용량 산정 — 월 0.7TB RUM 워크드 모델(3개월·6개월·1년)

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

용량 산정 — 월 0.7TB RUM 워크드 모델(3개월·6개월·1년)

0.7TB/월(prod, 세션 샘플링 100%) 캐파의 결론입니다.

블록 스토리지 온리 — S3 없이 EBS 단일 티어 튜닝

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

블록 스토리지 온리 — S3 없이 EBS 단일 티어 튜닝

이 카테고리의 나머지 문서는 전부 S3 cold 티어링을 쓴다는 전제로 씌었습니다. hot 스토리지·EBS가 gp3/io2 스펙·요금·StorageClass·단일 vs 다중을, S3 콜드 티어링이 storage_configuration·TTL MOVE·IRSA·move_factor·cache·금지 3종을, 용량 산정이 0.7TB/월 워크드 모델을, operator·다운타임이 storageManagement·다운타임 프로파일을 이미 기준 문서로 다뤘습니다. 이 페이지는 그 전제를 뒤집어 “블록 온리(EBS only, S3 티어링 없음)“만의 델타를 판합니다 — 무엇이 사라지고(storage XML·IRSA·cache·move_factor), 무엇을 새로 짊어지나(전량 EBS 상주 → 사이징 배수↑·온라인 확장이 유일 성장 레버·머지/백그라운드 풀 튜닝). 겹치는 것은 통째로 복붙하지 않고 relref로 넘깁니다.

버전 호환성·업그레이드 — 스택 전 구성요소 매트릭스와 EBS 롤백

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

버전 호환성·업그레이드 — 스택 전 구성요소 매트릭스와 EBS 롤백

operator 운영이 CH 서버 롤링 업그레이드 런북(shard 내 1 replica씩·shard 간 병렬·혼합버전 창)·operator 자체 minor 단계별 업그레이드·CRD 삭제 절대금지·안전장치 3층·Keeper(CHK) 업그레이드를 이미 깊게 다뤘습니다. operator 토폴로지·다운타임은 롤링 중 다운타임·EBS reattach 물리 역학을 다뤘습니다. 이 페이지는 그 일반 메커니즘을 반복하지 않습니다. HyperDX 스택 전체를 한 매트릭스로 묶었을 때 무엇이 무엇과 붙는가, 그리고 EBS-first에서 업그레이드를 어떻게 되돌리는가만 봅니다. 새로 깊게 파는 것은 (1) 6개 구성요소 상호 버전 호환 매트릭스, (2) CH compatibility 서버 설정, (3) 다운그레이드 비지원과 그 실질 롤백 경로, (4) EBS 스냅샷 기반 롤백입니다. 일반 롤링 런북은 전부 위 두 페이지로 위임합니다.

HyperDX 참고 자료

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

출처 — HyperDX 내재화(실전 배포) 조사 자료

이 페이지는 개요, 스택 토폴로지·MongoDB 최소 규모, hot 스토리지(EBS), S3 cold 티어링, operator 토폴로지·다운타임, Keeper, 복제·멀티마스터·failover, 용량 산정, 블록 온리 튜닝, 버전 호환·업그레이드 열 페이지가 인용한 1차 조사(R1~R9)의 ## 출처 섹션을 모은 목록입니다. 중복을 걷어내고 주제별로 분류했습니다. 조사 기준일은 2026-07-16입니다.