ELK vs Loki

ELK vs Loki: 로깅 시스템 선택

1. 문제 발생

기존에는 ELK(Elasticsearch, Logstash, Kibana) 스택을 사용하여 데이터 분석과 로깅을 관리하고 있었으나, MSA(Microservices Architecture) 도입을 고려하면서 대용량 서버 운영에 대한 새로운 요구사항이 생겼다. 이에 따라 분석과 로깅의 역활이 분리될 필요가 있었고 로깅은 스케일링이 용이하고 관리 비용이 적은 시스템으로 도입될 필요가 생겼다.

 

생각의 발달은 아래의 우아한 형제들의 기술 블로그를 토대로 발전시켰다.

따끈따끈한 전사 로그 시스템 전환기: ELK Stack에서 Loki로 전환한 이유 | 우아한형제들 기술블로그

 

2. 문제 원인

• ELK는 강력한 검색 기능을 제공하지만, 운영 비용이 높음
  • Elasticsearch의 샤드 관리가 복잡하고, 인덱스 저장 공간을 많이 차지함.
  • 대량의 로그를 저장할 경우 샤드 개수 증가로 인해 성능 튜닝이 필요함.
  • Logstash의 리소스 사용량이 높고, 수많은 로그 데이터를 처리하기 위해 별도의 클러스터링이 필요함.
• Loki는 메타데이터 기반의 경량 로그 저장 시스템
  • 로그 데이터를 직접 인덱싱하지 않고, 레이블을 기반으로 저장.
  • 레이블 단위로 로그를 청크(Chunk) 단위로 압축하여 저장하므로 저장 공간을 절약할 수 있음.
  • 복잡한 샤드 관리가 필요 없으며, 확장성이 뛰어남.

 

3. 문제 해결책 수립

해결 방법 비교

비교 항목	ELK (Elasticsearch, Logstash, Kibana)	Loki (Grafana Loki)
로그 저장 방식	전체 로그를 인덱싱하여 검색 가능	로그 내용을 색인화하지 않고, 레이블을 기반으로 저장
검색 성능	고급 검색 기능 제공 (Full-text Search, Aggregation 지원)	레이블 기반 필터링, Full-text Search 미지원
저장 공간	인덱싱된 데이터로 인해 저장 공간 요구량 높음	청크 단위 압축 저장으로 공간 절약
운영 및 확장성	샤드 관리, 리소스 최적화 필요	샤드 관리 불필요, 간단한 확장 가능
리소스 사용량	높은 CPU, 메모리 사용량	상대적으로 낮은 리소스 사용량
적용 사례	정밀한 검색 및 분석이 필요한 환경	MSA 및 대용량 로그 저장이 필요한 환경

 

4. 문제 해결: Loki 도입 결정

(1) MSA 환경에서의 확장성 고려

• MSA 기반 서비스는 여러 개의 마이크로서비스에서 로그를 생성하며, 각 서비스의 로그를 독립적으로 관리하면서도 효율적인 검색이 필요하다.
• Loki는 샤드와 같은 복잡한 관리가 필요 없고, 로그 저장 방식이 가볍기 때문에 대량의 서버를 운영하는 데 적합하다.

(2) 저장 공간 최적화

• ELK는 모든 로그를 색인화하는 방식이기 때문에 저장 공간이 많이 필요하며, 특히 대량 로그 저장 시 운영 비용이 증가한다.
• Loki는 로그 내용을 직접 색인화하지 않고, 레이블 기반으로만 색인하여 저장 공간을 절약할 수 있다.

(3) 인프라 운영 비용 절감

• ELK는 검색 기능이 강력하지만, Logstash와 Elasticsearch의 리소스 사용량이 높아 운영 비용이 증가한다.
• 반면, Loki는 가벼운 구조를 가지고 있어 운영 비용이 낮고, 확장성이 뛰어나다.

 

5. 결론

• 기존 ELK는 강력한 검색 기능이 필요할 때 유용하지만, 저장 공간과 운영 비용이 많이 소모된다.
• MSA 기반 대규모 로그 관리에서는 Loki가 더 적합하며, 샤드 관리 없이 확장성이 뛰어나고 운영이 간편하다.
• Loki는 로그 데이터를 직접 색인하지 않으며, 청크 단위로 저장하여 저장 공간을 절약할 수 있다.
• 결과적으로, ELK에서 Loki로 전환하여 MSA 환경에서 더욱 효율적인 로그 관리를 수행할 수 있다.