저장소가 아니었던 도메인

이미지가 안 보이는 건을 조사하면서 주소의 도메인을 저장소 이름으로 보고 그 안에서 파일을 찾았다. 없어서 비슷한 이름의 후보를 하나씩 뒤졌지만 전부 빈 결과였다.

Open Table of contents

버킷 이름으로 착각한 도메인

주소의 형태가 저장소에 직접 접근하는 모양과 같았다. 도메인이 있고 그 아래 식별자와 파일명이 붙는 구조였다.

이 패턴에 익숙하면 도메인을 저장소 이름으로 읽게 된다. 실제로 그런 경우가 많으므로 그 읽기 자체가 이상한 것은 아니었다.

후보를 하나씩 뒤지는 대신 저장소 목록을 통째로 뽑아 봤다. 그 이름의 저장소가 아예 없었다.

그러면 찾는 방법이 틀린 것이 아니라 전제가 틀린 것이다. 못 찾을 때 후보를 늘리는 대신 전체 목록을 한 번 보면 전제가 틀렸다는 것이 바로 드러난다.

코드에서 그 도메인을 쓰는 자리를 찾으니 주소를 만드는 함수가 나왔다. 별도 저장소에 그 도메인을 서빙하는 애플리케이션도 있었다.

요청을 받으면 실제 저장소에서 원본을 가져와 변환해 돌려주는 이미지 서버였다. 저장소가 아니라 저장소 앞에 있는 처리 계층이었고 그 서버 코드에 실제 저장소 이름과 경로 규칙이 적혀 있었다.

실제 경로로 찾아가 보니 해당 위치에 객체가 하나도 없었다. 데이터베이스에는 미디어 레코드가 있는데 저장소에는 아무것도 없는 상태였다.

이것은 이미지가 깨진 것이 아니라 업로드 자체가 안 된 것이다. 원본이 없는 것과 변환본만 없는 것은 증상이 같지만 앞은 복사로 복구하고 뒤는 변환을 다시 돌리므로 조치가 다르다.

이 조사 뒤로 이미지 문제는 정해진 순서로 본다. 주소의 도메인이 저장소인지 처리 계층인지를 먼저 가르고 실제 저장소와 경로 규칙을 코드에서 확인한다.

그다음에 원본이 있는지 보고 없으면 업로드 누락이고 있으면 변환본을 본다. 첫 단계를 건너뛰면 존재하지 않는 것을 계속 찾게 되므로 나머지 단계로 넘어갈 수 없다.