상세 본문에 들어 있는 이미지들을 더 높은 품질로 다시 굽고 싶었다. 기존 이미지 주소를 그대로 다시 넣으면 재처리가 돌 것으로 보고 시작했다.
Table of contents
Open Table of contents
조사 — 본문 저장 시의 처리
본문이 어디에 저장되는지부터 확인하니 products 에 직접 들어 있지 않고 product_details 에 있었다. 본문을 저장할 때 DetailHtmlProcessor 가 돌면서 외부 <img src> 를 우리 이미지 서비스로 재업로드하고 최종 주소를 CloudFront 의 /resized/ 주소로 바꾼다.
이 처리를 다시 태우기만 하면 새로 구워질 것으로 보였고 그래서 기존 주소를 그대로 다시 넣어 봤다.
원인 — 걸려 있던 스킵 조건
코드를 더 읽어 보니 str_starts_with($src, CDN_BASE) 면 건너뛰는 조건이 들어 있었다. 우리 것을 다시 가져올 이유가 없으므로 그 자체로는 당연한 최적화다.
그런데 그것 때문에 재생성이 막혔다. 기존 주소를 그대로 넣으면 스킵 조건에 걸려 아무 일도 일어나지 않는다.
조치 — 경유지를 쓴 우회
두 가지 방법이 있었는데 DetailHtmlProcessor 에 --force 같은 스킵 무시 옵션을 넣어 배포하는 것과 S3 원본 주소를 그대로 넣어 스킵 조건에 안 걸리게 하는 것이다. 뒤쪽을 골랐다. 이유는 코드 변경 없이 지금 돌릴 수 있어서다. 대신 원본 S3 주소가 공개 접근이 되는 동안만 쓸 수 있는 우회라는 것을 감수했다. S3 원본 주소로 넣으면 스킵되지 않고 이미지 서비스가 그것을 새로 굽는다.
처리가 끝나면 최종 주소는 다시 우리 저장소 것으로 바뀌므로 그 외부 주소는 최종 호스트가 아니라 통과점이다. 우리 것이 아닌 척하는 주소로 한 번 통과시키는 셈이다.
주의 — 이름과 실제 범위
혹시 다른 처리가 이미지를 건드리는지도 함께 확인했다. stripExternalLinks() 가 있었는데 <a href> 만 처리하고 <img src> 는 손대지 않았다.
이름만 보면 외부 것을 전부 없앤다고 읽히지만 실제 범위는 훨씬 좁았다. 중단 조건도 하나 있었는데 BannedWordFilter 에 걸리면 처리 전체가 중단되므로 대량 재요청을 돌리다 하나가 걸리면 거기서 멈추고 그래서 재요청 전에 사전 검사가 필요했다.
가정과 달랐던 폭 문제
같이 조사한 건이 하나 더 있었는데 상세 이미지가 화면 폭의 절반으로만 나온다는 증상이었다. 처음에는 style="width:50%" 같은 인라인 스타일 때문이라고 의심했다.
그런데 전체 본문에서 그 패턴을 grep -c 로 세니 0건이었다. 실제 원인은 다른 서비스에서 복사해 온 본문에 딸려 온 <div class="se-component"> 편집기 래퍼가 폭을 제한하는 것이었고 리사이즈 자체는 상한을 지키고 있었다. 원인이 다르면 해결 규모도 다른데 스타일 속성 제거와 래퍼를 걷어내고 재구축하는 것은 작업 크기가 전혀 다르다.
정리
- 재처리를 강제하려는데 스킵 조건에 걸려 아무 일도 안 일어날 수 있다
- 스킵을 피하려면 그 조건에 안 걸리는 형태로 넣는다
- 경유지는 최종 호스트가 아니라 통과점이다
stripExternalLinks()같은 함수 이름의 범위와 실제 범위를 확인한다- 중단 조건이 있으면 대량 처리 전에 사전 검사한다
- 증상의 원인을 가정하지 말고 전체에서 세어 확인한다
- 0건이면 다른 원인이다
- 원인이 다르면 해결의 규모도 다르다