AWS에 이미지를 업로드하는 방법 정리
방법 1) 서버에 이미지 저장
기본 이미지 저장 방법이다. 사용자가 이미지를 업로드하고 서버가 로컬로 디스크에 저장한다.
작은 파일
1) 장점
파일 업로드가 적으면 일반적으로 서버에 너무 부담을 주지 않으며 이미지를 저장하는 프로세스가 간단하다. 외부 서비스에 의존하지 않고 이미지 처리와 스토리지를 완전히 관리할 수 있다.
2) 단점
서버 한 대가 이미지를 저장하기 때문에 이미지 제공은 최적이 아니다. 사내 CDN을 사용하지 않은 경우 전송 속도는 서버 대역폭과 위치에 따라 달라진다. 또한 이 접근법은 시스템에 단일 장애점을 발생시키기 때문에 확장 가능한 방법이 아닐 수 있다. 그러나 이 접근법은 규모나 규모가 너무 커지지 않는 것으로 알려진 소규모 프로젝트에 있어서는 우수한 초기 접근법이다.
대용량 파일
일반적으로 큰 파일은 문제를 일으키기 때문에 100MB 이상의 파일을 저장하려면 이 방법을 권장하지 않는다.
1) 장점
유일하게 생각할 수 있는 장점은 고객의 데이터에 대한 완전한 액세스와 스토리지 제어이다. 제어는 기밀 데이터를 저장할 때 도움이 되지만, 적절하게 수행하면 클라우드에서 쉽게 보호할 수 있다.
2) 단점
서버 관리와 확장에 최악이다. 서버 비용, 관리 오버헤드, 장애 보호, 일반적인 운영 비용, 백업 등에 대해 생각해야 한다. 네트워크 대역폭도 마찬가지로 영향을 받는다.
방법 2) 서버에 일시적으로 저장하고 프로세스를 실행하여 AWS에 업로드
클라우드와 로컬 하이브리드 방법이다. 사용자가 이미지를 업로드한다. 서버는 이미지를 일시적으로 디스크에 저장하고 처리를 실행한 후 클라우드에 업로드한다.
작은 파일
장점
이 접근법은 작은 파일 제어와 확장성의 최적의 균형을 이룬다.. 이미지 사전 업로드와 비용 절감, 확장성 향상, 간단한 CDN 통합 등 클라우드 스토리지로 인한 모든 장점을 처리할 수 있다. 이미지 디스크의 사용 간격은 요청 수명 동안만이며 소규모 서버를 도입할 수 있다.
단점
동시 요청 트래픽이 급증하면 서버의 스토리지와 메모리가 급속히 소비될 수 있기 때문에 주의가 필요하다. 트래픽이 급증하면 장치의 스토리지 부족으로 인해 요청이 실패할 수 있다. 이 문제는 AWS의 ASG(AutoScaling Group)를 사용하여 특정 서버 파라미터에 새로운 인스턴스 전개를 트리거함으로써 적절하게 해결할 수 있다. 예를 들어, 서버의 스토리지 또는 메모리(또는 둘 다)의 사용률이 70%에 달했을 때, 새로운 인스턴스의 회전을 트리거할 수 있다.
대용량 파일
장점
업로드하기 전에 이미지 처리를 완전히 제어한다.
단점
스토리지, 확장성, 콘텐츠 전송을 스스로 유지하고 싶은 경우를 제외하고 대용량 이미지 저장은 문제가 된다. 예를 들어 디스크에 이미지를 저장하지 않은 경우 서버 메모리가 병목 현상이 발생한다. 그 결과 메모리가 금방 소진될 수 있다. 동시에 대량의 요구를 수신하면 디스크 영역도 문제가 되고, 물론 네트워크 대역폭에도 영향을 미친다.
방법 3) S3 버킷에 직접 업로드
서버리스 또는 대부분 클라이언트만의 접근 방식. 사용자는 이미지, 서버 또는 서버리스 기능을 업로드하고 해당 이미지에 대한 사전 서명 S3 URL을 생성한 후 클라이언트에서 S3 버킷으로 직접 업로드한다.
작은 파일
장점
이 접근법의 일반적인 케이스는 서버리스이다. 따라서 서버 메모리나 스토리지 제한에 대해 걱정할 필요가 없다. 직접 업로드하면 네트워크 부하가 크게 줄거나 완전히 제거된다.
단점
이 접근법의 가장 중요한 단점 중 하나는 워크플로우 제어가 손실된다는 것이다. 예를 들어, 사용자가 직접 이미지를 업로드하는 것처럼 이미지를 업로드하기 전에 처리나 최적화를 수행할 수 없다. 콜드 서버리스 기능에 히트하면 최대 10초(또는 그 이상)의 대기 시간이 발생할 가능성이 있다. 작은 이미지의 경우 이는 허용되지 않으며, 이전 접근 방식을 사용하면 보통 2초 미만이 되므로 사용자 경험이 손상된다. (5MB 이하 이미지의 경우)
대용량 파일
장점
이 접근법이 가장 유용한 케이스이다. 대량의 람다 대기 시간이 발생하더라도 큰 파일 업로드에는 상당한 시간이 걸릴 것으로 예상된다. 직접 업로드를 통해 서버 제한 및 스토리지 제약이 사라지고 이미지 및 파일 업로드 이외의 실제 서버 요구에 최적의 네트워크 대역폭을 사용할 수 있다.
단점
업로드하기 전에 제어를 할 수 없다는 것 외에는 없다.
방법 4) 동적 접근 (Dynamic Approach)
상황에 따라 각각의 접근 방식을 사용하는 것이다. 이 경우 첫 번째 접근법은 가치 이상의 문제를 일으킨다고 저는 주장하지만 하이브리드 접근법과 서버리스 접근법을 동적으로 사용하여 양쪽 세계를 최대한 활용할 수 있다. 하이브리드 접근법(소규모 파일의 경우)을 사용하여 소규모 이미지와 파일의 제어와 처리를 유지하면서 클라우드 확장성과 관리의 이점을 누리고 있습니다. 서버리스 기능에 의존하여 실행 전에 웜업 할 필요가 없기 때문에 사용자를 위해 업로드 속도를 빠르게 하고 있다. 대용량 파일일 경우에는 서버리스 접근을 하면, 대역폭, 메모리, 스토리지의 제한 등, 여기서 설명한 모든 과제를 해소할 수 있다.
'development' 카테고리의 다른 글
타입스크립트(typescript) 클린코드 (0) | 2022.12.01 |
---|---|
타입스크립트 인터페이스 선언 머지 (Interface Declaration Merging) (0) | 2022.12.01 |
초보자를 위한 리액트(React) 개발 팁 (0) | 2022.11.30 |
Gatsby 사이트에 애드센스(AdSense) 적용하기 (0) | 2022.11.29 |
Phaser 개발환경 세팅 (0) | 2022.10.04 |