Recommended
More Related Content
What's hot
What's hot (20)
Similar to Stormのパフォーマンス分析
Similar to Stormのパフォーマンス分析 (14)
Stormのパフォーマンス分析
- 2. 目次 はじめに STORMとは 分散処理のパターン 実験 –文書間の編集距離を計算するタスクを例として- まとめ
- 3. はじめに Twitter社（に買収されたBacktype社）が開発した、 リアルタイム分散処理システムSTORMが注目を 集めている 概要やインストレーションに関する資料は十分 具体的な使用例や、パフォーマンス分析などに ついての資料はまだ少ない印象
- 5. 目次 はじめに STORMとは 分散処理のパターン 実験 –文書間の編集距離を計算するタスクを例として- まとめ
- 6. STORMとは(1) 分散処理システム バッチ処理を対象とした分散処理 Apache Hadoop, Hortonworks リアルタイム処理を対象とした分散処理 Twitter STORM, Yahoo S4, jubatus 使用例 Twitter：ツイートの解析、スパム検出やパーソナライゼーション Groupon：データの分析、正規化、クリーニング
- 7. STORMとは(2) 競合システムと比較したときのSTORMの特徴 データ欠損がおこらない 分散処理に特化しており、分析系の機能はない STORMはデータ処理の失敗を検知でき、 処理失敗した際は再処理するような仕組みを持っている Jubatus:オンライン機械学習ライブラリが充実している Storm: storm-mlというプロジェクトがあったが、開発が止まっている・・・？ 分析などのアルゴリズムについては、 ライブラリを選定して使用するか、 自分で実装するしかない
- 8. STORMとは(3) STORMでの処理の流れ Bolt (A) Bolt (A) 外部 システム など 結果 出力 Bolt (B) Bolt (B) Bolt (C)・ ・ ・ Spout Bolt (A) ・ ・ ・ Bolt (B) テキストを 入力する 単語を 分割 単語を 集計 ・SpoutとBoltからなるネットワーク構造で分散処理を行う データの 入り口 データの 処理 Tuple Topology
- 9. server1 server2 STORMとは(4) STORMの構成要素 外部 システム など 結果 出力 ・ ・ ・ Spout Bolt (A) ・ ・ ・ Bolt (B) Worker(1) Worker(1) Worker(2) Worker(2) Supervisor Supervisor ZookeeperZookeeperZookeeper Nimbus Bolt (C) Bolt (A) Bolt (A) Bolt (B) Bolt (B)
- 10. 目次 はじめに STORMとは 分散処理のパターン 実験 –文書間の編集距離を計算するタスクを例として- まとめ
- 14. 分散処理を検討する際の注意点 分散処理のオーバーヘッド 分散処理が可能か？ 実行順序の依存関係 データ間の依存関係 10秒で完了するタスク 5秒？ 転送、分解、結合 などの処理で オーバーヘッドが生じる
- 15. 目次 はじめに STORMとは 分散処理について 実験 –文書間の編集距離を計算するタスクを例として- まとめ
- 16. 実験 簡単な分散処理の例をSTORMのトポロジとして実装し、 STORMクラスタをスケールアウトさせていったときの処理性能の 変化の傾向などを確かめる 実験環境：さくらのクラウドサーバ サーバのスペック：2CPU, メモリ2GB, ディスクSSD20GB Switchのスペック：ethtoolで確認したところ1000Mb/s 基本的には、一台で STORMを動かせるよう にした後、サーバを クローンしてNICの設定 を書き変えるだけで クラスタが組めた
- 18. STORMでの実装 storm-starterのSingleJoinTopologyを参考にして DistanceCalcTopologyの実装を行う。 Message Spout Distance Calculation Bolt(1) Distance Calculation Bolt(2) Distance JoinBolt Distance Calculation Bolt(5) ・・・ ID 文書 21 hogehoge ID 編集距離 21 0.78 悪例文①： この方法でやれば お金がいくらでも・・・ 悪例文⑤： ○○たんーー 会いたいよーー
- 20. とりあえず3台までで確認 サーバ台数を１台づつ増やしながら、DistanceCalcTopologyを起動し、 1秒間で処理できた文書の数を計測 100 200 300 400 500 600 700 800 1 2 3 1秒間で 処理できる 文書の数 サーバ台数 １台 2台 3台 120 120 140
- 22. オーバーヘッドの改善 現状の設計では、オーバーヘッドが大きいため十分な性能 が出ないのでは？ Message Spout Distance Calculation Bolt(1) Distance Calculation Bolt(2) Distance JoinBolt Distance Calculation Bolt(5) ・・・ID 文書 21 Hogehoge 22 Fugafuga 23 hohoho ID 編集距離 21 0.78 22 0.43 23 0.11
- 23. 再確認(1) Tupleに10個の文書をまとめて入れるようにして、再確認 100 200 300 400 500 600 700 800 1 2 3 サーバ台数 １台 2台 3台 1秒間で 処理できる 文書の数 150 220 240
- 25. トポロジの改善 Distance Calculation Bolt(1) Distance Calculation Bolt(2) Distance Calculation Bolt(5) ・・・ Distance Join Bolt Message Spout Mediation Bolt Mediator Bolt Distance Calculation Bolt(1) Distance Calculation Bolt(2) Distance Calculation Bolt(5) ・・・ Distance Join Bolt Mediator Bolt Distance Calculation Bolt(1) Distance Calculation Bolt(2) Distance Calculation Bolt(5) ・・・ Distance Join Bolt ① ② ・ ・ ・ DistanceCalculationBoltとMessageSpoutの間にMediationBoltを配置 MediationBolt からDistanceJoinBoltまでのネットワークと同一の形状の ものを生成し、つなげていく。
- 26. 再確認(2) サーバ台数を5台まで増やしていったときの1秒間で 処理できる文書の数を計測 0 100 200 300 400 500 600 700 800 1 2 3 4 5 サーバ台数 1台 2台 3台 4台 5台 1秒間で 処理できる 文書の数 150 220 400 580 740
- 27. まとめ 簡単な分散処理の例をSTORMのトポロジとして実装し、 STORMクラスタをスケールアウトさせていったときの 処理性能の変化の傾向を確かめた 十分なパフォーマンスを得るためには、タスクの粒度や boltの数、Workerプロセスの数などを調整する必要がある 調整次第でサーバ台数５台程度まで順調に処理性能が 向上することが分かった