PSP 장애: 중복 결제 없이 예비 경로로 전환하고 복귀하는 법

주 PSP가 다시 응답하자 당직자가 트래픽을 되돌립니다. 1분 뒤 자동화가 다시 예비 경로를 켭니다. 팀이 누가 라우팅을 통제하는지 따지는 사이, 이전 결제 일부는 결과를 알 수 없는 상태로 남습니다. 훈련용 가상 시나리오이지만 교훈은 분명합니다. PSP 페일오버는 신규 시도, 미완료 거래, 그리고 주 경로로의 안전한 복귀까지 모두 다뤄야 합니다.

가상 사례로 전환 과정을 살펴보라

플랫폼은 허용된 한 가지 결제수단에 대해 경로 A와 B를 미리 연결해 두었습니다. 14:05에 A에서 타임아웃이 늘어납니다. 팀은 A로 가는 신규 요청을 제한하고 B가 적합한지 확인합니다. 주문 R-902는 이미 A로 전송되었지만 응답이 없습니다. 이 건은 대사 대상으로 남습니다. 주문 R-903은 아직 전송되지 않았습니다. 통상적인 점검을 거친 뒤 파라미터가 이 경로에 맞는다면 B로 보낼 수 있습니다.

R-902의 멱등성 키를 그대로 B에 복사하고 보호가 공유된다고 여겨서는 안 됩니다. 제안하는 아키텍처에서는 하나의 내부 시도 기록이 있고, 새로운 금융 작업은 이전 작업의 결과가 확인되었거나 PG사가 제공하는 안전한 절차를 거친 뒤에만 허용됩니다. 고객 지원팀은 대기 사유를 볼 수 있고, 고객에게 통제 없이 결제를 반복하라고 권하지 않습니다.

먼저 문제를 분류하라

기술적 장애, 요청 오류, 추가 인증 요구, 거래 제한은 각기 다른 대응이 필요합니다. HTTP 코드만으로 비즈니스 결과를 항상 알 수 있는 것은 아닙니다. 예를 들어 Stripe는 500 응답을 받은 작업의 결과를 미확정으로 간주하라고 권장합니다. 새 키로 다시 시도하기 전에 원래 요청이 어떻게 되었는지 확인해야 합니다. 오류 응답이 금전적 효과가 없었다는 증거는 아닙니다.

운영자의 조치는 세 그룹으로 나누면 편리합니다. 아직 전송되지 않은 신규 거래는 허용된 예비 경로로 보낼지 평가할 수 있습니다. 이미 전송되었지만 결과를 모르는 거래는 격리하고 대사해야 합니다. 확인된 거절은 그 사유와 해당 결제수단의 규칙에 따라 분석해야 합니다. 당직자가 본질적으로 다른 문제를 버튼 하나로 해결하려 하지 않도록 이 그룹들을 대시보드에서 따로 보여 주는 것이 좋습니다.

예비 경로는 미리 준비되어 있어야 한다

장애가 나기 전에 경로마다 명세서를 작성하십시오. 법인, 연결된 계정, 허용된 거래 유형, 결제수단, 통화, 지역, 금액 한도, 환불 절차, 지원 연락처입니다. 어떤 고객 동의와 점검이 의무인지도 확인하십시오. 예비 경로가 아직 연결되지 않았거나 그 조건이 특정 거래에 맞지 않는다면 사용할 수 없는 것으로 간주하십시오.

상품 결제, 계좌 이체, P2P 플랫폼 참여자에 대한 지급 사이의 차이는 특히 주의 깊게 확인하십시오. 사용자 화면이 비슷하다고 해서 이 작업들을 서로 바꿔 쓸 수 있는 것은 아닙니다. 경로를 통과시키려고 거래의 목적, 수취인, 판매자 정보를 바꾸지 마십시오. 적합하고 허용된 대안이 없다면 정직하게 일시 중지하는 편이 즉흥적인 대응보다 안전합니다.

Adyen의 거절 사유 레퍼런스는 카드 발급사 장애, 인증 오류, 사기 의심, 금지된 거래를 구분합니다. '거절되면 무조건 다음 경로로'라는 단일 규칙이 왜 너무 거친지를 보여 주는 구체적인 예입니다. 예비 경로가 AML/KYC 요건, 제재 제한, 부정거래 방지 장치, 거래 불허 결정을 우회해서는 안 됩니다. 판단이 애매한 사유는 책임 있는 전문가에게 넘기십시오.

복구 중 부하를 제한하라

전환한다고 예비 채널의 한도가 사라지지는 않습니다. 신규 트래픽의 최대 비율, 허용 가능한 대기열, 중단 조건을 정하십시오. 값은 계약상 한도와 합의된 용량 테스트 결과를 근거로 고릅니다. 먼저 허용된 신규 거래 중 제한된 양만 옮기고, 결과를 본 뒤에야 부하를 늘리십시오.

AWS는 재시도가 어떻게 과부하를 키우는지 설명하며, 점점 늘어나는 간격에 지터(jitter)라고 부르는 약간의 무작위 편차를 더하는 것이 왜 유용한지 보여 줍니다. 결제 서비스에서는 이것이 대기열 전체를 동시에 일괄 재시도하지 말아야 하는 근거가 됩니다. 재시도를 관리하는 곳을 한 군데로 정하고, SDK가 눈에 띄지 않는 자체 재시도를 추가하지 않는지 확인하십시오.

주 경로로의 복귀에도 통제가 필요합니다. 누가 복귀를 승인하는지, 어떤 복구 신호가 필요한지, 다시 전환되는 것을 어떻게 막는지 기록하십시오. A와 B의 공통 의존성도 파악하십시오. 계약이 두 개라고 해서 인프라가 독립적이라는 증거는 되지 않습니다. 외부 상태 페이지의 녹색 표시만 보지 말고 내부 지표와 함께 가용성을 판단하십시오.

예비 경로의 비용은 전환 후에 드러난다

제안하는 점검에서는 예비 경로를 전체 수명 주기에 걸쳐 평가합니다. 이전 거래의 환불은 누가 처리하는가? 구매자가 주문 번호만 알고 있을 때 고객 지원팀은 어떻게 경로를 찾는가? 늦게 도착한 결제는 어느 대사에 들어가는가? 이 답들이 엔지니어 한 명의 기억에 달려 있다면, 두 번째 PSP는 연동을 하나 늘릴 뿐 관리 가능한 복원력을 주지는 못합니다.

시도마다 경로, 계정, 라우팅 규칙 버전을 미리 저장해 두십시오. 주문 하나에 여러 시도가 있을 수 있지만, 각 시도의 금전적 효과는 구분 가능해야 합니다. 리포트에서는 최초 경로와 최종적으로 확인된 결제의 경로를 나누십시오. 그렇지 않으면 장애 후 팀이 서로 다른 구매자 그룹을 비교하고, 개선 효과를 잘못 PG사의 품질 덕분으로 돌리게 됩니다.

주 경로로의 복귀도 하나의 릴리스다

복구 후 테스트 요청 하나가 성공했다고 전체 트래픽을 열지 마십시오. 허용된 신규 거래로 제한된 점검을 하고, 지연과 승인 확인을 평가한 뒤, 미리 정한 조건에 따라 트래픽을 넓히십시오. 구체적인 비율과 시간은 부하에 따라 다릅니다. 모든 서비스에 통하는 '5분간 오류 없음' 같은 기준은 없습니다.

사람이 복구를 진행하는 동안 자동 전환 장치를 어떻게 할지도 따로 합의하십시오. 두 메커니즘이 동시에 경로를 바꾸면 트래픽이 진동하고 실험 결과를 읽을 수 없게 됩니다. 의사결정 로그는 현재 누가 라우팅을 통제하는지 보여 줘야 합니다. 팀이 예비 경로로 넘어갈 수 있고, 다시 돌아올 수 있으며, 남은 결과 미확정 결제 목록을 정리할 수 있을 때 훈련이 성공한 것입니다.

훈련 보고서에는 세 가지 숫자를 남기십시오. 예비 경로로 처리된 신규 거래, 결과가 확인되지 않은 이전 거래, 확인된 중복 금전 효과입니다. 승인율이 높더라도 두 번째 숫자에는 담당자가 필요하고, 세 번째 숫자가 0이 아니라면 원인 분석이 필요합니다.