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

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

2. Gridの利用形態 • Grid • 複数クラスタ • 典型的なGridの使い方 • 多数の単体ジョブを並列処理 • Grid上で並列分散計算 • 例：逐次アプリの並列化 • 複雑な資源間の協調が必要 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

3. グリッド計算上の問題点 • Grid環境の複雑さ • 動的参加資源 • 資源の故障・脱退 • 接続性の問題 • NAT/firewall Fire Wall leave Grid フレームワークは 複雑な環境で動作することが必須 join www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

4. 既存のアプローチ (1) execute • Programming-less • バッチスケジューラ • タスク配置 (クラスタ間でも) • 故障時の再実行 • 協調は最小限 • Embarrassingly parallel SUBMIT redo 複雑な環境では複雑な協調がある問題は対象としない www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

5. 既存のアプローチ (2) doJob() • 部分的にプログラミング導入 • 例：Master-Worker framework • master/worker部分を記述 • Job 分配 • ワーカの参加・脱退 • エラー処理 • 可能な協調はまだ限定的 error() join() より幅広い問題を対象に：より柔軟・一般的な記述が必須 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

6. 最も柔軟なアプローチ • 並列言語処理系 • 既存言語を分散拡張 • 数多くの例 • (MultiLisp[Halstead ‘85], JavaRMI, ProActive[Huet et al. ‘04], …) • 問題点：Grid環境の枠組みに当てはまらない • 資源の参加・故障 • NAT/firewallを含めた接続性 表現と記述が困難・複雑 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

7. Grid並列分散計算の需要 • 柔軟・複雑に協調するアプリケーションを Grid環境で簡潔に実現する処理系 • 並列言語のアプローチは重要 Fire Wall App. leave 適用 join www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

8. 本研究の貢献 • Grid-enabled分散オブジェクト指向framework • 環境の複雑さ対応に主眼 • 参加・脱退・接続性 • 簡潔なプログラミングと最小限の設定を実現 • 900コア(9クラスタ)の環境で並列アプリケーションを実装 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

9. Agenda • はじめに • 関連研究 • 提案手法 • 評価 • まとめ www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

10. Programming-less frameworks • Condor/DAGMan [Thain et al. ‘05] • バッチスケジューラ • 透過的な再実行 / 複数クラスタも使える • 非常に限定された協調モデル • DAG依存関係 • タスク間では中間ファイルを介してデータを受け渡す Task Interaction using files Central Manager Assign Busy Nodes Cluster www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

11. 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な方法に頼るしかない Join Handler Failure Handler Join Map() divide Reduce() Map() Reduce() Input Data Map() www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

12. 分散環境でオブジェクト指向 foo.doJob(args) • ABCL [Yonezawa ‘90] JavaRMI, Manta [Maassen et al. ‘99] ProActive [Huet et al. ‘04] • 分散オブジェクト指向 • オブジェクトを資源間で分散 • 計算の分散 • メソッド呼び出し • RMI (Remote Method Invocation) • 非同期RMIで並列計算 • 扱うモデルに限定がなく、 望ましい compute RMI foo Async. RMI www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

13. Grid上分散オブジェクト指向の課題 • スレッドの競合 • 1つのオブジェクトに同時多数RMI • Active Objects • 1 object = 1 thread • デッドロックの懸念： e.g.: 再帰呼び出し • 非同期イベントへの対処 • e.g., ノード参加時の処理 • Event –drivenなループで処理可だが… • 一連のflowが分断され、複雑になる • ノードの参加・脱退 • 透過的な解決は困難 deadlock b.f() b a a.g() www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

14. Grid上の接続性の課題 NAT • オーバレイを構築 • ProActive[Huet et al. ‘04] • 木構造の接続オーバレイ • 手書きの接続設定ファイルが必要 • Jojo2 • 深さ2の階層的な接続を仮定 • SSH / UDP broadcast • 最小限の仮定・設定でデプロイすることが必要 Configure each link Firewall Connection Configuration File www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

15. 問題点の整理 • Gridで分散オブジェクト指向を実現する課題 • スレッドの競合 • イベント処理 • ノードの参加・脱退 • 簡潔な接続性の解決 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

16. 提案 : gluepy • Grid環境用分散オブジェクト指向フレームワーク • Pythonのライブラリ • オブジェクト指向の枠組みで簡潔な提案を示す • スレッドの競合 • オブジェクトに「所有権」 • イベント処理 • イベントをシグナルとしてハンドリング • ノードの参加・脱退 • 「最初の参照」を得ることが可能 • 呼び出し失敗に対する例外 • 接続性 (NAT/firewall) • ピア間で自動的に接続のオーバレイ構築 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

17. Programming in gluepy inherit Remote Object • RemoteObject • Base classを継承 • メソッドをRMIに出来る • futureを使った非同期RMI • 明示的にスレッドは使わない • placeholder • いずれ結果が格納される • 逐次のflowを保ちやすい 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 forallresults read forallresults www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

18. SerialObjectの所有権 waiting threads owner thread object • SerialObjects • 排他制御があるオブジェクト • RemoteObjectのsub-class • 明示的なロックは不要 • 各オブジェクトに所有権 • call ⇒ acquire • return ⇒ release • メソッドの実行は1スレッドのみ • 所有者スレッド • 所有者はブロックすると所有権を放棄する • e.g: waitall(), 他Serial Objectへの同期呼び出し • 他のスレッドが取得可能 • 再帰呼び出しによるdeadlockを排除する Th Th Th Th new owner thread object Th Th Th block Give-up Owner ship Th re-contest for ownership object Th Th Th Th www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy unblock

19. SerialObjectにシグナルを送る • 非同期イベントへの対応 • Event –drivenなループに頼らない • イベントを「シグナル」として表現し、扱う • オブジェクトへのシグナル • オブジェクトcontextでblockしているスレッドを1つ強制unblock • もしくは、次にblockするスレッド • Unblockされたスレッドでイベント処理が可能 object SIGNAL Th unblock handle object Th www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

20. SerialObjects in 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: • メソッド内で 「ブロックする操作の間」 • 属性のstateを変える、Non-SerialObjectへの呼び出しなどがatomicに行える • 例：分散Queue • 空のqueueに対してpop()はblockする • add()で追加する • 空でなくなったらsignal() でunblockさせる Atomic Section Signal & wake Block until signal www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

21. 動的な資源への対応 Objects in computation • 参加するプロセス対応 • 「最初の参照」 問題 Object lookup • 参加ノードが既にあるobjectへの参照を得ることが出来る • 故障⇒ RMI 例外 • ユーザは例外処理でrollbackなどを実装することが出来る lookup New object on joining node Exception! Object on failed node www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

22. 例：Master-worker in gluepy (1/3) 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 • 参加・脱退に対応 • 動的な参加： • 参加イベントを処理する • block中にsignalで Noneを返してunblock Signal for join Block & Handle join www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

24. 例： Master-worker in gluepy (3/3) • 起動 • マスタはオブジェクトを公開 • ワーカは参照を得て RMIで参加する Master init master = Master() master.register(“master”) master.run() Worker init worker = Worker() master = RemoteRef(“master”) master.nodeJoin(worker) while True: sleep(1) lookup on join www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

25. 自動的オーバレイ構築(1) • 簡潔な接続性解決 • 自動的にオーバレイ構築 • TCPオーバレイ • 起動時に自動的にピア情報を取得 • 各ピアは少数のピアと接続を確立 • 連結グラフを構築 NAT Global IP Firewall Attempt connection established connections www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

26. 自動的オーバレイ構築(2) • Firewallクラスタ • 自動port-forwarding • SSH情報を入力・設定 • 透過的通信 • P-P通信はルーティング • 動的：AODV [Perkins ‘97] Firewall traversal SSH #config file use src_patdst_pat, prot=ssh, user=kenny P-to-P communication www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

27. オーバレイ上のRMI失敗検出 RMI handler • オーバレイでの問題 • 「通信路」：複数接続からなる • RMI 失敗 ⇒ 中継接続が断絶 • Path Pointers • 転送ピアは覚えておく • RMI replyは来た道を戻る • 中間リンクが切れる • エラーが呼び出し側に伝搬する Path pointer RMI invoker Backpropagate failure www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

28. Agenda • はじめに • 関連研究 • 提案手法 • 評価 • まとめ www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

29. 実験環境 InTrigger 最大規模：9クラスタ・900コア以上の環境 Global IPs istbs:316 tsubame:64 mirai:48 okubo:28 hongo:98 All packets dropped hiro:88 chiba:186 kyoto:70 suzuk:72 InTrigger imade:60 kototoi:88 Private IPs Firewall www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

30. 必要な設定 • オーバレイ構築に必要な設定 • 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 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

31. 動的なMaster-Worker • マスタobj.がワーカobj.にタスクを割り振る • 10,000タスク asRMI • ワーカは動的に参加・脱退を繰り返す • 新たなワーカには新たなタスク • 故障したノードのタスクは再分配 • タスクは一切失われなかった www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

32. 実アプリケーション例 • 組み合わせ最適化問題を解く • Permutation Flow Shop Problem • 並列 branch-and-bound • Master-Worker型 • 定期的なバウンド更新 • 分散 • 探索空間を分割し、タスクにする • 負荷分散 • なかなか終わらないタスクはマスタで分割し、再投入 • ワーカの計算が無駄になることもある www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

33. Master-Workerの連携 • マスタはワーカにRMIをする • ワーカ: 定期的にマスタに問い合わせる • 単純なマスタ・ワーカではない • 提案するように柔軟なフレームワークが必要 Master exchange_bound() doJob() Worker www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

34. Speedup 900 coresでスケールしなくなる www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

35. 累積実行時間 累積計算時間の拡大が再実行による無駄が出ていることが分かる 累積計算時間を考慮すると、スピードアップは169 cores ⇒ 948 cores (5.64 倍) で 4.94 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

36. Troubleshoot サーチエンジン • Ever stuck debugging, or troubleshooting? • Googleクエリ結果を再ランキングする。 • Web-forumから学習した結果を適用 • 実行時にページ主文を自然言語処理 • Gridバックエンドを使う Compute!! Compute!! backend Query: “vmware kernel panic” Search Engine Compute!! www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

37. Troubleshoot サーチエンジンの概要 Graph extraction extraction asynchronously return to CGI parsing rescoring CGI: async. google query CGIからGrid上で負荷分散するコードまで、 すべて提案フレームワークでシームレスに処理 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

38. Agenda • はじめに • 関連研究 • 提案手法 • 評価 • まとめ www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

39. まとめ • Grid用分散オブジェクト指向フレームワーク • Grid環境で柔軟なモデルを簡潔にサポートする • スレッド競合、イベント処理、参加・脱退、接続性(NAT/firewall) • Gridを使ったアプリケーションを実装 • 900コア(9 クラスタ)で並列アプリケーション実装 • NAT/Firewall, 参加・脱退を含む環境 • “Grid backend”を使ったトラブルシュートサーチエンジン www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

41. オーバレイに関するMicro-Benchmarks • 1ノードからRMIを発行 • ほぼすべてのノードに対して3hop以内で到達 • Latency • Overlay上でno-opのRMI : ping() • Bandwidth • Overlay上で大きい引数のRMI : send_data() www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

42. オーバレイ上の遅延 • 1ノードから 5クラスタのノード上のobjectへRMI : ping() • pingで測定したRTTと比較 • overlay, 1 hop = ~1.5 [ms] www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

43. オーバレイ上のバンド幅 • 引数 (de)serialization overhead 大 • Full 1Gbit Ethernetで理想最大値： 40[MB/sec] • iperf測定値から算出される最大値と比較 • overlayでhopをするたびにバンド幅が減少 • store-and-forward Overlay hop数 でクラスタ内でもバンド幅が変化 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

44. Master-worker in 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) • Full Master-Worker • 並列RMI • New RMI for idle workers • ノードの参加・脱退 • Non-event driven Signal for join Block & Handle join Master init master = Master() master.register(“master”) master.run() Worker init worker = Worker() master = RemoteRef(“master”) master.join(worker) while True: sleep(1) Failure handling lookup on join www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

45. Grid上で並列分散計算の需要 • 例：Webアプリケーション • CGIとのインタラクション • タスク分割・負荷分散 • 結果集約・CGIへ結果加工 複雑な協調を必要とする backend Publicly accessible Application www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

46. 提案するモデルでのプログラミング #非同期 RMI 実行 f1 =foo1.doJob.future(args) f2 =foo2.doJob.future(args) #他の計算… … #返り値を取得。 Wait value1 =f1.get() value2 =f2.get() • futureで非同期RMI • 呼び出しに対するplaceholder • いずれ結果が格納される • 明示的なスレッドは不要 • 別スレッドによるcallbackなどはない • RMIを処理する側は？ www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

47. プログラミングモデルが提供するもの • 柔軟性：既存のオブジェクト指向言語をライブラリ拡張 • 並列分散計算に携わる諸問題を解決 • ロックを意識させない • オブジェクトの所有権を使ったimplicitな排他制御 • block時に所有権をimplicitに委託する：デッドロック予防 • event-drivenに陥らないイベント処理 • 同期モデルと協調したsignalセマンティクス • 参加・脱退への対応 • object lookup：　「最初の参照」問題 • 故障に対する例外セマンティクス • 分散した動的な環境(Grid)を簡潔に扱えるモデル www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

48. 資源間通信と協調の実現 Central Manager • Condor/DAGMan [Thain et al. ‘05] • バッチスケジューラ • 「タスク」はスクリプトで表現 • タスク間の依存関係はDAG • Ibis / Satin [Wrzesinska et al. ‘06] • 分散環境で分割統治問題 • 子タスクに分割 • タスクには親子関係 Assign Busy Nodes Cluster Task • タスク間の協調は中間ファイル媒体 • 依存関係のあるタスク間での通信に限定 DAG Dependency Relationship www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

49. 参加・脱退の処理 • JoJo2 [Aoki et al. ‘06] • Master – Worker • Event driven • イベント毎にハンドラ定義 • タスクの終了 • 参加 • 脱退・故障 Failure Handler Join Handler Join • 同期の問題 • イベント・ドリブンは分かりにくい • 提案する同期セマンティクスに非同期イベント通知機構を導入 • Event-drivenでない記述が可能 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

50. 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 28 Global/ 238 Private Peers Case: 95 % www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy