[설계] 팀바팀 이미지 업로드 설계 (1) - 이미지 Storage, 업로드 주체 결정

0. 들어가기 전

현재 팀바팀 서비스에서는 사용자들이 소통을 하는 '피드' 도메인이 다음과 같이 존재합니다.

팀바팀 피드

현재 피드를 작성할 때는 시간 상의 문제로 이미지 없이 텍스트로만 작성이 가능하도록 구현했었습니다.

 

이후 기능 개선 회의에서 피드에 이미지가 필요할 것 같다는 의견이 나왔고,

해당 의견이 반영되어 '피드에 이미지를 업로드 할 수 있다.'라는 요구사항이 도출되었습니다.

 

추가적으로, 아래의 슬랙처럼 '이미지를 피드 등록 창에 업로드했을 때, 이미지 미리보기를 할 수 있다.'라는 요구사항도 있었습니다.

슬랙 채팅창 이미지 업로드 시 미리보기

 

해당 요구사항을 구현하기 위해 어떠한 고민을 거쳤는지 기록해보고자 합니다! 👍🏻👍🏻👍🏻

---

1. 이미지 Storage : 서버 내부 Stroage or S3

결과적으로 이미지 Storage로는 AWS의 S3를 도입하기로 했습니다!

 

이미지를 저장하는 방법으로 크게 서버 내부에 Storage를 두고, DB에 직접 파일을 저장하는 방법과

AWS S3에 저장 후에 S3의 저장된 URL을 사용하는 방법이 존재했습니다.

 

AWS S3는 'AWS에서 제공하는 높은 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스'입니다.

AWS S3 설명 이미지 - 출처 : AWS S3 공식문서

S3에 파일을 업로드하면 S3 버킷(스토리지)에 저장되고, 업로드한 파일의 URL이 생성되어 

해당 URL로 파일에 접근할 수 있습니다.

 

해당 2가지 방법의 장단점은 다음과 같았습니다.

1-1. 서버 내부 Storage 

장점

• 외부 서비스(AWS)에 의존하지 않고 독립된 Storage를 구성할 수 있다.
• 파일 관리 및 보안을 서버에서 제어할 수 있다.

단점

• 파일 자체로 저장하기 때문에 용량이 크다.
• 용량이 크기 때문에 서버 리소스 부하가 커진다.
• 하나의 서버 내부에 Storage를 두기 때문에 Scale-Out 시 어려움이 있다.

 

1-2. AWS S3 

장점

• AWS S3에서는 용량 제한 없이 무제한으로 스토리지를 확장할 수 있어서 저장 용량 걱정이 없다.
• 파일 자체를 저장하는 서버 내부 Storage에 비해 서버 부하가 훨씬 덜하다.
• 서버 외부에 Storage가 존재하기 때문에 Scale-Out이 상대적으로 용이하다.

단점

• 추가적인 비용이 발생한다.
• 상대적으로 서버 내부 Storage 사용 시보다 추가적인 설정, 개발 리소스가 발생한다.

 

저희 팀바팀에서 서버 내부 Storage가 아닌 AWS S3를 선택한 이유는 위에 굵게 표시한 이유가 크리티컬했습니다.

'서버 부하'를 기준으로 고려했을 때, 용량이 큰 파일 자체를 서버 내부에 저장하는 것보다

파일 자체를 AWS S3에 저장하고 생성된 URL 자체를 저장하여 사용하는 것이 훨씬 효율적이라고 생각했습니다.

 

추가적으로, 현재 프로젝트 환경에서 S3를 사용할 수 있는 환경이 주어졌기 때문에

이를 잘 활용하는 것도 중요하다고 생각했습니다.

---

2. S3에 업로드하는 주체 - 백엔드 vs 프론트엔드

AWS S3에 이미지를 업로드를 하기로 결정하고 난 후

S3에 업로드를 백엔드에서 할지, 프론트엔드에서 할지 고민을 진행했습니다.

 

백엔드에서 S3 업로드, 프론트엔드에서 S3 업로드 Flow를 살펴보며 비교해봅시다.

 

2-1. 백엔드에서 S3 업로드

백엔드 S3 업로드 Flow

 

 

백엔드에서 S3 업로드 시 Flow

1. 프론트엔드에서 백엔드 서버로 이미지를 담아서 업로드 API 요청
2. 백엔드 서버에서 요청을 처리하여 S3에 이미지 업로드
3. 이미지 업로드 후 생성된 S3 ImageUrl DB에 저장
4. 프론트엔드에게 S3 ImageUrl Response로 응답

 

장점

• S3 이미지 관리와 DB의 이미지 관련 테이블 관리를 백엔드에서 진행하기 때문에 데이터 싱크를 맞추기 용이하다.

 

단점

• 서버에 이미지 자체를 담아서 요청하기 때문에 서버 리소스 소모가 심하다.
• 서버 리소스 소모가 심하기 때문에 동시에 여러 요청이 들어왔을 때 병목 현상이 발생할 수 있다.
• 사용자 입장에서 이미지 업로드 시 미리보기를 할 때 미리보기 되는 이미지 로딩이 오래걸린다. (네트워크를 여러번 거치므로)

 

2-2. 프론트에서 S3 업로드

프론트 S3 업로드 Flow

프론트엔드에서 S3 업로드 시 Flow

1. 프론트엔드에서 이미지를 S3에 업로드
2. 이미지 업로드 후 생성된 S3 ImageUrl 저장
3. DB 저장을 위해 생성된 S3 ImageUrl을 담아서 백엔드 서버에  요청 

 

장점

• 프론트엔드에서 S3에 직접 이미지를 전송하고 서버에는 S3 ImageUrl만 요청하므로 서버 부하가 적다.
• 사용자 입장에서 이미지 업로드 시 미리보기를 할 때 미리보기 되는 이미지 로딩이 상대적으로 빠르다. (네트워크를 적게 거치므로)

 

단점

• S3를 업로드 하는 주체와 DB 저장 주체가 다르기 때문에 데이터 싱크가 맞지 않을 수 있다.
  • S3에 업로드를 한 후, 서버에 이미지 업로드 요청을 보냈을 때 요청이 실패한다면 S3에 저장된 이미지도 삭제해야한다.
  • 서버에서 이미지 Url을 DB에 저장 시 S3에 해당 이미지가 존재하는지 체크해야한다.
•  프론트엔드에서 S3에 접근하기 때문에 보안 문제가 발생할 수 있다.

 

저희 팀바팀에서 프론트엔드에서 S3 업로드를 하기로 결정한 이유는 위에 굵게 표시한 이유가 크리티컬했습니다.

백엔드에서 S3 업로드를 했을 때 사용자, 서버 입장에서 단점이 너무 크다고 생각했기 때문입니다.

물론 프론트엔드에서 S3 업로드 시에도 고려할 부분이 많았지만, 차차 생각해보고 결정하기로 했습니다!

---

이렇게 우선 이미지 업로드는 S3로, 프론트엔드에서 진행하기로 결정이 됐습니다.

2편에서는 프론트엔드에서 S3에 이미지 업로드를 진행할 때의 문제 상황과

이를 해결하는 방법을 요구사항과 엮어서 포스팅할 계획입니다! 🙇🏻‍♂️