얼마전 까지 로그를 수집하고 분석할 때 ELK Stack을 사용했다. 이중 L 은 LogStash를 의미했고, 다방면에서 로그를 수집할 때 매우 유용하게 사용해왔다. 개인적으로 AWS Aurora Slow-query 를 수집하고 분석할 때도 Fluentd를 사용하고 있다. LogStash 나 Fluentd 둘 다 중앙 집중식으로 로그 데이터를 수집하고, 처리 및 전송을 하는 점이 유사하지만 적잖은 차이가 있다. GitHub 기준으로 LogStash 가 아직까지 Fluentd 보다 더 많은 호응을 얻고 있지만, 그 차이는 근소한 편이다. 아니 그 차이가 상당히 좁혀졌다.
상당히 일반적인 형태의 수집 구조
- https://github.com/elastic/logstash : 10,234 Stars
- https://github.com/fluent/fluentd : 7,948 Stars
Fluentd는 Slask 을 통해 정기적으로 새로운 소식을 공유하고 있으며, Google Group을 통해 토론을 나누는 편이다.
- http://slack.fluentd.org/ (Fluentd Slack Channel)
- http://groups.google.com/group/fluentd (Fluentd Google Groups)
반면 LogStash 는 IRC 채널을 통해 소식을 전달하고, Elastic.co 에서 의견을 나눈다.
기업에서의 선택
LogStash는 보편화된 ELK Stack의 일부라 ElasticSearch를 사용하는 경우 여전히 LogStash를 선호하는 경향이 있다. 물론 Fluentd 도 Elastic에 대한 지원을 하고 있지만, Elastic 의 변화에 대해 LogStash는 더 빨리 대응되는 편이다. 하지만 안타깝게도 엔터프라이즈급 지원을 제공하고 있지 않기 때문에 유료 솔루션이나, 대기업에서 LogStash를 강요하는건 쉽지 않다. 반면 Fluentd는 CNCF Stack이며, Kubernetes나 OpenTracing을 사용하는 경우 반드시 선택 되어야 하고, 유료로 엔터프라이즈 급 지원을 제공하고 있다.
Java 에 대해 불평불만이 많더라도, 대기업에서 Java 를 선호하는 이유는 엔터프라이즈급 지원이 가능하기 때문이라는걸 감안하고 생각하자.
플랫폼과 활용
LogStash 와 Fluentd 모두 Windows 와 Linux 등 Ruby 가 돌아가는 환경에서 모두 동작한다. 명확하게 말하자면, LogStash는 JRuby(Java 필요) 이며, Fluentd 는 CRuby 기반이다. 결합된 형태로 주로 동작하기 때문에 해당 플랫폼을 위한 플러그인이 지원하는지 여부를 먼저 확인할 필요가 있다.
아무래도 LogStash가 역사와 전통이 오래되다 보니, 공식 플러그인이 250개가 넘어 30여개의 Fluentd 보다 8배 넘게 많은 편. 플러그인은 결국 활용성과 연결된다. 물론 업무에 꼭 필요한 플러그인은 Fluentd 도 이미 대부분 있고, 비공식 Repo 에서는 수백개의 플러그인이 존재하므로 특이한(?) 개발을 하지 않는다면 큰 걱정될 만한 요소가 없다.
LogStash는 20개의 Fixed-Size Event를 제한된 On-Memory queue에 담기 때문에, 재시작시 지속성을 위해 External queue의 의존도를 높힌다. 이는 LogStash의 잘 알려진 문제로 Redis나 Kafka를 버퍼로 사용함으로서 문제를 해결할 수 있다. 단점에 대한 해결-접근성은 좋은편이지만, 안정성을 위해 독립적으로 동작시키기 어렵다는건 분명한 단점이다. Fluentd는 in-memory 또는 디스크를 활용함할 수 있는 고도화된 버퍼링 시스템을 지원한다. 물론, 매개변수를 별도로 구성해야 한다는 단점이 있지만, 2개의 미들웨어를 이해해야하는 LogStash 보단 낫다.
성능은 … 결국 대동소이하다. LogStash 와 Fluentd 의 처리능력을 논할 때 어느한쪽이 우월하다 생각해본 적도 없고 결과를 얻은적도 없었다. 과거 LG 에서 근무 할 때 PoC에서는 Fluentd 가 근소하게 앞섰지만, 내세울 정도의 성능은 아니었다. 주의해야 하 것은 수집하는 코어는 로그를 생성하는 서버에 설치하지 말 것. 이때는 Elastic Beats와 Fluent Bit 으로 대신하자.
개인적으로는 Log 를 남기는 대상의 성능이 Full-Performance를 내는 경우가 없어… 그냥 함께 설치해서 사용했었으니. 리소스 관리가 잘된다면 한대에 설치해도 큰 문제가 없다. 컴퓨팅 파워가 그만큼 강력해 졌기 때문.
모니터링 및 최적화
LogStash 와 Fluentd 모두 모니터링을 위한 일반적인 로그와 성능 향상을 위한 고급진 로그를 남길 수 있다. 두 제품 모두 하트-비트에 대해 응답하기 때문에 동작 여부를 확인할 수 있고, Zabbix 와 같은 도구와 결합하면 효과적인 모니터링이 가능하다.
LogStash는 다양한 필터 매트릭을 제공해 특정 처리 현황을 추적할 수 있다. 추적된 데이터는 Graphite와 같은 도구로 보내지고, Grafana를 사용해 시각화 할 수 있다. Grafana는 RESTFul API 를 제공함으로서, 매우 자세한 자원 현황 모니터링이 가능하다. 즉, LogStash 는 독립적인 모니터링 환경을 구축하기 쉽지 않다.
Fluentd는 처리 흐름 내 상태를 모니터링할 수 있는 쿼리를 제공한다. 이 모니터링은 에이전트를 통해 처리되며, 여러가지 모니터링 플러그인으로 확인할 수 있다.
두 수집기 모두 Routing을 지원하지만 접근 방식에 대한 차이가 있다. LogStash는 모든 데이터를 단일 스트림으로 Routing 하고, 알고리즘이 반영된 if-then 을 사용해 특정한 목적지로 데이터를 운반한다. Fluentd는 Tag를 사용해 Event를 Routing한다. 즉, 별도의 알고리즘이 없이 Tag를 따라 데이터를 운반하게 된다.
LogStash의 접근 방식은 Fluentd 보다 명확한 절차와 선언으로 접근하기때문에 Tag로서 제어할 수 없는경우 좀더 효과적인 응용이 가능하다. 물론, 경우에 따라 다르기 때문에 예제를 확인해 보고 적합한 것을 선택하자.
- https://www.elastic.co/guide/en/logstash/current/config-examples.html
- https://docs.fluentd.org/configuration/config-file
LogStash 는 ElasticSearch 와 너무 가까이 있다보니, ‘이정도면 충분한데’ 라는 느끼이 적잖다. 반면 Fluentd 는 ‘이거 혼자만으로도 가능한데?’ 가 조금 강하다. 모든 경우에 환경을 갖추고 진행하는게 아니다보니, Fluentd 로의 이동은 너무 자연스러운것 일지도 ..