AWS EKS 기반 Loki 구축 사례

AWS Ambassador

AWS EKS 기반 Loki 구축 사례

백룡화검 2025. 4. 22. 21:32

AWS EKS 환경에서 로그 시스템으로 Loki를 구축한 경험과 과정에서 겪었던 도전 과제, 해결 방법에 대해 공유하고자 한다.

예시 EKS 환경의 아키텍처는 아래와 같다.

예시 EKS 환경의 콘솔 화면은 아래와 같다.

* kubenetes 버전 : 1.32.

* nodegroup 관리 : 동적으로 인스턴스 유형을 간편하게 변경하기 위해 launch template 사용.

1. 도입 배경 및 필요성

AWS EKS로 전환하기 전에는 로그를 확인하기 위해 직접 접속하여 로그 파일을 확인하는 방식을 사용했습니다. 하지만 EKS 환경으로 전환하면서 큰 문제에 직면했다.

EKS Node는 AutoScaling으로 인해 서버가 동적으로 생성되고 제거되기 때문에, 기존 방식처럼 특정 서버에 접속해서 로그를 확인하는 방식을 유지하기가 어려웠다. 이런 상황에서 모든 로그를 한 곳에서 통합적으로 확인할 수 있는 로그 아키텍처의 필요성을 느끼게 되었다.

2. 왜 Loki를 선택했는가?

로그 수집 시스템으로는 ELK(Elasticsearch, Logstash, Kibana), EFK(Elasticsearch, Fluentd, Kibana) 등 다양한 옵션이 있었지만, 저희는 Loki를 선택하게 되었다. 그 이유는 아래와 같다.

Grafana 생태계와의 통합

Grafana에서 제공하는 다른 관측성 도구(Mimir, Tempo, Prometheus, Alloy)와의 결합이 용이.

풍부한 대시보드 라이브러리

다양한 Grafana 대시보드 라이브러리가 존재하여 손쉽게 대시보드 구축할 수 있으며 커스텀 대시보드 생성을 통하여 상황에 맞는 대시보드 구축 가능.

통합 모니터링 환경

Grafana에서 애플리케이션 로그 및 인프라 모니터링 대시보드를 함께 확인하고 분석 가능.

3. Loki 아키텍처 및 구성요소

아래는 Loki의 간단한 아키텍처이다.

Loki의 간단한 아키텍처를 보았을 때 단순히 Loki 컴포넌트만으로 구성되지 않으며, Promtail, Loki, Grafana의 조합으로 완전한 로그 수집 및 분석 시스템을 구성한다.

각 구성요소의 역할

영역	설명
Promtail	- 각 EKS Node마다 Daemonset(Agent 형태)으로 설치. - 기본적으로 각 Node의 /var/log/pods 아래 컨테이너 로그 수집. - scrape_config 옵션으로 환경에 맞는 별도 애플리케이션 로그도 수집 가능. - 수집된 로그는 지속적으로 Loki로 push.
Loki	- Promtail에서 push 받은 로그를 처리. - 메타데이터(Label)은 indexing하고, 실제 로그 데이터는 압축된 chunk 형태로 저장소(S3)에 저장.
Grafana	- DataSource를 Loki로 설정 후, LogQL을 사용하여 로그 쿼리 가능. - 쿼리 결과는 Grafana Explore, Dashboard 등에서 확인 가능.

Loki의 세 가지 운영 모드

Loki를 배포할 때 고려해야 할 중요한 요소 중 하나는 운영 모드입니다. Loki는 크게 3가지 모드로 운영할 수 있다.

모드 명	구성 방식 및 특징	적합한 환경
Monolithic 모드	- 모든 컴포넌트가 하나의 프로세스 / Pod에서 동작. - 설정이 간단하고 빠른 테스트 및 소규모 환경에 적합.	소규모(20 ~ 100GB 이하/일) 테스트 / 개발 환경.
Simple Scalable 모드	- 컴포넌트를 ‘Write’, ‘Read’, ‘Backend’ 3개 그룹으로 분리. - 각 그룹별로 독립적으로 확장 가능.	중규모(수백 GB ~ 수 TB/일) 운영 환경.
Microservice 모드	- 모든 컴포넌트를 각각 독립적인 마이크로서비스로 분리. - 최대한의 유연성과 확장성 제공.	대규모(수 TB 이상/일) 및 복잡한 운영 환경.

4. Monolithic 모드 배포 및 직면한 문제

처음에는 빠르고 간단하게 관리할 수 있는 Monolithic 모드로 Loki를 배포했다.

Loki Monolithic 모드로 배포했을 때의 화면이며 Promtail이 2개로 동작하는 이유는 EKS Node가 2대이기 때문이다.

Monolithic 모드 구성 요소

Pod 명	역할	세부 동작
Loki	모든 Loki 컴포넌트를 단일 프로세스에서 실행.	- Distributor : 로그 수집 요청 처리. - Ingester : 로그를 메모리에 저장, S3에 chunk 형태로 저장. - Querier : LogQL 쿼리 처리. - Compactor : 저장 데이터 압축.
Loki Canary	Loki 클러스터 상태 모니터링.	- fake 로그 주기적으로 Loki에 전송. - 해당 로그의 정상 저장 / 조회 확인.
Loki Gateway	Loki API 요청 프록시, 인증 / 부하 분산.	- /loki/api/v1/push 및 /loki/api/v1/query 엔드포인트 노출.
Loki Cache	로그 chunk와 쿼리 결과 캐싱.	- Chunk Cache : 자주 접근되는 로그 chunk 메모리 캐싱. - Result Cache : 반복적인 쿼리 결과 저장.

발생한 문제

운영 환경에서 성능 및 부하 테스트를 위해 EKS Node와 Pod의 수량을 Scale Out했을 때, 심각한 문제가 발생했다.

1. 로그 쿼리 불가 : Loki에서 로그 쿼리 자체가 되지 않음.

2. OOM 에러 : 얼마 지나지 않아 Loki 관련 Pod들이 OOM(Out of Memory) 에러를 발생시키며 정상 동작하지 않음.

원인 분석

원인을 분석해보니, 애플리케이션의 로그 레벨이 info로 설정되어 있었고, Pod와 Node 수량 증가에 따라 Monolithic 모드가 처리할 수 있는 용량을 초과했다. 단일 프로세스로 동작하는 Loki 컴포넌트에 심각한 부하가 발생한 것이 문제였다.

5. Microservice 모드로 전환

문제 해결을 위해 Microservice 모드로 아키텍처를 전환했다.

Loki Microservice 모드로 배포했을 때의 화면이며 Promtail이 4개로 동작하는 이유는 EKS Node가 4대이기 때문이다.

Microservice 모드 구성 요소

Pod 명	역할
Compactor	저장된 데이터 압축 및 처리.
Distributor	들어오는 요청 분산.
IndexGateway	인덱싱 처리 담당.
Ingester	데이터 수집 및 저장.
Querier	쿼리 요청 처리.
QueryFrontend	쿼리 프론트엔드 역할, 쿼리 요청 관리.
QueryScheduler	쿼리 스케줄링 담당.

Microservice 모드의 Flow (Read / Write)

Loki Microservice 모드의 Write Flow

Loki Microservice 모드의 Read Flow

전환 효과

Monolithic 모드에서 단일 프로세스로 동작하던 컴포넌트들(Distributor, Ingester, Querier, Compactor)이 Microservice 모드에서는 위 Flow와 같이 각각 분리되어 동작하기 때문에 아래와 같은 이점이 있다.

1. 부하가 분산되어 시스템의 안정성 향상.

2. 각 컴포넌트별 독립적인 스케일링 가능.

3. 장애 발생 확률 감소.

Microservice 모드라도 신경써야 할 점

Cache(쿼리 결과 출력을 빠르게 하기 위해 메모리에 상주시키는 역할), Querier(LogQL로 요청 들어온 로그 쿼리를 실제로 수행하는 역할)의 경우 별도 Resource의 Limit을 걸어두지 않으면 Node의 Memory를 전부 사용하는 부작용이 있다.

때문에 아래 2가지 경우를 고려하여 적용해야 한다.

1. 별도 Loki 관련 Pod들만 모여 있는 NodeGroup 생성.

2. 현 Node의 Resource 상황을 고려하여 Cache, Querier의 Resource Limit 부여.

6. 마무리 : EKS 기반 Loki를 사용하면서 느낀 점

AWS는 최근 Kubernetes의 가파른 학습 곡선을 완화하기 위해 다음과 같은 기능들을 출시하고 있다.

1. EKS Auto Mode 기능 : Kubernetes에 대한 깊은 지식 없이도 필요한 Addon 항목들을 자동으로 설치.

2. Custom Addon 추가 지원

Metrics Server
Kube State Metrics 및 Prometheus Node Export
External DNS
Cert Manager

AWS가 EKS 기반 애플리케이션 운영에 집중할 수 있도록 노력하고 있지만, 로그 영역도 Managed 서비스로 제공된다면 AWS Managed Prometheus, AWS Managed Grafana와 통합하여 사용할 수 있으므로 인프라 관리자와 개발자 모두에게 관리의 포인트가 줄어들기 때문에 큰 도움 될 것으로 기대하고 있습니다.

감사합니다.