東京農工大 金津 穂,山田 浩史
VM を用いたコンテナ
アプリプロセスを強力に分離
現状の IaaS では図左のような運用
Unikernel の場合図右のようにシンプルな構成を実現
単一のメモリ空間
システムコールが関数呼び出しに置き換えられる
→ オーバーヘッド削減が期待できる
→ 実装が簡潔になる
アプリの用途に特化させたカーネルの実現が容易
コンテナ仮想化にはない利点
例:DlibOS [Mallon et al., ASPLOS ’18]
従来 DPDK などを使用してカーネルをバイパス
Unikernel を利用してメモリ保護と両立しつつ容易に実現
マルチプロセスアプリケーションが稼動しない
fork(2)
,exec(2)
をサポートしない
→ 既存のマルチアプリケーションが起動しない
ソースコードの改変が必要
マルチプロセスの恩恵が受けられない
PosgreSQL … コネクションごとにプロセスを生成し互いを isolation
NginX … 複数プロセスでイベントループを回し高性能化を図る
単一メモリ空間ではスケーラビリティ確保が困難なことが知られている
マルチプロセスをサポートする Unikernel
IaaS 上でより unikernel の利点を継承する
既存のマルチプロセスアプリを稼動可能
マルチプロセスの恩恵を享受可能
マルチプロセスに対応
アプリケーションに応じて容易にカーネルの特化が可能
アプリに応じた設計を行うことで計算資源を効率活用
既存のプログラムを改変せず利用可能
互換性が向上し容易に活用可能に
他ノードへアプリ透過的に子プロセスが配置可能
データセンター規模での資源の活用
手法 | 特定用途へのカーネルの特化 | 既存プログラムへの互換性 | マルチプロセス対応 | マルチノード |
---|---|---|---|---|
MirageOS [Madhavapeddy et al., ASPLOS ’13] | ||||
partial†1 | N/A | |||
RumpRun [Kantee and Cormack, 2014] | ||||
Graphene [Tsai et al., EuroSys ’14] | ||||
KylinX [Mallon et al., ASPLOS ’18] | ||||
Unikernel fork |
起動時に VM 構成をカーネルへ保存
hypercall を用いて unikernel の fork を実現する
hypercall の処理は以下の流れ
ハンドラでプロセスの複製を実行
kvm
の機能を利用し VMCS の設定
VM 構成を復元
QEMU/kvm
と OSv へ実装予定
Unikernel プロセス間通信対応
仮想ディスクの取扱い
ネットワークデバイス
起動時に VM 構成をカーネルへ保存
実現方法は未定
同一ホストの場合共有メモリを利用するなどが考えられる
ハイパーバイザで VM の ID を管理し PID として使えるようにする
同一ホストで複製された場合仮想ディスクへの書き込みを調停する必要がある
現状では同時に書き込みが発生した場合競合状態が発生する
案として,子プロセスでの書き込みを一度親プロセスを経由するようにするなど
MAC アドレスの重複を避ける必要
通信中の場合通信をどのように継続するか検討が必要
IP アドレスは親と子が同じアドレスが見える必要がある
以下のような流れが考えられる
ハイパーバイザーが子プロセスの VM 通信を受ける
プロキシ
マルチプロセスをサポートする新たな機構 Unikernel fork を提案した
またそのセマンティクスと実装のコンセプトについて紹介した
今後はその実現を進めていく