동시성 이슈 해결하기 : synchronized, MySQL Lock, Redis Lock

동시성 문제

---

하나의 데이터에 여러 스레드가 동시에 접근하면서 생기는 문제를 동시성 문제라고 한다.

하나의 세션이 데이터를 수정 중일때, 다른 세션에서 수정 전의 데이터를 조회해 로직을 처리함으로써 데이터의 정합성이 깨지게 된다.

 

동시성 문제 해결 방법

---

동시성 문제는 하나의 세션이 데이터를 사용하는 동안, 다른 세션은 데이터를 사용하지 못하게 함으로서 해결할 수 있다. 세션의 독립적인 실행을 구현하는 방법으로 다음 세 가지 방법이 있다.

1. Application 레벨에서 synchronized 사용

2. 데이터베이스의 Lock 사용

3. Redis의 Lock 사용

 

재고 감소 로직을 통해 동시성 문제를 살펴보고 해결해보자.

 

목차
0. 재고 시스템 기본 로직
1. 멀티 스레드 환경에서 동시성 문제가 발생하는 이유
2. 경쟁 상태(Race Condition) 해결 방법
   1. java synchronized
   2. MySQL Lock
      1. Pessimistic Lock
      2. Optimistic Lock
      3. Named Lock
   3. Redis Lock
      1. Lettuce Lock
      2. Redisson Lock
3. 정리

 

재고 시스템 기본 로직

• Stock.java : 엔티티
• StockRepository.java : 레포지토리
• StockService.java : 재고 감소 로직

Stock.java

@Entity
@Getter
@NoArgsConstructor
public class Stock {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private Long productId;
    private Long quantity;
    @Version
    private Long version;	//Optimistic Lock에서만 사용

    public Stock(Long productId, Long quantity) {
        this.productId = productId;
        this.quantity = quantity;
    }

    public void decrease(Long quantity) {
        if (this.quantity - quantity < 0) {
            throw new RuntimeException("재고는 0개 미만이 될 수 없습니다.");
        }
        this.quantity -= quantity;
    }
}

 

StockService.java

@Service
@RequiredArgsConstructor
public class StockService {

    private final StockRepository stockRepository;

    public void decrease(Long id, Long quantity) {
        Stock stock = stockRepository.findById(id).orElseThrow();
        stock.decrease(quantity);
        stockRepository.saveAndFlush(stock);
    }
}

 

 

위 코드는 쉽게 떠올릴 수 있는 재고 감소 로직으로 실행하면 아무런 문제가 없다. 그러나 멀티 스레드 상황에선 예상과 다른 결과가 나타난다.

 

StockServiceTest.java

여러 스레드로 동시에 재고를 감소시키는 테스트

• ExecutorService : 병렬 작업 시 여러 개의 작업을 효율적으로 처리하기 위해 제공되는 JAVA 라이브러리
• CountDownLatch : 어떤 쓰레드가 다른 스레드에서 작업이 완료될 때까지 기다릴 수 있도록 해주는 클래스

@Test
public void 동시에_100개의_요청() throws InterruptedException {
    int threadCount = 100;
    ExecutorService executorService = Executors.newFixedThreadPool(32);
    CountDownLatch latch = new CountDownLatch(threadCount);

    for (int i = 0; i < threadCount; i++) {
        executorService.submit(() -> {
            try {
                stockService.decrease(1L, 1L);
            } finally {
                latch.countDown();
            }
        });
    }

    latch.await();

    Stock stock = stockRepository.findById(1L).orElseThrow();
    // 100 - (1 * 100) = 0
    assertEquals(0, stock.getQuantity());
}

 

100개의 스레드가 동시에 재고를 하나 감소시키는 테스트 코드다. 우리는 스레드 하나당 하나의 재고를 감소시키며 마지막에 남은 재고 수는 0이길 기대한다. 그러나 코드를 실행시켜보면 남은 재고 수량은 0보다 많아 테스트는 실패한다.

 

이는 레이스 컨디션(Race Condition)이 발생하기 때문이다. 레이스 컨디션이란 여러 개의 프로세스가 공유 자원에 동시 접근할 때 실행 순서에 따라 결과값이 달라질 수 있는 현상이다.

 

1. 멀티 스레드 환경에서 레이스 컨디션이 발생하는 이유

---

예상 작업 순서

멀티 스레드로 작업을 할 때, 아래 그림처럼 데이터에 순차적으로 접근하여 재고를 처리하길 기대한다.

Thread-1	Stock	Thread-2
select * from stock where id = 1	{id: 1, quantity: 5}
update set quantity = 4 from stock where id = 1	{id: 1, quantity: 4}
	{id: 1, quantity: 4}	select * from stock where id = 1
	{id: 1, quantity: 3}	update set quantity = 3 from stock where id = 1

 

실제 작업 순서

그러나 실제로는 같은 데이터를 동시에 변경하려 하기 때문에 재고 감소 작업이 누락될 수 있다.

Thread-1	Stock	Thread-2
select * from stock where id = 1	{id: 1, quantity: 5}
	{id: 1, quantity: 5}	select * from stock where id = 1
update set quantity = 4 from stock where id = 1	{id: 1, quantity: 4}
	{id: 1, quantity: 4}	update set quantity = 4 from stock where id = 1

 

2. 레이스 컨디션 해결 방법

레이스 컨디션을 해결하기 위해선 공유 자원에 대해 하나의 스레드만 접근할 수 있게끔 제한하면 된다.

 

(1) synchronized 이용하기

---

synchronized는 java에서 사용하는 스레드 동기화의 대표적인 방법

synchronized 키워드를 이용하면 해당 메서드를 한번에 한 스레드씩 수행하도록 보장한다.

synchronized 사용 시 주의할 점 : @Transactional을 붙이지 말 것(🔗), stock을 갱신할 땐 save가 아닌 saveAndFlush를 쓸 것(🔗)

public synchronized void decrease(Long id, Long quantity) {
    Stock stock = stockRepository.findById(id).orElseThrow();
    stock.decrease(quantity);
    stockRepository.saveAndFlush(stock);
}

 

💥synchronized의 문제점

- synchronized는 하나의 프로세스 안에서만 보장된다. 따라서 서버가 여러 대인 경우, synchronized를 사용하면 또 다시 race condition이 발생하게 된다.(멀티 프로세스)

- 실무에선 대부분 두 대 이상의 서버를 사용하므로 synchronized는 사용하지 않는다.

 

(2) 데이터베이스(MySQL)의 Lock 이용하기

---

1. Pessimistic Lock

• 실제로 데이터에 Lock을 걸어서 정합성을 맞추는 방법
• exclusive lock을 걸게 되면 다른 트랜잭션에선 lock이 해제되기 전에 데이터를 가져갈 수 없게 된다.
• 자원 요청에 따른 동시성 문제가 발생할 것을 예상하고 락을 거는 비관적 락 방식이다.
• 데드락이 걸릴 수 있기 때문에 주의하여 사용해야 한다.

2. Optimistic Lock

• 실제로 Lock을 이용하지 않고 버전을 이용함으로써 정합성을 맞추는 방법
• 먼저 데이터를 읽은 후, update를 수행할 때 현재 내가 읽은 버전과 일치하는지를 확인하여 업데이트를 수행한다.
• 내가 읽은 버전에서 수정사항이 생긴 경우, application에서 다시 읽어 작업을 수행해야 한다.

  

  ① Server 1이 version 1을 명시하여 쿼리를 날린다.
  ② version 1 쿼리를 처리하며 데이터베이스 version은 2가 된다.
  ③ Server 2가 version 1을 명시한 쿼리를 날린다. 하지만 버전이 일치하지 않아 업데이트에 실패한다.
  ④ 쿼리가 실패했으므로 Server 2는 데이터베이스의 버전을 다시 조회한 후 version을 수정하여 쿼리를 날린다.
  
  

3. Named Lock

• 이름을 가진 metadata locking (데이터베이스 개체에 대한 동시 액세스를 관리하고 데이터 일관성을 보장하는 잠금)
• 이름을 가진 lock을 획득한 후 해제할 때까지 다른 세션은 이 lock을 획득할 수 없다.
• 트랜잭션이 종료될 때 lock이 자동으로 해제되지 않는다. 따라서 별도의 명령어를 수행하거나 선점시간이 끝나야 해제된다.

1. Pessimistic Lock 사용하기

StockRepository.java

public interface StockRepository extends JpaRepository<Stock, Long> {

    //Lock을 걸고 데이터를 가져오는 메서드
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select s from Stock s where s.id = :id")
    Stock findByIdWithPessimisticLock(Long id);
}

 

- 내용 추가 예정 -