[S3] Presigned URL 사용해보기 2 / 고용량 파일 업로드 시 CPU 사용량 100% 혹은 서버 터질 때

 

생성된 Presigned Url을 분석해보면 아래와 같은 구조로 이루어져있다.

//Domain - S3 버킷 도메인, 리전
https://test.s3.ap-northeast-2.amazonaws.com

// Path - 파일 경로, 인코딩된 파일 명
/file_name.mp4?

// Query Parameters
// S3 인증 알고리즘
X-Amz-Algorithm=

// 업로드 및 다운로드 시 콘텐츠 검사 설정
X-Amz-Content-Sha256=

// AccessKey, RequestDate, Region, Service, RequestType 순
X-Amz-Credential=

// 요청 생성 시각
X-Amz-Date=

// Url 유효 기간
X-Amz-Expires=

// 검증용 서명
X-Amz-Signature=

// 서명된 hearder 목록
X-Amz-SignedHeaders=

// S3 작업 유형
x-id=PutObject

 

 

여기서 Domain과 Path를 합치면 S3에 업로드된 이미지의 Url 이 된다

예: https://test.s3.ap-northeast-2.amazonaws.com/file_name.mp4

 

 

 

 

S3에 업로드된 이미지의 url은 db에 저장해야 필요시 조회하여 사용할 수 있다.

이를 위해 Presigned URL을 생성하고 반환하는 API 에서 이미지 url 도 함께 반환하도록 로직을 추가해보았다.

다만 해당 Presigned URL를 사용하지 않거나 업로드가 실패한다면 이미지 url 이 유효하지 않게 되는 문제가 발생할 수 있어 고민했지만, 결론적으로 클라이언트에서 보관하고있던 이미지 url을 Presigned URL에 업로드가 성공할때만 서버로 전송해 DB에 저장하는 방식이기때문에 괜찮을 것 이라고 생각했다.

(생성된 Presigned URL를 사용하지 않아도 리소스에 영향을 주지 않는다(계속 남아있지 않음))

 

 

    const fileUrl = `https://${bucketName}.s3.${region}.amazonaws.com/${fileKey}`;

 

이런식으로 Presigned URL 을 생성하는 로직에 추가해주었다.

bucketName과 region은 env 파일에서 가져오는 방식이다.

 

 

 

 

 

 

 

클라이언트는 Presigned URL로 PUT 요청을 보내며, 요청의 Body에는 바이너리(binary) 형식으로 파일을 첨부해준다.

요청이 성공하면 클라이언트는 임시로 보관 중이던 파일 URL을 서버로 전송한다.

 

 

 

 

 

첫 번째 이미지 (Presigned URL 도입 전)

• Request sent: 9.38초
• Waiting for server response: 5.98초
• Content Download: 1.56ms
• 총 소요 시간: 약 15.37초

 

두 번째 이미지 (Presigned URL 도입 후)

• Request sent: 9.27초
• Waiting for server response: 220.09ms
• Content Download: 0.55ms
• 총 소요 시간: 약 9.54초

 

Waiting for server response가 95%이상 감소한 것을 볼 수 있다!

 

Presigned URL이 클라이언트가 S3와 직접 통신하도록 해 중간 서버를 거치지 않기 때문에

서버 통신 시간을 현저히 줄일 수 있는 것이다.

 

또한 대용량 파일 업로드 시에도 중간 서버를 거치지 않으므로 서버의 CPU 사용량은 거의 무시할 수 있을 수준이 될 정도로 줄어들었다.

이는 서버가 무거운 파일을 직접 처리하지 않고, 단순히 string 을 주고받는 작업만 수행하면 되기 때문이다.

다수의 사용자가 동시에 대용량의 동영상 파일을 업로드하는 환경에서 매우 효율적인 선택인것같다

 

다음번에는 Request sent을 줄이는 방법도 알아보고 적용해보고싶다!