이기종간 로그 수집(Log aggregator) 및 실시간 분석 아키텍쳐(1/3) - Scribe

제목을 너무 거창하게 잡은 것 같다.

현재 프로젝트에 많은 수십개의 이기종 서버가 연동되고 있다. 사용하는 언어도 제각각이다. 문제는 모든 서버의 에러를 실시간으로 인지하고 조치를 취해야 하는 것이다. 

제일 메인이 되는 서버가 자바를 사용하고 있어 자바로 된 오픈 소스를 검색하고 있지만, 전부 기능과 역할, 플러그인 지원등 모두 틀려서 쉽게 선택할 수 없다. 그래서 각각의 프로그램의 장/단점 및 특징을 비교, 분석을 해야 할 것 같다.

Scribe

scribe는 Facebook에서 제작하고 사용하던 log aggregator system이다.

http://www.cnblogs.com/brucewoo/archive/2011/12/13/2285482.html

다른 로그 수집 시스템들을 보면 알겠지만, Scribe는 다른 시스템보다 간단한 구조로 되어 있다.

Scribe는 일종의 message queue와 message queue에 쌓인 message를 DB에 저장해 주거나, DB가 실패하였으면 local에 저장하였다가 DB가 복구되었을 때 다시 DB에 저장해 주는 것만을 책임진다. 다시 말하면, message queue에 실제로 메시지를 보내는 부분은 사용자가 직접 작성하여야 한다는 것이다.

흔히들 말하는 scribe의 장점은 C++로 만든 만큼 다른 시스템들의 3~5배 정도의 성능을 보여준다는 것이다. 

하지만 실제 scribe 사용자들은 무엇보다도 Facebook이 실제로 사용하였던 솔루션인 만큼 성능과 안정성에서 

신뢰도가 있다는 것을 장점으로 뽑는다.

하지만 나는 scribe를 사용하는 것을 추천하지는 않는다.

일단 가장 큰 문제는 더이상 Facebook이 Scribe를 사용하지 않는다는 것이다. 

Facebook은 이미 Java로 작성한 Calligraphus를 사용하기 시작했다. scribe는 open source이고 개발이 완전히 멈춘 것은 아니다. 하지만 Facebook이 중심적으로 만들던 시절에 비하면 거의 발전이 없는 상태라고 해도 될 정도이다.

앞에서 말했듯이 Scribe는 message를 보내는 부분을 완전히 새롭게 작성해야 한다. 또한, 바이너리 배포를 안하기 때문에 사용하려면 Scribe 자체도 빌드하여야 하는데 Scribe 자체가 여러 라이브러리에 의존성이 걸려있기 때문에 빌드하는 것도 쉽지 않다.

남은 장점은 성능밖에 없는 관계로 일단 다른 솔루션을 사용해보고, 그것으로 감당이 되지 않을 정도로 많은 부하가 걸리는 게 아니라면 굳이 Scribe를 사용할 이유는 없어 보인다.

* 참고 라이브러리 의존성

Requirements
============
[libevent] Event Notification library
[boost] Boost C++ library (version 1.36 or later)
[thrift] Thrift framework
[fb303] Facebook Bassline (included in thrift/contrib/fb303/)
fb303 r697294 or later is required.
[hadoop] optional. version 0.19.1 or higher (http://hadoop.apache.org)

[출처]

http://blog.seulgi.kim/2014/04/log-aggregator-scribe-flume-fluentd.html

https://m.blog.naver.com/joycestudy/100112230801