AWS Lambda MicroVMs는 가상 머신 수준의 격리, snapshot에서의 거의 즉각적인 실행, 그리고 일시 중단 후 재개할 수 있는 상태 유지형 실행을 제공하는 새로운 서버리스 컴퓨트 프리미티브다. 이미 월 15조 회가 넘는 Lambda 호출을 떠받치고 있는 그 가벼운 가상화 기술, Firecracker 위에서 동작한다. 짧게 요약하면 이렇다. Lambda가 각 세션에 전용의, 격리된, 오래 살아남는 샌드박스를 건네줄 수 있게 됐고, 그것도 사용자가 직접 가상화를 관리하지 않고도 가능해졌다.

여러분의 애플리케이션이 직접 작성하지 않은 코드를 안전하게 실행하려고 시도해 본 적이 있다면, 멀티 테넌트 코드 실행, 인터랙티브 노트북, 취약점 스캐너 같은 작업이라면, 이게 왜 중요한지 이미 알 것이다. 지금까지의 솔직한 답은 "컨테이너나 VM을 띄우고 오케스트레이션, 격리, 라이프사이클 배관을 직접 구축하라"였다. MicroVMs는 그 모든 것을 API 호출 하나로 압축한다.

실제로 무엇이 새로운가

일반적인 Lambda 함수는 상태가 없고, 수명이 짧으며, 이벤트 기반이다. 그 용도로는 최고다. 하지만 몇 분에서 몇 시간 동안 살아 있고, 메모리에 상태를 유지하며, 신뢰할 수 없는 코드를 커널 수준에서 격리해야 하는 세션이 필요할 때는 잘못된 도구다. MicroVMs는 같은 서비스 안에 있는 다른 프리미티브로, 바로 그 공백을 정조준한다. AWS는 이를 오늘 이전까지 단일 AWS 컴퓨트 서비스가 한꺼번에 제공하지 못했던 세 가지 역량으로 설명한다.

1. VM 수준 격리

각 세션은 사용자 간에 커널을 공유하지 않고 리소스도 공유하지 않는 전용 MicroVM 안에서 실행된다. 그것이 바로 Firecracker의 보장이다. 한 테넌트의 신뢰할 수 없는 코드는 자신의 환경 안에 갇혀, 다른 환경이나 호스트로 향하는 경로가 없다. 컨테이너는 커널을 공유하지만 MicroVM은 그렇지 않다. 직접 작성하지 않은 코드를 실행한다면, 바로 그 경계가 핵심 그 자체다.

2. Snapshot 기반의 빠른 실행과 재개

모델은 이미지 빌드 후 실행 방식이다. Dockerfile과 Amazon S3에 있는 코드 아티팩트로 MicroVM 이미지를 빌드한다. Lambda는 Dockerfile을 실행하고, 애플리케이션을 초기화한 뒤, 실행 중인 메모리와 디스크 상태의 Firecracker snapshot을 떠 둔다. 그 이미지에서 실행되는 모든 MicroVM은 콜드 부팅 대신 미리 초기화된 snapshot에서 재개한다. 수 기가바이트짜리 인터랙티브 세션조차 라이브처럼 느껴질 만큼 빠르게 돌아온다. 이것은 SnapStart 아이디어를 논리적 극한까지 밀어붙인 것이다. 프로세스를 시작하는 것이 아니라, 이미 실행 중이던 프로세스를 복원하는 것이다.

3. 상태 유지 및 일시 중단 가능한 실행

실행 중인 MicroVM은 세션 동안 메모리, 디스크, 프로세스를 그대로 유지한다. 유휴 상태가 되면 상태를 온전히 보존한 채 일시 중단할 수 있고, 트래픽이 돌아오면 재개된다. 설치된 패키지, 로드된 데이터, 작업 파일이 전부 그대로 남아 있다. MicroVMs는 최대 8시간의 총 실행 시간을 지원하며 설정 가능한 유휴 시간이 지나면 자동으로 일시 중단된다. 이것이 바로 기존의 상태 없는 서버리스라는 전제를 깨는 부분이고, 좋은 의미에서 그렇다.

운영 관점에서 어떤 모습인가

두 번의 CLI 호출이 워크플로의 대부분을 담당한다. 먼저 이미지를 빌드한다.

aws lambda-microvms create-microvm-image \
  --code-artifact uri=<path/to/s3/artifact.zip> \
  --name my-sandbox \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn <build role ARN>

빌드 로그는 /aws/lambda/microvms/<image-name> 아래 CloudWatch로 스트리밍되고, 완성된 이미지는 자체 ARN과 버전을 가지고 나타난다. 그런 다음 그 이미지에서 MicroVM을 실행한다.

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-sandbox \
  --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

Lambda는 고유한 MicroVM ID와 전용 엔드포인트 URL을 반환하며, snapshot에서 재개됐기 때문에 애플리케이션은 이미 실행 중인 상태다. 네트워킹을 따로 구성할 필요가 없다. idle-policy가 바로 라이프사이클 제어가 위치하는 지점이다. 일시 중단까지 얼마나 유휴 상태로 둘지, 종료까지 얼마나 일시 중단 상태로 둘지, 그리고 다음 요청에서 자동으로 재개할지를 정한다.

어디에 맞고, 어디에 맞지 않는가

MicroVMs를 선택해야 할 때일반 Lambda를 유지해야 할 때
신뢰할 수 없거나 사용자가 제공한 코드를 실행하고 커널 수준 격리가 필요할 때코드가 신뢰할 수 있고 작업이 짧고 상태 없는 변환일 때
세션이 몇 분에서 몇 시간 동안 메모리에 상태를 유지해야 할 때각 호출이 독립적이고 수 초 안에 끝날 때
플릿을 직접 운영하지 않고 사용자별 전용 환경을 원할 때관리형 실행 환경을 공유해도 괜찮을 때
유휴 구간이 정상적이며, 유휴 상태로 비용을 내는 대신 일시 중단 후 재개를 원할 때트래픽이 일정하고 요청-응답이 전부일 때

MicroVMs는 함수의 대체재가 아니며, 24시간 내내 돌아가는 서버를 저렴하게 운영하는 방법도 아니다. 8시간 상한과 일시 중단 후 재개 모델은 세션을 위해 설계됐다. 사용자가 열어 두었다가 떠나는 코딩 샌드박스, 10분간 돌아가는 스캔, 두 시간 동안 처리하다가 조용해지는 분석 작업 같은 것들이다. 워크로드가 끊임없이 바쁜 장기 실행 서비스라면 그것은 여전히 ECS나 EC2의 영역이다.

알아 둘 만한 snapshot 주의점

모든 MicroVM이 미리 초기화된 snapshot에서 재개되기 때문에, 앱이 초기화 도중에 매번 새로 시작된다고 가정하고 하는 작업은 여러분을 놀라게 할 수 있다. 시작 시점에 생성되는 고유 ID, 부팅 시 열리는 네트워크 연결, 랜덤 시드, 한 번만 로드되는 일시적 데이터는 모두 snapshot에 얼어붙은 채 실행 간에 재사용될 수 있다. 이것은 SnapStart 사용자가 이미 알고 있는 것과 같은 부류의 함정이다. 세션마다 고유하거나 새로워야 하는 것이라면 초기화 중이 아니라 재개 이후에 생성하라. AWS는 이를 위한 훅을 제공하며, 연결 지향적이거나 보안에 민감한 작업이라면 그 훅이 필요할 것이다.

핵심 요점

Lambda MicroVMs는 서버리스가 더 이상 상태 없고 수명 짧은 것만이 아니게 됐다는 지금까지 가장 분명한 신호다. 이제 실질적인 격리, snapshot 속도의 시작, 일시 중단 후 재개되는 상태를 갖춘 관리형 Firecracker 샌드박스를, 두 번의 API 호출과 하나의 idle 정책으로 얻게 된다. 멀티 테넌트 코드 실행을 구축하는 사람이라면 이는 그 일에서 가장 어렵고 차별화되지 않는 부분, 즉 격리와 라이프사이클 배관을 제거해 준다. 제품을 만들고, MicroVM 플릿 운영은 Lambda에 맡겨라.

다음으로 읽어 보기

같은 출시에 대한 AI 및 에이전트 관점, 즉 MicroVMs가 왜 AI가 생성한 코드를 실행하기 위해 설계됐는지는 ercan.ai의 필드 노트에서 확인하라. AWS, 서버리스, 플랫폼 작업에 대한 컨설팅이 필요하거나 그냥 인사를 건네고 싶다면 ercanermis.com에서 시작하라.