1. Intro
AWS re:invent 2022에서 AWS Lambda의 새로운 feature인 SnapStart를 발표했습니다.
SnapStart는 Java 언어와 함께 Lambda를 사용할 때 Cold Start 시간을 대폭 개선하기 위한 기능입니다.
Lambda의 일반적인 작동 방식과 Cold Start에 대해서 이해하고, SnapStart의 작동 방식과 SnapStart를 사용해야 하는 이유에 대해서 알아보겠습니다.
2. AWS Lambda 란?
AWS Lambda는 serverless 서비스로서, 서버를 관리할 필요가 없이 Application Code를 실행할 수 있는 Compute 서비스입니다.
Lambda는 고가용성 컴퓨팅 인프라에서 코드를 실행하고 서버 및 운영 체제 유지 관리, capacity provisioning 및 autoscaling, logging을 포함한 컴퓨팅 리소스의 모든 관리를 수행합니다.
Lambda가 지원하는 언어 런타임 중 하나의 코드를 제공하면 Lambda 기반의 서비스를 사용할 수 있습니다.
3. Cold Start 란?
SnapStart를 필요성을 알기 위해서 Lambda의 작동 방식과 Cold Start에 대해 이해해야 합니다.
AWS Lambda는 요청이 발생하는 시점에 인스턴스를 기동하고 코드를 실행합니다.
코드를 실행하기 위해서 Code 다운로드, 컨테이너 실행, Runtime 실행이 선행되어야 하는데요.
이러한 시작을 위한 작업들을 Cold Start라고 합니다.
첫 번째 요청은 Cold Start로 인해 처리하는데 많은 시간이 소요됩니다.
다음 요청을 처리할 때는 동일한 컨테이너에서 코드 실행만 하면 되므로 빠르게 처리가 가능합니다.
4. Lambda SnapStart 란?
SnapStart는 Lambda의 사전 초기화된 스냅샷을 생성하고 Cold Start 시 해당 스냅샷을 사용하여 코드를 실행하는 기능입니다.
SnapStart 기능을 사용할 경우 Lambda function을 배포하면 초기화 단계를 실행합니다.
초기화 단계가 완료되면 Lambda는 메모리 및 로컬 디스크를 포함한 전체 기능의 스냅샷 이미지를 생성하고 Caching 합니다.
Cold Start가 발생하면 Lambda는 실행 환경을 처음부터 실행하는 대신 Caching 된 스냅샷을 이용하여 런타임을 실행하여 Cold Start 시간을 개선합니다.
4.1 Cold Start는 언제 발생합니까?
Lambda는 사용한 만큼만 비용을 지불하는 서비스입니다.
요청이 없을 경우에는 인스턴스의 실행도 없고 비용도 없습니다.
요청이 발생할 경우에만 인스턴스를 기동하고 코드를 실행하게 됩니다.
아래의 예시와 같이 새로운 인스턴스 기동이 필요한 경우에는 Cold Start가 발생합니다.
• 함수에 대한 첫 번째 요청 발생 시
• 새 애플리케이션 버전 배포 시
• 일정 시간 동안 요청이 없을 경우 인스턴스가 정리되고 새로운 인스턴스가 실행될 경우
• 동시 호출 발생하여 가용한 인스턴스가 없을 경우
4.2 SnapStart 작동방식
SnapStart 기능을 사용할 경우에는 아래의 그림과 같이 2가지 Phase로 나뉘어 작동을 합니다.
기존의 Lambda 작동에서는 없었던 Deployment Phase 가 추가되었습니다.
Lambda 배포 시 Deployment Phase 가 실행되고, Lambda Function 호출 시에는 Invocation Phase만 실행됩니다.
4.2.1 1) Deployment Phase
Lambda SnapStart를 사용하려면 Lambda에 코드를 올리고 버전을 배포해야 합니다.
배포하는 동안 Lambda는 런타임을 생성하고 새 코드로 초기화 작업을 진행합니다.
초기화가 완료되면 메모리와 로컬 디스크의 상태를 스냅샷으로 생성합니다.
Lambda 버전 배포 시 alias를 지정해서 배포하며,
배포가 완료되기 전까지는 이전 Lambda 버전을 호출하여 실행합니다.
새 Lambda 버전이 배포 완료되면 새 Lambda 버전을 가리키도록 Lambda alias를 업데이트합니다.
4.2.2 2) Invocation Phase
SnapStart를 사용할 경우에는 기존의 Cold Start 3가지 단계(Code 다운로드, 컨테이너 실행, Runtime 실행)가 필요 없습니다.
대신 Restore Snapshot 단계가 있고, 이 시간 동안에는 스냅샷을 로딩하여 초기의 상태로 빠르게 복원을 진행합니다.
Restore Stage는 Cold Start 발생조건에서만 실행됩니다.
Warm Start 조건에서는 Invoke Stage만 진행됩니다.
4.3 SnapStart를 사용해야 하는 이유
Lambda를 사용할 경우 Cold Start로 인한 실행 지연 문제와 SnapStart 작동 방식에 대해서 알아보았습니다.
SnapStart를 사용하면 Cold Start 시간을 줄여서 실행 지연 문제를 해결할 수 있습니다.
뿐만 아니라 Lambda 실행 시간 단축으로 인해 사용비용도 절감이 됩니다.
SnapStart 사용에 따른 추가 비용은 없습니다.
Lambda 기반의 Java Application을 실행하는 경우에는 큰 도움이 될 것이 분명합니다.
특히 Spring Framework처럼 Bootstrap 단계에서 많은 양의 처리가 필요한 경우 도움이 됩니다.
4.4 SnapStart 사용시 주의사항
SnapStart가 Java 기반 Lambda에서 많은 장점이 있지만, 모든 경우에 SnapStart를 쓸 수 있는 것은 아닙니다.
아래의 제약사항들을 확인하고 나의 Application에서 사용이 가능한지 확인하여야 합니다.
4.4.1 1) 런타임 제약사항
SnapStart는 Java 런타임 전용이며, Java 11 및 Java 17을 지원합니다.
또한 SnapStart는 x86 아키텍처에서만 사용할 수 있으며, 프로비저닝된 동시성, EFS, 512MB보다 큰 임시 스토리지의 사용을 지원하지 않습니다.
4.4.2 2) 배포 시간 증가
SnapStart를 사용하면 Deployment Phase 단계로 인해 배포 시간이 늘어납니다.
실행 환경을 초기화하고 초기화된 함수 스냅샷을 생성하는 데 추가시간이 걸리므로 SnapStart를 사용하지 않을 때보다 배포 시간이 더 오래 걸립니다.
이 시간은 Lambda 함수의 초기화 시간 및 스냅샷의 전체 크기에 따라 달라집니다.
CICD Pipeline 을 통해 배포를 할 경우 빌드 시간이 늘어나는 것으로 인해 개발 생산성 저하와 빌드 자원에 대한 비용의 증가로 이어질 수 있습니다.
환경별로 SnapStart 적용 여부를 다르게 하여 생산성을 높일 필요가 있습니다.
4.4.3 3) 고유성(Uniqueness)
난수 데이터의 Seeding에 대한 문제가 있습니다. 고유성을 유지해야 되는 값이 스냅샷에 포함된 경우 고유성을 유지할 수 없습니다.
예를 들면, Bootstrap 단계에서 생성되는 난수가 global 변수로 저장될 경우 해당 변수는 스냅샷에 포함이 됩니다. 모든 Lambda 함수는 동일한 값을 사용하게 되어 고유성을 잃게 됩니다.
이를 해결하기 위해서 고유성을 유지해야 되는 데이터를 handler function에서 생성하거나, 런타임 hook을 이용하여 처리해야 됩니다.
5. Outro
다른 런타임보다 Java 기반의 Application이 Cold Start의 영향을 많이 받았었는데요.
SnapStart의 발표로 Lambda에서의 Java 사용이 더 자유로워졌습니다.
Java 개발자들도 Computing 환경으로 Lambda를 고려할 가능성이 더 커졌고, Lambda가 더 많이 활성화될 것으로 기대됩니다.
