論文紹介ー"Jitsu: Just-In-Time Summoning of Unikernels"

システム系論文紹介 Advent Calendar 2015の12日目の記事です。

論文概要

Jitsuという、Unikernelを使う組込みプロセッサでWebサービスを提供するためのツールをつくりましたというお話。
著者はMirageOSを開発でお馴染みの方々が並んでいますね。
会議は今年のNSDIで、USENIX系の会議なので論文も著者のスライドも無料で手に入るので、
こんなブログを読まずともそちらを読んでしまえば全て完了するのではという気がしますが…

予備知識

最近ちょくちょく話題になりこの論文のキーともなるUnikernelについて簡単に説明しておこうと思います。

Unikernelとは、動かすプロセスを1つに限定することで様々なOSの抽象化を簡略化してライブラリのようにすることで、
アプリケーション単体でプロセッサで動くイメージとしたもの、といったとこでしょうか。
代表的なのはMirageOSとかOSvとかですね。
Unikernelの詳しい説明については、
Unikernels: Library Operating Systems for the Cloud
がよいでしょう。
英語版Wikipediaにも記事があります。
Unikernel - Wikipedia, the free encyclopedia
もう少し体系的でざっくりとした話だと、このスライドとかわかりやすいかもしれません。
An Introduction to Drawbridge(ja) // Speaker Deck

今回使うUnikernelはMirageOSなのですが、これはOCamlで書かれており、
OCamlにはARM用のコンパイラがあること、MirageOSが動作する環境であるXenがARM向けに対応していることなどが幸いしてか、
一部のARMボード上（CubieBoard2など）で動作するようです。
私も試してみようとCubieBoard2を購入したのですが、コンパイルでこけてしまいましたが。

論文の中身

研究背景

クラウド環境からサービスを提供することが流行っているが、クラウド環境への通信のオーバーヘッドが厄介。
また、IoTのデバイスはセキュリティの脆弱性が問題になる。
そこで、組込みハードウェア上でXenなどのハイパーバイザを動かしサービスを提供できれば、
ユーザーに近い位置でのサービス提供が可能となるため通信のレイテンシが緩和される。
また、ハイパーバイザを使うことで各サービスを独立で動かせる。

実現したこと

組込みデバイスで動くネットワークアプリケーションをセキュアに管理するためのツールを、Xenのツールスタックとして実装した。
VMとしてUnikernelを使うことでより低いlatencyでネットワークリクエストに応答する。

実装

XenのツールスタックをXenStoreを拡張し実装。
目標としては、サービスがネットワークに対してきちんと応答するようにするが、必要のないときはリソースがもったいないのでサービスを停止させましょうというもの。
そのために

  • Unikernelのブート時間の最適化
  • VM間コミュニケーションプロトコル”Conduits”の実装
  • 外部クライアントからのアクセスに対して、起動時間のレイテンシを隠蔽するためのディレクトリサービス”Synjitsu”の実装
    を行っている。
    Xen上でVMの設定値を管理・保存するためのツールスタック
    XenStoreを拡張することによって行なわれる。

ブート時間最適化

起動時の仮想デバイスの割りあてを並列処理したことと、
OCamlによるXenStoreトランザクションを利用することで高速化。
また、Unikernelを用いるたので、そもそものバイナリサイズが小さいためそれも高速化に寄与している。

Conduits

vchanという共有メモリを用いたデータパスを利用し、OCamlでvchanのプロトコルを実装。
ランデブーのためのインターフェースがvchanにはないので、XenStoreの名前空間を拡張してランデブーインターフェースを提供。

Directory Service

DNSのリクエストをどのUnikernelに割り当てるかをマップしているもの。
DNSのリクエストによりUnikernelが起動し、その後外部クライアントからTCPのリクエストが送られてくるのだが、
起動が完了していないとリクエストに応答できない。
そこで、起動前の場合、ひとまずリクエストをXenStoreに保存しておき、Unikernelとの間に割り込んでいるSynJitsuがTCPのACKを返しておく。
その後、Unikernelが起動すると溜まったリクエストへの応答を開始し、Synjitsuを介さずにクライアントとUnikernelが直接やり取りを開始する。
このようなことをしないと起動前のTCPパケットがタイムアウトして再送までの時間がかかってしまうため、
サービスのレスポンスが下がってしまう。
わかりやすい図が論文にあるので、そちらを参照されたい。

評価

いろいろなパフォーマンスを計測するための実験を行っているが、
そもそもARMボード上でこのようなことをやるというのがなく、
比較ができていないといった印象を受けた。
セキュリティに関しては、CVEのリストにある脆弱性のうち、どれがJitsuでは影響があるか調べている。
Unikernelを用いているため、
基本的にはLinuxのデバイスドライバ部分やカーネルそのものバグとXenに関するものしか受けず、
SSH overflowのようなアプリケーションよりのものは影響を受けない。

関連研究・議論

コンテナ型仮想化であるDockerやDrawbridgeなどが紹介されている。
UnikernelがよりOSの各種抽象化を省略しアプリケーション特化の構成になっている。

この研究はXenのABIを変えたりなどはしていないため、他のツールと併用することも可能。
ConduitsもMirageOSに特化したものではないため、プロトコルを実装すれば他のunikernelでも利用可能。

まとめ・私見・愚痴

Unikernelを使うことでARMボード上でWebサービスを素早く提供できるJitsuというXenのツールスタックを実装した、というものでした。
全体的に雑な説明になってしまいましたが、まあ、細かい話は論文を直接読んだほうがいろいろ手っ取り早くわかるでしょう。

最近ではDockerでUnikernelを動かすとかよくわからない話も上がってきたりして、
段々と注目度が上がっているようなので、このようなUnikernelを活用したシステムがこれからもいろいろと出てくるのでしょうか。

12日目といってもまだ2人目ですね。
システム系やっている人ってやっぱり少ないなあと思うし、
成果を出すのに時間がかかることが多かったりするせいか評価されることも少ないし、
いろいろとつらいなあと思う今日このごろ。