Categories
Tags
478 words in content
4 minutes for read
Nginx의 정적 파일 연결을 이용한 Local Image Storage 적용
인식한 상황
해커톤에서 이미지 저장 및 제공 방식을 결정할 때, 일반적으로 S3, Object Storage 등을 사용하여 안정적이고 확장성이 뛰어나지만, 학생의 제한된 재정 상황을 고려하여 처음부터 배포되고 운영될 만한 서비스가 맞을까라는 생각을 했다. 그래서 초기에는 Spring을 통해 이미지를 읽고 응답하는 방식을 사용했으나, 이는 서버의 부담이 커지고 전반적인 성능 저하가 발생하는 문제를 확인했다.
해결 과정
이 문제를 해결하기 위해 Docker Network로 구성된 환경에서 Spring, Nginx을 사용하고 있는 상황에 어떻게 처리하면 좋을지 고민하던 도중 이전 Nginx의 문법을 공부하던 자료에서 alias를 생각했다. 기존 로직에서 다음과 같이 변경했다.
- 이미지 저장: Spring을 통해 처리
- 이미지 조회: Nginx 단에서 /image/~ 요청이 오는 경우 image directory의 이미지를 직접 반환
또한, Host의 Directory와 Container 내의 Directory를 Bind시켜 Docker를 사용하여 배포된 Spring에서 해당 디렉토리에 저장되도록 했다.
이미지 저장(Spring)
@Value("${spring.image.path}")
private String FOLDER_PATH;
public String uploadImage(Long useId, ImageUseType imageUseType, MultipartFile file) throws IOException {
// File Path Fetch
String uuidImageName = UUID.randomUUID().toString() + "_" + file.getOriginalFilename();
String filePath = FOLDER_PATH + uuidImageName;
// File Upload
try {
file.transferTo(new File(filePath));
} catch (Exception e) {
throw new RestApiException(ErrorCode.FILE_UPLOAD);
}
return uuidImageName;
}
이미지 조회(Nginx)
location /images {
alias /root/resources/images/;
}
Architecture
결과
이후 프론트에서는 S3의 경로를 통해 Image를 들고 오는 것과 같이 사용할 수 있었다.
또한, 달력 화면에서는 매우 작은 이미지 View가 있다는 점에서 리사이즈 로직을 해커톤의 시간상의 문제로 넣지 못한 점이 아쉽게 남았다.