Serverless는 현재 많은 개발자들이 관심있게 지켜보고 사용하고 있습니다.
그중 Fass의 기능으로 유명하며 한번쯤은 들어보셨을만한 AWS의 Lambda에 대해서 이번 포스팅에서 자세히 한번 알아볼까 합니다.
# Lambda?
혹시 람다가 어떤건지 모르시는 분들이 계실까봐 아래 링크를 첨부합니다
https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/welcome.html
AWS Lambda를 사용하면 사용자는 자신의 코드에 대해서만 책임을 갖습니다. AWS Lambda는 메모리, CPU, 네트워크 및 기타 리소스의 균형을 제공하는 컴퓨팅 플릿을 관리합니다.
즉 개발자는 Lambda를 사용하면
개발한 코드만 집중하시면 됩니다.
코드가 동작하는 하드웨어의 CPU, Network, Memory등의 사항들은 신경쓸 필요 없이 개발자가 세팅한 값에따라 관리가 되어지고 요청한 request에따라 Lambda에서 특정 코드를 실행시켜준다!라는 내용인거죠
그러나 람다는 코드만 실행 시켜주는 역할이지 HTTP같은 다른 Action을 람다에 붙이고 싶으시면 다른 서비스를 이용해서 람다에 trigger해야 합니다.
한가지 가정을 해보겠습니다
선임): Dayzen씨 이번에 저희 프로젝트로 사용자가 올린 코드를 가지고 Auto scaling, 프로비저닝, 자동 조정 및, Full manage한 Fass서비스를 개발하기로 했습니다. 부탁드릴게요
Dayzen): 네…??
네… 막상 할려고 보면 막막하고 눈물이 나네요…
그렇지만 세상은 넓고 능력자 분들은 많습니다
그렇기에 Lambda가 공개가 되었겠죠
완벽하게 따라할수는 없겠지만 천천히 알아봅시다!
# Setup?
먼저 람다에 올린 코드가 어떻게 설정 및 실행 되어지는지 이해를 해봅시다.
Process는 다음과 같습니다.
Downlaod your code
Lambda가 실행하기전 올린 application code를 s3에서 download하는 단계
Start new container
실제로 download한 code가 실행되는 container를 생성하는 단계입니다.
이부분은 좀 더 뒤에 설명하겠습니다.
Create, Attach VPC ENI
먼저 해당하는 부분은 이미 변경 되었습니다.
그렇다면 어떤점이 변경이 되었나? 하고 보기전에
위 사진에서는 cold start task마다 ENI를 생성 및 람다에 할당을 진행합니다.
람다가 실행되는 동안 람다의 실행환경에 인터넷 엑세스의 권한은 존재하지않습니다.
그렇기에 람다는 VPC안에서 통신을 하기위해 여러 subnet의 ENI에서 각 private한 ip를 할당 받았습니다.
즉 lambda가 생성 및 auto scaling에 따라 ENI의 생성 및 람다에 private한 ip를 할당 받는 방식이었기에
요청에 따라 cold start 시간도 늘어나는 선형적 구조였었습니다.
그러나 현재의 방식은 각 람다가 생성 및 VPC가 update될경우 기존처럼 각 람다에 private ip를 할당하는 방식이 아닌
사전에 생성해놓은 VPC와 VPC를 연결하고 있는 NAT를 사용하는 방식으로 진행해서 cold start의 문제를 줄였다고 합니다.
실제로 14초에서 0.9초 정도로 시간을 줄였다고 하네요
더 자세한 내용을 원하신다면 아래의 링크에서 확인하실수 있습니다!
https://aws.amazon.com/ko/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
Bootstrap runtime
여러분들의 코드가 실행되는 runtime의 설정(nodejs12, python등등…) 또한 handler함수 밖의 global한 코드를 실행합니다.
const some = require("some-sdk"); // 이부분!exports.handler = async(event, context) {
console.log(await some.hello());
}
또한 여러분들이 원하는 custom runtime도 설정이 가능합니다
Start your code
cold start의 작업이 끝나고 user가 요청한 lambda의 async, sync, poll등의 이벤트를 람다 api를 통해서 호출한 함수의 실행이 되어집니다.
현재 warm상태라고 하는데 람다의 특징 중 하나가 특정 시간 이내로 다시 호출이 없다면 해당 lambda를 활성화를 하지않습니다.
그 뒤에 다시 재요청이 들어오면 위의 flow를 반복하는거죠
Q) cold start를 하는데 있어 가끔요청을하는데 바로 실행을 해야하는 로직이 있는데 람다에 계속 주기적으로 요청을 해서 warm state를 유지하는 방식으로 해야하나요??
A) 그렇지 않습니다 aws에서 Provisioned Councurrency lambda의 호출 수를 설정 할 수 있게 지원을 하고 있습니다.
즉 설정해놓은 람다는 sleep상태로 빠지지 않는것이죠
https://aws.amazon.com/ko/blogs/aws/new-provisioned-concurrency-for-lambda-functions/
# Component of the lambda
Application Load Balancer
Layer7에서 동작하는 Load Balancer로 user들이 invoke하는 각 request들을 어떤 AZ의 FrontEnd로 route할지에 대한 기능
FrontEnd
user들이 보낸 request를 전달받고 validation한뒤 worker manager에게 전달
Worker Manager
worker의 resource가 요청을 받기에 괜찮은지 검증 및 만약 worker들의 resource상태가 좋지 않다면 placement service에게 worker생성의 요청 및 user의 reqeuset를 worker에게 할당
Placement service
worker의 생성 및 자원의 관리를 효율적으로 사용할 수 있게 담당
Worker
만들어진 sandbox내에서 올린 code의 enviorment의 보안 관리 및 실제로request 요청된 함수의 코드 실행
Count service
Concurrency제한 및 실제로 얼마나 요청이 들어왔는지에 대한 확인 및 tracking하는 서비스
물론 위 서비스들은 예시를 돕기 위해서 하나, 두개의 인스턴스만 표시되어있지만 실제로는 수많은 서비스들이 띄워져서 관리가 되고 있을것입니다.
# Execution environment of the lambda
Worker가 실행되는 환경도 결국 EC2 기반에서 실행되고 관리가 되어집니다.
결국 사용하기에 code만 올리면 동작하기에 EC2와 다른 환경이라고 생각하실수도 있지만 실은 Lambda도 EC2와 같은 instance내에서 관리가 된다는걸 알 수 있습니다.
그런데 어떻게 수많은 Worker를 관리하고 각 Lambda내의 충돌 및 security를보장하는걸까요?
AWS에서는 위의 사진에서 MicroVM이라고 표시되어있는 block의 open source인 firecracker를 공개 했습니다.
firecracker는 하나의 Lambda worker에서 적게는 수백, 수천까지의 micro vm을 매우 빠르게 생성, 삭제, 확장 및 보안이 독립되어있는 환경에서 보장해준다고 합니다.
worker가 어떻게 내부적으로 작동되는지에 대해서는 https://youtu.be/QdzV04T_kec?t=1209 해당 url에서 확인하실수 있습니다.
마무리
람다를 사용하는데 있어서는 람다가 어떻게 구성되고 동작하는지 굳이 알아야할 필요는 없습니다.
그러나 사용을 한 것과 아는 것은 다른 개념이라고 생각했기 때문에 제가 아는 내용과 찾아보면서 정리했던 내용을 이번 포스팅에 담았습니다.
여러분들도 보고 쓱 넘기는게 아닌 테스트해보고 알아가면서 여러분의 지식으로 만드시길 바라겠습니다.
참고 사이트
- https://medium.com/@shouldroforion/battle-of-the-serverless-part-2-aws-lambda-cold-start-times-1d770ef3a7dc
- https://www.youtube.com/watch?v=QdzV04T_kec
- https://aws.amazon.com/ko/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
- https://dev.to/sosnowski/anatomy-of-aws-lambda-1i1e#event-and-context
