[Spring] 동시성 문제 해결방법 (3) - USER-LEVEL Lock(Named Lock) 사용

 

 

 

 

 

🤔 서론

이전 글에서는 비관적 락(Pessimistic Lock)과 낙관적 락(Optimistic Lock)을 통해 분산락을 구현하여 단일 서버는 물론 다중 서버에서도 동시성 문제를 해결하였습니다.

이번 글에서는 비관적 락과 비슷한 MySQL의 USER-LEVEL Lock(Named Lock)을 통해서 동시성 문제를 해결해 보도록 하겠습니다.

(앞으로는 user-level lock이라고 부르도록 하겠습니다.)

 

 

 

 

 

 

 

🤔 USER-LEVEL Lock (Named Lock)

MySQL 공식 문서를 보면 다음과 같은 user level lock을 지원해주는 것을 알 수 있습니다.

 

 

 

🐳 GET_LOCK(str, timeout)

주어진 이름(str)에 대한 Lock 획득을 시도합니다. 이때 문자열의 길이는 최대 64글자입니다.

이미 다른 session에서 동일한 이름의 Lock을 획득한 경우 Lock 획득을 위해 대기하게 되는데, 이때 최대 timeout에 명시된 시간 만큼 대기합니다.

만약 timeout이 음수인 경우, 무한정 기다리게 됩니다.

• 해당 락은 배타적(exclusive)으로 동작합니다.
  • 하나의 세션에서 named lock을 얻은 경우, 다른 세션에서는 동일한 이름의 lock을 획득할 수 없습니다.

• 반환값은 다음과 같습니다.
  • 1 : named lock을 성공적으로 획득한 경우 1이 반환됩니다.
  • 0 : timeout이 지나도록 lock을 획득하지 못한 경우 0이 반환됩니다.
  • null : 에러가 발생한 경우(out of memory 등) null이 반환됩니다.

• GET_LOCK()을 통해 획득한 Lock은 RELEASE_LOCK()을 호출함으로써 명시적으로 해제시킬 수 있으며, 세션이 종료되는 경우에는 암시적으로 반환됩니다.
  • 트랜잭션의 커밋 혹은 롤백으로는 GET_LOCK()으로 얻은 잠금이 해제되지 않습니다.
• GET_LOCK()은 메타데이터를 잠금(MDL)을 사용하여 구현됩니다.
• 하나의 세션이 다른 이름의 Lock은 물론, 동일한 이름의 Lock을 여러개 획득하는 것도 가능합니다.
  • 즉 다음과 같은 시나리오도 가능합니다.

# 세션 1
SELECT GET_LOCK('test', 100);
SELECT GET_LOCK('test', 100);

# 세션 2
SELECT GET_LOCK('test', -1);  # 대기 중

# 세션 1
SELECT RELEASE_LOCK('test');  # 세션 2는 여전히 대기 중

SELECT RELEASE_LOCK('test');  # 세션 2에서 Lock 획득

(잘 사용할 일이 있을지는 모르겠습니다)

 

 

• GET_LOCK()을 통해 여러 개의 잠금을 획득할 수 있으므로, 이로 인해 데드락이 발생할 가능성이 생깁니다.
  • 데드락이 발생하는 상황은 다음과 같습니다.

# 세션 1
SELECT GET_LOCK('mallang', -1);

# 세션 2
SELECT GET_LOCK('donghun', -1);

# 세션 1
SELECT GET_LOCK('donghun', -1);  # 세션 2가 donghun 에 대한 Lock을 가지고 있으므로 무한 대기

# 세션 2
SELECT GET_LOCK('mallang', -1);  # 세션 1이 mallang 에 대한 Lock을 가지고 있으므로 무한 대기

# -> 데드락 발생

• 위와 같이 데드락이 발생하면, mysql은 ERROR 3058(ER_USER_LOCK_DEADLOCK)을 발생시켜 잠금 획득 요청을 종료합니다. 이로 인해 트랜잭션이 롤백되지는 않습니다.
• 여러 클라이언트에서 잠금 획득을 기다리는 경우, 잠금을 획득하게 되는 순서는 정의되지 않습니다.
  • 따라서 잠금 요청 순서대로 잠금을 획득할 것이라 가정하고 사용해서는 안됩니다.

• GET_LOCK()은 statement-based replication에 대해 안전하지 않습니다.
• GET_LOCK()은 단일 MySQL 서버(mysqld)에 대해서만 잠그기 때문에, NDB 클러스터에 사용하기에는 적합하지 않습니다.

 

 

 

 

 

🐳 RELEASE_LOCK(str)

입력받은 이름(str)을 가진 Lock을 해제합니다.

• 반환값은 다음과 같습니다.
  • 1 : named lock을 성공적으로 해제한 경우 1이 반환됩니다.
  • 0 : 해당 쓰레드에서 획득한 Lock이 아닌 경우 0이 반환됩니다. (이 경우 Lock은 해제되지 않습니다.)
  • null : 해당 이름의 잠금이 존재하지 않으면 null이 반환됩니다.

 

 

 

나머지는 이번 글에서 사용하지 않으므로 살펴보지 않고 넘어가겠습니다.

궁금하다면 따로 공식 문서를 통해 확인해주세요 :)

 

 

 

 

 

 

 

 

 

🤔 USER-LEVEL Lock을 통한 동시성 문제 해결

우선 이전 글을 따라했다면, Stock 클래스에서 @Version과 버전 필드를 제거해줍니다.

 

user-level lock의 획득과 반환을 위해 LockRepository를 구현합니다.

public interface LockRepository extends JpaRepository<Stock, Long> {

    @Query(value = "SELECT GET_LOCK(:key, 3000)", nativeQuery = true)
    Integer getLock(String key);

    @Query(value = "SELECT RELEASE_LOCK(:key)", nativeQuery = true)
    Integer releaseLock(String key);
}

 

 

 

이제 재고감소 로직 전후로 Lock를 획득하고 반환해주는 작업을 처리하기 위해 NamedLockStockFacade를 작성해주도록 하겠습니다.

@RequiredArgsConstructor
@Service
public class NamedLockStockFacade {

    private final LockRepository lockRepository;
    private final StockService stockService;

    @Transactional
    public void decrease(Long id) {
        try {
            Integer acquiredLock = lockRepository.getLock(String.valueOf(id));
            if (acquiredLock != 1) {
                throw new RuntimeException("Lock 획득에 실패했습니다. [id: %d]".formatted(id));
            }
            stockService.decrease(id);
        } finally {
            lockRepository.releaseLock(String.valueOf(id));
        }
    }
}

 

user-level lock은 트랜잭션 종료 시 반환되지 않기 때문에, RELEASE_LOCK()을 호출하여 명시적으로 해제해주어야 합니다.

 

 

 

 

이제 StockService를 다음과 같이 변경합니다.

@RequiredArgsConstructor
@Service
public class StockService {

    private final StockRepository stockRepository;

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void decrease(Long id) {
        Stock stock = stockRepository.getById(id);
        stock.decrease();
        stockRepository.saveAndFlush(stock);
    }
}

 

propagation을 REQUIRES_NEW로 설정하여 새로운 트랜잭션에서 동작하도록 구현하였습니다.

만약 락 획득과 재고감소 로직이 동일 트랜잭션에서 발생한다면 아래와 같이 여전히 동시성 문제가 발생하게 됩니다.

이유는 아래 USER-LELEV Lock 사용 시 주의점 부분에서 확인하도록 하겠습니다.

 

 

 

테스트코드는 다음과 같습니다.

@SpringBootTest
class NamedLockStockFacadeTest {

    @Autowired
    private NamedLockStockFacade namedLockStockFacade;

    @Autowired
    private StockRepository stockRepository;

    private Long stockId;

    @BeforeEach
    void setUp() {
        stockId = stockRepository.saveAndFlush(new Stock(1L, 100))
                .getId();
    }

    @AfterEach
    void tearDown() {
        stockRepository.deleteAll();
    }

    @Test
    void decrease_with_100_request_name_lock() throws InterruptedException {
        // given
        int threadCount = 100;
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        // when
        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    namedLockStockFacade.decrease(stockId);
                } catch (Exception e) {
                    System.out.println(e);
                } finally {
                    latch.countDown();
                }
            });
        }
        latch.await();

        // then
        Stock stock = stockRepository.getById(stockId);
        assertThat(stock.getQuantity()).isEqualTo(0);
    }
}

 

이를 바로 실행하게 되면 REQUIRES_NEW로 인해 커넥션의 소모가 증가하여 올바르게 동작하지 않습니다.

 

일반적인 애플리케이션이라면 커넥션풀(DataSource)를 분리해 주는 것이 좋지만, 이는 테스트이므로 간단히 커넥션 풀을 늘려서 처리하도록 하겠습니다.

application.yml 설정에 다음과 같이 커넥션 풀 사이즈를 명시합니다.

spring:
  jpa:
    hibernate:
      ddl-auto: create
    show-sql: true
    properties:
      hibernate:
        format_sql: true
        use_sql_comments: true
        highlight_sql: true
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/stock
    username: root
    password: 1234
    hikari:
      maximum-pool-size: 40  # 추가

logging:
  level:
    org:
      hibernate:
        SQL: DEBUG
        type:
          descriptor:
            sql:
              BasicBinder: TRACE

올바르게 동작함을 확인할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

🤔 USER-LEVEL Lock 사용 시 주의점

USER-LEVEL Lock을 사용한다면 Lock을 얻는 트랜잭션과 로직을 수행하는데 사용되는 트랜잭션을 분리시켜야 합니다.

그리고 이들이 분리된다면 그에 따라 커넥션 사용량이 많아지므로(Lock 획득에 필요한 커넥션 1개, 로직에 필요한 커넥션 1개) , Lock을 얻는데 사용하는 Connection Pool(Datasource)과, 로직을 수행하는데 사용되는 ConnectionPool(Datasource)을 분리해 주는 것이 좋습니다.

 

우선 왜 두 트랜잭션을 분리해야 하는지에 대해 알아보도록 하겠습니다.

트랜잭션이 분리되지 않은 경우, 다음과 같은 상황이 발생할 수 있습니다.

 

락이 release되는 시점과 트랜잭션이 커밋되는 시점 사이에 새로운 요청이 들어와 완료된다면 네임드락을 사용하기 전과 마찬가지로 동시성 문제가 발생하게 되므로, 두 트랜잭션은 분리되어야 합니다.

 

그리고 트랜잭션(커넥션)을 분리하게 된다면, 하나의 요청에 대해 최소 2개의 커넥션이 사용되기 때문에 커넥션 부족으로 인해 문제가 발생할 수 있습니다.

이를 예방하기 위해 ConnectionPool(DataSource) 자체를 분리하여 사용하는 것을 권장합니다.

 

 

 

 

 

 

 

 

 

 

 

 

🤔 USER-LEVEL Lock VS 비관적 락

흔히 이 둘의 차이를 찾아보게 되면 USER-LEVEL Lock은 timeout 설정이 간편하다는 장점이 있다는 설명이 많습니다.

그러나 비관적 락 역시도 @QueryHint 등을 통해서 timeout 설정을 줄 수 있기 때문에, timeout을 장점으로 보기에는 조금 부족한 부분이 있는 것 같습니다.

 

user-level lock의 경우 락의 대상이 테이블이나 레코드 또는 AUTO_INCREMENT와 같은 데이터베이스 객체가 아닌, 단순히 사용자가 지정한 이름에 대해서 락을 거는 것이 특징입니다.

비관적 락은 레코드 수준에 락을 걸기 때문에, 다른 작업들을 처리하기 위한 커넥션들도 락이 걸린 레코드에 접근하지 못하게 됩니다.

이러한 문제는 user-level lock을 사용하면 발생하지 않으며, 이것이 이 둘 사이의 가장 큰 차이점이지 않을까 생각합니다.. ㅎㅎ;;

 

 

 

 

 

 

 

 

 

 

📚 Reference

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

MySQL :: MySQL 8.0 Reference Manual :: 12.14 Locking Functions

 

[재고시스템으로 알아보는 동시성이슈 해결방법]

[Real MySQL 8.0 1편]

https://www.inflearn.com/questions/1067435/named-lock-vs-%EB%B9%84%EA%B4%80%EC%A0%81-%EB%9D%BD

named lock vs 비관적 락 - 인프런 | 질문 & 답변

https://www.inflearn.com/questions/627768/%EB%84%A4%EC%9E%84%EB%93%9C%EB%9D%BD%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%A0-%EB%95%8C-%EB%8D%B0%EC%9D%B4%ED%84%B0%EC%86%8C%EC%8A%A4%EB%A5%BC-%EB%B6%84%EB%A6%AC%ED%95%B4%EC%95%BC%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0%EA%B0%80-%EA%B6%81%EA%B8%88%ED%95%B4%EC%9A%94

네임드락을 활용할 때 데이터소스를 분리해야하는 이유가 궁금해요! - 인프런 | 질문 & 답변

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

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

(이곳의 댓글)