이미지 quality 설정을 바꾸고 백 건 남짓을 다시 출력하는 작업이었다. resize:product 요청을 보내면 200 이 오는데 정말 다시 만들었는지가 그것으로는 확인되지 않았다.
Table of contents
Open Table of contents
원인 — 두 가지를 뜻하는 성공
시스템에 중복 제거가 있어서 media_files.content_hash 가 같으면 기존 것을 재사용한다. 그러면 요청 하나가 두 갈래로 가는데 해시가 다르면 재연산을 하고 같으면 연산 없이 기존 파일을 쓴다.
두 경우의 응답이 똑같다. 품질 설정만 바꾸고 원본은 그대로면 해시가 같으므로 성공했는데 아무것도 안 바뀐 상태가 된다.
판단 기준 — 시간이 가른 것
두 가지 방법이 있었는데 응답 본문에 reused 플래그를 추가하는 코드 변경을 기다리는 것과 소요 시간으로 가르는 것이다. 뒤쪽을 골랐다. 이유는 백 건 남짓을 지금 돌려야 하는데 배포는 다음 주라서다. 대신 시간이 애매한 건은 media_files 를 직접 조회해 확인하는 수고를 감수했다. content_hash 를 비우고 요청하면 3분 안팎이 걸리고 비우지 않고 재요청하면 1분 내외였다.
세 배에서 다섯 배 차이가 났고 앞쪽이 실제로 리사이즈를 돌린 것이었다. 시간이 유일한 신호였으므로 그 뒤로는 응답이 수십 초 만에 오면 재사용을 의심하게 됐다. 무거운 연산이 실제로 돌았으면 그렇게 빠를 수 없으므로 빠른 것이 좋은 것이 아니라 안 한 것일 수 있다.
조치 — 고정한 절차
건당 절차를 다섯 단계로 고정했다. content_hash 를 NULL 로 비우고 SELECT 로 비워졌는지 확인한 뒤 요청을 보내고 media_files 에 새 행이 생겼는지 조회하며 마지막으로 브라우저에서 렌더를 확인한다.
두 번째 단계가 중요하다. 비우는 조작이 실제로 먹었는지를 확인하지 않으면 요청이 재사용으로 빠진다. 마지막 단계도 필요한데 데이터베이스에 값이 있는 것과 화면에 제대로 나오는 것은 다르기 때문이다.
주의 — 반영 방식이 가른 확인 시점
원본을 바꿨을 때 마켓에 어떻게 반영되는지도 채널마다 달랐다. 마켓 페이지가 우리 CDN 주소를 그대로 쓰는 직접 참조형은 원본을 바꾸면 Cache-Control 만료 후 바로 반영된다.
마켓이 이미지를 가져가 자기 저장소에 올리는 재호스팅형은 원본을 바꿔도 그대로이고 sync:products 를 재전송해야 다시 가져간다. 같은 시점에 전부 확인하면 재호스팅형이 전부 미반영으로 나온다. 그것을 실패로 보면 없는 문제를 쫓게 된다.
성공 응답의 한계
한 채널의 상세 이미지가 낡은 채로 남은 건도 있었다. 처음에는 요청 실패로 봤는데 응답은 성공이었고 확인해 보니 ProductUpdated 이벤트 경로가 thumbnail 만 밀고 detail_images 는 안 밀고 있었다.
요청 실패가 아니라 전송 경로의 범위 문제였다. 이 작업 전체를 관통하는 것은 성공 응답이 요청이 접수됐다는 것까지만 말한다는 사실이다. 실제로 연산이 돌았는지와 어떤 파일이 만들어졌는지와 어디까지 전파됐는지는 소요 시간과 media_files 행과 렌더된 화면으로 각각 되읽어야 한다.
정리
content_hash중복 제거가 있으면 성공 응답이 실행과 재사용 둘을 뜻한다- 응답으로 못 가르면 소요 시간이 신호가 된다
- 빠른 것이 좋은 것이 아니라 안 한 것일 수 있다
- 사전 조작은 그것이 먹었는지 확인하고 다음으로 간다
- 반영 방식이 직접 참조형과 재호스팅형으로 갈린다
- 같은 시점에 다 확인하면 재호스팅형이 전부 실패로 보인다
- 성공 응답은 접수됐다는 것까지만 말한다
- 요청한 방식과 다른 방식으로 되읽는다