쿠폰 발급 시 데드락 발생

[eggnee]

1. 시나리오: 쿠폰 발급 로직

• 목표: 100명의 사용자가 동시에 동일한 쿠폰을 발급받는 상황에서 동시성 문제가 발생하는지 테스트

• 쿠폰 발급 로직:

  1. 쿠폰 테이블(coupon)의 잔여 수량을 감소시킴
  2. 발급된 쿠폰(issued_coupon) 테이블에 발급된 쿠폰 데이터를 INSERT

• 테스트 세부 사항:

  • 조건:

    1. 초기 쿠폰 테이블(coupon)의 잔여 수량은 100으로 설정
    2. 100명의 사용자가 동시에 쿠폰 발급 요청을 수행 (멀티스레드 환경에서 테스트)

  • 예상 결과:

    1. 발급된 쿠폰(issued_coupon) 테이블에 100개의 데이터가 생성되어야 함
    2. 쿠폰 테이블(coupon)의 잔여 수량이 0이 아니어야 함 (동시성 문제 발생 확인)

---

2. 테스트 중 발생한 문제

• SQL Error 1213 (Deadlock) 오류 발생
  • 동일한 쿠폰 ID에 대해 다수의 사용자가 동시다발적으로 쿠폰 발급을 요청할 때 데드락 발생
  • 쿠폰 잔여 수량 업데이트와 발급 쿠폰 INSERT가 순차적으로 이루어지는데도 불구하고 데드락이 발생
  • 결과적으로 발급된 쿠폰 테이블에 100개 데이터 생성에 실패함

---

3. 원인 분석

(1) MySQL의 잠금 메커니즘

• MySQL의 트랜잭션 격리 수준(기본값 REPEATABLE READ)에 따라 레코드에 자동으로 락이 설정됨
  • 쿠폰 수량 감소 시: Exclusive Lock (X) 설정
  • 발급 쿠폰 INSERT 시: 외래 키(FK)로 연결된 쿠폰 테이블에 대해 Shared Lock (S) 설정
• 이때, 락의 타이밍과 순서가 다른 트랜잭션과 충돌하면서 데드락 발생

(2) JPA의 쓰기 지연

• JPA의 쓰기 지연(Write-Behind) 메커니즘 덕분에 트랜잭션이 커밋되는 시점에 쿼리가 DB에 반영됨
  • 트랜잭션 내에서 쿼리 실행 순서와 실제 DB에 반영되는 순서가 다를 수 있음
  • 우선순위가 존재:
    1. Inserts, in the order they were performed
    2. Updates
    3. Deletion of collection elements
    4. Insertion of collection elements
    5. Deletes, in the order they were performed
  • 이로 인해 쿠폰 잔여 수량 업데이트를 먼저 수행해도 발급된 쿠폰(INSERT) 쿼리가 먼저 실행되어 X Lock과 S Lock이 충돌하면서 데드락이 발생 (+ X Lock은 트랜잭션이 완료될때까지 유지됨)

---

4. 데드락 발생 과정

1. TX1: 발급 쿠폰 INSERT 작업을 수행하려고 할 때, 쿠폰 테이블에 S Lock을 설정하고, 발급 쿠폰 PK 인덱스 엔트리에 X Lock을 설정
2. TX2: 동일한 쿠폰 ID에 대해 발급 쿠폰 INSERT 작업을 수행하려고 할 때, 쿠폰 테이블에 S Lock을 설정하지만, 발급 쿠폰의 X Lock을 대기
3. TX3: 쿠폰 수량 UPDATE 작업을 수행하려고 X Lock을 필요로 하지만, TX2가 쿠폰 테이블에 S Lock을 설정한 상태여서 대기
4. 데드락 발생:
   • TX1이 TX2의 대기 상태로 인해 진행되지 않으며, TX2는 TX3의 대기 상태로 인해 진행되지 않음
   • 이로 인해 데드락이 발생하며, 시스템은 이를 해결하기 위해 트랜잭션 중 하나를 롤백해야 함
     

---

결론

• 데드락 발생 원인: 발급 쿠폰 INSERT 작업에서 쿠폰 테이블에 대한 S Lock과 발급 쿠폰 PK 인덱스에 대한 X Lock이 서로 충돌하고, 쿠폰 수량 업데이트 작업에서 X Lock이 필요하지만 TX2의 S Lock으로 인해 대기 상태에 들어가면서 데드락 발생
• 해결 방안: 트랜잭션 간 락 순서를 명확히 하고, 필요 시 락 타임아웃을 설정하여 데드락을 방지하거나 락 순서 변경을 고려해야 함

[eggnee]

일단 flush()로 해결 ! 다른 좋은 방법이 있을까 궁금하다
비동기로 하는 방법도 있음 (그래서 나중에 카프카로 처리하는건가?)

[re-mora]

문제 발생

• 동시에 100개의 쿠폰 발급 요청 시
  • 쿠폰 잔여 수량 0 : x
  • 100개의 쿠폰 발급 이력 생성 : o
• 동시에 100개를 초과하는 쿠폰 발급 요청 시
  • 쿠폰 잔여 수량 0 : x
  • 100개의 쿠폰 발급 이력 생성 : x

문제 해결 시도

1. application 수준의 lock 적용을 통한 순서 제어 : synchronized
2. JPA Domain Event 발행을 통한 트랜잭션 순서 제어 : AggregateRoot
3. JPA Pessimistic Lock을 이용한 트랜잭션 순서 제어 : Record Lock
   • Transcation 범위 내에서 x-lock 유지(다른 트랜잭션의쓰기 행위 제어)

기술 질문 키워드

• JPA Write behind의 우선순위
• @transactional의 동작 방식과 AOP
• MySQL InnoDB 엔진의 S/X-Lock 동작 방식
  • x-lock(베타 락) : select ~ for update
  • s-lock(공유 락) : select ~ for share

[eggnee]

완전 잘못 생각했다!
실제 트랜잭션 실행 순서