無印吉澤

ソフトウェア開発、運用管理(俗にいう DevOps)、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

Fluentd Meetup 2015 夏の参加レポート

イベントページ: 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回は送る
      • ユースケースに合わせて使って欲しい
  • 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

  • 自己紹介

  • 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を並列で投げる
  • ユースケース

    • バグ発見機
      • 開発環境でとりあえず流しておくだけで結構バグが見つかる。重宝してる
      • ミドルウェアの更新時にも利用(OSSは特に更新頻度高い)
    • パフォーマンスの比較
      • 全く同一のhttp requestをbefore/afterの2台に投げる
  • 感想

    • 完全なshadow環境は難しい
      • POSTのパラメータ、Webブラウザ以外のアクセス
      • 意図しないデータの更新
    • それでも9割のアクセスはGETなので、テストとして有用

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を挟むパターン
  • 参考ページ

  • 質疑応答

      1. IoTデバイスでは、bi-directional communicationが必要では?
      1. Fluent-Bitはログ収集に集中。その先のロードマップは未定。

LT

fluentd対応MIDIキーボードを作ってみた (@kazunori_279)

  • 自己紹介

    • GCPのデベロッパーアドボケイト
    • Fluentdと連携するソリューションを社内外で提案した
      • Real-time logs analysis using Fluentd and BigQuery
      • GCPは本格採用し、google-fluentdというforkがある
  • Fluentd対応MIDIキーボードを作ってみた - Qiita

  • 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エンジニアが教えるプログラミング入門」という新書を出した
      • 誤解されがちだが、新人研修の内容をもとにしたもので、エンジニア向けではない
  • BigQuery

    • ストレージサーバーを容易する手間を省ける
    • すでにログを集めていたので、集約サーバーからBigQueryにログを送りたい→送れるようにした
    • データ送信の料金が問題
  • BigQueryにバッチでデータ送信すると、ストレージ料金しかかからない→バッチで安定的に送りたい

  • fluent-plugin-file-alternativeはgzip圧縮したファイルを保存できるので、これを使った
  • Jenkinsで送信。再送もJenkinsが担当
  • 1時間に1回うまく送るには、buffer_chunk_limitとbuffer_queue_limitの調整が必要