More Related Content
Similar to 分散システム第7章（後半） (20)
More from Kenta Hattori (20)
分散システム第7章（後半）
- 3. レプリカサーバ配置
問題：
N個の可能な位置の中から最善のＫ個の位置（Ｋ＜Ｎ）をどう
やって見つけ出すか？
この問題は計算的に非常に複雑なので、発見的手法（heuristics）
によってのみ解かれうる
[Qiu et al., 2001]の手法
配置の候補となる位置とクライアント間との平均距離が最小に
なるように1つのサーバの位置を選択する．
（k個のサーバが配置されているとすると，N-k個の位置の候補
の中から選択する）
[Radoslavov et al., 2001]の手法
大きさでＫ番目までの自律システム（AS: autonomous
system）の中から最大数のリンクを持つルータ上にサーバを
配置する
2013/7/19分散システム本読書会3
- 4. [Szymaniak et al., 2006]の手法
レイテンシを距離とみなしたd-次元幾何空間上に
ノードを位置づける．
最大Ｋ個のクラスタを見つけ，それぞれのクラスタ
の中から１つのレプリカサーバを選ぶ．
計算量はO (N ×max(logN, K ))
64000台の中から20台を選ぶ場合、前案の50000倍の高速
化
2013/7/19分散システム本読書会4
- 8. サーバ起動レプリカ
2013/7/19分散システム本読書会8
アルゴリズム
1. 各サーバは各ファイルのアクセス回数とアクセス元を記
録
ただし、クライアントC1,C2に近いサーバが共にPであったな
らば、サーバQはC1,C2からのアクセスをPからのアクセスとし
てカウント
cntQ(P,F): QのファイルFへのPからのアクセス回数
2. cntQ(P,F)がレプリケーション閾値rep(P,F)を超えると
サーバPにレプリカを作成
3. サーバQでのファイルFへの総アクセス回数
ΣS(cntQ(S,F))がdel(Q,F)を下回り、かつファイルFが最
後のレプリカでないならば、そのレプリカFを削除
4. cntQ(P,F)がQでのFの総アクセス回数の半分を超えると、
ファイルFをQからPへ移動
ただしcntQ(Q,F) >rep(Q,F)ならば複製
- 11. 状態 vs 操作
2013/7/19分散システム本読書会11
実際に何を伝播させるか？
更新があったことの通知のみを伝播
無効化プロトコル（invalidation protocol）
更新があったことのみを通知し、今のレプリカの内容を無効化(invalidate)
伝播 ネットワーク帯域が小さいときに有効
読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播
更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効
更新操作を伝播
アクティブレプリケーション（active replication）
更新されたデータではなく、更新操作内容を転送---各サーバは同じ更新操
作を実行してデータを更新
ネットワーク帯域は小さくてもよい
一般に各サーバに高い計算パワーが要求される
- 12. プル vs プッシュプロトコル
2013/7/19分散システム本読書会12
更新をプル(pull)するかプッシュ(push)するか？
プッシュベースアプローチ（サーバベースプロトコ
ル）
更新を行ったサーバが、他のレプリカ（サーバ）に伝播
させる
更新される側は問い合わせを行う必要が無い
主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあ
り得る
複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロト
コル）
サーバ又はクライアントが、他のサーバに更新の送信を
要求
主にクライアントキャッシュの更新で用いられる
更新に比べて読み取りの頻度が小さい場合に効果的
- 13. プル vs プッシュプロトコル
2013/7/19分散システム本読書会13
プッシュベースとプルベースプロトコルの比較
簡単のため、複数クライアント、単一サーバシステムで
考える
プッシュベースの場合、全てのクライアントキャッシュ
の状態をサーバで管理する必要（スケーラビリティ問
題）
プルベースの場合、更新の有無をサーバに問い合わせ
（ポーリング）、その後、更新を取得する必要
⇒クライアントの応答時間はプッシュベースの方が良
い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよ
びキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取
得）
ポーリングおよび更
新
クライアントでの応答時
間
即時（または更新の取得時
間）
更新取得時間
- 15. リースの失効時間の動的適応
[Duvvuri et.al. 2000]
2013/7/19分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適
応
３つのリース基準
エイジベースリース(age-based leases)
仮定：長期間変更されないデータの生存期間は長い
そのようなデータには長いリース期間を与える
更新頻度ベースリース(renewal-frequency based leases)
頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）
クライアントに長いリース期間を与える
状態空間オーバヘッドベースリース(state-space overhead
based leases)
サーバは自己が過負荷になるとクライアントへ渡すリース期間を
短くする
⇒同時に管理すべきクライアント数が減少
⇒サーバの持つべき状態空間を小さく出来る
⇒サーバ負荷軽減
- 16. ユニキャスト vs マルチキャスト
2013/7/19分散システム本読書会16
プッシュ/プルプロトコルに関連した設計課題
ユニキャストとマルチキャストのどちらを用いる
か？
N個のサーバを更新する場合
ユニキャストならばN個のメッセージが必要
マルチキャストならば1個でよい
多くの場合マルチキャストを用いる方が良い
特にプッシュベースアプローチの場合に有効
プルベースアプローチの場合、更新要求を出す相手は多
くの場合、単一のクライアント又はサーバ
⇒この場合はユニキャストの方がよい
- 18. 連続的一貫性
基本操作
データ項目xについて考える
xに対する書き込み操作Wの後の数値的変更をweight(W)
で表すものとする
仮定：∀W:weight(W) > 0.
書き込みWは最初にN個のレプリカサーバのうち一つに
転送される．そのサーバを origin(W) と表す
TW[i,j] は，サーバSjを起源とし，サーバSiによって実行
された書き込みとする：
TW[i,j] =Σ{weight(W) | origin(W) = Sj & W ∈ log(Si )}
v(t) = vinit +ΣN
k=1TW[k,k]
vi=vinit + ΣN
k=1TW[i,k]
2013/7/19分散システム本読書会18
- 19. プライマリベースプロトコル
問題
全てのサーバSiについて v(t) - vi ≦ δi を保証したい．
アプローチ
サーバ Sk は，SiがTW[i,j]の値として持っていると信じて
いる.ビュー TWk[i,j] を維持している．
この情報は，更新が伝播したときにゴシップされうる
注意
0 ≦ TWk[i,j] ≦ TW[i,j] ≦ TW[j,j]
解法
Sk はTWk [i;k]がTW[k;k]からかい離しそうなとき， 特に，
TW[k;k] - TWk [i;k] > δi/(N – 1)，そのログから書き込
み操作をSiに送る．
2013/7/19分散システム本読書会19
- 23. レプリカ書き込みプロトコル
write操作を複数のレプリカに対して実行
分類：
アクティブレプリケーション（active replication）
全てのレプリカに対してwrite操作を実行(更新操作の伝播)
定足数ベースプロトコル（quorum-based protocols）
幾つかのレプリカに対してのみwrite操作を実行
多数決投票(majority voting)メカニズムによって一貫性を保持
2013/7/19分散システム本読書会23
- 28. キャッシュコヒーレンスプロトコル
2013/7/19分散システム本読書会28
コヒーレンス強制戦略（coherence enforcement strategy）の違いによる分
類
キャッシュとサーバとの一貫性を保つ手法
単純な解決法：共有データはキャッシュに置かず、サーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証
性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合：
データが更新されると、サーバが全てのキャッシュに対して無効化(invalidate)メッセージ
を送信するアプローチ
データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合：
リードオンリーキャッシュの場合
更新はサーバでのみ行われ、その更新内容をいずれキャッシュに反映
多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合：
リードライトキャッシュの場合：
ライトスルーキャッシュ（write-through cache）: キャッシュ内容を更新すると同時に、サー
バでも更新操作を実行
クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類
似
（順序）一貫性保証のため、クライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（write-back cache）: キャッシュ内容のみを更新し、後でまとめて
サーバに伝播
更新の伝播を遅延することにより、サーバに通知する前に複数の書き込みが起こることを許容
- 30. クライアント中心一貫性の単純な実装
2013/7/19分散システム本読書会30
モノトニック読み取り一貫性の実装
クライアントがread操作を行うとき，read setをサーバに送信
し，サーバは関連するwrite操作がすべて実行済みかをチェック
もし実行していないものがあれば，他の複製サーバと通信して
必要なwrite操作を適切な順序で実行し，ローカルコピーを更新
write操作の順序一貫性は適切な手法（タイムスタンプなど）で保
障
モノトニック書き込み一貫性も同様
write操作を行うときにwrite setを送信
書き込み後読み取り一貫性の実装
クライアントがread操作を行うとき，write setをサーバに送信
サーバはwrite setに含まれていてまだ実行されていないwriteを
実行し，ローカルコピーを更新
読み取り後書き込み一貫性も同様
write操作を行うときにread setを送信
