데이터베이스 동시성 제어: MVCC와 Lock-Based Concurrency Control

김상진 ·2024년 12월 18일
0

CS

목록 보기
19/30

데이터베이스 동시성 제어: MVCC와 Lock-Based Concurrency Control 완벽 분석

데이터베이스에서 동시성 제어는 여러 트랜잭션이 동시에 데이터에 접근할 때 발생할 수 있는 충돌을 방지하고, 데이터의 일관성(Consistency)무결성(Integrity)을 보장하기 위한 핵심 기법입니다. 이번 글에서는 동시성 제어의 대표적인 방식인 MVCC(Multi-Version Concurrency Control)Lock-Based Concurrency Control을 심층적으로 분석하고, 실무에서의 활용 사례까지 다뤄보겠습니다.


1. MVCC (Multi-Version Concurrency Control)

MVCC는 데이터의 여러 버전(Multi-Version)을 유지하며, 트랜잭션 간의 독립성을 보장하는 동시성 제어 방식입니다. 읽기 작업쓰기 작업을 분리해 동시성 문제를 최소화하는 데 특화된 방식입니다.

MVCC의 동작 원리

  • 트랜잭션 스냅샷:
    트랜잭션이 시작되면, 데이터의 스냅샷(시점별 데이터 상태)을 생성합니다. 이후 트랜잭션은 이 스냅샷을 기준으로 데이터를 읽습니다.
    • 결과적으로 트랜잭션이 실행되는 동안 다른 트랜잭션의 쓰기 작업에 영향을 받지 않습니다.
  • 버전 관리:
    데이터를 수정할 때 새로운 버전을 생성하며, 이전 버전은 삭제하지 않고 유지합니다.
    예:
    • 데이터 A = 100
    • 트랜잭션 T1이 A를 200으로 수정 → 데이터베이스는 버전 A(100)A(200)을 모두 유지.

MVCC의 장점

  1. 읽기 작업의 높은 성능

    • 읽기 작업 시 잠금을 사용하지 않으므로, 쓰기 트랜잭션과 병렬 처리가 가능합니다.
    • 읽기 지연(Read Latency)이 거의 없어, 읽기 중심의 애플리케이션에서 특히 유리합니다.
  2. 일관성 유지

    • 트랜잭션이 실행되는 동안, 시작 시점의 데이터 상태를 기준으로 데이터를 읽습니다.
    • 이를 통해 Repeatable Read와 같은 고급 격리 수준(Isolation Level)을 구현합니다.
  3. 팬텀 리드 방지

    • MySQL InnoDB와 같은 MVCC 구현체는 갭락(Gap Lock)넥스트키 락(Next-Key Lock)을 사용해 팬텀 리드(Phantom Read)를 방지합니다.

MVCC의 단점

  1. 저장 공간 증가
    • 여러 데이터 버전을 유지하므로, 저장 공간이 더 많이 필요합니다.
  2. 버전 관리 오버헤드
    • 불필요한 데이터 버전을 정리하는 Garbage Collection 과정이 필요합니다.

2. Lock-Based Concurrency Control

Lock-Based 방식은 데이터를 접근하거나 수정할 때 잠금(Lock)을 통해 다른 트랜잭션의 접근을 제한하여 동시성을 제어합니다.
트랜잭션 간의 데이터 충돌을 직접적으로 차단하는 방식입니다.

Lock-Based 방식의 동작 원리

  1. 잠금 유형

    • 공유 잠금(Shared Lock): 읽기 작업에서 사용. 여러 트랜잭션이 동시에 데이터를 읽을 수 있음.
    • 배타 잠금(Exclusive Lock): 쓰기 작업에서 사용. 데이터에 단독으로 접근하여 다른 트랜잭션의 접근을 차단.
  2. 트랜잭션 격리 수준

    • Lock-Based 방식은 데이터 잠금을 활용해 트랜잭션의 격리 수준을 구현합니다.
      예:
      • Read Uncommitted: 잠금 없이 읽기 허용. Dirty Read 가능.
      • Serializable: 엄격한 잠금 사용으로 팬텀 리드 방지.

Lock-Based 방식의 장점

  1. 강력한 데이터 무결성 보장
    • 트랜잭션이 직접 데이터를 잠금으로 보호하므로, 동시성 충돌을 철저히 방지합니다.
  2. 직관적인 동작
    • 데이터 잠금 상태를 명시적으로 확인할 수 있어, 문제 진단이 용이합니다.

Lock-Based 방식의 단점

  1. 성능 저하
    • 대량의 트랜잭션이 동일한 데이터에 접근할 경우, 잠금 대기 시간으로 인해 성능이 저하됩니다.
  2. 교착 상태(Deadlock)
    • 잘못된 잠금 순서나 설계로 인해 교착 상태가 발생할 위험이 있습니다. 이를 방지하기 위한 Deadlock Detection 또는 Timeout 전략이 필요합니다.

3. MVCC와 Lock-Based 방식의 조합: MySQL InnoDB

실제 데이터베이스 시스템에서는 두 방식을 조합하여 최적의 성능과 안정성을 추구합니다.
MySQL의 InnoDB 스토리지 엔진은 MVCCLock-Based Concurrency Control을 결합한 대표적인 예입니다.

InnoDB의 동시성 제어 전략

  1. 읽기 작업 (MVCC 활용)

    • 일관된 읽기(Consistent Read): MVCC를 활용하여 읽기 작업 시 잠금을 피합니다.
    • 트랜잭션이 시작된 시점의 데이터 스냅샷을 읽기 때문에, 읽기 작업은 쓰기 작업과 독립적으로 이루어집니다.
  2. 쓰기 작업 (Lock-Based 방식 활용)

    • 쓰기 작업은 잠금을 사용하여 데이터의 일관성과 무결성을 보장합니다.
    • 쓰기 작업이 끝날 때까지 다른 트랜잭션의 수정 작업을 차단해 충돌을 방지합니다.
  3. 팬텀 리드 방지

    • InnoDB는 갭락과 넥스트키 락을 활용하여, 범위 내 데이터 변경으로 인해 발생하는 팬텀 리드를 방지합니다.

4. 실무에서의 선택: MVCC vs. Lock-Based

  • MVCC를 우선적으로 사용하는 경우

    • 읽기 작업이 빈번하고, 쓰기 작업이 상대적으로 적은 시스템.
    • 예: 읽기 중심 애플리케이션, 대규모 분석 쿼리 처리 시스템.
  • Lock-Based 방식을 우선적으로 사용하는 경우

    • 쓰기 작업이 빈번하고, 데이터 충돌 방지가 중요한 시스템.
    • 예: 금융 거래 시스템, 재고 관리 시스템 등.
  • 혼합 사용 (MySQL InnoDB와 같은 방식)

    • 읽기와 쓰기 작업이 모두 중요한 시스템.
    • 예: 전자상거래 플랫폼, 대규모 ERP 시스템.

결론

동시성 제어는 데이터베이스 시스템의 성능과 안정성을 좌우하는 핵심 기술입니다. MVCC는 잠금 없이 높은 동시성을 제공하며, Lock-Based 방식은 데이터의 직접적인 무결성 보장이 장점입니다.
실제 환경에서는 애플리케이션의 특성에 맞춰 적합한 방식을 선택하거나, 두 방식을 조합해 최적의 성능과 안정성을 확보하는 것이 중요합니다.


출처 및 참고자료

profile
알고리즘은 백준 허브를 통해 github에 꾸준히 올리고 있습니다.🙂

0개의 댓글

관련 채용 정보