[트러블슈팅] 쿠폰 발급하다 터진 Deadlock, 그리고 Redisson으로 해결한 이야기

💣 동시성 테스트 중 Deadlock 발생! 그리고 Redisson 락까지 도입한 트러블슈팅

 

선착순 할인 쿠폰 발급 기능을 만들면서 겪었던 트러블슈팅 과정을 정리해보려고 한다!
Deadlock이 실제로 발생했던 부하 테스트 결과와, 락 전략을 고민하고 최종적으로 Redisson 락을 도입하기까지의 실제 경험을 기반으로 풀어낸 트러블슈팅 기록이다!

 

🛫  문제 상황: Deadlock 발생 실험

기본적인 쿠폰 발급 API만 작성한 상태에서, 다수 사용자가 동시에 발급을 요청하면 어떤 일이 일어날까 궁금했다.
그래서 JMeter를 이용해 간단한 부하 테스트를 진행해 봤다.

테스트 조건

테스트 조건

항목	값
테스트 도구	Apache JMeter
스레드 수	100명
루프 횟수	1회 (1명당 1회 발급 시도)
쿠폰 수량	10개
대상 API	/api/coupons/{couponId}/issue
락 적용 여부	없음 (기본 발급 로직)

⚡ 테스트 실행 결과

테스트를 돌리자마자 다음과 같은 에러가 쏟아졌다..

Deadlock found when trying to get lock; try restarting transaction

상세 에러 로그를 살펴봤더니..

com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException:
Deadlock found when trying to get lock; try restarting transaction
SQL [update coupons set ... where id=?]

coupon.issueCount를 증가시키는 과정에서 Deadlock이 발생하고, 일부 트랜잭션이 강제 롤백되고 있었다..

🔍 Deadlock 원인 분석

Deadlock이 발생한 원인은 다음과 같다.
1. 100명의 사용자가 동시에 쿠폰 발급 요청
2. DB는 모두 같은 쿠폰을 업데이트하려고 시도
3. row-level 락을 잡으려다가, 서로 순서를 기다리는 순환 대기가 발생
4. 결과적으로 Deadlock 감지 → 일부 트랜잭션 롤백

 

🧠 왜 이걸 중요하게 봐야 했을까?

👉  단순한 coupon.issueCount++ 같은 로직도 트래픽이 몰리면 심각한 문제로 이어질 수 있다.
👉  race condition 뿐 아니라, Deadlock까지 발생할 수 있다는 사실을 직접 경험했다.
👉  "잘 되겠지"라는 막연한 믿음이 아니라, 실제 테스트로 확인해야 한다는 교훈을 얻었다.

 

🧩 문제 해결을 위한 Lock 전략 고민

Deadlock을 해결하려면 동시성 제어가 필요했다.
그래서 여러 Lock 전략을 정리하고 비교해 봤다.

전략	설명	장점	단점
비관적 락 (Pessimistic Lock)	DB SELECT ... FOR UPDATE 사용	강력한 정합성 보장 단일 서버에선 빠름	확장성 부족 DB 병목 가능성
낙관적 락 (Optimistic Lock)	버전 필드 기반 충돌 감지	락 없이 빠름	충돌 시 재시도 필요 실시간성 떨어짐
Redisson 분산 락	Redis를 이용한 글로벌 락	분산 환경 대응 실시간 제어 가능	네트워크 오버헤드 설정 복잡
메시지 큐 처리	Kafka 등으로 선착순 큐 처리	대량 처리에 강함 장애 복원력 우수	실시간성 부족 설계 복잡

 

🧪 직접 성능 테스트 확인

단일 서버 환경에서 각각의 락 전략을 적용하고 JMeter 부하 테스트를 다시 돌렸다.

전략	평균 응답 시간	중복 여부	비고
비관적 락	14ms	없음	DB 트랜잭션 기반으로 가장 빠름
Redisson 락	413ms	없음	Redis 통신 오버헤드 발생

✅ 비관적 락이 단일 서버 환경에선 압도적으로 빠른 결과를 보였다.

 

🛤️ 최종 선택: Redisson 분산 락

그럼에도 최종적으로 Redisson 분산 락을 선택했다. 이유는 명확했다.

고려사항	설명
수평 확장성	서버가 여러 대가 되어도 일관성 유지 가능
실시간성	메시지 큐보다 빠른 처리 가능
유지보수성	Redis 캐시 구조와 통합 운용 가능
설계 유연성	DB 트랜잭션과 독립된 락 관리 가능

비관적 락은 DB 안에서만 락을 걸 수 있고, 수평 확장 시(서버가 여러 대로 늘어나면) 락 일관성 유지가 어려웠다.
그래서 미래 확장을 고려하여, 조금 느리더라도 Redisson 락으로 전환하는 걸 선택했다.

 

단순한 기능이라고 가볍게 생각했지만, 실제 트래픽 상황에서는 race condition, Deadlock 같은 심각한 문제가 발생할 수 있음을 직접 경험했다.
문제를 테스트로 재현하고, 다양한 대안을 비교하고, 미래 확장성까지 고려하여 기술적 결정을 내리는 경험은 개발자로서 유익한 시간이었다.