CAP の availability 模擬

通信が切れた瞬間、どちらかを諦めることになる

同じデータを3台のサーバーに置くと、1台が止まっても別の台から読めます。厄介なのは、サーバー同士をつなぐ回線が切れ、それぞれは動いたまま連絡できなくなる場合です。この状態をネットワーク分断と呼びます。

東京の2台と大阪の1台が分断されたとします。東京で値を v2 に更新しても、大阪の値は v1 のままです。大阪へ読みに来た人には、手元の古い値を返すか、新しい値を確認できるまで正常な読み取り応答を止めるかを選ぶ必要があります。

CAPのCは、完了した更新を踏まえた一貫した読み取りを指します。Aは、故障していない各サーバーが要求に正常な応答を返すことです。Pはネットワーク分断です。分断が起きている間、CとAを常に両立することはできません。エラーをすぐ返しても、読めないならここでのAを守ったことにはなりません。

解説

現場の話 銀行の残高のように古い値で判断すると困る場面では、一部の要求を止めてでも一貫性を守る設計があります。SNSのいいね数では、少し古い数を許して表示を続ける設計もあります。どちらを選ぶかは用途によります。

何台が同じ値を返せば採用するか

ここからは、複数の台が返す値を多数決で読む簡単なモデルを考えます。同じデータを持つ台をレプリカと呼びます。全台数の過半数が同じ値を返したらその値を採用し、届かなければ合意なしとします。

5台のうち3台が v2、1台が v1、1台が無応答なら、v2 は過半数の3票に届きます。この条件では1台が無応答でも値を採れます。

4台が2票ずつに割れたら、どちらも採りません。最多の値を選ぶことと、過半数に届いた値を選ぶことは別です。

無応答でも、全台数からは除かない

無応答は空文字で表し、値の票数には入れません。ただし、過半数の基準は無応答を含む全台数です。返事が来た台だけで基準を下げると、分断の別々の側で違う値を採るおそれがあります。

多数決で値が決まっても、その値が最新かは票数だけでは分かりません。本物の quorum read では書き込みの規則や更新の順序も関わります。このモデルは過半数の判定を読むためのもので、CAPの両立できない性質を解消する仕組みではありません。

例題で確かめる

6台の返答が v3、v3、v3、v2、空文字、空文字だとします。必要な票は6 ÷ 2の整数部分に1を足して4票です。v3 は3票、v2 は1票なので合意なしです。返事のある4台だけなら3票は過半数に見えますが、全6台で判断するため採用できません。