새로 상장한 코인의 로고가 앱에서 안 보이는 건을 조사하면서 주소의 도메인을 버킷 이름으로 보고 그 안에서 파일을 찾았다. 없어서 비슷한 이름의 후보를 하나씩 뒤졌지만 전부 빈 결과였다.
Table of contents
Open Table of contents
배경 — 버킷 이름으로 착각한 도메인
주소는 img. 로 시작하는 도메인 아래 coins/ 와 심볼 파일명이 붙는 형태였다. 오브젝트 스토리지에 직접 접근하는 주소와 모양이 같았다.
이 패턴에 익숙하면 도메인을 버킷 이름으로 읽게 된다. 실제로 그런 경우가 많으므로 그 읽기 자체가 이상한 것은 아니었다.
해 본 것 — 전체 목록이 뒤집은 전제
후보를 하나씩 뒤지는 대신 aws s3 ls 를 엔드포인트만 바꿔 버킷 목록을 통째로 뽑아 봤다. 그 이름의 버킷이 아예 없었다.
그러면 찾는 방법이 틀린 것이 아니라 전제가 틀린 것이다. 못 찾을 때 후보를 늘리는 대신 전체 목록을 한 번 보면 전제가 틀렸다는 것이 바로 드러난다.
원인 — 도메인 뒤에 있던 처리 계층
코드에서 그 도메인을 쓰는 자리를 찾으니 주소를 만드는 AssetUrlBuilder 가 나왔다. 그 도메인은 별도 nginx 가 받고 있었고 설정에 image_filter resize 와 proxy_pass 가 있었다.
요청을 받으면 실제 버킷에서 원본을 가져와 크기를 줄여 돌려주는 이미지 서버였다. nginx 공식 문서는 ngx_http_image_filter_module 을 JPEG 와 GIF 와 PNG 와 WebP 이미지를 변환하는 필터로 적고 proxy_pass 뒤에 두는 예시를 든다. 버킷이 아니라 버킷 앞에 있는 처리 계층이었고 그 설정에 실제 버킷 이름과 경로 규칙이 적혀 있었다.
막힌 지점 — 레코드는 있고 파일이 없었다
실제 경로로 찾아가 보니 해당 위치에 객체가 하나도 없었다. coin_assets.logo_path 에는 값이 있는데 버킷에는 아무것도 없는 상태였다.
이것은 이미지가 깨진 것이 아니라 업로드 자체가 안 된 것이다. 원본이 없는 것과 변환본만 없는 것은 증상이 같지만 앞은 복사로 복구하고 뒤는 변환을 다시 돌리므로 조치가 다르다.
조치 — 확인 순서
이 조사 뒤로 이미지 문제는 정해진 순서로 본다. 주소의 도메인이 버킷인지 처리 계층인지를 먼저 가르고 실제 버킷과 경로 규칙을 nginx 설정에서 확인한다.
그다음에 원본이 있는지 HEAD 로 보고 없으면 업로드 누락이고 있으면 변환 응답을 본다. 순서를 문서에 적는 쪽을 골랐다. 이유는 첫 단계를 건너뛰면 존재하지 않는 것을 계속 찾게 돼서다. 대신 급한 건도 순서를 밟느라 몇 분이 더 드는 것을 감수했다.
정리
- 주소의 도메인이 버킷이 아닐 수 있다
- 앞에 처리 계층이 있으면 주소 형태만 같고 다른 것이다
- 못 찾으면 후보를 늘리지 말고 전체 목록을 뽑아 본다
- 그 이름이 아예 없으면 전제가 틀린 것이다
- 실제 버킷과 경로 규칙은 설정에서 확인한다
- 레코드가 있는데 파일이 없으면 안 올라간 것이다
- 업로드 누락과 변환 실패는 증상이 같고 조치가 다르다
- 확인 순서를 적어 두면 첫 단계에서 헤매는 것을 막는다