s3를 도입하는 이유

[Combi153]

프로젝트에서 이미지 파일을 다루는 기능이 있습니다.

대표적으로 사용자가 여행 감상에 이미지 파일을 업로드할 수 있습니다. 이러한 이미지 파일은 Web Application Server가 구동되고 있는 EC2 서버 내에 저장됩니다.

이를 그림으로 표현하면 다음과 같습니다.

현재 애플리케이션은 아래와 같은 구조를 띄고 있습니다.

이러한 애플리케이션에서 사용자가 이미지 업로드 요청을 보내면 다음과 같은 과정이 이어집니다.

1. 사용자가 업로드하는 이미지는 MultipartFile 형태로 서버에게 전달됩니다.
2. WAS는 이러한 MultipartFile 을 /images 와 같은 특정 경로에 저장합니다.
3. 이미지를 저장한 경로를 바탕으로 정적 이미지 파일에 대한 URL을 만듭니다.
4. 이러한 URL을 DB에 저장합니다.
5. 사용자가 이미지를 조회하면 이미지 URL을 반환해 볼 수 있도록 합니다.

이미지를 다룰 때 위와 같은 방식은 여러 문제에 노출될 수 있습니다. 그 이유는 다음과 같습니다.

1. EC2 디스크 용량 제한 : EC2 서버는 디스크 용량이 제한적입니다. 사용자가 지속적으로 이미지를 업로드한다면 시간이 지남에 따라 디스크 용량이 한계에 도달할 것입니다. 그때에는 애플리케이션이 정상적으로 구동되지 않을 것입니다.
2. 서버 확장 대비 : 만약 서버가 스케일 아웃을 할 경우, 이미지 파일은 여러 서버에 산재될 것입니다. 이미지 파일이 어떤 서버에 저장되어 있는지 모른다면, 이미지 파일에 직접 접근해야 하는 작업(삭제 등)을 하기 까다롭습니다. 즉, 이미지를 EC2 내부에 저장하는 방식은 서버 확장에 매우 불리한 구조입니다.
3. 백업 및 복구 : EC2 서버 내에 저장된 이미지는 서버가 손상되거나 데이터가 손실될 경우 복구가 어렵습니다. 백업 및 데이터 복구를 위해서는 별도의 노력과 자원이 필요할 것입니다.
4. 성능 : 서버 내에 이미지를 저장하는 방식은 서버의 메모리, CPU와 같은 리소스를 필요로 합니다. 만약 다수의 사용자가 동시에 업로드 요청을 하거나, 요청한 파일의 크기가 크다면 서버의 부하가 높아져 애플리케이션 성능이 저하될 가능성이 있습니다.

S3(Simple Storage Service)는 AWS가 제공하는 스토리지 서비스입니다.

S3를 이용해 이미지 파일을 관리하는 방식은 다음과 같은 특징을 갖습니다.

• S3는 WAS와 무관한 외부 스토리지입니다. 따라서 서버의 확장, 성능 등을 신경쓰지 않고 사용할 수 있습니다.
• S3에는 이미지뿐 아니라 다양한 파일을 저장할 수 있습니다. 각 파일은 1byte부터 5TB까지 허용되며, 파일은 무제한으로 업로드 가능합니다. 따라서 EC2의 디스크 용량을 걱정할 필요가 없어집니다.
• 버전 관리 기능을 제공합니다. S3에 저장된 모든 파일을 버전에 따라 보존, 검색 및 복원할 수 있습니다. 의도치 않은 장애로부터 복구가 가능합니다.

기존의 방식의 단점들을 극복하기 위해 S3를 도입하려고 합니다.