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