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

• 技術文書・技術解説
  [Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分？　不足する対策を16項目でチェック
• 製品資料
  [株式会社ウェーブスプリッタ・ジャパン] 100Gbps対応の光トランシーバーはどう選ぶ？　10分で分かる選定のポイント
• 製品資料
  [株式会社フィックスターズ] 組み込み開発の生産性と機密性を両立、自社環境で構築する「セキュアAI」活用術
• 製品レビュー
  [ServiceNow Japan合同会社] 問い合わせの約9割を自動で解決、AI主導の自律型CRMがもたらす業務変革の全貌
• 市場調査・トレンド
  [ServiceNow Japan合同会社] AI活用が業務自動化で止まる理由は何か？　調査で判明した課題と変革への道筋