[AWS] Lambda

AWS Lambda

---

AWS Lambda의 개념과 정의

AWS Lambda는 아마존 웹 서비스(AWS)에서 제공하는 서버리스 컴퓨팅 서비스다. 개발자가 서버를 직접 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해준다. 이벤트 기반으로 동작하며, 특정 이벤트가 발생할 때 지정된 코드를 자동으로 실행하는 방식이다. 사용자는 함수(Function) 단위로 코드를 작성하며, 실행된 시간(밀리초 단위)과 요청 수에 따라 비용이 청구된다.

서버리스 아키텍처란

서버리스 아키텍처는 클라우드 공급자가 서버를 실행하고 고객이 사용량에 따라 요금을 지불하는 클라우드 컴퓨팅 실행 모델이다. 인프라를 관리할 필요 없이 애플리케이션과 서비스를 구축하고 실행하는 방법이다. 서버리스 모델에서 개발자는 서버를 프로비저닝하거나 관리할 필요 없이 클라우드에서 실행되는 코드를 작성할 수 있다. 코드를 업로드하기만 하면 클라우드 공급자가 필요에 따라 코드를 실행한다.

서버리스 ≠ 서버가 없음  
서버리스 = 서버 관리가 필요 없음  

AWS Lambda의 주요 특징

이벤트 기반 실행 구조

Lambda는 이벤트에 의해 트리거된다. 예를 들어 다음과 같다.

• S3 버킷에 파일이 업로드될 때
• DynamoDB 테이블에 데이터가 변경될 때
• API Gateway를 통한 HTTP 요청이 들어올 때
• CloudWatch Events를 통한 스케줄 이벤트 발생 시
• SNS 토픽에 메시지가 게시될 때

지원 프로그래밍 언어

Lambda는 다양한 프로그래밍 언어를 지원한다

• Node.js 18.x, 16.x, 14.x
• Python 3.11, 3.10, 3.9, 3.8, 3.7
• Java 17, 11, 8
• Go 1.x
• Ruby 3.2, 2.7
• .NET 7, 6
• Rust
• 사용자 정의 런타임을 통한 기타 언어

실행 환경 스펙

각 Lambda 함수는 다음과 같은 환경에서 실행된다

• 메모리: 128MB - 3008MB (64MB 단위로 증가)
• 임시 저장용 디스크 공간: 512MB
• 최대 실행 시간: 900초(15분)
• 압축 시 패키지 크기: 50MB
• 압축 해제 시 패키지 크기: 250MB

+------------------------+  
| AWS Lambda 실행 환경   |  
+------------------------+  
| 메모리: 128MB-3008MB   |  
| 디스크: 512MB          |  
| 최대 실행: 15분        |  
| 패키지: 250MB(압축해제)|  
+------------------------+  

Lambda 실행 환경 수명 주기

Lambda 실행 환경은 다음과 같은 단계로 구성된다

초기화 단계 (Init)

1. 모든 익스텐션 시작 (Extension init)
2. 런타임 부트스트랩 (Runtime init)
3. 함수의 정적 코드 실행 (Function init)
4. 체크포인트 전 런타임 후크 실행 (Lambda SnapStart만 해당)

초기화 단계는 기본적으로 10초로 제한되며, 프로비저닝된 동시성이나 SnapStart를 사용하는 경우 더 긴 시간(최대 15분)이 허용된다.

호출 단계 (Invoke)

함수가 호출될 때마다 실행되는 단계로, 이벤트 데이터가 함수에 전달된다.

종료 단계 (Shutdown)

Lambda가 함수 인스턴스를 종료하기로 결정했을 때 실행되며, 이 단계에서 익스텐션은 정리 작업을 수행할 수 있다.

[초기화] -> [호출] -> [종료]

초기화: 환경 준비 및 코드 로드  
호출: 이벤트 처리 및 응답 반환  
종료: 리소스 정리  

AWS Lambda의 장점

인프라 관리 부담 제거

Lambda를 사용하면 서버 프로비저닝, 패치 적용, 운영 체제 관리 등의 인프라 관련 작업을 AWS가 대신 수행한다. 개발자는 코드에만 집중할 수 있다.

자동 확장성

Lambda는 동시에 많은 요청이 들어와도 자동으로 확장되어 처리한다. 기본적으로 1,000개의 동시 실행을 지원하며, 요청 시 이 한도를 증가시킬 수 있다.

비용 효율성

Lambda는 코드가 실행된 시간과 실행 횟수에 따라 비용이 청구된다. 코드가 실행되지 않을 때는 비용이 발생하지 않는다. AWS는 매월 100만 건의 요청과 40만 GB-초의 컴퓨팅 시간을 무료로 제공한다.

다른 AWS 서비스와의 통합

Lambda는 다양한 AWS 서비스와 쉽게 통합된다. API Gateway, S3, DynamoDB, CloudWatch, SNS 등과 원활하게 연동하여 복잡한 워크플로를 구성할 수 있다.

AWS Lambda의 단점

콜드 스타트 문제

함수가 처음 실행되거나 오랫동안 실행되지 않았을 때 발생하는 지연 시간이다. 컨테이너를 프로비저닝하고 코드를 로드하는 과정에서 발생한다.

+------------------+    +------------------+  
| 콜드 스타트      |    | 웜 스타트        |  
+------------------+    +------------------+  
| 컨테이너 생성    |    | 기존 컨테이너    |  
| 코드 로드        | vs | 즉시 실행        |  
| 환경 초기화      |    |                  |  
| 실행 (지연 발생) |    | 실행 (지연 최소) |  
+------------------+    +------------------+  

실행 시간 제한

Lambda 함수는 최대 15분 동안만 실행될 수 있어 장시간 실행이 필요한 작업에는 적합하지 않다.

리소스 제한

메모리 제한(최대 10GB), 디스크 공간 제한(512MB), 패키지 크기 제한(250MB) 등이 있어 리소스 집약적인 애플리케이션에는 한계가 있다.

Lambda 함수 작성 예제 (Node.js)

간단한 Lambda 함수 작성 예제를 살펴보자

exports.handler = async (event) => {  
    // 이벤트 데이터 로깅  
    console.log('Received event:', JSON.stringify(event, null, 2));  

    // 이벤트에서 데이터 추출  
    const name = event.name || 'World';  

    // 응답 생성  
    const response = {  
        statusCode: 200,  
        body: JSON.stringify({ message: `Hello, ${name}!` })  
    };  

    return response;  
};  

AWS Lambda의 사용 사례

백엔드 서비스 개발

Lambda를 API Gateway와 연계하여 RESTful API를 구성할 수 있다. 이를 통해 서버리스 애플리케이션을 구축할 수 있으며, 개발자는 코드 작성에 집중하고 인프라 관리 부담을 줄일 수 있다.

데이터 처리 및 변환

Lambda는 실시간으로 데이터 스트림을 처리하는 데 유용하다. Amazon Kinesis나 DynamoDB Streams를 통해 들어오는 데이터를 분석 및 변환할 수 있다. 또한, S3에 업로드된 이미지나 동영상을 변환하거나 메타데이터를 추출하는 용도로도 활용된다.

파일 변환

비디오나 이미지 파일을 한 형식에서 다른 형식으로 변환하는 작업에 적합하다. 예를 들어, S3에 업로드된 이미지 파일의 썸네일을 자동으로 생성할 수 있다.

IoT 백엔드

AWS IoT Core와 결합하여 센서 데이터 수집 및 처리를 수행할 수 있다. 실시간 기기 데이터 분석 및 알림 전송 기능을 구현할 수 있다.

보안 및 모니터링 자동화

AWS CloudWatch와 연계하여 특정 이벤트 발생 시 자동으로 보안 점검을 수행하거나 알림을 보낼 수 있다. 예를 들어, 비정상적인 로그인 시도를 감지하면 Lambda가 자동으로 보안 정책을 적용하도록 설정할 수 있다.

Lambda 함수 작동 방식

작동 방식을 다음과 같이 간략하게 파악할 수 있다.

[이벤트 소스] -> [트리거] -> [Lambda 함수] -> [대상 서비스]

예시)
S3 업로드   -> 객체 생성 알림  -> 이미지 처리   -> S3 저장
API 요청    -> API Gateway    -> 데이터 처리   -> DynamoDB 저장
DB 변경     -> DB 스트림      -> 알림 생성     -> SNS 메시지
예약 이벤트 -> CloudWatch     -> 보고서 생성   -> 이메일 전송

Lambda 서비스는 어떻게 구현됐을까?

---

Lambda를 배우고, 직접 사용해보면서 문득 어떻게 구현했을지 궁금해졌다. 일단 아무것도 찾아보지 않은 상태로 간단한 가설을 세워보았다. 사용자의 코드를 받아서 처리한 이후, S3에 저장하는 상황을 전제해보았다.

1. 사용자의 요청(컨테이너 이미지, 사용자 작성 코드)이나 이벤트 트리거에 따라 격리된 가상머신을 프로비저닝 및 세팅하는 역할의 코드가 있다.
2. 최적화된 가상머신에서 사용자에게 받은 코드를 실행한다.
3. 각 가상머신마다 특정 서비스(S3)를 확인하고, 연결된 서비스 순서대로 정해진 동작을 수행하도록 한다.
4. 최종 결과를 사용자에게 보여줄 수 있도록 응답하고, 일정시간 재호출이 없다면 가상머신에 할당된 자원을 해제하고 종료한다.

위와 같은 순서대로 진행되지 않을까 한다. 어차피 AWS 측에서 전부 공개할 리는 없기 때문에 상상의 영역이다. 그런데 이어서 또 다른 의문이 생겼다.

런타임 환경을 조성부터 코드 실행까지의 낮은 딜레이를 어떻게 보장할 수 있는 걸까?

직접 찾아보니 다음과 같은 글을 발견했다. ByteByteGo의 공동 창업자 Alex Wu가 작성한 글이다.
https://blog.bytebytego.com/p/how-does-aws-lambda-work-behind-the

요약하자면 다음과 같다.

Firecracker는 AWS Lambda 및 AWS Fargate와 같은 서버리스 서비스를 개선하기 위해 Amazon Web Services에서 Rust 언어로 개발되었으며, 빠른 시작 시간, 낮은 메모리 오버헤드 및 향상된 보안을 제공하는 마이크로VM 생성을 전문으로 한다. 이 기술은 사용자 공간에서 실행되고 Linux KVM을 사용하여 마이크로VM을 관리하며, 불필요한 장치를 제거하여 공격 표면을 줄인다. 다양한 컨테이너 생태계와 통합되어 있으며 Linux 및 OSv 게스트를 지원한다. 전반적으로 Firecracker는 서버리스 컴퓨팅을 위한 안전하고 효율적인 런타임 환경을 만드는 데 중점을 둔다.

다시 말해, 경량화된 마이크로VM으로 125ms 이하의 빠른 시작 시간을 보장해준다. 콜드 스타트 문제가 없진 않지만 이런 단점을 최소화하기 위한 노력을 볼 수 있었다. 훗날 시간이 되면 Firecracker 코드를 뜯어볼 수 있길 바란다.