イベントチュアルコンシステンシー（最終的整合性）をジュニアWeb開発者に説明する

Eventual Consistency, Junior Web Developer のための解説

基本的なCRUDアプリを構築する場合、通常は1つのデータベースを使用します。値を書き込み、それを読み戻すと、書き込んだものとまったく同じものが得られます。この即時的で予測可能な動作は、Strong Consistency（強い整合性）またはImmediate Consistency（即時整合性）と呼ばれます。それは明白で、まるで自然の法則のようです。しかし、アプリケーションが世界中に分散した多数のサーバーで実行されるほど大きくなると、その単純な保証は驚くほど高価になります。Eventual Consistency（結果整合性）は、多くの最新システムが速度と信頼性の引き換えに受け入れているトレードオフです。

Eventual Consistency が実際に意味すること

大規模システムでは、データを1つの場所に保持しません。異なるサーバー、しばしば異なる都市や国に複数のコピー（レプリカと呼ばれる）を保持します。これは、アプリがどこにいてもユーザーにとって高速であり、たとえ1つのサーバーがクラッシュしても機能し続けるようにするためです。

問題は、データを更新するとき、それらのコピーすべてをまったく同じ瞬間に更新できないことです。変更が1つのコピーから他のコピーに広がるまで、常にわずかな遅延があります。Eventual Consistency は、その遅延に関する単純な約束です。つまり、新しい更新が行われなければ、短い期間の後、すべてのコピーが同じ値に合意します。言い換えれば、システムは即時ではなく、最終的に整合性が取れるようになります。その短いウィンドウの間、異なるユーザー（あるいは異なるリクエストでの同じユーザー）は、データのわずかに異なるバージョンを見る可能性があります。

システムが意図的にこれを選択する理由

それは欠点のように聞こえますが、なぜこれを選ぶのでしょうか？正直な答えは、分散システムはトレードオフを強制するということです。サーバーが分散し、ネットワークが時折失敗したり遅くなったりする場合、システムは次のいずれかを行うことができます。

1. レスポンスを返す前に、すべてのコピーが更新を確認するのを待ちます。これにより、Strong Consistency が得られますが、書き込みが遅くなり、1つのサーバーに到達できない場合、操作全体が停止または失敗する可能性があります。

2. 1つのコピーを更新した後、すぐにレスポンスを返し、残りをバックグラウンドで同期します。これにより、速度と可用性が得られます。システムの一部が苦労している場合でも、アプリは高速に動作し、リクエストを受け付け続けます。これは、コピー間の一時的な不一致を犠牲にします。

Eventual Consistency はオプション2です。何百万人ものユーザーにサービスを提供するシステム（ソーシャルネットワーク、オンラインストア、ストリーミングプラットフォーム）は、多くの場合、毎ミリ秒完全に同期されることよりも、高速で常に利用可能であることを重視します。2秒間1つずれているいいねの数は、遅く感じず、めったにダウンしないサイトにとっては、通常は許容できる代償です。

具体的なEコマース/ソーシャルメディアの例

ちょうどバイラルになったソーシャルメディアの投稿を想像してみてください。何千人もの人々が同時に「いいね！」をしています。いいねの数は複数のレプリカに保存されています。あなたは投稿に「いいね！」をし、すぐにカウントが1,000から1,001にジャンプするのを見ます。別の国の友人が同時にリフレッシュすると、更新が彼らの最寄りのレプリカにまだ到達していないため、1〜2秒間はまだ1,000を見ます。どちらのユーザーも「バグ」を見ているわけではありません。システムが追いついているだけです。数秒後、両方のユーザーが同じ数値を見ます。同じ考え方がEコマースの商品レビューに適用されます。レビューを投稿するとすぐに表示されます（デバイスはあなた自身の行動を表示するため）。しかし、他の買い物客は、それが伝播するまでしばらくの間それを見ることができないかもしれません。

簡単なアナロジー

数人の友人が夕食を計画しているグループチャットを考えてみてください。しかし、誰もが異なるグループメンバーを介してメッセージをやり取りしており、メッセージがリレーされていきます。誰かが「7時に会いましょう」と言うと、そのメッセージが全員に届くには少し時間がかかります。数秒間、一部の友人は計画が7時だと思っていますが、他の友人にはまだ更新が届いていません。誰も嘘をついておらず、メッセージが失われたわけでもありません。ただ、一度にすべての人に届いていないだけです。少し待てば、グループ全体が合意します。その短い「間の」期間は、まさにEventual Consistencyがどのように感じられるかです。

ユーザーとアプリのデザインにとっての意味

実際的な影響は、「自分が書いたものがすぐに全員に読まれる」と仮定できなくなることです。Stale Read（古いデータを見ること）は、障害ではなく、正常なことです。危険なのは、これを無視するとユーザーを混乱させたり、害を与えたりする可能性があることです。たとえば、誰かが注文をしたが、注文履歴が空に見え、注文が失敗したと判断して、もう一度注文して二重に請求される可能性があります。優れたデザインは、その混乱を防ぐことです。

混乱と損害を軽減するためのデザインテクニック

1. Read-your-own-writes（自分の書き込みは自分で即座に読む）。グローバルシステムがまだ同期中であっても、ユーザーは常に自分のアクションの結果をすぐに確認できるようにします。誰かがコメントを投稿したり、カートに商品を追加したりした後、オプティミスティックに自分の画面を更新して、変更が即座に反映されるようにします。これにより、最悪の体験（ユーザーが何かをして、効果が見られない）が回避されます。

2. UIで状態を正直に伝えます。まだ確定していないのに、すべてが確定したかのように見せかけないでください。「送信中…」「保留中」「保存中」などの明確な一時的な信号や、控えめなスピナーを使用し、変更が確認されたら完了を伝えます。まだ伝播している可能性がある場合は、「他の人に表示されるまでしばらく時間がかかる場合があります」のような小さな注意書きは、適切な期待を設定し、パニックによる重複アクションを防ぎます。

3. 操作を繰り返し安全に行えるようにする（冪等性）と、二重の損害を回避する。重要な操作は、二度行っても損害が発生しないように設計します。たとえば、各注文または支払いに一意のリクエストIDを付与することで、ユーザーが確認が見えなかったために再試行した場合、システムはそれを同じアクションとして認識し、二度請求することはありません。これは、不整合のウィンドウ中にユーザーを保護し、再試行する可能性が最も高くなります。

4. 本当に重要な場合にのみ、より強い整合性（Strong Consistency）を選択します。Eventual Consistency は、いいねの数、表示回数、またはおすすめリストには適しています。しかし、支払いの最終ステップや、在庫の最後のアイテムがまだ利用可能かどうかを確認する場合には適していません。間違いがコストのかかる少数の操作にはより強い保証を使用し、それ以外の場合はEventual Consistencyを受け入れます。どのデータがどの保証を必要とするかを知ることは、あなたが下すことができる最も価値のある判断の1つです。

過度に単純化しない、コアとなるトレードオフ

Eventual Consistency は、不注意な意味での「弱い」ものではありません。それは、速度と可用性を、データのコピー間の一時的な不一致を犠牲にして購入する意図的な選択です。分散システムでは、完璧な即時整合性、完璧な可用性、およびネットワーク障害に対する完璧な耐性をすべて同時に持つことはできません。何かを犠牲にしなければなりません。Eventual Consistency は、即時の合意を犠牲にします。開発者としてのあなたの仕事は、この現実に逆らうことではなく、それに対処するように設計することです。ユーザーに自分の変更をすぐに表示し、保留中の状態を明確に伝え、リスクのあるアクションを安全に再試行できるようにし、正しいことが待てないごく一部の場所にはStrong Consistencyを予約します。それを行えば、一時的な不整合は、ユーザーの混乱の原因ではなく、目に見えない実装の詳細になります。

Webアプリケーションが成長するにつれて、特に多くのユーザーにサービスを提供したり、グローバルに展開したりするアプリケーションでは、開発者はしばしば**結果整合性（eventual consistency）**という概念に遭遇します。これは、現代の分散システムにおける基本的なトレードオフであり、より高いスケーラビリティと可用性を可能にしますが、データに対する異なる考え方を必要とします。

結果整合性とは何か？

あなたが構築した典型的なWebアプリケーションでは、データベースのデータを更新したとき（例：ユーザーのプロフィールを変更する）、その後の読み取り操作でその変更がすぐに反映されることを期待します。これは**即時整合性（immediate consistency）**と呼ばれます。書き込み操作が完了したと見なされる前に、データのすべてのコピーが更新され同期されます。

一方、結果整合性とは、書き込み操作が成功した後、システムのすべてのコピー間でデータがすぐに整合的になるとは限らないことを意味します。代わりに、特定のデータ項目に対して新しい更新が行われない場合、その項目へのすべてのアクセスは最終的に最後に更新された値を返すことがシステムによって保証されます。遅延はありますが、データは時間とともに整合的になります。

なぜ結果整合性を選ぶのか？

大規模なソーシャルメディアプラットフォームやeコマースサイトのような現代のWebシステムは、しばしば何百万人ものユーザーと膨大な量のデータを処理する必要があります。これを実現するために、単一のデータベースに依存することはできません。データを多くのサーバー、しばしば異なる地理的な場所に分散させます。これらの分散されたすべてのコピーを即時に整合させることは、信じられないほど困難でコストがかかります。それは、すべての書き込み操作がすべてのコピーからの確認を待つ必要があることを意味し、これは非常に遅く、1つのサーバーが一時的に利用できなくなっただけでも失敗しやすくなります。

結果整合性は、システムが即時整合性よりも可用性（一部のコンポーネントが失敗してもシステムは稼働し続ける）とパフォーマンス（書き込みと読み取りが高速）を優先することを可能にします。書き込みをサーバーのサブセットで迅速に完了させ、その後非同期に変更を他のサーバーに伝播させることで、システムはより多くのトラフィックを処理し、応答性を維持できます。

ユーザーとアプリケーション設計への実際の影響

ユーザーにとっては、最も顕著な影響は、一時的にわずかに古い情報を見る可能性があることです。アプリケーション設計者にとっては、特に書き込み直後であっても、読み取り操作が常に最新のデータを返すとは限らないと仮定できないことを意味します。

具体的な例（ソーシャルメディア）：
ユーザーが投稿に「いいね！」できるソーシャルメディアアプリを想像してください。ユーザーAが投稿に「いいね！」をすると、クライアントはすぐに「いいね！」の数がインクリメントされたことを表示します。しかし、結果整合性のために、異なるサーバーに接続されているユーザーBは、更新が彼らのサーバーに伝播されるまで、数秒間、あるいは1分間さえも古い「いいね！」数を見る可能性があります。最終的には、両方のユーザーが同じ、正しい「いいね！」数を見ることになります。

簡単な例え：
多くの支店を持つ大企業を考えてみてください。支店Aで誰かが連絡先情報を更新すると、その情報は支店Aですぐに利用可能になります。しかし、その更新された情報が他のすべての支店に到達するには時間がかかる場合があります（例：一晩の同期や1時間ごとのデータ転送）。短期間、支店Bの誰かがその人の連絡先情報を検索した場合、古い詳細を見る可能性があります。しかし、最終的にはすべての支店が正しく更新された情報を持つことになります。

不整合を軽減するための設計テクニック

結果整合性は強力なツールですが、ユーザーの混乱やデータの整合性の問題を防ぐためには、慎重なアプリケーション設計が必要です。以下に3つのテクニックを示します。

1. オプティミスティックUI更新と読み取り自身の書き込み（Read-Your-Writes）： ユーザーがアクション（コメントの投稿やアイテムへの「いいね！」など）を実行したとき、バックエンドが完全に伝播する前であっても、UIを即座に変更してその変更を反映させます。これにより、ユーザーは即時のフィードバックを得られます。さらに、「読み取り自身の書き込み」整合性を実装します。これは、書き込みを実行したユーザーが、他のユーザーが一時的に古いデータを見る可能性がある場合でも、常に自身の最新の変更を見ることを保証します。これは、その後の読み取りを書き込みを行ったサーバーにルーティングするか、最近の書き込みをローカルにキャッシュすることで実現できます。

2. 情報提供的なUIとステータスインジケーター： 結果整合性のあるデータについては、データの鮮度をユーザーに知らせるUI要素を検討してください。「X分前に最終更新」というタイムスタンプ、データが更新中であることを示すローディングスピナー、または「変更が全員に表示されるまでしばらく時間がかかる場合があります」のような微妙なメッセージなどが考えられます。これにより、ユーザーの期待が管理され、期待した更新がすぐに見られないときの混乱が軽減されます。

3. 戦略的な使用とクリティカルパスのためのより強力な整合性： すべてのデータが結果整合性に耐えられるわけではありません。金融取引（例：口座からの引き落とし）や在庫管理（例：アイテムが一度だけ販売されることを保証する）のような非常にクリティカルな操作については、即時整合性を強制するシステムやパターンを使用する必要があります。一時的な不整合が許容されるアプリケーションの部分（例：ソーシャルメディアフィード、ユーザープロフィール、コメント数）を特定し、そこに結果整合性を適用し、真にクリティカルなデータパスにはより強力な整合性モデルを予約してください。