2002년 경에 에릭 브루어(Eric Brewer)가 주창한 이론으로, CAP정리(CAP Theorem), 혹은 브루어 정리(Brewer’s theorem) 등으로 불리운다. 주요 내용은 분산 컴퓨터 시스템에서, 분산된 시스템이 가지는 세가지 특성을 동시에 충족시키는 것은 불가능하며, 이 중 두가지만을 취할 수 있다는 것을 정리한 내용이다.

나온지는 꽤 된 정리이지만, 관계형 데이터베이스 시스템(RDBMS)의 일관적인 활용에서 벗어난NoSQL 사용이 증가하면서 많이 언급되기 시작했다. 주로 RDBMS가 가지는 문제점인 분단가용성 부족으로 인한 수평적 확장(Horizontal Scalability)의 어려움을 벗어나기 위해서 NoSQL이 대두되게 되었는데, 여기서 당위성 설명을 위해 CAP 정리를 사용해 RDBMS가 치우친 면을 설명하고 그것을 벗어나기 위한 방법으로 NoSQL이 추구하는 방향성을 제시하는 경우가 많다.

분산 시스템이 추구하는 데이터의 특성 세가지에 대해서 알아보자.

• 일관성 (Consistency) : 각각의 사용자가 같은 데이터를 볼 수 있다 = 모든 노드가 같은 시간에 같은 데이터를 보여줘야 한다.
• 가용성 (Availability) : 모든 사용자가 항상 읽고 쓸 수 있다 = 몇몇 노드가 다운되어도 다른 노드들에게 영향을 주지 않아야 한다.
• 분단가용성 (Partition Tolerance) : 물리적으로 분리된 분산 환경에서도 작동한다 = 일부 메시지를 손실하더라도 시스템은 정상 동작을 해야 한다.

잘 이해가 되지 않는다면 서버에서 저장된 스토리지를 기준으로 생각하면 된다. 분산 시스템의 경우 대부분 저장소가 분산되어 있음으로서 생기는 동기화 지연이나 액세스 실패 등의 문제에 있어서 위의 방향성을 추구함으로서 해결 가능한 부분이 있다는 것을 대입시키면 쉽게 이해가 될 것이다.

CAP정리의 삼각형

CAP정리에 따르면 분산 시스템이 추구하는 데이터의 특성은 세 가지 중 두가지만 보장할 수 있다. 오른쪽의 그림은 이러한 특성을 삼각형으로 정리하고 각 데이터 베이스가 가지는 특성에 따라서 어느 방향에 놓여지는 가를 분류한 도표이다.

용어를 알아듣기 쉽게 분석하기 위해서 C= 동일성, A= 독립성, P=생존성 이라고 비유해보면,

1. CA 분류 (동일성 + 독립성 = 시스템이 죽을지언정 메시지 손실은 방지하는 강한 신뢰형)
   • 전통적인 RDBMS가 여기에 해당한다. 트랜잭션이 필요한 경우 필수적.
2. CP 분류 (동일성 + 생존성 = 모든 노드가 함께 퍼포먼스를 내야하는 성능형)
   • 구글의 BigTable과 그 아류작들(HyperTable, HBase 등)
3. AP 분류 (독립성 + 생존성 = 비동기화된 서비스 스토어에 적합)
   • Dynamo, Tokyo Cabinet, Apache Cassandra, CouchDB, Oracle Coherence 등

1. 위의 3가지가 각각의 목적이 다르기 때문에 적절한 사용 목적에 배치되어야만 한다.
2. 특히 C를 선택 하냐(동기식), 선택 안하냐(비동기식)를 아키텍처에 감안하여 선택해야 한다.
3. 보통 대용량으로 분산하는 케이스가 거의 P에 포함된다. 기존에 사용하던 RDB가 아닌 대안을 찾는다면 CP나 AP 분류를 선택해야 한다.
4. 보통 대용량으로 분산하는 케이스가 거의 P에 포함된다. 그러므로 기존에 사용하던 RDB가 아닌 대안을 찾는다면 CP나 AP 부류를 선택해야 한다.
5. CP는 대용량의 백데이터 저장이나 분산 파일 시스템용으로 사용한다. 주로 데이터의 덩치가 큰 편에 적합하며, 클러스터의 다중화도 고려되어야 한다.(C의 특성상 노드의 사망이 미치는 영향 때문에 Fail-Over 할 수 있는 다중화가 기본이다.)
6. AP는 요즘 인기를 얻고 있는 SNS들이 많이 채용하는 분류다. 메시지 처리가 안되면 그저 당장 처리못한다고 배를 째고 (에러 발생으로 리턴) 받을 수 있을 때 족족 받아 넣는 구조에 적합하다. 제대로 비동기식 플랫폼에 어울리는 놈이다. 이 분류는 동기식 실시간성과 동일성을 보장하지는 못하지만 Fail-Over에 강하다.
7. Oracle Coherence 같은 경우에는 하나의 서비스 노드가 다른 노드의 데이터를 백업본으로 들고 있을 수 있어서 다른 노드가 죽으면 해당 노드가 가지고 있던 데이터를 일정시간(몇 초) 이후에 자신의 서비스 데이터로 올려 놓는다. 그래서 시간적인 딜레이를 감안해 준다면 P의 약점인 데이터 유실을 일부 커버할 수 있고, 데이터의 유효성은 유지될 수 있다.(물론 백업본이 서비스로 올라오는 시간동안 다른 노드가 죽으면 유실될 수 있다.)

1. 기존에 많이 사용하던 RDBMS는 3가지 중 CA에 집중하고 있다. 웹이 발전하면서 다양한 요구사항이 생겨나고 엄청난 양의 데이터를 처리해야 하게 되면서, RDBMS가 갖지 못한 P의 특성이 필요해졌고 그러면서 등장한 것이 NoSQL이다.
2. 좀 더 풀어쓰면 데이터베이스에 대한 수평적 확장(Horizontal Scalability: 즉, 옆에 서버 한대 더 배치해서 데이터베이스를 늘리고 싶다는 의미이다.)에 대한 이슈가 발생했고 확장성 이슈를 해결하기 위해서 P를 선택하다보니 기존에 가지고 있던 C나 A의 특성 중 하나를 포기해야 했다. 그래서 NoSQL에는 다양한 시도들이 있지만 가장 중요한 이슈는 확장성을 해결하려는 것이다.
3. 관계형 데이터베이스는 기본적으로 분산형을 고려해서 디자인 되지 않았다. 그래서 ACID(원자성, 일관성, 독립성, 지속성) 트랜잭션 같은 추상화와 고레벨 쿼리모델을 풍부하게 제공할 수 있지만 확장성이 좋지 못하기 때문에 모든 NoSQL 데이터베이스는 다양한 방법으로 확장성 이슈를 해결하기 위해 초점을 맞추고 있다. 각 NoSQL에는 여러가지 차이점이 있지만 CAP의 범주에서만 보면 CP를 선택하거나 AP를 선택하게 된다.

• http://sjlee.egloos.com/5447532

• NoSQL 항목 : NoSQL