Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
P2P 技術と Cloud コンピューティングへの応用
Search
LeonardoKen Orihara
June 29, 2017
Technology
0
87
P2P 技術と Cloud コンピューティングへの応用
大学院の輪講でやったはなし
LeonardoKen Orihara
June 29, 2017
Tweet
Share
More Decks by LeonardoKen Orihara
See All by LeonardoKen Orihara
男性育休を6ヶ月取って得られた知見たち
leonardo_mbc
0
350
Webでできる体験を考える会 / On the possibilities of PWA experience
leonardo_mbc
3
2.2k
Web Assembly と 画像・動画
leonardo_mbc
5
6k
React.js と動くもの、鳴るもの
leonardo_mbc
2
2.9k
ユーザー体験にフォーカスした管理画面の実装 - Developers Summit 2018 KANSAI
leonardo_mbc
3
1.5k
エンジニアがUXをロジックで考えてみる
leonardo_mbc
2
1.6k
ユーザー体験にフォーカスした管理画面の実装
leonardo_mbc
8
4.6k
UXとユーザビリティ計測
leonardo_mbc
0
290
ユーザエクスペリエンスの測定
leonardo_mbc
1
610
Other Decks in Technology
See All in Technology
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
230
アクセス制御にまつわる改善 / Improving access control
itkq
0
510
Vertex AI を中心に 生成AIのアップデートを共有します
kaz1437
0
290
MapLibreとAmazon Location Service
dayjournal
1
150
MLOpsの「壁」を乗り越える、LINEヤフーの Data Quality as Code
lycorptech_jp
PRO
5
390
JSON攻略法.pdf
miyakemito
8
4.9k
Java EE/Jakarta EEの現状と将来―クラウドネイティブ時代にJava EEは対応できるのか?―
takakiyo
1
130
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
150
生産性向上チームの紹介
cybozuinsideout
PRO
1
860
マルチアカウント環境への発見的統制の導入
ch1aki
1
1.3k
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.7k
ServiceNow Knowledge Learning Rise up
manarobot
0
200
Featured
See All Featured
Building Effective Engineering Teams - LeadDev
addyosmani
28
1.8k
Raft: Consensus for Rubyists
vanstee
132
6.3k
Testing 201, or: Great Expectations
jmmastey
28
6.3k
We Have a Design System, Now What?
morganepeng
43
6.7k
A Modern Web Designer's Workflow
chriscoyier
689
190k
Become a Pro
speakerdeck
PRO
11
4.5k
How STYLIGHT went responsive
nonsquared
92
4.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
31
46k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
125
32k
Robots, Beer and Maslow
schacon
PRO
155
7.9k
Six Lessons from altMBA
skipperchong
21
3k
Product Roadmaps are Hard
iamctodd
44
9.7k
Transcript
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技術を用いての同期・分散を行うシステム LifeStuffについて紹介 この問題を解決するサービス
▪ 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 ee105fffd0f4608dc0bf2 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 = 0x0036 0x0001 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 1 15 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
3 13 0 8 3 1 2 6 時計回りで最初にぶつかったノードが担当 ノード3の担当領域は1, 2, 3 Hash = 6 Successorと呼ぶ 3は0のSuccessor 8は3のSuccessor
▪ 経路表内の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つでもノードが切断されると到達性が確保されない
▪ 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万接続あるとコストが高い
▪ 経路表に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 LifeStuff 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 3 4 必要なときのみ 結合・復元
▪ サービスを使っている不特定多数が共有しては問題 ❏ データを持っているユーザのみ復号化を許可 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技術への応用として、LifeStuffの概要を紹介 ❏ P2P技術の基本は比較的容易で応用しやすい ➡ 分散ハッシュテーブルやSelf-Encryptionはオープンソース 32 まとめ
(GitHub) システム開発や研究を行う上で役に立てていただければ。