高速ファイル/メッセージ転送システム K2HFTFUSE のパフォーマンスについて

こんにちは。ヤフー株式会社システム統括本部の望月です。

私たちは先日、高速ファイル/メッセージ転送システムの K2HFTFUSE（ケーツーエッチ、エフティーフューズ）を公開し、この場でも紹介させていただきました。（高速ファイル/メッセージ転送 K2HFTFUSE の紹介）
前回の Tech Blog では機能やプログラムの起動方法などを説明しましたが、今回はもっと詳細なパフォーマンス測定をしてみました。

皆さんは複数台のサーバー構成でデータを収集したり、メッセージ通信が必要なときに、どんなシステムをお使いでしょうか。
fluentd や kafka を利用されている方も多いのではないでしょうか。
今回は同じ条件で fluentd と kafka とも比較してみましたので既にこれらのプロダクトをお使いの方にもご一読いただければ幸いです。

K2HFTFUSE は、データ集約を高速で簡単にできるようにすることを目指して作成したシステムです。
ファイルシステムとして mount しておけば、後はその場所に書き込むだけでデータは転送され、送信前後に独自の処理で加工したり多段構成で集約したりできます。

K2HFTFUSE を構成するサブコンポーネントの、

K2HASH（ケーツーハッシュ、KVS / NoSQL ライブラリ）
CHMPX（シーエッチエムピーエックス、通信ミドルウエア）
K2HTPDTOR（ケーツーエッチ・ティーピーディートア、トランザクション転送プラグイン）

はプログラミングAPIが用意されていて、それぞれを単体で利用もできます。

パフォーマンス測定結果

パフォーマンス結果（ボトルネックとなる環境なし）

測定した内容

3パターンのデータファイルを用意しました。

long: 4096 Byte x 1千万レコード / middle: 1024 Byte x 1千万レコード / short: 10 Byte x 1億レコード

このファイルをクライアント3台からサーバー1台に送信してデータ転送量を計測します。

使用した HWスペック

Xeon E7-4850 / 4CPU
128GB MEM
SAS 300GB x2 / RAID1 x 1 vol
Network 10 Gbps

使用した環境

OS は ubuntu 14.04 です。
ネットワーク環境は 10Gbps で用意しました。
K2HFTFUSE は OSS 版 1.0.23 を使用しています。

測定方法

3台から同時に送信を始めます。（手動なので完全に同時ではありません。）
受信側で受け取ったデータを1つのファイルに集約し、10秒ごとにファイルサイズのチェックを行って、この差分から転送量を計算します。
送信開始20秒前後からの転送量が安定した時点から100秒間の平均値を取り、これを3回行った平均値を取ります。

データの投入方法

cat [データファイル] > [転送対象ディレクトリ] で、投入しました。

データの集約方法

設定ファイルで [K2HFTFUSESVR]FILE_UNIFY(集約)を指定して1ファイルに集約しました。

パフォーマンス測定結果

レコード長	平均転送レコード数（秒）	平均転送バイト数（秒）
10 Byte	937,779	8.9 MB/S
1024 Byte	219,578	214.4 MB/S
4096 Byte	64,943	253.7 MB/S

このパフォーマンス計測で利用した方法にはそれぞれ理由がありますので、この計測方法に至った理由を以降で説明していきます。
また、環境に依存したパフォーマンス結果の違いや、他のプロダクトとの計測結果の違いなどについても説明します。

1Gbps ネットワークでの測定（ネットワークのボトルネック環境）

上記と同様に転送量の計測を目的としたテストを 1Gbps ネットワークで行った際の結果です。　結果的にネットワーク性能が不足している場合の挙動になります。

テスト環境

Xeon D-1541 2.1GHz 8コア,16スレッド
32GB MEM
SATA SSD 400GB x1 / RAID 無
Network 1 Gbps

テスト方法

転送量の計測は、10秒ごとに集約したファイルのライン数をカウントして計算値を出しました。
計測が終わるとファイルを削除して、作り直されたファイルに書き込んでいきます。

テスト結果

送信側1台、受信側1台で予備テストしていたときはレコード長が大きくなると転送量が増える傾向だったのですが、今回は伸び悩んでいました。
理論値ではネットワークの性能以上の速度が出ていると予想できます。計測結果もこの付近で上限に達しています。

外部からモニタリングツールで確認した結果、実際に回線速度の上限に達していることが確認できました。
よって、今回の計測ではネットワーク上限での挙動を見ることができましたが、本来の性能は計測できていません。
また、この計測方法では、ファイル削除・作成に時間がかかっている可能性もあるので、以降は10秒ごとのファイルサイズの差分で出すことにしました。

まとめ

1Gbps ネットワークで K2HFTFUSE を使用した場合、ネットワークの限界以上の転送能力に留意して使用する必要がありそうです。
これは適切なウエートや送信頻度などで調整できると思います。

HDD 使用環境での測定（ファイル・デバイスのボトルネック環境）

同様にファイル・デバイスの違いによる転送量の計測を目的として SSD と HDD でテストを行った際の結果です。
結果的にファイル・デバイスの性能が不足している場合の挙動が明確になりました。
ネットワークは 10 Gbps で検査しています。

テスト環境

Xeon E5-2630L 2.00GHz / 2CPU
64GB MEM
SAS 300GB x2 / RAID1 x 1 vol
Network 10 Gbps

テスト方法

10秒ごとにファイルサイズをチェックして、10秒前のサイズとの差分から転送量を計算しました。

テスト結果

図11

データサイズ middle と long で差が小さいことと、転送を継続した際にパフォーマンスが急激に下がる現象が発生したので、転送完了までの推移を確認してみました。

同時にモニタリングツールで見てみると、計測中にフリーメモリがキャッシュに割り当てられて徐々に減少し、枯渇したところで遅くなる事がわかりました。
このグラフの時は150秒付近で最高速が出なくなり、700秒付近ではフリーメモリがほぼ無くなった状態になっていました。

この計測では SSD ではなく HDD を使っているので、受信したデータを書き込む際にディスクの速度が追いつかず、最終的にメモリを使い果したと想像できます。
出力先を /dev/null にしてネットワーク帯域の使用状況を見てみると、転送完了まで途中で速度低下することなく推移したので HDD がボトルネックであると確認できました。

まとめ

転送量がディスク書き込み速度を上回るとメモリを使い果した後にパフォーマンスが低下します。
HDD で K2HFTFUSE を利用する場合には、書き込み速度（転送量）を意識して運用をする必要があります。上限に達した場合には OS 全体のパフォーマンスへの影響が考えられます。
転送能力と言う意味では上記「時間の推移と転送量」のグラフでデータが取れていると思われますが、パケットには転送データ以外の管理用データも含まれますので、
やはり実際の書き込みまでの結果が必要だとの結論に至り、高速なファイル・デバイスのある環境で再度の計測をする事にしました。