Lambda SnapStart를 사용하여 시작 성능 개선 - AWS Lambda
사용 사례지원 기능 및 제한 사항지원되는 리전호환성 고려 사항요금

Lambda SnapStart를 사용하여 시작 성능 개선

Lambda SnapStart는 일반적으로 함수 코드를 변경하지 않고도 1초 미만의 시작 성능을 제공할 수 있습니다. SnapStart를 사용하면 리소스를 프로비저닝하거나 복잡한 성능 최적화를 구현하지 않고도 응답성 및 확장성이 뛰어난 애플리케이션을 더 쉽게 빌드할 수 있습니다.

시작 지연 시간(콜드 스타트 시간이라고도 함)이 발생하는 가장 큰 원인은 Lambda가 함수를 초기화하는 데 시간을 소비하기 때문입니다. 여기에는 함수 코드 로드 시간, 런타임 시작 시간, 함수 코드 초기화 시간이 포함됩니다. SnapStart를 사용하면 함수 버전을 게시할 때 Lambda가 함수를 초기화합니다. Lambda는 초기화된 실행 환경의 메모리 및 디스크 상태에대한 Firecracker microVM 스냅샷을 생성하고 스냅샷을 암호화하며 지능적으로 캐싱하여 검색 지연 시간을 최적화합니다.

복원력을 보장하기 위해 Lambda에서는 각 스냅샷의 여러 사본을 유지합니다. Lambda에서는 최신 런타임 및 보안 업데이트를 사용하여 스냅샷 및 해당 사본을 자동으로 패치합니다. 함수 버전을 처음 간접 호출하는 경우와 간접 호출이 스케일 업되는 경우 Lambda는 실행 환경을 처음부터 초기화하는 대신 캐싱된 스냅샷에서 새 실행 환경을 재개하여 시작 지연 시간을 개선합니다.

중요

애플리케이션에서 상태의 고유성이 중요한 경우 함수 코드를 평가하여 스냅샷 작업에 복원력이 있는지 확인해야 합니다. 자세한 내용은 Lambda SnapStart를 사용한 고유성 처리 단원을 참조하십시오.

주제

SnapStart를 사용하는 경우

Lambda SnapStart는 로드 모듈 종속성 또는 프레임워크와 같은 일회성 초기화 코드로 인해 발생하는 지연 시간 변동성을 해결하도록 설계되었습니다. 이러한 작업은 초기 간접 호출 중에 완료하는 데 몇 초 정도 걸릴 수 있습니다. SnapStart를 사용하여 최적의 시나리오에서 이 지연 시간을 몇 초에서 1초 미만의 지연 시간으로 줄입니다. SnapStart는 대규모 함수 호출에서 사용할 때 가장 효과적입니다. 자주 간접 호출되지 않는 함수에서는 동일한 성능 향상이 이루어지지 않을 수 있습니다.

SnapStart는 특히 두 가지 기본 유형의 애플리케이션에 유용합니다.

  • 지연 시간에 민감한 API 및 사용자 흐름: 중요한 API 엔드포인트 또는 사용자 대면 흐름의 일부인 함수는 SnapStart의 단축된 지연 시간 및 개선된 응답 시간의 이점을 누릴 수 있습니다.

  • 지연 시간에 민감한 데이터 처리 워크플로: Lambda 함수를 사용하는 시간 제한 데이터 처리 워크플로에서는 이상치 함수 초기화 지연 시간을 줄여 처리량을 개선할 수 있습니다.

프로비저닝된 동시성을 통해 함수를 초기화하고 두 자릿수 밀리초 내로 응답할 수 있습니다. 애플리케이션에 SnapStart로 적절하게 해결할 수 없는 엄격한 콜드 스타트 지연 시간 요구 사항이 있는 경우 프로비저닝된 동시성을 사용합니다.

지원 기능 및 제한 사항

SnapStart는 다음과 같은 Lambda 관리형 런타임에 대해 사용할 수 있습니다.

다른 관리형 런타임(예: nodejs22.x 및 ruby3.3), OS 전용 런타임, 컨테이너 이미지는 지원되지 않습니다.

SnapStart는 프로비저닝된 동시성, Amazon Elastic File System(Amazon EFS) 또는 512MB보다 큰 임시 스토리지를 지원하지 않습니다.

참고

게시된 함수 버전 및 버전을 가리키는 별칭에서만 SnapStart를 사용할 수 있습니다. 게시되지 않은 함수 버전($LATEST)에서는 SnapStart를 사용할 수 없습니다.

지원되는 리전

Java 런타임과 관련해 Lambda SnapStart는 아시아 태평양(말레이시아)을 제외한 모든 상용 리전에서 사용할 수 있습니다.

Python 및 .NET 런타임과 관련해 Lambda SnapStart는 다음 AWS 리전에서 사용할 수 있습니다.

  • 미국 동부(버지니아 북부)

  • 미국 동부(오하이오)

  • 미국 서부(오레곤)

  • 아시아 태평양(싱가포르)

  • 아시아 태평양(시드니)

  • 아시아 태평양(도쿄)

  • 유럽(프랑크푸르트)

  • 유럽(아일랜드)

  • 유럽(스톡홀름)

호환성 고려 사항

SnapStart를 사용하면 Lambda가 단일 스냅샷을 여러 실행 환경의 초기 상태로 사용합니다. 초기화 단계에서 함수가 다음을 사용하는 경우 SnapStart를 사용하기 전에 몇 가지 사항을 변경해야 할 수 있습니다.

Uniqueness

초기화 코드가 스냅샷에 포함된 고유한 콘텐츠를 생성하는 경우, 해당 콘텐츠가 여러 실행 환경에서 재사용될 때 콘텐츠가 고유하지 않게 될 수 있습니다. SnapStart를 사용할 때 고유성을 유지하려면 초기화 후에 고유한 컨텐츠를 생성해야 합니다. 여기에는 유사 무작위성을 생성하는 데 사용되는 고유 ID, 고유 보안 암호 및 엔트로피가 포함됩니다. 고유성을 복원하는 방법은 Lambda SnapStart를 사용한 고유성 처리 섹션을 참조하세요.

네트워크 연결

Lambda가 스냅샷에서 함수를 재개할 때, 초기화 단계에서 함수가 설정한 연결 상태는 보장되지 않습니다. 네트워크 연결 상태를 확인하고 필요에 따라 다시 설정하세요. 대부분의 경우 AWS SDK가 설정한 네트워크 연결이 자동으로 재개됩니다. 다른 연결에 대해서는 모범 사례를 참조하세요.

임시 데이터

일부 함수는 초기화 단계에서 임시 보안 인증 정보나 캐싱된 타임스탬프 같은 임시 데이터를 다운로드하거나 초기화합니다. SnapStart를 사용하지 않는 경우에도 임시 데이터를 사용하기 전에 함수 핸들러에서 해당 데이터를 새로 고치세요.

SnapStart 요금

참고

Java 관리형 런타임의 경우 SnapStart에 대한 추가 비용이 없습니다. 함수에 대한 요청 수, 코드를 실행하는 데 걸리는 시간, 함수에 대해 구성된 메모리를 기준으로 요금이 청구됩니다.

SnapStart 사용 비용에는 다음이 포함됩니다.

  • 캐싱: SnapStart를 활성화한 상태로 게시하는 모든 함수 버전에 대해 스냅샷 캐싱 및 유지 관리 비용을 지불합니다. 요금은 함수에 할당하는 메모리 양에 따라 달라집니다. 최소 3시간의 요금이 부과됩니다. 함수 버전을 삭제할 때까지 요금은 계속 청구됩니다. ListVersionsByFunction API 작업을 사용하여 함수 버전을 식별한 다음, DeleteFunction을 사용하여 미사용 버전을 삭제합니다. 미사용 함수 버전을 자동으로 삭제하려면 Serverless Land의 Lambda Version Cleanup 패턴을 참조하세요.

  • 복원: 함수 인스턴스가 스냅샷에서 복원될 때마다 복원 요금을 지불합니다. 요금은 함수에 할당하는 메모리 양에 따라 달라집니다.

모든 Lambda 함수와 마찬가지로 함수 핸들러에서 실행하는 코드에는 지속 시간 요금이 적용됩니다. SnapStart 함수의 경우 지속 시간 요금은 핸들러 외부에서 선언된 초기화 코드, 런타임에서 로드하는 데 걸리는 시간, 런타임 후크에서 실행하는 모든 코드에 적용됩니다. 지속 시간은 코드 실행을 시작한 시점부터 코드가 반환되거나 종료될 때까지 계산되며 가장 가까운 1ms 단위로 반올림합니다.

Lambda는 복원력을 위해 스냅샷의 캐시된 사본을 유지 관리하고 런타임 업그레이드 및 해당 보안 패치와 같은 소프트웨어 업데이트를 자동으로 적용합니다. Lambda가 소프트웨어 업데이트를 적용하기 위해 초기화 코드를 다시 실행할 때마다 요금이 부과됩니다.

SnapStart 사용 비용에 대한 자세한 내용은 AWS Lambda 요금을 참조하세요.