[FireCracker]

Serverless Computing

Serverless Computing 이란 새로운 Computing Paradigm 으로 클라우드 벤더사로부터 고객이 필요한 backend service 만 제공받고 구입하는 on-demand computing 이다. 예를 들어 예전에 웹을 하나 만들려면 서버가 필요했다. 그리고 클라우드가 생긴 후에 직접 서버를 사지 않아도 클라우드 인스턴스 생성 후 웹을 배포할 수 있다. 하지만, 내가 사용하지 않는 것들도 포함이 되므로 비효율적이다. Serverless Computing 은 내가 필요한 백엔드만 구입하는 것이다.

Serverless 의 장점은 기존 VM 과 컨테이너에 비해 적은 Provision Cost 를 갖는 것이다. Provision 의 사전적 의미는 준비, 예비, 설비하다라는 뜻인데 IT 인프라 자원을 고객의 요구사항에 맞게 할당, 배치, 배포하는 것을 의미한다. 서버의 CPU, Memory 자원을 적절하게 할당하는 것을 서버 자원 프로비저닝이라 하며, OS 를 서버에 설치하고 구성 작업을 하는 것을 OS 프로비저닝이라고 한다.

• Serverless 는 VM 및 Container 에 관한 지식이 없더라도 사용할 수 있으며,

• VM, Container 할당하는 시간을 줄이어준다.

• 새로운 함수를 시작하는데 milliseconds 안에 startup 되므로, 사용자의 요구에 따라 워크 로드간 변환이 용이하다. (VM startup time is in seconds)

• Amazon Lambda 는 2014 년 클라우드 벤더사에서 처음으로 Serverless computing 을 제공하였다.

  • Linux binary file (ex ./a.out ) 을 VM/Container 생성 없이 Run 시키면 된다.

Firecracker's Motivation

Serverless 는 좋지만, multi-tenancy (여러 사람이 서버를 공유할수 있다) 측면에서 개별 workload 간의 고립성이 더 요구된다.

Better Isolation..

• Security Aspect : 하나의 워크로드는 다른 워크로드와 연관된 데이터의 접근, 추론이 불가하다.

• Performance Aspect : 자원을 많이 소모하는 noisy workload는 다른 workload 의 실행 성능을 저하시킬 수 없다.

Container 로 한 대의 서버의 여러 사용자가 사용하면서 (Multi-tanency) 경제적인 효율성은 증가하지만, 그에 따라 고립성의 필요도도 증가하고 있다. 이에 관해 AWS-EC2 도 같은 고민을 하였고 다음 2가지로 해결한 연구들이 있다.

• Hypervisor-based Virtualization

  • ex) Kata Containers(QEMU/KVM) , LightVM(Xen-sliming down)

• bare metal Instances (avoid multi-tanency)

QEMU/KVM 은 flexibility, feature completeness 에 초점을 맞춘 연구라면, Firecracker 는 Isolation, Packaing Density (as many as VMs in a server), Startup time 에 초점을 맞춘 연구이다.

전형적인 컨테이너라 하면 Docker, LXC 를 말하는데, 이들은 Linux Kernel 에 구현된 다음 3가지의 Isolation Mechanism 을 사용한다.

• Cgroups : Process grouping, Resource Throtting and accounting

• Namespaces : Separate Linux Kernel Resources into name spaces

• Seccomp-bfs : Limit access Syscall

하지만 위 리눅스 커널에서 제공하는 Isolation mechanism 에 문제점은 단일 커널에서 실행되기 때문에 "Trade off between security and code compatibility" 문제가 따른다. 즉, 보안성을 높이기 위해서는 코드 내 제한하고 있는 System call 을 사용할 수 없음을 의미한다.

FireCracker

Firecracker(FC) 는 KVM 은 유지한채로, 오직 QEMU 를 대체하는 새로운 VMM(Virtual Machine Monitor, hypervisor) 이다.

QEMU 는 heavy 하다(QEMU > 1.4 million lines). VMM 을 가볍게 만들기 위해서 Firecracker 는 KVM 을 유지한채로 QEMU 를 대체하는 방법을 사용하였다. Firecracker (50k lines 96% fewer than QEMU) 는 안전한 언어 Rust 를 사용해서 구현하였다. Firecracker가 경량화 된것은 OS 와 Security-Critical Interface 를 가지게 되면서 이전에 있었던 Code Compatibility 랑 Security 의 Tradeoff 문제를 제거하였다. crosvm(Chrome OS Virtual Machine Monitor) 코드를 사용하면서 loc(Lines of Code)를 줄이었다.

하나의 Firecracker 는 하나의 MicroVM 당 실행이 된다. REST API 를 제공하면서 microVM 의 시작 및 종료를 관리 및 설정한다. Linux Guest Kernel 을 사용한다. Apache 2 라이센스를 가진 오픈소스이다. 2018 년부터 AWS Lambda 서비스로 상용화되었다. MicroVM 은 Minimul Linux Guest 로

• 5MB footprint(memory usage)

• Boot in 125ms

• Create 150 of microVM per sec per host

Specialized for Serverless Computing

• No high-level feature : microVM 별 Firecracker 가 있듯이(Firecracker's preocess-per-VM model) 쿠버네티스와 도커와 같은 orchestration 및 meta data management 에 해당하는 high-level feature 을 지원하지 않는다.

• No low-level feature : BIOS (부팅 능력) 을 제공하지 않으며, devices ( USB, PCI, video, sound, GPU) 등을 연결할 기능도 없다.

Rate Limiter

MicroVM 에 할당된 Device(Block/Network) 사용에 제약을 설정해놓는다. 따라서 특정 MicroVM 이 자원을 독차지 하는 것을 방지하고, control plane 에게 충분한 bandwidth 을 예비해두는 역할을 한다. Rate Limiter 는 간단한 in-memory token bucket 로 구현되어 있으며, 선택적으로 단기간 burst 를 허용한다. 이는 LXC 의 cgroups 보다 덜 유연적이다.

• Block, Disk : IOPS (Operations Per Seconds)

• Network : PPS (Packets Per Seconds)

Lambda Architecture

Client 로부터 hello world 코드 실행(API) 요청이 오면, Worker Manger 가 이 코드를 수행할 수 있는 Worker 를 찾는다.

• Worker executes client code

• Worker Manager : 어떤 worker 가 코드를 수행하게 할지를 정함. use sticky routing (cache locality, connection reuse)

• If not slot is available, Placement is called (Create a new slot for the function)

Worker 는 수천개의 Slot 들을 실행시킬 수 있다.

Slot (Linux Kernel + Shim control process)

• 한 Slot 은 하나의 함수를 담당한다. Slot (=MicroVM)은 하나의 함수가 실행될 수 있도록 준비된 환경 (pre-loaded execution environment for a function) 을 의미한다.

• A slot is a sandbox for single client function with minimal linux kernel and userland and shim control process

• Slot is microVM that is a security boundary

Fast Booting

• MicroManager keeps a pool of pre-booted MicroVM (125ms booting time)

• A FC process is responsible for

  • creating and managing microVM

  • Device Emulation

  • Handle VM exits

Evaluation

• Comparison

• VM configured

• Booting time

Memory Overhead

VM 사이즈와 상관없이(irrespective of VM Sizes) 오버헤드는 동일하였다.

I/O Overhead

• Read : 특히, 4K Read 에서는 QEMU 보다 낮아서 FC의 최적화가 필요한 부분이다.

• Write : 128K Write 에서 Firecracker 는 metal 보다 빨랐다. 이는 SSD 효과(due to no implementation of flush to disk)로 보인다.

Latency

오버헤드가 크다

Network Performance

iperf3 를 사용하여서 서버와 클라이언트간 대역폭을 측정한다. MTU(Maximum Transmission Unit) 는 한 패킷의 최대 크기로 정의하며 이더넷 같은 경우 1500 Bytes이다.

Firecracker 는 1500MTU 로 가장 났았다. 호스트의 1/3 배 였으며, QEMU 보다 더 낮았다. I/O 개선이 필요한 여지가 많이 남아있으나 Firecracker 에서 채택한 Virtio 방식의 제약점(Near-Bare Metal Performance)이 있다.

Q : Is FireCracker more secure than container?

• con ) FireCracker 는 Process 이다.

• pros )

  • It reduces security surface by limitng device support (Disk & Network I/O have to go through FireCracker)

  • Minimal Linux