로그 저장소
데이터베이스에서 분리하는 이유
세 가지가 흔히 근거로 꼽히고, 두 가지가 더 있다.
- 저장·조회 구조가 다르다. 로그는 쌓이는 속도가 빠르지만 더 정확한 근거는 속도가 아니라 구조다. 로그 조회는 시간 범위 스캔과 전문 검색이 지배적이고, OLTP 엔진의 인덱스 구조는 그 목적이 아니다. Loki 는 “expensively indexing every line of your logs” 를 피하는 것을 설계 목표로 명시한다.
- 서비스 장애 때도 쌓여야 한다. 로그 적재 경로가 서비스 데이터베이스와 분리되어 있으면 데이터베이스가 죽은 상황의 원인도 로그로 남는다. 장애 원인을 찾아야 하는 순간에 로그 경로가 같이 죽는 구성은 그 자체가 장애를 길게 만든다.
- 조회 요구가 서비스 레벨까지 올라올 수 있다. 이 경우 저장소 선택이 어려워지므로 조회 패턴을 먼저 정의해야 한다 — 다음 절의 내용이다.
- 보존 기간과 스토리지 계층화가 다르다. Loki 는 오브젝트 스토리지를 유일한 저장 수단으로 삼고 S3, GCS, Azure Blob 을 쓴다(개발용으로 로컬 파일시스템). AWS S3 Tables 는 Intelligent-Tiering 을 이용한 비용 최적화를 별도 문서 항목으로 둔다. 즉 로그 저장소는 계층화와 수명주기를 전제로 설계돼 있고, OLTP 데이터베이스에는 그 기능이 없다.
- 압축 특성이 다르다. 열 지향 저장은 정렬된 값을 모아 두어 압축률을 얻는다. 같은 데이터를 행 지향 OLTP 테이블에 넣으면 같은 압축 효과를 기대할 수 없다.
조회 패턴으로 고르기
선택을 가르는 축은 저장 용량이 아니라 조회 패턴이다. 네 가지로 갈린다.
| 조회 패턴 | 선택지 | 라이선스 |
|---|---|---|
| 라벨 + 시간 범위로 좁힌다 | Grafana Loki | AGPLv3 |
| 전문 검색이 필요하다 | OpenSearch, Elasticsearch | Apache 2.0 / 3중 택1 |
| 집계·분석 쿼리를 돌린다 | ClickHouse | Apache 2.0 |
| 저비용 보존 + 간헐 조회 | S3 Tables + Athena | 해당 없음 |
제품별로 확인된 설계 성격은 이렇다.
- Grafana Loki — 로그 내용을 색인하지 않고 라벨 집합 형태의 메타데이터만 색인한다. 그래서 색인이 다른 로그 집계 도구보다 현저히 작다. Prometheus 에서 영향을 받았지만 메트릭이 아니라 로그에 초점을 두고, pull 이 아니라 push 로 수집한다. 저장은 오브젝트 스토리지가 유일한 수단이다. 확인된 최신 버전은 3.7.8(2026-09-17)이다. 라벨로 좁혀지지 않는 임의 문자열 검색이 주된 조회 패턴이면 이 설계가 맞지 않는다.
- Elasticsearch · OpenSearch — 전문 검색이 목적이면 여기다. Elasticsearch 는 로그·이벤트·메트릭처럼 타임스탬프가 붙은 append-only 데이터에 data stream 을 권한다. OpenSearch 는 Apache 2.0 단일 라이선스다.
- ClickHouse — 열 지향 저장과 병렬 선형 스캔으로 집계를 처리한다. 다만 단독 해법이 아니라는 점을 문서가 스스로 밝힌다 — “ClickHouse alone isn’t an out-of-the-box solution for Observability” 이고, 시각화는 Grafana, 수집은 OpenTelemetry 와 조합해야 한다.
- S3 Tables + Athena — 보존 비용을 낮추고 조회는 드물게 하는 구성이다. S3 Tables 가 Iceberg 형식 저장과 자동 compaction·snapshot 관리, Glue Data Catalog 통합을 맡고, Athena 가 Iceberg v2 테이블을 읽고 쓴다.
ClickHouse 문서에는 드문 형태의 1차 근거가 하나 더 있다 — 벤더가 자기 제품의 부적합 조건을 직접 적어 두었다. 아래 셋 중 하나에 해당하면 다른 선택지를 보라고 문서가 권한다.
- 메트릭 축이 필요하다 — 메트릭 pillar 는 ClickHouse 에서 아직 덜 성숙했고 Prometheus 포맷과 PromQL 지원이 대기 중이다.
- 데이터가 약 150 GiB 미만이고 늘지 않는다.
- SQL 을 쓰고 싶지 않거나, 패키지로 묶인 종단 간 관측성 경험을 원한다.
세 조건은 그대로 선택 기준으로 쓸 수 있다. 관측성 저장소를 고를 때 가장 먼저 대조할 목록이다.
시계열·메트릭은 로그가 아니다
로그 저장소를 고르면서 메트릭까지 같은 곳에 넣으려는 설계가 자주 나온다. 경계를 정의하는 가장 깔끔한 1차 근거는 Loki 문서가 자신을 Prometheus 와 대비시키는 문장이다 — 메트릭이 아니라 로그에 초점을 두고, pull 이 아니라 push 로 수집한다. 데이터의 성격(이산 이벤트 대 시간축 위의 수치)과 수집 방향(push 대 pull)이 둘 다 다르다.
| 제품 | 확인 버전 | 날짜 | 라이선스 |
|---|---|---|---|
| Prometheus | 3.14.0 | 2026-08-18 | — |
| VictoriaMetrics | v1.152.0 | 2026-09-14 | Apache 2.0 |
| TimescaleDB | 2.30.1 | 2026-09-17 | Apache 2.0 + TSL 분할 |
| InfluxDB 3 Core | 3.11 | 2026-09-08 | — |
- TimescaleDB 는 독립 제품이 아니라 PostgreSQL 확장이다. PostgreSQL 16, 17, 18 빌드가 제공된다. 라이선스가 디렉터리로 갈리므로(
tsl/안이 Timescale License) 쓰려는 기능이 어느 쪽인지 먼저 확인한다. - InfluxDB 3 는 Core 와 Enterprise 의 경계를 공식 문서가 명시한다. Enterprise 가 추가하는 것이 과거 이력 조회 기능과 단일 시리즈 인덱싱, 고가용성, 읽기 복제본이고, 강화된 보안·행 수준 삭제·통합 관리 UI 는 예정 항목으로 표시돼 있다. 장기 이력 조회가 요구에 있으면 이 경계가 선택을 정한다.
“하나의 저장소로 로그·메트릭·트레이스를 모두 덮는다” 는 구성은 2026-09 현재 벤더 스스로도 단정하지 않는다. ClickHouse 가 메트릭 축의 미성숙을 자기 문서에 적은 것이 그 증거다. 세 축을 한 저장소로 통합하려면 그 통합이 제품 문서로 뒷받침되는지 확인하고, 안 되면 축별로 나누는 쪽이 검증 가능하다.
Advertisement