-
Notifications
You must be signed in to change notification settings - Fork 0
Description
6장
CAP 정리 관련(94p)
내 질문 : 책에서 CA는 존재하지 않는다고 하는데, 인터넷을 찾아보면 CA는 RDB라고 많이 함 왜그럴까?
분산 시스템에 관련된 NoSQL에 한해서 나오는 CA는 불가능하다고 하는 건가?
...
실제로는 CA 분산 데이터베이스가 존재할 수 없습니다.
많은 관계형 데이터베이스는 일관성과 가용성을 제공, 복제를 사용하여 여러 노드에 배포
[출처. IBM - CAP 정리](https://www.ibm.com/kr-ko/topics/cap-theorem)
CAP 정리의 일관성과 ACID의 일관성은 의미가 다르다
CAP 이론의 일관성과 ACID의 일관성은 의미가 상당히 다르다. ACID의 일관성은 트랜잭션의 일관성을 의미한다. 트랜잭션은 데이터베이스의 제약 조건(고유성 제약 조건, 참조 무결성 등)을 위반하지 않고 상태를 유효한 상태에서 또 다른 유효한 상태로 변경한다. 그에 반해 CAP 이론의 일관성은 연산의 원자성(작업 전체가 성공하거나 실패한다)과 일관성(어떤 작업도 데이터를 일관되지 않은 상태로 방치하지 않는다)을 의미한다.
– 데이터베이스 인터널스. 11장. 277쪽.
CAP Theorem, 오해와 진실
RDBMS에 CAP를 적용하여 CA로 분류하는 것을 자주 보았다. Brewer가 처음 발표할때에도 이렇게 표현을 하기도 했고, 하나의 인스턴스로 운영되는 RDBMS의 경우 네트워크로 연결되어 있지 않으므로 네트워크 단절을 배제할 수 있다는 점에서 이렇게 분류하는게 어느 정도 납득은 간다. 하지만 CAP는 분산시스템이 전제조건이고 따라서 RDBMS에 CAP를 적용하는 것은 맞지 않다. 굳이 적용하기 위해 CAP정리를 다음과 같은 명제식으로 바꾸어 본다고 하자.
p: 시스템이 분산시스템이다.
q: C,A,P 모두 만족 시킬 수 없다.
p->q
애초에 CAP Theorem이 의도했던바는 명확하다. 절대로 장애가 없는 네트워크는 존재하지 않으며, 따라서 분산시스템에서 P는 무조건 인정하고 들어가야 한다는 것이다. 따라서 네트워크가 단절되었을 때 시스템이 어떻게 동작할지 결정해야 하며, 이 때 C와 A를 모두 만족시키는건 불가능하므로 둘 중에 하나를 골라야 한다. 하지만 어려가지 문제로 CAP는 분산시스템에 대한 명확한 표현이 힘들다. PACELC를 이용하면 문제를 명확하게 이해할 수 있으며 시스템에 대해서도 깔끔하게 표현할 수 있다.
CAP보다는 PACELC를 쓰자
CAP는 분산 시스템 디자인의 선택에 도움을 주는 정리다. CAP가 장애 상황일 때의 선택에 대해 서술하는 것으로 생각하면, 정상 상황일 때의 선택에 대해 서술하지 못하게 된다. 그래서 정상상황일 때와 장애상황을 때를 나누어 설명하자는 것이 PACELC의 핵심이다. PACELC의 의미를 인용하자면 아래와 같다.

다시 말해 파티션(네트워크 장애)상황일 때에는 A와 C는 상충하며 둘 중 하나를 선택해야 한다는 것이다. 당연한 얘기다. 변경된 값을 모든 노드에서 바라볼 수 있도록 하려면 신뢰성 있는 프로토콜을 이용하여 데이터에 관여하는 모든 노드에 데이터가 반영되어야 한다. 하지만 네트워크 단절이 일어나 몇 개의 노드에 접근할 수 없을 때 C를 위해 데이터 반영이 아예 실패하던지 C를 포기하고 일단 접근 가능한 노드들이게 만 데이터를 반영하던지 둘 중의 하나만 골라야 한다. 또한, 정상상황일 때에는 L과 C는 상충하며 둘 중 하나를 선택해야 한다. 모든 노드들에 새로운 데이터를 반영하는 것은 상대적으로 긴 응답시간이 필요하기 때문이다. 이를 몇 가지 NoSQL 시스템에 적용하면 다음과 같다.
- HBase는 PC/EC이다. 장애 상황일때 C를 위해 A를 희생한다. 그렇지 않은 경우에도 C를 위해 L을 희생한다.
- Cassandra는 PA/EL이 가능하도록 디자인 되었다. 설정에 따라 Eventual Consistency의 특성을 가지게 되는데, 이 경우 PA/EL이 된다. 장애 상황인 경우에는 가능한 노드에만 데이터를 반영하고 정상으로 복구되면 필요한 노드에 데이터를 모두 반영한다. 정상상황일때도 Latency를 위해 모든 노드에 데이터를 반영하지 않는다.
- Brewer가 제시한 가상의 분산시스템은 PA/EC이다. 정상적인 경우에는 모든 노드에서 같은 메세지를 볼 수 있도록 쓰기 연산이 일어나는데 P 상황인 경우, 이를 판단하여 일단 접근 가능한 만큼만 데이터를 반영한다 결과적으로 시스템은 디운되지 않지만 절단된 노드들 끼리는 데이터를 주고 받지 못하게 된다. 장애상황이 복구되면 이를 감지하여 전달하지 못한 데이터를 반영한다. 장애상황일때에만 C를 포기하고 보통의 상황에서는 강력한 C를 가져가는 것이다.
출처 - 이정행님 블로그 해당 글 안에 참고된 레퍼런스 글도 모두 좋습니다. 대표적으로 CAP에서 P를 희생할 수 없다는 이 글..