Lambda의 상태를 저장하는 Execution Environment

들어가며

원더월, 프롬스토어 등의 벡엔드 서비스는 serverless 프레임워크를 사용하여 Lambda 기반으로 구성되어 있는데요. 혹시 람다 함수를 여러 번 호출했을 때, 이전에 실행한 함수의 상태가 남아있는 느낌을 받으신 적이 있으신가요?

대표적으로 첫번째 실행에서 DB 커넥션을 initialize 하고, 두번째 실행 때는 DB 커넥션을 initialize 하지 않아도 사용할 수 있는 경우가 있습니다. 제가 람다를 처음 사용했을 때는 ‘전역변수는 그대로 남겨두는건가?’ 하는 막연한 추측만 할 뿐이었습니다. 그 이유는 람다의 Execution Environment 때문인데요. 이번 블로그에서는 람다의 Execution Environment가 뭔지 살펴보는 시간을 갖도록 하겠습니다.

Lambda Execution Environment

Execution Environment(실행 환경)은 람다 함수가 필요한 리소스를 관리하고 함수를 실행시키기 위한 런타임 환경입니다. Execution Environment의 구성요소는 다음처럼 메모리, Timeout, Provisioned Concurrency 등 저희가 람다 함수를 만들 때 설정할 수 있는 값들로 이루어져 있습니다.

• Memory
• CPU
• Ephemeral Storage(임시 스토리지)
• Timeout
• Handler
• Provisioned Concurrency
• 환경변수

Execution Environment는 각 함수 간 공유되지 않지만, 하나의 함수를 연속적으로 실행할 경우는 Execution Environment가 공유될 수 있습니다. Execution Environment 생명주기 파트에서 자세히 살펴보도록 하겠습니다.

Lambda Execution Environment 생명주기

Execution Environment의 생명주기는 다음처럼 3단계로 이루어져 있습니다. 각 단계는 런타임이 전송한 이벤트를 받아 시작되고, 작업이 끝났다는 요청을 전송하여 완료를 나타냅니다.

1. INIT

첫번째 단계는 Init 단계입니다.

Init 단계는 저희가 람다 로그에서 볼 수 있는데요. 위처럼 INIT_START 로 표시된 부분이 Init 단계입니다. Init 단계에는 Lambda Execution Environment를 구성하는 세 가지 작업을 수행합니다.

• Extension Init : 람다에 붙는 추가기능을 실행하는 작업 (커스텀 모니터링, 보안작업, 자체적인 Lambda Extension 등)
• Runtime Init : 각 언어별로 코드 실행을 위해 필요한 요소들을 부트스트랩 하는 과정
• Function Init : 함수의 정적 코드 실행시켜서 handler 함수를 준비시키는 작업

Init 단계는 기본적으로 람다 함수가 호출됐을 때 시작되는 단계이기 때문에, 람다 함수가 이 단계에서 최대 10초의 지연이 생기고 콜드 스타트(Cold Start)가 될 수 있습니다. 그러나 Provisioned Concurrency 옵션을 사용하는 경우 람다를 좀 더 warm 하게 만들어 줄 수 있는데요. 람다 함수가 업데이트되고 미리 Execution Environment을 프로바이징 해놓고 대기합니다. 함수가 호출됐을 때 Init 단계가 완료된 상태라면 바로 다음 단계로 skip 할 수 있습니다.

2. INVOKE

두번째 단계는 Invoke 단계입니다.

service: fromm-store-api-delivery

frameworkVersion: '3'
configValidationMode: warn
useDotenv: true

plugins:
    - serverless-esbuild
    - serverless-plugin-canary-deployments
    - serverless-prune-plugin

provider:
    name: aws
    runtime: nodejs16.x
    timeout: 20 # Timeout 20s

Invoke 단계는 실제 저희가 작성한 Lambda 함수를 실행시키는 단계입니다. 람다 함수를 생성할 때 제한 시간(Timeout)을 설정하는데 이때 설정한 Timeout 값이 Invoke 단계의 Timeout 값입니다. Init 단계는 10초의 제한 시간이 있고 10초가 지나면 Invoke 단계의 Timeout을 잡아먹으면서 Init을 수행하게 됩니다.

3. SHUTDOWN

마지막 단계는 Shutdown 단계입니다.

런타임 및 Extension을 종료시키고 최종적으로 Execution Environment를 종료합니다. 최대 2초가 주어지고 2초가 지나면 강제로 종료됩니다.

Execution Environment의 유지

람다는 Shutdown 단계 이후 Execution Environment를 어느 정도 시간동안 유지합니다.
이는 함수가 호출될 때마다 Execution Environment를 프로바이징한다면 계속 리소스가 소유될 테니, 계속 함수를 사용할 것 같으면 람다가 최적화를 위해 Execution Environment를 계속 남겨두는 것입니다.

Execution Environment가 유지됐을 때 나타나는 효과들에 대해 알아보겠습니다.

1. 핸들러 바깥에서 초기화된 변수가 다음 호출되는 함수에 남아 있음

Execution Environment가 유지되면 Init 단계에서 Function Init을 실행했을 때 각각 언어의 런타임 환경이 만들어지게 되는데, 이 환경이 그대로 남아 있게 되면서 전역변수로 만들어진 객체들은 계속 참조가 남아있게 되는 것입니다.

이 특성을 활용해 NestJS 프레임워크와 서버리스를 활용한 프로젝트에서 자주 사용하는 패턴이 있는데요.
NestJS 프레임워크를 사용해 Nest 앱을 생성하고 서비스할 수 있는 상태로 만들어 둔 다음에 cachedServer 라는 전역변수에 할당을 합니다. 이 cachedServer 변수는 Execution Environment가 유지된다면 다음 함수 호출에서도 계속 유지될 수 있습니다.

// main.ts
let cachedServer;

export const bootstrapServer = async () => {
    if (!cachedServer) {
        const expressApp = express();
        const app = await NestFactory.create(AppModule, new ExpressAdapter(expressApp));
        await app.init();

        cachedServer = ServerlessExpress({ app: expressApp });
    }

    return cachedServer; // Execution Environment가 유지된다면 cachedServer 가 남아있기 때문에 그대로 리턴
};

lambda 핸들러에서는 캐싱이 된 앱을 사용해 요청을 처리합니다. NestFactory.create 를 다시 하지 않아서 보다 빠르게 서비스할 수 있습니다.

// lambda.ts
export const handler: APIGatewayProxyHandler = async (event: any, context: Context, callback: any) => {
    const server = await bootstrapServer(AppModule, 'Delivery', version, '/delivery');

    return server(event, context, callback);
};

2. /tmp 디렉터리 안에 내용이 남아 있음

/tmp 디렉터리는 Execution Environment 가 제공하는 임시 스토리지의 경로입니다. Execution Environment 가 유지된다면 디렉터리의 콘텐츠도 다시 사용할 수 있게 됩니다.

3. 백그라운드 프로세스 혹은 콜백함수가 다음 함수 호출에서 실행됨

함수 종료 시 완료되지 않은 백그라운드 프로세스 또는 콜백은 Lambda가 실행 환경을 재사용하는 경우에 다시 실행될 수 있습니다. Node.js 기반 람다함수일 경우에는 완료되지 않은 Promise가 다음 함수에서 resolve 되는 상황이 있을 수 있습니다.

마치며

AWS Lambda의 Execution Environment에 대해 알아봤는데요. 일반적으로 Execution Environment은 Lambda 서비스가 관리하므로 개발자가 직접 조작할 필요는 없습니다. 그러나 Execution Environment를 효과적으로 활용하면 Lambda 함수의 실행 시간과 자원 사용을 최적화할 수 있습니다. 람다의 상태 관리와 성능 최적화를 위해 Execution Environment의 동작 원리를 이해할 필요가 있을 것 같습니다. 이후에는 Lambda Extensions, Provisioned Concurrency 등과 같은 개념도 자세히 알아보는 시간이 있으면 좋겠습니다.

감사합니다.