[NaBMart] 주문 결제 시스템 개선기

🚀  개요

데브코스 4기에서 배달의 민족의 B마트 클론 코딩 프로젝트인 NaBMart 를 개발하였다. 프로젝트는 작년 9월에 끝났지만, 주문과 결제 부분에서 개선할 부분들이 보여 개인적으로 리팩토링을 진행하였다. 리팩토링한 내용은 다음과 같다.

1. 주문 스케줄러 개선
2. 주문 결제 동시성 이슈 해결

주문 스케줄러 개선

 우선 NaBMart 의 주문 결제 flow 는 다음과 같다. (결제 PG는 토스페이먼츠를 사용하였다.)

1. 클라이언트가 서버에 주문 요청을 하고, 서버는 주문을 처리하고 재고를 감소한다.
2. 클라이언트가 서버에 결제 요청을 하고, 서버는 주문의 유효성을 검사한 후 PG사와 통신할 때 필요한 데이터를 응답한다.
3. 클라이언트는 PG사에 결제 요청을 하고, 사용자는 결제 방법을 선택하여 결제를 진행한다.
4. 결제가 성공 또는 실패를 하면 콜백 url로 리다이렉트된다.
5. 서버는 PG사에 요청하여 결제 확인 및 승인 요청을 한다.

우리 프로젝트에서는 주문 요청을 했을 때 재고를 감소한다. 이 때, 주문 후 결제가 정상적으로 이루어지지 않을 경우 실제 상품의 재고가 있음에도 불구하고 주문을 할 수 없는 상황이 발생할 수 있다. 이러한 문제를 방지하기 위해 우리는 스케줄러를 사용하여 주기적으로 30분 동안 완료되지 않은 주문을 취소시키고 재고를 복구하는 작업을 하였다. 스프링 스케줄러를 사용하였으며 코드는 다음과 같다.

// OrderSchedulterService
@Scheduled(cron = "0 */5 * * * *")
public void updateOrderStatus() {
    orderService.updateOrdetatus();
}

// OrderService
@Transactional
public void updateOrderStatus() {
    LocalDateTime expiredTime = LocalDateTime.now().minusMinutes(30);
    List<OrderStatus> statusList = List.of(OrderStatus.PENDING, OrderStatus.PAYING);

    List<Order> expiredOrders = orderRepository.findByStatusInBeforeExpiredTime(expiredTime, statusList);
    expiredOrders.forEach(this::cancelOrder);
}

@Transactional
public void cancelOrder(Order order) {
    order.updateOrderStatus(OrderStatus.CANCELED);
    order.getOrderItems().forEach(
        orderItem -> itemRepository.increaseQuantity(orderItem.getItem().getItemId(),
            orderItem.getQuantity())
    );
}

테스트를 하기 위해 5개의 만기된 주문 데이터를 삽입하였다.

이제 스케줄러를 실행시키고 로그를 찍어보면 취소할 주문 모두 하나의 트랜잭션에서 수행되는 것을 알 수 있다. (로깅 레벨 : debug)

JpaTransactionManager 의 doCommit 메서드에 디버그 지점을 찍고, 락 조회 명령어를 통해 커밋이 완료되기 전 데이터베이스에 어떤 락이 존재하는지 확인해보자. (데이터베이스는 MySQL 을 사용하였다.)

SELECT * FROM performance_schema.data_locks;

취소해야하는 모든 주문의 상품에 재고 갱신을 위해 배타락이 걸리게 된다. 따라서 주문 스케줄러 동작이 끝날 때까지 해당 상품은 주문할 수 없다.

상품에 걸리는 락 시간을 최소화하고자 트랜잭션 전파속성인 REQUIRES_NEW 를 사용하여 주문들이 각각의 독립된 트랜잭션에서 수행되도록 수정하였다.

// OrderCancelService

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void cancelOrder(final Order order) {
    order.updateOrderStatus(OrderStatus.CANCELED);
    order.getOrderItems().forEach(
        orderItem -> itemRepository.increaseQuantity(orderItem.getItem().getItemId(),
            orderItem.getQuantity())
    );
}

다시 스케줄러를 실행시켜 실행 로그를 찍어보면 각각의 주문이 하나의 분리된 트랜잭션에서 동작하는 것을 확인할 수 있다.

이제 주문을 취소할 때, 해당 주문에 존재하는 상품에만 락이 걸리게 된다.

주문 결제 동시성 이슈 해결

재고 복구를 위한 주문 스케줄러를 도입하면서 결제 서비스와 주문 스케줄러에서 동일한 주문에 접근할 수 있기 때문에 동시성 문제가 발생하였다.

// OrderService
@Transactional
public void updateOrderStatus() {
    LocalDateTime expiredTime = LocalDateTime.now().minusMinutes(30);
    List<OrderStatus> statusList = List.of(OrderStatus.PENDING, OrderStatus.PAYING);

    List<Order> expiredOrders = orderRepository.findByStatusInBeforeExpiredTime(expiredTime, statusList);
    expiredOrders.forEach(this::cancelOrder);
}

// PaymentService
@Transactional
public PaymentResponse processSuccessPayment(Long userId, String uuid, String paymentKey,Integer amount) {
    ...
    validateOrderStatusWithPaying(order);
}

• 주문 스케줄러 : 주문의 상태가 30분 이상 주문 대기(PENDING) 또는 결제 중(PAYING) 라면 해당 주문를 취소하고 재고를 복구
• 결제 성공 처리 : 결제 대상이 되는 주문의 상태가 결제 중(PAYING)이라면 결제 정상 처리

위 그림과 같이 주문 스케줄러에 의해 주문이 취소되고 재고를 복구하는 동시에 결제가 완료될 수 있다. 따라서 주문이 취소되어 재고가 복구되었음에도 불구하고 결제는 완료되는 상황이 발생할 수 있다.

해당 문제를 해결하기 위해 낙관적락과 비관적락을 고려하였고, 다음과 같은 이유로 낙관적락을 선택하였다.

1. 대부분의 결제는 30분 내로 완료됨
2. 특정 주문에 대한 결제 처리와 주문 스케줄러가 동시에 요청이 발생할 경우가 적음
3. 비관적락을 사용할 경우, 주문 스케줄러에의해 기준 시간 이하의 모든 주문에 배타락이 걸려 주문 관련 요청(라이더 배차 등)들은 스케줄러가 락을 반납할 때까지 대기해야함
4. 비관적락을 사용할 경우, 스케줄러 대상 중 하나의 주문이라도 결제 서비스에 의해 락이 걸렸다면, 스케줄러는 대기해야함