筆者は以前、「Docker」コンテナをVMwareと統合することの難しさについて書いたことがある。VMwareは、ユーザーが仮想マシン(VM)の中でコンテナを実行することを望んでいるが、コンテナの利用方法としては、物理ハードウェア上での実行の方が一般的だ。VMを物理マシンで実行するのと同様の形である。
コンテナはOSレベルで実行される抽象化技術で、VMを上回る効率性を実現する。本記事では、VMと比較した場合のコンテナの長所と短所について説明する。
コンテナとVMの基本的な高レベルでの違い
VMは物理ハードウェアを抽象化する。それぞれのVMは、仮想化されたBIOSから、仮想化されたネットワークアダプタ、ストレージ、CPUまで、完全なサーバハードウェアスタックを備える。完全なハードウェアスタックを備えるということは、各VMに完全なOSが必要ということだ。各VMのインスタンス化には、完全なOSの起動が必要になる。VMのブートプロセスは通常、物理ハードウェアよりはるかに高速だ。ただし、OSや物理ハードウェアのパフォーマンス、システム負荷によっては、このプロセスに数秒~数分かかることもある。
コンテナ抽象化は、サーバハードウェアスタック全体を仮想化するのではなく、OSレベルで実行される。ほとんどのコンテナシステムでは、ユーザー領域が抽象化される。その典型的な例が、「Citrix XenApp」などのアプリケーションプレゼンテーションシステムだ。XenAppは、セグメント化されたユーザー領域をアプリケーションインスタンスごとに作成する。XenAppの主な使用例は、数十人から数千人単位のリモートワーカーへのオフィススイートの展開だ。このために、XenAppはそれぞれの接続ユーザーについて、サンドボックス化されたユーザー領域を「Windows Server」上に作成する。各ユーザーはカーネル、ネットワーク接続、ベースファイルシステムなど、同一のOSインスタンスを共有するが、オフィススイートの各インスタンスには個別のユーザー領域が確保される。
ユーザーセッションごとに個別のカーネルが読み込まれるわけではないため、複数のOSに付随するオーバーヘッドは、コンテナでは発生しない。したがって、コンテナのメモリとCPUの使用量は、同様のワークロードを実行するVMより少ない。よくあることだが、XenAppが単一のサーバで数百人規模のユーザーをサポートするのに対し、完全なVMを利用する「Citrix XenDeskop」は同じハードウェアで数十人単位のユーザーをサポートする。さらに、コンテナはOS内のサンドボックス化された環境にすぎないため、コンテナの開始には数ミリ秒しかかからないこともある。
コンテナ使用の難点
セキュリティ:VMを使用する利点は、物理ハードウェアレベル、つまり個々のカーネルレベルでの抽象化だ。こうした個々のカーネルによって、攻撃対象領域がハイパーバイザに限定される。理論上は、特定のOSバージョンの脆弱性を悪用して、同一物理ホスト上で実行中のほかのVMを攻撃することはできない。コンテナは同一のカーネルを共有するため、管理者とソフトウェアベンダーは特別な注意を払って、同一ホスト内のコンテナに起因するセキュリティ問題を回避する必要がある。
管理:Dockerなどのソリューションでコンテナの管理は楽になるが、多くの顧客は依然として、コンテナ管理は手順が明確に確立されていないと感じている。Dockerを利用している顧客の1人が先ごろ、記事を投稿して自身の体験を共有し、本番環境でのDocker管理に対する苛立ちを綴った。
結論
Dockerのようなコンテナ管理プラットフォームが発展し続けているため、データセンター管理者はコンテナ向きと思われるワークロードの調査を継続する必要がある。エンタープライズユーザーは徐々に開始した方がいいだろう。
特定のワークロードについてはVM内でコンテナを展開し、本番環境で同テクノロジの経験を得ることをお勧めする。例えば、Dockerのようなコンテナテクノロジを使って、複数の社内向けウェブサーバを単一のVM上にまとめてもいいだろう。あるいは、新しいアプリケーションの開発環境として、コンテナを提供してもいい。その経験を活用することで、コミュニティーにフィードバックを提供し、コンテナを自社のデータセンター運用に組み込む方法を理解することができるだろう。
提供:Joe McKendrick
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。