게시판에서 사용자가 질문 글을 작성할 때,
간단하게 사용자가 이미지 1개를 올릴 수 있는 기능을 개발하기로 결정했으므로
어떤식으로 이미지를 업로드할지 고민했다.
우선 이미지 업로드는 그 전 팀프로젝트에서 한번 경험해보긴 했지만,
이미지를 EC2서버에 저장하는 형태였기에 확장성에 있어 부족한점이 많고, 파일이 유실될 가능성도 존재하기에 업로드 방식을 바꿔 진행하기로 결정.
AWS S3 를 사용하기로 했다.
Client -> Server -> S3 순으로 업로드가 진행되고
S3 -> Server -> Client 순으로 다운로드가 진행되는 구조를 이용하기로
구상을하면서 가장 고민이 됬던점은 MIME Type (미디어타입) 결정이였다.
Octet-Stream을 이용할지 MultiPart를 사용할지
공부를 위해 구글링중 우아한형제들 기술 블로그를 통해 각각의 장단점을 비교해봤다.
출처: https://techblog.woowahan.com/11392/
Spring Boot에서 S3에 파일을 업로드하는 세 가지 방법 | 우아한형제들 기술블로그
Spring Boot에서 S3에 파일을 업로드하는 세 가지 방법 | 안녕하세요. 세일즈서비스팀에서 전자계약서 시스템을 개발하고 있는 박민규입니다. 최근 저는 Spring Boot + Kotlin을 활용한 프로젝트에서
techblog.woowahan.com
S3로 파일 업로드를 진행할 때 3가지 방식이 존재한다.
- stream
- multiPart
- AWS MultiPart
AWS MultiPart의 경우 진행 상태 표시가능등 이점이 존재하지만 AWS 의존성이 높으므로 탈락
multiPart와 stream이 남게됬다.
심사 숙고 후 결정은 Stream 을 이용하기로 했다.
이유는 이렇다.
- Server의 디스크나 힙 메모리에 용량을 거의 남기지 않는다는점
- 파일의 크기가 크지않고 가벼운 이미지파일 전용 업로드라는 점
- 웹 어플리케이션 정책이 게시물당 하나의 이미지만 존재하는 간단한 구성
Server의 디스크나 힙 메모리에 용량을 거의 남기지 않는다는점
Multipart를 이용하는 경우 데이터가 서버 임시 디렉토리에 저장이된다고한다. ( 정확히는 서블릿 컨테이너 디스크 )
Stream은 그에비해 바이트 코드로 깔끔하게 전송되므로 디스크나 힙메모리에 데이터를 남기지않는다는점이
유지보수에 편리하겠다 생각했다. ( 유지보수가 편할수록 생명주기가 긴 소프트웨어가 될거라 생각한다. )
파일의 크기가 크지않고 가벼운 이미지파일 전용 업로드라는 점
Stream의 단점으로 업로드 현황을 사용자에게 알려 줄 수 없다.
만약 단순한 이미지파일이 아닌 대용량의 이미지라던가 비디오 파일이라면
사용자는 업로드 버튼을 누르고 멍하니 완료될때까지 텅 빈화면을 보며 기다려야될것이다.
작은 용량에 이미지파일을 업로드하기로 결정했으니 이 단점은 큰 문제가 되지않았다.
웹 어플리케이션 정책이 게시물당 하나의 이미지만 존재하는 간단한 구성
프로젝트 시작부터가 혼자서 직접 클라이언트 서버부터 백엔드 그리고 AWS 배포등 간단한 DevOps 이해를 위한 학습을 목적으로 시작됬기에 규모가 큰 사이트를 상정하지않고 개발에 들어갔다.
하나의 API에 단 한개의 이미지만 업로드하는점이 단점이긴하지만 그 단점이 나의 프로젝트에 영향을 끼치진 못했다.
이유가 하나 더 있긴한데
지난 팀프로젝트에서 이미 멀티파트 방식으로 업로드를 한번 진행해봤기에
이번에는 octet-stream을 사용하기로 결정하자라는 마음도 있었다.
구현을 마치고 드는 생각은
멀티파트에 비해 구현이 간편하다 라는 생각이 컸다.
request에 담긴 바이트코드를 그대로 amazonS3Client에 보내주기만 하면 업로드가 진행된다.
하지만 뭐든 트레이드오프가 존재하는점..
애초에 서버로 오는 요청자체가 바이트 코드만 날라오기때문에
해당 파일에대한 정보가 하나도 업다.
콘텐츠 타입이라던지... 파일명이라던지 ...
Multipart의 경우 여러가지 파일에대한 메타데이터가 존재해 데이터를 검증하고 가공하는데 훨씬 편리했다.
또한 바이트 코드만 날라와 여러개의 파일을 동시에 업로드 할 수 없단점 또한 아쉬웠다.
( 화면에 이미지 업로드 버튼을 여러개 만들면 되겠지만... )
결론은....
사이트의 규모가 커지고 업로드에대한 비지니스 로직이 점차 더 생긴다면
멀티파트로방식으로 변경하는게 맞겠다 생각이 들었다.
1차배포 후 추후에 멀티파트로 방식을 변경할 생각도 크다.
'Project > TomorrowLand' 카테고리의 다른 글
Axios를 이용해 BinaryFile Upload 하기 (0) | 2024.01.30 |
---|---|
JWT Token, Cookie ? LocalStorage ? (0) | 2024.01.27 |
Testable Code 작성을 위한 노력 1 (0) | 2024.01.11 |
테스트 케이스를 작성하지말자. (0) | 2024.01.11 |
조회수 동시성문제 비관적 Lock을 선택한이유. (0) | 2024.01.08 |