[백엔드 로드맵 - DB] ACID

Sierra·2022년 8월 8일

ACID db 공부노트 백엔드로드맵

Backend-Roadmap

목록 보기

30/43

Intro

이번 포스팅의 주제는 ACID, Atomicity, Consistency, Isolation, Durability 에 대해 다뤄 보도록 하겠다.

ACID란?

데이터베이스 내에서 일어나는 트랜잭션의 안전성을 보장하기 위해 필요한 성질이다.
특히 돈이 오가는 주식, 금융업계에서 이러한 성질이 보장되지 않는다면 심각한 금융 사고로 이어질 수 있다.
ACID는 데이터베이스에서 데이터를 처리할 때 발생할 수 있는 예외적인 상황을 줄이고, 데이터베이스의 무결성을 보호할 수 있다.

Atomicity

원자성이라고 부르는 성질이다. 트랜잭션과 관련 된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 성질이다.
하나의 트랜잭션에서 중간에 특정한 작업이 실패한다면, 그 트랜잭션은 유효라고 할 수 없다.

예를 들어 A가 B에게 송금을 한다면, A의 계좌에서 돈이 빠져나가고 B의 계좌에 돈이 들어가게 된다. 만약에 A의 계좌에서 돈이 빠져나갔음에도 불구하고 B의 계좌에 돈이 들어가지 않는다면? 심각한 에러이므로 트랜잭션이 성립하지 않아 거래는 취소된다.

Consistency

일관성이라고 부르는 성질이다. 트랜잭션이 성공적으로 끝난다면, 일관성 있는 DB상태로 유지해야 한다는 것을 의미한다.
즉 무결성 제약 조건에 위배되는 트랜잭션이 실행되는 것을 막기 위해 필요한 성질이다.

만약 계좌에 돈이 없는 상황에서 송금 트랜잭션을 처리하려고 했을 때, 계좌에 만약 잔고가 있어야 한다는 게 무결성 제약 조건이라면 해당 트랜잭션은 중단 되게 된다.

Isolation

독립성이라고 부르는 속성이다. 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못 하도록 하는 속성이다. 트랜잭션 외부의 연산은 중간 단계의 데이터를 절대 알 수 없다.

사실 이해하기 가장 어려운 속성인데, 간단히 얘기하면 트랜잭션이 1, 2, 3, 4가 거의 동시에 수행 되더라도 순서대로 수행 한 것 마냥 실행해야 한다는 것이다.

조금 더 알기 쉬운 예시를 들어보자면 현재 내 계좌에 돈이 만원이 있다. 이 상황에서 A, B 계좌에 각각 6천원을 이체하는 트랜잭션이 실행된다면, A에 먼저 송금한 후 B 계좌에 송금 한 결과와 동일해야 한다는 것이다.

각각의 트랜잭션은 다른 트랜잭션에 전혀 관여할 수 없는 독립적인 상태다. 즉 B 계좌에 송금하는 트랜잭션은 A 계좌에 대한 트랜잭션에 관여 할 수 없다. 또한 작업 내용또한 알 수 없다.

마치 연속적으로 실행 된 것 과 같은 상태가 유지 되어야 한다.

Durability

지속성이라고 부르는 속성이다. 성공적으로 수행 된 트랜잭션은 영원히 반영되어야 한다는 의미다. 모든 트랜잭션은 로그로 남고, 시스템 장애가 발생할 시 로그를 추적하여 전 단계로 되돌릴 수 있다. 트랜잭션은 로그에 모든 것이 저장된 후에 commit 상태로 간주 될 수 있다.

Concurrency Control

여러 트랜잭션이 들어오게 된다면 Concurrency(동시성)이라는 성질이 생긴다. 거의 동시에 많은 요청들이 들어오게 되는 경우가 반드시 있기 마련이다. 이런 상황에서 ACID 를 보장하기 위해서 필요한 기술이 Concurrency Control이다.

Concurrency Control은 다수의 사용자 사이에 동시에 작용하는 다중 트랜잭션의 상호 간섭 작용에서 DB를 보호하는 것을 의미한다.
Concurrency를 허용하게 된다면 Consistency가 낮아지게 된다. 너무나 많은 상호 간섭이 일어나게 될 테니까.

대표적인 Concurrency Control 기법으로 Lock 과 MVCC가 있다.

Lock

ACID를 보장하기 위해 어떠한 트랜잭션이 실행될 때 DB를 잠궈버리는 것을 의미한다.

상당히 극단적인 방법이다. 만약 수 많은 사용자들이 동 시간대에 요청한다면 계속해서 응답을 기다리다 지치는 경우가 생길 수 있다.

두 가지 방법이 있다.

Pessimistic Concurrency Control
- 사용자들이 동시에 같은 데이터를 수정할 것이라 가정한다.
- 데이터를 읽는 시점에 lock을 걸고, 트랜잭션이 완료 될 때 까지 유지한다.
Optimistic Concurrency Control
- 사용자들이 같은 데이터를 동시에 수정하지 않을 것이라 가정한다.
- 데이터를 읽는 시점에 lock을 걸지 않는 대신, 수정 시점에 값이 변경되었는지를 검사한다.

MVCC

Lock의 대안. Multi Version Concurrency Control의 약자. 다중 버전 동시성 제어라고도 부른다.

메커니즘은 다음과 같다.

데이터에 사용자가 접근한 시점에서 DB의 Snapshot을 읽는다.
Snapshot 데이터에 대한 변경이 완료 될 때 까지 만들어진 변경사항은 다른 DB 사용자가 볼 수 없다.
데이터가 업데이트 된다면 이전의 데이터를 덮어 씌우는 게 아니라 새로운 버전의 데이터를 UNDO 영역에 생성한다. 변경 된 데이터를 따로 기록한다.
다른 사람이 데이터에 접근 할 때마다 데이터에 대한 여러 버전의 데이터가 쭉 생성되게 된다.
사용자는 마지막 버전의 데이터를 읽게 된다.

MVCC를 사용하게 되면 사용하지 않는 데이터가 생기므로 데이터를 정리하는 시스템이 필요하다. 또한 데이터 버전이 충돌하는 경우가 생긴다면 애플리케이션 영역에서 이 문제를 해결해야 한다.

Oracle, MySQL등 주로 쓰이는 RDBMS에서 해당 기능을 지원하고 있다.