【マイクロサービス入門】CAP定理 とはなんぞや？🔰
はじめに
こんにちは、Takeです。都内の自社開発企業でエンジニアとして働いています。
この記事では、マイクロサービスを理解する上で重要なキーワードに焦点を当て、学びを共有できればと思いコンパクトにまとめてみました。
目的
- CAP定理について理解すること
CAP定理とは
マイクロサービスを使用して構築されるような分散システムでは、すべての機能や特性を完全に満たすことは不可能で、必ずトレードオフが発生します。CAP定理は、分散システムにおいて互いにトレードオフとなる3つの特性があることを示しており、故障モードでは、この3つのうち2つを選択することしかできないことを示します。
- Consistency（一貫性）: どのノードにアクセスしても同じデータが返ってくることを保証します。
- Availability（可用性）: すべてのリクエストがレスポンスを受け取ることを保証します（システムが常に稼働しており、適切なレスポンスを返すこと）。
- Partition Tolerance（分断耐性）: ネットワークの一部が切断されても、システム全体が動作し続けることを保証します。
APシステム = Consistency（一貫性）を犠牲にする場合
システムはネットワーク分断が発生しても動作し続け、リクエストに応答しますが、一貫性が犠牲になることがあります。
CPシステム = Availability（可用性）を犠牲にする場合
システムはネットワーク分断が発生しても一貫性を維持しますが、可用性が低下し、リクエストに応答できなくなることがあります。
CAシステム = Partition Tolerance（分断耐性）を犠牲にする場合
システムは一貫性と可用性を維持しますが、ネットワーク分断が発生するとシステム全体が停止します。つまり、ローカルで動作する単一プロセスになるため、現実的にCAシステムは分散システムでは存在しません。
ここまでまとめると、現実的にはAPシステムかCPシステムの2択に絞られます。
APシステムかCPシステムか
結論として、状況次第です。
例えば、ECショッピングサイトではAPシステムが適しています。レコードが5分間犠牲になっても大きな問題にはならず、ユーザーが商品を閲覧して購入できることの方が重要です。その一方で、銀行システムでは振替などによる口座残高を最新に保つ必要があるため、CPシステムを選択する可能性が高いです。
まとめ
システム全体としてAPかCPのどちらかである必要はなく、機能ごとに使い分けることが重要です。また、さらに細かいトレードオフを考慮する場合、Cassandraのようなデータベースシステムでは、呼び出しごとに異なるトレードオフを選択することができます。
そのため、システム設計時にはCAP定理を理解し、どの特性を優先するかを慎重に検討することが求められます。
参考
書籍11章「大規模なマイクロサービス」より
Discussion