Mekal Z

Mekal Z

A programmer running out of the wall.
twitter

システム設計の面接におけるCAP定理

CAP 定理は、システム設計の面接で理解する必要のある重要なデータベースの概念です。CAP は、一貫性(Consistency)、可用性(Availability)、およびパーティション耐性(Partition Tolerance)を表し、それによって CAP 定理という名前が付けられています。
id:: 63eb007d-e404-4950-aa61-3e20077a5856

  • 一貫性は、すべてのユーザーが同じデータを同時に見ることができることを指します。
  • 可用性は、ノードの障害が発生しても、システムが常に読み取りまたは書き込みに使用できることを意味します。
  • パーティション耐性は、ノード間の通信が失敗してもシステムが動作し続けることを意味します。
  • この定理では、これらの 3 つの特性のうちの 2 つしか分散システムで保証できないと述べています。
  • 私たちが行っている仮定は、ネットワークの分割が発生するということです。したがって、信頼性のあるサービスを提供するためには、パーティション耐性が必要です。したがって、CAP の P を犠牲にすることはできません。これにより、一貫性と可用性の間でトレードオフをする必要があります。
    id:: 63eb0459-f049-4ba1-9ce7-5449b9144de8
  • 一貫性
    • 一貫性は、書き込みがデータベースに送信された後、任意のノードに送信されるすべての読み取りリクエストが更新されたデータを返すという特性です。
    • ネットワークの分割がある場合、ノード A とノード B の両方がそれらに送信された書き込みリクエストを拒否するシナリオを想像してください。これにより、それらの 2 つのノードのデータの状態が同じになります。それ以外の場合、ノード A には更新されたデータがあり、ノード B には古いデータがあります。
    • 時々、「強い一貫性」という用語を耳にします。CAP 定理の一貫性は、必ずしも強い一貫性を指すわけではありません。強力に一貫性のあるデータベースでは、データが書き込まれた後、直ちに読み取られると、理論的には常に更新されたデータが返されるはずです。
    • ただし、分散システムでは、ネットワーク通信は即座には行われないため、ノードは物理的に互いに分離されており、データの転送にはある程度の時間がかかります。
    • これが、完全に強力に一貫性のある分散データベースを持つことができない理由です。
      id:: 63eb08ce-93b6-45b2-84c7-252f2d2afee3
  • 現実世界では、一貫性を重視するデータベースについて話すとき、通常はノード間の非常に短い気づかれない遅延時間で最終的に一貫性があるデータベースを指します。
    id:: 63eb0a3e-118c-4dae-8d3e-fca205c2f385
  • したがって、再度要約すると、CAP 定理における一貫性とは、すべてのユーザーが同じデータを同時に見ることができることを意味します。
  • 可用性
    • 可用性を重視するデータベースでは、ノード間でデータが一貫していない場合があります。1 つのノードには古いデータが含まれ、別のノードにはより新しいデータが含まれる場合があります。
    • 可用性とは、リクエストを送信されたノードが優先的に完了することを意味します。利用可能なデータベースは、ネットワークの分割が解消された後、すべてのノードが最終的に互いに同期して同じ更新されたデータを持つようになるという意味です。この場合、ノード A は最初に更新を受け取り、しばらくするとノード B も更新されます。
  • 一貫性または可用性?
    • 一貫性または可用性を優先すべきタイミングはいつでしょうか?最新のデータである必要があるデータを扱っている場合は、一貫性を優先する必要があります。一方、クエリされたデータがわずかに古くても問題ない場合は、利用可能なデータベースに保存することがより良い選択肢となります。
    • 理解を深めるために、いくつかの例を挙げましょう。
      • Amazon のようなアプリを構築していると想像してください。ショッパーは製品のカタログを閲覧し、在庫があれば購入することができます。製品が実際に在庫にあることを確認したいので、利用可能なデータベースが一貫性を優先すべきかどうかを考えてみましょう。
      • 製品情報を保存するデータベースは、一貫性を優先すべきです。ネットワークの分割が発生し、ノードが互いに同期できない場合、1 つの商品が 1 つしかないのに 2 人以上のショッパーが同じ商品を購入することを許可したくありません。
      • 利用可能なデータベースでは、後者が許可され、少なくとも 1 人のショッパーの注文がキャンセルされるか返金される必要があります。
      • 別のシナリオを想像してみましょう。同じ Amazon のような製品で、PM がネットワークの障害が発生した場合に在庫切れと表示するよりも、ショッパーに返金する方が費用効果が高いと判断した場合。この場合、ネットワークの障害が発生した場合でも、製品を購入できないよりも注文をキャンセルして返金することを優先する必要があります。
        id:: 63eb1f8c-43d8-40a2-94fa-9fc99a458545
  • 上記の議論からわかるように、ここでは書き込みリクエストのみが議論されています。これは、読み取りリクエストはデータの状態を変更せず、ノード間の再同期も必要としないためです。一貫性と可用性の両方のデータベースにとって、ネットワークの分割中には通常、読み取りリクエストは問題ありません。
読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。