container보다 빠른 새로운 가상화 기술 Firecracker
Reference
[1] https://firecracker-microvm.github.io/
[2] https://www.redhat.com/ko/topics/virtualization/what-is-KVM]
[3] https://www.redhat.com/ko/topics/virtualization/what-is-virtualization
[4] https://en.wikipedia.org/wiki/Hypervisor
Firecracker 오픈 소스 가상화 기술로 함수 기반 서비스(FaaS)를 만들고 관리하기 위한 목적으로 만들어졌습니다. 기존 container의 startup 시간과 가상화 및 작업 부하 격리 기능을 최적화 하였습니다. Firecracker를 사용하여 컨테이너 속도와 리소스 효율성을 보장하여 향상된 기능을 제공하여 microVM이라는 시스템을 제공합니다. Firecracker는 AWS Lambda와 AWS Fargate와 같은 서비스에서 사용되며 고객의 경험을 토대로 개발되고 있습니다.
Firecracker는
2014년 11월 AWS가 Lambda를 출시 했을 때 Serverless 환경을 제공하는데 주력 했습니다. 고객 별로 EC2 인스턴스를 사용해 고객 간의 강력한 보안 과 자원 격리(isolation)을 제공했습니다. Lambda가 성장함에 따라 매우 안전하고 유연하며 효율적인 런타임 환경을 제공하는 기술이 필요하게 되었습니다. 하드웨어 가상화 기술과 EC2 인스턴스를 구축하는 경험으로 container 시스템과 통합되도록 VMM을 구축하기 위해 노력을 했다고 합니다.
Firecracker는 AWS Lambda와 Fargate와 같은 서비스를 통해 자원 활용률과 고객 사용 환경을 개선하는 동시에 퍼블릭 클라우드 인프라에 필요한 보안 그리고 격리(isolation)을 제공하기 위해 AWS 개발자에 의해 구축이 되었습니다. Firecracker는 Rust라는 언어로 작성된 오픈 소스 VMM인 Chromium OS의 가상 시스템 모니터(crosvm)에서 시작되었습니다. 이후에 crosvm과 Firecracker는 다양한 고객 요구사항을 충족하기 위해 서로 다른 방식으로 개발되고 있습니다.
Firecracker는 아직 Kubernetes와 Docker 또는 Kata containers와 함께 사용되지는 않습니다. 이유는 컨테이너를 동작시키기 위한 보안 접근이 Firecracker와 다르기 때문입니다. 향후 container 생태계와 자연스럽게 통합하기 위해 노력하고 있다고 합니다.
Firecracker와 Kata 컨테이너의 차이점은 Kata 컨테이너는 QEMU 가상 기반 시스템 내에서 컨테이너를 실행하는 OCI 호환 컨테이너 런타임입니다. Firecracker는 QEMU의 클라우드 네이티브 대안으로, 안전하고 효율적으로 container를 동작하도록 제작되었습니다. 필수적이지 않은 device를 제외하고 guest OS의 최소한 모듈(virtio-net, virtio-block, serial console, 1-button keyboard controller(microVM을 종료하기 위한))만을 제공합니다. 이를 통해 간소화된 kernel 로딩 프로세스로 125ms의 시작 시간과 메모리 공간을 줄일 수 있습니다.
Firecracker은 Linux KVM(Kernel-based Virtual Machine)을 사용하여 microVM을 만들고 관리하는 VMM(Virtual Machine Monitor)을 구현합니다. FaaS 서비스에 적합하도록 불필요한 디바이스와 게스트(guest) 기능을 제거해 최소한의 디자인으로 개발되어 메모리 사용량을 줄였습니다. 현재 Intel CPU를 지원하며 AMD, ARM 지원할 예정입니다. Firecracker는 또한 인기있는 container 런타임 ‘containerd’와 통합될 예정입니다.
* 가상화(virtualization)
하드웨어 종속된 자원을 사용해 여러 환경으로 배포해 서버의 가용성을 높입니다.
Hypervisor와 같은 가상화 지원 기술로 여러 명의 사용자가 동시에 액세스할 수 있습니다.
* VMM(Virtual Machine Monitor) or Hypervisor
Hypervisor는 소프트웨어가 물리적 자원을 필요로 하는 가상 환경으로부터 자원을 분리합니다. 필요에 따라 여러 환경으로 파티션됩니다.
* KVM(Kernel-based Virtual Machine : 커널 기반 가상 머신)
Linux에 구축되는 오픈 소스 가상화(virtualization) 기술입니다. KVM을 통해 Linux를 하이퍼바이저(hypervisor)로 전환하여 호스트 머신이 Guest 또는 VM(가상 머신)등 독립된 가상 환경 여러 개를 실행할 수 있습니다. 기본적으로 QEMU라는 가상 머신 실행 프로그램 기반으로 구동되며 리눅스 기반의 커널에서 CPU의 가상화 지원을 이용합니다.
KVM은 Linux를 Type 1(bare metal) Hypervisor로 전환합니다. 모든 Hypervisor에서 VM을 실행하려면 메모리 관리 프로그램, 프로세스 스케줄러, I/O, 드라이버, 네트워크와 같은 구성요소가 필요합니다. KVM은 Linux 커널의 일부이므로 모두 포함하고 있습니다. 모든 VM은 표준 Linux 스케줄러를 통해 일정이 예약되며, CPU, 메모리, 디스크, 그래픽, 네트워크 카드와 같은 전용 가상 하드웨어를 사용해 일반적인 Linux 프로세스로 구현됩니다.
* KVM의 기능
(1) 스케줄링과 리스소 관리 : VM은 커널에 의해 예약되고 관리되는 Linux 프로세스입니다.
(2) KVM은 게스트 머신과 요청이 증가할 수록 로드 부하에 맞춰 확장합니다.
(3) 메모리 관리 : NUMA(Non-Uniform Memory Access)와 KSM(Kernel Same-page Merging)을 포함한 Linux의 메모리 관리 기능을 그대로 제공합니다. VM 메모리는 swap 기능을 이용해 디스크 파일에서 이를 공유하거나 지원할 수 있습니다.
(4) 스토리지
* QEMU
하드웨어 가상화 기능을 갖춘, 오픈소스 CPU 에뮬레이터입니다.
Firecracker 특징
1. Firecracker는 같은 머신에서 여러 유저의 workload를 안전하게 실행할 수 있습니다.
2. 유저는 application 요구 사항에 맞춰 vCPU와 메모리를 설정해 microVM을 생성할 수 있습니다.
3. Firecracker microVM은 host 머신의 cpu와 메모리를 초과로 설정이 가능합니다. 초과 설정은 호스트 시스템 작동을 원활하게 하기 위해 workload를 부과하는 사용자에 의해 제어됩니다.
4. microVM은 minimal linux kernel과 단일 코어 CPU 그리고 128 Mib 메모리 RAM으로 설정시에 Firecracker는 호스트 머신에서 초당 5개의 microVM을 지원합니다. 36개의 물리적 core를 가진 호스트 머신에서는 초당 180개의 microVM을 생성할 수 있습니다.
5. 동시 실행 가능한 Firecracker의 microVM 수는 호스트 머신의 하드웨어 자원에 따라 제한됩니다.
6. 각각의 microVM은 HTTP 서버를 통해 호스트와 api 통신합니다.
7. 각각의 microVM은 /mmds (micro metadata service) 를 통해 호스트에서 설정된 metadata에 대한 guest 액세스를 제공합니다.
Firecracker 이점
Security 보안
Firecracker의 장점은 KVM 기반의 가상화 기술을 이용해 향상된 보안을 제공합니다. 이를 통해서 같은 머신(machine)에서 다른 고객간의 workload를 안전하게 실행할 수 있습니다.
Speed by design 속도
최소한의 device 모델 외에도 kernel 로드를 가속화하고 guest의 커널 구성을 최소한으로 제공하여 빠른 시작 시간을 제공합니다. firecracker를 사용하면 user space 또는 어플리케이션(application)의 코드를 초기화하는데 125ms 시간으로 매우 빠릅니다. 또한 호스트 하나에서 초당 150 microVM개를 생성할 수 있습니다.
Scale and efficiency 효율성
각 MicroVM은 5Mib 미만의 메모리 오버헤드로 실행되므로 각 서버에 고밀도의 microVM을 저장할 수 있습니다.
Firecracker는 각 microVM에 rate limiter를 제공합니다. 이를 통해 수천 개의 microVM에 네트워크와 저장 공간을 최적화하여 자원을 공유할 수 있습니다.
Firecracker 동작 원리
Firecracker 동작 원리는 다음과 같습니다. 사용자 공간에서 실행되며 Linux 커널 기반의 가상 머신인 KVM(Linux Kernel-based Virtual Machine)을 사용하여 microVM을 생성합니다. 각 microVM은 빠른 시작 시간과 낮은 메모리 오버헤드를 통해 수천 개의 microVM을 동일한 시스템에 패키징할 수 있습니다. 모든 기능과 컨테이너 그룹을 캡슐화할 수 있으므로, 보안이나 효율성에 대한 trade-off 없이 서로 다른 유저의 workload를 동일한 시스템에서 실행할 수 있습니다. 따라서 기존의 QEMU를 대체할 수 있는 새로운 VMM입니다. vCPU나 시스템 시작과 같은 작업을 RESTful API를 통해 Firecracker 프로세스를 제어할 수 있습니다.
Firecracker design
https://github.com/firecracker-microvm/firecracker/blob/master/docs/design.md
Host Integration
다음의 그림은 host 머신에서 실행 중인 firecracker microVM을 묘사한 구성도입니다. Firecracker는 4.14 이상의 kernel이 있는 Linux 호스트와 guest OS에서 실행됩니다. production 환경에서는 Firecracker는 jailer라는 바이너리 파일로 시작되어야 합니다. firecracker 바이너리 파일로 직접 실행 가능하나 이후에 사용되지 않을 예정입니다. 프로세스를 실행한 후에 유저는 InstanceStart를 실행하기 전에 Firecracker API를 통해 microVM 설정을 할 수 있습니다.
스토리지(storage)는 firecracker에서 에뮬레이션된 block device가 호스트의 파일에 백업됩니다. guest OS에 block 디바이스를 마운트하기 위해서는 guest kernel이 지원하는 파일 시스템으로 미리 포맷해야 됩니다.
Internal Architecture
[1] Machine Model
각 Firecracker 프로세스는 하나의 microVM 만을 캡슐화(encapsulation) 합니다. 프로세스는 API, VMM 그리고 vCPU와 같은 thread를 실행합니다. API thread는 Firecracker의 API 서버와 제어를 담당합니다. VMM thread는 머신 모델, micro VM metaservice(MMDS) 그리고 net 그리고 block device를 에뮬레이터한 VirtIO를 expose 합니다. 이것을 포함해 vCPU thread는 하나 이상이 있으며, KVM을 통해 생성되고, KVM_RUN이라는 메인 루프를 실행합니다. 장치 모델에서 동기식(synchronous) I/O 그리고 메모리 매핑 I/O 작업을 실행합니다.
Firecracker는 에뮬레이션된 VirtIO Net과 Block을 이용해 storage와 network에 접속합니다. 또한 serial 콘솔과 keyboard controller를 부분적으로 제공하여 VM을 재설정하는 사용됩니다. 게스트는 Firecracker가 제공하는 장치 모델 외에도 KVM이 지원하는 PIC(Programmable Interrupt Controller), IOAPIC(I/O Advanced Programmable Interrupt Controller), PIT(Programmable Interval Timer)도 참조한다.
[2] CPU
Firecracker는 호스트의 프로세서 정보 또는 다른 CPU의 family/model 중 하나를 실행해 호환성을 유지합니다. 추가적으로 Firecracker는 CPUID를 통해 feature masking을 제공합니다. 유저의 운영을 단순화하기 위해서 Firecracker API를 통해 CPU feature를 설정할 수 있습니다. 현재 이용 가능한 feature template은 AWS EC2와 T2 instance type으로 설정 가능합니다.
[3] I/O: 스토리지, 네트워킹 및 속도 제한
Firecracker는 Virt/blcok 및 VirtIO/net 에뮬레이션된 디바이스와 함께 각 볼륨 및 네트워크 인터페이스에 속도 제한 장치를 적용하여 호스트 하드웨어 리소스가 여러 microVM에서 공정하게 사용되도록 보장합니다. 두 개의 버킷을 기반으로 하는 토큰 버킷 알고리즘(https://en.wikipedia.org/wiki/Token_bucket)을 사용하여 구현됩니다. 하나는 초당 작업 수와 연결되고 다른 하나는 대역폭과 연결됩니다. 유저는 수신 및 송신 토큰 버킷 구성을 지정하여 API를 통해 속도 제한을 생성하고 구성할 수 있습니다. 각 토큰 버킷은 버킷 크기, I/O 비용, 리필 속도, 최대 버스트 및 초기 값을 통해 정의됩니다. 이를 통해 고객은 버스트 또는 특정 대역폭/작동 제한을 지원하는 유연한 속도 제한을 정의할 수 있습니다.
[4] MicorVM Metadata Service
Firecracker microVM은 API를 통해 게스트에 최소한의 액세스 권한만 노출합니다. 서비스에서 저장하는 메타데이터는 사용자가 완전히 구성합니다.
[5] Jailing
Firecracker 프로세스는 jailer 프로세스로 시작됩니다. jailer는 시스템 자원에 대해 높은 권한인 cgroup, chroot을 설정하고 권한 삭제를 하고 exec로 권한이 없는 프로세스로 시작됩니다. 이 시점에서는 권한이 부여된 리소스에만 액세스할 수 있습니다.
[6] cgroup and quotas.
각 Firecracker microVM은 cgroup에 추가로 캡슐화됩니다. cpuset 하위 시스템을 통해 Firecracker microVM의 선호도를 노드로 설정하면 해당 microVM이 노드 간에 마이그레이션되는 것을 방지할 수 있습니다. 이 경우 성능이 저하되고 공유 리소스에 불필요한 경합이 발생할 수 있습니다. 각 Firecracker microVM은 선호도 설정 외에도 CPU 시간에 대한 자체 전용 할당량을 cpu 하위 시스템을 통해 가질 수 있으므로 Firecracker microVM 간에 리소스가 상당히 공유됩니다.
[7] Monitoring
Firecracker는 API를 통해 전달되는 명명된 파이프에 각각 로그 및 메트릭 카운터를 방출합니다. 로그는 한 줄씩 플러시되지만, 인스턴스가 시작될 때 메트릭이 방출되고 실행 중이거나 패닉 상태일 때 메트릭이 60초마다 방출됩니다. Firecracker 고객은 Firecracker 로그 파일에서 데이터를 수집할 책임이 있습니다. 프로덕션 빌드에서 Firecracker는 호스트에서 볼 수 없는 게스트 데이터를 포함할 수 있기 때문에 직렬 콘솔 포트를 노출시키지 않습니다.
GitHub 주소는 다음과 같습니다. https://github.com/firecracker-microvm/firecracker
binary 파일을 build/debug에 위치합니다.
$ sudo apt install -y cpu-checker
$ kmv-ok
$ sudo setfacl -m u:${USER}:rw /dev/kvm
$ git clone https://github.com/firecracker-microvm/firecracker
$ cd firecracker
$ sudo tools/devtool build
설치가 진행됩니다.
$ cd build/debug
$ ls
$ sudo chmod +x firecracker
$ curl -fsSL -o hello-vmlinux.bin https://s3.amazonaws.com/spec.ccfc.min/img/hello/kernel/hello-vmlinux.bin
$ curl -fsSL -o hello-rootfs.ext4 https://s3.amazonaws.com/spec.ccfc.min/img/hello/fsfiles/hello-rootfs.ext4
$ ls
$ mv hello-* ./
$ sudo -i
$ cd /home/kimjc/firecracker/build/debug/
처음 시작할 경우
$ rm -f /tmp/firecracker.socket
$ ./firecracker --api-sock /tmp/firecracker.socket
두 번째 터미널은 열고 api를 이용해 firecracker에게 전달한다.
ref : https://github.com/firecracker-microvm/firecracker/blob/master/docs/getting-started.md
$ sudo -i
0. microVM cpu와 메모리 설정
sudo curl --unix-socket /tmp/firecracker.socket -i \
-X PUT "http://localhost/machine-config" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-d "{
\"vcpu_count\": 2,
\"mem_size_mib\": 3008
}"
1. Guest kernel 설정
curl --unix-socket /tmp/firecracker.socket -i \
-X PUT 'http://localhost/boot-source' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"kernel_image_path": "./hello-vmlinux.bin",
"boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
}'
2. Guest rootfs 루트 파일 시스템 설정
curl --unix-socket /tmp/firecracker.socket -i \
-X PUT 'http://localhost/drives/rootfs' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"drive_id": "rootfs",
"path_on_host": "./hello-rootfs.ext4",
"is_root_device": true,
"is_read_only": false
}'
3. Guest 머신 시작
curl --unix-socket /tmp/firecracker.socket -i \
-X PUT 'http://localhost/actions' \
-H 'Accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"action_type": "InstanceStart"
}'
첫 번째 터미널에서 Guest 머신 부팅을 확인할 수 있다.
Amazon Image로 실행이 된다.
첫 번째 터미널로 돌아와서 로그인을 한다. id : root , password : root
doc에서 현재 사용 가능한 CPU 템플릿은 C3, T2 타입이다.
자원 리소스를 확인해본다. 결과는 t2 type이고 cpu core 1개에 memory 1G로 default로 설정되어 있다.
$ cat /proc/cpuinfo
$ cat /proc/meminfo
Firecracker API
https://github.com/firecracker-microvm/firecracker/blob/master/api_server/swagger/firecracker.yaml
천 개의 microVM을 생성하는 법
for ((i=0; i<1000; i++)); do
./firecracker-v0.10.1 --api-sock /tmp/firecracker-$i.sock &
done
'AWS' 카테고리의 다른 글
AWS Certified Cloud Practitioner 클라우드 자격증 실전 문제를 활용한 준비-[1] (0) | 2020.12.14 |
---|---|
AWS Certified Cloud Practitioner 클라우드 자격증 (0) | 2020.12.13 |
AWS Lambda PyTorch RNN 모델 서빙하기 (0) | 2019.01.23 |
AWS Lambda Serverless MapReduce (0) | 2019.01.23 |
AWS EC2와 Lambda iPerf3 네트워크 성능 측정 (0) | 2019.01.09 |