結果整合性という割り切り
要点
- 強整合性は「いつ読んでも最新」を保証し、結果整合性は「いつかは揃う」を許容する。両者は割り切りの方向が違う。
- Eric Brewerが示したCAP定理は、ネットワーク分断のもとでは整合性と可用性の両立に限界があることを述べる。
- Werner Vogelsの「Eventually Consistent」は、大規模サービスがあえて結果整合性を選ぶ理由を実務から論じた。
- どちらが正しいかではなく、扱うデータがどれだけ古さを許せるかが選択を決める。
銀行の残高は、いつ見ても正確であってほしい。一方、SNSの「いいね」の数が、数秒のあいだ端末によって少し違っても、たいていの人は困らない。この感覚の差は、データの整合性をめぐる二つの立場——強整合性と結果整合性——の違いをよく表している。両者を並べると、分散システムが何を諦め、何を取ろうとしているかが見えてくる。
強整合性：常に最新を返す
強整合性とは、書き込みが完了したあとに読めば、必ずその最新の値が返るという保証である。残高の更新が終わった瞬間から、どこから読んでも新しい残高が見える。直感に最もよく合う振る舞いで、間違いが許されない領域では欠かせない。
代償は、調整のコストだ。複数のサーバーに同じデータを複製している場合、「最新」を保証するには、すべての複製が揃うのを待つか、調整役と通信する必要がある。その待ち時間は、応答の遅延として現れる。ネットワークが乱れているとき、強整合性は「正しいが、返ってこない」状態を生みうる。
結果整合性：いつかは揃う
もう一方の結果整合性は、割り切りの向きが逆だ。書き込み直後の短いあいだ、複製のあいだで値が食い違うことを許す。ただし、新たな更新が止まれば、やがてすべての複製が同じ値に収束する。Werner Vogelsは「Eventually Consistent」という論文で、Amazonのような大規模サービスが、なぜあえてこの方式を選ぶのかを実務の観点から論じた。要点は、常時の最新性よりも、止まらず応答し続けることを優先する場面が現実には多い、ということである。
結果整合性のもとでは、たった今書いた値が、別の端末ではまだ見えないことがある。非同期に処理を流す設計とこの考え方は地続きで、どちらも「即座の一致」をいったん手放す代わりに、全体の応答性と耐障害性を得ている。
CAP定理という補助線
この対立を理論として整理したのが、Eric Brewerの示したCAP定理である。ネットワークの分断が起きたとき、一貫性（Consistency）と可用性（Availability）の両方を同時に完全には満たせない、という主張だ。分断時に「正しさを守って応答を止める」のか「応答を続けて一時的な不一致を許す」のか——どちらかを選ばざるを得ない。
もっとも、CAP定理はしばしば単純化されすぎる。現実の分断は常時起きているわけではなく、平時には両立できる。だから実務上の問いは「CのシステムかAのシステムか」ではなく、「分断という例外時に、どちらへ倒すか」を事前に決めておくことだ。定理は二択を迫る道具ではなく、例外時の方針を言語化させる補助線として効く。
許せる古さで決まる
強整合性と結果整合性は、優劣ではなく適性の話である。決済や在庫の引き当てのように、不一致が直接損害になる領域では、遅くても強整合性を選ぶ。閲覧数やタイムラインのように、わずかな古さが実害を生まない領域では、結果整合性で応答性を取る。即時に返す層とまとめて確定させる層を分ける設計は、この使い分けの実装でもある。
結局のところ、選択を決めるのは技術の新しさではなく、扱うデータがどれだけ古さを許せるかという業務側の事情だ。すべてを強整合性で固めれば安全に見えるが、応答性とコストを失う。すべてを結果整合性にすれば速いが、一致を当てにできない場面が増える。割り切りの向きを、データの性質ごとに選ぶ。背景でデータを揃え続けるこの営みは、正しさと速さのあいだで毎回ひとつの妥協点を置く作業の連続である。
出典
- Werner Vogels「Eventually Consistent」（ACM Queue / Communications of the ACM）
- Eric Brewer によるCAP定理（PODC基調講演および後続の解説）