二つのイベントに参加するため，札幌に行ってました．

技術セミナー２０１４～ビッグデータ時代のＩＴシーズ～

北海道IT推進協会さまのイベントで，ビッグデータとかデータ解析周りについてクラウド要素も含めて，ビジネス的な話をしてきました． 参加者に経営者の方も多い感じだったので，なるべく技術的な用語は使わないよう心がけて講演．

いつもとは違う雰囲気の中での講演で，こういうのも勉強になって良いかなと．

AWS勉強会 in 北海道札幌！

メインは上のイベントだったのだけど，それだけで北海道を去るのも勿体ないなぁと他のイベントを探していたら

話す側でお願いしますw @repeatedly あれ，よく見たらクラスメソッドさんの勉強会が次の日にある．これに参加しようかな？ > "AWS勉強会 in 北海道札幌！（懇親会有）" http://t.co/doSVv4FPb8

— よこたさとし (@sato_shi) March 5, 2014

とのreplyをもらったので，飛び入りでFluentdについて発表してきました．

Fluentd利用者も少なかったので，基本的な動作原理や，Fluentdが有用なユースケース， AWSなイベントなのでAWS関係のプラグインの紹介などなど，一通りやった．

懇親会で色々と話を聞いたけど，まだ地方？だとそもそもデータを集めてなかったり， データ解析に関しての需要が出てきておらず，Fluentdなどを使う段階になってないとのこと． そもそもIT化出来てない会社とかもあるのでまずはそこから，とも
東京とかだとこの辺の動きが活発だけど，中央以外ではまた違った形で活動しないと， 「便利なソフトウェアがある！」とかで広めることは出来ないなぁと実感．

色々と考えないと行けないことが増えた感じで，この辺の話を聞けたのは良かった．

まとめ

リリースは永遠にされません！

日本では色々なところでv11の噂がまことしやかに囁かれていますが， 俺がメインメンテナである限りv11がリリースされることはないので，諦めてv0.10.xを使ってください！

以下まじめな話になります．

v11が生まれた背景と現状

v11が生まれたのは1年以上前です．背景には，v10と呼ばれる今のバージョンがプロトタイプを兼ねたリリースであり， 「利用者のフィードバックを取り込んで，ダメな所をガッツリ書き換えて互換性を壊してメジャーバージョンアップや！」という流れがありました．

しかし，v10は十分に柔軟でかつパフォーマンスも発揮しており，コミッタ陣はそれほどモチベーションがあったわけではありません． また，プラグインによって解決出来た問題も多く，v11が生まれた時ほどユーザから「v11が欲しい！」という要望は聞かれなくなりました．

当たり前ですが，ユーザからの声がなければ「あれ，じゃあこの機能あんまり必要ないんじゃね？」ということになって削られるのはよくあることで， v11もそんな感じで開発リソースはあまり割かれなくなって行きました．
もともと空いた時間に@frsyuki，@tagomoris，@sonotsの人達がたまにコミットしていたくらいなので，直近では機能追加のコミットはほぼありません．

Fluentdのユーザ拡大

v11で互換性を壊しても大丈夫だろう，とコミッタ陣が思っていたものの一つに，当時Fluentdのプラグインの大半をコミッタの関係者が書いていた， というのがあります．
そのため，互換性を壊しても必要そうなプラグインの書き換えはすぐに終わるし， 「えいや！」と同時にバージョン上げれば被害は少ないだろうという感じです．

しかし，v10は思っていたよりも早くユーザが増え，今ではさきがけとなったWeb/アドテク業界のみならず，大小問わず様々な企業， IoTな分野など，世界的にも使われるようになってきました．
また，それにともないプラグイン数も200を越え，当初の目論見が難しくなっているのが現状です．

開発方針の変更とv1案

俺がFluentdのメインメンテナとなったのも関わってるんですが，「v11のリリースをどうするか？」という問題もハンドリングするようになりました．
個人的には「v11の機能群は有用だけど，互換性を壊してリリースするほどのものではないなぁ」というのがv11を見た結論であり， その辺やりとりしたのが以下のtogetter．

Fluentd v11 なんてなかったんだ

上のまとめにあるように，色々と話した結果，v11が持っているいくつかの機能をv10にマージし， それらが終わったらv1としてリリースしようというのが，現在の開発の方向性です．
段階的な変化になりますが，基本的には互換性が保たれるようにAPIを変えていくので， 既存ユーザはそのまま使えますし，バージョンアップにともなって徐々に有用な機能が使えるようになります．

以下のissueで必要そうな機能リストと，進捗を管理してます．

Plan for v1 release

v1というバージョンに関しては，今のFluentdのgemのバージョンがv0.10.xで，v0.11.xのことをv11と呼んでいて非常に紛らわしく， 新しく入ってくるユーザとかを考えるとそろそろまじめにバージョニングした方が良いだろうという考えです．
v1だと安定版のイメージが強いですし，実際の所v0.10.xはv1でもおかしくない機能セットはすでに持っています．

まとめ

ということで，色々と今までの流れを書きましたが，皆さんFluentdを今後とも宜しくお願いします :)

Sensu

最近人気が出てきているようなので試して見た． 仕組みに関しては本家のドキュメントとかスライドとか見ると大体分かる．

雑感:

• server, client, api, dashboardに分かれているのは良い
  • 実装はRubyでシンプルに書かれているように見える．多分弄るのは簡単
• RabbitMQとRedisが必要なのが試すのに結構つらい．chefとかpuppetを使うと良いらしい？
  • なんかテストモードがあるなら知りたい
  • ドキュメントは最低限はある．Advancedなことしようとするとgithubとか先人を頼ることになる
• 設定がJSONなのはいいけど，ログすらJSONなのは徹底している
• RabbitMQにはクライアントから登録しにいくようで，勝手に監視対象が増えるのは楽
  • マスターからのpullは限界があるので，この仕組みはモニタリングでは筋が良さそう
• プラグインは簡単に書けるが，現状失敗したら諦める前提らしい
  • まじめにハンドリングするなら，他のと連携する必要がある
• apiが気がつけば落ちてる時があって，原因がよく分からない
• Fluentdのハンドラがコミュニティプラグインになかったので書いた

「FluentdかSensuかどっちかに寄せたい」みたいな記事を誰かが書いてた記憶があるけど，何となく分かる． Fluentdのプラグイン機構でSensuのクライアント周りの機構はよりロバストに実装出来る．
コアの機能は結構シンプルなので，visualizationまで考えるとどうしたもんかという感じ．

Sensuはモニタリングのためのフレームワークなのでその辺の機能が中心に開発されてるけど， そこの尖った部分が必要でなければ，RabbitMQとかと相まって結構大がかりにも見える．
Nagiosとかは使ったことはないので，その辺と違ってどこまでメリットがあるのかはよく分かってないけど， 新しく作るシステムで一からモニタリングシステムを構築するなら十分有り．

仕組み的には柔軟でAPIとかで管理も楽に出来るようになってるので，今後ユーザは増えそうな気もしている． しかしRabbitMQとRedisの二つ必要なのどうにかならないものか…

Developers Summit 2014：開発者のためのITカンファレンス

セッション登壇も兼ねて，初めてデブサミに参加してきました．

1日目

OSSコミッタ大集合

これに登壇してました．登壇といっても，それぞれのプロジェクトの人がわいわいと自分の関わってるプロジェクトについて 交互に話すというもので，FluentdとD言語の時に壇上にあがってあれやこれや話しました．
まぁFluentdに関しては登壇して何も喋らずに降りましたが…prz

セッションに関係ないですが登壇者控え室，和室でネットワークも電源もありで環境良すぎて超快適だった．雅叙園良いですね．

2日目

「Webの現在過去未来」のセッションなど気になるのがあったのですが，雪が降りすぎていたので参加しませんでした！

それとは別に，渋谷でRubyコミッタ3人との飲み会があり，鍋をつつきつつ色々と話をした． その結果，Focuslightのメンテナが正式に決まり，FluentdにはLinux kernel & Rubyコミッタであるkosakiさんがjoin．良い鍋でした．

@sora_h and @sonots are now focuslight committer! This is great step for growing #Fluentd visualization environment :)

— Mr. Fiber (@repeatedly) February 14, 2014

@kosaki55tea is now Fluentd committer! We can improve Fluentd more quickly :) #fluentd

— Mr. Fiber (@repeatedly) February 14, 2014

Fluentd -> Elasticsearch 大量データ転送でトラブル

上の記事にあるように，Elasticsearchに大量のデータを一気に流し込むと色々と問題が起きます． 元々検索エンジンはスケールさせるのが難しく，よく当たる問題だと思います．

また，Fluentdとかだとガンガンログを流し込むことも多く，この辺で詰まる云々はたまに聞きます．

第3回elasticsearch勉強会

で，Elasticsearch勉強会にFlorianという本家のエンジニアが来ていたので， 懇親会でこの辺どうすればいいのか聞いてみました． 実際Elasticsearchユーザの中でもちょくちょく問題になるらしく， 大きくわけて二つの方法(またはこの組み合わせ)で回避しているようです．

書き込み先のノードを増やす

1ノードへの書き込みで詰まるなら，もっとノードを増やせば良いというアプローチ． 今のfluent-plugin-elasticsearchにはラウンドロビンの機能はないんですが， out_roundrobinとかと組み合わせてやれば，書き込みを複数台に散らせることは出来そうです．

前段にキューを置く

書き込みをするノードの前にキューを置いて，そこでバッファリングしておくという方法． Fluentdの場合はバッファがキューになっているので，そこのフラッシュ間隔を長めに調整するとか， キュー系のプラグインがいくつかあるので，それを間に挟むという感じになるのかなと．
ただ，キューから値をポップする間隔が短いと結局詰まるので，この辺は少し工夫が必要そうです．

まとめ

Elasticsearchを真面目に運用したことがないので，どっちが現実的なのかよく分からないのが正直な所． この辺は高トラフィック環境で使っている人の話を聞きたい所です．