My VM is Lighter (and Safer) than your Container

• SOSP ‘17 발표 논문
• 논문 링크

Motivation

Core Problems

이 논문은 클라우드 컴퓨팅 및 분산 시스템의 근본적 딜레마인

• 가상 머신 (Virtual Machine) 의 격리 및 보안
• 컨테이너의 효율성

사이의 트레이드오프를 해결하고자 하는 논문입니다.

도커와 같은 컨테이너는 빠른 인스턴스화 시간, 낮은 메모리 사용량, 높은 density를 통해 마이크로서비스, 서버리스 컴퓨팅, 네트워크 가상화와 같은 use case들을 가능하게 하며 많은 인기를 얻었습니다.

그러나 컨테이너는 호스트 OS의 커널을 공유함으로써 작동하며 이로 인해 심각한 보안 취약점을 야기합니다. Linux를 예로 들면 약 400개가 넘는 시스템 콜 API가 있으며, 컨테이너는 이 시스템 콜을 기반으로 호스트 OS와 상호작용합니다. 이러한 구조로 인해 VM의 메모리 격리와 CPU ring을 통한 하드웨어적 protection과는 대조적으로 수많은 익스플로잇 및 공동 상주 컨테이너에 대한 DoS 위협에 노출됩니다.

VM은 하드웨어 기반 격리를 제공하지만, “무겁다"는 단점이 있습니다. 일반적으로 VM은 수 초에 달하는 느린 부팅 시간과 수백 MB에서 GB에 달하는 큰 디스크 이미지, 인스턴스당 메모리 사용량이 높은 특징을 가지고 있습니다. 이로 인해 컨테이너와는 반대로 단일 호스트에서의 density가 제한됩니다.

이전의 연구는 주로 고비용의 VM을 최적화하거나 공유하는 커널의 아키텍처를 변경하지 않고 컨테이너를 보호하는 데 초점을 맞췄기 때문에 이 트레이드오프를 해결하는 데 대체로 실패했습니다. 일부 연구에서는 minimal OS (unikernel 등) 를 도입하려 했지만 하이퍼바이저의 control plane 병목 현상을 다루지 못해 컨테이너 만큼의 성능을 달성하지 못했습니다.

Xen으로 대표되는 기존 하이퍼바이저의 설계는 XenStore와 같은 중앙 집중형 구성 요소와 복잡한 툴스택에 의존했으며, VM수에 따라 scalability가 좋지 못해 상당한 오버헤드를 발생시켜 클라우드 컴퓨팅과 같은 동적 워크로드에는 부적합했습니다.

Requirements

이 논문의 목표는 기존 하이퍼바이저 위에서 동작하는 경량의 가상화 기술을 제공하는 것입니다. 이 목표를 달성하기 위해서는 다음과 같은 요구사항이 존재합니다.

• Fast Instantiaion: 컨테이너와 같이 startup 시간이 수백 밀리초 단위로 맞춰지도록 한다.
• High Instance Density: 단일 호스트에서 수백~천 단위의 인스턴스를 생성할 수 있도록 한다.
• Pause/unpause: 컨테이너와 같이 pause와 unpause를 빠르게 수행할 수 있어 idle 인스턴스를 pause함으로써 density를 유지할 수 있도록 한다.

기존 VM이 위 요구사항을 달성하기 어려운 가장 큰 이유 중 하나는 VM의 이미지 크기입니다. VM의 이미지 크기가 커질수록 startup 시간이 길어지며 메모리 사용량도 많아지기 때문에 많은 인스턴스를 생성하기가 어려워집니다.

Challenges

위에서 설명한 문제들을 해결하는 데 있어서 주요한 과제는 크게 두 가지가 있습니다. 첫 번째로, 애플리케이션의 호환성을 침해하지 않으면서 게스트 OS의 이미지 크기 및 런타임 메모리 사용량을 줄여야 합니다. 범용 OS의 경우에는 애플리케이션의 호환성을 위해 여러 의존성을 추가하여 이미지 크기가 부풀려져 있습니다. 둘째, 하이퍼바이저 가상화 툴스택의 아키텍처 설계 (예: 중앙 집중형 상태 관리, 과도한 도메인 간 통신) 로 인해 발생하는 성능 병목 현상을 제거해야합니다.

Xen architecture

Xen 아키텍처는 VM의 제어 권한과 설정 정보를 중앙 관리자인 Dom0에 집중시킨 구조를 가지고 있습니다.

Xen의 하이퍼바이저 자체는 매우 얇은 계층으로, CPU나 메모리와 같은 기본적인 하드웨어 리소스의 할당과 관리만을 담당합니다. 하이퍼바이저 부팅이 완료되면 시스템에서 자동으로 Dom0 (Domain 0) 라고 하는 특별한 가상 머신을 생성합니다. 일반적으로 Dom0는 리눅스 환경으로 구동되며, 다른 일반 게스트 VM (Dom U) 들을 제어하기 위해 툴스택과 XenStore 레지스트리를 호스팅합니다.

• 툴스택은 VM 생성, 마이그레이션, 종료 등의 작업을 수행하는 xl 커맨드라인 도구와 실제 커맨드를 실행하기 위한 libxl, libxc, libxs 라이브러리로 구성되어 있습니다.
• XenStore는 현재 실행 중인 VM의 상태, 이름, 디바이스 정보 등의 관리 데이터를 중앙에서 기록하여 추적하는 데이터베이스 역할을 합니다. 특정 정보가 변경되었을 때 알림을 받을 수 있는 watches 메커니즘을 제공합니다.
• 소프트웨어 스위치를 통해 물리 NIC와 VM 사이에서 패킷을 분배해주며 기타 하드웨어 드라이버들도 Dom0에서 호스팅합니다.

중앙의 Dom0와 사용자의 게스트 VM간에는 Split-Driver 모델이라는 방식을 사용하여 통신을 합니다. 예를 들어 네트워크 통신을 할 때, Dom0에는 가상 네트워크의 백엔드 드라이버가 있고, 게스트 VM에는 프론트엔드 드라이버가 존재하여 두 드라이버가 shared memory를 통해 데이터를 주고받습니다. 데이터가 메모리에 준비되었을 때, 서로에게 이를 알리기 위해서 소프트웨어 인터럽트를 사용합니다.

이러한 기존 Xen 아키텍처에서는 중앙의 XenStore와 툴스택이 VM을 만들고 네트워크를 연결할 때마다 너무 많은 절차와 권한 이동을 요구하기 때문에 컨테이너와 같은 밀리초 단위의 VM 생성이 불가능하다고 지적받고 있습니다.

Solution

Key Idea

VM 격리와 컨테이너의 효율성 사이의 technical gap을 해소하려는 문제에 대한 저자들의 해결책은 LightVM입니다. LightVM은 Xen 하이퍼바이저의 control plane을 재설계하고, 도메인에 최적화된 경량 게스트 OS를 생성하는 전략을 사용합니다.

Approach

1. 경량 가상 머신 이미지: LightVM은 VM이 사용하는 애플리케이션 워크로드에 맞춰진 극도로 작은 VM 이미지를 생성하는 방법인 Tinyx를 제안하였습니다.
   • unikernel: 기존 unikernel은 최소한의 운영체제가 대상 애플리케이션과 직접 연결된 단일 목적의 커널입니다. 이를 통해 불필요한 OS 구성 요소를 제거하여 수백 킬로바이트에서 몇 메가바이트에 불과한 이미지를 만듭니다. 유니커널은 높은 성능을 제공하지만, 애플리케이션과의 의존성을 해결하기 위해 manual한 포팅 노력이 상당히 필요합니다.
   • Tinyx: unikernel의 사용성 문제를 해결하기 위해 개발되었으며, 지정된 애플리케이션을 위한 최소한의 리눅스 기반 이미지를 생성하는 자동 빌드 시스템입니다. Tinyx는 불필요한 패키지와 모듈을 제거하여 리눅스 커널과 파일 시스템을 최적화하며, 애플리케이션 호환성을 유지하면서 완전한 리눅스 환경을 제공하는 수십 메가바이트 크기의 이미지를 생성합니다.
2. 하이퍼바이저 (Xen specific) 재설계: LightVM은 Xen의 아키텍처를 개편하여 기존의 병목 현상을 해결하고자 했습니다.
   • chaos: xl 커맨드라인 툴과 무거운 libxl 라이브러리를 대체하기 위해 개발한 툴체인으로, libchaos라는 간소화된 백엔드 라이브러리를 사용합니다.
   • noxs (no XenStore): Xen의 중앙 집중형 XenStore 레지스트리를 완전히 제거하여 메세지 전달 프로토콜, 소프트웨어 인터럽트, 도메인 switching으로 인해 발생하는 성능 병목을 제거했습니다. noxs는 하이퍼바이저 자체가 관리하는 device memory page를 통해 프론트 및 백엔드 드라이버 간의 shared memory 통신을 사용합니다. 즉 기존 VM간 데이터 통신에서 사용하던 shared memory 메커니즘을 VM의 상태 관리에도 도입하여 VM의 생성 및 수정, 삭제를 효율적으로 할 수 있도록 했습니다.
   • 분할 툴스택: Xen의 xl 툴스택에서는 VM 생성 명령을 실행할 때 설정 파일 파싱, 하이퍼바이저 리소스 예약, 디바이스 생성 등을 매번 순차적으로 실행합니다. 그러나 비슷한 flavor를 지닌 VM들이 있다면 실행 과정의 상당 부분에 중복이 발생합니다. 이를 해결하기 위해 LightVM에서는 툴스택 작업을 prepare와 execute 단계로 분할했습니다. prepare 단계는 VM 생성을 요청하기 전에 백그라운드에서 chaos 데몬이 리소스 예약 및 할당, 가상 디바이스 생성 등을 미리 수행합니다. 또한 이렇게 생성한 빈 가상 머신 틀인 VM Shell을 리소스 풀로 관리합니다. execute 단계는 사용자가 chaos create 명령을 내렸을 때 실행되며 VM Shell 풀에서 가상 머신 틀을 하나 가져오고, 사용자 설정 파일에 맞게 Specialization을 하여 VM을 부팅합니다.
   • xendevd: 사용자가 구성한 VM 가상 장치 설정 스크립트를 경량 바이너리 데몬이 대체합니다. xendevd는 백엔드로부터 udev 이벤트를 수신하여 스크립트 실행이나 fork 없이 pre-defined 설정을 적용합니다.

Evaluation

Evaluation Metrics

경량의 가상화를 평가하기 위한 주요 지표들은 다음과 같습니다.

1. 인스턴스화 시간 (Instantiation Times): 인스턴스를 생성하고 부팅하는데 걸리는 시간. 동시에 실행되는 인스턴스 수에 따라 어떻게 변화하는지도 측정해야 한다.
2. 인스턴스 밀도 (Instance Density): 단일 호스트에서 실행될 수 있는 최대 인스턴스 수.
3. 체크포인팅 및 마이그레이션 시간: 인스턴스의 상태를 저장, 복원 및 마이그레이션하는 속도.
4. 자원 사용량 (Resource Footprint): 인스턴스당 메모리 및 CPU 사용량.

Evaluation Target

• Mini-OS based unikernel
  • noop unikernel: no operation, 즉 아무 작업도 수행하지 않는 unikernel
  • daytime unikernel: 현재 시간을 반환하는 간단한 TCP 서버가 수행되는 unikernel
  • Minipython: 경량의 Micropython 인터프리터를 기반으로 제작되어 파이썬 코드를 받아 연산을 수행할 수 있는 unikernel
• Tinyx image
  • Tinyx noop image: 마찬가지로 아무 애플리케이션이 설치되지 않은 Tinyx 이미지
  • Tinyx with Micropython: Micropython 인터프리터를 실행하는 Tinyx 이미지
• Debian VM
• Docker Container

Instantiation Times & Instance Density

첫 번째 평가에서는 기존의 Xen 아키텍처와 LightVM의 instantiation time을 비교하였습니다. 평가에 사용된 인스턴스 이미지는 daytime unikernel이며, 4 core machine을, 1개의 core를 Dom0에 할당하는 방식으로 평가를 진행했습니다.

Figure 9에서 xl은 기존 Xen을, chaos[XS]는 chaos 커맨드 툴체인만을 적용한 것을, chaos[XS+split]과 chaos[NoXS]는 각각 스플릿 툴스택과 noxs만을 적용한 것을, LightVM은 chaos, 스플릿 툴스택, noxs 모두를 적용한 것을 나타냅니다.

기존 Xen 아키텍처에서는 VM을 생성할 때 첫 번째 생성에서 약 100ms의 시간이 걸렸고, 1000번째 생성에서 거의 1초에 가까운 시간이 걸리며 scalability가 떨어지는 것을 확인할 수 있었습니다. 또한 XenStore의 log rotation에 의해 그래프 상에 spike가 나타나고 있습니다.

xl을 chaos로 대체한 것 만으로 creation time에 상당한 성능 향상을 가져오는 것을 확인할 수 있습니다. 그러나 scalability 측면에서 인스턴스의 수가 늘어날 수록 creation time도 늘어나고 있습니다.

스플릿 툴스택을 적용한 것과, XenStore를 제거한 것에서 scalability가 개선되었으며 이를 모두 적용한 LightVM에서 VM 생성 속도와 scalability가 최적화된 것을 확인할 수 있습니다. 첫 번째 boot time은 4ms 정도이며 1000번째 생성에서는 4.1ms 정도의 생성 속도를 보였습니다. 또한 daytime unikernel 대신 noop unikernel을 생성할 때는 boot time이 2.3ms까지도 줄어들었다고 합니다.

다음으로 LightVM이 컨테이너에 비해 instantiation 시간이 얼마나 걸리는지, scalability는 어떤지를 평가했습니다. 평가에 사용된 인스턴스 이미지는 noop unikernel이며, 64 core machine을, 4개의 core를 Dom0에 할당하여 평가를 진행했습니다.

먼저 Figure 10의 평가는 LightVM과 Docker Container의 비교입니다. Docker Container는 ramp up에서 150ms 정도의 시간이 걸렸으며, 3000번째 boot time은 약 1초에 가까웠습니다. 그래프 상의 spike는 Docker의 메모리 allocation 때문이며 3000번째 이후 allocation에서 시스템 전체의 메모리를 요구하여 실험을 중단하였습니다. 이에 비해 LightVM은 Docker 보다도 빠른 boot time을 보여주었으며, VM의 개수가 늘어나도 stable한 모습을 보였습니다.

Figure 11에서는 Tinyx와 unikernel, Docker Container를 비교하였으며 예상대로 unikernel이 가장 좋은 성능을 나타냈습니다. Tinyx와 Docker는 약 750개의 VM까지는 비슷한 양상을 보였으며, 그 이후부터 Tinyx의 경우 idle VM을 관리하는 데에 백그라운드 task가 요구되기 때문에 (Docker Container 및 unikernel은 idle 전환에 백그라운드 task가 없음) boot time이 상승하는 것을 확인할 수 있습니다.

Checkpointing and Migration

Checkpointing과 Migration 시간을 평가하기 위해서 4 core machine을 사용했으며, 2개의 core를 Dom0에 할당했습니다. 또한 daytime unikernel을 이미지로 사용했습니다.

Checkpointing을 위한 워크플로우는 다음과 같습니다.

• 매 run 마다 10개의 VM을 실행한다.
• 10개의 VM을 랜덤하게 선택하여 checkpointing을 한다.
• 총 1000개의 VM이 실행될 때까지 반복한다.

1000개의 VM에 도달했을 때, LightVM은 save에 30ms, restore에 20ms 정도의 시간이 소요되었지만, 기존의 Xen에서는 save에 128ms, restore에 550ms 정도가 소요되었습니다.

Migration의 경우에도 Checkpointing과 동일한 워크플로우로, 10개의 VM을 실행하고, 10개를 선택하여 migration을 하는 방법으로 평가가 진행되었습니다.

Figure 13에 따르면 LightVM이 약 60ms의 migration 시간을 stable하게 유지하며 가장 좋은 성능을 보였습니다. 초반 단계의 낮은 개수의 VM이 실행되는 환경에서는 chaos[XS]가 LightVM을 뛰어넘는 성능을 보여주는 것을 확인할 수 있는데, 이는 noxs에서 device destruction 워크플로우가 현재 LightVM에서는 최적화되어있지 않기 때문입니다. 따라서 device destruction을 최적화하는 것은 future work로 여전히 남아있습니다.

Memory Footprint

컨테이너 환경의 장점 중 하나는 일반적인 커널을 사용하여 인스턴스의 수를 늘리더라도 memory 사용량이 낮게 유지된다는 점입니다. VM의 경우에는 OS 이미지와 파일시스템의 full replica를 생성해야 하기때문에 컨테이너와 대조적으로 많은 메모리를 사용하게 됩니다.

LightVM의 메모리 사용량을 평가하기 위해서 4 core machine을 사용했으며, 하나의 core를 Dom0에 할당했습니다. 또한 Minipython unikernel, Tinyx with Micropython, Micropython이 설치된 Debian VM 이미지를 평가 대상으로 하였습니다. 대조군으로는 Docker 컨테이너와 Micropython 프로세스를 설정했습니다.

Figure 14를 보면 unikernel의 메모리 사용량이 Docker 컨테이너와 비슷한 결과를 나타내고 있습니다. Tinyx의 경우에는 1000개의 인스턴스를 실행하였을 때 약 27GB의 메모리를 사용하며 Docker 컨테이너에 비해 22GB 정도를 더 사용하였지만, 저자들은 상용 서버는 호스트당 수백 GB 단위의 메모리를 사용하기 때문에 큰 소요는 아니라고 주장합니다.

Debian VM은 1000개의 VM에 대해 114GB의 메모리를 사용하며 VM 1개당 111MB (최소한의 필요한 메모리)를 사용하고 있었습니다.

CPU Usage

마지막 평가는 CPU 사용량에 대한 평가입니다. 평가 대상은 noop unikernel, Tinyx, Debian, Docker 컨테이너이며, VM의 CPU 사용량을 측정하기 위해 iostat과 xentop 도구를 사용했습니다.

Figure 15에 따르면 도커 컨테이너가 가장 낮은 CPU 사용률을 보였고 unikernel은 컨테이너와 큰 차이가 없었으며 Tinyx도 1000개의 guest에도 CPU utilization이 최대 약 1%로 낮은 모습을 보여주었습니다. 그러나 Debian VM의 경우 scalability가 떨어져 1000개의 VM에 25%의 CPU 사용률을 보였습니다.

결과적으로 VM의 이미지 내에서 필요없는 부분을 제거한다면 컨테이너와 비슷한 정도의 오버헤드를 가질 수 있다는 점을 시사합니다.

Use Cases

저자들은 위에서 평가한 LightVM이 실제 어떤 사례에서 사용될 수 있는지를 제안하였습니다.

1. Personal Firewalls

모바일 엣지 컴퓨팅 (MEC) 환경에서 개별 사용자마다 클라우드 기반의 방화벽을 할당하는 시나리오입니다.

모바일 기지국 인근의 제한된 하드웨어 자원에서 수천 명의 사용자를 수용해야 하며, 사용자의 이동에 따라 방화벽 인스턴스를 빠르게 생성, 종료, 마이그레이션을 수행할 수 있어야 합니다. 일반적인 VM은 긴 boot time과 큰 이미지 사이즈로 인해 이 환경 내에서 현실적으로 사용이 어렵습니다. 또한 컨테이너의 경우 전체 클라우드 서비스에 위협이 될 수 있기 때문에 적합하지 않습니다.

따라서 네트워크 처리에 특화된 unikernel인 ClickOS를 LightVM 환경에서 실행하여 방화벽을 제공할 수 있도록 합니다. 결과적으로 1.7MB의 이미지와 8MB의 메모리만으로 하나의 인스턴스를 실행할 수 있었으며 64코어 CPU의 단일 호스트에서 최대 8000개의 방화벽 인스턴스를 실행할 수 있었습니다.

2. Just-In-Time Service Instantiation

마찬가지로 MEC 환경에서 특정 워크로드를 클라우드에 오프로딩하는 시나리오에 적용될 수 있는 사례입니다.

가장 중요한 메트릭은 최대한 많은 디바이스의 요청을 감당할 수 있어야 하는 것입니다. 따라서 idle 자원의 낭비를 방지하기 위해 새로운 클라이언트로부터 패킷이 도착하는 즉시 VM을 부팅하여 서비스를 제공하고, 일정 시간 (이 실험에서는 2초로 설정함) 활동이 없으면 VM을 다운하는 방식의 실험을 진행했습니다. 또한 worst case를 고려하기 위해 클라이언트가 패킷을 보내면 새롭게 부팅된 VM에서 응답이 오도록 실험 환경을 설정했습니다.

결과적으로 매 25ms마다 새로운 클라이언트가 접속을 하는 상황에서도 응답 시간의 중앙값은 13ms 정도로 측정되며 패킷 기반 트리거 방식의 VM 운용이 가능하다는 점을 시사했습니다.

3. High Density TLS Termination

CDN에서 사용자에게 더 가까운 위치에 TLS 연결 지점을 구축하는 사례를 LightVM으로 제공하는 사례입니다.

TLS는 handshake 과정에서 최소 한번 이상의 round trip time (RTT) 이 요구되기 때문에 먼 곳에 위치한 서버의 경우 응답 시간이 늦어질 수 있습니다. 따라서 RTT를 줄이기 위해 사용자 근처에 CDN을 두고 사용하는 방식이 많이 사용되고 있습니다. 그러나 TLS의 비밀 키를 보호하기 위해서는 VM 수준의 격리가 필수적이지만, 기존의 Linux VM은 무겁기 때문에 이 use case에서는 한계가 나타납니다.

저자들은 Tinyx 및 Minipython (unikernel) 을 기반으로 이 워크로드를 테스트했으며 Tinyx 기반의 LightVM TLS 프록시에서 초당 1400개의 요청 처리 성능을 보여주며 베어 메탈 리눅스 프로세스와 거의 유사한 수준을 나타냈습니다. (다만 복잡한 ECDHE 기반의 키 대신 1024-bit RSA 키를 사용했습니다.) unikernel 환경에서는 Tinyx의 성능에 크게 미치지 못했는데, lwip TCP 네트워크 스택의 구현 비효율성때문에 이러한 결과가 나타난 것으로 분석했습니다.

4. Lightweight Computing Service

아마존 클라우드 서비스의 Lambda와 같은 서버리스 컴퓨팅 환경을 LightVM으로 모사할 수도 있다고 제안하고 있습니다.

Micropython 인터프리터 기반의 유니커널을 LightVM 아키텍처에서 실행했을 때 100~200개의 작업이 대기중인 overloaded 환경에서 XenStore 사용 아키텍처에 비해 작업 완료 시간이 약 5배 빨라지는 결과를 보였습니다.

Related Work

• OS 레벨의 가상화 기술은 많은 방법론을 통해 존재하며, 넓은 분야에서 사용되고 있습니다. 예를 들어 Docker, LXC, FreeBSD jails 등이 있으며 density를 높이기 위한 연구가 진행되어 단일 호스트에서 1만개의 컨테이너를 실행하는 결과도 보여주었습니다. LightVM에서는 이러한 경량의 가상화를 하이퍼바이저 위에서 가능하게 하며 동시에 VM의 고수준의 격리를 제공합니다.
• Xen, KVM, VMWare와 같은 하이퍼바이저를 최적화하는 work들도 많이 존재하며, 하이퍼바이저의 boot time 오버헤드를 줄이기 위한 연구가 진행되었습니다. Intel Clear Container (ICC) 에서는 컨테이너를 VM 내에서 실행하는 방식과 하이퍼바이저의 툴스택을 최적화하려는 시도를 하였습니다.
• ukvm은 unikernel 모니터를 KVM 위에서 구현한 것으로 약 10ms의 boot time을 보여주었습니다. Jitsu, Swift Birth and Quick Death는 Xen 및 xl 툴스택을 최적화하고자 한 연구입니다.
• 커널 자체 혹은 하이퍼바이저 자체를 경량화하고자 한 연구로 Exokernel, NOVA와 같은 work들도 존재합니다.
• unikernel에 대해 수많은 연구가 진행되었으며, Mirage, ClickOS, Erlang on Xen, OSv와 같은 연구가 있습니다.

Discussion

• Memory Sharing: LightVM에서는 worst case에서 모든 page가 다를 것을 가정하여 메모리 page sharing을 사용하지 않았습니다. 여러 VM간의 중복되는 메모리 페이지를 통합하는 memory de-duplication과 같은 방법으로 최적화를 할 수 있지만 이는 가상화 system 자체를 수정해야한다는 제약사항이 있습니다.
• Generality: LightVM은 Xen을 기반으로 하고 있지만, 대부분의 컴포넌트는 KVM에도 적용이 가능합니다. Related works 에서 보았듯 기존 ukvm 연구에서 KVM의 툴스택을 경량화하였으며, guest의 pre-creation (split toolstack과 같은) 또한 특정 하이퍼바이저에 한정되지 않고 적용이 가능한 방법론입니다. Unikernel을 Xen 이외의 하이퍼바이저에서 적용하는 것도 일반화가 가능합니다. 마지막으로 Xen specific한 XenStore 역시 KVM 및 QEMU에서도 유사한 방식으로 VM의 상태관리를 하고 있기 때문에 구현 방식의 차이만 존재할 뿐, 비슷한 최적화를 적용할 수 있을 것입니다.
• Usability/Portability: LightVM은 아직 컨테이너만큼의 사용하기 쉽지 않습니다. 컨테이너는 큰 ecosystem을 바탕으로 애플리케이션의 수정 없이 쉽게 실행할 수 있지만, LightVM은 performance와 portability/usability 측면의 트레이드오프가 존재합니다. unikernel은 높은 성능을 가지고 있지만, 이전에 언급했듯 상당한 포팅의 노력이 필요합니다. Tinyx 자동 빌드 시스템은 이 문제를 해결하기 위한 첫 단계이며, 여전히 unikernel에 비해 낮은 수준의 성능을 제공합니다. 이 문제를 해결하기 위해서 OS의 컴포넌트를 fine-grainularity로 분할하고, 애플리케이션의 필요 dependency를 자동으로 분석하여 minimum set의 unikernel을 컴파일하는 future work가 필요합니다.

Conclusion

LightVM은Xen의 toolstack을 최적화하여 VM의 부팅 시간을 2.3ms 까지 줄일 수 있었고, 현재 실행중인 VM 수에 관계없이 stable하게 부팅 시간을 유지하였습니다. 이를 위해서 LightVM은 Xen의 중앙화된 toolstack, 특히 XenStore를 분산화하여 noxs라는 아키텍처를 만들어냈습니다. Use case들에서 보았듯, 이와 같은 경량화된 VM 가상 환경은 real world에서 필요로 하고 있습니다. 그러나 이를 위해 unikernel을 사용하려고 한다면 target 애플리케이션을 위한 manual한 포팅이 요구되며 이 문제를 해결하기 위해 Tinyx 빌드 시스템을 제안했습니다. 결과적으로 컨테이너와 비슷한 수준의 부팅 시간과 density를 제공하면서도 VM의 격리 이점을 가져갈 수 있는 아키텍처를 제안하였습니다.

Critique and Current Landscape

Limitations

1. unikernel portability: 저자들이 자주 언급했지만, 논문이 제시한 성능 지표에서 극적인 개선을 보인 것은 대부분 unikernel 환경에 의존하여 도출되었습니다. 기존의 애플리케이션을 unikernel로 이식하는 작업은 비용이 많이 들며, General OS에서 제공하는 수준의 디버깅 도구 및 관리 생태계를 갖추지 못해 유지보수 측면에서도 어려움이 있습니다. Tinyx라는 절충안을 제시하긴 했지만, 여전히 성능과 portability 및 usability 사이의 딜레마를 완전히 해결하지는 못했습니다.
2. unikernel throughput: unikernel은 TLS 워크로드에서 Tinyx의 성능보다 5배정도 낮은 모습을 보여주었으며, 극단적으로 경량화된 가상환경에서의 미성숙한 네트워크 스택으로 인해 고부하 네트워크 처리를 unikernel에서 수행하는 데에는 한계가 있다는 점을 시사했습니다.
3. scheduling contension: 이는 Xen 아키텍처의 한계이기도 하지만, 높은 density를 가지는 환경에서 round robin으로 스케줄링을 하는 방식으로 인해 CPU contension이 발생하는 모습을 보이고 있습니다. 따라서 짧은 workload를 가진 경량화된 VM에 대해 새로운 스케줄러 연구가 필요해 보입니다.

Current Landscape

1. Current Xen: 논문에서는 Xen의 XenStore가 대규모 VM 생성의 병목 지점이 되기 때문에 noxs를 제안했습니다. 현재 XenStore는 여전히 Xen 아키텍처에 존재합니다. 다만 이 논문은 XenStore의 dependency를 제거하려는 시도들에 영향을 주었고, Xen은 dom0less 기능을 도입하여 시스템 부팅 시 XenStore를 비롯한 Dom0의 개입 없이 VM을 즉시 부팅시키는 기능이 메인라인에 도입되어 사용되고 있습니다.
2. Automated Unikernel Buildsystem: 이 논문의 연구팀은 언급한 unikernel의 portability 문제를 해결하기 위해 Unikraft라는 연구를 발표했습니다. Unikraft는 Linux Foundation 및 Xen Project 산하의 공식 오픈소스 프로젝트로 독립하여 성공을 거두었으며, 현재 경량/고속의 unikernel을 배포하기 위한 표준 프레임워크 중 하나로 자리잡았습니다.
3. Current Virtualization Techniques: AWS Firecracker는 러스트로 작성된 경량의 VMM이며, Tinyx와 유사하게 불필요한 드라이버 및 서브시스템을 제거하여 커스텀 빌드된 이미지를 사용해 125ms 이내의 부팅 속도를 제공하는 AWS의 기술입니다. Kata Container는 논문에서 언급한 컨테이너 생태계의 도구를 적극 활용하기위해 쿠버네티스 환경에 통합되어 일반적인 컨테이너를 배포하듯 명령을 내리지만 실제로는 내부적으로 경량의 VM이 실행되도록 하는 방식으로 동작합니다. 또한 대안적인 접근으로 구글은 호스트 커널을 공유하지 않고 userspace에서 systemcall을 샌드박싱하는 방식으로 가상화를 하는 gVisor를 새로운 기법으로 제안했습니다.