[Spring Boot] 동시성 문제 해결하기

🌱 문제 상황

• 판매 입찰과 구매 입찰이 존재한다.
• 판매 입찰과 구매 입찰은 1:1 관계이다.
• 구매 입찰 요청이 동시에 들어와도, 1개의 구매 입찰만 성공해야 한다.

판매 입찰에 관련된 구매 입찰 생성 로직

@RequiredArgsConstructor
@UseCase
public class BidUseCase {

    private final BidRepository bidRepository;
    
    @Transactional
    public void order(User user, OrderRequestDto request) {
        Bid sellBid = bidRepository.findFirstByProductIdAndPriceAndStatusOrderByCreatedAtAsc(
            request.productId(), request.price()).orElseThrow(() -> NOT_FOUND_BID_WITH_CONDITION);

        Bid buyBid = bidRepository.save(Bid.transactSellBidAndCreateBuyBid(user, bid));
    }
}

@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class Bid extends BaseTimeEntity {
    
    public enum BidType {
        SELL, BUY
    }

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private Status status;
    
    @Column(updatable = false)
    private LocalDateTime transactionAt;
    
    // ... 생략
    
    public static Bid transactSellBidAndCreateBuyBid(User user, Bid sellBid) {
        LocalDateTime transactionAt = LocalDateTime.now();
        sellBid.doTransaction(transactionAt);
        return create(user, sellBid, Status.IN_TRANSACTION, BidType.BUY, transactionAt);
    }

    private void doTransaction(LocalDateTime transactionAt) {
        validate(Status.LIVE);
        this.status = Status.IN_TRANSACTION;
        this.transactionAt = transactionAt;
    }
}

이는 주어진 상품과 가격에 맞는 입찰을 조회하고, 해당 입찰을 거래 중으로 상태 변경한 후 새로운 구매 입찰을 생성하는 주문 API 로직이다.

 

비즈니스 로직 상 판매 입찰 한 개 당 한 개의 구매 입찰이 생성되어야 하는데 해당 로직대로라면 여러 개의 주문 API를 동시에 호출할 경우 동시성 문제가 발생할 것이다.

 

실제로 cmd에서 curl & 명령을 통해 동시에 5개의 주문 API를 호출했을 때 5개의 구매 입찰이 생성되는 것을 확인할 수 있었다.

 

이를 해결하기 위해 두 개 이상의 스레드가 동시에 접근하지 못하도록 메서드에 synchronized 키워드를 선언하면 어떻게 될까?

 

🌱 해결방안

1️⃣ synchronized

@RequiredArgsConstructor
@UseCase
public class OrderUseCase {

    private final BidRepository bidRepository;
    
    @Transactional
    public synchronized void order(User user, OrderRequestDto request) {
        Bid sellBid = bidService.readOrderableBid(request.productId(), request.price())
            .orElseThrow(() -> NOT_FOUND_BID_WITH_CONDITION);

        Bid buyBid = bidRepository.save(Bid.transactSellBidAndCreateBuyBid(user, bid));
    }
}

 

주문 로직에 synchronized 키워드를 붙여 다시 5개의 주문 API를 동시에 호출해 보았다.

아까보다는 구매 입찰의 개수가 줄어들기는 했지만 의도대로 1개의 구매 입찰이 생성된 것은 아니다. synchronized를 사용하면 한 개의 스레드만 공유 자원을 점유할 텐데 왜 이런 결과가 나왔을까?

 

🤔 synchronized가 먹히지 않은 이유

그 이유는 바로 @Transactional 때문이다. @Transactional 사용 시 Spring AOP를 통해 트랜잭션 관리 기능이 적용되는데 이 과정에서 프록시 객체가 만들어지게 된다.

// 프록시 객체
public class OrderUseCaseProxy extends OrderUseCase {

    private final BidRepository bidRepository;
    
    @Override
    public void order(User user, OrderRequestDto request) {
        // ...
    }
}

// 기존 객체
public class OrderUseCase {

    private final BidRepository bidRepository;
    
    public synchronized void order(User user, OrderRequestDto request) {
        // ...
    }
}

프록시 객체는 기존 객체인 OrderUseCase를 상속해서 만들어지는데, synchronized는 메서드 시그니처(메서드 이름 / 파라미터 타입과 개수)가 아니기 때문에 상속되지 않는다. 따라서 프록시 객체의 order() 메서드는 여러 스레드가 사용할 수 있게 된다.

 

정리해서 기존 객체의 order()는 동시성 제어를 받지만, @Transactional 어노테이션으로 인해 생성된 프록시 객체의 order()는 동시성 제어를 받지 않아 문제가 발생했던 것이다.

 

🤔 그럼 @Transactional을 사용하지 않는 것은 어떨까?

@RequiredArgsConstructor
@UseCase
public class OrderUseCase {

    private final BidRepository bidRepository;
    
    public synchronized void order(User user, OrderRequestDto request) {
        Bid sellBid = bidService.readOrderableBid(request.productId(), request.price())
            .orElseThrow(() -> NOT_FOUND_BID_WITH_CONDITION);

        Bid buyBid = bidRepository.save(Bid.transactSellBidAndCreateBuyBid(user, bid));
        bidRepository.save(sellBid);
    }
}

@Transactional 어노테이션을 사용하지 않아 트랜잭션이 자동으로 관리되지 않기 때문에 sellBid의 상태를 변경(LIVE → IN_TRANSACTION, transactionAt 갱신) 한 후 save를 호출하여 변경사항을 데이터베이스에 명시적으로 저장하는 코드를 추가해 주었다.

 

이 경우 의도했던 비즈니스 로직대로 한 개의 구매 입찰만 생성되는 것을 확인할 수 있다.

 

하지만 synchronized는 근본적인 해결책이 될 수 없다. 우선 synchronized는 모든 스레드 동작에 대해 락을 걸어 오버헤드가 발생할 수 있다. 뿐만 아니라 synchronized는 한 프로세스 내에서 한 번에 하나의 스레드만 공유 자원에 접근하는 것을 보장하는 것이기 때문에 두 개 이상의 서버를 사용하게 되면 동시성 문제를 해결할 수 없다.

 

2️⃣ DB Lock

데이터베이스 락에는 두 가지가 있다.

 

🔓 낙관적 락(Optimistic Lock)

낙관적 락은 동시 요청을 직접적으로 막지 않고, 현재 트랜잭션의 데이터를 커밋하기 전 다른 트랜잭션에서 변경을 했는지 확인(version or timestamp)을 통해 동시에 데이터가 수정되는 것을 막는다.

만약 데이터의 버전이나 타임스탬프가 다를 경우 충돌을 감지해 현재 트랜잭션을 롤백하거나 재시도하여 동시성 문제를 처리한다.

 

😆 장점

• 동시 요청에 대해 DB 락을 걸지 않기 때문에 비관적 락보다 성능 향상 이점이 있다.
• 낙관적 락은 충돌이 자주 발생하지 않는다고 가정하기 때문에, 많은 사용자가 동시에 데이터에 접근할 수 있어 처리량이 높다.

🥲 단점

• 동시 요청으로 데이터 충돌이 발생했을 때 이를 해결하기 위한 추가적인 로직의 구현이 필요하다.
• 데이터의 변경 빈도가 높은 시스템에서는 충돌이 자주 발생하기 때문에 이를 해결하기 위한 추가적인 시간이 필요하다.

즉,  낙관적 락은 충돌이 빈번하지 않고 성능이 우선시되는 경우와 동시 요청에서 하나의 요청만 처리해야 하는 경우 적합하다.

 

🔓 비관적 락(Pessimistic Lock)

비관적 락은 어느 트랜잭션에서 특정 테이블에 접근 시 락을 걸어(DB 전체, 테이블, 열) 해제될 때까지 다른 트랜잭션에서 해당 테이블에 접근하지 못하도록 잠근다.

 

😆 장점

• 낙관적 락과는 다르게 테이블에 락을 걸어 다른 트랜잭션에서 아예 접근을 못하기 때문에 데이터의 일관성이 보장된다.
• 트랜잭션에서 데이터를 사용하기 전 락을 걸기 때문에 데이터 변경 중 다른 트랜잭션과의 충돌 가능성이 낮다.

🥲 단점

• 데이터의 일관성을 보장하지만 동시 접속자가 많은 환경에서는 락 대기시간으로 인해 성능에 영향이 있다.
• 다수의 트랜잭션이 서로 다른 순서로 여러 데이터에 락을 요청하면 데드락이 발생할 수 있다.

즉, 비관적 락은 데이터의 정합성이 중요하고 트랜잭션 간 충돌이 빈번하게 발생할 수 있는 경우에 적합하다.

 

🫧 비관적 락 적용

비관적 락은 데이터베이스의 배타락을 사용한다.

• 트랜잭션 T1이 데이터를 조회할 때, 배타락을 건다.
  • select for update를 사용한 락
• 트랜잭션 T2가 데이터를 조회하려고 했으나, 배타락이 걸려 있어 조회가 불가능하다.
  • T2는 데이터의 락이 해제될 때까지 대기한다.
• T1이 데이터를 수정하고, 커밋한다.
• T2가 데이터를 조회할 때, 배타락을 건다.
• T2가 데이터를 수정하고, 커밋한다.

비관적 락은 org.springframework.data.jpa.repository.Lock 어노테이션의 락 옵션을 PESSIMISTIC_WRITE으로 지정해 DB의 배타락을 거는 것이다.

public interface BidRepository extends JpaRepository<Bid, Long>, BidCustomRepository {

    @Lock(value = LockModeType.PESSIMISTIC_WRITE)
    @QueryHints( {@QueryHint(name = "javax.persistence.lock.timeout", value = "3000")})
    Optional<Bid> findFirstByProductIdAndPriceAndStatusOrderByCreatedAtAsc(Long productId,
        Integer price, Status status);
}

 

트랜잭션은 Lock을 획득할 때까지 대기하므로, 추가적으로 Lock Timeout을 설정해 주었다.

 

동시에 5개의 주문 API를 호출했을 때 1개의 구매 입찰이 생성되는 것을 확인할 수 있었다.

 

낙관적 락 vs 비관적 락

낙관적 락과 비관적 락 중 어떤 락을 사용할지는 트랜잭션 간 충돌 빈도에 따라 결정할 수 있다.

 

• 충돌 빈도 낮음. 데이터 정합성보다 성능이 중요 → 낙관적 락
• 충돌 빈도 빈번. 데이터 정합성 중요 → 비관적 락

 

따라서 여러 사람이 동시에 상품을 주문하는 경우 충돌이 빈번하게 일어나기 때문에 비관적 락 사용을 고려해 보고, 여러 사람이 주문하기는 하나 주문하는 시간이 각자 다른 경우 충돌이 비교적 적게 일어나기 때문에 낙관적 락 사용을 고려해 볼 수 있다.

 

그 이유는 충돌이 빈번하게 일어나는 상황에서 낙관적 락을 사용하게 된다면 구현마다 다르지만 모든 요청이 완료될 때까지 재시도를 수행하게 되어 데이터베이스에 굉장히 많은 요청을 보내게 될 것이다.

반면 비관적 락을 사용한다면 Lock을 걸고 요청을 수행하기 때문에 이후의 요청들은 업데이트가 완료될 때까지 기다린 후 순차적으로 요청을 진행하게 된다. 따라서 충돌 가능성이 높으면 비관적 락이 더 좋은 선택이 될 수 있는 것이다.

낙관 락 vs 비관 락 실무에서 구체적인 예시를 들어주실 수 있을까요? - 인프런

 

하지만 티켓팅처럼 정해진 시간에 트래픽이 많이 몰리는 이벤트인 경우 충돌이 잦다고 볼 수 있으나, 주문 로직의 경우 실제 트래픽이 생기기 전까지는 충돌 빈도를 추정하기가 어렵다. 따라서 이렇게 충돌이 많이 일어날지 알 수 없는 경우에는 우선 낙관적 락을 사용(비관적 락의 DB 락에 비용이 필요하기 때문)하다가, 운영상 성능 이슈가 발생할 때 비관적 락이나 다른 방법을 고려해 보는 것이 좋다고 한다.

 

이전에 낙관적 락을 사용해본 경험이 있어서 비관적 락을 사용해보고 싶었으나 비관적 락 사용 시 발생할 수 있는 문제점(성능 저하, 데드락 발생 가능성, 확장성 제한, 자원 낭비 등)으로 우선은 낙관적 락을 사용하여 시스템을 구축하고, 실제 트래픽 패턴을 모니터링한 후 필요한 경우 비관적 락으로 전환하는 것이 더 좋을 것이라 판단해 낙관적 락을 사용하기로 하였다.

---

@Version

JPA는 @Version 어노테이션을 통해 엔티티의 버전을 관리할 수 있다. 이 속성을 정의할 때는 아래의 규칙을 지켜야 한다.

1. 각 Entity 클래스에는 @Version 속성이 한 개만 있어야 한다.
2. 여러 테이블에 매핑된 Entity의 경우 기본 테이블에 배치되어야 한다.
3. 버전 타입은 Integer(int), Long(long), Short(short), java.sql.Timestamp 중 하나여야 한다.

@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class Bid extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    ..

    @Version
    private Long version;
}

이 필드의 값 또는 시간으로 처음 조회될 때의 버전과 커밋될 때의 버전을 비교해 만약 다를 경우 충돌이 발생한 것으로 판단해 예외를 발생시킨다.

 

[transaction-1]: 판매 입찰 조회 / version: 1
[transaction-2]: 판매 입찰 조회 / verison: 1

---- 두 트랜잭션 중 transaction-1 먼저 완료됨 ----

[transaction-1]: 구매 입찰 생성 / version: 2 로 업데이트하고 커밋
[transaction-2]: 구매 입찰 생성 / verison: 2 로 업데이트하고 커밋하려할 때
transaction-1 에서 version이 2로 변경되어 조회했던 버전과 다르므로 업데이트 실패

UPDATE bid
SET
    bid_type=?,
    version=2
WHERE id=?
    AND version=1

위와 같이 쿼리가 발생하지만 version이 이미 [transaction-1]로  인해 2로 증가된 상태라 업데이트 대상을 찾지 못해 예외가 발생하는 것이다.

 

LockModeType

LockModeType를 OPTIMISTIC으로 설정해 낙관적 락을 사용한다.

public interface BidRepository extends JpaRepository<Bid, Long>, BidCustomRepository {

    @Lock(LockModeType.OPTIMISTIC)
    Optional<Bid> findFirstByIdAndBidTypeAndStatusOrderByCreatedAtAsc(Long id, BidType bidType,
        Status status);
}

 

낙관적 락의 예외 종류

• javax.persistence.OptimisticLockException (JPA)
• org.hibernate.StaleObjectStateException (Hibernate)
• org.springframework.orm.ObjectOptimisticLockingFailureException (Spring)

Spring 기반 JPA에서 낙관적 락을 사용하면 version 충돌 시 Hibernate에서 StaleStateException을 발생시킨다. 그 후 Spring에서 해당 예외를 ObjectOptimisticLockingFailureException로 감싸서 응답한다.

 

@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {

    ...

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler(ObjectOptimisticLockingFailureException.class)
    public ErrorResponse handleObjectOptimisticLockingFailureException(ObjectOptimisticLockingFailureException e) {
        log.info("구매 입찰 생성 동시성 문제 발생", e);
        return ErrorResponse.of("UNEXPECTED_ERROR", e.getMessage());
    }
}

GlobalExceptionHandler에 ObjectOptimisticLockingFailureException을 처리하는 로직을 추가해 주었다.

 

+ 다른 해결 방안

글의 윗부분에서 낙관적 락을 사용하다 운영상 성능 이슈가 발생할 때 비관적 락을 고려해 보는 것이 좋다고 써놓았지만, 비관적 락은 Lock이 필요하지 않은 상황에서도 모든 트랜잭션에 대해 Lock을 사용해 트래픽이 많은 경우 O(N^2) 정도 성능이 저하될 수 있으며 두 개 이상의 column 혹은 테이블에 Lock을 걸 경우 데드락이 발생할 수 있다는 단점이 있다.

 

따라서 이런 이슈들은 비관적 락이 아닌 다음 방법을 키워드로 참고해 보면 될 것 같다.

1. Redis Sorted Set 활용
2. Redis의 Lua Script 활용
3. Kafka와 같은 메시징 큐 도입
4. API Gateway에서 처리율 제한 알고리즘 구현
5. 처리율 제한기 미들웨어 도입

 

 

📚 참고

Pessimistic Locking in JPA

[JPA] @Transactional 과 동시성

How to specify @lock timeout in spring data jpa query?

상품 주문 동시성 문제 해결하기 - DeadLock, 낙관적 락(Optimistic Lock) & 비관적 락(Pessimistic Lock)

[E-commerce] 동시성 문제 해결하기 (비관적 락, 네임드 락, 분산 락)

동시성 문제 해결하기 V2 - 비관적 락(Pessimistic Lock)

낙관적 락과 비관적 락은 갱신 손실 문제를 어떻게 해결하는가