channel_products.channel_product_id 를 저장하는 코드에 문제가 있어 몇백 건이 비어 있었다. 상대 응답 형식이 바뀌면서 식별자가 data.id 에서 data.product.id 로 갔는데 코드가 그것을 못 읽고 NULL 을 저장하고 있었다.
Table of contents
Open Table of contents
증상 — 등록됐는데 모르는 상태
세어 보니 수백 건이 등록은 됐는데 channel_product_id 가 없었다. 식별자가 없으니 다시 등록하면 중복 등록이 된다.
상대 쪽에는 있고 우리 쪽에만 없는 상태였다. 두 가지 방법이 있었는데 전부 다시 등록하는 것과 우리 상품 코드로 상대에게 물어 식별자를 되찾는 것이다. 뒤쪽을 골랐다. 이유는 다시 등록하면 상대 쪽에 같은 상품이 둘이 돼서다. 대신 조회 결과가 하나가 아닌 경우를 따로 다뤄야 하는 것을 감수했다.
조치 — 조회 결과의 세 갈래
GET /products?seller_code= 로 상대를 조회하니 식별자가 나왔다. 다만 결과가 하나로 나오는지를 확인해야 했다.
결과가 하나면 복원하고 없으면 등록이 필요한 것으로 표시하며 여럿이면 사람이 봐야 하는 것으로 갈랐다. 복원이 대부분이고 없는 것이 십여 건이며 모호한 것이 몇 건이었는데 여럿 매칭은 전에 중복 등록된 것이라 자동으로 고르면 틀린 식별자를 넣게 된다.
원인 — 없는 것의 재등록과 원인 수정
상대에 없는 십여 건은 등록이 실패했는데 우리가 성공으로 본 것이었다. 다시 등록하면서 이번에는 응답을 두 형태 다 읽게 하고 그래도 식별자가 없으면 실패로 처리하게 했다.
원인 수정이 여기 있었다. 값이 없을 때 조용히 NULL 을 넣는 대신 MissingIdException 을 던지게 하면 다음에 형식이 바뀌어도 바로 알 수 있다. 응답 원본도 로그에 남겨서 형식이 바뀌었을 때 확인할 수 있게 했다.
검증 — 스크립트와 정기 대조
같은 일이 또 생길 수 있으므로 복원을 restore:channel-ids 커맨드로 만들어 두고 --dry-run 을 먼저 돌린 뒤 실행했다. 몇 건이 어떻게 되는지를 보고 진행하는 순서다.
등록됐는데 channel_product_id IS NULL 인 건수를 매일 세게 하고 0이 아니면 알리게 했다. 한 번 고치고 끝내지 않고 다시 생기는지를 보는 것이 원인 수정의 검증이다.
주의 — 되찾을 수 없는 값
식별자는 상대가 갖고 있어서 되찾았지만 우리만 갖고 있던 값은 못 되찾았다. 등록 시각은 상대 응답에 있어서 대략 맞췄고 등록 요청 내용은 어디에도 없었다.
그 뒤로는 요청도 응답과 함께 남기게 했는데 응답만 남기면 무엇을 보냈는지 알 수 없기 때문이다. 무엇이 어디에 있는지를 미리 알아 두면 잃었을 때 되찾을 수 있는지가 바로 갈린다.
정리
- 우리가 잃은 값을 상대가 갖고 있을 수 있다
- 우리 쪽 코드로 조회해 되찾는다
- 결과가 하나인지 없는지 여럿인지 나눈다
- 여럿이면 자동으로 고르지 않고 사람이 본다
- 없는 것은 다시 등록하되 원인을 고치고 한다
- 값이 없으면 조용히
NULL을 넣지 말고 실패로 만든다 - 요청과 응답 원본을 함께 남긴다
- 다시 생기는지 정기적으로 센다