-
Loki는 Grafana에서 개발한 오픈소스 로그 관리 시스템이며, Elasticsearch나 OpenSearch 같은 기존의 오픈소스 로그 데이터베이스보다 RAM과 저장 공간을 적게 사용하는 것이 주요 장점이다.
- Loki는 전체 로그를 인덱싱하지 않고, 일부 로그 필드(로그 스트림 라벨)만 인덱싱하는 구조이기 때문에, 빠른 전체 텍스트 검색은 지원하지 않지만 라벨을 통한 빠른 로그 스트림 탐색은 가능하다.
-
로그를 압축 저장함으로써 저장 공간 효율이 높아지고, 이러한 아키텍처는 대량 로그 저장과 분석에 필요한 CPU, RAM, 스토리지 등의 인프라 비용을 절감할 수 있게 해준다.
-
그러나 Loki는 Elasticsearch와 비교했을 때 다음과 같은 단점을 가진다.
-
Loki는 구성과 운영이 복잡한 편인데, 그 이유는 Loki의 전형적인 구성 방식이 서로 연결된 여러 서비스들로 이루어져 있고 설정 파일도 복잡하기 때문이다.
-
프로덕션 환경에서 Loki를 사용하려면 S3 호환 스토리지를 별도로 구성하고 관리해야 하며, 이는 단순한 저장 공간 이상의 추가 비용(예: PUT 요청 100만 건당 5달러, Glacier에서 1TB 읽기당 30달러 등)을 초래할 수 있기 때문에 사용자가 예기치 못한 요금 부담을 겪을 수 있다.
-
Loki의 업그레이드는 어렵고 자주 호환성을 깨뜨리는데, 새로운 릴리스가 이전 설정 옵션을 깨뜨리거나 새로운 설정을 강제하기 때문에 Loki를 업그레이드하려면 매번 설정 파일을 조정해야 한다.
-
Loki는 trace_id, user_id, ip 등과 같은 고카디널리티 필드를 다룰 때 RAM 사용량이 급격히 증가하는 경향이 있으며, 이에 대한 우회책으로 해당 필드들을 JSON으로 묶어 평문 로그 메시지에 저장한 뒤 쿼리 시 json 파이프를 사용해 필터링하라고 권장하지만, 이는 Elasticsearch처럼 역색인 구조를 활용한 필드 검색보다 훨씬 느릴 수밖에 없다.
-
고카디널리티 필드 문제를 해결하기 위해 최근 Loki에 structured metadata 기능이 추가되었지만, 아직 실험적인 상태이고 설정이 복잡하며 릴리스 간의 호환성도 보장되지 않아 실사용에 어려움이 있다.
-
Loki는 평문 로그에 대한 빠른 전체 텍스트 검색을 지원하지 않으며, 특정 단어 혹은 문장을 포함한 로그를 찾기 위해서는 전체 로그 메시지를 스토리지에서 읽어야 한다. 따라서 시간 범위와 라벨 필터로 검색 범위를 좁히는 것이 필수적이지만, 모든 검색이 이처럼 사전에 필터링 가능한 것은 아니며, 예를 들어 특정 user_id 값을 포함하는 모든 로그를 전체 스트림에 걸쳐 검색해야 할 경우 Loki는 매우 느리고 비용도 높아질 수 있다.
-
특히 로그가 S3 Glacier와 같이 데이터 조회 비용이 비싼 스토리지에 저장되어 있다면, 이러한 검색은 수 시간 이상 소요될 수 있고, 읽기 비용이 기하급수적으로 증가한다.
-
이런 문제점들에도 불구하고 Loki는 특정 환경에서는 효율적인 로그 저장 솔루션이 될 수 있지만, 설정의 복잡성, 느린 검색 속도, 고카디널리티 필드 처리의 비효율성 등으로 인해 모든 상황에서 최적은 아니다.
-
이러한 Loki의 단점들을 해결하면서도 Loki의 장점을 유지하고자 할 때 대안으로 떠오르는 것이 바로 VictoriaLogs이다.
-
VictoriaLogs는 Loki와 동일하게 로그 스트림 개념을 사용하며, 라벨 기반 필터링 역시 Loki와 동일한 방식(Prometheus에서 유래한 필터 시스템)을 사용하지만, 아키텍처와 기능 측면에서 Loki의 여러 한계를 근본적으로 해결한다.
-
VictoriaLogs는 설정과 관리가 매우 간단한 구조를 가지고 있는데, 이는 단일 실행 파일로 이루어져 있고, 별도 설정 없이도 모든 하드웨어 환경에서 최적의 성능을 발휘할 수 있는 zero-config 구조 덕분이다.
-
이 시스템은 설정 없이도 자동으로 가용한 CPU와 메모리를 감지하고, Raspberry Pi 같은 소형 장치부터 수백 개의 CPU 코어와 테라바이트 단위의 메모리를 가진 대형 서버까지 모든 환경에 맞게 동작할 수 있다.
-
VictoriaLogs는 데이터베이스 스키마나 인덱스를 미리 구성할 필요가 없는 schemaless 구조로 동작하기 때문에 운영 복잡도가 낮고, 유지보수가 간편하다.
-
프로덕션 환경에서 VictoriaLogs는 로그를 단일 로컬 디렉토리에 저장하며, 이 디렉토리는 일반적인 블록 디바이스나 파일시스템으로 마운트할 수 있기 때문에, 별도의 S3 호환 스토리지를 필요로 하지 않는다.
-
Google Persistent Disk 같은 영속적인 네트워크 블록 디바이스를 사용해도 무방하며, 이는 S3 대비 훨씬 저렴하고 예측 가능한 비용으로 운영할 수 있다.
-
VictoriaLogs는 릴리스 간 설정 호환성을 유지하는 정책을 공식적으로 약속하고 있으며, 새로운 릴리스를 적용할 때 기존 설정을 수정할 필요 없이 실행 중인 인스턴스를 중지하고 새 바이너리로 교체만 하면 된다.
-
특히 VictoriaLogs는 Loki에서 취약했던 고카디널리티 필드(user_id, trace_id, ip 등)에 대한 완벽한 대응을 제공하며, 별도의 JSON 파싱이나 쿼리 우회 없이 모든 필드를 자동으로 인덱싱하고 고속으로 검색할 수 있도록 설계되어 있다.
-
이 시스템은 각 필드를 컬럼 단위로 저장하는 column-oriented 구조를 채택하고 있어, 필드별 압축률이 높고 디스크 공간 사용량이 감소하며, 쿼리 시 필요한 필드만 읽기 때문에 쿼리 성능도 크게 향상된다.
-
평문 로그에 대한 전체 텍스트 검색도 매우 빠르게 처리할 수 있는데, 이는 로그 메시지를 토큰화하여 각 토큰에 대한 Bloom filter를 구성한 뒤, 이 Bloom filter를 사용하여 검색어가 없는 블록을 빠르게 건너뛸 수 있기 때문이다.
-
이러한 Bloom filter 기반 구조는 메모리에 로그 전체가 올라가지 못하는 환경에서도 Elasticsearch의 역색인 방식보다 더 나은 성능을 보여주며, 특히 ‘건초 더미에서 바늘 찾기’ 같은 유형의 검색에 매우 효과적이다.
-
VictoriaLogs는 Loki보다 일반적으로 더 적은 RAM과 디스크 공간을 사용하며, 쿼리 성능도 더 뛰어나다.
-
대부분의 일반적인 로그 분석 쿼리는 Loki보다 훨씬 빠르게 실행되며, 구조적 로그와 평문 로그를 모두 효과적으로 다룰 수 있다.
-
사용자는 설정이 필요 없고, 고카디널리티 필드를 고민할 필요도 없으며, 쿼리 언어 또한 더욱 강력한 기능을 제공받는다.
-
실제 프로덕션 환경에서 VictoriaLogs를 테스트해본다면, Loki에서 겪던 성능 저하, 유지보수 어려움, 검색 지연 문제들이 상당히 줄어들고 운영의 효율성과 가시성이 극적으로 개선된다는 것을 확인할 수 있을 것이다.
구조
VictoriaMetrics는 SingleNode Version, Cluster Version에 따라 구성 구조가 다르다.
-
SingleNode Version
- 단일 바이너리로 손쉽게 실행하고 사용할 수 있다.
- Prometheus 대비 2~10배 가량 빠르고 리소스를 적게 사용한다.
- 수집하는 데이터가 수천만 개 이상으로 증가하면 단일 노드로 트래픽 감당이 어렵고, SPOF(single point of failure)로 작용할 수 있다.
-
Cluster Version
-
- 저장되는 시계열 스케일에 맞춰 read, write, storage 컴포넌트의 수평적 scale out이 가능하다.
- replication factor를 적용하여 일정 부분 시계열 데이터 유실을 방지할 수 있다.
- 단 SingleNode에 비해 구조가 복잡하고 운영이 어려울 수 있다.
-
Prometheus의 한계를 극복하기 위한 Scalable Solutions
- Thanos
- Cortex
- Grafana Mimir
- M3DB
- Promscale
- VictoriaMetrics
참고