fileとすると自動でファイルがローテーションされ、最新ファイルへのシンボリックリンクが作成される仕組みになっています。して画面出力したものをファイルにリダイレクトして1ファイルに集約します。出力をファイルにリダイレクトして使用しました。[K2HFTFUSESVR]FILE_UNIFY(集約)を指定して1ファイルに集約しました。出力の結果も計測しました。パフォーマンス測定結果K2HFTFUSE(JSON)が最も良いパフォーマンスとなりました。変換後のサイズで計測されているためです。レコードサイズの大きなデータの方がパフォーマンスが良いという傾向でした。良いパフォーマンスとなりました。ネットワークと高速なストレージを準備して初めて上限に達しました。限界よりも先に、ネットワークやディスク書き込み速度が上限に達します。限界を気にせず有効に使うことができます。各プロダクトの設定作業についてそれぞれのプロダクトのインストールや設定作業を行った際の特長や所感です。K2HFTFUSE設定ファイルの項目が多いので最初が難しいかもしれませんが、記述の必要な項目は少ないので、サンプルの提供やマニュアルの充実で対応できそうです。設定ファイルをコピーするだけでクラスタ化できます。fluentdコマンド1発でインストールでき、一番簡単に設定作業が終わりました。自分で設定できる通信パラメーターは少ないようです。設定ファイルを用意したあとは、コピーするだけでクラスタ化できます。kafkakafka独自の用語が多いと感じたため難易度も高いと感じましたが、意外と簡単に動作させることができました。他のプロダクトと比較して必読のドキュメントが多く、また自作プログラムからの利用が前提となっているので、使いこなすまでに至るのは時間がかかると感じました。作成という手順でした。編集することでクラスタ構成にできました。各プロダクトをログ収集ツールとして使った場合の特長です。(本来の使用用途と異なるのかもしれませんが)データ整形機能K2HFTFUSE単純な文字列置換は設定ファイルだけでできます。自作プラグインを作りやすいのも特長です。fluentd豊富なプラグインを活用すれば自作する必要がありません。kafka自作前提のようです。使って高機能を実現しています。fluentdロードバランシングのみ利用できます。使って高機能を実現しています。複数ファイルの取り扱いK2HFTFUSEディレクトリだけ指定しておけばできます。fluentd公式サイトで配布しているプラグインで実現します。速度K2HFTFUSE今回測定したレコード長全般で良いパフォーマンスでした。fluentd速度よりも使いやすさを重視しているようです。サイズレコードで高パフォーマンスとなりました。これは送信時にデータ圧縮をしているからだと思われます。fluentd一度稼働させてしまえば運用であまり手間のかからない印象でした。手動操作など、できることが多いのですが、代わりに障害対応にはある程度の熟練が必要と感じました。想定しているユースケースのひとつである、ログ転送を主目的としたパフォーマンスの調査をしました。結果として、ログ転送において想定以上のパフォーマンスを確認できました。大量のデータが書き込まれるログを転送する。多数のファイルに吐かれるログを転送、集約する。転送データの加工をする。(今回はJSON形式で試行)データ加工を簡単にプロトタイプとして試行する。いったユースケースが効果的だと思います。稼働後にサーバーのスケール(追加や削除)を頻繁に行うケース。最小限のマニュアルでシステム運用チームに引き渡す。いう特長を活かせる場面も多いと思います。kafkaと比較してみましたが、私はこの2つのプロダクトのプロフェッショナルではありません。そのため、これらのプロダクトについて精通している方がチューニングして計測した場合はもっと良い結果になると思います。同じユースケースでチューニングした結果があればぜひとも公開していただければと思います。検査をしてみたいと思います。簡単に使えて、他のプロダクトの運用ノウハウも使えるような、そんな機能改善の検討を始めました。近日中に公開できるように励みます。お知らせK2HFTFUSEのサブコンポーネントのAPIマニュアルを公開しました。簡単に使う事ができます。マニュアルサンプルコードやそれぞれのコンポーネントの紹介もこれから順次公開していきたいと思います。近日中に公開する予定です最後に、長文をお付き合いいただきましてありがとうございました。続編にご期待ください。Appendix測定方法について測定方法に至るまでの準備や試行錯誤を簡単に紹介します。インストール弊社内の開発用サーバーとネットワークを手配して各プロダクトのインストールと、チュートリアルにある疎通確認までをやってみました。私自身は今まで利用した経験がなかったので情報収集しながらのインストールとなりました。予備テスト疎通ができたので、今度はデータファイルとサーバー構成を変えながら計測してみます。1千万レコードの送信開始から送信終了までの時間を測定しました。3パターンで用意し、それぞれが受信側でファイルを書き終わるまでの時間を3回測定して平均値を取りました。2台、3台と増やしてみます。この結果を参考にして専用環境でテストする際の計測方法やデータサイズをあらためて検討しました。Byteにする事に決めました。純粋な転送能力を測定したいので受信側で集約したファイルを、10秒ごとの行数カウントとファイル削除を行い理論値を計算することにしました。これによって送信側の影響を取り除くことを試みています。計測区間それぞれのプロダクトで試したところ、転送を開始から安定的に速度が出るのに20秒程度かかっていましたので、ここからを計測区間とすることにしました。JAPANでは情報技術を駆使して人々や社会の課題を一緒に解決していける方を募集しています。詳しくは採用情報をご覧ください。JAPANのサービス開発を支える技術やデザイン、文化を発信しています。Reserved.このページの先頭へ。