Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
STORMの
パフォーマンス分析
K.Ishizuka
目次
 はじめに
 STORMとは
 分散処理のパターン
 実験 –文書間の編集距離を計算するタスクを例として-
 まとめ
はじめに
 Twitter社(に買収されたBacktype社)が開発した、
リアルタイム分散処理システムSTORMが注目を
集めている
 概要やインストレーションに関する資料は十分
 具体的な使用例や、パフォーマンス分析などに
ついての資...
発表の目的
 簡単な分散処理のプログラムをSTORMの
トポロジとして実装
目次
 はじめに
 STORMとは
 分散処理のパターン
 実験 –文書間の編集距離を計算するタスクを例として-
 まとめ
STORMとは(1)
 分散処理システム
 バッチ処理を対象とした分散処理
Apache Hadoop, Hortonworks
 リアルタイム処理を対象とした分散処理
Twitter STORM, Yahoo S4, jubatus
...
STORMとは(2)
 競合システムと比較したときのSTORMの特徴
 データ欠損がおこらない
 分散処理に特化しており、分析系の機能はない
STORMはデータ処理の失敗を検知でき、
処理失敗した際は再処理するような仕組みを持っている
J...
STORMとは(3)
 STORMでの処理の流れ
Bolt (A)
Bolt (A)
外部
システム
など
結果
出力
Bolt (B)
Bolt (B)
Bolt (C)・
・
・
Spout
Bolt (A)
・
・
・
Bolt (B)...
server1 server2
STORMとは(4)
 STORMの構成要素
外部
システム
など
結果
出力
・
・
・
Spout
Bolt (A)
・
・
・
Bolt (B)
Worker(1) Worker(1)
Worker(2)...
目次
 はじめに
 STORMとは
 分散処理のパターン
 実験 –文書間の編集距離を計算するタスクを例として-
 まとめ
分散処理のパターン
 データ分散
 タスク分散
分散処理のアルゴリズムのパターン
データ分散
 大量のデータを扱い、データの断片を個別に
処理可能な場合のパターン
大きなデータ
分割して
個別に処理
タスク分散
 処理内容が実行順序に依存しない場合の
パターン
自動車の組み立て工場のパイプラインのようなイメージ
フレーム
エンジン
タイヤ
分散処理を検討する際の注意点
 分散処理のオーバーヘッド
 分散処理が可能か?
 実行順序の依存関係
 データ間の依存関係
10秒で完了するタスク
5秒?
転送、分解、結合
などの処理で
オーバーヘッドが生じる
目次
 はじめに
 STORMとは
 分散処理について
 実験 –文書間の編集距離を計算するタスクを例として-
 まとめ
実験
 簡単な分散処理の例をSTORMのトポロジとして実装し、
STORMクラスタをスケールアウトさせていったときの処理性能の
変化の傾向などを確かめる
実験環境:さくらのクラウドサーバ
サーバのスペック:2CPU, メモリ2GB, ディスク...
実験で実装するタスク
 文書間の編集距離を計算するタスク
投稿文書
きみかわいーねー
どっかで会おうよ!
イメージ:悪意のある投稿文章を検出する
悪例文⑤
○○たんーー
会いたいよーーー
悪例文①:
この方法でやれば
お金がいくらでも・・・
...
STORMでの実装
 storm-starterのSingleJoinTopologyを参考にして
DistanceCalcTopologyの実装を行う。
Message
Spout
Distance
Calculation
Bolt(1)
...
SpoutでのTupleの放出の注意点
 Spoutではトポロジに放出するTupleの量をBoltでの
処理スピードに合わせて調整する必要がある
 放出量が多すぎるとTupleが滞留し危険
Message
Spout
Distance
Ca...
とりあえず3台までで確認
 サーバ台数を1台づつ増やしながら、DistanceCalcTopologyを起動し、
1秒間で処理できた文書の数を計測
100
200
300
400
500
600
700
800
1 2 3
1秒間で
処理でき...
オーバーヘッドの改善
 現状の設計では、オーバーヘッドが大きいため十分な性能
が出ないのでは?
文書1
計算
転送
文書2
計算
転送
文書3
計算
転送
文書4
計算
転送
文書1
計算
転送
文書2
計算
文書3
計算
文書4
計算
転送
オーバーヘッドの改善
 現状の設計では、オーバーヘッドが大きいため十分な性能
が出ないのでは?
Message
Spout
Distance
Calculation
Bolt(1)
Distance
Calculation
Bolt(2)
D...
再確認(1)
 Tupleに10個の文書をまとめて入れるようにして、再確認
100
200
300
400
500
600
700
800
1 2 3
サーバ台数
1台 2台 3台
1秒間で
処理できる
文書の数
150
220
240
トポロジの改善
 負荷のかかる計算を行うBoltは5個
 サーバ3台のときのCPUは6個
リソースを有効活用できていないのでは?
Message
Spout
Distance
Calculation
Bolt(1)
Distance
Cal...
トポロジの改善
Distance
Calculation
Bolt(1)
Distance
Calculation
Bolt(2)
Distance
Calculation
Bolt(5)
・・・
Distance
Join Bolt
Mess...
再確認(2)
 サーバ台数を5台まで増やしていったときの1秒間で
処理できる文書の数を計測
0
100
200
300
400
500
600
700
800
1 2 3 4 5
サーバ台数
1台 2台 3台 4台 5台
1秒間で
処理できる...
まとめ
 簡単な分散処理の例をSTORMのトポロジとして実装し、
STORMクラスタをスケールアウトさせていったときの
処理性能の変化の傾向を確かめた
 十分なパフォーマンスを得るためには、タスクの粒度や
boltの数、Workerプロセス...
Upcoming SlideShare
Loading in …5
×

Stormのパフォーマンス分析

  • Login to see the comments

Stormのパフォーマンス分析

  1. 1. STORMの パフォーマンス分析 K.Ishizuka
  2. 2. 目次  はじめに  STORMとは  分散処理のパターン  実験 –文書間の編集距離を計算するタスクを例として-  まとめ
  3. 3. はじめに  Twitter社(に買収されたBacktype社)が開発した、 リアルタイム分散処理システムSTORMが注目を 集めている  概要やインストレーションに関する資料は十分  具体的な使用例や、パフォーマンス分析などに ついての資料はまだ少ない印象
  4. 4. 発表の目的  簡単な分散処理のプログラムをSTORMの トポロジとして実装
  5. 5. 目次  はじめに  STORMとは  分散処理のパターン  実験 –文書間の編集距離を計算するタスクを例として-  まとめ
  6. 6. STORMとは(1)  分散処理システム  バッチ処理を対象とした分散処理 Apache Hadoop, Hortonworks  リアルタイム処理を対象とした分散処理 Twitter STORM, Yahoo S4, jubatus  使用例  Twitter:ツイートの解析、スパム検出やパーソナライゼーション  Groupon:データの分析、正規化、クリーニング
  7. 7. STORMとは(2)  競合システムと比較したときのSTORMの特徴  データ欠損がおこらない  分散処理に特化しており、分析系の機能はない STORMはデータ処理の失敗を検知でき、 処理失敗した際は再処理するような仕組みを持っている Jubatus:オンライン機械学習ライブラリが充実している Storm: storm-mlというプロジェクトがあったが、開発が止まっている・・・? 分析などのアルゴリズムについては、 ライブラリを選定して使用するか、 自分で実装するしかない
  8. 8. STORMとは(3)  STORMでの処理の流れ Bolt (A) Bolt (A) 外部 システム など 結果 出力 Bolt (B) Bolt (B) Bolt (C)・ ・ ・ Spout Bolt (A) ・ ・ ・ Bolt (B) テキストを 入力する 単語を 分割 単語を 集計 ・SpoutとBoltからなるネットワーク構造で分散処理を行う データの 入り口 データの 処理 Tuple Topology
  9. 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. 10. 目次  はじめに  STORMとは  分散処理のパターン  実験 –文書間の編集距離を計算するタスクを例として-  まとめ
  11. 11. 分散処理のパターン  データ分散  タスク分散 分散処理のアルゴリズムのパターン
  12. 12. データ分散  大量のデータを扱い、データの断片を個別に 処理可能な場合のパターン 大きなデータ 分割して 個別に処理
  13. 13. タスク分散  処理内容が実行順序に依存しない場合の パターン 自動車の組み立て工場のパイプラインのようなイメージ フレーム エンジン タイヤ
  14. 14. 分散処理を検討する際の注意点  分散処理のオーバーヘッド  分散処理が可能か?  実行順序の依存関係  データ間の依存関係 10秒で完了するタスク 5秒? 転送、分解、結合 などの処理で オーバーヘッドが生じる
  15. 15. 目次  はじめに  STORMとは  分散処理について  実験 –文書間の編集距離を計算するタスクを例として-  まとめ
  16. 16. 実験  簡単な分散処理の例をSTORMのトポロジとして実装し、 STORMクラスタをスケールアウトさせていったときの処理性能の 変化の傾向などを確かめる 実験環境:さくらのクラウドサーバ サーバのスペック:2CPU, メモリ2GB, ディスクSSD20GB Switchのスペック:ethtoolで確認したところ1000Mb/s 基本的には、一台で STORMを動かせるよう にした後、サーバを クローンしてNICの設定 を書き変えるだけで クラスタが組めた
  17. 17. 実験で実装するタスク  文書間の編集距離を計算するタスク 投稿文書 きみかわいーねー どっかで会おうよ! イメージ:悪意のある投稿文章を検出する 悪例文⑤ ○○たんーー 会いたいよーーー 悪例文①: この方法でやれば お金がいくらでも・・・ 悪例文②: まゆみさんから新着 メッセージが届いています ・・・ 判定 悪例文⑤に似ている!
  18. 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 悪例文①: この方法でやれば お金がいくらでも・・・ 悪例文⑤: ○○たんーー 会いたいよーー
  19. 19. SpoutでのTupleの放出の注意点  Spoutではトポロジに放出するTupleの量をBoltでの 処理スピードに合わせて調整する必要がある  放出量が多すぎるとTupleが滞留し危険 Message Spout Distance Calculation Bolt(1) Distance Calculation Bolt(2) Distance JoinBolt Distance Calculation Bolt(5) ・・・
  20. 20. とりあえず3台までで確認  サーバ台数を1台づつ増やしながら、DistanceCalcTopologyを起動し、 1秒間で処理できた文書の数を計測 100 200 300 400 500 600 700 800 1 2 3 1秒間で 処理できる 文書の数 サーバ台数 1台 2台 3台 120 120 140
  21. 21. オーバーヘッドの改善  現状の設計では、オーバーヘッドが大きいため十分な性能 が出ないのでは? 文書1 計算 転送 文書2 計算 転送 文書3 計算 転送 文書4 計算 転送 文書1 計算 転送 文書2 計算 文書3 計算 文書4 計算 転送
  22. 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. 23. 再確認(1)  Tupleに10個の文書をまとめて入れるようにして、再確認 100 200 300 400 500 600 700 800 1 2 3 サーバ台数 1台 2台 3台 1秒間で 処理できる 文書の数 150 220 240
  24. 24. トポロジの改善  負荷のかかる計算を行うBoltは5個  サーバ3台のときのCPUは6個 リソースを有効活用できていないのでは? Message Spout Distance Calculation Bolt(1) Distance Calculation Bolt(2) Distance JoinBolt Distance Calculation Bolt(5) ・・・
  25. 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. 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. 27. まとめ  簡単な分散処理の例をSTORMのトポロジとして実装し、 STORMクラスタをスケールアウトさせていったときの 処理性能の変化の傾向を確かめた  十分なパフォーマンスを得るためには、タスクの粒度や boltの数、Workerプロセスの数などを調整する必要がある  調整次第でサーバ台数5台程度まで順調に処理性能が 向上することが分かった

×