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

각 솔루션의 성격은 앞의 솔루션별 페이지(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) 시퀀싱

• Week 0 — 공짜 이득 · Envoy JSON 액세스 로그 켜기 · Datadog 7일 로그 중복 제거 · hot만 1yr RI · Datadog 갱신일/Order Form 확인 — 성공 기준: 즉시 절감 + 의사결정 데이터.
• Week 2–8 — 키스톤 · OTel Collector 스파인 구축. 이후 모든 백엔드 결정이 exporter 한 줄로 수렴 — 성공 기준: 모든 소스가 Collector 경유.
• Sprint — istio 부활 (D1) · envoyOtelAls → Collector → VictoriaLogs. 오너 지정 + 런북 + 알림 — 성공 기준: Grafana 조회 + 유실 알림 동작.
• Month 2–4 — dual-write (D2) · Collector에서 OpenSearch + VictoriaLogs 동시 기록 → 검증 후 보존 90d→7d, UltraWarm 축소 — 성공 기준: 실장애 2–4건을 새 스택으로 해결.
• Month 4–6 — OpenSearch 은퇴 (D2) · UltraWarm 제거 → hot 축소·OR 이전 → 벌크 은퇴(여기서 $200–365K 실현) — 성공 기준: “옛 시스템 확인” 0건.
• Month 5–8 — RUM 트랙 (D3) · 웹 → ClickStack PoC / 모바일 → Datadog 잔류, 갱신 협상 반영 — 성공 기준: 갱신 전 서면 할인 유지 확보.
• Month 8+ — 선택적 통합 (D4) · traces+RUM 통합이 우선순위가 되면 ClickHouse/ClickStack. 메트릭은 제외 — 성공 기준: 통합 명분·오너 확보 시에만.

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

한 줄 결론

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

참고 — 근거 출처

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