参加レポート: Fluentd Meetup – 新しい応用事例とv1に関する発表 -
5/13(火)に開催されたfluentdのイベント「Fluentd Meetup - 新しい応用事例とv1に関する発表 -」に参加してきました！
会場は六本木ヒルズクロスポイントの5階、株式会社フリークアウト様の本社「Hills-Garage」。超オシャレなスペースでした。ライブハウスみたいですね。
レポート
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、楽しみにしてます！