[DBGuide.net] 연재 글 – Apache Flume를 활용한 데이터 수집(1)
오랜 만에 글을 올리네요. 이번 글에서는, “데이터 수집 #1 오픈 소스 수집기 비교“에서 언급 했던 로그 수집을 위해 가장 많이 활용되고 있는 Apache Flume에 대해 설명하고자 한다. 
일반적으로 준비되어 있는 DataStore인 HDFS(Hadoop Distributed File System)에 데이터를 입력할 때 아래와 같은 명령으로 간단히 처리 가능하다. 
?
% hadoop fs -put user_pretty-timestamps1.dat /datastore/user_pretty-timestamps.dat
이런 경우는 아주 이쁘게 잘 준비되어 있는 데이터를 업로드할 때 유용할 것이다.
하지만 현실의 경우에는 이런 경우가 매우 드물다. 서비스의 로그가 계속 유입이 되고, 즉시 DataStore에 저장되어 분석 되어지길 원할 것이며, 또한, 데이터를 유실 없이, 다양한 옵션이 필요로 한다. 
Hadoop으로 데이터를 입력하기 위해 간단하고 유연하며 확장이 가능한 솔루션으로서 Apache Flume이 적당하다. 
Apache Flume은 2011년에 Cloudera CDH3에 처음으로 소개되었으며, 현재는 Apache의 Top-Level Project로 이전 CDH3에서의 Version인 0.9.x버전은 Flume-OG라 명명하고 1.0.0 이후의 버전부터 Flume-NG(Next Generation)이라 명명하며 현재 최신버전은 1.4.0이다.
OG와 NG 버전은 아키텍처 구조가 상이하나 여기서는 따로 비교 설명을 하지 않을 것이며, 여기서는 NG를 기준으로 설명을 시작하도록 한다. 

 Apache Flume의 Design Goal

  • Flume의 설계 원칙 또는 특징에 대해 간략히 줄여보면 아래와 같다.
    • Reliability(신뢰성) : 장애가 나더라도 로그,이벤트를 유실없이 전송함을 보장하게 설계됨
    • Scalability(확장성) : 수평확장(Scale-Out)이 가능하여 분산수집이 가능한 구조로 설계됨
  • Apache Flume is a distributed, reliable, and available system for efficiently collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store. (http://flume.apache.org/FlumeUserGuide.html )
  • 정리하자면, Apache Flume을 활용하면 신뢰성, 확장성, 관리성, 커스트마이징 가능하면서 고성능을 기대할 수 있다. 또한, 동적 구성, Contextual Routing 가능하게 사용하면서 로그를 안정적으로 수집이 가능하다.

Apache Flume Core Concepts

Flume에서는 크게 Event와 Agent에 대한 개념을 이해하면 된다. Agent는 또한 Source, Channel, Sink로 구성되어져 있다.

Event

apache_flume_event
  • Flume을 통해 전달되어지는 데이터의 기본 payload를 event라 부른다.
  • Event는 0이상의 Header와 body영역으로 나뉜다. (Byte payload + set of string headers)
  • Header는 key/value 형태이며, 라우팅을 결정하거나, 구조화된 정보(예를 들어, 이벤트가 발생된 서버의 호스트명, timestamp 등 추가 가능)를 운반할 때 활용된다.

Agent

apache_flume_agent
  • 이벤트를 전달하는 컨테이너로서 Source, Channel, Sink로 흐름을 제어 하며, Agent간 Event 이동이 가능하며, 1개의 Agent가 다수의 Agent로 연결도 가능하다.
  • Source
    • 이벤트를 수집하여 채널로 전달, Interceptor, Channel Selector를 통해 수집된 데이터를 변경하거나 Channel을 지정할 수 있는 기능도 제공된다.
  • Channel
    • 이벤트를 Source와 Sink로 전달하는 통로로서 3가지 타입이 존재한다.
  • Sink
    • Channel로 부터 받은 이벤트를 저장, 전달한다. Sink Processor를 통해 Sink할 대상을 다중 선택하거나 여러개의 Sink를 하나의 그룹으로 관리하여 Failover에 대응할 수 있다.

Apache Flume Agent Details

Source

  • avro : Avro 클라이언트에서 전송하는 이벤트를 입력으로 사용, Agent와 Agent를 연결해줄 때 유용
  • netcat : TCP로 라인 단위 수집
  • seq : 0부터 1씩 증가하는 EVENT 생성
  • exec : System Command를 수행하고 출력 내용을 수집
  • syslogtcp : System 로그를 입력으로 사용
  • spooldir : Spooling Directory 디렉토리에 새롭게 추가되는 파일을 데이터로 사용
  • thirft : Thrift 클라이언트에서 전송하는 이벤트를 입력으로 사용
  • jms : JMS 메시지 수집

Channel

  • memory : Source에서 받은 이벤트를 Memory에 가지고 있는 구조로, 간편하고 빠른 고성능(High Throughput)을 제공하지만 이벤트 유실 가능성이 있다. 즉, 프로세스가 비정상적으로 죽을 경우 데이터가 유실될 수 있다.
  • jdbc : JDBC로 저장
  • file : JDBC와 마찬가지로 속도는 Memory기반에 비해 느리지만, 프로세스가 비정상적으로 죽더라도 transactional하게 프로세스를 재시작하여 재처리하여 이벤트 유실이 없는 것이 장점이 있다.

Sink

  • null : 이벤트를 버림
  • logger : 테스트 또는 디버깅을 위한 로깅
  • avro : 다른 Avro 서버(Avro Source)로 이벤트 전달
  • hdfs : HDFS에 저장
  • hbase : HBase에 저장
  • elasticsearch : 이벤트를 변환해서 ElasticSearch에 저장
  • file_roll : 로컬 파일에 저장
  • thrift : 다른 Thrift 서버(Thrift Source)로 이벤트 전달

위 Source, Channel, Sink는 위 종류 외에도 다양하게 Customize하여 추가 구성이 가능하다.
이상이 간략하게 Apache Flume에 대해 소개를 마치며, 바로 이어지는 글에서 Flume을 적용한 간단 예제와 모니터링 방법에 대해 작성할 예정이다. 

Reference



[DBGuide.net] 연재 글