関係データベース開発者に対する「eventual consistency（最終的一貫性）」の説明

分散システムでは、同じ論理データが複数のマシンに存在したり、あるサービスが別のサービスが所有するデータのローカルビューを維持したりすることがあります。結果整合性とは、システムが更新を受け入れる前に、その更新がすべてのコピーに到達する必要がないことを意味します。しばらくの間、異なるリーダーは異なる値を見る可能性があります。更新が停止し、通信とレプリケーションが正常に続行されれば、コピーは同じ値に収束します。「結果的」という言葉だけでは、特定の締め切りは約束されません。

図書館のいくつかの支店がカタログのコピーを保持していると想像してください。強い整合性では、図書館員が本の場所を変更し、確認を受け取ると、その後のカタログ検索は、その変更またはそれ以降の変更を反映する必要があります。支店は、古い場所で回答しないように調整します。現在の値を確認できない場合は、待機するか、エラーを返す必要があります。

結果整合性では、支店は変更を記録し、後で他の支店に通知できます。別の支店の誰かが一時的に古い棚の場所を見る可能性があります。その支店が必ずしも誤動作しているわけではありません。まだ追いついていないローカルコピーから回答しています。これは、使い慣れたSQLワークフローからの重要な変化です。書き込みが成功したからといって、読み取ることができるすべての場所がすでにそれを反映しているとは限りません。

用語の重要な区別があります。ACIDのCは、トランザクションが制約などのデータベースの不変条件を維持することを意味します。レプリカ間の強い整合性は、通常、線形化可能性を指します。これは、操作が1つの最新のコピーがあったかのように動作することを意味します。これらは同じ保証ではありません。データベースはローカルでACIDトランザクションを実行しながら、その結果を非同期に他の場所にレプリケートできます。また、リレーショナルクエリが見るものは、トランザクションの分離レベルとスナップショットによって異なります。

なぜ古い読み取りを受け入れるのか？調整には時間がかかり、操作はマシン間の通信に依存します。リージョン間では、ネットワークの往復時間はかなりのものになります。非同期レプリケーションにより、ローカルでの読み取り、および一部のデザインでは、リモートレプリカを待たずにローカルでの書き込みが可能になり、レイテンシが改善され、他のノードへの依存が軽減されます。

CAP定理は、ネットワークパーティション中のこのトレードオフを鋭くします。ノードのグループが通信できない場合、分散システムは、線形化可能な整合性と、機能しているノードへのすべての要求に対する可用性の両方を保証することはできません。整合性を維持するために、操作を遅延または拒否する必要がある場合があります。両側のリクエストを提供し続けるために、もう一方の側とまだ調整できない応答または更新を許可する必要がある場合があります。結果整合性は、その状況で可用性を選択するシステムで一般的に使用されるアプローチです。CAPは「常に2つを選択する」という意味ではありません。避けられない選択はパーティション中に発生します。同時更新には、明示的な競合解決ルールも必要です。収束は魔法ではありません。

ソーシャルアプリケーションの「いいね！」の数は良い候補です。121ではなく、一時的に120いいね！と表示されても、通常は無害です。対照的に、銀行口座のオーバードラフトなしのルールを強制するためだけに結果整合性を使用することは許容できません。2つのサービスが同じ古い残高を読み取ると、両方とも引き出しを承認する可能性があります。その決定には、権威のあるアトミックチェックアンドアップデートまたは同等の調整が必要です。その銀行アプリケーション内でも、分析ダッシュボードは安全に遅延することができます。

2つのパターンがユーザーが遅延を処理するのに役立ちます。まず、読み取り時の書き込み動作を備えた楽観的なUIを使用します。ユーザーの新しいコメントをすぐに表示し、レプリカが追いつくまで表示し続けるか、そのユーザーの読み取りを書き込みを適用したソースにルーティングします。確認されていない変更を保留中としてマークし、サイレントに保存済みとして扱うのではなく、失敗を明確に処理します。

第二に、非同期処理を明示的にします。「変更は保存されました。検索結果を更新しています」と表示し、関連する読み取りビューが更新を反映するまでポーリングするか、プッシュ通知を使用します。受け入れ済み、処理中、完了の状態を区別することで、一見不正確な画面が理解可能なワークフローに変わります。

「データベースは常に正しい」から「データベースはまもなく正しくなります」へ

単一のリレーショナルデータベースに対してSQLを記述する場合、非常に快適な保証の中で生きています。BEGINを実行し、UPDATEを実行し、COMMITを実行すると、その瞬間から世界中のすべての接続が新しい値を確認できるようになります。あるユーザーが古い行を見て、別のユーザーが新しい行を見ているというウィンドウは存在しません。その保証は、ACIDの「C」（一貫性）と「I」（分離性）であり、ロック、ラッチ、そして単一のマシン上の単一のライトアヘッドログによって強制されます。

分散システムは、いい加減さからではなく、ネットワークの物理法則が選択を強制するため、その快適さを壊します。その選択を理解することが、結果整合性（eventual consistency）のすべてです。

1. 強整合性 vs. 結果整合性：アナロジー

強整合性は、単一の部屋にある単一のホワイトボードです。

チームがオンコールスケジュールを1つのオフィスにある1つの物理ホワイトボードで管理していると想像してください。オンコール担当者を変更したい場合は、部屋に入り、消して書き直している間、他の誰もそれを読むことは許可されません。彼らはドアの外で待ちます。あなたが離れた瞬間、入ってくる誰もがまったく同じ、正しいスケジュールを見ます。真実はただ1つしかなく、それへのアクセスはシリアル化されています。それは行ロックを持つPostgresインスタンスのようなものです。

結果整合性は、会社中に広がる噂です。

次に、ベルリン、サンパウロ、シンガポールにオフィスを持つ会社を想像してください。各オフィスは独自のホワイトボードにスケジュールのコピーを保持しています。ベルリンのボードを変更します。メッセンジャーがサンパウロとシンガポールに派遣されます。次の数秒間、またはメッセンジャーが交通渋滞に巻き込まれた場合は数分間、シンガポールの同僚がローカルボードを読んでも、古いスケジュールしか見られません。彼らは破損したデータを読んでいるのではなく、少し前の正しいデータを読んでいるのです。それ以上の変更がなければ、3つのボードすべてが同じ値に収束します。「書き込みが停止すれば、すべてのレプリカが合意する」というその収束保証こそが、「結果的」という意味です。

重要な考え方の転換：古いデータは間違ったデータと同じではありません。 古いデータはシステムの有効な過去の状態です。破損したデータは、システムが一度も持ったことのない状態です。結果整合性は前者（古いデータ）を許可し、後者（破損したデータ）は依然として禁止します。

2. 分散システムがこれを選択する理由：CAPトレードオフ

CAP定理（Brewerの定理）は、分散データストアが同時に3つのプロパティのうち最大2つしか提供できないと述べています。

• C — 一貫性（Consistency）： すべての読み取りが最新の書き込みを返す。
• A — 可用性（Availability）： すべてのリクエストがエラー応答を受け取らない。
• P — 分割耐性（Partition tolerance）： システムは、ノード間のメッセージのネットワークドロップまたは遅延が発生しても動作し続ける。

ここで人々がつまずくのは、Pはオプションではないということです。データが複数のマシンにまたがって存在する場合、ネットワークパーティションは必ず発生します。スイッチが故障したり、ケーブルが切断されたり、クラウドの可用性ゾーンが到達不能になったり、GCの一時停止でノードがダウンしているように見えたりします。重力がないことを選択できないのと同じように、パーティションがないことを「選択」することはできません。したがって、CAPは実際には強制的な質問です。パーティションが発生した場合、CまたはAのどちらを犠牲にしますか？

• CP（可用性を犠牲にする）を選択： パーティション中、最新のデータを持っていることを確認できないノードは応答を拒否します。読み取りと書き込みはエラーを返すか、パーティションが回復するまでブロックされます。データが古くなることはありませんが、一部のユーザーにとってはサービスが停止します。これは、コンセンサス（Raft/Paxos — etcd、ZooKeeper、または同期レプリケーションされたSQLクラスタを考える）を使用する分散システムがほぼ行うことです。

• AP（強整合性を犠牲にする）を選択： パーティション中、各ノードはローカルで持つ最良のデータで応答し続け、接続が回復したときに後で調整します。誰もエラーを見ません。一部のユーザーはしばらくの間古い値を見ます。これは、デフォルトモードのDynamoDB、低いクォーラム設定のCassandra、DNS、およびほとんどのCDNバックエンドの読み取りパスです。

パーティション以外にも、さらに2つの圧力があります。

レイテンシ。 地理的にまたがる強整合性には調整が必要であり、調整にはネットワークラウンドトリップのコストがかかります。フランクフルトでの書き込みがシドニーのレプリカによって確認される前に200 OKを返す必要がある場合、各リクエストに約250ミリ秒の光速税が追加されます。それは最適化できるバグではなく、惑星の直径です。CAPへのPACELC拡張はこれを捉えています：パーティションが発生した場合、可用性または一貫性を選択します。それ以外の場合は、レイテンシまたは一貫性を選択します。 完全に正常なネットワーク上でも、調整のコストを支払っています。

マイクロサービスの結合度。 モノリスでは、注文テーブルと在庫テーブルは同じデータベースにあったため、BEGIN TRANSACTIONで両方をカバーできました。注文と在庫が別々のサービスと別々のストアになった場合、単一のACIDトランザクションは2フェーズコミットを必要とします。これはネットワーク全体でロックを保持し、コーディネーターの障害が参加者を無期限にブロックする可能性があります。ほとんどのチームは2PCを拒否し、代わりに非同期パターン（イベント発行、アウトボックスパターン、Saga）を使用します。これらのパターンは、構築上、結果整合性があります。結果整合性は、多くの場合、データベースの選択ではなく、システムを独立してデプロイ可能なサービスに分解することの避けられない結果です。

したがって、正直な要約は次のとおりです。分散システムは、障害時の可用性、大規模な低レイテンシ、およびサービス間の独立性 を購入するために結果整合性を選択します。そして、多くの種類のデータにとって、数百ミリ秒の古さはビジネス上のコストにはなりません。

3. 許容される場合と絶対に許容されない場合

許容される場合：ソーシャル投稿の「いいね！」または閲覧数、検索インデックス。

投稿に4,812件の「いいね！」があるとします。あなたが「いいね！」をすると、書き込みはローカルレプリカに送信され、即座に返されます。別の地域のユーザーがリフレッシュすると、4,813件になる前に、さらに800ミリ秒の間4,812件が表示されます。損害は何ですか？何もありません。お金は動かず、約束は破られず、古い数字に基づいて決定は下されませんでした。検索インデックス（新しく公開された記事が検索可能になるまで2秒かかる）、ユーザープロファイルのアバター、レコメンデーションフィード、分析ダッシュボードも同様です。その無害な遅延と引き換えに、機能はネットワークパーティション中に稼働し続け、世界中で一桁ミリ秒で応答します。

有用なテスト：ユーザーが5年前のデータに基づいて行動した場合に何が壊れるかを尋ねてください。 いいねカウンターの場合、何も壊れません。

許容されない場合：金融送金の借方側、または希少品の在庫。

2つの口座間で500ユーロを送金する場合、または引き出し前の口座残高の確認を検討してください。残高レプリカが古い場合、600ユーロの残高に対して2回のATM引き出し（各500ユーロ）が両方とも承認される可能性があり、あなたは何もなかったところから400ユーロを作り出してしまいます。「後で」調整することは、実際の顧客が実際の借金を負うことを意味し、規制上の問題が発生する可能性もあります。コンサートチケットの最後の1枚を販売したり、ユニークなユーザー名を割り当てたり、「1人につき1票」のルールを強制したりする場合も同様です。これらはすべて一意性または非負不変条件であり、決定の瞬間に保持されなければならない不変条件は、その後にしか合意を約束しないシステムでは強制できません。

これらのケースでは、クリティカルパスで強整合性が必要です。単一パーティショントランザクション、コンセンサスバックエンドストア、条件付き/比較・設定書き込み、または不変条件を狭く囲む分散ロックまたはリースです。

重要なニュアンス： これはアプリケーション全体での決定ではありません。同じeコマースシステムでも、チェックアウト時の支払い承認は強整合性がありますが、「お客様が他に購入したもの」カルーセル、製品レビュー数、注文履歴リストはすべて結果整合性があります。成熟した設計は、操作ごとに一貫性を選択し、不変条件が本当にそれを要求する場合にのみ調整コストを支払います。一般的な回避策は、不変条件を設計で回避することです。「最後のチケットをアトミックに予約する」のではなく、追加専用の予約イベントの台帳をモデル化し、売り越しが発生した場合はSagaで補償します。これは航空会社が常に過剰予約を処理してきた方法です。

4. ユーザーから遅延を隠すための2つのパターン

ユーザーはレプリケーションラグのメンタルモデルを持っていません。もし彼らが「保存」をクリックし、成功メッセージを見て、リストに移動しても、その変更が表示されない場合、彼らはあなたの製品が壊れていると判断し、もう一度「保存」をクリックします。これにより重複が発生します。2つのパターンがほとんどのこれを解決します。

パターンA：読み取り自身の書き込み（セッション整合性）、楽観的UIまたはスティッキー読み取り経由。

最も不快な失敗は、ユーザーが自身の変更を見られないことです。修正策は、グローバルな強整合性よりもはるかに安価な、ライター自身のセッションに対してのみ整合性を保証することです。2つの実装：

• 楽観的UI： クライアントは、サーバーからの再読み取りを待つのではなく、送信したペイロードから期待される結果を即座にレンダリングします。コメントを投稿すると、書き込みがバックグラウンドで伝播している間に、コメントがローカル状態からレンダリングされ、スレッドに即座に表示されます。サーバーが最終的にそれを拒否した場合、クライアントはアイテムをロールバックし、エラーを表示します。これは、チャットアプリやGoogleドキュメントが、高度に非同期でありながら瞬時に感じられる理由です。
• スティッキー/ピン留め読み取り： 書き込み後、短いウィンドウの間、そのユーザーの読み取りをプライマリ（または書き込みを受け付けたレプリカ）にルーティングするか、バージョン情報（「読み取り自身の書き込み」整合性トークン、LSN、またはベクトルクロック）を後続の読み取りに渡して、システムがレプリカが少なくともそのバージョンまで追いつくまで待てるようにします。コストは、書き込みを行ったばかりのセッションのごく一部のユーザーのみが負担します。

パターンB：ドメインモデルとUIでの明示的な「保留中」状態。

操作が瞬時に行われたと偽るのではなく、非同期ステップをデータモデルとインターフェースのファーストクラスのパートにします。銀行振込は**「保留中 — 明日までに完了します」と表示されます。ビデオアップロードは「処理中」と表示されます。注文は「支払い確認済み、発送待ち」**と表示されます。これは正直であり、ユーザーの既存の現実世界の期待（小切手のクリアには時間がかかることを誰もが理解している）と一致しており、混乱するデータの不在を有意義な情報に変換します。技術的には、これはエンティティのライフサイクルに対するステートマシンのアイデアと同じで、ドメインイベントによって駆動され、Sagaと自然にペアになります。各ステージは表示されるステータスを遷移させ、障害は「返金済み」のような補償状態に遷移させます。静かに消えるのではなく。

内部化する価値のある2つのサポートプラクティス：

• すべての書き込みを冪等にしてください。 各リクエストにクライアント生成の冪等キーを添付します。ユーザーがUIの遅延のためにダブルクリックした場合、またはタイムアウト後にリトライが発火した場合、2番目のリクエストは認識され、破棄されるため、2番目の注文が作成されることはありません。結果整合性の世界では、「ちょうど1回」配信はフィクションです。冪等ハンドラは、ちょうど1回の効果を得る方法です。
• 最後の書き込み者がクロックで勝つのではなく、収束のために設計してください。 異なるマシンの壁時計は一致しません。論理バージョン（ベクトルクロック、Lamportタイムスタンプ）、追加専用イベントログ、またはCRDT（マージ関数が定義されたカウンタ、セット、レジスタ）を使用して、同時更新が1つがサイレントに上書きするのではなく、決定論的にマージされるようにします。

今後持ち歩くべきメンタルモデル

データベースを現在の真実を保持する単一の紙のシートとして考えるのをやめ、それを発生したことのログ、それに加えてそのログのさまざまな時点にいる多くのリーダーとして考えるようにしてください。ACIDは、常にすべての人がログの同じ時点に立っているという幻想を与えてくれました。その幻想は、1台のマシンでは手頃な価格ですが、多数のマシンにまたがると高価になります。

エンジニアとしてのあなたの仕事は、「すべてを一貫させる」ことではなくなりました。それは、決して侵害されてはならない少数の不変条件（お金、一意性、非負カウント、承認）を特定し、そこで正確に強整合性のコストを支払い、残りはすべて独自のスケジュールで収束させ、UIがユーザーに何が起こっているかについて正直な物語を伝えることです。任意の機能についてどのくらい古いと古すぎ、何が壊れるかを説明できるようになれば、あなたは移行を完了したことになります。