揮発性資源上での並列分散計算を支援するオブジェクト指向ライブラリ

東京大学弘中健　澤井省吾　田浦健次朗

背景

利用できる計算資源の拡大 Grid5000(France) DAS-3(Neth.) InTrigger(Japan)

出来るだけ多くの資源を使った計算 資源はヘテロな環境にある

複数のクラスタ・ NAT/Firewall 使える資源は一定ではない

バッチ・キュー 使える時間の制約

計算途中の参加・脱退⇒ 資源は「揮発的」である

leave

join

Fire Wall

需要

依存性の少ない重い処理を並列化 非常に多い情報量の処理 多分野に渡った需要

自然言語処理 遺伝子情報解析

大量の入力ファイルを分割し、並列処理 逐次： 1 年間 → 並列： 1 日・数時間

簡単に広域分散計算資源を繋ぎ合せ、並列化したい

広域分散資源を繋ぎ合わせる

上層 (user level) の見え方 任意の資源間で通信

透過的な方法 簡潔に記述

サポートする下層の環境 揮発的資源

参加・脱退 Firewall/NAT

Fire Wall

join

leave

透過的なP2P な通信

Requirements

透過的通信 全対全接続を仮定しない システムに容易にプロセスを追加できる システムから途中に脱退を許す 故障した場合、検知する術を与える

本研究の貢献

dds:Python の分散オブジェクト指向ライブラリ RMI でプロセス間の通信を透過的に NAT/Firewall にも適用可能 動的な資源の投入が可能 ポータブル・記述も簡潔

ライブラリを用いた適応的並列処理フレームワーク 揮発性資源に耐える

動的に資源の投入・削除が可能

今後の発表の流れ

関連研究 dds : Python ライブラリの紹介 dds を用いた並列化フレームワーク フレームワークを用いた実験 まとめ

関連研究

ProActive [Huet et al. ‘04] Java に分散オブジェクトを追加 計算参加ノードは固定 複雑な XML 設定ファイルを手書きする必要

ネットワーク構成の詳細な知識が必要 Ibis + Zorilla [Drost et a ｌ . ‘05]

ノード (Peer) 間で overlay network を構築 資源の追加・削除にも対応している

P2P システム上で Java 分散オブジェクトの RMI を実装

手軽に繋ぎ合せたい：スクリプト言語を採用 自然言語処理、ウェブアプリケーションで使う人にとって java

は overkill

関連研究

Map-Reduce(Hadoop) [Dean et al. ‘04] ユーザは map, reduce の関数を定義するだけでクラスタで

処理を自動並列化 フレームワークの機能に制約される 接続の port 決めうち

クラスタ環境に限定 master worker ホスト名を列挙した設定ファイルの記

述 Martlet [Goodman ‘06]

並列関数型言語 大量の分散データに対する処理を並列化 開発中でまだ実装は明らかでない

dds: 分散オブジェクト指向ライブラリ Python 言語のライブラリ

分散オブジェクト間の RMI の実装 プロセスを跨るオブジェクトへの　　アクセスを透過的に扱う 遠隔のプロセスで容易に計算が可能

導入しやすい 設定ファイルなし import するだけ

広域分散環境への対応の記述を出来るだけスマートに

import import ddsdds # library # library をインポートをインポートdds.start()dds.start() # dds # dds を起動を起動…… 　　　　　　　　　　　　　　　　　　　　 # # 一連の処理一連の処理dds.shutdown()dds.shutdown() #dds #dds を終了を終了

foo.doJob()

RMI

計算

foo

Hello World

import ddsclass Foo: def hello(self): return “Hello World!”foo = Foo() dds.start()

#wrap 　分散オブジェクト化foo = dds.RemoteRef(foo)

# 任意文字列で外部公開foo.register(“Bar”)

while True: time.sleep(10)

dds.shutdown()

import ddsdds.start()

# 接続するdds.mk_connection( （ ip,port))

# 分散オブジェクト参照取得foo = dds.RemoteRef(“Bar”)

# RMI!print foo.hello()

dds.shutdown()

proc1.py proc2.py

$ python proc2.pyHello World!

非同期 RMI

並列計算 一つの RMI に block 出来ない 連続して発行できる必要

foo.doJob.promise()

RMI

計算

# 非同期 RMI 実行future1 = foo1.doJob.promise(args)future2 = foo2.doJob.promise(args)

# 他の計算……# 返り値を取得。 Waitvalue1 = future1.get_result()value2 = future2.get_result()

計算

RMI

foo.doJob.promise()

計算

RMI

foo.doJob.promise()

Block せずに続けて発効

まとめて取得

広域分散環境への対応

プロセス間で TCP Overlay Network プロセスは選んだ幾つかの Peer と接続を試みる

FireWall 内の相手の場合は失敗する グラフの連結性は仮定する

overlay 上で RMI msg を routing する 全対全の接続は必要無い

スケーラビリティ NAT/firewall 環境へ対応

FireWall

RMI

動的プロセスの参加

計算進行中にプロセスを加わる 動的に資源を投入するには必須 どれかのプロセスに TCP 接続

問題 どれかのプロセスの endpoint を

知る必要がある listen() している (IP, Port) ペア

endpoint をユーザーが明記することは大変 プロセスが存在するホストを特定する必要がある そもそも port は bind() してみないと分からない

dynamic bind

?

endpoint は何？

Endpoint Server(1)

接続可能な endpoint を格納したディレクトリサーバ 接続を受け付けるノードは登録 参加したいノードは問い合わせ、接続 ユーザーが覚えるものは

サーバの URL のみHTTP Server

EP 登録EP 取得

接続conn_list =

dds.get_endpoints(url)

dds.register_endpoint(url)

Endpoint Server(2)

endpoint は階層的に管理 登録・取得時に path を指定する 取得時に、 path で指定した階層

以下の endpoint のみ取得 繋ぎたいプロセスの集合が定義出来る

proc 0‘/hoge’

proc 1‘/’

proc 2‘/hoge/piyo’

proc 3‘/hoge/piyo’

/

/hoge

/hoge/piyo

proc 1

proc 0

proc 2, 3

‘/hoge’ ?⇒proc 0,2,3

広域環境対応に Endpoint Serverを使う ネットワーク環境ごとに

endpoint の登録を仕分けすることが出来る global IP → ‘/global’ Firewall → ‘/firewall’

参加プロセスの endpoint 取得 global IP プロセス

global IP の endpoint のみ求める

Firewall 背後プロセス global IP, 自分の LAN 内の

endpoint

⇒ 接続が成功する確率を高くすることが出来る

容易に広域環境で overlay network構築可能

proc 0‘/global’

proc 1‘/global’

proc 2‘/firewall/0’

proc 3‘/firewall/0’

proc 4‘/firewall/1’

proc 5‘/firewall/1’

未実装な点

プロセスの脱退 アプリケーションレベルで実装

overlay 上の RMI の fault tolerance 中継プロセスが RMI msg を持ったまま故障 故障の検知がまだ出来ない

「揮発的」資源のために今後必要

dds のまとめ

広域分散資源を繋ぎ合わせるライブラリ ( 同期・非同期 )RMI でプロセス間の通信を容易に NAT/Firewall がある環境でも繋ぎ合わせが容易

overlay network構築、 routing 容易にプロセスを追加することが可能

Endpoint Server

今後の発表の流れ

関連研究 dds : Python ライブラリの紹介 dds を用いた並列化フレームワーク フレームワークを用いた実験 まとめ

dds を用いた並列化フレームワーク ファイルを入力に取り、ファイルを出力とす

るような大量なジョブを並列に実行 資源は自由に参加・脱退可能 用途

大量の文章の自然言語解析 文章ファイルを配布し、並列に計算資源で処理 文章に字句解析、構文解析、意味解析と順番に処理

Job Staging

lexical syntax semantics

Job Staging

現在の job が次の job を生成する job が木構造に展開する

worker が job 実行時に新しい子 job を masterに投入出来る必要があるSTAGE 1

STAGE 2

STAGE 3

JOB SPAWN TREE

フレームワークの処理の流れ

worker の life-cycle 計算に参加 計算の実行

1. ジョブを受け取る 2. 入力ファイルの取得 3. 出力ファイルのコピー

をマスターに格納 4. 子ジョブの投入

計算から脱退 heartbeat で検知

Submit

Job Queue

File Request

OutputFileCopy

ファイル転送の詳細

基本的には、 Worker が直接 file source から取得 別の worker, master, HTTP Server

worker が他の worker から取得出来ないことがある source が既に脱退してしまった source が NAT/firewall 背後にいる

出力ファイルは Master

にも置かれるので　　そこから入手

Firewall

Non-Operational

RMI でプロセス間の通信を透過的に記述 他の MW フレームワークとの違い

master→worker だけでなく、 worker→master のRMI worker も master に子ジョブを投入出来る

worker ⇔ worker でも RMI が可能 random work stealing などの協調動作

には必要

dds での実装

DO JOB

SUBMIT JOB

STEAL

今後の発表の流れ

関連研究 dds : Python ライブラリの紹介 dds を用いた並列化フレームワーク フレームワークを用いた実験 まとめ

実験 (1)

HPSG パーサ： Enju [Miyao et al. ‘02] Head-Driven Phrase Structure Grammar 自然言語処理：英文の意味的・構文的解析 入力

MEDLINE: 医学系論文 DB のアブストラクト 背景

解析し、総合的な医学系意味的サーチエンジンを作りたい

膨大な量のアブストラクト 意味的解析は大きな計算量を要する

実験の手法 MEDLINE のアブストラクト 10個を 1 Job で処理

12,000 jobs 平均実行時間： 168[sec] 平均ファイルサイズ： 61[KB]

2 stage で処理 1. EnjuJob

Enju パーサでアブストラクトを解析 2. StoreJob

解析結果を自分のノードの持って来るジョブ あくまで、ファイル転送のオーバーヘッドを強調するた

めのもの

実験 (2)

EnjuJob StoreJob

Parse! Do Nothin

g

実験環境

Master Object/初期ファイル source hongo クラスタの 1 node

クラスタ 場所 コア数 ネットワークsuzuk 東京工業大学 72 Global

kototoi 東京大学 88 Global (FW)

imade 京都大学 60 Private

okubo 早稲田大学 28 Global

chiba 国立情報学研究所 186 Global

hongo 東京大学 98 Global

スケーラビリティの実験

異なるコア数で実行し、 speedup を測定 90 cores

hongo 363 cores

suzuk, okubo, chiba, hongo 513 cores(FW, private IP 環境も含める )

suzuk, imade, kototoi, okubo, chiba, hongo

スケーラビリティの結果

0

100

200

300

400

500

600

0 100 200 300 400 500 600

Cores

Spee

dup Enju Job

Enju + Store Job

ノード間のファイル転送

0

2000

4000

6000

8000

10000

12000

14000

16000

suzuk kototoi imade okubo chiba hongo

Fil

e T

ran

sfer

Co

un

t 513 cores: Intra-cluster

363 cores: Intra-cluster

513 cores: Inter-cluster

363 cores: Inter-cluster

ファイルの転送元

Master Node に集中11918 15100⇒

0

50

100

150

200

250

300

350

400

450

0 5000 10000 15000

Time [sec]

Act

ive W

orke

rs

資源が揮発的な環境での実験

実行時にノードの追加・強制終了を繰り返す 資源が揮発的 正常に全てのジョブが終了するか

資源が揮発的な環境での実験結果

0

5000

10000

15000

20000

25000

0 5000 10000 15000

Time [sec]

Jobs

Com

plet

ed

実験結果について

ファイル転送の部分でオーバーヘッドがある 他のワークフローフレームワークでは

レプリケーション 裏で転送

dds を用いて作ることの利点として クラスタを跨る資源を on demand で使える 拡張性が効く お手軽感

まとめ

分散オブジェクト指向ライブラリ スクリプト言語で広域分散資源を容易に繋ぎあわ

せることが出来る NAT/firewall 動的資源の追加

ライブラリを用いたフレームワークの実装 ファイルを入出力する Job を並列に実行 揮発性資源 ( 参加・脱退 ) に対応

今後の課題

ライブラリレベルでノードの故障・脱退に対応 FT な RMI

invoker に exception を発行 事前な object の避難

object migration を用いる 安全な脱退プロトコルを用いる [ 関谷ら’ 06]

Leaving…

プロセスの脱退はアプリケーションレベルで実装 heartbeat を RMI で実装

overlay 上の RMI の fault tolerance 中継プロセスが RMI msg を持ったまま故障 故障の検知がまだ出来ない

現状では「揮発的」資源には対応しきれない

ユーザーの手間

提供された Job クラスを継承したクラスを実装import job

class MyJob(job.Job): def __init__(self, filepath, host): job.Job.__init__(self) self.add_input(‘tcp’, filepath, host)

def run(self): fp = open(self.input_files[0])

# 一連の処理 (RMI なども OK)

self.add_output(‘tcp’, outfilepath, self.localhost) self.master.add_jobs(new_jobs)

継承 入力ファイルの指定TCPソケット接続で入手

出力ファイルの指定

子 Job も投入出来る

実行される頃には file は node に転送されている

myjob.py

従来の手法 ファイル転送・ジョブの簡単なスケジューリン

グ 「フレームワーク」に縛られない部分

あくまでも、 dds のライブラリ上のフレームワーク

ジョブ間で RMI などの協調も可能

今後の課題

資源の脱退を踏まえて FT な RMI dds ライブラリレベルで clean な脱退のサポート

全体として

RMI の恩恵 master – worker 間の interaction は batch queue

の単純な staging で出来るか！？ worker-worker 間でのファイルのやり取り

java などである job submission framework との差分は？ workflow との差分は？ それだけに限られてしまう。

フレームワークの概要

dds を用いたアプリケーション 膨大な量の情報の処理を並列化するフレーム

ワーク 複数の Job に分割して記述 一つの Job が子供 Job を作り出しても OK

用途 大量の文章の自然言語解析

文章ファイルを配布し、並列に計算資源で処理 文章に字句解析、構文解析、意味解析と順番に処理

lexical syntax semantics

フレームワークの下層部

フレームワークがカバーする部分 必要なファイルは自動的に転送 途中の資源の参加・脱退も考慮する ユーザーは目的の処理だけを記述する

アプリケーションに集中出来る

処理の流れ Master-Worker Model Worker は自由に参加脱退出来

る Master は heartbeat で monitori

ng 脱退した worker job は再実行

ファイル転送 処理に必要なファイルは work

er が source にアクセスする TCP, wget (HTTP)

出力ファイルは Master に集める

Job submission worker から子供 job の投入も

出来る

Submit

Job Queue

File Request

OutputFile