락⭐

경쟁 상태 (race condition)

• 두 개 이상의 프로세스나 스레드가 동시에 공유 자원에 접근할 때 발생할 수 있는 문제로

  실행 순서에 따라 결과가 달라지는 비결정적 상황을 의미한다.

  int counter = 0;
  
  void thread1() { counter += 1; }
  
  void thread2() { counter += 1; }
  

  • 스레드가 동시에 실행되었을 때 경쟁 상태가 발생하면 counter = 1이 나올 수 있다.

• 공유 자원에 대한 읽기-수정-쓰기(read-modify-write) 연산이 원자적으로 수행되지 않을 때 주로 발생

• 이를 해결하기 위해서는 주로 '상호 배제'가 보장되어야 한다.

• 공유 자원은 여러 프로세스나 스레드가 동시에 접근할 수 있는 데이터나 장치이다.

  • 데이터베이스의 테이블, 레코드, 메모리의 특정 변수, 파일 등

상호 배제 (mutual exclusion)

• 한 번에 하나의 프로세스나 스레드만 공유 자원에 접근할 수 있도록 하는 것
• 상호 배제 구현 방법

  • 락 (Lock)

    lock.lock();     // 락 걸기 (자원 사용 시작)
    try {
        // 자원 사용
    } finally {
        lock.unlock(); // 락 해제
    }
    

    • 가장 기본적인 상호 배제 메커니즘
    • 임계 영역에 진입하기 전에 락을 획득하고, 작업이 끝난 후 해제하여 하나의 자원에 대한 동시 접근을 막는다.

  • 세마포어 (Semaphore)

    Semaphore sem = new Semaphore(3);
    sem.acquire();   // 자원 사용 전 - 카운터 감소
    // 자원 사용
    sem.release();   // 자원 사용 후 - 카운터 증가
    

    • 정수 값을 기반으로 여러 스레드의 접근을 제어하며, 지정된 수만큼 동시 접근을 허용할 수 있다.
    • 바이너리 세마포어(값이 0 또는 1인 세마포어)는 락과 유사하게 동작한다.

  • 모니터 (Monitor)

    synchronized(공유자원) {
        // 해당 자원을 사용하는 코드
    }
    

    • 언어 수준에서 제공하는 동기화 구조
    • Lock과 조건 변수를 함께 포함한 고수준 동기화 구조
    • Java의 synchronized 블록이 이에 해당

원자성(Atomicity) 보장 방법

• 락 없이도 동시성 문제를 해결할 수 있는 대안적 기법
• 원자적 연산 (Atomic Operations)
  • CPU 수준에서 지원하는 원자적 명령어(CAS, Compare-And-Swap 등)를 사용하여 락 없이도 안전한 연산이 가능하다.
• 트랜잭션 메모리 (Transactional Memory)
  • 메모리 접근을 트랜잭션으로 관리하여 원자성을 보장한다.
• AtomicInteger 등의 사용은 Lock-Free 프로그래밍의 예시로, 성능 병목을 줄이는 데 유리하다

데드락(Deadlock) 방지

• 데드락이란, 여러 개의 프로세스 또는 스레드가 서로가 가진 자원을 기다리면서 영원히 작업을 끝내지 못하는 상태이다.
  • Thread 1 : 자원 1 보유 ⇒ 자원 2 기다리는 중
  • Thread 2 : 자원 2 보유 ⇒ 자원 1 기다리는 중
  • 이 상태로 영원히 멈추는 것을 데드락(교착 상태)이라고 한다.
• 경쟁 상태를 해결하기 위해 락을 사용할 때는 데드락 발생 가능성을 고려해야 한다.
• 데드락이 발생하는 조건은 아래 4가지 조건이 모두 만족할 때 발생한다.
  • 상호 배제 : 자원은 한 번에 하나의 프로세스(스레드)만 사용 가능
  • 점유 대기 : 자원을 가진 채로 다른 자원을 기다린다.
  • 비선점 : 자원을 강제로 뺏을 수 없음
  • 환형 대기 : 서로가 서로의 자원을 기다림
• 락 획득 순서를 일관되게 유지하거나, 타임아웃을 설정하여 데드락을 방지할 수 있다.

언어 및 프레임워크 수준의 지원

• Java
  • synchronized, volatile, java.util.concurrent 패키지(ReentrantLock, AtomicInteger 등)
  • Java에서는 'synchronized' 키워드를 사용하여 메서드나 블록을 동기화할 수 있다.
  • 또한, 'ReentrantLock' 클래스를 사용하여 보다 세밀한 제어를 할 수도 있다.
• C++
  • std::mutex, std::atomic, std::lock_guard
• 데이터베이스
  • 트랜잭션 격리 수준, 락(SELECT FOR UPDATE 등)

분산 시스템에서의 경쟁 상태 해결

• 경쟁 상태는 MSA 환경에서도 발생한다.
• 분산 락 (Distributed Lock)
  • Redis, ZooKeeper 등을 사용하여 여러 서버 간 상호 배제를 구현하는 것
• 최종 일관성 (Eventual Consistency)
  • 분산 환경에서 일시적인 데이터 불일치를 허용하되, 시간이 지나면 결국 일관된 상태로 수렴하도록 보장하는 일관성 모델
• CRDT (Conflict-free Replicated Data Type)
  • 충돌 없이 분산 데이터를 병합할 수 있는 자료구조를 사용하는 것

• 경쟁 상태를 해결하려면 단순히 락만 사용하는 것에 그치지 않고, 원자적 연산, 언어 및 프레임워크 수준의 동기화 메커니즘, 그리고 분산 환경에서의 일관성 유지 전략까지 폭넓게 고려해야 한다.

데이터베이스 시스템에서 동시성 제어란?

• 데이터베이스 시스템에서 동시성 제어는 여러 트랜잭션이 동시에 데이터베이스에 접근할 때 데이터의 일관성과 무결성을 보장하기 위한 메커니즘이다.
• 동시성 제어 메커니즘은 크게 3가지 방식이 존재한다.
  • 잠금 (Locking)
  • 타임스탬프 (Time-stamping)
  • 낙관적 동시성 제어(Optimistic Concurrency Control, OCC)
• 실무에서는 DBMS이 이러한 동시성 제어 메커니즘을 자동으로 처리하지만, 개발자는 트랜잭션 격리 수준을 설정하여 동시성 제어의 강도를 조절할 수 있다.

락 메커니즘 (Locking)

• 가장 일반적인 방법으로, 트랜잭션이 데이터에 접근할 때 잠금을 설정하여 다른 트랜잭션이 해당 데이터에 접근하지 못하게 하는 것
• 잠금(락 메커니즘)은 공유 락(읽기)과 배타 락(쓰기)으로 나뉜다.

타임스탬프 (Time-stamping)

• 각 트랜잭션에 타임스탬프를 부여하여 트랜잭션의 순서를 결정한다.
• 트랜잭션 실행 순서를 미리 결정하고, 충돌 여부를 타임스탬프 기반으로 판단한다.
• 트랜잭션이 데이터에 접근할 때 타임스탬프를 비교하여 일관성을 유지한다.

낙관적 동시성 제어 (Optimistic Concurrency Control, OCC)

• 트랜잭션이 데이터에 접근할 때 잠금을 사용하지 않고, 커밋 시점에 충돌을 검사하여 문제가 있을 경우 롤백한다.
• 트랜잭션 간 충돌이 거의 없는 시스템(예: 읽기 위주 시스템)에서 성능상 유리

특수 락 메커니즘

• 2단계 락킹 (Two-Phase Locking)
• MVCC (Multi-Version Concurrency Control)
• 인텐션 락 (Intention Lock)
• 타임스탬프 기반 동시성 제어
• 분산 락 (Distributed Lock)

2단계 락킹(2PL, Two-Phase Locking)

• 트랜잭션은 확장 단계와 수축 단계의 2단계를 거친다.
• 확장 단계에서는 락을 획득만 하고 해제하지 않으며, 수축 단계에서는 락을 해제만 하고 획득하지 않는다.
• 이는 직렬화 가능성(serializability)을 보장한다.

MVCC (Multi-Version Concurrency Control)

• 데이터의 각 버전을 트랜잭션마다 별도로 관리함으로써 서로 다른 버전을 볼 수 있어 읽기 트랜잭션이 쓰기 트랜잭션을 차단하지 않는다.

• PostgreSQL, Oracle, MySQL의 InnoDB에서 사용된다.

  (MySQL의 InnoDB는 MySQL에서 사용하는 저장 엔진 중 가장 널리 쓰이는 기본 엔진)

인텐션 락 (Intention Lock)

• 인덱스나 테이블처럼 계층적인 자원에 락을 적용할 때 상위 레벨에 락 충돌 없이 하위 레벨 락이 가능하도록 돕는 메타 정보용 락
• Ex. 특정 레코드에 배타 락을 걸려면 그 테이블에 먼저 Intention Exclusive Lock(IX Lock)을 요청해야 한다.
• 주로 InnoDB에서 사용되며, 락 충돌 여부를 빠르게 판단할 수 있도록 도와준다.

분산 락 (Distributed Lock)

• 여러 노드/서버에서 공유 자원에 동시에 접근하지 못하도록 제어하는 락
• 단일 메모리 공간이 아닌 분산 환경에서의 동기화 문제를 해결한다.
• 보통 Redis, ZooKeeper, etcd 등을 활용해서 구현

분산 데이터베이스 동시성 제어

• 2단계 커밋(2PC), 3단계 커밋(3PC) 프로토콜을 사용하여 여러 노드에 걸친 트랜잭션의 일관성과 원장성을 보장하기 위한 메커니즘
• 트랜잭션 전체 흐름을 조율하는 프로토콜
  • 2PC : Coordinator가 참여자들 모두에게 커밋 여부를 확인 → 모두 OK면 커밋, 아니면 롤백
  • 3PC : 2PC의 단점을 보완해서 중간 단계 추가 (네트워크 장애 대비)

• 낙관적 락과 비관적 락은 데이터베이스에서 동시성 제어를 위한 두 가지 접근 방식으로 구현 방식에 따른 분류한 것이다.

낙관적 락 (Optimistic Lock)

• 낙관적 락은 데이터 충돌이 드물다고 가정하고, 트랜잭션이 끝날 때까지 데이터에 대한 락을 걸지 않는다. 대신 트랜잭션이 커밋될 때 데이터가 변경되지 않았는지 확인한다.

• 예를 들어, 사용자가 데이터를 읽고 수정한 후 저장할 때, 저장 시점에 데이터의 버전이 변경되지 않았는지 확인하여 충돌을 감지한다.

• 구현 방식

  • 일반적으로 버전 필드(version), 타임스탬프(timestamp), 해시값(hash) 등을 사용하여 구현

  • JPA 구현 예시 : @Version 어노테이션을 사용하여 엔티티의 버전 필드를 관리한다.

    @Entity
    public class Product {
        @Id @GeneratedValue
        private Long id;
        private String name;
        private int price;
    
        @Version
        private Long version;
    }
    

• 장점
  • 락을 획득하지 않기 때문에 동시성이 높고, 교착 상태(Deadlock)가 발생하지 않는다.
• 단점점
  • 충돌 발생 시 롤백과 재시도 로직이 필요하며, 충돌이 자주 발생하면 성능이 저하된다.
• 사용 시나리오
  • 읽기 작업이 많고 충돌이 적은 환경, 웹 애플리케이션의 동시 편집, 분산 시스템 등에 적합하다

비관적 락 (Pessimistic Lock)

• 비관적 락은 데이터 충돌이 자주 발생한다고 가정하고, 데이터에 접근할 때마다 락을 걸어 다른 트랜잭션이 해당 데이터에 접근하지 못하도록 한다.

• 구현 방식

  • 데이터베이스의 락 메커니즘(shared lock, exclusive lock)을 직접 사용한다.

  • JPA 구현 예시 : LockModeType을 사용하여 다양한 종류의 락을 적용할 수 있다.

    // 읽기 락(shared lock)
    Product product = entityManager.find(Product.class, id, LockModeType.PESSIMISTIC_READ);
    
    // 쓰기 락(exclusive lock)
    Product product = entityManager.find(Product.class, id, LockModeType.PESSIMISTIC_WRITE);
    

• 장점
  • 트랜잭션이 시작될 때 데이터 일관성을 보장하기 때문에 충돌 처리 로직이 필요 없다.
• 단점
  • 락이 오래 유지되면 동시성이 저하되고, 교착 상태가 발생할 수 있다.
• 사용 시나리오
  • 충돌이 자주 발생하는 환경, 데이터 일관성이 매우 중요한 금융 시스템, 재고 관리 등에 적합하다

성능 비교

• 낙관적 락은 락을 사용하지 않아 시스템 자원 소모가 적지만, 충돌 시 롤백 비용이 발생한다.
• 비관적 락은 락을 유지하는 오버헤드가 있지만, 충돌이 자주 발생하는 경우 롤백 비용이 없어 유리할 수 있다.