분산 시스템을 설계할 때는 CAP 정리(Consistency, Availability, Partition Tolerance theorem)를 이해하고 있어야 한다. (면접에서 이 질문 나왔을때 엄청 당황했다.)
CAP 정리
다음의 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것이 불가능하다.
•
일관성(Consistency)
•
가용성(Availability)
•
파티션 감내(Partition tolerance)
CAP는 원래 Database 에서 trade-off 에 대한 논의를 시작하려는 목적으로 정확한 정의 없이 경험 법칙으로서 제안 되었다.
여기서 말하는 분산 시스템은 Database cluster를 의미하는 것이며, 하나의 main-sub 부터 leaderless 구조까지 다양한다.
결국 3가지 중 2개를 골라야 한다.
그런데 이와 같이 생각하면 오해의 소지가 있다.
네트워크 분단은 좋든 싫든 발생한다. 네트워크가 올바르게 동작할 때는 시스템이 일관성(선형성)과 완전한 가용성을 모두 제공할 수 있다.
데이터 일관성 (Consistency)
분산 시스템에 접속하는 모든 client 는 어떤 노드에 접속했느냐에 관계없이 언제나 같은 데이터를 보게 되어야 한다.
Query Q에 대해서 어떤 노드이건 관계없이 동일한 Answer A를 반환한다.
가용성 (Availability)
분산 시스템에 접속하는 client 는 일부 node 에 장애가 발생하더라도 항상 응답을 받을 수 있어야 한다.
분산 시스템에서 Query Q를 받았을 때 언제나 Answer A를 반환한다.
이는 고가용성(High-availability)과 혼동하지 말아야 한다. 많은 양의 쿼리 응답을 제공하는 것이 아니라, 응답을 거부하지 않는것을 의미한다.
파티션 감내(Partition tolerance)
파티션은 두 node 사이에 통신 장애가 발생하였음을 의미한다.
“파티션 감내라고 해서 파티션이 있어도 시스템이 동작한다.” 라는 의미가 아니다. 네트워크 단절등으로 인해 cluster안에 존재하는 node 간 통신이 일어나지 않는다 하더라도 계속 응답이 있음을 뜻한다.
CAP 정리는 이들 가운데 어떤 두 가지를 충족하려면 나머지 하나는 반드시 희생되어야 한다는 것을 의미한다.
Trade off 비교
•
CP 시스템
◦
일관성과 파티션 감내를 지원하는 저장소
◦
가용성을 희생한다.
•
AP 시스템
◦
가용성과 파티션 감내를 지원하는 저장소
◦
데이터 일관성을 희생한.
•
CA 시스템
◦
일관성과 가용성을 지원하는 저장소
◦
파티션 감내는 지원하지 않는다.
◦
하지만, 네트워크 장애는 피할 수 없는 일로 여겨지므로, 분산 시스템은 반드시 파티션 감내가 가능하도록 설계되어야 한다.
즉, 결과적으로 CA 시스템은 존재하지 않는다.
이러한 정의만으론 이해가 어렵다. 몇 가지 구체적인 사례를 살펴본다.
•
분산 시스템에서 데이터는 보통 여러 node 에 복제되어 보관한다.
•
3대의 복제 node n1, n2, n3 에 데이터를 복제하여 보관한다고 가정하자.
이상적인 상태
파티션이 된다는 것은 n1과 n2에 존재하는 집합 A가 n3에 존재하지 않는 상황을 의미한다.
이상적인 환경이라면 n1에 기록된 데이터는 자동으로 n2, n3 에 복제된다.
데이터 일관성과 가용성도 만족된다.
실세계의 분산 시스템
분산 시스템은 파티션 문제를 피할 수 없다.
만약 파티션 문제가 발생할 경우 C(일관성)와 A(가용성) 중 하나를 선택해야 한다.
n3에 장애가 발생하고 n1, n2 와 통신이 불가능한 상황
•
n1과 n2에 기록한 데이터는 n3 로 저장되지 않는다.
•
n3에 기록된 데이터중 n1과 n2로 전달되지 않는 데이터가 있다면 n1, n2는 오래된 사본을 갖는다.
여기서 가용성(Availability)을 ‘포기’하고 일관성을 선택하면(CP)
일관성 유지를 위해 n1, n2 에 쓰기 작업을 중단시켜야 한다.
일관성은 유지되지만, 가용성(일부 노드에 장애가 발생해도 응답한다)이 만족되지 않는다.
그래서 일관성과 가용성은 동시에 만족할 수 없다.
요약
•
일관성이 필요 없는 application 은 네트워크 문제에 더 강하다.
◦
이런 통찰력이 2000년에 Eric Brewer 가 CAP 정리로 이름을 붙여 널리 알려졌다. 물론 1970년대에도 분산 데이터베이스 설계자들에게 알려져 있긴 했지만 말이다.
•
그래서 AP, CP 는 존재하지만 CA는 존재할 수 없다.
적용
MongoDB 는 CAP 로 보면 어떻게 될까?
MongoDB 는 NoSQL DBMS로 BSON(Binary JSON)을 저장한다.
용도로는 Big data, Sharding을 적용한 real-time application으로 사용한다.
CAP 정리로는 CP에 해당한다.
•
MongoDB는 single-master system 으로 각각의 replica 는 오로지 하나의 primary node 를 갖는다.
•
Upsert operation 을 받는 단 하나의 primary node 가 있고, 나머지는 복제본이다.
◦
Primary node의 로그를 읽어 2차 노드에 복제한다.
◦
Client는 primary node 에서도 읽지만, 2차 노드에서 읽는다.
•
1차 Primary node 가 사용 불가능한 상태가 되면, 가장 최신의 로그가 복제된 2차 노드가 primary node 가 된다.
•
모든 2차 노드가 새로운 master를 따라잡을 경우(복제가 완료된 경우) cluster 가 다시 사용 가능해진다.
◦
Client 는 이 따라잡는 간격 중에 쓰기 요청을 할 수 없다.
Cassandra 의 CAP 정리.
Apache cassandra 는 NoSQL DBMS 이다.
분산 네트워크에 데이터를 저장할 수 있도록 허용하는 Wide-Column Database 로 MongoDB와는 다르게 masterless 아키텍처를 보유하여 다수에 장애 가능성이 존재한다.
CAP로는 AP에 해당한다.
•
가용성, 파티선 허용을 제공하지만 일관성은 제공하지 못한다.
•
Master node 가 없으므로 모든 노드는 쓰기와 가용성을 보장하며, 언제, 어느 노드라도 Upsert가 가능하다.
•
그러나 consistency 는 최종적 일관성(Eventual consistency)을 보장하여 노드간 불일치를 가능한 빠르게 해소하고자 한다.
•
만약 네트워크 파티셔닝 이슈로 인해 inconsistent 인 상황이 발생하면 빠르게 노드의 차이를 따라잡는 “repair” 라는 기능을 제공한다.
•
그러나 이 기능은 system performance를 고려할 때 trade off 가 존재하므로 따져볼 필요가 있다.
