イベントページ: Fluentd Meetup 2015 夏 - 2015/06/01(月) - dots.
Fluentd Meetupに参加してきました。6月上旬なのにタイトルは夏？と思わないでもないですが、まあすでに暑いですしね……。
イベント中にざっと講演内容をメモしてたので、せっかくですしブログに貼っておきます。
イベント全体の感想
v0.12の機能について断片的にしか知らなかったので、@repeatedlyさんの講演でそのへんの説明を改めて聞けて良かったです。Fluentdについては出たばかりの頃に使ったせいか、「複雑なことをやろうとするとタグの付け替えが大変」という印象が強かったのですが、FilterとLabelの機能がある今なら、だいぶ楽に使えそうですね。
あと、IoT向けFluentdであるFluent-Bitについて、開発者のEduardo Silva氏による講演もありました（今回の目玉？）。mBaaSのようなものは認識していたのですが、IoT機器からCPUなどのメトリクスやらsyslogやらを収集というのは個人的に盲点でした。まだvery early stateなプロジェクトということなので、今後に注目したいと思います。
他に気になった講演としては、@toyama0919さんによる、fluentdで収集したhttp requestをテストに利用する方法についての講演がありました。本番とテスト環境で全く同じデータベースを用意するのは難しいでしょうから、GETが多いアプリなど、うまく適用するにはいくつか前提条件がありそうに感じました。ただ、テスト自動化ができると便利なのは確かなので、更新系の少ないアプリなどで試してみたいところです。
以下、講演内容のメモです。
Fluentd v0.12完全解説 (@repeatedly)
はじめに
- 今回は使っている人前提の話
v0.10 (old stable)
- mainly for log forwarding
- robust but not good for log processing
- 日本だとほぼいろいろな分野に入った。Web、アドテク系、かなりの場所で使われている。
v0.12 (current stable)
- v1を目標に開発している。今年の年末のリリースが目標。
- v1のconfigurationをデフォルトでサポート
- v1のすべての設定はサポートされていないので、ドキュメントを読んで欲しい
- 4つの主要な追加機能
v1 configuration
- hash, array, enum型の追加（JSONと同じ形式を受け付ける）
- #{}でRubyコードを埋め込める
- Socket.gethostnameでホスト名を取れる。これはよく使われている。
- ログに、パスワードなどのセンシティブな情報を出力しないための :secret オプション
- 通常は設定ファイルの内容がすべてログに出る
Filter
- v0.10では、outputで擬似的にfilterを実装しなければいけなかった
- TDの当初の利用では不要だったが、その後フィルタが多く必要になった
- ユーザが多かったプラグイン2つと、追加で1つ入れている
- Filter: record_transformer
- record_reformerのfilter版
- Filter: grep
- Filter: stdout
- ストリームをコピーしてout-stdoutに渡す必要がなくなった
- ウィンドウの中の状態を管理したい場合、filterメソッドよりfilter_streamメソッドをいじると良い
Label
- tagを駆使してmatchさせようとすると、tagの付け替えが煩雑になる
- そういう場合はlabelでmatchさせることができるようにした
- 注意事項：全プラグインは対応していない
- Engine.emitをrouter.emitに書き換えれば、ラベル機能が使えるようになる
- Engine.emitはdeprecated
- Fluentdはchunkに分けてデータをまとめるが、output側に制約がある場合がある chunkの一部に失敗した場合、そのchunkをerror labelで抽出できる
at-least-one semantics
- v0.10はat-most-onceをサポートしてた
- 欠損の可能性あり
- 広告など、パフォーマンスが求められる分野ではこちらの方が適していた
- v0.12はat-least-onceをサポート（require_ack_response parameter）
- 重複してでも、最低1回は送る
- ユースケースに合わせて使って欲しい
- v0.10はat-most-onceをサポートしてた
HTTP RPC based management
- CRubyで実装した関係上、いままではシグナルを使っていた。
- Windowsなどに対応できるようにHTTP RPCを実装。
- RESTにするかは議論があったが、難しかった
- いまのところはFluentdで使っているシグナルを置き換えるRPCのみ持っている
- inputプラグインだけを止めたい、という要望もあり、そのRPCが増えるかも
Almost ecosystems are v0.12 based
- docs.fluentd.org はすべてv0.12ベースになっている
- td-agentも最新版からv0.12ベース
Roadmap
- v0.14を夏にリリース。ServerEngineで無停止で再起動できるようになる予定
fluentdで本番環境を再現する (@toyama0919)
スライド: 未公開？
関連記事: fluentdで本番環境を再現する - Qiita
自己紹介
- Fluentdの社内勉強会を開催
- Fluentd歴は3年くらい
- 分析系のインフラ構築メイン
- インフラ系SaaSカジュアルトーク、を6/26(金)に開催予定
- 最近増えてきたインフラ系SaaSを比較したい
- インフラ系SaaSカジュアルトーク at IPROS 〜 New RelicやTwillioなどを利用したインフラ運用ノウハウ大公開！〜 - 2015/06/26(金) - dots.
Shadow Proxy
- productionのhttp requestを複製してバックエンドに送信するproxy
- 目をつけた理由＝Web系のテストが年々複雑化、本番のデータで落ちてしまう、等
- 公開されているOSS
- cookpad/kage の事例が目立っている
- mod_mrubyを使う方法も考えたが、諸事情で断念した
- kage:「クラウドセキュリティ」という本で紹介されている
Shadow Proxyを採用しなかった理由
- フロントエンドにミドルウェアをあまり入れたくない
- 事例が聞こえてこない（安全にやりたいが、難しい？）
fluent-plugin-http_shadow
- 新たに開発した
- フロントエンドに手を入れずにShadow Proxyを再現（http requestを復元）
パラメータについて、運用して分かった問題を交えて解説
- rate
- 本番と同じrequestを、stagingではさばけない
- 最初は1%で運用し、徐々に上げていくのが安全
- timeout
- client側でbufferが詰まらないように設定
- 並列数
- http requestを並列で投げる
- rate
ユースケース
- バグ発見機
- 開発環境でとりあえず流しておくだけで結構バグが見つかる。重宝してる
- ミドルウェアの更新時にも利用（OSSは特に更新頻度高い）
- パフォーマンスの比較
- 全く同一のhttp requestをbefore/afterの2台に投げる
- バグ発見機
感想
- 完全なshadow環境は難しい
- POSTのパラメータ、Webブラウザ以外のアクセス
- 意図しないデータの更新
- それでも9割のアクセスはGETなので、テストとして有用
- 完全なshadow環境は難しい
fluent-bit (Eduardo Silva氏)
自己紹介
- コスタリカから遠隔でTreasure Dataで働いている
- 日本は今回が初めて
アプリケーションのログ収集は有用だが、今日は別の観点で話す: IoTs, embedded applications
New project: Fluent-Bit
- 目的が違うので別の物が必要
- IoTでもLoggingが必要
すでにFrameworkの標準化活動がある
- IoTivity, AllJoyn, Brillo (by google)
Fluent Bitはまだvery earlier state
Requirement
- lightweight, written in c, pluggable, integrate with fluentd
- support custom inputs/outputs
- binary serialization (MessagePack)
Features
- Built-in system metrics
- C API for developers (WIP)
システム構成
- data source（センサ）から収集したデータを集めるraspberry piなどの中継点でfluent bitが動作する
- fluent bitからstorage(s3など)に直接送信するパターンと、Fluentdを挟むパターン
参考ページ
質疑応答
- IoTデバイスでは、bi-directional communicationが必要では？
- Fluent-Bitはログ収集に集中。その先のロードマップは未定。
LT
fluentd対応MIDIキーボードを作ってみた (@kazunori_279)
自己紹介
- GCPのデベロッパーアドボケイト
- Fluentdと連携するソリューションを社内外で提案した
- Real-time logs analysis using Fluentd and BigQuery
- GCPは本格採用し、google-fluentdというforkがある
- CPUを全く使っていない
- FPGAで実装
- TCPプロトコルを処理するチップを使用、1個2000円くらい
- ハードウェアの設計をプログラミング言語でできるOSSがある（Javaで書ける）
- FPGA触り始めて2年の素人だが、ここまで簡単につくれた
Docker and Fluentd (@tagomoris)
- container、原則としてシャットダウンしたらデータは消える。外にデータを保存する必要がある。ネットワーク経由での転送が必要。
ログが混ざって、どこから来たかわからなくなるのは困る
Aggregation Pattern
- 全コンテナから個別に集めるか、ホストごとに集約するか
- どちらもメリット/デメリットあり
- ホストごとに集約するほうが、変更に対してはロバスト（設定変更時は、ホストごとのfluentdを再起動すれば良い）
ホストごとに集約する方法
- ネットワーク経由で送る
- 性能面でのデメリットは特にない
- container logger & tail
- Kubernetesはこちらのモデルで設定が行われている
- container自身のログも集約できるメリット
- パース処理などがあるので性能面では遅くなる
- Logging Driver "fluentd"
- Docker v1.6からLogging Driverという仕組みが入った
- --log-driver=fluentdのプルリクを送ってるのでv1.7.0には入るはず（syslogはすでにある）
- ネットワーク経由で送る
Fluentdの入ったdocker imageを配布中
fluentdによる大規模キュー設計 (@edvakf)
自己紹介
- pixivの漫画事業の開発責任者（元々はpixiv自体の開発責任者）
汎用ジョブキュー
- Sidekiq, Resque, MySQL Q4M, MongoDB
pixivのアクセス解析で、キューに関する特殊な要件
最初はMongoDBを考えたが、MongoDBがよく詰まる・落ちる
- すべてのアクセスに挿入できるほど信頼出来ない
- そこでFluentd（元々Apacheログの収集に使っていた）
ログをログファイルに出力し、Fluentdでバッチサーバに転送
1分間に10万行のログ、とかあっても詰まらない
ファイルとしてバッチサーバに残っているので、やり直しが容易
- 元に戻ってやり直せる
- 失敗したら停止させて、バッチを直したらログの処理を再開
転送先をACT/SBY構成にできる
大量のログをBigQueryに送ってみた (@catatsuy)
pixivでインフラを担当
- 「pixivエンジニアが教えるプログラミング入門」という新書を出した
- 誤解されがちだが、新人研修の内容をもとにしたもので、エンジニア向けではない
- 「pixivエンジニアが教えるプログラミング入門」という新書を出した
BigQuery
- ストレージサーバーを容易する手間を省ける
- すでにログを集めていたので、集約サーバーからBigQueryにログを送りたい→送れるようにした
- データ送信の料金が問題
BigQueryにバッチでデータ送信すると、ストレージ料金しかかからない→バッチで安定的に送りたい
- fluent-plugin-file-alternativeはgzip圧縮したファイルを保存できるので、これを使った
- Jenkinsで送信。再送もJenkinsが担当
- 1時間に1回うまく送るには、buffer_chunk_limitとbuffer_queue_limitの調整が必要
