낙관적 동시성 제어를 적용하면서 마주친 문제: 타임스탬프

✔️ 결론

👀 문제 정의

❓ 분석&시도

시도1) 안 되는 이유를 나름 분석해보았다

시도2)

3) 잘못된 개념 바로잡은 후, 타임스탬프로 안 되는 이유 분석

🔍 원인

✅ 해결방법

✔️ 결론

👀 문제 정의

처음에 동시성 문제를 해결하려고 하였을 때, 처음에 가정을 Isolation Level이 Repeatable Read로 하면 안 된다는 잘못된 개념을 가지고 있었어서 Read Committed로 내려야 되는 줄 알고 얘를 위해 Read Committed로 내리는 건 말이 안 되는 것 같아 비관적 동시성 제어로 해결하는 방법을 선택하였는데 ㅎ,,

잘못된 지식으로 잘못된 판단을 내리고 있었다 ㅠㅠㅠ

JPA를 사용한다면 Version으로 깔끔하게 구현이 가능하던데,

나는 Spring + MyBatis여서 쿼리문에서 CAS(compare-and-set) 방식으로 낙관적 동시성 제어 방법을 구현하는 것을 사용하였다.

위에서 말한 잘못된 지식을 가지고 일단 낙관적 동시성 제어를 적용해보았다

1. Isolation Level을 MySQL의 기본인 Repeatable Read → Read Committed로 변경

   @Transactional(rollbackFor = Exception.class, isolation = Isolation.READ_COMMITTED)
   public void order(Order order) throws Exception {
       // 0-1. 재고수량 감소
       decreaseProdQty(order.getOrdDtlList());

2. 재고수량 감소 쿼리에 UPD_DTTM(변경일시)이 마지막으로 읽은 후로 변경되지 않았을 때만 수정되도록 쿼리 수정

   <update id="decreaseProdQty" parameterType="Map">
       UPDATE prod_opt
       SET INV_QTY = INV_QTY - #{qty}
         , UPD_DTTM = now()
       WHERE OPT_COMB_NO = #{optCombNo}
       AND UPD_DTTM = #{updDttm}
   </update>

⇒ 이렇게 수정한 후 재고가 1개 남은 상품을 2개의 쓰레드가 동시에 주문하도록 하고 돌려보았는데 내가 기대한 결과가 아닌 재고수량이 여전이 -1이 됨

❓ 분석&시도

시도1) 안 되는 이유를 나름 분석해보았다

아래는 내가 생각한 위의 상황의 flow였다..

그러니까 결론은 트랜잭션1에서 재고수량을 변경해 UPD_DTTM도 최신값으로 변경되었으나
Isolation Level이 Read Committed고 트랜잭션이 끝나지 않아 커밋이 되지 않았기 때문에 UPD_DTTM는 여전히 트랜잭션 시작 시 읽어온 값이다.
따라서 UPD_DTTM 컬럼을 비교하는 검증 부분이 통과되어 재고수량이 감소된다.

시간 순서	트랜잭션 1 상태	트랜잭션 2 상태	설명
1	Read: 재고수량 & 변경일시 재고수량: 1개 변경일시: 02/05/2024 10:02:18.000
2	재고수량 검증: 1개 이상이기 때문에 통과	Read: 재고수량 & 변경일시 재고수량: 1개 변경일시: 02/05/2024 10:02:18.000
1	decreaseProdQty를 실행해 재고수량을 감소시킨다. 이때 트랜잭션1이 시작된 이후로 재고수량이 변경되지 않았기 때문에 UPD_DTTM 컬럼을 비교하는 검증 부분이 통과되어 재고수량이 감소된다.	재고수량 검증: 1개 이상이기 때문에 통과
2	그 뒤로 주문 로직 생성	decreaseProdQty를 실행해 재고수량을 감소시킨다. 트랜잭션1에서 재고수량을 변경해 UPD_DTTM도 최신값으로 변경되었으나 Isolation Level이 Read Committed고 트랜잭션이 끝나지 않아 커밋이 되지 않았기 때문에 UPD_DTTM는 여전히 트랜잭션 시작 시 읽어온 값이다. 따라서 UPD_DTTM 컬럼을 비교하는 검증 부분이 통과되어 재고수량이 감소된다.
3	커밋	그 뒤로 주문 로직 생성
4	결과는 재고수량 0	커밋
5		결과는 재고수량 -1

시도2)

위에서 정의했던 이상한 가정으로 낙관적 동시성 제어를 적용하는 과정에서 굉장히 삽질을 하고 있었다.

일반적으로 동시성 문제를 해결하는 방법은 크게 두 가지다.

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

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

여러 책에서는 낙관적 동시성 제어를 타임스탬프를 활용하는 방법으로 소개하고 있었다. 하지만 실제로 적용해 보았는데 동시성 문제가 해결되지 않았고, 이유를 분석하려다 오히려 문제 해결과는 점점 멀어지는 이상한 가정을 하게 되었다.

구글링을 통해 다양한 해결책을 찾아봤지만, 대부분 JPA의 @Version으로 해결하고 있었고 MyBatis 사용 사례는 찾기 어려웠다. 그러다 찾다찾다 드디어 우연히 한 블로그에서 JPA가 아니라 내가 책에서 본 쿼리를 사용해 동시성 문제를 해결한 글을 발견하게되었다..!

[DB] 동시성 문제 해결방법

동시성 문제가 무엇이고 해결방법에 대하여 알아보도록 한다.

https://chrisjune-13837.medium.com/db-동시성-문제-해결방법-f5e52e2e3

나는 이미 잘못된 가정에 깊이 빠져 있어서 "저 방법으로 해결될 리가 없다"고 생각하며 반신반의하며 속는셈치고 시도를 해보았다.

재고수량 감소쿼리에 INV_QTY >= #{qty} 조건을 추가해 실제 재고 수량이 충분할 때만 업데이트하도록 했다. 변경 후 격리 수준에 상관없이 Repeatable Read와 Read Committed 모두 문제없이 작동하는 것을 확인할 수 있었다. 이 결과는 내가 세운 가정과 전혀 달랐고.. 예상치 못한 결과였다. 내 예상으로는 -1로 동시성 문제가 해결이 안 되었어야 했는데 실제로는 0으로 동시성 문제가 해결되었다..

기존

<update id="decreaseProdQty" parameterType="Map">
    UPDATE prod_opt
    SET INV_QTY = INV_QTY - #{qty}
      , UPD_DTTM = now()
    WHERE OPT_COMB_NO = #{optCombNo}
    AND UPD_DTTM = #{updDttm}
</update>

변경

<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>

그 이유에 대해서는 아래 글 참고.

낙관적 동시성 제어를 적용하면서 마주친 문제들: 재고수량 비교

👀 의문점❓ 원인 추론 & 시도1) 일단 Repeatable Read로 시나리오 짜보고 테스트2) 책, 자료 찾아보기3) 헷갈렸던 부분2🔜 나가며더 알아볼 것Ref 아래는 제 삽질 과정을 기록한 글이고 틀린 내용이 포함되어있을 수 있습니다…! 👀 의문점위 게시글에서 정의했던 이상한 가정으로 낙관적 동시성 제어를 적용하는 과정에서 굉장히 삽질을 하고 있었다.일반적으로 동시성 문제를 해결하는 방법은 크게 두 가지다.비관적 동시성 제어(Pessimistic Concurrency Control)낙관적 동시성 제어(Optimistic Concurrency Control) 여러 책에서는 낙관적 동시성 제어를 타임스탬프를 활용하는 방법으로 소개하고 있었다. 하지만 실제로 적용해 보았는데 동시성 문제가 해결되지 않았고..

https://beppp.tistory.com/126

3) 잘못된 개념 바로잡은 후, 타임스탬프로 안 되는 이유 분석

위 글을 통해잘못된 개념 바로잡고, 그래서 왼쪽이나 오른쪽이나 같은 메커니즘인데.. 안 되는 이유를 분석해보았다.

처음 수정일시를 조회해온 값을 찍어보았는데,

thread2

Executing order # on thread: 재고수량 감소 후 수정일시 확인용pool-1-thread-2prodQtyList2: [ProdOptDTO{optItemNm='null', optCombNo=1, optPrc=0, invQty=0, prodId=10001, shoesSize='null', regDttm=null, regrId=0, updDttm=Mon Feb 05 18:39:56 KST 2024, updrId=0, delDttm=null, delrId=0, delYn='null'}]

thread1

Executing order # on thread: 재고수량 감소 후 수정일시 확인용pool-1-thread-1prodQtyList2: [ProdOptDTO{optItemNm='null', optCombNo=1, optPrc=0, invQty=-1, prodId=10001, shoesSize='null', regDttm=null, regrId=0, updDttm=Mon Feb 05 18:39:56 KST 2024, updrId=0, delDttm=null, delrId=0, delYn='null'}]

updDttm이 시분’초’까지만 값을 가져온 거 보고 혹시 트랜잭션이 너무 빠르게 진행되어서 그런가..? 라는 생각이 번뜩 들었다.

결론은 이게 맞았다..!

모든 로직이 전부 56초 내에 수행되어

트랜잭션1이 값을 변경한 후 now()로 updDttm을 수정했지만 처음 조회해온 값과 같은 18:39:56이 저장되어서 트랜잭션2가 변화를 감지하지 못해 마지막 읽은 후로 변경되지 않았다고 판단해 재고수량을 또 차감해 -1이 된것..

재고가 1개 남은 상품을 2개의 쓰레드가 동시에 주문

1. 처음에 재고수량을 조회해올 때 변경일시도 조회해온다.

2. A 트랜잭션이 먼저 수량 변경을 한다.

3. 그리고 또 거의 동시에 B 트랜잭션이 수량을 변경한다.

4. 2번, 3번 변경 시차 차이가 거의 없다보니까 2가 변경되어서 커밋되기 전에 3도 변경 시도를 함

🔍 원인

수정일시 컬럼이 밀리초(millisecond) 단위까지 저장하지 않고, 시분초(second) 단위까지만 저장하기 때문에 발생하는 문제였다. 이 경우 같은 초 내에 여러 트랜잭션이 동시에 데이터를 수정하게 되면 수정일시를 기반으로 변경을 감지하는 경우 정확하게 동작하지 않을 수 있다. 특히 고속으로 처리되는 트랜잭션 환경에서는 같은 초 내에 여러 데이터가 변경될 가능성이 높다.

✅ 해결방법

1. prod_opt 테이블의 timestamp 컬럼의 타입을 timestamp(3)으로 변경

2. UPD_DTTM 값을 넣어줄 때 now()가 아닌 CURRENT_TIMESTAMP(3)로 넣어주도록 쿼리 변경

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

<update id="decreaseProdQty" parameterType="Map">
    UPDATE prod_opt
    SET INV_QTY = INV_QTY - #{qty}
      , UPD_DTTM = CURRENT_TIMESTAMP(3)
    WHERE OPT_COMB_NO = #{optCombNo}
      AND UPD_DTTM = #{updDttm}
</update>

Uploaded by N2T