Ops Insights – 로깅

OpenSearch (EFK)

Sun, 12 Jul 2026 00:00:00 +0000

OpenSearch (EFK) — 지금 쓰는 것, 왜 뚱뚱해 보이는가

강점은 임의 필드 ad-hoc 풀텍스트·고카디널리티 검색, SIEM/보안 완제품, 관리형 운영의 낮은 인건비입니다.
약점은 로그 저장 목적에 비해 컴퓨트가 무겁다는 점입니다 — 비용의 ~90%가 인스턴스 시간이고 스토리지는 ~10%뿐입니다.
UltraWarm은 예약(RI) 불가(hot만 예약 가능)라 전 클러스터 블렌디드 절감 상한이 ~25%에 그칩니다 — “40% 절감” 기대는 성립하지 않습니다.
진짜 절감은 보존 tail을 컬럼나+S3로 옮기고 hot을 축소·OR로 전환하는 데서 나옵니다. 이게 hot RI 최대 절감보다 큽니다.
우리 케이스: 90일 보존이 정말 필요한지부터 되묻습니다. tail 이전 + in-place 최적화를 먼저 합니다.

Apache Lucene 기반 분산 검색·분석 엔진입니다. 2021년 Elastic이 SSPL로 전환한 뒤 Elasticsearch 7.10.2 / Kibana를 포크해 만들었습니다. 라이선스는 Apache 2.0이고 지금은 OpenSearch Software Foundation(Linux Foundation)이 관리합니다 — 성숙도·생태계가 넓고 프로덕션 채택이 두텁습니다. AWS에서는 관리형 Amazon OpenSearch Service로 제공됩니다. 고객사는 fluent-bit → Firehose → OpenSearch(+ UltraWarm)로 운영 중입니다. 파이프라인 구성 자체는 정석입니다. 쟁점은 로그 저장 용도에 비춘 요금 구조입니다.

Loki + Alloy

Sun, 12 Jul 2026 00:00:00 +0000

Loki + Alloy — PLG를 ALG로 되살리기

object storage 네이티브 + 공격적 압축으로 장기 보존 비용이 낮습니다. Lucene/OpenSearch 대비 스토리지가 ~10–15× 적습니다.
카디널리티는 foot-gun입니다. 나쁜 라벨 하나가 수백만 스트림·ingester OOM으로 이어집니다. structured metadata가 완화하지만 그 규율은 팀이 지켜야 합니다.
풀텍스트/미지값 검색이 느립니다. label+time으로 못 좁히면 brute-force decompress-scan이라 VictoriaLogs 대비 최대 십수 배 느리다는 벤치가 있습니다.
promtail은 EOL 확정(2026-03-02)이고 Simple Scalable(SSD) 모드는 Loki 4.0에서 제거 예정입니다. 지금 SSD 위에 새로 지으면 sunset feature 위에 짓게 됩니다.
우리 케이스: istio access-log엔 잘 맞지만 스택을 하나 더 들이는 것 자체가 방치(rot) 리스크라 보류합니다.

Grafana 진영의 로그 집계 스택(AGPLv3). 로그 본문이 아니라 라벨 집합(스트림)만 인덱싱합니다. 압축 청크는 object storage에 두어 값싸게 보존하는 설계입니다. 2018년 공개 후 3.7.x로 성숙했고(최신 패치 v3.7.3, 2026-06-24), promtail이 EOL되며 Alloy가 자리를 넘겨받아 PLG(Promtail-Loki-Grafana)가 ALG(Alloy-Loki-Grafana)로 재편됐습니다.

VictoriaLogs

Sun, 12 Jul 2026 00:00:00 +0000

VictoriaLogs — VM을 이미 쓴다면 가장 자연스러운 선택

단일 static Go 바이너리·외부 의존성 0 — 벤더 주장으로 RAM 최대 30x·디스크 최대 15x 절감, 소규모 3rd-party 벤치도 같은 방향을 확인합니다.
쿼리 가능한 오브젝트 스토리지 티어가 없습니다(headline gap). 현재 local-disk-only이고 S3/GCS 백엔드는 로드맵 WIP·확정 일정 없음.
클러스터 내 복제(HA)가 없습니다 — 진짜 HA는 독립 클러스터 2벌 + mirror가 필요해 스토리지 비용이 대략 2배가 됩니다.
넓은 수집 호환(Loki push API 포함)에 VictoriaMetrics와 동일한 운영 모델 — 이미 VM을 운영 중이면 학습·rot 비용이 0에 가깝습니다.
우리 케이스: istio 로그부터 넣으면 오브젝트 스토리지 부재가 걸리지 않고 cold tail만 S3 Parquet로 분리하면 됩니다.

VictoriaMetrics 패밀리의 로그 전용 저장소로, 단일 static Go 바이너리 · 외부 의존성 0으로 돌아갑니다. 코어는 오픈소스(Apache-2.0)이고 일부 기능(vlagent의 Kafka 소스, 테넌트별 stats/quota 등)만 Enterprise-gated입니다. 단일 노드는 v1.0.0(2024-11-12)에서 GA(“production-ready”)에 도달했고 클러스터 모드는 2025-06에 공개돼 아직 ~1년 된 젊은 축입니다. 릴리스가 잦아(2026년에도 v1.50·v1.51 등 분기당 수 회) 활발하지만 그만큼 버전 pin이 필요합니다.

ClickHouse (self-hosted)

Sun, 12 Jul 2026 00:00:00 +0000

ClickHouse (self-hosted on EKS) — 통합 저장소로서의 야심

압축·저장 밀도가 이 클래스 최상급입니다 — OTel 로그 벤치에서 CH 내부 압축 ~16.3x, 디스크 상 Elasticsearch 대비 ~4.95x 작음.
분석 쿼리 성능이 뛰어나고(Uber 10x 처리량·50x aggregation) PB 스케일에서 실전 검증됐습니다(Trip.com 4→50PB+, Cloudflare quadrillion-row).
셀프호스트 운영 부담이 실재합니다 — 스키마·ORDER BY·TTL 설계가 상시 스킬 요구사항이고 clickhouse-backup의 incremental 체인은 fragile합니다.
진짜 storage-compute 분리는 Cloud 전용(SharedMergeTree)입니다 — self-host는 shared-nothing이라 RF2여도 S3에서 사본이 두 배가 됩니다.
우리 케이스: PLG 방치 이력이 있는 소규모 플랫폼 팀이라 self-host CH를 1차 채택안으로 밀지 않습니다 — 지배적 위험은 기술이 아니라 오너십입니다.

컬럼형(column-oriented) OLAP 데이터베이스입니다. Yandex에서 출발해 오픈소스로 공개된 Apache-2.0 프로젝트이고 대규모 분석 쿼리에 최적화된 성숙한 엔진입니다. 로그·트레이스·이벤트·웹 RUM을 한 스키마 계열·SQL 인터페이스로 흡수하는 “통합 관측성 저장소” 후보로 자주 거론됩니다.

HyperDX / ClickStack

Sun, 12 Jul 2026 00:00:00 +0000

HyperDX / ClickStack — ClickHouse 위의 통합 프론트

로그·트레이스 검색이 강합니다 — ClickHouse 컬럼 압축(Elasticsearch 대비 12~19x)과 native JSON의 이점을 그대로 받습니다.
replay → trace → log 상관이 시그니처 강점입니다 — 웹 프론트엔드 한정으로는 Datadog RUM을 현실성 있게 대체합니다.
네이티브 모바일 RUM이 없습니다(결정적). iOS/Android/Flutter 퍼스트파티 SDK가 없고 유일한 RN 포크도 세션 리플레이는 지원하지 않습니다.
메트릭이 가장 약합니다 — OTel 메트릭을 저장은 하지만 PromQL이 없습니다(SQL/Lucene only).
우리 케이스: 로그는 더 가벼운 VictoriaLogs로 가고 ClickStack은 채택하지 않습니다 — CH+MongoDB 운영 표면이 이번 로그 규모에는 과합니다.

ClickHouse Inc.가 HyperDX를 인수(2025-03)해 ClickStack으로 출시(2025-05)했습니다. ClickHouse를 백엔드로 쓰는 OpenTelemetry-native 관측성 스택입니다. HyperDX UI/API + 전용 OTel Collector + ClickHouse + 상태 저장용 MongoDB를 조합해 로그·트레이스·세션 리플레이를 한 화면에서 다룹니다. 메인 repo는 MIT 라이선스라 Grafana AGPL·SigNoz보다 관대합니다. ClickHouse Inc.가 정식 스튜어드를 맡아 월간 릴리스를 낼 만큼 개발도 빠릅니다(~9.7k stars, 활발한 릴리스 라인).

StarRocks

Sun, 12 Jul 2026 00:00:00 +0000

StarRocks — S3 위 stateless 컴퓨트, 그러나 로그엔 이르다

헤드라인 차별점은 다중테이블 JOIN·고동시성입니다(SSB ~~1.87x, TPC-H 3~~5x, ClickHouse 대비).
shared-data(storage-compute 분리)가 OSS에 first-class GA입니다 — S3/GCS/Azure/MinIO 위 stateless CN을 초 단위로 add/remove합니다.
로그의 핵심인 풀텍스트 inverted index가 가장 미성숙합니다 — 정작 쓸 shared-data 모드에서는 v4.1(2026) Beta입니다.
턴키 관측성 UI가 전무하고 네이티브 OTLP 리시버가 없으며 로그 스케일 프로덕션 레퍼런스가 사실상 0입니다.
우리 케이스: 로그 스토어로는 아직 얼리어답터 영역이라 S3 탄력성이 하드 요구인 별도 mandate가 없으면 숏리스트에서 제외합니다.

Linux Foundation MPP OLAP·실시간 분석 엔진(Apache-2.0). Apache Doris 포크(Doris 자체는 Baidu Palo 포크)를 vectorized execution + Cascades 코스트기반 옵티마이저로 재설계했고 창업사 CelerData가 2023-02 프로젝트를 Linux Foundation에 기증했습니다(상용 백커 유지). 최신 라인은 v4.0/4.1(2026)이며 무게중심은 서브초 BI·다중테이블 JOIN·레이크하우스 질의이고 로그는 근래 inverted index로 열린 인접 용도입니다.

ClickHouse vs StarRocks

Sun, 12 Jul 2026 00:00:00 +0000

ClickHouse vs StarRocks (로그/관측성 한정)

결정축은 3–3(+ 워크로드 의존 2축) — 무조건 승자는 없고 워크로드 shape가 답을 정합니다.
self-host storage/compute 분리·JOIN/mutable/레이크하우스·K8s 탄력 스케일은 StarRocks 승.
단일 테이블 스캔·압축·풀텍스트/JSON·생태계/매니지드는 ClickHouse 승.
로그/관측성 한정 판정 = ClickHouse. 결정타는 검색 축 — 가장 필요한 풀텍스트가 CH는 GA, SR은 Beta입니다.
둘 다 BM25/relevance 스코어링이 없습니다 — ES식 랭킹 검색이 진짜 필요하면 전용 검색층을 남겨야 합니다.

정면으로 붙여보면 결정축이 3–3(+ 워크로드 의존 2축)으로 나뉘어 “무조건 승"이 나오지 않습니다. 워크로드 shape가 답을 정합니다. (아래 표는 결정축 중심 요약)

우리 케이스 · 권장안

Sun, 12 Jul 2026 00:00:00 +0000

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

결론은 수집 1개(OTel Collector) + 저장 패밀리 1개(Victoria) + Grafana로 수렴합니다 — RUM/APM은 별도 트랙으로 분리 판단.
진짜 게이트는 인건비입니다 — 신호 하나만 내재화하면 platform SRE 인건비가 절감을 상쇄하거나 초과합니다.
저후회 시퀀싱: Week 0 공짜 이득 → 키스톤(OTel Collector) → istio 부활(D1) → dual-write(D2) → OpenSearch 은퇴 → RUM 트랙(D3) → 선택적 통합(D4, earn-it-last).
로그·메트릭·웹 RUM 세 신호가 같은 팀·같은 컬럼나 스토어를 나눠 물어야 통합 저장소(D4)가 성립합니다.
“OpenSearch 40% RI 절감 기대”, “메트릭을 CH/StarRocks에 억지로”, “Loki SSD 신규 구축” 등 7가지는 검증에서 기각됐습니다.

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