Go ahead!

Memoization for Everything

Fluentdの現実装のPros/Cons

| Comments

TODO: 必要なら図を足す

内部のイベントストリームの扱い

  • Pros: Inputがスケーラブルに実装しやすく，データストリームを正常時/エラー時で切り替えやすい
  • Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい

以下長々と理由書きます．

Fluentdはイベントストリームを効率良く，またロバストに扱うことを目的に設計されています．そのため，独自の転送プロトコル(forwardプラグイン)を実装していますし，内部のイベントのハンドリングもそれに沿うようになっています．ただ，それによって相性の悪い操作とかもあります．

Fluentdはバッファ機能を提供しており，これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています．が，あまりにも書き込み先が遅いなどの問題があると，バッファの制限を超えてしまうことがあります．
この時，FluentdはInputプラグインにエラーを返します．これによりInputプラグインはさらにエラーを外部にも伝搬させることが出来，forwardプラグインなら再送や，エラーが続くようならセカンダリに流すなどが出来るようになっています．これはデータストリームを流し続けるため，またInputプラグインがブロックせずに大量の入力を扱えるようにするため，こうなっています．

このモデルは，データがストリームではない過去ログの一括転送などと少し相性が悪いです(例えばtail -> elasticsearch)．Elasticsearchの時によく問題に当たるのですが，Elasticsearchは1台だと受け付けられるデータ量はそれほど多くなく，大量の過去ログを一気に送ろうとするとOutputプラグインのフラッシュ処理が追いつかなくなり，結果バッファが溜まっていきリミットを越えInput側にエラーが返り続けることになります(tailの場合はひたすらリトライ)．

一方，Elasticsearchと一緒によく使われるLogstashはFluentdとは違うアプローチをとっています．内部には長さ固定のブロッキングキュー(Outputのバッファではない)がInputとOutputの間に存在しており，Inputはそのキューがあくまで処理がブロックします．
そのため，上記のような過去ログの転送などでは，キューが空くまで読み込み処理は行われないのでOutput側が詰まっても，問題なくいずれは完走します．その変わりブロックしているため，外部からデータが送られてくるようなケースにおいては，このブロックがどんどん伝搬していくので，大量の入力を捌くのが難しくなります．

この辺に関しては最近のイベントでも言及されてました(ここで言われているログが抜ける云々はInput側の問題ではなくて，ESが高負荷になりすぎてES側でrejectされてるんだと思います．この記事参照)．

これらのモデルの差は

  • Fluentdはロバストなログ転送をするために
  • Logstashはログの管理をするために(昔はそれほどES/Kibanaと密結合していなかったはず)

という出生の違いによって生まれているのかなぁと思っています．

実のところFluentdで過去ログを転送している人はいて大きな問題にはなってないのですが，どうしてもキャパシティが足りないところに無理にやろうとすると，上記のElasticsearchのような問題が起きたりするので気をつけましょうという感じです(一括転送専用にバッファをチューニングするのは面倒だったりしますし…)．

今だとEmbulkがあるので，大量データの一括転送はそちらを使ってくださいという流れになりますが，ブロックする挙動があっても損はないとは思うので，うまくバッファのAPIが整備出来れば，back-pressureっぽい機能は入れようかとは思ったりはしてます(fluent/fluentd #569)．

今回はFluentdとLogstashしか言及してませんが，他にもいくつかログ収集のプロダクトは存在しているので，上記のイベントのライフサイクルや，転送プロトコルでどういうセマンティクスがあるのかなどは，使う場合には一通りチェックした方が良いと思います．

Comments