1 / 45

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

gluepy : 複雑なグリッド環境で 柔軟なプログラミングを 実現するフレームワーク. 東京大学 田浦研究室 M2 弘中 健. Grid を用いたアプリの普及. 多数 の単体 ジョブ 全く通信・協調がない アプリの並列化 密 な 資源間 の通信・協調 が必要 並列分散計算が身近に必要. グリッド計算上の問題点. Grid 環境の複雑さ 動的参加資源 資源の故障・脱退 接続性の問題 NAT/firewall. Fire Wall. leave. ユーザにはこの複雑さを解決する グリッドフレームワークが不可欠. join.

azuka
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. gluepy:複雑なグリッド環境で柔軟なプログラミングを実現するフレームワークgluepy:複雑なグリッド環境で柔軟なプログラミングを実現するフレームワーク 東京大学 田浦研究室M2 弘中 健 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

  2. Gridを用いたアプリの普及 • 多数の単体ジョブ • 全く通信・協調がない • アプリの並列化 • 密な資源間の通信・協調が必要 • 並列分散計算が身近に必要 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

  4. Gridフレームワークの課題 • アプリの表現・記述が簡潔・柔軟 • アプリケーションの動作を自然に記述 • グリッドの「複雑さ」に係る処理は最小限 • グリッド環境への適応も容易 • 複雑な環境上でも動作 • ユーザに大きな設定負担をかけない Fire Wall App. leave 適応 join www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

  6. 既存のアプローチ (2) doJob() • 部分的にプログラミング導入 • 例：Master-Worker framework • master/worker部分を記述 • Job 分配 • ワーカの参加・脱退 • エラー処理 • 表現できるアプリは限定的 • 提供されるフローに束縛 error() join() より幅広い問題を対象に：より柔軟・一般的な記述が必須 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

  8. 本研究の貢献 • Grid-enabled分散オブジェクト指向framework • オブジェクト指向言語Pythonに分散拡張 • 環境の複雑さ対応に主眼 • 参加・脱退・接続性 • 柔軟・簡潔なプログラミングと 最小限の設定を実現 • 並列アプリをグリッドの分散環境で 繋ぎとめる“のり” (glue) 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. 分散環境でオブジェクト指向 Proc: A Proc: B • ABCL [Yonezawa ‘90] JavaRMI, Manta [Maassen et al. ‘99] ProActive [Huet et al. ‘04] • 分散オブジェクト指向 • オブジェクトを資源間で分散 • 計算の分散 • メソッド呼び出し • RMI (Remote Method Invocation) • 非同期RMIで並列計算 • アプリの記述は自由 a a.f() f() RMI Proc: A Proc: B Proc: B Proc: B a a.f() a a.f() a a.f() async. RMI f() f() f() www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

  13. Grid上分散オブジェクト指向の課題 Proc: A Proc: B Proc: A Proc: A • スレッドの競合 • 1つのオブジェクトに同時多数RMI • Active Objects • 1 object = 1 thread • デッドロックの懸念： e.g.: 再帰呼び出し • 参加処理の記述 • どのように参加するか • 参加のイベント通知 • Event –drivenなループではflowが分断される • 脱退への対応 • 透過的な解決は困難 a a.f() a.f() a.f() f() f() f() race Active objects a b b.f() f() a.g() deadlock www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

  14. Grid上実行の課題 Fire Wall • 接続性を解決 • オーバレイを構築 • ProActive [Huet et al. ‘04] • 接続設定ファイル • Jojo2[Aoki et al. ‘06] • SSH / UDP broadcast • 最小限の仮定・負担でデプロイすることが必要 NAT www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

  15. 提案 : gluepy • Grid環境用分散オブジェクト指向フレームワーク • Pythonのライブラリ • プログラミングモデル：記述を支援 • オブジェクトに「所有権」 • レースを解消 • ノード参加記述の支援 • 他のオブジェクト参照取得可能 • イベントに対してblocking操作がunblockし、処理する • ノード脱退のセマンティクス • 呼び出し失敗に対する例外 • 処理系：接続性 (NAT/firewall)の自動的解決 • ピア間で自動的に接続のオーバレイ構築 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

  16. The Basic Programming Model Proc: A Proc: B • 分散オブジェクト • あるプロセスで生成 • RMIでアクセス • Passive Objects • 占有スレッドはない • スレッド • あくまで並列処理のため • 同期・非同期RMIは 陰にスレッド生成 • Future • 非同期RMIの返り値 • placeholder • 呼出し中の例外も格納され リレイズされる a Spawn for RMI a.f() f() Proc a Spawn for async F = a.f() async f() store in F 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にシグナルを送る • 非同期イベントへの対応 • イベントを「シグナル」として表現し、扱う • Unix のシグナルセマンティクス • Blocking操作がunblockする • オブジェクトへのシグナル • オブジェクト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. 提案 : gluepy • Grid環境用分散オブジェクト指向フレームワーク • Pythonのライブラリ • プログラミングモデル：記述を支援 • オブジェクトに「所有権」 • レースを解消 • ノード参加記述の支援 • 他のオブジェクト参照取得可能 • イベントに対してblocking操作がunblockし、処理する • ノード脱退のセマンティクス • 呼び出し失敗に対する例外 • 処理系：接続性 (NAT/firewall)の自動的解決 • ピア間で自動的に接続のオーバレイ構築 www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

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

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

  29. 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/gluepy

  30. Parallel deployment • たくさんの資源を使う場合 • 逐一、consoleで叩くのも大変 • 並列 deployerを使う • Batch schedulerを使う • InTriggerの場合：torque, qsub • GXPを使う • gxpc e command で一括投入 • gxpc mw command を使う • bootstrap serverが不要になる $ gxpc export VAR=VALUE が使える • $ gxpc e python client.py • $ gxpc mw python server_client.py www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

  31. 実アプリケーション例 • 組み合わせ最適化問題を解く • Permutation Flow Shop Problem • 並列 branch-and-bound • Master-Worker型 • 定期的なバウンド更新 • 分散 • 探索空間を分割し、タスクにする • ワーカ • C++逐次ソルバを外部プロセスで起動 • gluepyはソルバ間の通信・同期に使う www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

  33. 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

  34. Troubleshoot Search Engine Overview async. doQuery() Graph extraction Python CGI doSearch() rescoring parsing async. doWork() Leveraged sync/async RMIs to seamlessly integrate parallelism into a sequential program. Merged CGIs with Grid backend www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

  36. まとめ • Grid用分散オブジェクト指向フレームワーク • 計算資源の増減に対応 • 複雑なWAN環境上の接続性解決 • プログラミングモデル：柔軟・簡潔な記述 • SerialObjects • ノード参加の記述をサポート • ノードの脱退：RMI失敗には例外 • 処理系：Grid上実行可能 • 自動的なオーバレイ構築 • InTriggerを用いた事例：Grid上のアプリの繋ぎ • 並列 flowshopソルバ • トラブルシュートサーチエンジンバックエンド www.logos.ic.i.u-tokyo.ac.jp/~kenny/gluepy

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

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

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

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

  41. 例：実験環境 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

  42. 必要な設定 • オーバレイ構築に必要な設定 • 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

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

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

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

More Related