What is CAP Theorem
분산 시스템을 설계할 때에는 CAP 정리를 이해하고 있어야 한다. CAP 정리는 일관성(Consistency), 가용성(Availability), 파티션 감내(Partition Tolerance)라는 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것을 불가능하다는 정리다. 우선 각 요구사항의 의미부터 명확히 정리하고 넘어가자.
- 일관성 Consistency : 분산 시스템에 접속하는 모든 클라이언트는 어떤 노드에 접속했느냐에 관계없이 언제나 같은 데이터를 보게 되어야 한다.
- 가용성 Availability : 분산 시스템에 접속하는 클라이언트는 일부 노드에 장애가 발생하더라도 항상 응답을 받을 수 있어야 한다.
- 파티션 감내 Partion Tolerance : 파티션은 두 노드 사이에 통신 장애가 발생하였음을 의미한다. 파티션 감내는 네트워크 파티션이 생기더라도 시스템은 계속 동작해야한다는 것이다.
CAP를 모두 만족할 수 있는 시스템은 존재하지 않기 때문에 CA, AP, CP 시스템 중에서 하나를 선택해야한다. 그런데 통산 네트워크 장애는 피할 수 없는 일로 여겨지므로, 분산 시스템은 반드시 파티션 문제를 감내할 수 있도록 설계되어야 한다. 따라서 실세계에 CA 시스템은 존재하지 않는다. 세상에는 CP, AP 시스템만 존재한다. CP, AP 시스템을 괜히 한 번 더 짚어보자.
- CP : 일관성과 파티션 감내를 지원하는 시스템. 가용성을 희생한다.
- AP : 가용성과 파티션 감내를 지원하는 시스템. 일관성을 희생한다.
실세계의 분산 시스템
Consistency와 Availability 모두 중요해보이기 때문에 둘 중 하나를 포기한다는 것이 어떤 의미인지 잘 와닿지 않는다. 구체적인 예시를 들어서 어떻게 접근해야하는지 머릿속에 각인시켜보자.

이상적인 환경이라면 네트워크가 파티션되는 상황은 절대로 일어나지 않는다. Node A에 Write된 데이터는 Node B, Node C에 자동으로 복제된다. Consistency와 Availability 모두 만족한다.

분산 시스템은 파티션 문제를 피할 수 없다. Node C에 장애가 발생하여 Node A, Node B와 통신할 수 없는 상황을 생각해보자. 여기서 주의할 점은 Node C 자체적으로는 문제가 없지만 Node A, Node B와의 네트워크 단절이 발생했다는 점이다. 그래서 Node C에서도 Client의 요청을 받아서 새로운 데이터를 Write할 수 있는 상황이다. 네트워크 파티션으로 인해 Node C에 저장된 데이터는 Node A, Node B에 저장되지 않는다. 상대적으로 Node A, Node B에는 오래된 데이터가 존재한다고 볼 수 있다.
뱅킹 시스템과 같이 Consistency를 양보할 수 없는 상황에서는 Write 연산을 중단시켜야 한다. Node A와 Node B 사이에는 정상적인 네트워크가 가능하지만 Node C에 문제가 생겼기 때문에 Node A와 Node B에 대한 Write도 중단해야 한다. 만약 네트워크 파티션을 감지하고 Node C로의 모든 Client의 연결이 중단되는 것이 보장된다면 Node A, Node B에 대해서만 Write를 수행하고 이후에 Node C가 정상화되었을 때 Node A, Node B로부터 데이터를 복구할 수도 있다. 중요한 점은 일부 Node가 아닌 정상 Node 전체에 대해서 Consistency를 보장해야한다는 것이다. 정상 Node의 범위를 명확히 보장할 수 없다면 시스템 전체가 정상화될 때까지 Write를 중단해야한다.
추천, 뉴스 피드, 리더 보드처럼 Consistency보다 Availability가 더 중요한 경우는 오래된 데이터를 반환할 위험이 있더라도 계속 READ 연산을 보장해야 한다. Node A, Node B에는 계속 Write 연산이 수행될 것이고 네트워크 파티션 문제가 해결된 이후에 Node C에 최신 데이터가 전송될 것이다.
결론
Consistency와 Availability 중에서 어떤 것을 선택할지의 문제는 시스템의 요구사항에 따라서 비교적 단순해 보일 수 있지만
구현의 관점에서 어디까지 어떻게 고려해야할지의 문제는 단순하지가 않다. 그래서 가능한 많은 Design System의 사례를 공부하고 시야를 넓혀야 한다. 다음 포스팅에서는 Google File System에서 이러한 접근법을 어떠게 다루는지를 간단하게 소개를 해보려고 한다.
Reference
가상 면접 사례로 배우는 대규모 시스템 설계 기초 93~96 page
'DEV > System Design' 카테고리의 다른 글
처리율 제한 장치, Rate Limiter (0) | 2025.05.04 |
---|---|
Google File System 뜯어보기 - Memory Mapped I/O (0) | 2025.04.24 |
Google File System 리뷰 (1) | 2025.04.20 |
개략적인 규모 추정 :: 숫자에 대한 감 잡기 (0) | 2025.04.12 |
CAP Theorem in Google File System (0) | 2025.04.12 |