중앙 집중식 로깅 시스템 (EFK stack)

중앙 집중식 로깅

일반적으로 분산환경에서 마이크로서비스를 운영하면 각 서비스에서 발생한 로그 파일들은 파편화되어 각각 저장된다.

서로 다른 개별 서비스에서 발생하는 로그를 연결지어 처음부터 끝까지 순서대로 추적하는 것은 어렵다.

따라서 로그의 출처에 상관없이 모든 로그를 중앙 집중적으로 저장, 분석해야 하며, 서비스 실행 환경에서 분리하여 관리되어야 한다.

 

• 장점
  • 여러 서버나 어플리케이션에서 생성된 로그를 한 곳에 수집하기 때문에 다양한 시스템의 상태를 한 번에 파악할 수 있다.
  • 모든 로그 데이터를 통합하여 저장하므로 관리가 용이해진다. (보통 용량이 크고 확장 가능한 DB나 클라우드 스토리지사용)
  • 중앙에서 로그를 한 번에 검색하고 분석할 수 있으므로 이벤트를 추적하기가 쉬워지고, 문제 해결 시간이 단축된다.
• 단점
  • 단일 장애 지점 - 중앙 로그 서버에 문제가 생기면 전체 로그 수집 및 관리가 중단될 수 있다,
  • 성능 - 로그의 양이 방대해지면 처리 성능 및 검색 속도가 느려질 수 있으며, 클러스터링과 같은 복잡한 구조를 도입해야할 수 있다.
  • 네트워크 - 대규모 시스템에서 실시간으로 로그를 수집할 경우 네트워크 부하가 발생할 수 있다.
  • 비용 - 인프라, 저장공간, 유지보수, (상용 솔루션 사용 시) 라이선스 비용 등
  • 확장성 - 시스템의 크기에 비례하여 로그 양도 기하급수적으로 늘어나므로 확장성이 충분히 고려되어야 함.

 

마이크로서비스 아키텍처와 컨테이너화된 어플리케이션의 복잡성으로 인해 쿠버네티스 환경에서 로깅은 매우 중요하다.

• 동적 인프라 관리
  컨테이너화된 어플리케이션은 필요에 따라 생성되고 삭제되기 때문에, 인프라의 상태가 끊임없이 변화한다.
• 클러스터 안정성 유지
  클러스터 내에서 발생하는 노드 다운타임, pod 실패, 네트워크 장애와 같은 이슈를 모니터링한다면 서비스의 가용성을 높이고, 장애로 인한 손실을 최소화할 수 있다.
• 성능 최적화와 리소스 관리
  CPU, 메모리, 네트워크 사용량 등 다양한 리소스 메트릭을 추적한담녀 과도한 리소스 사용이나 비효율적인 자원 배분을 실시간으로 감지하여 최적화할 수 있다.
• 보안 강화
  비정상적인 트래픽, 권한 없는 접근 시도, 취약한 컨테이너 이미지 사용 등을 탐지하고 경고할 수 있다.

* 참고:

쿠버네티스 모니터링 활용 사례

Pod 메모리 누수 해결 사례

 

 

중앙 집중식 로깅 컴포넌트

1. 로그 생산자가 로그 스트림을 생산한다.
2. 로그 적재기에서 서로 다른 로그 생산자에서 생산하는 로그 메시지를 수집하고,
   다양한 종단점으로 메시지를 보낸다. (로그 저장소, 스트림 처리기, 대시보드 등)
3. 로그 스트림 처리기에서는 로그 저장소/대시보드 등에 보내기 위해 실시간 로그 이벤트를 분석/처리한다.
4. 로그 저장소에서는 모든 로그 메시지를 저장한다.
   실시간 로그 저장: elasticsearch 등
   로그 아카이빙: hdfs, s3 등
   통계/요약 데이터: mongodb, cassandra 등
5. 로그 대시보드에서는 로그 분석 결과를 사용자가 보기 편한 차트, 그래프등의 형태로 로그 분석 보고서를 보여준다.

 

Logstash vs. Fluentd

두 솔루션 모두 엔터프라이즈급 로그 파이프라인 구성에 사용되는 로그 분석용 파서 역할을 할 수 있다.

수집된 로그를 필터링, 라우팅할 수 있고, 모두 다양한 플러그인을 사용할 수 있다.

 

 

1. 생태계 및 설계 철학

Logstash는 Elastic 에서 개발한 툴로, Elasticsearch, Kibana 등의 다른 Elastic 툴과의 통합이 용이하다. 

Fluentd는 CNCF(Cloud Native Computing Foundation)의 graduated project 중 하나로, 클라우드 네티이브 시스템, 마이크로 서비스, prometheus와 같은 다른 CNCF 재단에 속한 프로젝트와 함께 사용하기 용이하다. Elastic 사의 시스템과도 통합을 지원한다.

https://www.cncf.io/projects/

 

Logstash의 경우 Grok 필터와 같은 고급 패턴 매칭 기능을 제공하여 로그데이터를 정제하고 분석하는데 용이하며, Fluentd의 경우 로그데이터를 여러 클라우드 서비스나 데이터베이스로 전송하는데에 최적화된 플러그인이 많다.;

 

Fluentd의 경우 경량화된 설계를 바탕으로 데이터 수집과 전송을 단순하고 효율적으로 처리하는데에 중점을 두는 반면, Logstash는 다양한 입력/필터/출력 플러그인을 사용해 데이터를 정제하고 변환하는 데에 초점을 맞춘다.

 

 

 

2. 성능 및 사용 리소스

Logstash 는 java로 개발되었고, JVM 위에서 실행된다. 고급 필터링이나 복잡한 데이터 처리 작업을 할 때는 Fluentd에 비해 많은 cpu와 메모리를 소모할 수 있다. 타 오픈소스에 비해 무겁고 설정이 복잡한 편.

 

Fluentd는 Ruby + C로 제작되어 상대적으로 빠르고, 메모리 사용량도 낮다.

경량으로 설계되어 있어 리소스 사용량이 적고 성능이 우수하다. 대규모 로그 데이터를 처리할 때 더 효율적이다.

 

 

3. 확장성 및 클러스터링

Logstash는 클러스터링 기능은 직접 지원하지 않고 있지만 Elasticsearch와의 연동을 통해 로그를 처리하고 검색하는 확장성을 얻을 수 있다.

 

Fluentd는 기본적으로 경량화되어 있어 확장성이 뛰어나고, 대규모 분산 환경에서 효과적으로 사용할 수 있다. Kubernetes 환경에서 Fluentd를 로그 수집기로 자주 사용한다고 한다. 다중 작업을 쉽게 분산할 수 있도록 설계되어 있다.

 

 

위와 같은 특징으로 아래와 같은 사례에서 유용하게 사용된다.

 

• Logstash: 고급 데이터 처리, 강력한 필터링 및 변환 기능, Elastic Stack과의 긴밀한 통합.
  -> 로그 분석, 검색, 모니터링이 중요한 환경에서 많이 사용된다.
• Fluentd: 경량, 빠른 성능, 리소스 절약, 클라우드 환경에 적합.
  -> kubernetes, docker 등의 클라우드 네이티브 환경에서 자주 사용된다.

 

EFK stack - 구성 요소 

Fluentd

• 로그를 수집하고 로그 저장소에 로그를 보내는 역할

Fluentbit는 성능에 중점을 두고 개발되었기 때문에 Fluentd와 비교하여 더 경량화 되어 있고, 사용하는 리소스도 훨씬 적다. 그렇기 때문에 FluentBit를 deamonset으로 실행하고 Fluentd 서비스에 로그를 전달하는 방법으로 사용할 수 있다.

https://docs.fluentbit.io/manual/about/fluentd-and-fluent-bit

 

 

Fluentd 구성 요소

https://www.fluentd.org/architecture

 

• input: 여러 플러그인들로 다양한 어플리케이션으로부터 다양한 포맷의 데이터를 수집
• buffer(optional): input에서 들어온 데이터를 바로 쓰지 않고 buffer을 둠 (file/memroy 두 가지 타입)
  로그를 분리하는 tag단위로 chunk 생성
•  
• output: 여러 output plugin을 사용해 출력함.

 

Elasticsearch

• 분산형 검색 및 분석 엔진으로, 실시간 로그를 저장하여 필요한 내용을 검색
• 데이터를 분산해서 저장하는 샤딩 지원 -> 빠른 검색 가능

Elasticsearch 구성 요소

https://braineanear.medium.com/elasticsearch-architecture-v-node-roles-81ec3d04257e

• 마스터 노드: 클러스터 상태를 유지, 노드의 추가, 제거, 인덱스 관리 등 담당 (마스터, 마스터 후보)
• 데이터 노드: 실제 데이터를 저장하고 검색, CRUD 요청 처리 ( data_content, data_hot, data_warm, data_cold, data_frozen)
• 코디네이터 노드: 클러스터 전체의 검색 및 인덱싱 요청 라우팅, 데이터 노드로 요청을 분배. only 트래픽 조율 역할
• ingest node: 데이터 처리 파이프라인 관리, 데이터를 인덱싱하기 전 변환 및 전처리 작업 담당 (fluentd, logstash 등을 사용하면 사용할 일이 없음)

 

index architecture

https://github.com/exo-archives/exo-es-search?tab=readme-ov-file#es-architecture

 

• Index: 모든 데이터를 하나에 document 에서 사용하는데, document를 모아놓은 집합 (테이블과 유사)
• Sharding
   indexing 시에 node 내부에 논리적인 데이터 저장 공간을 만들고 데이터를 쭉 쓴다. -> 저장 공간을 논리적으로 나누므로 동시에 여러 개의 데이터를 분산해서 저장할 수 있음.
  스케일 아웃을 위해 index를 여러 shard로 쪼갠다.
• Replica
   shard에 대한 복제본을 생성.

 

Kibana

• Elasticsearch와 함께 작동되도록 설계된 시각화 플랫폼. (웹 응용 프로그램)
• Elasticsaerch index에 저장된 데이터를 검색하고 조회. 실시간 쿼리의 변경사항을 표시하는 대시보드가 존재하므로 Elasticsearch의 실시간 데이터 시각화가 용이하게 가능

기능

• Discover: 데이터를 확인하고 탐색하는 용도로 사용
• Visualize: 데이터를 그래프나 표, 지도 등 다양한 타입으로 보여줌
• Dashboard: 시각화 타입을 한 페이지에 모아볼 수 있음. 자동 새로고침 기능으로 실시간 모니터링 용이
• Canvas: 파워포인트처럼 인포그래픽 형태로 데이터를 보여줌. 
• Maps: 위치정보가 포함된 데이터를 지도에 올려 시각화 가능

 

Fluentd 통합 Common Architecture

Forwarder And Aggregator

 

가장 일반적으로 사용하는 구조로, kubernetes node / vm 등 데이터가 생성되는 edge에 가벼운 인스턴스 (fluentbit)를 배포한다.

forwarder에서는 최소한의 처리를 수행한 다음 forward protocol을 사용하여 더 무거운 Fluentd 인스턴스로 전송한다. aggregator 역할을 수행하는 fluentd에서는 다음 백엔드로 라우팅하기 전 더 많은 필터링과 처리를 수행한다.

 

• 장점
  • edge에서의 리소스 사용량 감소 (처리량 극대화)
  • aggregate layer에서 처리를 확장하기 용이
  • 백엔드와의 통합이 용이하다 (모든 forwarders에서 config를 수정하는 것보다 fluentd 하나에서 수정하는 것이 용이)
• 단점
  • aggreagor instacne에 따로 리소스가 필요 (비용 증가)

 

Sidecar/Agent deployment

Fluentd나 Fluent Bit를 edge에 배포하고, 데이터를 백엔드 서비스에 직접 보내도록 구성한다. 사용하는 백엔드가 하나만 있을 경우에 효과적이다.

Deamonset으로 배포하거나, 어플리케이션과 pod 내부에 배포할 수 있다. 

• 장점
  • aggregator 가 필요하지 않다. 
• 단점
  • agent 전체에서 구성을 변경하기 어려움
  • 백엔드를 추가하기 어려움

 

이외 다른 로그 수집 솔루션

1. Prometheus,  Grafana

Prometheus는 로그 대신 메트릭 데이터를 수집하고 모니터링하는 데 주로 사용되지만, 일부 로그 데이터를 지표 형태로 변환하여 처리할 수 있습니다.
Grafana는 주로 Prometheus와 연동되어 대시보드를 제공하며, 메트릭 데이터와 로그 데이터를 통합하여 모니터링할 수 있습니다.

 

2. Loki, Grafana (PLG 스택)

• Promtail, Loki, Grafana

 

Loki는 Grafana와 함께 사용되는 로그 수집 시스템으로, Prometheus와 유사하게 동작한다.

로그 데이터를 메트릭과 함께 저장하고 조회하는 데 최적화되어있고, 특히 Loki는 로그를 레이블 기반의 메타데이터만 인덱싱해서 인덱스에 사용되는 메모리가 적다.

* 참고: Logging in Kubernetes: EFK vs PLG Stack

 

 

3. AWS CloudWatch 및 GCP Logging

kubernetes 클러스터를 직접 운영하지 않고 EKS등을 사용한다면 아래와 같은 로깅 시스템 사용 가능하다.

• AWS CloudWatch: EKS 클러스터에서 직접 로그를 수집하고 시각화할 수 있는 AWS에서 제공하는 로그 모니터링 서비스
• Google Cloud Logging: GKE 클러스터에서 Google Cloud Logging을 사용해 로그를 수집하고 관리할 수 있다.

4. Splunk, Datadog

• Splunk: 고급 로그 분석 솔루션. 복잡한 로그 분석과 보안 모니터링을 제공하며 대규모 기업환경에서 많이 사용됨. (kuberenets 에서도 splunk 에이전트를 사용해 로그 수집 가능). 오픈소스가 아니라 비용은 높음
• Datadog: 모니터링과 로그 수집을 통합적으로 제공. Kubernetes와의 쉬운 통합. 로그 수집 뿐만 아니라 어플리케이션 모니터링, 인프라 모니터링을 함께 제공하는 전체적인 모니터링 솔루션 필요 시 사용 

 

 

 

 

참고

https://bravenamme.github.io/2021/01/28/elk-stack/

https://nangman14.tistory.com/68

https://aws.amazon.com/ko/blogs/containers/fluentd-considerations-and-actions-required-at-scale-in-amazon-eks/

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#master-node

https://braineanear.medium.com/elasticsearch-architecture-v-node-roles-81ec3d04257e

https://fluentbit.io/blog/2020/12/03/common-architecture-patterns-with-fluentd-and-fluent-bit/

https://www.infracloud.io/blogs/logging-in-kubernetes-efk-vs-plg-stack/