分散システム第7章（後半）

第7章「一貫性と複製」（後半）
分散システム本読書会資料
2013年7月19日（金）服部健太

レプリカ管理
 どこに，いつ，だれによってレプリカが配置される
か
 配置問題：
 レプリカサーバの配置問題
 コンテンツの配置問題
 レプリカ間の一貫性を確保するにはどのメカニズム
を使用すべきか
 コンテンツ配信：
 複製されたコンテンツを管理するための基本的メカニズ
ム
2013/7/19分散システム本読書会2

レプリカサーバ配置
 問題：
 N個の可能な位置の中から最善のＫ個の位置（Ｋ＜Ｎ）をどう
やって見つけ出すか？
 この問題は計算的に非常に複雑なので、発見的手法（heuristics）
によってのみ解かれうる
 [Qiu et al., 2001]の手法
 配置の候補となる位置とクライアント間との平均距離が最小に
なるように1つのサーバの位置を選択する．
 （k個のサーバが配置されているとすると，N-k個の位置の候補
の中から選択する）
 [Radoslavov et al., 2001]の手法
 大きさでＫ番目までの自律システム（AS: autonomous
system）の中から最大数のリンクを持つルータ上にサーバを
配置する

[Szymaniak et al., 2006]の手法
 レイテンシを距離とみなしたd-次元幾何空間上に
ノードを位置づける．
 最大Ｋ個のクラスタを見つけ，それぞれのクラスタ
の中から１つのレプリカサーバを選ぶ．
 計算量はO (N ×max(logN, K ))
 64000台の中から20台を選ぶ場合、前案の50000倍の高速
化

コンテンツの複製と配置
 永久レプリカ
 オリジナルのレプリカ．手動で（静的に）複製
 例：ミラーリング（ミラーサイト），ルートDNSサーバのデータ
 サーバ起動レプリカ
 サーバによる永久レプリカのキャッシュ
 例：DNSキャッシュサーバのデータ
 クライアント起動レプリカ
 クライアントによる上位レプリカのキャッシュ
 例：Webブラウザによるキャッシュ

永久レプリカ
 分散データストアに最初から（静的に）配置されて
いるレプリカ
 レプリカの数は少ない
 例）
 webサイトのミラーリング
 あるwebサイトのコンテンツを幾つかのサーバ(ミラーサイト)
に複製
 クライアントは幾つかのミラーサイトから１つを選択
 共有なしアーキテクチャ（shared-nothing architecture）
で構成された分散データベース
 複数のサーバ（クラスタ）上に分散されたデータベースで、各
プロセッサがディスクやメモリを共有しないもの

サーバ起動レプリカ
 課題：いつ、どこにレプリカを生成/削除するか？
 webホスティングサービスにおけるアプローチ
 更新頻度は読まれる頻度より小さいと仮定
 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
 そのファイルに大量のアクセスを行うクライアントに近いサーバに
移動またはコピー（性能向上のため）

サーバ起動レプリカ
 アルゴリズム
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)ならば複製

クライアント起動レプリカ
 クライアントが生成する複製（キャッシュ）
 リクエストしたデータを一時的にローカルストレージに
蓄積
 キャッシュの管理：クライアントの責任
 一般に、一貫性の保証にデータストア（サーバ）は関与
しない
 目的：データへのアクセス時間向上
 キャッシュ：一般に有効期限あり
 元ファイルと一貫性が無くなったデータを捨てるため
 ディスクの空きを増やすため

コンテンツ配信
 レプリカ管理は，関連するレプリカサーバへの（更
新された）コンテンツ配信，すなわちコンテンツの
伝播も扱う
 様々な考慮すべきトレードオフがある．

状態 vs 操作
 実際に何を伝播させるか？
 更新があったことの通知のみを伝播
 無効化プロトコル（invalidation protocol）
 更新があったことのみを通知し、今のレプリカの内容を無効化(invalidate)
 伝播 􀃆 ネットワーク帯域が小さいときに有効
 読み取りに比べて更新が頻繁な場合に有効
 データの内容を伝播
 更新されたデータ内容を他のサーバに転送
 更新に比べて読み取りが頻繁な場合に有効
 更新操作を伝播
 アクティブレプリケーション（active replication）
 更新されたデータではなく、更新操作内容を転送---各サーバは同じ更新操
作を実行してデータを更新
 ネットワーク帯域は小さくてもよい
 一般に各サーバに高い計算パワーが要求される

プル vs プッシュプロトコル
 更新をプル(pull)するかプッシュ(push)するか？
 プッシュベースアプローチ（サーバベースプロトコ
ル）
 更新を行ったサーバが、他のレプリカ（サーバ）に伝播
させる
 更新される側は問い合わせを行う必要が無い
 主に永久レプリカとサーバ起動レプリカの間で用いられる
 サーバからクライアントキャッシュに更新をプッシュすることもあ
り得る
 複製間で高い一貫性が要求される場合に有効
 プルベースアプローチ（クライアントベースプロト
コル）
 サーバ又はクライアントが、他のサーバに更新の送信を
要求
 主にクライアントキャッシュの更新で用いられる
 更新に比べて読み取りの頻度が小さい場合に効果的

プル vs プッシュプロトコル
 プッシュベースとプルベースプロトコルの比較
 簡単のため、複数クライアント、単一サーバシステムで
考える
 プッシュベースの場合、全てのクライアントキャッシュ
の状態をサーバで管理する必要（スケーラビリティ問
題）
 プルベースの場合、更新の有無をサーバに問い合わせ
（ポーリング）、その後、更新を取得する必要
⇒クライアントの応答時間はプッシュベースの方が良
い
事項プッシュベースプルベース
サーバでの状態クライアントレプリカおよ
びキャッシュのリスト
なし
送られたメッセージ更新（そして後に更新の取
得）
ポーリングおよび更
新
クライアントでの応答時
間
即時（または更新の取得時
間）
更新取得時間

両者の混合アプローチ
 リースに基づく更新伝播[Gray and Cheriton 1989]
 プッシュとプルの混合アプローチ
 リース(lease): 特定時間以内は更新をプッシュし続
けるというサーバによる約束
 サーバは更新を管理すべきクライアント数を一定数に制
限可能⇒スケーラビリティ問題を解決
 リースが失効するとクライアントは更新をプルするか、
リースを再取得する必要

リースの失効時間の動的適応
[Duvvuri et.al. 2000]
 異なるリース基準に基づいてリース失効時間を動的に適
応
 ３つのリース基準
 エイジベースリース(age-based leases)
 仮定：長期間変更されないデータの生存期間は長い
 そのようなデータには長いリース期間を与える
 更新頻度ベースリース(renewal-frequency based leases)
 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）
クライアントに長いリース期間を与える
 状態空間オーバヘッドベースリース(state-space overhead
based leases)
 サーバは自己が過負荷になるとクライアントへ渡すリース期間を
短くする
⇒同時に管理すべきクライアント数が減少
⇒サーバの持つべき状態空間を小さく出来る
⇒サーバ負荷軽減

ユニキャスト vs マルチキャスト
 プッシュ/プルプロトコルに関連した設計課題
 ユニキャストとマルチキャストのどちらを用いる
か？
 N個のサーバを更新する場合
 ユニキャストならばN個のメッセージが必要
 マルチキャストならば1個でよい
 多くの場合マルチキャストを用いる方が良い
 特にプッシュベースアプローチの場合に有効
 プルベースアプローチの場合、更新要求を出す相手は多
くの場合、単一のクライアント又はサーバ
⇒この場合はユニキャストの方がよい

一貫性プロトコル
 一貫性プロトコルとはある特定の一貫性モデルの実
装についての記述である
 データ中心モデル
 連続的一貫性
 プライマリベースプロトコル
 レプリカ書き込みプロトコル
 キャッシュコヒーレンスプロトコル
 クライアント中心モデル

連続的一貫性
 基本操作
 データ項目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]

プライマリベースプロトコル
 問題
 全てのサーバ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に送る．

プライマリベースプロトコル
 任意のデータ要素xに対して、プライマリ(サーバ)を
割り当て
 プライマリはxに対するwrite操作に関して責任を持つ
 分類：
 プライマリがある特定のサーバに固定
⇒遠隔書き込みプロトコル(Remote-Write Protocol)
 write操作の実行を依頼したプロセスにプライマリを移動
して、そこでwrite操作を実行
⇒ローカル書き込みプロトコル(Local-Write Protocol)

遠隔書き込みプロトコル
 writeはある1つのサーバで責任を持つ
 readは近くのローカルコピーから行う
 プライマリバックアッププロトコル(primary-backup
protocols)[Budhiraja et al. 1993]

ローカル書き込みプロトコル
 書き込みクライアントの場所へのプライマリコピー
の移動を許すローカル書き込みプロトコル
 write操作実行時のみ、プライマリをローカルコピーに移
動
 更新結果は全てのローカルコピーに反映(バックアップ)
 read操作はローカルコピーに対して実行

レプリカ書き込みプロトコル
 write操作を複数のレプリカに対して実行
 分類：
 アクティブレプリケーション（active replication）
 全てのレプリカに対してwrite操作を実行(更新操作の伝播)
 定足数ベースプロトコル（quorum-based protocols）
 幾つかのレプリカに対してのみwrite操作を実行
 多数決投票(majority voting)メカニズムによって一貫性を保持

アクティブレプリケーション
 各レプリカをそれぞれ１つのプロセスに対応付け
 プロセスは対応付けられたレプリカに対してwrite操作を
実行
 write操作は他の全てのレプリカに伝播される
 アクティブレプリケーションの問題点：
 全てのレプリカで同じ順番でwrite操作を実行する必要がある
(一貫性保持のため)
 解決法：
 全順序マルチキャストの利用
 Lamportのタイムスタンプを用いて実装可能
 ただし、スケーラブルではない
 中央コーディネータ(シーケンサ(sequencer))の利用
 ある1つのコーディネータが各write操作にシーケンス番号を振り、全順序を保
証
 依然としてスケーラブルでない
 シンメトリックマルチキャスト(symmetric multicast)[Rodrigues
et.al. 1996]の利用⇒詳細は文献参照のこと

定足数ベースプロトコル
 投票ベースプロトコルの一般化
 N個のレプリカからデータを読み込むとき
 クライアントは読み取りコーラム(read quorum)と呼ばれ
るサーバの部分集合に対してリクエスト
 任意のNR個のサーバ
 書き込むとき
 書き込みコーラム(write quorum)と呼ばれるサーバの部分
集合に対してリクエスト
 任意のNW個のサーバ
 ただし、
 NR +NW >N （read-write競合を避けるため）
 NW >N/2 （write-write競合を避けるため）

定足数ベースプロトコル
 読み取り/書き込みコーラムの選択例
 特に(c)はRead-One, Write-All(ROWA)と呼ばれる例
 コーラムベースプロトコルの詳細は[Jalote1994]参照

キャッシュコヒーレンスプロトコル
 キャッシュ(=クライアント起動レプリカ)の内容が
サーバ側のデータと一貫性があることを保証するプ
ロトコル
 コヒーレンス検出戦略(coherence detection strategy)
の違いによる分類（キャッシュの不整合がいつ検出
されるか？）
 静的な解決策
 プログラム実行前にコンパイラが静的に分析
 動的な解決策
 実行時にキャッシュの不整合を検出

キャッシュコヒーレンスプロトコル
 コヒーレンス強制戦略（coherence enforcement strategy）の違いによる分
類
 キャッシュとサーバとの一貫性を保つ手法
 単純な解決法：共有データはキャッシュに置かず、サーバだけに置く
 一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証
 性能はキャッシュを用いる場合より悪い
 共有データをキャッシュする場合：
 データが更新されると、サーバが全てのキャッシュに対して無効化(invalidate)メッセージ
を送信するアプローチ
 データの更新を単純に全てのキャッシュに伝播させるアプローチ
 キャッシュされたデータを更新する場合：
 リードオンリーキャッシュの場合
 更新はサーバでのみ行われ、その更新内容をいずれキャッシュに反映
 多くの場合プルベースアプローチを利用
 キャッシュされたデータを更新する場合：
 リードライトキャッシュの場合：
 ライトスルーキャッシュ（write-through cache）: キャッシュ内容を更新すると同時に、サー
バでも更新操作を実行
 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類
似
 （順序）一貫性保証のため、クライアントに排他的な書き込み権限が与えられる必要
 ライトバックキャッシュ（write-back cache）: キャッシュ内容のみを更新し、後でまとめて
サーバに伝播
 更新の伝播を遅延することにより、サーバに通知する前に複数の書き込みが起こることを許容

クライアント中心一貫性の単純な実装
 各write操作に大域的なＩＤを付与
 そのwrite操作最初に受け付けたサーバが行う
 各クライアント毎に以下の２つの集合を管理
 read set: クライアントが行った一連のread操作に関連す
るwrite操作のIDの集合
 「関連するwrite操作」＝一連のread値を再現するための最小限
のwrite操作
 write set: クライアントが行った一連のwrite操作のIDの集
合

クライアント中心一貫性の単純な実装
 モノトニック読み取り一貫性の実装
 クライアントがread操作を行うとき，read setをサーバに送信
し，サーバは関連するwrite操作がすべて実行済みかをチェック
 もし実行していないものがあれば，他の複製サーバと通信して
必要なwrite操作を適切な順序で実行し，ローカルコピーを更新
 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保
障
 モノトニック書き込み一貫性も同様
 write操作を行うときにwrite setを送信
 書き込み後読み取り一貫性の実装
 クライアントがread操作を行うとき，write setをサーバに送信
 サーバはwrite setに含まれていてまだ実行されていないwriteを
実行し，ローカルコピーを更新
 読み取り後書き込み一貫性も同様
 write操作を行うときにread setを送信

分散システム第7章（後半）

More Related Content

What's hot

Similar to 分散システム第7章（後半）

More from Kenta Hattori

Recently uploaded

分散システム第7章（後半）