見出し画像

コンテナ型仮想化とサーバ仮想化?の比較

本稿の目的

昨今流行りも落ち着きつつあり、アプリケーションの開発においては徐々に一般的になりつつあるDocker、Kubernetesを中心としたコンテナを用いた仮想化ですが、ここで改めて整理してみたいと思います。

注意

著者自身も調べながら書いている部分でもあるので内容の正しさを保証するものではありません。

サーバ仮想化とコンテナ型仮想化の比較

一般的には、仮想マシンを使った仮想化と比較されることが多いですが、実際には根本的に異なるものではありますが、今回は知識の整理を兼ねて改めて違いを整理しておきましょう。

画像1

図1 コンテナ型仮想化とサーバ仮想化の比較

最近はKata ContainergVisorのようにマイクロVMとも分類されるコンテナ型仮想化のテクノロジーも出てきつつありますが、ここでは現時点(2020年2月)一般的なコンテナ型仮想化を例に解説します(図1)。

図1からわかるとおり、コンテナ型仮想化とサーバ仮想化の大きな違いはどこでリソースの分離が行われるかという点です。サーバ仮想化は仮想的なマシンを払い出すことでその中でOSを動作させています。一方コンテナ型仮想化では、同一OS上に隔離空間を作りその中にアプリケーションの動作に必要なライブラリなどを同梱することで隔離された空間を作成しています。

リソース分離が行われるポイントが異なることで、それぞれの特徴に違いが現れてきます。サーバ仮想化と比較した際のコンテナ型仮想化のメリットとは以下のようなものがあるでしょう。
1. オーバーヘッドの削減
2. 高速な起動

では、以降ではそれぞれのメリットについて解説します。

コンテナ型のメリットとしてのオーバーヘッドの削減

画像2

図1 コンテナ型仮想化とサーバ仮想化の比較(再掲)

コンテナ型仮想化とサーバ仮想化を比較した際に大きく異なるのが、コンテナはOSを共有している一方で、サーバ仮想化ではOSも隔離された部分に含んでいることです。したがって仮想マシンはOSも含めてすべてを内部に抱えこむ必要があり、CPUおよびメモリに対する要求はどうしても大きくなってきます。一方でコンテナでは、アプリケーションバイナリと、それが動作するのに必要最小限のライブラリさえあれば、そのほかのOS機能はコンテナのホスト側が管理してくれます。

このようにコンテナ型仮想化では隔離空間のなかにOSまでは持ち込まないようにすることで、リソース的なオーバーヘッドをサーバ仮想化と比較して小さく保つことができるようになっています。

コンテナのメリットとしての高速な起動

先程はリソース的なオーバーヘッドの観点でコンテナ型仮想化とサーバ仮想化について比較しました。それでは、コンテナ型仮想化のメリットとしての高速な起動とはどういうことなのでしょう。

仮想マシンは内部にOSまで抱えこんでおり、目的のアプリケーションバイナリを動作させるまでには、仮想マシンとしての仮想ハードウェアを立ち上げ、OSを起動し、目的のアプリケーションのバイナリを起動するといった流れになります。実際のOS(Linux)起動の流れについては、Linuxがブートするまでを参考とすると良いでしょう。このようにサーバ仮想化では目的とするプロセスが起動するまでには多くのステップを経る必要があります。

一方で、コンテナ型仮想化でははじめからOSは立ち上がっている状態であり、実質的にはプロセスを立ち上げるだけとなります。(実際にはコンテナそのものを切り出すプロセスもありますがサーバ仮想化と比較した際には誤差レベルの内容です)

画像3

図2 アプリケーション起動にいたるまでの作業ステップと所要時間のイメージ

イメージとしてアプリケーションプロセスの起動にいたるまでの所要時間イメージを表すと図2のようになります。

コンテナ型仮想化のデメリット

コンテナ型仮想化のメリットについて先程まで述べましたが、デメリットについてももちろん存在します。デメリットは基本的には複数の隔離空間(コンテナ)でOSを共有していることに起因します。
1. 他のカーネルを使えない
2. 隔離機能が弱い(サーバ仮想化と比較して)
他のカーネルが使えないというのは、文字通りです。Linuxカーネル上でコンテナを利用している場合は、Windowsのコンテナを動かすことはできません。(Docker for macやDocker for windowsではそのためのLinux仮想マシンを準備し、その上でLinuxコンテナを動かすことでLinuxコンテナの動作を実現しています)

隔離機能が弱いこともOSを共有していることに起因します。隔離されているアプリケーション側から見ると他のコンテナは見えませんが、コンテナのホスト側からはすべてのコンテナが見えます。また、最終的にはカーネルのシステムコールなどは同一のカーネルに流れるため、セキュリティの観点でも仮想マシンには劣ります。

さらに、一般的なサーバ仮想化では、コンテナ型仮想化と比較すると基本的にはノイジーネイバーには強いと言われています(ノイジーネイバーについての参考: 仮想環境における「うるさい隣人」問題 )。コンテナ型仮想化においてもcgroupsなどを活用することでノイジーネイバー対策はある程度は行うことができますが、サーバ仮想化と比較すると少し複雑かもしれません。

このような課題を回避するための手段としてKata ContainergVisorのようにマイクロVMとも分類されるコンテナ型仮想化のテクノロジーが出てきたと解釈することができます。特にコンテナ型仮想化でマルチテナントをセキュアに実現しようとなるとマイクロVMが重要になってくるでしょう。

まとめ

今回はコンテナ型仮想化とサーバ仮想化について比較してみました。コンテナ型仮想化をサーバ仮想化と比較した際のメリット・デメリットとしては以下のように述べることができるでしょう。

・メリット
 - オーバーヘッドが小さい
 - 高速に起動できる
・デメリット
 - 他のOSが使えない
 - 隔離機能が弱い
  (マルチテナント時のセキュリティ観点・リソース分離観点)

実際の利用の際にはベアメタルのサーバの上にコンテナを起動するよりは仮想マシンの上でさらにコンテナを立ち上げることで、高速な起動のメリットや、アプリケーションの動作環境をコード定義できるメリット(別記事にて開設予定?)を享受することを狙うことが多いでしょう。

あくまでも本記事ではよく言われる内容を記述したのみで、他にも様々な側面からの比較が可能なのでその点はご注意の程をば。

参考文献

cgroups - Wikipedia
「Kubernetes」とは何か――コンテナ型仮想化の本番利用に向けた課題
LXCで学ぶコンテナ入門 -軽量仮想化環境を実現する技術 第2回 コンテナの仕組みとLinuxカーネルのコンテナ機能[1]名前空間とは?
Linuxがブートするまで
仮想環境における「うるさい隣人」問題
Kata Container
gVisor

この記事が気に入ったらサポートをしてみませんか?