JP2021521530A - ソフトウェアコンテナの性能および分離を改善するための方法およびシステム - Google Patents

Abstract

一実施形態における方法は、カーネルベースの分離層を実装して、カーネルベースの分離層上のソフトウェアコンテナをライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含むように構成して、ソフトウェアコンテナの１つ以上のユーザプロセスを実行することを含む。方法は、各処理デバイスがメモリに結合されたプロセッサを備えた、複数の処理デバイスを含む、クラウドベースの処理プラットフォーム、エンタープライズ処理プラットフォームまたは他のタイプの処理プラットフォームによって実行される。ライブラリオペレーティングシステムは、例示として、ソフトウェアコンテナにおいて実行している１つ以上のユーザプロセスの特権レベルと同じである特権レベルで、ソフトウェアコンテナで動作する。ライブラリオペレーティングシステムは、例示として、システムコールを対応する関数コールに変換することと連動して１つ以上のユーザプロセスのバイナリの自動翻訳をサポートするように構成される。【選択図】図３

Description

優先権の主張
本出願は２０１８年４月１１日に出願の「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｉｍｐｒｏｖｉｎｇ Ｓｏｆｔｗａｒｅ Ｃｏｎｔａｉｎｅｒ Ｐｅｒｆｏｒｍａｎｃｅ ａｎｄ Ｉｓｏｌａｔｉｏｎ」と題する米国仮特許出願第６２／６５６，０５１号の優先権を主張し、これは参照により完全に本明細書に組み込まれる。

政府支援の陳述
本発明は、米国科学財団（ＮＳＦ）によって授与された契約番号ＣＳＲ−１４２２５４４、ＣＮＳ−１６０１８７９、ＣＳＲ−１７０４７４２、１０５３７５７および０４２４４２２、米国国立標準技術研究所（ＮＩＳＴ）によって授与された契約番号６０ＮＡＮＢ１５Ｄ３２７および７０ＮＡＮＢ１７Ｈ１８１、ならびに、米国国防総省高等研究計画局（ＤＡＲＰＡ）によって授与された契約番号ＦＡ８７５０−１０−２−０２３８、ＦＡ８７５０−１１−２−０２５６およびＤ１１ＡＰ００２６６の下で政府支援を受けてなされた。米国政府は、本発明における一定の権利を有する。

本発明の分野は、概して情報処理システムに関し、より具体的には、このようなシステムで利用されるソフトウェアコンテナに関する。

コンテナは、アプリケーションをパッケージングする好適な方法となっており、サーバレスアーキテクチャおよび多数の他のタイプの処理プラットフォームのキーコンポーネントである。また同時に、エクソカーネル（ｅｘｏｋｅｒｎｅｌ）アーキテクチャは、ハイパーバイザがエクソカーネルとして役割を果たし、多くのライブラリオペレーティングシステム（ＯＳ）が提供されているかまたは開発中であることによって、牽引力を得ている。エクソカーネルは、それらのトラステッドコンピューティングベース（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｂａｓｅ、ＴＣＢ）および攻撃対象領域が小さいため、優れたセキュリティ分離特性を有し、一方でライブラリＯＳは特定のアプリケーションのためにカスタマイズすることができる。残念なことに、これらの２つの傾向は、現在互いに互換性がない。現在のライブラリＯＳは、最新のアプリケーションコンテナを動作させるために必要となっている、複数のプロセスに対するバイナリ互換性およびサポートを欠いている。

例示の実施形態は、本明細書においてＸコンテナと称される、改良型のソフトウェアコンテナを提供する。１つ以上の実施形態のＸコンテナアーキテクチャにおいて、Ｘコンテナは、例示として、仮想マシンハイパーバイザおよびホストオペレーティングシステムのうち１つを用いて実装されるＸカーネル上のライブラリＯＳとして、専用のＬｉｎｕｘ（登録商標）カーネルによって動作する。Ｘカーネルは、さらに一般的に言えば、本明細書において、「カーネルベースの分離層」と呼ばれるものの例である。結果として得られるＸコンテナの配置は、例示として、変更されていないマルチプロセッシングアプリケーションをサポートして、即座に自動的にアプリケーションバイナリ置換を最適化する。このタイプのいくつかの実施形態のＸコンテナは、変更されていないＬｉｎｕｘ（登録商標）と比較してシステムコールオーバーヘッドのかなりの減少を好都合に提供すると共に、ウェブベンチマーク上のＵｎｉｋｅｒｎｅｌおよびＧｒａｐｈｅｎｅのようなライブラリＯＳも著しく上回る。

一実施形態において、方法は、カーネルベースの分離層を実装して、カーネルベースの分離層上のソフトウェアコンテナをライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含むように構成して、ソフトウェアコンテナの１つ以上のユーザプロセスを実行することを含む。この方法は、複数の処理デバイスを含む、クラウドベースの処理プラットフォーム、エンタープライズ処理プラットフォームまたは他のタイプの処理プラットフォームによって実行され、それぞれのこのような処理デバイスがメモリに結合されたプロセッサを含む。

ライブラリオペレーティングシステムは、例示として、ソフトウェアコンテナにおいて実行している１つ以上のユーザプロセスの特権レベルと同じである特権レベルで、ソフトウェアコンテナで動作する。

ライブラリオペレーティングシステムは、いくつかの実施形態では例示として、システムコールを対応する関数コールに変換することと連動して１つ以上のユーザプロセスのバイナリの自動翻訳をサポートするように構成される。

本発明のこれらの、そしてまた他の、例示の実施形態は、その中で実施されるソフトウェアプログラムコードを有するプロセッサ可読ストレージ媒体を含む、システム、方法、装置、処理デバイス、集積回路およびコンピュータプログラム製品を含むが、これに限定されるものではない。

図１は、例示の実施形態のクラウドベースの処理プラットフォームを実装しているＸコンテナを含む、情報処理システムを示す。 図２は、例示の実施形態のＸコンテナを実装しているエンタープライズ処理プラットフォームを含む、情報処理システムを示す。 図３は、例示の実施形態のＸコンテナの例示の配置を示す。 図４は、本明細書において開示されるＸコンテナを利用しているアーキテクチャを含む様々なアーキテクチャの分離境界を例示する。 図５は、例示の実施形態の、異なる数のＸコンテナを使用している２つのアプリケーションの代替構成を示す。 図６は、例示の実施形態の、１つ以上のＸコンテナで実行されるバイナリ置換の例を示す。 図７は、例示の実施形態の評価において利用されるソフトウェアスタックの例を示す。 図８は、例示の実施形態で実行される評価の結果を示しているプロットである。 図９は、例示の実施形態で実行される評価の結果を示しているプロットである。 図１０は、例示の実施形態で実行される評価の結果を示しているプロットである。 図１１は、例示の実施形態で実行される評価の結果を示しているプロットである。 図１２は、例示の実施形態で実行される評価の結果を示しているプロットである。

本発明の実施形態は、例えば、コンピュータネットワークを含む情報処理システム、または、ネットワーク、クライアント、サーバ、処理デバイスおよび他のコンポーネントの他の配置の形で実施することができる。このようなシステムの例示の実施形態を、本明細書において詳述する。しかしながら、本発明の実施形態は、多種多様な他のタイプの情報処理システムおよび関連するネットワーク、クライアント、サーバ、処理デバイスまたは他のコンポーネントに、さらに一般的に適用できることを理解すべきである。
したがって、「情報処理システム」という本明細書で用いられる用語は、概して、これらおよび他の配置を含むと解釈されることを意図している。

図１は、例示の実施形態のＸコンテナを実装している情報処理システム１００を示す。システム１００は、複数のユーザデバイス１０２−１、１０２−２、．．．１０２−Ｎを含む。ユーザデバイス１０２は、ネットワーク１０５上でクラウドベースの処理プラットフォーム１０４と通信するように構成される。

ユーザデバイス１０２の１つ以上は、それぞれ、例えば、ラップトップコンピュータ、タブレット型コンピュータもしくはデスクトップパーソナルコンピュータ、携帯電話、または別のタイプのコンピュータもしくは通信デバイス、および複数のこのようなデバイスの組合せを含むことができる。いくつかの実施形態では、ユーザデバイス１０２の１つ以上はそれぞれのコンピューティングノードを含むことができ、それは例示として、１つ以上の処理プラットフォームに実装されて、おそらくクラウドベースの処理プラットフォーム１０４を含む。

システム１００の様々な要素の間の通信は、図のネットワーク１０５によって集合的に表される１つ以上のネットワークを通じて行われると仮定する。ネットワーク１０５は、例示として、例えば、インターネットなどのグローバルコンピュータネットワーク、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、衛星ネットワーク、電話もしくはケーブルネットワーク、携帯電話ネットワーク、ＷｉＦｉまたはＷｉＭＡＸなどの無線プロトコルを使用して実装されるワイヤレスネットワーク、またはこれらおよび他のタイプの通信ネットワークの様々な部分もしくは組合せを含むことができる。

クラウドベースの処理プラットフォーム１０４は、より一般的に本明細書において、メモリに結合されたプロセッサをそれぞれ含んでいる複数の処理デバイスを含む、「処理プラットフォーム」と称されるものの例である。処理デバイスの１つ以上は、複数のプロセッサおよび／または複数のメモリをそれぞれ含むことができる。

処理プラットフォームの所与のこのような処理デバイスのプロセッサは、例えば、マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、中央演算処理装置（ＣＰＵ）、演算論理ユニット（ＡＬＵ）、グラフィック処理装置（ＧＰＵ）、デジタルシグナルプロセッサ（ＤＳＰ）または他の類似の処理デバイスコンポーネント、ならびに任意の組合せの他のタイプおよび配置の処理回路を含むことができる。

処理プラットフォームの所与のこのような処理デバイスのメモリは、例えば、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）もしくは他のタイプのＲＡＭ、読取り専用メモリ（ＲＯＭ）、フラッシュメモリもしくは他のタイプの不揮発性メモリ、磁気メモリ、光メモリ、または任意組合せの他のタイプのストレージなどの、電子メモリを含むことができる。

メモリは、例示として、プロセスによる実行のためのプログラムコードを記憶する。このようなメモリは、より一般的に本明細書において、その中で実施されるプログラムコードを有する、「プロセッサ可読ストレージ媒体」と称されるものの例である。

このようなプロセッサ可読ストレージ媒体を含む製品は、本発明の実施形態と考えられる。本明細書で用いられる「製品」という用語は、一時的な、伝播している信号を除くものと理解すべきである。

プロセッサ可読ストレージ媒体を含む他のタイプのコンピュータプログラム製品は、他の実施形態で実施することができる。

加えて、本発明の実施形態は、本明細書において開示されるように、Ｘコンテナを実装することに関連した処理動作を実施するように構成された処理回路を含んだ、集積回路の形で実装することができる。

クラウドベースの処理プラットフォーム１０４または本明細書において開示される他の処理プラットフォームの所与の処理デバイスは、通常上記のプロセッサおよびメモリに加えて他のコンポーネントを含む。例えば、所与の処理デバイスは、例示として、処理デバイスが他のシステム要素とネットワーク１０５を通じて通信することができるように構成されたネットワークインタフェースを含む。このようなネットワークインタフェースは、例示として、１つ以上の従来のトランシーバを含む。

本実施形態のクラウドベースの処理プラットフォーム１０４は、より具体的には、物理インフラストラクチャ１１４で動作している仮想化インフラストラクチャ１１２を利用している複数のＸコンテナ１１０を実装する。物理インフラストラクチャ１１４は例示として、上記のタイプの複数の処理デバイスを含み、それぞれが少なくとも１つのプロセッサおよび少なくとも１つのメモリを含む。例えば、いくつかの実施形態では、物理インフラストラクチャは、ベアメタルホストまたは他のタイプのコンピュータまたはサーバを含む。仮想化インフラストラクチャ１１２はいくつかの実施形態では仮想マシンハイパーバイザを含むが、ハイパーバイザはＸコンテナ１１０を実装するために必要ではない。したがって、仮想化インフラストラクチャ１１２は、他の実施形態では除去することができる。

図２の情報処理システム２００は、仮想化インフラストラクチャ１１２などの仮想化インフラストラクチャを含まない、１つの可能性がある別の実施形態を表す。システム２００で、エンタープライズ処理プラットフォーム２０４は複数のＸコンテナ２１０を直接物理インフラストラクチャ２１４上に実装し、あらゆるハイパーバイザまたは他の仮想化インフラストラクチャをＸコンテナ２１０とその基盤となる物理インフラストラクチャ２１４との間から除去し、後者の物理インフラストラクチャ２１４は例示として、ベアメタルホストまたは他のタイプのコンピュータまたはサーバとして実装される。システム２００の他の要素は、他の場合は通常、図１の１００システムと連動して先に述べたものと同じである。

それぞれの図１および図２で示すシステム１００および２００の特定の配置は開設の例としてだけ示されるものであって、多数の他の配置が可能であることは理解されよう。

例えば、これらの実施形態がそれぞれのクラウドベースおよびエンタープライズ処理プラットフォームのＸコンテナを実装するが、多種多様な追加的であるか代替の処理プラットフォーム、例えばモノのインターネット（ＩｏＴ）プラットフォームおよびネットワーク機能仮想化（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ、ＮＦＶ）プラットフォームが使用可能である。

他の例には、サービスとしてのプラットフォーム（ＰａａＳ）モデル、サービスとしてのソフトウェア（ＳａａＳ）モデル、サービスとしてのインフラストラクチャ（ＩａａＳ）モデルおよび／またはサービスとしての機能（ＦａａＳ）モデル、ならびにエンタープライズアプリケーションコンテナプラットフォーム、サーバレスコンピューティングプラットフォーム、マイクロサービスプラットフォームおよびクラウドベースのネイティブアプリケーションプラットフォーム、ならびにまた他の一般のクラウドコンピューティングまたはエンタープライズコンピューティングインフラストラクチャに従って実装されるプラットフォームが含まれる。さらに一般的に言えば、Ｘコンテナは、それらのセキュリティおよび性能の利点から恩恵を受けることができるいかなるプラットフォームにも実装することができる。

Ｘコンテナ１１０または２１０を実装する際に、システム１００または２００は、例示として、本明細書において、「カーネルベースの分離層」と呼ばれるものを実装するように構成される。Ｘコンテナ１１０または２１０の所与の１つは、例示として、カーネルベースの分離層上のソフトウェアコンテナとして構成される。所与のＸコンテナはライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含み、１つ以上のユーザプロセスが所与のＸコンテナで実行される。カーネルベースの分離層は、いくつかの実施形態では、特にＸコンテナの専用のオペレーティングシステムカーネルに対して、Ｘカーネルの形で実装される。Ｘカーネルは、より具体的には仮想マシンハイパーバイザまたはホストオペレーティングシステムの少なくとも一部を含むことができる。他のタイプのカーネルベースの分離層が、他の実施形態で使用可能である。

図３は、例示の実施形態のＸコンテナ３１０の例示の配置を含む、情報処理システム３００の一部を示す。この例のＸコンテナ３１０はより具体的には、すべてがＸカーネル３１２に実装されている、第１第、２および第３のＸコンテナ３１０−１、３１０−２および３１０−３を含む。

上記のように、Ｘカーネルは、いくつかの実施形態では仮想マシンハイパーバイザ（例えば、Ｘｅｎ）を含むことができる。例えば、このタイプの所与の実施形態のＸカーネル３１２は、図１の仮想化インフラストラクチャ１１２の１つ以上の仮想マシンハイパーバイザを用いて実装することができる。仮想マシンは、本明細書において、それぞれのＶＭとも称される。

他の実施形態のＸカーネル３１２は、ホストオペレーティングシステムの少なくとも一部を含むことができる。例えば、このタイプの実施形態では、Ｌｉｎｕｘ（登録商標）カーネルまたはＷｉｎｄｏｗｓ ＯＳカーネルを用いて、Ｘカーネルを実装することができる。このような実施形態は、例示として、直接図２の物理インフラストラクチャ２１４上で動作する。

一例として挙げるに過ぎないが、第１のＸコンテナ３１０−１は単一のユーザプロセスを含み、第２のＸコンテナ３１０−２は２つのユーザプロセスを含み、第３のＸコンテナ３１０−３は３つのユーザプロセスを含む。異なる数および配置のＸコンテナおよびそれらのそれぞれの関連するプロセスまたは複数プロセスが使用可能である。

図３の実施形態の各Ｘコンテナ３１０は、図ではＸ−ＬｉｂＯＳと記されているライブラリオペレーティングシステムとして、対応する専用のオペレーティングシステムカーネルを含む。Ｘ−ＬｉｂＯＳは、例示として、指定されたタイプのモノリシックオペレーティングシステムカーネルから変換される。Ｘ−ＬｉｂＯＳは、Ｘコンテナで実行している１つ以上のユーザプロセスの特権レベルと同じである特権レベルで、Ｘコンテナで動作する。Ｘ−ＬｉｂＯＳは、例示として、本明細書において他でさらに詳細に後述するように、システムコールを対応する関数コールに変換することと連動して１つ以上のユーザプロセスのバイナリの自動翻訳をサポートするように構成される。

上記のように、Ｘカーネル３１２上の各Ｘコンテナ３１０は、その対応するＸ−ＬｉｂＯＳインスタンスとして別々の専用のオペレーティングシステムカーネルを含む。１つ以上のユーザプロセスの異なるセットは、Ｘコンテナ３１０のそれぞれのものにおいてそれらのそれぞれのＸ−ＬｉｂＯＳインスタンスを用いて実行する。したがって、Ｘコンテナ３１０のいずれか１つにおいて実行しているユーザプロセスは、Ｘコンテナ３１０の他のものでそれぞれ実行しているユーザプロセスから、確実に分離される。

Ｘカーネル３１２およびそれぞれのＸコンテナ３１０のＸ−ＬｉｂＯＳインスタンスの全てが、同じタイプのオペレーティングシステムを利用する必要はない。例えば、Ｘカーネル３１２およびＸ−ＬｉｂＯＳインスタンスの所与の１つは、異なるタイプのそれぞれの第１および第２のオペレーティングシステムを用いて実装することができる。

いくつかの実施形態では、Ｘカーネル３１２上のＸコンテナ３１０の所与の１つがそのＸ−ＬｉｂＯＳインスタンスとして専用のオペレーティングシステムカーネルを含むように構成することはさらに、既存のソフトウェアコンテナのコンテナイメージを抽出して、Ｘカーネル３１２上のＸコンテナを構成する際の仮想マシンイメージとして抽出されたコンテナイメージを利用することを含む。このタイプの配置において、Ｘカーネル３１２上のＸコンテナは、既存のソフトウェアコンテナのラッピングされたバージョンを含むことができる。このような実施形態の既存のソフトウェアコンテナの１つ以上のユーザプロセスは、例示として、それらの１つ以上のユーザプロセスのいかなる修正も必要とすることなく、Ｘカーネル３１２上の所与のＸコンテナの１つ以上のユーザプロセスとして実行することを許可される。

異なるタイプのＸコンテナ３１０を、異なる実施形態で実装することができる。例えば、Ｘコンテナ３１０はいくつかの実施形態では、本明細書において準仮想化されたＸコンテナまたはＰＶ Ｘコンテナと称されるものとして実装されて、ライブラリオペレーティングシステムおよび１つ以上のユーザプロセスはユーザモードで動作する。このタイプのいくつかの実施形態は、例示として、他の場合は標準仮想マシンハイパーバイザまたはオペレーティングシステムカーネルであるものの修正されたバージョンとして、Ｘカーネル３１２を実装する。

別の例として、他の実施形態のＸコンテナは、本明細書においてハードウェアアシスト型仮想化ＸコンテナまたはＨＶ Ｘコンテナと称されるものとして実装されて、ライブラリオペレーティングシステムおよび１つ以上のユーザプロセスはハードウェアアシスト型仮想マシンの中でカーネルモードで動作する。このタイプのいくつかの実施形態は、標準仮想マシンハイパーバイザまたはオペレーティングシステムカーネルとしてＸカーネル３１２を実装する。このタイプの他の実施形態では、いくつかの修正が仮想マシンハイパーバイザまたはオペレーティングシステムになされ得る可能性がある。

図３に図示される例示のＸコンテナアーキテクチャは、ソフトウェアコンテナに改良された性能および分離を提供する。いくつかの実施形態では、Ｘコンテナアーキテクチャは、Ｌｉｎｕｘ（登録商標）カーネルなどの従来のモノリシックオペレーティングシステムカーネルを、Ｘコンテナの１つ以上のユーザプロセスと同じ特権レベルで動作するＸ−ＬｉｂＯＳインスタンスに変える。異なるＸコンテナの分離は、最小のトラステッドコンピューティングベースおよびカーネル攻撃対象領域によって保護される。

従来のコンテナ実装とは異なり、Ｘコンテナ分離は、この２０年の間に製造された大部分のＩｎｔｅｌプロセッサに影響を及ぼす最近発見されたメルトダウン（Ｍｅｌｔｄｏｗｎ）ＣＰＵバグに影響されない。例示の実施形態は、この脆弱性および他のセキュリティ問題によって生じるコンテナ分離の問題を緩和するために用いることができる。

Ｘコンテナはいくつかの実施形態では例示として、自動的にシステムコール命令を関数コールに翻訳するように構成され、それは、既存のコンテナが、いくつかの実施形態ではいかなる修正もなくＸコンテナで動作することができるという点で、完全なバイナリ互換性のサポートを可能にする。

Ｘコンテナは、従来のアプローチに対して強化された分離を示す。例えば、開示された配置は、所与のホスト上の危殆化されたコンテナがその同じホスト上の他のコンテナを危険にさらすのを防止する。Ｘコンテナは、既存のアプリケーションに対する安全なコンテナ分離だけでなく、上記のメルトダウン脆弱性などの緊急のコンテナセキュリティ問題に対するソリューションを提供する。

上記のように、例示の実施形態のＸコンテナは、Ｘカーネルに対して仮想マシンハイパーバイザまたはオペレーティングシステムカーネルを用いる（例えば、いわゆる「エクソカーネル」として役割を果たす）ことによって、これらおよび他の問題に対処する。従来のモノリシックオペレーティングシステムカーネル、例えばＬｉｎｕｘ（登録商標）カーネルは、例示として、ライブラリＯＳに変換されて、それは同じ特権レベルで１つ以上のユーザプロセスと共に動作する。

ユーザプロセスのバイナリは、即座にパッチされて、システムコールを最適化された性能および完全なバイナリ互換性のための関数コールに翻訳することができる。

既存のＬｉｎｕｘ（登録商標）コンテナ（例えば、Ｄｏｃｋｅｒ、ＬＸＣ）は、コンテナディスクイメージを抽出して、仮想マシンイメージとしてそれを使用することによって、自動的にＸコンテナにラッピングすることができる。

Ｘコンテナアーキテクチャは、相互に信頼できないユーザからのプログラムの安全な分離および効果的な実行をサポートするパブリックコンテナクラウドまたはサーバレスコンピューティングプラットフォームにおいてだけでなく、多種多様な他のクラウドベースまたはエンタープライズ処理プラットフォームにおいても使用することができる。

前述のように、ＸカーネルおよびＸ−ＬｉｂＯＳインスタンスは、いくつかの実施形態では、異なるオペレーティングシステムタイプに基づいて実装することができる。例えば、ＸカーネルはＸｅｎに基づいて実装することができ、Ｘ−ＬｉｂＯＳはＬｉｎｕｘ（登録商標）カーネルに基づいて実装することができる。

いくつかの実施形態では、Ｘコンテナアーキテクチャは非常に効率的なＬｉｂＯＳとして役割を果たすために修正されたＬｉｎｕｘ（登録商標）カーネルを利用してそれにより完全な互換性を既存のアプリケーションおよびカーネルモジュールへ提供する一方で、ハイパーバイザまたはオペレーティングシステムカーネルをエクソカーネルとして用いて、Ｘコンテナを動作させて分離することができる。

各Ｘコンテナは、例示として、Ｌｉｎｕｘ（登録商標）カーネルに基づいて、専用の、かつおそらくカスタマイズされたＬｉｂＯＳによってアプリケーションをホストする。Ｘコンテナは、１つ以上のユーザプロセスをサポートすることができ、１つ以上のユーザプロセスが同じ特権レベルのＬｉｂＯＳと共に動作する。異なるプロセスはリソース管理および互換性のためのそれら自体のアドレス空間を相変わらず有するが、しかし、プロセスが並列化のために用いられるという点で、それらは互いからの安全な分離をもはや提供せず、一方でＸコンテナが分離を提供する。

Ｘコンテナアーキテクチャは実行時の間、アプリケーションのバイナリを自動的に最適化して、高コストのシステムコールを非常により低コストのＬｉｂＯＳへの関数コールに書き換えることによって、性能を高める。Ｘコンテナは、ネイティブＤｏｃｋｅｒコンテナと比較して生のシステムコールスループットが大幅に高く、他のベンチマークに対するネイティブコンテナと競合するかまたはより優れている。

Ｘコンテナアーキテクチャは、コンテナおよびサーバレスサービスのために特化されたアーキテクチャも上回る。例えば、Ｘコンテナ、ＵｎｉｋｅｒｎｅｌおよびＧｒａｐｈｅｎｅ上でＮＧＩＮＸでｗｒｋウェブベンチマークを動作させた。このベンチマークの下で、Ｘコンテナアーキテクチャは、Ｕｎｉｋｅｒｎｅｌに相当する性能と、Ｇｒａｐｈｅｎｅの約２倍のスループットを有する。しかしながら、ＰＨＰおよびＭｙＳＱＬを動作させるときに、ＸコンテナアーキテクチャはＵｎｉｋｅｒｎｅｌより大幅に良好な性能を示す。

Ｘコンテナアーキテクチャがいくつかの実施形態ではＬｉｎｕｘ（登録商標）のソフトウェアベースの多くを利用する一方で、設計および実装は様々な課題に対処しなければならない。例示の実施形態は、複数の別個の例示の設計を含む。第１の例示の設計において、Ｘｅｎ上でユーザプロセスと一緒にユーザモードでＬｉｎｕｘ（登録商標）カーネルを動作させる。これは、Ｘｅｎハイパーバイザに広範囲な修正を必要とするが、特別なハードウェアサポートを必要としない。実際、この設計は、ベアメタル上で、そして、パブリッククラウドの仮想マシン内部で動作することができる。第２の例示の設計において、Ｌｉｎｕｘ（登録商標）カーネルを利用しているハードウェア仮想化サポートと一緒にカーネルモードでユーザプロセスを動作させる。この設計は、いかなるハイパーバイザ上でも動作することができて、相変わらず確実に異なるコンテナを分離する。いずれの場合においても、Ｌｉｎｕｘ（登録商標）のアーキテクチャ依存的な部分だけしか修正しなくてよい。

Ｘコンテナアーキテクチャは、いくつかの実施形態では、Ｌｉｎｕｘ（登録商標）コンテナと互換性があり、拮抗するかより優れた性能および分離をネイティブＤｏｃｋｅｒコンテナならびに他のＬｉｂＯＳデザインに提供する、エクソカーネルベースのコンテナアーキテクチャを含む。さらに、このアーキテクチャは、互換性、ポータビリティまたは性能を犠牲にすることなくコンテナの安全な分離をサポートする。

本明細書において開示されるＸコンテナを使用して、ソフトウェアコンポーネントをパッケージ化して配信することができ、そしてサーバレスおよびマイクロサービスアーキテクチャの基本的なビルディングブロックとして、開発者がアプリケーションをその依存関係と共に１つのコンテナで出荷してそれが次にパブリックならびにプライベートクラウドのどこででも動作させられるという点での、ポータビリティなどの利点と、コンテナが仮想マシンと比較して無視できるほどのオーバーヘッドで数ミリ秒で起動できるという点での性能と、を提供することができる。多種多様な他の使用事例が、他の実施形態のＸコンテナによってサポートされる。

例示の実施形態のＸコンテナが従来のアプローチに対して著しい利点を提供することは、上記のことから明らかである。例えば、Ｘコンテナは、従来のアプローチに対して大幅に改善した性能および分離を有するライブラリＯＳに基づいて、新規なセキュリティモデルを提供する。同じライブラリＯＳを共有している複数のプロセスがサポートされ、大きいクラスのコンテナにとって重要な特徴である。このアプローチにより、Ｌｉｎｕｘ（登録商標）カーネル自体をライブラリＯＳ変換して、１００％の互換性を提供する。例示の実施形態は、システムコールを最初の時だけリダイレクトして、それから自動的にそれらを関数コールに変換して、以降の実行を最適化する。例示の実施形態は、既存の変更されていないコンテナを実行することを可能にすると共に、性能のためにバイナリ自動的に最適化もする。さらに、このような実施形態は、攻撃対象領域およびＴＣＢが著しく減少しており、したがって、より大幅に安全である。多種多様な異なる実装が可能であり、ハードウェア仮想化サポートのない実施形態を含む。

本明細書において開示される上記のこれらおよび他の例示の実施形態の態様は、例としてのみ示されており、いかなる形であれ限定するものとして解釈されるべきではない。

例示の実施形態の動作に関する追加の詳細は、ここで図４〜図１２を参照して記載される。

複数ユーザおよびプロセスをサポートする最新のＯＳは、プロセスがカーネルの完全性を損なうこともできないし、カーネルに保持されている秘密情報を読み込むこともできないことを保証する、カーネル分離、および、１つのプロセスが容易にもう一方にアクセスすることができず、または損なうことができないことを保証する、プロセス分離を含む、様々なタイプの分離をサポートする。

カーネル分離をセキュアにするためのコストは著しいものであり得る。カーネルコードにアクセスするシステムコールは、ライブラリへの関数コールより桁違いに遅い。さらに、しばしば、データコピーは、カーネルとユーザモードコードとの間のデータの依存性を排除するために、入出力（Ｉ／Ｏ）スタックで実行される。一方、ますます多くの機能性をＯＳカーネルに押し込む傾向があって、カーネルへの攻撃に対して防御するのはますます難しくなっている。Ｌｉｎｕｘ（登録商標）などの最新のモノリシックＯＳカーネルは、複雑なサービス、デバイスドライバおよびシステムコールインタフェースを有する巨大なコードベースになっている。このような複雑なシステムのセキュリティを検証することは実際的ではなく、新規な脆弱性が絶えず発見されている。

プロセス分離は、同じように問題を含む。一例として、この種の分離は、それがどのように実装されて実施されるかにより、通常はカーネル分離に依存する。しかし、おそらくさらに重要なことに、プロセスは、単にセキュリティ分離だけを目的としない。それらは主にリソース共有および並列化サポートのために使われて、この最新のＯＳが、共有メモリ、共有ファイルシステム、シグナリング、ユーザグループおよびデバッグフックを含む、分離を越えるインタフェースを提供するのをサポートする。これらのメカニズムは大きい攻撃対象領域を露出させ、それはセキュリティ分離のためのプロセスに依存するアプリケーションに多くの脆弱性を生じさせる。

例えば、Ａｐａｃｈｅウェブサーバは、同じユーザＩＤを有する子プロセスを生み出す。危殆化されたプロセスは、デバッグインタフェース（ｐｔｒａｃｅなど）またはｐｒｏｃファイルシステムに影響を及ぼすことによって、他のプロセスのメモリに容易にアクセスすることができる。注意深い構成無しでは、危殆化されたプロセスはまた、共有ファイルシステムにアクセスして、構成ファイルまたはデータベースからさえ情報を盗む可能性がある。最終的には、ハッカーがカーネルを危殆化することなく大部分のプロセス分離メカニズムを破るようにルート特権を得ることを可能にし得る、特権拡大攻撃が存在する。

実際、ほとんどの既存のマルチクライアントアプリケーションは、相互の信頼できないクライアントを分離するプロセスに依存せず、特に、それらはプロセスを各クライアントに専用としない。全くプロセスさえ使用しないものも多い。例えば、ＮＧＩＮＸウェブサーバ、Ａｐａｃｈｅ Ｔｏｍｃａｔ、ＭｙＳＱＬおよびＭｏｎｇｏＤＢなどの人気のプロダクションシステムは、マルチプロセッシングの代わりにイベント駆動モデルまたはマルチスレッディングを使用する。Ａｐａｃｈｅウェブサーバなどのマルチプロセスアプリケーションはセキュリティではなく並列化のためにプロセスプールを使用し、その結果、各プロセスは複数スレッドを有して、異なるクライアントにサービスするために再利用することができる。これらのアプリケーションはアプリケーションロジックでクライアント分離を実行し、役割ベースのアクセス制御、認証および暗号化などのメカニズムを活用する。

しかしながら、例外がある。ＳＳＨデーモンはプロセス分離に依存して、異なるユーザを分離する。また、同じカーネル上の同じＭｙＳＱＬデーモンを使用する複数のアプリケーションがある場合、各アプリケーションがＭｙＳＱＬに対する異なるクライアントのような態度をとるという点で、いくつかのアプリケーションが危殆化する場合に備えて、ＭｙＳＱＬに組み込まれるプロセス分離およびクライアント分離の組合せはアプリケーションにセキュリティを提供する。

本明細書において開示される例示の実施形態は、分離境界を再考することを必要とし、そのことは以下で図４を参照して説明される。

プロセスはリソース管理および並列化に役立つが、理想的にはセキュリティ分離はプロセスモデルから切り離されなければならない。実際、他の分離メカニズムが導入された。

図４は、様々な他のアーキテクチャの分離境界を例示する。各コンテナがそのカーネルのそれ自身のインスタンス生成であると見えるように、コンテナ分離はカーネル上で名前空間を切り離す。しかしながら、用いられる技術は、コンテナで達成されることができるいかなる分離もコンテナ無しで達成することができるという点で、プロセス分離と基本的に同じである。それは、カーネルが、多くの利用可能なシステムコールのために大きい攻撃対象領域を有する大きくかつ脆弱なＴＣＢであるという問題を解決しない。

セキュリティ観点から、それぞれ独自の専用のカーネルを有する個々の仮想マシン（ＶＭ）においてコンテナを実行することは、可能なソリューションである。ＴＣＢはここで、非常に小さい攻撃対象領域を有する比較的小さいハイパーバイザから成る。残念なことに、冗長なリソース消費および分離境界のため、オーバーヘッドは大きい。それにもかかわらず、これは現在、マルチテナントコンテナクラウドのためのデファクトのソリューションである。このソリューションの高いコストを取扱うために、より多くの実験システム（例えばＵｎｉｋｅｒｎｅｌ、ＥｂｂＲＴ、ＯＳｖおよびＤｕｎｅ）は、ＶＭ内部で動作するように設計された軽量ＯＳカーネルの選択肢である。残念なことに、これらは、バイナリレベルでの互換性の欠如のため、既存のアプリケーションを十分にサポートしない。また、通常、それらは、単一プロセスアプリケーションしかサポートすることができない。

マイクロカーネルアーキテクチャにおいて、大部分の従来のＯＳサービスは、アプリケーションプロセスと一緒に別々のユーザプロセスで動作する。このようなアーキテクチャは、バイナリ互換性を提供することができる。しかしながら、異なるアプリケーションがそれらのＯＳサービスを共有するので、危殆化されたＯＳサービスはアプリケーションの間の分離を崩し、その結果、ＴＣＢおよび攻撃対象領域が減少しない。また、システムコールオーバーヘッドは、大きい傾向がある。

本明細書の例示の実施形態のＸコンテナアーキテクチャは、アプリケーションの間のセキュリティ分離に改良されたパラダイムを提供する。例えば、アーキテクチャは、いくつかの実施形態では、カーネル攻撃対象領域が小さくシステムコールオーバーヘッドが低いエクソカーネルアーキテクチャに基づく。個々のＸコンテナは、例えば、リソース管理および並列化のために複数のプロセスを有することができるが、個々のＸコンテナの中のそれらのプロセスは互いに分離されていない。その代わりに、ユーザおよび／またはアプリケーションは、異なるユーザおよび／またはアプリケーションのための別々のＸコンテナを生み出すことによって、互いから分離される。Ｘコンテナの中での分離を無くすことによって、システムコールオーバーヘッドを関数コールのオーバーヘッドにまで低減することができる。

上記のように、例示の実施形態のＸコンテナは、完全なバイナリ互換性を有する標準ＯＳカーネルに基づいて、Ｘ−ＬｉｂＯＳを使用する。いくつかの実装において、Ｘ−ＬｉｂＯＳは、Ｌｉｎｕｘ（登録商標）に由来して、Ｌｉｎｕｘ（登録商標）のアーキテクチャ依存的な部分の変更を必要とするだけである。標準カーネルを使用する利点は多数ある。例えば、Ｌｉｎｕｘ（登録商標）は、非常に最適化され、そして、成熟しており、活発なコミュニティによって開発されている。Ｘコンテナは、完全にこのような利点を活用するが、分離については非常に小さいＸカーネルに依存している。いくつかの実装において、Ｘカーネルは、Ｘｅｎに由来する。

前述のように、異なるアプリケーションは、異なるＸコンテナに置かれなければならない。図５は、それぞれがＭｙＳＱＬデータベースを使用する２つのアプリケーションを含んでいる例示の実施形態の状況でこれを示す。図５は、図５（ａ）、図５（ｂ）および図５（ｃ）で示す３つの部分を含む。

１つのオプションは、図５（ａ）にて示すように、アプリケーションごとのＸコンテナに加えて、ＭｙＳＱＬ専用の第３のＸコンテナを作成することである。すなわち、このオプションは、ＭｙＳＱＬをそれ自身の分離したアプリケーションとみなす。ＭｙＳＱＬはアクセス制御ロジックを内部に含んで、確実に２つのアプリケーションのテーブルを分離する。

より安全な構成は、ＭｙＳＱＬの２つのインスタンスを作成し、アプリケーションごとに１つとし、それぞれがそれ自身のＸコンテナで動作し、結果として、図５（ｂ）にて示すように、合計４つのＸコンテナになる。これは、ＭｙＳＱＬ実装の中でアクセス制御ロジックに対する依存を取り除き、したがって厳密に構成のセキュリティを増大させる。加えて、このオプションは、ＭｙＳＱＬサーバおよびそれらをサポートするオペレーティングシステムカーネルの両方のより良好なカスタマイズ可能性を提供する。

しかしながら、図５（ｂ）の各アプリケーションがどのようにそれ自身のＭｙＳＱＬインスタンスを有するかについて留意する。各アプリケーションは、永続的にそのデータを格納して正しくクエリに応答するために、そのＭｙＳＱＬインスタンスに依存するが、逆に言えば、各ＭｙＳＱＬインスタンスは専用であり、それ自身のアプリケーションによって危殆化されて失うものはない。したがって、図５（ｃ）に示すように、２つのＸコンテナだけを安全に配備することができ、それぞれがその専用のＭｙＳＱＬインスタンスとともにアプリケーションロジックを含んでいる。このオプションは、それぞれ図５（ａ）および図５（ｂ）に示される３つまたは４つのＸコンテナ構成よりも著しく良好な性能を提供する。

Ｘコンテナまたは一般にコンテナ上で動作するアプリケーションについては、外部および内部の２種類の脅威が考えられ、そしてこれらは、おそらく結託することができる。１つのタイプの外部の脅威は、アプリケーションロジックを損なうように設計されたメッセージによってもたらされる。この脅威は、アプリケーションおよびオペレーティングシステム論理によって対処されて、標準コンテナおよびＸコンテナで同一である。別のタイプの外部の脅威は、コンテナの分離バリアを突破しようとすることができる。標準コンテナの場合、この分離バリアは基盤となる汎用オペレーティングシステムカーネルによって提供されており、それは大きいＴＣＢおよび、多数のシステムコールに起因する大きい攻撃対象領域を有する。Ｘコンテナは、これとは対照的に、例示の実施形態の分離では、分離を提供することを専門とする比較的小さいＸカーネルに依存する。それは、比較的保証するのが容易である小さいＴＣＢおよび少数のハイパーバイザコールを有する。Ｘコンテナが標準コンテナ外部の脅威に厳密により良好な保護を提供すると信じられる。

内部脅威は、サードパーティライブラリに依存しているアプリケーションによって作られるか、または、上記のＭｙＳＱＬの例で示すように、同じコンテナの中で展開されるサードパーティサービスによって作られる。Ｌｉｎｕｘ（登録商標）コンテナにおいて、アプリケーションは、異なるユーザアカウントによって所有されるプロセスの間の分離を実行するのをＬｉｎｕｘ（登録商標）にまかせる。Ｘコンテナは、同じコンテナのプロセスの間の安全な分離を明示的に提供しない。プロセスの間の安全な分離バリアに依存するアプリケーションは、競合するプロセスが異なるＸコンテナで動作するように、標準ＶＭおよびＬｉｎｕｘ（登録商標）ソリューションを使用するかまたはアプリケーションを再編成しなければならない。後者は、より堅固なセキュリティを提供するが、より多くの実装努力を必要とする。

Ｘコンテナの例示の実施形態の追加の設計および実装の詳細を、ここで説明する。

理想的には、コンテナは、アプリケーションを実行するための安全かつ自己内蔵型の環境を提供しなければならない。以下は、アプリケーションコンテナを安全に実行するためのアーキテクチャを設計する鍵となる原則である。

１． 自給自足性およびカスタマイズ可能性：コンテナは、アプリケーションのすべての依存性を含まなければならない。これは、ライブラリ、ファイルシステムのレイアウトおよびサードパーティツールだけでなく、ＯＳカーネルも含む。コンテナは、カスタマイズされたＯＳカーネルを使用してそれ自身のカーネルモジュールをロードしなければならない。

２． 互換性：コンテナプラットフォームは、理想的にはアプリケーションの変更を必要とするべきでない。バイナリレベル互換性は、ユーザが、それらのアプリケーションを書きかえるかまたは再コンパイルすることさえなくただちにコンテナを配備することを可能にする。

３． 小さいＴＣＢによる分離：コンテナは、互いに確実に分離されなければならない。特権ソフトウェアを共有して共有物理リソースにアクセスすることが必要であるが、そのソフトウェアは信頼されており、かつ小さくなければならない。

４． ポータビリティ：コンテナのキーとなる利点はそれらが一度パッケージ化されて、それから、ベアメタルマシンおよび仮想化されたクラウド環境を含む至る所で動作することができるということである。

５． スケーラビリティおよび効率：アプリケーションコンテナは、軽量で、かつ小さなオーバーヘッドで実行されなければならない。

本明細書において開示されるＸコンテナのいくつかの実装においては、ハイパーバイザを使用してＸカーネルとして役割を果たし、Ｌｉｎｕｘ（登録商標）カーネル配布を、それがアプリケーションと同じ特権モードで動作することを可能にするＸ−ＬｉｂＯＳインスタンスに修正する。より具体的に以下の２つの例示の実装を解説する。

１． ユーザモードでＸ−ＬｉｂＯＳおよびアプリケーションを動作させる、準仮想化された（ＰＶ）Ｘコンテナ。このような実装は、例示として、（カーネルモードで動作する）ハイパーバイザの修正を必要とするが、それは特別なハードウェアサポートを必要とせず、ベアメタルマシンにならびにパブリッククラウドのＶＭにおいて配備することができる。

２． カーネルモードでＸ−ＬｉｂＯＳおよびアプリケーションを動作させる、ハードウェアアシスト型仮想化（ＨＶ）Ｘコンテナ。このような実装は、例示として、ハードウェア仮想化サポートを必要とするが、変更されていないハイパーバイザと連携する。

上記の第１の実装例については、Ｘカーネル実装をＸｅｎに基づくものとした。Ｘｅｎはオープンソースであり、Ｌｉｎｕｘ（登録商標）におけるその準仮想化インタフェースのサポートは成熟している。第２の実装例については、Ｘカーネルとしてハードウェア仮想化とともに変更されていないＸｅｎを使用するが、他のハイパーバイザも同様に使うことができる。例えば、Ｇｏｏｇｌｅ Ｃｏｍｐｕｔｅ ＥｎｇｉｎｅのＫＶＭ上でＨＶ Ｘコンテナを動作させた。

両方の実装例は、有益な特徴を提供する。第１の実装は、Ｘコンテナが管理される方法のより大きな制御を可能にする。例えば、それにより、同じＶＭにおいて確実に互いから分離された複数のＸコンテナを実行することが可能になる。単一の高性能ＶＭ上で複数のＸコンテナを動作させることがより良好に実行され、それ自身の、より小さいＶＭにおいて各Ｘコンテナを動作させるよりも費用効果が良い。また、Ｘｅｎ ＶＭ管理機能性、例えばライブマイグレーション、コンソリデーションおよびメモリバルーニングは、付加的なボーナスとしてＰＶ Ｘコンテナのためにサポートされ、これらは、従来のＬｉｎｕｘ（登録商標）コンテナにおいては十分にサポートされてない機能である。

ハードウェア仮想化が利用できるときに、第２の実装はより良好な性能を有する傾向がある。しかしながら、仮想化された環境では、入れ子ハードウェア仮想化がサポートされない限り、ＨＶ Ｘコンテナは全部のＶＭを引き継ぐことを必要とする。パブリッククラウドのＶＭは、一般に入れ子ハードウェア仮想化を露出させない。

本明細書において記載されている実験のために、Ｌｉｎｕｘ（登録商標）カーネル４．４．４４からＸ−ＬｉｂＯＳの両方のバージョンを得た。カーネルに対する修正は、アーキテクチャ依存的な層の中にあり、カーネルの他の層に対して透過的である。ｘ８６−６４ロングモードで動作しているアプリケーションに焦点を当てた。

Ｌｉｎｕｘ（登録商標）を使用することによってバイナリ互換性が与えられるが、加えて、Ｌｉｎｕｘ（登録商標）カーネルも高度にカスタマイズ可能である。それは、何百ものブートパラメータ、何千ものコンパイル構成および多くのきめ細かいランタイム調整ノブを備えている。大部分のカーネル機能がカーネルモジュールとして構成されて、実行時の間にロードすることができるので、カスタマイズされたＬｉｎｕｘ（登録商標）カーネルは高度に最適化することができる。例えば、多くのイベント駆動アプリケーションなどの単一スレッドを動作させるアプリケーションに対して、マルチコアおよび対称型マルチプロセシング（Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ、ＳＭＰ）サポートを無効にすることによって、不必要なロッキングおよび変換ルックアサイドバッファ（ＴＬＢ）のシュートダウンを排除することができ、それは性能を大幅に高める。作業負荷に応じて、アプリケーションは、異なるスケジューリングポリシーを有するＬｉｎｕｘ（登録商標）スケジューラを構成することができる。多くのアプリケーションに対して、Ｌｉｎｕｘ（登録商標）カーネルのポテンシャルは、カーネル構成の管理欠如かまたは他のアプリケーションとカーネルを共有しなければないことに起因して、完全には利用されていなかった。Ｌｉｎｕｘ（登録商標）カーネルをＬｉｂＯＳに変えて、それを単一のアプリケーション専用にすることによって、すべてのこの種のポテンシャルを解き放つことができる。

上記のＰＶ Ｘコンテナの例示の実施形態を、ここで詳細に説明する。Ｘｅｎ準仮想化（ＰＶ）アーキテクチャに基づいて、ＰＶ Ｘコンテナを実装した。ＰＶアーキテクチャはハードウェアアシスト型仮想化のためのサポート無しに同じ物理マシン上の複数の同時並行Ｌｉｎｕｘ（登録商標） ＶＭ（例えば、ＰＶゲストまたはＤｏｍａｉｎ−Ｕ）の実行を可能にするが、ゲストカーネルは基盤となるハイパーバイザと連携するため適度の変更を必要とする。以下において、ＸｅｎのＰＶアーキテクチャの鍵となる技術およびｘ８６−６４プラットフォーム上でのその制約を検討する。

ＰＶアーキテクチャにおいて、Ｘｅｎは最高特権モード（カーネルモード）で動作して、ゲストカーネルおよびユーザプロセスは両方ともより少ない特権で動作する。新規のページテーブルのインストールおよびセグメントセレクタの変更などの、セキュリティ分離に影響を及ぼし得るすべての機密性の高いシステム命令は、Ｘｅｎによって実行される。ゲストカーネルはハイパーコールを実行することによってそれらのサービスを要求し、それはサービスが行われる前にＸｅｎによって有効性確認される。例外および割込みは、効率的なイベントチャネルを通して仮想化される。

デバイスＩ／Ｏについては、ハードウェアをエミュレーションする代わりに、Ｘｅｎは、より単純な分割ドライバモデルを定める。ハードウェアデバイスにアクセスしてデバイスを多重化する特権ドメイン（通常は、Ｄｏｍａｉｎ−０、つまり、ブート中にＸｅｎによって作られるホストドメイン）があるので、それが他のＤｏｍａｉｎ−Ｕによって共有できる。Ｄｏｍａｉｎ−Ｕはフロントエンドのドライバをインストールして、それはＸｅｎのイベントチャネルを通してＤｏｍａｉｎ−０の対応するバックエンドドライバに接続され、データは共有メモリ（非同期バッファ記述子リング）を用いて転送される。

ＸｅｎのＰＶインタフェースは、それがｘ８６−３２プラットフォーム上の最も効率的な仮想化技術の１つであったので、主流のＬｉｎｕｘ（登録商標）カーネルによって広くサポートされている。メモリセグメンテーション保護のための４つの異なる特権レベル（リング−０からリング−３）があるので、分離のための異なる特権レベルでＸｅｎ、ゲストカーネルおよびユーザプロセスを動作させることができる。システムコールは、Ｘｅｎの関与無しで実行することができる。しかしながら、ＰＶアーキテクチャは、ｘ８６−６４プラットフォーム上の基本的な課題に直面する。ｘ８６−６４ロングモードのセグメント保護の削除のため、ゲストカーネルおよびユーザプロセスは両方ともユーザモードでしか動作させることができない。ゲストカーネルをユーザプロセスから保護するために、ゲストカーネルは、別のアドレス空間において分離されることが必要である。各システムコールは、仮想例外としてＸｅｎハイパーバイザによって転送することが必要であり、ページテーブルの切替えおよびＴＬＢフラッシュを招く。これは、著しいオーバーヘッドを含んでおり、６４ビットＬｉｎｕｘ（登録商標） ＶＭが、ハードウェア仮想化において今日準仮想化の代わりに完全に仮想化して動作するのを好む、主要な理由の１つとなっている。

ＰＶ Ｘコンテナのカーネル分離の削除に関する態様をここで説明する。

ＰＶ Ｘコンテナアーキテクチャは、Ｘｅｎ ＰＶアーキテクチャと類似しており、１つの鍵となる違いは、ゲストカーネル（すなわち、Ｘ−ＬｉｂＯＳ）がユーザプロセスから分離されていないということである。その代わりに、それらは同じセグメントセレクタおよびページテーブル特権レベルを使用し、そのため、カーネルアクセスが（ゲスト）ユーザモードと（ゲスト）カーネルモードの間の切替えをもはや必要とせず、システムコールは関数コールによって実行することができる。

これが複雑化を引き起こし、Ｘｅｎは、正しいｓｙｓｃａｌｌ転送および割込み伝達のために、ＣＰＵがゲストユーザモードにあるのかゲストカーネルモードにあるのかを知っていることを必要とする。Ｘｅｎは、すべてのユーザ−カーネルモードスイッチがＸｅｎによって扱われるのでそれが維持することができるフラグを用いて、これを行う。しかしながら、Ｘ−ＬｉｂＯＳでは、本明細書において記載されているような軽量システムコールおよび割込み処理によって、ゲストユーザ−カーネルモードスイッチはもはやＸカーネルを含まない。その代わりに、Ｘカーネルは、現在のスタックポインタの位置をチェックすることによって、ＣＰＵがカーネルまたはプロセスコードを実行しているかどうか判定する。通常のＬｉｎｕｘ（登録商標）メモリレイアウトのように、Ｘ−ＬｉｂＯＳは、仮想メモリアドレス空間の上半分にマップされて、すべてのプロセスによって共有される。ユーザプロセスメモリは、アドレス空間の下半分にマップされる。したがって、スタックポインタの最上位ビットは、それがゲストカーネルモードにあるかゲストユーザモードにあるかを指し示す。

準仮想化されたＬｉｎｕｘ（登録商標）では、ページテーブルの「グローバルな」ビットは無効にされるので、異なるアドレス空間の間の切替えが完全なＴＬＢフラッシュを引き起こす。これはＸ−ＬｉｂＯＳには必要とされず、したがって、Ｘ−ＬｉｂＯＳおよびＸカーネルのためのマッピングは、ページテーブルでセットされるグローバルビットを両方とも有する。同じＸ−ＬｉｂＯＳ上で動作している異なるプロセス間の切替は完全なＴＬＢフラッシュを必要とせず、それがアドレス変換の性能を非常に高める。異なるＸコンテナ間のコンテクスト切替えは、完全なＴＬＢフラッシュを起動する。

カーネルコードがもはや保護されていないので、１つのプロセスしかない場合には、カーネルルーチンは専用のスタックを必要としないことになる。しかしながら、Ｘ−ＬｉｂＯＳは、複数のプロセスをサポートする。したがって、まだカーネルの局面では専用のカーネルスタックを必要とし、システムコールを実行するときに、ユーザスタックからカーネルスタックへの切替えが必要である。

ＰＶ Ｘコンテナの軽量割込み処理に関する態様をここで説明する。

Ｘｅｎ ＰＶアーキテクチャにおいて、割込みは、非同期イベントとして伝達される。Ｘｅｎおよびゲストカーネルによって共有される、保留中のイベントが存在するかどうかについて指し示す変数がある。存在する場合には、ゲストカーネルはＸｅｎにハイパーコールを出して、それらのイベントを伝達させる。Ｘコンテナアーキテクチャにおいて、Ｘ−ＬｉｂＯＳは、何らかの保留イベントを見つけると割込みスタックフレームをエミュレーションして、最初にＸカーネルにトラッピングすることなく割込みハンドラに直接ジャンプすることが可能である。

割込みハンドラから戻るために、ｉｒｅｔ命令を用いて、コードおよびスタックセグメント、スタックポインタ、フラグおよび命令ポインタを一緒にリセットする。割込みも、アトミックに有効にされなければならない。しかし、Ｘｅｎ ＰＶアーキテクチャでは仮想割込みはメモリロケーションに書くことによってしか有効にすることができず、それは他の操作によってアトミックに実行することができない。特権レベルを切り替えるときにアトミック性およびセキュリティを保証するために、Ｘｅｎは、ｉｒｅｔを実装するためのハイパーコールを提供する。Ｘコンテナアーキテクチャにおいては、完全にユーザモードでｉｒｅｔを実装することができる。

ユーザモードでｉｒｅｔを実装するときに、２つの課題がある。第１に、すべての汎用レジスタはリターンアドレスへジャンプバックする前に回復しなければならないので、一時的な値、例えばスタックおよび命令ポインタはレジスタの代わりにメモリに保存することしかできない。第２に、ハイパーコールを出さずに、仮想割込みは、他の操作によってアトミックに有効にすることができない。したがって、メモリに保存された一時的な値を操作しているコードは、リエントラント性をサポートしなければならない。

考察すべき２つのケースがある。カーネルモードスタック上で動作している場所に戻るときには、Ｘ−ＬｉｂＯＳは一時レジスタをリターンアドレスを含む行き先スタックにプッシュして、割込み許可の前にスタックポインタを切り替えるので、先取りが安全であると保証される。それから、コードは、単なるｒｅｔ命令を用いてリターンアドレスへジャンプする。ユーザモードスタックに戻るときには、ユーザモードスタックポインタは有効でないかもしれないので、Ｘ−ＬｉｂＯＳはシステムコール処理のためにカーネルスタックに一時的な値を保存して、割込みを有効にして、それから、ｉｒｅｔ命令を実行する。ｉｒｅｔと同様で、システムコールハンドラから戻るために使われるｓｙｓｒｅｔ命令は、カーネルモードにトラッピング無しで最適化される。ｓｙｓｒｅｔは、それが特定の一時レジスタを活用することができるので、実装するのがより容易である。

上記のＨＶ Ｘコンテナの例示の実施形態を、ここでさらに詳細に説明する。上記で説明したＰＶ Ｘコンテナの大多数は、ページテーブル操作およびコンテクスト切替えを含むすべての機密性が高いシステム命令を、ハイパーコールを通して実行するためのコストが伴う。ハードウェア仮想化サポートが利用できる場合、ＨＶ Ｘコンテナはこのコストを省く。

ハードウェア仮想化サポートによって、Ｘ−ＬｉｂＯＳはカーネルモードで動作することができて、大部分の特権命令を直接実行することができ、それはページテーブル管理およびコンテクスト切替えの性能を非常に高める。大きな課題は、カーネルモードで同様にユーザプロセスを実行することから生まれる。ユーザプロセスがカーネルモードで動作することができるようにＬｉｎｕｘ（登録商標）カーネルでメモリおよびＣＰＵ管理コンポーネントを修正することに加えて、割込みおよび例外が扱われる方法も変えることが必要である。ＣＰＵがＨＶ Ｘコンテナで直接割込みおよび例外を伝達するので、Ｘカーネルはそれらが扱われる方法を制御しない。ｘ８６プラットフォーム上のデフォルト動作は、カーネルモードの割込みまたは例外があるときに、スタック切替えが起こらないということである。これは割込みハンドラが直接ユーザスタック上で実行することができることを意味し、それはユーザコードおよびカーネルコードにおける基本的な仮定を破り、ユーザスタック上のデータは危殆化されることがあり得て、Ｌｉｎｕｘ（登録商標）カーネルの多くのコードは正しくこのような状況を扱うために変更することが必要となる。

幸いにも、ｘ８６−６４は割込みスタックテーブル（ＩＳＴ）と呼ばれる新規な割込みスタック切替えメカニズムを導入しており、割込みおよび例外時のスタック切替えを強制する。割込み記述子テーブル（ＩＤＴ）にタグを指定することによって、特権レベルが変えられない場合であっても、ＣＰＵは新規なスタックポインタに切り替わる。しかしながら、入れ子割込みはこの場合同じスタックポインタが再利用されるなら、問題になる。この問題を、ＩＳＴにおいて一時スタックポインタを指定することによって解決した。割込みハンドラに入った直後に、スタックフレームを通常のカーネルスタックへコピーするので、同じスタックポインタが入れ子割込みのために使用できる。

ＰＶおよびＨＶ Ｘコンテナの両方での軽量システムコールに関する態様をここで説明する。

ｘ８６−６４アーキテクチャにおいて、ユーザモードプログラムはシステムコールをｓｙｓｃａｌｌ命令を使用して実行し、それは制御をカーネルモードのルーチンへ移す。Ｘカーネルは制御をＸ−ＬｉｂＯＳへ直ちに移し、バイナリ互換を保証するので、既存のアプリケーションがいかなる修正もなくＸ−ＬｉｂＯＳ上で動作することができる。

Ｘ−ＬｉｂＯＳおよびプロセスが両方とも同じ特権レベルで動作するので、直接システムコールハンドラを呼び出すことはより効率的である。しかしながら、ＧＳセグメントの設定から課題が生じる。Ｌｉｎｕｘ（登録商標）カーネルは、ＣＰＵごとの変数をＧＳセグメントに格納する。このセグメントは、あらゆるシステムコールごとにカーネルに入る際にｓｗａｐｇｓ命令によって設定されて、ユーザプログラムに戻る前に再設定される。残念なことに、ｓｗａｐｇｓ命令は、カーネルモードにおいてしか有効でない。セグメンテーションの使用を回避することによって、ＣＰＵごとの変数の配置を変えることができる。しかし、Ｌｉｎｕｘ（登録商標）カーネルに対する変更を最小限に保つために、Ｘ−ＬｉｂＯＳに入るかまたはそれから出るときに、ＧＳセグメント切替えをその代わりに無効にして、常にＧＳセグメントを有効に保つ。ｘ８６−６４アプリケーションがスレッドローカルストレージ用のＦＳセグメントを使用するかもしれないが、ＧＳセグメントは通常影響されない。カスタマイズされたＧＳセグメントを必要とするいかなるアプリケーションもまだ現れていない。

別の課題が、軽量システムコールを有効にするメカニズムから生じる。Ｘ−ＬｉｂＯＳはシステムコールエントリテーブルをｖｓｙｓｃａｌｌページに格納し、それはプロセスごとで固定仮想メモリアドレスにマップされる。Ｘ−ＬｉｂＯＳを更新することは、システムコールエントリテーブルの位置に影響を及ぼさない。このエントリテーブルを使用して、アプリケーションは、ほとんどの既存のＬｉｂＯＳｓが行うように、ソースコードをパッチしてシステムコールを関数コールに変えることによってＸコンテナのためのそれらのライブラリおよびバイナリを最適化することができる。しかし、それによって配備の複雑さが著しく増加し、そしてそれは、利用可能なソースコードを有しないサードパーティツールおよびライブラリを処理することができない。アプリケーションを書き換えるかまたは再コンパイルすることを回避するために、ＰＶ Ｘコンテナ用のＸカーネルに、そして、ＨＶ ＸコンテナのためのＸ−ＬｉｂＯＳに、オンラインの自動最適化モジュール（Ａｕｔｏｍａｔｉｃ Ｂｉｎａｒｙ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｍｏｄｕｌｅ、ＡＢＯＭ）を実装した。それは、自動的に即座にｓｙｓｃａｌｌ命令を関数コールに置き換える。所定場所でのバイナリ置換のための多くの課題がある。

１． バイナリレベルの等価性：パッチされた命令の全長は変えることができず、アプリケーションコードがパッチされたブロックの途中にジャンプするときでも、プログラムは正確に同じ機能を実行しなければならない。

２． 位置独立性：ｇｌｉｂｃなどのライブラリが異なるプロセスのために異なる位置にロードされるので、相対アドレス変位の代わりにメモリまたはレジスタに格納された絶対アドレスをコールすることしかできない。

３． 最小限の性能への影響：アプリケーションをロードするとき、または、実行時の間に、バイナリ全体をスキャンすることは実際的ではない。

４． 読取り専用ページ処理：大部分のバイナリコードは、メモリにおいて読取り専用でマップされている。バイナリ置換はＸ−ＬｉｂＯＳのコピーオンライトメカニズムを起動させることができず、そうでなければ、場合によっては、同じメモリページの多くのコピーが異なるプロセスに対して作成され得るかもしれない。

５． 並列化安全性：コードの同じ部分は、異なるスレッドまたはプロセスを実行している複数のＣＰＵによって共有され得る。置換は、他のＣＰＵに影響を及ぼしたり停止させたりせずに、アトミックに行わなければならない。

６． スワッピング安全性：メモリスワッピングは、置換の間に起こることがあり得る。システムは、メモリを危殆化するか、または大きな性能オーバーヘッドを引き起こすことなく、それを正しく検出して処理することができなくてはならない。

ＡＢＯＭは、ユーザプロセスからｓｙｓｃａｌｌ要求を受け取ると、即座にバイナリ置換を実行して、バイナリファイル全体をスキャンすることを回避する。ｓｙｓｃａｌｌ要求を転送する前に、ＡＢＯＭは、ｓｙｓｃａｌｌ命令周辺でバイナリをチェックして、それが認識するパターンと一致するかどうかを見る。もし一致するならば、ＡＢＯＭは一時的にＣＲ−０レジスタの書込み保護ビットを無効にして、そのため、カーネルモードで動作しているコードは、あらゆるメモリページを、それがページテーブルにおいて読取り専用でマップされている場合であっても、変更することができる。それから、ＡＢＯＭは、アトミックなｃｍｐｘｃｈｇ命令によってバイナリパッチを実行する。各ｃｍｐｘｃｈｇ命令が処理できるのは多くても８バイトであるので、８バイトを超えて修正することを必要とする場合、バイナリのいかなる中間状態も並列化安全性のために相変わらず有効なことを確認することが必要である。パッチはＸ−ＬｉｂＯＳに対して大部分透過的であるが、ページテーブルのダーティビットが読取り専用ページに設定されることは除く。Ｘ−ＬｉｂＯＳは、同じパッチが将来必要でないように、それらのダーティページを無視するか、またはディスクにそれらをフラッシュすることのいずれかを選択することができる。

より大きい問題は、スワッピング安全性を処理することである。特にＰＶ Ｘコンテナでは、メモリスワッピングの決定がＸ−ＬｉｂＯＳによりなされるが、すべてのページテーブル操作はＸカーネルのハイパーコールを通して行われる。Ｘカーネルはページテーブルをロックしてバイナリ置換の間、スワッピングを防止することができるが、これによってより大きな性能オーバーヘッドが生じることがあり得る。結局以下の通りにバイナリ置換を実行することになった。バイナリ置換はシステムコールの場面で動作するので、対象ページが置換の直前にスワップアウトされる場合、ページへ書き込むことはページフォルトを起動させる。ＡＢＯＭは、このページフォルトをキャプチャして、システムコールを、Ｘ−ＬｉｂＯＳのページフォルトハンドラにそれを伝播することなく転送し続ける。ＡＢＯＭは、それが次に実行されるときに、同じ位置をパッチしようとする。

図６は、ＡＢＯＭが認識するバイナリコードの３つのパターンを例示する。システムコールを実行するために、プログラムは、通常システムコール番号をｍｏｖ命令でｒａｘまたはｅａｘレジスタにセットして、それから、ｓｙｓｃａｌｌ命令を実行する。ｓｙｓｃａｌｌ命令は２バイトで、ｍｏｖ命令はオペランドのサイズにより５または７バイトである。絶対アドレスをメモリに格納した単一のコール命令にこれらの２つの命令を置き換え、それは７バイトで実装することができる。エントリポイントのメモリアドレスは、ｖｓｙｓｃａｌｌページに格納されたシステムコールエントリテーブルから読み出される。バイナリ置換は、各場所につき一回、実行されることを必要とするだけである。

７バイト置換によって、２つの命令を１つにマージする。プログラムが、ｒａｘレジスタを他の場所にセットした後か、または割込みの後に、直接元のｓｙｓｃａｌｌ命令の位置へジャンプするというまれな場合がある。置換の後、これによってコール命令の最後の２バイトへのジャンプが生じ、それは常に「０ｘ６０ ０ｘｆｆ」である。これらの２バイトによって、Ｘカーネル（ＰＶ）またはＸ−ＬｉｂＯＳ（ＨＶ）への無効なオペコードトラップが生じる。バイナリレベルの等価性を提供するために、Ｘカーネル（ＰＶの場合だけ）およびＸ−ＬｉｂＯＳに特別なトラップハンドラを追加して、命令ポインタをコール命令の始まりへ後方に移動することによって、トラップを修正する。これが起動されるのが見られたことがあるのはいくつかのオペレーティングシステムのブート時の間だけである。

図６にて示したように、９バイト置換は、２フェーズで実行され、それらの各１つが元のバイナリに等価の結果を生成する。ｍｏｖ命令が７バイトをとるので、それを直接ｓｙｓｃａｌｌハンドラへのコールに置き換える。プログラムが直接それへジャンプする場合に備えて、元のｓｙｓｃａｌｌ命令を不変のままにすることができる。しかし、それを以前のコール命令へのジャンプでさらに最適化する。Ｘ−ＬｉｂＯＳのｓｙｓｃａｌｌハンドラは、リターンアドレス上の命令がｓｙｓｃａｌｌまたはコール命令に対する特定のジャンプのいずれかであるかどうかを再び調べる。もしそうならば、ｓｙｓｃａｌｌハンドラは、この命令をスキップするためにリターンアドレスを修正する。

オンラインのバイナリ置換ソリューションは、ｓｙｓｃａｌｌ命令がｍｏｖ命令に直ちに続くケースを扱うだけである。より複雑なケースについては、バイナリにいくつかのコードを入れ込んで、より大きいかたまりのコードをリダイレクトすることができる。オフラインでそれを行うためのツールも提供される。ｇｌｉｂｃなどの大部分の標準ライブラリに対しては、デフォルトシステムコールラッパは、図６に示されるパターンを通常使用する。したがって、本実施形態は、クリティカルパス上の大部分のシステムコールラッパを最適化するのに十分である。

ＰＶおよびＨＶ ＸコンテナのＤｏｃｋｅｒイメージの軽量ブートストラッピングに関している態様をここで説明する。

Ｘコンテナは、ＶＭディスクイメージを有しておらず、ＶＭが行う同じブートストラッピングフェーズを経由しない。Ｘコンテナをブートするために、Ｘカーネルは、メモリにＸ−ＬｉｂＯＳに特別なブートローダをロードして、直接Ｘ−ＬｉｂＯＳのエントリポイントへジャンプする。ブートローダは、ＩＰアドレスをセットすることを含めて仮想デバイスを初期化して、そして次に、いかなる不必要なサービスも実行することなくコンテナのプロセスを生み出す。コンテナの第１のプロセスは、必要に応じて追加プロセスをフォークすることができる。加えて、ＨＶ Ｘ−ＬｉｂＯＳには、ＧＮＵ ＧＲａｎｄ Ｕｎｉｆｉｅｄ Ｂｏｏｔｌｏａｄｅｒ（ＧＲＵＢ）によって、基盤となるハイパーバイザの助け無しに特別なブートローダをロードすることもできる。このアプローチは、Ｘコンテナを通常のＶＭより小さくし、かつブートをより高速にする。例えば、６４ＭＢのメモリサイズで３秒以内に単一のｂａｓｈプロセスを有する新規なＵｂｕｎｔｕ−１６ Ｘコンテナを生み出すことが可能である。

Ｘコンテナがバイナリレベル互換性をサポートするので、修正無しでいかなる既存のＤｏｃｋｅｒイメージも動作させることができる。ＸコンテナアーキテクチャをＤｏｃｋｅｒ ＷｒａｐｐｅｒによってＤｏｃｋｅｒプラットフォームに接続する。ホストＸコンテナにおいて動作している変更されていないＤｏｃｋｅｒエンジンを用いて、Ｄｏｃｋｅｒイメージをプルしてビルドする。デバイスマッパーをストレージドライバとして使用し、それはＤｏｃｋｅｒイメージの異なる層をシンプロビジョニングされたコピーオンライトスナップショットデバイスとして格納する。それから、Ｄｏｃｋｅｒ Ｗｒａｐｐｅｒは、Ｄｏｃｋｅｒからメタデータを読み出して、シンブロックデバイスを作成して、それを新規なＸコンテナに接続する。次に、コンテナのプロセスは、専用のＸ−ＬｉｂＯＳによって生み出される。

上記の特定の例示の実施形態の例示の実装は、これらの例示の実施形態の様々な利点を示すために、従来の配置に対して評価された。

図７は、例示の実施形態のこの評価において利用されるソフトウェアスタックの例を示す。この図において、点線ボックスは、ＤｏｃｋｅｒコンテナまたはＸコンテナを示す。実線は、特権レベルの間の分離境界を示す。点線は、ライブラリインタフェースを示す。

評価の一部として、両方のベアメタルマシンおよびパブリッククラウドのＶＭ上で実験を行った。ベアメタル実験に対しては、４台のデルＰｏｗｅｒＥｄｇｅ Ｒ７２０サーバ（２個の２．９ＧＨｚのＩｎｔｅｌ Ｘｅｏｎ Ｅ５−２６９０ ＣＰＵ、１６個のコア、３２個のスレッド、９６ＧＢのメモリ、４ＴＢディスク）を使用し、１つの１０Ｇｂｉｔスイッチに接続した。クラウド環境に対しては、アマゾンＥＣ２ノースヴァージニア領域（ｍ３．ｘｌａｒｇｅインスタンス、２個のＣＰＵコア、４個のスレッド、１５ＧＢのメモリおよび２台の４０ＧＢのＳＳＤストレージ）において４つのＶＭの実験を動作させた。

ベースラインとして、ベアメタル上とアマゾンＨＶマシンの両方でＤｏｃｋｅｒコンテナプラットフォームを動作させた。これらの２つの構成をそれぞれＤｏｃｋｅｒ／ネイティブ／ベアおよびＤｏｃｋｅｒ／ネイティブ／クラウドと呼ぶ。我々は、個々のＸｅｎ ＨＶおよびＰＶ Ｄｏｍａｉｎ−Ｕ ＶＭで動作するＤｏｃｋｅｒコンテナに対して、そして、Ｘコンテナに対して、それらの性能を対比した。これによって、６つの追加構成、Ｄｏｃｋｅｒ／ＨＶ／ベア、Ｄｏｃｋｅｒ／ＰＶ／ベア、Ｘコンテナ／ＨＶ／ベア、Ｘコンテナ／ＰＶ／ベア、Ｘコンテナ／ＨＶ／クラウドおよびＸコンテナ／ＰＶ／クラウドとなった。図７は、これらの構成の様々なソフトウェアスタックを示す。なお、これらの８つの構成の中で、３つはクラウド内で、そして５つはベアメタル上で動作する。

ネイティブＤｏｃｋｅｒを実行するホスト（物理マシンまたはアマゾンＥＣ２インスタンス）は、Ｄｏｃｋｅｒエンジン１７．０３．０−ｃｅおよびＬｉｎｕｘ（登録商標）カーネル４．４．４４によってインストールしたＵｂｕｎｔｕ １６．０４ＬＴＳを有した。Ｘｅｎ ＶＭを実行するホストは、Ｄｏｍａｉｎ−０にインストールされたＣｅｎｔＯＳ−６およびＤｏｃｋｅｒエンジン１７．０３．０−ｃｅ、Ｌｉｎｕｘ（登録商標）カーネル４．４．４４およびＸｅｎ ４．２によるＤｏｍａｉｎ−ＵのＵｂｕｎｔｕ １６．０４−ＬＴＳを有した。Ｘコンテナを実行するホストは、Ｌｉｎｕｘ（登録商標）カーネル４．４．４４に基づくＸ−ＬｉｂＯＳおよびＨｏｓｔ ＸコンテナとしてのＣｅｎｔＯＳ−６を使用した。Ｄｏｃｋｅｒコンテナは、デフォルトのＮＵＭＡ対応Ｌｉｎｕｘ（登録商標）スケジューラを、ＩＲＱ−バランスサービスをオンにして使用した。Ｄｏｍａｉｎ−０およびＨｏｓｔ Ｘコンテナは専用のＣＰＵコアで構成されて、異なるコアに手動でＩＲＱのバランスをとった。他のＶＭまたはＸコンテナは、ＮＵＭＡ配置に従って他のＣＰＵコアに均一に配布された。

実験のセットごとに、同じＤｏｃｋｅｒイメージが使われた。Ｄｏｃｋｅｒエンジンは全て、デバイスマッパーストレージドライバによって構成された。クライアントまたはサーバを含んだネットワークベンチマークを実行するときに、分離されたマシンまたはＶＭが用いられた。

Ｘコンテナで動作しているアプリケーションがＸ−ＬｉｂＯＳを完全に制御するので、それらは単一のスレッド型だけがビジーであるときに、対称型マルチプロセシング（Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ、ＳＭＰ）およびマルチコアサポートを無効にすることができる。この最適化は多くの場合大幅に性能を高めることができ、並列化管理およびＴＬＢシュートダウンを排除することができる。Ｄｏｃｋｅｒコンテナで動作しているアプリケーションは、それがルート特権を必要とするので、この種の最適化をすることができない。続くマイクロベンチマークおよびマクロベンチマークにおいて、単一プロセスおよびマルチプロセステストを行った。単一プロセスケースに対してＸ−ＬｉｂＯＳのＳＭＰサポートを無効にした。

本明細書において記載されている大部分の実験について、５つの動作の平均を報告し、さらに標準偏差を示す。

マイクロベンチマークのセットによってＸコンテナの性能を評価した。Ｕｂｕｎｔｕ１６ Ｄｏｃｋｅｒイメージから始めて、ＵｎｉｘＢｅｎｃｈおよびその中のｉｐｅｒｆを実行した。Ｅｘｅｃｌベンチマークはｅｘｅｃシステムコールの速度を計測するものであり、それは新規なバイナリを現行プロセスの上にオーバレイする。Ｆｉｌｅ Ｃｏｐｙベンチマークは、ファイルのコピーのスループットを異なるバッファサイズでテストする。Ｐｉｐｅ Ｔｈｒｏｕｇｈｐｕｔベンチマークは、パイプにおける読込みおよび書込みのスループットを計測する。ＰｉｐｅベースのＣｏｎｔｅｘｔ Ｓｗｉｔｃｈｉｎｇベンチマークは、パイプで通信している２つのプロセスの速度をテストする。Ｐｒｏｃｅｓｓ Ｃｒｅａｔｉｏｎベンチマークは、ｆｏｒｋシステムコールによって新規なプロセスを生み出すことの性能を測定する。Ｓｙｓｔｅｍ Ｃａｌｌベンチマークは、ｄｕｐ、ｃｌｏｓｅ、ｇｅｔｐｉｄ、ｇｅｔｕｉｄおよびｕｍａｓｋを含む一連のシステムコールを発行する速度をテストする。最後に、ｉｐｅｒｆベンチマークは、ＴＣＰ転送の性能をテストする。同時並行テストについては、ベアメタル実験では４つのコピーを、そしてＥＣ２インスタンスが２つのＣＰＵコアしか持たないので、アマゾンＥＣ２では２つのコピーを実行した。

図８は、上記のマイクロベンチマークに対する様々な図７の構成の相対性能を示す。図８は、図８（ａ）、図８（ｂ）、図８（ｃ）および図８（ｄ）で示される４つの部分を含む。

システムコールを軽量関数コールに変えたので、Ｘコンテナが著しくより高いシステムコールスループットを有することが全般的に分かった。単一プロセスベンチマークについては、ＳＭＰサポートを無効にすることによってＸ−ＬｉｂＯＳを最適化して、その結果、ＸコンテナはＤｏｃｋｅｒを大幅に上回っている。Ｘコンテナ／ＰＶは、プロセス作成およびコンテクストスイッチングにおいて、特にアマゾンＥＣ２などの仮想化された環境のＤｏｃｋｅｒ／ネイティブと比較して、著しいオーバーヘッドを有した。これはプロセス作成およびコンテクストスイッチが多くのページテーブル操作を必要とするのが理由であり、それはＸカーネルで行わねばならない。Ｘコンテナ／ＨＶは、このオーバーヘッドを取り除いて、Ｄｏｃｋｅｒ／ネイティブおよびＤｏｃｋｅｒ／ＨＶ／ベアよりも良好な性能を達成した。Ｄｏｃｋｅｒ／ＨＶ／ベアは、ディスクキャッシングの余分の層があるので、ファイルコピーベンチマークのＤｏｃｋｅｒ／ネイティブ／ベアよりも良好な性能を達成する。

２つのマクロベンチマークによるＸコンテナの性能も評価したが、その評価結果を図９に示す。図９は、図９（ａ）、図９（ｂ）、図９（ｃ）および図９（ｄ）で示される４つの部分を含む。ＮＧＩＮＸウェブサーバスループットに対する評価結果は図９（ａ）および図９（ｂ）に示され、カーネルコンパイル時間に対する評価結果は図９（ｃ）および図９（ｄ）に示される。

ＮＧＩＮＸサーバについては、すべてのプラットフォーム上でＤｏｃｋｅｒイメージＮＧＩＮＸ：１．１１を動作させた。ｗｒｋベンチマークを使用して、ＮＧＩＮＸサーバのスループットを単一および複数のワーカープロセスでテストした。ｗｒｋクライアントは、ＮＧＩＮＸサーバでワーカープロセスごとに１０本のスレッドおよび１００の接続を開始した。ベアメタルマシン上で、ＤｏｃｋｅｒコンテナおよびＸコンテナは、ブリッジされたネットワークを使用したが、直接クライアントに接続することができる。アマゾンＥＣ２上で、それらは、ポート転送によるプライベートネットワークを使用した。なお、Ｘコンテナ／ＨＶ／クラウドがＥＣ２のＨＶＭ全体にとって代わるので、それはポート転送無しにネットワークにアクセスした。カーネルコンパイルテストについては、Ｕｂｕｎｔｕ−１６．０４ Ｄｏｃｋｅｒイメージを使用して、それにコンパイルツールをインストールした。「小さい」構成によって最新の４．１０のＬｉｎｕｘ（登録商標）カーネルをコンパイルした。同時並行テストは、ベアメタル実験で４つの並列ジョブおよびアマゾンＥＣ２実験で２つの並列ジョブを動作させることによって実行される。

図９（ａ）および図９（ｂ）は、ベアメタルマシンおよびアマゾンＥＣ２上で計測されるＮＧＩＮＸウェブサーバスループットを示す。Ｘコンテナは、カーネルカスタマイズおよび低減されたシステムコールオーバーヘッドのため、Ｘｅｎ ＶＭ内部のＤｏｃｋｅｒコンテナより一貫して優れていた。単一のワーカープロセスを実行するときに、Ｘコンテナ／ＰＶ／ベアおよびＸコンテナ／ＨＶ／ベアはＳＭＰサポートを無効にすることによってさらに最適化されて、Ｄｏｃｋｅｒ／ネイティブ／ベアコンテナよりもそれぞれ５％および２３％高いスループットを達成した。ベアメタル上で同時並行ワーカープロセスを実行すると、Ｘコンテナの性能はＤｏｃｋｅｒ／ネイティブ／ベアコンテナと同等だった。アマゾンＥＣ２において、Ｘコンテナ／ＨＶ／クラウドは、それがＨＶＭ全体にとって代わりポート転送無しで動作したので、Ｄｏｃｋｅｒ／ネイティブ／クラウドよりも６９％〜７８％高いスループットを達成した。コンテクストスイッチのオーバーヘッドのため、Ｘコンテナ／ＰＶ／クラウドは、Ｄｏｃｋｅｒ／ネイティブ／クラウドと比較して同時並行テストの２０％の性能損失があった。この結果は、ネットワークＩ／Ｏ集中型の作業負荷に対して、ＸコンテナがＶＭより性能が良く、そして多くの場合、ネイティブＤｏｃｋｅｒコンテナよりもさらに性能が良いことを示す。

図９（ｃ）および図９（ｄ）は、ベアメタルマシンおよびアマゾンＥＣ２インスタンス上のカーネルコンパイル時間を示し、下位カーネルコンパイル時間は上位カーネルコンパイル時間よりも良い。ＮＧＩＮＸ実験と同様で、ベアメタルマシン上の単一プロセスＸコンテナは、ネイティブで動作するかまたはＶＭ内で動作しているＤｏｃｋｅｒコンテナより大幅に性能が良い。アマゾンＥＣ２では同様の改善は見られなかったが、入出力スケジューリングの別の層によるものと思われる。ＰＶ Ｘコンテナの性能は準仮想化された環境のページテーブル管理の高オーバーヘッドのため、僅かに損なわれて、ｆｏｒｋおよびｅｘｅｃなどの動作を遅くした。この結果は、ＣＰＵ集中型の作業負荷に対して、より軽量のシステムコールから得ることができる性能の利点が制限されるが、性能向上はまだカーネルカスタマイズによって可能であることを示す。

Ｘコンテナの例示の実施形態は、ＧｒａｐｈｅｎｅおよびＵｎｉｋｅｒｎｅｌとも比較されて、その結果が図１０に示されている。図１０は、図１０（ａ）、図１０（ｂ）および図１０（ｃ）と示された３つの部分を含む。

これらの比較のために、ベアメタルマシン上でＮＧＩＮＸウェブサーバ、ＰＨＰおよびＭｙＳＱＬデータベースによるｗｒｋベンチマークを動作させた。Ｇｒａｐｈｅｎｅは、Ｕｂｕｎｔｕ−１６．０４によってＬｉｎｕｘ（登録商標）上で動作して、セキュリティ分離モジュール無しでコンパイルされた（これはその性能を改善するはずである）。Ｕｎｉｋｅｒｎｅｌに対しては、Ｒｕｍｐｒｕｎを使用したが、その理由は、それが軽微なパッチでそれらのアプリケーションを動作させることができるからである（ＭｉｒａｇｅＯＳによる実行はＯＣａｍｌでアプリケーション全体を書き直すことを必要とする）。ＵｎｉｋｅｒｎｅｌはＸｅｎ ＨＶでの動作をサポートしないので、それをＰＶモードでテストしただけである。

図１０（ａ）は、単一のワーカープロセスを有する静的ウェブページのために役立つＮＧＩＮＸウェブサーバのスループットを比較する。１つのＮＧＩＮＸサーバプロセスしか動作していないので、ＳＭＰを無効にすることによってＸコンテナを最適化した。Ｘコンテナは、Ｕｎｉｋｅｒｎｅｌに相当するスループット、そして、Ｇｒａｐｈｅｎｅのスループットの２倍を超えるスループットを達成した。

図１０（ｂ）は、単一のＮＧＩＮＸウェブサーバの４つのワーカープロセスを実行するケースを示す。これはＵｎｉｋｅｒｎｅｌによってサポートされないので、Ｇｒａｐｈｅｎｅに対してだけ比較した。この場合、Ｘコンテナは、Ｇｒａｐｈｅｎｅより５０％超高性能だった。Ｇｒａｐｈｅｎｅの性能は限定されたが、それは、Ｇｒａｐｈｅｎｅでは複数のプロセスがＩＰＣコールを使用して共有ＰＯＳＩＸライブラリへのアクセスを調整し、それによって著しいオーバーヘッドが生じるからである。

前に図５に関連して記載されているシナリオを評価したが、そこでは、２つのＰＨＰ ＣＧＩサーバがＭｙＳＱＬデータベースに接続されている。ＰＨＰの組み込みウェブサーバを有効にして、ｗｒｋクライアントを使用して、データベースに（読み出しと書き込みに対して等しい確率を有する）要求を出したページにアクセスした。図５に示すように、ＰＨＰサーバは、データベースを共有するかまたは分離されたデータベースを有することができる。ＧｒａｐｈｅｎｅはＰＨＰ ＣＧＩサーバをサポートしないので、Ｕｎｉｋｅｒｎｅｌに対してだけ比較した。２つのＰＨＰサーバのトータルスループットは、異なる構成によって計測されたが、その結果を図１０（ｃ）に示す。すべてのＶＭは、１つのＣＰＵコアで単一プロセスを実行していた。３ＶＭおよび４ＶＭ構成では、Ｘコンテナは、Ｕｎｉｋｅｒｎｅｌより４０％超高性能であった。これはＬｉｎｕｘ（登録商標）カーネルがＲｕｍｐｒｕｎカーネルよりもよく最適化されるという理由であると思われる。さらに、Ｘコンテナは単一のコンテナにおいてＰＨＰおよびＭｙＳＱＬの実行をサポートするが、それはＵｎｉｋｅｒｎｅｌでは可能でない。この便利さが性能にも著しく役立ち、Ｘコンテナスループットは、Ｕｎｉｋｅｒｎｅｌ設定の約３倍のスループットであった。

例示の実施形態のスケーラビリティ評価も実行されて、その結果が図１１に示されている。

１つの物理マシン上で最大４００のコンテナを実行することによって、Ｘコンテナアーキテクチャのスケーラビリティを評価した。この実験のために、ＰＨＰ−ＦＰＭエンジンを有するＮＧＩＮＸサーバを使用した。ｗｅｂｄｅｖｏｐｓ／ＰＨＰ−ＮＧＩＮＸ Ｄｏｃｋｅｒイメージを使用して、単一のワーカープロセスによってＮＧＩＮＸおよびＰＨＰ−ＦＰＭを構成した。ｗｒｋベンチマークを動作させて、すべてのコンテナのトータルスループットを計測した。各コンテナは５つの同時接続を有する専用のｗｒｋスレッドを備えており、したがって、ｗｒｋスレッドおよび同時接続の合計数はコンテナの数によって直線的に増加する。

各Ｘコンテナは、ＳＭＰサポートを無効にすることによってＸ−ＬｉｂＯＳを最適化して、単一の仮想ＣＰＵおよび１２８ＭＢのメモリで構成された。Ｘコンテナはより少ない量のメモリ（例えば、６４ＭＢのメモリ）で作動することができるが、１２８ＭＢのメモリサイズは４００個のＸコンテナをブートするのに十分に小さいという点に留意する必要がある。Ｄｏｃｋｅｒ／ＨＶ／ベアおよびＤｏｃｋｅｒ／ＰＶ／ベアのために、各Ｘｅｎ ＶＭは、１つの仮想ＣＰＵおよび５１２ＭＢのメモリを割り当てられた（５１２ＭＢはＵｂｕｎｔｕ−１６ ＯＳのための推奨の最小サイズである）。しかしながら、物理マシンが９６ＧＢのメモリを備えているだけであるので、２００を超えるＶＭを開始するときに、ＶＭのメモリサイズを２５６ＭＢに変えなければならなかった。ＶＭがそれでもブートすることができるとわかったが、ネットワークスタックはパケットをドロップし始めた。Ｘｅｎ上で２５０を超えるＰＶインスタンスまたは２００を超えるＨＶインスタンスを正しくブートすることができなかった。

図１１は、すべてのベアメタル構成の総スループットを示す。Ｄｏｃｋｅｒ／ネイティブ／ベアコンテナが少数のコンテナに対してより高いスループットを達成したことが分かる。これは、Ｄｏｃｋｅｒコンテナ間のコンテクストスイッチングが、Ｘコンテナ間およびＸｅｎ ＶＭ間よりも安価であるからである。しかしながら、コンテナの数が増加したのにつれて、Ｄｏｃｋｅｒコンテナの性能はより早く低下した。これは、各ＮＧＩＮＸ＋ＰＨＰコンテナが４つのプロセスを実行したからであり、Ｎ個のコンテナで、Ｄｏｃｋｅｒコンテナを動作させているＬｉｎｕｘ（登録商標）カーネルは４Ｎ個のプロセスをスケジューリングしていたが、Ｘカーネルは、それぞれが４つのプロセスを実行しているＮ個の仮想ＣＰＵをスケジューリングしていた。この階層的なスケジューリングは一緒に多くのコンテナをスケジューリングする、よりスケーラブルな方法であることがわかって、Ｎ＝４００では、Ｘコンテナ／ＰＶ／ベアはＤｏｃｋｅｒ／ｎａｔｉｖｅ／ｂａｒｅを１８％上回った。

評価はカーネルカスタマイズの追加的な性能の利点をさらに示したが、そのことはここで図１２を参照して説明する。Ｘコンテナの例示の実施形態は、カスタマイズされたカーネルモジュールを必要とするアプリケーションコンテナを有効にする。例えば、Ｘコンテナは、ソフトウェアＲＤＭＡ（Ｓｏｆｔ−ｉｗａｒｐおよびＳｏｆｔ−ＲＯＣＥの両方）アプリケーションを使用することができる。Ｄｏｃｋｅｒ環境において、このようなモジュールはルート特権を必要とし、直接ホストネットワークをコンテナにさらして、セキュリティの懸念を増大させる。

我々は、シナリオを３台のＮＧＩＮＸウェブサーバおよび１台のロードバランサでテストした。ＮＧＩＮＸウェブサーバは、それぞれ１つのワーカープロセスを使用するように構成されている。Ｄｏｃｋｅｒプラットフォームは、通常、ＨＡＰｒｏｘｙなどのユーザレベルロードバランサを使用する。ＨＡＰｒｏｘｙは、生産システムで広く配備されている単一スレッドのイベントドライバプロキシサーバである。Ｘコンテナは、ＨＡＰｒｏｘｙをサポートするが、ＩＰＶＳ（ＩＰ仮想サーバ）などのカーネルレベルロードバランシングソリューションを使用することもできる。ＩＰＶＳは新規なカーネルモジュールを挿入して、ｉｐｔａｂｌｅおよびＡＲＰテーブルルールを変えることを必要とし、それはホストネットワークにルート特権およびアクセスがないＤｏｃｋｅｒコンテナにおいては可能でない。

この実験では、我々は、ＨＡＰｒｏｘｙ：１．７．５ Ｄｏｃｋｅｒイメージを使用した。ロードバランサおよびＮＧＩＮＸサーバは、同じ物理マシン上で動作していた。各Ｘコンテナを単一の仮想ＣＰＵで構成し、性能の最適化のためにＸ−ＬｉｂＯＳにおいてＳＭＰサポートをオフにした。我々は、ｗｒｋ作業負荷発生器を使用して、トータルスループットを計測した。

図１２は、様々な構成を比較している。ＨＡＰｒｏｘｙを有するＸコンテナプラットフォームは、Ｄｏｃｋｅｒコンテナプラットフォームのスループットの２倍を達成した。ＮＡＴモードを使用するＩＰＶＳカーネルレベルロードバランシングによって、Ｘコンテナは、処理能力をさらに１２％高める。この場合、ロードバランサは、それがウェブフロントエンドおよびＮＡＴサーバの両方の役割だったので、ボトルネックであった。ＩＰＶＳは、「直接ルーティング」と呼ばれる別のロードバランシングモードをサポートしている。直接ルーティングによって、ロードバランサはバックエンドサーバに要求を送り届けることを必要とするだけであるが、バックエンドサーバからの応答はクライアントに直接送られる。これは、ｉｐｔａｂｌｅルールを変えて、カーネルモジュールをロードバランサおよびＮＧＩＮＸサーバの両方に挿入することを必要とする。直接ルーティングモードによって、ボトルネックはＮＧＩＮＸサーバにシフトされ、トータルスループットはさらに１．５倍改善された。

上記の評価に関連して記載されている特定のＸコンテナの実施形態が例に過ぎず、例示の実施形態の利点を示すことを意図しており、いかなる形であれ制限するものとして見られるべきでないことが理解されよう。

図１〜図１２に関連して図と共に示されて説明される特定の配置が図示例のみによって表されたものであり、そして多数の別の実施形態が可能であることが理解されよう。したがって、本明細書において開示される様々な実施形態は、いかなる形であれ制限するものとして解釈されるべきでない。ソフトウェアコンテナを実装する多数の代替的な配置が、他の実施形態で利用され得る。例えば、他のタイプのカーネルベースの分離層が、特定の例示の実施形態に関連して記載されている特定のＸカーネルの配置の代わりに使用可能である。当業者であれば、他の処理操作および関連するシステム実体構成が他の実施形態で使用可能であることも認めるであろう。

そのため、他の実施形態が例示の実施形態の構成要素に対して、追加的または代替のシステム要素を含むことができる可能性がある。したがって、特定のシステム構成ならびに関連ソフトウェアコンテナおよびカーネルベースの分離層実装は、他の実施形態で変化することができる。

本明細書において記載されている情報処理システムの所与の処理デバイスまたは他のコンポーネントは、例示として、メモリに結合されたプロセッサを備えた対応する処理デバイスを利用して構成される。プロセッサは、処理操作および他の機能性の性能を制御するためにメモリに格納されているソフトウェアプログラムコードを実行する。処理デバイスは、１つ以上のネットワークの上の通信をサポートするネットワークインタフェースも含む。

プロセッサは、例えば、マイクロプロセッサ、ＡＳＩＣ、ＦＰＧＡ、ＣＰＵ、ＡＬＵ、ＧＰＵ、ＤＳＰまたは他の類似の処理デバイスコンポーネント、ならびに他のタイプおよび配置の処理回路を、任意の組合せで含むことができる。例えば、本明細書において開示される所与の処理デバイスは、このような回路を用いて実装することができる。

メモリは、処理デバイスの機能性の一部を実施する際にプロセッサによって実行するためのソフトウェアプログラムコードを格納する。所与の、対応するプロセッサによって実行するためのこのようなプログラムコードを格納するこのようなメモリは、本明細書においてさらに一般的には、その中で実施されるプログラムコードを有するプロセッサ可読ストレージ媒体と称されるものの例であり、例えば、ＳＲＡＭ、ＤＲＡＭまたはその他のタイプランダムアクセスメモリ、ＲＯＭ、フラッシュメモリ、磁気メモリ、光メモリまたは任意の組合せの他のタイプのストレージデバイスなどの、電子メモリを含むことができる。

前述のように、このようなプロセッサ可読ストレージ媒体を含む製品は、本発明の実施形態と考えられる。「製品」という本明細書で用いられる用語は、一過性の伝播信号を除外するものと理解しなければならない。プロセッサ可読ストレージ媒体を含む他のタイプのコンピュータプログラム製品は、他の実施形態で実装することができる。

加えて、本発明の実施形態は、カーネルベースの分離層上のソフトウェアコンテナを提供することと関連した処理操作を実装するように構成された処理回路を含む、集積回路の形で実装することができる。

本明細書において開示される情報処理システムは、１つ以上の処理プラットフォームまたはその一部を使用して実装することができる。

例えば、情報処理システムの少なくとも一部を実装するために用いることができる処理プラットフォームの１つの例示の実施形態は、物理インフラストラクチャ上で動作するハイパーバイザを用いて実装される仮想マシンを含むクラウドインフラストラクチャを含む。このような仮想マシンは、１つ以上のネットワーク上で互いに通信するそれぞれの処理デバイスを含むことができる。

このような実施形態のクラウドインフラストラクチャは、ハイパーバイザの管理下の仮想マシンのそれぞれのものの上で動作するアプリケーションの１つ以上のセットをさらに含むことができる。少なくとも１つの基盤となる物理マシンを用いてそれぞれ１セットの仮想マシンを提供している、複数のハイパーバイザを使用することもできる。１つ以上のハイパーバイザにより提供される仮想マシンの異なるセットは、情報処理システムの各種コンポーネントの複数のインスタンスを構成する際に利用することができる。

本明細書において開示した情報処理システムの少なくとも一部を実装するために使うことができる処理プラットフォームの別の例示の実施形態は、少なくとも１つのネットワーク上で互いに通信する複数の処理デバイスを含む。処理プラットフォームの各処理デバイスは、メモリに結合されたプロセッサを含むとみなされる。

また、これらの特定の処理プラットフォームは例として示されているだけであり、情報処理システムは、追加または代替の処理プラットフォームならびに多数の別個の処理プラットフォームを任意の組合せで含むことができて、それぞれのこのようなプラットフォームは、１つ以上のコンピュータ、サーバ、ストレージデバイスまたは他の処理デバイスを含んでいる。

例えば、本発明の実施形態を実装するために用いる他の処理プラットフォームは、仮想マシンを含んでいる仮想化インフラストラクチャの代わりに、または、それに加えて、異なるタイプの仮想化インフラストラクチャを含むことができる。したがって、いくつかの実施形態では、システムコンポーネントは、少なくとも部分的にクラウドインフラストラクチャまたは他のタイプの仮想化インフラストラクチャで動作することができる、という可能性がある。

したがって、他の実施形態で、追加または代替の要素の異なる配置が使用可能であると理解すべきである。少なくともこれらの要素のサブセットは共通の処理プラットフォームに集合的に実装されてもよく、または、それぞれのこのような要素が別々の処理プラットフォームに実装されてもよい。

また、コンピュータ、サーバ、ストレージデバイスまたは他のコンポーネントの多数の他の配置が、情報処理システムにおいて可能である。このようなコンポーネントは、任意のタイプのネットワークまたは他の通信媒体上の情報処理システムの他の要素と通信することができる。

前述のように、本明細書において開示されるシステムのコンポーネントは、少なくとも部分的に、メモリに格納されて処理デバイスのプロセッサによって実行される１つ以上のソフトウェアプログラムの形で、実装することができる。例えば、本明細書において開示される特定の機能性は、少なくとも部分的にソフトウェアの形で実装することができる。

本明細書において記載されている情報処理システムの特定の構成は例示的なものでしかなく、他の実施形態のこのような所与のシステムは、具体的に示されている要素に加えるか、またはその代わりの他の要素を含むことができ、その中にはこのようなシステムの従来の実装で一般に見られるタイプの１つ以上の要素を含む。

例えば、いくつかの実施形態では、情報処理システムは、開示された技術を利用して他の状況において追加であるか代替の機能性を提供するように構成することができる。

本明細書において記載されている本発明の実施形態が例示することだけを意図していることを再び強調しなければならない。本発明の他の実施形態は、本明細書において説明されている特定の例示の実施形態および多数の他の状況で利用されているものとは異なる、多種多様なタイプおよび配置の情報処理システム、ネットワークおよびデバイスを利用して実装することができる。加えて、本明細書において特定の実施形態を説明する前後関係でなされる特定の仮定は、他の実施形態に適用する必要はない。これらおよび多数の他の別の実施形態は、当業者にとって直ちに明らかなものである。

Claims (22)

1. カーネルベースの分離層を実装することと、
   前記カーネルベースの分離層上のソフトウェアコンテナがライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含むように構成することと、
   前記ソフトウェアコンテナにおいて１つ以上のユーザプロセスを実行することと、を含み、
   メモリに結合されたプロセッサをそれぞれ含んでいる複数の処理デバイスを含む処理プラットフォームによって実行される、方法。
2. 前記カーネルベースの分離層が、前記ソフトウェアコンテナの前記専用のオペレーティングシステムカーネルに対してＸカーネルの形で実装されている、請求項１に記載の方法。
3. 前記カーネルベースの分離層が、仮想マシンハイパーバイザおよびホストオペレーティングシステムのうち１つを含む、請求項１に記載の方法。
4. 前記ライブラリオペレーティングシステムが、指定されたタイプのモノリシックオペレーティングシステムカーネルから変換される、請求項１に記載の方法。
5. 前記ライブラリオペレーティングシステムが、前記ソフトウェアコンテナにおいて実行している前記１つ以上のユーザプロセスの特権レベルと同じである特権レベルで前記ソフトウェアコンテナにおいて動作する、請求項１に記載の方法。
6. 前記ライブラリオペレーティングシステムが、システムコールを対応する関数コールに変換することと連動して前記１つ以上のユーザプロセスのバイナリの自動翻訳をサポートするように構成されている、請求項１に記載の方法。
7. 前記カーネルベースの分離層上のソフトウェアコンテナがライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含むように構成することがさらに、
   既存のソフトウェアコンテナのコンテナイメージを抽出することと、
   前記カーネルベースの分離層上の前記ソフトウェアコンテナを構成する際の仮想マシンイメージとして前記抽出されたコンテナイメージを利用することと、を含み、
   前記カーネルベースの分離層上の前記ソフトウェアコンテナが前記既存のソフトウェアコンテナのラッピングされたバージョンを含む、請求項１に記載の方法。
8. 前記既存のソフトウェアコンテナの１つ以上のユーザプロセスが、それらの１つ以上のユーザプロセスのいかなる修正も必要とすることなく前記カーネルベースの分離層上の前記ソフトウェアコンテナの前記１つ以上のユーザプロセスとして実行するのを許可される、請求項７に記載の方法。
9. 前記カーネルベースの分離層上のソフトウェアコンテナがライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含むように構成することは、前記カーネルベースの分離層上の複数のソフトウェアコンテナを、前記複数のソフトウェアコンテナのそれぞれがライブラリオペレーティングシステムとして別々の専用のオペレーティングシステムカーネルを含むように構成することをさらに含む、請求項１に記載の方法。
10. 前記ソフトウェアコンテナにおいて１つ以上のユーザプロセスを実行することは、前記複数のソフトウェアコンテナのそれぞれのものの１つ以上のユーザプロセスの別個のセットを実行することをさらに含み、前記別個のセットのうち少なくとも１つが複数の異なるユーザプロセスを含む、請求項９に記載の方法。
11. 前記複数のソフトウェアコンテナの第１のものにおいて実行している１つ以上のユーザプロセスの前記別個のセットの第１のものは、前記複数のソフトウェアコンテナの第２のものにおいて実行している１つ以上のユーザプロセスの前記別個のセットの第２のものから分離される、請求項１０に記載の方法。
12. 前記ソフトウェアコンテナを構成することは、前記ライブラリオペレーティングシステムおよび前記１つ以上のユーザプロセスがユーザモードで動作する準仮想化されたソフトウェアコンテナとして前記ソフトウェアコンテナを構成することを含む、請求項１に記載の方法。
13. 前記準仮想化されたソフトウェアコンテナが動作する前記カーネルベースの分離層を実装することは、他の場合は標準仮想マシンハイパーバイザまたはオペレーティングシステムカーネルであるものの修正されたバージョンとして前記カーネルベースの分離層を実装することを含む、請求項１２に記載の方法。
14. 前記ソフトウェアコンテナを構成することは、前記ライブラリオペレーティングシステムおよび前記１つ以上のユーザプロセスがハードウェアアシスト型仮想マシンの中でカーネルモードで動作するハードウェアアシスト型の仮想化されたソフトウェアコンテナとして前記ソフトウェアコンテナを構成することを含む、請求項１に記載の方法。
15. 前記ハードウェアアシスト型の仮想化されたソフトウェアコンテナが動作する前記カーネルベースの分離層を実装することは、標準仮想マシンハイパーバイザまたはオペレーティングシステムカーネルとして前記カーネルベースの分離層を実装することを含む、請求項１４に記載の方法。
16. 前記カーネルベースの分離層および前記ソフトウェアコンテナの前記ライブラリオペレーティングシステムが、異なるタイプのそれぞれの第１および第２のオペレーティングシステムを用いて実装されている、請求項１に記載の方法。
17. メモリに結合されたプロセッサをそれぞれ含んでいる複数の処理デバイスを含む処理プラットフォームを含むシステムであって、
    前記処理プラットフォームは、
    カーネルベースの分離層を実装し、
    前記カーネルベースの分離層上のソフトウェアコンテナがライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含むように構成し、
    前記ソフトウェアコンテナにおいて１つ以上のユーザプロセスを実行するように構成されている、システム。
18. 前記処理プラットフォームが、それぞれの異なるテナントに対して前記カーネルベースの分離層上の１つ以上のソフトウェアコンテナの異なるセットを提供するように構成されており、それぞれのこのようなソフトウェアコンテナはライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含む、請求項１７に記載のシステム。
19. 前記処理プラットフォームが、
    クラウドベースの処理プラットフォーム、
    エンタープライズ処理プラットフォーム、
    モノのインターネット（ＩｏＴ）プラットフォーム、および
    ネットワーク機能仮想化（ＮＦＶ）プラットフォーム、のうち少なくとも１つを含む、請求項１７に記載のシステム。
20. １つ以上のソフトウェアプログラムのプログラムコードを中に格納している非一時的プロセッサ可読ストレージ媒体を含むコンピュータプログラム製品であって、前記プログラムコードは、それぞれの処理デバイスがメモリに結合されたプロセッサを含んでいる複数の処理デバイスを含む処理プラットフォームによって実行されると、前記処理プラットフォームに、
    カーネルベースの分離層を実装することと、
    前記カーネルベースの分離層上のソフトウェアコンテナがライブラリオペレーティングシステムとして専用のオペレーティングシステムカーネルを含むように構成することと、
    前記ソフトウェアコンテナにおいて１つ以上のユーザプロセスを実行することと、を行わせる、コンピュータプログラム製品。
21. 前記ライブラリオペレーティングシステムが、前記ソフトウェアコンテナにおいて実行している前記１つ以上のユーザプロセスの特権レベルと同じである特権レベルで前記ソフトウェアコンテナにおいて動作する、請求項２０に記載のコンピュータプログラム製品。
22. 前記ライブラリオペレーティングシステムが、システムコールを対応する関数コールに変換することと連動して前記１つ以上のユーザプロセスのバイナリの自動翻訳をサポートするように構成されている、請求項２０に記載のコンピュータプログラム製品。

Images