Pre-Signed URL? 미리 서명된 URL이란 무엇을 말하는 걸까? AWS S3의 Pre-Signed URL에 대해 알아보자.
Prs-Signed URL이란?
클라이언트에게 Pre-Signed URL을 제공하면 이를 사용하여 AWS의 S3 버킷에 파일을 직접 업로드 / 다운로드를 할 수 있다.
Pre-Signed-URL를 생성할 때는 아래와 같은 값들을 설정해주어야한다.
- Amazon S3 버킷
- 객체 키(이 객체를 다운로드하면 Amazon S3 버킷, 업로드하면 업로드할 파일 이름)
- HTTP 메서드(객체 다운로드의 경우 GET, 업로드의 경우 PUT)
- 만료 시간 간격
프론트 단에서 aws-sdk를 사용해서 Pre-Signed URL을 생성할 수 있지만, S3의 버킷에 대한 접근 권한을 가진 credentials 부분이 탈취당하게 된다면 우리의 S3 저장공간이 누구나 접근할 수 있게 되어 어떤 사이드이펙트가 나타날 지 모른다.
그러니, 서버(백엔드)측에서 S3에 대한 접근 권한과 Pre-Signed URL을 발급받아 클라이언트에 전달하면 클라이언트는 URL을 사용하여 파일을 업로드 및 다운로드할 수 있게 하는 방식이 좋을 것 같다.
사용해야 하는 이유?
우리는 백엔드에 대용량 파일(이미지, 파일)을 저장하지 않는다.
기존의 업/다운로드 로직
기존의 로직은 S3에 저장하기 위해서 클라이언트에서 서버로, 서버에서 S3로 저장한다. 말 그대로 우리는 백엔드 서버에 대용량 파일을 저장하지 않는다. 하지만 이미지와 파일 같은 용량이 큰 객체를 서버에 전송하는 과정은 좋지 않아 보인다.
반면에 Pre-Signed URL을 적용한 로직은 아래와 같다.
Pre-Signed URL 로직
- 클라이언트에서 파일을 바로 서버에 올려보내지 않고, 파일을 업/다운로드 하겠다는 요청을 서버에 보낸다.
- 서버는 S3에 파일을 저장할 URL를 미리 생성시킨다.
- 생성된 URL를 클라이언트에게 전달한다.
- 생성된 URL(S3)로 직접 업/다운로드한다.
프론트 로직이 줄어든다.
파일을 업/다운로드하는 방법이 다양할 수 있겠지만 구현을 하다 보면 Blob, createObjectURL, revokeObjectURL과 같은 URL과 관련된 용어를 많이 봤을 것이다.
클라이언트에서 다운로드 로직
또한, createObjectURL를 사용하고 revokeObjectURL로 폐기하지 않으면, createObjectURL로 만들어진 URL이 유효하다고 판단하여 삭제되지 않기 때문에 메모리 누수가 발생할 상황이 생기는데 Pre-Sigend URL은 이럴 상황을 만들지 않는다는 것도 이점으로 볼 수 있겠다.
회사 일을 하면서 파일 다운로드 시에 Pre-Sigend URL를 적용해달라는 요청을 받았는데, 처음 들어본 용어라 무척이나 당황스러웠었다. Pre-Signed URL을 적용하기 위해 찾아보면서 업/다운로드에 대한 지식도 다시 한 번 살펴본 계기가 되었고, 기존에 하던 방식보다 괜찮다고 생각했다.
결국 찾아보면서, 프론트에서는 변경할 부분이 별로 없다는 걸 알게되었다. 넘겨주는 URL에 파일을 주고받기만 하면 되는...
그러나 기존 로직과 달라지는 부분이 있었기에 왜 달라져야하나? 왜 createObjectURL나 Blob를 사용하지 않아도 되는 것일까?에 대한 의문이 들었고, 그 부분을 중점적으로 정리하면서 글을 작성하니까 더 좋았던 것 같다.
나중에는 Blob이나 File 같은 데이터에 대해서도 알아보면 좋을 것 같다.