CAP定理をプロダクトマネージャーに説明する

さて、CAP定理についてお話ししましょう。これは分散システムの基本的な概念であり、今後のアーキテクチャに関する議論で非常に重要になります。これは、複数のマシンにまたがってデータを保存するシステムを設計する際に、固有のトレードオフを理解するための指針と考えてください。 CAP定理は、分散データストアは、整合性（Consistency）、可用性（Availability）、およびネットワーク分割耐性（Partition Tolerance）の3つのプロパティのうち、任意の時点で2つしか保証できないと述べています。それぞれの意味を実用的な言葉で分解してみましょう。 1. **整合性（Consistency, C）:** プロフィール写真を変更するなど、ある情報を更新したと想像してください。整合性の取れたシステムは、プロフィール写真を閲覧しようとする*すべて*のユーザーが*新しい*写真にすぐにアクセスできることを保証します。一部のユーザーは古い写真を見、他のユーザーは新しい写真を見るという期間はありません。システムがどの部分にアクセスしても、すべてのユーザーは同時に同じ、最新のデータを見ます。 2. **可用性（Availability, A）:** 可用性の高いシステムとは、送信したすべてのリクエストに応答があることを意味します。システムは常に稼働しており、リクエストに対応する準備ができています。「システムが利用できません」というエラーメッセージが表示されたり、タイムアウトが発生したりすることはありません。常に*最新*のデータが得られるとは限りませんが、常に*何らかの*応答が得られます。 3. **ネットワーク分割耐性（Partition Tolerance, P）:** これは、システムがネットワーク障害にどのように対処するかということです。分散システムでは、異なる部分（ノード）がネットワークを介して通信します。ネットワーク分割とは、これらのノードの一部間のネットワーク接続が切断され、システムが事実上互いに通信できない孤立したグループに分割されることです。ネットワーク分割耐性のあるシステムは、これらのネットワーク障害が発生しても、運用および機能を継続します。最新の分散システムでは、ネットワーク分割は避けられない現実であるため、ネットワーク分割耐性はほぼ*常に*必要です。 ### なぜ2つしか保証できないのか CAP定理の核心は、ネットワーク分割が発生した場合に何が起こるかということです。真に分散されたシステムではネットワーク障害は避けられないため（つまり、ネットワーク分割耐性は*必須*です）、このようなイベント中に直面する実際の選択は、整合性と可用性のどちらかになります。 データストアが互いに通信できない2つのサーバーグループに分割されたとしましょう。ここで、ユーザーがグループAのサーバーに新しいデータを書き込もうとし、別のユーザーがグループBのサーバーから同じデータを読み取ろうとします。 * **整合性を優先する場合（CPシステム）:** グループBのユーザーが古いデータを読み取らないようにするために、システムは、グループAと通信して最新バージョンを持っていることを確認できるまで、グループBのサーバーはそれらのデータに対する読み取りリクエストに応答できないと判断するかもしれません。これは、パーティションが修復されるまで、グループBはその特定のデータに対して*利用できなくなる*ことを意味します。整合性は維持されますが、可用性は犠牲になります。 * **可用性を優先する場合（APシステム）:** グループBのユーザーが常に応答を得られるようにするために、グループBのサーバーは、グループAと同期できていないことを知っていても、持っているデータを返すかもしれません。これは、グループBのユーザーが、グループAのユーザーがちょうど書き込んだデータよりもわずかに古いデータを受け取る可能性があることを意味します。可用性は維持されますが、即時の整合性は犠牲になります（パーティションが修復されれば整合性が取れるようになる「結果整合性」が得られます）。 ### 分かりやすい例え：ATMが2台ある銀行 あなたの銀行口座に接続された2台のATM、ATM AとATM Bがある銀行を想像してください。中央銀行システムがあなたの実際の残高を追跡しています。 * **整合性:** ATM Aで100ドルを引き出した場合、すぐにATM Bで残高を確認すると、即座に100ドル少ない残高が表示されます。 * **可用性:** 両方のATMは常に機能しており、取引を実行できます。 * **ネットワーク分割耐性:** ATM Aが中央銀行（またはATM B）に接続されているネットワークケーブルが切断された場合でも、ATM Aは独立して動作できます。 さて、ATM Aへのネットワークケーブルが切断された場合（パーティション）のトレードオフを見てみましょう。 * **整合性の優先（CP）:** ATM Aで現金を引き出そうとすると、「サービス停止中」または「取引不可」というメッセージが表示されるかもしれません。なぜなら、中央銀行と通信して現在の残高を確認し、口座超過を防ぐことができないからです。処理する取引が中央記録と完全に整合していることを保証するために、可用性を犠牲にします。 * **可用性の優先（AP）:** ATM Aで現金を引き出そうとすると、中央銀行と確認できなくても、最後に知っている残高に基づいて引き出しが許可されるかもしれません。これは利用可能ですが、リスクがあります。口座が超過する可能性があります。または、中央銀行の記録が一時的にATM Aの記録と異なる可能性があります。ネットワーク接続が復旧すると、システムは残高を照合しますが、一時的に不整合が生じます。 ### CAP定理のトレードオフに関する実際の例 1. **CPシステム例：従来のRDBMS（例：PostgreSQL、MySQL）を強力な整合性設定で使用する場合、または金融取引システム。** * **選択:** これらのシステムは、整合性とネットワーク分割耐性を優先します。ネットワーク分割が発生した場合、すべてのデータが完全に整合していることを保証するために、システムの С части を利用不可にする場合があります。サーバーが最新のデータを持っていることを確認できない場合、データを提供しません。 * **エンドユーザーへの影響:** ネットワークの問題やサーバー障害中に、ユーザーは一時的な遅延や一時的な「システム利用不可」メッセージを経験する可能性があります。例えば、銀行振込を完了しようとしているときにシステムがパーティションを経験している場合、取引は保留または失敗する可能性がありますが、口座残高が常に正確であり、矛盾する値が表示されないことが保証されます。これは、データの整合性が最優先されるアプリケーションにとって不可欠です。 2. **APシステム例：ソーシャルメディアフィード（例：Facebook、Twitter）またはEコマースのショッピングカート（例：Amazon DynamoDBはしばしば結果整合性で設定される）。** * **選択:** これらのシステムは、可用性とネットワーク分割耐性を優先します。ネットワーク分割が発生した場合、一部のユーザーが一時的にわずかに古い情報を見る可能性があるとしても、リクエストの提供を継続します。それらは「結果整合性」を目指しており、パーティションが解決されるとデータは時間とともに整合性が取れるようになります。 * **エンドユーザーへの影響:** ユーザーはほぼ常に応答を得られます。例えば、ソーシャルメディアで投稿を更新した場合、特にネットワークの不具合がある場合、すべてのフォロワーが見るのに数秒または数分かかることがあります。同様に、Amazonのカートに商品を追加した場合、売り切れたばかりでも一時的に利用可能と表示される可能性があります。または、別のデバイスから追加した商品がすぐにカートに反映されない場合があります。システムは、サービスを稼働させ応答性を維持することを優先し、一時的な不整合はより良いユーザーエクスペリエンスのために許容できると受け入れます。 ### 今後のアーキテクチャ会議のための質問 この理解に基づいて、アーキテクチャ会議で尋ねるべき重要な質問をいくつか示します。 * **当社のビジネスにとって、どの特定のデータ型または操作で強力な整合性が絶対に不可欠ですか？** （例：金融取引、在庫数、ユーザー認証）。どの不整合も許容できないのはどこですか？ * **どのデータ型または操作で、結果整合性または一時的な古いデータを許容できますか？** （例：ユーザープロフィールの更新、レコメンデーションエンジン、分析データ）。即時整合性よりも可用性が重要なのはどこですか？ * **コアユーザーフローにおける一時的な利用不可と一時的な不整合のビジネスへの影響は何ですか？** それぞれの選択は、ユーザーエクスペリエンス、収益、信頼にどのように影響しますか？ * **可用性と結果整合性を優先する場合、必然的に発生するデータ競合を処理および解決するための戦略は何ですか？** データが最終的に正しく収束することをどのように保証しますか？ * **さまざまな種類のネットワーク分割に対する予想される復旧時間と戦略は何ですか？** イベント後に完全な整合性をどのくらいの速さで復旧できますか？ * **分散データストアの整合性と可用性をどのように監視しますか？** ビジネス要件を満たしていることを確認するために、どのようなメトリックを追跡しますか？ CAP定理を理解することは、「最良の」オプションを選択することではなく、ビジネスニーズとユーザーの期待に沿った情報に基づいたトレードオフを行うことです。これらのトレードオフに関するあなたの意見は非常に貴重です。

分散システムへの移行に関するアーキテクチャの議論に入る場合、CAP定理は最も役立つ思考モデルの1つです。要点は次のとおりです。分散システムがネットワークの問題によって分割された場合、通常は、データをすべての場所で完全に同期させるか、システム全体を応答可能に保つかのどちらかを選択する必要があります。両方の保証を同時に得ることはできません。 実用的な考え方を以下に示します。 分散データストアとは、データが単一の場所に正確に存在しなくなることを意味します。複数のマシン、データセンター、またはクラウドリージョンに複製される場合があります。これにより、スケーラビリティと耐障害性が得られますが、新たな現実も生じます。それは、それらのマシンが互いに確実に通信できない場合があるということです。ネットワークは完璧ではありません。メッセージは遅延したり、失われたり、ブロックされたりする可能性があります。CAPは、それらの瞬間にシステムが何をするかということです。 実際的な意味での一貫性とは、ユーザーがどのレプリカまたはノードにアクセスしても、データの一部に対して常に同じ最新の回答を見ることができることを意味します。顧客が配送先住所を変更し、すぐにページを更新したり、別のデバイスでアプリを開いたりした場合、一貫性とは、すべての場所で新しい住所がすぐに表示されることを意味します。あるサーバーが古いと述べ、別のサーバーが新しいと述べる期間はありません。製品の意思決定において、一貫性とは、人々が古い情報や矛盾した情報を見てもビジネスが許容できるかどうかということです。 実際的な意味での可用性とは、システムの一部が問題を抱えている場合でも、システムがリクエストに応答し続けることを意味します。ユーザーはタイムアウトやエラーではなく、応答を受け取ります。たとえば、買い物客がカートに商品を追加した場合、利用可能なシステムは、1つのリージョンまたは1つのレプリカが到達不能であっても、アクションを受け入れて使用可能なものを返します。製品チームにとって、可用性とは、返されるデータが最新ではない可能性がある場合でも、ユーザーエクスペリエンスをあらゆるコストで維持する必要があるかどうかということです。 実際的な意味でのパーティション耐性とは、システムの部分間のネットワーク障害にもかかわらず、システムが動作し続けることを意味します。パーティションは必ずしも劇的な障害ではありません。それは、あるサーバーグループが別のグループと確実に連携できない、あらゆる通信の破綻であり得ます。分散システムでは、この問題から本当に逃れることはできません。異なるゾーンまたはリージョンにマシンがある場合、パーティションは現実です。したがって、パーティション耐性は、選択する機能というよりも、設計で考慮する必要がある条件です。 これが、人々がCAPは実際にはパーティションが発生したときの整合性と可用性の間のトレードオフについてであると言う理由です。通常の運用では、多くのシステムが両方を提供できます。ネットワークが信頼できず、レプリカが安全に連携できない場合に、痛みを伴う選択が現れます。 なぜ同時にすべてを保証できないのですか？データベースの2つのレプリカ、1つはニューヨーク、もう1つはダブリンにあると想像してください。ネットワークの問題が突然、それらが互いに通信できなくさせました。今、顧客はニューヨークでアカウントを更新しましたが、別のリクエストがダブリンからそのアカウントを読み取ります。 一貫性を優先する場合、ダブリン側は、おそらく古いデータで応答することを避ける必要があります。最新の状態を確認できるまで、その読み取りを遅延、拒否、またはエラーにする必要があるかもしれません。これにより、単一の正しい回答が維持されますが、一部のリクエストが成功しないため、可用性が低下します。 可用性を優先する場合、ダブリンはニューヨークと確認できないにもかかわらず、応答し続ける必要があります。古いデータを返したり、後で調整が必要な書き込みを受け入れたりする可能性があります。これにより、製品は応答性を維持しますが、異なるユーザーが異なる真実を見る可能性があるため、一貫性は一時的に弱まります。 トレードオフの背後にある力は単純です。サーバーが通信できない場合、リアルタイムでグローバルに正しい決定を下していることを互いに確実に知ることはできません。調整を待ってダウンタイムのリスクを冒すか、リクエストを処理し続けて分岐のリスクを冒すかのどちらかです。 記憶に残るアナロジーは、ギフトカード残高を共有するコーヒーショップのチェーンです。残高が2つの支店に保存されており、それらの間のインターネット接続がダウンしたとします。 障害中に両方の支店が同じギフトカードの受け入れを続けた場合、顧客は同じお金を2回使う可能性があります。それは高い可用性、低い一貫性です。 支店が接続が復旧するまでギフトカードの使用を拒否した場合、過剰な支出を防ぐことができます。それはより高い一貫性、低い可用性です。 そして、これがすべて問題になる理由は、支店がパーティションされていることです。それらは通信できません。 このアナロジーはうまく機能します。なぜなら、ビジネス上の質問が明白になるからです。障害中に私たちと顧客にとってより悪いのは、一時的に取引を拒否することか、後でクリーンアップする矛盾した状態を一時的に許可することか？ それでは、実際の例で具体的に見ていきましょう。 1つの例は、プライマリ-レプリカ設定で展開され、重要な書き込みに対してプライマリで強力な一貫性を備えた従来のRDBMSです。銀行、支払い、在庫予約、または注文配置に使用されるシステムを考えてみてください。システムが現在の残高または在庫数を安全に確認できない場合、二重請求や売り切れのリスクを避けるために、トランザクションを拒否または遅延させる可能性があります。CAPの観点から、パーティション中にこれらのシステムは、重要な操作に対して可用性よりも一貫性を重視する傾向があります。エンドユーザーにとっては、障害中に「後でもう一度お試しください」のようなエラーが表示される可能性がありますが、マイナスの残高や、2人が最後の席を購入するなどの不可能な状態を見る可能性は低くなります。 2番目の例はDNS、ドメイン名をIPアドレスにマッピングするシステムです。DNSは高度に分散されており、グローバルに応答性を維持するように設計されています。変更は時間とともに伝播し、キャッシュとタイミングに応じて異なるユーザーが一時的に異なる回答を受け取る可能性があります。これは、即時の一貫性よりも可用性とパーティション耐性を優先することを意味します。エンドユーザーにとっては、通常、ウェブサイトはほとんどの時間アクセス可能ですが、最近のDNS変更がすべてに反映されるには時間がかかる場合があります。 3番目の例はAmazon Dynamoスタイルのシステムと、その設計に触発された多くのショッピングカートまたはセッションストアです。これらのシステムは、ネットワークの問題が発生した場合でも稼働し続けるように構築されており、多くの場合、複数の場所で書き込みを受け入れ、後で調整します。リクエストの損失が、わずかに古いデータを一時的に表示することよりも悪い場合に適しています。エンドユーザーにとっては、インフラストラクチャの問題が発生した場合でも、カートの更新がすぐに成功する可能性がありますが、エッジケースでは、カートの古いバージョンが一時的に表示されたり、システムが後で解決する重複/矛盾したアイテムに遭遇したりする可能性があります。 4番目の例は、Google Spannerや分散SQLデータベースなどのシステムで、分散ノード全体で強力な一貫性を提供するために調整に多大な投資を行っています。これらは、よりデータベースのようなプログラミングモデルを提供できますが、特定の障害が発生した場合、不確かな結果を返すのではなく、一部の操作をブロックまたは失敗させることを選択する場合があります。エンドユーザーにとっては、これは多くの場合、より予測可能な正確さを意味しますが、特定の障害シナリオでは、レイテンシが高くなったり、書き込み可用性が低下したりする可能性があります。 重要な製品の教訓は、普遍的に最良のCAPの選択肢はないということです。正しい答えは、あなたが顧客に約束していることに依存します。 支払い台帳を構築している場合、一貫性は多くの場合、常にリクエストを受け入れることよりも重要です。二重請求のリスクを避けるために、ユーザーに「現時点では処理できません」と伝える方が、通常は良いです。 ソーシャルフィード、レコメンデーションサービス、分析ダッシュボード、またはショッピングカートを構築している場合、可用性の方が重要になる場合があります。ユーザーは、アプリが高速で使いやすいままであれば、短い時間、わずかに古いデータを見ても許容することがよくあります。 また、同じ製品でも、アクションごとに異なるトレードオフを選択する場合があります。小売プラットフォームは、在庫予約と支払いキャプチャに対して強力な一貫性を必要とする場合がありますが、製品ビュー、レコメンデーション、およびレビューカウントに対しては最終的な一貫性を許可する場合があります。CAPは会社全体の1つの決定ではなく、ワークフローごとの一連の決定であることがよくあります。 これで、会議で最も役立つ部分、つまり尋ねるべきことに入ります。 まず、どのユーザーアクションが絶対に正確で最新のデータを必要とし、どのデータが遅延または陳腐化を許容できるかを尋ねます。言い換えれば、「間違っているが応答性がある」のはどこで許容され、どこで許容されないのか？ 次に、ネットワークパーティションまたはリージョン障害が発生した場合に何が起こるかを尋ねます。書き込みは拒否されるか、キューに入れられるか、ローカルで受け入れられて後で調整されるか？これは、図だけでなく、実際の運用動作を明らかにします。 3番目に、ユーザーが実際にどのような不整合を見る可能性があるかを尋ねます。古い残高、重複した通知、在庫があるように見えるが実際にはないアイテム、または一方の画面には表示されるがもう一方の画面には表示されないプロファイル更新などを見る可能性がありますか？製品の意思決定は、これらの具体的な障害モードに依存します。 4番目に、不整合がどれくらいの期間続く可能性があるかを尋ねます。数秒、数分、数時間？「最終的に一貫性がある」だけでは曖昧すぎます。許容できるウィンドウは機能によって異なります。 5番目に、どのビジネスリスクが最も重要か（ダウンタイムによる売上損失、混乱したデータによるサポート負荷、不正確な記録による法的/コンプライアンスリスク、または二重処理による財務損失）を尋ねます。CAPのトレードオフは、ビジネスインパクトに関連付ける必要があります。 6番目に、システムの異なる部分が異なる一貫性モデルを使用できるかどうかを尋ねます。多くの場合、答えは「はい」であるべきです。これは、すべてを最も厳格な要件に過剰に設計することを避けるのに役立ちます。 7番目に、システムがパーティション中に書き込みを受け入れた場合、競合がどのように解決されるかを尋ねます。2つのリージョンが同じレコードを異なる方法で更新した場合のルールは何ですか？最後に書き込まれたものが勝ちますか？マージしますか？手動レビューですか？隠された競合解決ルールは、悪いユーザーエクスペリエンスを生み出す可能性があります。 8番目に、障害シナリオでのフォールバックユーザーエクスペリエンスを尋ねます。システムが可用性よりも一貫性を選択した場合、ユーザーはどのようなエラーまたはリトライパターンを目にしますか？可用性よりも一貫性を選択した場合、一時的な不確実性をどのように伝えますか？ 9番目に、どのようなオブザーバビリティが存在するかを尋ねます。システムがパーティションされていること、レプリカが遅延していること、ユーザーが古いデータを見ていることをどのように知ることができますか？製品チームとサポートチームは、これに対する可視性が必要です。 10番目に、規制または契約上の要件により、支払い、ID、監査証跡、または同意記録などの特定のデータ型に対して、より強力な一貫性が強制されるかどうかを尋ねます。 会議に持ち込む1つの文が必要な場合は、これを使用してください。「CAPは好きなバズワードを選ぶことではなく、ネットワークが信頼できないためにシステムのパーツが合意できない場合に製品がどうすべきかを決定することです。」 優れたプロダクトマネージャーは、「CPまたはAPですか？」と抽象的なラベルとして尋ねることはありません。より良い質問は、「重要な各ユーザーワークフローについて、システムがストレス下にあるとき、アクションをブロックするか、古いまたは矛盾したデータを表示/受け入れるリスクを冒すか、そしてなぜですか？」です。 CAPがアーキテクチャの意思決定に役立つのはそのレベルです。理論的な定理を、正確さ、稼働時間、ユーザーの信頼、およびビジネスリスクに関する製品トレードオフの会話に変えます。