狠狠撸

狠狠撸Share a Scribd company logo
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]
■ Cloudコンピューティングが普及
? 複数のコンピュータを用いてサービスを運用
2
近年のオンラインシステム
抽象化されたCloudの中身は複数マシンが接続
■ Dropboxのようなデータを共有?同期するシステムが普及
? Cloudと抽象化されたコンピュータ集合にデータを預ける
3
データ共有サービス
■ ユーザがアップロードするファイルの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技術を用いての同期?分散を行うシステム
LifeStu?について紹介
この問題を解決するサービス
■ P2Pネットワーク
? 複数のコンピュータが互いに直接接続
5
Peer-to-Peerネットワーク
サーバーを必要とせず、クライアント同士で通信が可能
本発表ではChordアルゴリズムを紹介
■ P2Pネットワークではデータの分散配置が可能
? 1つの同じデータを5人のユーザがアップロードした場合
6
P2Pにおけるデータの分散配置1
1つのファイルで5倍のディスクスペースを使用
ディスクスペース逼迫する要因
Cloudコンピューティングでは
■ 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
■ 分散ハッシュテーブル
? そもそも、マシン群へデータを保存?取得するとは?
8
P2Pの基本的なアルゴリズム
データの実態はマシン群のどこかのマシンに存在する
データを保存
データを取得
■ 各々のマシンはマシン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
■ ハッシュ関数とは
? データを元に別の空間に射影する関数
10
ハッシュ関数
mod 素数2
素数1
MD5
SHA-1
etc..
8c7dd922ad47494f
c02c388e12c00eac
971c419dd609331343d
ee105?fd0f4608dc0bf2
45682183
射影
ハッシュ関数 ハッシュ関数
■ 各々のマシンはマシン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 = 0x00360x0001 0x0011
0x0021
0x0031
:担当範囲
マシン 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
:担当範囲
■ 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
115
7
14
6
13
5
0
8
12 4
11
3
10
2
9
1
m=4のとき
ID空間が密や疎になることがない
■ Chordの担当領域も時計回りで決定
? 以下のようなChordネットワークを仮定
ノード8が保存
14
Chordネットワークのルーティング
13
0
8
313
0
8
3
1
2
6
時計回りで最初にぶつかったノードが担当
ノード3の担当領域は1, 2, 3
Hash = 6
Successorと呼ぶ
3は0のSuccessor
8は3のSuccessor
■ 経路表内のSuccessorを用いてデータをルーティング
15
経路表の構築
13
0
8
313
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つでもノードが切断されると到達性が確保されない
■ SuccessorListを保持して到達性を向上
16
Successorの冗長化
13
0
8
313
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万接続あるとコストが高い
■ 経路表に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)
■ 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
新規ノード
■ 単に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のまま
■ 自ノードの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
修正は行われない
■ 自ノードの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
■ 自ノードの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の存在を検知
■ 自ノードの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
■ 自ノードの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処理は
定期的に行われる
■ 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のすべての座標にアクセス
? 宛先が変わっていたら修正
■ 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
…
…
…
ネットワークが修正
■ ネットワークが維持されているとデータの共有?分散が可能
? このようにP2Pネットワーク上で処理が行える
27
データの共有?分散
7
14
6
0
8
12 4
11
10
1
7
14
6
0
8
12 4
11
10
1
複数コンピュータ間での
サーバーを除いた通信が容易に可能
■ P2Pネットワーク上で、Dropboxのようなシステムを運用
28
LifeStu?
P2Pなので、管理者であっても
データを閲覧することができない
ネットワーク上のデータの重複を回避
■ ネットワーク上のノード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
34
必要なときのみ
結合?復元
■ サービスを使っている不特定多数が共有しては問題
? データを持っているユーザのみ復号化を許可
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 =
秘密鍵
暗号化 =,
秘密鍵
データを所持している人のみ復号化可能
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
秘密鍵
秘密鍵
秘密鍵秘密鍵
秘密鍵
データを所持しているユーザなら
秘密鍵を生成できる
必要なときに復号化
■ P2Pネットワーク技術の基礎としてChordを取り扱った
? Cloud技術への応用として、LifeStu?の概要を紹介
? P2P技術の基本は比較的容易で応用しやすい
? 分散ハッシュテーブルやSelf-Encryptionはオープンソース
32
まとめ
(GitHub)
システム開発や研究を行う上で役に立てていただければ。

More Related Content

P2P 技術と Cloud コンヒ?ューティンク?への応用