🔐 동시성 문제 해결을 위해 어떤 Lock을 사용해야 할 까? - (1) DB Lock에는 무엇이 있을까? 🔓

👀 Overview

스페이스 클럽 프로젝트를 진행하면서, 아래와 같이 클럽에서 행사를 개최할때, 공연 카테고리의 행사를 신청하면 선착순 기능을 제공해야 했다.

그래서 아래와 같이 행사 개최자가 최대 정원(아래는 100명)을 설정해 놓으면, 예매 장수를 선택해 신청을 해야 했다.

그리고 정원이 없는 행사인 경우 최대 999명까지 받을 수 있도록 정책을 설정했었다.

이때 발생할 수 있는 문제점이 동시성 문제가 발생할 수 있었다.

따라서 행사를 신청하고 취소할때 동시성문제가 발생하지 않도록, 비관적 락(Pessimistic lock)을 사용해 동시성 문제를 해결하였다.

그리고 api 호출 시 신청이 불가한 경우 발생한 스프링 예외를 변환해서 프론트에게 전달해 주었다.

 

프로젝트를 진행할 때는, 일단 lock의 여러 방법이 있다는 것을 알고 있었는데, JPA의 비관적 락을 통해서 DB lock을 간단히 걸 수 있고, DB의 데이터에 접근함에 있어 동시성 보장이 확실히 되었기 때문에 사용하였다.

 

하지만 찾아보니, 비관적 락을 사용한다면 읽기가 빈번 할 경우 성능 저하의 문제가 있다는 것을 알고 DB와 JPA에서 제공하는 lock의 종류로는 무엇이 있고, 어떠란 lock을 사용하는것이 좋은 선택인지에 대한 고민이 생겼다.

 

DB Lock을 알아보자!

1. 트랜잭션과 Lock의 차이점!

먼저 DB에서 제공하는 Lock은 동시성을 제어하기 위한 기능이다.

그러면 트랜잭션은? 트랜잭션은 데이터의 정합성을 보장하기 위한 기능이다. 트랜잭션의 Isolation level을 설정하는데 있어서 DB lock을 사용해서 데이터의 정합성을 보장한다.

트랜잭션의 ACID 원칙에 있어 Atomicity 원칙으로 인해 애플리케이션 개발에서 고민해야 할 문제를 줄여주는 아주 필수적인 DBMS 기능을 제공한다. Partial Update가 발생하면 실패한 쿼리로 인해 남은 레코드를 다시 삭제하는 것을 개발자가 일일이 챙겨줘야 하기 때문이다. 

 

2. MySQL 엔진의 Lock에 대해서 알아보자!

MySQL 엔진과 InnoDB 스토리지 엔진의 차이를 모른다면 여기를 참고하자.

MySQL 엔진 레벨 Lock은 모든 스토리지 엔진에 영향을 미치지만 스토리지 엔진 레벨의 Lock은 스토리지 엔진 간 상호 영향을 미치지는 않는다.

 

(1) 글로벌 락 (Global Lock)

FLUSH TABLES WITH READ LOCK 명령으로 획득 가능하며 MySQL에서 제공하는 lock 가운데 가장 범위가 크다.

MySQL 서버 전체에 lock을 거는 것이며 실행과 동시에 MySQL 서버에 존재하는 모든 테이블을 닫고 lock을 건다. 

FLUSH TABLES WITH READ LOCK 은 테이블 읽기 잠금 걸기 전에 먼제 테이블을 플러시 하기 때문에 테이블에 실행중인 모든 종류의 쿼리가 완료되어야 한다.

글로벌 락을 통해 백업 또는 데이터 마이그레이션 작업 완료 후에는 UNLOCK TABLES 사용해서 Lock을 해제해야한다.

사용예시는 아래와 같다.

START TRANSACTION;
FLUSH TABLES WITH READ LOCK;
mysqldump --all-databases > backup.sql;
UNLOCK TABLES;
COMMIT;

언급했다시피, 모든 테이블에 큰 영향을 미치기에 웹서비스용으로 사용되는 MySQL 서버에서는 가급적 사용하지 않는 것이 좋다.

 

(2) 테이블 락 (Table Lock)

테이블 락은 개별 테이블 단위로 설정되는 락이다.

LOCK TABLES table_name [ READ | WRITE ] 사용해서 락 획득이 가능하다.

아래와 같이 명시적으로 사용가능한데, 테이블 락도 특별한 상황이 아니면 애플리케이션에서 사용할 필요가 거의 없다고 한다.

LOCK TABLES users WRITE;
# 작업 수행
UNLOCK TABLES;

명시적으로 테이블을 잠그는 작업은 글로벌 락과 같이 온라인 작업에 상당한 영향을 미치기 때문이다.

묵시적으로 테이블락은 MyISAM, MEMORY 테이블에 데이터 변경하는 쿼리를 실행하면 발생한다. 쿼리가 실행되는 동안 자동으로 획득되었다가 쿼리 완료 후 자동 해제 된다.

하지만 InnoDB 테이블 경우, 스토리지 엔진 레벨에서 레코드 기반 lock을 제공하기에 묵시적인 테이블 락 설정되지 않는다. (명확히는  테이블 락이 걸리지만, DML 쿼리는 무시되고 DDL 경우에만 영향을 미침)

 

(3) 네임드 락 (Named Lock)

GET_LOCK() 함수를 이용해서 임의의 문자열에 대해 잠금 설정이 가능하다.

그냥 단순히 사용자가 지정한 문자열에 대해 획득하고 반납하는 lock이다.

이는 나중에 다룰 분산락 구현에 사용될 수 있다. 분산락이란 여러서버에서 공유된 데이터를 제어하기 위해 사용하는 기술인데, DB서버가 1대인데 비해 서버가 여러대로 서비스하는 상황에서 데이터 동기화 하기 위해 사용하는 lock을 말한다.

 

select get_lock(key, timeout)을 통해 lock을 획득 할 수 있다.

select release_lock(key)을 통해서 lock을 해제 한다.

 

아래는 내가 동시성을 학습하면서 작성한 코드인데, 사용방식의 예는 다음과 같다.

실무에서는 lock을 획득하고 반납하는데 있어 connection 고갈이 일어날 수 있기에 datasource를 분리하는게 좋다고 한다.

 

먼저 named lock을 획득하고 반납을 담당하는 repository를 JdbcTemplate을 이용해 생성해 주었다. 

그 이유는 해당 lock 설정은 특정 entity에 종속되지 않기 때문에 Spring Data JPA를 사용하는 것 보다 JdbcTemplate을 사용하였다.

@Repository
public class NamedLockRepository {

    private final JdbcTemplate jdbcTemplate;

    public NamedLockRepository(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    public void getLock(String key) {
        jdbcTemplate.execute("SELECT GET_LOCK('" + key + "', 10)");
    }

    public void releaseLock(String key) {
        jdbcTemplate.execute("SELECT RELEASE_LOCK('" + key + "')");
    }

}

@Component
public class NamedLockStockFacade {

    private final LockRepository lockRepository;
    private final StockService stockService;

    public NamedLockStockFacade(LockRepository lockRepository, StockService stockService) {
        this.lockRepository = lockRepository;
        this.stockService = stockService;
    }

    @Transactional
    public void decrease(Long id, Long quantity) {
        String lockKey = id.toString();
        try{
            lockRepository.getLock(lockKey);
            // critical section
            stockService.decrease(id, quantity);
        } finally {
            lockRepository.releaseLock(lockKey);
        }
    }
    
}

 

(4) 메타데이터 락 (Metadata Lock)

데이터베이스 객체의 이름이나 구조를 변경하는 경우에 획득하는 lock이다.

RENAME TABLE table_a TO table_b 같이 테이블 이름 변경하는 경우 자동으로 획득된다. (두 테이블 모두 lock 설정)

 

2. InnoDB 스토리지 엔진에서의 Lock에 대해서 알아보자!

InnoDB 스토리지 엔진은 레코드 기반의 잠금 기능을 제공하는데, 잠금정보가 상당히 작은 공간으로 관리된다.

따라서 MyISAM 보다 훨씬 뛰어난 동시성 처리를 할 수 있다.

또한 InnoDB의 잠금은 레코드를 잠그는 것이 아닌 인덱스를 잠그는 방식으로 처리되기 때문에, 변경해야하는 레코드를 찾기 위해 검색한 인덱스의 레코드를 모두 락을 걸어야 한다는 특징이 있다

스토리지 엔진 잠금은 레코드 락과 레코드와 레코드 사이를 잠그는 갭(Gap)락 등이 존재하는데 하나씩 알아가보자!

 

(1) 레코드 락

레코드 자체만을 잠그는 것을 레코드 락 (Record Lock)이라고 하며, 다른 상용 DBMS의 레코드 락과 동일한 역할을 한다.

하지만 앞서 언급했지만, InnoDB 스토리지 엔진은 레코드 자체가 아닌 인덱스의 레코드를 잠근다는 것이 차이점이 있다. 

인덱스가 없으면 그럼 어쩌는가? -> 인덱스가 없더라도 내부적으로 생성된 클러스터 인덱스를 이용해 잠금을 설정한다.

 

레코드 락은 어떻게 그럼 설정하는 걸까?

UPDATE, DELETE 쿼리를 통해 레코드를 업데이트 or 삭제 명령을 실행하면 UPDATE, DELETE하는 동안 레코드 락이 설정된다!

그럼 SELECT 할때 lock 설정은 어떻게 할까?

SELECT name FROM user WHERE id = 1 FOR SHARE; // 공유 락 (읽기 잠금)
SELECT name FROM user WHERE id = 1 FOR UPDATE; // 배타 락 (쓰기 잠금)

위와 같이 shared lock (공유 락)과 exclusive lock (배타 락)이 존재한다.

이런 shared lock과 exclusive lock은 멀티 트랜잭션 환경에서 데이터베이스의 일관성과 무결성을 유지하기 위해서 트랜잭션의 순차적 진행을 보장할 수 있는 장치와 관련되어 있다 (트랜잭션의 격리 수준에 따른 데이터 정합성 보장에 사용)

 

따라서 트랜잭션이 시작되어 shared lock과 exclusive lock을 취득하고, 트랜잭션이 커밋되거나 롤백되어 완료가 되면 lock이 반환된다.

-- 트랜잭션 시작
BEGIN;

-- Shared Lock 설정
SELECT * FROM 테이블 WHERE id = 1 FOR SHARE;

-- Exclusive Lock 설정
SELECT * FROM 테이블 WHERE id = 2 FOR UPDATE;

-- 데이터 변경
UPDATE 테이블 SET 이름 = '새로운 이름' WHERE id = 1;

-- 트랜잭션 롤백 or 커밋
ROLLBACK or COMMIT;
-- Shared Lock과 Exclusive Lock 모두 해제 (출처 : google gemini)

트랜잭션을 사용하지 않는 경우, UNLOCK TABLES; 을 통해 명시적으로 lock을 해제할 수 있다.

정리 :

- shared lock과 exclusive lock은 트랜잭션이 종료시점에 해제되지만, UNLOCK TABLE 키워드를 통해 명시적으로 해제할 수도 있다.

- 레코드 락 취득 방법은 1️⃣ UPDATE 쿼리, 2️⃣ DELETE 쿼리, 3️⃣ Shared Lock / Exclusive Lock 획득 시에 발생한다.

 

 

(2) Gap Lock (갭 락)

갭 락은 레코드 자체가 아닌 레코드와 바로 인접한 레코드 사이의 간격만을 잠그는 것으로, 레코드와 레코드 사이의 간격에 새로운 레코드가 생성 (insert) 되는 것을 제어한다.

 

갭락에 대해서는 아래 당근마켓 블로그에서 자세히 다루고 있다.

MySQL Gap Lock 다시보기

 

 

(3) Next Key Lock (넥스트 키 락)

레코드 락과 갭 락을 합쳐 놓은 형태의 잠금을 말한다. 

갭 락, 넥스트 키 락의 목적은 바이너리 로그에 기록되는 쿼리가 replica server에서 실행될 때 source server에서 만들어 낸 결과와 동일한 결과를 만들어 내도록 보장해 주는 것이 주 목적이다. 

예를들어, UPDATE tb_gaplock SET .. WHERE id BETWEEN 1 AND 3 쿼리를 실행하면, 1,3번 row + 1,3 row 사이도 잠근다. 

따라서 실제 업무 프로그램에서는 이런 Next Key Lock이 더 일반적으로 사용 된다고 한다.

 

 

(4) Auto Increment Lock (자동 증가 락)

AUTO_INCREMENT 칼럼이 적용된 테이블에 동시에 여러 레코드가 insert 되는 경우, 저장되는 각 레코드는 중복되자 않고 순서대로 증가하는 일련번호를 가져야 하기 때문에 내부적으로 auto_increment lock이라는 테이블 수준의 lock을 사용한다.

따라서 INSERT, REPLACE 문에서만 필요하며, UPDATE, DELETE 쿼리에서는 걸리지 않는다.

트랜잭션과 관계 없이 auto_increment 값 가져오는 순간만 락 걸렸다가 즉시 해제되며, 테이블에서 lock은 단 하나만 존재한다.

 

Reference

Real MySQL 8.0 Chapter 5

참고 자료는 노션에 더 추가적으로 기록해 놓았다.

REAL MySQL - 05. 트랜잭션과 잠금 | Notion

https://techblog.woowahan.com/2631/

MySQL을 이용한 분산락으로 여러 서버에 걸친 동시성 관리 | 우아한형제들 기술블로그

https://dev.mysql.com/doc/refman/8.0/en/locking-functions.html

MySQL :: MySQL 8.0 Reference Manual :: 14.14 Locking Functions