(Review) On-demand Container Loading in AWS Lambda

date

Feb 1, 2024

slug

on-demand-container-loading-in-aws-lambda

author

status

Public

tags

Paper Review

summary

“On-demand Container Loading in AWS Lambda” 논문 리뷰

type

Post

thumbnail

category

paper-review

updatedAt

Oct 1, 2025 06:23 AM

Index

• Problem

• Challenge

• Solution

• Conclusion

Problem

• AWS Lambda와 같은 Serverless Computing에서 Cold-Start 시간을 줄이는 것이 고객 경험을 결정하는 핵심

• Cold-Start는 데이터의 이동량과 연관이 큼

• AWS Lambda 초창기에는 250mb의 압축 아카이브 파일을 고객이 업로드하도록 요구, 이 압축파일을 해제하는 방식으로 배포

• 작은 단위에서는 적합하지만, 크고 복잡한 애플리케이션에 대한 수요가 많아졌으며, 이를 쉽게 관리하기 위한 Docker Container 기능에 대한 수요도 증가함

Challenge

• Cold-Start와 trade-off 하지않으면서 aws lambda에 container 기능 추가

• 10GB 크기의 15000개 컨테이너를 개인이 배포 가능하도록 (Scalability)

• 아래 3개를 고려해야 Cold-Start와 Scalability 만족
• Cacheability
• Hot Images are Hot, Cold are Cold
• Commonality
• Alpine, base 등의 기본적으로 사람들이 base layer image로 사용하는 것이 많으므로 이것을 Caching하고 Deduplication할 필요가 있음
• Sparsity
• 아무리 큰 컨테이너 데이터라도 fully hot하지 않음

• 고객이, 컨테이너 이미지를 원하는 repository에 업로드만 해도 수행할 수 있도록. (On-demand)

Background

On-demand

• 외부 서비스 공급자가 데이터를 관리하는 방식

AWS-Lambda Architecture (Based)

• Frontend
• load balanced 된 stateless한 frontend
• 여기서는 UI가 아닌 실제 function 실행을 요청하는 역할이라고 이해하는 것이 좋음
• function 실행 요청을 invoke라고 함 (multi-thread의 invoke와 유사한 맥락인듯)

• Worker Manager
• function을 실행할 수 있는 Capacity를 tracking하는 역할
• Capacity가 충분하다면 포워딩, 부족하다면 여유있는 Workers에 SandBox를 신규 생성하도록 요청

• Work Flow
• Lambda 요청 → Authentication → Worker manager → “Worker fowarding” or “identifies available Worker”

Architecture of the AWS Lambda worker

• Micro Manager
• MicroVM들을 Control하고 Monitoring/Logging하는 Control Process
 

• MicroVM
• Worker 단위 내에 존재하는 수 많은 초소형 VM
• MicroVM 하나당 한명의 소비자와 1:1 매핑 (Customer Code)
• 초소형 최적화 guest Linux Kernel (논문에서 Alpine을 docker image tag를 많이 언급하는데, based 아키텍처에서는 Alpine 정도의 크기인듯)
• lambda Shim을 통해 Programming Model과 Runtime(JVM 등) 제공
• 유저의 코드와 라이브러리(250MiB 이하의 zip 파일)는 SandBox 생성 요청 발생 시 AWS S3에서 다운로드하고 압축해제
• 위의 프로세스는 Firecracker로 VirtIO 구현으로 이루어지는데, 보안으로 인해 VirtIO가 유일하게 MicroVM과 Worker 사이에서 발생하는 것이라고 함
 

Introduction to virtio-networking and vhost-net

Virtio was developed as a standardized open interface for virtual machines (VMs) to access simplified devices such as block devices and network adaptors. Virtio-net is a virtual ethernet card and is the most complex device supported so far by virtio.

https://www.redhat.com/en/blog/introduction-virtio-networking-and-vhost-net

Firecracker

Firecracker enables you to deploy workloads in lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers. Firecracker was developed at Amazon Web Services to improve the customer experience of services like AWS Lambda and AWS Fargate .

https://firecracker-microvm.github.io/

Vertio Block

• Para Virtualization (반 가상화) 하드웨어의 일부 기능을 HostOS와 GuestOS가 공유
리눅스 컨테이너가 Para Virtualization이므로, Docker 또한 Para Virtualization

• Block device
• chunk(block)에 대한 스토리지민 retrieval을 허용하는 device, HDD, SSD 등이 해당
• Virto-blk ⇒ 블록 장치 에뮬레이션

Overlay Filesystem

• 여러 개의 파일 시스템을 하나의 파일시스템처럼 보이게 하는 기술. (셀로판지 여러 겹을 위에서 본다고 생각)

• 하위 파일 시스템의 내용을 유지하면서 상위 파일 시스템의 내용을 변경 가능

• Docker에서는 HostOS FIlesystem을 Lower로 사용하고 Upper에는 애플리케이션 관련 데이터가 속함.

• Lowerdir : Read-Only인 기본 파일 시스템

• Upperdir : Writable한 파일 시스템

• Mergedir(Overlay) : Lowerdir unionUpperdir (합집합 개념)

Solution

Block-Level Loading

• Filesystem + Overlay로 인한 복잡성 발생 ⇒ MicroVM Guest와 HyperVisor 사이에 Block-level virtual-blk를 유지하고 guest 내부에서 filesystem 작업을 처리.

• 컨테이너 이미지를 block device 이미지로 나누어 저장

• 일반적으로는 런타임 때 Overlay가 이루어지는데, Block-level Loading에서는 code, config, architecture 수정 시 trigger 될 경우만 수행하고 각 이미지 레이어가 하나의 ext4 Filesystem을 생성하도록 함. ⇒ Flattening Process

• Flattening process는 각 레이어를 하나의 ext4 파일 시스템에 품. 이때 AWS는 파일 시스템을 수정하여 모든 오퍼레이션을 deterministic하게 수행하도록 변경하였는데, 이를 통해 수정 날짜와 같은 변수들을 serial하고 deterministic하게 선택가능

• Flattened된 파일 시스템은 고정 크기의 chunk들로 나누어지고 대부분의 chunk는 캐시로 업로드됨.

• Chunk의 이름은 가지고 있는 content를 사용해 만들어지기 때문에 같은 content를 가진 chunk는 같은 이름을 갖는 것이 보장되고, 한번만 캐시가 됨.

• Chunk의 고정 크기는 512KB이다. Chunk의 크기가 커지면 메타데이터의 크기를 줄이고 데이터 로드 request가 줄어드는 효과가 생김

New AWS Lambda Architecture with Block-Level Loading

• Local Agent : Firecracker Hypervisor로의 Block Device

• Local Cache: Worker에서 자주 사용되는 chunk를 캐시

• Lambda 함수가 worker에서 새로 시작하면 Micro Manager는 새로운 local agent와 virtio block device를 가진 Firecracker MicroVM을 생성.

• 이 MicroVM이 부팅되면 supervisory 컴포넌트들과 컨테이너 이미지의 사용자 코드를 실행.

• local agent는 읽기 처리시 로컬 캐시에 chunk가 존재하면 직접 읽고 없다면 tiered cache에서 관련된 chunk를 가져옴.

• local agent는 쓰기 처리시 worker 스토리지의 block overlay에 write.

Image Deduplication

• 80%가 new function (duplicated with re-uploads, CI/CD)

• 20%가 unique chunk를 가짐

• 20% 중 평균 4.3% 만이 unique chunk

• 특정 chunk가 많이 쓰이기 때문에 해당 chunk로의 접근이 실패하거나 느려질 수 있고 이는 전체 시스템에 영향을 미칩니다.

• 손상된 데이터가 있으면 감지할 수 있으나 고치지 못합니다.

Conclusion

• 2018년 압축 패키징된 250MB의 code와 library dependencies 배포로 제한되었던 AWS Lambda를, 2020년에는 10GB의 컨테이너 이미지 배포가 가능하도록 만듦

• 단일 유저당 초당 최대 15000 개의 container scale-out이 가능하게 됨

• 초당 수 백만건의 요청 처리

• 수백만개의 unique workload 처리

• start-up (cold-start) 시간을 50ms로 줄임

• 총 수 조 건에 달하는 lambda 호출을 안정적으로 처리하게 됨