NoSQL CAP 이론
① Overview
CAP 이론은 분산형 구조에서 나타나는 세 가지 특징 중 두 가지만 만족할 수 있다는 이론이다.
Consistency (일관성)
- 분산 노드 중 어떤 노드로 접근하여도 동일한 데이터 값을 읽도록 보장한다.
- RDBMS 는 Consistency 를 보장한다.
- Strong Consistency 를 보장하는 대신 Eventually Consistency (or Weak Consistency)를 보장하는 방향으로 trade-off 하는 방법도 있다.
Availability (가용성)
- 분산 노드 중 어떤 노드가 다운 상태여도 정상적인 요청 처리를 보장하여 서비스를 이용할 수 있다. 쉽게 말하면, 모든 노드는 항상 읽기와 쓰기를 할 수 있어야한다.
- 가용성이 있다 vs 없다
- 어떤 노드에 장애가 발생하여 정상적인 서비스를 할 수 없다면 가용성이 없다고 할 수 있다.
- 가용성이 높다 vs 낮다
- 서비스 이용할 수 있느냐 없느냐 관점으로 생각해보면, 처리(응답) 시간이 10초 또는 1분 이상이 걸린다면 사용자가 서비스를 정상적으로 이용할 수 있을까? 서비스에 따라 다르겠지만, 이러한 처리(응답) 속도에 따라 가용성이 낮다, 높다로 표현할 수 있다.
- 가용성이 높다 → 요청에 대한 응답 시간이 빠르다.
- 가용성이 낮다 → 요청에 대한 응답 시간이 느리다.
- 서비스 이용할 수 있느냐 없느냐 관점으로 생각해보면, 처리(응답) 시간이 10초 또는 1분 이상이 걸린다면 사용자가 서비스를 정상적으로 이용할 수 있을까? 서비스에 따라 다르겠지만, 이러한 처리(응답) 속도에 따라 가용성이 낮다, 높다로 표현할 수 있다.
Partitioning Tolerance (분산 내구성)
- 클러스터링 노드간 통신 중 네트워크 장애가 발생하여도 정상적인 서비스를 보장한다.
- (노드의 장애가 아닌 네트워크 장애를 말하는 것)
- (물리적으로 다른 서버에 있더라도)
- Partitioning Tolerance 를 지원한다 vs 안한다
- 지원 : P 를 지원한다는 것은 네트워크 장애에 대한 대책이 세워져 있는 것
- 미지원 : 반대로 P 를 지원하지 않는 것은 네트워크 장애에 대한 대책이 없는 것 → 네트워크 장애가 나지 않도록 시스템을 구성해야함 → 현실적으로 분산 구조에서 불가능한 구조
② Trade-off 🤔
- 처음 말한것 처럼 CAP 이론은 세 가지를 모두 만족시킬 수 없고 두 가지만 만족시킬 수 있다. 어느 하나를 포기할지는 운영하는 서비스에 따라 무엇이 중요한지 고민하여 결정해야한다.
- 그런데 CAP 는 모두 동등하게 trade-off 관계에 있지 않고 Consistency 와 Availability 가 trade-off 관계에 있고, Partitioning-Tolerance 는 별도의 특징이라고 볼 수 있다. 그리고 대부분 NoSQL 은 분산 구조로 설계되어 있기 때문에 P 는 필수인 것 같다.
Consistency vs Avaliability
- 분산 구조에서 데이터의 Consistency 를 위해서는 노드간 데이터 복제가 필요한데, 복제에 드는 시간이 0이 될 수는 없다. 복제를 위한 지연 시간이 늘어날수록 사용자가 일관성(Consistency)있는 데이터를 조회하는데 걸리는 시간이 길어지면서 서비스 가용성(Availability)은 떨어진다.
- 반면 데이터 일관성을 포기하면 사용자에게 아직 복제되지 않아 업데이트되지 않은 값을 보여줘도 된다. 요청에 대해 즉시 처리해줄 수 있어 가용성을 더욱 확보할 수 있다.
- 즉, 일관성과 가용성은 trade-off 관계에 놓이게 된다.
Eventual Consistency (최종 일관성) - Wikipedia
- 최종 일관성은 고 가용성을 달성하기 위해 분산 컴퓨팅에서 사용하는 일관성 모델이다. 만약 지정한 데이터 항목에 대한 새로운 업데이트가 없다면, 해당 항목에 대한 정보는 다른 노드로 언젠가 복제되어 모든 요청이 마지막으로 업데이트 된 값(동일한 값)을 반환한다.
- Optimistic replication 으로도 불린다.
- RDBMS 의 ACID 와 대조된다. ACID 는 제약조건을 가지고 엄격하게 일관성을 지키는 반면, Eventually Consistency 는 즉시 일관성을 지키지 못해도 언젠가 복제 노드들도 동일한 값으로 업데이트된다는 것이다.
martinfowler - eventual consistency
-
파틴파울러가 microservice 와 관련하여 단점 중 하나로 eventual consistency 를 말하고 있다. 하지만 비즈니스 프로세스의 경우에 따라 불일치에 관대한 경우가 있다. 그리고 종종 일관성보다 가용성이 더 중요한 경우가 생긴다. 이때 일관성을 약간 내어주고 고 가용성을 얻을 수 있다.
(원문) Business processes are often more tolerant of inconsistencies than you think, because businesses often prize availability more.
③ CAP 에 따른 NoSQL 분류
AP
- DynamoDB, Cassandra
- DynamoDB 의 경우 Strongly consistent 를 설정할 수 있는데, 이 경우 CP 가 된다.
CP
- MongoDB, Redis, HBase
CA
- RDBMS
- 대부분의 RDBMS 는 애초에 분산 구조를 고려하여 설계하지 않았기 때문에 CA 에 초점이 맞춰져 있다.
④ 읽어보면 좋은 자료 👍🏻
- Outsider’s Dev Story - NoSQL에 대하여 #1
- NoSQL 이 왜 등장했고, 왜 CAP 중 P 가 필수인지, 왜 비관계형인지
- 단순 이론보다 Why? 에 대한 대답을 쉽게 설명하여 처음 NoSQL 을 이해하는데 도움이 된다.
- CAP Theorem, 오해와 진실
- CAP 이론의 헛점과 애매한 부분을 설명해준다. 그리고 그 대안 PACELC 를 설명해준다.