こんにちは。@sonots です。
02/15(金)の Fluentd Casual Talks #2 at :D で発表をしてきたので、資料をあげます。
ustream はこちら http://www.ustream.tv/recorded/29298222
160人規模の勉強会で、募集が始まって２時間であっとういまに埋まったのは驚愕でしたね。どんだけ Fluentd 人気あるんだと。
当日は10人の発表者が１人5分 or 10分の持ち時間で Fluentdに関する話をカジュアルに発表しました。カジュアルといいながら皆ガチで発表するのが Casual Talks クォリティ。
で、私の発表では最近作っている Haikanko という Fluentd クラスタ管理ツールの話をしてきました。
この Haikanko (配管工) というツールは、例えばログ監視を追加したい（抜きたい）とか、ログ情報からグラフ生成をしたいといった設定をすると、その設定情報から Fluentd の(複雑な？)設定ファイルを自動生成し、Fluentd クラスタにデプロイすることができるという、カジュアルに Fluentd クラスタを運用するためのツールです。
なぜわざわざそんなものを作っているのかというと、弊社でグローバル展開をしている都合上、中国など他の拠点でこの Fluentd のシステムを使ってもらいたいと思っているのですが、その際に Fluentd の設定ファイルはこう書くんだ、とか、このプラグインを使えばいいみたいだよ、とかそういうやり取りをするよりは、私のほうでユースケース（やりたいこと）ベースで要望を受けてシステムを提供したほうが良いと思っているからなんですね。
発表でも話したように、Fluentd のノード数は爆発しがちなので、自動デプロイ機能が必要だとか、設定ファイルも爆発しがちなので、設定ファイルの自動生成機能が必要だ、とかそういう理由ももちろんあるのですが、一番の理由はやはり上記の理由になる気がしています。
「まとめ」でも言ったのですが、Fluentd やそのプラグインは汎用的な仕組みまでは提供してくれるのですが、やりたい機能（ログ監視とかグラフ生成とか）そのものを提供してくれるものではないので、アプリ層のものが１つ必要だと思います。そのアプリ層のものとして Haikanko があるわけですね。
さて、このあたりで勝手にQ&Aをしてみます。こういう質問くるかな？と思っていたものです（質疑応答の時間がなかったのであれでしたが）
Q. chef ではだめなの？
A. Haikanko の裏側で使っている mina の代わりに capistrano とか chef とかを使ってもいいとは思います。chef と Haikanko の比較、という意味であれば、chef はフレームワークというか仕組みを提供するレイヤーのツールで、Haikanko はアプリレイヤーのものなので比較するレイヤーが違うかもしれませんね
Q. 設定ファイルを erb で生成しなくても fluent-plugin-forest とか fluent-plugin-config-expander もあるけど
A. それらも検討したのですが、設定爆発の問題に対しては erb でループ回して生成したほうが応用が効いて、カジュアルだと判断したのでそうすることにしました。ruby コードがかけるので、最悪、なんでもできますし、そういう状況にしておかないと他拠点からの要望にカジュアルに答えられませんからね。＃そもそも、config-expander を使うようにしても、config-expander の for ループの値を生成するために、erb のほうでループ回さないといけないんですよね。ならもう erb だけでも良いかと。
Q. OSS化はしないの？
A. したいと思っています。Haikanko を提供できるようになると、:DeNA で使っている Fluentd のシステムを気軽に他社さんが導入できるようになるので、結構 life changing なんじゃないかなぁと思っています。ただ、社内で便利に使えるように社内ツールとの連携をしたいと思っているのですが、それをしてしまうと、他社の環境で動かなくなってしまうわけで、そのあたりで悩んでいるのが現状ですね。どうしようかなぁ。
後半の Fluentd 側の話に続きます。
02/15(金)の Fluentd Casual Talks #2 at :D で発表をしてきたので、資料をあげます。
ustream はこちら http://www.ustream.tv/recorded/29298222
160人規模の勉強会で、募集が始まって２時間であっとういまに埋まったのは驚愕でしたね。どんだけ Fluentd 人気あるんだと。
当日は10人の発表者が１人5分 or 10分の持ち時間で Fluentdに関する話をカジュアルに発表しました。カジュアルといいながら皆ガチで発表するのが Casual Talks クォリティ。
で、私の発表では最近作っている Haikanko という Fluentd クラスタ管理ツールの話をしてきました。
この Haikanko (配管工) というツールは、例えばログ監視を追加したい（抜きたい）とか、ログ情報からグラフ生成をしたいといった設定をすると、その設定情報から Fluentd の(複雑な？)設定ファイルを自動生成し、Fluentd クラスタにデプロイすることができるという、カジュアルに Fluentd クラスタを運用するためのツールです。
なぜわざわざそんなものを作っているのかというと、弊社でグローバル展開をしている都合上、中国など他の拠点でこの Fluentd のシステムを使ってもらいたいと思っているのですが、その際に Fluentd の設定ファイルはこう書くんだ、とか、このプラグインを使えばいいみたいだよ、とかそういうやり取りをするよりは、私のほうでユースケース（やりたいこと）ベースで要望を受けてシステムを提供したほうが良いと思っているからなんですね。
発表でも話したように、Fluentd のノード数は爆発しがちなので、自動デプロイ機能が必要だとか、設定ファイルも爆発しがちなので、設定ファイルの自動生成機能が必要だ、とかそういう理由ももちろんあるのですが、一番の理由はやはり上記の理由になる気がしています。
「まとめ」でも言ったのですが、Fluentd やそのプラグインは汎用的な仕組みまでは提供してくれるのですが、やりたい機能（ログ監視とかグラフ生成とか）そのものを提供してくれるものではないので、アプリ層のものが１つ必要だと思います。そのアプリ層のものとして Haikanko があるわけですね。
さて、このあたりで勝手にQ&Aをしてみます。こういう質問くるかな？と思っていたものです（質疑応答の時間がなかったのであれでしたが）
Q. chef ではだめなの？
A. Haikanko の裏側で使っている mina の代わりに capistrano とか chef とかを使ってもいいとは思います。chef と Haikanko の比較、という意味であれば、chef はフレームワークというか仕組みを提供するレイヤーのツールで、Haikanko はアプリレイヤーのものなので比較するレイヤーが違うかもしれませんね
Q. 設定ファイルを erb で生成しなくても fluent-plugin-forest とか fluent-plugin-config-expander もあるけど
A. それらも検討したのですが、設定爆発の問題に対しては erb でループ回して生成したほうが応用が効いて、カジュアルだと判断したのでそうすることにしました。ruby コードがかけるので、最悪、なんでもできますし、そういう状況にしておかないと他拠点からの要望にカジュアルに答えられませんからね。＃そもそも、config-expander を使うようにしても、config-expander の for ループの値を生成するために、erb のほうでループ回さないといけないんですよね。ならもう erb だけでも良いかと。
Q. OSS化はしないの？
A. したいと思っています。Haikanko を提供できるようになると、:DeNA で使っている Fluentd のシステムを気軽に他社さんが導入できるようになるので、結構 life changing なんじゃないかなぁと思っています。ただ、社内で便利に使えるように社内ツールとの連携をしたいと思っているのですが、それをしてしまうと、他社の環境で動かなくなってしまうわけで、そのあたりで悩んでいるのが現状ですね。どうしようかなぁ。
後半の Fluentd 側の話に続きます。
