빅데이터(Big Data) 분석의 시작, 데이터 수집 그리고 로그 수집기(Log Aggregator) 솔루션들

지난 12월초에 3월초까지 빅데이터에 대한 글을 포스팅하고 나서 전반적인 내용들을 대부분 정리했다고 생각하면서도 무언가 빠진 듯한 느낌이 있었는데 지난 주 어느 분과 이야기를 나누면서 빠진 부분이 무엇인지 퍼뜩 생각이 났습니다.

데이터 프로세싱을 하면서 제일 중요한 부분이면서 간과하기 쉽고 무엇보다 실무에 있어서는 가장 괴롭고 힘든 업무 영역이 바로 데이터 수집에 대한 것입니다. 결국은 데이터를 분석하기 위해서는 데이터를 수집하는 것부터 시작을 해야 하겠지만 이 데이터 수집이라는 것이 그렇게 만만한 일이 아닙니다.

아시다시피 하둡의 배치 프로세싱 성능이 아무리 좋아봐야, 클러스터의 규모가 아무리 커도 일단 HDFS에 데이터가 저장이 되어 있어야하고 실시간 처리를 하고 싶어도 처리할 데이터가 원하는 시간내에 실시간 프로세서로 전달이 되지 않는다면 아무 소용이 없기 때문입니다.

다행이 분석에 필요한 데이터들이 초기부터 데이터베이스에 저장되어 있었다면 분석 용도에 맞게 데이터베이스에서 데이터를 가공 처리하거나 변환작업을 통해서 원하는 분석 업무를 할 수 있겠지만 분석을 해야 하는 데이터들이 파일 시스템의 파일 형태로 저장되어 있다면 그 데이터의 포맷이나 형식이 상이하기 때문에 원하는 데이터 형태로 변환하고 처리하는 프로그램을 직접 구현하거나 유닉스에 마련된 다양한 유틸리티들을 이용해서 사전에 프리프로세싱을 해서 데이터베이스에 적재하는 작업이 필요합니다.

이것도 해당 데이터들이 같은 시스템에 있는 경우라면 그나마 낫겠죠. 하지만 분석해야 하는 데이터들은 해당 서비스가 운영되는 별도의 시스템에 저장되어 있거나 시스템의 로그 서버에 따로 저장되어 있기 마련입니다. 따라서 우선 분석을 해야 하는 데이터를 가져오는 일부터 데이터의 수집은 시작됩니다. HTTP 을 이용하거나 별도의 전송 프로그램을 이용해서 데이터를 전달할 수도 있겠지만 일반적으로 대용량의 데이터 전송을 위해서 대부분 ftp 을 사용하게 됩니다. 보안이 이슈가 된다면 방화벽 설정과 sftp 를 이용하기도 합니다. 문제는 이 ftp 가 그렇게 안정적이지 못하기도 하고 기본적으로 트랜잭션이라는 것을 지원하지 않기 때문에 대부분 ftp 을 이용하는 경우 데이터를 전송해주는 쪽과 데이터를 받아서 사용하는 쪽에서 데이터가 정확히 전달되었는지 확인할 수 있도록 전송파일과 함께 체크파일을 함께 전송하도록 하고 있습니다.

하지만 이 역시 완벽하지 않죠. 그래서 이러한 데이터 전송에 대한 notification 과 트랜잭션관리등을 위한 상용 솔루션들도 있습니다. 예를 들어 IBM의 MQ File Transfer Edition 같은 것입니다. 기본적인 데이터 전송 프로토톨은 ftp 을 사용하지만 안정적으로 데이터 전송을 하는데 필요한 처리를 맡아서 해주는 역할을 해주는 것이죠. ( 참고: http://www.lusodata.pt/webluso/Data/Sites/1/pdf/rp-wsmqftesolutionoverview.pdf) 찾아보니 기업내, 기업간 데이터 전송을 위한 IBM의 토탈(?) 솔루션도 있네요. (http://www.redbooks.ibm.com/abstracts/sg247927.html) 여담이지만 IBM은 없는 솔루션이 없는 것 같아요. ^^

현실적으로 십수개의 시스템과 연동을 해서 데이터를 가져오는 작업 자체가 그렇게 기술적인 난이도가 있는 것은 아닙니다. 문제는 이렇게 연동되는 연동 인터페이스에 대한 관리를 어떻게 하면 제대로 하는가가 가장 큰 문제라고 할 수 있습니다. ftp 기반으로 데이터를 연동하는 경우에는 별도의 프로세스가 연동 시스템의 체크파일등을 확인하면서 연동된 결과를 일일히 파악해야 하는 어려움이 있습니다. 만일 장애가 발생하면 재시도하는 작업을 해야 하는데 많은 경우 수작업에 의존하는 경우도 많은 것이 사실입니다. 물론 상용솔루션을 구매하거나 이에 준하는 유틸리티를 개발하면 되겠지만 생각보다 만만한 작업은 아닐 것입니다.

그나마 데이터를 수집을 위해서 연동을 해야 하는 시스템이 십수개라면 어느 정도 통제하에 데이터를 수집하고 처리할 수 있겠지만 만일 수집해야 하는 물리적인 시스템의 수가 수십, 수백, 수천개가 된다면 어떻게 해야 할까요? 더불어 각 시스템에서 돌아가는 각종 서비스들로 부터 발생하는 로그의 종류까지 생각해본다면? 게다가 ftp 와 같은 배치작업이 아니라 실시간성으로 데이터를 수집해야 한다면 이러한 작업은 그렇게 쉽지 않겠죠.

전통적으로 유닉스에서의 로그 수집은 syslog을 사용해왔습니다. 자바에서는 Log4j을 많이 사용하고 있었지만 문제는 각종 서비스들은 이러한 표준화된 도구에서 제공하는 규약을 지켜서 로그를 쌓기도 하지만 서비스 자체에서 정의한 고유의 포맷으로 각종 로그 데이터들이 저장되게 됩니다. 소위 웹로그, 트랜잭션로그, 클릭로그 등 다양한 형태의 로그 데이터가 쌓이게 되는 것이죠. 아참, 이 밖에도 데이터베이스에 저장되는 로그데이터(히스토리데이터) 들도 수집해야하는 대상이 되는 데이터들이 되겠습니다.

그래서 이러한 흩어져 있는 각종 로그 데이터를 일관된 방법으로 수집할 수 있는 잘 설계된 로그 수집 프레임워크(Log Aggregator Framework) 는 빅데이터 분야에서 반드시 필요하고 고려해야 할 부분입니다.

아마도 이러한 로그 관리 도구로 가장 유명한 것중 하나가 스플런크(splunk) 일 것입니다. 프리 버전과 엔터프라이즈 버전을 제공하고 있고 이쪽 분야에서는 많이 알려지고 많이들 활용하고 있는 것 같습니다. 최근 엔터프라이즈 버전에서는 하둡과 통합이 되어서 HDFS에 데이터를 저장하고 하둡에서 분석 프로세싱을 할 수 있도록 업그레이드가 되었습니다. 웹 기반의 GUI을 제공하고 있어서 그 사용성이나 관리적인 측면에서는 매우 큰 강점이 있을 것 같습니다. 그런데 공개된 자료로는 대충 짐작만 할 수 있어서 정확하게 파악이 안되네요. 혹시 잘 아시는 분이 댓글을 달아주시면 큰 도움이 될 것 같습니다. 예산을 어느 정도 확보하고 안정된 솔루션을 확보하고 비용 투자할 의사가 있는 기업에서는 splunk가 괜찮은 솔루션으로 보입니다.

하지만 하둡 에코시스템 측면에서 관심을 가져야 할 로그 수집기(Log aggregator)는 Flume 입니다.

사실 재작년쯤에 페이스북이 공개한 Scribe 을 검토하고 개발팀내에서 HDFS를 지원할 수 있도록 개발한 적이 있습니다만 제대로 활용을 할 수가 없었습니다. 가장 큰 이유는 기존 시스템에 Scribe을 설치할 수 있는 여건과 상황이 되질 않았기 때문이였습니다. 네 맞습니다. 레가시 시스템을 쉽게 건드릴 수는 없습니다.

그런데 최근 Flume 에 대해서 다시 검토를 해보니 맘에 쏙 들게 만들어져 있더군요. (Thanks, Cloudera!) 무엇보다도 데이터 수집을 위한 다양한 데이터 플로우 토폴로지를 구성할 수 있고 마스터 노드에서 통합 관리할 수 있는 웹페이지를 제공할 뿐만 아니라 이를 통해서 설정을 쉽게 변경하거나 모니터링이 가능하다는 것입니다. 뿐만 아니라 마스터 노드를 이중화하여 가용성이 크게 높아져 있더군요. 게다가 자바로 구현되어 있어서 다양한 오에스 플랫폼에 포팅이 되어 있다는 것입니다. MS윈도우서버, 각종 유닉스/리눅스 서버에 설치해서 로그 데이터 수집이 가능합니다. 당연히 데이터 저장소가 기본적으로 HDFS 라는 것으로 전제하였기 때문에 하둡과 매우 잘 통합되어 있기도 합니다.

Cloudera’s Flume

View more presentations from Cloudera, Inc.

반면 공개된 Scribe 소스코드는 더이상 업데이트도 되고 있지 않고 데이터 수집을 하는 각 노드에 대한 모니터링도 쉽지않습니다 또한 설정도 rshell 을 이용해야 하는 등 불편함이 있습니다.

물론 Scribe 은 페이스북 내부에서 실시간 데이터 프로세싱을 위해서 잘 활용되고 있는 것으로 보입니다만 단순히 Scribe 만 활용하는 것이 아니라 Calligrapuhs 라는 Scribe 와 호환되는 자바로 쓰여진 프로그램(Flume의 Collector와 같은 역할) 과 Ptail, Puma, hbase 와 같은 프로그램과 결합되어져 가능해진 것이죠. 아직 오픈소스로 공개되지는 않았습니다.(참고: http://borthakur.com/ftp/SIGMODRealtimeHadoopPresentation.pdf)

2011 06-30-hadoop-summit v5

View more PowerPoint from Sam Rash

오늘은 빅데이터 분야에서 쉽게 간과할 수 있는 데이터 연동, 수집에 관한 얘기와 관련 솔루션에 대해서 얘기를 해보았습니다. 사실 flume 이든 scribe 이든 이를 잘 활용해서 좀 더 있어보이는(?) 데이터 플랫폼을 구축하고 싶지만 현실은 그렇게 녹녹치 않다는 것입니다. 여전히 서비스 시스템들은 분석 시스템들과 동떨어져 있고 서비스 구축시에 분석 환경에 대한 것들을 충분히 고려하고 있지 않기 때문에 위와 같은 것들을 바로 적용하기에는 여러가지 어려움이 있습니다. 로그데이터 수집을 위한 에이전트들이 서비스 서버의 성능에 얼마만큼 영향을 주는지도 충분히 검토해야 하고 서비스를 하는 쪽에 수집 에이전트를 설치했을 때 그 영향이 어떠한지 객관적으로 정보를 제공도 해야 합니다. 이러다보니 현실적으로 각 시스템 관리 책임을 명확 구분하기 위해서 데이터 연동/수집을 위해서 ftp 를 적용하자는 쪽으로 결론 나는 것이죠. 사실 대부분의 경우 큰 문제가 없고 안정적이기 때문에 ftp 를 잘 활용하는 것도 좋은 방법이구요.

저에게 하둡기반으로 로그데이터 수집을 위한 솔루션을 선택하라면 Flume 과 FTP 을 적절히 활용해야 한다고 말씀드리고 싶다는 걸로 오늘 포스팅은 마무리 지을까 합니다.

아! 맞다.  FUSE 얘길 하지 않았군요. ^^

광고