CAP 이론?

개요

현재 진행 중인 프로젝트에서, 데이터베이스를 선택할 때 큰 틀인 RDBMS(관계형 데이터베이스)와 NoSQL(Not Only SQL) 데이터베이스 중 어떤 것을 선택해야 할지, 도움을 줄 수 있는 이론인 CAP 이론에 대해 알아보고, 각각의 RDBMS에서는 CAP 이론의 어떤 점을 만족하는지, NoSQL에서는 CAP 이론의 어떤 점을 만족하는지에 대해 알아보겠습니다.

CAP 이론

CAP 이론은 일관성(consistency), 가용성(availability), 그리고 분산 시스템의 파티션 허용 오차 차이(partition tolerance in distributed system)간의 절충점(trade-off)을 설명하는 컴퓨터 과학의 개념입니다.

먼저 일관성(Consistenct)이란 다음과 같은 시스템 속성을 말합니다.

 

• 모든 노드가 데이터를 일관되게 볼 수 있는 시스템 속성을 말합니다.
• 사용자가 여러 노드 중 어떤 노드를 선택하더라도 해당 데이터는 일관하게 보이는 것을 의미합니다.
• 즉, 모든 클라이언트(여기서는 사용자)는 어느 노드에 연결하든 동일한 데이터를 동시에 볼 수 있습니다.

다음으로 가용성(Availability)이란 시스템이 사용자의 요청에 항상 응답할 수 있는 능력을 말합니다.

 

마지막으로 파티션 허용 오차(Partition tolerance)란 시스템이 네트워크 파티션이 있어도 계속 작동할 수 있는 기능을 말합니다.

그렇다면 여기서 네트워크 파티션은 무엇일까요?

• 네트워크 파티션은 분산 시스템의 노드가 네트워크 장애로 인해 서로 통신할 수 없을 때 발생합니다

만약 네트워크 파티션이 있는 경우 시스템은 일관성(Consistency)과 가용성(Availability)중 하나를 선택해야 합니다.

• 시스템이 일관성을 우선시하는 경우, 네트워크 파티션이 해결될 때까지 위의 그림에서 데이터를 업데이트할 수 없게 됩니다.
  • 네트워크 파티션이 해결될 때까지 데이터를 업데이트할 수 없게 함으로써, 데이터의 일관성을 유지할 수 있어 데이터 불일치 현상을 방지할 수 있습니다.
• 반면 시스템에서 가용성을 우선시하는 경우, 네트워크 파티션이 해결되지 않아도 데이터 업데이트를 허용할 수 있습니다. 하지만 이로 인해서 네트워크 파티션이 해결될 때까지 데이터 불일치 현상이 발생할 수 있습니다.

예시

네트워크를 통해 두 대의 ATM이 연결된 작은 은행이 있다고 가정하겠습니다.

• ATM은 입금(Deposit), 인출(Withdraw), 잔액 확인(check balance)의 세 가지 작업을 지원합니다.
• 잔액은 어떤 일이 있어도 0 이하로 내려가면 안 됩니다.

현재 시스템에서는 각 계정별 잔액을 보관하는 중앙 데이터베이스가 없습니다. 잔액은 두 ATM에 모두 저장됩니다.

고객이 ATM기기를 사용하면 네트워크를 통해 두 ATM의 잔액이 모두 업데이트됩니다. 이렇게 함으로써 ATM에서 계좌의 잔액을 일관되게 볼 수 있습니다.

하지만 위의 케이스는 정상 작동하는 시나리오이며, 만약 네트워크 파티션이 발생해 ATM이 서로 통신할 수 없는 경우, 시스템은 일관성과 가용성 중 하나를 선택해야 합니다.

은행(ATM)이 일관성을 선택한 경우

• 네트워크 파티션이 해결될 때까지 ATM에서 입금 또는 출금 처리가 거부될 수 있습니다.

이렇게 하면 잔액은 일정하게 유지되지만, 고객은 파티션이 해결될 때까지 해당 시스템을 사용할 수 없습니다.

은행(ATM)이 가용성을 선택한 경우

• 네트워크 파티션이 해결되지 않아도 고객은 ATM 시스템을 사용할 수 있습니다.

하지만 파티션이 해결될 때까지 잔액이 일정하지 않을 수 있습니다. 이로 인해 사용자는 ATM 시스템을 계속 사용할 수 있다는 장점이 있지만, 데이터의 일관성이 떨어질 수 있습니다.

위의 예시에서 은행의 경우, 데이터(잔액)의 일관성이 중요하기 때문에 가용성을 우선시하게 되면

네트워크 파티션이 있는 상황에서 ATM을 사용하는 각각의 고객은 두 ATM에서 전체 잔액을 인출할 수 있습니다. 만약 이렇게 인출을 한 후 네트워크 파티션이 해결되어 온라인 상태가 되면, 데이터 불일치가 해결되어 잔액이 마이너스가 될 수도 있습니다.

또 다른 예시

소셜 미디어 플랫폼(SNS)에서 CAP 이론을 어떻게 적용할 수 있는지 살펴보겠습니다.

네트워크 파티션이 발생한 상황에서 두 명의 사용자가 동시에 같은 글에 댓글을 다는 경우,

파티션이 해결될 때까지 한 사용자의 댓글이 다른 사용자에게 표시되지 않을 수 있습니다.

또는 SNS 플랫폼이 일관성을 우선시하는 경우, 네트워크 파티션이 해결될 때까지 사용자가 댓글 기능을 사용할 수 없습니다.

소셜 네트워크 플랫폼의 경우 가용성을 우선순위로 두는 것이 허용되는 경우가 많습니다. 이로 인해 SNS 플랫폼을 이용하는 사용자가 때때로 약간 다른 화면을 보게 되는 비용을 치르게 됩니다.

앞선 예시를 통해 살펴본 CAP 이론은 단순하고 간단하게 보일 수 있지만 실제 프로젝트는 훨씬 복잡합니다. 소프트웨어 엔지니어링의 많은 부분이 트레이드오프에 관한 것인 것처럼 CAP이론도 마찬가지입니다. CAP 이론을 통해 흑백논리처럼 두 가지 중 한 가지를 명확하게 선택할 수 있는 것이 아닙니다.

CAP 정리는 가용성 100% 또는 일관성 100%를 가정합니다. 실제 프로젝트에서는 일관성의 정도와 가용성의 정도에는 분산 시스템 설계를 하는 사람이 신중하게 고려해야 할 점이 있습니다.

앞서 설명했던 은행 시스템의 예시로 돌아가서, 네트워크 파티션 중에 ATM은 잔액 확인만 허용할 수도 있습니다.

네트워크 파티션 중에는 잔액 조회만 처리될 수 있으며, 입금 및 출금 기능은 차단될 것입니다.

CAP 이론이 정말 유용한지 의문이 들 수도 있습니다. CAP 이론을 통해 네트워크 파티션이 있을 때 고려해야 할 높은 수준(high-level)의 트레이드오프에 대해 설명합니다.

CAP 이론을 통해 트레이드오프를 고려한 설계의 좋은 출발점이 될 수 있지만, 설계를 위한 완벽한 정보를 제공하지는 않습니다. 균형 잡힌 분산 시스템을 설계할 때 고려해야 할 장단점에 대한 완벽한 토대를 제공하지는 않습니다.

특히 네트워크 장애 없이 시스템이 정상적으로 작동하는 경우, 대부분의 경우에서 대기 시간과 데이터의 일관성 사이에서 고려해야 할 절충안이 있습니다. 위와 관련한 내용은 PACELC 이론이라 합니다

(해당 내용은 다른 포스팅에서 설명하도록 하겠습니다.)

그렇다면 RDBMS와 NoSQL은 CAP 이론의 어떤 부분을 만족하고 있을까요?

RDBMS와 NoSQL에서의 CAP 이론

대부분의 RDBMS는 CA(일관성과 가용성)을 만족하고 있습니다. 그렇다는 것은 네트워크 장애를 허용하지 않아야 합니다. 하지만 이런 시스템은 현재까지 세상에 존재하지 않습니다.

더 나아가서 RDBMS로 자주 쓰이는 Mysql에서는 Primary-Secondary(Master-Slave와 같은 말입니다.) 관계를 사용할 때 CA를 만족하며, 클러스터 방식으로 데이터베이스를 구성할 때는 CP를 만족합니다. 이렇듯 RDBMS라고 해서 무조건 CA를 만족시키는 것이 아니라, 각각의 데이터베이스 솔루션의 설정 환경에 따라 다양하게 조합이 될 수 있으니 해당 데이터베이스 솔루션의 공식 문서나 관련 자료를 참고하여, CAP 우선순위를 결정하는 것이 좋을 것 같습니다.

이어서 NoSQL은 CP, AP의 형태를 가질 수 있습니다. CP형태를 가지는 Nosql은 MongoDB, Redis 등이 있습니다. AP 형태를 가지는 NoSQL은 cassandra와 CouchDB가 있습니다. 일관성을 포기하여 데이터의 불일치 현상이 발생할 수도 있지만, 그로 인해 동기화된 처리가 아닌 비동기화된 처리를 하기 때문에 데이터 처리 속도가 빠르다는 장점이 있어 대용량 데이터 처리에 유리할 수 있습니다.

 

Availability 와 Partition tolerance의 차이?

Availability와 Partition tolerance는 분산 시스템 상황에서 서로 연관되어 있는 개념이라 볼 수 있지만 실제로는 별개의 개념 입니다.

**Availability(**가용성)은 장애나 다른 유형의 중단에도 분산 시스템이 계속 작동하고 클라이언의 요청에 응답할 수 있는 기능을 말합니다. 이러한 가용성을 중시하는 분산 시스템은 일반적으로 복제(replication), 이중화(redundancy) 및 다른 기타 기술을 사용하여 주어진 시간에 여러 개의 데이터 또는 서비스 사본을 사용할 수 있도록 합니다. 이를 통해 일부 노드(여기서는 데이터베이스 서버를 노드라 가정 하겠습니다.)나 서비스에 장애가 발생하거나 일시적으로 사용할 수 없게 되더라도 시스템이 계속 작동할 수 있습니다.

Partition tolerance (파티션 허용 오차 차이)

파티션 허용 오차 차이는, 네트워크 파티션이 발생하더라도 분산 시스템이 계속 작동하고 일관성을 유지할 수 있는 기능을 말합니다. (여기서 네트워크 파티션은 분산 시스템의 노드를 연결하는 네트워크가 일시적으로 사용할 수 없게 되거나 연결이 끊긴 세그먼트로 분리될 때 발생합니다.)

이런 네트워크 파티션은 네트워크 장애, 소프트웨어 오류 와 같은 다양한 이유로 발생할 수 있습니다. 이때 파티션 허용 오차 차이를 보장하기 위해 분산 시스템은 일반적으로 리더 선출, 합의 알고리즘 또는 기타 형태의 쿼럼 기반 의사 결정과 같은 기술을 사용하여 네트워크 파티션이 발생하더라도 시스템이 계속 작동하고 발전할 수 있도록 보장합니다.

(리더 선출, 합의 알고리즘, 쿼럼 기반 의사 결정에 대한 내용은 본 포스팅의 주제를 넘는다 생각해, 따로 정리하지 않았습니다.)

이렇게 설명을 통해 알아보아도 이해가 쉽지 않아, 좀 더 쉽게 부가 설명과 예시를 통해 설명해보겠습니다.

CAP 이론의 A(가용성)은 어떤 서버가 다운되어 사용 불가능한 상태가 되더라도 문제가 없다는 것이고, P(파티션 허용 오차 차이)는 어떤 한 대의 서버가 병목 지점이 되지 않는다 는 것을 말합니다.

예를 들어, 축구에서 골키퍼가 퇴장되었을 때, ‘수비수가 일단 골대 앞을 지키는 것이 가능하다’, 하지만 ‘수비수는 손을 사용할 수 없기 때문에 효율적이지 않다’가 되는 것 입니다. A는 달성하였지만 P는 달성하지 못한것입니다. 만약 골키퍼가 분할 가능하다면 P도 가능하지만, 축구 경기의 규칙상 규칙 위반으로 실격이 될 것 입니다.

 

 

 

마무리

CAP 이론을 통해 우선순위를 정하고 각자의 프로젝트에서 필요한 데이터베이스를 선택하는 것은 참고지표로 도움이 될 수 있지만 , 절대적인 기준이 될 수는 없는 것 같습니다. 또한 현실 세계를 반영한 실무 프로젝트에서는 더 복잡한 상황들이 추가될 수 있기 때문에, CAP 이론을 통해서만 간단히 데이터베이스를 결정할 수 있는 문제는 아니라고 생각이 들었습니다.

앞서 살펴본 CAP 이론을 통해, 데이터베이스를 결정하는 주원인이 될 수는 없겠지만. 현재 진행 중인 프로젝트에 적용을 하고자 한다면, 굿즈 거래라는 상품 거래가 주요 기능인 프로젝트입니다. 그렇기에 해당 상품의 재고나, 거래 상태, 결제와 같은 데이터의 일관성이 중요한 비중을 차지하게 될 것 같습니다. 따라서 CAP 이론의 요소 중 일관성(Consistency)을 우선시할 요소로 두고, 나머지 요소들을 선택하게 될 것 같습니다.