우리 케이스 — “이거랑 저거만 있으면”

각 솔루션의 성격은 앞의 솔루션별 페이지(OpenSearch·Loki·VictoriaLogs·ClickHouse·HyperDX·StarRocks)에서 다뤘다 — 목록은 챕터 개요 참고. 여기서는 그걸 우리 환경에 얹어 최소 조합·게이트·마이그레이션 순서로 정리한다.

발라내면 결론은 수집 1개 + 저장 패밀리 1개 + Grafana로 수렴한다. RUM/APM은 별도 트랙으로 분리해 판단한다.

[수집 — 전부 여기로 통일]
  OTel Collector 또는 Grafana Alloy (DaemonSet + gateway)
   ├─ 앱 로그        (filelog — fluent-bit 대체)
   ├─ istio 로그     (envoyOtelAls gRPC 직송, 파일 테일 아님)
   ├─ EC2 로그       (기존 fluent-bit 단계적 흡수)
   └─ 메트릭 스크레이프 (vmagent 역할 병합 가능)
          │  ← "collector as switch": 백엔드 전환은 여기서 dual-write로
          ▼
[저장]
  메트릭    VictoriaMetrics 클러스터        (현행 유지 + 400d 아카이브는 별도 챕터)
  로그      VictoriaLogs                    (istio부터 → 검증 후 앱 로그 hot)
  트레이스  Datadog APM 유지                → ClickStack/VictoriaTraces 후속 평가
  웹 RUM    ClickStack(HyperDX)             (usage 분해 결과 웹 우세일 때)
  모바일    Datadog RUM 유지                (셀프호스트 대안 성숙 전까지)
          ▼
[조회]  Grafana 단일 (victorialogs-datasource 공식 플러그인)

메트릭 계층의 400일 장기보관 설계는 메트릭 400일 보관 챕터에서 별도로 다룬다.

이 구조가 사실상 “2개"로 수렴하는 이유:

1. 수집기 하나가 모든 소스를 커버하면서, 백엔드 전환기에는 dual-write 스위치 역할을 한다. 나중에 저장소를 바꿔도(exporter 한 줄) 앱은 건드리지 않는다.
2. Victoria 패밀리는 팀이 이미 검증한 운영 모델이라 학습·rot 비용이 0에 가깝다. 메트릭(VM)에서 쌓은 근육이 로그(VictoriaLogs)에 그대로 전이된다.

진짜 게이트는 기술이 아니라 인건비

숫자로 확인해야 할 불편한 진실: OpenSearch 인프라 절감은 vs RI ~$205K/yr, vs 온디맨드 $365K/yr ≈**로 크다. 그러나 셀프호스트 스택을 제대로 운영할 **platform SRE 1.52명의 fully-loaded 비용이 $330440K/yr ≈로, 온디맨드 기준($365K)이면 거의 상쇄되고 문서가 실제로 모델링한 RI 기준($205K)이면 인건비가 절감을 오히려 초과한다.

저후회(low-regret) 시퀀싱

거버넌스(PLG 재발 방지): 스택별 명시적 오너 1인 + 런북 + “수집기는 분기별 업그레이드” 캘린더 + 수집 파이프라인 자체에 대한 알림(로그 유입량 급감 = 페이지).

한 줄 결론

하지 말 것 (검증에서 기각)

참고 — 근거 출처

이 챕터는 두 리서치 세트를 압축한 것이다(원본은 내부 리서치 저장소).