参加レポート: Fluentd Meetup – 新しい応用事例とv1に関する発表 –
5/13(火)に開催されたfluentdのイベント「Fluentd Meetup - 新しい応用事例とv1に関する発表 -」に参加してきました！
会場は六本木ヒルズクロスポイントの5階、株式会社フリークアウト様の本社「Hills-Garage」。超オシャレなスペースでした。ライブハウスみたいですね。
本イベントはトレジャーデータ様と.dotsというサービスを提供している株式会社インテリジェンス様の共催でした。主催者様、会場提供者様、ありがとうございました。
レポート
Fluentd v1 and Roadmap by 中川 真宏氏 (@repeatedly)
・v1をどうするかについてはgithubのissueに全て書いてある。 →そこに書いたものをまとめたのが今日のスライド。
・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にすることで１台のサーバで複数の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アクセスが無いのでわからない。 →ローカルでのデータ遷移がサーバ側としてアクセスにならないので解析が出来ない。
・イベントに対応したアクセスログ収集ツールを使う。 →mixpanel、flurry、Google Analytics、optimizely →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、楽しみにしてます！
