file을 함께 전송해야 하는 api에 대한 궁금증

History

사이드 프로젝트에서 file을 s3에 저장해야 하는 상황

1. postLogDirectory의 request content-type을 application/json으로 받는 방식
• FE에서 file을 s3에 저장하고 s3의 이미지 url을 전달받는 image api를 호출한다.
• image api를 통해 얻은 url + 나머지 settings 정보를 넣어 postLogDirectory api를 호출한다.

2. postLogDirectory의 request content-type을 mulipart/form-data로 받는 방식
• FE측에서 form-data형태로 postLogDirectory api를 호출한다.

Issue

• Q1. 왜 BE는 1번 방식을 선호할까?
• A1: 2번의 방식으로 가면 프론트에서 이미지를 업로드하면 서버는 s3 에 올리기 위해 bypass 해주는 역할만 하는데, presignedUrl 방식으로 가면 서버 리소스 측면에서 더 효율적이라고 생각합니다.(작업 기간도 고려해아할 것 같아서 고려해서 진행해주시죠! 전 둘다 좋습니다요

• Q2. 1번의 경우, 프론트에서 s3에 바로 찔르면 네트워크 로그가 다 남을텐데 보안적인 이슈는 없는걸까?

• Q3. 서버는 s3에 올리기 위해 bypass해주는 역할만 한다는 게 무슨 이야기일까?

• Q4. presignedUrl방식은 어떤걸까?

• Q5. presignedUrl방식이 왜 서버 리소스 측면에서 더 효율적일까?

Reference

• Q1. S3 및 postLogDirectory에 업로드 하기 위한 API 분리하는 것을 선호하는 이유?
• 모듈화
• 분리를 통해 시스템의 여러 부분을 독립적으로 개발, 테스트, 확장 및 유지보수 가능 (ex. 로그 관리 방법에 영향을 주지 않고 업로드 처리 방법을 변경할 수 있다.)
• 보안 및 제어
• 업로드의 경우, presignedUrl을 사용하여 사용자가 파일만 업로드하고 다른 작업은 수행할 수 없도록 할 수 있다.

• Q2. 프론트에서 s3에 바로 찔르면 네트워크 로그가 다 남을텐데 보안적인 이슈는 없는걸까?
• 임시 액세스
• presignedUrl은 서버에서 제어할 수 있는 지정된 기간 동안만 유효하다. ⇒ 이 기간이 지나면 URL은 만료되어 다시 사용할 수 없다.
• 제한된 권한
• URL은 생성된 특정 작업만 허용한다. ⇒ 해당 URL로는 다른 작업을 수행할 수 없다.

• Q3. 서버는 s3에 올리기 위해 bypass해주는 역할만 한다는 게 무슨 이야기일까?
• 서버가 S3에 파일을 업로드하기 위한 우회 역할만 수행하여 서버는 단지 중개자 역할만 한다.
• 실제 파일 데이터를 직접 처리하는 대신 클라이언트에서 S3 스토리지로 파일을 전달하기만 하면 된다.

• Q4. presignedUrl방식은 어떤걸까?
• 제한된 시간 동안 작업(ex. 파일 업로드)을 승인하기 위해 액세스 자격 증명을 사용하여 서버에서 생성하는 URL
⇒ 이 URL은 클라이언트가 서버와의 추가 상호 작용 없이 S3에서 직접 허용된 작업을 수행하는 데 사용될 수 있다.
• Ex. 서버는 사용자가 특정 파일을 S3 버킷에 업로드할 수 있도록 presignedUrl을 생성한 다음 이 URL을 사용자의 브라우저로 보낼 수 있다.
• 사용자의 브라우저는 이 URL을 사용하여 파일을 S3에 직접 업로드할 수 있다.

• Q5. presignedUrl방식이 왜 서버 리소스 측면에서 더 효율적일까?
• 대역폭 사용량 감소
• 서버는 파일 데이터를 처리할 필요가 없다.
• 파일은 클라이언트에서 S3로 직접 이동하므로 서버의 대역폭이 절약되고 로드가 줄어든다.
• 낮은 서버 부하
• 파일 데이터를 처리하고 전송할 필요가 없으므로 서버는 다른 작업에 리소스를 사용할 수 있다. ⇒ 전반적인 효율성과 용량이 향상되어 더 많은 사용자나 작업을 처리할 수 있다
• 빠른 파일 업로드
• 데이터가 S3로 직접 이동하여 데이터 이동 시간이 단축되므로 사용자는 더 빠른 업로드를 경험한다.