[Database] ACID, BASE, CAP 이론과 DB 선택 방법

회사에서  NoSQL DBMS 도입을 검토하면서 ACID, BASE, CAP 이라는 용어를 접했습니다.

ACID는 어디서 많이 들어본거 같은데, BASE와 CAP은 처음 들어봤습니다.

각 용어의 정의와 어떤 때 어떤 조건을 충족시켜야 할지 고민해보겠습니다.

 

 

1. ACID

ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어 입니다. (위키백과, ACID)

데이터베이스에서 데이터에 대한 하나의 논리적 실행단계를 트랜잭션이라고 합니다. 예를 들어, 은행에서의 계좌이체를 트랜잭션이라고 할 수 있는데, 계좌이체라는 트랜잭션이 내부적으로는 여러단계로 이루어질 수 있지만,  '송신자 계좌의 금액 감소', '수신자 계좌의 금액 증가'가 한 동작으로 이루어져야 하는 것을 의미합니다.

 

A,C,I,D 각각은 아래와 같습니다.           

 

가. 원자성(Atomicity)

원자성(Atomicity)은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다. 예를 들어, 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안된다. 원자성은 이와 같이 중간 단계까지 실행되고 실패하는 일이 없도록 하는 것이다.

간단하게 말하면 성공할거면 모두 성공하고, 실패할거면 모두 실패해야 한다는 것을 뜻합니다. 원자성과 관련해서는 2 phase commit 에 대해 추가로 알아두면 좋겠습니다.

 

2 단계 커밋(2 Phase Commit)

2PC는 다중 노드에서 원자성을 보장하기 위한 알고리즘입니다. 트랜잭션 처리시, DB1, DB2 두개의 노드에서 Commit이 필요한 경우에 처리하기 위한 알고리즘 입니다. 아래 그림과 같이, 두개의 노드에서 모두 write 준비가 된 후에 commit을 수행하는 알고리즘을 의미합니다. 

 

https://dongwooklee96.github.io/post/2021/03/26/two-phase-commit-%EC%9D%B4%EB%9E%80/

 

나. 일관성(Consistency)

일관성(Consistency)은 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미한다. 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단된다. 

데이터베이스의 제약 조건을 만족해야 한다는 의미입니다.

 

다. 독립성(Isolation)

독립성(Isolation)은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다. 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미한다. 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없다. 공식적으로 고립성은 트랜잭션 실행내역은 연속적이어야 함을 의미한다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건이다. 자세한 내용은 관련 문서를 참조해야 한다. 

독립성 또는 고립성은 A 트랜잭션에 B트랜잭션이 영향을 줄수 없다는 것을 뜻함과 동시에 A,B 트랜잭션이 동시에 수행되는 경우 A,B가 연속적으로 수행하는 것과 동일한 결과를 가진다는 것을 의미한다고 합니다.

락(Lock)

추가로 한 가지 개념을 간단히 알아보고 가겠습니다.

다중 사용자 환경에서 둘 이상의 트랜잭션이 동시에 수행될 때, 일관성을 해치지 않도록 트랜잭션의 데이터 접근 제어가 필요합니다. 이를 동시성 제어(concurrency control) 이라고 하고, 동시성 제어가 실패하면, 트랜잭션 유형에 따라, 오손 읽기, 반복불가능 읽기, 유령데이터 읽기, 갱신 손실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있습니다.

따라서 여러개의 트랜잭션이 하나의 데이터로 접근하려 할때, 트랜잭션을 제어하기 위한 방법이 필요한데, 이것이 락(Lock)입니다. 락에는 공유락, 배타락 등이 있으며, 공유락은 읽기, 배타락은 쓰기시에 필요하다 정도로만 알고 여기서 자세한 내용은 다루지 않겠습니다.

라. 지속성(Durability)

지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미한다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미한다. 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다. 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.

모든 성공한 트랜잭션의 결과는 이후에 발생한 런타임 오류나 시스템 오류의 영향을 받지 않고 유지된다는 것을 의미합니다.

 

2. BASE

 

ACID는 다른 뜻으로는 산(Acid)라는 뜻을 가지고 있는데요. BASE도 다른 뜻으로 염기(Base)이기도 합니다. ACID에 맞춰서 알파벳을 짜맞춘게 아닌가 싶네요.

BASE 보다는 CAP이 중요하니까 간단하게 약어만 확인하고 넘어가겠습니다.

 

Basically Available : 기본적으로 Available하고
Soft-state : 사용자가 관리(refresh, modify)하지 않으면 Data가 expire 될 수도 있으며
Eventually consistency : 지금 당장은 아니지만 언젠가는 Data가 일관성을 가진다

 

 

3. CAP

CAP 정리는 다음과 같은 세 가지 조건을 모두 만족하는 분산 컴퓨터 시스템(둘 이상의 DB에 데이터를 저장하는 시스템)이 존재하지 않음을 증명한 정리입니다.

일관성(Consistency) 모든 노드가 같은 순간에 같은 데이터를 볼 수 있다.

한개 노드에 쓰기가 될때, 그 쓰기가 완료되기 전에 다른 노드에 데이터가 복제된다는 것을 의미합니다.

 

가용성(Availability) 모든 요청이 성공 또는 실패 결과를 반환할 수 있다. 

하나 이상의 노드가 다운되더라도 오류가 없는 모든 노드는 모든 읽기 및 쓰기 요청에 대한 응답을 반환한다는 것을 의미합니다. 응답이 성공인지, 실패인지는 상관없습니다.

 

분할내성(Partition tolerance) 메시지 전달이 실패하거나 시스템 일부가 망가져도 시스템이 계속 동작할 수 있다. 

일부 메시지가 손실되거나 시스템에 오류가 있더라도 시스템이 계속 작동한다는 것을 의미합니다.

Partition은 네트워크의 단절을 의미합니다. 즉, 네트워크 단절 시에 각 노드간에 오차를 허용하고, 추후 복구가 가능하다는 것을 의미합니다.

 

위의 세 가지 조건의 첫 글자를 따서 CAP 정리라고 부르고, 이 세가지 조건 중 최대 2가지 조건만 만족할 수 있다는 것이 증명되어있다고 하네요. 

 

CAP 정리는 시스템을 세가지 범주로 분류합니다. 3가지 조건 중 2가지만 만족하니까.. 3가지 조합이 있는 거죠. 

 

CP(Consistent and Partition Tolerant)  데이터베이스는 가용성을 희생하고 일관성과 분할내성을 제공합니다. 만약 A, B 두개의 노드가 있을때, A,B간에 네트워크가 중단되는 경우, 일관성과 분할내성을 유지하기 위해서는 A노드에서는 쓰기를 할 수 없도록 막아야 합니다. 이후 네트워크가 복구되면 다시 노드를 동기화하여 불일치를 복구합니다.

 

AP(Available and Partition Tolerant) 데이터베이스는 일관성을 희생하고 가용성과 분할내성을 제공합니다. 네트워크 중단시에는 A,B 노드를 계속 사용할 수 있지만, A,B가 다른 데이터를 반환할 수 있습니다. 그 후 네트워크가 복구되면 다시 노드를 동기화하여 불일치를 복구합니다.

 

CA(Consistent and Available) 데이터베이스는 네트워크 파티션이 없는 경우에도 일관성과 가용성을 제공합니다. 사실상 단일 노드의 DB서버여야 CA시스템으로 분류되고 이경우는 노드간 오차가 없으므로 처리 필요도 없습니다.

 

사실상 네트워크로 연결된 모든 분산 시스템에서 네트워크 단절이나, 메시지 유실은 실제로 발생할 수 있기 때문에, 이런 부분을 적절하게 처리해주어야 합니다. 결국 P는 필수이며, A와 C중에서 적절한 DBMS를 선택해야 합니다.

 

정리하면, CAP는 분산시스템의 설계자가 시스템상의 절충점을 판단할 수 있게 해주고 이에 따라 NoSQL DB를 선택할때 도움을 줍니다. 

 

아래의 벤다이어그램은 CAP 정리를 기반으로 하는 데이터베이스 분류를 보여줍니다.

 

 

https://medium.com/@kumar.barmanand/cap-theorem-and-nosql-databases-589e26e15905

 

어떤 DBMS를 사용할 것인가?

NoSQL 도입을 검토했던 시스템은 청구 데이터를 청구서 포맷으로 변환해서 발송하는 시스템이었습니다.

다양한 NoSQL DBMS가 있습니다만, 결론적으로 MongoDB를 선택했고, 위 벤다이어그램에서 보는 바와 같이 MongoDB는 CP 데이터베이스 입니다.

청구서 작업은 온라인 업무보다는 이미 만들어진 청구 데이터를 변환하는 배치작업이 주가 되기 때문에 가용성은 포기가 가능한 부분이었고, 대신 숫자를 다루는 것이기 때문에 일관성이 아주 중요했습니다. 그래서 CP데이터베이스가 선택되는데 무리가 없었습니다.

(사실.. MongoDB로 결정이 먼저되었고, 왜 MongoDB여야 하는지 이유를 나중에 붙였다는 이야기가 전해집니다..)

그런데, NoSQL 중에 하나를 고른다면, MongoDB가 맞겠으나.. 기존에 잘 쓰던 RDBMS를 굳이 MongoDB로 교체했어야 하냐..라고 묻는다면, 굳이 가용성을 포기하고 그럴 필요가 없을 것 같습니다.

만약 시스템을 처음 구축하는 것이었다면, 청구서(=Document)의 특성상 NoSQL이 맞았겠지만, 이미 장기간 RDBMS에서 안정적으로 운영이 되어왔기 때문에, NoSQL을 도입해서 얻는 이득이 거의 없었습니다.

이 부분은 주제에서 조금 벗어나기 때문에 나중에 기회가 닿는다면 더 얘기해봐야겠네요.

 

 

 

참고자료

https://hanamon.kr
https://medium.com/@kumar.barmanand/
milktea_good/62
망나니 개발자/62
개발자 이동욱/62
Embian Blog/62