Apache Flume 기본 개념 정리

Apache Flume (아파치 플룸) 기본 개념 정리

---

오늘 소개 할 Apache Flume(이하 플룸)은 클라우데라에서 처음 개발 돼, 아파치 소프트웨어 재단으로 이관 됐다. 로그데이터를 깔끔하게 수집하는 데 이만한 게 없으며, 많은 기업들에서 실제 서비스 로그데이터 관리를 위해 사용하고 있다. 전체적인 구조를 간단하게 보자면 다음과 같다.

 

내가 이해한 구조는 위 그림과 같은데 (직접 그림), 서비스 서버에서 수집되는 로그를 Flume Agent가 Flume Collector가 있는 host로 보내는 것이다. Collector에 설정값을 통해 Sink를 정해주는데, sink란 수집 된 로그데이터를 저장해놓을 데이터베이스를 값으로 갖는다. sink는 위에 그려놓은 HDFS, Kafka 이외에도 열 가지가 넘는다. Multiplexing 구조로 플룸을 구동시키면 동시에 여러개의 싱크로 로그를 전달 할 수도 있다. 참고로, 그림에는 안 나와있지만 Spooling Directory라는 개념이 있다. Spooling Directory란 로그데이터가 적재되는 디렉토리를 말한다. 일반적으로 Agent Node의 어딘가에 존재한다.

 

 

가볍게 들어가기 (작명 센스)

복잡한 설명 전에 플룸이라는 이름이 지어진 유래에 대해 가볍게 이야기해보자. 로그데이터 수집하는 오픈소스 중 이보다 더 작명을 잘 할 수 없을 것 같으니 말이다.

 

놀이동산에 가면 줄이 그렇게 길지도 짧지도 않으면서도 재밌어서 꼭 타게 되는 기구가 있다. (a.k.a 롯데월드) 가심비 좋은 그 놀이기구는 바로 후룸라이드다. 후룸라이드 (= Flume Ride). 플룸은 사실 통나무를 운반하는 수로를 의미하는 영단어다. 통나무는 영어로 Log.. 통나무를 운반하는 수로, Log 데이터를 저장소로 운반해주는 오픈소스, 그것이 바로 Flume인 것이다. 너무나도 찰떡같은 이름이어서 무릎을 탁 칠 수 밖에 없었다.

 

 

Left: 후룸라이드, Right: 통나무 수로

 

 

주요 개념

자, 이렇게 재밌는 오픈소스를 좀 더 자세히 들여다보자. 플룸의 시작점이라고 할 수 있는 Flume Agent를 자세히 들여다보면 다음과 같이 생겼다.

 

출처: https://flume.apache.org/

Web Server는 로그가 발생하는 서버일 테고, Source, Channel, Sink라는 것들이 눈에 띈다.

• Source
  • 데이터가 발생하는 소스로부터 (로그)데이터 수집 담당
  • Channel에 이벤트 입력
• Channel
  • Source와 Sink 사이의 Queue
  • Source가 수집한 이벤트를 Queue에 저장 
  • 메모리와 파일, Queue등이 제공 됨
  • 이벤트의 트랜잭션 관리
• Sink
  • 수집한 데이터를 외부로 보내는 역할
  • "단일" Channel에 연결
  • HDFS, Hive, Logger, Avro, Thrift, IRC, File Roll, Null, HBase, MorhplineSolr, Elastic Search, Kite Dataset, Kafka, HTTP, Custom sink 등 다양한 종류를 제공

 

Flow

Apache Flume으로 구성할 수 있는 구조도 살펴보자.

 

1. Multi-Agent Flow

데이터가 여러개의 Flume Agent로 흐르도록 하는 구조다. 직전 sink는 반드시 'Avro' 통신이어야 하며, 현재 hop(오른쪽 host)의 Source 역시 Avro 유형이어야 한다.

 

2. Consolidation

이 구조는 복잡해보이지만 사실 가장 일반적인 구조다. 보통 로그데이터를 수집할 때, 하나의 웹 서버에서 수집 되진 않는다. 서비스가 클 수록 수십대의 웹 서버에서 로그가 수집되어진다. 각 웹 서버에는 Flume Agent가 있어서 수집을 돕고, 하나의 Agent에서 이를 통합 (Consolidates)한다. 마지막에 Sink를 통해 어떤 레파지토리에 데이터를 저장할지 정해준다.

 

3. Multiplexing the Flow

플룸은 하나 이상의 목적지에 데이터를 저장할 수 있게 하기 위해, 다중 이벤트 flow를 지원한다. 멀티플렉서 정의를 하면 채널-싱크 가 복사 되어 원하는 레파지토리로 데이터를 전송할 수 있다. 다양한 레파지토리로 연결 되는 것 뿐만 아니라 위에서 설명한 Multi-Agent도 가능하다.

 

Reliability

그러나 이름이 찰떡같다고(?), 정교한 스트럭쳐가 있다고 해서 무작정 쓰기에는 찝찝하다. 안정성은 어떨까? 플룸 공식 문서를 확인해보면 다음과 같은 내용을 볼 수 있다.

 

Reliability

The events are staged in a channel on each agent. The events are then delivered to the next agent or terminal repository (like HDFS) in the flow. The events are removed from a channel only after they are stored in the channel of next agent or in the terminal repository. This is a how the single-hop message delivery semantics in Flume provide end-to-end reliability of the flow.

Flume uses a transactional approach to guarantee the reliable delivery of the events. The sources and sinks encapsulate in a transaction the storage/retrieval, respectively, of the events placed in or provided by a transaction provided by the channel. This ensures that the set of events are reliably passed from point to point in the flow. In the case of a multi-hop flow, the sink from the previous hop and the source from the next hop both have their transactions running to ensure that the data is safely stored in the channel of the next hop.

 

대충 풀어보자면 트랜잭션을 활용해 'end-to-end' 방식으로 신뢰성을 높인다는 것이다. 발생한 이벤트가 채널 혹은 레파지토리(sink에서 설정값으로 준 저장소)에 전달이 된 후에만 제거가 된다고 한다.

 

즉, 트랜잭션이 시작된 뒤에 다른 Agent 혹은 Collector로 이벤트를 완전히 전달한 것이 확인 되어야지만 트랜잭션이 커밋되는 방식이다. 채널 배치에서 데이터를 삭제하기 전에 각 싱크는 채널을 사용하여 트랜잭션을 시작한다. 스토리지 시스템 또는 다음 플룸 에이전트에(multi agent flow방식인 경우 agent에서 collector로 연결되는 게 아니라, agent-to-agent 로 연결 된다. 위에 설명했음!) 기록 된 성공적인 이벤트 일괄 처리시, 트랜잭션을 커밋한다는 것이다. 트랜잭션이 커밋되면, 채널은 자신의 내부 버퍼에서 이벤트를 삭제한다. 

---

사실 필자도 지금 Multiplexing Flow를 구현해야 되는데, 한창 가동 되고 있는 서버를 멈춰서 수정하고 재가동 시키기에는 데이터 유실, 코드 유실 등 리스크가 걱정되는 상황이다. 특히 Log데이터 같은 경우는 스트리밍 데이터가 많아서 데이터 유실이 더더욱 신경쓰인다. 테스트서버에서 먼저 테스트 하고 빠르게 실제 서버에 적용하는 방법으로 생각하고 있긴 한데, 더 좋은 방법 있다면 댓글에 달아주세요. ^^ (갑분존댓말)

 

+) 더 자세한 설명은 플룸 공식 문서 https://flume.apache.org/ 참고! 

     언제나 그렇듯 공식 독스는 짱!b

+) 오타, 가짜뉴스(ㅋㅋ) 지적은 언제든 환영입니다!