makgol's note – 저장소 비교·선택

OpenSearch (EFK)

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

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 +0900

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 +0900

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 +0900

ClickHouse를 로그 저장소로 운영한다면

ClickHouse는 로그를 SQL로 검색하고 집계할 수 있는 컬럼형 OLAP 데이터베이스입니다. Yandex에서 시작한 Apache-2.0 프로젝트로, 로그·트레이스·이벤트를 함께 저장하는 용도로도 쓰입니다. 저장량을 줄이고 대규모 집계를 빠르게 처리할 여지가 있지만, 직접 운영하려면 스키마와 복제, 백업을 담당할 사람이 필요합니다.

HyperDX / ClickStack

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

HyperDX / ClickStack으로 로그와 RUM을 함께 보기

HyperDX는 로그를 찾다가 같은 요청의 트레이스와 브라우저 세션 리플레이까지 이어 보는 데 유용합니다. ClickHouse를 저장소로 쓰고, HyperDX UI·API, 전용 OTel Collector, 앱 설정용 MongoDB를 함께 운영합니다. ClickHouse Inc.가 2025-03에 HyperDX를 인수한 뒤 2025-05에 이 조합을 ClickStack으로 출시했습니다.

StarRocks

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

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 +0900

로그 저장소로 비교하는 ClickHouse와 StarRocks

로그가 계속 추가되는 큰 테이블을 검색·집계하려는지, 다른 업무 테이블과 JOIN하고 자주 수정하려는지에 따라 선택이 달라집니다. 이 비교는 2026-07~08 조사 당시의 기능과 로그·관측성 워크로드를 기준으로 합니다.

우리 케이스 · 권장안

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

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

결론은 수집 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)에서 다뤘습니다 — 목록은 챕터 개요 참고. 여기서는 그걸 우리 환경에 대입해 최소 조합·게이트·마이그레이션 순서로 정리합니다.