[ZI9ZA9] 결제 성능 개선기

🔗 github.com/wootecam-gugucon/shopping-mall

 

우리 ZI9ZA9(이하 지구재구) 쇼핑몰에서는 당연히 결제 기능이 존재한다. 실제 출시할 서비스가 아니지만 최대한 비슷한 환경을 구현하고 싶어 테스트 키로 토스페이먼츠를 사용했다. (자사 포인트 결제도 제공하지만 이 포스팅에서는 생략하겠다.)

 

💸 결제 플로우

1. 주문서 생성

원하는 의류를 장바구니에 담고 주문하기 버튼을 누르면 서버에서 주문 및 주문 상품 데이터가 생성된다. 아직 사용자가 주문을 요청만 했으므로 주문 상태는 CREATED, 결제 상태는 NONE 이다.

 

프론트에서는 API 응답으로 받은 주문 데이터 id로 아래 결제하기 페이지를 불러온다.

 

결제하기 화면

결제 수단 중 일반 결제가 토스페이먼츠 결제를 의미한다.

 

2. 결제 요청

사용자가 결제를 요청하면 프론트는 우선 서버에 결제 요청 API를 보낸다. 

이 때 주문 데이터의 주문 상태와 결제 상태가 업데이트 된다. 

 

결제 전 결제 데이터를 업데이트하는 이유는 추후 서버에서 진행할 결제 승인 때문이다. 해당 주문이 정상적으로 결제를 요청했었는지, 토스 결제가 맞는 지 확인이 필요하기 때문이다.

 

3. 결제 진행

서버에서 전처리가 완료되면 이후 플로우는 토스페이먼츠에서 제공하는 위 그림을 따라간다.

 

프론트에서 결제위젯을 렌더링하고, 사용자는 위젯을 통해 실제 결제를 진행한다. 

결제위젯

 

4. 결제 승인

결제가 완료되면 미리 지정해둔 경로(successUrl)로 페이지가 이동하고, 프론트는 서버로 결제 승인 API를 요청한다. 이 때 서버에서 토스페이먼츠 API를 호출해 결제를 검사하고 완료되었으면 관련 재고를 차감 후 주문 데이터를 업데이트한다.

 

 

 

🐢 문제: 재고 감소와 외부 API 호출

결제 플로우는 문제가 없어 보인다. 실행하면 잘 동작한다. 다만 걸리는 부분이 있었다. 바로 마지막 단계인 결제 승인 API다.

// 결제 승인 트랜잭션
@Transactional
public PayValidationResponse validatePay() {
    // 재고 감소
    decreaseStock(order);
        
    // 토스페이먼츠 API로 결제 승인
    payValidator.validatePayment(payValidationRequest);

    return PayValidationResponse.from(orderId);
}

private void decreaseStock(final Order order) {
    order.getOrderItems().forEach(orderItem -> {
    	// 상품 조회
        final Product product = productRepository.findById();
        // 품절인지 검사
        product.validateStockIsNotLessThan(orderItem.getQuantity());
        // 재고 차감
        product.decreaseStockBy(orderItem.getQuantity());
    });
}

결제를 승인한 후 재고를 차감한다면 사용자 입장에서 결제는 승인되었는데 재고가 부족해 취소되는 불편함이 발생할 수 있다. 따라서 결제 승인 전 재고를 차감한다.

 

재고를 차감할 때는 상품 데이터를 가져온 후, 재고가 품절 상태인지 검사한다. 품절되지 않았다면 재고를 차감한다. 이 때 여러 스레드가 동시에 실행되는 과정에서 '조회 후 업데이트'라는 전형적인 갱신 손실이 발생한다. (만약 트랜잭션 격리 수준이 Serializable 라면 애초에 동시에 실행되지 않으므로 그 이하의 수준에서만 발생한다. 우리는 MySQL 기본 수준인 Repeatable Read 를 사용하고 있다.)

 

갱신 손실 예시

 

이 문제를 해결하기 위해 상품 테이블을 조회할 때 베타 락(select... for update)을 획득하도록 했다. 즉, 하나의 트랜잭션 내에서 락 획득과 외부 API 호출이 함께 이루어진다. 성능 저하가 우려되므로 nGrinder를 사용해 간단히 로컬에서 테스트를 해보자. 토스페이먼츠의 결제 승인 API가 성공하려면 주문 ID가 필요한데, 테스트라 결제는 하지 않으므로 임의의 값을 보내 실패하도록 했다. 이 테스트에서 외부 API 성공 여부는 중요하지 않기 때문이다.

 

성능 테스트 결과

가상 유저 99명이 동시에 접속할 때 평균 TPS가 31.9가 나왔다.

TPS 그래프

살펴보니 4초가 될 때부터 TPS가 급격히 떨어진다. MariaDB 기본 락 대기 시간(innodb_lock_wait_timeout) 은 50초이므로 커넥션들이 락을 얻기 위해 끝까지 기다리며 성능이 저하되었음을 유추할 수 있다. 

 

평균 테스트 시간은 3s다. 우리 쇼핑몰에 99명이 동시에 결제를 시도하면 3초 정도 기다려야 한다. 실제로는 결제 승인 외에도 다양한 요청이 동시에 일어날 것이기 때문에 더 기다려야 할 것이다. 또 로컬(램 16기가, 맥북 프로 M1)에서 테스트했으므로 실제 서버에선 더 느릴 것이다. 

 

어차피 이 쇼핑몰에는 아무도 접속할 수 없다. 좋지 않은 성능이라 판단해 해결하기로 했다.

 

 

 

🤔 해결: 재고 감소와 외부 API 호출을 분리하자

성능을 위해 단순히 둘을 다른 트랜잭션으로 분리하는 순간, 재고에 대한 정합성이 보장되지 않는다. 다른 접근이 필요하다. 해결책을 위해 이미 우리보다 뛰어난 개발자들이 만들어놓은 실제 서비스들을 생각해보았다.

 

그 때 영화 예매 서비스가 떠올랐다. 좌석(예매)에 대한 엄격한 정합성이 요구된다. 

결제'대기' 상태의 유저 A

같은 좌석을 선택하려는 유저 B

위는 CGV 예매 서비스다. 유저 A가 좌석을 선택한 순간, 결제하지 않아도 다른 유저들은 해당 좌석을 선택할 수 없다. 심지어 유저 A가 창을 닫아도 몇 분 동안은 여전히 다른 유저들이 예매할 수 없다.

 

추측할 수 있는 로직은 다음과 같다.

 

1. 사용자가 결제 창으로 이동하는 순간 일정 시간동안 좌석이 예매된 것으로 간주한다.
2. 만약 일정 시간 이내로 결제가 완료되지 않았다면 다시 예매 가능 상태로 변경한다.

우리 프로젝트도 이 방법을 적용하기로 했다. 따라서 결제 플로우 2번인 결제 요청에서 재고가 차감된다. 그리고 일정 시간 동안 결제가 완료되지 않으면 해당 주문을 취소한다.

// 결제 요청 트랜잭션
@Transactional
public OrderPayResponse requestPay() {
    final Order order = orderRepository.findByIdAndMemberIdExclusively();

    order.validateNotCanceled();
    order.startPay(orderPayRequest.getPayType());
    
    // * 재고 감소 메서드 추가
    decreaseStock(order);
    
    return OrderPayResponse.from(order);
}
    
// 결제 승인 트랜잭션
@Transactional
public PayValidationResponse validatePay() {
    // * 사라진 재고 감소 메서드
    
    // 토스페이먼츠 API로 결제 승인
    payValidator.validatePayment(payValidationRequest);

    return PayValidationResponse.from(orderId);
}

 

베타 락이 사라진 결제 승인 API의 성능은 얼마나 향상되었을까? 똑같은 조건으로 다시 성능 테스트를 진행했다.

성능 테스트 결과

TPS 98.8, 평균 실행 시간 1.7s로 3배 정도 성능이 향상되었다. 

물론 베타 락 획득 로직이 결제 요청 API로 이동했기 때문에 해당 요청의 성능은 느려졌지만, 결제 중 특정 구간에서 병목이 발생하지 않게 되었다.

🛞 해결: 주문 취소 스케줄러

재고를 미리 차감한다면 결제가 실패했을 때 복구해야 한다. 하지만 서버에서 사용자의 결제 취소 액션(ex. 창 닫기)을 모두 감지할 수 없다. 따라서 CGV처럼 일정 시간마다 결제되지 않은 주문을 취소하는 스케줄러가 필요하다.

 

우리는 Spring Boot와 MariaDB를 사용한다. 즉 Spring Scheduler와 MariaDB Event 모두 사용할 수 있다. 하지만 최대한 비즈니스 로직을 DB에 주지 않고 어플리케이션에서 객체지향적으로 해결하고 싶어 전자를 선택했다. DB 서버가 추가되면 이벤트를 다루기 까다로워진다는 점도 고려햇다.

 

@Transactional
public void cancelIncompleteOrders() {
    final LocalDateTime scanStartTime = lastScanTime == null ? DEFAULT_SCAN_START_TIME : lastScanTime;
    final LocalDateTime scanEndTime = LocalDateTime.now().minus(CANCEL_INTERVAL);

    // 비관적 락으로 취소할 주문들 조회
    final List<Order> incompleteOrders = orderRepository.findAllIncomplete();

    boolean allSucceeded = true;
    for (Order incompleteOrder : incompleteOrders) {
        final boolean succeeded = cancelIncompleteOrders(incompleteOrder);
        if (!succeeded) {
            allSucceeded = false;
        }
    }

    // 모든 취소에 성공하면 lastScanTime 업데이트
    if (allSucceeded) {
        lastScanTime = scanEndTime;
    }
}

private boolean cancelIncompleteOrders(final Order incompleteOrder) {
    // CREATED 주문 취소
    if (incompleteOrder.isCreated()) {
        orderService.cancelCreatedOrder(incompleteOrder);
        return true;
    }

    // PAYING 주문 취소
    try {
        orderService.cancelPayingOrder(incompleteOrder);
    } catch (Exception e) {
        return false;
    }
    return true;
}

 

스케줄러 플로우는 다음과 같다.

 

1. 마지막 취소 시간(lastScanTime)으로 취소할 시간의 범위를 정한다.
2. 해당 범위에 해당하는 주문 데이터들을 베타 락을 걸어 조회한다.
   - 스케줄러가 작동하는 동안 취소할 주문이 결제 완료가 되면 치명적인 업데이트 동시성 문제가 발생하기 때문이다.
3. 각 주문을 취소한다.
   - PAYING(결제 시작) 상태는 재고가 감소되었으므로 복구하고, CREATED(주문서 생성) 상태는 상태만 변경한다.
4. 모든 주문 취소에 성공하면 마지막 취소 시간을 업데이트한다.
   - 하나라도 실패하는 주문이 있으면 다음 스케줄러가 처리해야 하기 때문이다.

 

재고 복구 트랜잭션

이 때 3번의 재고 복구에 대해 생각해보자. 스케줄러는 일정 시간(우리 서비스는 30분으로 정했다) 내 결제가 완료되지 않은 주문들을 취소한다. 즉 상황에 따라 매우 많은 주문 데이터를 처리해야 할 수도 있다. 이 때 하나의 트랜잭션에서 모든 상품의 재고를 복구한다면, 트랜잭션이 종료되기 전까지는 재고가 복구되지 않으므로 데이터 양에 따라 주문이 밀릴 수 있다. 

 

따라서 재고를 복구할 때는 새 물리적 트랜잭션을 생성해 스케줄러의 영향을 받지 않도록 했다.

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void cancelPayingOrder(final Order order) {
    order.getOrderItems()
            .forEach(orderItem -> productRepository.increaseStock();
    order.cancel();
}

 

이 방법은 트레이드 오프가 있다. 스케줄러의 트랜잭션과 별개로 동작해 재고 복구가 신속히 이루어진다는 장점이 있지만, 매번 새 물리적 트랜잭션을 생성하면서 오버헤드가 발생한다. 따라서 스케줄러 내 주문 데이터의 베타 락 획득 시간이 길어진다.

외부 트랜잭션에 연결된 리소스는 내부 트랜잭션이 새 데이터베이스 연결과 같은 자체 리소스를 획득하는 동안 바인딩된 상태로 유지됩니다. 이로 인해 Connection Pool이 고갈될 수 있습니다. 여러 스레드가 활성 외부 트랜잭션을 가지고 있고 내부 트랜잭션에 대한 새 연결을 획득하기 위해 기다리는 경우 풀이 더 이상 이러한 내부 연결을 제공할 수 없어 교착 상태(deadlock)가 발생할 수 있습니다. Connection Pool의 크기가 동시 스레드 수를 1 이상 초과하는 적절한 크기가 아니면 PROPAGATION_REQUIRES_NEW를 사용하지 마세요.

또한 Spring 공식 문서에 나온 것처럼 하나의 요청에서 필요한 connection의 개수가 증가한다.

 

다만 스케줄러는 무조건 하나의 스레드에서만 실행되기 때문에 커넥션이 하나만 더 필요하다는 점, 생성되고 30분이 지난 주문 데이터를 업데이트 할 일이(베타 락을 획득해야 할 일이) 거의 없다는 점을 고려해 이 방법을 선택했다.

 

MariaDB(MySQL)의 락 

2번의 베타 락에 대해서도 살펴보자.

MySQL InnoDB는 레코드 기반의 잠금 방식을 탑재한다. 이 때 레코드 락(Record lock)은 레코드 자체가 아닌 인덱스의 레코드를 잠근다. 테이블에 인덱스를 추가하지 않았다면 클러스터링 인덱스인 PK(Primary Key)를 잠근다. 그리고 변경해야 할 레코드를 찾기 위해 검색한 인덱스의 레코드를 모두 락을 걸어야 한다.

 

스케줄러는 취소할 주문을 조회할 때 다음과 같은 쿼리를 실행한다.

SELECT * FROM Order o 
WHERE o.status IN ('CREATED', 'PAYING') 
    AND (o.lastModifiedAt BETWEEN '시작 시간' AND '종료 시간')
FOR UPDATE;

상태와 마지막 수정 시간을 조건으로 데이터를 조회하므로 해당 컬럼들을 탐색하며 조건에 맞는 데이터를 필터링한다. 이 때 두 컬럼에 인덱스가 걸려있지 않으면 어떻게 되는지 테스트 해보자.

 

주문 테이블에 4개의 데이터가 있다.

트랜잭션을 시작하고 위 쿼리와 비슷하게 실행해보았다.

begin;
select * from orders where status = 'CREATED' and last_modified_at = now() for update;

그리고 현재 걸려있는 모든 락을 조회했다.

*************************** 1. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: NULL
            LOCK_TYPE: TABLE
            LOCK_MODE: IX
          LOCK_STATUS: GRANTED
            LOCK_DATA: NULL
*************************** 2. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: PRIMARY
            LOCK_TYPE: RECORD
            LOCK_MODE: X
          LOCK_STATUS: GRANTED
            LOCK_DATA: supremum pseudo-record
*************************** 3. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: PRIMARY
            LOCK_TYPE: RECORD
            LOCK_MODE: X
          LOCK_STATUS: GRANTED
            LOCK_DATA: 1
*************************** 4. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: PRIMARY
            LOCK_TYPE: RECORD
            LOCK_MODE: X
          LOCK_STATUS: GRANTED
            LOCK_DATA: 2
*************************** 5. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: PRIMARY
            LOCK_TYPE: RECORD
            LOCK_MODE: X
          LOCK_STATUS: GRANTED
            LOCK_DATA: 3
*************************** 6. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: PRIMARY
            LOCK_TYPE: RECORD
            LOCK_MODE: X
          LOCK_STATUS: GRANTED
            LOCK_DATA: 4

해당 쿼리로 조회되는 데이터는 없음에도 4개의 모든 데이터와 테이블의 마지막(supremum pseudo-record)이 잠금을 획득했다. 이는 따로 조건절을 포함하는 인덱스가 없어, 조건에 맞는 데이터를 찾기 위해 모든 데이터를 탐색했기 때문이다.

 

스케줄러가 실행되는 동안 다른 주문에 대한 업데이트와 새로운 주문 추가는 정상적으로 이루어져야 한다. 따라서 카디널리티가 큰 last_modified_at 컬럼에 인덱스를 추가했다.

 

인덱스를 추가하고 다시 베타 락을 걸어 조회해보자. 이번에는 2번 행이 조회되도록 쿼리를 실행했다.

*************************** 1. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: NULL
            LOCK_TYPE: TABLE
            LOCK_MODE: IX
          LOCK_STATUS: GRANTED
            LOCK_DATA: NULL
*************************** 2. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: idx_2
            LOCK_TYPE: RECORD
            LOCK_MODE: X
          LOCK_STATUS: GRANTED
            LOCK_DATA: 0x99B2E22A27, 2
*************************** 3. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: PRIMARY
            LOCK_TYPE: RECORD
            LOCK_MODE: X,REC_NOT_GAP
          LOCK_STATUS: GRANTED
            LOCK_DATA: 2
*************************** 4. row ***************************
          OBJECT_NAME: orders
           INDEX_NAME: idx_2
            LOCK_TYPE: RECORD
            LOCK_MODE: X,GAP
          LOCK_STATUS: GRANTED
            LOCK_DATA: 0x99B2E22A28, 3

탐색 과정에서 거친 2번 행의 idx_2(last_modified_at) 인덱스와 PK 인덱스만 락이 걸려있다. 취소할 주문 데이터에만 락이 걸리도록 해결했다.

 

 

 

👍 정리

결제 플로우 중 하나의 트랜잭션에서 잠금 획득과 외부 API 호출이 겹치며 병목이 발생했다.

이를 해결하기 위해 두 작업을 다른 트랜잭션으로 분리하고 이로 생긴 재고 정합성 문제는 Spring Scheduler를 통해 해결했다.

 

3주 안에 프로젝트를 완성해야 해서 시간이 부족했기 때문에 더 발전시킬 부분이 보이는 게 아쉽다. 스케줄러를 어플리케이션과 별도의 서버에서 실행하고, 재고 복구 쿼리가 비동기적으로 실행되도록 변경한다면 (DB 스펙 때문에 확실하지는 않지만) 더 빠르게 실행되었을 것이다. 

 

실제 운영할 서비스가 아니었기 때문에 성능 목표를 딱 정하지 못한 점, 토스페이먼츠와의 통신이 포함된 시나리오에 대해 성능 테스트를 제대로 못한 점도 아쉽다. 그래도 다양한 내용을 공부할 수 있어서 좋았다.