gluepy : 複雑なグリッド環境で柔軟なプログラミングを実現するフレームワーク

gluepy:複雑なグリッド環境で柔軟なプログラミングを実現するフレームワーク東京大学田浦研究室 M2弘中健

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

Grid を用いたアプリの普及• 多数の単体ジョブ

– 全く通信・協調がない

• アプリの並列化– 密な資源間の通信・協調が必要

• 並列分散計算が身近に必要www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy2008/11/12

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

leave

join

Fire Wall

ユーザにはこの複雑さを解決するグリッドフレームワークが不可欠2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

Grid フレームワークの課題• アプリの表現・記述が簡潔・柔軟

– アプリケーションの動作を自然に記述– グリッドの「複雑さ」に係る処理は最小限

• グリッド環境への適応も容易– 複雑な環境上でも動作– ユーザに大きな設定負担をかけない


leave

join

Fire Wall

適応

App.

既存のアプローチ (1)

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

– 協調は最小限• Embarrassingly parallel


execute

redo

SUBMIT

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

既存のアプローチ (2)

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

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

– 表現できるアプリは限定的• 提供されるフローに束縛

　2008/11/12 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-enabled 分散オブジェクト指向 framework– オブジェクト指向言語 Python に分散拡張–環境の複雑さ対応に主眼

• 参加・脱退・接続性–柔軟・簡潔なプログラミングと最小限の設定を実現

• 並列アプリをグリッドの分散環境で繋ぎとめる“のり” (glue)


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 で並列計算

• アプリの記述は自由2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

a

f()

Proc: A Proc: B

a.f()

RMI

a

f()

Proc: A Proc: B

a.f()

async.RMI

a

f()

Proc: B

a.f() a

f()

Proc: B

a.f()

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

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

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

e.g.: 再帰呼び出し• 参加処理の記述

– どのように参加するか– 参加のイベント通知

• Event –driven なループでは flow が分断される• 脱退への対応

– 透過的な解決は困難2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

b

f()

deadlock

ab.f()

a.g()

a

Proc: A Proc: B

a.f()

Proc: A

a.f()

Proc: A

a.f()

f()f()f()race

Activeobjects

Grid 上実行の課題• 接続性を解決• オーバレイを構築– ProActive [Huet et al. ‘04]

• 接続設定ファイル– Jojo2 [Aoki et al. ‘06]

• SSH / UDP broadcast

• 最小限の仮定・負担でデプロイすることが必要2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

Fire WallNAT

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

– Python のライブラリ• プログラミングモデル：記述を支援

– オブジェクトに「所有権」• レースを解消

– ノード参加記述の支援• 他のオブジェクト参照取得可能• イベントに対して blocking 操作が unblock し、処理する

– ノード脱退のセマンティクス• 呼び出し失敗に対する例外

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


The Basic Programming Model• 分散オブジェクト

– あるプロセスで生成– RMI でアクセス– Passive Objects

• 占有スレッドはない

• スレッド– あくまで並列処理のため– 同期・非同期RMI は陰にスレッド生成

• Future– 非同期RMI の返り値– placeholder – 呼出し中の例外も格納されリレイズされる


a

f()

Proc: A Proc: B

a.f() Spawn for

RMI

a

f()

Proc

Spawn for async

store in F

F = a.f() async

Programming in gluepy• RemoteObject

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

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

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

　2008/11/12 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 にシグナルを送る• 非同期イベントへの対応

– イベントを「シグナル」として表現し、扱う• Unix のシグナルセマンティクス• Blocking 操作が unblock する

• オブジェクトへのシグナル– オブジェクト 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

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

– Python のライブラリ• プログラミングモデル：記述を支援

– オブジェクトに「所有権」• レースを解消

– ノード参加記述の支援• 他のオブジェクト参照取得可能• イベントに対して blocking 操作が unblock し、処理する

– ノード脱退のセマンティクス• 呼び出し失敗に対する例外

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


自動的オーバレイ構築 (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

Agenda

• はじめに• 関連研究• 提案手法• デモ• まとめ


Quick Recap

• 1. startup a bootstrap server– set everyone’s bootstrap url:

• 2. start server code• 3. start client code(s)• 4. enjoy the terribly interesting

console output :D

$ export GLUE_BOOTSTRAP_URL=tcp://HOST:PORT

www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy2008/11/12

Parallel deployment• たくさんの資源を使う場合

– 逐一、 console で叩くのも大変• 並列 deployer を使う

– Batch scheduler を使う• InTrigger の場合： torque, qsub

– GXP を使う• gxpc e command で一括投入

– gxpc mw command を使う• bootstrap server が不要になる

$ gxpc e python client.py

$ gxpc mw python server_client.py

www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy2008/11/12

$ gxpc export VAR=VALUE が使える

実アプリケーション例• 組み合わせ最適化問題を解く– Permutation Flow Shop Problem– 並列 branch-and-bound

• Master-Worker型• 定期的なバウンド更新

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

– ワーカ• C++逐次ソルバを外部プロセスで起動• gluepy はソルバ間の通信・同期に使う


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

Master

Worker

doJob() exchange_bound()


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

• Grid バックエンドを使う

backend

Search Engine

Query:“vmware kernel panic”

Compute!!

Compute!!

Compute!!


Troubleshoot Search Engine Overview


PythonCGI

async.doQuery()

doSearch()

async.doWork()

parsing

Graph extraction

rescoring

Leveraged sync/async RMIs to seamlessly integrate parallelism into a sequential program.

Merged CGIs with Grid backend

Agenda

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


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

– 計算資源の増減に対応– 複雑な WAN 環境上の接続性解決

• プログラミングモデル：柔軟・簡潔な記述– SerialObjects– ノード参加の記述をサポート– ノードの脱退： RMI 失敗には例外

• 処理系： Grid 上実行可能– 自動的なオーバレイ構築

• InTrigger を用いた事例： Grid 上のアプリの繋ぎ– 並列 flowshop ソルバ– トラブルシュートサーチエンジンバックエンド






例：実験環境

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

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/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

Documents

gluepy : 複雑なグリッド環境で 柔軟なプログラミングを 実現するフレームワーク

gluepy : 複雑なグリッド環境で柔軟なプログラミングを実現するフレームワーク