ベアメタルサーバと仮想化ホスティング環境の長所と短所にそれぞれ重みを付けるのは目新しいことではない。これは、2000年代に仮想化がデータセンターで広く採用されるようになるころからCTOの念頭にあった。それは誰もがDockerを知るようになるはるか前のことだ。

　ベアメタルサーバの主な長所を簡単に挙げるとすれば以下のようになる。

• ハードウェアエミュレーションによってシステムリソースが浪費されないため、パフォーマンスが高い
• 需要の高い期間にアイドルになるマシンリソースがないため、全てのリソースをフル活用できる
• インフラ内でのホスト、ネットワーク、ディスクの競合がほとんどないため、管理が容易

　一方仮想マシンには以下のような長所がある。

• 仮想マシンイメージをサーバから別のサーバに移すだけで、ホスト間でアプリケーションを簡単に移動できる
• 異なる仮想マシン内で動作するアプリケーションはそれぞれ独立している。その結果、セキュリティのメリットが幾つか生まれ、管理の複雑さを抑えられる
• 全てのアプリケーションを同じ種類の仮想マシンに展開することで、基になるホストサーバが同じ種類でなくても、インフラ全体で一貫したソフトウェア環境を維持できる。

　しかし、仮想マシンには幾つか欠点もある。

• サーバのリソースをフル活用できない。例えば、仮想マシンのディスクイメージを作成するためにサーバホストにストレージ領域を確保すると、そのディスクをアタッチした仮想マシンがその全領域を使用していなくても、そのストレージ領域を他の目的に使用できなくなる
• 仮想マシンから物理ハードウェアに直接アクセスできない。例えば、仮想マシンのコンピューティング操作をホストのGPUにオフロードすることはできない。できるとしても簡単ではない。それは、仮想マシンが基になるホスト環境から抽象化されているためだ。
• 仮想マシンのパフォーマンスは一般に物理サーバほど高くない。それはリソースが仮想サーバのエミュレーションに使用されるためだ

　最近の仮想化プラットフォームは、管理者がこうした制限を回避できる仕組みを用意している。例えば、動的ディスクイメージを作成できる。これにより、仮想マシンによるディスク使用量が増加するにつれてイメージが拡張され、ゲストが実際に使用する前にホストのストレージ領域が使用できなくなるのを防ぐことができる。また、場合によってはパススルー機能を利用して、仮想マシンからホスト上の物理ハードウェアに直接アクセスすることもできる。

　ただ、このような仕組みは常にうまく機能するとは限らない。このような仕組みは全種類のホストやゲストOSでサポートされているわけではなく、管理上の負担も増加する。実行するアプリケーションからベアメタルへのアクセスが必要なら、そのようなアプリケーションはベアメタルサーバで実行するのが最適だ。

　あるいは、ベアメタルサーバのコンテナ内部でアプリケーションを実行すれば、ベアメタルと仮想化の両方の長所を生かすことができる。

不可能を可能にするベアメタルでのコンテナの実行

　ベアメタルでコンテナを動作させれば、仮想化の欠点を補いながら、仮想マシンの多くの長所を生かすことができる。ベアメタルサーバで動作するコンテナにより以下のことが可能になる。

• アプリケーションのプロセスがホストサーバをサポートするOSと同じOSで動作するため、パススルー技法を使わずに、アプリケーションからベアメタルハードウェアにアクセスできる
• システムリソースの使用量を最適化できる。コンピューティング、ストレージ、ネットワークなど、コンテナが使用するリソースを制限できるが、通常、コンテナでは1つのコンテナがこれらのリソースを専用で使用する必要はない。そのため、ホストはシステムリソースを必要に応じて配分できる
• ホストサーバから独立したハードウェアエミュレーション層は存在しないため、アプリケーションのパフォーマンスはベアメタルのパフォーマンスと等しくなる

　また、ベアメタルのコンテナホストを使用することで、これまで仮想マシンを使わなければ利用できなかった以下の長所も得られる。

• ホストサーバ間で簡単に移動できる移植可能な環境内部にアプリケーションを展開できる
• アプリケーションの分離。議論の余地はあるが、コンテナの分離レベルは仮想マシンほどではない。だが、コンテナにより管理者はアプリケーションが相互作用することを防ぎ、各コンテナに関連付けられる権限やリソースへのアクセス権に厳格な制限を設定することができるようになる

　端的に言えば、ベアメタルで動作するコンテナは不可能を可能にする。ベアメタルのパフォーマンスとハードウェアアクセスの長所に加え、仮想マシンの移植性と分離機能も得られる。