[Spring] 동시성 문제 해결방법 (2) - 낙관적 락(Optimistic Lock), 비관적 락(Pessimistic Lock)

 

 

 

 

🤔 서론

이전 글에서 알아본 synchronized는 단일 서버 환경에서만 동시성 문제를 해결할 수 있었습니다.

이번 글에서는 다중 서버 환경에서 동시성 문제를 해결할 수 있는 방법에 대해 알아보도록 하겠습니다.

 

여러 대의 서버에서 동일 자원에 접근하는 경우, 동시에 한 개의 프로세스(혹은 쓰레드)만 접근 가능하도록 하기 위해 사용하는 Lock을 분산 락(Distributed Lock)이라 부릅니다.

 

이제부터 분산 락을 구현하는 여러 방법들에 대해 알아보도록 하겠습니다.

💡 분산 락에 대해서
분산 락에 대해서 이렇다 할 완전한 정의를 찾지는 못해서 다음 두 상황이 혼동될 수 있을 것 같습니다.
1. 웹 애플리케이션 서버가 여러대인 경우, 이들간의 동시성 문제를 해결하기 위해 사용되는 Lock
2. 스케일 아웃된 DB 환경에서 동시성 문제를 해결하기 위해 사용되는 Lock

이런저런 자료들을 찾아본 결과, 1, 2번 모두를 분산락을 보는 경우도 있었고, 2번만 분산락으로 보는 경우도 있었습니다.
앞으로의 글에서는 1, 2 번 모두를 분산락으로 생각하고 설명을 이어가도록 하겠습니다.

이를 언급하게 된 계기는 다음과 같습니다.
1번의 경우 여러 분산 서버에서 1개의 DB를 사용한다면 낙관적 락 혹은 비관적 락 만으도로 동시성 문제를 처리할 수 있습니다.
이때 1번의 개념을 분산락으로 본다면 낙관적 락과 비관적 락을 통해서 분산락을 구현할 수 있지만, 2번 상황은 해결하지 못하는 상황이 발생합니다.
이로 인해 1번은 분산락이 아닌가 하는 생각이 들었는데, 찾아보니 분산락에 대한 대부분의 설명에서 1번 상황을 가정하고 있었습니다. 그래서 최종적으로 혼동을 줄이기 위해, 위 두 상황 모두 분산락에 해당한다고 가정하겠습니다.

 

 

 

 

 

 

🤔 분산락을 구현하는 여러 방법

• 비관적 락 (Pessimistic Lock)
• 낙관적 락 (Optimistic Lock)
• USER-LEVEL Lock(Named Lock) (MySQL 한정)
• Redis
• Zookeeper
• 등등..

 

 

이중에서 이번 글에서는 낙관적 락과 비관적 락에 대해서 알아본 뒤, 나머지는 다음 글에서 이어서 알아보도록 하겠습니다.

 

 

 

 

🐳 비관적 락(Pessimistic Lock)

비관적 락은 DB의 X-Lock 혹은 S-Lock을 이용하여 데이터의 정합성을 맞추는 방법입니다.

비관적 락을 사용하게 되면 동시성 문제를 방지할 수 있으나, 데드락이 걸릴 수 있기 때문에 주의해서 사용해야 합니다.

 

 

 

 

 

🐳 낙관적 락(Optimistic Lock)

낙관적 락은 실제로 Lock을 사용하지 않고, 버전을 통해 데이터의 정합성을 맞추는 방법입니다.

먼저 데이터를 읽은 후에 update를 수행할 때 내가 현재 읽은 버전이 변경되지 않았는지 확인하며 업데이트를 진행합니다.

내가 읽은 버전에서 수정사항이 생겼을 경우에는 application에서 다시 읽은후에 작업을 수행해야 합니다.

 

 

 

나머지에 대해서는 다음 글에서 이어서 알아보도록 하겠습니다.

 

 

 

 

 

 

 

 

 

🤔 비관적 락을 통한 동시성 문제 해결

StockRepository에 다음과 같은 메서드를 추가합니다.

public interface StockRepository extends JpaRepository<Stock, Long> {

    default Stock getById(Long id) {
        return findById(id).orElseThrow(NoSuchElementException::new);
    }

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select s from Stock s where s.id = :id")
    Stock findByIdWithPessimisticLock(Long id);
}

 

 

 

이를 사용하는 서비스 코드를 작성합니다.

@RequiredArgsConstructor
@Service
public class PessimisticLockStockService {

    private final StockRepository stockRepository;

    @Transactional
    public void decrease(Long id) {
        Stock stock = stockRepository.findByIdWithPessimisticLock(id);
        stock.decrease();
        stockRepository.saveAndFlush(stock);
    }
}

 

 

 

이제 테스트 코드를 작성해 보겠습니다.

@SpringBootTest
class PessimisticLockStockServiceTest {

    @Autowired
    private PessimisticLockStockService pessimisticLockStockService;

    @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() 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 {
                    pessimisticLockStockService.decrease(stockId);
                } finally {
                    latch.countDown();
                }
            });
        }
        latch.await();

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

 

 

위와 같이 잘 동작하는 것을 볼 수 있습니다.

 

 

findByIdWithPessimisticLock 호출 시 발생하는 쿼리를 살펴보면 다음과 같습니다.

 

select for update를 통해서 X-lock을 획득하는 것을 알 수 있습니다.

 

 

 

 

 

 

 

 

🐳 다중 서버 환경에서 테스트

이전 글에서 진행한 것과 같이, 다중 서버에서의 동작을 확인해 보도록 하겠습니다.

 

컨트롤러 코드를 다음과 같이 변경합니다.

@RequiredArgsConstructor
@RestController
public class StockController {

    private final PessimisticLockStockService stockService;
    private final StockRepository stockRepository;

    @GetMapping("/stocks")
    public void createStock() {
        stockRepository.save(new Stock(1L, 100));
    }

    @GetMapping("/stocks/{id}/decrease")
    public void decreaseStock(
            @PathVariable Long id
    ) {
        stockService.decrease(id);
    }
}

 

이후 http://localhost:8080/stocks로 get 요청을 보냅니다.

위와 같이 상품이 잘 생성되었다면, 100개의 요청을 동시에 보내보도록 하겠습니다.

 

 

이전 글과 코드는 동일하며, 아래와 같습니다.

class MultiServerStockServiceTest {

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

        // when
        for (int i = 0; i < threadCount; i++) {
            final int ii = i;
            executorService.submit(() -> {
                try {
                    int port = (ii % 2 == 0) ? 8080 : 8081;
                    ResponseEntity<Void> forEntity = restTemplate.getForEntity(
                            "http://localhost:" + port + "/stocks/1/decrease",
                            Void.class);
                } finally {
                    latch.countDown();
                }
            });
        }
        latch.await();
    }
}

동시성 문제 없이 정확히 100개의 재고가 줄어든 것을 확인할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

🤔 낙관적 락을 통한 동시성 문제 해결

낙관적 락은 실제 Lock을 이용하는 것이 아닌 버전을 이용하는 것이므로, 버전에 대한 필드가 추가되어야 합니다.

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class Stock {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long productId;

    private int quantity;

    @Version
    private Long version;

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

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

 

(jakarta.persistence 패키지의 Version을 사용해야 합니다.)

 

 

StockRepository에 다음과 같은 메서드를 추가합니다.

public interface StockRepository extends JpaRepository<Stock, Long> {

    default Stock getById(Long id) {
        return findById(id).orElseThrow(NoSuchElementException::new);
    }

    @Lock(LockModeType.OPTIMISTIC)
    @Query("select s from Stock s where s.id = :id")
    Stock findByIdWithOptimisticLock(Long id);
}

 

 

이를 사용하는 서비스 코드를 작성합니다.

@RequiredArgsConstructor
@Service
public class OptimisticLockStockService {

    private final StockRepository stockRepository;

    @Transactional
    public void decrease(Long id) {
        Stock stock = stockRepository.findByIdWithOptimisticLock(id);
        stock.decrease();
        stockRepository.saveAndFlush(stock);
    }
}

 

 

낙관적 락은 실패 시 재시도를 해주어야 합니다.

이를 처리하는 OptimisticLockStockFacade를 작성해 주도록 하겠습니다.

@RequiredArgsConstructor
@Service
public class OptimisticLockStockFacade {

    private final OptimisticLockStockService optimisticLockStockService;

    public void decrease(Long id) {
        while (true) {
            try {
                optimisticLockStockService.decrease(id);
                break;
            } catch (Exception e) {
                try {
                    Thread.sleep(50);
                } catch (InterruptedException ex) {
                    throw new RuntimeException(ex);
                }
            }
        }
    }
}

 

 

이제 테스트 코드를 작성해 보겠습니다.

@SpringBootTest
class OptimisticLockStockFacadeTest {

    @Autowired
    private OptimisticLockStockFacade optimisticLockStockFacade;

    @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() 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 {
                    optimisticLockStockFacade.decrease(stockId);
                } finally {
                    latch.countDown();
                }
            });
        }
        latch.await();

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

 

위와 같이 잘 동작하는 것을 볼 수 있습니다.

 

 

 

 

 

🐳 다중 서버 환경에서 테스트

컨트롤러 코드를 다음과 같이 변경합니다.

@RequiredArgsConstructor
@RestController
public class StockController {

    private final OptimisticLockStockFacade stockService;
    private final StockRepository stockRepository;

    @GetMapping("/stocks")
    public void createStock() {
        stockRepository.save(new Stock(1L, 100));
    }

    @GetMapping("/stocks/{id}/decrease")
    public void decreaseStock(
            @PathVariable Long id
    ) {
        stockService.decrease(id);
    }
}

 

마찬가지로 2개의 서버를 띄운 후, 동시에 100개의 요청을 보내면 결과는 다음과 같습니다.

 

수량은 정확히 100개가 줄었으며, 수량이 업데이트 된 횟수만큼 version 컬럼의 값이 증가된 것을 확인할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

🤔 낙관적 락과 비관적 락 사용 시 문제

낙관적 락 혹은 비관적 락을 사용하는 경우, 단일 웹 서버 환경 뿐만 아니라 다중 웹 서버 환경에서도 동시성 문제를 방지할 수 있었습니다.

그러나 스케일아웃된 DB 환경에서는 이들을 통해서 동시성 제어를 할 수 없다는 문제점이 있습니다.

DB가 스케일아웃 된 상황이라면 Redis 혹은 ZooKeeper등을 통해 분산락을 구현해야 합니다.

 

이들을 사용하는 방법을 알아보기 전에, 다음 글에서는 MySQL에서 사용할 수 있는 Named Lock을 통해 분산락을 구현하는 방법에 대해 알아보도록 하겠습니다.

💡 Named Lock 역시도 스케일아웃된 DB 환경에서는 동시성 제어를 할 수 없습니다.

 

 

 

 

 

 

 

 

 

🤔 마무리

이번 글에서는 데이터베이스의 낙관적 락과 비관적 락을 사용하여 동시성 문제를 해결하는 방법에 대해 알아보았습니다.

위 두 방법을 사용하면 단일 서버 뿐만 아니라 다중 서버 환경에서도 동시성 문제를 방지할 수 있다는 것을 확인했습니다.

다음 글에서는 MySQL에서 제공하는 USER-LEVEL Lock(Named Lock)을 통한 분산락의 구현방법에 대해 알아보도록 하겠습니다.

 

 

 

 

 

 

 

 

 

📚 Reference

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

https://channel.io/ko/blog/distributedlock_2022_backend