람다는 우리가 작성한 함수를 오로지 필요할 때만 실행하고 그리고 자동으로 스케일 아웃 해준다. 오로지 우리가 사용한 컴퓨팅 시간만큼만 비용을 지불하면 되기 때문에 좋다.

1. 람다를 쓰면 좋은 경우

람다를 쓰면 일단 모든 하드웨어적 리소스에 대해 전혀 신경쓸 필요가 없기 때문에 좋다. 그리고 람다는 다양한 AWS와 연동하여 사용할 수 있는데 예를 들어

• API Gateway에서 HTTP 리퀘스트를 람다 함수로 라우팅한다거나
• DynamoDB나 Kinesis와 연결하거나
• S3 이벤트를 받아서 S3 object를 처리하게 한다거나
• SQS 메시지를 처리하거나 SNS 노티를 처리하게 한다거나
• Step Functions을 사용해서 여러 람다 함수들을 하나의 state machine으로 만든다거나
  하는 용도로 사용할 수 있다.

2. 배포 방법

사용자는 람다에 자신의 함수 코드를 크게 2가지 종류의 배포 패키지(deployment package) 중 하나로 배포할 수 있다.

(1) .zip file archive

람다 함수를 콘솔에서 만들어서 실행할 때 주로 쓰이는 방법이다. 이 경우에 사용자는 코드와 디펜던시를 제공해야하고, OS와 런타임은 람다가 제공한다.

(2) container image

OCI(Open Container Initiative) 스펙과 호환되는 컨테이너 이미지로 이 경우에는 사용자가 코드와 디펜던시 뿐만 아니라 OS와 런타임도 이미지에 직접 포함시켜야 한다.

3. Execution role

람다는 함수를 생성할 때 execution role(IAM)을 생성해서 해당 함수가 로그를 업로드할 수 있게 해준다(Cloudwatch?) 람다 함수는 실행될 때 이 execution role을 갖고 실행된다. 람다는 매 invocation마다 로그를 생성하는데 함수가 이것을 CloudWatch에 기록한다.

4. Trigger

트리거는 람다 함수를 실행하는 리소스나 설정이다. 트리거는 람다 함수를 실행하도록 설정된 AWS 서비스 또는 event source mappings를 포함한다. event source mapping은 람다 안의 리소스로, 스트림이나 큐로부터 아이템을 읽어서 함수를 실행한다.

5. Event

이벤트는 JSON 포맷의 도큐먼트로 람다 함수가 처리할 데이터를 담고 있다. 각 런타임이 이벤트를 객체로 변환해서 함수 코드에 전달한다. 함수를 호출할 때 사용자가 이벤트의 구조와 내용을 정의할 수 있다. 사용자가 직접 JSON 문서를 작성할 수도 있지만 보통 람다는 다른 AWS 서비스와 연동해서 사용하는 경우가 많기 때문에 각 AWS 서비스가 넘기는 이벤트의 형식을 확인하고 사용하게 되는 경우가 많다.

6. Execution environment

실행환경은 람다 함수를 위한 안전하고 고립된 런타임 환경이다. 실행환경에서 함수 실행을 위해 필요한 프로세스와 리소스들을 관리한다. 실행환경은 함수를 위한 lifecycle support와 extensions(?)를 제공한다.

7. Runtime

런타임은 language-specific한 환경으로 exeucution environment 안에서 실행된다. 런타임은 invocation events, context information, responses를 람다와 함수 사이에서 중계한다.
사용자는 람다가 제공하는 런타임을 사용하거나 직접 자신의 것을 빌드할 수도 있다. 만약 .zip file archive를 배포 패키지로 사용한다면 사용한 프로그래밍 언어에 맞는 실행 환경을 설정하면 되고, container image를 배포 패키지로 사용한다면 이미지를 빌드할 때 런타임을 포함시켜야 한다.

8. Layer