Influent ベンチマーク - Part 3 #fluentd

Java 製 Fluentd サーバ、Influent のベンチマーク第三弾です。

今回は Influent マルチスレッド化の成果と、Fluentd 0.14 で導入されたマルチプロセスワーカーの性能を計測しました。

テスト概要

http://blog.okumin.com/entry/2017/01/24/002953#テスト概要

Disclaimer

http://blog.okumin.com/entry/2017/01/24/002953#Disclaimer

テスト環境

マシンスペック

送信側には Google Compute Engine asia-northeast1 リージョンの n1-highcpu-32 を、受信側には n1-highcpu-64 用いました(注: 2017/5/31現在、日本語ドキュメントには n1-highcpu-64 についての記載がないようです)。

送信側は上記スペックのインスタンスを15台用意し、それぞれ20プロセス、合計300プロセスの Fluentd が並列にイベントを送信します。

バージョン

環境構築は influent-benchmark の 43ef11b491b2eec65efd24324ef3037533f69ade で行いました。

Influent は 568f89de61190a445122fc3fc6c26bfc5839f56fを、Fluentd サーバはバージョン 0.14.16を、Fluentd クライアントはバージョン 0.12.35 を用いました。

プロトコル

Fluentd 0.12 を用いて、at-most-once(require_ack_response なし)プロトコルでイベントを送信しました。

送信クライアントに Fluentd 0.14 を用いなかった理由は以下です。

• Fluentd 0.14 で新しく追加された機能のほとんどが Influent に実装されていない
• Fluentd 0.14 の in_forward で Fluentd 0.14 の out_forward を受けるとなぜか性能が低下した
  • 多分パラメータかなにかが好ましくないんだと思います
  • 今回関心のある箇所じゃないので原因は調べてません

今回の改善ポイント

イベントループのスレッド数を調整できるよう改良しました。
単一のスレッドで動作させると CPU がボトルネックとなるため、並列度を増やすことで解決を狙います。

Fluentd 0.14 では奇しくも同じような機能を提供するマルチプロセスワーカーが導入されたので、ついでにそれと比較してみました。
Fluentd v0.14.12 has been released | Fluentd

テスト結果

Fluentd の場合はワーカープロセス数を、Influent の場合はイベントループスレッド数を増減させて、それぞれの並列度に対する最大スループットを記録しました。
いずれも並列度を増やすと、秒間1600万イベントまでは線形にスループットが向上しました。
またプロセス数、スレッド数に応じてより多くの CPU が使用されていることもわかります。
秒間1600万イベント(15〜16Gbps)で頭打ちになるのはネットワーク帯域を使い切ったのだと予想してますが、GCP のドキュメントにはインバウンド上限の記載が見当たらず、確かなことは分かってません。

	Fluentd		Influent
並列数	受信イベント数(秒間)	CPU(%)	受信イベント数(秒間)	CPU(%)
1	800,000	100	2,000,000	120
2	1,500,000	200	4,000,000	250
4	2,550,000	400	8,000,000	440
8	5,150,000	800	15,500,000	850
16	10,000,000	1600	16,000,000	950
32	16,000,000	2800	16,000,000	1000

雑感

Influent に関しては大体予想通りの結果でした。

Fluentd のマルチプロセスワーカー機能も完璧に CPU を使えていて、若干立つ瀬がなくなってきた感じがあります。
マルチプロセスワーカーが使えると運用が容易になるので、td-agent 3 にはとても期待してます。

次やりたいこと

API 再設計

前回の記事に対し frsyuki 先生にコメントいただき、イベントのデータ構造から見直そうと思い始めました。

性能最適化

今回みたいに API 設計に関係ない最適化ポイントもまだあるので、並行してやっていきたいです。