Dana Garner[1] : 우리는 단지 데이터에서 증가를 다루는 것이 아니라 다른 데이터 소스를 다룬다. 우리는 여전히 메인프레임과 함께하고 있다. (당췌 무슨 소린지 ... )

이 내용은 우리가 Big Data를 다루는 것은 불가능하다. Right Data를 다루어야만 한다. Big Data와 Right Data의 차이는 무엇인가?

Noel Yuhanna[2] : 이것은 GIGO(Garbage In Garbage Out) (발번역자 : FIFO를 바꿔서 쓰는것 같음)와 같다. 오랜 시간동안 Data를 다루는 조직들은 자신들이 어떤 Data를 다루어야하는지 조차 파악하지 못하고 있었다. 뿐만 아니라 그 Data의 가치 조차 파악되지 않았따. 새로운 도전은 바로 이런 Data의 가치를 파악하는 것이다.

그리고 매우 중요한 포인트는 바로 이런 Data를 통해 비지니스 감각을 만드는 것이다. 그래서 Right Data가 중요하다. [...]

다시 생각해보면 Big Data를 다루는 조직들에게는 엄청난 기회이다. 무엇보다 Big Data의 의미에 대해서 생각해보고 이해해야 하며 그것을 활용할 것인지 끊임없이 질문해봐야 한다. Data에 대해서 정확하게 인지하지 못한다면 Big Data Framework에 Data를 넣는 것은 의미도 목적도 없는 행위일 뿐이다.

Todd Brinegar[3]:  Noel 의 말이 100% 맞다. 이 내용은 대부분의 Data에 대한 것이 아니라 Right Data에 대한 것이다. 내 고객들 중에는 다량의 데이터베이스를 가지고 있는 사람들이 있는데 그들의 데이터베이스에는 관심도 없고 사용하지도 않는 데이터들이 쌓여있다.

[...]


그렇기 때문에 Right Data가 들어오고 추가되고 가져가지는 것과 그런 Data를 만드는 것이 요즘 매우 중요해지고 있다. 이런 것들을 낮은 가격으로 만드는 기술을 가지고 있는 것이 매우 중요하다. 

Right Data에 바로 접근하는 방법은 없다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

About

이번 포스트는 Fluentd 에 대한 소개이다. Fluentd는 Treasure Data 사에서 만든 오픈소스 로그 수집기 이다.

The Problems

로그에 있어서 근본적인 문제점은 로그들이 스트림 형태로 표현될 지라도 파일로 저장되는 것에 있다. 전통적으로 로그들은 text 형태의 파일로 덤프되게 되고 rsync를 상요해서 시간 혹은 하루 주기로 수집된다. 오늘날의 web/mobile 어플리케이션에서는 이런 방식은 두가지 문제를 야기한다. 

PROBLEM 1: NEED AD-HOC PARSING

Text 형태의 로그는 자신만의 포맷을 가지고 있어서 분석 엔지니어들은 각각의 포맷에 맞는 파서를 만들어야 한다. 분석 엔지니어는 Data Scientist이지 파서 제너레이터가 아니다!!!!

PROBLEM 2: LACKS FRESHNESS

로그의 지연현상이 발생한다. 사용자 행태에 대한 실시간 분석이 훨씬 빠른 기능 반복을 만든다. nimber A/B 테스팅을 통해 서비스 차별화에 도움이 된다.

이런 이유 때문에 Fluentd를 만들게 되었다. 우리는 Fluentd가 파일의 제거와 로그를 반구조화 데이터 스트림으로 변경을 통해 스케어러블 로그 수집의 모든 이슈를 해결할 것이라고 믿는다.

What’s Fluentd?

Fluentd를 설명하기 가장 쉬운 방법은 'syslogd that understands JSON'이다. 특징은 다음과 같다. :

• 쉬운 설치 : rpm/deb/gem 사용
• 작은 footprint : 300라인의 루비소스
• 반구조화 데이터(Semi-Structured data) : 로깅
• 쉬운 시작 : 적은 설정
• 완벽한 프러그인 스타일 : 구조화, Ruby gems를 사용한 프러그인 배포

유사한 다른 로그 수집 시스템은 페이스북의 Scribe, Cloudera의 Flume이 있다. 아래 테이블을 통해 Scribe, Flume, Fluentd의 차이점을 요약해보도록 하겠다. (주의: 저자는 FlumeNG branch에 대해서 정확하게 이해하고 있지는 못하지만 Flume에 큰 변화의 움직임이 있는것 같다.)

물론 여기에도 장점과 단점은 있다. Fluentd 최대 확장과 유연성은 Ruby의 에코 시스템을 통한다. 반면 Scribe는 강력한 성능(물론 Fluentd또한 꽤나 빠르다. 하나의 코어에서 1800msg/s를 처리할 수 있다.)을 가지고 있다. Flume은 Java로 만들어졌기 때문에 다양한 엔터프라이즈 시스템에 적용이 가능하다.

아래 내용은 Fluentd의 기본 컨셉에 대해 자세히 다루도록 하겠다.

LogEntry = time + tag + record

전통적인 raw-text 로그와 다르게 Fluentd의 로그 엔트리는 세가지 속성을 가지고 있다. (time, tag, record)

• time 은 UNIX 타임 스탬프로 로그가 포스트되는 시점을 나타낸다.
• tag 는 로그포워딩에 사용되는 경로 메세지를 나타내고 자세한 내용은 다음에 설명하겠다.
• record 는 JSON 형태로 표현되고 raw text형태가 아니다.

레코드는 의도적으로 JSON형태로 표현된다. Fluentd는 비구조화 데이터(unstructured data)가 아닌 반구조화 데이터(semi-structured data)를 수집한다. 이것은 다음 분석에 파싱이 필요없다는 것을 뜻한다. 이 방식은 다루기 쉽고 임의의 regexp 보다 빠르다. 그렇지만 어플리케이션이 Fluentd를 위해서 로깅 라이브러리를 필요로 한다.

Internal Architecture: Input -> Buffer -> Output

Fluentd는 3가지 기본 컨포넌트로 구성된다. : Input, Buffer, Ouput 기본 행동은 1) Feeding logs from Input, 2) Buffers them, 3) Forward to Output.

Input

Input은 로그가 들어오는 장소를 말한다. 사용자는 다양한 소스로 부터 이벤트를 받아드리도록 확장 할 수 있다. 예를 들어서 Input은 공식적으로 HTTP+JSON, file을 tail하기(Apache log parser 지원), syslog를 지원한다. 물론 Ruby plugin 작성을 통해 다양한 Input plugin작성이 가능하다.

Buffer

Buffer는 신뢰성을 위해 존재한다. Output이 실패했을 경우 이벤트는 버퍼에 남아있고 자동적으로 재시도 된다. 메모리나 파일 버퍼가 지원된다.

Output

Buffer는 log의 청크를 만들고 Output으로 전달한다. Output은 저장하거나 청크를 전달한다. Buffer는 몇초에서 1분동안 청크가 생성되는 것을 기다린다. 이런 것은 배치 스타일의 임포팅을 지원하는 스토리지에서 매우 효과적인 쓰기 방법이다.

다양한 Input/Output plugin들이 커뮤니티를 통해서 만들어지고 있다. : MongoDB, Redis, CouchDB,Amazon S3, Amazon SQS, Scribe, 0MQ, AMQP, Delayed, Growl, 등이 있다.

Log Forwarding

Fluentd는 하나의 노드에서도 동작을 잘할 뿐만 아니라 여러 노드의 설정 또한 가능하다.

어플리케이션 서버는 하나의 Fluentd를 로컬에 가지고 있고, 로컬의 로그들을 모든 로그를 하나로 수집하는 다른 Fluentd로 넘기게 된다. tag는 목적지가 되는 Fluentd를 가르키게 된다(정해진 설정 파일을 사용).

Conclusion

Fluentd를 사용하면 실시간 로그 수집을 매우 간단하게 할 수 있다. 또한 다른 로그 수집 솔루션중에서 가장 쉽게 설치, 설정, 추가, 수행이 가능하다고 생각한다.
물론 Scribe 와 Flume에 비해서 얼마 되지 않은 제품이지만 벌써 하루에 수천만 건의 로그를 수집하는 사용자들이 Fluentd를 사용하고 있다. 커미터의 숫자와 플러그인들 또한 매일같이 늘어나고 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이 포스트는  Fluentd-MongoDB plugin 을 사용해서 반구조화된 로그를 실시간으로 모으는 방법에 대해 이야기한다.

Background

Fluentd 는 Tresure Data에서 만든 오픈 소스 로그 콜렉터이다. Fluentd는 로그를 반구조화(semi-structured data)된 데이터 스트림으로 처리하기 때문에 이상적인 데이터베이스가 강하게 반구조화(semi-structured data)된 데이터를 지원해야한다. 몇몇 데이터베이스가 이 기준에 맞기는 하지만 나는 MongoDB 가 가장 강력한다고 생각한다.

MongoDB를 잘모르는 사람들을 위해 소개를 하자면 MongoDB는 오픈 소스이고 도큐먼트 기반의 데이터베이스이며 10gen, Inc 에서 개발했다. MongoDB는 schema-free 이며 JSON-like format 을 반구조화(semi-structured data)관리를 위해 사용한다.

이번 포스트는 Apache log를 Fluentd를 사용해서 MongoDB로 입력하는 것을 보여준다. (아주 간단한 설정만 사용한다.)

Mechanism

사진은 동작 방법을 보여준다.

Fluentd 는 3가지 동작을 한다.:

1. access log를 지속적으로 "tails"한다.
2. 입력되는 log를 파싱해서 의미있는 필드 (예를 들어 ip, path, 등)를 추출해서 버퍼에 저장한다. 
3. 버퍼된 데이터를 MongoDB에 주기적으로 적는다.

Install

이 포스트는 한 노드의 구성만 보여주고 있다. 아래의 소프트웨어들은 모두 동일 노드에 설치되어있어야한다.

• Fluentd with MongoDB Plugin
• MongoDB
• Apache (with the Combined Log Format)

Fluentd 의 가장 최근 버전인 deb/rpm package 에는 MongoDB plugin이 포함 되어 있다.  plugin 설치를 위해서 Ruby Gems을 사용하고 싶다면 gem install fluent-plugin-mongo 를 사용하면 된다.

• Debian Package
• RPM Package

MongoDB를 다운받기 위해서는 아래 사이트를 활용하면 된다.

• MongoDB Downloads

Configuration

실제 설정을 시작하겠다. deb/rpm을 사용한다면 Fluentd의 설정 파일은 /etc/td-agent/td-agent.conf 에 위치 하고 그 이외의 경우는  /etc/fluentd/fluentd.conf에 위치한다.

Tail Input

입력을 위해서 Fluentd가 최근 Apache logs(보통 /var/log/apache2/access_log) 추적하게 설정하겠다. Fluentd 설정은 아래와 같다.

<source>
  type tail
  format apache
  path /var/log/apache2/access_log
  tag mongo.apache
</source>

설정에 대해서 한줄씩 살펴보자.

1. type tail:  tail plugin은 지속적으로 log file을 추적한다. 이 편리한 plugin은 Fluentd의 중요한 Plugin중의 하나이다.
2. format apache: Fluentd의 내장 Apache log 파서를 사용한다.
3. path /var/log/apache2/access_log: Apache log가 /var/log/apache2/access_log 임을 가정한다.
4. tag mongo.apache: mongo.apach 가 Fluentd 에게 log 엔트리를 의미있는 필드로 파싱할 것을 명령한다.

이것 뿐이다. 이로써 JSON 형태의 출력을 가질 수 있다.

MongoDB Output

Output  설정은 아래와 같다. :

<match mongo.**>
  # plugin type
  type mongo

  # mongodb db + collection
  database apache
  collection access

  # mongodb host + port
  host localhost
  port 27017

  # interval
  flush_interval 10s
</match>

match 섹션은 tag의 일치를 위해서 정규식을 지정한다. 만약에 tag가 일치되면 <match> ...</match> 안의 설정이 사용된다. 예를 들어서 mongo.apache tag 같은 경우 (tail로 부터 생성된)는 항상 사용된다.
flush_internal은 얼마나 자주 데이버베이스(이번 경우는 MongoDB)로 저장하는 지를 나타낸다. 다른 옵션은 MongoDB의 호스트, 포트, db, collection을 나타낸다.

Test

설정을 테스트 하기위해서 원한다면 Apache server에 ping을 날려보도록 하자. 이 예제는 ab (Apache Bench) 프로그램을 사용한다.

$ ab -n 100 -c 10 http://localhost/

MongoDB에 접속해서 저장된 데이터를 보자.

$ mongo
> use apache
> db.access.find()
{ "_id" : ObjectId("4ed1ed3a340765ce73000001"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "200", "size" : "44", "time" : ISODate("2011-11-27T07:56:27Z") }
{ "_id" : ObjectId("4ed1ed3a340765ce73000002"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "200", "size" : "44", "time" : ISODate("2011-11-27T07:56:34Z") }
{ "_id" : ObjectId("4ed1ed3a340765ce73000003"), "host" : "127.0.0.1", "user" : "-", "method" : "GET", "path" : "/", "code" : "200", "size" : "44", "time" : ISODate("2011-11-27T07:56:34Z") }

Conclusion

Fluentd + MongoDB 실시간 Log 수집을 매우 간단하고 쉬우며 강하게 만든다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.