파일이 커지면 깨지는 것들

파일 업로드 기능이 작은 파일로는 잘 됐는데 큰 파일을 올리자 여러 곳에서 걸렸다. 걸리는 자리가 한 곳이 아니었다.

Open Table of contents

계층마다 있던 제한

웹서버의 요청 본문 크기와 애플리케이션의 업로드 크기가 각각 따로 있었다. 메모리는 파일을 통째로 읽으면 그만큼 쓰고 연결은 업로드 도중에 시간 제한에 걸렸다.

저장소에도 단일 요청으로 올릴 수 있는 크기 제한이 있었다. 다섯 곳을 다 손대야 통과하는 구조였다.

이 문제가 답답한 것은 제한이 한 번에 다 보이지 않는다는 점이다. 앞의 것을 고쳐야 다음 것이 드러난다.

그래서 브라우저에서 저장소까지 경로 전체를 그려 놓고 각 계층의 제한을 한 번에 확인했다. 하나씩 걸릴 때마다 찾으면 그 횟수만큼 배포와 재현이 반복된다.

메모리 문제는 설정으로 풀리지 않아서 코드를 바꿔야 했다. 파일을 통째로 읽어 넘기던 것을 스트림으로 흘려보내게 했다.

메모리 한도를 늘리는 것은 임시방편이고 파일이 더 커지면 다시 걸린다. 읽는 방식을 바꾸는 것이 근본 해결이었다.

저장소의 단일 요청 제한은 스트림으로도 안 풀려서 여러 조각으로 나눠 올리는 방식을 썼다. 중간에 실패해도 그 조각만 다시 올리면 되므로 실패에 강해진다.

대신 조각 관리와 실패 처리와 미완료 정리가 붙어서 복잡해진다. 그래서 작은 파일은 단순 업로드로 두고 큰 파일만 나눠 올리게 기준을 정했다.

한동안 돌리고 저장소를 보니 미완료 업로드가 쌓여 있었다. 조각은 올라갔는데 합쳐지지 않은 것들이고 그대로 공간과 요금을 쓴다.

일정 기간이 지난 미완료 업로드를 자동으로 지우는 규칙을 넣었다. 나눠 올리기를 도입하면 이 정리 규칙이 반드시 따라와야 하고 안 넣으면 조용히 쌓인다.

진행률은 조각 단위로 계산해 보여 줬다. 조각마다 걸리는 시간이 달라 정확하지는 않지만 멈춘 것처럼 보이지 않는 것이 목적이었다.