[etc] PT.2 - React 프로젝트 이미지 성능 최적화 시키기 (AWS lambda@edge, cloudfront, S3)

김채운·2023년 10월 25일

etc.

목록 보기

3/9

앞서 온디맨드 이미지 리사이징의 작동순서에 대해서 설명을 했는데 그 안에서 사용되는 AWS 서비스인 lambda@edge, cloudfront, S3가 각자 어떤 역할을 하는지에 대해서 밑에서 알아보자!!

➡️ lambda@edge

Lambda@Edge는 Amazon CloudFront의 기능 중 하나로서 애플리케이션의 사용자에게 더 가까운 위치에서 코드를 실행하여 성능을 개선하고 지연 시간을 단축할 수 있게 해 준다. Lambda@Edge를 사용하면 전 세계 여러 위치에 있는 인프라를 프로비저닝하거나 관리하지 않아도 된다. 사용한 컴퓨팅 시간만큼만 비용을 지불하고, 코드가 실행되지 않을 때는 요금이 부과되지 않는다.

프로비저닝(Provisioning) 이란 의미는 영어 직역한 그대로 "제공하는것" 이다.
어떤 종류의 서비스든 사용자의 요구에 맞게 시스템 자체를 제공 하는 것을 프로비저닝이라고 하며 제공해줄 수 있는 것은 인프라 자원이나 서비스, 또는 장비가 될 수도 있다.

Lambda@Edge는 서버 관리 부담 없이 웹 애플리케이션을 전 세계로 배포하고 성능을 개선하여 효과를 향상해 준다. Lambda@Edge는 Amazon CloudFront 콘텐츠 전송 네트워크(CDN)에 의해 생성된 이벤트에 대한 응답으로 코드를 실행한다. 그러니까 콘텐츠의 전송을 위하여 CDN 종류 중 하나인 cloudFront에 함수를 등록할 수 있는 게 Lambda Edge이다.
코드를 업로드하기만 하면 AWS Lambda가 최종 사용자와 가장 가까운 AWS 로케이션에서 뛰어난 가용성으로 코드를 실행하고 확장하는 데 필요한 모든 작업을 처리한다.

lambda@edge 이벤트 타입

Viewer Request: cloudfront가 사용자 요청로부터 요청을 받고, cloudfront의 캐시가 확인되기전에 함수를 실행한다. 해당 이벤트에 람다를 트리거하면 CloudFront 캐시 여부에 관계없이 매 요청마다 람다가 실행된다.
Viewer Response: cloudfront가 요청한 개체를 뷰어에게 사용자 응답을 전달하기 전에 람다가 실행된다. 해당 이벤트에 람다를 트리거하면 CloudFront 캐시 여부에 관계없이 매 요청마다 람다가 실행된다.
Origin Request: 요청한 개체가 CloudFront 캐시에 없을 때, 오리진으로 요청을 전달할 때 람다가 실행된다. 요청한 개체가 CLoudFront 캐시에 있을 때는 실행되지 않는다.
Origin Response: 오리진으로부터 응답을 수신하고, 응답에서 개체를 캐시하기 전에 람다가 실행된다. 오리진에서 오류가 반환된 경우에도 람다가 실행된다.
* 해당 이벤트에서 원본 이미지 리사이징 처리가 된다.

➡️ CloudFront(CDN)

AWS에서 제공하는 CDN(Content Delivery Network) 서비스이다. 캐싱을 통해서 사용자에게 좀 더 빠른 전송 속도를 제공하는 것을 목적으로 한다. cloudfront의 주요 역할은 전 세계 이곳저곳에 Edge Server(location)을 두고 사용자에게 가장 가까운 Edge Server를 찾아 빠른 속도로 data를 제공하는 것이다. 그래서 cloudfront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 Edge location으로 요청이 라우팅 되므로 가능한 최고의 성능으로 콘텐츠가 제공이 된다.

❓ CDN이란?

CDN(Content delivery network)은 콘텐츠 전송 네트워크로써 지리적으로 분산된 여러 개의 서버로 지리, 물리적으로 떨어져 있는 사용자에게 컨텐츠를 더 빠르고 효율적으로 제공하는 서버의 분산 네트워크 시스템을 말한다. 사용자가 원격지에 있는 서버(Origin Server)로 부터 콘텐츠들(Web Object, Video, Music, Image, Document등)을 다운 받을 때 가까이 있는 서버에서 받는 것보다 시간이 오래 걸린다. 그렇기 때문에 사용자의 물리적 위치와 가까운 엣지(Edge) 서버가 있고 이곳에 위치한 Cache Server에 해당 콘텐츠를 저장(캐싱)하고 콘텐츠 요청시에 Cache Server에서 응답을 준다. 이렇듯 인터넷 서비스 제공자(ISP,Internet Service Provider)에 직접 연결되어 데이터를 전송하므로, 콘텐츠 병목을 피할 수 있고, 전송 속도를 높이게 되면서 사용자는 콘텐츠가 로딩될 때까지 기다릴 필요가 없게 되는 것이다.

📡 Edge location & Regional Edge Cache

Edge location

Edge Location은 CloudFront 서비스가 콘텐츠를 캐싱하고 Client에게 제공하는 지점 혹은 캐시 서버를 의미한다. 즉, 엣지 로케이션은 CDN 서비스와 사용자가 만나는 곳을 Edge라고 하며, 그 Edge가 어느 지역에 위치한 시설을 일컫는다. 전 세계에 여러 장소에 흩어져 있으며, 장소나 환경에 구애를 최대한 받지 않도록 빠른 서비스를 제공하기 위해 전 세계 주요 도시에 Edge Location이 분포되어 있다. 만약 사용자가 요청한 콘텐츠의 캐시가 Edge Location에 있다면 멀리 있는 서버에 직접 요청이 아닌 가까운 Edge Location에 저장된 캐시를 불러올 수 있다.

Regional Edge Cache

리전 엣지 캐시(Regional Edge Cace)는 사용자가 접근할 수 있는 글로벌 하게 배포되어 있는 CloudFront 위치이다. 오리진 서버와 Edge Location 사이에 위치해 있는데, 만일 서비스를 이용하려고 할때, Edge location에 컨텐츠가 없는 경우 Regional Edge Cache에서 검색을 시도하며, 캐시 스토리지 용량이 더 크기 때문에 거대한 범위에서 콘텐츠를 캐싱하고 제공한다. 이는 리전 내에 있는 모든 엣지 로케이션에서 동일하게 캐시된 콘텐츠를 사용할 수 있도록 해준다. 그렇기 때문에 Regional Edge Cache를 사용하면 특정 리전에 있는 모든 엣지 로케이션에서 공유되는 콘텐츠를 이용할 수 있다. 이 REC로 인해 CloudFront가 오리진에 요청하는 것을 줄여준다.

⚙️ CloudFront의 구성요소

Origin Server

원본 데이터를 가지고 있는 서버이다. AWS에서는 S3, EC2 instance를 나타낸다.

Edge Server

에지 서버의 주요 목적은 콘텐츠를 요청하는 클라이언트 시스템에 최대한 가깝게 저장하여 대기 시간을 줄이고 페이지 로드 시간을 개선하는 것으로, AWS 에서 실질적으로 제공하는 전 세계에 퍼져있는 서버이다. Edge Server에는 요청 받은 데이터에 대해서 빠르게 응답해주기 위해 캐싱 기능을 제공한다.

⚙️ CloudFront 작동방식

CloudFront 데이터 전달 과정

클라이언트로부터 Edge Server에 요청이 발생한다.
Edge Server는 요청이 발생한 데이터에 대하여 캐싱 여부를 확인한다.
사용자의 근거리에 위치한 Edge Server 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터를 응답하고, 사용자의 요청에 적합한 데이터가 캐싱되어 있지 않은 경우 Origin Server로 요청이 포워딩된다.
요청받은 데이터에 대해 Origin Server에서 획득한 후 Edge Server에 캐싱 데이터를 생성하고, 클라이언트로 응답이 전달한다.

➡️ S3 Buket

AWS S3는 (Simple Storage Service) 업계 최고의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 객체 스토리지 서비스이다. (* 앞글자의 S가 3개라 S3라고 한다.)
S3를 쉽게 설명하자면, 구글 드라이브처럼 파일을 저장하는 서비스이며, 데이터를 온라인으로 Object 형태로 저장하는 서비스라고 보면 된다. (* 앞에 온라인이라는 글자가 붙는 이유는 데이터 조작에 HTTP/HTTPS를 통한 API가 사용되기 때문이다.)
S3는 REST,SOAP과 같은 단순한 웹 서비스 인터페이스를 사용하고, 저장하는 데이터 양에 대한 비용도 저렴하며 저장할 수 있는 데이터 양이 무한에 가깝다.
S3는 FTP 서버처럼 단순한 파일 저장 영역으로 사용할 수도 있지만, 다양한 AWS 서비스의 사용 로그 저장, 정적 웹 사이트 호스팅 하는 등의 기능들도 가지고 있다. 또한, elastic한 성질 때문에 별도의 스토리지 확장, 축소에 신경쓰지 않아도 된다.

❗ S3 버킷과 객체

S3는 버킷(Bucket)이라는 컨테이너를 놓을 리전을 선택하고, 해당 컨테이너 내부에 객체(Object)라는 형태로 데이터를 저장한다. 버킷은 여러 개 만들 수 있으며, 한 계정 당 Bucket은 최대 100개까지 사용이 가능하고, 버킷 단위로 접근 제한을 설정할 수도 있다. 단, Bucket의 소유권은 이전할 수 없기 때문에 주의해야 한다.
S3에 저장되는 데이터는 모두 객체라고 부른다. 객체는 하나 당 1Byte에서 최대 5TB까지 저장이 가능하며 저장할 수 있는 객체의 수는 제한이 없다. 각 객체는 데이터와 메타데이터를 지니는데 S3 버킷에 올리는 객체가 바로 데이터이고 최종 수정일, 파일 타입 등의 데이터를 메타데이터라고 한다. (메타데이터는 네임-벨류 쌍으로 이우러져 있다.)
객체는 키를 통해서 버킷에서 유일한 것으로 식별될 수 있으며, 버킷에 존재하는 모든 객체는 단 하나의 키를 지닌다. 따라서 S3 내에서 버킷, 키, 버전 ID를 통해 특정 객체를 파악할 수 있다.

버킷

Amazon S3에서 생성되는 최상위의 디렉토리이며, Amazon S3에 저장된 객체의 컨테이너 이다.
S3상의 모든 객체는 버킷에 포함된다.
버킷의 이름은 S3에서 유일해야 한다.
게임 아이디같이 중복될수가 없다. 즉, 전세계에 어디에도 중복된 이름이 존재 할 수 가 없다.
한 계정 당 최대 100개의 버킷 사용 가능.
버킷 주소는 https://bucketname.s3.Region.amazonaws.com 형태로 이루어진다.
버킷을 생성하면 default로 private상태이다.
버킷 소유권은 이전할 수 없다.
버킷 안에 다른 버킷을 둘 수 없다.

객체

객체 하나의 크기는 1Byte ~ 5TB
저장 가능한 객체 갯수 무제한
객체마다 각각의 접근 권한 설정 가능
default로 private 이다.
객체 metadata는 객체가 업로드 된 후에는 수정될 수 없고, 복사해서 수정해야 한다.
객체는 Range HTTP header를 이용해서 부분적으로 검색할 수 있다.
(* 클라이언트가 특정 범위 또는 부분을 요청하여 다운로드할 수 있는 기능을 의미한다. 이것은 크기가 크거나 요청한 데이터의 일부만 필요한 경우에 유용하다.)
객체는 Pre-signed url를 사용해서 다운로드 할 수 있다.
객체의 metadata는 response header에 반환된다.
객체를 그룹화하는 디렉터리를 생성할 수 있다. 따라서 폴더, 파일 처럼 디렉터리를 계층화해서 객체를 저장할 수도 있다.

Pre-signed url?

Presigned URL 이란 AWS 자원에 대한 접근 권한을 제공하기 위해서 사용되는 이름 그대로 사전에 적절한 권한을 가진 자격증명에 의하여 Signed 된 URL 을 말한다.
미리 서명된 URL의 생성자가 해당 객체에 대한 액세스 권한을 보유할 경우, 미리 서명된 URL은 URL에서 식별된 객체에 대한 액세스를 부여합니다. 즉, 객체를 업로드하기 위해 미리 서명된 URL을 수신하는 경우, 미리 서명된 URL의 생성자가 해당 객체를 업로드하는 데 필요한 권한을 보유하는 경우에만 객체를 업로드할 수 있다.

pre-signed url 사용의 이유?

다운로드 같은 경우, 권한이 있는 사용자만 접근할 수 있게
업로드 같은 경우, 권한이 있는 파일 혹은 사용자만 업로드할 수 있도록 만들기 위해서다.
추가로 파일 업로드 같은 경우 백엔드 서버로 파일 업로드를 관리하면 백엔드 서버에 저장 시키거나 S3 에 업로드 하더라도 form-data 로 데이터를 받아 업로드 시켜야 하는데, pre signed url은 백엔드 메모리도 소모되지 않으며 바로 S3에 url를 요청 받아 업로드하면 되니 백엔드 서버 업로드 방식을 최적화 할 수 있다.

객체의 구성요소

S3 Object에는 Key, Value, Version ID, Metadata, CORS(Cross Origin Resource Sharing)와 같은 다양한 구성요소가 존재한다.

Key : 파일의 이름
버킷 내 객체의 고유한 식별자. 버킷 내 모든 객체는 정확히 하나의 키를 갖는다.
버킷, 키 및 버전 ID의 조합은 각 객체를 고유하게 식별한다.
Value : 파일의 데이터
S3은 Key - Value 형태로 저장되지만, Key의 접두어 및 슬래시를 이용하여 폴더 개념 같이 사용 가능하다. 윈도우 파일의 폴더 경로를 조회해보면 \Documents\img\cloud.png 이렇게 되어있는데, 이와같이 url로 /awsinaction/img/cloud.png 같이 구성 되어진다는 말이다.
Version Id : 파일의 버전 아이디
Version ID는 S3의 고유 특징 중 하나이다. 같은 파일이지만 다른 버전으로 올릴 수 있게 돕는 인식표 라고 보면 된다. 만약 이전 버전으로 돌아가고 싶다면, Version ID를 통해 쉽게 복원시킬 수 있다.
MetaData : 파일의 정보를 담은 데이터(최종 수정일, 파일 타입, 파일 소유자, 사이즈 ..등)
ACL : 파일의 권한을 담은 데이터 (접근이나 수정)
Torrents : 토렌트 공유를 위한 데이터
CORS(Cross Origin Resource Sharing) : 버킷의 파일을 지역을 무시하고 다른 버킷에서 접근 가능하게 해주는 기능

참조

김채운

이전 포스트

[etc] PT.1 - React 프로젝트 이미지 성능 최적화 시키기 (온디맨드 이미지 리사이징)

다음 포스트