Go, Vantage point
가까운 곳을 걷지 않고 서는 먼 곳을 갈 수 없다.
Github | https://github.com/overnew/
Blog | https://everenew.tistory.com/
티스토리 뷰
Lamdba의 기반인 Firecracker와 microVM
AWS의 Lambda도 결국에는 컨테이너 기반의 서비스이다.
Docker와 같은 컨테이너 서비스보다 훨씬 빠른 반응 속도를 보이는 것은 AWS가 개발한 Firecracker 기반의 가상화 기술을 활용하기 때문이다.
기존의 다양한 서비스보다는 간단한 게스트 기능만을 제공하기 때문에 보안뿐만 아니라 오버헤드까지 줄였다.
이때 사용되는 것이 경량화 가상 머신인 mircoVM이다.
microVM는 약 5MiB의 메모리와 125밀리 초 안에 실행시킬 수 있다고 공식 문서에서 밝히고 있다.
Cold Start와 Warm Start 그리고 성능 향상
Lambda가 이러한 microVM에서 동작하기 때문에 굉장히 빠르지만, 결국에는 초기에는 사용자 코드를 다운로드하고 수행을 시키기까지의 딜레이가 존재한다.
이러한 딜레이는 함수가 처음 수행되었을 때 가장 크게 발생하고 이를 Cold Start라고 한다.
반면, 한번 수행시킨 함수는 재실행시켰을 때 initaliztion 과정이 미리 준비가 되어 있기 때문에 더 빠르게 실행된다.
이러한 수행 방식은 Warm Start라고 한다.
여기서 Warm Start는 위의 Cold Start와 다르게 Execute Initialization 부분도 initaliztion에 포함되는 것이 눈에 띈다.
즉, Lambda의 handler 함수 밖에 있는 전역 부분은 Cold Start 시점에서만 진행되고, 이후에는 해당 값이 유지되면서 재사용된다.
따라서 위의 예시 코드처럼, 항상 os.environ['환경변수']를 통해 환경변수를 가져오지 않아도
lambda_handler() 함수 밖에 배치하여 Execute Initialization 시점에 실행되도록 세팅하면 함수의 최적화가 가능하다.
특히 DB 연결을 전역에서 실행하면, 모든 함수 호출이 DB와 Connection을 만들지 않기 때문에 Lambda 함수와 DB 입장에서도 훨씬 나은 최적화가 가능하다.
이를 시각적으로 표현하면 이와 같다.
Lambda의 동시성(concurrency)
문제는 Lambda는 순서대로 하나씩 호출되는 것이 아니라 동시에 여러개가 호출될 수 있다는 것이다.
따라서 특정 시점에 요청이 몰리면 Cold start는 최대 동시 실행 개수 만큼 일어날 수 있다.
초록선 아래에 숫자가 현재 실행되는 함수의 개수이다.
해당 GIF를 확인하면 최대 동시 실행 개수인 6만큼 Cold start가 일어나는 것을 확인할 수 있다.
예약된 동시성(Reserved concurrency)
문제는 계정당 함수 동시성은 동시에 1000개로 한정되어 있다. (요청시 확장은 가능)
함수 종류에 관계 없이 풀이 가득 차면 동시성 문제로 함수 실행자체가 되지 않는다.
다른 기타 함수로 인해 중요 함수가 실행되지 않는다면 심각한 서비스 문제가 될 수 있다.
따라서 AWS는 특정 함수의 동시성 개수를 예약시킬 수 있다.
아래처럼 두개의 함수를 각각 400개씩 예약하여 최소한의 개수가 동시 실행될 수 있도록 보장한다.
프로비저닝된 동시성(Provisionedconcurrency)
이전에는 Cold start를 방지하고자, 요청이 없더라도 일정 주기마다 Fake 호출을 진행했다고 한다.
하지만 이제 AWS에서 프로비저닝된 동시성을 제공한다.
프로비저닝된 동시성을 사용하면, Warm 환경이 유지된다.
따라서 아래 그림처럼 일반 함수는 텀이 지나면 t3시점에서 초기화되지만, 프로비저닝된 동시성은 계속 Warm 환경이 유지된다.
물론 Warm 상태가 지속적으로 유지되므로 비용이 발생하므로 운영 정보를 통해 적절한 세팅 값을 설정해야 한다.
참조
https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-concurrency.html
https://docs.aws.amazon.com/lambda/latest/operatorguide/execution-environments.html
https://velog.io/@ayoung0073/OS-Firecracker
'Cloud > AWS' 카테고리의 다른 글
[AWS] CloudWatch가 EC2 Memory 모니터링을 제공하지 않는 이유는? (Hypervisor & OS) (0) | 2024.07.20 |
---|---|
Lambda의 VPC 접근을 위한 Hyperplane ENI (0) | 2024.07.19 |
AWS ALB의 Path routing 활용하기 (0) | 2024.07.13 |
AWS Code Build buildspec , 컨테이너 빌드 및 ECR 전송 (Terraform) (0) | 2024.07.06 |
AWS ECS Fargate 모니터링 (2) - AWS Grafana(SAML) (0) | 2024.07.03 |