Transcript B(1)

A Low-Stretch Object Migration
Scheme for Wide-Area
Environments
2007.2.16
電子情報工学科4年
近山・田浦研究室
50390 弘中 健
Background

大域環境での分散オブジェクト指向言語

JavaRMI, CORBA



Web-service
分散データベース
scalableで、適応的な並列分散計算は考え
られてない
Background

適応的な並列計算


特定計算nodeにobjectが固定されていることは制約が大きい
Object Migration

性能向上


負荷分散


local nodeに置くことでアクセスコストの削減
object配置を変更して、ノード間負荷分散
柔軟性

ノード脱退もobjectを追い出すことで可能
Motivation

ただし、objectは移動しても既存のレファ
レンスは有効である必要がある

何らかで位置情報の更新をする必要がある
B
A
?
C
REFERENCE
Motivation

object migrationの実装例は数多くある





JavaParty [Philippsen et al. 1997]
Mozart [Van Roy et al. 1999]
ProActive [Baude et al. 2000]
location server, home node, …
今まで大域環境を考慮した実装はありま
せんでした
Contribution


大域的な環境で有効なobject migration
手法の提案
並列分散プログラミングが出来る オブ
ジェクト指向 middlewareの実装



object migration
mobile objectへの透過的なRMI
通信時間を考慮したrouting
objectの追跡

大域環境では


ただ追っていくと、不必要な大域的通
信が急増
STRETCHが大きくなる

actual / optimal path ratio
CLUSTER B
cluster 間を飛ぶ必要がなかった
CLUSTER A
位置情報の更新

全部のレファレンスを更新は避けたい


メッセージ数が膨大になる
不必要な更新も多い
UPDATE
CLUSTER A
CLUSTER B
有るべき形

大域的通信は控える

objectへのaccessメッセージ


stretchの小さいアクセス
更新メッセージ

遠隔で、無関係なノードに通知しない
Our Proposal

広域ネットワークで有効なobject
migrationのヒューリスティックス


限定された範囲で更新メッセージを伝搬
オブジェクトが移動しても、高い確率で
optimal access pathの定数倍のstretch
でアクセスが出来る




Related Work
Proposal
Results
Conclusion
Address Forwarding Protocol

[Fowler 86]

objectの移動順に追う
利点：
 ネットワーク通信
が限定される
欠点：
 high-latency, multi-hop
環境では、forwardingが
連鎖的に起きると
大きなstretch


FORWARDING
A
dst:A
B
dst:B
dst:C
D
OBJ.
PATH OF ACCESS
C
Mobile Networks

DSDV [Perkins et al. 94]




AODV [Perkins 97]



mobile agentの移動ごとに情報をbroadcast
常に最新の位置を把握
scalableではない
access時に位置をbroadcastで把握
on-demandな手法による遅延の問題
SHARP [Ramasubramanian 03]


DSDV, AODVの折衷
ただし、二つの使い分け方はあいまい




Related Work
Proposal
Results
Conclusion
Proposal : Overview


計算参加ノードでoverlay network
ノード間でshortest path routing table


各ノードを根としてrouting treeが
構成される
dst
各edgeの距離は
通信時間を使いました。
ROUTING
TREE
Proposal : Overview

objectが動くと、移動距離と比例した範囲
でupdate msgをbroadcastする
RANGE OF UPDATE MSG.
REFERRING TO NODE: B
B
OBJ.
A
C
RANGE OF UPDATE MSG.
REFERRING TO NODE: C
stretchの保証
アクセス間隔に一回しかobjがmigrateしない場合
migrateした距離の k倍の範囲にbcastすれば
アクセスはoptimal pathの 1+2/k 倍でバウンドされる
ことを証明した。


B
A
Pa/Po <= 2/k + 1
actual path : Pa
optimal path : Po
C
updateの節約

さらに、updateメッセージを節約する手法
を提案します
optimization 1

msgは新しいhost nodeをrootとしたrouting
treeに沿って伝搬されればメッセージ数を抑え
new dst
られる。
parent
child
optimization 2
new dst
old dst
B
A
parent
child
C
D
Implementation

Pythonをライブラリで拡張


近山・田浦研B4 澤井 と共同開発
move()を実装


オブジェクトを任意のあて先 dst_pidに動かす
obj.move(dst_pid)
4 cluster, 300 nodesで動作確認をしました
demonstration
randomized work stealing




[Blumofe et al. 1999]
Problem Setting: 一つの問題を処理するのですが、

親jobは子jobを生成し、親jobは子jobの完了結果を用いる

生成された子jobが優先的に処理される
生成され、未処理のjobはstackに入れられる
プログラムは一つのプロセスから開始します
stack
PP
RETURN
待機中
P1
PP
P2
P2
完了
C1
C2
実行中
demonstration
randomized work stealing


jobのないprocessは他プロセスからjobをstealする
親jobが遠隔ノードにstealされた場合、子jobは遠隔
ノードに結果を返さないといけない
 stealをmoveで実装
 moveしたobjectへ多数のRMIが発生する
Proc 0
Proc 1
MOVE
P2
RETURN
C2
P2




Related Work
Proposal
Results
Conclusion
Results

stretchでは、既存のForwarding
Address手法との比較


どのくらいの範囲に伝搬するかを変えながら
実験
更新msg数では、どのくらいの範囲に伝
搬するかで比較をしました
実験環境
HONGO:
66 nodes
within cluster: 0.060[ms]
CHIBA:
64 nodes
within cluster: 0.065[ms]
6.7 [ms]
10.7 [ms]
KASHIWA:
66 nodes
within cluster: 0.100[ms]
4.2 [ms]
stretchの実験の手法


objがR回migrationした後、アクセス
最適なパスでアクセスした時間と、実際にアク
セスに掛かった時間の比
MIGRATION
optimal path
stretchの実験結果(従来)
大きいRでstetchが非常に大きくなる
Forwarding Address Scheme
25
R=5
R=10
Access Stretch
20
15
10
5
0
0
100
200
300
Access Iterations
400
500
stretchの実験結果(提案)
Our Scheme(k=1)
14
Access Stretch
12
R=5
R=10
10
Rが変化しても、安定した low stretch
8
6
4
2
0
0
100
200
300
Access Iterations
400
500
stretchの実験結果(提案)
Our Scheme(k=0.5)
R=5
R=10
14
Access Stretch
12
10
8
6
4
2
0
0
100
200
300
Access Iterations
400
500
stretchの実験結果(提案)
Our Scheme(k=0.2)
R=5
R=10
14
Access Stretch
12
10
8
6
4
2
0
0
100
200
300
Access Iterations
400
500
メッセージ数の実験

object がランダムに100回migrationをし
た場合の更新メッセージの総和

更新メッセージの伝搬する範囲を変化さ
せて実験し、更新の局所性が保たれてい
るか検証しました
メッセージ数の実験
Histogram of Update Message Propagation
小さいkでobjectの近隣の
ノードのみに伝搬
1600
1400
1200
1000
800
600
k=1
k=0.5
k=0.2
400
200
0
0.05クラスタ内の伝搬
0.1
0.2
0.5
1
2 クラスタ間の伝搬
5
10
20
Propagation [ms]




Related Work
Proposal
Results
Conclusion
Conclusion

Muti-cluster環境において

常に安定して低いaccess stretchを実現


伝搬する範囲を制限しても、大きく性能に影響はな
い
更新メッセージの伝搬範囲を制限

メッセージの局所化を考慮した、効率的な伝搬が出
来ました
Future Work

オブジェクトが続けて複数回migrateする
場合における、stretch保証の研究

実アプリケーションを用いた検証
Background

分散した計算資源でのプログラミングが盛ん

クラスタ内計算


一様, 低遅延( order of [us])
クラスタ間計算

ヘテロ, 高遅延 ( order of [ms])
Background

object migrationの効果

性能向上


負荷分散


local nodeに置くことでアクセスコストの削減
object配置を変更して、ノード間負荷分散
柔軟性

ノード脱退もobjectを追い出すことで可能
Motivation

有るべき形とは
cluster間のものは
cluster間通信
常にSTRETCHが小さく抑えられたアクセス
CLUSTER B
CLUSTER A
cluster内のものはcluster
内の通信
Motivation

有るべき形とは
メッセージは局所的で限定されている
UPDATE
CLUSTER B
CLUSTER A
Proposal : Overview


あるノードへの距離は、そのノードをroot
とした木での深さ
destination
ＴＩＭＥ ＯＵＴ！
distance
stretchの保証 (根拠)

node間routingが常にshortest pathで
routingされて居る時は、距離で三角不等
式が成立する

|Rac – Rbc | <= Rab <= Rac + Rbc
Rab
A
B
Rbc
Rac
C
inter-node routing structure

一般なグラフでもあるnodeへのroutingは
木をなしている
destination
parent
child
Aggressive Migration

実験

ある時間周期でオブジェクト1000個がグ
ループでmoveする



周期も変えて実験
1ノードからの100 access時間を測定
forwarding pointerとの性能比較
Aggressive Migration
Total Execution Time [ms]
16000
14000
12000
提案手法ではmigration頻度が上がっ
ても安定したアクセス時間
10000
kにあまりよらず良性能
8000
Forwarding Address
Scheme
Our Scheme(k=1)
Our Scheme(k=0.5)
6000
Our Scheme(k=0.2)
4000
2000
0
0
0.5
1
1.5
Migration Frequency [Hz]
2
2.5
Message Overhead
40000000
Total Message Count
35000000
kを小さくして抑えることが
出来る
30000000
25000000
20000000
15000000
10000000
5000000
0
Forwarding
Address Scheme
Our
Scheme(k=1)
Our
Our
Scheme(k=0.5) Scheme(k=0.2)
Message Overhead
Update Message Traversal Cost
Traversal Cost [ms]
12000
動いた距離に対して伝搬の比
10000
を小さくすると、updateは局所的になる
8000
6000
4000
2000
0
0
0.2
0.4
0.6
0.8
Propagation Ratio: k
1
1.2
Message Overhead
Update Message Count
35000000
Simple Update
30000000
optimizationなしの1/6程度
Broadcast Scheme
overlayのdensityに依存
25000000
Our Scheme
20000000
15000000
10000000
5000000
0
0
0.2
0.4
0.6
0.8
Propagation Ratio: k
1
1.2
Analysis

現実問題、動いた距離の分数距離で十分



1/2、1/5 くらい
激しくmigrationがある環境でも、forwarding
pointerよりもはるかにlatencyはよい
単純なbroadcast methodと提案手法



ほぼ同性能
msg数的には、圧倒的に提案手法が良い
routing table次第でもある

shortest path routing tableが作れればなお更良い





Related Work
Proposal
Preliminary Results
Analysis
Conclusion
Conclusion

大域環境になればなるほど、migrationはoverheadを
伴うものである。




その後のaccessとのtrade-offになる
objectの集団移動が起こるような環境ではなおさら
programmerに下の層を意識させたプログラミングを強いる
object migrationが気軽に使える、solutionになるため
には、本研究のような工夫が必要


objectがどのように動いても、optimal pathと桁違いをしない
latencyでaccess出来ることが必要である
また、そのoptimizationが本業務を圧迫するようなことがあっ
てはいけない

msgでbandwidthが潰れる
NETWORK A
NETWORK B
access path
optimal path
OBJ.
RANGE OF UPDATE MSG.
REFERRING TO NODE: B
OBJ.
D
B
A
C
OBJ.
b
a
d(a,c) ≦ d(a,b) + d(b,c)
d(b,c)
c
destination node
parent
child
optimization 2
old object host
new object host
A
B
parent
child
C
D






hongo-shepherd: 4.2 ms
hongo-chiba: 6.7 ms
chiba-shepherd:10.7ms
hongo-hongo: 0.05 - 0.07ms
sheep-sheep: 0.1ms
chiba-chiba:0.06-0.07ms
実験環境
HONGO:
66 nodes
within cluster: 0.060[ms]
CHIBA:
64 nodes
within cluster: 0.065[ms]
6.7 [ms]
10.7 [ms]
KASHIWA:
66 nodes
within cluster: 0.100[ms]
4.2 [ms]
Objectのアクセス(1/2)

アクセスメッセージはオブジェクトがあると
思われる方向にルーティングされる

あて先


自分のノードが持っている情報を基に決める
若しくは、objectのunique IDに埋め込まれてい
るbirth placeに設定する
Objectのアクセス(2/2)

より新しい情報が優先される
GOTO NODE: C
GOTO NODE: B
B
OBJ.
A
A → B → C → Dのpath
をshort-cut出来ている
C
DST: B
DST: C
PATH OF ACCESS MSG.
DST: A
D
Leaving Nodes

src nodeは周囲に情報を伝搬している


周辺のノード達がその後forwardingを担う
少なくとも隣接ノードに情報を伝搬すれば、
安全に脱退できるプロトコルが実装出来
る
Broadcast Range

広範囲にbroadcastをする理由はshortcuttingのため

どの範囲でbroadcastすればよいか？
Broadcast Heuristics

Distance Effect


Mobility Rate


動きは、近くにあるノードほど大きく感じる
速度が大きいほど
変化を強く感じる
MIGRATION
変化を感じない場所に
通知する必要はない
B
A
OBJ.
現状と今後の予定

現状



Object migrationのprotocolが決まった
Node間routingのprotocolが決まっていない
今後の予定


Ad-hoc networkをヒントにNode間routingを考える
実装


Pythonインタープリタの拡張として実装
評価

分散ウェブアプリケーションをシステム上で書く
Object Unique ID (UID)

Location independentで不変な識別子

Objectが作られた場所


IP address, port #
Objectが作られた場所でのlocal id

例えば、メモリ番地
Object Routing Table


各ノードが持っている
Entry:<UID, dst, seq #>

destination:今居ると思われる場所


デフォルトではUIDに含まれる場所
sequence #:情報の「新しさ」を意味する

数が大きいほど新しい
Update Message

Objectがmigrateすると、srcとdstで変化
をbroadcastをする



この際、seq.#は+1する
<UID, new location, seq#>
MessageにTTLを付ける
Time-To-Live (TTL)

Messageが伝搬される範囲を指定する



転送されるたびに -1
0になったら転送しない
Update messageのTTLはsrc-dstノードの
hops数に比例させる
TTL:1
TTL:2
TTL:0
TTLに込められた意味

Distance Effect


Mobility Rate


動きは、近くにあるノードほど大きく感じる
速度が大きいほど
変化を強く感じる
変化を感じない場所に
通知する必要はない
MIGRATION
OBJ.
Object Access Message


Object Accessの時に生成される
<UID, dst, seq. #>

情報はObject Routing Tableを元に行う
Object Location

受信ノード

Access MessageとObject Routing Table
の内容を比較する



矛盾があった場合は新しい情報を優先する
古い情報は書き換える
Msgのdstへ送る

直接繋がらない時は”next hop”へ送る
Inter-Node Routing


直接ノード間で繋がらない時にルーティン
グが必要
ノード間で
Node B
Node A
Node D
Node C
Node B
Node A
Node C
B(1)
B(1)
B(1)
B(1)
B(1)
B(1)
B(1)
B(1)
B(1)
B(1)
Node D
B(1)
Migration:A→B
HOPS=2
BROADCAST TTL=2
Node B
Node A
Node C
C(2)
C(2)
C(2)
B(1)
C(2)
B(1)
C(2)
B(1)
B(1)
B(1)
Node D
B(1)
Migration:B→C
HOPS=1
BROADCAST TTL=1
Node B
Node A
Node C
C(2)
C(2)
C(2)
B(1)
C(2)
B(1)
C(2)
B(1)
B(1)
B(1)
A(0)
A(0)
Node D
B(1)
Node D:
Access to Object
Node B
Node A
C(2)
C(2)
Node C
C(2)
B(1)
C(2)
B(1)
C(2)
B(1)
B(1)
B(1)
A(0)
B(1)
A(0)
Node D
B(1)
Node B
Node A
C(2)
C(2)
Node C
C(2)
B(1)
C(2)
B(1)
C(2)
B(1)
B(1)
B(1)
B(1)
A(0)
Node D
B(1)
B(1)
Node B
Node A
C(2)
C(2)
Node C
C(2)
B(1)
C(2)
B(1)
C(2)
B(1)
C(2)
B(1)
B(1)
B(1)
A(0)
Node D
B(1)
B(1)
Node B
Node A
C(2)
C(2)
C(2)
Node C
C(2)
B(1)
C(2)
B(1)
C(2)
B(1)
B(1)
B(1)
A(0)
Node D
B(1)
B(1)
基本的な手法

Proactive




Reactive




常に最新のrouting tableを
トポロジーに変化があった場合に、積極的にupdate msgを交
換する
eg:DSDVなど
必要になったらrouting tableを更新する
アクセス時に正しい場所を皆で調べる
eg:simple broadcast, AODV, TORAなど
Hybrid


各ノードを中心とした“zone”を定義する(数ホップ内のエリア)
このzone内ではproactiveに、その外ではreactiveに
それぞれの問題点

Proactive


Reactive


Msg数がO(N*N)で増加する
アクセスが遅くなる
Hybrid


“zone”の範囲はどうする？
動的に伸縮する手法もあるが、その
heuristicsもかなり怪しい
中間発表後の方針



Routingはまだ未決定
取りあえずは、proactive/reactiveな手法
で実装して見る
ベターなroutingアルゴリズムを考える


Mobile ad-hoc networkよりは制約は緩い
はず
この制約の緩さを旨く使ったアルゴリズムを
考えていきたいです
求めているもの


基本的には、nodeに繋げる時は直接繋
ぎに行く
繋げないという万が一の時のために
routingが必要


そのためにO(N*N)のアルゴリズムを使うの
は勿体ない
ノードの増減を許す
最後に


コメント・アドバイス大歓迎です
実装処理系の名前も募集中です



Mudpy(ダメ、使われている)
Muddy?
Dsoapyはありきたりすぎかもしれません。。。