Slide 1

Slide 1 text

P2P技術とCloudコンピューティングへの応用 折原 レオナルド賢 The application to cloud computing and peer-to-peer network. Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan. Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications. SIGCOMM ’01, pp.149-160. (2001). [1]

Slide 2

Slide 2 text

■ Cloudコンピューティングが普及 ❏ 複数のコンピュータを用いてサービスを運用 2 近年のオンラインシステム 抽象化されたCloudの中身は複数マシンが接続

Slide 3

Slide 3 text

■ Dropboxのようなデータを共有・同期するシステムが普及 ❏ Cloudと抽象化されたコンピュータ集合にデータを預ける 3 データ共有サービス

Slide 4

Slide 4 text

■ ユーザがアップロードするファイルの75%~90%は重複[2] ❏ Cloud上のディスクスペースを逼迫 4 データの重複 Anthony D. Joseph. A Survey, Cloud File Sharing, and Object Augmentation. Pervasive Computing, IEEE, Vol.11, Issue.2, p.96, (2012). [2] 75%~90% 75%~90% P2P技術を用いての同期・分散を行うシステム LifeStuffについて紹介 この問題を解決するサービス

Slide 5

Slide 5 text

■ P2Pネットワーク ❏ 複数のコンピュータが互いに直接接続 5 Peer-to-Peerネットワーク サーバーを必要とせず、クライアント同士で通信が可能 本発表ではChordアルゴリズムを紹介

Slide 6

Slide 6 text

■ P2Pネットワークではデータの分散配置が可能 ❏ 1つの同じデータを5人のユーザがアップロードした場合 6 P2Pにおけるデータの分散配置1 1つのファイルで5倍のディスクスペースを使用 ディスクスペース逼迫する要因 Cloudコンピューティングでは

Slide 7

Slide 7 text

■ P2Pネットワークを用いてデータを共有 ❏ 1つのデータを5人のユーザで共有した場合 7 P2Pにおけるデータの分散配置2 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 2 3 4 5 5人が1つのデータの断片を所持している ➡1つのデータを5分割してそれぞれ所持 個人のディスクスペース消費は1/5で済む 一般的なデータであるほど、消費量は減る 1

Slide 8

Slide 8 text

■ 分散ハッシュテーブル ❏ そもそも、マシン群へデータを保存・取得するとは? 8 P2Pの基本的なアルゴリズム データの実態はマシン群のどこかのマシンに存在する データを保存 データを取得

Slide 9

Slide 9 text

■ 各々のマシンはマシンIDを持っている ❏ ハッシュ関数を用いてデータの保存場所を決定 9 データの所在 データの実態はマシン群のどこかのマシンに存在する :担当範囲 192.168.0.1 192.168.1.1 192.168.2.1 192.168.3.1 マシン IPアドレス マシンID 担当範囲 A 192.168.0.1 0x0001 0x0001~0x0010 B 192.168.1.1 0x0011 0x0011~0x0020 C 192.168.2.1 0x0021 0x0021~0x0030 D 192.168.3.1 0x0031 0x0031~0x0040 Hash = 保存場所 あるデータが与えられた時、 そのデータを代表する数値を得る関数 0x0001 0x0011 0x0021 0x0031

Slide 10

Slide 10 text

■ ハッシュ関数とは ❏ データを元に別の空間に射影する関数 10 ハッシュ関数 mod 素数2 素数1 MD5 SHA-1 etc.. 8c7dd922ad47494f c02c388e12c00eac 971c419dd609331343d ee105fffd0f4608dc0bf2 45682183 射影 ハッシュ関数 ハッシュ関数

Slide 11

Slide 11 text

■ 各々のマシンはマシンIDを持っている ❏ ハッシュ関数を用いてデータの保存場所を決定 マシン IPアドレス マシンID 担当範囲 A 192.168.0.1 0x0001 0x0001~0x0010 B 192.168.1.1 0x0011 0x0011~0x0020 C 192.168.2.1 0x0021 0x0021~0x0030 D 192.168.3.1 0x0031 0x0031~0x0040 11 データの所在 データの実態はマシン群のどこかのマシンに存在する 192.168.0.1 192.168.1.1 192.168.2.1 192.168.3.1 Hash = 0x0036 0x0001 0x0011 0x0021 0x0031 :担当範囲

Slide 12

Slide 12 text

マシン IPアドレス マシンID 担当範囲 A 192.168.0.1 0x0001 0x0001~0x0010 B 192.168.1.1 0x0011 0x0011~0x0020 C 192.168.2.1 0x0021 0x0021~0x0030 D 192.168.3.1 0x0031 0x0031~0x0040 ■ 各々のマシンはマシンIDを持っている ❏ ハッシュ関数を用いてデータの保存場所を決定 Hash = 0x0036 12 データの所在 データの実態はマシン群のどこかのマシンに存在する 192.168.0.1 192.168.1.1 192.168.2.1 192.168.3.1 0x0001 0x0011 0x0021 0x0031 :担当範囲

Slide 13

Slide 13 text

■ Chordではリング状にID空間を形成 ❏ IPアドレスとハッシュ関数を用いてマシンIDを設定 Chordでは 0~2 -1までの整数値を取る m 13 ChordのID空間 Chordネットワークは時計回りに移動 15 7 14 6 13 5 0 8 12 4 11 3 10 2 9 1 15 7 14 6 13 5 0 8 12 4 11 3 10 2 9 1 m=4のとき ID空間が密や疎になることがない

Slide 14

Slide 14 text

■ Chordの担当領域も時計回りで決定 ❏ 以下のようなChordネットワークを仮定 ノード8が保存 14 Chordネットワークのルーティング 13 0 8 3 13 0 8 3 1 2 6 時計回りで最初にぶつかったノードが担当 ノード3の担当領域は1, 2, 3 Hash = 6 Successorと呼ぶ 3は0のSuccessor 8は3のSuccessor

Slide 15

Slide 15 text

■ 経路表内のSuccessorを用いてデータをルーティング 15 経路表の構築 13 0 8 3 13 0 8 3 種別 IPアドレス マシンID Successor 192.168.8.1 8 種別 IPアドレス マシンID Successor 192.168.3.1 3 種別 IPアドレス マシンID Successor 192.168.13.1 13 ・・・ ・・・ 切断 1つでもノードが切断されると到達性が確保されない

Slide 16

Slide 16 text

■ SuccessorListを保持して到達性を向上 16 Successorの冗長化 13 0 8 3 13 0 8 3 種別 IPアドレス マシンID ステータス Successor 192.168.8.1 8 SuccessorList1 192.168.13.1 13 SuccessorList2 192.168.0.1 0 切断 SuccessorList全てにファイルを持たせ、冗長化 ➡ レプリケーション 到達性は向上した ➡ ノードが50万、100万接続あるとコストが高い

Slide 17

Slide 17 text

■ 経路表にFingerTableを追加 17 経路の短絡 7 14 0 8 12 4 11 10 1 7 14 0 8 12 4 11 10 1 種別 IPアドレス マシンID Successor 192.168.10.1 10 SuccessorList1 192.168.11.1 11 SuccessorList2 192.168.12.1 12 FingerTable1 192.168.0.1 0 FingerTable2 192.168.12.1 12 FingerTable3 192.168.10.1 10 FingerTable m 192.168.m.1 m … … … FingerTable1 FingerTable2 FingerTable3 最大で向かいのノードまでジャンプ可能 ➡ FingerTableを用いた経路長は O(logN)

Slide 18

Slide 18 text

■ P2Pネットワークではノードが追加・切断されることは頻繁 ❏ JoinとStabilizeを用いてネットワークを維持 マシンID6のノードが追加 ➡ 6を担当するノードを時計回りに検索 18 ノードの新規追加 7 14 0 8 12 4 11 10 1 7 14 0 8 12 4 11 10 1 種別 IPアドレス マシンID Successor 192.168.7.1 7 … … … Join Hash = 6 6 新規ノード

Slide 19

Slide 19 text

■ 単にJoinされただけでは、正しいルーティングが行われない ❏ Predecessorを用いて修正する 19 経路表の修正 Stabilize(Successor用) 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 Predecessor ➡ 1つ前のノードへの経路 種別 IPアドレス マシンID Successor 192.168.7.1 7 Predecessor 192.168.1.1 1 ノード4のSuccessorが7のまま

Slide 20

Slide 20 text

■ 自ノードのSuccessorにPredecessorがどのノードが聞く 20 Successor用 Stabilizeの動作 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 Successor 192.168.7.1 7 Predecessor 192.168.1.1 1 Successor 192.168.7.1 7 Predecessor 192.168.?.1 ? Successor 192.168.8.1 8 Predecessor 192.168.4.1 4 ノード4のSccssrは7 ノード7Prdcssrのは4 1 修正は行われない

Slide 21

Slide 21 text

■ 自ノードのSuccessorにPredecessorがどのノードが聞く 21 Successor用 Stabilizeの動作 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 Successor 192.168.7.1 7 Predecessor 192.168.1.1 1 Successor 192.168.7.1 7 Predecessor 192.168.?.1 ? Successor 192.168.8.1 8 Predecessor 192.168.6.1 4 ノード6のSccssrは7 ノード7Prdcssrのは4 2 間違いを修正 6

Slide 22

Slide 22 text

■ 自ノードのSuccessorにPredecessorがどのノードが聞く 22 Successor用 Stabilizeの動作 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 Successor 192.168.7.1 7 Predecessor 192.168.1.1 1 Successor 192.168.7.1 7 Predecessor 192.168.?.1 ? Successor 192.168.8.1 8 Predecessor 192.168.6.1 6 ノード4のSccssrは7 ノード7Prdcssrのは6 3 6にアクセス 一周まわって 6の存在を検知

Slide 23

Slide 23 text

■ 自ノードのSuccessorにPredecessorがどのノードが聞く 23 Successor用 Stabilizeの動作 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 Successor 192.168.6.1 7 Predecessor 192.168.1.1 1 Successor 192.168.7.1 7 Predecessor 192.168.4.1 ? Successor 192.168.8.1 8 Predecessor 192.168.6.1 6 ノード6にアクセス 6のPrdcssrは ”?” 4 ノード6のPrdcssr、 ノード4のSccssrを修正 4 6

Slide 24

Slide 24 text

■ 自ノードのSuccessorにPredecessorがどのノードが聞く 24 Successor用 Stabilizeの動作 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 Successor 192.168.6.1 6 Predecessor 192.168.1.1 1 Successor 192.168.7.1 7 Predecessor 192.168.4.1 4 Successor 192.168.8.1 8 Predecessor 192.168.6.1 6 ネットワークが修正 Stabilize処理は 定期的に行われる

Slide 25

Slide 25 text

■ FingerTable用のStabilizeを実行 ❏ FingerTableは元々m個と決まっている 25 FingerTableの修正 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 FingerTable1 192.168.?.1 ? FingerTable2 192.168.?.1 ? FingerTable3 192.168.?.1 ? FingerTable m 192.168.?.1 ? … … … FingerTableのすべての座標にアクセス ➡ 宛先が変わっていたら修正

Slide 26

Slide 26 text

■ FingerTable用のStabilizeを実行 ❏ FingerTableは元々m個と決まっている FingerTable用のStabilizeも定期的に行われる 26 FingerTableの修正 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 FingerTable1 192.168.14.1 14 FingerTable2 192.168.10.1 10 FingerTable3 192.168.8.1 8 FingerTable m 192.168.m.1 m … … … ネットワークが修正

Slide 27

Slide 27 text

■ ネットワークが維持されているとデータの共有・分散が可能 ❏ このようにP2Pネットワーク上で処理が行える 27 データの共有・分散 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 複数コンピュータ間での サーバーを除いた通信が容易に可能

Slide 28

Slide 28 text

■ P2Pネットワーク上で、Dropboxのようなシステムを運用 28 LifeStuff P2Pなので、管理者であっても データを閲覧することができない ネットワーク上のデータの重複を回避

Slide 29

Slide 29 text

■ ネットワーク上のノード4がデータを要求 ❏ 5分割されたデータのコピーをノード4へルーティング → 結合 29 P2Pにおけるデータの分散配置 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 1 2 3 4 5 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 1 2 3 4 5 1 2 3 4 必要なときのみ 結合・復元

Slide 30

Slide 30 text

■ サービスを使っている不特定多数が共有しては問題 ❏ データを持っているユーザのみ復号化を許可 30 データ共有・同期サービスにおいて 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 1 2 3 4 5 Self-Encryption データそのものを鍵として暗号化 Hash = 秘密鍵 暗号化 = , 秘密鍵 データを所持している人のみ復号化可能

Slide 31

Slide 31 text

31 Self-Encryption 7 14 6 0 8 12 4 11 10 1 7 14 6 0 8 12 4 11 10 1 1 2 3 4 5 秘密鍵 秘密鍵 秘密鍵 秘密鍵 秘密鍵 データを所持しているユーザなら 秘密鍵を生成できる 必要なときに復号化

Slide 32

Slide 32 text

■ P2Pネットワーク技術の基礎としてChordを取り扱った ❏ Cloud技術への応用として、LifeStuffの概要を紹介 ❏ P2P技術の基本は比較的容易で応用しやすい ➡ 分散ハッシュテーブルやSelf-Encryptionはオープンソース 32 まとめ (GitHub) システム開発や研究を行う上で役に立てていただければ。