AWS 람다(lambda)

8 분 소요

0. 들어가면서

지금 참여하는 중인 프로젝트는 서버리스(serverless) 아키텍처를 채택 중이어서 클라우드 프론트(cloudfront), S3, API 게이트웨이, 람다(lambda)를 활용 중이다. 프로젝트 초반에 참여한 것은 아니기 때문에 시장에 빠르게 진입할 수 있고, 사용자가 적기 때문에 비용을 절약할 수 있다는 장점 때문에 이런 선택을 한 것 같다. 커리어 대부분을 스프링 프레임워크를 사용한 나로선 많은 공부가 되고 있다. 이번 글은 서버리스 아키텍처에서 백엔드(backend)의 핵심 역할을 하는 AWS 람다에 대해 알아보려 한다.

1. AWS Lambda

간략하게 AWS 람다에 대해 정리해 보았다. AWS 람다는 서버를 직접 프로비저닝(provisioning)하거나 유지 관리할 필요 없이 코드를 실행할 수 있게 해주는 서버리스(Serverless) 컴퓨팅 서비스다. 클라우드 환경에서 운영 체제, 컴퓨팅 용량, 스케일링, 보안 등 인프라의 모든 측면을 AWS가 전적으로 관리하므로, 개발자는 오직 애플리케이션의 비즈니스 로직 작성에만 집중할 수 있다. 간단히 말하면 코드만 업로드하면 AWS 람다가 그 기능을 실행해준다.

Lambda의 핵심 특징은 다음과 같다.

이벤트 기반 실행: 람다는 독립적으로 계속 실행되는 것이 아니라 특정 이벤트가 발생했을 때 트리거되어 작동한다. 예를 들어, API 게이트웨이를 통한 HTTP API 요청, S3 버킷에 파일 업로드, DynamoDB 데이터베이스의 테이블 업데이트 등 다양한 AWS 서비스나 외부의 이벤트에 응답하여 자동으로 코드를 실행한다.
비용 효율성: 프로비저닝 된 서버에 트래픽이 없더라도 비용을 지불하는 방식과 달리, 람다는 코드가 실제로 실행된 시간(1ms 단위)과 요청 수에 대해서만 요금이 청구된다. 코드가 실행되지 않을 때는 지불할 비용이 전혀 없다.
자동 확장성과 고가용성: 들어오는 이벤트나 트래픽의 수에 맞춰 자동으로 컴퓨팅 리소스가 확장(스케일 아웃)된다. 또한, 다중 가용 영역(AZ)에 걸쳐 고가용성과 내결함성이 기본적으로 내장되어 있어 별도의 로드 밸런싱이나 이중화 설계에 신경 쓸 필요가 없다.
다양한 런타임 지원: Node.js, Python, Java, Ruby, Go, Rust, C#(.NET) 등 다양한 프로그래밍 언어를 지원하며, 필요할 경우 사용자가 직접 사용자 지정 런타임(Custom Runtime)을 만들어 사용할 수도 있다.
무상태(Stateless) 아키텍처: Lambda 함수는 개별 요청마다 안전하게 격리된 환경(MicroVM)에서 실행되며, 각 호출은 기본적으로 상태를 공유하지 않는 무상태로 동작한다. 단, 성능 최적화(콜드 스타트 방지)를 위해 AWS는 처리가 끝난 실행 환경을 일정 시간 유지하다가 다음 호출에 재사용(웜 스타트)하기도 한다.

2. Constraints

AWS 람다는 편리하지만, 여러 제약사항이 있다. 람다를 선택하기 전에 비즈니스 요건을 확인하고, 람다가 적합한 기술 스택인지 고려해봐야 한다. 먼저 컴퓨팅 리소스 제약 사항들을 살펴보자.

메모리: 128MB에서 시작하여 최대 10,240MB(10GB)까지 1MB 단위로 할당할 수 있다.
CPU: CPU 용량은 사용자가 직접 제어할 수 없으며, 설정된 메모리 크기에 비례하여 자동으로 증가하여 할당된다.
임시 스토리지(/tmp): 함수 실행 시 사용할 수 있는 임시 디스크 공간은 512MB에서 최대 10,240MB(10GB)까지 1MB 단위로 제공된다. 단, 이 공간은 환경이 유지되는 동안에만 일시적으로 보존된다.

함수의 처리 시간은 최대 15분(900초)으로 엄격하게 제한된다. 따라서 오랜 시간이 걸리는 장기 실행 프로세스에는 적합하지 않으며, 이 경우 작업을 더 작은 단위로 분할해야 한다. 람다는 실행 라이프사이클이 존재하며, 각 단계별로 시간 제약이 존재한다. 람다의 실행 라이프 사이클은 크게 다음과 같이 나뉜다.

초기화 단계(Init)
- 람다가 함수 실행을 위해 환경을 준비하는 첫 단계다. 여기서는 세 가지 주요 작업이 수행된다.
- 확장(Extensions) 시작
- 런타임 부트스트랩 (언어 런타임 인터프리터를 메모리에 로드, 런타임 API 연결 설정, 필요한 환경 변수/자격 증명 로드, 함수 코드(.zip 또는 레이어)를 실행 환경으로 로드 등)
- 개발자가 작성한 핸들러 외부의 정적 코드(핸들러 함수 외부 영역) 실행 - 초기화 작업은 기본적으로 최대 10초 이내에 완료되어야 한다. 단, 미리 환경을 데워두는 ‘프로비저닝 된 동시성’이나 ‘SnapStart’ 기능을 사용할 경우에는 130초 또는 최대 15분까지 허용된다. - 만약 이 단계에서 크래시가 나거나 10초를 초과하면, 람다는 다음번 첫 함수 호출 시에 초기화 단계를 다시 시도합니다.
호출 단계(Invoke)
- 실제 비즈니스 로직이 수행되는 단계다. 람다는 런타임과 각 확장 프로그램에 Invoke 이벤트를 전송한다.
- 사용자가 설정한 함수의 타임아웃 한도(최대 900초/15분) 내에 함수 본연의 코드와 확장 작업이 모두 완료되어야 한다.
- 별도의 사후 처리 단계가 없으므로 총 실행 시간의 합이 설정된 타임아웃을 초과해서는 안 됩니다.
- 처리 중에 타임아웃이나 크래시가 발생하면 람다는 실행 환경을 초기화(리셋)하여 다음 요청에 대비한다. 리셋될 때 런타임과 확장은 셧다운 되지만, /tmp 디렉터리의 임시 파일은 지워지지 않고 유지된다.
종료 단계(Shutdown)
- 유지보수나 장기간 미사용으로 인해 람다가 실행 환경을 완전히 파기하기 직전의 단계다. 하나의 호출(Invoke)이 성공적으로 완료되었다고 해서 람다가 곧바로 종료 단계로 넘어가는 것은 아니다. 람다는 런타임과 확장의 처리가 끝나면 성능 향상을 위해 실행 환경의 상태를 동결(Freeze)한 채로 일정 시간 유지한다.
- 등록된 확장 프로그램에 Shutdown 이벤트를 보내어 최종적인 정리(Cleanup) 작업을 할 수 있는 기회를 제공한다.
- 전체 종료 단계는 최대 2초로 엄격하게 제한된다. 런타임이나 확장이 2초 내에 응답하지 않으면 람다는 강제 종료(SIGKILL) 신호를 보내 환경을 강제로 꺼버린다.