[volume-6] 장애 및 지연 대응

[yeonsu00]

📌 Summary

• PG 연동
• Resilience4j 적용
  • Circuit Breaker
    • 슬라이딩 윈도우 20, 최소 호출 10, 실패율 60% 초과 시 OPEN 상태로 전환
    • OPEN 상태에서 30초 대기 후 자동으로 HALF_OPEN 상태로 전환
    • HALF_OPEN 상태에서 최대 5번의 호출만 허용하여 시스템 복구 여부 확인
  • Retry: 최대 2번 재시도 (총 3번 시도), 1초 간격
  • TimeLimiter: 3초 타임아웃 설정
  • 외부 시스템 장애 대응
    • Circuit Breaker Fallback: PG 시스템 장애 시 즉시 차단하고 Fallback 메서드 호출
    • Retry Fallback: 재시도 실패 시 PENDING 상태 응답 반환
  • 콜백 처리 및 상태 동기화
    • 콜백 수신: PG에서 전송하는 결제 완료/실패 콜백을 PaymentV1Controller.handlePaymentCallback에서 처리
    • 상태 업데이트: 콜백 수신 시 Order와 Payment 상태를 동기화

---

💬 Review Points

1. PG 결제 완료 후 콜백 전송 실패 시나리오 처리

PG 사에서 결제가 완료되었지만, 우리 서비스로 콜백을 보내는 과정에서 네트워크 오류가 발생하여 PG는 결제 완료 상태이지만 우리 서버는 결제 완료 사실을 모르는 상황일 때

1. 실무에서는 이런 상황을 어떻게 해결하시나요?

   • 주기적으로 PG의 결제 상태 확인 API를 호출하여 동기화하는 스케줄러를 운영하시나요?

2. PG 상태 확인 API 호출 시 주의사항이 있나요?

   • 너무 빈번한 호출로 인한 Rate Limit, 동일 transactionKey에 대한 중복 처리 방지 등

---

2. 주문 만료 처리 및 스케줄러 운영

사용자가 주문을 생성했지만 일정 시간 내에 결제를 완료하지 않은 경우 주문 만료 처리를 어떻게 하시나요?
Order.createdAt이 일정 시간 지난 주문들을 OrderStatus.CANCELED로 변경하는 스케줄러를 운영하시나요?

---

✅ Checklist

• 불필요한 코드 제거

⚡ PG 연동 대응

• PG 연동 API는 RestTemplate 혹은 FeignClient 로 외부 시스템을 호출한다.
• 응답 지연에 대해 타임아웃을 설정하고, 실패 시 적절한 예외 처리 로직을 구현한다.
• 결제 요청에 대한 실패 응답에 대해 적절한 시스템 연동을 진행한다.
• 콜백 방식 + 결제 상태 확인 API를 활용해 적절하게 시스템과 결제정보를 연동한다.

🛡 Resilience 설계

• 서킷 브레이커 혹은 재시도 정책을 적용하여 장애 확산을 방지한다.
• 외부 시스템 장애 시에도 내부 시스템은 정상적으로 응답하도록 보호한다.
• 콜백이 오지 않더라도, 일정 주기 혹은 수동 API 호출로 상태를 복구할 수 있다.
• PG 에 대한 요청이 타임아웃에 의해 실패되더라도 해당 결제건에 대한 정보를 확인하여 정상적으로 시스템에 반영한다.