Loki 간단 정리

로그적재시스템은 low-read, high-write 환경이다. 로그는 1초에도 엄창난 량이 적재되지만, 실제 로그를 조회하는 행위는 빈번하지 않다. 경우에 따라서는 장애나 버그가 발생하지 않고서는 조회될 일이 없기도 하다.

기존 ELK 스택의 단점

ELK 스택을 사용하며 서비스가 확장되다 보면 인덱스 부하가 필연적으로 발생한다. 비용이 증가하고, 운영 부담도 커진다. 스케일링을 위해서는 인덱스와 샤드를 옮기는 작업을 해야하고, 볼륨이 커질수록 많은 시간이 소요된다.

볼륨에 저장하는 로그 기간을 줄이고 S3로 저장하다 보면 조회방법이 파편화되기도 한다.

전반적으로 ElasticSearch는 높은 비용과 대규모 클러스터 확장이 곤란한 문제를 가지고 있다.

요즘 우아한형제들이나 넥슨 등 회사들이 관심을 가지는 스택이 LGTM이다. LGTM은 ELK의 단점을 어느정도 해소한다.

오늘은 LGTM의 “L”을 맡고 있는 Loki를 정리해본다.

Loki는 로그에 대한 메타데이터만 인덱싱한다. 즉, 로그 자체의 내용들을 인덱싱하는 것이 아니라 레이블 세트를 인덱싱한다. 실제 로그는 압축되어 저장된다.

따라서 실제 조회시에는 메타데이터로 매칭된 레이블과 이에 매칭되는 압축 로그 데이터를 가져와 사용자에게 보여주게 된다.

Loki는 수평확장 가능한 고가용성의 멀티 테넌트 로그 수집 시스템이다.

Prometheus와 유사하지만 메트릭이 아닌 로그를 대상으로 한다는 점, Pull 방식이 아니라 Push 방식으로 동작한다는 점이 차이가 있다.

key value pair 형태로 된 모든 데이터. Loki에서는 log stream의 메타데이터를 지칭할 때 사용하는 단어이다.