Grid/P2P プログラミングモデルと関連技術

Grid/P2Pプログラミングモデルと関連技術 東京大学情報理工学系研究科田浦健次朗

P2P • よく知られている起源: Napsterファイル共有 • ユーザ間の勝手な音楽ファイル転送を手助け • 手助け(持ち主の検索のためのディレクトリ作成)はサーバ, 転送はユーザ間で • その後 • 多数のファイル共有(Gnutella, Kazaa, WinMX, Winny, …) • 同時配信のためのP2Pネットワーク(BitTorrent) • 構造的P2Pネットワーク(Chord, Pastry, Tapestry, CAN, …) PPLサマースクール

P2Pのインパクト • 社会的インパクト(省略) • もう少し技術的なインパクト • 初めて多くの人が，非常に多数の計算機の協調によって，実質的にサービスの質・容量が向上しているのを見た • 強力なサーバ << 多数のPC • サービス= 大きなコンテンツの多数への配信 • ファイル共有 : キャッシュ • BitTorrent : 同時配信 PPLサマースクール

Grid • 起源となるアイデア: メタコンピューティング • 遠隔にある複数の資源を統合した計算 • 期待をこめた見方 • 世界中の計算資源の効率的な流通(融通) • 必要な時に，必要な人の下へ計算資源を即座に提供する基盤 • Where is 計算資源? • 専門の会社, ユーザの遊休PC, etc. • cf. Sun utility computing, SETI@Home, 多数のXXX@Home, … • 電力網(Power Grid)と同じくらい普遍的に，誰でも利用可能な「計算網」(Computational Grid) PPLサマースクール

SETI@Home • ユーザの遊休PCを計算資源とした並列計算 • Volunteer計算, インターネット計算 http://www.boincsynergy.com/ PPLサマースクール

SETI@Homeのインパクト • 印象的なクライアント数 • SETI@Home 39万 (2005年8月) • ここでも: • 初めて，多くの人が，非常に多数の計算機の協調によって，実質的にサービスの質・容量が向上しているのを見た • スーパーコンピュータ << 多数のPC • サービス= 科学を助ける計算 PPLサマースクール

P2P/Grid vs. 伝統的並列処理 • 非常に多数の計算機(インターネット上のPC)の協調によって，実質的にサービスの質・容量が向上している … • それって大昔からある「並列処理」では? • それもきわめて限定された，単純な応用(ブロードキャスト，CPU-only計算)の… • 半分は真実 • Broadcastのテクニックはよく知られている(MPIライブラリ) • 科学技術計算の高度な並列処理は多数行われてきた • But, これまでの多くの並列処理とプラットフォームの仮定が根本的に異なる PPLサマースクール

伝統的並列処理 vs P2P/Grid: プラットフォームに関する仮定の違い PPLサマースクール

課題と共通ゴール 並列環境固定, 性能一様, 故障なし, などの前提からの脱却共通ゴール「分散環境での一般的な並列処理」動的な変化, 故障, ネットワーク性能の多様性, スケール P2Pbeyond ブロードキャスト (e.g., 検索) Volunteer Computing beyond CPU-only型の応用(e.g., データ集約的応用) PPLサマースクール

共通鍵技術：オーバーレイネットワーク • 参加計算機間で，一部の(TCP)接続を作り，維持する • この接続でできたグラフ上をメッセージが流れる • 通信アブストラクションの提供．e.g. • マルチキャスト • 1-1通信 PPLサマースクール

なぜオーバーレイネットワークが重要か? • なぜ下位の通信レイヤで直接接続・通信しないのか? • 直接接続が可能とは限らない(Firewall/NAT) • N-Nの直接接続は資源を圧迫し，無駄に使う • ファイルディスクリプタ，ポート，TCPの再送Window • N-Nの接続は変更の際に維持するコストが大きい • cf. クライアントサーバ • トラフィック量(ホップ数)  許容台数，資源消費 ?? PPLサマースクール

本チュートリアルの中心課題 • 並列プログラミングのための「オーバーレイネットワークの構築とそれを利用した通信の実現方法」 • 資源消費(接続数) • ノードや接続の増減に伴う更新コスト • ルーティング性能(ホップ数) • 既存提案，興味深い理論，理論的な限界などの紹介 • これらは，分散環境(資源の動的増減，ネットワーク性能の多様性，故障，etc.)での並列処理の基盤となる(はず) PPLサマースクール

Roadmap • Part I: 並列・分散プログラミングモデルの実例 • メッセージパッシング，共有メモリ，RPC/RMI, タプルスペース • 大規模，分散，故障のある，動的な環境での課題 • Part II: 構造的P2PとDHTの枠組み • Part III: Advanced Topics • 任意の重みつきグラフに対するCompactルーティング • 構造がないグラフ上の効率的ルーティング PPLサマースクール

Part I: 並列・分散プログラミングモデルの実例 • メッセージパッシング • 共有メモリ • タプルスペース PPLサマースクール

Grid (分散)環境での並列処理の現状 • 「並列プログラミングなし」という実用的解 • 逐次プログラム+バッチスケジューラ(SGE, Condor, etc.) • 並列シェル(GXP, pdsh, dsh, etc.) • 伝統的並列プログラミングモデルの利用 • メッセージパッシング(MPI, PVM, etc.) • 分散共有メモリはほとんど使われない • 伝統的分散プログラミングモデルの利用 • RMI, RPC, ソケット • タプルスペース (JavaSpace, TSpace, etc.) • 分散環境に適した並列プログラミングモデル • Phoenix • マスターワーカモデル PPLサマースクール

課題 • 伝統的並列プログラミングの課題 • 分散環境で当然の故障，動的な資源増減下でのプログラミングを支援していない • ネットワークの制限(Firewall/NAT)下でしばしば動作しない • 伝統的分散プログラミングの課題 • 多くは1-1のみの通信をサポートしているのみで，「多数のプロセスの協調」を直接支援していない PPLサマースクール

メッセージパッシング • 実例 MPI, PVM • 基本アイデア: • 各参加プロセスに固定された名前(e.g., 0, 1, 2, …)をつける • プロセス名を指定した通信(メッセージ送信) • 基本API • send(p, msg) /* プロセスpにメッセージを送る */ • msg = recv() /* メッセージを受け取る */ • 集団通信(broadcast, reduction, etc.) p PPLサマースクール

メッセージパッシング:単純な実装のモデル • 各プロセスが「APIレベルのプロセス名  下位通信レイヤにおける名前」の対応を保持 • プロセスの増減がなければ起動時に定まり，不変 • send(p, msg)  下位通信レイヤの送信プリミティブを起動下位通信レイヤの接続 PPLサマースクール

メッセージパッシング:分析 • 固定した多数のプロセス集合による計算の素直なモデル • 全プロセス間で接続が許可されていれば, 1,000プロセス程度まではN-N接続可能(ボトルネックのない実装が容易) • 効率的な集合通信(特にbroadcast)の支援が容易 • プロセスが動的に増減する場合，プログラミングの複雑度が非常に増す • 参加中のプロセス名の管理 • プロセス  データのマッピングの管理 PPLサマースクール

共有メモリ • 実例: 共有メモリ計算機，分散共有メモリ(仮想共有メモリ) • 基本アイデア: • 通信にはプロセス名を用いず，別の名前空間(アドレス空間: 通常プロセス数よりずっと大きい)を用いる • プロセス間の通信は複数プロセスが同じアドレスにアクセスすることで(間接的に)行われる • 基本API: • WRITE(a, v) • READ(a) a PPLサマースクール

共有メモリ: 単純な実装のモデル • キャッシュ(複製)なし • アドレス空間を分割担当．各プロセスが，「アドレス  担当するプロセス名」の対応を保持 • read(a)/write(a, v) aを担当するプロセスへのメッセージ送信 read(a) a PPLサマースクール

共有メモリ: 分析 • 通信にプロセス名を用いないため，プロセスの増減下でのプログラミングモデルとして好ましい • 通信の効率が悪い(ほぼ常に2ホップ) • ブロードキャストプリミティブの不在 • 1-1をN回繰り返すことになる PPLサマースクール

タプルスペース • 実例: Linda, JavaSpace • 基本アイデア: • 共有メモリに類似した空間「タプル空間」にタプルを出し入れすることで通信 • 基本API • out(value) • value = in(template), value = rd(template) in(int, int) out(3, 5) (3, 5) PPLサマースクール

（string，int) （string, string”) （3, *) （”bye”, string, int) タプルスペース: 実装のモデル • タプルサーバを配置 • 全ての成立していない通信を格納する．i.e. • outされたが，マッチするinが発行されていないタプル • inされたが，マッチするoutが発行されていないタプル • in/out  タプルサーバとの通信 in/out （１，”hello”) （2，”bye”) （5，”hello”) PPLサマースクール（”bye”, 10, 12) タプルサーバ

タプルスペース: 分析 • 共有メモリの利点/欠点を多くの大部分継承する • タプルサーバがボトルネックにならない実装は難しい • 通信の粒度の通信が可能(メッセージのサイズが任意) • メッセージパッシングの利点を踏襲 PPLサマースクール

通信のアブストラクション Part I: まとめ(1) • 多かれ少なかれ，モデルを実装するとはプログラミングモデルレベルの通信  下位通信レイヤにおける通信(主にTCP接続を用いた通信) のマッピングを行うことである • 1-1メッセージのルーティング，マルチキャスト下位レイヤの通信 PPLサマースクール

Part I: まとめ(2) • 下位通信レイヤへのマッピングの方法は様々であり，トレードオフが存在する • OSの資源制約内でサポートできる台数 • 通信の性能(ホップ数など) • ボトルネックの有無 • 動的な更新のコスト PPLサマースクール

Part II: 構造的P2PとDHT • 基本アイデア: 参加ノードで協調的に，規則的に，オーバーレイネットワークを構築 • 不規則なネットワークでは困難な，1-1通信を効率的に実現 • 以下の3点の“good balancing point” • トラフィック量(ホップ数) • 消費資源(維持すべき接続数) • 参加・脱退時の更新コスト • 提供する通信のアブストラクション • 分散ハッシュ表(DHT) PPLサマースクール

DHT • Chord [SIGCOMM 2001]を例として説明する • 同時期に発表された類似システム • Pastry [Middleware 2001] • Tapestry [Berkeley Technical Report 2000] • CAN [SIGCOMM 2001] PPLサマースクール

構造的P2P: 動機 • 初期のP2Pシステム • 同一コンテンツの大量配信(ブロードキャスト)に威力 • 検索には洗練されていない方法を用いていた • 単一サーバ，flooding • 技術的言い換え • ブロードキャストは無秩序なオーバーレイネットワークで十分効率よく実行可能 • 1-1メッセージのルーティングは非効率的 PPLサマースクール

DHT (Distributed Hash Table) • 構造的P2Pが提供しているアブストラクション(問題設定) • put(key, value) • value = get(key) • keyは大きな整数の区間(e.g., [0, 2160))の要素 • 本質的には共有メモリと同じ • 注: 厳密な共有メモリの意味論(consistency)を実装するのはもっと複雑 a 鍵空間 PPLサマースクール

a あるプロセスの担当範囲 key b Chord (1) • 鍵空間[0, 2m) modulo 2m (m : たとえば160) • Chord ring, Chord circleなどと呼ばれる • 参加中のプロセスがこの空間を分割して担当する • 1プロセスは一つの区間(a, b] modulo 2mを担当 • bをそのプロセスのidと呼ぶ • 実装の鍵となる要素: ルーティング • 与えられたkeyを担当するプロセスへメッセージを配達する Chord ring PPLサマースクール

Chord (2) • 各プロセスは以下のプロセスへの接続を持つ • Chord ring上の両隣(predecessor, successor) • Finger table : 自分のid = bとして， • b + 2m – 1 • b + 2m – 2 • … • b + 21 • を担当するプロセス(最大でm個．プロセスidが均等分布していれば約log N個) • 2mノードのHypercubeネットワークを(ノードの集合を1ノードに縮約することにより)Nプロセスで模倣したものに近い PPLサマースクール

Chord ルーティング • 問題 key kを担当するプロセスにメッセージを届ける • if (kが自分の担当) {自分へ配達;} else { Finger tableからkを越えない最大のentry iを取り出す; /* k < b + 2i */メッセージを対応するプロセス(pi)へ転送} k PPLサマースクール

Chordルーティング • ホップ数 < m, プロセスidほぼ均等ならばO(log N) • ノードの参加・脱退時のコスト • O(log2N)個のメッセージ(接続の追加，変更) • いずれもHypercubeの性質(ノード当たりlog Nリンク, diameter log N)と比べると理解しやすい PPLサマースクール

注 • Chordおよび多くのDHTの提案は, 世の中で使われている “ファイル共有アプリケーション” と異なり，各ノードが望むノードと接続を作ることができると仮定している • 実用的には， “No firewall/NAT”を仮定 • 抽象的には，「完全グラフのspanner」を設計している • 伝統的ネットワークトポロジーの模倣が常に可能 • より現実に即した，発展形の問題 • 任意のグラフのspannerをオーバーレイネットワークとする • 重みつきグラフの元でのホップ数拡大係数 PPLサマースクール

Part III: Advanced Topics • 任意の重みつきグラフに対するCompactルーティング • 構造がないグラフ上の効率的なルーティング PPLサマースクール

t s ルーティング: 問題設定 • G = V, E : 重み付きグラフが与えられる • V : プロセスの集合, E : 通信路の集合 • 辺の重み: その辺を通るコスト(遅延) • タスク: パケットのソース sとあて先 tを与えられ，それを低いコストで届ける • コスト: 通った辺の重みの和 • 任意の重み付きグラフを考えることで，現実の分散環境を反映したモデルとなる 3 2 1 6 2 5 3 3 4 1 1 2 PPLサマースクール

プロセス 次ホップ 0 3 1 22 2 9 3 35 22 3 10 9 N – 2 22 N – 1 3 35 ルーティングの基本方式(最短路) • 基本アイデア: 全対全の最短路を計算する • 各ノードは，他の各ノードへの最短路に沿った次ホップを蓄えた表(経路表/ルーティング表)を保持 • 記憶領域: N log N • ルーティングの品質: 最適 PPLサマースクール

Topic 1: コンパクトルーティング • Nプロセスに対し，各プロセスがsubblinear (o(N))の記憶領域を用いるルーティング方式をコンパクトルーティングという • 当然コンパクトルーティングは最適でないルーティング(回り道)をする可能性がある • あるルーティング方式のstretch (伸び率) = [ そのルーティングによるコスト / 最短路のコスト ]の，全プロセス対にわたる最悪値 • 目標 : stretchを抑えたコンパクトルーティング PPLサマースクール

Taxonomy : Name Independence • トポロジ非依存名((topology) independent names) • ルーティング関数に与えられるあて先(アドレス)は，あらかじめ決められたノード名(e.g., 0, 1, …, n – 1) • トポロジ依存名 ((topology) dependent names) • ルーティング関数に与えられるあて先(アドレス)は，ルーティング方式が決めてよい • ルーティングに関する情報を，アドレスに「埋め込む」ことを許す • 極端な方法: グラフ全体の情報がアドレスに埋め込まれている • サイズ0のルーティング表 • 制約: アドレス長さ = log nの多項式 PPLサマースクール

例 • 重み一様な完全グラフに関するルーティングを考える常にマスタ(ルーティングセンター)を経由 stretch = 2 トポロジ非依存名  コンパクトにできないトポロジ依存名  コンパクトにできる (e.g., マスタ以外各ノードのアドレス=マスタ側ポート番号とする) PPLサマースクール

知られている結果 • (トポロジ依存名) Stretch 3 コンパクトルーティング • Cowen SODA 1999, “Compact routing with Minimum Stretch” • トポロジ非依存名 Stretch 3 コンパクトルーティング • Abraham et al. SPAA 2004, “Compact name-independent routing with minimum stretch” • Stretch 3は「最適」なコンパクトルーティング • 全ノードo(n)の記憶域でstretch < 3は達成不可能 • Gavoille et al. SIROCCO 1997, “Space Efficiency of routing schemes of stretch factor three” • 以降はCowenの方法の基本アイデアを紹介する PPLサマースクール

CowenのStretch 3 Compact Routing • 仮定 • G = V, E. 重みつき無向グラフ. nノード． • トポロジ依存名: i.e. ノードのアドレス(あて先)は事前に付け替えてよい(制約: アドレスはO(log n) bits) • 結果 • 任意のグラフに対し，Stretch 3 (最短路の3倍以下)でルーティング • ルーティング表サイズ O(n2/3 log4/3n) PPLサマースクール

基本アイデア • 準備: • 少数の「目印(Landmark)」ノードを決める • ただし，どのノードも最低一つの目印を近くに持つように • 各ノードuに対し「uの近くのノード」と，全目印への最短路を計算．uに，それら(のみ)への次ホップを保持 • ルーティング (s to t): • case 1: tがsの近く  最短路 • case 2: そうでない  tに最寄の目印を目指す : 目印 : あて先(t) : 送信元(s) case 1 case 2 PPLサマースクール

ポイント • なぜ経路表を小さくできるか? • 近くのノードと，目印へのエントリしか持たない • 必要な目印の数を抑えられればよい • なぜstretch 3か? • 後述 • 微妙なところ: • あて先ノードに最寄の目印をどう知るか? • 目印ノードの経路表の大きさは? • 答: アドレスに情報を含めておく • トポロジ依存名の活用実際の道  最短路 PPLサマースクール

アルゴリズム：全体構造 • 前処理 :以下を計算 • 目印の集合 L • 各ノード uに対するトポロジ依存名(3つ組) = u, uに最寄の目印 lu, luから uへの最短路上の次ホップ • 経路表構築 :各ノード uは，以下のノードらにする最短路を計算し，それに沿った次ホップを経路表に登録 • u に近いノード • 全目印 L • ルーティング (s t): • 自分に近いノードへは最短路 • それ以外は，tに最寄の目印を経由 PPLサマースクール

目印の選択 • 要件1: どのノード uも自分の近く (B(u)) に一つ目印を持つ • ある程度遠いノード間では目印を経由しても，ひどい回り道にならない • 要件2: 目印の数が少ない • 全目印へ最短経路を記憶しても表サイズがnにならない PPLサマースクール

前処理 • for uV {B(u) = uから近いn個のノード /*  < 1 : 定数．同距離はノード名で順序付け */R(u) = { y | uB(y) } /* uを近くに持つノード */}C = { u | |R(u)| > n(1+ )/2 }D = GREEDY_COVER(V, { B(u) }uV)L = C  D /* 目印 */for uV {lu = uに最も近い目印n = luからuへ最短路上の次hopaddress(u) = u,lu, n} PPLサマースクール

GREEDY_COVER • GREEDY_COVER(P, S) input: S : 集合, P : Sの，「大きさkの部分集合」の集合output: Pを覆うSの部分集合T. i.e. T S s.t. XPtXT = {} /* for each stept = 新たに覆われる集合が最も増える要素T = T + { t }return T • 事実: Pの各要素の大きさがkのときTの要素数は O(|S|/k log n) PPLサマースクール

Grid/P2P プログラミングモデルと関連技術