Sync 기능 추가

SyncIssue drawio

개요

쿠팡에 등록된 상품의 정보는 아마존에서 가져오는 것이기 때문에 시간이 지남에 따라 재고/수량/환율의 변동이 생길 수 있다.
- 아마존 → DB → 쿠팡 Sync를 맞춰줘야 한다.
쿠팡에서 구매가 발생하면 db를 통해 해당 상품의 정보를 가져오게 된다.
- 쿠팡 → DB Sync를 맞춰줘야 한다.

현황 파악

쿠팡 → DB

현재 구현은 쿠팡 → DB sync의 일부만 되어있다.

구현

DB의 status=TBD인 엔티티 조회
각 엔티티의 productId로 쿠팡 상품 상태 조회
상품 상태가 승인완료라면 status=ON으로 업데이트
- 승인반려, 상품삭제라면 status=OFF
- 그 외라면 status=TBD

일부라고 표현한 이유

쿠팡에만 존재하는 상품인 경우가 확인되지 않는다.
- 쿠팡에서는 판매가 되었으나 DB 상에 존재하지 않는 상품이기 때문에 주문 프로세스를 진행할 수 없다.
승인완료라도 판매중지 상태가 존재한다.
- DB의 status=ON이더라도 쿠팡에서 판매하고 있지 않은 경우가 있으므로 sync가 맞을 수 없다.

승인완료라도 판매중지 상태 존재

승인완료라도 판매중지 상태가 존재하는 이유

PM을 경유해 deleteProduct 수행 시: 참고 : [상품삭제 하려면 판매중지 상태여야 한다.]
- vendorItemId가 존재하면
  - 판매중지 요청 API 호출 → 상품삭제 요청 API 호출 → 성공유무에 따라 ApiException 발생
    - 예외 발생 시, 다음 로직이 수행되지 않아 DB 상에도 status=OFF가 반영되지 않는다.
  - 판매중지 요청은 성공했으나 상품삭제 요청에 실패한 경우 발생
- vendorItemId가 존재하지 않으면
  - 상품삭제 요청 API 호출 → ApiException 발생
판매중지 요청과 상품삭제 요청이 트랜잭션 단위로 수행되어야 해당 문제가 발생하지 않게 된다.

개선안

아마존 → DB → 쿠팡

가장 먼저, 해당 sync를 수행하기 위해서는 쿠팡 → DB sync가 전제되어야 한다.
쿠팡 → DB sync가 완료된 경우,
1. DB의 status=ON인 엔티티를 가져오도록 한다.
2. 해당 엔티티의 source_id(ASIN)로 rainforest에서 가격/수량 정보를 받아온다.
3. 해당 정보를 토대로 가격을 재책정하고 DB에 업데이트한다.

문제점

너무 긴 시간 소요

쿠팡의 경우만 상정하더라도, 상품이 모두 등록된 경우 10,000개
- Rainforest API 호출 시간은 약 30초
- 한 상품 정보를 업데이트하는데 30초가 걸린다고 예상하더라도
- 총 소요 시간: 약 83시간

해결 방안

스레드풀 사용

스레드풀 사용을 통해 소요 시간을 절감한다.

쿠팡 → DB

쿠팡에서 제공하는 API 중, 쿠팡에 등록된 상품 목록을 가져오는 API는 존재하지 않는다.
- findAll()이 부재한 뉘앙스로, productId 등의 특정 정보에 대해서만 조회가 가능하다.
쿠팡 wing에서 직접 지정한 상품 목록(전체도 가능)의 엑셀 파일을 다운 받는 것이 가능하다.
1. 쿠팡 wing에서 조회하고 싶은 상품 상태를 지정한다.
2. 엑셀 파일 다운 요청을 한다. - [요청 - 승인 - 다운]까지 약 30초 소요
3. 다운 받은 엑셀 파일의 특정 row(예 - productId) 정보로 DB에 존재하는지, 존재한다면 status가 올바른지 대조 및 업데이트한다.
4. DB에 존재하지 않는 상품에 대해서는 슬랙 알람을 보내게 하고, 삭제처리 한다.

문제점

WebCrawler 사용

현재로서는 엑셀을 활용한 방안만이 쿠팡 → DB sync를 수행할 수 있는 방법이라고 판단된다.
그렇다면 두 가지 방식으로 이를 해결할 수 있다.
1. 매번 파일을 로컬 환경 등의 외부 환경에서 직접 다운 받아 서버로 넘겨주고 트리거하거나,
2. WebCrawler를 통해 wing에 접근해 해당 로직을 수행하도록 할 수 있다.
전자의 방법 장단점
- 장점: 파일을 다운 받아 서버로 넘겨주는 방식 자체는 단순하다.
- 단점: 자동화와는 거리가 있다.
후자의 방법 장단점
- 장점: 자동화가 되어 HWAS 취지에 더 부합하게 된다.
- 단점: 과거 PA에서의 이슈와 같이, webcrawler를 사용했을 때 발생하는 문제점들을 감수하고 사용해야 한다.

해결 방안

논의 필요

다른 방식으로 쿠팡 → DB sync 방법은 없는지, 혹은 문제점.WebCrawler 사용에서 제시한 방안 외 다른 방안이 있는지, 없다면 어떤 방식을 채택하는 것이 합리적인 선택일지 논의 필요

코멘트 작성자: kingwaggs

아래 이해가 잘 안되는 내용 질문드립니다.

승인완료라도 판매중지 상태가 존재하는 이유

쿠팡에서 특정 상품에 대한 상태를 승인완료 이자 판매중지 인 상태를 허용하나요? 둘 중 하나만 유효한게 아닌가요? ({승인완료} && {판매중지}) DB 기준 destinationID 로 쿠팡 API 사용해서 상태 조회시에 두 상태가 모두 조회되는지 확인이 필요할 것 같습니다.

엑셀을 활용한 방안만이 쿠팡 → DB sync를 수행할 수 있는 방법이라고 판단된다

findAll() 과 같은 API 가 부재한 상황이라고 말씀 주셨는데요, 쿠팡의 상품 목록 페이징 조회 를 사용해서 여러 리소스적인 측면을 고려해서 페이징 값 넣어 받아와서 쿠팡 -> DB 간 sync 에 사용할 수 있는것 아닌가요? 그 외 구간 조회 방법도 있는것 같은데.. 이건 생성일 기준 조회인데 최대 10분 텀이라 사용에는 좀 제약이 있을것 같습니다.

만약 말씀주신 엑셀 이 최선의 방안이라면 크롤링보단 엑셀 방식을 선택하는게 맞을것 같습니다.

제가 생각했던 sync 시나리오를 말씀드려보겠습니다.

아래 두 작업은 동기 로 처리됩니다. 즉, 1 이 수행된 뒤 2가 수행됩니다.

Amazon -> DB (단방향)
DB <-> Coupang (양방향)

1. Amazon -> DB 단방향 sync

DB 상 존재하는 상품들에 대해 Rainforest 를 사용해 상품 상세 정보를 최신화
DB 의 SourceId 로 Rainforest 에 요청을 보낸 뒤 응답을 가지고 DB 의 값을 갱신하면 될 것 같습니다
말씀주신대로 스레드를 사용해서 처리하면 시간을 줄일 수 있을것 같네요.
이 때는 API 호출에 사용할 RestTemplate 의 동시성 이슈를 잘 파악하시고 사용해야 할 것 같습니다. (공유해서 사용해도 멀티 스레드 환경에서 병렬 처리가 가능한지 등)

2. DB <-> Coupang 양방향 sync

1 의 작업이 완료되었다면 DB 의 값은 최신화가 되어있을 것입니다.
DB -> Coupang 의 경우
- 최신화된 값을 바탕으로 "상품 수정" 을 하면 될 것 같습니다. 이 때,
- DB 엔 존재하지만 쿠팡엔 없는 상품 : DB 에서 해당 row 삭제
- DB 의 상품 상태와 쿠팡의 상품 상태가 다른 경우(쿠팡에서 판매중 이 아닌 경우) : DB의 상태 변경, "상품 수정" 하지 않음
- 그 외 : DB 의 값으로 "상품 수정"
Coupang -> DB 의 경우
- 쿠팡에 등록된 상품이지만 DB 엔 없는 경우 (이번 판매 이슈에 해당하겠네요) : 쿠팡에서 해당 상품 삭제
- 위 1 케이스밖에 존재하지 않을것 같습니다.

이 1, 2번 작업이면 sync 를 모두 맞출 수 있을것 같습니다만.. 어떻게 생각하실까요? 제가 포함하지 못한 경우의 수가 존재한다거나, 예상되는 예외상황들을 의견 부탁드릴게요

@kingwaggs 윤성님 추가 코멘트 드립니다.

쿠팡에서 특정 상품에 대한 상태를 승인완료 이자 판매중지 인 상태를 허용하나요? 둘 중 하나만 유효한게 아닌가요? ({승인완료} && {판매중지})

네 허용합니다. 이 이후의 논의들도 이 부분을 먼저 염두하고 진행되어야할거 같습니다. 이해를 돕기 위해 위에 붙여넣었던 사진에 해당하는 상품을 wing에서 보았을 때 사진도 첨부할게요!

음..상태 값 조회는 동일한 메세지만 뜨는군요... comment에 false 단어가 포함되어 있는지를 확인하는 것으로 판별이 가능할거 같기는 한데, comment에 어떤 추가 케이스가 존재할지 몰라 애매하기는 하겠군요.

{
    nextToken: 
    message: 
    data: [class OSellerProductStatusHistory {
        statusName: 승인완료
        createdBy: 와이더블유에프커머스(YWF Commerce)
        createdAt: 2022-11-23T15:14:56
        comment: '빈티지 스타일 핸드헬드 머메이드 배니티 미러 콜드캐스트 레진 앤티크 브론즈 마감' 아이템의 판매상태(이)가 'false' (으)로 변경되었습니다.
    }, class OSellerProductStatusHistory {
        statusName: 승인완료
        createdBy: 쿠팡 셀러 시스템
        createdAt: 2022-11-14T10:02:18
        comment: 승인완료
    }, class OSellerProductStatusHistory {
        statusName: 승인대기중
        createdBy: 와이더블유에프커머스(YWF Commerce)
        createdAt: 2022-11-14T10:02:14
        comment: 판매자(A00536509) 승인 요청 후 대기중
    }, class OSellerProductStatusHistory {
        statusName: 임시저장
        createdBy: 와이더블유에프커머스(YWF Commerce)
        createdAt: 2022-11-14T10:02:14
        comment: 판매자(A00536509) 임시저장
    }]
    code: SUCCESS
}

쿠팡의 상품 목록 페이징 조회 를 사용해서 여러 리소스적인 측면을 고려해서 페이징 값 넣어 받아와서 쿠팡 -> DB 간 sync 에 사용할 수 있는것 아닌가요?

param 값들에 null을 설정하고서, 이전에 sdk를 탑재한 버전에서 실행했을 때 null 관련 오류가 나면서 안되었었는데, 윤성님 코멘트보고 혹시나해서 직접 코드 이식해서 실행해보니 잘 작동하네요!! 하,, 이 부분은 엑셀도 필요없이 해당 API 사용하면 될거 같네요 ㅠㅠ 다행입니다...

Amazon -> DB (단방향)

네 해당 내용들 파악했습니다. 동감입니다.

DB <-> Coupang (양방향)

여기서 궁금한 부분이 있습니다.

DB -> Coupang 의 경우 DB 엔 존재하지만 쿠팡엔 없는 상품 : DB 에서 해당 row 삭제

쿠팡에 없는 상품이라면, 쿠팡 측에서 삭제했거나 우리가 특정 사유로 삭제했을 거라고 생각됩니다. 근데 DB에서 삭제하게 된다면, 추후 문제의 상품이 다시 소싱될 우려가 있을거 같은데요. DB에 status=OFF 를 시켜두는 것으로 처리하는게 낫지 않을까 생각됩니다!

DB -> Coupang 의 경우 DB 의 상품 상태와 쿠팡의 상품 상태가 다른 경우(쿠팡에서 판매중 이 아닌 경우) : DB의 상태 변경, "상품 수정" 하지 않음

사소한 차이이기는 하지만, 작업 순서 관련 내용으로도 확장될 여지가 있어서 질문드리면, (위도 동일합니다.) DB의 상태는 변경하고 쿠팡의 상품 수정은 하지 않는다면, Coupang -> DB 방향이 아닌가요? 변경되지 않을 것[Coupang]을 기준으로, DB를 변경해서요! ㅎㅎㅎ계속 이 부분만 생각하다보니 저도 복잡해져서요 ㅎㅎ

쿠팡에 등록은 되어 있지만 판매중이지 않은 상품에 대해 이야기 드리면, [현재] 파악된 바로는 아래의 두 가지 경우입니다.

[승인완료]가 아닌 상태: 쿠팡 측에서 특정 사유로 승인을 반려했거나 승인 pending 중이라 판매 중이지 않음
- 만약 pending인 경우: 늦어도 1일 이내에 pending이 끝나게 된다.
[승인완료]인 상태: deleteProduct 를 하기 위해 구매중지만 수행되고, 상품삭제는 수행되지 않은 상태

쿠팡에 상품을 등록하면 모두가 바로 승인되는 것이 아니라, 임시저장/심사중/승인대기 등의 여러 상태가 존재합니다. 그렇기 때문에 DB에서는 쿠팡에 상품을 등록하는 시점에는 status=TBD로 두고 계신거로 이해했는데요. 여기서 문제가 발생 여지가 존재합니다.

[승인완료]가 아닌 상태 중 pending 등의 상태로, 추후 상품이 정상 등록(승인완료)될 잠재가 있는 상품이 존재하는 것입니다. 만약 pending 상태인데 DB 상태를 변경해버리면, 추후 정상 등록되는 상품의 경우, DB와 sync가 맞지 않게 됩니다. (DB는 status=OFF로 변경된 상태)

DB의 상품 상태와 쿠팡의 상품 상태 비교를 아래와 같이 한다면 문제는 해결될 것으로 보입니다.

status=TBD = 임시저장/심사중/승인대기
status=ON = 승인완료 && 판매중
status=OFF = Else(나머지 쿠팡 상품 상태 값) || !판매중

이 1, 2번 작업이면 sync 를 모두 맞출 수 있을것 같습니다만.. 어떻게 생각하실까요?

위의 참고사항 정도를 제외하면, 공감합니다 ㅎㅎ 사실 말씀해주신

Amazon -> DB (단방향) DB <-> Coupang (양방향)

부분이, 제가 제안한

Amazon -> DB -> Coupang Coupang -> DB

와 유사하다고 생각되어서 공감합니다 ㅎㅎ

단지, 조금 의견이 다른 부분은, 윤성님은 1이 수행된 뒤 2를 수행하는 방안을 제시해주셨는데, 저는 2를 수행하고 1을 하는게 나을거 같다고 생각이 되어 공유드립니다. 1을 먼저하게 되면, 현재 쿠팡에 실제로 판매 중이지 않은 상품에 대해서도 (= 재고/가격 정보 업데이트가 필요없는 상품) rainforest api를 사용하는 resource를 할당해야 합니다. 만약 2를 먼저 수행해서, 실제로 쿠팡에서 판매 중이지 않은 상품을 조금이라도 줄일 수 있다면 resource를 경제적으로 활용할 수 있지 않을까 생각이 듭니다!

코멘트 작성자: kingwaggs

> 음..상태 값 조회는 동일한 메세지만 뜨는군요... comment에 false 단어가 포함되어 있는지를 확인하는 것으로 판별이 가능할거 같기는 한데, comment에 어떤 추가 케이스가 존재할지 몰라 애매하기는 하겠군요.

우선 확인된 케이스는 "false" 로 판단하고 있는듯 하니.. ({승인완료} && {판매중지}) 상태에 대해서는 comment false 를 파악하여 sync 기능의 일부로 추가하는것으로 결정하시죠. 이후에 다른 케이스가 존재하면 그때 또 추가하는거로 가야할 것 같습니다.

윤성님 코멘트보고 혹시나해서 직접 코드 이식해서 실행해보니 잘 작동하네요!!

넵 다행입니다~ 이부분은 Coupang -> DB 의 sync (상태값) 에만 사용될 API 일테니, 상세 정보(등록된 상품의 가격, 상품명, 상세 설명 등)가 응답으로 돌아오지 않더라도 상관없겠죠?

DB에 status=OFF 를 시켜두는 것으로 처리하는게 낫지 않을까 생각됩니다!

넵 그것도 좋습니다만.. 제가 위와같이(DB row 삭제) 생각했던 이유는 wing 의 상품 개수와 DB 의 상품 개수(SELECT count(*) FROM product) 가 같아야 된다고 생각했기 때문입니다. 근데 다시 생각해보니 굳이 같아야 할 이유는 없겠네요. DB 의 개수가 더 많은게 오히려 더 자연스러운 그림으로 생각되기도 합니다. status OFF 변경하는것이 더 좋은 선택이 될 것 같습니다.

DB의 상태는 변경하고 쿠팡의 상품 수정은 하지 않는다면, Coupang -> DB 방향이 아닌가요? 변경되지 않을 것[Coupang]을 기준으로, DB를 변경해서요!

음.. 이 경우는 모든 예외에 대응하기 위해 고려한 경우의 수 입니다. DB 에는 존재하고 쿠팡에는 등록되지 않은 상품이 있을 수 있을것 같습니다. (구현상 그렇지 않을것이라 판단되더라도 예외시 대응이 가능해야할 것 같습니다) 따라서 DB -> Coupang 이라 표현하였고 이전 코멘트 드린 내용상 1번이 선행된다면 DB 의 데이터가 최신화(가격, 수량 등) 되어있을 것입니다. 따라서 DB 의 데이터를 Coupang 에 "갱신" 해줘야 하기 때문에 DB -> Coupang 이라 표현하였습니다.

[승인완료]가 아닌 상태 중 pending 등의 상태로, 추후 상품이 정상 등록(승인완료)될 잠재가 있는 상품이 존재하는 것입니다. 만약 pending 상태인데 DB 상태를 변경해버리면, 추후 정상 등록되는 상품의 경우, DB와 sync가 맞지 않게 됩니다. (DB는 status=OFF로 변경된 상태)

이건 DB status = TBD 인 상품에 대해서 sync 작업을 돌리면 되는것 아닐까요? 아마 지금 구현에도 포함이 되어있는 것 같은데요, DB status = TBD 상품에 대해 sync 를 수행할 때, 쿠팡에서 pending 상태(임시저장/심사중/승인대기 등)인 경우 계속 TBD 로 남아있게 하면 될 것 같습니다. 그러면 다음 sync 배치에 또 상태값을 체크하고 정상 변경될 것 같습니다. 혹시 제가 질문주신 내용을 잘못 이해한 것일까요?

DB의 상품 상태와 쿠팡의 상품 상태 비교를 아래와 같이 한다면 문제는 해결될 것으로 보입니다.

넵 제시해주신 내용은 이견 없습니다. 그렇게 반영하면 될 것 같습니다. (만약 추후 다른 이슈가 발생한다면 그때 또 업데이트 하면 될 것 같습니다)

단지, 조금 의견이 다른 부분은, 윤성님은 1이 수행된 뒤 2를 수행하는 방안을 제시해주셨는데, 저는 2를 수행하고 1을 하는게 나을거 같다고 생각이 되어 공유드립니다. 1을 먼저하게 되면, 현재 쿠팡에 실제로 판매 중이지 않은 상품에 대해서도 (= 재고/가격 정보 업데이트가 필요없는 상품) rainforest api를 사용하는 resource를 할당해야 합니다. 만약 2를 먼저 수행해서, 실제로 쿠팡에서 판매 중이지 않은 상품을 조금이라도 줄일 수 있다면 resource를 경제적으로 활용할 수 있지 않을까 생각이 듭니다!

저는 이 부분에 대해서 다른 생각입니다. 절차의 장단을 비교해보면

2->1 로 수행하게 될 경우, 쿠팡에서 먼저 상태를 동기화 하기 때문에 Rainforest 의 credit saving 의 장점이 있겠습니다.
1->2 로 수행하게 될 경우, 최신화 된 상품(가격, 재고 등)을 바탕으로 쿠팡에 업데이트 하게 될 테니 가격이나 재고이슈로 판매 취소를 해야하는 경우를 줄일 수 있을것 같습니다.

저는 위 케이스에서 1->2 가 저희의 이익 창출에 더 도움이 될 것이라 생각하였습니다. credit 은 시간이 지나 1만개의 상품을 모두 적용하게 된다면.. 충분할 것이라 생각됩니다. 만약 부족하다면 투자를 늘리면 되겠죠 ㅎㅎ (대신 그만큼 저희의 수익이 늘어야 할 텐데요 ㅜ)

이정도면 논의가 얼추 정리가 될 것 같습니다. 추가로 이견있으신 사항에 대해 질문주시면 제 의견 답변으로 달겠습니다. 정리된 항목에 대해서는 이 이슈의 코멘트로 기능 목록 도출하여 작업 진행 부탁드릴게요. (혹시나 상웅님께서 도출해주신 기능 목록에 저희가 논의된 내용을 서로 잘못 이해한 내용이 있다면 다시 짚고 넘어가려고 합니다)

넵 다행입니다~ 이부분은 Coupang -> DB 의 sync (상태값) 에만 사용될 API 일테니, 상세 정보(등록된 상품의 가격, 상품명, 상세 설명 등)가 응답으로 돌아오지 않더라도 상관없겠죠?

네 그렇다고 생각합니다 ㅎㅎ

넵 그것도 좋습니다만.. 제가 위와같이(DB row 삭제) 생각했던 이유는 wing 의 상품 개수와 DB 의 상품 개수(SELECT count(*) FROM product) 가 같아야 된다고 생각했기 때문입니다.

개수 부분도 SELECT count(*) FROM product where status="ON"으로 확인 가능할거 같습니다.

그러면 다음 sync 배치에 또 상태값을 체크하고 정상 변경될 것 같습니다. 혹시 제가 질문주신 내용을 잘못 이해한 것일까요?

아닙니다 맞습니다!

저는 위 케이스에서 1->2 가 저희의 이익 창출에 더 도움이 될 것이라 생각하였습니다.

아..! 취지를 이해했습니다 ㅎㅎ. 제가 2 -> 1 로 생각했던 이유가 시간 문제였었습니다.

1. DB <-> 쿠팡 : 수분 내에 동기화가 완료될 것으로 생각
1. Amazon -> DB : 수 시간 소요 예상

정리된 항목에 대해서는 이 이슈의 코멘트로 기능 목록 도출하여 작업 진행 부탁드릴게요.

네 알겠습니다.

코멘트 작성자: kingwaggs

> 제가 2 -> 1 로 생각했던 이유가 시간 문제였었습니다. DB <-> 쿠팡 : 수분 내에 동기화가 완료될 것으로 생각 Amazon -> DB : 수 시간 소요 예상

그러게요 이 부분이 조금 고민되긴 합니다만.. 그렇다 하더라도 1->2 로 방향은 설정하는게 좋을 것 같습니다. 대신 소요 시간을 줄이는 이슈를 같이 또 고민해보시는걸로 하시죠 비슷한 이유로 PA 에서 아이템스카우트를 크롤링으로 긁어올 때 fork join pool 을 사용하고 있습니다. Java 저희 현재 버전에서 제공하는 스레드 풀의 리스트를 한번 보시고, 가장 퍼포먼스가 좋을 구현체를 골라 사용하는걸로 하시죠. 이번에 sync 에서 적용되는 결과를 바탕으로 PA v2 에서도 적용이 가능할 것 같습니다(크롤링을 걷어내고 Http Client 로 병열 요청)

기능목록

PM sync 기능

HWAS 상품의 sync를 맞추도록 한다.
- 아마존 -> DB 의 sync를 맞추도록 한다.
  - DB 상 status=ON || status=TBD 상태인 상품을 조회한다.
  - 해당 상품 정보 중 source_id로 Amazon 실시간 정보를 요청한다.
  - 반환받은 Amazon 정보를 기반으로 수량 / 가격 정보를 DB에 업데이트한다.
- 쿠팡 <-> DB 의 sync를 맞추도록 한다.
  - 아마존 -> DB의 sync를 선행으로 한다.
  - DB -> 쿠팡
    - 최신화된 DB를 기준으로 쿠팡 상품을 업데이트 한다.
      - DB 상 품절 시 상품을 삭제하도록 한다.
    - 승인완료 && 판매중(일반상황)
      - 쿠팡 상품의 수량 / 가격 정보를 업데이트한다.
    - (승인완료 && !판매중) || 임시저장 || 부분승인완료
      - 쿠팡 상품 삭제 요청 및 DB status = OFF로 변경한다.
    - 승인반려 || 상품삭제
      - DB status = OFF로 변경한다.
    - 심사중 || 승인대기중
      - 쿠팡 상품의 수량 / 가격 정보를 업데이트하되, status = TBD로 변경한다.
    - 상태값 변경된 상품 정보, 가격,재고 값 변경된 상품 정보를 알람으로 보내도록 한다.
    - 쿠팡 -> DB
      - 승인완료 상태의 쿠팡 상품을 가져온다.
      - 해당 상품의 productId로 DB에 존재하는 destination_id인지 확인한다.
      - 만약 존재하지 않으면 쿠팡 상품을 삭제하도록 한다.
        
        알람을 보내도록 한다.

그러게요 이 부분이 조금 고민되긴 합니다만.. 그렇다 하더라도 1->2 로 방향은 설정하는게 좋을 것 같습니다. 대신 소요 시간을 줄이는 이슈를 같이 또 고민해보시는걸로 하시죠

네 좋습니다 ㅎㅎ

Java 저희 현재 버전에서 제공하는 스레드 풀의 리스트를 한번 보시고, 가장 퍼포먼스가 좋을 구현체를 골라 사용하는걸로 하시죠. 이번에 sync 에서 적용되는 결과를 바탕으로 PA v2 에서도 적용이 가능할 것 같습니다(크롤링을 걷어내고 Http Client 로 병열 요청)

네 좋습니다. Resttemplate 동시성 문제도 확인해보니 우선은 thread safe하다고 합니다.

코멘트 작성자: kingwaggs

@tonykang22

상웅님 추가로 하나 더 궁금한게 있습니다.

DB의 상품 상태와 쿠팡의 상품 상태 비교를 아래와 같이 한다면 문제는 해결될 것으로 보입니다. status=TBD = 임시저장/심사중/승인대기 status=ON = 승인완료 && 판매중 status=OFF = Else(나머지 쿠팡 상품 상태 값) || !판매중

쿠팡 상품 상태에 "판매중" 이라는 상태가 있는건가요?

상품 상태변경이력 조회 API 에서 판매중 이라는 상태는 안나와 있습니다.

제가 생각했을땐

{
    nextToken: 
    message: 
    data: [class OSellerProductStatusHistory {
        statusName: 승인완료
        createdBy: 와이더블유에프커머스(YWF Commerce)
        createdAt: 2022-11-23T15:14:56
        comment: '빈티지 스타일 핸드헬드 머메이드 배니티 미러 콜드캐스트 레진 앤티크 브론즈 마감' 아이템의 판매상태(이)가 'false' (으)로 변경되었습니다.
    }, class OSellerProductStatusHistory {
        statusName: 승인완료
        createdBy: 쿠팡 셀러 시스템
        createdAt: 2022-11-14T10:02:18
        comment: 승인완료
    },
    ...
    ]
    code: SUCCESS
}

statusName equals "승인완료" && comment equals "승인완료" 를 Status ON 으로 봐야하지 않을까 해서요

@kingwaggs 윤성님,

쿠팡 상품 상태에 "판매중" 이라는 상태가 있는건가요?

없습니다. 앞서 이야기했던 대로 쿠팡 상품 상태변경이력 조회 API의 comment 값을 확인해야합니다.

우선 확인된 케이스는 "false" 로 판단하고 있는듯 하니.. ({승인완료} && {판매중지}) 상태에 대해서는 comment false 를 파악하여 sync 기능의 일부로 추가하는것으로 결정하시죠. 이후에 다른 케이스가 존재하면 그때 또 추가하는거로 가야할 것 같습니다.

위에서는 이렇게 이야기하셨었는데, statusName equals "승인완료" && ! comment contains "false" 이보다는 statusName equals "승인완료" && comment equals "승인완료" 이게 더 낫다고 말씀하시는거죠?

현재 wing에 등록된 상품들의 상태별(statusName) 이력을 확인해보니 구현된 기능 상으로는 둘 다 문제는 없을거 같습니다 ㅎㅎ 그렇다면 아무래도 statusName equals "승인완료" && comment equals "승인완료" 이게 더 이점이 있을거 같네요!

코멘트 작성자: kingwaggs

> 그렇다면 아무래도 statusName equals "승인완료" && comment equals "승인완료" 이게 더 이점이 있을거 같네요!

넵 저도 이게 더 명시적이고 좀 더 포괄적으로 대응할 수 있을 방안이라 생각되네요.

sync 작업에서 상태값이나 가격이 변경된 상품에 대해서는 슬랙 알람으로도 받아볼 수 있도록 되면 좋을것 같습니다.

sync 작업에서 상태값이나 가격이 변경된 상품에 대해서는 슬랙 알람으로도 받아볼 수 있도록 되면 좋을것 같습니다.

네 이 내용도 추가해두겠습니다 ㅎㅎ

참고사항

상품 상태변경 이력

상품 가격 / 수량 수정 시

결론

상품 상태변경 이력 조회 시, comment의 상태완료가 판매 중을 보장하지는 않는다.
첨부한 이미지와 같은 경우가 존재하기 때문에 comment 검증에 참고
- Sync 작업을 수행하면 가격 / 수량은 늘 변동하기 때문이다.

tonykang22 / hello-world-auto-store

[product-manager] Sync 기능 추가 #121

Sync 기능 추가

개요

현황 파악

쿠팡 → DB

구현

일부라고 표현한 이유

승인완료라도 판매중지 상태가 존재하는 이유

개선안

아마존 → DB → 쿠팡

문제점

너무 긴 시간 소요

해결 방안

스레드풀 사용

쿠팡 → DB

문제점

WebCrawler 사용

해결 방안

논의 필요

코멘트 작성자: kingwaggs

1. Amazon -> DB 단방향 sync

2. DB <-> Coupang 양방향 sync

코멘트 작성자: kingwaggs

코멘트 작성자: kingwaggs

기능목록

PM sync 기능

코멘트 작성자: kingwaggs

코멘트 작성자: kingwaggs

참고사항

상품 상태변경 이력

상품 가격 / 수량 수정 시

결론