주문 시 재고수량이 마이너스가 되는 동시성 문제 해결하기

@Test
public void orderQtyTest() throws Exception {
    // 1. 테스트할 상품의 재고수량을 1로 설정한다.(opt_comb_no = 1, 2)
    int[] optCombArr = {1};
    int[] invQtyArr = {1};
    int updateInvQtyresult = setInvQty(optCombArr, invQtyArr);

    // 재고수량 변경이 잘 되었는지 체크
    assertTrue(optCombArr.length == updateInvQtyresult);

    // 2. 2개의 쓰레드로 총 10개의 주문을 시도한다.
    int numberOfThreads = 2;
    int ordersPerThread = 5;

    ExecutorService executorService = Executors.newFixedThreadPool(numberOfThreads);

    for (int i = 0; i < numberOfThreads; i++) {
        executorService.execute(() -> {
            for (int j = 0; j < ordersPerThread; j++) {
                Order order = FOS_OrderServiceImplTest.getOrder();
                try {
                    // 주문을 생성한다.
                    service.order(order);
                } catch (Exception e) {
                    e.printStackTrace();
                    fail("주문 생성 실패");
                }
            }
        });
    }

    // 모든 스레드가 종료될 때까지 대기
    executorService.shutdown();
    while (!executorService.isTerminated()) {
        // 대기
    }

    // 3. 재고수량이 기대한값대로 0인지 체크
    List<ProdOptDTO> prodOptDTOList = prodOptDAO.selectProductQty(optCombArr);
    int totalProdInvQty = prodOptDTOList.stream().mapToInt(ProdOptDTO::getInvQty).sum();

    assertEquals(0, totalProdInvQty);
}

초기 재고수량은 1개. 2명의 사용자가 동시에 같은 상품을 주문했을 경우에 조금 늦게 들어온 사용자는 재고수량 검증 로직에 걸려 주문이 안 되었어야 하나 결과를 보면 재고수량은 -1개가 되었고 실제로 주문이 된 것을 확인할 수 있다.

2. 발생원인

MySQL의 기본 Isolation Level은 Repeatable Read다. Tx이 시작된 이후 변경은 무시되는 완화된 격리 수준이다. 이렇게 Repeatable Read 격리에서는 트랜잭션에서의 데이터의 일관성을 보장하지만, 다른 트랜잭션이 동시에 같은 데이터를 수정하려고 할 경우에는 이런 동시성 문제(갱신 손실, 쓰기 스큐, 팬텀)가 발생할 수 있다

내가 겪은 상황을 그림으로 나타내자면 아래와 같다. 이런 Repeatable Read의 특성때문에 동시성 문제가 발생한 것이다.

<문제 발생 과정>

주문 트랜잭션1 시작 및 스냅샷 생성: 재고수량 1개

트랜잭션1 재고수량 검증: 재고수량이 1개이기 때문에 검증 통과

트랙잭션1에서 재고수량을 감소 & 주문 생성: 재고수량 1개 → 0개

주문 트랜잭션2 시작 및 스냅샷 생성: 트랜잭션2가 시작된 시점에서 재고수량은 1개이기 때문에 재고수량이 1개인 스냅샷을 생성

트랜잭션1에서 생성한 데이터 커밋: DB에 영구적으로 반영

트랜잭션2 재고수량 검증: 트랜잭션1에서 변경한 재고수량 데이터가 커밋이 되었지만 내 스냅샷(재고수량 1개)을 기반으로 재고수량을 검증한다. 이로인해 재고수량 검증에 통과한다.

트랙잭션2에서 재고수량을 감소 & 주문 생성: 재고수량 0개 → -1개

트랜잭션2에서 생성한 데이터 커밋: 재고수량이 -1개인채로 DB에 영구적으로 반영

Repeatable Read는 스냅샷 격리이고, MVCC로 구현되어있다. 이를 통해 일관된 보기(Read Consistency)를 유지하게 해준다. 상세한 내용은 아래를 참고.

💪🏻 해결 방법

1. Serializable 적용

장점 : 데이터 품질↑

단점 :
- 모든 걸 순차적으로 실행하기 때문에 성능↓
- 데드락 발생 가능성이 있다. → 트랜잭션이 롤백되기 때문에 병렬처리가 거의 불가능하다고 보면 됨

/**
 * 주문을 생성한다.
 *
 * @throws Exception 주문 처리 도중 발생하는 예외
 * @author min
 * @since 2023/07/07
 */
@Override
@Transactional(rollbackFor = Exception.class, isolation = Isolation.SERIALIZABLE)
public void order(Order order) throws Exception {
    // 0-1. 재고수량 감소
    decreaseProdQty(order.getOrdDtlList());

2. 낙관적 동시성 제어(Optimistic Concurrency Control)

정의

마지막으로 읽은 후로 변경되지 않았을 때만 갱신을 허용함을써 동시성 문제를 해결하는 방법이다.

원래는 먼저 검사를 하고 변경 시도를 해야 하는데 설마 변경되어있겠어? 하고 낙관적으로 접근해, 데이터를 업데이트하기 전에 해당 데이터가 마지막으로 읽힌 후 변경되었는지 확인. 변경되었다면 충돌을 감지해 트랜잭션을 롤백한다.

장점과 단점

장점: 성능 측면에서 비관적 락보다 일반적으로 우수한 것으로 알려져 있다. 데이터를 조회할 때 락을 걸지 않기 때문에, 여러 사용자가 동시에 데이터에 접근할 수 있다.

단점:
1. 자원 경합이 빈번하게 발생하는 상황에서 실패했을 때의 처리 비용이 높다. 현재 값이 이전에 읽은 값과 일치하지 않으면 read-modify-write 주기를 재시도해야 한다.
1. 동일한 상품에 주문이 몰릴 경우 충돌이 발생해 트랜잭션이 롤백될 것이고 재시도 로직을 구현하겠지만 무한으로 재시도 처리를 할 수는 없기 때문에 정해둔 재시도 횟수를 넘어가게되면 주문이 실패하게되어 고객이 불편함을 겪게된다.

적용방법

해당 컬럼만 비교
처음 재고수량을 조회해오고 마지막으로 읽은 후로 변경되지 않았을 때만 갱신을 허용함을써 동시성 문제를 해결하는 방법이다.
재고수량 감소 로직에 처음 읽어왔을 당시의 재고수량을 재고수량을 감소시키는 쿼리에 param으로 넘겨줘야 해 추가 코드 수정이 필요하다는 단점이 있다.
```
UPDATE prod_opt
SET INV_QTY = INV_QTY - #{new_qty}
WHERE OPT_COMB_NO = #{optCombNo}
AND INV_QTY = #{old_qty} # 마지막 읽은 이후로 변경되지 않았을 때만
```

변경일시 = 타임스탬프
데이터의 최종 변경 시간을 타임스탬프로 관리하고, 이를 통해 변경 여부를 판단하는 방법이다.

1번 방법은 일반적인 상황에서 확장성이 좋지 않다. 재고수량이 들어있는 prod_opt 컬럼에는 다른 컬럼이 같이 변경될 일은 없어서 다른 예시를 들어보자면..
우수 고객을 대상으로 적립포인트를 제공하는 이벤트를 실시한다고 가정했을 때, 고객의 실적정보를 읽어 적립 포인트를 계산해 변경한다. 적립 포인트를 계산하는 동안 다른 트랜잭션이 같은 고객의 실적정보를 변경한다면 문제가 생길 수 있다.
이런 문제를 해결하기 위해 낙관적 동시성 제어 방법을 적용하고 버전 컬럼이 아닌 변경을 감지해야 하는 컬럼을 일일이 써주었을 경우에 일단 귀찮고 추후에 실적정보가 추가된다면 쿼리를 수정해야 하는 관리 포인트가 늘어나고 보기에도 좋지 않다.
```
UPDATE 고객 
SET 적립포인트 = #{적립포인트}
WHERE 고객번호 = #{고객번호}
AND 적립포인트 = #{old_적립포인트}
AND 방문횟수 = #{old_방문횟수}
AND 최근방문일시 = #{old_최근방문일시}
AND 구매실적 = #{old_구매실적}
```
버전 컬럼이나 최종변경일시를 관리하는 컬럼이 있다면 조건절에 넣어 간단히 해당 레코드의 갱신여부를 판단할 수 있다.
```
UPDATE 고객 
SET 적립포인트 = #{적립포인트}
WHERE 고객번호 = #{고객번호}
AND 변경일시 = #{변경일시} # 최종 변경일시가 트랜잭션 시작 시점에 읽은 값과 일치하는지 비교
```
나의 경우에는 이렇게 적용할 수 있다.
```
UPDATE prod_opt
SET INV_QTY = INV_QTY - #{qty}
  , UPD_DTTM = now()
WHERE OPT_COMB_NO = #{optCombNo}
AND UPD_DTTM = #{updDttm} -- 수정일시
```
하지만 이 방법은 나의 상황에 바로 적용하기에는 한계가 있다.
최종 변경 시간을 활용하여 데이터가 마지막으로 읽힌 이후 변경되었는지 판단하는 방식은, 시간 단위가 밀리초까지 고려되어야만 정확한 비교가 가능하다. UPD_DTTM 컬럼의 데이터 타입은 TIMESTAMP로, 소수점 이하의 초를 저장할 수 있도록 정밀도를 설정해야 한다.
또한 prod_opt에 변경이 발생할 시 현재는 now() 메서드로 변경일시를 넣어주고 있는데 now() 메서드는 시분’초’까지만 나타낸다. 밀리초까지 표현하려면 정밀도를 설정할 수 있는 CURRENT_TIMESTAMP를 이용해야 한다.

변경 포인트가
1. UPD_DTTM 컬럼의 데이터 타입 TIMESTAMP → TIMESTAMP(3) 변경
1. 변경일시를 now() → CURRENT_TIMESTAMP(3) 변경
이렇게 2군데나 되고, 추가 코드 수정이 많아지고 관리 포인트가 늘어나게된다는 단점이 있다.

관련해서는 아래를 참고

적용하면서 삽질 과정이 궁금하신 분들은 아래 글 참고,,

버전 컬럼
트랜잭션이 시간된 후 버전이 변경되었는지 확인해 버전이 같아야 update를 수행, 변경되었다면 update를 수행하지 않고 트랜잭션을 롤백하는 2번이랑 비슷한 방법
```
UPDATE prod_opt
SET INV_QTY = INV_QTY - #{qty}
  , UPD_DTTM = now()
WHERE OPT_COMB_NO = #{optCombNo}
AND versione = #{version} 
```
2와 같은 방법이다.
이 방법도 2번과 마찬가지로 prod_opt 테이블에 버전 컬럼을 추가해줘야 하고, 재고수량이 변경되는 모든 쿼리에 version도 같이 + 되는 쿼리를 추가해줘야 하는 단점이 있다.

JPA의 @Version
JPA를 활용하면 낙관적 동시성 제어를 @Version 애너테이션으로 쉽게 구현할 수 있다. 하지만 MyBatis만을 사용하는 내 프로젝트에는 당장 적용이 어렵다.

수량 비교
구매하려는 수량이 현재 수량보다 많이 남아있는지를 체크하여 낙관적 동시성 제어를 적용하는 방법이다.
추가 코드 없이도 가장 쉽고 깔끔하게 구현 가능.
```
<update id="decreaseProdQty" parameterType="Map">
    UPDATE prod_opt
    SET INV_QTY = INV_QTY - #{qty}
      , UPD_DTTM = now()
    WHERE OPT_COMB_NO = #{optCombNo}
    AND INV_QTY >= #{qty}
</update>
```

나는 5번 ‘수량 비교’를 선택해 낙관적 동시성 제어를 구현했다. 다른 코드를 추가하거나 수정할 필요 없이 가장 깔끔하고 쉽게 적용할 수 있는 방법이기 때문이다.

재시도 처리

동시성 문제를 낙관락으로 해결했다면 재시도 로직을 반드시 구현해야 한다. 경합 발생 시 예외를 강제로 발생시켜 트랜잭션을 롤백하고 재시도 처리를 하지 않으면, 사용자는 다시 주문을 시도해야 하기 때문에 사용자가 겪게되는 불편함이 크다.

충돌이 감지되어 롤백되었을 경우에 재시도 처리를 위해 @Retryable 애너테이션을 사용했다. 재시도 횟수는 3회로 제한하였다.

@Override
@Retryable(
    value = OptimisticLockingFailureException.class,
    maxAttempts = 3,
    backoff = @Backoff(delay = 100)
)
@Transactional(rollbackFor = Exception.class)
public void order(Order order) throws Exception {
      // 0-1. 재고수량 감소
    decreaseProdQty(order.getOrdDtlList());
		...

package com.teamProject.syusyu.common.config;

import org.springframework.context.annotation.Configuration;
import org.springframework.retry.annotation.EnableRetry;

@Configuration
@EnableRetry
public class RetryConfig {
    // 추가 설정이 필요한 경우 여기에 정의
}

3회 재시도 후에도 충돌이 계속 발생한다면, 사용자에게 에러 메시지를 반환한다.

@PostMapping("orders")
@ResponseBody
public ResponseEntity<String> order(@RequestBody OrderRequestDTO orderRequestDTO, @SessionAttribute int mbrId) {
    try {
        service.order(new Order(orderRequestDTO, mbrId));
    } catch (OptimisticLockingFailureException e) { // 낙관락 충돌이 발생했을 때
        e.printStackTrace();
        return new ResponseEntity<>(e.getMessage(), HttpStatus.BAD_REQUEST);
    } catch (Exception e) {
        e.printStackTrace();
        return new ResponseEntity<>("ADD_ERR", HttpStatus.BAD_REQUEST);
    }

    return new ResponseEntity<>("ADD_OK", HttpStatus.OK);
}

3. 비관적 동시성 제어(Pessimistic Concurrency Control)

정의

사용자들이 같은 데이터를 동시에 수정할 것으로 가정한다. 따라서 한 사용자가 데이터를 읽는 시점에 Lock을 걸고 조회 또는 갱신처리가 완료될 때까지 이를 유지한다.

장점과 단점

장점: 데이터 수정 전 조회 시 미리 락을 걸어 다른 트랜잭션이 동시에 같은 데이터를 변경 못 하게 함으로써 데이터의 정합성을 유지한다.

단점:
1. Lock은 첫 번째 사용자가 트랜잭션을 완료하기 전까지 다른 사용자들이 같은 데이터를 수정할 수 없게 만들기 때문에 일반적으로 처리량이 감소하고 동시성이 나빠질 수 있다.
1. 사용자가 몰릴 경우, 락을 얻기 위해 대기하면서 커넥션을 계속 점유하게 되어 극단적 상황에서는 커넥션 부족 현상이 발생할 수 있다.

적용방법

재고수량을 조회해올 때 Lock을 걸고 해당 쿼리를 실행하는 트랜잭션이 종료될 때까지 유지한다.

<select id="selectProductQty" parameterType="int" resultType="ProdOptDTO">
    SELECT PO.PROD_ID, PO.OPT_COMB_NO, PO.INV_QTY
    FROM PROD_OPT PO
    WHERE OPT_COMB_NO IN
    <foreach collection="array" item="optCombNoArr" open="(" close=")" separator=",">
        #{optCombNoArr}
    </foreach>
		FOR UPDATE;
</select>

커넥션 문제를 해결하는 방법

사실 커넥션 문제는 정말 생각해보지도 않았고 고려해볼 생각도 못한 주제였는데, 이분의 글을 읽고 진지하게 생각해보게되었다.

오라클은 NOWAIT과 WAIT n 옵션을 제공해, 특정 시간만 대기 후 락을 얻지 못하면 예외를 발생시켜 트랜잭션을 종료시킬 수 있다. 따라서 오히려 동시성을 증가시키게되고 커넥션도 계속 물고 있지 않는다.

<select id="selectProductQty" parameterType="int" resultType="ProdOptDTO">
    SELECT PO.PROD_ID, PO.OPT_COMB_NO, PO.INV_QTY
    FROM PROD_OPT PO
    WHERE OPT_COMB_NO IN
    <foreach collection="array" item="optCombNoArr" open="(" close=")" separator=",">
        #{optCombNoArr}
    </foreach>
		FOR UPDATE WAIT 3;
</select>

하지만 MySQL에서는 WAIT n 옵션을 제공하지 않는다. NOWAIT과 SKIP LOCKED 옵션만 제공하는데, 현재 상황에서는 NOWAIT 옵션만 적용할 수 있다. 하지만 WAIT N이 아닌 NOWAIT 옵션을 적용할 경우 락 시도 후 다른 트랜잭션이 점유 중이면 바로 예외를 던져 재시도 비용이 크다. 이렇게 처리하면 낙관락이랑 무슨 차이가 있나 싶기도 하다.

비관적 동시성 제어를 적용해 커넥션이 부족하게 되면 문제가 발생한다면, 커넥션 부족 문제는 일반적으로 자주 발생하는 문제가 아니기도하고.. 나라면 DB 커넥션을 늘리는 방법을 고려할 것 같다.

적용하면서 삽질 과정이 궁금하신 분들은 아래 참고..

4. 분산 락

하나의 애플리케이션에서 여러 DB를 사용할 경우 동시성 문제를 해결하기 위해 사용되는 방법이다.

❗적용한 방법과 선택 기준, 테스트

Serializable은 데드락 발생 가능성과 심각한 성능 저하의 이유로 제외했다. 분산 락도 현재 프로젝트가 Redis 같은 분산 캐시 시스템을 사용하지 않고, 모든 데이터 처리가 단일 데이터베이스 내에서 이루어지므로 고려 대상이 아니었다. 따라서 낙관적 동시성 제어와 비관적 동시성 제어 중 하나를 선택해야 했다.

낙관락 vs. 비관락

많은 블로그에서 일반적으로 자원의 경합이 빈번하면 비관적 동시성 제어, 빈번하지 않으면 낙관적 동시성 제어를 사용하라고 하던데.. 나의 상황에 대입해 생각해보기로 했다.

내 프로젝트에서 주문 로직은 재고수량 조회 후 구매 가능한 상태를 검증하고 바로 재고수량을 감소시키기 때문에, 조회와 수정 시간 간격이 매우 짧다.

낙관적 동시성 제어를 사용하더라도 락을 아예 안 거는 게 아니라 조회 시 락을 안 걸고 수정 시에는 락을 걸게된다. 이런 상황에서의 낙관적 동시성 제어의 적용은 Lock이 유지되는 시간이 짧아서 동시성을 높이는데 유리하다는 장점을 활용하지 못한다고 생각한다.

또한, 낙관적 동시성 제어의 경우 현재 값과 이전에 읽은 값의 불일치 시 재시도하는 로직을 추가로 구현해야 한다. 특히 특가상품이나 한정재고 같은 경우 자원 경합이 빈번하게 발생될 것이고 무한으로 재시도 처리를 할 수는 없기 때문에 정해둔 재시도 횟수를 넘어가게되면 주문이 실패하게되어 고객이 불편함을 겪게된다.

성능 테스트

이런 내 가정이 정말인지 확인하기 위해 실제로 조회에 락을 걸었을 때와 락을 걸지 않았을 때의 성능 테스트를 해보았다.

재고 499개 상태에서 100개의 쓰레드를 사용하여 동일한 5개 상품에 대한 총 500개의 주문을 시도한 결과(각각 10번씩 돌려보고 평균치를 내보았다.)

조회에 Lock을 걸지 않았을 때의 평균 처리 시간은 5.8초였고, 비관적 동시성 제어를 사용했을 때는 5.9초로 나타났다.

조회에 Lock을 걸지 않았을 때
5.8566 = (5.931+6.61+5.858+5.824+5.787+5.910+5.518+5.635+5.845+5.648)/10

조회에 Lock을 걸었을 때
5.9623 = (6.52+5.528+5.867+5.999+6.482+5.769+5.931+5.970+5.770+5.787)/10

테스트 결과, 조회에 Lock을 걸었을 때는 평균 5.9초. 조회에 Lock을 걸지 않았을 때는 평균 5.8초로 평균 처리 시간의 큰 차이가 없었다. 내가 가정했던 Lock이 유지되는 시간이 비슷하기 때문에 성능차이도 그렇게 크지 않을 것 같다는 가정에 확신을 가질 수 있게 되었다.

그렇다면 굳이 내 상황에서 경합이 발생될 때 처리비용이 큰 낙관적 동시성 제어를 선택해서 동시성 문제를 해결할 필요가 없다고 생각되어 비관적 동시성 제어를 선택해 동시성 문제를 해결하였다.

경합이 자주 발생하는 경우에는 비관적 락, 그렇지 않을 때는 낙관락을 적용하는 것이 좋다라는 이론적인 공식보다는 현재 내 프로젝트 상황을 고려해 해결 방법을 선택하는 것이 좋을 것 같다.

구현

재고수량을 조회해오는 쿼리문에 FOR UPDATE 구문을 써 로우 락을 걸어주어 동시성 문제를 해결할 수 있었다. (오라클이라면 for update wait 3 구문을 써주었을 것 같다.)

<select id="selectProductQty" parameterType="int" resultType="ProdOptDTO">
    SELECT PO.PROD_ID, PO.OPT_COMB_NO, PO.INV_QTY
    FROM PROD_OPT PO
    WHERE OPT_COMB_NO IN
    <foreach collection="array" item="optCombNoArr" open="(" close=")" separator=",">
        #{optCombNoArr}
    </foreach>
    FOR UPDATE
</select>

🔜 나가며

이번 동시성 문제를 해결하는 과정에서 이론적으로 공부한 지식을 실무에 직접 적용해보는 경험이 정말정말정말 중요하다는 걸 깨달았다. 단순히 ‘공부했다’에서 끝나면 안 된다. 실제로 적용을 해봐서 완전히 내걸로 만들어야 한다. 이론만 알고있는 건 의미없고 배운 걸 실제로 꺼내서 쓸 줄 알아야 한다.

2월부터 지금까지 정말 많은 공부를 해왔지만, 실제로 적용해본 건 손에 꼽았고 그렇다보니 내 기억에도 강렬하게 남지는 않았던 것 같다.(물론 복습을 안 해서인 것도 있다 ㅎㅎ..)

이번에 동시성 문제 해결하기 위해 데이터 중심 애플리케이션 설계 7장 트랜잭션 부분을 다시 읽으면서, 내가 해결해야 하는 문제가 있고 그걸 해결하기 위해 대입하면서 읽으니까 이해가 더 깊어진 걸 경험했다. 그동안 수업듣고 그내용 익히느라 바빠서 배웠던 내용을 실전에 적용하지 못했었는데, 실제로 이렇게 써먹으니까 너무너무너무 재밌었다 시간 가는 줄 모르고 빠져들었던 것 같다

앞으로는 어떤 걸 배우거나 책을 읽더라도 ‘목적’과 ‘의도’를 분명하게 설정하고 읽자. 그리고 공부했다는거에서 끝내지말도 작은 거라도 실제로 적용해서 내것으로 만들기!

책을 읽어도 이런 문제들이 내가 개발하고 있는 시스템에서도 발생할 수 있는 문제들인지, 나의 상황에서 대입해보자. 그냥 지식을 얻는 것뿐만이 아닌 내가 이걸 배워서 어디에 적용할 수 있는지 이런 적용점들을 생각하면서 읽는 게 중요하다는 것도 느꼈다.

데중에설에서도 동시성뿐만아니라 다양한 문제들에 대해 배운 내용을 더 적용해보는 것도 좋을 것 같다.

다시 한번 느끼는 거지만 멧돼지 책은 저자의 실무 경험이 잘 녹아있는 것 같다. 어떤 문제가 있고 시도할 수 있는 방법들은 무엇이며 이런 문제 해결 과정이 상세하게 나와있어서 많은 도움이 됐다.