Embed Size (px)
Citation preview
第 7 章「一貫性と複製」（後半）
分散システム本読書会資料2013 年 7 月 19 日（金） 服部 健太
レプリカ管理 どこにいつだれによってレプリカが配置される
か 配置問題
レプリカサーバの配置問題 コンテンツの配置問題
レプリカ間の一貫性を確保するにはどのメカニズムを使用すべきか
コンテンツ配信 複製されたコンテンツを管理するための基本的メカニズ
ム
2013719分散システム本読書会2
レプリカサーバ配置 問題
N 個の可能な位置の中から最善のＫ個の位置（Ｋ＜Ｎ）をどうやって見つけ出すか この問題は計算的に非常に複雑なので発見的手法（ heuristics ）
によってのみ解かれうる [Qiu et al 2001] の手法
配置の候補となる位置とクライアント間との平均距離が最小になるように 1 つのサーバの位置を選択する
（ k 個のサーバが配置されているとすると N-k 個の位置の候補の中から選択する）
[Radoslavov et al 2001] の手法 大きさでＫ番目までの自律システム（ AS autonomous
system ）の中から最大数のリンクを持つルータ上にサーバを配置する
2013719分散システム本読書会3
[Szymaniak et al 2006] の手法 レイテンシを距離とみなした d- 次元幾何空間上に
ノードを位置づける 最大Ｋ個のクラスタを見つけそれぞれのクラスタ
の中から１つのレプリカサーバを選ぶ 計算量は O (N timesmax(logN K ))
64000 台の中から 20 台を選ぶ場合前案の 50000 倍の高速化
2013719分散システム本読書会4
コンテンツの複製と配置 永久レプリカ
オリジナルのレプリカ手動で（静的に）複製 例ミラーリング（ミラーサイト）ルート DNS サーバのデータ
サーバ起動レプリカ サーバによる永久レプリカのキャッシュ 例 DNS キャッシュサーバのデータ
クライアント起動レプリカ クライアントによる上位レプリカのキャッシュ 例 Web ブラウザによるキャッシュ
2013719分散システム本読書会5
永久レプリカ
2013719分散システム本読書会6
分散データストアに最初から（静的に）配置されているレプリカ
レプリカの数は少ない 例）
web サイトのミラーリング ある web サイトのコンテンツを幾つかのサーバ ( ミラーサイ
ト ) に複製 クライアントは幾つかのミラーサイトから１つを選択
共有なしアーキテクチャ（ shared-nothing architecture ）で構成された分散データベース 複数のサーバ（クラスタ）上に分散されたデータベースで各
プロセッサがディスクやメモリを共有しないもの
サーバ起動レプリカ
2013719分散システム本読書会7
課題いつどこにレプリカを生成 削除するか web ホスティングサービスにおけるアプローチ
更新頻度は読まれる頻度より小さいと仮定 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
レプリカ管理 どこにいつだれによってレプリカが配置される
か 配置問題
レプリカサーバの配置問題 コンテンツの配置問題
レプリカ間の一貫性を確保するにはどのメカニズムを使用すべきか
コンテンツ配信 複製されたコンテンツを管理するための基本的メカニズ
ム
2013719分散システム本読書会2
レプリカサーバ配置 問題
N 個の可能な位置の中から最善のＫ個の位置（Ｋ＜Ｎ）をどうやって見つけ出すか この問題は計算的に非常に複雑なので発見的手法（ heuristics ）
によってのみ解かれうる [Qiu et al 2001] の手法
配置の候補となる位置とクライアント間との平均距離が最小になるように 1 つのサーバの位置を選択する
（ k 個のサーバが配置されているとすると N-k 個の位置の候補の中から選択する）
[Radoslavov et al 2001] の手法 大きさでＫ番目までの自律システム（ AS autonomous
system ）の中から最大数のリンクを持つルータ上にサーバを配置する
2013719分散システム本読書会3
[Szymaniak et al 2006] の手法 レイテンシを距離とみなした d- 次元幾何空間上に
ノードを位置づける 最大Ｋ個のクラスタを見つけそれぞれのクラスタ
の中から１つのレプリカサーバを選ぶ 計算量は O (N timesmax(logN K ))
64000 台の中から 20 台を選ぶ場合前案の 50000 倍の高速化
2013719分散システム本読書会4
コンテンツの複製と配置 永久レプリカ
オリジナルのレプリカ手動で（静的に）複製 例ミラーリング（ミラーサイト）ルート DNS サーバのデータ
サーバ起動レプリカ サーバによる永久レプリカのキャッシュ 例 DNS キャッシュサーバのデータ
クライアント起動レプリカ クライアントによる上位レプリカのキャッシュ 例 Web ブラウザによるキャッシュ
2013719分散システム本読書会5
永久レプリカ
2013719分散システム本読書会6
分散データストアに最初から（静的に）配置されているレプリカ
レプリカの数は少ない 例）
web サイトのミラーリング ある web サイトのコンテンツを幾つかのサーバ ( ミラーサイ
ト ) に複製 クライアントは幾つかのミラーサイトから１つを選択
共有なしアーキテクチャ（ shared-nothing architecture ）で構成された分散データベース 複数のサーバ（クラスタ）上に分散されたデータベースで各
プロセッサがディスクやメモリを共有しないもの
サーバ起動レプリカ
2013719分散システム本読書会7
課題いつどこにレプリカを生成 削除するか web ホスティングサービスにおけるアプローチ
更新頻度は読まれる頻度より小さいと仮定 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
レプリカサーバ配置 問題
N 個の可能な位置の中から最善のＫ個の位置（Ｋ＜Ｎ）をどうやって見つけ出すか この問題は計算的に非常に複雑なので発見的手法（ heuristics ）
によってのみ解かれうる [Qiu et al 2001] の手法
配置の候補となる位置とクライアント間との平均距離が最小になるように 1 つのサーバの位置を選択する
（ k 個のサーバが配置されているとすると N-k 個の位置の候補の中から選択する）
[Radoslavov et al 2001] の手法 大きさでＫ番目までの自律システム（ AS autonomous
system ）の中から最大数のリンクを持つルータ上にサーバを配置する
2013719分散システム本読書会3
[Szymaniak et al 2006] の手法 レイテンシを距離とみなした d- 次元幾何空間上に
ノードを位置づける 最大Ｋ個のクラスタを見つけそれぞれのクラスタ
の中から１つのレプリカサーバを選ぶ 計算量は O (N timesmax(logN K ))
64000 台の中から 20 台を選ぶ場合前案の 50000 倍の高速化
2013719分散システム本読書会4
コンテンツの複製と配置 永久レプリカ
オリジナルのレプリカ手動で（静的に）複製 例ミラーリング（ミラーサイト）ルート DNS サーバのデータ
サーバ起動レプリカ サーバによる永久レプリカのキャッシュ 例 DNS キャッシュサーバのデータ
クライアント起動レプリカ クライアントによる上位レプリカのキャッシュ 例 Web ブラウザによるキャッシュ
2013719分散システム本読書会5
永久レプリカ
2013719分散システム本読書会6
分散データストアに最初から（静的に）配置されているレプリカ
レプリカの数は少ない 例）
web サイトのミラーリング ある web サイトのコンテンツを幾つかのサーバ ( ミラーサイ
ト ) に複製 クライアントは幾つかのミラーサイトから１つを選択
共有なしアーキテクチャ（ shared-nothing architecture ）で構成された分散データベース 複数のサーバ（クラスタ）上に分散されたデータベースで各
プロセッサがディスクやメモリを共有しないもの
サーバ起動レプリカ
2013719分散システム本読書会7
課題いつどこにレプリカを生成 削除するか web ホスティングサービスにおけるアプローチ
更新頻度は読まれる頻度より小さいと仮定 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
[Szymaniak et al 2006] の手法 レイテンシを距離とみなした d- 次元幾何空間上に
ノードを位置づける 最大Ｋ個のクラスタを見つけそれぞれのクラスタ
の中から１つのレプリカサーバを選ぶ 計算量は O (N timesmax(logN K ))
64000 台の中から 20 台を選ぶ場合前案の 50000 倍の高速化
2013719分散システム本読書会4
コンテンツの複製と配置 永久レプリカ
オリジナルのレプリカ手動で（静的に）複製 例ミラーリング（ミラーサイト）ルート DNS サーバのデータ
サーバ起動レプリカ サーバによる永久レプリカのキャッシュ 例 DNS キャッシュサーバのデータ
クライアント起動レプリカ クライアントによる上位レプリカのキャッシュ 例 Web ブラウザによるキャッシュ
2013719分散システム本読書会5
永久レプリカ
2013719分散システム本読書会6
分散データストアに最初から（静的に）配置されているレプリカ
レプリカの数は少ない 例）
web サイトのミラーリング ある web サイトのコンテンツを幾つかのサーバ ( ミラーサイ
ト ) に複製 クライアントは幾つかのミラーサイトから１つを選択
共有なしアーキテクチャ（ shared-nothing architecture ）で構成された分散データベース 複数のサーバ（クラスタ）上に分散されたデータベースで各
プロセッサがディスクやメモリを共有しないもの
サーバ起動レプリカ
2013719分散システム本読書会7
課題いつどこにレプリカを生成 削除するか web ホスティングサービスにおけるアプローチ
更新頻度は読まれる頻度より小さいと仮定 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
コンテンツの複製と配置 永久レプリカ
オリジナルのレプリカ手動で（静的に）複製 例ミラーリング（ミラーサイト）ルート DNS サーバのデータ
サーバ起動レプリカ サーバによる永久レプリカのキャッシュ 例 DNS キャッシュサーバのデータ
クライアント起動レプリカ クライアントによる上位レプリカのキャッシュ 例 Web ブラウザによるキャッシュ
2013719分散システム本読書会5
永久レプリカ
2013719分散システム本読書会6
分散データストアに最初から（静的に）配置されているレプリカ
レプリカの数は少ない 例）
web サイトのミラーリング ある web サイトのコンテンツを幾つかのサーバ ( ミラーサイ
ト ) に複製 クライアントは幾つかのミラーサイトから１つを選択
共有なしアーキテクチャ（ shared-nothing architecture ）で構成された分散データベース 複数のサーバ（クラスタ）上に分散されたデータベースで各
プロセッサがディスクやメモリを共有しないもの
サーバ起動レプリカ
2013719分散システム本読書会7
課題いつどこにレプリカを生成 削除するか web ホスティングサービスにおけるアプローチ
更新頻度は読まれる頻度より小さいと仮定 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
永久レプリカ
2013719分散システム本読書会6
分散データストアに最初から（静的に）配置されているレプリカ
レプリカの数は少ない 例）
web サイトのミラーリング ある web サイトのコンテンツを幾つかのサーバ ( ミラーサイ
ト ) に複製 クライアントは幾つかのミラーサイトから１つを選択
共有なしアーキテクチャ（ shared-nothing architecture ）で構成された分散データベース 複数のサーバ（クラスタ）上に分散されたデータベースで各
プロセッサがディスクやメモリを共有しないもの
サーバ起動レプリカ
2013719分散システム本読書会7
課題いつどこにレプリカを生成 削除するか web ホスティングサービスにおけるアプローチ
更新頻度は読まれる頻度より小さいと仮定 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
サーバ起動レプリカ
2013719分散システム本読書会7
課題いつどこにレプリカを生成 削除するか web ホスティングサービスにおけるアプローチ
更新頻度は読まれる頻度より小さいと仮定 個々のファイルのレプリカをそれぞれ異なるサーバに分散配置
そのファイルに大量のアクセスを行うクライアントに近いサーバに移動またはコピー（性能向上のため）
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
サーバ起動レプリカ
2013719分散システム本読書会8
アルゴリズム1 各サーバは各ファイルのアクセス回数とアクセス元を記録
ただしクライアント C1C2 に近いサーバが共に P であったならばサーバ Q は C1C2 からのアクセスを P からのアクセスとしてカウント
cntQ(PF) Q のファイル F への P からのアクセス回数2 cntQ(PF) がレプリケーション閾値 rep(PF) を超えると
サーバ P にレプリカを作成3 サーバ Q でのファイル F への総アクセス回数
ΣS(cntQ(SF)) が del(QF) を下回りかつファイル F が最後のレプリカでないならばそのレプリカ F を削除
4 cntQ(PF) が Q での F の総アクセス回数の半分を超えるとファイル F を Q から P へ移動
ただし cntQ(QF) gtrep(QF) ならば複製
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
クライアント起動レプリカ
2013719分散システム本読書会9
クライアントが生成する複製（キャッシュ） リクエストしたデータを一時的にローカルストレージに
蓄積 キャッシュの管理クライアントの責任
一般に一貫性の保証にデータストア（サーバ）は関与しない
目的データへのアクセス時間向上 キャッシュ一般に有効期限あり
元ファイルと一貫性が無くなったデータを捨てるため ディスクの空きを増やすため
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
コンテンツ配信 レプリカ管理は関連するレプリカサーバへの（更
新された）コンテンツ配信すなわちコンテンツの伝播も扱う
様々な考慮すべきトレードオフがある
2013719分散システム本読書会10
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
状態 vs 操作
2013719分散システム本読書会11
実際に何を伝播させるか
更新があったことの通知のみを伝播 無効化プロトコル（ invalidation protocol ）
更新があったことのみを通知し今のレプリカの内容を無効化 (invalidate) 伝播されるデータ量が小さい1048774ネットワーク帯域が小さいときに有効 読み取りに比べて更新が頻繁な場合に有効
データの内容を伝播 更新されたデータ内容を他のサーバに転送
更新に比べて読み取りが頻繁な場合に有効 更新操作を伝播
アクティブレプリケーション（ active replication ） 更新されたデータではなく更新操作内容を転送 --- 各サーバは同じ更新操作を実
行してデータを更新 ネットワーク帯域は小さくてもよい 一般に各サーバに高い計算パワーが要求される
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
プル vs プッシュプロトコル
2013719分散システム本読書会12
更新をプル (pull) するかプッシュ (push) するか プッシュベースアプローチ（サーバベースプロトコル）
更新を行ったサーバが他のレプリカ（サーバ）に伝播させる 更新される側は問い合わせを行う必要が無い 主に永久レプリカとサーバ起動レプリカの間で用いられる
サーバからクライアントキャッシュに更新をプッシュすることもあり得る 複製間で高い一貫性が要求される場合に有効
プルベースアプローチ（クライアントベースプロトコル） サーバ又はクライアントが他のサーバに更新の送信を要求
主にクライアントキャッシュの更新で用いられる 更新に比べて読み取りの頻度が小さい場合に効果的
キャッシュが共有されていない（一つのクライアントで占有している）場合など
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
プル vs プッシュプロトコル
2013719分散システム本読書会13
プッシュベースとプルベースプロトコルの比較 簡単のため複数クライアント単一サーバシステムで考える プッシュベースの場合全てのクライアントキャッシュの状態
をサーバで管理する必要（スケーラビリティ問題） プルベースの場合更新の有無をサーバに問い合わせ（ポーリ
ング）その後更新を取得する必要rArrクライアントの応答時間はプッシュベースの方が良い
事項 プッシュベース プルベース
サーバでの状態 クライアントレプリカおよびキャッシュのリスト
なし
送られたメッセージ 更新（そして後に更新の取得）
ポーリングおよび更新
クライアントでの応答時間
即時（または更新の取得時間）
更新取得時間
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
両者の混合アプローチ
2013719分散システム本読書会14
リースに基づく更新伝播 [Gray and Cheriton 1989]
プッシュとプルの混合アプローチ リース (lease) 特定時間以内は更新をプッシュし続けるというサーバによる約束 サーバは更新を管理すべきクライアント数を一定数に制
限可能rArrスケーラビリティ問題を解決 リースが失効するとクライアントは更新をプルするか
リースを再取得する必要
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
リースの失効時間の動的適応[Duvvuri etal 2000]
2013719分散システム本読書会15
異なるリース基準に基づいてリース失効時間を動的に適応 ３つのリース基準
エイジベースリース (age-based leases) 仮定長期間変更されないデータの生存期間は長い そのようなデータには長いリース期間を与える
更新頻度ベースリース (renewal-frequency based leases) 頻繁にキャッシュ更新が必要な（＝そのデータをよく使用する）クライ
アントに長いリース期間を与える 状態空間オーバヘッドベースリース (state-space overhead
based leases) サーバは自己が過負荷になるとクライアントへ渡すリース期間を短くす
るrArr同時に管理すべきクライアント数が減少rArrサーバの持つべき状態空間を小さく出来るrArrサーバ負荷軽減
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
ユニキャスト vs マルチキャスト
2013719分散システム本読書会16
プッシュ プルプロトコルに関連した設計課題 ユニキャストとマルチキャストのどちらを用いる
か N 個のサーバを更新する場合
ユニキャストならば N 個のメッセージが必要 マルチキャストならば 1 個でよい
多くの場合マルチキャストを用いる方が良い 特にプッシュベースアプローチの場合に有効 プルベースアプローチの場合更新要求を出す相手は多くの場合単一のクライアント又はサーバ
rArrこの場合はユニキャストの方がよい
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
一貫性プロトコル 一貫性プロトコルとはある特定の一貫性モデルの実装についての記述である データ中心モデル
連続的一貫性 プライマリベースプロトコル レプリカ書き込みプロトコル
キャッシュコヒーレンスプロトコル クライアント中心モデル
2013719分散システム本読書会17
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
連続的一貫性 基本操作
データ項目 x について考える x に対する書き込み操作 W の後の数値的変更を
weight(W) で表すものとする 仮定forallWweight(W) gt 0 書き込み W は最初に N 個のレプリカサーバのうち一つ
に転送されるそのサーバを origin(W) と表す TW[ij] はサーバ Sj を起源としサーバ Si によって実
行された書き込みとする TW[ij] =Σweight(W) | origin(W) = Sj amp W isin log(Si )
v(t) = vinit +ΣNk=1TW[kk]
vi=vinit + ΣNk=1TW[ik]
2013719分散システム本読書会18
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
プライマリベースプロトコル 問題
全てのサーバ Si について v(t) - vi ≦ δi を保証したい アプローチ
サーバ Sk は Si が TW[ij] の値として持っていると信じている ビュー TWk[ij] を維持している
この情報は更新が伝播したときにゴシップされうる 注意
0 ≦ TWk[ij] ≦ TW[ij] ≦ TW[jj] 解法
Sk は TWk [ik] が TW[kk] からかい離しそうなとき 特に TW[kk] - TWk [ik] gt δi(N ndash 1) そのログから書き込み操作を Si に送る
2013719分散システム本読書会19
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
プライマリベースプロトコル
2013719分散システム本読書会20
任意のデータ要素 x に対してプライマリ ( サーバ )を割り当て プライマリは x に対する write操作に関して責任を持つ
分類 プライマリがある特定のサーバに固定
rArr遠隔書き込みプロトコル (Remote-Write Protocol) write操作の実行を依頼したプロセスにプライマリを移
動してそこで write操作を実行rArrローカル書き込みプロトコル (Local-Write
Protocol)
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
遠隔書き込みプロトコル
2013719分散システム本読書会21
write はある 1 つのサーバで責任を持つ read は近くのローカルコピーから行う
プライマリバックアッププロトコル (primary-backup protocols)[Budhiraja et al 1993]
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
ローカル書き込みプロトコル 書き込みクライアントの場所へのプライマリコピーの移
動を許すローカル書き込みプロトコル write操作実行時のみプライマリをローカルコピーに移動 更新結果は全てのローカルコピーに反映 ( バックアップ ) read操作はローカルコピーに対して実行
2013719分散システム本読書会22
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
レプリカ書き込みプロトコル write操作を複数のレプリカに対して実行 分類
アクティブレプリケーション（ active replication ） 全てのレプリカに対して write操作を実行 ( 更新操作の伝播 )
定足数ベースプロトコル（ quorum-based protocols ） 幾つかのレプリカに対してのみ write操作を実行 多数決投票 (majority voting) メカニズムによって一貫性を保
持
2013719分散システム本読書会23
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
アクティブレプリケーション
2013719分散システム本読書会24
各レプリカをそれぞれ１つのプロセスに対応付け プロセスは対応付けられたレプリカに対して write操作を実
行 write操作は他の全てのレプリカに伝播される アクティブレプリケーションの問題点
全てのレプリカで同じ順番で write操作を実行する必要がある ( 一貫性保持のため )
解決法 全順序マルチキャストの利用
Lamport のタイムスタンプを用いて実装可能 ただしスケーラブルではない
中央コーディネータ ( シーケンサ (sequencer)) の利用 ある 1 つのコーディネータが各 write操作にシーケンス番号を振り全順序を保証 依然としてスケーラブルでない
シンメトリックマルチキャスト (symmetric multicast)[Rodrigues etal 1996] の利用rArr詳細は文献参照のこと
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
定足数ベースプロトコル
2013719分散システム本読書会25
投票ベースプロトコルの一般化 N 個のレプリカからデータを読み込むとき
クライアントは読み取りコーラム (read quorum) と呼ばれるサーバの部分集合に対してリクエスト 任意の NR 個のサーバ
書き込むとき 書き込みコーラム (write quorum) と呼ばれるサーバの
部分集合に対してリクエスト 任意の NW 個のサーバ
ただし NR +NW gtN （ read-write競合を避けるため） NW gtN2 （ write-write競合を避けるため）
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
定足数ベースプロトコル
2013719分散システム本読書会26
読み取り 書き込みコーラムの選択例 特に (c) は Read-One Write-All(ROWA) と呼ばれる例
コーラムベースプロトコルの詳細は [Jalote1994]参照
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
キャッシュコヒーレンスプロトコル キャッシュ (= クライアント起動レプリカ ) の内容
がサーバ側のデータと一貫性があることを保証するプロトコル
コヒーレンス検出戦略 (coherence detection strategy) の違いによる分類（キャッシュの不整合がいつ検出されるか） 静的な解決策
プログラム実行前にコンパイラが静的に分析 動的な解決策
実行時にキャッシュの不整合を検出
2013719分散システム本読書会27
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
キャッシュコヒーレンスプロトコル
2013719分散システム本読書会28
コヒーレンス強制戦略（ coherence enforcement strategy ）の違いによる分類 キャッシュとサーバとの一貫性を保つ手法 単純な解決法共有データはキャッシュに置かずサーバだけに置く
一貫性はプライマリベースまたはレプリカ書き込みプロトコルで保証 性能はキャッシュを用いる場合より悪い
共有データをキャッシュする場合 データが更新されるとサーバが全てのキャッシュに対して無効化 (invalidate) メッセージを送信
するアプローチ データの更新を単純に全てのキャッシュに伝播させるアプローチ
キャッシュされたデータを更新する場合 リードオンリーキャッシュの場合
更新はサーバでのみ行われその更新内容をいずれキャッシュに反映 多くの場合プルベースアプローチを利用
キャッシュされたデータを更新する場合 リードライトキャッシュの場合
ライトスルーキャッシュ（ write-through cache ） キャッシュ内容を更新すると同時にサーバでも更新操作を実行 クライアントキャッシュを一時的にプライマリにするプライマリベースローカル書き込みプロトコルに類似 （順序）一貫性保証のためクライアントに排他的な書き込み権限が与えられる必要
ライトバックキャッシュ（ write-back cache ） キャッシュ内容のみを更新し後でまとめてサーバに伝播 更新の伝播を遅延することによりサーバに通知する前に複数の書き込みが起こることを許容
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
クライアント中心一貫性の単純な実装 各 write操作に大域的なＩＤを付与
その write操作最初に受け付けたサーバが行う 各クライアント毎に以下の２つの集合を管理
read set クライアントが行った一連の read操作に関連する write操作の ID の集合 「関連する write操作」＝一連の read 値を再現するための最
小限の write操作 write set クライアントが行った一連の write操作の
ID の集合
2013719分散システム本読書会29
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
クライアント中心一貫性の単純な実装
2013719分散システム本読書会30
モノトニック読み取り一貫性の実装 クライアントが read操作を行うとき read set をサーバに送信し
サーバは関連する write操作がすべて実行済みかをチェック もし実行していないものがあれば他の複製サーバと通信して必要
な write操作を適切な順序で実行しローカルコピーを更新 write操作の順序一貫性は適切な手法（タイムスタンプなど）で保障
モノトニック書き込み一貫性も同様 write操作を行うときに write set を送信
書き込み後読み取り一貫性の実装 クライアントが read操作を行うとき write set をサーバに送信 サーバは write set に含まれていてまだ実行されていない write を実行しローカルコピーを更新
読み取り後書き込み一貫性も同様 write操作を行うときに read set を送信
