[🔥TroubleShooting - TicToc🔥] 경매 관리 중에 입찰이⁉️ 동시성 충돌을 막아라‼️‼️

📌 프로젝트 소개

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

---

🔥TroubleShooting🔥

Problems

경매(Auction)의 현재 진행 상태를 progress 라는 칼럼을 두고 관리를 하기로 했다.
이 칼럼은 아래와 같은 상태를 가진다.

• NOT_STARTED : 아직 경매가 시작되지 않음
• IN_PROGRESS : 경매가 진행 중
• BID : 경매 종료 및 입찰 완료
• NOT_BID : 경매 종료 및 입찰 실패

경매 수정와 삭제 기능을 구현하면서 고민이 생겼다. 이미 경매가 시작된 상태에서 수정/삭제를 하는 건 잘못된 기획이라고 생각해서 아래와 같이 수정/삭제 전에 유효성 검사를 실행했다.

하지만 경매 수정/삭제 과정에서 입찰이 들어오면 어떻게 해야 할까..?

기획은 아래와 같이 정의했다.

1. 경매 수정 중 입찰이 들어오면 입찰 성공 ✅, 수정 실패 ❌
2. 경매 삭제 중 입찰이 들어오면 입찰 성공 ✅, 수정 실패 ❌

---

How

위 기획대로 기능을 구현하기 위해 아래와 같은 해결책을 고려했다.

수정 및 삭제 로직이 경매(Auction)의 변경을 감지해야 한다.

감지하기 위해서 "비관적 락"을 적용하기로 했다.

---

Process

비관적 락을 적용하기 위해 delete 와 update 를 아래와 같이 구현했다.

📍 AuctionCommandService.java - update

📍 AuctionCommandService.java - delete

그리고 위 메서드 안에 존재하는 findAuctionByIdForUpdate 는 아래와 같이 비관적 락을 적용해서 구현했다.

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT a FROM Auction a WHERE a.id = :auctionId and a.status = :status")
    Optional<Auction> findByIdAndStatusForUpdate(@Param("auctionId") Long auctionId, @Param("status") TicTocStatus status);

내가 생각한 기획 시나리오에 맞게 아래 테스트를 작성했다.

📍 경매 수정 동시성 테스트

    @Test
    @DisplayName("경매 수정 시 동시성 이슈 발생에 대한 테스트")
    public void 경매_수정_시_동시성_이슈_발생에_대한_테스트() throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(2);
        ExecutorService executorService = Executors.newFixedThreadPool(2);

        executorService.submit(() -> {
            try {
                bidCommandUseCase.bid(2L, new BidUseCaseReqDTO.Bid(auction.getId(), BID_PRICE));
            } catch (Exception e) {
                assertThat(e.getMessage()).isEqualTo(ErrorCode.BID_FAIL.getMessage());
            } finally {
                latch.countDown();
            }
        });

        executorService.submit(() -> {
            try {
                AuctionUseCaseReqDTO.Update updateDTO = new AuctionUseCaseReqDTO.Update(
                        "Updated Auction Title",
                        "Updated Auction Description",
                        1200,
                        LocalDateTime.now().plusMinutes(15),
                        LocalDateTime.now().plusHours(1),
                        LocalDateTime.now().plusHours(2),
                        Collections.emptyList(),
                        AuctionType.ONLINE
                );
                auctionCommandUseCase.update(1L, auction.getId(), updateDTO);
            } catch (Exception e) {
                assertThat(e).isInstanceOf(ConflictAuctionUpdateException.class);
            } finally {
                latch.countDown();
            }
        });

        latch.await();
        executorService.shutdown();

        Auction afterAuction = auctionRepositoryPort.findAuctionById(auction.getId());
        assertThat(afterAuction.getTitle()).isEqualTo("Test Auction");
        assertThat(afterAuction.getProgress()).isEqualTo(AuctionProgress.IN_PROGRESS);
        assertThat(afterAuction.getCurrentPrice()).isEqualTo(BID_PRICE);
    }

📍 경매 삭제 동시성 테스트

    @Test
    @DisplayName("경매 삭제 시 동시성 이슈 발생에 대한 테스트")
    public void 경매_삭제_시_동시성_이슈_발생에_대한_테스트() throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(2);
        ExecutorService executorService = Executors.newFixedThreadPool(2);

        executorService.submit(() -> {
            try {
                bidCommandUseCase.bid(2L, new BidUseCaseReqDTO.Bid(auction.getId(), BID_PRICE));
            } catch (Exception e) {
                assertThat(e.getMessage()).isEqualTo(ErrorCode.BID_FAIL.getMessage());
            } finally {
                latch.countDown();
            }
        });

        executorService.submit(() -> {
            try {
                auctionCommandUseCase.delete(1L, auction.getId());
            } catch (Exception e) {
                assertThat(e).isInstanceOf(ConflictAuctionDeleteException.class);
            } finally {
                latch.countDown();
            }
        });

        latch.await();
        executorService.shutdown();

        Auction deletedAuction = auctionRepositoryPort.findAuctionById(auction.getId());
        assertThat(deletedAuction.getStatus()).isEqualTo(TicTocStatus.ACTIVE);
        assertThat(deletedAuction.getProgress()).isEqualTo(AuctionProgress.IN_PROGRESS);
        assertThat(deletedAuction.getCurrentPrice()).isEqualTo(BID_PRICE);
    }

그치만... 테스트가 실패했다..😭😭

위 코드에 대한 시나리오는 아래 사진과 같다.

먼저 수정/삭제 시 해당 경매를 조회하고 이를 Lock 한다. 그 후 입찰을 시도하게 되면 잠겨 있기 때문에 입찰에 실패하게 된다.

그럼 코드를 다른 방향으로 생각해 보아야 한다.

비관적 락이 아닌, 낙관적 락을 적용해 보기로 했다.

📍 Auction.java

먼저 Auction 엔티티에 @Verison 을 추가한다.

그 후 update, delete 메서드에 낙관적 락 로직을 적용한다.

📍 AuctionCommandService.java - update

📍 AuctionCommandService.java - delete

📍 AuctionRepository.java - findByIdAndStatusForUpdate

위 구현의 시나리오는 아래와 같다.

---

Result

위 구현 결과, 위에서 실패했던 테스트 코드를 통과할 수 있었다.
즉, 문제에서 제기한 기획대로 구현한 것이다.

1. 경매 수정 중 입찰이 들어오면 입찰 성공 ✅, 수정 실패 ❌
2. 경매 삭제 중 입찰이 들어오면 입찰 성공 ✅, 수정 실패 ❌

---

Thoughts

이번 경험을 통해 무조건 비관적 락이 좋다! 낙관적 락이 좋다! 보단 언제 어떤 상황에서 어떤 방식으로 풀어나가는 게 맞는지를 배울 수 있었다.

단순히 동시성을 피하기 위해 비관적 락을 적용해 DB를 잠궈버리려 했지만, 이는 입찰 요청을 방해하는 일이 되어버렸다.

동시성 문제를 해결하기 위해서 낙관적 락, 비관적 락, 분산 락, 등 어떤 설계를 적용하든 잘 알고 상황에 맞게 쓰는 것이 중요하다는 것을 배울 수 있었다.

---