10GB 파일 업로드 — presigned URL + 멀티파트로

• 대용량 분석 데이터를 다루는 플랫폼의 업로드 파이프라인. 프론트와 백엔드 양쪽을 함께 수정

증상

• 큰 파일 업로드가 실패 — 분석 대상 데이터가 큰 제품이라 업로드 상한이 곧 제품 한계
• 서버측 상한을 풀었더니 업로드는 통과하는데 저장 단계에서 터짐

원인

• 파일이 API 서버를 통과하는 경로였다. 요청 본문이 서버 메모리를 지나가므로 파일이 커질수록 서버가 먼저 죽는다. 상한을 올리는 건 죽는 지점을 뒤로 미룰 뿐이다
• 앞단 프록시·게이트웨이에도 각자 본문 크기 상한이 있어서, 애플리케이션 설정 하나만 풀면 다음 구간에서 다시 막힌다
• 한 번의 PUT으로 올리면 중간에 끊겼을 때 처음부터 다시 올려야 한다. GB 단위에서는 재시도 비용이 성공률을 지배한다

조치

• S3 presigned URL 발급으로 전환 — 서버는 권한 검사와 메타데이터만 다루고, 파일 바이트는 브라우저에서 S3로 직접 간다. 서버 메모리와 업로드 크기가 분리된다
• 파일을 청크로 쪼개 멀티파트 업로드 — 파트마다 presigned URL을 받아 올리고, 마지막에 파트 목록으로 완료 요청을 보내 S3가 하나로 합친다. 끊기면 실패한 파트만 다시 올린다
• 진행률은 완료된 파트를 누적해 계산 — 단일 PUT일 때는 알 수 없던 값이다
• 업로드 완료와 저장(메타데이터 기록)이 어긋나지 않게 프론트 흐름을 손보고, 백엔드는 파일 처리·예외 처리를 보강
• 대용량 시나리오를 테스트로 고정해 재발 차단
• 대용량 읽기 오류도 함께 보고됐는데 추적해보니 파일을 생성하는 쪽 문제였다. 뷰어·업로드 코드를 고치는 대신 원인 지점을 특정해 담당 팀에 전달

결과

• 최대 10GB 업로드
• 업로드 규모가 서버 자원과 분리됨 — 파일이 커져도 서버는 URL만 발급한다