미디어 업로드 - ( 단일 업로드 / 멀티파트 업로드 )

업로드 방식
。백엔드 프록시 , Pre-Signed URL

백엔드 프록시 ( Backend Proxy )

。클라이언트가 백엔드에게 파일 업로드를 명령 시 백엔드가 Object Storage에 저장

。 구현이 간단하지만, 파일이 백엔드와 S3을 거치므로, 서버부하가 크고 네트워크 비용이 2배로 발생


Pre-Signed URL

• Presigned URL : 제한시간동안만 유효한 서명된 URL
  
  。클라이언트가 백엔드로 URL을 요청 시 백엔드가 Presigned URL을 발급하는 방식
  
  。클라이언트가 Presigned URL을 통해 Object Storage에 직접 업로드
  ▶ 백엔드 프록시 방식에 비해 클라이언트에서 직접 Presigned URL을 통해 업로드를 수행하므로 서버 부하를 줄이고, 네트워크 비용을 절감

업로드 유형
。단일 업로드 / 멀티파트 업로드

단일 업로드
。보통 50 MB 미만 수준의 작은 파일에 적합한 업로드 방식
▶ 파일 용량이 큰 경우, 중간에 실패 시 처음부터 다시 업로드하는 단점이 존재


Presigned URL을 통한 단일 업로드 순서

1. 클라이언트가 8 MB 이하 파일을 업로드하기 위해 백엔드에 init POST API를 호출
。Init 상태의 Media 객체가 생성


2. 백엔드는 Object Storage에 Pre-signed URL을 요청 및 수신한 Pre-signed URL을 클라이언트에게 응답


3. 수신한 Pre-signed URL을 통해 클라이언트가 Object Storage에 직접 파일 업로드


4. 업로드 완료 시 클라이언트가 백엔드에 UPLOADED POST API를 호출
。해당 Media 객체는 UPLOADED 상태로 전환

멀티파트 업로드
。50 MB를 초과하는 대용량 파일에 수 MB 단위의 작은 여러 파트로 분할하여 개별 업로드를 수행하는 업로드 방식

• 멀티파트 업로드를 수행 시 장점
  。신뢰성 확보 : 파일 업로드 중 네트워크가 끊겨도 실패 파트만 재시도
  
  。병렬 업로드 : 여러 파트를 동시에 파일 업로드하여 속도를 증진
  
  。진행률 추적 : 각 파트의 업로드 상태를 추적하여, 사용자에게 진행률을 지시 가능
  
  
• 이미지 크기 임계값 : 8 MB가 적합한 이유?
  
  。임계값이 작은 경우 ( ex. 1 MB )
  안정성은 높지만, 멀티파트 업로드를 통해 여러 요청을 보내야하므로, 요청 오버헤드가 높게 발생
  ▶ 모든 이미지를 1 MB 단위로 쪼개야하는 만큼 Object Storage에 전송할 요청도 증가
  
  。임계값이 높은 경우 ( ex. 100 MB )
  단일 업로드와 유사하므로 단순하지만, 안정성이 낮은 단점이 존재
  ▶ 큰 파일을 전송하므로 네트워크 전송 시 중간에 끊길 위험이 존재
  
  。임계값이 균형인 경우 ( ex. 8 MB )
  일반 스마트폰 사진은 단일 업로드, 동영상은 멀티파트로 처리
  ▶ 데이터 특성에 따라서 임계값을 설정
  
  
  멀티파트 업로드 순서
  

1. 클라이언트가 8 MB 이상 파일을 업로드하기 위해 init POST API를 백엔드로 요청
   。Request Body에 포함된 파일 크기에 따라서 단일업로드 / 멀티파트 업로드로 구분
   
   。Init 상태의 Media 객체가 생성
   
   
2. 백엔드에서 createMultiPartUpload()를 호출해서 Object Storage으로부터 uploadId를 수신 및 저장
   。해당 Media 객체의 uploadId 필드에 해당 값 지정
   
   
3. 여러 Presigned URL로 구성된 배열을 클라이언트에게 전달
   
   
4. 클라이언트는 각 파트를 8 MB 씩 분할 및 각 파트마다 Presigend URL을 통해 Object Storage로 미디어파일 업로드
   。각 파트의 파일이 Object Storage에 업로드 완료 시 해당 파트의 ETag를 반환

Part1 업로드
↓
HTTP 200 OK / ETag: "ab123"
Part2 업로드
↓
HTTP 200 OK / ETag: "cd456"
  ...

▶ 클라이언트에서 파트 별 Presigned URL에 각 파트를 업로드하면 S3은 응답 헤더에 ETag을 전달

ETag : 멀티파트 업로드에서 각 파트의 업로드 결과


5. 모든 파일 업로드가 완료 시 클라이언트는 uploaded POST API를 통해 각 파트의 ETag들을 포함하여 백엔드로 요청


6. 백엔드는 completeMultipartUpload()를 호출 시 Object Storage 모든 파트를 하나의 파일로 병합 후 OK를 반환


7. 백엔드는 해당 파일 정보를 DB에 저장 및 200 OK를 클라이언트에게 반환

API 유형

Init API ( POST )
。해당 API를 통해 파일 업로드 요청 시 mediaType과 fileSize를 함께 전달 시 단일 / 멀티파트 업로드를 결정하여 응답값을 반환

• 업로드 파일이 8 MB 보다 작아서 단일 업로드를 수행하는 경우
  
  。 2MB는 임계값( = 8MB )보다 작으므로, Presigned URL 하나만 반납
  ▶ uploadId / presignedUrlParts와 같은 멀티파트 용 필드는 비어있음.
  
  
• 업로드 파일이 8 MB를 초과해서 멀티파트업로드를 수행하는 경우
  
  。 16 MB는 임계값( = 8MB )보다 크므로, 여러 Presigned URL를 반납
  ▶ 단일 업로드 용 presignedUrl은 비어있고, uploadId / presignedUrlParts와 같은 멀티파트 용 필드가 제공
  
  
  Uploaded API ( POST )
  
  。단일 업로드 : mediaId만 전달 시 백엔드는 해당 파일 업로드를 완료 처리
  
  。멀티파트 업로드 : mediaId와 함께 parts에 각 작업완료 된 파트의 partNumber와 ETag 쌍을 전달하여 백엔드는 Object Storage에 완료를 알려준 후 완료 처리