[결제 프로세스 설계] 트랜잭션 설정 및 전파, 동기/비동기, 동시성, Facade 패턴

사이드 프로젝트 중, 숙소 예약을 할 때의 결제 프로세스를 구현중이었습니다.

 

예약을 확정할 때, 결제 프로세스는 다음 사진처럼 여러 프로세스로 나뉘어 집니다. 

결제 요청부터 응답까지의 결제 프로세스

 

이 때, 제가 고려한 것은 총 5가지이며 이에 대해 설명을 진행합니다.

• 결제 프로세스의 트랜잭션 설정 범위
• '결제 승인을 위한 PG사 API 호출'과 트랜잭션의 순서
• '결제 승인을 위한 PG사 API 호출'을 동기/비동기 중 선택 
• 동시성 제어 방법
• 잔액 부족으로 인한 결제 승인 실패나 트랜잭션 롤백 시 발생하는 경우를 어떻게 처리할 것인지

 

1. 결제 프로세스의 트랜잭션 설정 범위

'결제 승인을 위한 PG사 API 호출' 은 네트워크를 통해 PG사에게 POST 요청을 통해 결제를 승인 받는 과정으로 트랜잭션에 포함되어 트랜잭션이 길어지게 된다면 다음과 같은 단점들이 있을 것이라 생각했습니다.

• Mysql 8.0 InnoDB 아키텍처 특성 상 트랜잭션이 길어질수록 언두 영역의 데이터가 삭제되지 못하고 성능이 느려집니다.
• 트랜잭션이 길면 DB커넥션이 재활용되지 못하고, 동시 요청의 수가 줄어듭니다.
• 네트워크 요청 시간에 의해 DB커넥션이 timeout 되거나, 잠금이 일어났을 경우 잠금 대기 시간이 길어지게 됩니다.

그렇기에 트랜잭션에서 '결제 승인 요청'을 분리하게 되었습니다.

 

2. '결제 승인을 위한 PG사 API 호출' 의 순서

이제 '결제 승인을 위한 PG사 API 호출'(이하 결제 승인 요청) 의 순서를 트랜잭션 시작과 끝 중 어디에 놓을 것인지 고민했습니다.

 

'결제 승인 요청' 이 트랜잭션 시작 전일 경우

• 장점
  • 결제 승인이 실패 했을 때, 고려할 것이 적어진다 → DB커넥션을 쓰지 않기 때문에 DB 관련 처리가 수월하다.
  • 결제 승인이 성공하고, 트랜잭션 내부에서 예외가 터졌을 때 롤백하기가 쉽다.
• 단점
  • 결제 승인이 성공하고, 트랜잭션 내부에서 예외가 터졌을 때, 롤백하기 쉽지만 PG사에게 '결제 취소 요청' 을 추가로 보내야 한다.

'결제 승인 요청'이 트랜잭션 끝난 후일 경우

• 장점
  • 숙소가 예약이 성공적일 때만 '결제 승인' 이 진행된다.
• 단점
  • '결제 승인 요청' 에서 금액 부족과 같이 문제가 발생해서 승인이 이루어지지 않는다면, 커밋된 트랜잭션을 손수 롤백해야 한다. 
  • 이 때, '결제 취소 요청을 보내는 비용'보다 '트랜잭션을 롤백하기 위해 DELETE 쿼리를 작성'하는 것은 비용이 더 큽니다.
    • 동시성 제어를 위해 예약 테이블에 유니크 제약조건을 사용했는데, 유니크 제약조건을 DELETE 할 때는 레코드 수준의 쓰기 락으로 걸리게 됩니다. 이는 데드락 빈도를 높이는 행위입니다.
    • InnoDB 아키텍처의 체인지 버퍼 기능을 사용하지 못합니다.
      • 체인지 버퍼란 쓰기 작업 시 디스크에 즉시 반영하는 대신 메모리에 반영함으로써 디스크 I/O 를 줄이는 기능입니다. 하지만, 유니크 컬럼은 고유해야 한다는 특성 때문에 쓰기 작업 시 디스크에 즉시 반영을 하게 됩니다.

이러한 고민을 바탕으로 아래의 사진과 같이 '결제 승인 요청' 을 트랜잭션 시작 전에 놓기로 결정했습니다.

결제 프로세스의 진행 설계

 

3. 결제 승인 요청을 보내는 외부 API 호출 방법을 동기로 선택

비동기의 장단점

• 장점
  • 외부 API 응답을 기다리지 않아도 되니 제 서버의 성능이 올라갑니다.
• 단점
  • 잔액 부족 같은 이유로 결제 승인이 실패할 경우, 예약 테이블과 결제 테이블에 INSERT 된 데이터를 다시 DELETE 해야 한다.
  • 이 과정에서 해당 트랜잭션이 데드락이 되어 DELETE 가 실패하면 재시도 로직을 추가하고, 예외를 잡는 로직을 추가하는 등 후처리 로직이 늘어난다.

동기의 장단점

• 장점
  • 결제 승인 요청 실패하면 트랜잭션이 시작되지 않으니 비동기의 단점에 해당하는 로직이 필요 없다.
• 단점
  • 외부 API 응답을 기다려야 하니 외부 API 응답이 느릴 경우, 서버 전체의 성능이 느려진다.

저는 동기 방식으로 외부 API를 호출하는 것을 선택했습니다.

비동기의 단점 문제를 해결하는 것보다 동기의 단점을 극복하는 것이 쉽기 때문입니다.

 

HTTP 쓰레드 풀의 연결 시간 타임 아웃과 응답 시간 타임 아웃을 설정해서 극복하고자 합니다.

이를 통해 외부 API 장애에 영향을 덜 받으며, 해당 요청을 처리하고자 합니다.

 

4. 동시성 제어 방법

저는 예약 날짜에 대해 숙소ID 와 날짜에 대해 유니크 제약조건을 사용했습니다.

이유

• 최초 INSERT 시에는 낙관적/비관적 락을 사용할 수 없습니다.
• '예약 가능 여부' 를 확인하기 위해서는 숙소ID와 날짜를 조회해야 하며, 인덱스가 필요하다. 이 때, 유니크 제약조건을 사용하면 유니크 인덱스가 생성된다. 

한계

• 유니크 제약조건은 체인지 버퍼 기능을 사용하지 못하기 때문에 쓰기 작업이 느립니다. 그래서, 예약 테이블에 INSERT 로 인해 성능이 느려진다면 다른 방법을 고민해야 합니다.

 

5. 잔액 부족으로 인한 결제 승인 실패나 트랜잭션 롤백 시 발생하는 경우의 구현 방법

잔액 부족으로 인해 결제 승인이 실패한다면 DB 조작이 발생하면 안됩니다.

그리고, 트랜잭션 롤백 시, 결제 취소 요청을 보내야 합니다.

 

트랜잭션 전파와 Facade 패턴을 사용해서 이러한 과정을 구현했습니다.

 

먼저, 트랜잭션 전파의 기본 설정인 REQUIRED를 통해 현재 진행중인 트랜잭션이 있으면 해당 트랜잭션에 참여하도록 구현했습니다.

class 결제서비스 {
    
    private final 예약서비스;
    
    @Transactional
    public void 숙소_예약에_대한_결제추가() {
    	
        1. 결제 승인 요청(외부 API 호출)
        2. @Transactional
           예약 서비스 호출()  -> 예약 중복확인, 예약 테이블 INSERT
        3. 결제 테이블 INSERT
    }
}

 

이제, 네트워크를 타는 결제 승인 요청을 트랜잭션에서 분리하고자 Facade 패턴을 사용했습니다.

결제 Facade는 결제 승인 요청(외부 API 호출)을 하는 TossClient 와 @Transactional이 걸린 결제 서비스를 호출합니다.

 

결제서비스를 호출할 때만 @Transactional 을 걸음으로써 트랜잭션에서 네트워크 요청을 분리하게 되었습니다. 

결제 프로세스 구현 세부 내용

 

그리고 결제 서비스의 트랜잭션을 예약 서비스까지 전파시켜 결제 데이터 INSERT, 예약 확정 UPDATE, 예약 날짜 INSERT 중 하나라도 롤백이 되어 물리 트랜잭션이 롤백되게 구현했습니다.

 

그리고, 롤백 될 때 Spring이 제공하는 DB 최고 상위 예외인 DataAccessException 을 try-catch 로 잡게 되면 TossClient 를 호출하여, 결제 취소 요청을 보내도록 구현했습니다.

public 결제응답데이터 예약확인하기(PaymentConfirmServiceRequest request) {

        // 임시 결제 데이터 존재 & 요청자와 결제자가 같은지 확인
        paymentService.validateExistingPaymentTemporary(request);

        // 결제 승인 요청(외부 API 호출)
        TossPaymentConfirm tossPaymentConfirm = tossClient.confirmPayment(request.paymentKey(), request.orderId(),
                request.amount());

        try {
            
            // 결제 및 예약 INSERT 에 대한 트랜잭션 시작
            return paymentService.confirmReservation(tossPaymentConfirm, request.reservationId(), request.memberId());
        
        } catch (DataIntegrityViolationException | BusinessException e) {
            log.warn("예약 실패", e);

            // 결제 취소 요청 보내기
            tossClient.cancelPayment(request.paymentKey());
            throw new BusinessException(ErrorCode.NOT_CONFIRM_RESERVATION);
        }
    }

 

 

 

글을 마무리 하며..

 

저는 기능의 안정성을 우선적으로 생각합니다.

만약, 글을 읽고 부족한 부분이 보인다면 주저없이 댓글로 남겨주시면 공부해서 보완하도록 하겠습니다🙇‍♂️