Docker社が買収したUnikernel Systems社が扱ってるUnikernelについて全然知らなかったので、Docker Online MeetupのUnikernelの動画を見たついでに、分からないところを調べられた範囲で補完しつつまとめてみました。なお、超基本的な内容です。

動画だけでなくスライド自体も上がってます。

先に自分が理解した範囲でまとめを書くと、以下のような流れみたいです。

• Unikernelは単一のアプリを動かすためのシンプルかつ高速なOSで色々な実装がある。
• でも従来のOSと違うし、各実装ごとにツールもあるしで、アプリをビルドして動かすのが大変。
• dockerのエコシステムに取り込んでdockerコマンドでビルド・デプロイできるようになったらいいんじゃないってことで買収した。

従来のOSの問題

現在使われているLinux等のOSは膨大なコードを持ち、アプリケーションに必要でない部分もシステムに組み込む必要がある。 そのためアプリケーションがSystemAPIと結びついてしまい、以下のような問題がある。

• OSのディストリビューションやバージョンの制約を受ける
• アプリケーションのアドホックな設定が必要になる
• ファイアウォール等、システム全体の設定が必要になる

これは従来のOSの目的が、複数のユーザが複数のアプリを同時に動かすことだからだ。 しかしマイクロサービス等、現在のアーキテクチャでは一つのアプリのみを動かすだけという使い方も考えられるため、従来のOSの目的と合わなくなってきている。

また、ポータブル性の欠如という問題もある。 従来のシステムでビルドは環境に依存するが、実際は複数のターゲットを扱わないといけない。 例えば複数のターゲットを持つクラウドサービスやスマートフォンといったもの。またJavaScriptもブラウザにより異なるし、IoTでもデバイス毎に異なる。 これらは複数のターゲットごとにプログラムせねばならず、コードの再利用は難しい。

Unikernelとは何か

これらの問題を解決するためにUnikernelが役に立つ。 Unikernelには以下のような特徴がある。

• OSのコンポーネントをライブラリの集合として利用できるようにしている。
• ビルド時にアプリケーションのコードをシステムライブラリとリンクし、アプリケーションが必要とするライブラリだけを使うことが可能。
• 単一のプロセス、単一のアドレススペースのイメージが作成される。
• アプリケーションは同じコードベースを使い、ビルド時にシステムライブラリを切り替えるだけでターゲットの変更が可能。

なお、Unikernelのコンセプトは新しいものではなく、1990年代から存在していた。

利点

前述の特徴から以下のような利点がある。

• 必要なライブラリのみをスタティックにリンクできるため、シンプルにできる。
• TCP接続が確立される間にブートできるくらい高速。
• レイヤーが少ないので低レイテンシおよび、パフォーマンスの予測が容易。
• リソースをあまり使わない。例えばUnikernelの実装の一つであるMirageOSのアプリは10MB以下のメモリしか使わない。MirageOSのDNSサーバは200KBしかない。
• マイクロサービスやImmutable Infrastructure等の新しいデザインパターンの構築が容易になる。

Unikernelを使う場合の開発サイクル

以下のような流れで開発していくことができ従来の方法と大きくは変わらない。

• アプリのビルドは普通に行うが、OSのコンポーネントに対応するライブラリを使ってリンクすることと、従来のホストOSとの依存性を排除するという点が従来と異なる。
• テストや測定は通常通りに行うことが可能。
• Unikernelとしてビルドする
• デプロイする

利用するツールもCIシステム、gdb、プロファイラ、linterやdtraceといった従来のものが利用可能。 カーネル空間・ユーザ空間というものがなく全てがユーザ空間で動くので、通常のツールが利用できる。

Unikernelの実装

Unikernelには多くの実装がある。 それぞれトレードオフがある。 例えばMirageOSとHaLVMはまっさらな状態からライブラリを書き直している。 一方Rumprunは長年使われてきたNetBSDのコンポーネントを再利用している。

(ちなみにMirageOSはOCaml、HaLVMはHaskell、RumprunはCでそれぞれ書かれている)

このように現在のアーキテクチャに適したUnikernelだが、導入時の障壁として以下のようなものが考えられる。

• デベロッパーはUnikernelを使うために様々なツールを学ぶ必要がある。
• 複数のプロジェクトがあるということは複数のツールチェーンがあるということ
• デプロイが単純には行かないということでもある

これらを解決するために、DockerはUnikernelと手を取った。

• Unikernelはより良いツールが必要でDockerには様々なツールとエコシステムがある。
• UnikernelをDockerのエコシステムに組み込むことでこれらを利用可能にする。

デモ

デモはこのレポジトリのもので、Nginx・PHP・MySQLをUnikernelのアプリとしてdocker buildで立ち上げるというもの。 以下は話してた内容や画面上を見た範囲でのメモ。実際に動かしたらQiitaにでも投稿します(追記:動かして投稿しました)。

• Unikernelはdockerのツールチェーンを使って普通のLinuxコンテナと同じように動かすことができる。
• それぞれのUnikernelがKVMの仮想マシンとして動く。
• 各OSイメージは2-6MB程度で必要な機能のみが入った状態になっている。
  • 実際、nginxのイメージが2.1MBくらいになってた。
• 1秒以下で起動する。
  • 実際それくらいだった。
• nginxのみ外から繋がり、他はVM間でしかつながらないようになっている。

以上。

Unikernelの考えは確かに現在のアーキテクチャに適しているように思いました。 利点がとても大きいように思えるので、dockerツールに組み込まれて透過的に扱えるようになれば大流行するんじゃないでしょうか。 なお、Unikernel関連の議論はこちらで行われているようです。