ハイパーバイザーとの違いは？　「コンテナ技術」を活用する5つのメリット／デメリット（1/2 ページ）

コンテナ技術は迅速なスケーラビリティ、柔軟性、使いやすさを保証するが、全てのワークロードに適しているわけではない。

公開 2015年07月17日 12時00分

更新 2016年11月15日 16時26分

著者

Stephen J. Bigelow

[TechTarget]

印刷する

ホストOS型とコンテナ型の違い（参照：1回で分かる：仮想化とは違うコンテナ技術「Docker」って何？）《クリックで拡大》

　コンテナは以前から存在する仮想化技術だ。クラウドコンピューティングの台頭、それに伴うアプリケーション開発の変化、米Dockerの「Docker」などの強力な新しいコンテナフレームワークが利用できるようになったことで、多くの新たな関心が寄せられている。2015年6月中旬に開催された米Gartnerの「IT Operations Strategies and Solutions Summit 2015」では、Gartnerの副社長で著名なアナリストでもあるトーマス・ビットマン氏がコンテナに関するセッションに登壇した。同氏のセッションでは、コンテナ技術に関する幅広いメリットだけでなく、重要なさまざまなデメリットについても取り上げられていた。本稿では、このようなデメリットについて説明し、対処法について考察したい。

コンテナ技術を知る

Dockerとは？

1．全てのタスクに適しているとは限らない

　コンテナは多様性をもたらすが、既存の全ての仮想マシン（VM）を一様に代替するものではないことにビットマン氏は言及した。仮想化の黎明期に、一部のレガシーアプリケーションが物理的な環境に導入するのが適していたのと同様に、コンテナ仮想化に適していないアプリケーションもある。

　例えばコンテナは、マイクロサービス型のアプリケーション開発に適している。マイクロサービス型のアプリケーション開発とは、基本的な構成要素を使用して、より複雑なアプリケーションを構成できるアプローチである。それぞれの構成要素はコンテナに導入され、アプリケーションの構成要素であるコンテナは互いにリンクされ総合的なアプリケーションを形成する。アプリケーションの機能を拡張する場合は、新しいアプリケーションを作り直すのではなく、適切な構成要素のコンテナを導入すればよい。

　モノリシックであることが求められるアプリケーションも存在する。モノリシックな設計にすると、スケーラビリティや迅速な導入などのメリットは簡単に享受できなくなる。この場合、コンテナでは単にワークロードが制限される。多くの場合、最適なアプローチは、コンテナ化によるメリットを享受できる既存のアプリケーションを調査して確認することだ。新しいアプリケーションの開発パラダイムは、コンテナ化によるメリットを享受できる可能性が高いだろう。簡単にコンテナ化できないアプリケーションは、完全に機能するVMを従来のハイパーバイザー上で実行できる。大手保険会社に勤めるITアーキテクトは、コンテナ導入に対して尻込みしているとし、次のように述べる。「コンテナは興味深いが、当社のソフトウェアチームがコンテナを正しく使いこなすには、多くの確認作業が必要になるだろう」

2．依存関係に取り組む

　一般的にVMは自己完結型で、各VMには一意のOS、ドライバー、アプリケーションコンポーネントが含まれている。適切なハイパーバイザーが利用できれば、VMは別のシステムに移行できる。一方、物理OS上で実行するコンテナは、基盤のOSカーネルの大半を各種ライブラリやバイナリと共有する。ビットマン氏は、コンテナに依存関係を持たせることは、サーバ間の移植可能性を制限することになり得ると話す。例えば、Docker上のLinuxコンテナは、米Microsoftの「Windows Server」の既存バージョンでは実行できない。

　この問題に対する回答は、解決策というよりは事実である。コンテナは数秒で起動して増やすことができ、OSは並外れた安定性や非常に高速な再起動を実現した”マイクロOS”や”ナノOS”のバリエーションを提供するように進化している。このような環境では、コンテナは基本的に可用性が高く、データセンターで他のサーバが利用できる限り、別のサーバに移行または待避できる。

　このような依存関係は、新しいOSの進化と共に緩和されている。例えば、Microsoftの次期OS「Windows Server 2016」では、DockerとMicrosoftのネイティブな「Hyper-V」コンテナのサポートが保証される。コンテナプラットフォームには、Docker以外に、LXC、米Odinの「Parallels Virtuozzo Containers」、米Joyentの「Joyent」、英Canonicalの「LXD」、米Spoonの「Spoon」などもある。また、どこかの時点で、VMwareがコンテナ市場に参入する可能性も大いにある。

3．低いレベルの分離

　ハイパーバイザーベースのVMでは、高いレベルの相互分離が実現される。これはシステムのハードウェアリソースが全て仮想化され、ハイパーバイザー経由でVMに提供されることに起因する。つまり、バグ、ウイルス、侵入といった事象が1台のVMを危険にさらすことはあるものの、そのリスクが別のVMに波及することはない。

　コンテナはOSカーネルやコンポーネントを共有し、最初から実行できるように深いレベルの承認（通常、Linux環境のルートアクセス権）が既に与えられている。そのため、分離レベルは低い。つまり、欠陥や攻撃が基盤のOSや別のコンテナに波及する可能性は高い。また、悪意のある活動が元の事象を超えてさらに波及する恐れもある。

　コンテナのプラットフォームはOSの権限を分離し、脆弱なセキュリティ体制を制限するように進化しているが、VMでコンテナを実行することで、管理者はセキュリティを向上させられるとビットマン氏は語る。例えば、Hyper-V上でLinux VMをセットアップしたり、Linux VMにDockerコンテナをインストールすることができる。VM内のコンテナが危険にさらされた場合も、脆弱性がVM外に波及することはなく、潜在的な被害の範囲は制限される。

次ページへハイパーバイザーベースとの違いは？