Lambda SnapStart를 사용하여 시작 성능 개선
Java용 Lambda SnapStart는 일반적으로 함수 코드를 변경하지 않고도 추가 비용 없이 지연 시간에 민감한 애플리케이션의 시작 성능을 최대 10배까지 높일 수 있습니다. 시작 지연 시간(콜드 스타트 시간이라고도 함)이 발생하는 가장 큰 원인은 Lambda가 함수를 초기화하는 데 시간을 소비하기 때문입니다. 여기에는 함수 코드 로드 시간, 런타임 시작 시간, 함수 코드 초기화 시간이 포함됩니다.
SnapStart를 사용하면 함수 버전을 게시할 때 Lambda가 함수를 초기화합니다. Lambda는 초기화된 실행 환경의 메모리 및 디스크 상태 Firecracker microVM
중요
애플리케이션에서 상태의 고유성이 중요한 경우 함수 코드를 평가하여 스냅샷 작업에 복원력이 있는지 확인해야 합니다. 자세한 내용은 Lambda를 사용한 고유성 다루기 SnapStart 단원을 참조하십시오.
주제
지원 기능 및 제한 사항
SnapStart는 Java 11 및 그 이상의 Java 관리형 런타임을 지원합니다. 다른 관리형 런타임(예: nodejs20.x 및 python3.12), OS 전용 런타임, 컨테이너 이미지는 지원되지 않습니다.
SnapStart는 프로비저닝된 동시성, arm64 아키텍처, Amazon Elastic File System(Amazon EFS) 또는 512MB보다 큰 임시 스토리지를 지원하지 않습니다.
SnapStart로 작업을 수행하는 데에는 Lambda 콘솔, AWS Command Line Interface(AWS CLI), Lambda API, AWS SDK for Java, AWS CloudFormation, AWS Serverless Application Model(AWS SAM) 및 AWS Cloud Development Kit (AWS CDK)를 사용할 수 있습니다. 자세한 내용은 Lambda 활성화 및 관리 SnapStart 단원을 참조하십시오.
참고
지원되는 리전
SnapStart는 다음 AWS 리전에서 사용할 수 있습니다.
미국 동부(버지니아 북부)
미국 동부(오하이오)
미국 서부(캘리포니아 북부)
미국 서부(오레곤)
아프리카(케이프타운)
아시아 태평양(홍콩)
아시아 태평양(뭄바이)
아시아 태평양(하이데라바드)
아시아 태평양(도쿄)
아시아 태평양(서울)
아시아 태평양(오사카)
아시아 태평양(싱가포르)
아시아 태평양(시드니)
아시아 태평양(자카르타)
아시아 태평양(멜버른)
캐나다(중부)
유럽(스톡홀름)
유럽(프랑크푸르트)
유럽(취리히)
유럽(아일랜드)
유럽(런던)
유럽(파리)
유럽(밀라노)
유럽(스페인)
중동(UAE)
중동(바레인)
남아메리카(상파울루)
호환성 고려 사항
SnapStart를 사용하면 Lambda가 단일 스냅샷을 여러 실행 환경의 초기 상태로 사용합니다. 초기화 단계에서 함수가 다음을 사용하는 경우 SnapStart를 사용하기 전에 몇 가지 사항을 변경해야 할 수 있습니다.
- Uniqueness
-
초기화 코드가 스냅샷에 포함된 고유한 콘텐츠를 생성하는 경우, 해당 콘텐츠가 여러 실행 환경에서 재사용될 때 콘텐츠가 고유하지 않게 될 수 있습니다. SnapStart를 사용할 때 고유성을 유지하려면 초기화 후에 고유한 컨텐츠를 생성해야 합니다. 여기에는 유사 무작위성을 생성하는 데 사용되는 고유 ID, 고유 보안 암호 및 엔트로피가 포함됩니다. 고유성을 복원하는 방법은 Lambda를 사용한 고유성 다루기 SnapStart 섹션을 참조하세요.
- 네트워크 연결
-
Lambda가 스냅샷에서 함수를 재개할 때, 초기화 단계에서 함수가 설정한 연결 상태는 보장되지 않습니다. 네트워크 연결 상태를 확인하고 필요에 따라 다시 설정하세요. 대부분의 경우 AWS SDK가 설정한 네트워크 연결이 자동으로 재개됩니다. 다른 연결에 대해서는 모범 사례를 참조하세요.
- 임시 데이터
-
일부 함수는 초기화 단계에서 임시 보안 인증 정보나 캐싱된 타임스탬프 같은 임시 데이터를 다운로드하거나 초기화합니다. SnapStart를 사용하지 않는 경우에도 임시 데이터를 사용하기 전에 함수 핸들러에서 해당 데이터를 새로 고치세요.
SnapStart 요금
SnapStart를 사용하는 데 따른 추가 비용이 없습니다. 함수에 대한 요청 수, 코드를 실행하는 데 걸리는 시간, 함수에 대해 구성된 메모리를 기준으로 요금이 청구됩니다. 지속 시간은 코드 실행을 시작한 시점부터 코드가 반환되거나 종료될 때까지 계산되며 가장 가까운 1ms 단위로 반올림합니다.
지속 시간 요금은 함수 핸들러에서 실행되는 코드, 핸들러 외부에서 선언된 초기화 코드, 런타임(JVM)을 로드하는 데 걸리는 시간, 런타임 후크에서 실행되는 모든 코드에 적용됩니다. Lambda의 기간 계산 방식에 대한 자세한 내용은 Lambda에 대한 모니터링 SnapStart의 내용을 참조하세요.
SnapStart를 사용하여 구성된 함수의 경우 Lambda는 주기적으로 실행 환경을 재활용하고 초기화 코드를 다시 실행합니다. Lambda는 복원성을 위해 여러 가용 영역에 스냅샷을 생성합니다. Lambda가 다른 가용 영역에서 초기화 코드를 다시 실행할 때마다 요금이 부과됩니다. Lambda의 요금 계산 방식에 대한 자세한 내용은 AWS Lambda 요금
Lambda SnapStart와 프로비저닝된 동시성 비교
Lambda SnapStart와 프로비저닝된 동시성은 모두 함수가 스케일 업될 때 콜드 스타트와 비정상적인 지연 시간을 줄일 수 있습니다. SnapStart를 사용하면 추가 비용 없이 시작 성능을 최대 10배까지 높일 수 있습니다. 프로비저닝된 동시성은 두 자릿수 밀리초 내에 함수가 초기화되고 응답 준비가 되도록 합니다. 프로비저닝된 동시성을 구성하면 AWS 계정에 요금이 부과됩니다. 애플리케이션에 엄격한 콜드 스타트 지연 시간 요구 사항이 있는 경우 프로비저닝된 동시성을 사용하세요. 동일한 함수 버전에 SnapStart와 프로비저닝된 동시성을 모두 사용할 수는 없습니다.
참고
SnapStart는 대규모 함수 호출에서 사용할 때 가장 효과적입니다. 자주 호출되지 않는 함수에서는 동일한 성능 향상이 이루어지지 않을 수 있습니다.
추가적인 리소스
이 장의 다른 주제를 읽어보는 것 외에도 AWS Lambda SnapStart를 통한 더 빠른 시작
