株式会社クリアコード > ククログ

ククログ


Kafka Connector for Fluentdのベンチマーク

PLAZMA OSS Day: TD Tech Talk 2018 – Cooperative works for Fluentd Community の補足記事その3です。

fluent-plugin-kafkaのアウトプットプラグインをkafka-connect-fluentdで置き換えられるようにするためには、機能だけでなく性能も重要なので性能を比較した結果をまとめます。

構成

GCP上にn1-standard-2(vCPU 2, memory 7.5GB)で構築しています。OSイメージはdebian-cloud/debian-9です。

システム構成図

  • client
    • fluent-benchmark-client が入っているホスト
  • Fluentd
    • in_forward + fluent-plugin-kafkaのoutputプラグインの入ったホスト
    • Fluentdはtd-agent3で入れた1.0.2
  • Kafka
    • Kafka + kafka-connect-fluentd が入っているホスト
  • metrics
    • Fluentd + influxdb + grafana が入っているホスト
    • Fluentdはtd-agent3で入れた1.0.2
    • influxdb + grafana はDockerイメージを使用している

ベンチマークシナリオ

今回はfluent-plugin-kafkaとkafka-connect-fluentdの比較ができればいいので、送信するレコードはfluent-benchmark-clientのデフォルトのものを使用します。 JSONで表現すると以下のものとなります。MessagePackだと50byteです。

{ "message": "Hello, Fluentd! This is a test message." }

また、スループットを比較したいのでout_kafka, out_kafka_buffered, out_kafka2の各パラメータはデフォルト値のままにします。 ただし、デフォルトだと遅すぎるため、out_kafka2に関しては buffer/flush_thread_countを3に変更しています。

kafka-connect-fluentdもworker pool sizeは1としますが、KAFKA_HEAP_OPTS="-Xmx4G -Xms4G" を指定しています。

fluent-benchmark-client のパラメータは以下の通り、5分間負荷をかけるようにしました。 --n-events-per-secに与える値を変えると、負荷を大きくしたり小さくしたりできます。

fluent-benchmark-client \
        --host=$host \
        --port=$port \
        --max-buffer-size=4g \
        --flush-interval=10 \
        --n-events-per-sec=$1 \
        --period=5m

fluentd-benchmarkにあるシナリオを参考にして、--n-events-per-secの値を決めました。

  • 1000 events/sec
  • 10000 events/sec
  • 30000 events/sec
  • 50000 events/sec

ベンチマーク結果

10000 events/sec 30000 events/sec or 50000 events/sec
out_kafka out_kafka 10k events/sec out_kafka 30k events/sec
out_kafka_buffered out_kafka_buffered 10k events/sec out_kafka_buffered 30k events/sec
out_kafka2 out_kafka2 10k events/sec out_kafka2 50k events/sec
FluentdSourceConnector FluentdSourceConnector 50k events/sec FluentdSourceConnector 50k events/sec

out_kafkaとout_kafka_bufferedは30000events/secでout_kafka2とFluentdSourceConnectorは50000events/secです。

それぞれのグラフは上から順に、CPU使用率、メモリ使用量、Kafkaが処理したイベント数(直近の1分間の平均、5分間の平均、15分間の平均)、Kafkaが処理したイベント数の合計です。

「Kafkaが処理したメッセージ数の合計=指定した秒間イベント数×5分」になっていれば、イベントはKafkaで処理できています。

送信イベント数(events/sec) 平均受信イベント数(events/sec) CPU usage 全部処理できた? 備考
out_kafka 10000 10000 40%-50%
out_kafka 30000 2万弱 90%以上 ×
out_kafka_buffered 10000 10000 0%-85%
out_kafka_buffered 30000 2万弱 100% ×
out_kafka2 10000 10000 40%-50%
out_kafka2 50000 - 100% × Fluentdのバッファがあふれた
FluentdSourceConnector 10000 10000 20%以下
FluentdSourceConnector 50000 5万弱 平均66%

fluent-plugin-kafkaよりもkafka-connect-fluentdの方がメッセージのスループットが約2.5倍高かった。 また、同じイベンント数を処理する場合でもkafka-connect-fluentdの方がCPUの使用率が低かった。

メモリー使用量については、Fluentd側が正しく測定できていなさそうなので追加の検証が必要です。

まとめ

kafka-connect-fluentdとfluent-plugin-kafkaの性能を比較して、kafka-connect-fluentdの方が速いことがわかりました。

kafka-connect-fluentdは、Kafka Connecotr APIのマルチタスクをサポートしていなかったり、fluent-plugin-kafkaと同じ形式で書き込むようにしていたりするので、まだまだ性能を向上する余地があります。

タグ: Fluentd
2018-03-01

«前の記事: KafkaのメトリクスをFluentdに送信するプラグインを書きました 最新記事 次の記事: go-apt-cacherによるお手軽APT専用キャッシュサーバーの導入方法»
タグ:
年・日ごとに見る
2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|