gluepy : 複雑なグリッド環境で柔軟なプログラミングを...

gluepy:複雑なグリッド環境で柔軟なプログラミングを実現するフレームワーク6/13/08東京大学弘中健 , 斉藤秀雄 , 高橋慧 , 田浦健次朗

2008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

Grid の利用形態• Grid

– 複数クラスタ• 典型的な Grid の使い方

– 多数の単体ジョブを並列処理

• Grid 上で並列分散計算– 例：逐次アプリの並列化– 複雑な資源間の協調が必要

www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy2008/6/13

グリッド計算上の問題点• Grid 環境の複雑さ– 動的参加資源– 資源の故障・脱退– 接続性の問題• NAT/firewall

leave

join

Fire Wall

Grid フレームワークは複雑な環境で動作することが必須2008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

既存のアプローチ (1)

• Programming-less– バッチスケジューラ• タスク配置 ( クラスタ間でも )• 故障時の再実行

– 協調は最小限• Embarrassingly parallel


execute

redo

SUBMIT

複雑な環境では複雑な協調がある問題は対象としない

既存のアプローチ (2)

• 部分的にプログラミング導入– 例： Master-Worker framework

• master/worker 部分を記述– Job 分配– ワーカの参加・脱退– エラー処理

• 可能な協調はまだ限定的

　2008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

error()

join()

doJob()

より幅広い問題を対象に：より柔軟・一般的な記述が必須

最も柔軟なアプローチ • 並列言語処理系– 既存言語を分散拡張– 数多くの例

• (MultiLisp[Halstead ‘85], JavaRMI, ProActive[Huet et al. ‘04], …)

– 問題点： Grid 環境の枠組みに当てはまらない• 資源の参加・故障• NAT/firewall を含めた接続性


表現と記述が困難・複雑

Grid 並列分散計算の需要• 柔軟・複雑に協調するアプリケーションを

Grid 環境で簡潔に実現する処理系• 並列言語のアプローチは重要


leave

join

Fire Wall

適用

App.

本研究の貢献• Grid-enabled 分散オブジェクト指向

framework–環境の複雑さ対応に主眼• 参加・脱退・接続性

–簡潔なプログラミングと最小限の設定を実現– 900 コア (9 クラスタ ) の環境で並列アプリケーションを実装


Agenda

• はじめに• 関連研究• 提案手法• 評価• まとめ


Programming-less frameworks

• Condor/DAGMan [Thain et al. ‘05]– バッチスケジューラ– 透過的な再実行 / 複数クラスタも使える– 非常に限定された協調モデル

• DAG 依存関係• タスク間では中間ファイルを介してデータを受け渡す


Central Manager

Busy Nodes

Assign

Cluster

Interaction using files

Task

Restricted Programming Models• Master-Worker Model: Jojo2 [Aoki et al. ‘06], OmniRPC [Sato et al. ‘01], 　　　　　　　　　Ninf-C [Nakata et al. ‘04], NetSolve [Casanova et al. ‘96]

– マスタでの処理：参加・脱退をevent-drivenに書く• Map-Reduce [Dean et al. ‘05]

– map(), reduce()の2手続きを定義– 故障ノードがあった場合、部分的に再実行

• Ibis – Satin [Wrzesinska et al. ‘06]– 分割統治法を分散処理– Random work stealingで参加・脱退に対処している

• 特定な問題に対して有効的– モデル・問題を限定し、プログラミングが楽・Grid上にマップしやすい– 「想定モデル」を外れると、ユーザはOut-of-band、Ad-hocな方法に頼るしかない


Map()

Map()

Map()

Reduce()

Reduce()Input Data

Join

Failure Handler

Join Handler

divide

分散環境でオブジェクト指向• ABCL [Yonezawa ‘90]

JavaRMI, Manta [Maassen et al. ‘99]ProActive [Huet et al. ‘04]

• 分散オブジェクト指向– オブジェクトを資源間で分散

• 計算の分散– メソッド呼び出し– RMI (Remote Method Invocation)– 非同期 RMI で並列計算

• 扱うモデルに限定がなく、望ましい

foo.doJob(args)

RMI

compute

foo

Async. RMI


Grid 上分散オブジェクト指向の課題• スレッドの競合

– 1 つのオブジェクトに同時多数 RMI– Active Objects

• 1 object = 1 thread• デッドロックの懸念：

e.g.: 再帰呼び出し• 非同期イベントへの対処

– e.g., ノード参加時の処理– Event –driven なループで処理可だが…

• 一連の flow が分断され、複雑になる

• ノードの参加・脱退– 透過的な解決は困難


b.f()

a.g()a

bdeadlock

Grid 上の接続性の課題• オーバレイを構築

– ProActive [Huet et al. ‘04]• 木構造の接続オーバレイ• 手書きの接続設定ファイルが必要

– Jojo2• 深さ 2 の階層的な接続を仮定

– SSH / UDP broadcast

• 最小限の仮定・設定でデプロイすることが必要 ConnectionConfiguration File

NAT

Firewall

Configure each link


問題点の整理• Grid で分散オブジェクト指向を実現する課題– スレッドの競合– イベント処理– ノードの参加・脱退– 簡潔な接続性の解決


提案 : gluepy• Grid 環境用分散オブジェクト指向フレームワーク

– Python のライブラリ• オブジェクト指向の枠組みで簡潔な提案を示す

– スレッドの競合• オブジェクトに「所有権」

– イベント処理• イベントをシグナルとしてハンドリング

– ノードの参加・脱退• 「最初の参照」を得ることが可能• 呼び出し失敗に対する例外

– 接続性 (NAT/firewall)• ピア間で自動的に接続のオーバレイ構築


Programming in gluepy• RemoteObject

– Base class を継承– メソッドを RMI に出来る

• future を使った非同期 RMI– 明示的にスレッドは使わない– placeholder

• いずれ結果が格納される– 逐次の flow を保ちやすい

　2008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

class Peer(RemoteObject): def run(self, arg): # work here… return result

futures = [] for p in peers: f = p.run.future(arg) futures.append(f) waitall(futures)

for f in futures: print f.get()

async. RMI run() on all

wait for all results

read for all results

inherit Remote Object

SerialObject の所有権• SerialObjects

– 排他制御があるオブジェクト– RemoteObject の sub-class

• 明示的なロックは不要• 各オブジェクトに所有権

– call acquire⇒– return release⇒– メソッドの実行は 1 スレッドのみ

• 所有者スレッド

• 所有者はブロックすると所有権を放棄する– e.g: waitall(), 他 Serial Object への同期呼び出し– 他のスレッドが取得可能– 再帰呼び出しによる deadlock を排除する

ThTh Th Th

object ownerthread

Th

Th Th Th

object

newownerthread

Give-upOwner

ship

block

Th Th Th Th

object

unblock

re-contestfor ownership

waiting threads


SerialObject にシグナルを送る• 非同期イベントへの対応

– Event –driven なループに頼らない– イベントを「シグナル」として表現し、扱う

• オブジェクトへのシグナル– オブジェクト context で block しているスレッドを 1 つ強制 unblock

• もしくは、次に block するスレッド– Unblock されたスレッドでイベント処理が可能

Th

object

unblock

SIGNAL

Th

object handle


SerialObjects in gluepy• Atomic Section:

– メソッド内で「ブロックする操作の間」– 属性の state を変える、 Non-

SerialObject への呼び出しなどが atomic に行える• 例：分散 Queue

– 空の queue に対して pop() はblock する

– add() で追加する• 空でなくなったら signal()で unblock させる


class DistQueue(SerialObject): def __init__(self): self.queue = []

def add(self, x): self.queue.append(x) if len(self.queue) == 1: self.signal()

def pop(self): while len(self.queue) == 0:

wait([])

x = self.queue.pop(0) return x

Atomic Section

Signal & wake

Block until signal

動的な資源への対応• 参加するプロセス対応

– 「最初の参照」問題Object lookup– 参加ノードが既にある

object への参照を得ることが出来る• 故障⇒ RMI 例外

– ユーザは例外処理でrollback などを実装することが出来る

Exception!

Objects in computation

New object on joining node

lookup

Object on failed node


例： Master-worker in gluepy (1/3)

• 参加・脱退に対応• 動的な参加：– 参加イベントを処理する– block 中に signal で

None を返して unblock


class Master(SerialObject): ...

def nodeJoin(self , node): self.nodes.append(node) self.signal()

def run (self): assigned = {} while True: while len(self.nodes)>0 and

len(self.jobs)>0: ASYNC. RMIS TO IDLE WORKERS

readys = wait(futures) if readys == None: continue

for f in readys: HANDLE RESULTS

Signal for join

Block &Handle join


• 故障への処理– 結果回収で例外– 例外を処理し、再投入


for f in readys: node, job = assigned.pop(f) try: print ”done:”, f.get() self.nodes.append(node) except RemoteException, e: self.jobs.append(job)

Failurehandling


• 起動– マスタはオブジェクトを公開– ワーカは参照を得て

RMI で参加する


worker = Worker()

master = RemoteRef(“master”)

master.nodeJoin(worker)

while True: sleep(1)

master = Master()

master.register(“master”)

master.run()

lookup on join

Worker init

Master init

自動的オーバレイ構築 (1)• 簡潔な接続性解決

– 自動的にオーバレイ構築• TCP オーバレイ

– 起動時に自動的にピア情報を取得– 各ピアは少数のピアと接続を確立– 連結グラフを構築

NAT

Firewall

Global IP

Attempt connection

established connections


自動的オーバレイ構築 (2)

• Firewall クラスタ– 自動 port-forwarding– SSH情報を入力・設定

• 透過的通信– P-P通信はルーティング

• 動的： AODV [Perkins ‘97]

SSH

Firewalltraversal

P-to-Pcommunication


#config fileuse src_pat dst_pat, prot=ssh, user=kenny

オーバレイ上の RMI 失敗検出• オーバレイでの問題

– 「通信路」：複数接続からなる• RMI 失敗⇒ 中継接続が断絶

• Path Pointers– 転送ピアは覚えておく– RMI reply は来た道を戻る

• 中間リンクが切れる– エラーが呼び出し側に伝搬する

Path pointer

RMI handler

failure

Backpropagate

RMI invoker


Agenda



実験環境

hongo:98

chiba:186

okubo:28

suzuk:72

imade:60kototoi:88

kyoto:70

istbs:316

tsubame:64

FirewallPrivate IPs

All packets droppedhiro:88

mirai:48

Global IPs

最大規模： 9 クラスタ・ 900 コア以上の環境


InTrigger

InTrigger

必要な設定• オーバレイ構築に必要な設定– 2 クラスタ ( tsubame, istbs) は他のクラスタとは

SSH-portforwarding が必要– 2 行の設定ファイル


# istbs クラスタが外界とは sshuse 133\.11\.23\. (?!133\.11\.23\.), prot=ssh, user=kenny

# tsubame クラスタゲートウェイは外界とは sshuse 131.112.3.1 (?!172\.17\.), prot=ssh, user=kenny

正規表現で接続時の追加指示を記述

動的な Master-Worker• マスタ obj. がワーカ obj. にタスクを割り振る

– 10,000 タスク as RMI

• ワーカは動的に参加・脱退を繰り返す– 新たなワーカには新たなタスク– 故障したノードのタスクは再分配– タスクは一切失われなかった


0 500 1000 1500 2000 2500 30000

100200300400500600700800900

Workers

Time[sec]

Tas

k/W

orke

r C

ount

実アプリケーション例• 組み合わせ最適化問題を解く– Permutation Flow Shop Problem– 並列 branch-and-bound• Master-Worker 型• 定期的なバウンド更新

– 分散• 探索空間を分割し、タスクにする• 負荷分散

– なかなか終わらないタスクはマスタで分割し、再投入– ワーカの計算が無駄になることもある


Master-Worker の連携• マスタはワーカに RMI をする– ワーカ : 定期的にマスタに問い合わせる– 単純なマスタ・ワーカではない– 提案するように柔軟なフレームワークが必要

Master

Worker

doJob() exchange_bound()


Speedup

100 200 300 400 500 600 700 800 900 10000

2000

4000

6000

8000

10000

12000

14000

16000

Completion Time

CPU Cores

Com

plet

ion

Tim

e [s

ec]

900 cores でスケールしなくなる


累積実行時間

A(169)

B(569)

C(948)

0 1000000 2000000 3000000 4000000 5000000 6000000

Total Comm.Total Comp.

累積計算時間の拡大が再実行による無駄が出ていることが分かる

累積計算時間を考慮すると、スピードアップは 169 cores 948 cores ⇒(5.64 倍 ) で 4.942008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

Troubleshoot サーチエンジン• Ever stuck debugging, or troubleshooting?• Google クエリ結果を再ランキングする。– Web-forum から学習した結果を適用– 実行時にページ主文を自然言語処理

• Grid バックエンドを使う

backend

Search Engine

Query:“vmware kernel panic”

Compute!!

Compute!!

Compute!!


Troubleshoot サーチエンジンの概要


CGI:async.googlequery

extraction

parsing

Graph extraction

rescoring

asynchronously return to CGI

CGI から Grid 上で負荷分散するコードまで、すべて提案フレームワークでシームレスに処理

Agenda



まとめ• Grid 用分散オブジェクト指向フレームワーク

– Grid 環境で柔軟なモデルを簡潔にサポートする• スレッド競合、イベント処理、参加・脱退、接続性 (NAT/firewall)

• Grid を使ったアプリケーションを実装– 900 コア (9 クラスタ ) で並列アプリケーション実装

• NAT/Firewall, 参加・脱退を含む環境– “Grid backend” を使ったトラブルシュートサーチエンジン　　


オーバレイに関するMicro-Benchmarks

• 1 ノードから RMI を発行–ほぼすべてのノードに対して 3hop以内で到達

• Latency– Overlay 上で no-op の RMI : ping()

• Bandwidth– Overlay 上で大きい引数の RMI : send_data()


オーバレイ上の遅延• 1 ノードから 5 クラスタのノード上の

object へ RMI : ping()– ping で測定した RTT と比較

• overlay, 1 hop = ~1.5 [ms]

chiba1

01

chiba1

03

hiro00

1

hong

o100

hongo

102

imad

e001

kotot

oi000

kototoi002

kyoto

002

mirai00

0

mirai00

20

5

10

15

20

25

30

35

ping()RTT

Lat

ency

[m

s]L

aten

cy

[ms]


オーバレイ上のバンド幅• 引数 (de)serialization overhead 大– Full 1Gbit Ethernet で理想最大値： 40[MB/sec]– iperf 測定値から算出される最大値と比較– overlay で hop をするたびにバンド幅が減少• store-and-forward

chiba

101

chiba1

03

hiro00

1

hongo

100

hong

o102

imad

e001

kotot

oi000

kotot

oi002

kyoto

002

mirai00

0

mirai00

205

1015202530354045

Throughputiperf

Thr

ough

put [

MB

/s]

Overlay hop 数でクラスタ内でもバンド幅が変化


Master-worker in gluepy

• Full Master-Worker– 並列 RMI

• New RMI for idle workers– ノードの参加・脱退

• Non-event driven

2008/6/13www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

class Master(SerialObject): def __init__(self, jobs): self.nodes = [] self.jobs = jobs

def nodeJoin(self , node): self.nodes.append(node) self.signal()

def run (self): assigned = {} while True: while len(self.nodes)>0 and len(self.jobs)>0: node = self.nodes.pop() job = self.jobs.pop() f = node.doJob.future(job) assigned[f] = (node, job)

readys = wait(assigned.keys()) if readys == None: continue

for f in readys: node, job = assigned.pop(f) try: print ”done:”, f.get() self.nodes.append(node) except RemoteException, e: self.jobs.append(job)

Failurehandling

Signal for join

Block &Handle join

worker = Worker()

master = RemoteRef(“master”)

master.join(worker)

while True: sleep(1)

master = Master()

master.register(“master”)

master.run()

lookup on join

Worker init

Master init

Grid 上で並列分散計算の需要• 例： Web アプリケーション

• CGI とのインタラクション• タスク分割・負荷分散• 結果集約・ CGI へ結果加工

　　　

backend

Application

Publicly accessible

複雑な協調を必要とする


提案するモデルでのプログラミング• future で非同期 RMI

– 呼び出しに対するplaceholder

– いずれ結果が格納される• 明示的なスレッドは不要

– 別スレッドによる callbackなどはない

• RMI を処理する側は？2008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

# 非同期 RMI 実行f1 = foo1.doJob.future(args)f2 = foo2.doJob.future(args)#他の計算……#返り値を取得。 Waitvalue1 = f1.get()value2 = f2.get()

プログラミングモデルが提供するもの• 柔軟性：既存のオブジェクト指向言語をライブラリ拡張• 並列分散計算に携わる諸問題を解決

– ロックを意識させない• オブジェクトの所有権を使った implicit な排他制御• block 時に所有権を implicit に委託する：デッドロック予防

– event-driven に陥らないイベント処理• 同期モデルと協調した signalセマンティクス

– 参加・脱退への対応• object lookup ：　「最初の参照」問題• 故障に対する例外セマンティクス

• 分散した動的な環境 (Grid) を簡潔に扱えるモデル2008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

資源間通信と協調の実現• Condor/DAGMan [Thain et al. ‘05]

– バッチスケジューラ– 「タスク」はスクリプトで表現– タスク間の依存関係は DAG

• Ibis / Satin [Wrzesinska et al. ‘06]– 分散環境で分割統治問題– 子タスクに分割– タスクには親子関係

DAG DependencyRelationship

Central Manager

Busy Nodes

Assign

Cluster

Task

- タスク間の協調は中間ファイル媒体- 依存関係のあるタスク間での通信に限定

www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

参加・脱退の処理• JoJo2 [Aoki et al. ‘06]

– Master – Worker– Event driven– イベント毎にハンドラ定義

• タスクの終了• 参加• 脱退・故障

Join

Failure Handler

Join Handler

- 同期の問題- イベント・ドリブンは分かりにくい-提案する同期セマンティクスに非同期イベント通知機構を導入-Event-driven でない記述が可能


Overlay Construction Simulation– Evaluate the overlay construction scheme– For different cluster configurations, modified number of attempted connections per peer– 1000 trials per each cluster/attempted connection configuration

0 5 10 15 20 25 30 350

0.2

0.4

0.6

0.8

1

1.2

Probability of Connected Graph

4 Global 3 Private2 Global 3 Private1 Global 3 Private

num. of attempted connections per peer

Prob

abili

ty

28 Global/ 238 Private Peers Case: 95 %


Future Work

• Reliable WAN communication for the Grid overlays– Node failure– Connection failure

• Weakness of WAN connections– Router Policies• close connections after given period

– Obscure kernel bugs with NAT• Connection resets

Faulty link

WAN links are more vulnerable, and failures will occur2008/6/13 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

Some Related Work• Robust Tree Topologies for

Sensor Networks [ England ‘06]– Create spanning tree for data

reduction– Flat tree for high reliability

• Fewest Hops– Tree with short distance for

low power consumption• Shortest Path

⇒ Spanning Tree that merges the two metrics for the best of two worlds

Fewest Hop:High ReliabilityHigh Power Usage

Shortest Path:Low ReliabilityLow Power Usage


Possible Future Direction

• Our context: Grid computing– communication latency = metric for link reliability

• Fewest Hops– Reliability for node

failure• Shortest Distance– Reliability for link failure

Short reliable links

Long faulty links

Can we construct an overlay connection topology that take the best of two worlds?


Publications• 1. Ken Hironaka, Hideo Saito, Kei Takahashi, Kenjiro Taura. A Flexible Programming

Framework for Complex Grid Environments. In 8th IEEE International Symposium on Cluster Computing and the Grid, May 2008 (Poster Paper. To Appear).

• 2. Ken Hironaka, Hideo Saito, Kei Takahashi, Kenjiro Taura. A Flexible Programming Framework for Complex Grid Environments. In IPSJ Transactions on Advanced Computing Systems. (Conditional Accept)

• 3. Ken Hironaka, Hideo Saito, Kei Takahashi, Kenjiro Taura. A Flexible Programming Framework for Complex Grid Environments. In Proceedings of 2008 Symposium on Advanced Computing Systems and Infrastructures. (To Appear)

• 4. Ken Hironaka, Shogo Sawai, Kenjiro Taura. A Distributed Object-Oriented Library for Computation Across Volatile Resources. In Summer United Workshops on Parallel, Distributed and Cooperative Processing. August 2007

• 5. Ken Hironaka, Kenjiro Taura, Takashi Chikayama. A Low-Stretch Object Migration Scheme for Wide-Area Environments. In IPSJ Transactions on Programming. Vol 48 No.SIG 12 (PRO 34), pp.28-40, August 2007


Problems with Grid Computing (2)

• Complexity of Programming on the Grid– Low Level Computing (sockets)

• Communication• Multi-threaded Computing (Synchronization)• Heavy Burden on Non-experts

– Flexibility and Integration• Grid Frameworks for task distribution• Independent parallel programming languages• Computing is not execution of many independent tasks

– Need finer grained communication• Bad interface with user application

– Java, Ruby, Python, PHP


Related Work

• Discussed with respect to criteria necessary for modern Grid computing– Workflow Coordination• Flexibility without putting the burden on the user

– Joining Nodes / Failure of resources• Handling these events should not dominate the

programming overhead– Connectivity in Wide-Area Networks• Adaptation to networks with NAT/firewall with little

manual settings


Workflow Coordination (1)

• Condor / DAGMan [Thain ‘05]– “Tasks” are expressed as script files and

distributed on idle nodes– Dependency between tasks can be

expressed in DAG (Directed Acyclic Graph)

• Ibis / Satin [Wrzesinska ‘06]– framework for divide-and-conquer

problems– Tasks can be broken into smaller sub-

tasks, on which it depends

DAG DependencyRelationship

Central Manager

Busy Nodes

Assign

Cluster

Task

- Many computation cannot be expressed as “Tasks” with dependencies- A task’s communication is limited to others to which it has dependencies


Object Synchronization Example

class A: def __init__(self, x): self.x = x

def f(self, b): self.x += 1

#blocking RMI b.g() self.x -= 1

return

Atomic section

Atomic section

a b

b.g()

Value x stays

consistent

In method f(), instance a invokes blocking method g() on object b

only 1 thread at a

time

give-upownershipduring RMI

block


Adaptation to Dynamic Resources• Signal delivery to objects

– Unblocks any thread that is blocking in the object’s context• Can be used to notify

asynchronous events– A joining node

• Node Failure RMI Failure⇒– Failure returned as exception to

method invocation– The user can catch the

exception, and perform rollback procedures if necessary

exception

Th

object

blockunblock

signal


Preliminary Experiments

• Overlay Construction Simulation• A Simple Master-Worker Application with

dynamically joining/leaving nodes• A Real-life Parallel Application on the Grid• A Troubleshoot-Search Engine


hongo(98)

chiba(186)

okubo(28)

suzuk(72)

imade(60)kototoi (88)

kyoto(70)

istbs(316)

tsubame(64)

Global IPs

FirewallPrivate IPs

All packets dropped


gluepy : 複雑なグリッド環境で 柔軟なプログラミングを...

Documents

gluepy : 複雑なグリッド環境で柔軟なプログラミングを...