Gartnerが提言する

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

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

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

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外に波及することはなく、潜在的な被害の範囲は制限される。

この記事の著者

関連記事

• 

  ハイパーバイザー型よりもコンテナ型の仮想化が有利なケースは？

• 

  「Windows Server 2016」で待望のコンテナ機能が使える日はいつやってくる？

• 

  1回で分かる：仮想化とは違うコンテナ技術「Docker」って何？

• 

  押さえておきたいDockerの社内利用、メリット／デメリットを解説

新着ホワイトペーパー PR

• 製品資料
  [横河レンタ・リース株式会社] 不正アクセス被害が深刻化　狙われる「セキュリティの死角」はどこなのか？
• 製品資料
  [NTTインテグレーション株式会社] 2026年度末開始の「SCS評価制度」をどう攻略する？
• 製品資料
  [NTTインテグレーション株式会社] 「復旧せよ」の決断に即答できる？　いま必要な戦略的データ復旧の極意
• 製品資料
  [NTTインテグレーション株式会社] SCS評価制度は「共通のモノサシ」になる？　いま製造業がすべきこととは
• 事例
  [Extreme Networks株式会社] BYOD時代の大学のWi-Fi、安定した通信環境をどう実現する？