chiba-research 2010-01-22 at rakuten meeting

Dynamic Load-Balanced Multicast for Data-Intensive

Applications on Clouds

楽天技術研究所ミーティング

東京工業大学　数理・計算科学専攻千葉　立寛

Outline

10.1.25 Dynamic Load-Balanced Multicast for Data-Intensive Applications on Clouds

  背景   クラウド   HPCクラウドに向けて   目的と成果

  他のシステムでのマルチキャスト手法と問題点   提案手法   評価   まとめ

2

クラウドコンピューティング


  クラウド利用の広まり

使いたい！   欲しい時に欲しいだけのリソース   使った分だけ支払うモデル(pay-as-you-go)   SLAによる性能保証

主にWebアプリケーションや，業務アプリケーションを対象

HPCアプリケーションにも使えないのか？

3

クラウドコンピューティング   HPCに使えるクラウド

  将来的にはSaaSなものもいける(はず   現状ではHaaSな環境がベター → Amazon Web Services

  ユーザが比較的カスタマイズしやすい   Science Cloudへ向けて

VM Monitor/resource manager

VM VM VM VM my resource others

cloud physical infrastructure = Data Center

cloud users provided virtual compute resources

black box

over HTTP, SSH

10.1.25 Dynamic Load-Balanced Multicast for Data-Intensive Applications on Clouds 仮想化されていて見えない部分も多い

4

HPC Applications on Clouds


  Compute-intensive Applications [Walker ’08]   Amazon EC2でNAS Parallel Benchmarksの性能評価   OpenMPで7-21%, MPIで40-1000%の性能低下   ネットワーク性能の低さが原因

  Data-intensive Applications   Montage*の実行性能[Deelman et al. ‘’08]やS3のr/w性能

[Palankar et al. ‘’08]を評価   ストレージ利用コストの低さ・高可用性/信頼性   S3のアクセス・I/O性能の低さ→ 性能チューニングの可能性

* http://montage.ipac.caltech.edu/

データへのI/O性能向上・性能の低さを隠蔽できれば使える！？

HPCアプリの要求を満たす性能には現時点では至らず

5

Cloud Usage Model for Data-intensive Applications - EC2/S3 case

  ユーザ・実験装置から生成される処理データをクラウドストレージへ   大量アクセスされるデータの場合，ストレージに保存したほうが低

コスト   ノードorストレージへの転送(IN)コスト = $0.10 per GB   クラウドストレージでの保存コスト = $0.15 per GB

  処理データは個々の計算ノードのローカルスペースへ   クラウドストレージのI/Oスループットは低い

  並列ファイルシステムとして直接使うのはパフォーマンス的に困難   一度ローカルに保存してから計算すべき

  要求に応じて柔軟に対応可能なインスタンスの性能   メモリ: 1.7 GB ～ 68.4 GB   ディスクサイズ: 160 GB ～ 1690 GB

cloud compute resources

cloud users cloud storage

high network transfer charge

only once

クラウドストレージから計算ノードへの処理データのマルチキャスト性能の向上が重要に

10.1.25 Dynamic Load-Balanced Multicast for Data-Intensive Applications on Clouds 6

目的と成果


  目的   クラウドでの大規模データのマルチキャストの最適化

  クラウドストレージにある処理データを高速に各計算ノードへ配布することを目指す

  成果   クラウドの特徴を考慮した２つのマルチキャスト手法(non-steal, steal)を提案   マルチキャストスループットを動的に最適化   分散システムとP2PでのマルチキャストアルゴリズムをベースにWork Stealingのアイデアを取り入れる

  ノード数・データサイズの増加に対してスケーラブル   単純なマルチキャスト手法に比べて高スループット

  non-steal: 1.6倍程度   steal: 1.7倍程度

7

Outline


  背景   他のシステムでのマルチキャスト手法と問題点

  並列分散システム   P2Pシステム   予備実験 - クラウドでのマルチキャスト   問題点

  提案手法   評価   まとめ

8

multicast algorithm on 並列分散システム

  高性能な集団通信・マルチキャストアルゴリズム   GridMPI [matsuda et al ’06]   Stable Broadcast [takahashi et al ’08]

  前提   ネットワークが安定・高バンド幅   トポロジは変化しない   モニタリングデータ利用可能

モデル化

性能計測

Bandwidth(B-C) = 800Mbps Latency(B-C) = 2ms

T = α + M/B + γ…. 性能の最適化 • Optimal Treeの構築 • アルゴリズムの適応選択 • 通信スケジューリング • アプリケーションの特性　分析結果の利用 • データ配置の変更

多数のノードでは最適化コストが高い&安定した性能とは限らない 10.1.25 Dynamic Load-Balanced Multicast for Data-Intensive Applications on Clouds

clusters and grids

WAN A

B C

D

最適な通信ツリー・トポロジ・通信スケジューリングの決定

高スループットかつ高速な転送

9

multicast algorithm on Peer to Peer

  特徴   高いロバスト性

  動的なネットワーク性能の変化への対応   ノードの動的な増減への対応 (耐churn)

  multi-hop，multi-pathでのメッセージフォワード

  データの分散とDHTなどを用いたサーチ

application-level multicast


structured overlay

  前提   P2P: ノード間が疎結合なネット

ワーク => internet   clouds: ノード間が密結合な

ネットワーク => Data Center

  structuredオーバーレイ上でのアプリケーションレベルマルチキャスト(ALM)   Scribe [Castro et al. ’02]   SplitStream [Castro et al. ’03]   BitTorrent [Cohen et al. ’03]

前提となるネットワーク性能が異なり，工夫が必要

高い耐故障性とスケーラビリティ

10

Algorithm Features Algorithm features cluster P2P multicast topology spanning tree overlay

communication type push pull network performance high row

network proximity dense sparse node-to-node performance homo. hetero.

topology stable unstable adaptability for dynamic change bad good


性能とスケーラ

ビリティの

トレードオフ

クラウドでの問題点を踏まえて最適な手法を探る必要性

性能スケーラビリティ

11

simple multicast solution - flat tree algorithm

  flat tree algorithm   個々のノードが直接データをダウンロード(1hop)   中間ノードの転送を含まず，効果的   データ転送量は重複するため無駄も多い ⇔ same regionはコスト＄0

bucket

cloud storage (Amazon S3)

compute nodes (Amazon EC2)

target file (object)

same region

十分なダウンロードスループットが得られるならば， Flat Treeアルゴリズムも有効なマルチキャスト手法の一つ


nodes

total I/O throughput

I/O bandwidth bottleneck

？

12

preliminary experiment

  experiment 1:   1ノードでのS3からのダウンロード性能を計測   試行回数:1000, ファイルサイズ: 10MB, 100MB, 1GB

  experiment 2:   flat treeでのマルチキャスト性能を計測 (実行時間, スループット)

  1GBのファイルをそれぞれのノードが同時にダウンロード

  試行回数: 10, ノード数: 8, 16, 32ノード   実験環境

  Amazon EC2/S3 (EU site)   instance type: small


experiment 1 ‒ throughput

  得られたスループットの分布にばらつき   遅いノード(4MB/sec), 速いノード(8MB/sec)の二極化   ファイルサイズが大きくなると，この傾向が顕著に

0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10 11 12

freq

uenc

y (%

)

download throughput from S3 (MB/sec)

iterations = 1000

10MB

100MB

1GB


experiment 2 ‒ comp. time & throughput

  通信完了時間は安定せず (左図)   速いノードと遅いノードで２倍以上の時間差   平均通信完了時間も150 ~ 200 secでばらつき

  複数ノードでも1ノードと同様にスループットにばらつき (右図)   速いノード(35%): 9MB/sec~   遅いノード(65%): 4MB/sec~

0

50

100

150

200

250

300

1 2 3 4 5 6 7 8 9 10

Com

plet

ion

Tim

e (s

ec)

runs

slowest average fastest


0 5

10 15 20 25 30 35 40

1 2 3 4 5 6 7 8 9 10 11

freq

uenc

y (%

)

download throughput from S3 (MB/sec)

file size: 1GB

8nodes (N = 80) 16nodes (N = 160) 32nodes (N = 320)

8 nodes

15

experiment 2 ‒ total throughput

  トータルスループットにばらつき   runごとにS3から得られるトータルスループットが変化   速いノードが次のrunでも高スループットとは限らない

  S3から得られるスループットがノード数に対してスケール   現状ではS3でのボトルネックは発生しなかった   １ノードからのコネクション数を増やしたときの性能の確認が必要

  ノードのNICレベルでのボトルネックはどの程度か

52

106

187

0 20 40 60 80

100 120 140 160 180 200

8nodes 16nodes 32nodes

tota

l thr

ough

put (

MB

/sec

)


0

10

20

30

40

50

60

70

1 2 3 4 5 6 7 8 9 10

Tota

l Thr

ough

put (

MB

/sec

)

runs

node 1 node 2 node 3 node 4 node 5 node 6 node 7 node 8

16

予備実験から得られた問題

  個々のノードのS3から得られるスループットのばらつき   fast link(35%): 8MB/sec~, slow link(65%): 4MB/sec ~   I/O性能のばらつきは予測できず

  システムによる動的な帯域制限? I/Oコンテンション?   ファイルサイズ, ノード数が増加すればするほど全体としての性能が低下   一部の速いノードと大多数の遅いノード   ノード間の差が大きいと並列計算にも影響

  ノードの利用時間の開き→ $コスト大   long-tail で見た場合の影響は大


クラウドで一般的に起こりうる問題と解決策


  クラウドストレージ   ノード数に応じて合計のI/Oスループットは向上

  並列I/Oファイルシステム? (e.g. Lustre, GFS, PVFS, etc)   データ永続性・スケーラビリティ・データアクセスシビリティ

  個々のコネクションのI/Oスループットが変動   I/Oノード(チャンクサーバ)でのコンテンション   I/Oフラクチュエーションは予測不可能

  クラウドノード内ネットワーク   ノード間ネットワーク性能は変動

  同一ホスト・NICを共有する他のVM(仮想ノード)との競合   絶えず仮想ノードのchurnが発生   突発的に発生するボトルネックリンクも予測不可能

  クラウドシステム内部でのロードバランス   ルーティング・トポロジの変化

  モニタリングデータの利用   サービスとして提供されている場合は可能   常に安定しているわけではないため，使い方も難しい

動的にI/O, マルチキャストスループットを各ノードが自律的に最適化

18

Outline


  背景   他のシステムでのマルチキャスト手法と問題点   提案手法

  クラウドでのマルチキャストへの要求   non-steal algorithm   steal algorithm

  評価   まとめ

19

Requirements for multicast algorithm on clouds

  クラウドストレージからのトータルダウンロードスループットの最大化   ノード数に対してダウンロードスループットは増加   個々のノードのダウンロードスループットの変化への動的な対応

  個々のノードのマルチキャスト時間の最小化   ノードごとのマルチキャスト時間のばらつきを抑制   数千ノード利用時にもスケール

  モニタリングデータやトポロジ推定などの情報への非依存   常にモニタリングデータ使えるとは限らない   dry runもしないことが望ましい


Algorithm Features cluster P2P clouds

multicast topology spanning tree overlay tree + overlay

communication type push pull pull network performance high row middle

network proximity dense sparse dense node-to-node performance homo. hetero. hetero.

topology stable unstable (un)stable adaptability for dynamic

change bad good good

cluster向けのmulticast手法

P2P向けのmulticast手法

proposed multicast algorithm on clouds


両方の良い特性を取り入れることで，性能とスケーラビリティを高めることを可能に

21

overview of proposed algorithms


  ２種類のマルチキャストアルゴリズムを提案   non-steal algorithm phase 1でのロードバランスなし   steal algorithm phase 1でのロードバランスあり

  どちらも Scatter (phase 1) と Allgather (phase 2) で構成   phase 1:

  ターゲットファイルをノード数で分割し，それぞれが担当範囲のデータをダウンロード

  phase 2:   ノード間にオーバレイネットワークを構築し，BitTorrent-likeな通信で不足するデータを他のノードからダウンロード

bucket S3

EC2

target file

file.part0 file.part1 file.part2 file.part3

phase 1 phase 2

[van de Geijn algorithm ’93]

22

non-steal algorithm - phase 1

0 1 2 3

0 1 2 3 ・・・・・ P-1 32KB 32KB

3 4 5 P-1 P-3 P-2

expression meaning

P 全ピース数

N 全ノード数

Ri ノードiの担当ピースID範囲 Wi ノードiの担当するピース数 i, j ノード番号 (0 ≦ i, j < N)

node 0 node 1 node N-1


  ファイルを論理的に32KBずつのピースに分割   ピースのダウンロード範囲を均等に配分

Ri = (iP

N,(i + 1)P

N− 1)  担当するピースだけを取得

  担当するピースを全て取得後，他のノードがピースを取得し終わるまで待機

23

non-steal algorithm - phase 2

  ノード間にオーバーレイネットワークを構築   ノード間の近接性を考慮 (複数サイト利用時に有効)   最大5ノードとのコネクションを確立   10 secごとにスループットの高いノードに切り替え

  BitTorrent-likeなプロトコルを用いてマルチキャスト   個々のノードが持っているピース情報を交換 [ ]   未取得のピースp を持つノードに取得要求 [ ]   ピースp を取得後，他のコネクションへ通知 [ ]   各ノードは，ピース情報を更新 [ ]


pos. list

possession(i) request(p)

have(p) update( possession(i) )

1 2

update

update

24

steal algorithm - phase 1 (1/2)   担当する範囲のピースをダウンロード後，速くダウンロードを終えたノードが他ノードのダウンロードを手助け


  Download Work Stealing   ノード間のダウンロードスループットの動的なロードバランス   ノード全体でのダウンロードスループットの向上

0 1 2 3

0 1 2 3 ・・・・・ P-1 32KB 32KB

3 4 5 P-1 P-3 P-2

node 0 node 1 node N-1

25 1. steal

1.  steal request 2.  divide work 3.  send new work

2. divide 3. send

4 5

25

steal algorithm - phase 1 (2/2) 1)  steal request

  ランダムに選択したノードに，まだダウンロードを終えていないピースがあるかどうかを尋ねる

2)  divide current work   fast node i とslow node j のこれまでのスループットをもとに現在

のnode j のwork size: W をWi, Wj に分割 3)  send new work list

  2)で決定したwork size分のwork listをノードiに新しいダウンロードタスクを割当

  ノードjも残ったダウンロードタスクをダウンロード

2 MB/sec

8 MB/sec

assigned download pieces

1) steal request 3) send new work list

slow node j

fast node i

2) divide current work

Wj = �W ∗ Bj/(Bi + Bj)�= �5 ∗ 2/(8 + 2)� = 1

Wi = �W ∗ Bi/(Bi + Bj)�= �5 ∗ 8/(8 + 2)� = 4

already downloaded not yet download


性能評価

  non-steal, steal algorithmのマルチキャスト性能をflat treeアルゴリズムと比較・評価   通信時間 (completion time) と安定性 (stability)   スケーラビリティ (node scalability)   non-stealとstealの比較 (performance analysis)

  実験環境   Amazon EC2/S3 (EU site)   instance type: small


CPU memory HDD price

small 1 ECU (1 core) 1.7 GB 160 GB $0.10/hour http://aws.amazon.com/ec2/instance-types/ ECU : EC2 Compute Unit → 1.0 ~ 1.2 GHz 相当

27

評価 ‒ completion time and stability

  1GBのファイルを8ノードに対してマルチキャスト   non-steal, stealともにflat treeと比べて性能向上

  flat treeのfastestなノードと同程度   性能のばらつきがノードごと，試行ごとで少ない

  steal: 全ノードが常に100 ~ 120 sec   non-steal: 10回目に性能が低下 ← phase 1での律速

0 20 40 60 80

100 120 140

1 2 3 4 5 6 7 8 9 10

com

plet

ion

time

(sec

)

runs


0 20 40 60 80

100 120 140

1 2 3 4 5 6 7 8 9 10

com

plet

ion

time

(sec

)

runs



non-steal algorithm steal algorithm

28

評価 ‒ node scalability

  ノード数を増加させ，1GBのファイルをマルチキャストしたときのスループットを比較   flat tree: スループットが低下

  低速にダウンロードするノードの比率が増加   non-steal, stealはノード数に対してスケーラブルな性能を達成

  non-steal: flat treeに対して1.6倍程度   steal: flat treeに対して1.７倍程度

0 1 2 3 4 5 6 7 8 9

10

4nodes 8nodes 16nodes 32nodes

tota

l thr

ough

put (

MB

/sec

)

flat tree non-steal steal


評価 ‒ finer analysis of our algorithms

  non-steal   ノード数が少ないときに性能低下

  steal   ノード数によらずに同程度の性能をキープ

  ノード数が増えると性能差が減少   phase 1での各ノードのダウンロード量が減少   phase 2での通信に比重が高まる

0

2

4

6

8

10

12

4nodes 8nodes 16nodes 32nodes

aver

age

thro

ughp

ut (M

B/s

ec)

phase 1 (steal) phase 1 (non-steal) phase 2 (steal) phase 2 (non-steal)

102

55.5 29

15 10

40

70

81 95 103

0

20

40

60

80

100

120

140

160

2nodes 4nodes 8nodes 16nodes 32nodes

com

plet

ion

time

(sec

)

phase 2 phase 1


steal algorithm

30

まとめと今後の課題


  まとめ   クラウドの特徴を考慮した２つのマルチキャスト手法(non-steal, steal)を提案   Download Work Stealingでマルチキャストスループットを動的に最適化

  ノード数・データサイズの増加に対してスケーラブル   今後の課題

  phase 1 とphase 2のオーバラップ   ノード単位でのマルチコネクション化

  ノードのNICでのバンド幅上限まで引き出す

31


  論文発表   千葉立寛 et al. “クラウド環境における大規模データブロードキャストの最適化”, HPCS2010, Jan, 2010.

  Tatsuhiro Chiba et. al “ Dynamic Load-Balanced Multicast for Data-Intensive Applications on Clouds”, CCGrid2010, to appear.

Question?

chiba-research 2010-01-22 at rakuten meeting

Documents

Transcript of chiba-research 2010-01-22 at rakuten meeting