Lambda SnapStart로 시작 성능 개선

Lambda SnapStart로 시작 성능 개선 (Improving startup performance with Lambda SnapStart)

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

시작 대기 시간(흔히 콜드 스타트 시간이라고 함)의 가장 큰 요인은 Lambda가 함수를 초기화하는 데 보내는 시간입니다. 여기에는 함수 코드 로드, 런타임 시작, 함수 코드 초기화가 포함됩니다. SnapStart를 사용하면 Lambda는 함수 버전을 게시할 때 함수를 초기화합니다. Lambda는 초기화된 실행 환경의 메모리 및 디스크 상태에 대한 Firecracker MicroVM 스냅샷을 만들고, 스냅샷을 암호화하고, 검색 대기 시간을 최적화하기 위해 지능적으로 캐시합니다.

복원력을 보장하기 위해 Lambda는 각 스냅샷의 여러 복사본을 유지합니다. Lambda는 스냅샷과 그 복사본을 최신 런타임 및 보안 업데이트로 자동 패치합니다. 함수 버전을 처음 호출할 때와 호출이 확장됨에 따라 Lambda는 캐시된 스냅샷에서 새 실행 환경을 다시 시작하고 처음부터 초기화하는 대신 시작 대기 시간을 개선합니다.

중요

애플리케이션이 상태의 고유성에 의존한다면 함수 코드를 평가하고 스냅샷 작업에 탄력적인지 검증해야 합니다. 자세한 내용은 Lambda SnapStart로 고유성 처리를 참조하세요.

문제가 발생하면 Lambda 함수용 SnapStart 오류 문제 해결을 참조하세요.

출처: AWS Lambda 개발자 안내서

본문

SnapStart를 사용해야 하는 경우

Lambda SnapStart는 모듈 종속성이나 프레임워크 로딩 같은 일회성 초기화 코드가 도입하는 대기 시간 변동을 해결하도록 설계되었습니다. 이러한 작업은 초기 호출 중에 몇 초가 걸릴 수 있습니다. 최적 시나리오에서는 이 대기 시간을 몇 초에서 1초 미만으로 줄이려면 SnapStart를 사용하세요. SnapStart는 대규모로 확장되는 함수 호출과 함께 사용할 때 가장 잘 작동합니다. 드물게 호출되는 함수는 같은 성능 개선을 경험하지 못할 수 있습니다.

SnapStart는 특히 두 가지 주요 유형의 애플리케이션에 유용합니다:

대기 시간에 민감한 API 및 사용자 흐름 — 중요한 API 엔드포인트나 사용자 대면 흐름의 일부인 함수는 SnapStart의 낮아진 대기 시간과 개선된 응답 시간의 이점을 얻을 수 있습니다.
대기 시간에 민감한 데이터 처리 워크플로 — Lambda 함수를 사용하는 시간 제한 데이터 처리 워크플로는 이상값 함수 초기화 대기 시간을 줄여 더 나은 처리량을 달성할 수 있습니다.

프로비저닝된 동시성(provisioned concurrency)은 함수를 초기화된 상태로 유지해 수십 밀리초 단위로 응답할 준비가 되게 합니다. SnapStart로 적절히 해결할 수 없는 엄격한 콜드 스타트 대기 시간 요구 사항이 있으면 프로비저닝된 동시성을 사용하세요.

지원되는 기능 및 제한 사항

SnapStart는 다음 Lambda 관리형 런타임과 해당 AWS Lambda 기본 이미지를 ZIP 및 컨테이너 이미지 배포 형식 모두에서 지원합니다:

Java 11 이상
Python 3.12 이상
.NET 8 이상. .NET용 Lambda Annotations 프레임워크를 사용한다면 SnapStart 호환성을 보장하기 위해 Amazon.Lambda.Annotations 버전 1.6.0 이상으로 업그레이드하세요.

AWS Lambda 기본 이미지 또는 사용자 지정 기본 이미지 위에 빌드된 컨테이너 이미지의 경우 컨테이너 이미지용 SnapStart 훅 구현을 참조하고 SnapStart 고유성 요구 사항 처리를 위해 함수 코드를 검증하세요.

다른 관리형 런타임(예: nodejs24.x 및 ruby4.0)과 OS 전용 런타임은 지원되지 않습니다. SnapStart는 프로비저닝된 동시성, Amazon Elastic File System(Amazon EFS), Amazon S3 Files, 512MB를 초과하는 임시 스토리지를 지원하지 않습니다.

참고

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

지원 리전

Lambda SnapStart는 아시아 태평양(뉴질랜드)과 아시아 태평양(타이베이)을 제외한 모든 상용 리전에서 사용할 수 있습니다.

호환성 고려 사항

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

고유성 — 초기화 코드가 스냅샷에 포함된 고유한 콘텐츠를 생성한다면 그 콘텐츠는 실행 환경 간에 재사용될 때 고유하지 않을 수 있습니다. 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 요금을 참조하세요.

더 알아보기 (Learn more)

Lambda SnapStart 고유성 처리
SnapStart 모니터링
SnapStart 오류 문제 해결