gluepy : 複雑なグリッド環境で 柔軟なプログラミングを...
DESCRIPTION
gluepy : 複雑なグリッド環境で 柔軟なプログラミングを 実現するフレームワーク. 東京大学 田浦研究室 M2 弘中 健. Grid を用いたアプリの普及. 多数 の単体 ジョブ 全く通信・協調がない アプリの並列化 密 な 資源間 の通信・協調 が必要 並列分散計算が身近に必要. グリッド計算上の問題点. Grid 環境の複雑さ 動的参加資源 資源の故障・脱退 接続性の問題 NAT/firewall. Fire Wall. leave. ユーザにはこの複雑さを解決する グリッドフレームワークが不可欠. join. - PowerPoint PPT PresentationTRANSCRIPT
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 フレームワークの課題• アプリの表現・記述が簡潔・柔軟
– アプリケーションの動作を自然に記述– グリッドの「複雑さ」に係る処理は最小限
• グリッド環境への適応も容易– 複雑な環境上でも動作– ユーザに大きな設定負担をかけない
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
leave
join
Fire Wall
適応
App.
既存のアプローチ (1)
• Programming-less– バッチスケジューラ• タスク配置 ( クラスタ間でも )• 故障時の再実行
– 協調は最小限• Embarrassingly parallel
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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 を含めた接続性
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
これを補うことは出来ないだろうか?
本研究の貢献• Grid-enabled 分散オブジェクト指向 framework– オブジェクト指向言語 Python に分散拡張–環境の複雑さ対応に主眼
• 参加・脱退・接続性–柔軟・簡潔なプログラミングと最小限の設定を実現
• 並列アプリをグリッドの分散環境で繋ぎとめる“のり” (glue)
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Agenda
• はじめに• 関連研究• 提案手法• デモ• まとめ
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Programming-less frameworks
• Condor/DAGMan [Thain et al. ‘05]– バッチスケジューラ– 透過的な再実行 / 複数クラスタも使える– 非常に限定された協調モデル
• DAG 依存関係• タスク間では中間ファイルを介してデータを受け渡す
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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な方法に頼るしかない
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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) の自動的解決– ピア間で自動的に接続のオーバレイ構築
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
The Basic Programming Model• 分散オブジェクト
– あるプロセスで生成– RMI でアクセス– Passive Objects
• 占有スレッドはない
• スレッド– あくまで並列処理のため– 同期・非同期RMI は陰にスレッド生成
• Future– 非同期RMI の返り値– placeholder – 呼出し中の例外も格納されリレイズされる
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
SerialObject にシグナルを送る• 非同期イベントへの対応
– イベントを「シグナル」として表現し、扱う• Unix のシグナルセマンティクス• Blocking 操作が unblock する
• オブジェクトへのシグナル– オブジェクト context で block しているスレッドを 1 つ強制 unblock
• もしくは、次に block するスレッド– Unblock されたスレッドでイベント処理が可能
Th
object
unblock
SIGNAL
Th
object handle
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
SerialObjects in gluepy• Atomic Section:
– メソッド内で「ブロックする操作の間」– 属性の state を変える、 Non-
SerialObject への呼び出しなどが atomic に行える• 例:分散 Queue
– 空の queue に対して pop() はblock する
– add() で追加する• 空でなくなったら signal()で unblock させる
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
例: Master-worker in gluepy (1/3)
• 参加・脱退に対応• 動的な参加:– 参加イベントを処理する– block 中に signal で
None を返して unblock
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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
例: Master-worker in gluepy (2/3)
• 故障への処理– 結果回収で例外– 例外を処理し、再投入
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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
例: Master-worker in gluepy (3/3)
• 起動– マスタはオブジェクトを公開– ワーカは参照を得て
RMI で参加する
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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) の自動的解決– ピア間で自動的に接続のオーバレイ構築
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
自動的オーバレイ構築 (1)• 接続性解決
– 自動的にオーバレイ構築• TCP オーバレイ
– 起動時に自動的にピア情報を取得– 各ピアは少数のピアと接続を確立– 連結グラフを構築
NAT
Firewall
Global IP
Attempt connection
established connections
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
自動的オーバレイ構築 (2)
• Firewall クラスタ– 自動 port-forwarding– SSH情報を入力・設定
• 透過的通信– P-P 通信はルーティング
• 動的: AODV [Perkins ‘97]
SSH
Firewalltraversal
P-to-Pcommunication
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
#config fileuse src_pat dst_pat, prot=ssh, user=kenny
Agenda
• はじめに• 関連研究• 提案手法• デモ• まとめ
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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 はソルバ間の通信・同期に使う
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Master-Worker の連携• マスタはワーカに RMI をする– ワーカ : 定期的にマスタに問い合わせる– 単純なマスタ・ワーカではない– 提案するように柔軟なフレームワークが必要
Master
Worker
doJob() exchange_bound()
2008/11/12 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!!
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Troubleshoot Search Engine Overview
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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
• はじめに• 関連研究• 提案手法• 評価• まとめ
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
まとめ• Grid 用分散オブジェクト指向フレームワーク
– 計算資源の増減に対応– 複雑な WAN 環境上の接続性解決
• プログラミングモデル:柔軟・簡潔な記述– SerialObjects– ノード参加の記述をサポート– ノードの脱退: RMI 失敗には例外
• 処理系: Grid 上実行可能– 自動的なオーバレイ構築
• InTrigger を用いた事例 : Grid 上のアプリの繋ぎ– 並列 flowshop ソルバ– トラブルシュートサーチエンジンバックエンド
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
例:実験環境
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 コア以上の環境
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
InTrigger
InTrigger
必要な設定• オーバレイ構築に必要な設定– 2 クラスタ ( tsubame, istbs) は他のクラスタとは
SSH-portforwarding が必要– 2 行の設定ファイル
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
# 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
• ワーカは動的に参加・脱退を繰り返す– 新たなワーカには新たなタスク– 故障したノードのタスクは再分配– タスクは一切失われなかった
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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 でスケールしなくなる
2008/11/12 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
累積実行時間
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