Unique Life

출처: http://www.devblog.kr/r/8y0gFPAvJ2e9YusO2zkCjl9yRvrgsWxq08MkPeBRH0PF8XOX51Oh1RP9ZBacWBDcSz8C55JnqHSwB249T13HZ9j

위에서 언급한 수집기 오픈 소스중 3가지 Flume, Scribe, Chukwa를 간단 비교요약하면 아래와 같다.

	Apache Flume	Facebook Scribe	Apache Chukwa
Overview	대용량의 로그 데이터를 분산,안정성,가용성을 바탕으로 효율적으로 수집,집계,이동이 가능한 로그수집 솔루션	Facebook이 개발하여 오픈소스화한 로그수집서버. 대량의 서버로 부터 실시간으로 스트리밍 로그 수집을 위한 솔루션	Apache Hadoop의 서브 프로젝트로 분산되어 있는 서버에서 로그 데이터를 수집, 저장, 분석하기 위한 솔루션
Home	http://flume.apache.org/	https://github.com/facebook/scribe	http://chukwa.apache.org/
Last Version	1.4.0 (2013.7.2)	2.2(2010)	0.5.0 (2012.1.26)
Status	Cloudera -> Apache Top-Level Project	Facebook -> Open Source	Yahoo -> Apache Incubator project
WIKI	https://cwiki.apache.org/confluence/display/FLUME/Home	https://github.com/facebook/scribe/wiki	http://wiki.apache.org/hadoop/Chukwa/
Document	풍부	빈약	풍부
Implementation	Java	C++	Java
Community	활발	활발	보통
Summary	다양한 소스로 부터 데이터를 수집하여 다양한 방식으로 데이터를 전송이 가능하지만, 아키텍처가 단순하고 유연하며 확장 가능한 데이터 모델을 제공하여, 실시간 분석 애플리케이션을 쉽게 개발할 수 있다. 최근 국내의 빅데이터 솔루션에서 수집부분의 기반이 되는 솔루션. 각종 Source,Sink등 제공으로 쉽게 확장 가능	Facebook의 자체 Scaling 작업을 위해 설계되어 현재 매일 수백 억건의 메시지를 처리하고 있다. 클라이언트 서버의 타입에 상관없이 다양한 방식으로 로그를 읽어 들일수 있다. 단, Apache Thrift는 필수. Thrift 기반 Scribe API를 활용하여 확장 가능	수집된 로그 파일을 HDFS에 저장한다. HDFS의 장점을 그대로 수용하고 실시간 분석도 가능하다. 반면에 Hadoop에 너무 의존적이라는 단점도 있다.
Outline

Flume은 Log aggregator 즉 로그 수집기입니다. 수많은 서버에 분산되어 있는 많은 양의 로그 데이터를 flume을 통해서 한 곳(기본적으로는 HDFS)으로 모을 수 있도록 해줍니다.

Flume의 아키텍처
다음 그림처럼 Flume은 3 계층으로 구성되어 있습니다. 에이전트 계층, 컬렉터 계층, 스토리지 계층 3가지입니다.

에이전트 계층에서 각 에이전트 노드는 수집할 로그데이터가 생성되는 머신에 설치하는 것이 일반적입니다. 머신이 여러개 일 경우 각 머신마다 에이전트 노드를 설치하고 이 에이전트 노드가 에이전트 계층을 형성합니다. 에이전트노드에서 수집한 데이터는 컬렉터노드로 전송이 됩니다. 컬렉터노드는 보통 다른 머신에 있으며 당연히 여러 컬렉터노드로 구성할 수 있습니다. 에이전트 노드에서 컬렉터노드로 데이터를 전송할 때는 어떤 데이터를 어디로 보내고 어떻게 처리할 것인지 등에 대한 데이터흐름(data flow)를 설정할 수 있고 이 설정대로 데이터를 이동시켜 스토리지 계층에 저장합니다.

이 데이터흐름의 설정을 담당하는 것이 마스터노드입니다. 마스터는 각 논리적 노드를 런타임에서 설정할 수 있습니다.(이 부분이 플럼의 가장 큰 장점이라고 생각합니다.) 각 노드를 실행해 놓은 상태에서 마스터 노드를 통해서 자유롭게 설정을 변경할 수 있습니다. 즉 이는 어디서 로그데이터를 가져오고 어떻게 처리하고 어디에 저장할 것인지를 동적으로 계속 변경할 수 있습니다.

노드는 물리적 노드와 논리적 노드로 구분할 수 있습니다. 물리적 노드는 머신의 한 JVM위에서 동작하는 하나의 자바 프로세스입니다. 물리적 노드도 논리적 노드와 동일하게 동작하지만 물리적 노드위에는 다수의 논리적 노드를 생성할 수 있습니다. 그래서 필요한 용도에 따라 여러가지 논리적 노드를 생성해서 데이터 흐름을 구성할 수 있습니다. 각 논리적 노드(에이전트와 컬렉터 모두 포함)은 상당히 유연한 추상화입니다. 모든 논리적 노드는 2가지 컴포넌트를 가지고 있는데 이벤트를 생산하는 source와 이벤트를 소비하는 sink입니다. source는 어디서 데이터를 수집하는 지를 지정하고 sink는 어디로 데이터를 보내야 하는지를 지정합니다.(추가적으로 source와 sink에는 decorator를 설정해서 데이터를 전달하는 중에 어떤 처리를 할 수 있습니다.) 컬렉터와 에이전트는 사실 동일한 노드 소프트웨어에서 동작합니다. 즉, 동일한 노드이지만 설정이 다를 뿐입니다.



Flume의 신뢰도와 확장성
Flume은 신뢰할 수 있는 데이터 전송을 위해서 3가지 수준의 신뢰도를 지원합니다.

• end-to-end 신뢰도는 flume이 이벤트를 받으면 최종지점까지 보장한다는 의미입니다.
  
• store on failure 신뢰도는 데이터를 보내다가 실패했을 때 로컬디스크에 저장했을 때 다시 보낼수 있게 되거나 다른 컬렉터를 선택할 때까지 기다린 후에 다시 보냅니다.
  
• best-effort 신뢰도는 처리중인 데이터가 실패했을 때 잃어버릴 수도 있다는 의미입니다. 이는 가장 약한 신뢰도이지만 가장 경량입니다.

Flume은 수평적 확장을 지원합니다. 이는 시스템에 추가적인 머신을 추가함으로써 전체 쓰루풋을 향상시킬수 있다는 의미입니다. 각 계층별로 부하량에 따라 노드를 추가해서 전체적인 성능을 향상시킬 수 있습니다.