AWS Lambda에 대해 더 살펴보자 (2) - Lambda Snap Start, CloudFront 함수와 Lambda@Edge 차이점까지

 

#0 Lambda SnapStart

Lambda SnapStart는 Lambda함수의 성능을 높이기 위한 기능인데

Java 11이상에서 실행되는 Lambda함수들을 추가 비용 없이 성능을 최대 10배 높여준다고 한다. 

...

어떻게 성능을 높여준다는 걸까?🤔

Lambda호출은 몇 개의 수명 주기 단계가 있는데 SnapStart가 비활성화되어있고 Java에서 실행 중인 Lambda함수가 있다면 Lambda함수가 호출되었을 때 우리의 Java 코드가 초기화된 후에 호출되고 shutdown(종료)될 것이다.

그런데 Snap Start가 활성화되어있으면 함수가 미리 초기화된 상태에서 호출될 것이다. 즉, 처음에 함수 초기화가 없다는 의미이다. Snap Start를 활성화하면 Java에서는 굉장히 오래 지속될 수 있는 초기화 단계가 없어지고 바로 호출 단계로 넘어가게 된다.

=> 이게 또한 무료인 기능이라 좋다!

 

<작동 방법>

새로운 Lambda 버전을 발행할 때 Lambda가 우리의 함수를 초기화할 것인데 이 초기화 단계가 미리 진행되어 있을 것이다. 그 이후에 메모리와 초기화된 함수의 디스크 상태의 스냅샷이 생성된 후 마지막으로 이 스냅샷이 저지연 액세스를 위해 캐시될 것이다

=> 이는 우리의 함수가 SnapStart, 즉 빠른 시작을 할 수 있도록 한다!

 

#1 Edge - 커스터마이징

보통은 함수와 애플리케이션을 특정 region에서 배포하지만 CloudFront를 사용할 때는 Edge Location을 통해 콘텐츠를 배포한다. mordern 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구하기도 한다.

=> 이것을 Edge Function(엣지 함수)라고 하며 CloudFront 배포에 연결하는 코드이다.

...

이 함수는 사용자 근처에서 실행하고 지연 시간을 최소화하는 것이 목적이다.

(CloudFront에는 CloudFront 함수와 Lambda@Edge가 있다 => 각각 언제 필요한지와 차이점은 바로 아래 챕터에서!)

(추가로 Edge 함수를 사용하면 서버를 관리할 필요가 없다 => 전역으로 배포되기 때문)

 

#2 CloudFront 함수의 원리와 활용하는 법

일반적인 CloudFront의 요청 처리 과정은 아래의 그림과 같다.

CloudFront에 클라이언트가 요청을 보내는 것을 viewer request(뷰어 요청 - 클라이언트가 뷰어)이라고 하는데 그런 다음 CloudFront가 origin request(오리진 요청)을 origin 서버에 전송한다. 서버가 CloudFront에 origin response(오리진 응답)을 보내고 CloudFront가 클라이언트에게 viewer response를 전송한다. 

 

CloudFront 함수는 JavaScript로 작성된 경량함수인데 viewer response와 request를 수정할 때에만 사용한다. 그리고 확장성이 높고 지연 시간이 민감한 CDN 사용자 지정에 사용된다.

CloudFront가 viewer로부터 request를 받은 다음에 viewer request을 수정할 수 있고 CloudFront가 viewer에게 response를 보내기 전에 viewer response를 수정할 수 있다.

=> CloudFront의 네이티브 기능으로 모든 코드가 CloudFront에서 직접 관리된다. 그래서 고성능, 고확장성이 필요할 때 viewer request와 viewer response에만 사용된다.

 

#3 Lambda@Edge

이 함수는 Node.js나 Python으로 작성하고 초당 수천 개의 request를 처리할 수 있다.

모든 CloudFront 요청 및 응답을 변경할 수 있다.

viewer request는 앞서 본 대로이고 origin request는 CloudFront가 origin에 request를 전송하기 전에 수정할 수 있다.

origin response는 CloudFront가 origin에서 response를 받은 뒤에 수정된다.

viewer response는 CloudFront가 viewer에게 response를 보내기 전에 수정된다.

(함수는 한 region에만 작성할 수 있는데 CloudFront 배포를 관리하는 region과 같아야 한다)

함수를 작성하면 CloudFront가 모든 Location에 해당 함수를 복제하는 방식이다!

 

#4 CloudFront 함수와 Lambda@Edge 차이점

차이점은 한 눈에 보기 쉬운 AWS 공식 자료가 있어서 가져와본다

	CloudFront 함수	Lambda@Edge
프로그래밍 언어	JavaScript (ECMAScript 5.1 호환)	Node.js 및 Python
이벤트 소스	- 최종 사용자 요청 - 최종 사용자 응답	- 최종 사용자 요청 - 최종 사용자 응답 - 오리진 요청 - 오리진 응답
Scale	초당 10,000,000건 이상의 요청	리전별 초당 최대 10,000건의 요청
함수 지속 시간	서브밀리초	최대 5초(최종 사용자 요청 및 최종 사용자 응답) 최대 30초(오리진 요청 및 오리진 응답)
최대 메모리	2MB	128~3,008MB
함수 코드 및 포함된 라이브러리의 최대 크기	10KB	아니요(최종 사용자 요청) 예(오리진 요청, 오리진 응답 및 최종 사용자 응답)
네트워크 액세스	X	O
파일 시스템 액세스	X	O
요청 본문에 대한 액세스	X	O
위치 정보 및 장치 데이터에 대한 액세스	O
안에서 완전히 빌드하고 테스트할 수 있는지	O	X
함수 로깅 및 지표	O	O
요금	프리 티어 이용 가능, 요청당 청구	프리 티어 없음. 요청 및 함수 기간에 따라 요금이 청구

 

#5 차이점에 따른 각각의 Use Case 알아보기

<CloudFront 함수>

- Cache Key를 정규화한다 :

request 속성을 변환해서 최적의 캐시 키를 생성한다. request나 response에 HTTP 헤더를 삽입, 수정, 삭제하도록 헤더를 조작하고 URL을 다시 쓰거나 리디렉션한다.

request를 허용/거부하기 위해 JWT를 생성하거나 검증하는 요청 인증, 권한 부여에도 사용되고 모든 작업이 1밀리초 이내에 이루어진다.

 

<Lambda@Edge>

- 실행시간은 10초가 걸릴 수도 있다. CPU와 메모리가 증가하니 여러 라이브러리를 로드할 수 있고 타사 라이브러리에 코드를 의존시킬 수도 있다. (가령 SDK에서 다른 AWS서비스에 액세스할 수 있도록..!)

- 네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있어 대규모 데이터 통합도 수행할 수 있다.

- 파일 시스템이나 HTTP request에도 바로 액세스할 수 있다 -> 다양항 사용자 지정이 가능하다.