hirano

2012.08.30

統合ログ管理基盤としてのFluentdを試してみました。

先日、朝ご飯を家で食べてきたにも関わらず、通勤途中の駅のカレー屋さんの匂いに誘惑され、
朝カレーしました！周りのメンバーにはこの幸せがまったく響かなかったのが残念です。

アライドアーキテクツの唯一のインフラ基盤エンジニアの平野です。

「からあげ朝カレー」というメニューでした。

さて今回のお題は、インフラ界隈で盛り上がりを見せているFluentdという技術についてです。
私ももれなくこの技術に注目し、先日もFluentd Meetup in Japan #2 に参加させていただいたり、
自社のシステム合宿で、周りのメンバーが粛々とプログラムをしている横でFluentdをいじり倒してました。

◇背景
昨今ビッグデータ、ビッグデータと注目され、Webサービスにおけるユーザの行動解析、
即時性のあるマーケティングデータの抽出要望がシステムに課せられます。
NoSQLと呼ばれる大量データを分散処理による高いスケーラビリティを実現する技術により、
蓄積されたデータを効率よく処理できるようになってきました。

しかしながらクラウド時代において、数十台ものサーバから出力される大量・大規模なログファイルを
解析するためのNoSQLサーバに対してどのように蓄積するのか、ということが課題になります。

いままでですと、
・１日１回、ログファイルをログ解析サーバに転送
・収集後のログファイルをマージして、パースして解析プログラムにかける
というのが主流でした。

これは、いくつかの問題・課題があります。

1) サーバ数分だけの大量の巨大ログファイルが一度に転送され時間と負荷がかかる
2) 巨大な故にコピー処理が失敗することもある。
3) バッチ形式だからおおよそ前日分のデータしか解析できない。
などなど

私個人的には1)2)は運用設計で工夫することで回避するなども考慮できそうですが、
3)に関しては技術的に効率よく解決できるソリューションはあまりなかったと思いますし、
前日分のデータの参照というのは、スピード感としては今ひとつです。

今後（というか現時点で）サービス的には、

・今日リリースした機能の５分前の行動状況をしたい
・開催しているキャンペーンの参加状況を準リアルタイムでチェックしたい

という要望は間違いなくあると思いますし、システム的には、

・今現在のPV/UUはどれくらいでているのか？
・今現在のレスポンス遅延が発生しているページはどこ？
・今現在の表示できていないページはあるか？

などの要望に対して応えていくためにはまじめに考えないといけない課題でした。

◇Fluentdとは
Fluentdは上記のような問題を解決するために考えられましたソリューションです。
以下のような特徴を持っています。

・あらゆるデータソースからログを収集、転送、集約できる。
・取り扱うデータはJSONオブジェクトとして構造化された状態で利用することができる。
・インストールや設定導入が簡単。
・プラグインアーキテクチャを採用しており、新規プラグイン・拡張開発を自由に行なう事ができる
・HA構成も考慮されており、低レイヤー（クラスタなど）での冗長に対する考慮が必要ない。

詳細な説明は、作成者の古橋さんのブログをご覧いただくのがよいと思います。
http://d.hatena.ne.jp/viver/20110929/p1

Fluentd Meetupでいただきましたステッカーです。

◇Fluentdの採用
当社のサービス「モニプラ」にも自前で開発しているログ集計システムがあります。
またモニプラのサービスの分析のために多種多様な分析プログラムもあるようです。
社内の優秀なエンジニアにより強力なシステムが出来上がっています。

なので割とメンバー内では新人の私（年齢的にはかなりベテラン）に対しても
Fluentdいらないよね、って風が吹いてます（と思ってます）

・・・でも負けません。勝手に分析システム（の基盤）を検証しがてら構築してみました。

◇Fluentdの導入検証
今回は既存環境に極力手をいれず、かつ単純なオペレーションで
インストール、設定を行うようにしました。

やったことはログ出力サーバのhttpdから出力されるアクセスログをログ解析サーバにログ転送、
JSON形式で直接投入できるmongodbに差し込むだけのシンプルなものです。

＃mongoDBに入ったデータをリアルタイムで取得してごにょごにょするものも作っていますが、
もったいぶって恐縮ですが社内向け情報となりますので今回は省略します。

＃fluentdはtd-agentというモジュール一体型のものと、gemでインストールするものがありますが、
前者がログ出力サーバ側、後者が収集側、という位置づけだったのかと思ってたんですが、
実は両方ともtd-agentでよかったみたいです。でもせっかく両方のパターンでインストールしたので、
両方を公開しておきます。

◇導入手順

１．環境情報

２．ログ出力サーバへのfluentdのインストール（td-agentのインストール）
yumのリポジトリに以下を追加します。

インストール

以上（簡単・・・すぎますね）

３．ログ解析サーバへのfluentdのインストール（gemによるインストール）
rubyの1.9.2以上を導入する必要がありますが、
CentOS 5.8ではyumで入らないため、自前ビルドをする必要があります。

まずrubyに必要なzlibをインストールします。

yamlもrubyのビルド前に必要になるのでインストールします。

rubyのソースコードを取得してビルドインストールします。

gemでfluentdをインストールします。

fluentdの稼働に必要なbson_extもインストールします。

fluentdからmongodbにデータを投入するプラグインをインストールします。

４．mongodbのインストール
yumのリポジトリに以下を追加します。

mongodbをインストールします。

５．設定ファイルを準備する（td-agent/fluentd、mongodb）
ログ出力サーバ側 td-agent設定ファイル（td-agent.conf）

ログ解析サーバ側 fluentd設定ファイル（fluentd.conf）

ログ解析サーバ側 mongodb設定ファイル（mongo.conf）

６．fluentd、mongodbの起動

ログ解析サーバ側 mongodb起動

ログ解析サーバ側 fluentd起動

ログ出力サーバ側 td-agent起動

紆余曲折ありましたが、上記の通りにすれば必ずセットアップできます。

◇検証環境での稼働

上記でインストール、起動ができますと、アクセスログが書かれる毎に
mongodbにどんどん入っていきます。

mongodbに正常にJSON形式のデータが入っている場合は以下のようになります。

正しく値が入らない場合は、ログ出力サーバ側の「/var/log/td-agent/td-agent.log」や、
ログ解析サーバ側の「/var/log/fluentd/fluentd.log」、「/var/log/mongo/mongod.log」を確認してください。

だいたい失敗するのは、td-agent側のtailするファイルの権限でした。
※td-agentユーザが見ることができる権限が必要

これをログ出力サーバ側を１台から１０台程度まで増やして試してみましたが、
ログ解析サーバ側の負荷（リソース）は低く、また出力側も導入前後で負荷は低い状況で安心です。
（申し訳ございません、定量的なデータは割愛します）

また蓄積後のmongodbデータベースからは、簡単なクエリで蓄積データの結果を返してくれます。
（すごく簡単なものですいません・・・）

これを駆使して作り込みを行うことで、リアルタイムな分析環境が出来上がる訳です。

◇近い将来検証していきたいこと

今回は簡単にmongodbに投入して分析環の構築を行いました。
この環境でもまあ使えますが、データ量がずば抜けて増えてくる分析データを取り扱う場合、
やはりmongodbをデータストアとして使うには運用が難しいです。

そのため、本命としてはfluentdからHDFS（Hadoop Distributed File System）にログを流し、
ログのクレンジングを行いサイズを小さくし、分散処理による高速な一次解析・集計を行い、
その集計結果をmongodb、または既存システムで利用されるMySQLに戻してあげる、
というような使い方が現実的かと考えています。

そんな検証を継続して、自社サービスに生かしていきたいと思います。

当社のサービスに競争力のある分析データを提供できるインフラを、
今後も積極的に組み込んでいきたいと思っています。