Post on 22-Jun-2015
description
KiZUNA: P2P ネットワークを用いたマイクロブログサービスの実現
大阪市立大学 創造都市研究科播磨 裕太 安倍 広多石橋 勇人 松浦 敏雄
2
研究背景マイクロブログサービスの普及
◦Twitter, Weibo, Yammer, etc…
Twitter◦月間アクティブユーザ : 2 億 4 千万人超◦日間ツイート数 : 5 億ツイート
既存のマイクロブログサービスはサーバクライアントモデルで実現
3
研究背景 | 問題点 (1)
サーバクライアントモデル
．．．
アクセスがサーバに集中
サーバがダウンするとサービスが停止する（単一故障点の存在）
バルス！ バルス！ バルス！ バルス！
4
研究背景 | 問題点 (2)
高い運用コスト◦大量のサーバなどが必要
Twitter Inc.◦2013 年第 4 四半期（ 10 月 -12 月） : 517 億円の赤
字
5
研究目的Pure P2P でマイクロブログサービスを実現
◦全ユーザの端末で Twitter のサブセットを実現◦サーバ不要◦名称 : KiZUNA
メリット◦耐故障性（単一故障点の排除）◦高いスケーラビリティ◦低い運用コスト
KiZUNA で実現する Twitter の機能
7
Twitter | ツイート
140文字以内の短文（ツイート）を投稿できる
8
Twitter | フォロー（購読）
フォローしているユーザらのツイート
9
Twitter | ハッシュタグ
”#”から始まる文字列
10
Twitter | ハッシュタグ
「#IPSJ」に言及しているツイート
11
Twitter | 全文検索
「ソチ」を含むツイート
12
Twitter | 検索ストリーム
「ソチ」を含むツイート
Push型
13
Twitter | ログイン
ユーザの認証
14
Twitter | メッセージアーカイブ機能
ユーザの過去のメッセージを取得
本研究の意義
16
関連研究P2P ベースのマイクロブログサービス
Cuckoo
Megaphone
西尾らの手法
戸部らの手法
KiZUNA
P2Pの種類 Hybrid Pure Hybrid Pure Pure
購読者に配送する機能
○ ○ ○ ○ ○
内容に応じた配送 × × × × ○
全文検索 × × × × ○
メッセージのアーカイブ管理
○ ○ 不明 不明 ○
本研究ツイートをフォロワーに配送する機能に該当
ハッシュタグや検索ストリームに該当
KiZUNAだけがサポート！
17
本研究の意義高機能なマイクロブログサービスを
Pure P2P で実現する方法を明らかにする◦マイクロブログサービス = Pub/Sub パラダイム
によってモデル化 購読者にメッセージを配送
→トピックベース Pub/Sub 内容に応じたメッセージ配送
→コンテンツベース Pub/Sub アーカイブ機能
→アーカイブ機能付き Pub/Sub
同時に実現
KiZUNA の設計について
19
KiZUNA | 構造4 つの Skip Graph ベースの
構造化 P2P ネットワークから構成
すべてを Skip Graphベースで実現することで実装コストを下げる
後で説明
DHT用
検索ストリーム用
全文検索用
メッセージ配送用
20
KiZUNA | ユーザの識別 (1)
Twitterではスクリーンネーム（ユーザが任意に設定可能で重複しない）
KiZUNAでも使うが…重複しないことを保証したいがサーバがないため難しい
21
KiZUNA | ユーザの識別 (2)
重複しない IDが必要
乱数で生成した長いビット列をIDとする（これを UIDと呼ぶ）
UIDとスクリーンネームを併用
UIDの例 : 582cd103-ee87-4b14-b57f-848a248de58c
メッセージ配送の実現法
23
メッセージ配送 | 概要 (1)
A B C X
Aのフォロワーバルス！
フォロワー全員に配送しなければならない
一人一人に送るのは効率が悪い
．．．
Twitterで最もフォローされているユーザのフォロワー数は 5000万人
超
24
メッセージ配送 | 概要 (2)
一人一人に送るのは効率が悪い
まとめて送信する
P2Pネットワーク (Skip Graph)上でALM(Application Level Multicast)により
配送
25
メッセージ配送 | Skip Graph の構造
25
10000
20100
30110
40010
50101
60001
70111
80011
10
20
30 4
0
50 6
0
70 8
0
10
20
30
40
50 6
0
70
80
Level 0
Level 2
Level 1
Level 3
10
20 3
0
40 5
0
60 7
0
80
同一のコンピュータ（ノード）キー（昇順に並ぶ）
26
メッセージ配送 | Skip Graph の ALM
10000
20100
30110
40010
50101
60001
70111
80011
10
20
30 4
0
50 6
0
70 8
0
10
20
30
40
50 6
0
70
80
Level 0
Level 2
Level 1
Level 3
10
20 3
0
40 5
0
60 7
0
80[50, 80]
へ送信
①
②
② ③
ホップ数 : )(lognO
: ネットワーク内の総ノード数n
27
メッセージ配送 | 詳細 (1)
購読者をある範囲に集めておけばALMでメッセージを配送できる
ユーザ Xがユーザ Yを購読する場合Xは Yの UIDをキーとして Skip Graphに挿
入する
28
メッセージ配送 | 具体例Aのフォロワー
B
Cのフォロワー
UID: 10
UID: 20
UID: 30
10
20
30
フォロー関係を表した Skip Graph(Level 0部分）
A
B C
C
キーを挿入しているユーザ
A自分自身のキーは初めから挿入
Bのフォロワー
29
メッセージ配送 | 具体例Aのフォロワー
B
B
Cのフォロワー
UID: 10
UID: 20
UID: 30
10
10
20
30
フォロー関係を表した Skip Graph(Level 0部分）
A B
B C
C
Bが Aの UID(10)を挿入
Aを購読A
Bのフォロワー
30
メッセージ配送 | 具体例Aのフォロワー
B
B
Cのフォロワー
AUID: 10
UID: 20
UID: 30
10
10
20
30
30
フォロー関係を表した Skip Graph(Level 0部分）
A AB
B C
C
Aが Cの UID(30)を挿入
A
BのフォロワーCを購読
31
メッセージ配送 | 具体例Aのフォロワー
B C
B
A C
Cのフォロワー
A
C
UID: 10
UID: 20
UID: 30
10
10
10
20
20
20
30
30
フォロー関係を表した Skip Graph(Level 0部分）
A A AB
B C
C C
Aのフォロワー Bのフォロワー Cのフォロワー
A
Bのフォロワー
32
メッセージ配送 | 具体例Aのフォロワー
B C
Bのフォロワー
B
A C
Cのフォロワー
A
C
UID: 10
UID: 20
UID: 30
10
10
10
20
20
20
30
30
フォロー関係を表した Skip Graph(Level 0部分）
A A AB
B C
C C
A
バルス！
Bはこの範囲に ALMする
33
メッセージ配送 | まとめ購読
◦購読したいユーザの UID をキーとして Skip Graph に挿入
配送◦自身の UID をキーの範囲として ALM
フォロワーが多くても効率が良い◦ホップ数は対数オーダー
配送時に購読していないノードを経由しない
※ ハッシュタグに関する配送については割愛
メッセージアーカイブの実現法
35
メッセージアーカイブ | 背景(1)過去のメッセージをいつでも取得したい
発信者自身が過去のメッセージ
を保持
これだけでは発信者自身がオフラインの場合は取得できない
36
メッセージアーカイブ | 背景 (2)
発信者自身がオフラインの場合は取得できない
他のノード上にメッセージの複製を持つ必要がある
DHTに複製を配置する ?
コストがかかる
37
メッセージアーカイブ | 提案方式 (1)
複製のためにコストをかけたくない
（オンラインの）フォロワーにはメッセージが配送されている
配送されたメッセージを複製として保持しておけば良い
全員オフラインの場合に問題
38
メッセージアーカイブ | 提案方式 (2)
発信者もそのフォロワーもすべてオフラインだった場合はどうする ?
オンラインのフォロワー数を一定以上に保つ
オンラインのフォロワー数が一定以下になったら誰かに強制的に購読させる
39
メッセージアーカイブ | 具体例Aのフォロワー
B C
Bのフォロワー
B
A C
Cのフォロワー
A
C
UID: 10
UID: 20
UID: 30
10
10
10
20
20
20
30
30
フォロー関係を表した Skip Graph(Level 0部分）
A A AB
B C
C C
Cのフォロワー
ACのオンラインのフォロワーが少ない
X
30
無作為にオンラインのユーザを選ぶ
Cを強制的に購読させる
40
メッセージアーカイブ | まとめフォロワーがメッセージの複製を保持する
◦余計なコストがかからない
常に一定数以上のフォロワー数を保つ◦少なくなると強制的に購読させる◦フォロワーの右端のノードが
フォロワー数の判定と強制購読を担当
全文検索と検索ストリームの実現法
42
全文検索 | 概要過去のメッセージを検索
KiZUNAではサーバがないためメッセージをユーザが分散して保持している
分散しているメッセージを効率よく探す必要がある
BF Skip Graphを用いる
43
全文検索 | BF Skip Graph の概要
P2P ネットワーク上で全文検索を行うしくみ◦各ノードは保持しているドキュメントを
Bloom Filter に登録◦各ノードの Bloom Filter を階層的に集約IOT研究会なう
IOT形態素解析
研究 会 なう登録
Bloom Filter
44
全文検索 | BF Skip Graph の構造
44
10
20
30
40
50
60
70
80
10
20
30 4
0
50 6
0
70 8
0
10
20
30
40
50 6
0
70
80
Level 2
Level 1
Level 3
10
20 3
0
40 5
0
60 7
0
80
Level 0
45
全文検索 | BF Skip Graph の構造
45
10
20
30
40
50
60
70
80
10
20
30 4
0
50 6
0
70 8
0
10
20
30
40
50 6
0
70
80
Level 2
Level 1
Level 3
10
20 3
0
40 5
0
60 7
0
80
Level 0
バルス バルス バルス
「バルス」を検索
46
全文検索 | KiZUNA では…全文検索用の新たな Skip Graph を構成する
発信者自身がオフラインでも検索したい◦複製を保持しているノードも参加◦フォロワーが一部だけが参加（で十分）
47
検索ストリーム | 概要Push 型検索
◦検索キーワードを登録しておく
検索ストリーム専用の BF Skip Graph を構成◦検索キーワードを Bloom Filter に登録する◦メッセージ配送時にマッチするかを調べ配送す
る
48
検索ストリーム | 具体例
48
10
20
30
40
50
60
70
80
10
20
30 4
0
50 6
0
70 8
0
10
20
30
40
50 6
0
70
80
Level 2
Level 1
Level 3
10
20 3
0
40 5
0
60 7
0
80
Level 0
IOT なう 研究
「 IOT研究会なう」をツイート
IA SITE 加賀IPSJ
発信者認証について
50
発信者認証 | 概要 (1)
サーバなしでユーザを認証する必要がある
メッセージにデジタル署名を付与する
ユーザの公開鍵はDHTに保存
改ざん・詐称をチェックできる
51
発信者認証 | 概要 (2)
通常の DHTは誰でもデータを書き換え可能
公開鍵が改ざんされる
DHTにデジタル署名を付与署名が付いているデータの書き換えは署名付きのリクエストが必要
メッセージ配送のまとめ
53
メッセージ配送のまとめ
DHT用
検索ストリーム用
全文検索用
メッセージ配送用
A
IOT研究会なう
#IPSJ
Aのフォロワーへ配送
ハッシュタグを抽出し配送
形態素解析しマッチするBFを持つユーザへ配送
Aのメッセージを受信した
ユーザが Aの公開鍵で検証
実装について
55
KiZUNA | 実装P2P 基盤ソフトウェア PIAX 上に実装中
◦実装済み Skip Graph BF Skip Graph メッセージ配送機能 発信者認証機能
56
まとめPure P2P でマイクロブログサービスを実現す
る方法を示した◦メッセージ配送には Skip Graph 上の ALM を使用◦アーカイブ機能（複製機能）◦全文検索・検索ストリームには BF Skip Graph を使
用これにより…
◦耐故障性（単一故障点の排除）◦高いスケーラビリティ◦低い運用コスト
今後評価予定