토리를 운영하면서 모니터링 시스템 부재로 인한 여러 불편함을 경험했다. 시스템의 현재 상태를 한눈에 파악하기 어려웠고, 로그 확인을 위해 서버에 직접 접근해야 했으며, 특정 이벤트나 에러가 발생했을 때 이를 즉시 인지하기 어려웠다. 이러한 상황은 서비스 운영의 효율성을 저하시키고 잠재적인 문제에 대한 선제적 대응을 어렵게 만들었다.
특히 다음과 같은 상황에서 모니터링의 필요성을 강하게 느꼈다
이러한 어려움을 해결하고 더 안정적인 서비스 제공을 위해 체계적인 모니터링 시스템 구축이 필요하다고 판단했다. 목표는 단순히 문제 발생 후 원인 파악을 위한 도구가 아닌, 서비스의 전반적인 상태와 동작을 투명하게 볼 수 있는 통합 모니터링 환경을 만드는 것이다.
ELK vs Grafana Loki
로그 시스템은 High-Write, Low-Read 패턴의 특성을 가지기 때문에, 대량의 데이터가 지속적으로 수집되지만 실제로 조회되는 비율은 상대적으로 낮다. 따라서 수집과 저장의 효율성, 그리고 검색 능력 사이에서 적절한 균형을 찾는 것이 중요하다. 로그 시스템 선택 과정에서 널리 사용되는 ELK 스택(Elasticsearch, Logstash, Kibana)과 Grafana Loki 스택을 중점적으로 검토했다. 두 솔루션을 다양한 측면에서 비교한 결과는 다음과 같다.
ELK 스택은 Elasticsearch, Logstash, Kibana로 구성된 로그 관리 솔루션이다. Elasticsearch는 모든 로그 콘텐츠를 인덱싱하여 다양한 검색 기능을 제공한다. 로그의 모든 내용을 인덱싱하기 때문에 어떤 필드든 빠르게 검색하고 집계할 수 있다.
이러한 강력한 기능은 리소스 비용으로 이어진다. 방대한 인덱스를 유지하기 위해 상당한 메모리와 디스크 공간이 필요하며, 로그 볼륨이 증가할수록 리소스 요구사항도 함께 증가한다. 또한 클러스터 관리, 샤딩, JVM 튜닝 등 전문적인 운영 지식이 요구되어 관리 부담이 있다.
Loki는 Prometheus에서 영감을 받아 개발된 로그 집계 시스템으로, 근본적으로 다른 접근 방식을 취한다. 로그 내용 자체가 아닌 메타데이터(레이블)만을 인덱싱하는 설계 철학을 가지고 있다.
레이블을 기준으로 로그 스트림을 구성하고, 실제 로그 내용은 압축하여 저장한다. 로그 검색 시 먼저 레이블을 기반으로 필터링한 후, 해당하는 압축된 로그 데이터를 가져와 처리하는 방식이다. 이러한 설계는 스토리지 사용량과 운영 비용을 크게 줄여준다.
Loki는 Write 경로(Distributor, Ingester)와 Read 경로(Query-Frontend, Querier 등)를 명확히 분리하여 각 컴포넌트를 독립적으로 확장할 수 있는 유연한 아키텍처를 제공한다. 또한 단기 데이터는 메모리에, 장기 데이터는 S3와 같은 비용 효율적인 오브젝트 스토리지에 저장할 수 있어 비용 효율성이 높다.
https://grafana.com/docs/loki/latest/get-started/architecture/