仮想マシンとコンテナを比較した記事をネット上で散見します。特に、英語サイトでは”Container vs. Virtual Machine”というトピックがネット上に溢れています。そんな記事をざっと見渡していると、コンテナと仮想マシンの比較は、やがて両者を対比するのではなく組み合わせよう、という議論に発展し始めた様子も伺えます。要するに、コンテナと仮想マシンは対立する存在ではなく、どちらか一方を選ばなければならないわけでもない。コンテナと仮想マシンは共存できるという論点です。
具体的には、仮想マシン（VM）は物理的なハードウェア上で、ハイパーバイザーを通じて仮想化された複数のオペレーティングシステム（OS）のことであり、コンテナはOS上でコンテナに区画された個々のアプリケーションです。つまり、VMを用いたからといって、そのOSをコンテナに区分けできなくなるわけではありません。一台の物理的なハードウェア上で複数のVMが仮想化され、その個々のVMが複数のコンテナを持つことだって、理論上は何の問題もないはずです。
言い換えると、コンテナとVMは、アーキテクチャにおいて仮想化が適用されるレベルが異なるので、両方のレベルに同時に仮想化を適用しても問題ない、ということになります（下図参照）。
「コンテナとVMの併用が可能か否か？」という議論よりも重要なのは、「併用が得策かどうか？」です。併用が可能だからといって、必ず併用するのが得策とは限りません。すべてはニーズとリスクのバランス次第です。
ニーズの観点から一般論を言えば、コンテナのニーズは非常に高まっています。DevOpsやマイクロサービス、CI/CD（継続的インテグレーション／継続的デリバリー）の実践には、コンテナ環境がふさわしいというコンセンサスがほぼ確立されています。コンテナのニーズが定着しつつある状況においては、「コンテナとVMとの併用が得策かどうか？」ということよりも、本当の議題は、コンテナを物理サーバー（ベアメタル）のOSに直接適用するか、VMに適用する？かという二者択一です。
この二者択一への答えを見出すには、そもそもVMを採用する上での利点と欠点は何だったのかを再考し、それがコンテナによって補われるのかどうかを検証するのが近道です。VMにもたらされた利点がコンテナでもすべて達成できるのであれば、コンテナ採用時にVMを維持し続ける必要はありません。また、コンテナの欠点も検証すべきです。それがVMの使用で補われるであれば、コンテナ採用時にVMを維持する意味があります。ここで大切なのは、VMとコンテナを比べて両者の優越を競わせるのではなく、個々の活用意義を純粋に分析することです。両者の比較記事はネット上に散乱していますが、コンテナ単独とコンテナVM併用を比較するのに直接役立つとは言えません。
そもそもVMの利点と欠点は？
VMを活用する利点は枚挙に暇がありませんが、それらは大きく分ければ、次の4つに分類できます。
- 節約（サーバーを減らすことによるスペースの節約、費用の節約、中央管理による人件費の節約など）
- 効率化（リソース使用の効率化）
- 柔軟性（アップグレードやスケーリングが容易に。拡張性の向上）
- 災害復旧（レプリケーション、VMスナップショットによるRTO/RPOの短縮など）
上記の1、2、3はコンテナによっても達成可能と言えます。まったく同じことが達成できるわけではありませんが、異なるレベルで、異なる角度から、同様の課題を克服できるので、VMをコンテナに置き換える理由になり得ます。
災害復旧（DR）もコンテナで同様に達成できるかと言えば、多少疑問が残ります。コンテナに合わせたソリューションの開発も進んでいるようですが、VMにはすでに多くの企業に採用され、実用化されてきた実績があります。VMを利用したDRソリューションに比べれば、コンテナはまだまだ発展途上です。コンテナ自体はステートレスで、コンテナ イメージの再生が容易なので、コンテナそのものがDR込みで設計されているとも言えます。しかし、サーバーレベルのDRはコンテナとは別問題です。ベアメタルよりも仮想環境のほうがDRに適していることを思えば、VMとコンテナを置き替えるよりも、VMにコンテナを追加したほうがセキュリティが強固なのは言うまでもありません。
VMの欠点は概ね次の3つに絞られます。
- オーバーヘッド（パフォーマンス、複数のゲストOSを稼働することによる負荷）
- 費用（運営コストは節約されるが、初期投資はかさむ）
- 複雑さ（コンフィギュレーション、設定や構成の複雑さ）
これらの欠点はすべてVMをコンテナに置き換えれば解消されますが、2と3に関しては、コンテナにはコンテナの問題があります。問題がサーバーレベルからOSレベルに特化されるので、処理の単純化は期待できるでしょう。特に3の「複雑さ」に関して言えば、Kubernetesなどのコンテナ オーケストレーション ツールがかなりの部分を自動化してくれ、対応が急速に進んでいる分野でもあります。
むしろ深刻なのは1のオーバーヘッドです。オーバーヘッドの削減は、そもそもコンテナ導入の目的でもあるわけで、そのコンテナをVM内に置いたら、せっかくのコンテナ効果が薄れてしまいます。オーバーヘッドの解消が最優先の課題である場合は、コンテナはVMとは併用せずに、ベアメタルで使用すべきでしょう。
しかし、VMをコンテナに置き換える企業は、当然ながら、すでにVMを実用化している企業です。VMのオーバーヘッドがすでに織り込み済みで、VMがもたらす効果のほうが大きいから実用化したはずです。新規にVMかコンテナかを二者択一するなら、オーバーヘッドは問題ですが、既存するVMにコンテナを追加する場合は、問題にならないはずです。問題にならないどころか、実用化されたVM環境をコンテナ中心に設計し直すことに比べたら、はるかに合理的な選択とも言えます。
コンテナがもたらす効果
では、コンテナ自体の利点と欠点はどうでしょうか？
コンテナがもたらす数々の利点はネットでもさんざん論じられていて、どれも理にかなっており、それらに疑問を投じることが本稿の目的ではないので、ここでは概略に留めます。
- アプリケーションの可搬性、柔軟性、拡張性、リソースの節約、プロビジョニングの簡略化、開発プロセスの単純化（環境からの隔離性によるテスト／プロダクション環境への可搬性）など。
コンテナの欠点はどうでしょうか。
- セキュリティ、単一のOSに縛られること、個々の独立性がゆるい（カーネルを共有）、別種のOSを使うには別のサーバーが必要、など。
これらの欠点は、VMと併用することで解消可能です。セキュリティの課題はDRに関連し、VM向けに各種ソリューションが確立されていることは前述のとおりです。別種のOS云々は、まさにそれを解決するためにVMが存在します。コンテナをVMと併用することで、コンテナの実用性が高まると言って間違いなさそうです。
コンテナ単独かコンテナVM併用か？
VMの代替ソリューションとしてのコンテナの有用性を証明するために「コンテナ vs. VM」を論じるのは、現実に即していない気がします。コンテナとVMのいずれも使用していない企業が、どちらか一方を新規導入しなければならない状況なら、「コンテナ vs. VM」の議論も有意義ですが、現在、VMを使用している企業にはあまり有意義とは言えません。重要なのは、「コンテナ単独 vs コンテナ＋VM」の議論です。それにより、現在使用中のVMをコンテナに置き換えるか、VMを維持したままコンテナを導入するかを検討すべきです。その議論が深まれば深まるほど、コンテナとVMを併用したハイブリッド環境が今後さらに注目を集めることは想像に難くありません。
RSSフィードを取得する
