동시성 문제를 해결하는 다양한 방법, 분산 환경에서의 동시성 문제

1. 개요 

벌써 동시성 관련 포스터만 4개째이다...

 

진행 중인 프로젝트에선 MySQL Lock을 걸어 동시성 이슈를 해결했었는데 다른 방법도 알게되어 소개하고자 한다.  

 

단일 환경에선 DB에 비관적 락 등을 이용하여 동시성을 제어할 수 있지만, 여러 대의 DB가 존재하는 분산 DB 환경에서는 동시성 문제를 해결할 수 없다.

 

이때 분산 락을 활용해 동시성 문제를 해결한다. Redis는 분산락을 해결하기 위해 널리 사용되는 방법 중 하나이다. 

 

 

 

 

2. 동시성 문제가 일어날 경우

다음은 재고 엔티티가 있고 재고 감소를 하는 기능을 테스트하는 코드이다.  

 

 

- Entity

@Entity
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class Stock {
    @Id
    @GeneratedValue
    @Column(name = "stock_id")
    private Long id;

    private Long quantity;

    public void decrease(Long quantity) {
        if (this.quantity - quantity < 0) {
            throw new RuntimeException("error");
        }

        this.quantity -= quantity;
    }
}

 

 

- 서비스 코드

@Service
@RequiredArgsConstructor
@Transactional
public class StockService {
    private final StockRepository stockRepository;

    public void decrease(Long stockId, Long val) {
        Stock stock = stockRepository.findById(stockId).get();
        stock.decrease(val);
    }
}

 

 

- 테스트 코드

@SpringBootTest
public class StockTest {
    @Autowired
    private StockRepository stockRepository;
    @Autowired
    private StockService stockService;

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

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

    @Test
    public void decrease_test() {
        stockService.decrease(1L, 1L);

        Stock stock = stockRepository.findById(1L).orElseThrow();
        // 100 - 1 = 99

        assertEquals(99, stock.getQuantity());
    }
}

 

처음 수량은 100개였고 1개를 감소시켜 결과를 비교하는 것으로 재고 감소 기능을 테스트했다. 

무리 없이 통과하는 것을 볼 수 있다. 

하지만 이 코드의 문제점은 무엇일까? 

 

요청이 동시에 여러 개가 들어온다면 예상치 못하게 동작할 수 있다. 

 

 

- 동시성 테스트

@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 - (100 * 1) = 0
    assertEquals(0, stock.getQuantity());
}

 

멀티 스레드를 이용하기 위해 ExecutorService를 사용하였다. newFixedThreadPool(32)는 최대 32개의 스레드를 가진 스레드 풀을 생성하는 메서드이다. 이를 사용하여 주문 처리를 동시에 처리한다.

 

for 반복문으로 100개의 요청을 보낸다. 

 

CountDownLatch를 사용하여 100개 요청이 끝날때까지 기다리도록 하였다. 

 

예상되는 바는 100번 감소를 시키니까 0이 되야한다. 

 

하지만 실제 결과는 다음과 같다.

 

 

위와 같은 결과가 나타나는 이유가 바로 동시성 문제 때문이다. 

 

문제는 Stock 엔티티의 decrease() 메서드에서 발생한다.

현재 구현에서는 재고 수량을 감소시키기 전에 수량이 음수가 되는지 확인하고, 음수가 되면 예외를 던진다. 그러나 여러 스레드가 동시에 이 메서드를 호출할 경우, 첫 번째 스레드가 수량을 확인한 후 감소하기 전에 다른 스레드가 수량을 변경할 수 있다. 이로 인해 잘못된 결과가 발생하게 되는 것이다.

 

 

 

 

 

3. 직접 Update 쿼리문을 날려 해결

update 하는 과정을 잘 분석해 보면 JPA의 변경 감지를 사용하고 있기 때문에 동시성 문제가 일어나는 걸 알 수 있다. 변경 감지의 경우 바로바로 데이터베이스 값을 수정하는 것이 아니라 커밋 하는 시점에 flush가 일어나 쿼리가 날아가게 된다. 그래서 한 트랜잭션에서 select와 update 하는 사이에 누군가가 동시에 select 하고 update 하게 되면 갱실 분실이 일어난다.

 

그렇기 때문에, 변경 감지를 포기하고 직접 update 문을 날려주어서 정합성을 맞춰줄 수도 있다. update 문의 경우 x lock이 걸리기 때문에 해당 부분에서 다음과 같은 과정이 일어나 동시성이 발생하지 않는다.

 

 

 

@Modifying
@Query("update Stock s set s.quantity = s.quantity - :val where s.id = :stockId")
int decrease(@Param("stockId") Long stockId, @Param("val") Long val);

 

 

 

 

 

 

 

4. synchronized를 활용한 해결

- 서비스 코드

@Service
@RequiredArgsConstructor
@Transactional
public class StockService {
    private final StockRepository stockRepository;

    public synchronized void decrease(Long stockId, Long val) {
        Stock stock = stockRepository.findById(stockId).get();
        stock.decrease(val);
    }
}

 

 

하지만 여전히 실패하게 된다. 이유는 뭘까?

 

 

그 이유는 스프링의 @Transactional 동작 방식 때문이다.

 

스프링은 @Transactional이 붙은 경우 프록시 객체를 만들어서 사용한다. 위의 코드에서 @Transactional 어노테이션은 decrease 메서드에 적용되어 있기 때문에, 실제로 메서드가 실행될 때는 decrease 메서드를 호출한 곳에서 프록시 객체를 통해 실행되게 된다.

 

즉, 메서드 자체에 대해서는 동기화를 할 수 있지만 트랜잭션 컨텍스트 내에서 데이터베이스에 반영하기 전에 다른 쓰레드가 접근한다면 다른 쓰레드는 decrease 변경이 반영되기 전 값을 가져올 수 있다. 

 

 

 

 

 

 

5. 데이터 베이스 Lock을 활용한 해결

Lock에 대해선 예전에 자세히 다룬 포스터가 있어 링크 남겨두겠다

 

 

 

 

 

6. Redis를 활용한 해결

Redis를 사용하면 MySQL의 Lock을 걸어 해결할 수 없는 상황에서도 동시성 문제를 해결할 수 있다. 

 

 

1. Lettuce 라이브러리 이용

- setnx 명령어를 활용하여 분산 락 구현 (spin lock 방식) 

- retry 로직을 개발자가 구현해주어야 한다. 

 

SETNX 명령어는 "SET if Not eXists"의 약자로, 키가 존재하지 않을 때만 특정 값을 설정하는 명령어이다.

 

이 방식은 mysql을 사용할 때의 NamedLock과 비슷한 방식이라고 할 수 있다. 

 

 

먼저 다음과 같이 레디스 레포지토리를 만든다. 

@Component
@RequiredArgsConstructor
public class RedisLockRepository {

    private final RedisTemplate<String, String> redisTemplate;

    public Boolean lock(Long key) {
        return redisTemplate
                .opsForValue()
                .setIfAbsent(generateKey(key), "lock", Duration.ofMillis(3_000));
    }

    public Boolean unlock(Long key) {
        return redisTemplate.delete(generateKey(key));
    }

    private String generateKey(Long key) {
        return key.toString();
    }
}

 

 

- Facade 클래스 생성

@Component
@RequiredArgsConstructor
public class LettuceLockStockFacade {

    private final RedisLockRepository redisLockRepository;

    private final StockService stockService;

    public void decrease(Long key, Long quantity) throws InterruptedException {
        while (!redisLockRepository.lock(key)) {
            Thread.sleep(10);
        }

        try {
            stockService.decrease(key, quantity);
        } finally {
            redisLockRepository.unlock(key);
        }
    }
}

 

 

 

 

2. Redisson 사용

Redisson은 pub-sub 기반의 lock 구현을 제공한다.

pub-sub 기반은 채널을 하나 만들고 lock을 점유중인 쓰레드가 다음 lock을 점유하려는 쓰레드에게 점유가 끝났음을 알려주면서 lock을 주고 받는 방식이다.

 

 

 

- 의존성 추가

dependencies {
    // Redisson
    implementation 'org.redisson:redisson-spring-boot-starter:3.17.4'
}

 

 

- Facade 클래스 생성

@Component
@RequiredArgsConstructor
public class RedissonLockStockFacade {

    private final RedissonClient redissonClient;

    private final StockService stockService;

    public void decrease(Long key, Long quantity) {
        RLock lock = redissonClient.getLock(key.toString());

        try {
            boolean available = lock.tryLock(10, 1, TimeUnit.SECONDS);

            if (!available) {
                System.out.println("lock 획득 실패");
                return;
            }

            stockService.decrease(key, quantity);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            lock.unlock();
        }
    }
}

 

 

Lettuce 와 다르게 Redisson 은 계속 락 획득을 계속 시도하는게 아니기 때문에 Redis의 부하를 줄일 수 있다. 

 

 

 

 

 

 

 

7. 결론

처음 이 포스터를 작성한 이유는 데이터베이스에 직접 Lock을 거는 것 보다 인메모리 데이터베이스인 Redis를 사용해서 Lock을 처리해 성능을 향상 시키고자 했기 때문이다. 

 

하지만 단일서버, 단일DB를 사용할 땐 Redis의 성능이 더 나오지 않았다.

 

Redis는 분산 환경에서 데이터베이스에 Lock을 걸어 동시성 문제를 해결할 수 없을 때 주로 사용하였고, TTL을 설정해 데드락을 방지할 수 있었다. 

 

나는 단일 서버 & 단일 DB를 사용하고 있었고, 추후에 서버가 확장된다면 그때 마이그레이션 해도 큰 문제 없을 것 같아 기존에 사용하던 MySQL Lock을 그대로 사용하기로 했다.