결제서비스 - 결제 승인 시스템 구조와 Retry 전략[#52]

시스템 구조

결제 승인 구조는 포트와 어댑터 패턴을 사용하여 설계되었습니다. 이 패턴을 사용한 이유는 여러 결제 시스템을 유연하고 확장 가능하게 처리하기 위해서입니다.

 

예를 들어, Toss Payment 서비스를 사용하다가 PayPal이나 Stripe와 같은 다른 결제 서비스를 추가하거나 교체할 경우, 비즈니스 로직은 변경할 필요가 없으며, PaymentExecutor에 새로운 어댑터를 구현하는 것만으로 충분합니다.

 

이를 통해 유지보수가 용이하고 확장성이 뛰어난 구조를 유지할 수 있으며, 의존성 역전 원칙에 따라 비즈니스 로직이 구체적인 결제 시스템에 종속되지 않도록 설계되었습니다.

 

노락색 박스는 모두 인터페이스, 검은색 박스는 구현체를 의미하며 초록색 박스 안에 있는 값들은 클래스 변수입니다

똑똑한 Retry 전략

Retry 전략이 중요한 이유

MSA(Microservices Architecture) 환경에서 여러 개의 서비스가 통신하는 과정에서 네트워크 문제나 일시적인 오류가 발생할 수 있습니다. 특히 결제 서비스(PSP, Payment Service Provider)와 같은 중요한 트랜잭션에서는 결제 실패 시 시스템 안정성을 위해 트랜잭션 롤백, 재고 복원 등 추가적인 작업이 필요합니다.

 

아래 그림과 같이 결제 실패 요청을 모아서 일정 시간마다 한꺼번에 재시도하는 방식으로 결제를 처리한다고 가정해 보겠습니다. 이러한 방식은 다음과 같은 문제를 일으킬 수 있습니다:

• 서버 과부하: 재시도 요청들이 한꺼번에 몰리면 서버에 과부하가 걸려 네트워크 병목이 발생하거나, 서버 자원이 고갈될 수 있습니다.
• 성공 가능성 저하: 네트워크나 서버 문제로 처음 요청이 실패했을 경우, 재시도 시에도 동일한 문제가 발생할 가능성이 큽니다. 따라서 단순 재시도는 성공 확률을 높이지 않습니다.
• 지연 증가: 반복적인 재시도로 인해 결제 처리 시간이 길어져, 사용자 경험이 저하될 수 있습니다

 

이를 해결하기 위해 스마트한 Retry 전략이 필요하며, 그 핵심은 네트워크 장애 시에도 시스템을 효율적으로 복구하는 것입니다.



Exponential Backoff

Exponential Backoff는 재시도 간격을 지수적으로 증가시키는 방식입니다. 예를 들어, 첫 번째 재시도는 1초 후에, 두 번째는 2초 후에, 세 번째는 4초 후에 진행되는 방식으로, 2의 제곱에 비례하여 대기 시간이 늘어납니다.

하지만 이 방식에도 문제가 있습니다. 만약 여러 클라이언트가 동일한 시간에 실패하여 동일한 간격으로 재시도한다면, 재시도 요청이 동시에 몰리게 되는 문제는 여전히 남아 있습니다.

 

Jitter

Jitter는 Exponential Backoff의 문제를 해결하기 위해 고안된 방식입니다. Jitter는 재시도 간격에 랜덤한 지연 시간을 추가하여 요청들을 분산시킵니다. 이렇게 하면 여러 클라이언트가 동시에 재시도하더라도, 각각의 요청이 랜덤한 시간 차이를 두고 처리되어 서버 과부하를 줄일 수 있습니다.

예를 들어, 모든 클라이언트가 동일한 시간에 요청을 보내는 대신, Jitter로 인해 각각의 요청이 서로 다른 시간에 재시도됩니다. 이는 재시도 횟수가 늘어날수록 그 효과가 더 커집니다.

 

상태 기반 재시도

상태 기반 재시도 전략은 단순한 일시적 오류와 심각한 시스템 장애를 구분하여, 상태 코드에 따라 재시도 여부와 횟수를 다르게 설정하는 방식입니다. 이를 통해 불필요한 재시도를 방지하고, 시스템 효율성을 높일 수 있습니다.

예를 들어, 결제 시 발생할 수 있는 두 가지 상황을 고려해 보겠습니다:

• 고객 카드 한도 초과: 이는 고객의 자금 문제로 인한 오류이며, 재시도를 해도 성공할 가능성이 없으므로 즉시 실패 처리해야 합니다.
• 카드사 네트워크 장애: 네트워크 문제로 인해 일시적으로 결제가 실패한 경우입니다. 이 경우에는 재시도를 통해 성공 가능성을 높일 수 있습니다.

이처럼, HTTP 상태 코드를 바탕으로 결제 실패의 원인을 분석하고, 그에 따라 재시도 전략을 다르게 적용해야 합니다.