created at 2022-11-20

이 포스팅은 ACID, CAP, BASE 이론들을 설명하는 글입니다.

대부분의 어플리케이션은 데이터의 정합성을 보장하기 위해서 데이터 베이스를 이론(ACID, CAP, BASE 이론)에 따라 관리합니다.

일반적으로 분산 DB를 사용하지 않는 싱글 Data 시스템이라면, ACID 이론에 따라 DB를 관리합니다. 만약 분산 Data 시스템 구조라면, CAP/BASE 이론에 따라 DB를 관리합니다.

1. ACID

ACID는 Atomicity, Consistency, Isolation, Durability 의 약자로써 트랜젝션의 정합성을 만족시키는 이론입니다.

예를 들어 다음과 같이 A와 B가 C에게 1000원을 송금한다고 가정해볼까요?
A의 잔고에서 1000원 출금
C의 잔고에 1000원 입금
B의 잔고에서 1000원 출금
C의 잔고에 1000원 입금
이 때, 발생할 수 있는 비정상적인 동작은 다음과 같습니다.
(1) or (2) or (3) or (4) 를 실행하고나서 서버가 멈춤
A와 B가 동시에 C에게 송금
이 때 ACID이론에 맞추어 어플리케이션을 설계한다면 위와 같은 비정상적인 동작에 대응할 수 있습니다.

1-1. 원자성(Atomicity)

원자성은 일련의 과정이 트랜젝션이라는 단위로 묶이고, 묶인 과정들이 모두 실행되거나 아니면 실행되지 않거나 둘 중 하나만 선택해야하는 규칙입니다.

어플리케이션은 원자성을 보장하기 위해서 다음의 과정을 실행해야겠죠?

TRANSACTION 1 : (1), (2), TRANSACTION 2 : (3), (4) 와 같이 트랜젝션이라는 단위로 묶습니다.
ERROR : (1) => ROLLBACK : (1)
SUCCESS : (1) && ERROR : (2) => ROLLBACK : (1), (2)
SUCCESS : (1), (2) && ERROR : (3) => ROLLBACK : (3)
SUCCESS : (1), (2), (3) && ERROR : (4) => ROLLBACK : (3), (4)

위의 과정을 통해 어플리케이션은 원자성을 보장할 수 있고, 데이터 정합성을 보장할 수 있게 됩니다.

1-2. 일관성(Consistency)

일관성은 트랜젝션 수행 전/후 DB의 상태는 모순 없이 일관성을 유지해야 하는 규칙입니다.

즉, 우리가 사전에 정의한 룰들이 지켜져야한다는 규칙입니다.

사전에 정의한 규칙들 예시
A, B, C의 account_id는 유니크이어야 한다.
송금 기록의 index_id는 유니크이어야 한다.

위와 같이 ~는 유니크이어야 한다. 라는 규칙은, RDB에서는 unique keys, foreign key constraints 와 같이 DB가 자동적으로 예외를 반환하도록 설정할 수 있습니다. 반면 Non-Relational DB는 다른 방식으로 사용하겠죠?

1-3. 고립성(Isolation)

독립성은 현재 수행중인 트랜젝션이 동시에 수행되고 있는 다른 트랜젝션에 의해 영향을 받으면 안된다는 규칙입니다.

RDB에서는 트랜젝션의 독립성을 지원하는 여러가지 격리레벨 수준을 가지고 있습니다.

제가 사용하는 RDB는 Postgres로써, READ COMMITTED(LEVEL 2)를 기본적으로 사용합니다. 얘네는 NON-REPEATABLE READ 라는 문제점을 가지고 있습니다. 이 문제점은 트랜젝션 내에 SELECT를 두 번 실행했을 때 값이 달라질 수 있는 문제점입니다.

이런 고질적인 문제는 비관적 읽기 잠금 으로 SELECT로 데이터를 읽을 때 잠구고 읽도록 설정함으로써 완화할 수 있습니다.

1-4. 지속성(Durability)

지속성은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 규칙입니다.

즉, TRANSACTION 1와 TRANSACTION 2가 성공적으로 수행되면, A와 B의 잔고는 각각 1000원이 줄어들어야 하며, C의 잔고는 1000+1000 원이 늘어나 있어야 한다는 규칙입니다.

{} 어플리케이션에서 DB를 한곳에서만 관리한다면 ACID 이론에 따라 여러 규칙들에 맞게 설계할 수 있습니다. 하지만, DB가 분산되어있다면 ACID 이론으로만 관리할 수는 없습니다.

분산시스템에서는 CAP 이론과 BASE 이론에 맞추어 설계해야합니다.

But only for single-machine data systems. The moment we introduce multiple machines forming a system, strictly obeying the ACID rules gets tricky. We need other sets of rules and theorems around the distributed systems. There come CAP and BASE.

2. CAP

CAP이론은 분산 Data 시스템에서 많이 사용되는 이론입니다.

2-1. 일관성(Consistency)

분산 시스템을 이루는 다수의 Node로부터 동일한 응답을 얻을 수 있어야 하는 속성을 의미합니다.

2-2. 가용성(Availability)

분산 시스템을 이루는 특정 Node가 다운되더라도 분산 시스템이 동작해야하는 속성을 의미합니다.

2-3. 파티션 허용(Partition-tolerance)

Network 장애로 인하여 Node 간 통신이 불가능하여도 분산 시스템이 동작해야 한다는 속성을 의미합니다.

대부분의 분산 Data 시스템(MongoDB, Cassandra, etc.)에서는 Partition-tolerance를 기본적으로 지원하고 일관성과 가용성 둘중 하나를 선택하여 지원합니다. 두가지 다 동시에 지원할 수 없는 이유는 아래와 같습니다.

일관성과 가용성 중 하나밖에 선택할 수 없는 이유

C와 A는 서로 상반된 관계를 가집니다.

예로 CP(일관성 + 파티션 허용) 시스템에서는 같은 시간에 모든 노드들로부터 동일한 응답을 얻어야 합니다. 따라서 노드 장애 발생 시, 해당 노드의 재시작까지 기다려야되죠.

반면 AP(가용성 + 파티션 허용) 시스템에서는 다운 된 노드를 무시하고 응답을 수행합니다. 이렇게 되면 무시한 노드에는 사실 어떤 정보가 저장되었는지 모르기떄문에, 일관성을 포기하는 셈이죠.

따라서 일관성과 가용성 중, 하나만 지킬수 밖에 없는 것입니다.

CP 시스템은 MongoDB, HBase 가 대표적인 시스템이며, AP 시스템은 Cassandra 입니다.

3. BASE

BASE는 CAP과 마찬가지로 분산 DB 시스템에서 주로 사용되는 이론입니다.

CAP의 AP 시스템과 유사한 형태를 가지고 있습니다.

3-1. 가용성 보장(Basically-Available)

가용성 보장은 CAP 이론의 Available 특성과 유사합니다.

분산 시스템을 이루는 특정 Node에 장애가 발생하더라도 분산 시스템이 동작해야하는 속성을 의미합니다.

3-2. Soft-state

분산 데이터 시스템에 어떤 인풋이 없더라도 계속해서 변화하는 특성힙니다.

3-3. 일관성(Eventually-consistent)

일시적으로는 일관되지 않는 값을 반환하지만, 결론적으로는 일관성을 보장하는 특성입니다.