Lambda 운영 환경 정보(콜드 스타트 및 핫 스타트)

개시하다

지난해 Operating Lambda 시리즈의 번역판이 aws 블로그에 공개됐다.

람바다를 이용하는 개발자에게 알아야 할 것을 담은 블로그로, 3개로 구성됐다.이번에는 내용에서 람다의 차가운 시동과 따뜻한 시동에 관한 일부 글을 발췌했다.

콜드 스타트, 지연 시간, 예열 시작
다음 그림은 Lambda 함수에서 수행된 request에서 처리 함수를 수행할 때까지 프로세스를 나타냅니다.
Lambda는 Lambda API를 통해 함수를 수행할 때 다음 작업을 수행합니다.
1: S3 구간에서 실행할 코드를 다운로드하거나 컨테이너 포장을 사용할 때 ECR에서 다운로드한다.
2: 지정된 스토리지, 실행 시간 및 다양한 설정에 기반한 환경을 만듭니다.
3: Lambda의 프로세서 함수 이외의 초기화 코드.
4: Lambda의 프로세서 함수 실행

람다의 콜드 스타트는 코드 준비 및 환경 준비 단계입니다.

lambda의 냉장고 가동은 매우 유명하고 요금 대상도 이 냉장고가 시작될 때 발생하는 최초의 환경 준비에 포함되지 않는다.

사실 lambda는 반드시 냉장으로 시작하는 것은 아니다.

람다의 실행이 완료되면 람다는 실행 환경을 불특정 기간에 유지한다.

따라서 이때 같은 함수에 대한 요구가 있으면 람바다는 환경 재활용을 한다.

콜드 스타트와는 달리 콜드 스타트 절차(코드 준비 및 환경 제작)를 생략했기 때문에 온기 스타트다.
실행 환경의 생명 주기

Lambda는 함수를 실행한 후 이 환경을 즉시 버리지 않습니다.

단, 환경이 폐기될 때까지 기간을 지정할 수 없습니다.

람다의 예열 가동을 성능 최적화로 삼고 예열 가동에 의존하는 것은 좋지 않다.

람바다는 AZ 관리 전반에 걸쳐 수행되는 서비스이기 때문이다.
이에 따라 시행되는 람다는 이후 몸풀기가 시작될 것으로 예상했으나 콜드스타트일 가능성도 있다.
=> 또한 Lambda 배율 조정 시 함수 추가가 발생했다고 가정합니다.이렇게 되면 이런 상황에서도 새로운 실행 환경을 만들고 추가 부분의 함수에 대해 추워지기 시작한다.
=> 이외에 새 버전의 코드만 사용하여 코드를 업데이트하고 함수를 수정하는 별명을 설정하면 실행된 환경은 버려집니다.이런 상황에서도 썰렁한 시작이다.
람바다가 안정적으로 몸풀기를 시작할 수 있도록 하는 방법(Event Bridge를 이용해 1분 간격으로 함수 호출을 하는 방법)도 있지만, 공식 블로그에 이런 방법으로는 콜드스타트를 줄일 수 없다고 기재돼 있다.
성능 최적화
Lambda 기능에는 Provisioned Conceurrency가 있습니다.이것을 사용하면 냉각 시동이 줄어든다.
Provisioned Conceurrency 기능은 환경을 사전에 준비하여 동시에 실행하는 기능을 말합니다.
준비의 범위로서 사전에 실행 코드의 준비, 환경의 제작, 처리 프로그램 이외의 초기화 코드의 집행을 구축한다.
이를 통해 해결된 과제는 두 가지다. 하나는 초기 점방이 완전히 추워지고 지연이 커지는 과제, 하나는 스매시가 점방될 때 축소해서 따라가지 못하는 과제다.
음, 이 부분의 비용은 Provisioned Conceurrency 비용 + 요구 비용 + 계산 비용으로 주의해야 할 부분입니다.

인용원