동시성 이슈 해결방법 (2/3) - 데이터베이스 락(Lock)으로 해결하기

💡 최상용님의 재고시스템으로 알아보는 동시성이슈 해결방법 강의를 듣고 정리한 내용입니다.

배경

지난 동시성이슈 해결방법 (1/3) - 동시성 이슈와 Application Level로 해결하기 글에서 멀티 스레드 환경에서 개발할 때 발생할 수 있는 경합 상태(Race condition)를 비롯한 동시성 이슈를 알아보았다. 이를 해결하기 위해서는 공유 데이터에 접근할 때 한 번에 한 스레드만 접근하고 작업할 수 있도록 제어를 해야 한다는 사실을 알았고 자바의 synchronized 키워드를 먼저 적용하여 해결하였다. 하지만 자바의 synchronized 키워드는 한 프로세스 내에서만 스레드 안전성을 제공하며 스프링의 @Transactional 어노테이션과 함께 사용하기에 한계가 있었다.
 
결국 동시성 이슈를 해결하기 위해 별도의 동기화 메커니즘의 필요성을 느꼈고, 이번 글에서는 데이터베이스에서 제공하는 Lock을 활용하여 문제를 해결해 본다.

데이터베이스 락(Database Lock)

데이터베이스는 락(Lock)이라는 장치로 데이터에 접근 제약을 두어 데이터 정합성을 맞추는 다양한 방법을 제공하는데, 대표적으로 비관적 락(Pessmistic Lock), 낙관적 락(Optimistic LocK), 네임드 락(Named Lock)이 있다. 각각의 특성에 대해 간략히 살펴보면 다음과 같다.

비관적 락(Pessimistic Lock)

실제로 데이터베이스 테이블 혹은 데이터베이스 로우(Row)에 Lock을 걸어서 데이터 접근 제약을 두어 정합성을 맞추는 방법이다. 이러한 방식으로 Exclusive lock을 걸게 되면 다른 트랜잭션에서는 Lock이 해제되기 전에 데이터를 가져갈 수 없다.

 

가장 직관적으로(데이터에 접근 자체를 제한) 접근 제약을 둘 수 있지만, 두 개 이상의 스레드가 서로 락을 얻기 위해 무한정 대기하는 데드락(Deadlock, 교착상태)에 빠질 수 있으므로 주의해서 사용해야 한다.

낙관적 락(Optimistic Lock)

 
실제로 데이터 자체에 락(Lock)을 두는 것이 아니라 데이터의 버전(Version)을 이용하여 정합성을 맞추는 방법이다. 데이터를 읽을 때 데이터의 버전을 함께 조회한다. 그리고 업데이트하기 전에 업데이트하려는 데이터의 버전이 처음 조회했을 당시 버전과 동일한지 확인한다.

 

만일 버전이 같다면 업데이트에 성공하고, 버전이 다르다면 업데이트에 실패한다.

이 경우 애플리케이션단에서 다시 데이터를 조회해서 업데이트를 재수행하는 로직을 짜야한다.

네임드 락(Named Lock)

이름을 가진 Metadata lock기법이다.

이름을 가진 Lock을 한 세션이 획득한 후 해제하기 전까지 다른 세션은 이 Lock을 획득할 수 없다.

주의할 점은 Transaction이 종료될 때 Lock이 자동으로 해제되지 않기 때문에 별도의 명령어로 해제를 수행해야 한다.

혹은 TTL(Time to live)를 두어 선점시간이 끝나면 해제하도록 개발자가 별도로 설정해야 한다.
Pessimistic Lock과 유사하나 Pessimistic Lock은 로우나 테이블 단위로 락을 거는 반면 네임드 락은 metadata lock에 대해 락을 건다는 차이가 있다.

Pessimistic Lock 활용해 보기

앞서 설명한 3가지 락 기법(비관적 락, 낙관적 락, 네임드 락)을 직접 재고 관리 시스템에 적용하여 Race condition을 해결해 본다.

 

먼저 비관적 락(Pessimistic Lock)을 먼저 적용해 본다.
앞서 설명했듯 낙관적 락은 실제 테이블 혹은 Row에 락을 걸어 동시성 문제를 해결하고 정합성을 맞춘다.

실제 데이터에 Exclusive Lock을 걸면 다른 트랜잭션에서는 해당 데이터에 대해 Lock을 획득하고 작업하기 전까지 대기해야 한다.
 
비관적 락(Pessimistic Lock)을 사용하는 경우 타임라인 별로 두 개의 스레드가 공유 데이터인 Stock에 어떻게 접근하여 동시성 이슈를 해결하는지 그 과정을 살펴보면 다음과 같다.

StockRepository

재고 로우에 대해 Lock을 걸고 데이터를 조회하기 위해 findByIdWithPessimisticLock() 메서드를 추가한다.
이때 Spring Data JPA에서 제공하는 @Lock 어노테이션을 활용하여 LockModeType을 PESSIMISTIC_WRITE로 두어 간단하게 Pessimistic Lock을 구현할 수 있다.

public interface StockRepository extends JpaRepository<Stock, Long> {
	// Spring Data Jpa에서는 @Lock 어노테이션을 활용하여 손쉽게 Pessimistic Lock을 구현할 수 있다.
	@Lock(LockModeType.PESSIMISTIC_WRITE)
	@Query("select s from Stock s where s.id = :id")
	Stock findByIdWithPessimisticLock(Long id);
}

PESSIMISTIC_WRITE

JPA(Java Persistence API)에서 제공하는 비관적 락(Pessimistic Locking) 설정 어노테이션은 특정 엔티티에 대해 잠금을 걸어 데이터베이스까지 전파한다. MySQL에서는 SELECT ... FOR UPDATE 쿼리를 통해 쓰기 락(Write Lock)을 설정한다. 행 수준(Row Level)의 락에는 Shared Lock(sLock-공유 락)과 Exclusive Lock(xLock - 베타 락)이 존재한다.

• 공유 락 (sLock): 읽기 전용 락으로, 다른 트랜잭션이 읽을 수 있지만 수정은 불가능
• 베타 락 (xLock): 쓰기 락으로, 다른 트랜잭션이 해당 데이터를 읽거나 쓸 수 없게 한다. Spring Data JPA에서는 LockModeType.PESSIMISTIC_WRITE로 설정할 수 있습니다.

비관적 락의 목적은 데이터를 읽은 후 변경 가능성이 있을 때 즉시 잠금을 걸어, 다른 트랜잭션에서 해당 데이터를 수정하지 못하게 하는 것이다. 트랜잭션이 완료될 때까지 잠금이 유지되며, 만약 다른 트랜잭션이 먼저 락을 가진 경우 요청된 트랜잭션은 누락되지 않고 대기 상태에 들어간다.

PessimisticLockStockService

재고 감소 로직을 수행할 때 decrease() 메서드에서 Pessimistic Lock을 사용하는 로직을 구현한다.

이를 통해 이전과 달리 락을 걸고 데이터를 조회할 수 있다.

@Service
public class PessimisticLockStockService {
	private final StockRepository stockRepository;

	public PessimisticLockStockService(StockRepository stockRepository) {
		this.stockRepository = stockRepository;
	}

	@Transactional
	public void decrease(Long id, Long quantity) {
		// 락을 걸고 재고 데이터를 가져온다.
		Stock stock = stockRepository.findByIdWithPessimisticLock(id);

		stock.decrease(quantity);
		stockRepository.save(stock);
	}
}

StockServiceTest

비관적 락을 사용하는 PessimisticLockStockService 클래스의 decrease() 메서드를 테스트하는 코드를 작성한다.
테스트 코드를 새로 작성할 필요 없이 기존의 테스트 코드에서 @Autowired로 StockService 대신 PessimisticLockStockService 클래스를 의존관계로 주입하면 된다.

@SpringBootTest
class StockServiceTest {
	@Autowired
	//private StockService stockService;
	private PessimisticLockStockService stockService;

	@Autowired
	private StockRepository stockRepository;

	@BeforeEach
	public void before() {
		stockRepository.saveAndFlush(new Stock(1L, 100L));
	}

	@AfterEach
	public void after() {
		stockRepository.deleteAll();
	}

	@Test
	public void 동시에_100개의_요청() throws InterruptedException {
		// 100개의 쓰레드 사용(멀티스레드)
		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 {
               	 	// CountDownLatch 1 감소
					latch.countDown();
				}
			});
		}
		latch.await();

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

테스트 결과

테스트가 성공하는 것을 볼 수 있다.

로그를 확인해 보면 다음과 같이 조회 쿼리를 호출할 때  select for update 쿼리를 호출하는 것을 볼 수 있다.

이 부분은 데이터에 대해 Lock을 걸고 데이터를 조회하는 부분에 해당한다.

즉, 비관적 락을 사용한다는 것은 조회 시점에 select for update 쿼리를 호출하여 조회하려는 데이터에 대해 Lock을 건다는 것을 알 수 있다.

이처럼 Pessimistic Lock은 조회시점에 Lock을 통해 업데이트를 제어하여 데이터 정합성을 보장한다.

하지만 데이터 조회 시점에 별도의 Lock을 잡아버리기 때문에 충돌이 빈번하게 발생하지 않는 상황에서는 불필요한 대기 시간으로 성능 저하가 나타날 수 있다.

(바로 다음에 살펴볼) Optimistic Lock은 충돌이 일어나는 경우 데이터를 다시 조회해야 하므로 충돌이 빈번하게 일어난다면 성능이 저하된다. 반면 충돌이 빈번하게 일어나는 데이터인 경우 Pessimistic Lock은 Optimistic Lock에 비해 뛰어난 성능을 제공한다.

Optimistic Lock 활용해 보기

이번에는 낙관적 락(Optimistic Lock)으로 동시성을 제어하여 정합성 문제를 해결해 본다.
낙관적 락(Optimistic Lock)은 실제 데이터베이스의 락을 이용하지 않고 version을 이용하여 정합성을 맞추는 방법이다.

위 이미지는 서버 1과 서버 2가 version이 1인 데이터를 동시에 조회하는 상황이다.

서버 1이 먼저 데이터를 변경한다고 하자. 이때 재고만 변경하는 게 아니라 version의 값도 변경한다.

이런 경우 server2는 version이 1인 데이터를 update 한다는 쿼리를 날리지만 이미 서버 1이 version의 값도 변경하여 update 쿼리가 실패하고 만다. 이렇게 업데이트가 실패하면 애플리케이션 레벨에서 다시 데이터를 조회한 후 업데이트를 수행하는 로직을 짜야한다.

Stock

낙관적 락은 레코드(로우)의 버전을 확인하여 충돌을 감지하는 방식으로 동작한다.

이를 구현하기 위해 Stock 클래스에 version 필드를 추가하고 해당 필드에 @Version 어노테이션을 두어 특정 레코드에 대해 수정이 일어날 때마다 자동으로 증가하고 충돌 감지에 사용할 수 있도록 한다.

@Entity
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() {
	}

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

	public Long getQuantity() {
		return quantity;
	}

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

		// 현재 수량을 갱신
		this.quantity -= quantity;
	}
}

이때 @Version 어노테이션은 jakarta.persistence를 import 한다.

Stock 테이블을 조회해 보면 다음과 같이 version 컬럼이 추가된 것을 볼 수 있다.

@Version

Spring JPA에서 @Version 어노테이션은 낙관적 락(Optimistic Locking)을 구현하는 데 사용된다.

낙관적 락은 데이터를 변경하려 할 때, 다른 트랜잭션에 의해 데이터가 변경되었는지 확인하여 동시성을 제어하는 방식이다.

• @Version 필드 관리: @Version 어노테이션을 붙인 필드의 값은 엔티티가 업데이트될 때마다 자동으로 증가하여, 변경된 이력이 반영된다.
• 동시 수정 시도: 동일한 엔티티를 수정하려는 두 트랜잭션 중 먼저 시작한 트랜잭션이 엔티티를 수정하고 커밋하면, @Version 값이 증가한다.  이후 시작된 다른 트랜잭션이 데이터 수정 시 이전에 읽었던 @Version 값과 데이터베이스 값이 달라지므로 OptimisticLockingFailureException이 발생한다. 이 방식으로 동일 데이터 접근 시 트랜잭션 간 충돌을 방지할 수 있다.

낙관적 잠금을 사용할 경우 충돌 가능성을 고려해 예외 처리 로직을 추가해야 한다.

예를 들어, 재고 수 감소 실패 시 재시도하거나 사용자에게 에러 메시지를 표시하는 방식으로 대응할 수 있다.

 

낙관적 락의 예외 종류

• javax.persistence.OptimisticLockException (JPA)
• org.hibernate.staleObjectStateException (Hibernate)
• org.springframework.orm.ObjectOptimisticLockingFailureException (Spring)

Spring 기반의 JPA에서 낙관적 락을 사용하게 되면 충돌 시 Hibernate는 StaleStateException을 발생시키며, Spring은 이를 OptimisticLockingFailureException으로 감싸서 응답한다.

 

낙관적 락은 이러한 방식으로 Race Condition을 방지하지만, 예외 처리가 미흡할 경우 작업이 정상적으로 진행되지 않는다. 따라서, 낙관적 락을 사용할 때는 충돌 발생 시 재시도하거나 사용자에게 오류를 알리는 등의 적절한 예외 처리가 필요하다.

StockRepository

Optimistic Lock을 사용하는 findByIdWithOptimisticLock() 메서드를 추가한다.

이때에도 @Lock 어노테이션을 사용하는데 이번에는 LockModeType를 OPTIMISTIC로 둔다.

public interface StockRepository extends JpaRepository<Stock, Long> {
	@Lock(LockModeType.OPTIMISTIC) // Optimistic Lock을 위함
	@Query("select s from Stock s where s.id = :id")
	Stock findByIdWithOptimisticLock(Long id);
}

OptimisticLockStockService

findByIdWithOptimisticLock()를 호출하여 재고를 조회하고 업데이트하는 서비스 클래스를 추가한다.

@Service
public class OptimisticLockStockService {
	private final StockRepository stockRepository;

	public OptimisticLockStockService(StockRepository stockRepository) {
		this.stockRepository = stockRepository;
	}

	@Transactional
	public void decrease(Long id, Long quantity) {
		// Optimistic Lock으로 재고(Stock) 조회
		Stock stock = stockRepository.findByIdWithOptimisticLock(id);

		// 재고 수량 감소
		stock.decrease(quantity);
		stockRepository.save(stock);
	}
}

OptimisticLockStockFacade

낙관적 락(Optimistic Lock)은 실패했을 때 재시도를 해야 하므로 재시도 로직이 추가로 필요하다.

업데이트를 실패했을 때 재시도를 해야 하므로 while문으로 optimisticLockStockService.decrease(id, quantity)을 감싸준다.

 

수량 감소에 실패하게 되면 Thread.sleep(50)을 통해 50ms 이후에 재시도를 한다.

정상적으로 update가 되면 break를 통해 while문을 빠져나온다.

@Service
public class OptimisticLockStockFacade {

    private OptimisticLockStockService optimisticLockStockService;

    public OptimisticLockStockFacade(OptimisticLockStockService optimisticLockStockService) {
        this.optimisticLockStockService = optimisticLockStockService;
    }

    public void decrease(Long id, Long quantity) throws InterruptedException {
        while (true) {
            try {
                optimisticLockStockService.decrease(id, quantity);

                break;
            } catch (Exception e) {
                Thread.sleep(50);
            }
        }
    }
}

 테스트 코드

@SpringBootTest
class OptimisticLockStockFacadeTest {
    @Autowired
    private OptimisticLockStockFacade optimisticLockStockFacade;

    @Autowired
    private StockRepository stockRepository;

    @BeforeEach
    public void insert() {
        Stock stock = new Stock(1L, 100L);

        stockRepository.saveAndFlush(stock);
    }

    @AfterEach
    public void delete() {
        stockRepository.deleteAll();
    }

    @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 {
                    optimisticLockStockFacade.decrease(1L, 1L);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();

        Stock stock = stockRepository.findById(1L).orElseThrow();

        // 100 - (100 * 1) = 0
        assertEquals(0, stock.getQuantity());
    }
}

실행해 보면 테스트가 성공하는 것을 볼 수 있다.
 
참고로 예시와 같이 충돌이 자주 발생하는 경우 50ms 대기하고 재시도(다시 재고를 조회하여 업데이트)하는 로직이 있어 Pessmistic Lock에 비해 속도가 느리다.

 Pessmistic Lock으로 구현했을 때 테스트 수행 속도는 다음과 같다. (참고)

 

낙관적 락(Optimistic Lock)은 데이터베이스에 직접 락을 걸지 않으므로 성능상 이점이 있다.

하지만 예시와 같이 충돌이 빈번하게 일어나거나 빈번할 것이라고 예상된다면 Pessimistic Lock에 비해 성능이 저하된다.(이 경우 Pessimistic Lock을 사용한다.) 또한, 실패했을 때 재시도 로직을 개발자가 애플리케이션 레벨에 직접 작성해주어야 하기 때문에 추가 작업이 필요하다.

Named Lock 활용해 보기

마지막으로 Named Lock을 활용하여 동시성 문제를 해결해 본다.
Named Lock은 이름을 가진 메타 데이터(Meta data) 락이다.

이름을 가진 락을 획득한 후 해제 할 때까지 다른 세션은 이 락을 획득할 수 없게 된다.  

 
주의할 점은 앞서 살펴본 Pessimistic Lock과 Optimistic Lock과 달리 트랜잭션이 종료될 때락을 자동으로 반납하지 않는다. 따라서 개발자가 별도의 명령어로 Lock을 반납하는 로직을 작성해주어야 한다. 혹은 선점시간이 끝나면 락이 해제되도록 타임아웃을 걸어야 한다.
 

이전에 살펴봤던 비관적 락(Pessimistic Lock)은 Stock에 대해서 락을 걸었다면 Named Lock은 Stock에 락을 걸지 않고 별도의 공간에 Lock을 건다. Mysql에서는 getLock 명령어로 Named Lock을 획득하고 releaseLock 명령어로 해제할 수 있다.

위 이미지에서 Session-1이 ‘1’이라는 이름으로 Lock을 걸면 다른 세션인 Session-2는 Session-1이 ‘1’이라는 이름의 Lock을 반납해야 이를 획득할 수 있다. (두 번째 인자인 1000은 타임아웃을 걸기 위한 시간에 해당한다.)

 

실습에 들어가기 전 주의 사항이 있다.

같은 datasource를 사용하면 커넥션 풀이 부족해지는 현상으로 인해서 다른 서비스에도 영향을 끼칠 수 있다.

그렇기 때문에 실무에서는 datasource를 분리해서 사용하는 게 좋다.

아래 실습에서는 같은 datasource를 사용한다.

LockRepository

Named Lock을 위한 리포지토리를 구현한다.

public interface LockRepository extends JpaRepository<Stock, Long> {
	@Query(value = "select get_lock(:key, 3000)", nativeQuery = true)
	void getLock(String key);

	@Query(value = "select release_lock(:key)", nativeQuery = true)
	void releaseLock(String key);
}

편의를 위해 JPA의 Native Query 기능을 활용하여 Named Lock을 얻는 getLock 메서드와 반납하는 releaseLock을 구현한다.

 

또한 비즈니스 로직과 동일한 DataSource로 Named Lock을 구현한다.

(앞서 말한 것처럼 실무에서는 Named Lock이 비즈니스 로직과 동일한 DataSource를 사용하게 되면 커넥션 풀(Connection Pool)이 부족해져 다른 서비스에 영향을 줄 수 있다. 따라서 DataSource를 분리하여 사용하는 것을 추천한다.)

NamedLockStockFacade

실제 비즈니스 로직 전후로 Named Lock을 획득하고 로직 수행 후 해제를 수행하는 클래스이다.
비즈니스 로직(여기서는 decrease) 수행 전후로 getLock과 releaseLock을 호출하여 Named Lock을 획득/반납한다.

이때 Lock 이름은 row의 id로 지정하였다.

@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){
		try {
			// id 값을 기준으로 Named Lock 획득
			lockRepository.getLock(id.toString());

			// 재고 감소 로직
			stockService.decrease(id, quantity);
		} finally {
			// 모든 비즈니스 로직을 수행하고 나면 lock 해제
			lockRepository.releaseLock(id.toString());
		}
	}
}

StockService

전체 로직은 Pessimistic Lock, Optimistic Lock과 동일하다.

차이점으로는 재고 감소를 위한 decrease() 메서드의 Propagation 수준을 REQUIRES_NEW로 지정한다.
만약 부모와 같은 트랜잭션에서 Named Lock 조회 로직을 사용한다면 비즈니스 로직 수행 중에 예외가 발생하여 실패하는 경우, 비즈니스 로직을 롤백하면서 Lock 해제까지 롤백되어 버린다. Lock은 여전히 이 스레드가 획득한 상태로 남아있게 되고, 다른 스레드는 Lock을 획득하기 위해 무한정 대기에 빠지게 있다. 따라서 비즈니스 로직은 Named Lock을 획득하는 부모와 별도의 트랜잭션에서 수행한다. 이를 위해 Propagation 수준을 REQUIRES_NEW로 지정한다.

@Service
public class StockService {
	// StockService : 재고(Stock)에 대한 CRUD 기능을 통한 비즈니스 로직 제공
	private final StockRepository stockRepository;

	public StockService(StockRepository stockRepository) {
		this.stockRepository = stockRepository;
	}

	// 재고 감소 로직 구현
	// Named Lock을 사용하는 경우 부모와 별도의 트랜잭션에서 수행되어야하므로 Propagation 수준을 REQUIRES_NEW로 지정한다.
	@Transactional(propagation = Propagation.REQUIRES_NEW)
	public synchronized void decrease(Long id, Long quantity) {
		// Stock 조회
		Optional<Stock> stock = stockRepository.findById(id);

		// 재고 감소
		stock.orElseThrow(() -> new RuntimeException("해당하는 재고가 없습니다."))
			.decrease(quantity);

		// 갱신된 값을 저장
		stockRepository.save(stock.get());
	}
}

application.yml

같은 datasource를 사용하기 때문에 커넥션 풀 사이즈를 변경한다.

spring:
  jpa:
    hibernate:
      ddl-auto: create
    show-sql: true
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    ...
    hikari:
      maximum-pool-size: 40

...

NamedLockStockFacadeTest

NamedLockStockFacade을 테스트하여 Named Lock이 잘 동작하여 동시성 이슈를 해결하고 재고 수량을 성공적으로 차감하는지 테스트한다.

@SpringBootTest
class NamedLockStockFacadeTest {
	@Autowired
	private NamedLockStockFacade namedLockStockFacade;

	@Autowired
	private StockRepository stockRepository;

	// 각 테스트가 실행되기 전에 데이터베이스에 테스트 데이터 생성
	@BeforeEach
	public void before() {
		stockRepository.saveAndFlush(new Stock(1L, 100L));
	}

	// 각 테스트를 실행한 후에 데이터베이스에 테스트 데이터 삭제
	@AfterEach
	public void after() {
		stockRepository.deleteAll();
	}

	@Test
	public void 동시에_100개의_요청() throws InterruptedException {
		// when
		// 100개의 쓰레드 사용(멀티스레드)
		int threadCount = 100;

		// ExecutorService : 비동기로 실행하는 작업을 간단하게 실행할 수 있도록 자바에서 제공하는 API
		ExecutorService executorService = Executors.newFixedThreadPool(32);

		// CountDownLatch : 작업을 진행중인 다른 스레드가 작업을 완료할때까지 대기할 수 있도록 도와주는 클래스
		CountDownLatch latch = new CountDownLatch(threadCount);
		// 100개의 작업 요청
		for(int i = 0; i < threadCount; i++) {
			executorService.submit(() -> {
				try {
					namedLockStockFacade.decrease(1L, 1L);
				} finally {
					latch.countDown();
				}
			});
		}
		latch.await();

		// then
		Stock stock = stockRepository.findById(1L).orElseThrow();
		assertEquals(0, stock.getQuantity());

	}
}

 테스트가 성공적으로 수행되는 것을 볼 수 있다.

작업 스레드 중 하나인 pool-1-thread-4의 로그를 추적해 보면 다음과 같이 수행되는 것을 볼 수 있다.
1. Named Lock 획득

2. 비즈니스 로직 수행(재고 차감)

3. Named Lock 해제

 

Named Lock은 주로 분산락(Distributed lock)을 구현할 때 사용한다.

또한 타임아웃을 구현하기 까다로운 Pessimistic Lock과 달리 Named Lock은 손쉽게 이를 구현할 수 있다.

이외에도 데이터 삽입시 정합성이 중요한 경우에도 사용할 수 있다.
하지만 트랜잭션 종료 시 Lock을 꼭 해제해줘야 하므로 주의해서 사용한다. 따라서 실제로는 구현방법이 복잡해질 수 있다.

Spring JPA Lock 옵션 (LockModeType)

LockModeType설명

NONE	락 사용 안 함 (기본값)
OPTIMISTIC	낙관적 락 사용 데이터 수정 시 다른 트랜잭션에 의해 데이터가 변경 됐는지 확인 @Version으로 버전 컬럼 관리
OPTIMISTIC_FORCE_INCREMENT	낙관적 락 사용 락이 걸린 엔티티 Version을 강제로 증가시켜 다른 트랜잭션에서 해당 엔티티를 읽을때 충돌을 발생시킴
PESSIMISTIC_READ	비관적 락 사용 엔티티에 락을 건 트랜잭션이 완료될 때까지 다른 트랜잭션에서 해당 엔티티 변경 방지 다른 트랜잭션에서는 읽기 가능
PESSIMISTIC_WRITE	비관적 락 사용 엔티티에 락을 건 트랜잭션이 완료될 때까지 다른 트랜잭션에서 해당 엔티티를 읽거나 쓸 수 없게 함
PESSIMISTIC_FORCE_INCREMENT	비관적 락 사용 락이 걸린 엔티티 Version을 강제로 증가시켜 다른 트랜잭션에서 해당 엔티티를 읽을때 충돌을 발생시킴

트랜잭션 격리 레벨 관리 (@Transactional의 isolation 레벨)

@Transactional의 isolation 속성을 사용하여 트랜잭션 간 동시성 문제를 방지하고 데이터를 보호할 수 있다.

격리 단계 (Isolation Level)

Isolation Level설명

READ_UNCOMMITTED	가장 낮은 격리 수준. 다른 트랜잭션에서 아직 커밋되지 않은 변경 내용을 읽을 수 있음 Dirty Read, Non-Repeatable Read, Phantom Read 모두 발생 가능 READ_UNCOMMITED는 기본 격리 수준이며, 추가 정보 없이도 트랜잭션 처리
READ_COMMITTED	다른 트랜잭션에서 커밋된 변경 내용만 읽을 수 있음 Dirty Read는 방지하지만, Non-Repeatable Read와 Phantom Read는 발생 가능 SELECT 쿼리에 FOR UPDATE 키워드를 추가하여 락을 건다. 이를 통해 다른 트랜잭션이 해당 데이터를 변경하지 못하게 한다.
REPEATABLE_READ	같은 트랜잭션 내에서 여러 번 데이터를 읽을 때 항상 같은 결과를 보장 Dirty Read와 Non-Repeatable Read는 방지하지만, Phantom Read는 발생 가능 SELECT 쿼리에 FOR UPDATE 키워드를 추가하여, 락을 건 데이터가 다른 트랜잭션에 의해 변경되지 않도록 함 트랜잭션 시작 시점의 데이터 상태를 기록하여, 트랜잭션 진행 중에 다른 트랜잭션이 데이터를 변경해도 영향을 받지 않도록 함 (ReadView)
SERIALIZABLE	가장 높은 격리 수준 트랜잭션들을 순차적으로 실행하여 동시성 문제를 완전히 방지 모든 동시성 문제를 방지하며, 가장 안전하지만 성능 저하가 발생할 수 있음 SELECT 쿼리에 FOR UPDATE 키워드를 추가하여, 락을 건 데이터가 다른 트랜잭션에 의해 변경되지 않도록 함 트랜잭션 시작 시점의 데이터 상태를 기록하여, 트랜잭션 진행 중에 다른 트랜잭션이 데이터를 변경해도 영향을 받지 않도록 함 (ReadView) 모든 쿼리에 SERIALIZABLE 옵션을 추가하여, 모든 쿼리가 순차적으로 실행

예시 코드

@Service
public class IsolationService {

    // READ_UNCOMMITTED
    @Transactional(isolation = Isolation.READ_UNCOMMITTED)
    public void processReadUncommitted() {
        // 커밋되지 않은 데이터도 읽기 가능
        // Dirty Read, Non-Repeatable Read, Phantom Read 가능
    }

    // READ_COMMITTED
    @Transactional(isolation = Isolation.READ_COMMITTED)
    public void processReadCommitted() {
        // 커밋된 데이터만 읽기 가능
        // Dirty Read 방지, Non-Repeatable Read와 Phantom Read 가능
    }

    // REPEATABLE_READ
    @Transactional(isolation = Isolation.REPEATABLE_READ)
    public void processRepeatableRead() {
        // 같은 트랜잭션 내에서 읽은 데이터는 항상 같은 결과를 보장
        // Dirty Read와 Non-Repeatable Read 방지, Phantom Read 가능
    }

    // SERIALIZABLE
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public void processSerializable() {
        // 트랜잭션 순차적 실행, 모든 동시성 문제 방지
        // 가장 높은 수준의 격리, 성능 저하 발생 가능
    }
}

 

 

지금까지 데이터베이스에서 제공하는 3가지 방식으로 동시성 이슈에 대해 알아봤다.

다음은 레디스(Redis)로 분산 락(Distributed Lock)을 구현하여 동시성 이슈를 해결해 본다.

참고

https://velog.io/@lsb156/JPA-Optimistic-Lock-Pessimistic-Lock

https://www.inflearn.com/course/%EB%8F%99%EC%8B%9C%EC%84%B1%EC%9D%B4%EC%8A%88-%EC%9E%AC%EA%B3%A0%EC%8B%9C%EC%8A%A4%ED%85%9C/dashboard

https://nooblette.tistory.com/entry/%EC%8B%9C%EC%8A%A4%ED%85%9C-%EB%94%94%EC%9E%90%EC%9D%B8-%EC%9E%AC%EA%B3%A0%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-%EB%8F%99%EC%8B%9C%EC%84%B1%EC%9D%B4%EC%8A%88-%ED%95%B4%EA%B2%B0%EB%B0%A9%EB%B2%95-23-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%9D%BDLock%EC%9C%BC%EB%A1%9C-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0#google_vignette

https://sjiwon-dev.tistory.com/20