https://docs.makgol.com/observability/hyperdx/Recent content in HyperDX·ClickStack on makgol's noteHugo -- gohugo.ioko-KR© 2026 MontSun, 04 Oct 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/a1-ebs-gp2-gp3-benchmark/Mon, 05 Oct 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/a1-ebs-gp2-gp3-benchmark/ <h1>부록 · EBS gp2·gp3 fio 실측은 gp3 선택을 어디까지 뒷받침하는가</h1><p>100 GiB gp2에서 짧은 부하 시험만 하면 버스트 소진 뒤의 성능을 놓칠 수 있습니다. atomai의 <a href="https://www.atomai.click/kubernetes-docs/ko/storage/01-ebs-gp2-gp3-benchmark"target="_blank" rel="noopener">EBS gp2 vs gp3 실측 벤치마크</a>는 m5.xlarge 노드에 gp2와 gp3를 붙여 각각 fio로 측정했습니다. gp2는 2,700초 실행 중 약 33분이 지난 뒤 3,000 IOPS에서 300 IOPS로 내려갔습니다. 별도로 600초 측정한 gp3는 3,000 IOPS 근처를 유지했습니다.</p>https://docs.makgol.com/hyperdx-operating/01-our-deployment/Thu, 13 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx-operating/01-our-deployment/ <h1>우리 배포 형상</h1><p>우리 RUM 데이터는 자체 컨버터를 거쳐 ClickHouse에 들어갑니다. 브라우저 SDK와 Mobile RUM이 보내는 데이터를 받기 위해 Datadog Agent의 RUM 전송 방식을 참고해 구현했습니다. 표준 로그·트레이스·메트릭은 별도의 OTel Collector로 수집합니다. 두 수집기는 서로 호출하지 않고 ClickHouse에서 데이터를 합칩니다 <code>✓</code>.</p>https://docs.makgol.com/hyperdx/01-stack-topology/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/01-stack-topology/ <h1>ClickStack을 Kubernetes에 배치하기</h1><p>ClickStack을 Kubernetes에 올릴 때는 텔레메트리가 저장되는 경로와 HyperDX의 설정이 저장되는 경로를 따로 따라가면 배치가 이해됩니다. 브라우저가 보낸 이벤트는 Collector를 거쳐 ClickHouse로 들어가고, 사용자·대시보드·알럿 설정은 HyperDX API가 MongoDB에 저장합니다. 두 데이터베이스의 크기와 장애 영향이 다른 이유도 이 흐름에 있습니다.</p>https://docs.makgol.com/hyperdx-operating/02-runbook/Thu, 13 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx-operating/02-runbook/ <h1>HyperDX 운영 런북</h1><p>장애가 나면 조회와 적재 중 어느 쪽이 멈췄는지 확인합니다. 우리 구성은 RUM 컨버터와 OTel Collector가 별도로 ClickHouse에 쓰므로, 수집 장애도 두 경로를 나누어 확인해야 합니다.</p>https://docs.makgol.com/hyperdx/02-hot-storage-ebs/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/02-hot-storage-ebs/ <h1>ClickHouse hot 데이터를 gp3에 저장하기</h1><p>월 0.7TB의 RUM 데이터를 저장하는 ClickHouse라면 노드마다 gp3 볼륨 하나를 붙이는 구성으로 시작할 수 있습니다. 볼륨의 최대 IOPS를 높이기 전에 확인할 것은 EC2 인스턴스가 지속적으로 처리할 수 있는 EBS 대역폭입니다. 중간 크기의 r7g에서는 볼륨보다 인스턴스 쪽 한도에 먼저 닿을 수 있습니다.</p>https://docs.makgol.com/hyperdx/03-s3-cold-tiering/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/03-s3-cold-tiering/ <h1>ClickHouse의 오래된 데이터를 S3로 옮기기</h1><p>보존 기간을 늘리면 오래된 로그와 트레이스가 EBS 용량을 계속 차지합니다. 이 구성에서는 최근 데이터는 gp3에 남기고, 일정 시간이 지난 파트를 S3 Standard로 옮깁니다. ClickHouse가 두 위치를 함께 조회하므로 HyperDX에서 저장 위치를 나눠 다룰 필요는 없습니다.</p>https://docs.makgol.com/hyperdx-operating/03-decision-guide/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx-operating/03-decision-guide/ <h1>HyperDX 구성을 언제 바꿀 것인가</h1><p>디스크가 느려졌다고 곧바로 io2로 옮기거나, Keeper 부하가 늘었다고 노드를 두 대 더 추가할 필요는 없습니다. 볼륨 대역폭, 인스턴스 한계, 작은 INSERT가 만드는 part 수처럼 원인에 따라 조치가 달라집니다. 반면 AZ 장애 중에도 쓰기를 계속해야 한다는 요구는 현재 부하가 작아도 replica 구성을 바꿀 이유가 됩니다.</p>https://docs.makgol.com/hyperdx/04-operator-topology-downtime/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/04-operator-topology-downtime/ <h1>EBS 기반 ClickHouse의 장애와 복구</h1><p>ClickHouse 노드가 내려갔을 때 EBS 볼륨에 데이터가 남아 있다면 새 노드에서 처음부터 채울 필요는 없습니다. 같은 AZ에 볼륨을 다시 붙이고 ClickHouse를 시작한 뒤, 중단 중 쌓인 파트만 따라잡으면 됩니다. 다만 볼륨이 살아 있다는 사실과 요청을 처리할 수 있다는 사실은 다릅니다. 재부착이 끝날 때까지는 남은 replica가 부하를 맡습니다.</p>https://docs.makgol.com/hyperdx/05-keeper/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/05-keeper/ <h1>ClickHouse Keeper와 수집 데이터의 내구성</h1><p>ClickHouse에 이벤트를 보낸 직후 서버가 꺼졌다고 가정해 봅니다. Keeper 세 대가 모두 살아 있어도 수신 중이던 이벤트를 대신 보관해 주지는 않습니다. 이벤트 본문은 ClickHouse 서버로 직접 들어가고, Keeper에는 복제를 진행하는 데 필요한 메타데이터만 남기 때문입니다.</p>https://docs.makgol.com/hyperdx/06-replication-failover/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/06-replication-failover/ <h1>ClickHouse replica 장애와 복구</h1><p>ClickHouse replica 한 대가 내려가면 누가 쓰기를 이어받을까요. ReplicatedMergeTree에서는 남은 replica가 이미 쓰기를 받을 수 있으므로 primary를 승격하는 절차가 없습니다. 장애 대응에서 확인할 대상은 쓰기를 보낼 주소, Keeper 연결, 그리고 아직 복제되지 않은 파트입니다.</p>https://docs.makgol.com/hyperdx/07-capacity-planning/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/07-capacity-planning/ <h1>월 0.7TB RUM의 저장 용량과 비용</h1><p>월 0.7TB라는 수치만으로는 ClickHouse 볼륨 크기를 정할 수 없습니다. 수집 전 원본 크기인지, 압축 후 단일 replica에 기록된 크기인지에 따라 필요한 저장 공간이 달라집니다. 또 세션 리플레이를 30일 뒤 지우면 전체 데이터를 보관 개월 수만큼 곱하는 계산도 맞지 않습니다.</p>https://docs.makgol.com/hyperdx/08-block-only-tuning/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/08-block-only-tuning/ <h1>S3 없이 EBS에 보관하는 ClickHouse</h1><p>보관 기간이 짧거나 staging 규모가 작다면 ClickHouse 데이터를 전부 EBS에 두는 구성이 간단합니다. S3 디스크와 캐시, 접근 권한, TTL MOVE를 관리할 필요가 없습니다. 대신 오래된 로그와 트레이스도 삭제할 때까지 EBS 공간을 사용합니다.</p>https://docs.makgol.com/hyperdx/09-version-upgrade-compat/Sat, 01 Aug 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/09-version-upgrade-compat/ <h1>HyperDX 스택 업그레이드와 데이터 복원</h1><p>HyperDX 앱 이미지를 올리는 일과 ClickHouse 데이터를 새 버전으로 여는 일은 복구 방법이 다릅니다. 앱은 이전 이미지로 돌아갈 수 있어도 ClickHouse가 새 포맷으로 기록한 파트는 이전 바이너리가 읽지 못할 수 있습니다. 업그레이드 전에 호환 버전뿐 아니라 되돌릴 데이터 사본도 준비해야 합니다.</p>https://docs.makgol.com/hyperdx/10-sources/Wed, 15 Jul 2026 00:00:00 +0900https://docs.makgol.com/hyperdx/10-sources/ <h1>HyperDX 참고 자료</h1><p><a href="https://docs.makgol.com/hyperdx/">HyperDX 내재화 시리즈</a>의 배포·스토리지·복제·용량 산정에 사용한 자료입니다. 공식 제품 문서, 설정 파일과 소스, 운영 사례를 나누어 찾을 수 있도록 모았습니다.</p>