[DevOps] fluentd와 fluentbit의 차이점

 

 

  지난 시간에는 [Elasticsearch] EFK(Elasticsearch, Fluentd, kibana)란 에 대해서 알아보면서 fluentd에서 HA 구성을 뺀 더 적은 메모리를 사용하는 경량버전인 Fluent-Bit이라고 정의하며 간략하게 마무리 하였다. 그 이후 구체적으로 minikube 환경에서 EFK를 구현하면서 fluentd와 fluentbit의 차이점에 대해서 더욱 궁금하게 되었다. 백엔드 개발자의 입장에서 이미 정제된 데이터를 예쁜 대시보드를 통해 시각화 해주는  Kibana보다, 그 이면에서 실제로 데이터를 수집하기 위한 무거운 작업을 수행하는 Fluentd와 FluentBit에 대해 더 궁금하였다. 그래서 구체적으로 Fluentd와 Fluent Bit의 차이에 대해서 정리하게 되었다.

 

 

Fluentd는 무엇인가?

The most common technologies running in Docker(https://www.datadoghq.com/docker-adoption/#6)

  Fluentd는 사실, EFK(Elasticsearch, Fluentd, Kibana)의 대명사이다.  Datadog 의 자료에 따르면 Fluentd는 4번째로 많이 사용되는 Docker 이미지이다.  Fluentd는  Treasure Data 의 사람들이 2011년에 만든 오픈 소스 로그 수집기, 프로세서이다. Ruby로 작성된 Fluentd는 여러 소스의 데이터를 집계하고, 다른 형식의 데이터를 JSON 개체로 통합하고, 이를 다른 출력 대상으로 라우팅할 수 있는 원스톱 구성 요소인 통합 로깅 계층으로 작동하도록 만들어졌다.

  성능, 확장성 및 안정성은 Fluentd의 뛰어난 기능 중 일부이다. vanilla Fluentd 배포는 ~40MB의 메모리에서 실행되며 초당 10,000개 이상의 이벤트를 처리할 수 있다. 새 입력 또는 출력을 추가하는 것은 비교적 간단하며 성능에 거의 영향을 미치지 않는다. Fluentd는 버퍼링 및 큐잉을 위해 디스크 또는 메모리를 사용하여 전송 실패 또는 데이터 과부하를 처리하고 보다 탄력적인 데이터 파이프라인을 보장하기 위해 여러 구성 옵션을 지원한다.

 

 

Fluentd, Kubernetes & Docker

  Fluentd는 얼마 동안 사용되어 왔으며 기능을 확장하는 1000개 이상의 다양한 플러그인으로 구성된 풍부한 생태계를 개발했다. Fluentd는 Kubernetes에 로깅하는데 사용되는 가장 널리 사용되는 Docker 이미지 중 하나이다.

 Fluentd Docker 이미지에는 ARM 기본 이미지, 빌드 및 테스트 용 태그 debian가 포함되어 있다. Kubernetes는 데몬셋을 활용하여 Fluentd를 실행하고 있다. 아래는 fluentd의 설치 정보이다.

$ git clone https://github.com/fluent/fluentd-kubernetes-daemonset

 

 

Fluent Bit란 무엇인가?

  Fluent Bit는 비교적 새로운 업체이지만 특히 Docker 및 Kubernetes 환경에서 인기가 높아지고 있다.

Fluent Bit는  Treasure Data의 사람들이 2015년에 만든 오픈 소스 로그 수집기이자 프로세서이다. C로 작성된 Fluent Bit는 제한된 capacity와 감소된 overhead(메모리 및 CPU)가 있는 고도로 분산된 환경을 염두에 두고 만들어졌다. 

 이러한 목적을 달성하기 위해 Fluent Bit는 고성능을 위해 설계되었으며 ~450KB에서만 실행된다. 추상화된 I/O 처리기는 비동기 및 event-driven read/write 작업을 지원한다. 복원력과 안정성을 위해 다양한 구성 옵션을 사용하여 재시도 및 버퍼 제한을 정의할 수 있다.

 

 

Fluent Bit, Kubernetes & Docker

Fluent Bit도 확장 가능하지만 Fluentd에 비해 생태계가 작다. 입력 에는 syslog, tcp, systemd/journald뿐 아니라 CPU, 메모리 및 디스크도 포함된다. 출력 에는 Elasticsearch, InfluxDB, 파일 및 http가 포함된다. Kubernetes 배포의 경우 전용 필터 플러그인은 Pod 이름 및 네임스페이스, 컨테이너 이름/ID와 같은 메타데이터를 로그 데이터에 추가한다.

Kubernetes Fluent Bit 필터에는 Kubernetes 포드의 이름 및 ID, 네임스페이스, 컨테이너 이름 및 ID, annotations 및 레이블과 같은 메타데이터가 포함된다. 후자의 2개와 Pod ID는 Kubernetes API 서버를 쿼리하여 찾을 수 있다.

 

 

Fluentd와 Fluent Bit 비교

  Fluentd와 Fluent Bit는 모두 사용자가 중앙 집중식의 안정적이고 효율적인 로깅 파이프라인을 구축할 수 있도록 Treasure Data에서 개발했다. Fluentd와 이후 Fluent Bit의 비전은 비정형 데이터 형식 지정, 여러 데이터 소스의 집계, 복원력 및 보안과 같은 프로덕션 환경 로깅과 관련된 몇 가지 문제를 극복하는 데 도움을 주는 것이었다.

두 도구 간에 아키텍처 및 디자인 유사점이 있지만 둘 사이를 선택할 때 고려해야 하는 몇 가지 핵심적인 차이점도 있다.

 

• Apache License v2.0의 조건에 따라 사용이 허가됨
• CNCF(Cloud Native Computing Foundation 에서 호스팅하는 프로젝트
• 프로덕션 등급 솔루션: 매일 수천 번, 매월 수백만 번 배포 돈다 .
• 커뮤니티 주도 프로젝트
• 업계에서 널리 채택: AWS, Microsoft, Google Cloud 및 기타 수백 개와 같은 모든 주요 회사에서 신뢰한다.
• 원래 Treasure Data 에서 만들었다 .

 

다음은 두 도구의 차이점을 요약한 표이다.

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

 

 

성능

  차이점을 측정하려면 Kubernetes에서 둘을 실행하는 데 권장되는 기본 yaml을 살펴볼 수 있다. Fluent Bit는 Fluentd보다 작은 설치 공간을 사용하고 있다. 

 

 

Fluentd:

resources:  
  limits:
    memory: 500Mi  
  requests:
    cpu: 100m
    memory: 200Mi

 

Fluent Bit :

resources:  
  limits:
    cpu: 50m
    memory: 60Mi  
  requests:
    cpu: 5m
    memory: 10Mi

 

 

 

집합

Fluent Bit는 수집기 및 전달자 역할을 하며 위에서 설명한 대로 성능을 염두에 두고 설계되었다. Fluentd는 여러 입력에서 집계, 데이터 처리 및 다른 출력으로의 라우팅과 같은 많은 처리량을 처리하도록 설계되었다. Fluent Bit는 Fluentd만큼 훨씬 더 많은 양의 입력 및 출력 소스와 통합될 수 있는 플러그(pluggable)와 유연성(flexible) 많지 않다.

 

   

Monitoring

Fluent Bit는 배포된 환경에서 메트릭 수집을 기본적으로 지원한다. CPU 및 디스크와 같은 다양한 입력 플러그인은 CPU 및 메모리 사용량에 대한 데이터를 수집하고 선택한 출력으로 전달한다. 버전 0.13은 또한 Prometheus 메트릭에 대한 지원도 함께 제공된다. Fluentd는 이 기능과 함께 제공되지 않는다.

 

 

Ecosystem

 Fluentd와 Fluent Bit는 모두 설계상 플러그가 가능하며 다양한 입력, 필터 및 출력 플러그인을 사용할 수 있지만

 Fluentd(최대 1000개 플러그인 포함)는 자연스럽게 Fluent Bit(최대 70개 플러그인 포함)보다 더 많은 플러그인을 가지고 있어 로깅 파이프라인 및 오래된 도구가 되는 것이다. 

  Fluentd의 역사는 Fluentd Docker driver 와 Kubernetes Metadata Filter가 Dockerized 및 Kubernetes 환경에서 채택을 주도하면서 채택 및 대규모 에코시스템에 기여했다.

 

 

 

그렇다면 Fluentd 또는 Fluent Bit는 언제 사용해야하나?

  어떤 면에서 Fluent Bit는 분산 아키텍처의 edge hosts 또는 device에 에이전트로 설치하여 Fluentd에 전달하는 경량 로그수집기이다.

예를 들어 Kubernetes에서 Fluent Bit는 노드별로 데몬셋으로 배포되어 클러스터별로 배포된 Fluentd 인스턴스에 데이터를 수집 및 전달하고 집계자 역할을 하여 데이터를 처리하고 태그를 기반으로 다른 소스로 라우팅한다.

  Fluent Bit가 장치별로 설치되어 Fluentd 인스턴스로 데이터를 전송하는 IoT 아키텍처도 마찬가지다. Fluent Bit는 물론 자체적으로 사용할 수 있지만 집계 기능과 다른 솔루션과의 통합을 위한 훨씬 적은 양의 플러그인 측면에서 제공할 수 있는 것이 훨씬 적다.

 

 

요약하자면

  따라서 Fluentd와 Fluent Bit의 차이점은 로그 전달자와 로그 수집기의 차이로 간단히 요약할 수 있다. 전자는 로컬 이벤트를 수신하기 위해 에지 호스트에 설치한다. 이벤트가 수신되면 로그 수집기로 전달한다. 후자는 로그 전달자로부터 이벤트 스트림을 수신하고 버퍼링하고 주기적으로 데이터를 일종의 데이터 저장소에 업로드하는 데몬이다.

  Fluentd와 Fluent Bit의 조합은 서로를 보완하는 방식 때문에 Kubernetes 배포에서 매우 인기를 얻고 있다. Fluent Bit는 클러스터의 여러 노드에서 데이터를 수집하고 집계, 처리 및 처리를 위해 데이터를 Fluentd로 전달하는 경량 운송업체 역할을 한다. 지원되는 출력 대상으로 라우팅한다. Kubernetes가 보급될 수록 Fluent Bit을 더 많이 사용하게 될 것이다.

 

 

ㅁ 함께 보면 좋은 사이트 

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

GitHub - fluent/fluent-bit: Fast and Lightweight Logs and Metrics processor for Linux, BSD, OSX and Windows

GitHub - fluent/fluentd: Fluentd: Unified Logging Layer (project under CNCF)

 

Fluentd & Fluent Bit - Fluent Bit: Official Manual