論文紹介：My VM is Lighter (and Safer) than your Container

元論文: https://dl.acm.org/citation.cfm?id=3132763

VM（仮想マシン）をたくさん立ち上げたいとき、VMM（仮想マシンモニタ、ハイパーバイザ）のどういうところがボトルネックになるかを分析した上で、VMMを改善し、Unikernelを用いてコンテナシステムより軽量で（かつセキュアな）システムを構築しました、というような話です。

論文概要

  • タイトル：My VM is Lighter (and Safer) than your Container
  • 著者：Filipe Manco, Costin Lupu, Florian Schmidt　et. al.
  • 会議：Proceedings of the 26th Symposium on Operating Systems Principles (SOSP ‘17)

システム系のトップカンファレンスとしておなじみのSOSPで発表された論文です。
著者はNEC Laboratories Europeとブカレスト工科大学（ルーマニアの大学）の所属の方々です。

背景

DockerやLXCのような軽量な仮想化はひとつのトレンドになっている。例えばGoogleでは自社のサービスを全てコンテナ化して動かしており、Container as a Service（CaaS）としてAmazonやMicrosoftのAzureもコンテナプラットフォームを提供している。
コンテナ型仮想化はXenやKVMのようなハードウェアレベルの仮想化に比べると起動が早く、インスタンスごとのメモリ使用量も少なくてすみ、１つのホストによりたくさんのインスタンスを立ち上げられる。
しかし、コンテナ型仮想化ではインスタンスはホストOSから400以上ものsyscallのAPIを与えられ、それらをセキュアに保つのは難しい。これらのAPIを利用することでインスタンスがリソースを大量に消費するようなDoS攻撃を他のインスタンスに対してしかけることも考えられる。
そのため、複数のユーザーが存在するような状況ではコンテナ型仮想化を使うことはセキュリティ上の懸念から難しい。

研究の要求仕様

彼らは既存のハードウェアレベル仮想化のVMMのボトルネックを分析した上で、LightVMという軽量なType-1のハイパーバイザ（XenのようにOSを介在することなくハードウェア上で直接動くVMM）を開発した。
ゴールとしてコンテナのような軽量性を目指していて、具体的な仕様としては

  • インスタンスの高速な起動
  • 大量のインスタンスが建てられること（メモリ使用量とインスタンスイメージのサイズが小さい）
  • インスタンスの一時停止と再開が高速にできる

ということを掲げている。

軽量なVM

まず第一にVMそのものが軽量である必要がある。多くの場合、VM（ないしコンテナ）は1つのアプリケーションのみを動かすことが多い。
そこに注目することで、VMに含まれる機能を削れば軽量なVMをつくることができる。
有名な既存研究としてはUnikernelが存在する（参考：Unikernels: Library Operating Systems for the Cloud）。
これはOSをライブラリ化してしまい、対象アプリケーションに直接リンクさせることにより、非常に小さいVMをつくるというものである。
OSの機能をシングルアプリケーションを動かすことに特化させられ必要な機能のみをリンクするので強力なアプローチである一方、
Unikernelが提供するAPIはLinuxなどの既存のAPIとは互換性がないため、多くの場合、既存のアプリケーションをそのまま動かすのは非常に難しい。

もう一つの軽量なVMをつくる方法として、Tinyxが存在する。
これは特定のアプリケーションを動かすことに特化したLinuxディストリビューションを自動的にビルドするというツールだ。
この研究ではこの２種類のVMと通常のLinuxのVMを使い各種実験を行っている。

既存のVMMのボトルネック

この研究では著名なType-1ハイパーバイザであるXenを分析して、大量のインスタンスを立ち上げた時のボトルネックを調べている。
まず、1000のVMを立ち上げる、という実験をしている。全てのVMは起動後アイドル状態になるようにしてインスタンスが増えてもリソースを消費しないようにしたにもかかわらず、起動時間がインスタンスが増えるに従い激減していることがまずわかった（VMはDebian、Tinyx、Unikernelそれぞれで試している）。
原因はXenStoreというVMの情報を管理するツールに自身の情報を登録するフェーズにあることがわかった。

そこで彼らのLightVMではXenStoreを使わずnoxsという新たなVM・VMM間のコミュニケーションを共有メモリを介して行うアーキテクチャを設計した。
また、xl/libxlの代わりとしてchaos/libchaosというツールスタックも実装した。
XenではVM起動時にVM側のデバイス側のインターフェースを初期化するにはまず、dom0がデバイスのバックエンドからイベントチャンネルなどの必要な情報を取り出し、それをXenStoreに格納する。
その後、VM側はXenStoreに問い合わせることによってそれらの情報を取り出す。このXenStoreとのインタラクションは頻繁に発生し起動が遅くなる原因となる。
LightVMではdom0がバックエンドから取り出した必要な情報をハイパーバイザ内のページに格納する。その後、VM側でハイパーコールを使うことでそれらの情報を取り出しVM側で情報を持つようにする。
その後、デバイスのバックエンドとのやり取りはイベントチャンネル介し直接やり取りできるようになる。

また、彼らは同じようなVM作成時に実行されるコマンドのうち多くは、VM作成前に実行できるということに注目した（例えば同じメモリ容量を割り当てるVMであれば事前にメモリをアロケートしておく）。
そこで、libchaosでは作成時のフェーズをprepareとexecuteという2つのフェーズに分け、prepareはVM作成コマンドが発行される前に予め行っておき、VM作成のための土台をプールしておく。
VM作成コマンドが実行されると、そのプールから土台を持ってきて、そのVMのためにコンフィギュレーションをチェックした上で実際にVMを起動させる。

評価

Dockerとブートタイム、マイグレーション、メモリ使用量などを比較している。詳細は割愛するが、Docker並のパフォーマンスが実現できている。

まとめ

Xenのボトルネックを詳細に分析した上で、LightVMという新しいアーキテクチャのVMMを設計し、Dockerにもひけを取らない軽量な仮想化フレームワークを構築した。
ユースケースとしては、モバイルエッジコンピューティング（クラウド上ではなくモバイル端末にプロセスを直接走らせる）やAmazon Lambdaのような短時間の計算リソース提供サービスなどが考えられる。
この研究ではXenをターゲットとしたが、KVMなど他のVMMでもこの手法は使えるだろうと論文では主張している。
また、用いるVMとしてUnikernelはアプリケーション移植のエンジニアリングコストが高く、Tinyxは通常のLinuxのVMよりはパフォーマンスがいいが、Unikernelほどではなない。
そのような面からDocker並の使いやすさはまだ備えていない。