「仮想マシン」と「物理サーバ」を比較　コンテナにはどちらを選ぶべき？

物理サーバと仮想マシンのどちらがコンテナ導入に適するのか。どちらにも、それぞれ大きな長所と短所がある。

公開 2019年01月15日 05時01分

著者

Chris Tozzi

[TechTarget]

印刷する

　コンテナのメリットは広く知られているが、コンテナの導入先に選ぶべきインフラの種類についてはどうだろうか。コンテナを物理サーバに配備するのは、仮想マシン（VM）に配備するよりも適切な選択なのだろうか。

　当然、その答えはさまざまな要素によって変わる。コンテナを物理サーバとVMで運用することには、それぞれ長所と短所がある。

併せて読みたいお薦め記事

「コンテナ」についてもっと詳しく

「物理サーバ」のメリット

物理サーバとVMの比較

　2000年代にデータセンターでサーバ仮想化技術が普及して以来、最高技術責任者（CTO）は物理サーバとVMのどちらが適切かをずっと考えてきた。コンテナ管理ツール「Docker」の名を誰もが耳にするようになったのは、そのかなり後のことだ。Dockerの登場は2013年にさかのぼる。

　主要な物理サーバのメリットは、次の通りだ。

物理ハードウェアのエミュレーションによるシステムリソースの浪費が基本的にはないため、パフォーマンスが高い。
負荷のピーク時に未使用のシステムリソースが生じにくく、リソースを十分に活用しやすい。

　一方のVMには、以下のようなメリットがある。

サーバから別のサーバへVMイメージを転送するだけで、サーバ間でアプリケーションを簡単に移動できる。
アプリケーションを異なるVMで実行させることで、アプリケーション同士を論理的に分離できる。この構造はセキュリティ上のメリットがあり、管理の複雑さも減る。

　ただしVMには、次のような幾つかのデメリットも伴う。

サーバリソースが十分に活用されない可能性がある。例えばVMイメージを作成するためにサーバのストレージ領域を確保すると、その領域を他の目的に使用することが難しくなる。VMがそのストレージ領域を使い切っていなくても同様だ。
ほとんどの場合、VMから物理ハードウェアへの直接アクセスはできない。例えば演算処理をサーバのGPU（画像処理プロセッサ）にオフロード（移転）することは、少なくとも簡単にはできない。
VMではアプリケーションとハードウェアの間に抽象化層が追加されるため、一般的に物理サーバと同程度のパフォーマンスではアプリケーションを実行できない。

　サーバ仮想化製品の最新機能は、管理者がこうした制約を回避するのに役立つ可能性がある。VMの使用量増加に合わせてディスクイメージの容量を動的に拡大させる機能を使えば、ゲストOSが実際に使わないにもかかわらず、サーバのストレージ領域を余分に確保してしまう事態を回避できる。VMからサーバの物理ハードウェアに直接アクセスするパススルー機能の実装も進む。

　こうした機能は、必ずしも適切に動作しないことがある。全ての種類のゲストOSで利用できるわけでもない。新たな機能によって管理の負担が増える可能性もある。実行したいアプリケーションで物理ハードウェアへのアクセスが必要なら、そのアプリケーションは物理サーバで実行するのが最適だ。

物理サーバ×コンテナで不可能を可能に

　物理サーバでコンテナを実行すると、以下のようなメリットを享受できる。しかもVMのデメリットは伴わない。

パススルー機能を使わなくても、アプリケーションから物理ハードウェアへアクセスできる。
システムリソースを適切に利用できる。コンテナでは使用できるコンピューティングリソースやストレージ、ネットワークの量を制限可能だ。一般的なコンテナ管理ツールでは、これらのリソースを1つのコンテナ専用にする必要はない。そのためサーバでは、共有システムリソースを必要に応じて分散利用できる。
サーバからアプリケーションを分離するハードウェアエミュレーション層が存在しないため、アプリケーションは物理ハードウェアならではのパフォーマンスを得ることができる。

　上記に加えて、VMで実現できていた次のようなメリットも得られる。

サーバ間を簡単に移動可能な、移植性のある環境にアプリケーションを導入できる。
アプリケーションを分離できる。コンテナはVMと同レベルの分離は実現できないものの、アプリケーションによるデータのやりとりを防ぐことはできる。

　物理サーバでコンテナを実行すると、不可能に見えることが可能になることがある。パフォーマンスと利便性の双方を高めることができるからだ。同時に、VMに備わる移植性と分離の機能のメリットも得られる。

物理サーバ×コンテナのデメリット

　「なぜ全てのアプリケーションを物理サーバのコンテナで実行しないのか」と不思議に思う人もいるだろう。物理サーバを使用して、VMではなくコンテナをホストする場合、次のデメリットが伴うことを考慮する必要がある。

アップグレードが難しい。物理サーバを置き換えるには、新しいサーバでコンテナ環境を一から作り直さなければならない。VMであれば、VMイメージにコンテナ環境が含まれていれば、そのイメージを新しいサーバへ簡単に移動できる。
ほとんどのクラウドでVMが必要になる。「ベアメタルクラウド」といった名称で物理サーバを提供するクラウドは、Rackspace USの「OnMetal Cloud Servers」やOracleの「Oracle Cloud Infrastructure」など幾つか存在する。クラウドとはいえ、クラウド環境の物理サーバはコストが大幅に高くなるのが一般的だ。全体的に見て、大半のパブリッククラウドはVMしか提供していない。こうしたクラウドでコンテナを利用したい場合、VMにコンテナ管理ツールを導入する必要がある。
物理サーバでは、障害発生前の状態に戻すロールバックが難しい。ほとんどのサーバ仮想化製品では、管理者はVMのスナップショット機能を利用し、ある時点での構成状態に後からロールバックできる。コンテナは本来一時的な存在であり、ロールバックする対象がない。ホストOSやファイルシステムに組み込まれたロールバック機能は使用できるだろう。ただしシームレス性でVMに劣る場合が多い。シンプルなロールバックを実現するためには、コンテナをVMでホストする必要がある。
コンテナはOSに依存する。LinuxコンテナはLinuxで実行され、WindowsコンテナはWindows Serverで実行される。Windows Serverの物理サーバで、Linux向けにコンパイルされたアプリケーションのDockerコンテナを実行するには、LinuxのVM環境が必要になる。ただし、この制限をなくす技術開発が進んでいる。
コンテナはあらゆるハードウェア／ソフトウェア環境で稼働するわけではない。最近、VMware製品をはじめとするサーバ仮想化製品では、VMでほぼ全ての種類のOSをホストできるようになった。Dockerをはじめとするコンテナ管理ツールの方が、制限はより厳しくなる。Dockerを実行できるのは、「Linux」や特定バージョンの「Windows Server」を実行するサーバ、IBMのメインフレームに限られる。例えば本稿執筆時点のDockerは、「Windows Server 2012」では稼働できない。例えばWindows Server 2012を実行する物理サーバでコンテナ管理ツールを利用する場合、物理サーバで別途VMを稼働させる必要がある。