HyperDX 직접 운영하기

이 섹션은 HyperDX 내재화 챕터의 기준 문서 위에서, 우리 손으로 직접 배포·운영할 때 필요한 현황·순서·판단만 세 장에 모읍니다. 챕터의 공통 원칙 하나를 그대로 이어받습니다 — 모든 결정을 “왜/어떻게 안전한가"와 함께 봅니다. 배포·스토리지·토폴로지·조정 계층의 기본값을 정할 때마다 “이 기본값이 어떤 장애를 어떻게 견디나”, “이 규모에 왜 충분한가”, “무엇이 승급 트리거인가"를 같은 자리에서 답합니다. 그래야 규모가 커질 때 무엇을 올릴지 압니다.

읽는 순서는 정해두지 않았습니다. 세 장이 필요해지는 순간이 각각 다릅니다. 형상을 확인할 때 01, 사건이 났을 때 02, 기본값을 올릴지 판단할 때 03입니다.

1. 경계 판정 규칙 — 어떤 문단이 어느 섹션에 속하나

이 트랙과 기준 문서가 한때 같은 주제를 양쪽에서 서술했고 그 중복이 사실 드리프트를 낳았습니다. 절단선이 “해상도 차이"라서 판정할 수 없었던 탓입니다. 그래서 경계를 판정 가능한 규칙 세 줄로 정해 둡니다.

• R1 — 우리 클러스터에서만 참인 사실은 이 트랙이 소유합니다. namespace·CHI/CHK 이름·stage/prod 격차·자체 RUM 컨버터·실제 CH 유저 권한이 그렇습니다. 표준 문서에 쓰면 “표준이 무엇인가"를 오염시킵니다.
• R2 — 버전·수치·용량·요금·매트릭스는 기준 문서 단일 소유입니다. 이 트랙은 재기재하지 않고 relref만 합니다. 관측된 드리프트는 딱 하나, 트랙이 기준 문서의 버전 숫자를 복사한 자리에서 났습니다. 그래서 복사할 자리를 아예 없앱니다.
• R3 — “지금 무엇을 먼저 하나"는 이 트랙이 소유합니다. 순서·판별 신호·승급 트리거가 여기 있고 그 절차가 왜 그런지는 기준 문서에 있습니다.

R2에는 예외가 하나 있습니다. 명령 텍스트의 정본은 메커니즘 장(기준 문서)이 유지합니다. 명령 블록이 그 메커니즘의 다이어그램·설명과 같은 자리에 묶여 있어서입니다. 런북은 증상 → 판별 → 어느 절차 → 확인의 라우팅과 우리 형상 파라미터·순서를 소유하고 명령 정본은 relref 합니다.

2. 3부 구성

• 1부 우리 배포 형상 — 자체 RUM 컨버터, 표준 조립 5 실행 단위 대 우리 실제 6, stage/prod 격차 표, 컴포넌트별 실제 HA. R1이 소유하는 사실이 전부 여기 있습니다. 대응 기준 문서: /hyperdx/01-stack-topology/·/hyperdx/08-block-only-tuning/(stage가 블록 온리 형상입니다)
• 2부 운영 런북 — 증상별 진입, 판별 신호, 절차 순서, 우리 형상 파라미터, stage 리허설. 축은 노드 급사·Keeper 정족수 상실·계획된 변경입니다. 대응 기준 문서: /hyperdx/04-operator-topology-downtime/·/hyperdx/05-keeper/·/hyperdx/06-replication-failover/·/hyperdx/09-version-upgrade-compat/·/clickhouse/05-altinity-operations/
• 3부 의사결정 가이드 — 7축 결정 매트릭스(기본값·왜 안전/충분·승급 트리거) + 승급 트리거의 관측 지점 + 배포 전 실측 체크리스트 9항목. 승급 판단은 우리 클러스터의 현재 부하를 보는 일이므로 트랙 소관입니다. 대응 기준 문서: 축별로 매트릭스 각 행에 개별 링크

hot/cold 티어링·용량 산정·컴포넌트별 가용성 종합은 이 트랙이 따로 서술하지 않습니다 — 각각 /hyperdx/02-hot-storage-ebs/·/hyperdx/03-s3-cold-tiering/·/hyperdx/07-capacity-planning/·/hyperdx/04-operator-topology-downtime/가 정본입니다. 이 트랙은 그 위에서 “우리 형상은 지금 어디쯤인가"와 “언제 올리나"만 붙입니다.

3. 기준 문서와의 관계

이 세 페이지는 운영에 필요한 현황·순서·판단을 그 자체로 완결되게 서술합니다. 남김없는 세부와 매니페스트 전문, 산식 유도, 1차 출처 URL은 챕터 기준 문서(01~09)와 출처 모음(/hyperdx/10-sources/)이 계속 담당합니다. 트랙 페이지가 기준 문서의 주장을 가져와 다시 쓴 자리에서는 원문의 근거 기호(✓/≈/Ⓥ/?/Ⓑ/Σ)를 그대로 따랐습니다. 트랙과 기준 문서 사이에 등급 불일치가 보이면 기준 문서가 우선합니다.

규칙 하나가 이 거버넌스를 받칩니다. R2에 따라 트랙은 버전·수치를 애초에 쓰지 않습니다. 사후에 어느 쪽이 맞는지 대조하기보다 등급 불일치가 생길 표면 자체를 줄이는 편이 값쌉니다. 그래도 불일치가 보이면 위 우선 규칙으로 판정하고 트랙 쪽 문장을 relref로 바꿉니다.

우리 케이스에서는

지금 돌아가는 것은 stage 축소판 하나뿐이고 prod 목표와의 격차가 곧 작업 목록입니다. 그 목록은 우리 배포 형상의 표에 있습니다. 사건이 나면 운영 런북의 증상 표에서 한 줄을 찾아 그 절차만 밟습니다. 기본값을 올릴지 말지는 의사결정 가이드의 관측 지점에서 신호가 실제로 잡힐 때만 판단합니다.

먼저 착수할 1번 작업은 3부의 실측 체크리스트 9항목을 staging에서 ✓로 승격하는 일입니다. 0.7TB 해석 하나가 배포 규모·비용을 결정합니다. cold 티어링 계열 5항목은 켜기 전에 확인하지 않으면 나중에 되돌리기 비쌉니다. 시점 기준 2026-08.