Fluentdとはどのようなソフトウェアなのか
Fluentd というソフトウェアがある。日本国内ではそこそこ話題になってきたが、何ができるのか、何に使うと嬉しいのか、何に使えるのか、という点について詳細をよく知らないという人もおそらくまだ多いことでしょう。
なので、簡単にまとめる。
なお以下の個別項目ごとに書いていくが、その手前にまとめを置いておくので忙しい人はそれだけ読むとよい。インストールや設定については導入部分については日本語の記事はもう多くあるので、触れない。
- 概要
- できること
- ログの収集
- センサデータ等の収集
- 汎用データ処理プロセッサとして
- 頻出ユースケース
- ログの収集
- データの集約
- 簡単なリアルタイム集計
- ソフトウェアとしての特徴
- コア
- プラグイン
- 安定性
- 性能
- 開発体制
- コミュニティ
- ぶっちゃけどうなの？
まとめ
現時点で、複数の場所に分散したデータや常に増え続けるデータの安全な転送・収集・集約・保存あるいはリアルタイム処理などについて問題を抱えている、という人は試す価値のあるソフトウェアです。
性能や安定性についてはかなり高い水準で成功を収めていると言ってよいと思います。ほとんどあらゆる機能をプラグインで拡張でき、また公開プラグインが既に多数存在するため、機能的に足りなくて使えない、ということはほとんど無いと思います。
いっぽう激しく開発中のソフトウェアであり、また完全にコミュニティベースで発展しているものなので、長期の互換性や商用サポート等がないと導入できない、という人には難しいでしょう。
概要
Fluentd はデータのやりとりを管理するソフトウェアだ。デーモンとして動作する。今のところはLinux上での動作が主に想定されている*1。
データの中身は本来は何でもいいが、ログ*2を相手に使われることが多い。が、本来は別に何でもいい。相手を問わない。
データのやりとりを管理するには、以下のようなことができる必要がある。Fluentdはこれらの機能をすべて備えている。
- 必要なところからデータを取り出す (input)
- そのデータを必要に応じて分解(パース)する
- データのタイムスタンプを管理する
- 必要なところにデータを届ける (output)
- そのデータを必要に応じて整形(フォーマット)して保存する
- データを紛失しないよう管理する (buffer)
- やりとりの途中で何かエラーが起きたらリトライする
Fluentd は input, buffer, output という仕組みを持っており、それぞれデータの流入、Fluentd内部での管理、データの流出に対応する。Fluentdは1プロセス内にこの input/output を好きなだけ持てるので、複数のデータ入力を受け付け、複数のデータ出力先に流し込むことができる。そのように設定を書けばよい。
bufferはメモリ/ファイルどちらも使うことができる。ファイルバッファを使えば1サーバで数十GBのデータを溜めておくこともできるので、もし長時間エラーが起き続けたりしてもそのくらいのデータは後でリトライされて無事に再送される。
Fluentd の input, buffer, output はそれぞれプラグインという形で記述されている。Fluentd自身に最初から含まれているものもいくつかあるが、その他に以下のような方法でインストールできる。
- 自分でプラグインを書き、どこかのディレクトリに置いておき、それを読み込む
- 自社リポジトリ(git)に置いておき、そこからネットワークインストールする
- 公開プラグイン(gem)を使うことにし、rubygems.org からネットワークインストールする
どの方法でインストールしても同じように扱える。単に使用するプラグイン名を設定ファイル内で指定すればいい。入力/出力の方法について必要なものがなければ、単に自分で書けばよい。非常に簡単に書ける。また公開プラグインも既に200以上存在し、たとえば出力先としてはローカルのファイルはもちろん、AWS S3、Hadoop HDFS、MongoDB、Cassandra、MySQL、PostgreSQL、Redis、そのほか様々なものが既に選べる。
Fluentdはデータに「タグ」という文字列をつけて管理する。通常、どこから入力されたデータをどこに出力するかといったことはタグに対する条件を設定に記述して実現する。実際には、タグの一部分やデータの中身など様々なものを条件にタグを書き換えるプラグインなどが存在する。大抵のことはできる。
頻出ユースケース
様々な用途が既に存在するが、ここではいくつか分かりやすいものを中心に例を挙げる。
ログの収集
アクセスログ、およびアプリケーションログの収集。以下のような各段からなる。
- 動作しているサーバ(Apache, Nginx および各言語のアプリケーションサーバ)がログを出力する
- そのログを各サーバ上に起動してあるFluentdが受け取る
- Fluentdはネットワーク越しにログ集約用Fluentdに対して転送する
- ログ集約用Fluentdは集まってきたログをどこかに書き込む
- 典型的には local file, AWS S3, Hadoop HDFS, MongoDB など
一番最初のログの出力についてはふたつの方法があり、ひとつは一度 local file に書きこむもの、もうひとつはロガー経由で直接 Fluentd に送るもの。local file に書き込むのはApacheやNginxなどが対象のサーバ側を変更しづらい場合が多く、プログラムコードからアプリケーションログを送る場合はロガーを差し替えて直接 Fluentd に送る場合が多いだろう。
このようなログ収集を行うと何が嬉しいかというと、大きくは以下のような利点がある。
- 紛失を防ぐ
- 特にEC2等を使っていてローカルディスクに依存できないケースで
- 障害時の調査を容易にする
- 複数のサーバによる分散構成をとっていても全ログを一カ所に集め、時系列で並べられる
- データ分析・集計を容易にする
- 収集したデータをサービスの稼動状況の集計などに適したデータベースに直接投入できる
センサデータの集約
構成自体は前述「ログの収集」とほぼ同じになるだろうが、特にネットワーク的に分散した場所にあるデータの収集にはFluentdのバッファリング機構が効くケースがある。
センサ自体はネットワーク的に脆弱な場所にあることが多く、ネットワーク経路自体の冗長化はほぼ不可能な場合、経路の途絶が起きてもデータの収集自体が継続して行われ、また収集したデータが安全に保存され、経路の復旧とともに自動的に再送される必要がある。これを実現するために必要な機能をFluentdはすべて備えている。
また Fluentd のネットワーク転送プロトコルはMessagePackとTCPをベースにした非常に簡単なものなので、再実装も容易である。
簡単なリアルタイム集計
特にWebサービスのアクセスログを集計している場合、ログ収集・集約を行うのと同時にHTTPステータスコードやレスポンスタイムに対して簡単な集計を行うというケースがある。
ほぼリアルタイムに近い形で、ユーザのリクエストに対してエラーを返している率や極端に重くなっているページが無いかどうかなどを判定することができる。これは公開されているいくつかのプラグインの組合せで可能になる。
その集計結果を用い、ある閾値を越えたらIRCやメールなどで通知を飛ばすようにすれば簡単なリアルタイムサービス監視になる。また出力を常にグラフツールにプロットしておけば、時系列に沿ったサービスの稼動状況の記録をとれる。
汎用データ処理プロセッサとして
先に述べたように、Fluentd自体はデータのやりとりを管理するソフトウェアだ。入力があり、バッファリングして、出力する。いったんどこかにデータ出力して、更にそこからまたデータを拾って別の場所に流したりもできる。
つまり、何でもできる。ちょっとコードを書いてデータの流れの間に挟んでやればリアルタイム処理のできあがりとなる。面倒なネットワーク転送やバッファリングやエラー再送はFluentdがやってくれる。書くコードはプラグインの形にしてもいいし、あるいは1行受け取って1行を出力する古典的なUnixプログラミングでもいい、そういったプログラムを扱うための仕組みがFluentdにはある。
信じてほしい。流れているデータを処理する仕事なら何でもできる。マジで。もう自分でデータ流路を書く必要はない。
ソフトウェアとしての特徴
Fluentd はRubyで書かれている。プラグインを書くときもRubyで書く。現在のところJRubyでは動かないし、Rubiniusで動かしたという話も聞かない。
コア
Fluentd のコアは主に @frsyuki という人が書いている。行数はかなり短いが、効率を求めるあまりいろいろ複雑な構造になっており、コメントもほぼ皆無で、初心者がいきなり読む対象としてはお薦めしない。Fluentdのコードをお手本にRubyの勉強をしようというのはもっとお薦めしない。我こそは上級者なりという人のみが参考にするとよい。
とはいえ行数が行数なので、一度ざっと全部読んで頭に入れてしまえば割とわかりやすい。そういう意味で開発に参加するには敷居の低いコードである。たぶん。
プラグイン
たいへん書きやすい。手順はググるといろいろ見付かるので参考にしよう。
普通に使えるものがrubygems.orgにある誰が開発したかわからない*3ものなので、そこに不安を覚える人はいるようだ。しかしこれはコアの開発やリリースを身軽にするために必要なのだ。諦めて現実を受け入れるのがよろしい。
また、プラグインの機能や品質にもし不満があったらぜひgithubでpullreqを送ろう。いやissueを立てるだけでもいいけど。ぜひ。きっと普通に直してくれる。
安定性
使用するプラグインによる。プラグインが動作をぶっこわすとFluentd自体が簡単に止まるので。とはいえそれはプラグインが持つ自由度や性能とのトレードオフになるので、杓子定規にそこをどうにかしろと言われてもどうにかなるものでもない。
よく使われているプラグインについては最近は不安定だという話を全く聞かないので、たぶん大抵のケースでは大丈夫のはず。自分の手元でもじつに安定していて、いきなり落ちるなんてことは最近のバージョンでは皆無だと言っていいのではないかなあ。
というか、Fluentdが不安定だという人は証拠をもってこちらまでいらっしゃい。おにいさんが直してあげます。
性能
使用するプラグインによる。プラグインが超重いとFluentd自体が簡単に超絶遅くなるので。とはいえそれは以下略！
よく使われているプラグインについては以下略！
Fluentd全体はかなり高速に動くと思う。1データがよっぽど巨大でなければ秒間1万イベントくらいは普通にさばく。Fluentd自体はマルチコアをうまく扱えないソフトウェアなので、それ以上の性能が必要になる場合は自分で複数プロセスを立てて調整するか、最近出現した multiprocess plugin を使うかするとよいかも*4。
http://docs.fluentd.org/articles/in_multiprocess
というか、Fluentdがコードが悪くて遅いという人は証拠をもってこちらまでいらっしゃい。おにいさんが直してあげます。
https://github.com/fluent/fluentd/issues?state=open
あ、Ruby VM自体の性能についてはワタクシ何もわかりませんが、きっとRubyコミッタのおにいさん方が直してくれます。頑張って再現コードやベンチマークを作って bugs.ruby-lang.org に突撃しましょう。
開発体制
Fluentd自体は開発のホスティングを Treasure Data がやっている。メイン開発者 @frsyuki とメンテナ役*5 @repeatedly はそこの社員だ。で、他のコミッタは日本国内の各社に散らばっている。(たぶん)まだ日本人以外のコミッタはいない。
開発はフルにgithubでやってるので、文句があったらpullreqを送ってコミッタに「さっさとマージしろや！ もしくは文句があるならさっさとつけろや！！！」とTwitterで攻撃していると、きっとそのうち誰かが根負けして真面目に見る。どういうユースケースでどう困るのか/改善されるから嬉しいのか、が明確に書かれているほうがマージの理由になって良い。
またpullreqを送りまくり「いいかげんこの人のpullreqをマージするのめんどくさいお……。」という気分になってきた人が増えてきたらコミッタになれる。たぶん。(frsyuki以外の)コミッタも大抵は大きい変更はpullreq形式にして他のコミッタのレビューを要求している。
まあ、そういう感じなのであまり強固な開発体制とは言い難い。フルタイムの開発者もいない。誰かならないかな。
コミュニティ
明確なユーザコミュニティというものは存在しない。Google GroupにFluentdのグループがあり、MLとして使われているが、回答者側に活発な人があまりおらず、今のところは @repeatedly 無双の様相を呈している*6。
たぶん Fluentd ML でがんがん英語で回答しまくる人が出てくると思いっきり重宝されるのが確定しているので、そういうことをやってくれる奇特な教えたがりマンはどこかにいないものか。
日本国内のユーザや主要開発者間のやりとりはもっぱらTwitterが舞台となっているので、そのへんを全部フォローしておくとなんとなくのやりとりが見えるかもしれないが、そのかわり夜に唐突に美味いもの画像の爆撃を受ける可能性も高まるので油断がならない。
また数名がTwitterでキーワード検索を常に流しているっぽいので、そのへんの人が言及やblogエントリを発見して流したりする。みんなTwitterであれこれ発言してみよう！ 入れ食いだぞ！
ぶっちゃけどうなの？
何らかのデータが複数の場所にあって、それをどうにかしたい、という問題意識を抱えている人は使うことを検討すると良いと思います。それだけの価値のあるソフトウェアだと考えています。いっぽうそういった問題意識に縁の無い人は特に気にする必要はないと思います。
ソフトウェアには強固なサポートがないと使えない、という人には現時点ではおすすめできません。
ソフトウェアというのは自分で調べながら使うもんだ、という人にはおすすめできます。現時点では、よっぽど変わったことをやろうとしない限り動かないなんて局面には出会わないと思いますし、同じくよっぽど変わったことをやろうとしない限りは性能・安定性の面での問題にも当たりにくいのではないかと思います。
どうかな、と思った方はぜひ試してみてください。導入からテスト起動まで、そうそう手間や時間はかかりません。試してから考えてみても遅くないと思いますよ。
*
このエントリは Fluentd Advent Calendar 2013 の3日目でした。明日は @yoshi_ken さんです！
http://qiita.com/advent-calendar/2013/fluentd/participants
また 12月13日 に Fluentd Casual Talks #3 が開催されます。お楽しみにどうぞ。
http://atnd.org/events/45386
