이미지 하나에 서빙 경로 셋

새 등록 경로로 만든 상품의 본문을 보다가 이미지 주소가 저장소 경로가 아니라 다른 도메인이라는 지적을 받았다. 이미지 서비스 코드를 열어 저장할 때와 응답할 때를 각각 나눠서 확인했다.

Open Table of contents

저장과 응답의 불일치

저장할 때는 저장소에 변환 결과를 직접 경로로 넣고 있었다. 그런데 응답을 만들 때는 그 경로가 아니라 프록시 도메인 형태의 주소를 돌려주고 있었다.

저장하는 경로와 응답으로 나가는 주소가 서로 다른 구조였다. 그 프록시가 무엇을 하는지 확인하니 리다이렉트가 아니라 요청마다 원본을 가져와 즉석에서 변환해 스트리밍하고 있었고 캐시 헤더도 없었다.

두 주소로 각각 받아 바이트 수를 비교하니 같은 이름인데도 크기가 달랐다. 저장된 것과 즉석에서 변환한 것이 서로 다른 결과를 내고 있다는 뜻이다.

즉 같은 이름을 쓰지만 실제로는 별도 변환 경로였다. 전체를 정리하니 대표와 부가 이미지는 저장소 직접이고 옛 본문도 직접인데 신규 본문만 프록시였다.

여기가 문제의 핵심인데 본문은 HTML 텍스트로 저장되므로 이미지 주소가 등록 시점에 텍스트로 박힌다. 나중에 서빙 방식을 바꿔도 이미 등록된 본문은 그대로 남는다.

신규 본문이 쌓일수록 전부 프록시 주소가 박히고 모든 상세 조회가 영구히 그 서비스에 의존하게 된다. 그 서비스가 죽거나 외부 마켓이 그 도메인을 차단하면 상세 이미지가 전부 깨지고 이미 박힌 주소는 되돌릴 수 없다.

즉석 변환에 캐시 헤더까지 없으면 상세 페이지를 한 번 열 때마다 이미지 수만큼 변환이 일어난다. 저장소 직접이면 배포망이 캐시하는데 프록시면 매번 서비스를 친다.

부하와 지연이 완전히 다른 구조가 되는 것이다. 조회가 늘수록 그 차이가 그대로 비용이 된다.

저장소에 객체가 실제로 존재하는지를 확인하니 직접 주소로도 정상 응답이 왔다. 그러면 본문에 저장소 직접 주소를 넣는 대안이 그대로 성립하게 된다.

변환이 이미 돼 있는 상태이므로 요청마다 즉석 변환을 할 이유가 없다. 저장소 객체가 없었으면 프록시가 필수였을 것이므로 그 확인 하나가 선택지를 만들었다.