Transcript ppt - 東京大学
適応的並列計算を支援するプロ
トコルの設計と正当性の証明
関谷 岳史，田浦 健次朗，近山 隆
（東京大学）
背景
• 動的に変化する分散計算環境
– 他のユーザとの資源の共有
– ヘテロなグリッド環境
• そのような環境で資源の有効利用のために
は
– プロセスの動的な参加・脱退・再配置
– プロセス間の通信路の動的な張替え
を行う必要がある
プロセスの動的な脱退
• 単にプロセスを終了するのでは故障と同じ
– 途中までの計算状態や他のプロセスとの通信メッセージ
が失われてしまう
• 「安全な」脱退とは
– 通信路上のメッセージを喪失しない
• 自分宛にメッセージが飛んでいるときにcloseしない
– プロセスが計算状態などを他のプロセスへ送信できる
• プロセスが脱退を完了するまではメッセージを押し付ける相手が
いる
マスタ・ワーカモデルによる
プロセスの動的な脱退
• 1つの脱退しないマスタと複数の
ワーカからなる
• ワーカはマスタとのみ通信を行う
ので、マスタとの簡単なやりとりで
安全に脱退ができる
• 問題点
– マスタがボトルネックになりがち
– 広域分散環境ではマスタとワーカが
離れてしまう可能性あり
Master
Worker
一般の接続トポロジーでの
プロセスの動的な脱退
• プロトコルがやるべきこと
– 通信路上のメッセージをすべて”掃き出
す”
– 脱退を完了する直前の計算状態を送
る相手を確保しておく
Naïveな手法
– 周りのプロセスへ脱退したいことを知ら
せる
– 周りのプロセスはその返事を返す
– 返事をすべて受け取ったら、計算状態
をそのうちひとりに送って脱退完了
Naïveな手法ではダメな点
• 周りのプロセスも脱退
を希望していたときは
破綻してしまう
• システム全体としての
接続グラフが非連結に
なることも
デッドロック
グラフが分断
本研究の目的
• 安全な脱退のためのプロトコルの設計
– メッセージを喪失・複製しない
– 任意の接続トポロジー
– 任意のタイミングで脱退を希望可能
– デッドロックを起こさない
• その正しさの証明
発表の流れ
• 関連研究
– 脱退に対するアプローチによる分類
• 問題設定
– 仮定と問題定義
• 提案手法
– プロトコルの動作例
– 正しさの証明の概要
• 実装と実験
• まとめ
脱退に対するアプローチ
その1
• メッセージが明らかにないタイミングで脱退
– ループを並列実行し、各イテレーションごとにバリ
ア同期をとるような計算([松原ら2003]など)
• 問題点
– 同期をとるようなアプリケーションでしか利用でき
ない
JOIN
sync
sync
sync
P1
P2
P3
P4
LEAVE
脱退に対するアプローチ
その2
• 故障を前提とし、脱退が起きた際に個々の
メッセージの到達について保証しないもの
– 分散Cilk [Blumofe et al.1997]
– P2P通信システム (Tapestry [Zhao et al. 2000]な
ど)
• メッセージの喪失に対して、ユーザレベルで
の対応が必要
本研究のアプローチ
• 故障をないものと仮定
• 特定の接続トポロジー・計算モデルを仮定し
ない
• 各プロセスが独立に任意のタイミングで脱退
を希望できる
• メッセージを絶対に失わない
本プロトコルが置く仮定
•
•
•
•
プロセス・通信路は故障しない
接続グラフは連結
通信路はFIFO
任意のプロセス間で直接新しい接続を張ることがで
きる
• プロセスは
– メッセージの生成・脱退の希望を任意のタイミングで行う
– 他のプロセスによって生成されたメッセージを受信し、消
費する
– 脱退を希望した後はメッセージを消費しない
プロトコルが満たすべきこと
• Safety
– あるプロセスによって生成されたすべてのメッセージは、
他のいずれかのプロセスによって消費される
• Progress
– 脱退を希望したプロセスは必ず脱退できる
• プロトコルはデッドロックやライブロックしない
• Connectivity
– 新しく脱退するプロセスがいないときに接続グラフはいず
れ連結になる
本プロトコルとルーティングの関係
• 本プロトコルは、メッセージが”特定の”プロセ
スに届くことを保障するわけではない
– “特定の”プロセスは次の瞬間には脱退してしま
うかもしれない
• 本プロトコルの応用例:マイグレート可能な分
散オブジェクト
– 本プロトコルが維持するグラフ上でオブジェクトに
対するメッセージをルーティング
プロトコルの流れ
•
グローバルな流れ
1. 脱退をするプロセス同士で木構造を作る
2. 木構造の葉のプロセスから順に脱退
•
ローカルな(各プロセスでの)流れ
1. 脱退を開始したプロセスは周りのポートにSEEKROOT
メッセージを送る
2. 脱退を開始していないプロセスがSEEKROOTを受け
取るとそのポートにROOTメッセージを送る
3. 1つ目のROOTメッセージを受け取るとそのポートを自
分の”親”に設定し、その他のポートにROOTメッセージ
を転送
4. すべてのポートからROOTメッセージを受け取ると最後
に自分の親へ向けて、計算状態を送信し脱退を完了
プロトコルの動作例
はじめの状態
ほぼ同時に複数プロセスが
脱退を希望
脱退したい
脱退したい
脱退したい
脱退したい
脱退したい
脱退したい
脱退したい
SEEKROOTを送る
SEEKROOTを受
け取った
脱退したい
脱退したい
脱退したい
SEEKROOTを受
脱退したい
け取った
SEEKROOTを受
SEEKROOTを受
け取った
け取った
脱退したい
脱退したい
SEEKROOTを受
け取った
脱退したい
ROOTを送る
ROOTを受け
取った
ROOTを受け
取った
SEEKROOTを受
け取った
ROOTを受け
取った
SEEKROOTを受
け取った
SEEKROOTを受
SEEKROOTを受
け取った
け取った
SEEKROOTを受
け取った
Leafノードから順に脱退
接続性を回復
プロトコルのメッセージ
• DATA
– ユーザメッセージ
• SEEKROOT
– 脱退を開始したプロセスが周りのプロ
セスへ送る
• ROOT(K)
– 脱退のための“木”を作るメッセージ
– 木のrootになるプロセスから送られ、
次々にfloodingされる
– Kは木のrootのプロセスIDの集合
ROOTメッセージ
プロセスiの状態変数
Pi
leavei
Ki
starti
– 管理するポートの集合
– 接続性を保つために接続すべきプ
ロセスの集合
Mi
– 他のプロセスへ送るべきメッセージ
の集合
– 脱退を希望している
– 脱退を開始している
parent
parenti
– 親のプロセスへ繋がるポート
childreni
– 子のプロセスへ繋がるポートの集
合
children
children
メッセージが失われない仕組み
1. ROOTメッセージを送り出したポー
ト childreni からは以降なにも送
らないようにする
ROOTを受け取ったポートは安全に
closeできる
2. 脱退する直前には必ず parenti
のポートがある
脱退する直前まで他のプロセスへ
メッセージが押し付けられる
接続性の回復
• 脱退によって接続グラフが分断されてしまうこ
とがある
• 接続性を保つ仕組み
– rootのプロセスはプロセスID(プロセスにつなぐた
めの情報)をROOTメッセージと一緒に送る
– 受け取ったIDは Ki に追加する
– ｒootのプロセスは、 Ki のすべてのプロセスへ接
続する
正しさの証明の概要
•
3つのことを示す
1. メッセージが失われない
•
•
プロトコルの管理外のポート(closeしてしまったポート)にメッ
セージがやってこない
プロセスがDATAメッセージを保持したまま脱退を完了しない
2. 脱退を希望したプロセスはいずれ脱退を完了できる
3. 新しく脱退するプロセスがいないときにいずれ接続グラ
フが連結になる
•
詳細は予稿集をご覧下さい。
1.メッセージが失われない
ROOTメッセージを送ったポートには以降いかなる
メッセージも送らない (Lemma 3)
– ROOTを送る各場合について、それぞれ示す
Pi に含まれないポートにメッセージがやってこない
(Theorem 1 前半)
– ポートp が p Pi になるには必ずROOTを受け取る必要
がある
– よって、Lemma 3から示される
プロセスがDATAメッセージを保持したまま脱退を完
了しない (Theorem 1 後半)
– 自分の親のノードへ向かって M i の中身を送ればよい
2.脱退を希望したプロセスはいずれ
脱退を完了できる(1)
• 右図のような有向エッジによって
定められるグラフをFとする
Fはforestで、各treeは脱退を開始
していないプロセスをrootとしてい
る (Lemma 5)
– Fの形が変わるときにforestであるこ
とが保たれることを示す
– ROOTメッセージを最初に送りだす
のは脱退を開始していないプロセス
parent
children
2.脱退を希望したプロセスはいずれ
脱退を希望
脱退を完了できる(2)
していない
脱退を開始したプロセスは必ず脱退を完
了できる (Lemma 8)
– 脱退を開始したプロセスiは脱退を開始してい
ないプロセスrと繋がっている(Lemma 6)
r
ROOT({r})
• エッジが切れる場合について調べる
脱退を希望したプロセスはいずれ必ずROOT
を受け取ることができる(Lemma 7)
– 1つ目のROOT受け取ると、いずれ脱退のた
めの条件が揃う
• 周りのプロセスの状態によって場合わけして、各場
合について調べる
i
脱退を希望
2.脱退を希望したプロセスはいずれ
脱退を完了できる(3)
脱退を希望しているプロセスはいずれ脱退を
開始できる (Lemma 13)
– 開始のための条件をいずれ満たすことを示す
• childreni : Lemma 8から示される
• K i : もし i K jならば、 j Ki (Lemma 11)
よっていずれ j Ki であるすべてのjから接続を
acceptすることになる
iKj
j Ki
i
k
l
j
2.脱退を希望したプロセスはいずれ
脱退を完了できる(4)
• 証明：2つのLemmaから示される
– 脱退を希望したプロセスはいずれ脱退を開始で
きる(Lemma 13)
– 脱退を開始したプロセスはいずれ脱退を完了で
きる(Lemma 8)
3.新しく脱退するプロセスがいないと
きにいずれ接続グラフが連結になる
• 接続グラフGに{ij | i K j }となるよう
なエッジを加えたグラフをCとする
Cは常に連結 (Lemma 14)
i
– GのエッジやCのエッジが削除する場
合に連結が保たれることを各場合につ
いて示す
• 証明：
– 新しくプロセスが脱退しないといずれ
G=Cになる(Lemma 15,16)
– Lemma 14からCは連結なのでGも連
結
j
iKj
実装と動作確認
• プロトコルを通信ライブラリとして実装
• 実際の動作のログを可視化
– 同一クラスタ内の118ノードに1プロセスづつ立ち
上げ、そのうち50プロセスをほぼ同時に脱退させ
る
– 接続グラフは2分木
評価実験
• 4つのクラスタの環境で1クラスタ上のすべて
のプロセスを一度に脱退させる
– 1ノードに対して1プロセス
– 各プロセスは1MBの計算状態を持ち、脱退する
ときには、それを別の脱退しないプロセスまで送
る必要がある
– 接続グラフは同じクラスタのプロセス同士が近く
なるようなbinomial tree
実験環境
50Mbps
Cluster A @柏
(64 nodes)
Cluster C @本郷
(93 nodes)
64プロセスを一度
に脱退させる
50Mbps
500Mbps
32Mbps
Cluster B @西千葉
(64 nodes)
Cluster D @本郷
(68 nodes)
比較対象
(排他制御プロトコル)
• 中央サーバが同時に１プロセスず
つ脱退するように調整
• 同時に1プロセスずつであれば簡単
なプロトコルで安全に脱退可能
• 脱退にかかる時間は脱退するプロ
セス数に比例
実験結果
•
中央サーバを
1. Cluster B(脱退するプロセスと同じ)に配置
2. Cluster Cに配置
•
提案プロトコルでは(1)に比べて半分
程度の時間で脱退を終えた
– 提案プロトコルでは
•
(周りのプロセスと合意をとるためのメッ
セージが往復する時間)
+ (計算状態を転送する時間)
が複数のプロセスで並列に実行される
12
10
提案プロトコル
排他制御(1)
排他制御(2)
8
6
4
2
0
脱退にかかった時間(sec)
まとめ
• プロセスが安全に脱退を行うためのプロトコ
ルの設計・正しさの証明を行った
– 任意の接続トポロジー
– 各プロセスが独立に任意のタイミングで脱退を希
望可能
• マルチクラスタ環境で実験を行い、プロトコル
の性能評価を行った