상세 본문에 들어 있는 이미지들을 더 높은 품질로 다시 굽고 싶었다. 기존 이미지 주소를 그대로 다시 넣으면 재처리가 돌 것으로 보고 시작했다.
Table of contents
Open Table of contents
본문 저장 시의 처리
본문이 어디에 저장되는지부터 확인하니 상품에 직접 들어 있지 않고 별도 테이블에 있었다. 본문을 저장할 때 처리기가 돌면서 외부 이미지 주소를 우리 이미지 서비스로 재업로드하고 최종 주소를 우리 저장소의 크기 제한 주소로 바꾼다.
이 처리를 다시 태우기만 하면 새로 구워질 것으로 보였고 그래서 기존 주소를 그대로 다시 넣어 봤다.
걸려 있던 스킵 조건
코드를 더 읽어 보니 주소가 이미 우리 저장소 것이면 건너뛰는 조건이 들어 있었다. 우리 것을 다시 가져올 이유가 없으므로 그 자체로는 당연한 최적화다.
그런데 그것 때문에 재생성이 막혔다. 기존 주소를 그대로 넣으면 스킵 조건에 걸려 아무 일도 일어나지 않는다.
경유지를 쓴 우회
재처리를 강제하려면 그 조건에 안 걸리는 형태로 넣어야 했다. 외부 주소로 넣으면 스킵되지 않고 이미지 서비스가 그것을 새로 굽는다.
처리가 끝나면 최종 주소는 다시 우리 저장소 것으로 바뀌므로 그 외부 주소는 최종 호스트가 아니라 통과점이다. 우리 것이 아닌 척하는 주소로 한 번 통과시키는 셈이다.
이름과 실제 범위
혹시 다른 처리가 이미지를 건드리는지도 함께 확인했다. 외부 링크를 제거하는 함수가 있었는데 링크 태그만 처리하고 이미지 주소는 손대지 않았다.
이름만 보면 외부 것을 전부 없앤다고 읽히지만 실제 범위는 훨씬 좁았다. 중단 조건도 하나 있었는데 금칙어 검사에 걸리면 처리 전체가 중단되므로 대량 재요청을 돌리다 하나가 걸리면 거기서 멈추고 그래서 재요청 전에 사전 검사가 필요했다.
가정과 달랐던 폭 문제
같이 조사한 건이 하나 더 있었는데 상세 이미지가 화면 폭의 절반으로만 나온다는 증상이었다. 처음에는 폭을 직접 지정한 인라인 스타일 때문이라고 의심했다.
그런데 전체 본문에서 그 패턴을 세니 0건이었다. 실제 원인은 다른 서비스에서 복사해 온 본문에 딸려 온 편집기 래퍼가 폭을 제한하는 것이었고 리사이즈 자체는 상한을 지키고 있었다. 원인이 다르면 해결 규모도 다른데 스타일 속성 제거와 래퍼를 걷어내고 재구축하는 것은 작업 크기가 전혀 다르다.
정리
- 재처리를 강제하려는데 스킵 조건에 걸려 아무 일도 안 일어날 수 있다
- 스킵을 피하려면 그 조건에 안 걸리는 형태로 넣는다
- 경유지는 최종 호스트가 아니라 통과점이다
- 함수 이름의 범위와 실제 범위를 확인한다
- 중단 조건이 있으면 대량 처리 전에 사전 검사한다
- 증상의 원인을 가정하지 말고 전체에서 세어 확인한다
- 0건이면 다른 원인이다
- 원인이 다르면 해결의 규모도 다르다