Lambda 실행 환경 수명 주기 이해 - AWS Lambda
런타임 환경 수명 주기콜드 스타트 및 지연 시간프로비저닝된 동시성으로 콜드 스타트 감소정적 초기화 최적화

Lambda 실행 환경 수명 주기 이해

Lambda는 안전하고 격리된 런타임 환경을 제공하는 실행 환경에서 함수를 간접 호출합니다. 실행 환경은 함수를 실행하는 데 필요한 리소스를 관리합니다. 또한 실행 환경은 함수의 런타임 및 함수와 관련된 모든 외부 익스텐션에 대한 수명 주기 지원을 제공합니다.

함수의 런타임은 런타임 API를 사용하여 Lambda와 통신합니다. 익스텐션은 익스텐션 API를 사용하여 Lambda와 통신합니다. 또한 확장은 텔레메트리 API를 사용하여 함수의 로그 메시지와 기타 텔레메트리 데이터를 수신할 수 있습니다.

실행 환경의 아키텍처 다이어그램.

Lambda 함수를 생성할 때 함수에서 허용된 메모리 용량 및 최대 실행 시간 같은 구성 정보를 지정합니다. Lambda는 이 정보를 사용하여 실행 환경을 설정합니다.

함수의 런타임 및 각 외부 익스텐션은 실행 환경 내에서 실행되는 프로세스입니다. 권한, 리소스, 자격 증명 및 환경 변수는 함수와 익스텐션 간에 공유됩니다.

Lambda 실행 환경 수명 주기

Lambda 수명 주기 단계: 초기화, 간접 호출, 종료

각 단계는 Lambda가 런타임 및 등록된 모든 익스텐션에 전송하는 이벤트로 시작됩니다. 런타임 및 각 익스텐션이 Next API 요청을 전송하여 완료를 나타냅니다. 런타임 및 각 익스텐션이 완료되고 대기 중인 이벤트가 없으면 Lambda는 실행 환경을 중지합니다.

초기화 단계

Init 단계에서 Lambda는 다음 세 가지 작업을 수행합니다.

  • 모든 익스텐션 시작(Extension init)

  • 런타임 부트스트랩(Runtime init)

  • 함수의 정적 코드 실행(Function init)

  • 모든 체크포인트 전 런타임 후크 실행(Lambda SnapStart만 해당)

Init 단계는 런타임 및 모든 익스텐션이 Next API 요청을 전송하여 준비되었음을 알린 후에 종료됩니다. Init 단계는 10초로 제한됩니다. 세 작업이 모두 10초 이내에 완료되지 않으면 Lambda는 첫 번째 함수 호출 시 구성된 함수 타임아웃으로 Init 단계를 다시 시도합니다.

Lambda SnapStart가 활성화되면 함수 버전을 게시할 때 Init 단계가 발생합니다. Lambda는 초기화된 실행 환경의 메모리 및 디스크 상태 스냅샷을 저장하고 암호화된 스냅샷을 유지하며 짧은 지연 시간으로 액세스할 수 있도록 스냅샷을 캐싱합니다. 체크포인트 이전의 런타임 후크가 있는 경우 코드는 Init 단계가 끝날 때 실행됩니다.

참고

10초 시간 제한은 프로비저닝된 동시성 또는 SnapStart를 사용하는 함수에는 적용되지 않습니다. 프로비저닝된 동시성 및 SnapStart 함수인 경우 초기화 코드를 최대 15분 동안 실행할 수 있습니다. 시간 제한은 130초 또는 구성된 함수 제한 시간(최대 900초) 중 더 높은 값입니다.

프로비저닝된 동시성을 사용하면 함수에 대한 PC 설정을 구성할 때 Lambda가 실행 환경을 초기화합니다. 또한 Lambda는 간접 호출에 앞서 초기화된 실행 환경을 항상 사용할 수 있도록 합니다. 함수의 간접 호출 단계와 초기화 단계 사이에 시간 격차가 발생할 수 있습니다. 함수의 런타임 및 메모리 구성에 따라 초기화된 실행 환경에서 첫 번째 간접 호출 시 가변적 지연 시간이 나타날 수도 있습니다.

온디맨드 동시성을 사용하는 함수의 경우 Lambda는 간접 호출 요청에 앞서 실행 환경을 초기화하는 경우가 있습니다. 이 경우 함수의 초기화 단계와 간접 호출 단계 사이에 시간 격차가 발생할 수 있습니다. 이 동작에 의존하지 않는 것이 좋습니다.

Init 단계 중 실패

Init 단계 중에 함수가 충돌하거나 시간이 초과되면 Lambda는 INIT_REPORT 로그에 오류 정보를 생성합니다.

예 — 타임아웃에 대한 INIT_REPORT 로그
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
예 — 확장 실패에 대한 INIT_REPORT 로그
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Init 단계가 성공하면 SnapStart 또는 프로비저닝된 동시성이 활성화되지 않은 한 Lambda는 INIT_REPORT 로그를 내보내지 않습니다. SnapStart 및 프로비저닝된 동시성 함수는 항상 INIT_REPORT를 내보냅니다. 자세한 내용은 Lambda SnapStart 모니터링 단원을 참조하십시오.

복원 단계(Lambda SnapStart만 해당)

SnapStart 함수를 처음 간접 호출하고 함수가 스케일 업되면 Lambda는 이 함수를 처음부터 초기화하는 대신 유지된 스냅샷에서 새 실행 환경을 재개합니다. 복원 후 런타임 후크가 있는 경우 코드는 Restore 단계가 끝날 때 실행됩니다. 복원 후 런타임 후크 지속 시간에 대해 요금이 청구됩니다. 런타임이 로드되고 복원 후 런타임 후크가 제한 시간(10초) 내에 완료되어야 합니다. 그렇지 않으면 SnapStartTimeoutException이 발생합니다. Restore 단계가 완료되면 Lambda가 함수 핸들러(간접 호출 단계)를 간접적으로 간접 호출합니다.

복원 단계 중 실패

Restore 단계가 실패하면 Lambda는 RESTORE_REPORT 로그에 오류 정보를 생성합니다.

예 — 타임아웃에 대한 RESTORE_REPORT 로그
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
예 — 런타임 후크 실패에 대한 RESTORE_REPORT 로그
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

RESTORE_REPORT log에 대한 자세한 내용은 Lambda SnapStart 모니터링을 참조하십시오.

간접 호출 단계

Next API 요청에 대한 응답으로 Lambda 함수가 간접 호출되면 Lambda는 런타임과 각 익스텐션에 Invoke 이벤트를 전송합니다.

함수의 제한 시간 설정은 전체 Invoke 단계의 기간을 제한합니다. 예를 들어 함수 제한 시간을 360초로 설정하면 함수와 모든 익스텐션이 360초 내에 완료되어야 합니다. 독립적인 간접 호출 후 단계는 없습니다. 기간은 모든 호출 시간(런타임 + 익스텐션)의 합계이며 함수와 모든 익스텐션의 실행이 완료될 때까지 계산되지 않습니다.

간접 호출 단계는 런타임 및 모든 익스텐션이 Next API 요청을 전송하여 완료되었음을 알린 후에 종료됩니다.

간접 호출 단계 중 실패

Invoke 단계 중에 Lambda 함수가 충돌하거나 시간이 초과되면 Lambda는 실행 환경을 재설정합니다. 다음 다이어그램은 간접 호출 실패 시 Lambda 실행 환경 동작을 보여줍니다.

실행 환경 예시: 초기화, 간접 호출, 오류가 있는 간접 호출, 간접 호출, 종료

이전 다이어그램에서

  • 첫 번째 단계는 오류 없이 실행되는 INIT 단계입니다.

  • 두 번째 단계는 오류 없이 실행되는 간접 호출 단계입니다.

  • 어떤 시점에서 함수에 간접 호출 오류(함수 시간 초과나 런타임 오류)가 발생했다고 하겠습니다. 간접 호출 WITH ERROR라고 표시된 세 번째 단계가 이 시나리오를 보여줍니다. 이 경우 Lambda 서비스가 재설정을 수행합니다. 재설정은 Shutdown 이벤트처럼 동작합니다. 먼저 Lambda는 런타임을 종료한 다음 등록된 각 외부 익스텐션에 Shutdown 이벤트를 전송합니다. 이벤트에는 종료 이유가 포함됩니다. 이 환경이 새 호출에 사용되는 경우 Lambda는 익스텐션과 런타임을 다음 호출과 함께 다시 초기화합니다.

    Lambda 재설정으로 다음 초기화 단계 전에 /tmp 디렉터리의 내용이 지워지지 않는다는 점에 유의하세요. 이 동작은 일반 종료 단계와 동일합니다.

    참고

    AWS는 현재 Lambda 서비스에 대한 변경 사항을 구현하고 있습니다. 이러한 변경으로 인해, AWS 계정의 여러 Lambda 함수에서 내보내는 시스템 로그 메시지와 추적 세그먼트의 구조와 내용 간에 약간의 차이가 있을 수 있습니다.

    함수의 시스템 로그 구성이 일반 텍스트로 설정된 경우, 이 변경은 함수에서 간접 호출 실패가 발생할 때 CloudWatch Logs에 캡처되는 로그 메시지에 영향을 줍니다. 다음 예는 이전 형식과 새 형식의 로그 출력을 모두 보여줍니다.

    이러한 변경 사항은 앞으로 몇 주 동안 구현되며, 중국 및 GovCloud 리전을 제외한 모든 AWS 리전의 모든 기능은 새로운 형식의 로그 메시지 및 추적 세그먼트를 사용하도록 전환됩니다.

    예 CloudWatch Logs 로그 출력(런타임 또는 확장 충돌) - 이전 스타일
    START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
    예 CloudWatch Logs 로그 출력(함수 제한 시간) - 이전 스타일
    START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3000 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms

    CloudWatch 로그의 새 형식에는 REPORT 줄에 status 필드가 추가로 포함됩니다. 런타임 또는 확장 충돌이 발생하는 경우, 해당 REPORT 줄에는 ErrorType 필드도 포함됩니다.

    예 CloudWatch Logs 로그 출력(런타임 또는 확장 충돌) - 새 스타일
    START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 133 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
    예 CloudWatch Logs 로그 출력(함수 제한 시간) - 새 스타일
    START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3016 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout

  • 네 번째 단계는 간접 호출 실패 직후의 간접 호출 단계를 나타냅니다. 여기서 Lambda는 INIT 단계를 다시 실행하여 환경을 다시 초기화합니다. 이를 억제된 초기화라고 합니다. 억제된 초기화가 발생하는 경우 Lambda는 CloudWatch 로그에 추가 INIT 단계를 명시적으로 보고하지는 않습니다. 대신 REPORT 줄의 지속 시간에 추가 INIT 기간 + 간접 호출 기간이 포함되어 있음을 알 수 있습니다. 예를 들어 CloudWatch에 다음과 같은 로그가 표시되어 있다고 가정하겠습니다.

    2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST 
2022-12-20T01:00:02.500-08:00 END RequestId: XXX 
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms 
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB

    이 예제에서 REPORT 타임스탬프와 START 타임스탬프 간의 차이는 2.5초입니다. 이는 Lambda가 수행한 추가 INIT(억제된 초기화)를 고려하지 않기 때문에 보고된 지속 시간인 3022.91 밀리초와 일치하지 않습니다. 이 예시에서는 실제 간접 호출 단계에 2.5초가 걸렸다고 추론할 수 있습니다.

    이 동작에 대해 더 자세히 알아보려면 텔레메트리 API를 사용하여 확장의 실시간 텔레메트리 데이터에 액세스을 사용하면 됩니다. Telemetry API는 간접 호출 단계 사이에 억제된 초기화가 발생할 때마다 INIT_START, INIT_RUNTIME_DONE, INIT_REPORT, phase=invoke 이벤트를 내보냅니다.

  • 다섯 번째 단계는 오류 없이 실행되는 SHUTDOWN 단계를 나타냅니다.

종료 단계

Lambda는 런타임을 종료하려고 할 때 Shutdown 이벤트를 등록된 각 외부 익스텐션에 전송합니다. 익스텐션은 이 시간 동안 최종 정리 작업을 수행할 수 있습니다. Shutdown 이벤트는 Next API 요청에 대한 응답입니다.

기간: 전체 Shutdown 단계는 2초로 제한됩니다. 런타임 또는 익스텐션이 응답하지 않는 경우, Lambda는 신호(SIGKILL)를 통해 이를 종료합니다.

함수와 모든 익스텐션이 완료된 후 Lambda는 다른 함수 호출을 예상하여 일정 시간 동안 실행 환경을 유지합니다. 그러나 Lambda는 몇 시간마다 실행 환경을 종료하여 런타임 업데이트 및 유지 관리를 허용하며, 이는 지속적으로 간접 호출되는 함수에 대해서도 동일합니다. 실행 환경이 무기한 지속될 것이라고 가정하면 안 됩니다. 자세한 내용은 함수에서 상태 비저장 구현 단원을 참조하십시오.

함수가 다시 간접 호출되면 Lambda는 재사용을 위해 환경을 재개합니다. 실행 환경을 재사용하는 것은 다음과 같은 의미를 가집니다.

  • 함수의 핸들러 메서드 외부에서 선언된 객체는 함수가 다시 간접 호출될 때 추가로 최적화가 되도록 초기화된 상태로 유지됩니다. 예를 들어 Lambda 함수가 연결을 재설정하는 대신 데이터베이스 연결을 설정하면 원래 연결이 후속 호출에 사용됩니다. 코드에 로직을 추가하여 연결을 새로 생성하기에 앞서 연결이 이미 존재하는지 확인하는 것이 좋습니다.

  • 각 실행 환경은 /tmp 디렉터리에 512MB에서 10,240MB 사이 1MB 단위로 디스크 공간을 제공합니다. 디렉터리 콘텐츠는 실행 환경이 일시 중지되어도 그대로 유지되기 때문에 일시적인 캐시를 여러 호출에서 사용할 수 있습니다. 코드를 추가하여 캐시에 저장한 데이터가 포함되어 있는지 확인할 수 있습니다. 배포 크기 제한에 대한 자세한 내용은 Lambda 할당량 섹션을 참조하세요.

  • Lambda 함수에 의해 초기화되었고 함수 종료 시 완료되지 않은 백그라운드 프로세스 또는 콜백은 Lambda가 실행 환경을 재사용하는 경우에 재개됩니다. 코드가 종료되려면 먼저 코드의 백그라운드 프로세스 또는 콜백이 완료되어야 합니다.

콜드 스타트 및 지연 시간

Lambda가 Lambda API를 통해 함수를 실행하라는 요청을 수신하면 서비스는 먼저 실행 환경을 준비합니다. 이 초기화 단계에서 서비스는 코드를 다운로드하고, 환경을 시작하고, 기본 핸들러 외부에서 모든 초기화 코드를 실행합니다. 마지막으로 Lambda는 핸들러 코드를 실행합니다.

성능 최적화 그림 1

이 다이어그램에서 코드를 다운로드하고 환경을 설정하는 처음 두 단계는 '콜드 스타트'라고 불리기도 합니다. 이 기간에는 요금이 부과되지 않지만 전체 간접 호출 기간에 지연 시간이 추가됩니다.

간접 호출이 완료되면 실행 환경이 동결됩니다. 리소스 관리 및 성능을 개선하기 위해 Lambda는 일정 기간 동안 실행 환경을 유지합니다. 이 기간 동안 동일한 함수에 대해 또 다른 요청이 도착하면 Lambda가 환경을 재사용할 수 있습니다. 실행 환경이 이미 완전히 설정되어 있으므로 이 두 번째 요청은 일반적으로 더 빨리 완료됩니다. 이를 '웜 스타트'라고 합니다.

콜드 스타트는 일반적으로 간접 호출의 1% 미만에서 발생합니다. 콜드 스타트 지속 시간은 100밀리초 미만에서 1초 넘게까지 다양합니다. 일반적으로 콜드 스타트는 프로덕션 워크로드보다 개발 및 테스트 함수에서 더 흔합니다. 일반적으로 개발 및 테스트 함수에서 간접 호출 횟수가 더 적기 때문입니다.

프로비저닝된 동시성으로 콜드 스타트 감소

워크로드에 대해 예측 가능한 함수 시작 시간이 필요한 경우 가능한 지연 시간을 최소화하려면 프로비저닝된 동시성을 사용하는 것이 좋습니다. 이 기능은 실행 환경을 미리 초기화하여 콜드 스타트를 줄입니다.

예를 들어 프로비저닝된 동시성이 6인 함수에서는 6개의 실행 환경이 미리 워밍됩니다.

성능 최적화 그림 4

정적 초기화 최적화

정적 초기화는 함수에서 핸들러 코드 실행이 시작되기 전에 수행됩니다. 이는 기본 핸들러 외부에 있는 사용자가 제공하는 초기화 코드입니다. 이 코드는 라이브러리 및 종속성을 가져오고 구성을 설정하며 다른 서비스에 대한 연결을 초기화하는 데 자주 사용됩니다.

다음 Python 예제에서는 간접 호출 중 lambda_handler 함수가 실행되기 전에 초기화 단계에서 모듈을 가져오고 구성하며 Amazon S3 클라이언트를 생성하는 방법을 보여줍니다.

import os
import json
import cv2
import logging
import boto3

s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

  # Handler logic...

함수 실행 전 지연 시간에 가장 많이 기여하는 요인은 초기화 코드입니다. 이 코드는 새 실행 환경이 처음 생성될 때 실행됩니다. 간접 호출이 웜 실행 환경을 사용하는 경우 초기화 코드가 다시 실행되지 않습니다. 초기화 코드 지연 시간에 영향을 미치는 요인은 다음과 같습니다.

  • 가져온 라이브러리 및 종속 항목과 Lambda 계층 관점에서 함수 패키지의 크기.

  • 코드 및 초기화 작업의 양.

  • 연결 및 기타 리소스를 설정할 때 라이브러리 및 기타 서비스의 성능.

정적 초기화 지연 시간을 최적화하기 위해 개발자가 수행할 수 있는 여러 단계가 있습니다. 함수에 객체 및 연결이 많은 경우 단일 함수를 여러 특수 함수로 리아키텍팅할 수 있습니다. 이들은 개별적으로 더 작으며 각각 초기화 코드가 적습니다.

함수는 필요한 라이브러리 및 종속 항목만 가져와야 합니다. 예를 들어 AWS SDK에서 Amazon DynamoDB만 사용하는 경우 전체 SDK 대신 개별 서비스가 필요할 수 있습니다. 다음 세 가지 예제를 비교합니다.

// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')

// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')

// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)

정적 초기화는 함수가 동일한 실행 환경에 대한 여러 간접 호출을 통해 연결을 재사용할 수 있도록 데이터베이스 연결을 여는 데 가장 적합한 위치이기도 합니다. 그러나 함수의 특정 실행 경로에서만 사용되는 객체가 많을 수 있습니다. 이 경우 전역 범위에서 변수를 지연 로드하여 정적 초기화 지속 시간을 줄일 수 있습니다.

컨텍스트별 정보에 대해서는 전역 변수를 사용하지 마세요. 함수에 단일 간접 호출의 수명 동안에만 사용되고 다음 간접 호출을 위해 재설정되는 전역 변수가 있는 경우 핸들러에 로컬로 존재하는 변수 범위를 사용합니다. 그러면 여러 간접 호출에서 전역 변수 누출을 방지하고 정적 초기화 성능도 개선됩니다.