대량의 로그 파일 수집

빅데이터를 활용하고 분석하고, 결과를 도출하는 처리 과정은 크게 6가지 단계로 나누어 볼 수 있습니다. 여기서는 6단계의 처리 과정에 대해서 가볍게 살펴보도록 하겠습니다. 아래의 그림은 하둡 에코 시스템(Hadoop Echo System)의 전체 구성도입니다. 여기서 살펴볼 내용들은 하둡에만 국한된 사항은 아니지만, 이 그림을 통해서 설명할 내용들이 어디에 속하는지 알 수 있습니다.

 

[ 하둡 에코 시스템 구조 ]

 

빅데이터 분석 절차의 첫 번째 단계는 분석 대상이 되는 데이터를 수집하는 단계입니다. 데이터 수집을 위한 방법은 매우 다양하고 광범위합니다. 데이터 수집 시 수집 주체의 능동성 여부에 따라서 데이터 수집을 두 가지 형태로 분류할 수 있습니다. 데이터를 능동적으로 수집하는 형태와 수동적으로 모으는 형태입니다. 능동적 데이터 수집의 대표적인 예로 로그데이터(Log Data) 등을 들 수 있으며, 수동적 데이터 수집의 예로 웹 크롤러(Web Crawler)를 들 수 있습니다.

 

 

대량의 로그 파일 수집

대량의 로그를 수집하고 저장하는 기술로는 대표적으로 비정형 데이터를 수집하는 척와(Chukwa), 스크라이브(Scribe), 플룸(Flume) 등이 있으며, 정형 데이터를 수집하는 스쿠프(Sqoop) 와 hiho 등이 있습니다.

아파치 척와(Apache Chukwa)

분산되어 있는 노드들의 로그 데이터를 수집하고, 수집된 데이터를 저장하며 분석하기 위해 만들어진 오픈소스 프로젝트입니다. 척와가 수집하는 로그는 모니터링 로그(Monitoring Log), 응용프로그램 로그(Application Log), 하둡 로그(Hadoop Log) 등 다양한 데이터를 수집하며, 테라바이트 단위 이상의 로그데이터를 모니터링 하기위하여 개발되었습니다.

 

 [ Chukwa 구조 ]

 

 

에이전트(agent) 는 로그를 수집할 대상 서버(Monitored Source Node)에 설치가 됩니다. 에이전트의 임무는 해당 서버의 로그 파일이나 서버 정보를 콜렉터(Collector)에게 보내는 것입니다. 컬럭터(Collector)는 여러대의 에이전트로부터 로그 정보를 수신해서 하둡 분산 파일시스템(HDFS, Hadoop Distributed File System)에 저장하는 역할을 담당합니다. 하나의 컬렉터는 여러대의 에이전트 서버로부터 데이터를 전송받지만 하나의 파일에 저장합니다. 이때 저장되는 파일을 싱크(sink)파일이라고 부르며, 하둡 파일 시스템의 시퀀스파일(SequenceFile) 형식으로 저장됩니다.

 

수집된 로그 데이터를 처리하는 데이터 처리(Data Processing) 방법에는 아카이빙(Archiving)과 디먹스(Demux) 2가지 작업이 있습니다. 아카이빙(Archiving)은 컬렉터가 저장한 로그 파일에 대해서 시간 순서로 동일한 그룹으로 묶는 작업을 수행합니다. 데이터의 중복을 제거하고 졍렬 작업을 수행한 후, 하둡의 SequenceFile 포맷으로 저장합니다. 디먹스(Demux)는 로그 레코드를 파싱해서 키-값(Key-Value) 쌍으로 구성하여 척와레코드(ChukwaRecord)를 만든 후에 하둡 파일 시스템에 파일로 다시 저장합니다.

 

마지막으로 사용자는 HICC(Hadoop Infrastructure Care Center) 라는 웹-포탈 인터페이스를 통하여 하둡 클러스터의 로그 파일과 시스템 정보를 수집해서 분석한 후에 웹 UI를 통해서 결과를 보여줍니다. 로그 수집을 위한 일반적인 용도가 아니라, 하둡 클러스터 자체를 실시간으로 모니터링하고 관리하는 기능입니다.

 

 

아파치 플럼(Apache Flume)

플럼(Flume)은 분산 환경에서 대량의 로그 데이터를 효과적으로 수집하여, 합친 후 다른 곳으로 전송할 수 있는 신뢰할 수 있는 서비스입니다. 플럼은 단순하며 유연한 스트리밍 데이터 플로우(streaming data flow) 아키텍처를 기반으로 합니다. 또한 플럼은 장애에 쉽게 대처 가능하며, 로그 유실에 대한 신뢰 수준을 상황에 맞게 변경할 수 있으며, 장애 발생시 다양한 복구 메커니즘을 제공합니다. 실시간으로 로그를 분석하는 어플리케이션을 개발할 수 있도록, 간단하며 확장 가능한 데이터 모델을 사용합니다.

 

클러스터에 있는 모든 장치로부터 로그 파일들을 수집한 후, 하둡 분산 파일 시스템(HDFS)과 같은 중앙 저장소에 저장하는 로깅 시스템을 구축해야 할 때 플럼이 가장 제격입니다. 플럼의 핵심 목표는 신뢰성(Reliability), 확장성(Scalability), 운영가능성(Manageability), 확장성(Extensibility) 을 만족시키는 것입니다.

 

[ Flume 구조 ]

 

위의 그림에서 다수의 어플리케이션 서버에서 로그 데이터를 수집하기 위해 플럼을 배치하는 전형적인 아키텍처를 볼 수 있습니다. 플럼 아키텍처는 다수의 논리 노드(logical node)로 구성되며, 각 논리 노드는 3개의 티어로 분류가 됩니다. 에이전트(agent) 티어는 로그를 생성하는 머신에 설치되며, 수집한 로그 데이터를 컬렉터 (Collector) 티어로 전송합니다. 컬렉터 티어는 분산된 에이전트로부터 데이터를 수집한 후에 스토리지(Storage) 티어로 재 전송합니다.

 

 

페이스북 스크라이브(Facebook Scribe)

페이스북(Facebook)에서 개발된 대규모의 서버로부터 실시간으로 스트리밍 로그 데이터 수집을 위한 애플리케이션입니다. 스크라이브(Scribe)는 네트워크와 시스템의 장애를 위해 고안된 것으로, 확장성과 신뢰성을 목표로 두고 있습니다. Facebook에서는 수 천대 규모로 설치, 운영되고 있고 하루에 100억 개의 메시지를 수집하고 있습니다.

 

[ Scribe 구조 ]

 

하나의 중앙 Scribe 서버와 여러 대의 Local Scribe 서버 구조로 구성되어 있으며, Scribe 서버는 시스템의 모든 노드들 위에서 동작합니다. 만약 중앙 Scribe 서버가 동작하지 못하면, Local Scribe 서버가 Local Disk에 있는 파일에 메시지를 작성하고, 중앙 Scribe 서버가 복구되었을 때 다시 메시지를 전송하여 메시지의 손실을 방지합니다.

 

중앙 Scribe 서버는 분산 파일 시스템 같은 마지막 목적지의 파일에 메시지를 작성하거나, 다른 층의 Scribe 서버로 메시지를 전송합니다. 이때, Scribe는 메시지 저장을 위해 Store라는 개념을 사용하여 여러 가지 타입의 Store를 제공하고, 이를 이용하면 HDFS에도 메시지를 저장할 수 있다. 로그 기록은 파일에도 할 수 있고, HDFS에 실시간으로도 할 수 있습니다.