fluentdでKinesis streamsに送るときの性能確認

(2017-06-05)

localでのstreamsとproducerのbenchmark

aws-fluent-plugin-kinesismake benchmarkはlocalにDummyServerを立ち上げて送っている。

空でもいいのでroleをつけておく必要がある。

$ git clone https://github.com/awslabs/aws-fluent-plugin-kinesis.git
$ cd aws-fluent-plugin-kinesis
$ yum install -y ruby-devel gcc
$ echo 'gem "io-console"' >> Gemfile
$ make
$ make benchmark

RATEを指定しなければデフォルトで秒間1000レコードが送られる設定。 fluentdを起動してから10秒後にプロセスをkillし、そのレコード数などを出力している。

t2.microでデフォルト(RATE=1000)で実行した結果がこれ。 固める分producerの方はややパフォーマンスが落ちる。

bundle exec rake benchmark TYPE=streams
Results: requets: 20, raw_records: 9400, records: 9400
bundle exec rake benchmark TYPE=producer
Results: requets: 14, raw_records: 1005, records: 8900

RATE=3000のとき。producerではraw_recordsが1/100、リクエスト数は1/5。 streamsだとシャードを増やしていく必要があるけど、producerの方は当分大丈夫そうだ。

bundle exec rake benchmark TYPE=streams
Results: requets: 57, raw_records: 27600, records: 27600
bundle exec rake benchmark TYPE=producer
Results: requets: 12, raw_records: 241, records: 25200

RATE=10000のとき。raw_records, requestの圧縮率はさらに上がり、 パフォーマンスの差が大きくなってきている。

bundle exec rake benchmark TYPE=streams
Results: requets: 177, raw_records: 88000, records: 88000
bundle exec rake benchmark TYPE=producer
Results: requets: 26, raw_records: 385, records: 75000

実際にkinesis streamsに送ってみる

ap-northeast-1でシャードは3のKinesis streamsにt2.microインスタンス1台から送る。

<source>
  @type dummy
  dummy {"hello":"world"}
  tag dummy
  rate 1000
</source>

<source>
  @type monitor_agent
  bind 0.0.0.0
  port 24220
</source>

<match **>
  @type kinesis_streams
  region ap-northeast-1
  stream_name test

  flush_interval 1
  buffer_chunk_limit 1m
  try_flush_interval 0.1
  queued_chunk_flush_interval 0.01
  num_threads 15
</match>

秒間3000まではほとんどキューにたまらず送れる。

$ curl localhost:24220/api/plugins.json | jq
{
  ...
  "plugins": [
    {
      "plugin_id": "object:3fc0dfac66a8",
      "plugin_category": "output",
      "type": "kinesis_streams",
      ...
      "buffer_queue_length": 0,
      "buffer_total_queued_size": 17500,
      "retry_count": 0,
      "retry": {}
    }
  ]
}

4000にするとそのうちretryが発生してしまう。

{
  ...
  "plugins": [
    {
      "plugin_id": "object:3fc0dfac66a8",
      "plugin_category": "output",
      "type": "kinesis_streams",
      ...
     "buffer_queue_length": 60,
      "buffer_total_queued_size": 56544178,
      "retry_count": 5,
      "retry": {
        "steps": 5,
        "next_time": "2017-06-05 14:05:38 +0000"
      }
  ]
}

たしかにスループットが超過している。スペック通りだ。

書き込みスループットの超過

次に30シャードにしてみる。一度にシャード数は倍から半分にしかできないので作り直し。

これに秒間30000を送ってみると、キューにいくらか溜まった。

{
  ...
  "plugins": [
    {
      "plugin_id": "object:3fc0dfac66a8",
      "plugin_category": "output",
      "type": "kinesis_streams",
      ...
      "buffer_queue_length": 7,
      "buffer_total_queued_size": 7752600,
      "retry_count": 0,
      "retry": {}
  ]
}

さらに倍にして60シャード。これに秒間60000で送ってみる。キューに溜まるものの増え続けはしないのでなんとか送れてそうだ。 td-agentのプロセスがCPUを99%使っているので、このインスタンスではこの辺が限界かもしれない。

{
  ...
  "plugins": [
    {
      "plugin_id": "object:3fc0dfac66a8",
      "plugin_category": "output",
      "type": "kinesis_streams",
      ...
      "buffer_queue_length": 15,
      "buffer_total_queued_size": 16105807,
      "retry_count": 0,
      "retry": {}
  ]
}

ついでにus-east-1にも30シャードのStreamsを作成して30000送ってみたところ、キューに溜まる量が格段に増えた。 早くFirehoseやAnalyticsが東京リージョンにも来てほしい。

{
  ...
  "plugins": [
    {
      "plugin_id": "object:3fc0dfac66a8",
      "plugin_category": "output",
      "type": "kinesis_streams",
      ...
      "buffer_queue_length": 50,
      "buffer_total_queued_size": 52432436,
      "retry_count": 0,
      "retry": {}
  ]
}