서버가 예기치 못한 사유로 종료되는 경우, order-manager에서는 어떠한 대응을 해야하는지 체크가 필요하다.
서버가 갑자기 종료된 경우
참고 : #62
Rainforest API
검증 단계에서 서버 종료 시
주문의 상태 변경이 없었으므로, 검증 중이던 주문은 서버를 다시 시작한 후 재검증 하면 된다.
Zinc API
쿠팡 주문 [상품준비중]으로 변경 중
쿠팡 주문은 [상품준비중]이 되었으나 order는 영속성을 갖지 않은 상태가 될 경우
slack message를 전송하도록 한다.
복구 방안 : controller 단에서 orderId의 값을 받아, 해당 orderId에 해당하는 쿠팡 주문 정보, hwasProduct 정보를 받아와 영속성을 부여하는 기능 추가로 완전한 복구 가능
현재 order-manager 서비스 단에서 영속성 order의 상태 변경이 이뤄지면 변경 이후 즉시 current_status 를 변경하고 있다.
만약 order의 변경이 이뤄졌으나, 그 다음줄의 코드(order의 current_status 변경)가 실행되기 전에 서버가 종료된다면,
모든 단계에 대한 복구 방안 코드를 작성해야할 것으로 판단된다.
Purchase Agency 주문/취소 요청 중
주문/취소 요청 후 반환되는 Request Id를 받자마자 서버가 종료되었다면, 해당 Request Id는 유실되는 것이므로 복구가 어렵다.
Zinc에서 시간 별로 요청받은 내역을 조회하는 기능은 존재한다.
서버 종료 시간을 명확히 인지하고 적절한 시간 텀에 이뤄진 요청 정보를 조회해온 후, order_sheet table에 존재하는 purchase_agency_request_id 혹은 cancelled_order table의 purchase_agency_cancel_id와 하나하나 대조해본 후, 그 어디에도 매치되지 않는 Request Id가 서버 종료 시에 이뤄진 요청의 응답으로 판단하고, 해당 Request Id로 주문의 상태를 조회해, 해당 주문이 어떤 order에 매치될지 판단해야한다.
Request Id로 받아온 주문의 상품 ASIN / 가격 등으로 order를 유추해야한다.
ASIN 과 가격 정보만 들어가기 때문에, 부합하는 order는 다수 일 수 있다. (소비자 특정 불가)
Purchase Agency 주문/취소 확인 중
주문/취소 확인 중 서버 종료는 아무런 문제가 되지 않는다.
서버가 재시작하면 scheduled job에 의해 주문/취소 확인을 재시도한다.
Source 환불 요청 확인 중
환불 요청 확인 중 서버 종료는 아무런 문제가 되지 않는다.
서버가 재시작하면 scheduled job에 의해 환불 요청 확인을 재시도한다.
Ohmyzip API
배대지 신청 중
배대지 신청 전 서버 종료 : 서버 재시작 후 다시 배대지 신청하게 되므로 아무런 문제가 되지 않는다.
배대지 신청 후(order의 current_status 변경 전) 서버 종료
서버 재시작 후 다시 배대지를 신청하게 된다.
이미 신청된 배대지는 추후 오마이집에서 정보 미기입으로 카톡 수신하게 된다. (비용 X)
카톡 확인 후 배대지 신청서 삭제
Source 송장 업로드 중
위의 배대지 신청 후 서버 종료 와 동일하다.
동일한 송장 번호로 Source 송장 업로드 재시도 시, NOT_ALLOW_INVOICE_NUMBER_RE_UPLOAD라는 resultCode를 받게 되는데 retry unnecessary라고 한다.
International Courier 정보 요청 중
International Courier 정보 요청 중 서버 종료는 아무런 문제가 되지 않는다.
서버가 재시작하면 scheduled job에 의해 정보 요청을 재시도한다.
배대지 송장 업로드 중
오마이집에 송장 번호 업로드 재시도 시 문제가 되지 않으므로, 서버 종료는 아무런 문제가 되지 않는다.
배대지 상태 확인 요청 중
상태확인은 scheduled job에 의해 지속적으로 이루어지는 것이므로, 서버 종료는 아무런 문제가 되지 않는다.
서버 종료 상태 확인
예기치 못한 서버 종료에 대한 대응을 하기 위해서는 서버의 동작 유무를 파악하고 있어야한다.
예기치 못한 서버 종료 시 대응 시나리오 (order-manager)
개요
서버가 갑자기 종료된 경우
Rainforest API
Zinc API
order
는 영속성을 갖지 않은 상태가 될 경우orderId
의 값을 받아, 해당orderId
에 해당하는쿠팡 주문 정보
,hwasProduct 정보
를 받아와 영속성을 부여하는 기능 추가로 완전한 복구 가능order
의 상태 변경이 이뤄지면 변경 이후 즉시current_status
를 변경하고 있다.order
의current_status
변경)가 실행되기 전에 서버가 종료된다면,Request Id
를 받자마자 서버가 종료되었다면, 해당 Request Id는 유실되는 것이므로 복구가 어렵다.order_sheet table
에 존재하는purchase_agency_request_id
혹은cancelled_order table
의purchase_agency_cancel_id
와 하나하나 대조해본 후, 그 어디에도 매치되지 않는Request Id
가 서버 종료 시에 이뤄진 요청의 응답으로 판단하고, 해당Request Id
로 주문의 상태를 조회해, 해당 주문이 어떤order
에 매치될지 판단해야한다.Request Id
로 받아온 주문의 상품 ASIN / 가격 등으로order
를 유추해야한다.order
는 다수 일 수 있다. (소비자 특정 불가)Ohmyzip API
order
의current_status
변경 전) 서버 종료배대지 신청 후 서버 종료
와 동일하다.NOT_ALLOW_INVOICE_NUMBER_RE_UPLOAD
라는 resultCode를 받게 되는데 retry unnecessary라고 한다.서버 종료 상태 확인