이미지 저장/조회 서버 만들기(1) - 저장 어디에..?

공지사항 기능을 만들던 중 이미지를 저장해야하는 상황이 생겼습니다.

그 김에 첫번째 일주일 프로젝트로 이미지 저장/조회 api를 만들어보려고합니다.

 

일단 이미지 처리 api를 만들려고하니 받아온 이미지를 어디에 저장해야할지 고민이 되었습니다.

 

고민 1. 이미지 저장은 어디서 해야할까?

기존에 data들은 모두 database에 저장을 하였으니 database에 저장을 그래도 하면 되는걸까?

 

아무래도 이건 아닌 것 같았습니다. 

서버 배포할 때 database의 용량의 크기가 이미지를 저장하는 용도는 아닐것이라 생각을 했거든요.

 

그래서 이미지는 보통 어디에 저장하는지 구글링을 해보았습니다.

 

크게 저장 장소가 3가지 있었습니다.

 

1. database

2. 서버 컴퓨터의 disk

3. 외부 storage

 

하니씩 살펴보겠습니다.

 

1. database에 저장

이미지를 database에 저장하면 어떻게 될까요?

 

할 수는 있을까요?

 

네, 결론적으로 말하면 "할 수는 있으나 비용상 하지 않는다" 입니다

 

이미지를 database에 저장하는 것의 장점과 단점을 알아보겠습니다

 

장점

- 이미지 자체를 트랜잭션에 포함시킬 수 있음 

 

결국에 database에 이미지를 저장하지 않는다하더라도 문자열로 이루어진 이미지가 저장된 주소정도는 저장을 해야됩니다.

 

이렇게 되면 이미지를 다른 곳에 저장하고 저장 위치의 주소를 database 저장하는 2번의 저장 과정이 생기게 되는데요.

 

이때, 2번 중 한번에서 오류가 생긴다면

1. 이미지는 저장되었는데 주소가 기록이 안됨

2. 이미지가 저장안되었는데 주소가 기록됨

 

같은 오류가 발생할 수 있습니다.

 

트랜잭션을 사용할 수 있다면 이와 같은 상황을 방지할 수 있겠죠.

 

단점

- 비용이 비쌈

   : 고성능의 데이터베이스 시스템을 사용할수록 대용량의 이미지 테이터를 저장하면 비용이 비싸질 수 있음

 

- 성능 저하

   : 대용량의 이미지를 저장하면 성능이 저하되고, 데이터베이스의 백업 및 복원 기간도 길어질 수 있음

 

 

2. 서버 컴퓨터의 디스크에 저장

이미지를 컴퓨터 파일 시스템에 저장하듯이 하면 되지 않을까요?

 

결론적으로 말하면, 이것도 "할 수는 있으나 비용상 하지 않는다" 입니다

 

장점

- 이미지 파일을 직접 디스크에 저장하면 빠르고 로컬 파일 시스템을 활용할 수 있음

- 이미지 파일에 쉽게 접근하고 관리할 수 있음

 

단점

- 서버 디스크 공간의 한계 때문에 이미지가 많아질수록 확장성에 제한이 걸립니다. (확장 비용이 비쌉니다)

- 파일 시스템의 백업 및 복구는 데이터베이스보다 복잡합니다.

 

3. 외부 스토리지(예 : AWS S3)에 저장

제가 채택할 방법은 '바로 3번 외부 스토리지에 저장한다' 입니다.

 

그중에서도 aws의 s3라는 파일 저장 서비스를 이용할 계획입니다.

 

장점

- aws s3같은 클라우드 기반 스토리지 서비스는 높은 확장성과 필요에 따라 자동 확장 기능을 제공함

- 데이터 손실 위험이 적음

- 세밀한 접근 제어와 보안 기능을 제공함

 

단점

- 사용량에 따라 비용이 발생

- 네트워크 의존성 때문에 네트워크의 지연 시간이 성능에 영향을 줄 수 있음

 

 

 

결론

 

클라우드 스토리지가 제공하는 높은 확장성과 적은 손실 위험, 보안 기능 때문에 3번을 채택하기로 하였습니다.

 

 

 

다음글

https://preparingfor.tistory.com/7

[일주일 프로젝트] 이미지 저장/조회 서버 만들기(2) - 이미지 파일 어떻게 받아오지?