업로드 경로와 그 한계

파일이 어디를 지나가는지를 먼저 정합니다. 저장 위치가 아니라 경로입니다.

경로가 정해지면 나머지가 따라옵니다. 직접 업로드를 고르면 완료 통보와 메타데이터 기록을 설계해야 하고, 앱 서버를 거치면 동시 업로드 수가 스레드 한계에 걸립니다.

흔한 실수: 저장소 종류(스토리지냐 DB 냐)부터 고르는 것. 그건 뒤에 오는 결정입니다. 먼저 정할 것은 트래픽이 앱을 통과하느냐이고, 그 답이 확장 한계를 정합니다.

서버가 상태를 갖게 되는 것이 핵심 문제입니다.

용량과 소실도 문제지만 그건 디스크를 키우거나 백업으로 완화할 수 있습니다. 되돌리기 어려운 것은 무상태가 깨지는 것입니다.

서버 A 에 올린 파일이 서버 A 디스크에만 있다
로드밸런서가 다음 요청을 서버 B 로 보낸다
서버 B 에는 그 파일이 없다

이렇게 되면 서버를 늘리는 것으로 해결되지 않습니다. 세션 고정으로 같은 서버에 붙이는 우회가 가능하지만, 그 서버가 죽으면 파일이 사라지고 오토스케일도 못 씁니다.

흔한 실수: 디스크 용량만 문제로 답하는 것. 용량은 돈으로 미룰 수 있고, 진짜 비용은 수평 확장과 인스턴스 교체를 포기하게 되는 것입니다.

파일이 여전히 앱 서버를 통과한다는 것이 남습니다.

용량과 소실과 무상태는 풀립니다. 서버는 파일을 들고 있지 않으니 언제든 교체됩니다. 그런데 업로드 요청이 앱에 들어와 앱이 스토리지로 다시 보내는 구조라면, 앱이 전송량을 그대로 냅니다.

요구사항이 하루 40TB 이므로 그 전부가 앱을 통과해야 합니다. 저장하지 않아도 지나가게 하는 것만으로 병목이 됩니다.

흔한 실수: 스토리지로 옮겼으니 확장 문제가 끝났다고 답하는 것. 저장 위치는 바뀌었지만 경로는 그대로입니다. 경로에서 앱을 빼는 것이 다음 단계입니다.

아닙니다. 파일 크기와 동시 업로드 수가 선택을 정합니다.

하루 열 건에 100KB 짜리 설정 파일이라면 앱 서버가 받아 처리하는 편이 낫습니다. 서명 발급 경로, 완료 통보, 고아 객체 정리를 만드는 비용이 얻는 것보다 큽니다.

직접 업로드는 앱이 경로에서 빠지므로 업로드가 끝났는지 앱이 모릅니다. 완료 통보와 메타데이터 기록을 따로 만들어야 하고, 그 사이에 실패하면 스토리지에만 남은 고아 객체가 생깁니다.

흔한 실수: 서명 방식을 최신이라서 고르는 것. 사다리 위 칸이 항상 나은 것이 아니라 어떤 제약을 충족하는가로 이름 붙여야 합니다. 제약이 없으면 아래 칸이 맞습니다.