参加レポート: Fluentd Meetup – 新しい応用事例とv1に関する発表 –

fluentd
93件のシェア(ちょっぴり話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

5/13(火)に開催されたfluentdのイベント「Fluentd Meetup - 新しい応用事例とv1に関する発表 -」に参加してきました!

flm01

会場は六本木ヒルズクロスポイントの5階、株式会社フリークアウト様の本社「Hills-Garage」。超オシャレなスペースでした。ライブハウスみたいですね。

IMGP0921本イベントはトレジャーデータ様と.dotsというサービスを提供している株式会社インテリジェンス様の共催でした。主催者様、会場提供者様、ありがとうございました。

レポート

Fluentd v1 and Roadmap by 中川 真宏氏 (@repeatedly)

・v1をどうするかについてはgithubissueに全て書いてある。
 →そこに書いたものをまとめたのが今日のスライド。

・fluentd概要
 →MxNをM+Nにする、ログの収集・配送を一本化することを目標にしているのがfluentd。
 →今までバージョン呼称が統一されていなかった、gemではv0.10、コミッターでの呼び名はv10。
 →ログの収集をロバストかつハイパフォーマンスに行うことを目標。
 →早い段階からProductionで使われるようになった。
 →公開されているプラグインが250以上ある。
 →CRubyを想定して書かれている。

・v11(v0.11)は...
 →2年くらい前にv10の後に出た要望を取り込む形でv11をリリースしようという話があった。
  →ユーザがまだ少なかったのでAPIを全面的に作り直そうかと思っていた。
 →ユーザが一気に増えてしまい、APIを作り直せる状況ではなくなった。
  →v10に必要な機能を追加で取り込む形にして、v11のリリースは取りやめた。

・v1を出そう
 →v11で想定していた機能から「これはユーザにとって必要だろう」という機能を、APIの互換性を壊さずに、v10に取り込む。そしてv1としてリリースする。
 →APIの互換性があるので、v10からv1にアップデートしても基本的に影響は無い。
 →v1としてリリースすることでバージョンが分かりやすくなる、また安定しているように見える。

・must features
 →新しいconfiguration file format
  →現在、1行単位でしか設定出来ないなどの変な制限があったり、配列がサポートされていなかったりする。
   →そういった設定ファイルの困るところを改善した。
  →keyをハッシュや配列で書けるようにした。
  →Rubyのコードを書けるようになった(ex. #{ENV['KEY']})
  →--use-v1-configを指定するとv0.10から使える。
  →早めに書き換えしておくとv1リリース後も設定ファイルがそのまま使える。
 →フィルターやラベルのサポート。
  →細かい操作をするとadd_Tag、remove_tagなどを使ってtagの書き換えをするのが必須になる、しかし大変。
  →タグを「データがどこから来たのか」を分かるようにするものと定義し、フィルターでルーティングする。
  →ラベルを識別子として使うようにする、matchの下にmatchをネストさせるなど、今実装を検討中。
  →タグを使ってラベルをつけていたのを、ラベルからmatchを読んでルーティングするようにする。

・improved plugin
 →error stream→@ERRORラベルを使って処理、@がついているラベルは内部処理で使う。
 →Pluginでglobal APIを使うことがよくある、それを撤廃していきたい。
 →ログレベル(infoやwan等)を指定できるように(0.10.43で取り込み済み)

・nice to have features
 →v1がリリースされたあと徐々に入っていくだろう機能。
 →ServerEngine based
  fluentdが現在持っていないサーバ機能を組み込み。treasure dataで使っているもの。
 →Multi Process
  →1台のサーバで複数のfluentdを起動できようになる。
  →1台のサーバで複数のfluentdを起動したい場合はfluentdの設定ファイルを分けて複数起動するしか無かった。
  →Multi Processにすることで1台のサーバで複数のfluentdを起動することが出来る。
 →Zero downtime restart
  →SupervisorとWorkerでheatbeatで生存確認をして、workerが死んだら別のworkerにtcpのセッションを引き継ぐ。
 →Actor
  →fluentd pluginを書くときの定型的な部分を抽象化して短く書ける仕組み。
  →fluentd側の実装に近い記述を隠蔽出来る。

・other
 →Windowsのサポート。
 →JRubyのサポート。
 →td-agent2
  →ruby 2.1.2対応、core librariesも一気にバージョンあげる。
  →fluentd v1のconfigがデフォルトになる。
  →パッケージ名がtd-agent2という名前に変わる。
 →fluentdのWebサイトがリニューアルされるかも?

毎秒10万件でもまだ軽い!Norikra+BigQuery+Dockerで10分でつくるリアルタイムログ解析基盤 by Google Inc. クラウドプラットフォーム ソリューションアーキテクト 佐藤一憲氏 (@kazunori_279)

・リアルタイムとビッグデータという2つの課題にどう答えるか?

・100台規模のWebサーバのアクセスログを集計してグラフを書きたい。
 →過去のデータも見たい、リアルタイムでも見たい。
 →Elasticsearchでやろうと思ったが数十ギガバイト単位のデータではいっきに重くなる。

・ビッグデータの問題をどう解消するか?→Google BigQuery
 →Google自体がビッグデータをたくさん持っている、Youtube、google検索、gmail、android...
 →sqlは普通に書けて、9億件のデータを、indexが無い状態で、20秒で応答が帰ってくる。これがBigQuery。
 →Google Dremelを外部向けにしているのがGoogle BigQuery。
 →なんでそんなに早いのか?
  →Columnar Storage。
  →1TBのデータを1秒間でフルスキャンするには何台のディスクが必要か?
   →5000台。じゃあ5000台用意する。対規模並列化している。
  →並列化された各ノードを集約する中間ノードが配置されている
  →5億件のデータを"select count(*) from 4つのテーブル"して3秒で完了。
 →fluentd-plugin-bigquery by @tagomoris
  →BigQuery streaming APIを使っている、1秒間で10万行のデータが扱える。
 →BigQuery Connector For Hadoopがある。

・ビッグデータをリアルタイムで出来るか?
 →ディスク読み取りパターンとメモリ読み取りパターンの2つに分ける。
  →BigQueryはディスクをなめるパターン。
  →norikraはメモリをなめるパターン。
  →lambda architectureとして2つを一緒に使うことで実現させる。
 →norikra: リアルタイムCEP、リアルタイムでストリームに対し処理が出来る
 →fluentdで集めたデータを、リアルタイムではnorikraで、過去データはBigQueryで、集計してGoogle Spreadsheetにグラフ表示する。

HTML5 Single Page Application のイベントログ収集をFluentdで効率化している話 by Quipper, Ltd デベロッパー 本多一行氏 (@hakobera)

Quipper→HTML5、backbone.jsで作っていてamazons3で動いている。
・Single Page Applicationのイベントログで苦労した話。

・Single Page Applicationだとアクセスログが飛んでこないイベントが多数ある。
 →画面遷移だけだとjsでdomを切り替えるだけなのでapiアクセスがされていない。
 →ローカルキャッシュを利用していると2回目以降はapiアクセスが無いのでわからない。
 →ローカルでのデータ遷移がサーバ側としてアクセスにならないので解析が出来ない。

・イベントに対応したアクセスログ収集ツールを使う。
 →mixpanelflurryGoogle Analyticsoptimizely
 →mixpanelの場合
  →タグを埋め込んだら使える。
   →HTML5なのでHTMLを書き換えるだけ、楽。
  →解析用のダッシュボードなどが最初から用意されている。
 →Excelで分析したい、みたいな要求には使えない。
  →mixpalenからexportしてs3に保存するプログラムを作った。
 →他の解析ツールでもやりたい!という要求が出てきた。
  →scriptタグが増えてきてページロードが遅くなってしまう。
  →statingとproductinで解析用のIDを変えるのもつらい。
   →Googleタグマネージャで解決できる。
 →fluentdで集約したい。
  →mixpanelから移行するのは辛い。
  →mixpanelのscriptタグをそのまま使いたい。

fluent-plugin-mixpanel
 →mixpanelのタグのapi hostをfluentdにして、fluentdからmixpanelサービスにデータを投入する。絶賛検証中。
 →segment.ioというサービスがこういう機能を提供してビジネスにしている。

マゾいログ回収の話と未来 by 株式会社フリークアウト エンジニア 加藤慶一氏(@s_wool)

・fluentdでログ集約、s3、Hadoop、fluentd watcherに投入している。

・当初はrsyncでログを集約して、ログサーバからサマリーをMySQLに投入。
 →新機能開発時にログの格納場所に困り始め、一部(トラッキングログ)でTDを使い始めた。
  →良い感じなので他のログも集めたくなってきた。

・Hadoopが出来るエンジニアが入ってきた
 →全部のアクセスログをfluentdでログサーバに集約してS3とHadoopに投入、hiveクエリで確認。
 →S3に投入した後、古いデータがAmazon Glacierに入れる

・突然DCの移行が発生!→ログサーバから先行して移行開始。
 →DC間の転送はどうするか?
  →VPNは転送料がTB越えるので厳しい。
  →元々データを保存してあったS3から移行先DCのHadoopにデータコピーすることにした。

fluent-plugin-webhdfsを使ってWebHDFSへ直接転送開始、分単位で転送可能。

・このあたりでハマりはじめる。
 →S3へ転送するときに詰まる、queue size exceeds limitが発生。
 →アプリケーションサーバでログをparseするときにエラーがでる。
  →aggregatorに飛んでくるデータが壊れてる?
 →配信サーバのロードアベレージが高くなってきた。

・対処
 →S3が詰まる→fuentdを複数起動、td_monitor_agentが便利だった。
 →parseエラー→tail時のformatをシンプルにしてHDFSに入れた後に頑張るようにした。
 →複数起動したときのconfの管理はpuppetで対処。

→Elasticsearchの活用
 →APIの状況をKibanaを使って監視。
 →Hiveでログ加工したデータを入れて異常監視。

・今後
 →rsyncとfluentdの2つの仕組みが動いているので片方に集約したい。
 →fluentに全て集約するための改修(カラムの精査、フォーマットの統一など)
 →リアルタイムな異常監視が出来るようにしたい。

まとめ

今回は懇親会もあったので一緒に参加させて頂き、色々なエンジニアさんとお話させて頂きました。皆さんありがとうございました!

fuentd v1、楽しみにしてます!