[🔥TroubleShooting - TicToc🔥] 돈이 걸린 문제‼️ 1명만 입찰 성공 ✅, 4999명 입찰 실패 ❌

📌 프로젝트 소개

팀원 : 개인 프로젝트
기간 : 2025.01 ~ 진행 중
링크 : https://github.com/M-ung/TicToc_Server
서비스 내용 : 당신의 시간에 가치를 매기다, 시간 거래 경매 플랫폼

---

🔥TroubleShooting🔥

Problems

우리 서비스 "TicToc"의 가장 중요한 핵심 기능에 대해서 고민할 시간이다. 바로 "입찰 기능" 이다.
단순히 Bid 엔티티를 저장해서 입찰을 하는 방식은 동시성 문제가 발생할 수 있다.

여기서 동시성 문제란?
동시성 문제는 여러 개의 트랜잭션이 동일한 데이터에 동시 접근하여 예기치 않은 결과가 발생하는 문제를 의미한다.
예를 들어 우리 TicToc 서비스의 입찰 기능은 여러 사용자가 같은 경매에 동시에 입찰할 때, 입찰 결과가 예상과 다르게 반영되거나 데이터 충돌이 발생할 수 있다.

우리 서비스는 돈으로 입찰을 하기 때문에 정확히 입찰 결과를 알려야 한다. 그렇기 때문에 "입찰 기능"을 구현하면서 오랜 고민을 하게 되었다.

궁금적으로 문제는 아래와 같다.

1. 동일한 데이터에 동시 접근하는 동시성 문제 해결
2. 여러 접근 중에 딱 하나의 접근만 가져오고 나머지는 롤백

---

How

위 문제들을 해결하기 위해 분산 락을 적용하여 하나만의 트랜잭션와 제어하도록 하고자 했다. 그리고 "입찰 기능"은 금전이 오고 가는 기능이기에 분산 락 외에 추가적인 안전 장치를 더하기로 했다.

---

Process

먼저 분산 락을 활용해서 단 하나의 입찰만 성공할 수 있게 구현했다.

또 단순히 분산 락만 적용하는 것이 아니라 락을 획득했을 때, 원자적 연산을 통해 바로 currentPrice를 즉시 DB에 업데이트해 주었다.

그 후 입찰 로직을 순차적으로 진행했고, 바로 락을 해제했을 때 대기 중이었던 입찰이 성공될 경우를 대비해 Thread.sleep(RedisConstants.LOCK_LEASE_TIME * 1000); 를 추가하여 딜레이 전략을 적용했다.

마지막으로 Bid 테이블에 beforePrice 라는 입찰 성공 전 가격을 저장하고, @Table(name = "bid", uniqueConstraints = @UniqueConstraint(columnNames = {"auctionId", "beforePrice"})) 유니크 제약 조건을 추가했다.

유니크 제약 조건으로 인해 Bid 테이블에는 하나의 auctionId에는 중복되는 beforePrice가 올 수 없기에 같은 경매가에 입찰을 성공하는 Bid가 2개 이상 존재할 수 없게 된다.

---

Result

문제 해결로 아래와 같은 결과를 얻었다.
1. “원자적 연산 + 분산 락 + 딜레이 + 유니크 제약 조건” → 동시성 문제 해결.
2. 5,000건 기준, 동시 입찰 요청 중 1건 성공, 4,999건 실패.
3. 데이터 일관성을 100% 보장.
4. 서비스의 핵심 기능 “입찰” 을 매우 안전하게 운영 가능.

최종적으로 "원자적 연산 + 분산 락 + 딜레이 + 유니크 제약 조건" 을 활용하여 5000명 이 동시에 입찰 시도를 했을 때, "1명만 입찰 성공 ✅, 4999명 입찰 실패 ❌" 테스트를 통과할 수 있었다.

---

Thoughts

"입찰 기능" 하나를 구현하는 데에 많은 시간 동안 많은 공부를 할 수 있었다. 단순히 어노테이션을 붙이 동시성 제어에서 끝내는 것이 아닌 Redis를 활용하여 분산 락을 활용했고, 단순히 분산 락에서 끝내는 것이 아닌 딜레이 전략을 활용해 안전성을 보장했다. 또 이에서 끝내는 것이 아닌, 원자적 연산과 유니크 제약 조건을 통해 더욱 안전성을 보강했다.

이번 경험을 통해 동시성 제어의 중요성을 다시 깨달았고, 테스트 코드의 신뢰성이 서비스 안정성에 직접적인 영향을 미친다는 점을 배울 수 있었다. 앞으로 테스트 코드를 꾸준히 작성하여 더욱 안정성과 신뢰성을 보장하는 개발자로 성장해야겠다.

---