로깅 · 옵저버빌리티 — ES 말고 어떻게 관리할까
로그·메트릭·RUM을 여러 저장소에 흩뿌려 놓은 MSA 팀이 “이거랑 저거만 있으면 다 될 것 같은” 최소 조합을 찾으며 검토한 솔루션을 정리한 챕터입니다. Elasticsearch(OpenSearch) 기반 EFK 말고 애플리케이션 로깅을 내재화하는 다른 길이 있는지, 솔루션마다 성격은 어떻고 우리 케이스에서는 무엇을 골랐는지 다룹니다.
자매 챕터: VictoriaMetrics 지식베이스 · 메트릭 400일 보관 — 메트릭 계층은 그쪽에 있고 이 챕터는 로그·RUM 계층을 맡습니다. istio 액세스 로그·APM·RUM만 따로 파는 심화는 별도 도메인(Istio · APM · RUM 내재화)에서 이어갈 예정입니다. ClickHouse를 채택했을 때 필요한 운영 전략(배포·스토리지·operator)은 ClickHouse 운영 도메인에서 다룹니다(D4의 채택 여부 판단과 전제가 다릅니다).
먼저, 이건 “하나의 큰 결정"이 아니다
여러 이야기가 섞여 있어 하나로 뭉뚱그리면 ROI를 판단할 수 없습니다. 발라내면 서로 독립인 결정 4개입니다. 답이 각각 다르니 따로 판단해야 합니다.
| 결정 | 질문 | 결론 |
|---|---|---|
| D1. istio 로그 부활 | PLG를 살릴까, VictoriaLogs로 갈까 | 즉시·저위험 → VictoriaLogs |
| D2. OpenSearch 뚱뚱함 | 90d/160TB EFK를 어떻게 다이어트하나 | 강한 YES → tail 이전 + in-place RI/OR 최적화 |
| D3. RUM 내재화 | Datadog RUM 2배 인상, 빼올까 | 웹 YES / 모바일 NO |
| D4. 단일 통합 저장소 | ClickHouse로 로그+트레이스+RUM 다 합칠까 | 가능하나 최후에 (“earn it last”) |
이 프레이밍을 먼저 정해두는 이유가 있습니다. D1은 스프린트 단위로 끝나는 저위험 작업이고 D2는 자릿수 절감이 걸린 큰 건입니다. D4는 조건이 성숙해야 성립하는 장기 베팅입니다. 하나로 묶으면 “전면 이전 ROI 나올까?“라는 답 없는 질문이 됩니다.
왜 이 고민을 하는가 — 현재 구조의 겹침
규모 있는 MSA를 운영하면 옵저버빌리티 데이터가 자연스럽게 여러 저장소로 번집니다. 같은 성격의 데이터를 여러 곳에 중복으로 수집·저장하면서 비용과 운영 부담만 늘어나는 게 문제입니다.
| 레이어 | 흔한 현재 모습 | 중복도 | 진단 |
|---|---|---|---|
| 수집 에이전트 | Datadog agent + fluent-bit + (방치된) promtail | 3중 | 통합 1순위 |
| 로그 저장 | Datadog logs(7d) + OpenSearch(90d) + (죽은) Loki | 3중 | 최대 비용처 |
| 메트릭 | Datadog infra + VictoriaMetrics 클러스터 | 2중 | VM은 잘 운영 중 — 확장 기반 |
| APM/트레이스 | Datadog 단독 | 1중 | 당분간 유지 |
| RUM (웹/모바일) | Datadog 단독 | 1중 | RWoL 재요율로 ~2배 인상 |
로깅 스택이 죽는 원인은 대개 기술이 아니라 오너십입니다. promtail이 방치되고 DaemonSet이 노드 교체와 함께 사라지는 건 도구를 바꿔서 해결될 일이 아닙니다. 그래서 “어떤 솔루션이냐"만큼 “우리가 스택 하나를 더 썩히지 않을 수 있느냐"가 선택 기준이 됩니다.
솔루션 한눈에 보기
| 솔루션 | 계열 | 한 줄 성격 | 우리 케이스 포지션 |
|---|---|---|---|
| OpenSearch (EFK) | 검색엔진(Lucene) | 강력한 풀텍스트, 비용 ~90%가 인스턴스 시간 | 현행, tail 이전 + in-place 최적화 |
| Loki + Alloy | 라벨 인덱스 + object storage | 저비용 로그 집계, 새 운영 모델 학습 부담 | 보류(SSD 모드 EOL 예정) |
| VictoriaLogs | Victoria 패밀리 | VM과 동일한 운영 모델, 초경량 · 풀텍스트 | 추천 — 로그 내재화의 축 |
| ClickHouse (self-hosted) | 컬럼형 OLAP | 극단적 압축, 로그+트레이스+RUM 통합 흡수 | 통합 이유가 생겼을 때(D4) |
| HyperDX / ClickStack | ClickHouse 위 UI 스택 | 웹 RUM·로그·트레이스 통합 프론트(턴키) | 웹 RUM 중계처 후보 |
| StarRocks | 컬럼형 MPP OLAP | S3 위 stateless 컴퓨트가 강점, 그러나 로그·UI는 미성숙 | 별도 mandate 없으면 제외 |
| RUM 대안군 | Sentry/OpenReplay/Faro 등 | 셀프호스트 세션 리플레이 | → 별도 RUM 내재화 도메인 |
문서 지도
| 문서 | 내용 |
|---|---|
| 솔루션별 페이지 | OpenSearch · Loki+Alloy · VictoriaLogs · ClickHouse · HyperDX/ClickStack · StarRocks |
| ClickHouse vs StarRocks | 로그/관측성 한정 정면 비교(8축 요약·판정) |
| 우리 케이스 · 권장안 | 최소 조합 아키텍처, 인건비 게이트, 저후회 시퀀싱, 하지 말 것, 결론 |
근거 표기 범례:
✓확인됨(1차 출처 검증) ·≈추정 ·Ⓥ벤더 주장 ·?미확인 ·Ⓑ퍼블릭 벤치마크 ·Σ종합 판단.⁽ ⁾는 부가 설명,✓/≈처럼 병기하면 혼재를 뜻합니다.