[Database] 동시성 제어(Concurrency Control) - MVCC

여러 트랜잭션이 동시에 데이터베이스에 접근하여 작업을 수행하려고 할 때, 데이터의 일관성을 유지하고 오류를 방지하는 방법 (동시에 작용하는 다중 트랜잭션의 상호간섭 작용에서 Database를 보호하는 것) 을 동시성 제어(Concurrency Control) 라고 합니다. 그러면 이러한 방법에 대한 종류는 어떤 것이 있을까?! 지금부터 그것을 알아보러 떠나봅시다.

주로 사용되는 방법은 다중 버전 동시성 제어 (MVCC, Multi-Version Concurrency Control)과 잠금 기반 동시성 제어 (Lock-based Concurrency Control)이 있습니다. 그러면 이제 하나하나 자세하게 알아볼까요??

1. 동시성 제어의 목적

정의: 여러 트랜잭션이 동시에 데이터베이스에 접근해도 데이터의 일관성과 무결성을 보장하면서, 성능과 효율성을 유지하는 것이 목적입니다.

1. 분실된 갱신(Lost Update)
   • 문제 상황: 두 트랜잭션이 같은 데이터를 읽고 수정한 후 저장하면, 먼저 저장된 결과가 나중 저장으로 덮여짐.
     • T1: A = 100 읽음 → A = A+10 → 저장
     • T2: A = 100 읽음 → A = A+20 → 저장
       → 결과: A=120 (T1의 10은 사라짐)
2. 모순성(Inconsistency)
   • 문제 상황: 두 트랜잭션이 동시에 실행되어 데이터가 불일치하거나 오류 상태에 빠지는 경우.
     • T1은 잔고를 차감하고, T2는 동시에 차감하여 최종 잔고가 잘못됨
3. 연쇄복귀(Cascading Rollback)
   • 문제 상황: 한 트랜잭션이 실패하여 롤백되면, 그 트랜잭션 결과를 참조한 다른 트랜잭션도 연쇄적으로 롤백되는 상황.
     • T1이 A값을 변경 (커밋 안됨)
     • T2가 A를 참조 → T1 실패로 롤백
     • T2도 영향을 받아 롤백
4. 비완료 의존성(Uncommitted Dependency)
   • 문제 상황: 커밋되지 않은 데이터(잠정값)를 다른 트랜잭션이 읽고, 그 값을 기반으로 처리하면 오류 발생 가능.
     • T1이 A=500 → 600으로 변경했지만 아직 커밋 안 됨
     • T2가 A=600 사용
     • T1이 롤백 → T2는 잘못된 A 사용

---

2. MVCC (Multi-Version Concurrency Control)

MVCC는 원본의 데이터와 변경 중인 데이터를 동시에 유지하는 방법으로, 원본 데이터에 대한 Snapshot을 백업하여 보관하고, 두 가지 버전의 데이터가 존재하는 상황에서 사용자가 데이터에 접근하면 데이터베이스의 Snapshot을 읽습니다. 즉 기존의 데이터를 덮어씌우는 것이 아닌 기존의 데이터를 바탕으로 이전 버전의 데이터와 비교하여 변경된 내용을 기록하는 방법으로, 여러 버전의 데이터가 존재하게 되거나 사용자는 마지막 버전의 데이터를 읽게 됩니다.

MVCC 의 특징

특징
Snapshot Isolation	각 트랜잭션은 시작 시점의 데이터를 기준으로 고정된 스냅샷을 읽습니다. 이후 다른 트랜잭션의 변경 사항은 영향을 주지 않아, 일관된 데이터를 읽을 수 있습니다.
Non-blocking Read	읽기 작업은 쓰기 작업을 막지 않고, 쓰기 작업도 읽기 작업에 방해받지 않습니다. 따라서 동시성이 높아지고, 락 경합이 줄어듭니다.
트랜잭션 내 읽기 일관성 보장	트랜잭션이 실행되는 동안 동일한 질의 결과는 항상 같은 데이터를 반환합니다. 단, Read Committed 수준에서는 커밋된 최신 데이터만 반영되어 결과가 달라질 수 있습니다.

 

PostgreSQL에서 MVCC 의 작업 방식 예제

https://vladmihalcea.com/how-does-mvcc-multi-version-concurrency-control-work/

1. Alice와 Bob은 모두 새 트랜잭션을 시작하고, txid_current() PostgreSQL 함수를 호출하여 트랜잭션 ID를 확인할 수 있습니다.
2. Alice가 새 글 행을 삽입하면 xmin 열 값이 Alice의 트랜잭션 ID로 설정됩니다.
3. 기본 읽기 커밋 격리 수준에서, Bob은 앨리스가 트랜잭션을 커밋할 때까지 앨리스가 새로 삽입한 레코드를 볼 수 없습니다.
4. Alice가 커밋한 후, Bob은 이제 Alice가 새로 삽입한 행을 볼 수 있습니다

⇒ 즉 이처럼 MVCC는 각 트랜잭션이 시작될 때, 그 시점의 스냅샷(Snapshot)을 생성합니다. 이 스냅샷은 다음을 보장합니다:

• 읽기 일관성 (Read Consistency): 트랜잭션은 자신이 시작된 시점의 데이터 버전만 볼 수 있고, 이후 다른 트랜잭션이 데이터를 수정하거나 삭제해도 그 트랜잭션에는 영향 없음.
• 쓰기 충돌 최소화: 각 트랜잭션은 자신만의 버전에서 작업하며, 커밋 시점에만 충돌을 체크함.

---

MySQL에서의 MVCC(Multi-Version Concurrency Controll)

MySQL의 InnoDB에서는 Undo Log를 활용해 MVCC 기능을 구현해보자.

CREATE TABLE member (
    id INT NOT NULL,
    name VARCHAR(20) NOT NULL,
    area VARCHAR(100) NOT NULL,
    PRIMARY KEY(m_id),
    INDEX idx_area(area)
)

INSERT INTO member(id, name, area) VALUES (1, "Dohyun", "Pohang");

이러면 데이터는 메모리와 디스크에 해당 데이터가 동일하게 저장이 된다.

 

그리고 다음과 같이 시작한다고 가졍해보자,

UPDATE member SET area = "Seoul" WHERE id = 1;

 

해당 Updata 문을 실행한 결과는 사진과 같다. 먼저 COMMIT 실행 여부와 무관하게 InnoDB 버퍼 풀은 새로운 값으로 갱신되고, Undo Log에는 변경 전에 값만 복사된다. InnoDB 버퍼 풀의 내용을 백그라운드 쓰레드를 통해서 디스크에 기록이 된다. 하지만 반영 여부는 시점에 따라 달라질 수 있다.

따라서,

SELECT * FROM member WHERE id = 1; 

하게 되면,

- READ_UNCOMMITTED에서는 버퍼 풀의 변경된 데이터 읽기 → Dirty Read 발생
- READ_COMMITTED 이상(REPEATABLE_READ, SERIALIZABLE) → Undo Log 기반으로 커밋 전 데이터 복원
- Undo Log는 참조되지 않으면 삭제가 되어 집니다.

 

그럼 다음은 잠금 기반 동시성 제어 (Lock-based Concurrency Control)에 대해서 배워보도록 합시다!

 

다음 글이 궁금하다면?

2025.07.15 - [BackEnd🍃/DB & SQL] - [Database] 동시성 제어(Concurrency Control) - Locking

[Database] 동시성 제어(Concurrency Control) - Locking