04 · 스케일링·용량 기준치

큐 상한·리소스·HA·메모리 임계를 어떤 근거로 잡는지 적어 둡니다. 확정 숫자보다 판단 기준과 산정식에 무게를 둡니다 — 실제 값은 실측으로 조정합니다.

관련 문서: 02 vmagent 전송 튜닝 · 03 자기감시 메트릭 · 실전 01 카디널리티 · 우리의 운영 허브

① 디스크 큐 상한 산정식

maxDiskUsagePerURL은 이 질문에서 나옵니다 — “링크 장애가 나도 몇 시간치 지표를 큐에 버틸 수 있게 할 것인가”.

maxDiskUsagePerURL ≈ sum(rate(vmagent_remotewrite_bytes_sent_total[1h])) × 버틸 장애 시간

평시 전송 바이트레이트 × 목표 버팀 시간입니다. 링크가 끊긴 동안 큐가 지표를 붙잡아 두고 복구되면 다시 흘려보냅니다. 상한을 넘기면 오래된 블록부터 버립니다(→ drop 동작은 02).

평시 바이트레이트는 03의 bytes_sent로 실측합니다. 목표 버팀 시간을 확정하면 이 표의 값도 그에 맞춰 조정합니다(TODO).

② vmagent 리소스 기준치

현행값을 기준선으로 둡니다. 실사용량을 관찰해 조정합니다.

TODO(실측 후 조정): 실제 CPU·메모리 사용량과 스크랩 대상 수를 관찰해 requests/limits를 맞춥니다. vmagent 메모리는 활성 시계열 수·스크랩 크기에 좌우되므로 카디널리티가 늘면 함께 올려야 합니다.

③ HA(replicaCount: 2) — 의도적 미적용

vmagent를 2벌로 띄우면 가용성은 오릅니다. 그러면서 전송 절감 목표와 정면으로 부딪힙니다.

• replica가 각자 전량을 전송합니다. vmagent HA는 2벌이 같은 타깃을 스크랩해 각자 remote_write 하는 구조라 cross-cluster 전송 트래픽이 2배가 됩니다.
• dedup은 저장만 절약합니다. 중복은 수신측/쿼리 시점 dedup이 걷어내지만(→ 개념 03 수집), 그건 저장 용량 이야기일 뿐 전송량은 이미 2배로 나간 뒤입니다.

Phase 1의 목표가 전송 안정화·절감(zstd 고정, 큐 상한)인데 HA는 전송을 2배로 늘리므로 의도적으로 미적용합니다. 가용성 요구가 절감보다 우선하는 상황이 명확해지면 그때 별도로 판단합니다.

④ slow insert 임계 — 메모리 부족 경고

수신측에서 보는 용량 신호입니다. slow insert rate가 10%를 계속 넘으면 현재 활성 시계열 수에 비해 메모리가 부족하다는 경고입니다. TSID 캐시가 메모리에 다 담기지 못해 IndexDB 폴백이 잦아진 상태입니다. 이 지표와 churn rate의 원리·임계 근거는 D2 개념을 그대로 계승합니다 → 실전 01 카디널리티.