아직도 Logstash만 쓰는 그대를 위한 : Fluentd 알아보기

결론적으로 Fluentd는 Logstash와 같은 로그 수집기 (Log Aggregator / 집게, 처리, 라우팅) 기능을 합니다.

 

하지만 마냥 똑같진 않습니다. ㅎㅎ.. 일단 로그 수집기와 fluentd에 대해서 좀 더 알아볼까요?

MSA 구조와 클라우드 환경에서 일일이 log 파일을 뒤지며, find/grep을 통해서 수만줄이 되는 로그 중 원하는 로그를 찾기 어렵습니다. 이러한 상황에서 흩어진 로그 데이터를 모아 수집/가공/전송 해주는 것이 통합 로그 수집기입니다.

별도의 로그 수집기를 왜 사용해야 할까요? 일단 아래의 그림을 보겠습니다.

 

https://www.fluentd.org/architecture

위와 같이 현대의 서버 시스템은 매우 다양한 로그를 출력 합니다. 접근 로그, 앱 서버 로그, 시스템 로그 등.. 로그 시스템은 매우 복잡합니다. 이러한 로그들을 아래의 그림과 같이 fluentd로 통합 로깅 계층을 만들어 효율적으로 로그 데이터를 수집, 가공, 전송하기 위해서 사용하는 것입니다.

https://www.fluentd.org/architecture

궁극적으로 fluentd를 통해서 Access log, App log, System log, db log를 알림 시스템, 분석, 저장 하기 위한 것입니다.

이제 Fluentd에 대해서 간략히 알아보고, 아키텍처에 대해서 살펴보겠습니다.

 

1. Fluentd에 대해서

access log를 json 파싱

1. Json 포맷 기반 : 모든 데이터를 Json으로 변환해 처리합니다. 이러한 Json 형태를 통해 로그를 필터, 조합하기 쉽습니다.
   • Json 형식으로 데이터를 다루기에 NoSQL 데이터베이스 연동에도 이점을 가집니다.
2. Pluggable 아키텍처 : 수백 가지의 플러그인을 지원하며, 이러한 플러그인을 통해 원하는 데이터 소스, 저장소를 연결하기 쉽습니다. ex) AWS S3
   • fluentd 플러그인 목록 : https://www.fluentd.org/plugins
   • 플러그인을 통해서 로그 알림 시스템, 로그 백업 등 다양한 시스템을 구현하기 쉽습니다.
   • 아래에서 좀 더 자세히 다루어 보겠습니다.
3. 높은 신뢰성 : 메모리와 파일 기반으로 버퍼를 동작시키기 때문에 네트워크 장애가 발생해도 데이터 유실에 대해서 신뢰성을 가집니다.

 

2. Fluentd 아키텍처와 동작 원리

Fluentd의 동작 원리는 간단합니다.

데이터 라이프사이클

Fluentd 내부에서 데이터는 Tag, Time, Record 세 가지 요소로 구성된 이벤트로 처리됩니다.

 

1. Input(수집): 로그 파일(log tailing), HTTP 요청, TCP/UDP 등 다양한 소스에서 데이터를 받아들입니다.
2. Parser(변환) : 들어온 비정형 데이터(Text, RegEx 등)를 정형 데이터(JSON)로 변환합니다.
3. Filter(가공): 불필요한 필드를 삭제하거나, 새로운 필드(e.g. 호스트 이름, 커스텀 태그)를 추가하고, 민감 정보를 마스킹합니다.
4. Buffer(임시 저장): 출력하기 전 데이터를 임시로 모아둡니다(청크 단위, 청크 단위로 저장하여 안정적인 버퍼 활용이 가능합니다)
5. Output(전송): 버퍼에 모인 로그 데이터를 저장소, 메세지 큐(S3, Elasticsearch, Kafka 등)로 보냅니다.

 

https://www.fluentd.org/architecture

 

3. Fluentd vs. Logstash 차이점

 

 

여기까지만 보다보면 그냥 Logstash를 쓰면 되는거 아닌가? 싶을 수 있습니다. 하지만 같이 좀 더 살펴보죠!

 

저도 회사에서 사용하는 인프라를 공부하다 보니 ELK 스택(Elasticsearch, Logstash, Kibana)에서 Logstash 대신 fluentd를 사용하고 있었습니다. (HDFS, Miniio(S3) 전송도 하고 있었음), 따라서 자연스럽게 ELK와 호환성이 더 좋은 "Logstash 대신 왜 Fluentd를 써야 할까?" 라는 의문이 생겼습니다. 일단 제가 정리한 아래의 표를 살펴보겠습니다.

 

항목	Fluentd	Logstash
개발 언어	C/Ruby (CRuby)	JRuby (Java/JVM 기반)
메모리 사용량	~40MB	~120MB+ (JVM 오버헤드)
CPU/성능	더 가볍고 빠름	상대적으로 무거움

 

즉, 위 표에 따르면 좀 더 가볍고, 덜 복잡한 로그 수집기가 필요하다면 Fluentd가 대안이 될 수 있습니다.

 

각자의 장단점이 존재합니다. 특히 Fluentd는 Docker/Kubernetes 환경에서 리소스 효율이 Logstash보다 뛰어납니다. 왜냐하면 애초에 Fluentd는 CNCF(클라우드 네이티브 애플리케이션 구축 방법론)을 통해 클라우드 환경에서 사용되도록 애초에 만들어졌기 때문입니다. 그리고 Fluentbit(로그 수집기)와 같이 만들어져 하나의 클라우드 환경 로그 수집 생태계를 잘 구성하고 있습니다.

또한, Logstash는 Java 기반이면서 동시에 메모리 사용량이 높기 때문에 복잡한 파싱 시 JVM GC로 인한 지연이 발생할 수 있습니다.

데이터 유실에 대한 대응도 좀 다른데요. Logstash는 기본적으로 인-메모리 큐로 로그를 처리합니다. 디스크 기반 백업 기능이 있지만, 인-메모리 기반보다 성능이 좀더 떨어집니다. 그럼에도 불구하고, 디스크 기반 백업은 체크 포인트 단위로 이루어지기 때문에 완전한 백업이 불가능합니다. 이러한 단점을 극복하기 위해서 Kafka와 같은 MQ를 추가적으로 도입해야 한다고 합니다.

 

반면에 fluentd는 기본적으로 buffer file(디스크) 기반으로 기본적으로 메모리와 디스크를 조합한 버퍼를 제공해 MQ 없이도 안정적입니다.

 

이러한 차이점들이 있고, 추가적으로 로그를 처리하는 명령 방식도 다릅니다.

 

• Fluentd: 태그 기반 라우팅. 태그만 붙혀 자동 라우팅되므로 설정이 직관적이고 확장성 좋습니다. (아래에서 자세히)

• Logstash: if-else 조건 기반 라우팅. 복잡한 조건 로직에는 훨씬 강점이 있습니다. 아래의 조건문 예시처럼요.

if [field] == "value"

 

위와 같은 차이점이 있는데 결론적으로 두 로그 수집기의 차이는 아래와 같습니다.

 

1. 서버 리소스를 적게 사용하면서 컨테이너 환경(Docker/K8s)과 유연하게 연동하고 싶다면 Fluentd가 좋을 수 있다!
2. 이미 Java 기반 인프라가 구축되어 있고 복잡한 데이터 변환 로직이 필요하다면 Logstash가 좋을 수 있다!

 

4. 플러그인 종류 및 사용법

Fluentd의 가장 큰 장점 중 하나는 매우 큰 플러그인 생태계입니다. 설정 파일(fluent.conf)에서 지시어(Directive)를 사용하여 제어 할 수 있습니다.

4.1 Input Plugins

데이터를 어디서 가져올지 정의합니다.

• in_tail: 파일을 실시간으로 읽음 (가장 많이 사용)
• in_http: HTTP 요청으로 로그를 받음
• in_forward: 다른 Fluentd 노드로부터 TCP 패킷을 받음

4.2 Output Plugins

데이터를 어디로 보낼지 정의합니다. tag 패턴 매칭을 통해 라우팅합니다.

• out_stdout: 콘솔에 출력 (디버깅용)
• out_file: 파일로 저장
• out_elasticsearch: Elasticseach 로 전송
• out_s3: AWS S3 로 전송

4.3 Filter Plugins

데이터 전처리 파이프라인입니다.

• grep: 특정 패턴이 포함된 로그만 남기거나 제외.
• record_transformer: 로그에 필드를 추가하거나 수정 (예: IP 주소 추가).

이러한 플러그인 적용에 대해서는 각 플러그인 문서에 자세히 서술되어 있습니다.

 

5. Docker Compose 사용 및 설정 파일(fluent.conf) 예시

 

자 이제 어떻게 사용하는지 fluentd 간단한 예시로 살펴봅시다.

더욱 더 자세한 내용은 아래의 fluentd 공식 문서를 살펴보기를 권장드립니다. 매우 친절하고 자세히 적혀있어요!!

•  fluentd 공식문서 : https://docs.fluentd.org/

 

목표: "/var/log/access.log 파일을 읽어서, 에러(500) 로그만 필터링한 뒤 로컬 파일로 저장하기" 입니다.

 

우선 docker compose를 통해서 fluentd를 구성해보겠습니다.

 

fluentd 공식 도커 이미지 : https://hub.docker.com/r/fluent/fluentd/

 

1. docker-compose.yaml 작성

services:
  fluentd:
    image: fluent/fluentd:latest
    container_name: fluentd-demo
    volumes:
      - ./conf:/fluentd/etc # 설정 파일 위치
      - ./logs:/var/log/fluent # 결과 로그 저장 위치
      - /var/log/nginx:/var/log/source # 수집할 원본 로그 위치
    user: root # 권한 문제 방지용

2. fluent.conf 작성 (./conf/fluent.conf)

# 1. Input - access.log 파일을 읽음
<source>
  @type tail
  path /var/log/access.log
  pos_file /var/log/td-agent/access.log.pos
  tag nginx.access
  <parse>
    @type nginx # Nginx 로그 포맷 자동 파싱하도록 적용
  </parse>
</source>

# 2. Filter - Http 코드가 500인 것만 추출
<filter nginx.access>
  @type grep
  <regexp>
    key code
    pattern ^500$
  </regexp>
</filter>

# 3. Output - 로컬 파일로 저장 (일별로 Log Rotate)
<match nginx.access>
  @type file
  path /var/log/fluent/error_500.*.log
  append true
  <buffer>
    timekey 1d
    timekey_use_utc true
    timekey_wait 10m
  </buffer>
</match>

• Buffer 설정: 엄청나게 많은 로그가 유입될 때 buffer_chunk_limit와 flush_interval을 조절해야 OOM(Out of Memory) 에러를 예방 할 수 있습니다.
• Fluent Bit와 혼용 가능: 각 노드(Kubernetes는 Pod)에는 매우 가벼운 Fluentbit를 설치해 수집만 담당하게 하고, 중앙에 Log Aggregator 수집기로 Fluentd를 두는 구조가 효율적입니다.

 

3. 플러그인 설치가 필요할때

플러그인 설치가 필요하다면 (예시: 나는 ElasticSearch, S3 플러그인이 필요하다~)
아래와 같이 도커 파일을 통해서 직접 이미지를 빌드하는 것을 권장합니다.

# Dockerfile
FROM fluent/fluentd:latest
USER root

# 필요한 플러그인 설치 (예: ElasticSearch, S3)
RUN gem install fluent-plugin-elasticsearch
RUN gem install fluent-plugin-s3

USER fluent

# AWS S3로 전송할떄
<match nginx.access>
  @type s3 # 설치한 플러그인
  
  # 보통 플러그인 공식 문서에 나와있습니다.
  aws_key_id AWS키ID
  aws_sec_key AWS시크릿키
  s3_bucket 버킷이름
  s3_region 버킷리전
  
  path logs/nginx/
  
  <buffer>
    @type file
    path /var/log/fluent/s3_buffer
    timekey 1h
    timekey_wait 10m
    chunk_limit_size 256m
  </buffer>
</match>

 

직접 상황에 맞는 플러그인을 찾아 공식 문서를 보시고 적용하는 것을 권장드립니다!

 

---

6. 결론적으로..!!

Fluentd는 단순한 로그 수집기를 넘어 로그 데이터 허브 역할을 수행할 수 있습니다. 로그 데이터 저장뿐만 아니라, 필요한 데이터 형태로 필터, 파싱, 저장까지 가능한 것입니다.

1. 데이터 엔지니어링 관점에서는
   • 로그 데이터를 AWS S3, HDFS와 같은 스토리지로 장기 보관할 수 있습니다.
   • 이후 Spark, Hive, Presto 등을 이용해 비즈니스 인텔리전스(BI) 분석을 수행할 수 있는 기반 데이터 레이크(Data Lake)를 만들 수 있습니다.
2. 로그 모니터링 관점에서는
   • 실시간 로그를 Elasticsearch로 전송하고 Kibana로 시각화할 수 있습니다.
   • 이러한 ELK(Logstash 대체)처럼 시스템 장애를 실시간으로 탐지하고 알림(nagios 서버 플러그인)을 보낼 수 있습니다.

결론적으로 복잡한 시스템 환경에서 로그의 '수집'과 '활용'을 분리(Decoupling)가 필요하다면 Fluentd가 좋은 선택이 될 수 있습니다.

 

 

 

다음 글에서는 Fluentd보다 더 가볍게 동작하는 Fluent Bit와의 구체적인 차이점과, Kubernetes 환경에서 Sidecar 패턴으로 로깅을 구축하는 방법에 대해 다루겠습니다.

 

Reference

https://www.fluentd.org/architecture

What is Fluentd? | Fluentd

https://logz.io/blog/fluentd-vs-fluent-bit/

Fluentd vs. Fluent Bit: Side by Side Comparison | Logz.io

https://velog.io/@bbkyoo/Fluentd-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC

Fluentd 개념 정리

https://smoh.tistory.com/365

LogStash vs Fluentd - 어떤 것을 선택해야 할까