Intro
로그 시스템을 도입하게 된 계기는 다음과 같다.
- 기존의 서비스는 로그를 수준별로 파일로 나누어 저장만 하기에 유의미한 활용이 어렵다.
- 매번 발생하는 에러 로그를 추적하기 위해 ssh로 ec2 환경에 접속하는 작업도 귀찮다.
- 서버 에러 로그를 구성원 모두가 확인할 수 있기에 협업에 용이하다.
로그 시스템은 크게 ELK Stack과 Grafana Loki Stack이 있다.
ELK Stack
ELK Stack은 Elasticsearch, Logstash, Kibana의 앞글자를 딴 시스템 + Filebeat
Filebeat
- 각 서버에 설치되어 로그 혹은 파일을 경량화된 방식으로 전달한다.
- 크게 입력 플러그인과 출력 플러그인으로 구분할 수 있다.
- 입력 플러그인을 통해 Logstash, Kafka, Redis 등으로 로그를 수신할 수 있다.
- 출력 플러그인을 통해 Logstash, Elasticsearch 등으로 로그를 전달할 수 있다.
Logstash
- 데이터 처리를 위한 파이프라인으로 filebeat, kafka 등의 입력으로부터 받은 다양한 데이터(로그) 형식을 수집하고 변환할 수 있다.
- 불필요한 로그를 drop하고 별도의 필드를 파싱할 수 있다.
Elasticsearch
- 전처리된 로그 데이터를 저장한다.
- 하나의 데이터: document
- document를 묶는 집합: index
- 인덱스는 기본적으로 shard(샤드) 단위로 구분되고, 각 노드에 분산되어 저장된다.
- 강력한 검색 및 쿼리 기능을 제공하여 다양한 조건으로 로그를 검색하고 원하는 데이터를 쉽게 추출할 수 있다.
- Full Text Search에 강점이 있으며 Block Storage에 샤딩하여 저장하기에 Grafana Loki Stack보다 빠른 속도로 로그를 조회할 수 있지만, 유지보수하기 위해 상당한 노력이 든다.
kibana
- 시각화 도구로써 Elasticsearch에 저장된 데이터를 시각화하여 볼 수 있다.
Grafana Loki Stack
Grafana Loki Stack은 Promtail + Loki + Grafana 조합으로 구성하는 가벼운 로그 시스템이다.
Promtail
Promtail is an agent which ships the contents of local logs to a private Grafana Loki instance or Grafana Cloud. It is usually deployed to every machine that runs applications which need to be monitored. - Promtail 공식 문서
Promtail은 로컬 로그를 Loki나 Grafana에 전달하는 에이전트이다.(ELK Stack에 Filebeat 역할)
Promtail이 수행하는 역할은 다음과 같다.
- Discover Target: 전달할 타겟을 설정
- Attaches labels to log streams: log stream에 label을 붙임(pipeline stage에서 설정)
- Pushes them to the Loki instance: Loki로 전달
Loki
- 수평 확장이 가능하고 가용성 높은
로그 집계 시스템 - Like Prometheus, But for logs의 철학을 갖고 있다.
- Object Storage에서 데이터를 직접 가져와 Loki가 분석하기에 Block Storage에 비해 상대적으로 느리다.
- Loki는 이 문제를 해결하기 위해 로그에 대한 메타데이터인
레이블을 인덱싱한다는 아이디어를 중심으로 구성했다.(로그를 조회하기 위해 1차로 메타 데이터를 기반으로 조회 + 메타 데이터에 매칭되는 레이블을 고도로 압축된 로그 데이터(Chunk)만 따로 가져와 유저에게 보여줌) - Loki 내부적으로 Write 컴포넌트와 Read 컴포넌트를 나눌 수 있어 효율적인 운영이 가능하고 언제든 스케일링이 가능하다.(Read Component를 빠르게 조회하기 위해 Memcached와 같은 별도 캐시를 사용하거나 Global Query를 날려 캐싱처럼 사용하거나 병렬 처리를 할 수도 있다)
Grafana
- Grafana는 시계열 매트릭 데이터를 시각화하는 Data Visualization Tool이다.
- prometheus, loki 등 다양한 datasource와 연동하여 시각화할 수 있다.
- 다양한 플러그인이 있어 대시보드를 직접 만들지 않고도 간단하게 구성 가능하다.
무엇을 선택할까?
현재(2023.11.22일 기준) 모니터링 시스템은 EC2에서 Cloudtype으로 이전했기에 아래와 같은 구성도를 갖고 있다.
- Release Server[EC2] - Spring, Node Exporter
- Monitoring Server[Cloudtype] - prometheus(docker), grafana(template)
이미 Grafana 생태계를 사용하고 있기에 Loki Stack을 도입하는게 더 쉬울거 같았지만, 조금 더 장단점을 찾아보며 우리 도메인에 어떤 스택이 더 맞을지 고민해보았다.
ELK와 Grafana Loki 비교
- 환경
- 서버 비용을 최대한 낮추기 위해 free tier EC2와 Cloudtype을 사용하고 있는 시점에서 새로운 서버를 구축하는데는 부담이 된다. 새로운 Cloudtype 계정을 만들어 최대한 기존의 것들을 활용하고, 인프라를 작게 구성하는 방향이 더 좋을거 같다. →
Loki - 로그를 수집할 때 filebeat와 promtail 모두 경량화된 방식으로 수집하기에 서버에 부담이 되지는 않는다. 다만, ELK Stack을 구성할 때 한 대의 서버에 ELK를 모두 설치할 경우 4GB 이상의 메모리를 요구하기에 Loki에 비해 많이 무겁다. →
Loki
(promtail은 실서버 EC2 환경에 도입해본 결과 cpu 0.3%, memory 3.5%정도 점유하는 것으로 측정됐다)
- 서버 비용을 최대한 낮추기 위해 free tier EC2와 Cloudtype을 사용하고 있는 시점에서 새로운 서버를 구축하는데는 부담이 된다. 새로운 Cloudtype 계정을 만들어 최대한 기존의 것들을 활용하고, 인프라를 작게 구성하는 방향이 더 좋을거 같다. →
- Learning curve
- 솔직히 둘 다 처음 접해보는 스택이기에 공식 Docs가 잘 되어있고 Reference가 많으면 좋을거 같다. 대부분의 회사는 로그 시스템을 ELK로 구성하기에 참고 자료도 많고, 공식 문서도 잘 되어있으나 Loki는 참고 자료가 적고, Docs도 상대적으로 불친절하다. →
ELK
- 솔직히 둘 다 처음 접해보는 스택이기에 공식 Docs가 잘 되어있고 Reference가 많으면 좋을거 같다. 대부분의 회사는 로그 시스템을 ELK로 구성하기에 참고 자료도 많고, 공식 문서도 잘 되어있으나 Loki는 참고 자료가 적고, Docs도 상대적으로 불친절하다. →
- 확장성
- 사실 지금은 프로젝트 규모가 크지 않기에 로그 데이터를 EC2 내부에 저장해도 상관 없으나 규모가 커질수록 로그 시스템에 저장하는게 좋을 것이다. Elasticsearch와 Loki 둘 다 로그 수집을 위한 좋은 대안이 될 수 있으나 Elasticseacrh는 Loki에 비해 더 다양한 기능을 제공하고 대용량 데이터 처리에 특화되었다.(그렇기에 리소스를 더 많이 필요로 한다) 다양한 기능을 제공한다는 점에서 Elasticsearch가 더 매력적이었으나 로그 보관기한에 제한이 있고 스케일링이 어렵다는 단점이 있다. →
Loki
- 사실 지금은 프로젝트 규모가 크지 않기에 로그 데이터를 EC2 내부에 저장해도 상관 없으나 규모가 커질수록 로그 시스템에 저장하는게 좋을 것이다. Elasticsearch와 Loki 둘 다 로그 수집을 위한 좋은 대안이 될 수 있으나 Elasticseacrh는 Loki에 비해 더 다양한 기능을 제공하고 대용량 데이터 처리에 특화되었다.(그렇기에 리소스를 더 많이 필요로 한다) 다양한 기능을 제공한다는 점에서 Elasticsearch가 더 매력적이었으나 로그 보관기한에 제한이 있고 스케일링이 어렵다는 단점이 있다. →
따라서 Grafana Loki Stack으로 로그 시스템을 구축해보자
참고
Backend-Developer