동시성 이슈 해결방법 (1/3) - 동시성 이슈와 Application Level로 해결하기

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

 

어떤 작업이 오래 걸려 서비스 응답 속도에 영향을 주는 경우, 애플리케이션의 성능 향상을 위해 멀티 스레드 환경을 고려할 수 있다. 멀티 스레드를 통해 여러 작업 스레드가 동시에 실행되어 응답 속도와 처리량을 개선할 수 있다. 그러나, 여러 스레드가 동시에 동일한 데이터에 접근하고 수정할 경우 데이터 일관성이 깨지거나 레이스 컨디션(Race Condition)과 같은 문제가 발생할 수 있다. 이는 작업이 의도한 대로 처리되지 않게 만들어, 데이터 무결성을 손상시킬 위험이 있다.

 

강의에서는 상품 재고를 관리하는 간단한 재고 시스템을 구현하여 멀티 스레드 환경에서 발생하는 동시성 문제를 마주하고 발생 원인을 분석한다. 해결 방안으로는 3가지 방법을 차례대로 적용하여 해결해본다.

 

첫번째 방법은 Application level에서 자바의 synchronized 키워드를 사용하여 해결하는 것이고, 두번째는 Database가 제공하는 Lock, 마지막으로 세번째는 레디스(Redis)로 분산 락(Distributed lock)을 구현하여 해결하는 것이다.
 
이번 글에서는 멀티 스레드 환경에서 개발할때 발생하는 문제점과 발생 원인을 살펴보고 먼저 Application level에서 자바의 synchronized 키워드를 사용하여 해결해볼 것이다.

재고감소 로직 작성

간단한 재고 관리 시스템을 구현한다. 먼저 재고 감소 로직을 작성한다.

Stock

데이터베이스의 재고 정보를 담고 있는 테이블과 매칭 되는 엔티티다.

@Entity
public class Stock {

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

	private Long productId;
	private Long quantity;

	public Stock() {
	}

	public Stock(Long id, Long quantity) {
		this.id = id;
		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;
	}
}

StockRepository

// StockRepository : 재고(Stock)에 대한 데이터베이스와의 CRUD 기능 제공
public interface StockRepository extends JpaRepository<Stock, Long> {
}

StockService

재고 서비스에 관해 핵심 비즈니스 로직이 존재한다.
재고 감소 로직인 decrease() 메서드를 구현한다.

@Service
public class StockService {
	private final StockRepository stockRepository;

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

	// 재고 감소 로직 구현
	@Transactional
	public void decrease(Long id, Long quantity) {
		// Stock 조회
		Optional<Stock> stock = stockRepository.findById(id);

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

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

StockServiceTest

@SpringBootTest
class StockServiceTest {
	@Autowired
	private StockService stockService;

	@Autowired
	private StockRepository stockRepository;

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

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

	@Test
	public void 재고감소() {
		// when
		stockService.decrease(1L, 1L);

		// then : 1L 상품의 재고 : 100 - 1 = 99개가 남아있어야함
		Stock stock = stockRepository.findById(1L).orElseThrow();
		assertEquals(99, stock.getQuantity());
	}
}

먼저 하나의 스레드가 재고 감소 로직을 호출하는 경우를 테스트한다.

실행 해보면 테스트가 성공하는 것을 볼 수 있다.

 

다음으로는 100개의 스레드가 동시에 재고 감소 로직을 호출하는 경우를 테스트한다.

@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 {
				stockService.decrease(1L, 1L);
			} finally {
				// CountDownLatch 1 감소
				latch.countDown();
			}
		});
	}
    
	// CountDownLatch이 0이 될때까지 스레드 대기 - await() 이후 로직은 CountDownLatch이 0이 되고나서 수행된다.
	latch.await();

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

재고 수량을 100개로 세팅하고 100개의 스레드가 한 번씩 재고 감소 로직을 호출하기 때문에 최종적으로 0개의 수량이 남게 될 것을 예상했다.

 

하지만 실행 해보면 최종적으로 95개의 재고 수량이 남고 테스트는 실패한다.

문제 발생 원인

이는 두개 이상의 스레드가 재고(Stock)라는 공유 데이터에 동시에 접근하고 변경하면서 경합 상태(Race Condition)이 발생했기 때문이다. 다음과 같이 순차적으로 재고의 수량(quantity)을 업데이트할 것을 예상했다.

 
하지만 실제로는 Thread-1이 재고 수량을 조회(e.g. quantity = 5)하고 수량을 1만큼 감소하고나서 DB에 반영하기 전에 Thread-2가 동일한 수량의 재고를 조회하고 1만큼 감소한다. 이때 Thread-1이 1만큼 감소한 재고 수량(e.g. quantity = 4)을 DB에 반영하고 Thread-2도 1만큼 감소한 값으로 갱신하면 Thread-1이 작업하고 반영한 결과는 사라진다. (이를 Lost update라 한다.)

결국 두 개 이상의 스레드가 id = 1인 Stock이라는 공유 데이터에 엑세스하여 동시에 변경하면서 경합 상태(Race condition)이 발생한 것이다. 이를 해결하기 위해서는 하나의 스레드가 작업이 완료된 이후에 다른 스레드가 데이터에 접근할 수 있도록 제어를 해야한다.

Application Level에서 문제 해결

먼저 Application Level에서 동시성 이슈인 경합 상태를 해결한다.

자바에서 제공하는 Synchronized 키워드로 문제를 해결해본다.

Synchronized

한 개의 스레드만 접근이 가능하도록 자바에서 제공하는 키워드이다.

메서드 선언부에 다음과 같이 Synchronized 키워드를 추가하면 한 개의 스레드만 메서드에 접근이 가능하다.

@Service
public class StockService {
	private final StockRepository stockRepository;

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

	// 재고 감소 로직 구현
	@Transactional
	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());
	}
}

 StockServiceTest에 작성했던 동시에_100개의_요청()를 호출하여 테스트를 다시 실행해본다.

테스트가 성공할 줄 알았으나 여전히 테스트가 실패하는 것을 볼 수 있다.

Synchronized 실패 원인

이는 StockService의 decrease() 메서드에 추가한 스프링의 @Transactional 어노테이션의 동작 방식 때문이다. 스프링의 @Transactional 어노테이션을 메서드 혹은 클래스 레벨에 추가하면, 스프링은 해당 클래스가 아닌 해당 클래스를 감싸고 있는 proxy 객체를 빈으로 등록하고 의존관계 주입에 사용한다.
 
즉, 다음과 같이 StockService를 감싸고 있는 TransactionStockService 클래스를 스프링이 빈으로 등록하는 것이다. 스프링의 @Transactional 어노테이션은 아래 코드와 같이 트랜잭션을 시작하고 타겟 클래스를 호출하고나서 로직이 완료되면 변경사항을 커밋(혹은 롤백)하고 트랜잭션을 종료하는 방식으로 동작한다.

package com.example.stock.service;

public class TransactionStockService {
	private StockService stockService;

	public TransactionStockService(StockService stockService) {
		this.stockService = stockService;
	}

	public void decrease(Long id, Long quantity) {
		// 트랜잭션 시작
		startTransaction();

		// 타겟 클래스 호출
		stockService.decrease(id, quantity);

		// 트랜잭션 종료
		endTransaction();
	}

	private void startTransaction() {
		System.out.println("Transaction started");
	}

	private void endTransaction() {
		System.out.println("Commit");
	}
}

 그림으로 나타내면 다음과 같다.

하지만 이러한 @Transactional 어노테이션의 동작 방식 때문에 의도와 다르게 동작한다.

decrease() 메서드에 @Transactional 어노테이션을 두게되면 StockRepository의 save() 메서드를 호출하는 시점에 갱신된 값이 DB에 반영(커밋)하는 것이 아니라 StockService의 모든 로직을 수행하고 나서 StockService의 proxy 객체가 변경사항을 반영(커밋)한다.

다시 말해 StockService의 decrease 메서드는 한 번에 한 스레드만 접근하기 위해 synchronized 키워드를 두었어도, @Transactional로 인해 프록시 객체에는 여러 스레드가 동시에 접근이 가능하다. 그래서 proxy 객체가 변경사항을 반영(커밋)하기 전에 다른 스레드에서 재고 수량을 조회하면 이전의 재고 수량을 조회하게 되고 결국 여전히 경합 상태가 발생하는 것이다.

@Transactional 동작원리

그림으로 좀 더 자세히 알아보자.

@Transaction이 적용된 클래스는 CGLIB에 의해서 런타임에 해당 클래스 기반 프록시가 생성된다

그리고 @Transactional 로직으로 진입하기 전/후에서 Transaction Begin & Commit/Rollback이 진행되는 것이다

• 이렇게 @Transactional이 걸려있는 비즈니스 로직에 synchronized 키워드를 붙이게 된다면 다음과 같이 동작한다

• 해당 비즈니스 로직에 synchronized가 걸려있으니 해당 로직으로 진입할때 Monitor Lock을 가지고 진입하게 되는것이다

• 그러면 Thread1을 제외한 나머지 쓰레드들은 비즈니스 로직에 접근하지 못하고 Lock을 얻기 위해서 대기한다
• 여기서 Thread1이 비즈니스 로직을 끝내고 커밋/롤백 시점으로 돌입한다고 가정하자

• 이 시점에 Thread2가 진입하게 되면 아직 Thread1의 로직이 commit되기 전이므로 DB에 존재하는 stock의 수량은 여전히 100이다
• 그에 따라서 Thread2는 stock의 수량을 100으로 받게 되고 그에 따른 로직이 진행된다

이러한 이유로 인해서 @Transactional + synchronized는 Spring의 Proxy 메커니즘으로 인해 동시성 문제를 해결하지 못하는 것이다

 

물론 @Transactional 어노테이션을 해제하고 실행하면 테스트 케이스가 성공하는 것을 볼 수 있다.

Synchronized와 @Transactional 사용 이슈

그렇다고 동시성 이슈를 해결하기 위해 @Transactional 어노테이션을 사용하지 말고 synchronized 키워드를 두어야할까?
 
스프링의 @Transactional 어노테이션은 데이터 관리 관점에서 굉장한 편의성을 개발자에게 제공한다.

만일 이 어노테이션을 사용하지 않는다면 개발자는 비즈니스 로직을 작성할때마다 매번 DB 커넥션을 조회하고 커밋하거나 롤백하는 로직을 작성해주어야할 것이다. 또한 스프링의 트랜잭션 매니저는 다양한 데이터 접근 기술에 대한 추상화된 트랜잭션 관리 방안을 제공하는데 이러한 이점도 얻을 수 없다.
 
또한 스프링의 @Transactional 어노테이션은 체크 예외와 언체크 예외(런타임 예외) 별로 다르게 동작하며 안정적인 프로그램 개발에도 많은 기여를 한다.

예컨대 예상치 못한 런타임 예외(e.g. NullPointerException, IllegalArgumentException)가 발생하면 트랜잭션을 롤백하여 변경사항을 DB에 반영하지 않는다. 반면 비즈니스 예외상 의도적으로 던지는 예외를 구현하는데 주로 쓰이는 체크 예외가 발생하면 트랜잭션을 커밋하여 진행 상태를 DB에 반영하는 식이다. (물론 @Transactional의 rollbackFor 속성을 사용하여 특정 체크 예외에 대해서도 롤백을 지정할 수 있다.) 만일 @Transactional 어노테이션을 사용하지 않는다면 이처럼 예외 계층 별로 적절한 처리 방안을 개발자가 모두 작성해주어야할 것이다.

분산 환경에서의 synchronized 한계

이 외에도 자바의 Synchronized 키워드가 제공하는 동기화 작업은 하나의 프로세스 안에서만 보장이 된다는 치명적인 단점이 있다. 즉 한 대의 서버에서 멀티쓰레드로 작업하는 경우에는, 공유 자원에 대한 접근은 한 대의 서버안에서만 이루어지기 때문에 안전한 접근을 보장한다. 하지만 서버가 여러대인 경우 여러 서버에서 공유 자원에 접근할 수 있으므로 스레드 안전성이 보장이 되지 않는다.

 
실무에서 일반적으로(간단한 시스템일지라도) 운영 서버는 보통 한 대만 두지 않는다.

여러 대의 장비와 서버 인스턴스를 두는데 결국 여러대의 서버가 동시에 공유 자원에 접근하게되면 결국 여전히 Race Condition이 발생하는 것이다. 따라서 실무에서 Synchronized를 거의 사용하지 않는다.

 

결국 동시성 이슈를 해결하려면 별도의 동기화 메커니즘이 필요하다.

다음 글에서는 데이터베이스에서 제공하는 Lock을 활용하여 문제를 해결해본다.

참고

https://velog.io/@mohai2618/%EB%8F%99%EC%8B%9C%EC%84%B1-%ED%99%98%EA%B2%BD-%ED%85%8C%EC%8A%A4%ED%8A%B8%ED%95%98%EA%B8%B0

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-13-%EB%AC%B8%EC%A0%9C-%EC%9D%B8%EC%8B%9D%EA%B3%BC-Application-Level%EB%A1%9C-%ED%95%B4%EA%B2%B0%ED%95%98%EA%B8%B0