このブログやTwitterをご縁に、Fluentd meetup in Japan #2 で登壇させていただくことになり、張り切って発表してきました。

発表資料はアニメーションを多様していたのでSlideShareだとわかりづらいかもですが、アップロードしましたので御覧くださいませ。

発表資料

内容の補足

いくつか質問を受けて答えたりTwitterで見た点について、資料の補足をしておきます。

Agent -> Collector通信経路について

Q. なぜVPNにしなかったのか

A. VPNは可用性／負荷分散性の点で弱いため。また、VPNサーバや他にもGatewayなど余計な経路を通ることになり無駄である。Agentの増加に対してボトルネックができない構成にしたかったため。政治的な理由で、ある環境だけVPNをはれないといった場合もあり、総合するとGlobal＋暗号化 が良い落とし所だった。

圧縮／暗号化について

Q. どの部分で処理しているのか

A. 改造した out_forward と in_forward でやっています。参考までに圧縮は gzip、暗号化は blowfish です。圧縮は gzip か bzip2 くらいが選択肢ですが、暗号化は色々ありすぎて難しいところで、CPUコストと暗号化強度のバランスをとって決めました。

バッファ・キューの監視

やるか迷ったところですが、安定稼働に持ち込めてしまったので現在は不要と判断しています。でもどのへんが危険ラインが試験して、最低でもアラートを飛ばすくらいは入れるのがよいかとも思っています。

圧縮効率について

圧縮率が低目なのは、flush_intervalの間隔のせいかもですが、forwardに無理に入れたこともあるかもしれません。もっと効率良くできるはずです。

CPU利用率について

最初の頃にベンチマークとったときはログ流量に比例してましたが、圧縮／暗号化を入れたことで、凹凸あるトラフィックに比べて、CPUが平坦になったものと思われます。平坦な理由は、流量に対するCPUリソースよりも、圧縮／暗号化のコストの方が遥かに大きいため、トラフィック分の波がかき消された形と予想します。

Flume NGについて

Flume OGの後、NGも検討しましたが、OGで得た知識が全く無意味なくらい変化した（というか別物）ため、簡単そうなFluentdに走りました。

規模について

今のところ、Agent 300～400台 に対して Collector 5台 で運用しています。十分な安定稼働をしており、ネットワーク経路さえ間違えなければ数千台規模も問題ない印象を受けています。



Windowsだと会場の無線に繋げなかったり、VGAコネクタで表示できなかったりとハプニングが多かったですが、Twitter #fluentd を見る限りは発表自体はそこそこ好評だったようで、ホッとしています。

直接お話させていただいたりして、どんな需要があるかとか聞けたので、当分ブログネタに困らなさそうなので来週の発表が終ったらぼちぼち色々書いて行きたいと思います。

主催・参加された皆様、ありがとうございました。