여러 관련 프로그램 중에서 Flume을 설정 할 일이 있어 알아 본 내용을 포스팅 하겠습니다.
About Flume
Flume OG 와 Flume NG의 차이점
가장 큰 변화는 아키텍쳐 자체가 변했다는 점입니다. Flume OG의 아키텍쳐를 보면 Agent, Collector, Master로 나눠져 있습니다.(HDFS는 Hadoop 저장 장치를 의미합니다.) Flume은 하나의 머신에서 논리적으로 나눠서 구성할 수도 있고 각각의 머신으로 물리적으로 구성 할 수도 있습니다. 저는 쉽게 설명드리기 위해 물리적 구성으로 설명 드리겠습니다. Flume OG는 각각의 머신에 있는 Agent가 모은 데이터를 Collector라는 애가 있는 머신으로 보냅니다. Collector라는 애는 각각의 머신에 있는 Agent에게서 받은 데이터를 최종 저장 장치에 보내게 됩니다. 이런 데이터 흐름을 관리하는 곳이 Master 입니다. 간단한 예를 들어 보자면 각각의 배(Agent)에서 잡은 생선들은 경매장(Collector)에 모이고 경매된 생선들은 다시 노량진 수산시장(HDFS같은 최종 저장장치) 같은 최종 소비자가 구매 할 수 있는 곳으로 모이게 되져. Flume OG의 개념이 이와 같습니다. Flume OG는 각각의 역할이 정해져 있어서 설정할 때도 각각의 역할에 맞게 명시적으로 설정을 해줘야 되는데 한번 구성하고 땡이면 상관없는데 수평적으로 Agent를 확장 할 수도 있고 Collector를 확장 할 수 있는 구조에서 확장 될때 마다 Master를 다시 설정해야 되는 구조가 불편했습니다. 사실 Collector는 Agent입니다. Master에서 어떻게 설정 하느냐에 따라 Agent가 Collector가 되는 것입니다. 이런 불편함을 개선한게 Flume NG입니다.
Flume NG에서는 Master가 사라졌습니다. Collector 개념도 없어졌습니다. Collector는 위에서 설명했듯이 Master에서 Collector라고 이름만 바꿔준 Agent 입니다. 그래서 Master가 없어졌으니 당연히 Collector도 없어진 것입니다.(이래서 줄을 잘서야 됩니다.) 아키텍쳐를 처음 보시면 Flume OG와 Flume NG의 시점이 달라서 눈에 확 안들어 올 수 있지만 잘 보시면 둘다 데이터의 Flow를 나타내고 있다는 걸 아실 수 있습니다. Flume NG의 아키텍쳐는 Agent안에서의 데이터 흐름만 나타내고 있는데 Flume NG 에서는 Agent만 알면 되고 Flume OG는 Agent, Collector, Master 를 알아야지만 데이터의 Flow를 설명 할 수 있기 때문입니다. 또 설명 드리지만 Flume NG에서는 Master와 Collector 개념이 빠졌습니다. Flume OG의 아키텍쳐에서 Master와 Collector를 빼보면 Flume NG의 아키텍쳐와 똑같다는 걸 알 수 있습니다.
Flume NG의 아키텍쳐를 보면 Agent안에 Source, Sink, Channel이 있는 것을 확인 할 수 있습니다. Source, Sink는 Flume OG에서도 Agent 안에 있던 아이들 입니다. Source는 데이터가 Agent로 들어오는 곳이고 Sink는 Agent가 데이터를 내보낼때 사용 하는곳 입니다.사람을 Agent라고 하면 Source는 입이고 Sink는...똥......꼬?가 되겠네요. 음식물(데이터)이 입(Source)을 통해 몸(Channel)에 들어오면 똥꼬(Sink)를 통해 똥(데이터)으로 나오고 그 똥들은 정화조(HDFS)에 모입니다. Channel은 일종의 큐라고 생각하면 됩니다. Source로 부터 데이터가 들어오면 Channel에 쌓이고 Sink는 Channel에 있는 데이터를 꺼내와 내보내게 됩니다. 이렇게 함으로써 Flume OG에서는 전체 Flow를 관리하던 Master가 있어야 됐지만 Flume NG는 Agent 하나하나의 설정만 알고 있으면 되게 되었습니다.
Flume NG Flow 구성 종류
Setting multi-agent flow
Consolidation
Multiplexing the flow
Flume NG로 구성 할 수 있는 Flow 구성도 입니다. 가운데 있는 Consolidation Flow가 Flume OG의 아키텍쳐와 비슷 하다는걸 알 수 있습니다. Flume NG는 각각의 Agent만 알고 있으면 된다고 했습니다. 그 의미는 Source의 Type과 Sink의 Type만 결정하여 설정해 놓으면 Agent가 수평적으로 확장이 되어도 다른 Agent는 신경 쓸 필요가 없어집니다. Consolidation Flow를 보면 각각의 Agent가 하나의 Agent로 데이터를 보내고 있는것을 알 수 있습니다. Flume OG의 용어로 말하자면 각각의 Agent에서 Collector로 데이터를 보내는 것입니다. 하지만 Flume NG에서는 Collector가 아닌 Agent에서 Agent로 데이터를 이동하는 것 뿐입니다. Multiplexing Flow를 보면 Channel과 Sink를 여러개 만들어 각각의 저장소에 저장하거나 다른 Agent로 보낼 수도 있음을 확인 할 수 있습니다. 굉장히 심플해 지면서 유연성있게 변경된 걸 확인 할 수 있습니다.
Agent Type
모든 Type들을 살펴본 것은 아니며 몇가지 테스트한 Type에 대해서만 설명 드리도록 하겠습니다.
Source Type
- Avro Source : Agent 와 Agent를 연결해 주는 Type입니다. Agent끼리 연결 할 경우는 Source와 Sink의 Type를 avro로 해주면 됩니다.
- Exec Source : 파일을 읽을때 사용 하는 Type으로서 Command 속성을 이용하여 tail 명령어로 데이터를 읽어 올 수 있습니다.
- NetCat Type : 터미널에서 데이터를 입력 받을 때 사용 합니다.
- Syslog Source : SyslogTCP와 SyslogUDP로 나뉘며 SyslogTCP는 로그 한줄 한줄이 새로운 Event이이나 SyslogUDP는 전체로그를 한번의 Event로 보냅니다.
이밖에도 Scribe Source, Json Source, Custom Source 등 여러 Type이 있습니다.
Sink Type
- Avor Sink : Agent 와 Agent를 연결해 주는 Type입니다. Agent끼리 연결 할 경우는 Source와 Sink의 Type를 avro로 해주시면 됩니다.
- HDFS Sink : Hadoop 저장장치에 저장할때 사용 하는 Type 입니다.
- File_Roll Sink : 원하는 저장장치에 파일로 저장한다.
- HBase Sink : HBase에 형태로 저장한다.
이밖에도 Logger Sink, Custom Sink등 여러 Type이 있습니다.
Channel Type
- Memory Channel : Source에서 받은 Event를 Memory에 가지고 있는 방식으로 빠르고 간편하지만 Event를 잃어버릴 수도 있습니다.
- JDBC Channel : JDBC 형태로 저장한다.
- File Channel : File 형태로 저장한다.
이밖에도 Custom Channel도 있습니다.
모든 Type를 다 테스트하기에는 어려운 점이 있어 제가 알아본 Type만 작성 하였습니다. Flume User Guide를 참고하시면 여러 Type에 관해 알 수 있습니다.
참고
[Flume] Flume 설치부터 예제까지...
댓글 없음:
댓글 쓰기