f() - 東京大学

Download Report

Transcript f() - 東京大学

gluepy:
複雑なグリッド環境で
柔軟なプログラミングを
実現するフレームワーク
東京大学
田浦研究室M2
弘中 健
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
グリッド計算上の問題点
• Grid環境の複雑さ
– 動的参加資源
– 資源の故障・脱退
– 接続性の問題
Fire Wall
leave
• NAT/firewall
ユーザにはこの複雑さを解決する
グリッドフレームワークが不可欠
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
join
Gridフレームワークの課題
• アプリの表現・記述が簡潔・柔軟
– アプリケーションの動作を自然に記述
– グリッドの「複雑さ」に係る処理は最小限
• グリッド環境への適応も容易
– 複雑な環境上でも動作
– ユーザに大きな設定負担をかけない
Fire Wall
App.
leave
適応
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
join
既存のアプローチ (1)
• Programming-less
– バッチスケジューラ
• タスク配置 (クラスタ間でも)
• 故障時の再実行
execute
SUBMIT
redo
– 協調は最小限
• Embarrassingly parallel
複雑な環境では複雑な協調がある問題は対象としない
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
既存のアプローチ (2)
doJob()
• 部分的にプログラミング導入
– 例:Master-Worker framework
• master/worker部分を記述
– Job 分配
– ワーカの参加・脱退
– エラー処理
error()
join()
– 表現できるアプリは限定的
• 提供されるフローに束縛
より幅広い問題を対象に:より柔軟・一般的な記述が必須
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
最も柔軟なアプローチ
• 並列言語処理系
– 既存言語を分散拡張
– 数多くの例
• (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依存関係
• タスク間では中間ファイルを介してデータを受け渡す
Central
Manager
2008/11/12
Interaction using
files
Assign
Busy
Nodes
Cluster
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
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]
–
•
Map-Reduce [Dean et al. ‘05]
–
–
•
map(), reduce()の2手続きを定義
故障ノードがあった場合、部分的に再実行
Failure
Handler
Ibis – Satin [Wrzesinska et al. ‘06]
–
–
•
マスタでの処理:参加・脱退をevent-drivenに書く
再帰呼び出しを分割統治法で分散処理
Random work stealingで参加・脱退に対処している
特定な問題に対して有効的
–
–
モデル・問題を限定し、プログラミングが楽・Grid上にマップしやすい
「想定モデル」を外れると、ユーザはOut-of-band、Ad-hocな方法に頼るしかない
Map()
divide
Reduce()
Map()
Input Data
2008/11/12
Reduce()
Map()
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Join
Handler
Join
分散環境でオブジェクト指向
• ABCL [Yonezawa ‘90]
JavaRMI, Manta [Maassen
et al. ‘99]
ProActive [Huet et al. ‘04]
• 分散オブジェクト指向
Proc: A
Proc: B
a.f()
a
RMI
f()
– オブジェクトを資源間で分散
• 計算の分散
– メソッド呼び出し
– RMI (Remote Method
Invocation)
– 非同期RMIで並列計算
Proc: A
async.
RMI
a.f()
a.f()
a.f()
• アプリの記述は自由
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Proc: B
Proc: B
Proc: B
a
a
a
f()
f()
f()
Grid上分散オブジェクト指向の課題
• スレッドの競合
Proc:
A
Proc:
Proc:AA
Proc: B
a.f()
a.f()
a.f()
a
– 1つのオブジェクトに同時多
数RMI
– Active Objects
f()f()
f()
race
• 1 object = 1 thread
• デッドロックの懸念:
e.g.: 再帰呼び出し
• 参加処理の記述
– どのように参加するか
– 参加のイベント通知
Active
objects
• Event –drivenなループでは
flowが分断される
a
b.f()
f()
• 脱退への対応
a.g()
– 透過的な解決は困難
2008/11/12
b
deadlock
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Grid上実行の課題
• 接続性を解決
• オーバレイを構築
NAT
– 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 Wall
提案 : 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
Proc: A
Proc: B
a.f()
a
• 占有スレッドはない
Spawn for
RMI
f()
• スレッド
– あくまで並列処理のため
– 同期・非同期RMIは
陰にスレッド生成
Proc
• Future
– 非同期RMIの返り値
– placeholder
– 呼出し中の例外も格納され
リレイズされる
2008/11/12
F = a.f() async
Spawn for
async
a
f()
store in F
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Programming in gluepy
inherit Remote Object
• RemoteObject
– Base classを継承
– メソッドをRMIに出来る
class Peer(RemoteObject):
def run(self, arg):
# work here…
return result
async. RMI
run() on all
• futureを使った非同期RMI
–
–
futures = []
for p in peers:
明示的にスレッドは使わない
f = p.run.future(arg)
placeholder
wait for all futures.append(f)
• いずれ結果が格納される
results
– 逐次のflowを保ちやすい
waitall(futures)
for f in futures:
print f.get()
read for all
results
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
SerialObjectの所有権
waiting threads
•
SerialObjects
– 排他制御があるオブジェクト
– RemoteObjectのsub-class
•
•
Th Th Th
各オブジェクトに所有権
•
object
Th Th
所有者スレッド
所有者はブロックすると所有権を放
棄する
– e.g: waitall(), 他Serial Objectへの同期
呼び出し
– 他のスレッドが取得可能
– 再帰呼び出しによるdeadlockを排除す
る
Th
2008/11/12
Th
Th
re-contest
for ownership
Th Th
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
unblock
owner
thread
Th
明示的なロックは不要
– call ⇒ acquire
– return ⇒ release
– メソッドの実行は1スレッドのみ
•
object
object
Th
new
owner
thread
block
Give-up
Owner
ship
SerialObjectにシグナルを送る
• 非同期イベントへの対応
object
– イベントを「シグナル」として表現し、扱う
SIGNAL
• Unix のシグナルセマンティクス
• Blocking操作がunblockする
Th
unblock
• オブジェクトへのシグナル
– オブジェクトcontextでblockしているス
レッドを1つ強制unblock
• もしくは、次にblockするスレッド
– Unblockされたスレッドでイベント処理が
可能
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
object
Th
handle
SerialObjects in gluepy
• Atomic Section:
– メソッド内で
「ブロックする操作の間」
– 属性のstateを変える、
Non-SerialObjectへの呼び
出しなどがatomicに行える
Section
def add(self, x):
self.queue.append(x)
if len(self.queue) == 1:
self.signal()
Signal & wake
• 例:分散Queue
– 空のqueueに対してpop()
はblockする
– add()で追加する
• 空でなくなったらsignal()
でunblockさせる
2008/11/12
class DistQueue(SerialObject):
def __init__(self):
Atomic
self.queue = []
def pop(self):
while len(self.queue) == 0:
wait([])
Block until signal
x = self.queue.pop(0)
return x
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
動的な資源への対応
• 参加するプロセス対応
Objects in
computation
lookup
– 「最初の参照」 問題
Object lookup
– 参加ノードが既にある
objectへの参照を得るこ
とが出来る
• 故障⇒ RMI 例外
New object on
joining node
Exception!
– ユーザは例外処理で
rollbackなどを実装する
ことが出来る
Object on
failed node
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
例:Master-worker in gluepy (1/3)
• 参加・脱退に対応
class Master(SerialObject):
...
def nodeJoin(self , node):
self.nodes.append(node)
self.signal()
• 動的な参加:
Signal for join
– 参加イベントを処理する
– block中にsignalで
Noneを返してunblock
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
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Block &
Handle join
例: Master-worker in gluepy (2/3)
• 故障への処理
– 結果回収で例外
– 例外を処理し、再投入
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)
Failure
handling
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
例: Master-worker in gluepy (3/3)
• 起動
– マスタはオブジェクトを
公開
– ワーカは参照を得て
RMIで参加する
Master init
master = Master()
master.register(“master”)
Worker init
master.run()
worker = Worker()
master = RemoteRef(“master”)
master.nodeJoin(worker)
while True:
sleep(1)
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
lookup on join
提案 : gluepy
• Grid環境用分散オブジェクト指向フレームワーク
– Pythonのライブラリ
• プログラミングモデル:記述を支援
– オブジェクトに「所有権」
• レースを解消
– ノード参加記述の支援
• 他のオブジェクト参照取得可能
• イベントに対してblocking操作がunblockし、処理する
– ノード脱退のセマンティクス
• 呼び出し失敗に対する例外
• 処理系:接続性 (NAT/firewall)の自動的解決
– ピア間で自動的に接続のオーバレイ構築
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
自動的オーバレイ構築(1)
• 接続性解決
Global IP
NAT
– 自動的にオーバレイ構築
Firewall
• TCPオーバレイ
– 起動時に自動的にピア情
報を取得
Attempt
connection
– 各ピアは少数のピアと接
続を確立
– 連結グラフを構築
established
connections
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
自動的オーバレイ構築(2)
• Firewallクラスタ
– 自動port-forwarding
– SSH情報を入力・設定
Firewall
traversal
SSH
#config file
use src_pat dst_pat, prot=ssh, user=kenny
• 透過的通信
– P-P通信はルーティング
• 動的:AODV [Perkins ‘97]
P-to-P
communication
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
Quick Recap
• 1. startup a bootstrap server
– set everyone’s bootstrap url:
$ export GLUE_BOOTSTRAP_URL=tcp://HOST:PORT
• 2. start server code
• 3. start client code(s)
• 4. enjoy the terribly interesting
console output :D
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Parallel deployment
• たくさんの資源を使う場合
– 逐一、consoleで叩くのも大変
• 並列 deployerを使う
– Batch schedulerを使う
• InTriggerの場合:torque, qsub
– GXPを使う
• gxpc e command で一括投入
$ gxpc export VAR=VALUE が使える
$ gxpc e python client.py
– gxpc mw command を使う
• bootstrap serverが不要になる
$ gxpc mw python server_client.py
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
実アプリケーション例
• 組み合わせ最適化問題を解く
– 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
doJob()
2008/11/12
Worker
exchange_bound()
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Troubleshoot サーチエンジン
• Ever stuck debugging, or troubleshooting?
• Googleクエリ結果を再ランキングする。
– Web-forumから学習した結果を適用
– 実行時にページ主文を自然言語処理
• Gridバックエンドを使う
Compute!!
backend
Query:
“vmware kernel panic”
Search
Engine
2008/11/12
Compute!!
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Compute!!
Troubleshoot Search Engine Overview
Python
CGI
async.
doQuery()
Graph
extraction
doSearch()
async.
doWork()
rescoring
parsing
Leveraged sync/async RMIs to seamlessly
integrate parallelism into a sequential program.
Merged CGIs with Grid backend
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
まとめ
• 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
例:実験環境
最大規模:9クラスタ・900コア以上の環境
Global IPs
istbs:316
tsubame:64
mirai:48
okubo:28
hongo:98
All packets
dropped
hiro:88
chiba:186
suzuk:72
InTrigger
kototoi:88
kyoto:70
imade:60
Firewall
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
Private IPs
必要な設定
• オーバレイ構築に必要な設定
– 2クラスタ( tsubame, istbs)は他のクラスタとは
SSH-portforwardingが必要
– 2行の設定ファイル
正規表現で接続時の
追加指示を記述
# istbsクラスタが外界とはssh
use 133\.11\.23\. (?!133\.11\.23\.), prot=ssh, user=kenny
# tsubameクラスタ ゲートウェイは外界とはssh
use 131.112.3.1 (?!172\.17\.), prot=ssh, user=kenny
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
動的なMaster-Worker
• マスタobj.がワーカobj.にタスクを割り振る
– 10,000タスク as RMI
• ワーカは動的に参加・脱退を繰り返す
Task/Worker Count
– 新たなワーカには新たなタスク
– 故障したノードのタスクは再分配
– タスクは一切失われなかった
900
800
700
600
500
400
300
200
100
0
Workers
0
2008/11/12
500
1000
1500
Time[sec]
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
2000
2500
3000
Speedup
16000
14000
Completion Time [sec]
Completion Time
12000
10000
900 coresでスケールし
なくなる
8000
6000
4000
2000
0
0
2008/11/12
200
400
600
CPU Cores
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
800
1000
累積実行時間
累積計算時間の拡大が再実行による無
駄が出ていることが分かる
C(948)
Total Comm.
Total Comp.
B(569)
A(169)
0
1000000
2000000
3000000
4000000
5000000
6000000
累積計算時間を考慮すると、スピードアップは169 cores ⇒ 948 cores (5.64 倍)
2008/11/12
www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy
で 4.94