MySQL에서 ACID를 보장하는 방법

개요

MySQL과 같은 RDB는 안전하고 신뢰할 수 있는 트랜잭션을 보장하기 위해 ACID 성질을 핵심 원칙으로 삼고 이를 구현하고 있다. 보통 ACID 성질은 아래와 같이 정의된다.

• Atomicity (원자성): 트랜잭션의 모든 작업은 전부 처리되거나, 하나도 처리되지 않아야 한다.
• Consistency (일관성): 트랜잭션이 완료된 후, 데이터베이스는 일관된 상태(규칙, 제약 조건)를 유지해야 한다.
• Isolation (독립성): 동시에 수행되는 여러 트랜잭션은 서로 영향을 미치지 않고 독립적으로 동작해야 한다.
• Durability (지속성): 성공적으로 완료된 트랜잭션의 결과는 영구적으로 반영되어야 한다.

정의에 대해서는 잘 알고있지만, 데이터베이스에서 이를 어떻게 보장하고 있는지 자세한 내용을 공부해보진 않았던 거 같다. 갑자기 궁금하기도 해서 블로그 글을 작성하면서 관련 내용을 정리했다.

 

ACID에서 가장 중요한 것은 Undo 로그와 Redo 로그이다. 이를 기반으로 모든 특성을 보장하고 있기 때문이다. MySQL에서는 이 두 개의 로그로 원자성과 지속성, 독립성을 보장한다. 이 두 로그의 존재 이유는 무엇일까? 이를 먼저 알아보기 위해서는 MySQL의 아키텍처와 버퍼 관리 정책에 대해서 먼저 알아야 한다.

 

MySQL의 아키텍처

먼저 ACID에 대해서 이야기 하기전에 간단하게나마 MySQL의 아키텍처 구조를 살펴보면 아래와 같다. 질의 처리기가 실제로 SQL을 해석하고, 검증 및 최적화하는 구간이며, 실제로 SQL을 실행하면서 발생하는 데이터 삽입, 수정, 삭제, 조회 등의 물리적인 처리를 수행하는 것은 질의 처리기 아래 계층인 '저장 시스템'이 담당한다.

 

저장 시스템에는 흔히 아는 InnoDB와 같은 스토리지 엔진이 활용되며, 이외에도 MyISAM, Memory 등이 존재한다. 그림에서는 디스크까지를 InnoDB라고 표현했지만 정확히는 페이지 버퍼와 로그 버퍼가 포함된 영역이 '저장 시스템'이고, 그 아래는 디스크로 InnoDB가 관리할 뿐 InnoDB 자체에 포함되는 영역은 아니다.

 

즉, 그림은 InnoDB가 관리하는 논리적인 영역을 표시한 것이라고 보면 된다.

 

데이터베이스는 기본적으로 디스크에 데이터 파일들을 저장하여 관리하지만, 성능을 위해 일부분은 메인 메모리에 유지한다. 또한, 데이터베이스는 디스크 입출력 효율을 위해 데이터를 고정 크기의 페이지(Page) 단위로 저장하고 조회하기 때문에, 메인 메모리에 관리되는 데이터 역시 페이지 단위로 나뉘어 '페이지 버퍼(InnoDB 공식은 버퍼 풀)'를 통해 관리된다.

 

버퍼 관리 정책

버퍼 관리 정책에는 Steal, No-Steal, Force, No-Force가 존재하는데, 각각의 설명은 아래와 같다.

• Steal: 어떠한 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
• No-Steal: 모든 수정된 페이지는 적어도 트랜잭션의 커밋 후 종료 시점까지는 페이지 버퍼에 유지해야 하는 정책
• Force: 트랜잭션 커밋 시 수정된 모든 페이지를 곧바로 디스크에 반영해야 하는 정책
• No-Force: 트랜잭션 커밋이 일어나도 수정된 모든 페이지를 디스크에 곧바로 반영하지 않는 정책

현재 존재하는 거의 모든 데이터베이스는 버퍼 관리 정책을 Steal, No-Force 정책으로 관리하고 있다. 그 이유는 간단하게 말하면 성능 때문이다. No-Steal의 경우에는 트랜잭션이 길게 유지되거나, 데이터 크기가 큰 경우 수정된 데이터가 페이지 버퍼의 용량을 초과하는 일이 발생할 수 있고, Force의 경우에는 모든 페이지를 곧바로 디스크에 반영하니 그만큼 다량의 디스크 I/O가 한번에 발생할 수 있다.

 

성능을 위해 Steal + No-Force 정책을 선택했지만, Steal 정책으로 인해 롤백이 일어날 트랜잭션의 데이터도 디스크에 반영될 수 있고, No-Force 정책으로 인해 커밋되었음에도 디스크에 반영되지 않고 종료되어 문제가 생길 수 있다. 이를 위해서 필요한 것이 각각 Undo 로그와 Redo 로그이다.

 

데이터베이스 로깅 방식

그럼 로그는 어떤 방식으로 기록될까? 로그 기록 방식은 대표적으로 세 가지로 분류된다. 각각 '물리적 상태 로깅', '물리적 전이 로깅', '논리적 전이 로깅'이다.

 

물리적 상태 로깅

상태 변화 이전 이미지와 변화 후의 이미지를 함께 로깅하는 방법이다. 예를 들어 a라는 컬럼이 1에서 2로 변화했다면 하나의 로그 레코드는 a컬럼이 존재하는 물리적인 페이지의 n번지의 이전 값인 1과 이후 값인 2를 함께 기록한다.

 

이를 통해 Undo가 필요할 땐 이전 이미지를, Redo가 필요한 경우에는 이후 이미지를 통해 값을 복구한다.

 

물리적 전이 로깅

XOR 연산의 차이값만 기록하는 방식이다. 복구 시점에 로그 레코드에 기록된 이미지를 XOR 값과 비교하여 복구를 수행한다.

 

논리적 전이 로깅

해당 방식은 값을 기록하는 것이 아니라 '어떤 일'을 수행했는지 기록하는 방법이다. a = a + 1과 같은 연산을 로깅할 수도 있고, 이전 값 1, 이후 값 2와 같은 값을 로깅할 수도 있다.

 

해당 로깅은 물리적 로깅과 다르게 실제 물리적인 위치를 저장하지 않고 ’A 테이블의 B 컬럼‘과 같이 논리적으로 대상을 표현한다.

 

그래서 B-Tree, B+Tree의 SMO 연산으로 물리적 위치가 자주 변하는 경우에 로깅 시점과 복구 시점에 위치가 다른 경우를 방지할 수 있다.

 

이 세 가지 로깅 방식 중 MySQL에서는 Undo 로그에는 논리적 전이 로깅을 Redo 로그에는 물리적 상태 + 전이 로깅을 활용하고 있다.

 

그 이유는 장애로 인한 복구 시에, 표준 복구 알고리즘인 ARIES 방식을 따르기 때문이다. 해당 알고리즘은 Redo 로그를 활용해 물리적 위치에 데이터를 먼저 때려박은 후에 Undo 로그로 아직 끝나지 않은 트랜잭션을 롤백 시키는 과정을 거친다.

 

좀 더 자세히 살펴보면, B-Tree의 구조가 변경되는 SMO 연산 중 장애가 났다면 트리의 물리적 연결이 손상된채(포인터 연결에 실패 등)로 서버가 재가동된다. 이럴때는 논리적 위치로 레코드를 찾지 못할 가능성이 높다. 그래서 물리적 위치에 레코드를 박아넣고, B-Tree를 복구한 후에 논리적 위치를 통해 끝나지 않은 트랜잭션을 롤백하는 것이다.

 

이렇게 복구를 위해 로그를 활용하기 때문에 모든 데이터는 WAL(Write-Ahead Log) 규칙을 따라 데이터보다 로그를 먼저 디스크에 기록한다.

 

Durability (지속성)

MySQL에서는 위의 지식을 기반으로 지속성을 보장하고 있다. 트랜잭션 커밋 시점에 로그 버퍼에 있는 해당 트랜잭션의 로그 데이터들은 모두 디스크에 작성되며, fsync()와 같은 시스템 콜을 통해 물리적 디스크에 완전히 동기화 되었음을 확인한 후에야 커밋이 완료된 것으로 인정한다. 커밋 시점 이외에도 WAL이 필요한 경우, 로그 버퍼가 가득 찬 경우, DBMS 내부적으로 필요로 하는 경우에도 로그 버퍼에 있는 로그 데이터들이 디스크에 작성된다.

 

이 과정에서 서버의 장애가 나서 MySQL이 비정상 종료되었다면, 해당 트랜잭션의 커밋은 수행되지 않은 것으로 판단해 롤백으로 복구를 처리하게 된다. 반대로 동기화가 완료되었지만, 데이터 파일에는 반영되지 않았다면 커밋 성공으로 판단해 Redo 로그를 통해 데이터를 복구한다.

 

Atomicity (원자성)

원자성은 대표적으로 3가지 발생 가능성이 존재한다.

• 트랜잭션 커밋
• 트랜잭션 롤백
• 트랜잭션 진행 중 장애

이 중에서 트랜잭션 커밋 상황의 경우에는 위 내용에서 이미 어느정도 파악할 수 있기 때문에, 롤백과 진행 중 장애 상황에 대해서만 얘기해보고자 한다.

 

트랜잭션 롤백

트랜잭션 롤백의 경우에는 사용자가 명시적으로 ROLLBACK을 호출했거나, 수행 도중 하나의 연산이 실패한 경우가 있을 수 있다. 이런 경우에는 시스템 자체는 정상적으로 동작하는 것이기 때문에 해당 트랜잭션의 번호를 기반으로 Undo 로그를 역방향 탐색하여 데이터들을 롤백한다.

 

데이터들을 롤백하면서, Undo 작업에 대한 보상 로그 레코드도 함께 Redo 로그에 추가한다. 이는 롤백 중 장애로 인해 서버가 종료되었을 때 재시동하면서 했던 Undo 작업을 다시 하지 않기 위해서이다. 예를 들면 100개의 Undo 작업을 수행해야 하는 상황에서 50개 정도 수행했을 때 서버가 재시동되면 보상 로그 레코드가 없는 경우에 다시 첫 번째 Undo 작업부터 처리해버릴 수 있다. 하지만, 이러한 보상 로그 레코드를 통해서 작업의 진행 정도를 기록하여 중복 Undo 작업을 방지한다.

 

트랜잭션 진행 중 장애

해당 상황에서는 트랜잭션이 커밋되지 않고 종료되었기 때문에 롤백의 과정과 비슷하게 진행된다. 다만, 진행 도중 데이터의 물리적인 구조(B-Tree 등)가 손상되었을 가능성이 있기 때문에, 먼저 Redo 로그를 통해 장애 발생 직전의 상태로 물리적 복구를 진행한 후에 논리적인 롤백(Undo)을 수행한다.

 

만약 로그 버퍼의 내용이 디스크에 기록되기도 전에 장애가 발생해 유실된 경우에는 어떻게 될까? 데이터베이스는 이를 '성공적으로 커밋되지 않은 미완성 트랜잭션'으로 간주한다. 따라서 유실된 데이터를 굳이 살려낼 의무가 없으며, 오히려 원자성을 보장하기 위해 아예 없던 일로 무효화 처리하는 것이 올바른 동작이다.

 

Isolation (독립성)

독립성은 위의 Undo, Redo 로그를 기반으로 더 많은 지식을 요구한다. 주요 개념으로는 MVCC, 락, 격리 수준, 읽기 현상 등이 있다. 먼저 해당 개념에 대해서 알면 독립성에 대해서 이해할 수 있다.

Read Phenomena (읽기 현상)

Dirty Read

이는 커밋되지 않은 결과를 읽는 것으로, 각 트랜잭션이 서로 독립적이지 않아 발생한다.

 

그림에서 볼 수 있듯이 Tx1은 아직 커밋되지 않은 Tx2의 변경 사항을 읽기 때문에 Tx2가 롤백 되었을 때 사실상 존재하지 않은 변경 사항을 읽게 된 것이라 큰 문제로 이어질 수 있다.

 

Non-Repeatable Read

다른 트랜잭션이 커밋한 데이터로 인해 같은 데이터 조회를 수행했음에도 서로 다른 데이터를 읽어버릴 수 있는 문제이다. 즉, 같은 트랜잭션 안에서 동일한 조회를 두 번 수행한 결과가 다른 것이다.

 

해당 현상으로 인해 합계를 구하는 조회의 경우 두 개의 합계가 서로 다르게 나오는 경우가 발생할 수도 있다.

 

Phantom Read

Phantom Read는 Non-Repeatable Read와 비슷하지만 레코드 단위가 아니라 범위 검색이라는 차이점이 있다. 그래서 기존 행이 변경되는게 아니라 새로운 행이 발견되는 것이다.

 

트랜잭션 격리 수준

SQL 표준에서 격리 수준은 4단계로 나뉘어진다.

 

Read Uncommited

다른 트랜잭션의 미커밋 데이터에 접근할 수 있는 격리 수준이다. 가장 낮은 독립성을 가진 격리 수준이며 위에서 얘기한 Dirty Read나 Non-Repeatable Read, Phantom Read와 같은 문제가 발생할 수 있다. 데이터 일관성이 보장되지 않기 때문에 권장되지 않는다.  PostgreSQL에서는 공식적으로 해당 격리 수준을 지원하긴 하나 내부 구현은 Read Commited로 동작하게 되어있다.

 

Read Commited

이름 그대로 커밋된 데이터만 접근할 수 있는 격리 수준이다. Dirty Read 문제는 막을 수 있지만, Non-Repeatable Read, Phantom Read 문제는 막지 못한다.

 

Repeatable Read

MySQL의 기본 격리 수준이다. MVCC를 통해 수행되는 트랜잭션의 격리를 보장한다. 해당 격리 수준에서는 Dirty Read, Non-Repeatable Read 문제를 막을 수 있다. Phantom Read는 막을 수 없는데, MySQL에서는 MVCC를 활용하기에 특정 상황에서만 Phamtom Read가 일어난다.

 

특정 상황이라함은 select ... for update와 같은 쓰기 잠금을 걸고 조회를 수행할 때를 말한다. 일반적으로 조회할 때 MVCC는 기본적으로 Undo 로그를 통해 해당 트랜잭션이 바라봐야 하는 시점의 과거 데이터를 가져온다. 하지만 for update를 통해 조회하면 조회하는 레코드에 락을 걸어야 하지만 백업 데이터인 Undo 로그 레코드에는 락을 걸 수가 없다.

 

따라서 이 경우에는 어쩔 수 없이 Undo 로그가 아닌 현재 시점의 실제 테이블 레코드에 락을 걸고 조회하기에 Phantom Read가 발생할 수 있는 것이다.

 

Serializable

가장 단순한 격리 수준이면서 동시에 가장 엄격한 격리 수준이다. 한 트랜잭션에서 읽고 쓰는 데이터는 동시에 다른 트랜잭션에서 절대 접근할 수 없다. 그만큼 동시 처리 성능도 낮아진다.

 

이러한 격리 수준은 명세이기에 이를 구현하는 방법으로 'Lock (잠금)'이라는 매커니즘을 활용한다.

 

Lock (잠금) 매커니즘

데이터베이스가 앞서 설명한 격리 수준을 물리적으로 구현하고 동시성 문제를 제어하기 위해 사용하는 핵심 방법이 바로 Lock이다. 동시성 충돌을 바라보는 관점에 따라 크게 비관적 동시성 제어와 낙관적 동시성 제어로 나눌 수 있다.

 

비관적 동시성 제어

트랜잭션 간 충돌이 반드시 발생한다고 가정하고, 데이터를 읽거나 쓸 때 아예 처음부터 잠금을 걸어서 트랜잭션이 완료될 때까지 이를 유지하여 다른 트랜잭션의 접근을 물리적으로 막아버리는 방식이다. 잠금의 단위는 행 잠금부터 페이지 잠금, 테이블 잠금까지 다양하게 존재한다.

 

낙관적 동시성 제어

트랜잭션 간 충돌이 드물다고 가정하여, 잠금없이 자유롭게 읽고 쓰면서 트랜잭션이 커밋되는 시점에 충돌이 있었는지 검증하는 방식이다. 잠금 유지 비용이 없으니 대기 시간이 없고 처리 성능이 높아진다.

 

다만, 커밋 시점에 다른 트랜잭션이 수정했다는 충돌이 발생하면 롤백된다.

 

MVCC (다중 버전 동시성 제어)

현대 데이터베이스는 잠금 매커니즘 중 하나만으로 격리 수준을 구현하지 않고, 두 동시성 제어를 결합한 MVCC를 활용한다. 이는 원본의 데이터와 변경 중인 여러 데이터를 동시에 유지하는 방식으로 앞서 다루었던 Undo 로그가 핵심적인 역할을 한다.

 

예를 들어 트랜잭션 A가 a = 10인 레코드를 a = 11로 변경하는 쓰기 작업을 진행 중이라고 가정해보자. 이때 이 레코드에는 비관적인 쓰기 잠금이 걸린다. 하지만 이와 동시에 트랜잭션 B가 해당 레코드를 조회할 때, MVCC는 트랜잭션 B를 대기 시키지 않는다. 대신 Undo 로그에 백업된 변경 전 과거 데이터를 찾아 반환한다.

 

Undo 로그가 논리적인 전이 로깅 방식으로 기록하기에 어떻게 과거 데이터를 반환하는지가 궁금해서 찾아보았는데, 이는 역연산을 이용해서 찾아온다.

 

정리하면, 읽기 작업은 낙관적 특성을 활용해 과거의 스냅샷을 통해 락 없이 처리하고, 쓰기 작업은 비관적 특성을 활용해 락을 걸어 충돌을 방지한다. MySQL의 Repeatable Read 격리 수준이 바로 이 MVCC를 기반으로 동작한다.

 

InnoDB의 특별한 잠금: Gap Lock과 Next-Key Lock

MVCC를 통해 락 없는 읽기를 보장하더라도, 앞서 설명한 SELECT ... FOR UPDATE와 같이 명시적인 쓰기 잠금을 걸어야 하는 상황에서는 어쩔 수 없이 실제 테이블 레코드에 잠금을 걸게 되며, 이로 인해 Phantom Read 현상이 발생할 수 있다고 언급했다.

 

하지만 MySQL은 이런 상황에서도 데이터 정합성을 지키기 위해 단순한 행 단위 잠금(Record Lock)을 넘어선 특별한 락 메커니즘을 사용한다.

1. 레코드 락 (Record Lock): 인덱스 레코드 자체에만 거는 기본적인 잠금이다.
2. 갭 락 (Gap Lock): 실제 존재하는 레코드가 아니라, 인덱스 레코드 사이의 빈 공간(Gap)을 잠그는 기술이다. 이 공간에 다른 트랜잭션이 새로운 데이터를 INSERT하는 것을 원천 차단한다.
3. 넥스트 키 락 (Next-Key Lock): InnoDB가 Repeatable Read 환경에서 범위 검색 시 주로 사용하는 잠금으로, 레코드 락과 갭 락을 결합한 형태이다. 특정 레코드뿐만 아니라 그 레코드 앞의 간격까지 함께 잠가버린다.

결론적으로, MySQL은 Repeatable Read 격리 수준에서 기본적으로 MVCC를 통해 높은 동시성을 제공하면서도, 범위 검색이나 배타적 락이 필요한 순간에는 넥스트 키 락을 동원하여 빈 공간(Gap)까지 틀어막음으로써 Phantom Read를 최대한 억제하고 데이터의 독립성(Isolation)을 철저하게 지켜낸다.

 

Consistency (일관성)

마지막으로 ACID의 'C'에 해당하는 일관성(Consistency)이다. 앞서 살펴본 원자성(A), 고립성(I), 지속성(D)이 데이터베이스 엔진(InnoDB의 로그, 버퍼, 락 등)의 시스템적인 메커니즘을 통해 강제적으로 보장된다면, 일관성은 조금 결이 다르다.

 

일관성은 트랜잭션이 완료된 후 데이터베이스의 상태가 사전에 정의된 '규칙'을 위반하지 않아야 함을 의미한다. 기본적으로 데이터베이스가 제공하는 제약조건(Primary Key, Foreign Key, Unique, Not Null 등)을 통해 기본적인 무결성이 지켜진다.

 

하지만 진정한 의미의 일관성은 여기에 더해 애플리케이션 레벨의 비즈니스 로직(예: 계좌 이체 시 두 계좌 잔액의 합은 항상 같아야 한다)이 올바르게 설계되고 검증되어야만 완벽하게 보장될 수 있다. 즉, 일관성은 데이터베이스의 기능과 개발자의 올바른 설계가 합쳐져서 완성되는 영역이다.

 

마치며

지금까지 데이터베이스가 ACID라는 강력한 원칙을 어떻게 내부적으로 구현하고 보장하는지 살펴보았다. 단순히 추상적인 개념으로만 알고 있던 ACID가, 실제로는 InnoDB의 버퍼 관리 정책(Steal/No-Force)을 바탕으로 Redo/Undo 로그라는 치열한 복구 메커니즘을 거치고, MVCC와 정교한 잠금 메커니즘을 통해 완성된다는 사실을 알 수 있었다.

 

데이터베이스의 깊은 내부 동작 원리를 이해하는 것은, 동시성 이슈나 장애 상황에 직면했을 때 근본적인 원인을 파악하고 더 안정적인 애플리케이션을 설계하는 든든한 밑거름이 될 것이다.