Serverless아키텍쳐 구성4 - Lambda(람다) 특징 및 한계

1.람다함수의 Life Cycle

1. 해당함수의 코드 찾아서 다운로드
2. 새로운 실행환경 구성(컨테이너시작) //여기까지 Cold start 상태
3. 런타임 부트스트랩
4. 코드 시작

잦은 호출이 되는 람다에게 제공되는 서버는 항상 켜져 있어야 하고,
그렇지 않은 람다의 서버는 꺼져 있어야 한다.
그런데 꺼진 후 다시 사용하려고 할 때 딜레이 발생, cold start 상태

 

 

 

 

2. Cold Start

트리거에 의해 람다가 호출되었을 때 서버가 켜지고 부수적인 세팅이 되기 까지 걸리는 시간
즉, 함수를 처음 호출할때나 업데이트 된 후 실행할 때 어쩔수 없이 발생하는 지연(delay)

 

Cold start가 발생하는 이유? 왜 딜레이가 발생하는걸까? 내부적으로 무슨일을 하길래?

람다의 Function하나를 수행하기 위해서 거쳐야 하는 작업

• Compute substrate : 함수가 실행될 VM
• Execution Enviroment : 환경변수 등 실행환경
• Language runtime : 언어별 런타임, 언어별로 성능차이가 생김(nodejs,python)
• your function : 실행할 함수코드

즉, Compute substrate(?) 위에 Function 컨테이너가 올라가고,
그 위에 runtime언어가 설정이 되면, 람다 안에서 작성한 function이 동작하게 된다.

그래서 람다 function 하나를 수행하기 위해 이런 작업들이 cold start에 영향을 줌

 

*람다의 퍼포먼스에 영향을 주는 것

VPC 내부에 속하는지, conginto나 IAM을 사용해서 인증을 하는지, 언어별 차이에 따라서 지연시간 발생

 

 

 

 

Cold start를 줄일 수 있는 방법은?

3. Warm start

Warm start : 함수가 실행이 완료된 이후에도 한동안 유지가 되는 동안,

다른 이벤트가 발생하면 훨씬 빨리 응답할 수 있는 상태

주기적으로 함수를 호출해서 서버가 내려가지 않도록 warm상태를 유지한다.
서버가 아직 내려가지 않은 따뜻한(warm)상태라면 준비과정을 거치지 않고 빠르게 함수 수행할 수 있기 때문에
ex) 5분동안 요청이 없으면 cold start, 초기에 딜레이 발생하고 warm start되면 빠르게 응답가능

+ warm up 플러그인

https://github.com/FidelLimited/serverless-plugin-warmup

FidelLimited/serverless-plugin-warmup

 

warm상태를 유지했을 때 주의할 점

5분마다 지속적으로 함수를 실행시킨다고 하면 지연이 줄어든다.
하지만, 계속해서 함수를 호출하기 때문에 비용이 추가적으로 발생한다.

컨텍스트가 동일하게 계속해서 유지될거란 보장이 없다.
콜드 스타트를 줄이기 위해서 컨텍스트를 재사용하지만, 어쩔때는 서버가 새로운 컨텍스트를 생성할 수 있음, 그래서 해당 컨텍스트에 저장된 값을 다른 함수에서 재사용해서는 안된다(?)

 

4.람다함수의 성능향상 방법

1)실행환경의 성능개선 : 메모리 추가

메모리를 더 많이 할당할수록 소요되는 시간이 줄어서 성능향상 가능 (더 큰 CPU제공)
물론 그만큼 비용이 증가하지만, 항상 비싸다고 성능이 더 좋다고 할 수 없음.

람다는 호출횟수와 메모리 사용량으로 과금 결정,
그래서 메모리만 적게 쓰면 cpu 또는 네트워크를 많이 사용하더라도 비용이 적을 수도 있다

 

2) 람다함수의 성능개선

콜드스타트일 때 : 함수의처음부터 끝까지 실행
재사용 : 진입점인 핸들러함수만 실행

https://futurecreator.github.io/2019/03/14/serverless-architecture/

서버리스 Serverless 아키텍처 파헤치기

직접 cold상태인지, warm상태인지 확인해볼 수 있나? 딜레이 시간이 몇조인지 확인할수 있나?

Cloudwatch안에서 response시간 차이로 딜레이 시간 계산할 수 있음

방법1. Serverless Framwork에서 대쉬보드 기능으로 확인할 수 있음

-> 그런데 서울리전에서는 지원하지 않는 기능(?)

방법2. Dashbird : 서버리스 애플리케이션 모니터링 툴
dashbird.io : 지연시간 확인할 수 있음

나의 람다함수 대쉬보드

 

 

 

5.서버리스 한계

1)메모리 : 128MB~3GB

람다는 1개의 환경에서 실행된다.  
두개의 호출이 동시에 발생한다해도 1개의 환경에서 마치 두개의 프로세스가 실행되는 것처럼

람다의 인프라는 전체 4GB 정도의 메모리를 갖고 있는데 3008MB까지 사용하지 못한다.
이유 : 4GB시스템에서 1GB는 커널이 차지하기 때문에

 

람다의 한계 :한번에 호출될 때 많은 메모리를 사용하고, 실행시간이 긴 람다일 때 제한
병렬로 호출되면 성능한계가 발생한다.

메모리 변경에 따른 실제 람다 컨테이너의CPU와 메모리 차이

2) 처리시간 : 최대 15분

15분이 초과되는 작업은 람다로 수행할 수가 없음,
그래서 단시간 동안 많은 자원을 필요 하는 작업은 람다와 맞지 않음.

https://aws.amazon.com/ko/lambda/faqs/

AWS Lambda – FAQ

3) 비용

람다는 함수가 수행된 시간을 100ms 단위로 올림해서 과금
API Gateway의 경우 100만 요청당 3.5USD 과금

메모리 크기별 요금