AWS Lambda

lambda는 aws의 핵심 서비스로 서버를 관리할 필요 없이 작성한 코드를 함수 단위로 실행시킬 수 있다. 요청량에 따라 인프라 걱정 없이 실행되고 사용한 만큼만 과금한다. 이런 serverless의 장점을 바탕으로 aws의 다양한 서비스를 lambda와 결합해서 더 강력한 인프라를 구축할 수 있다.

 

 

Cold start / Warm start

lambda가 최초 실행되어 자원을 할당받아 컨테이너가 구동되고 함수 실행을 준비하는 것을 cold start라 부른다. lambda가 종료돼도 컨테이너는 바로 반납되지 않고 약간의 딜레이를 가진다. 이 시간 안에 다시 lambda가 실행되는 것을 warm start라고 한다. warm start로 기존에 실행했던 컨테이너에서 다시 실행이 된다면 handler 밖에서 실행했던 작업을 재사용할 수 있다.

 

따라서 database connection 같이 오래 걸리면서 재사용 가능한 작업은 handler 밖에서 실행하면 이 이점을 활용할 수 있다. 초기 cold start 시 connection을 맺은 다음에 warm start로 lambda가 실행될 때는 이미 작업한 connection을 참조하기 때문에 connection 작업을 아낄 수 있다.

 

 

Version과 Alias

lambda의 code나 환경 설정들을 변경하고 publish를 하면 새로운 version이 생성된다. version은 1부터 증가하며 latest은 최신을 가리킨다. version이 생성되면 현재 lambda의 snapshot을 만들었다는 뜻으로 수정할 수 없다. 수정은 latest로 옮겨서 해야 한다. 

 

lambda alias는 lambda version을 가리킨다. 단순히 version 하나를 가리킬 수 있지만, 여러 version에 대해 가중치를 설정할 수도 있다. 기존 버전에 90%, 새로운 버전에 10% 가중치 두면 트래픽을 9:1로 라우팅 시킬 수 있다.

 

 

Limit

Concurrency

lambda는 리전 별로 같은 동시성 풀(pool)을 가지고 있다. 같은 리전에 있는 lambda는 그 풀 안에서 자원을 할당받아 동시에 실행된다. 풀 사이즈는 기본 1000개이고 티켓을 통해 더 늘릴 수 있다.

이 기본 사이즈도 항상 사용 가능한 건 아니다. 낮은 수준부터 점진적으로 확장된다. 확장 속도보다 더 짧은 시간에 여러 lambda를 실행시킬 경우 전체 한도는 넘지 않았음에도 불구하고 throttling에 걸리게 된다.

 

throttling 제한에 걸린 경우 호출하는 방법에 따라 다르게 처리한다.

1. sync: Rate exceeded 429 에러
2. async: retry 후 SNS나 SQS로 구현된 DLQ(Dead Letter Queue)로 전달 

 

Reserved Concurrency

다른 역할을 하는 lambda들이 같은 풀을 사용하다 보니 의도치 않게 중요한 lambda가 불필요한 lambda에 의해 실행이 실패할 수도 있다. 이를 방지하기 위해 미리 자신의 풀을 reserved concurrency로 예약할 수 있다. 대신 공동의 풀은 reserved concurrency로 할당한 크기만큼 작아진다.

reserved concurrency를 설정한 lambda는 예약한 풀 외에 공동의 풀에서는 실행이 제한되기 때문에 최대 동시 실행 개수의 의미도 가진다. 이런 제약으로 RDS나 기타 연결된 서비스의 호출을 제어하는데 활용할 수도 있다.

 

Provisioned Concurrency

lambda의 cold start 단점을 보완하기 위해 미리 실행환경을 초기화하고 유지시킬 수 있다. lambda의 특성상 누군가 경험해야 할 느린 응답을 최소화시키는 데 사용한다. provisioned concurrency를 넘어서는 요청에 대해서는 cold start를 겪는 일반 lambda처럼 동작한다.

실행환경을 유지하는 비용으로 구성한 자체만으로도 비용이 발생하고, 실제 사용에 따른 비용도 따로 부과된다.

 

Configure

최대 실행시간은 15 min이고 메모리는 128MB - 3008MB까지 사용 가능하다. CPU 성능은 메모리 성능에 비례한다. 실행 시간 단위로 과금하는 lambda 특성상 적절한 메모리 크기를 설정하는 게 좋다.

 

/tmp 폴더를 최대 512MB까지 사용 가능하다. 재사용할 수 있는 static 한 정보들은 여기에 캐싱해서 lambda 성능을 높이는 데 사용한다. 

 

lambda는 실제 코드를 업로드해서 배포하는데 파일 크기를 최대 250MB, 압축하면 50MB로 제한한다. 의존성 파일까지 모두 합친 크기로 생각보다 제한이 빡빡하다. 또 여러 lambda에서 사용하는 모듈 같은 경우라면 lambda마다 같은 코드를 업로드해야 하는 게 비효율적이다. 

이와 같은 경우에는 lambda layer로 해결할 수 있다. 의존성 파일들로 lambda layer로 생성하고 lambda에서 해당 layer를 추가한다. 그러면 lambda에서 /opt 경로를 통해 lambda layer로 업로드 한 파일들을 참조할 수 있다. 

 

 

Lambda@Edge

cloudfront에 lambda를 실행시킬 수 있는 기능이 있다. 두 기능이 합쳐 실제 유저한테 가까운 환경에서 실행되는 global serverless 라 보면 된다. cloudfront에 오가는 총 4가지 request/response에 대한 trigger가 가능하다.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html