ACID

Transaction이 제공하는 안정성 보장(safety guarantee)은 흔히 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)를 의미하는 ACID로 알려져있다.

많은 강의, 책에서 Transaction을 설명할 때, 필수적인 개념으로 등장하며 무조건 보장되어져야하고 모든 데이터베이스에서 지켜지고 있는 것처럼 설명한다. 하지만 현실에서는 참 애매모호하다. ACID의 의미가 모호한 부분이 있어서 데이터베이스마다 ACID 구현이 제각각이다.

ACID에 대해 각각 살펴보자.

 

Atomicity

원자성은 쓰기 작업 중 일부만 성공한 후 결함이 생기면 어떤 일이 생기는지 이야기한다.

• 여러 쓰기 작업이 하나의 원자적인 트랜잭션으로 묶여 있는데 결함 때문에 완료(Commit) 될 수 없다면 Abort 되고 데이터베이스는 이 트랜잭션에서 지금까지 실행한 작업들을 무시 또는 취소해야 한다.
• 다시 말해, 전부 반영되거나 아무것도 반영되지 않는 것을 보장하는 것이다. 이로써 부분 실패를 걱정할 필요가 없게 도와준다.

원자성이 보장되지 않는다고 해보자. 여러 개의 쓰기 작업 중 일부만 성공하다가 실패한 상황이 발생했다면, 애플리케이션에서 이에 대한 처리를 직접 다 해주어야한다. 하지만 이것도 어려운게 어디서 부터 실패한지 알아내기 어렵고, 재시도 로직을 구성했다하더라도 멱등성이 보장되지 않는다면 중복 쓰기 등의 문제로 잘못된 데이터가 만들어질 수도 있다. 즉, 원자성이 보장되지 않는다면 데이터의 안정성도 보장되지 않을 뿐더러 애플리케이션 개발에서도 큰 힘듦을 겪어야 할 것이다.

Transaction에서 오류가 생겼을 때, Transaction을 어보트하고 기록한 모든 내용을 취소하는 능력은 ACID의 원자성에서 온 것이라고 볼 수 있다.

 

 

Consistency

일관성은 항상 진실이어야 하는, 데이터에 관한 어떤 불변식에 대해 이야기한다.

• 예를 들어 회계 시스템에서의 계좌들은 대변차변이 항상 맞아떨어져야 한다, 모든 고객의 계좌는 0 이상의 값을 가진다 등이 있다.

Transaction이 불변성이 다 지켜지는 데이터베이스에서 시작하고, 해당 Transaction 실행된 모든 쓰기 작업이 유효성을 보존한다면 불변식이 항상 만족한다고 확신할 수 있다. 즉, 일관성이 보장된다.

하지만 데이터 중심 애플리케이션 설계 책에서 말하길 일관성의 아이디어는 애플리케이션의 불변식 개념에 의존하고, 일관성을 유지하도록 트랜잭션을 올바르게 정의하는 것은 애플리케이션의 책임이라고 이야기한다. 즉, 일관성이란 데이터베이스가 보장할 수 없는 것이다.

• 위 예제의 계좌들의 대변차변같은 경우, 애플리케이션의 특성에 따른 불변식이며 데이터베이스가 이를 지키도록 보장할 수 없다는 것이다.

물론 외래키 제약조건 등 여러 제약조건을 사용해 데이터를 제한하는 경우가 있다. 그러나 일반적인 데이터의 불변식이라는 것은 애플리케이션에서 데이터가 유효한지 아닌지를 정의한다. 데이터베이스는 단순히 데이터를 저장할 뿐이다.

그러므로, 원자성(A), 격리성(I), 지속성(D)은 데이터베이스의 속성인 반면 일관성(C)은 애플리케이션의 속성이다.

• 애플리케이션에서 일관성을 달성하기 위해 데이터베이스의 원자성 및 격리성에 기대볼 수는 있지만 앞서 이야기했듯 데이터베이스만으로는 불가능하다.

 

 

Isolation

격리성은 동시에 실행되는 트랜잭션은 서로 격리된다는 것을 의미한다. 즉, 트랜잭션은 다른 트랜잭션을 방해할 수 없다.

과거의 교과서 등 자료에서는 격리성을 직렬성(Serializability)이라는 용어로 설명하는 경우가 있다. 즉, 전체 데이터베이스에서 실행되는 유일한 트랜잭션인 것처럼 동작할 수 있게 하는 것을 의미한다.

하지만 데이터베이스는 실제로 여러 트랜잭션이 동시에 실행될 수 있다. 만약 동시에 실행되었더라도 트랜잭션이 커밋됐을 때의 결과가 트랜잭션이 순차적으로 방해없이 실행됬을 때의 결과와 동일하도록 최대한 보장하는 것이 격리성이 의미하는 바라고 할 수 있다.

격리성을 보장하기 위해 Transaction을 동시에 실행요청이 들어오더라도 그냥 하나씩 실행시키면 안되나? 라고 생각할 수 있다. 이는 격리 수준 중 직렬성 격리(Serializable isolation) 를 의미하는데, 직렬성 격리는 성능 손해로 인해 현실에서는 거의 사용하지 않는다. 아예 구현조차 하지 않은 데이터베이스가 있을 정도다. 보통은 커밋 후 읽기, 스냅숏 격리 등 완화된 격리수준을 사용해 격리성을 보장한다.

 

 

Durability

지속성은 트랜잭션이 성공적으로 커밋됐다면 하드웨어 결함이 발생하거나 데이터베이스가 죽더라도 트랜잭션에서 기록한 모든 데이터는 손실되지 않는다는 보장이다.

• 즉, 데이터베이스는 데이터를 잃어버릴 염려가 없는 안전한 저장소를 제공하는 것이다.

지속성은 어떤 데이터베이스냐에 따라 의미하는 바가 다를 수 있다.

• 단일 노드 데이터베이스라고 하면 비휘발성 저장소에 기록한다 를 의미하고, 복제 기능이 있는 데이터베이스에서는 데이터가 다른 노드에 복사 되어 운영된다 를 의미할 수 있다.

지속성을 보장하기 위해서는 Transaction이 성공적으로 커밋되었다라고 보기하기 전에 쓰기 또는 복제가 완료될 때까지 기다려야 한다.

그럼 만약 비휘발성 메모리와 백업이 다 파괴된다면, 어떻게 되는걸까? 지속성을 보장할 수 있는 것일까?

• 당연히 데이터베이스가 할 수 있는 것은 없다. 현실에서 데이터를 절대적으로 보장할 수 없다. 단지, 저장/백업 등의 위험을 줄이려는 기법만 있을 뿐이다.
• 즉, 여기서 말하는 지속성 보장은 ‘이론적인' 지속성 보장으로 이해해야 한다. 하지만 당연히 지속성을 최대한 보장하기 위한 다양한 기법들을 제공해야 하고, 해야만 한다.

---

 

이렇게 ACID를 알아보았다. 각 개념에 대한 설명들을 읽어보면 당연하고 중요한 말들 같으면서도 추상적이라는 생각이든다.

데이터베이스 시스템이 ACID를 준수(ACID compliant)한다고 했을 때, 정확히 어떤 것을 기대할 수 있을지 알 수 있을까? 단순히 ACID의 개념으로 아! ACID 준수하니깐 안전하겠다 라는 생각은 하면 안된다. 데이터베이스 간 ACID 준수를 위한 구현 및 트랜잭션의 특성이 다를 수 있으니 잘 알아보고 사용하도록 하자.

---

References

• 데이터 중심 애플리케이션 설계