결제 도메인의 재시도 상황 및 전략, 멱등성 연계

스타트업 결제 도메인 구축기

결제 과정은 금전과 관련된 일이기 때문에 반드시 한번 이상의 처리를 보장해야합니다. 이를 보장하려면 필연적으로 재시도가 생겨납니다.

네트워크 끊김 등 모든 상황에서도 한번 이상 올바르게 처리되도록 하기 위해서는 트랜잭션으로 보장받지 못하는 모든 연결부에서 발생하는 케이스에서 실패 시 재시도가 되어야 하기 때문입니다.

따라서 똑같은 로직이 여러번 발생하는 경우 생기는 문제를 막기 위해 멱등성을 보장했습니다. 시리즈의 전 포스트를 참고해주세요.

이번 글에선 결제 도메인에서 재시도 처리를 해야하는 케이스들을 살펴보고, 함께 활용할 수 있는 재시도 전략들도 살펴보겠습니다.

재시도 전략

고정 간격 재시도 (Fixed Interval Retry)

제일 기본적이고 직관적인 재시도 방식입니다. 특정 고정 간격을 두고 실패 시 해당 간격 후 재시도를 실행하는 방식입니다.

예를 들어, 실패할 때마다 5초 후에 다시 시도하도록 설정하는 방식입니다. 단순한 로직으로 구현이 쉽지만, 여러 요청이 동시에 실패할 경우 같은 시점에 다시 몰려 시스템에 부하를 줄 수 있습니다. 실패의 원인이 치명적인 에러가 아니거나 의도한 경우, 혹은 빠른 응답이 중요한 경우 주로 사용됩니다.

지수 백오프 (Exponential Backoff)

재시도 실패 시 다음 재시도까지의 대기 시간을 점진적으로 늘려나가는 방식입니다. 첫 번째 재시도 시 1초, 두 번째는 2초, 세 번째는 4초와 같이 대기 시간이 기하급수적으로 증가합니다.

결제 시스템에 일시적으로 부하가 걸렸을 때, 재시도 요청이 한꺼번에 몰리는 것을 효과적으로 방지합니다. 실패가 생길 수 있는 원인이 시스템 다운 등 예측 불가능한 상황인 경우, 복구까지 기다릴 수 있기에 유용합니다.

다만 client와 동기적으로 주고받는 API 단에서 사용하기엔 응답을 받는 데 드는 시간이 지수적으로 늘어나서 UX를 해칩니다.

분산 재시도 (Jitter)

지수 백오프나 고정 간격 재시도 등에 임의의 지연 시간을 추가하는 방식입니다. 예를 들어, 2초 후에 재시도해야 할 경우, 1.8초에서 2.2초 사이의 무작위 시간으로 재시도합니다. 이는 여러 요청이 정확히 같은 시간에 재시도되어 다시 충돌하는 ‘재시도 폭풍’을 방지하는 데 효과적입니다.

실패 로그 / 데드 레터 큐

만약 임계 까지 재처리하여도 성공하지 못해 영구적으로 실패로 처리되거나, 내부 DB 등 영속성 영역에 문제가 생겼을 때는 SW 상에선 즉각적으로 자동화된 대응이 불가능 합니다.

이런 작업이 발생했을 경우, 반드시 다원화된 창구를 통해 이 사항을 기록하여야 합니다.

API 단에서 생기는 쓰기 작업은 DB에 에러 테이블을 만들거나, slack에 결제 실패 스레드를 만들고 로그를 쌓는 등을 통해 처리할 수 있습니다.

데드 레터 큐는 메시지 브로커 재처리 쪽에서 주로 쓰이는 개념으로 실패한 메시지만 모아놓는 토픽을 따로 개설하여 재처리 실패시 해당 토픽에 적재하는 방식으로 사용됩니다. 아래 글에서 다뤘는데 흥미 있으시면 참고 바랍니다.

Kafka Consumer - 오프셋 커밋과 재처리 전략, Dead Letter Queue(DLQ)

거래 생성 시 재시도 - 낙관적 락

거래 생성이 만약 상품의 재고를 관심사로 두고 있는 경우, 쓰기 정합성 보장 및 조회 시의 오버헤드를 줄이기 위해 낙관적 락을 많이 사용합니다. 이 케이스에선 결제가 생성되는 시점에 재고에 대한 변동이 있을 경우 실패 처리가 아니라 동일 로직을 재시도해주어야 합니다.

재시도 전략을 신중히 고려해야합니다. 만약 한 칼럼에 일 순간에 수많은 거래 생성 요청이 생기는 경우 (ex: 티켓팅 서비스) 바로 재시도 시기는 경우 충돌 빈도가 늘어나고 시스템에 부하가 갈 수 있습니다.

제가 권장하는 방식은 고정 간격 재시도와 지터 추가입니다.

낙관적 락 자체는 굉장히 빈번하게 실패할 수 있는 상황이며 서버 다운같은 상황으로 실패되는 것이 아니기에 오래 기다릴 필요가 없습니다.

다만 어느정도의 지터를 두어 동시에 요청이 쏟아 진 경우 적절히 분산되게 처리합니다.