JP2023036828A - マルチテナントａｐｉゲートウェイにおいてテナント分離を提供するためのマイクロサービスコンテナの活用 - Google Patents

Abstract

【課題】マルチテナント環境において要求をサービスするためにコンテナを使用してテナント同士を分離する方法を提供する。【解決手段】システムは、複数の異なるテナントのＡＰＩをホストし、多くの異なるクライアントデバイスから要求を受信する。要求を受信すると、ルータが、要求をサービスするためにコンテナインスタンスが利用可能かどうかを判断する。コンテナインスタンスは、内部エンドポイントと、ウェブサーバと、実行時環境とを含む空コンテナインスタンスであってもよい。空コンテナインスタンスは、特定のテナントに関連付けることができない。コンテナインスタンスをテナントに関連付けるために、キー値データストアなどのデータストアが、依存しないコンテナインスタンスを、特定のテナントに関連付けられ、必要なＡＰＩ機能を実行するための構成コードを含むコンテナインスタンスに変える構成ファイルを検索する。【選択図】図７

Description

関連出願との相互参照
本願は、２０１７年９月３０日に出願された米国仮特許出願第６２／５６６，４２２号、２０１７年９月３０日に出願された米国仮特許出願第６２／５６６，４３１号、および２０１７年９月３０日に出願された米国仮特許出願第６２／５６６，４３５号の利益を主張する。米国仮特許出願第６２／５６６，４２２号、第６２／５６６，４３１号、および第６２／５６６，４３５号の開示全体が、付録を含め、ここに引用により援用される。

背景
アプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）ゲートウェイとは、開発業者が公共消費のためにＡＰＩを作成し、公開し
、維持し、監視し、安全にすることを可能にする、十分に管理されたサービスである。テナントはＡＰＩを定義してそれらをクラウドプラットフォームといったこれらのパブリックＡＰＩゲートウェイへ公開することができ、これらは次に、クライアントデバイスにとって利用可能になり得る。大規模なＡＰＩゲートウェイでは、環境は、複数の異なるテナントが、ホストされた同じサービスを通して利用可能になるＡＰＩをホストする、マルチテナント環境を含む場合がある。

概要
いくつかの実施形態では、マルチテナント環境において要求をサービスするためにコンテナを使用してテナント同士を分離する方法は、第１のテナントによって提供される第１のサービスに対する第１の要求を受信するステップと、マルチテナント環境における空コンテナを選択するステップと、第１のサービスを実現する第１の構成をコンテナにロードするステップと、コンテナから第１の要求をサービスするステップと、第２のテナントによって提供される第２のサービスに対する第２の要求を受信するステップと、コンテナから第１の構成をフラッシュするステップと、コンテナから第２の要求をサービスするステップとを含んでいてもよい。

いくつかの実施形態では、非一時的コンピュータ読取可能媒体は、１つ以上のプロセッサによって実行されると１つ以上のプロセッサに動作を実行させる命令を含み、動作は、第１のテナントによって提供される第１のサービスに対する第１の要求を受信することと、マルチテナント環境における空コンテナを選択することと、第１のサービスを実現する第１の構成をコンテナにロードすることと、コンテナから第１の要求をサービスすることと、第２のテナントによって提供される第２のサービスに対する第２の要求を受信することと、コンテナから第１の構成をフラッシュすることと、コンテナから第２の要求をサービスすることとを含む。

いくつかの実施形態では、システムは、１つ以上のプロセッサと、１つ以上のメモリデバイスとを含んでいてもよく、１つ以上のメモリデバイスは、１つ以上のプロセッサによって実行されると１つ以上のプロセッサに動作を実行させる命令を含み、動作は、第１のテナントによって提供される第１のサービスに対する第１の要求を受信することと、マルチテナント環境における空コンテナを選択することと、第１のサービスを実現する第１の構成をコンテナにロードすることと、コンテナから第１の要求をサービスすることと、第
２のテナントによって提供される第２のサービスに対する第２の要求を受信することと、コンテナから第１の構成をフラッシュすることと、コンテナから第２の要求をサービスすることとを含む。

任意の実施形態において、以下の特徴のうちのいずれかまたはすべてが、任意の組合せで、および何ら限定されることなく含まれていてもよい。コンテナは、クライアントデバイスからの要求をサービスするためにインスタンス化される、マルチテナント環境における複数のコンテナのうちの１つであってもよい。第１の構成は、第１のサービスによって使用され得るメモリにおけるヒープのサイズを含んでいてもよい。コンテナから第１の構成をフラッシュした後で、コンテナは、埋込まれたサーバと内部エンドポイントとを有する実行時プロセスを含んでいてもよい。内部エンドポイントは、第２の要求をサービスするために、マルチテナント環境におけるルータによって呼び出されてもよい。第１の構成は、要求をサービスするためにともにつながれる複数のアクションを含んでいてもよい。マルチテナント環境は、コンテナが、異なるテナントに関連付けられた要求を同時にサービスすることを防止してもよい。マルチテナント環境は、コンテナが、単一のテナントに関連付けられた要求を同時にサービスすることを可能にしてもよい。方法／動作はまた、第２のテナントによって提供される第２のサービスに対する第３の要求を受信するステップと、コンテナから第２の構成をフラッシュすることなく、コンテナから第３の要求をサービスするステップとを含んでいてもよい。第１のサービスは、マルチテナント環境を通して利用可能になるパブリックＡＰＩを含んでいてもよい。

本発明の性質および利点の一層の理解は、明細書の残りの部分および図面を参照して実現され得る。いくつかの図面にわたり、同様の構成要素を指すために同じ参照符号が使用される。場合によっては、複数の同様の構成要素のうちの１つを示すために、参照符号にサブラベルが関連付けられる。既存のサブラベルへの特定化なく参照符号が参照される場合、それは、そのような複数の同様の構成要素すべてを指すよう意図されている。
いくつかの実施形態に従った、マルチテナント環境において要求を扱うためのシステムの簡略ブロック図である。 いくつかの実施形態に従った、テナントに対する要求をサービスするために準備されているコンテナインスタンス１０８の図である。 いくつかの実施形態に従った、空コンテナインスタンスにデータストアからのファイルがどのように投入され得るかを示すブロック図である。 いくつかの実施形態に従った、投入されたコンテナがどのように要求をサービスできるかを示す図である。 いくつかの実施形態に従った、利用可能なコンテナのプールに戻されているコンテナの簡略ブロック図である。 いくつかの実施形態に従った、マルチテナント環境におけるコンテナのライフサイクルの状態図である。 いくつかの実施形態に従った、マルチテナント環境におけるコンテナのライフサイクルの代替的な状態図である。 マルチテナント環境において要求をサービスするためにコンテナを使用してテナント同士を分離する方法のフローチャートである。 いくつかの実施形態に従った、マルチテナント環境においてコンテナのための実行時状態およびサービス構成を管理する方法のフローチャートである。 いくつかの実施形態に従った、マルチテナント環境において要求をサービスするためにコンテナのプールを効率的に配分する方法のフローチャートである。 実施形態のうちのいくつかを実現するための分散型システムの簡略ブロック図である。 実施形態システムのコンポーネントによって提供されるサービスをクラウドサービスとして提供し得るシステム環境のコンポーネントの簡略ブロック図である。 さまざまな実施形態が実現され得る例示的なコンピュータシステムを示す図である。

詳細な説明
ここに説明されるのは、ＡＰＩゲートウェイを管理するための実施形態である。クラウドシステムは、複数の異なるテナントのためのＡＰＩをホストし、多くの異なるクライアントデバイスから要求を受信することができる。要求が受信されると、関連付けられたテナントが識別可能であり、ルータが、要求をサービスするためにコンテナインスタンスが利用可能かどうかを判断することができる。コンテナインスタンスは、内部エンドポイントと、ウェブサーバと、実行時環境とを含む空コンテナインスタンスであってもよい。空コンテナインスタンスは、特定のテナントに関連付けることができない。コンテナインスタンスをテナントに関連付けるために、キー値データストアなどのデータストアが、依存しない（agnostic）コンテナインスタンスを、特定のテナントに関連付けられ、必要なＡＰＩ機能を実行するための構成コードを含むコンテナインスタンスに変える構成ファイルを検索することができる。コンテナにおけるＡＰＩが要求（または単一のテナントに対する複数の要求）をサービスし終えると、実行時状態情報がデータストアに戻って保存可能であり、コンテナインスタンスのコンテンツはフラッシュされ得る。これは、コンテナの再使用およびプールされたリソースの効率的管理を依然として可能にしつつ、マルチテナント環境におけるテナントデータ間の分離を保証する。データストアは、システムにおけるルータが、必要な場合に新しいコンテナインスタンスを配分し、コンテナインスタンスが使用されていない場合にそれらの配分を解除することを可能にするように、サービスレジストリを維持することができる。データストアはまた、オンデマンドベースで任意のコンテナに分散され得るテナントＡＰＩのための実行時状態情報、構成、およびアプリケーションを格納することができる。

図１は、いくつかの実施形態に従った、マルチテナント環境において要求を扱うためのシステムの簡略ブロック図である。この開示全体を通し、ＡＰＩゲートウェイの一例が使用されてもよい。しかしながら、ここに説明される実施形態はそう限定されない。代わりに、ＡＰＩゲートウェイに対する要求を扱うために説明される機能は、要求を受信するためのインターフェイスを有する任意のシステムで実現され得る。

複数のクライアントデバイス１０２（たとえば、スマートフォン、ラップトップ、タブレットコンピュータ、ワークステーション、サーバなど）が、ロード・バランサ・アズ・ア・サービス（Load Balancer as a Service：ＬＢａａＳ）インターフェイスを含み得るパブリックインターフェイス１０４へ要求を送信することができる。これらの要求は、マルチテナント環境の特定のテナントに関連付けられてもよく、ＡＰＩ機能といった、そのテナントによって提供される特定のサービスを参照してもよい。たとえば、クライアントデバイス１０２のうちの１つから受信された要求が、「Tenant:ACME, API:ProcessInvoice」といった情報を含んでいてもよい。パブリックインターフェイス１０４は、その要求
を１つ以上のルータ１０６へ送り込むことができる。

ルータ１０６は、テナントに割り当てられて特定の要求を処理できる１つ以上のコンテナを判断するために、データストア１１２と周期的にかつリアルタイムで通信することができる。図１の例では、テナント２に対する要求は、ルータ１０６が選択できる３つの異なるコンテナインスタンスを有するであろう。テナント２に割り当てられた一組のコンテナインスタンス内で、ルータ１０６は、要求をサービスする構成および／またはアプリケーションがロードされた１つ以上のコンテナインスタンスを選択することができる。たとえば、ルータ１０６は、「API:ProcessInvoice」を扱うための構成がロードされた、「Te
nant:ACME」に割り当てられた３つのコンテナインスタンスのうちの１つを選択すること
ができる。どのインスタンスにもこの構成がまだロードされていない場合、ルータ１０６は、既存の空コンテナを選択すること、または、新しい空コンテナをインスタンス化することができる。ルータ１０６は次に、「Tenant:ACME」に対する特定の要求を扱うことが
できるコンテナ化されたサービスを作成するために、データストア１１２に、「API:ProcessInvoice」に特有の構成を既存の／新しい空コンテナへ転送させることができる。

コンテナ化されたサービスがいったん要求を扱い、（必要であれば）クライアントデバイスへ応答を返すと、コンテナ化されたサービスは、その特定のテナント／サービスの組合せに対する追加の要求をサービスするために再使用され得るか、または、そのコンテンツがフラッシュされたコンテナが他のテナントにとって利用可能にされ得る。コンテナがフラッシュされ、異なるテナントに割り当て直される場合、コンテナに保存される必要がある実行時情報がデータストア１１２に送り返され得る。これは、この次にその特定のアプリケーションまたはＡＰＩが空コンテナにおいてインスタンス化されると、実行時情報が転送され、それが中断したところから再開するように新しいコンテナによって使用され得る、ということを保証する。

登録サービス１１４は、新しいテナントをマルチテナント環境に登録するために使用され得る。新しいテナントは、登録サービス１１４のインターフェイスを使用して、データストア１１２において新しいテナントエントリを生成すること、および、それらのマルチテナント環境の使用のためのパラメータを定義することができる。これらのパラメータは、その特定のテナントにとって利用可能であるコンテナインスタンスの最大数、最小数、平均数、および予想数を含んでいてもよい。加えて、新しいテナントは、要求をサービスするためのルータの数およびタイプ、利用可能であり得る異なる構成サービス、実行時コンテナプールの異なる構成、ならびに登録プロセスの他の局面を選択することができる。

構成サービス１１０は、テナントが構成を定義し、パブリックインターフェイスを通して利用可能になり得るアプリケーションを選択することを可能にする、ウェブベースのユーザインターフェイスを提供してもよい。たとえば、いくつかの実施形態は、テナントがＡＰＩを構築するために複数の異なるマイクロサービス、アプリケーション、機能などから選択することを可能にする、一連のウェブフォームおよびドロップダウンボックスを提供してもよい。いくつかの実施形態はまた、テナントが、予め定められた時間限度内でＡＰＩが呼び出され得る回数を限定するためのアプリケーションといった、実行可能なアプリケーションを選択することを可能にしてもよい。構成およびアプリケーションが構成サービス１１０を通して選択／定義された後で、これらは、システムにおける空コンテナへの配置のためにデータセンター１１２に格納され得る。

なお、所与のゲートウェイが２つ以上のテナントに同時に応じることができる。いくつかの実施形態では、完全に分離され、異なる利用可能性のドメインまたはデータセンター上で実行される、複数のゲートウェイが存在し得る。たとえば、シカゴ（Chicago）用の
ゲートウェイと、フェニックス（Phoenix）用のゲートウェイとがあってもよい。しかし
ながら、これらのゲートウェイは双方とも、依然として同じテナントにサーブしてもよい。エンドユーザは依然として、一意的なゲートウェイＩＤを使用して、複数のゲートウェイのうちの１つまたは任意の組合せにＡＰＩをデプロイメントしてもよい。いくつかの実施形態では、各ゲートウェイは、構成、アプリケーションなどを格納するためのそれ自体の一意的なキー値データストアを有していてもよい。

以下の図は、システムによって要求がどのように処理され得るかを示す一例を説明する。これらの例は、限定的であるよう意図されてはいない。図２は、いくつかの実施形態に従った、テナントに対する要求をサービスするために準備されているコンテナインスタン
ス１０８の図を示す。この段階では、ルータ１０６は、サービスされるべき要求をすでに受信している。まず、ルータ１０６は、データストア１１２と連動して作動して、利用可能なコンテナインスタンスが動作していて要求をサービスするために利用可能かをどうかを判断することができる。データストア１１２は、システムにおける利用可能なインスタンスの各々をカタログするサービスレジストリ２１４を含み得る。サービスレジストリ２１４はまた、どのＡＰＩおよびテナントがインスタンス化された各コンテナに割り当てられるかを追跡することができる。新しいコンテナがインスタンス化されるか、または既存のコンテナが除去される場合、サービスレジストリ２１４は、データストア１１２によってリアルタイムで更新され得る。ルータ１０６は、サービスレジストリ２１４の少なくとも一部のローカルコピーを保持することができる。データストア１１２は、サービスレジストリ２１４への変更のリストを用いて、ルータ１０６を断続的に更新することができる。いくつかの実施形態では、データストア１１２は、要求を受信できる利用可能なコンテナインスタンスのリストを用いて、ルータ１０６を更新することができる。いくつかの実施形態では、システムにおけるインスタンスの総リストが非常に大きいものであり得るため、サービスレジストリ２１４の変更または一部のみがルータ１０６へ送信される。

図１に示すように、いくつかの実施形態は、複数のルータ１０６を含んでいてもよい。ルータ１０６－２のうちの１つは、マスタルータとして指定され得る。マスタルータ１０６－２は、必要な場合に新しいコンテナインスタンスをインスタンス化することを許可された唯一のルータ１０６として指定され得る。したがって、図２のルータ１０６がマスタルータとして指定される場合、それは、特定のテナントに対する要求をサービスするために、必要であれば新しいコンテナインスタンスを自由にインスタンス化することができる。マスタルータ１０６－２は、プールにおけるテナントに割り当てられたコンテナインスタンスの数が、その特定のテナントのための最小／最大数内にあることを保証するために、登録中にテナントによって提供された設定を分析することができる。ルータ１０６のうちの１つが、新しいコンテナがインスタンス化されることを必要とする要求を扱っている場合、ルータ１０６－１は要求をマスタルータ１０６－２へ転送することができ、マスタルータ１０６－２は新しいコンテナをインスタンス化するべきかどうかを判断することができる。マスタコンテナ１０６－２のみが新しいコンテナをインスタンス化できるようにすることにより、これは、コンテナプールのサイズが効率的に管理されることを保証するのに役立つ。たとえば、６つの異なるルータがすべて、特定のテナントについての特定のサービスに対する同時要求を受信した場合、これらのルータの各々は、インスタンス化されたコンテナが１つで十分であれば、新しいコンテナをインスタンス化することを独立して決定し得るであろう。これらの要求の各々をマスタルータ１０６－２へ送り込むことは、最小数の新しいコンテナのみがインスタンス化されることを保証する。

逆に、使用されていない複数のコンテナインスタンスが１つのテナントに割り当てられている、または、割り当てられていない複数のコンテナがコンテナプールで利用可能であるとルータ１０６および／またはデータストア１１２が判断した場合、これらの未使用のコンテナのうちの１つ以上をシステムから排除できるという判断を下すことができ、それにより、既存のコンテナが動作するためのメモリおよび処理パワーを解放する。これは、要求をサービスできるコンテナインスタンスの動的プールを提供する。このプールは、受信された要求トラフィックが任意の所与の時間にどれくらい多いかに基づいて、動的に成長／縮小し得る。以下に説明されるように、コンテナコンテンツをフラッシュすることは、テナントが互いから分離されることを依然として保証しつつ、コンテナが異なるテナント間で再使用されることを可能にする。

これらの実施形態によって達成される１つの技術的利点は、コンテナプールのサイズの効率的管理である。実行時プールは、共通の特性をすべて共有する実行時インスタンスの集合であってもよい。コンテナのプールにおける実行時インスタンスは、所与の実行時イ
ンスタンスが｛プール名、インスタンスのインデックス｝という１対の値によって一意的に識別されるように、インデックス０で始まって連続的に番号付けされてもよい。プール管理は、各実施形態によって使用される特定のコンテナ環境に依存してもよい。たとえば、必要に応じて実行時コンテナを作成／開始／停止するために、Ｊａｖａ（登録商標）クラスが、ドッカー（Docker）デーモンＲＥＳＴ ＡＰＩを使用してプール機能性を実現するために使用されてもよい。このクラスは、環境が、プールの名前、ポートの数、デバッグポートの数、コンテナ状態遷移のタイムアウト値（以下に詳細に説明される）などを設定することを可能にしてもよい。いくつかの実施形態はまた、このクラスが、要求をサービスするために利用可能になるであろうテナントに結合されていない実行中のコンテナインスタンスの数を表わす「最小サイズ」値を特定することを可能にしてもよい。加えて、「最大サイズ」値は、コンテナプールにおける実行時コンテナインスタンスの最大数を特定してもよい。

サービスがゲートウェイにおけるコンテナにいったん割り当てられると、サービスは、それが生きていて適切に機能していることを他のサービスに示す表示として、周期的な「ハートビート（heartbeat）」を実行してもよい。たとえば、サービスがコンテナにロー
ドされる場合、それは、それが要求をサービスするために利用可能であることをルータに知らせるために、ハートビートを実行してもよい。ハートビートを実行することは、データストア１１２のサービスレジストリにおける対応するエントリを更新することを含んでいてもよい。これらのハートビート送信は、ゲートウェイにおけるコンテナのライフサイクルを判断するために使用され得る。たとえば、いくつかの実施形態は有効時間（time-to-live：ＴＴＬ）間隔を使用してもよく、その後でサービスはアクティブでないと考えられてもよい。それに代えて、いくつかの実施形態は、サービスがアクティブでないと考えられる前にスキップされる／抜かされることが許可されるハートビート数を特定してもよい。ハートビートは、１０秒ごと、２０秒ごと、３０秒ごと、６０秒ごとなどのように定期的に起こってもよい。

図２の例では、ルータ１０６は、現在特定のテナントに割り当てられていない、または、要求のテナントに割り当てられているものの、要求の特定のＡＰＩを実行するための構成が投入されていない空コンテナ１０８－３を識別することができる。なお、コンテナ１０８－１およびコンテナ１０８－２は、構成が投入され、特定のテナントに割り当てられている。それらはコンテナ１０８－３とは別個のコンテナにおいて動作するため、これら３つのコンテナのデータおよび動作は、互いから厳密に分離され得る。

図３は、いくつかの実施形態に従った、空コンテナインスタンスにデータストア１１２からのファイルがどのように投入され得るかを示すブロック図を示す。図２の例を続けると、特定のテナントに対する要求３０４を扱うために、空コンテナ１０８－３が割り当てられ得る。まず、コンテナ１０８－３は、コンテナ１０８－３を通して他のテナントの要求をサービスすることができないように、そのテナントに割り当てられ得る。次に、要求３０４からのテナントおよびＡＰＩ情報が、データストア１１２における構成、アプリケーション、および実行時情報を調べるために使用され得る。いくつかの実施形態では、データストア１１２は、キー値データストアであってもよい。いくつかの実施形態はまた、データストア１１２が、マルチテナント環境における異なるシステム上に、または異なるプラットフォームにわたって分散されることを可能にしてもよい。たとえば、要求３０４からのテナントおよび／またはＡＰＩは、構成２０２、アプリケーション２０４、および／または任意の実行時状態情報を返すデータストア１１２における値を調べるためのキーとして使用され得る。

いくつかの実施形態では、キー値データストア１１２は、テナント特有の構成をディスクまで持続するために使用されてもよい。加えて、キー値データストアは、実行中のすべ
てのマイクロサービスがそれら自体を「登録」し、他のサービスがそれらを突き止めて起動することができるように、中央サービスレジストリ２１４を提供することができる。たとえば、ｅｔｃｄ（登録商標）などの分散型キー値データストアが、管理サービスから取り込まれた構成（たとえば、ポリシー、ＡＰＩ、アプリケーション、計画メタデータなど）；サービスレジストリ２１４における実行時コンテナ状態；コンテナプール構成（たとえば、最小値、最大値、戦略、タイムアウト間隔など）；テナント登録ステータス（たとえば、テナント、テナントとプールとの結合など）；律速構成、リアルタイム状態などといった状態情報を格納するために使用されてもよい。

構成２０２は、図１の構成サービス１１０で定義されたアクション２０６のパイプラインを含んでいてもよい。これらのアクション２０６は、ＡＰＩまたはデータを処理するための他のサービスを形成するために、ともにつながれてもよい。アクション２０６の各々は、要求を受信すること、要求におけるペイロードを解析すること、ペイロードにおけるデータを処理すること、ペイロードにおけるデータを変更すること、情報を得るために別のサービスを呼び出すこと、ファイルまたはデータベースへ情報を書き込むこと、および／または応答を生成することなどを含んでいてもよい。いくつかの実施形態では、構成２０２は、複数の要求を同時に扱うことができる。このため、構成２０２が投入された単一のコンテナが、その特定のＡＰＩおよびその特定のテナントに対する複数の要求を扱うことができる。一般に、構成はステートレス（たとえばＲＥＳＴｆｕｌ）であり、情報を処理して応答を迅速に生成する点で非常に効率的である。

構成２０２を返すことに加えて、データストア１１２は、ＡＰＩ構成２０２とともにコンテナで実行され得る１つ以上のアプリケーション２０４を返すことができる。たとえば、アプリケーション２０４は、予め定められた時間間隔内で特定のＡＰＩが呼び出され得る回数を限定する（たとえば、毎時１００個の要求のみがサービスされ得る）帯域幅限定アプリケーションであってもよい。構成２０２とは対照的に、アプリケーション２０４は、実行時状態情報がアプリケーションの実行の合間に保存されることを必要としてもよい。図３では、アプリケーション２０４は過去に実行されなかったかもしれず、そのため、アプリケーション２０４のためにデータストア１１２に保存された状態実行時情報がない可能性がある。コンテナ１０８－３はここで、特定のＡＰＩ要求を処理するために単一のテナントに割り当てられるマイクロサービスを表わしてもよい。コンテナ１０８－３がいったんテナントに結合されると、インスタンスは、データストア１１２から、ＡＰＩ定義、アプリケーション、計画、サブスクリプションといった新しい構成情報のすべてをオンデマンドでロードすることができる。

空コンテナは、ドッカー（登録商標）コンテナなどのソフトウェアコンテナであってもよく、マルチテナント環境は、Kubernetes（クバネティス）（登録商標）などのオーケストレーションされたコンテナプラットホームを含み得る。新しい空コンテナをインスタンス化することは、コンテナ画像から空コンテナを生成することと、それに、システムで使用されるどの構成にも共通になるであろう最小数のソフトウェアプロセスを投入することとを含んでいてもよい。たとえば、いくつかの実施形態は空コンテナを、Ｊａｖａ実行時環境（登録商標）（Java Runtime Environment：ＪＲＥ）などの実行時環境２１２と、ＨＴＴＰサーバなどのｗｅｂサーバ２１０と、内部エンドポイント２０８とを含むドッカー（登録商標）コンテナとして指定してもよい。内部エンドポイント２０８はルータ１０６に露出されてもよく、要求をコンテナ１０８－３へ送信するためにルータ１０６によって使用され得る。いくつかの実施形態では、ドッカー（登録商標）コンテナ以外のコンテナ環境が使用されてもよい。たとえば、いくつかの実施形態は、実行時コンテナを開始／停止するためにＵＮＩＸ（登録商標）プロセスを使用してもよい。

空コンテナが投入される場合、データストア１１２は、構成２０２およびアプリケーシ
ョン２０４をコンテナ１０８－３へ転送することができる。データストア１１２において実行時状態データ３０２が利用可能であった場合、それもコンテナ１０８－３へ転送されるであろう。この場合、実行時状態データ３０２は、アプリケーションが実行される際にそれによって生成され、コンテナ１０８－３に格納される。たとえば、アプリケーション２０４は、所与の時間間隔内に受信された要求の数を記録してもよい。この情報は実行時状態３０２に保存され、このコンテナ１０８－３がフラッシュされる際にデータストア１１２へ転送されて戻り得る。一般に、構成２０２、アプリケーション２０４、および／または実行時状態３０２を、空であるもののインスタンス化されたコンテナ１０８－３へ転送することは、かなりの遅延なく要求を扱うために非常に迅速にかつ効率的に行なわれ得る比較的軽量のプロセスである。

図４は、いくつかの実施形態に従って、投入されたコンテナ１０８－３がどのように要求をサービスできるかを示す。コンテナ１０８－３は、構成２０２によって定義されたＡＰＩのために、このテナントに対するあらゆる要求をサービスすることができる。ある場合には、これは、構成２０２がコンテナ１０８－３へ転送されるようにした単一の要求を処理することのみを含んでいてもよい。他の場合には、これは、ルータ１０６へ送信された、同じテナントに対する複数の同様の要求を処理することを含んでいてもよい。要求がすべて処理され、応答（もしあれば）が要求元のクライアントデバイスに送り返された後で、コンテナ１０８－３はアイドルまたはパッシブになり得る。コンテナ１０８－３が依然として特定のテナントに割り当てられるかまたは結合されている間、それは現在、任意の要求を処理するために使用されていない。予め定められた時間間隔の後で、コンテナ１０８－３は、その特定のテナントから割り当て解除され、新しい構成を有する新しいテナントへの割り当てを待つ利用可能なコンテナ１０８－３のプールに戻され得る。

コンテナ１０８－３がフラッシュされ、異なるテナントに割り当て直される前に、コンテナ１０８－３上で実行されたアプリケーション２０４によって生成または更新された任意の実行時状態情報３０２が、データストア１１２に保存され得る。次に、構成２０２および／またはアプリケーション２０４が将来の要求をサービスするために新しいコンテナに割り当て直される場合、実行時状態情報３０２は異なるコンテナへ送信され得る。

図５は、いくつかの実施形態に従った、利用可能なコンテナのプールに戻されているコンテナ１０８－３の簡略ブロック図を示す。実行時状態情報３０２がデータストア１１２へ転送されて戻った後で、コンテナ１０８－３から、構成２０２、アプリケーション２０４、および／または実行時状態３０２がフラッシュされ得る。空コンテナ１０８－３はここで、異なるＡＰＩ呼び出しをサービスするために、ルータ１０６によって異なるテナントに割り当て直され得る。図５ではコンテナ１０８－３のみが空であるように図示されているが、実際のデプロイメントは典型的には、複数の空コンテナを含んでいてもよい。ルータ１０６は、総当たり戦略といった、複数の利用可能な空コンテナのうちの１つへ要求を割り当てるための異なる戦略を使用することができる。上述のように、コンテナ１０８－３が予め定められた時間間隔内で新しいテナント／ＡＰＩに割り当てられない場合、メモリおよび／またはコンピューティングリソースを残しておくために、コンテナ１０８－３をマルチテナント環境から除去することができる。

上述のように、データストア１１２は、構成、アプリケーション、および実行時状態を、マルチテナント環境で動作するさまざまなコンテナに分散させることによって、これらの動作を容易にする。データストア１１２はまた、新規登録時に、および実行時でさえも、テナントから構成情報を受信してもよい。データストア１１２はまた、いかなる時もコンテナプールの状態を監視するサービスレジストリ２１４を維持する。データストア１１２はこのサービスレジストリ２１４を使用してルータ１０６と通信し、利用可能なコンテナのプールがいつ成長および／または縮小すべきかを判断する。

図６Ａは、いくつかの実施形態に従った、マルチテナント環境におけるコンテナのライフサイクルの状態図を示す。最初の状態６０２では、コンテナは存在しない。状態６０４では、コンテナは、上述の一組のプロセス（たとえば、ウェブサーバ、エンドポイントなど）を有してすでにインスタンス化されているが、コンテナは特定のテナントに結合されておらず、または割り当てられておらず、空である。要求をサービスする場合、コンテナは状態６０６に入ることができ、そこで、それは特定のテナントに結合されるかまたは割り当てられ、構成、アプリケーション、および／または実行時状態情報が投入される。コンテナはルータ１０６から受信された要求をアクティブにサービスし得るため、状態６０６はアクティブと呼ばれる。状態６０８では、コンテナは依然として特定のテナントに結合されるかまたは割り当てられ得るが、それがその内部に格納された構成を用いて要求をアクティブに処理していないという点でパッシブである。予め定められた時間間隔の間アイドルのままでいた後で、コンテナは、状態６１０で割当てまたは結合を解除され得る。コンテナが特定のテナントにもはや結合されていない場合、内部構成、アプリケーション、および／または実行時状態はフラッシュされ得る。いくつかの実施形態では、非結合のコンテナは、それが新しいテナントに割り当て直されるまで、その内部コンテンツをフラッシュする必要はない。コンテナが新しいテナントに割り当てられない場合、状態６１２でコンテナは除去され得る。

図６Ｂは、いくつかの実施形態に従った、マルチテナント環境におけるコンテナのライフサイクルを示す、図６Ａからの状態図の別の図を示す。最初の状態６０２では、コンテナはまだ存在せず、または、コンテナ環境からすでに削除されている。コンテナインスタンスが作成されると、それは状態６０４で非結合であってもよい。コンテナが「非結合タイムアウト」と呼ばれる予め定められた時間間隔の間アイドルである場合、コンテナは環境から削除され、状態６０２に戻り得る。それに代えて、状態６０６で、コンテナはテナントに割り当てられ、構成、アプリケーション、状態情報などがロードされ得る。結合されたアクティブな状態６０６から、ルータがコンテナのプールのサイズを縮小し、よって状態６０２に遷移して戻る場合、コンテナは環境から除去され得る。コンテナはまた、状態６０４で、テナントから解放され、そのテナント特有のコンテンツをフラッシュさせ、コンテナの非結合プールに返され得る。さらに、状態６０６における結合されたアクティブなコンテナは、それが「アイドルテナントタイムアウト」と呼ばれる予め定められた時間間隔の間、クライアント要求をサービスすることなくアイドルのままでいる場合、状態６０８でパッシブになり得る。結合されたパッシブな状態６０８から、「パッシブタイムアウト」間隔が満了し、コンテナを、結合されたパッシブなコンテナ状態６０８から、状態６０４のコンテナの非結合プールへ遷移させ得る。コンテナが存在する限り、このコンテナライフサイクルは状態間を遷移し得る。

図７は、マルチテナント環境において要求をサービスするためにコンテナを使用してテナント同士を分離する方法のフローチャートを示す。方法は、第１のテナントによって提供される第１のサービスに対する第１の要求を受信するステップ（７０２）を含んでいてもよい。方法はまた、マルチテナント環境における空コンテナを選択するステップ（７０４）を含んでいてもよい。方法は加えて、第１のサービスを実現する第１の構成をコンテナにロードするステップ（７０６）を含んでいてもよい。方法はさらに、コンテナから第１の要求をサービスするステップ（７０８）を含んでいてもよい。方法はまた、第２のテナントによって提供される第２のサービスに対する第２の要求を受信するステップ（７１０）を含んでいてもよい。方法は加えて、コンテナから第１の構成をフラッシュするステップ（７１２）を含んでいてもよい。方法はさらに、コンテナから第２の要求をサービスするステップ（７１４）を含んでいてもよい。いくつかの実施形態は、これらの方法ステップを実行する１つ以上のプロセッサと１つ以上のメモリとを含むシステムを含んでいてもよい。他の実施形態は、１つ以上のプロセッサにこれらの方法ステップを実行させる命
令を格納する非一時的コンピュータ読取可能媒体を含んでいてもよい。

任意の実施形態において、以下の特徴のうちの１つ以上が、任意の組合せで、および何ら限定されることなく含まれていてもよい。コンテナは、クライアントデバイスからの要求をサービスするためにインスタンス化される、マルチテナント環境における複数のコンテナのうちの１つであってもよい。コンテナから第１の構成をフラッシュした後で、コンテナは、埋込まれたサーバと内部エンドポイントとを有する実行時プロセスを含んでいてもよい。内部エンドポイントは、第２の要求をサービスするために、マルチテナント環境におけるルータによって呼び出されてもよい。第１の構成は、要求をサービスするためにともにつながれる複数のアクションを含んでいてもよい。マルチテナント環境は、コンテナが、異なるテナントに関連付けられた要求を同時にサービスすることを防止してもよい。マルチテナント環境は、コンテナが、単一のテナントに関連付けられた要求を同時にサービスすることを可能にしてもよい。方法はまた、第２のテナントによって提供される第２のサービスに対する第３の要求を受信するステップと、コンテナから第２の構成をフラッシュすることなく、コンテナから第３の要求をサービスするステップとを含んでいてもよい。第１のサービスは、マルチテナント環境を通して利用可能になるパブリックＡＰＩを含んでいてもよい。

図７に示す特定のステップは、本発明のさまざまな実施形態に従った、マルチテナント環境において要求をサービスするためにコンテナを使用してテナント同士を分離する特定の方法を提供する、ということが理解されるべきである。他の順序のステップも、代替的な実施形態に従って実行されてもよい。たとえば、本発明の代替的な実施形態は、上に概説されたステップを異なる順序で実行してもよい。さらに、図７に示す個々のステップは、個々のステップにとって適切に、さまざまな順序で実行され得る複数のサブステップを含んでいてもよい。さらに、特定の用途に依存して、追加のステップが追加または除去されてもよい。当業者であれば、多くの変形、変更、および代替案を認識するであろう。

図８は、いくつかの実施形態に従った、マルチテナント環境においてコンテナのための実行時状態およびサービス構成を管理する方法のフローチャートを示す。方法は、マルチテナント環境において提供されるサービスに対して要求が受信されたという表示を受信するステップ（８０２）を含んでいてもよい。方法は加えて、サービスを実現する構成を識別し、構成がデータストアに格納されるステップ（８０４）を含んでいてもよい。方法はまた、要求をサービスするために、マルチテナント環境におけるコンテナへ構成を送信するステップ（８０６）を含んでいてもよい。方法はさらに、コンテナから実行時状態を受信するステップ（８０８）を含んでいてもよい。方法はまた、実行時状態をデータストアに格納し、構成がコンテナからフラッシュされるステップ（８１０）を含んでいてもよい。いくつかの実施形態は、これらの方法ステップを実行する１つ以上のプロセッサと１つ以上のメモリとを含むシステムを含んでいてもよい。他の実施形態は、１つ以上のプロセッサにこれらの方法ステップを実行させる命令を格納する非一時的コンピュータ読取可能媒体を含んでいてもよい。

任意の実施形態において、以下の特徴のうちの１つ以上が、任意の組合せで、および何ら限定されることなく含まれていてもよい。構成は、実行時に先立って、マルチテナント環境のテナントによって提供されてもよい。データストアは、キー値データストアを含んでいてもよい。キー値データストアは、分散型キー値データストアを含んでいてもよい。サービスに関連付けられたテナントのアイデンティティは、キー値データストアにおけるキーであってもよく、構成および実行時状態は、キー値データストアにおける値であってもよい。データストアはまた、マルチテナント環境において利用可能であるコンテナのレジストリを格納してもよい。マルチテナント環境において新しいコンテナが利用可能になると、データストアは、コンテナのレジストリに基づいて、マルチテナント環境における
１つ以上のルータを更新してもよい。

図８に示す特定のステップは、さまざまな実施形態に従った、マルチテナント環境においてコンテナのための実行時状態およびサービス構成を管理する特定の方法を提供する、ということが理解されるべきである。他の順序のステップも、代替的な実施形態に従って実行されてもよい。たとえば、本発明の代替的な実施形態は、上に概説されたステップを異なる順序で実行してもよい。さらに、図８に示す個々のステップは、個々のステップにとって適切に、さまざまな順序で実行され得る複数のサブステップを含んでいてもよい。さらに、特定の用途に依存して、追加のステップが追加または除去されてもよい。当業者であれば、多くの変形、変更、および代替案を認識するであろう。

図９は、いくつかの実施形態に従った、マルチテナント環境において要求をサービスするためにコンテナのプールを効率的に配分する方法のフローチャートを示す。方法は、複数のコンテナをマルチテナント環境における第１のテナントに割り当てるステップ（９０２）を含んでいてもよい。方法はまた、第１のテナントに割り当てられているものの、第１のテナントによって使用されていない、複数のコンテナにおける１つ以上のコンテナを識別するステップ（９０４）を含んでいてもよい。方法は加えて、１つ以上のコンテナのコンテンツをフラッシュするステップ（９０６）を含んでいてもよい。方法はさらに、１つ以上のコンテナをマルチテナント環境における第２のテナントに割り当て直すステップ（９０８）を含んでいてもよい。いくつかの実施形態は、これらの方法ステップを実行する１つ以上のプロセッサと１つ以上のメモリとを含むシステムを含んでいてもよい。他の実施形態は、１つ以上のプロセッサにこれらの方法ステップを実行させる命令を格納する非一時的コンピュータ読取可能媒体を含んでいてもよい。

任意の実施形態において、以下の特徴のうちの１つ以上が、任意の組合せで、および何ら限定されることなく含まれていてもよい。１つ以上のコンテナのコンテンツをフラッシュした後で、１つ以上のコンテナは、第２のテナントに割り当て直される前に、第１の時間間隔の間、任意のテナントに割り当てられる必要はない。方法はまた、第１のテナントに割り当てられているものの、第１のテナントによって使用されていない、複数のコンテナにおける第２の１つ以上のコンテナを識別するステップと、第２の１つ以上のコンテナを必要とする他のテナントはないと判断するステップと、マルチテナント環境から第２の１つ以上のコンテナを除去するステップとを含んでいてもよい。方法は加えて、第１のテナントが、複数のコンテナによってサービスされ得る要求よりも多い要求を受信していると判断するステップを含んでいてもよい。方法はさらに、新しい複数のコンテナをインスタンス化するステップと、新しい複数のコンテナを第１のテナントに割り当てるステップとを含んでいてもよい。方法はまた、以前に別のテナントに割り当てられたコンテナを第１のテナントに割り当てるステップを含んでいてもよい。マルチテナント環境のゲートウェイが、１つ以上のコンテナをマルチテナント環境における第２のテナントに割り当て直してもよい。

図９に示す特定のステップは、さまざまな実施形態に従った、マルチテナント環境において要求をサービスするためにコンテナのプールを効率的に割り当てる特定の方法を提供する、ということが理解されるべきである。他の順序のステップも、代替的な実施形態に従って実行されてもよい。たとえば、本発明の代替的な実施形態は、上に概説されたステップを異なる順序で実行してもよい。さらに、図９に示す個々のステップは、個々のステップにとって適切に、さまざまな順序で実行され得る複数のサブステップを含んでいてもよい。さらに、特定の用途に依存して、追加のステップが追加または除去されてもよい。当業者であれば、多くの変形、変更、および代替案を認識するであろう。

ここに説明された方法の各々は、コンピュータシステムによって実現されてもよい。こ
れらの方法の各ステップは、コンピュータシステムによって自動的に実行されてもよく、および／または、ユーザが関与する入力／出力を提供されてもよい。たとえば、ユーザは方法におけるステップごとに入力を提供してもよく、これらの入力の各々は、そのような入力を要求する特定の出力に応答するものであってもよく、出力はコンピュータシステムによって生成される。各入力は、対応する要求出力に応答して受信されてもよい。さらに、入力は、ユーザから、別のコンピュータシステムからデータストリームとして受信され、メモリ位置から検索され、ネットワークを通して検索され、ウェブサービスから要求されたりしてもよい。同様に、出力は、ユーザに、別のコンピュータシステムにデータストリームとして提供され、メモリ位置に保存され、ネットワークを通して送信され、ウェブサービスに提供されたりしてもよい。要するに、ここに説明された方法の各ステップは、コンピュータシステムによって行なわれてもよく、ユーザが関与する、または関与しないかもしれない、コンピュータシステムとの間での任意の数の入力、出力、および／または要求を伴ってもよい。ユーザが関与しないそれらのステップは、人の介入なくコンピュータシステムによって自動的に行なわれる、と言ってもよい。したがって、ここに説明された各方法の各ステップは、ユーザとの間での入力および出力を含むように変更されてもよく、または、人の介入なくコンピュータシステムによって自動的に行なわれてもよく、その場合、あらゆる決定がプロセッサによって下される、ということが、この開示に鑑みて理解されるであろう。さらに、ここに説明された各方法のいくつかの実施形態は、有形のソフトウェア製品を形成するために有形の非一時的な記憶媒体上に格納された１組の命令として実現されてもよい。

図１０は、実施形態のうちの１つを実現するための分散型システム１０００の簡略図を示す。図示された実施形態では、分散型システム１０００は１つ以上のクライアントコンピューティングデバイス１００２、１００４、１００６、および１００８を含み、それらは、１つ以上のネットワーク１０１０を通して、ウェブブラウザ、専用クライアント（たとえば、オラクル・フォームズ（Oracle Forms））などのクライアントアプリケーションを実行し、動作させるように構成される。サーバ１０１２は、ネットワーク１０１０を介して、リモートのクライアントコンピューティングデバイス１００２、１００４、１００６、および１００８と通信可能に結合されてもよい。

さまざまな実施形態では、サーバ１０１２は、システムのコンポーネントのうちの１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスまたはクラウドサービスとして、もしくはソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）モデルの下で、クライアントコンピューティ
ングデバイス１００２、１００４、１００６、および／または１００８のユーザに提供されてもよい。クライアントコンピューティングデバイス１００２、１００４、１００６、および／または１００８を操作するユーザは次に、これらのコンポーネントによって提供されるサービスを利用するためにサーバ１０１２と対話するために、１つ以上のクライアントアプリケーションを利用してもよい。

図に示す構成では、システム１０００のソフトウェアコンポーネント１０１８、１０２０および１０２２は、サーバ１０１２上で実現されるとして示されている。他の実施形態では、システム１０００のコンポーネントおよび／またはこれらのコンポーネントによって提供されるサービスのうちの１つ以上も、クライアントコンピューティングデバイス１００２、１００４、１００６、および／または１００８のうちの１つ以上によって実現されてもよい。クライアントコンピューティングデバイスを操作するユーザは次に、これらのコンポーネントによって提供されるサービスを使用するために、１つ以上のクライアントアプリケーションを利用してもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。分散型システム
１０００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるべきである。図に示す実施形態はこのため、実施形態システムを実現するための分散型システムの一例であり、限定的であるよう意図されてはいない。

クライアントコンピューティングデバイス１００２、１００４、１００６、および／または１００８は、携帯型ハンドヘルドデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（personal digital assistant：ＰＤＡ））、またはウェアラブルデバイス（たとえば、グーグル・グラス（Google Glass）（登録商標）頭部装着型ディスプレイ）であってもよく、マイクロソフト・ウィンドウズ・モバイル（Microsoft Windows Mobile）（登録商標）などのソフトウェア、および／または、ｉＯＳ、ウィンドウズフォン、アンドロイド（登録商標）、ブラックベリー（登録商標）１０、パームＯＳなどのさまざまなモバイルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（short message service：ＳＭＳ）、ブラックベリー（登録商標）、または他の通信プ
ロトコルに対応していてもよい。クライアントコンピューティングデバイスは、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはリナックス（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを例として含む、汎用パーソナルコンピュータであり得る。クライアントコンピューティングデバイスは、たとえばグーグル・クローム（Google Chrome）ＯＳなどのさまざまなＧＮＵ／リナッ
クスオペレーティングシステムを何ら限定されることなく含む、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ様オペレーティングシステムのうちのいずれかを実行するワークステーションコンピュータであり得る。それに代えて、またはそれに加えて、クライアントコンピューティングデバイス１００２、１００４、１００６、および１００８は、ネットワーク１０１０を通して通信可能である、シンクライアントコンピュータ、インターネット対応ゲーミングシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャー入力デバイスを有する、または有さない、マイクロソフトＸｂｏｘゲーミングコンソール）、および／またはパーソナルメッセージングデバイスといった、任意の他の電子デバイスであってもよい。

例示的な分散型システム１０００は４つのクライアントコンピューティングデバイスを有して示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを有するデバイスなどの他のデバイスが、サーバ１０１２と対話してもよい。

分散型システム１０００におけるネットワーク１０１０は、ＴＣＰ／ＩＰ（transmission control protocol/Internet protocol：伝送制御プロトコル／インターネットプロト
コル）、ＳＮＡ（systems network architecture：システムネットワークアーキテクチャ）、ＩＰＸ（Internet packet exchange：インターネットパケット交換）、アップル・トーク（Apple Talk）などを何ら限定されることなく含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。単なる例として、ネットワーク１０１０は、イーサネット（登録商標）、トークンリング（Token-Ring）などに基づくものといった、ローカルエリアネットワーク（local area network：ＬＡＮ）であり得る。ネットワーク１０１０は、ワイドエリアネットワークおよびインターネットであり得る。それは、仮想プライベートネットワーク（virtual private network：ＶＰＮ）、イントラネ
ット、エクストラネット、公衆交換電話網（public switched telephone network：ＰＳ
ＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、電気電子技術者協会（the Institute of Electrical and Electronics：ＩＥＥＥ）８０２．１１プロトコルスイー
ト、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのうちのいずれ
かの下で動作するネットワーク）、ならびに／もしくは、これらのおよび／または他のネットワークの任意の組合せを何ら限定されることなく含む、仮想ネットワークを含み得る。

サーバ１０１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを例として含む）、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せで構成されてもよい。さまざまな実施形態では、サーバ１０１２は、前述の開示で説明された１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ１０１２は、本開示の一実施形態に従った上述の処理を行なうためのサーバに対応していてもよい。

サーバ１０１２は、上述のもののうちのいずれかを含むオペレーティングシステム、および商業的に入手可能な任意のサーバオペレーティングシステムを実行してもよい。サーバ１０１２はまた、さまざまな追加のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行してもよく、ＨＴＴＰ（hypertext transport protocol：ハイパーテキスト伝送プロトコル）サーバ、ＦＴＰ（file transfer protocol：ファイル転送プロトコル）サーバ、ＣＧＩ（common gateway interface：コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース（Sybase）、ＩＢＭ（International Business Machines：インターナショナル・ビジネス・マシ
ーンズ）などから商業的に入手可能なものを何ら限定されることなく含む。

いくつかの実現化例では、サーバ１０１２は、クライアントコンピューティングデバイス１００２、１００４、１００６、および１００８のユーザから受信されたデータフィードおよび／またはイベント更新を分析して統合するための１つ以上のアプリケーションを含んでいてもよい。一例として、データフィードおよび／またはイベント更新は、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る、１つ以上の第三者情報源および連続データストリームから受信されたツイッター（登録商標）フィード、フェースブック（登録商標）更新またはリアルタイム更新を含んでいてもよいが、それらに限定されない。サーバ１０１２はまた、クライアントコンピューティングデバイス１００２、１００４、１００６、および１００８の１つ以上の表示デバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含んでいてもよい。

分散型システム１０００はまた、１つ以上のデータベース１０１４および１０１６を含んでいてもよい。データベース１０１４および１０１６は、さまざまな位置に存在していてもよい。例として、データベース１０１４および１０１６のうちの１つ以上は、サーバ１０１２に対してローカルな（および／または、サーバ１０１２内にある）非一時的記憶媒体上に存在していてもよい。それに代えて、データベース１０１４および１０１６は、サーバ１０１２からリモートであってもよく、ネットワークベースの接続または専用接続を介してサーバ１０１２と通信してもよい。一組の実施形態では、データベース１０１４および１０１６は、ストレージエリアネットワーク（storage-area network：ＳＡＮ）に存在していてもよい。同様に、サーバ１０１２に帰する機能を行なうための任意の必要なファイルが適宜、サーバ１０１２上にローカルに格納されてもよく、および／またはリモートに格納されてもよい。一組の実施形態では、データベース１０１４および１０１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、更新し、検索するように適
合された、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでいてもよい。

図１１は、本開示の一実施形態に従った、実施形態システムの１つ以上のコンポーネントによって提供されるサービスをクラウドサービスとして提供し得るシステム環境１１００の１つ以上のコンポーネントの簡略ブロック図である。図示された実施形態では、システム環境１１００は、クラウドサービスを提供するクラウドインフラストラクチャシステム１１０２と対話するためにユーザによって使用され得る１つ以上のクライアントコンピューティングデバイス１１０４、１１０６、および１１０８を含む。これらのクライアントコンピューティングデバイスは、クラウドインフラストラクチャシステム１１０２によって提供されるサービスを使用するためにクラウドインフラストラクチャシステム１１０２と対話するためにクライアントコンピューティングデバイスのユーザによって使用され得る、ウェブブラウザ、専用クライアントアプリケーション（たとえば、オラクル・フォームズ）、または何らかの他のアプリケーションといったクライアントアプリケーションを動作させるように構成されてもよい。

図に示すクラウドインフラストラクチャシステム１１０２は、図示されたもの以外のコンポーネントを有していてもよい、ということが理解されるべきである。また、図に示す実施形態は、この発明の一実施形態を取入れ得るクラウドインフラストラクチャシステムの単なる一例である。いくつかの他の実施形態では、クラウドインフラストラクチャシステム１１０２は、図示されたものよりも多い、または少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組合せてもよく、もしくは、異なる構成または配置のコンポーネントを有していてもよい。

クライアントコンピューティングデバイス１１０４、１１０６、および１１０８は、１００２、１００４、１００６、および１００８について上述したものと同様のデバイスであってもよい。

例示的なシステム環境１１００は３つのクライアントコンピューティングデバイスを有して示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを有するデバイスなどの他のデバイスが、クラウドインフラストラクチャシステム１１０２と対話してもよい。

ネットワーク１１１０は、クライアント１１０４、１１０６、および１１０８とクラウドインフラストラクチャシステム１１０２との間のデータの通信および交換を容易にしてもよい。各ネットワークは、ネットワーク１０１０について上述したものを含む、商業的に入手可能なさまざまなプロトコルのうちのいずれかを使用してデータ通信をサポートできる、当業者にはよく知られた任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム１１０２は、サーバ１０１２について上述したものを含み得る１つ以上のコンピュータおよび／またはサーバを含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどといった、クラウドインフラストラクチャシステムのユーザにとってオンデマンドで利用可能にされる多数のサービスを含んでいてもよい。クラウドインフラストラクチャシステムによって提供されるサービスは、そのユーザのニーズを満たすために動的にスケール変更され得る。クラウドインフラストラクチャシステムによって提供されるサービスの特定のインスタンス化は、ここに「
サービスインスタンス」と呼ばれる。一般に、クラウドサービスプロバイダのシステムから、インターネットなどの通信ネットワークを介してユーザに利用可能とされる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを作り上げるサーバおよびシステムは、顧客自身の構内サーバおよびシステムとは異なっている。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドでアプリケーションをオーダーし、使用してもよい。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダーによってユーザに提供されるかまたは当該技術分野において他の態様で公知であるようなストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、もしくは他のサービスへの、保護されたコンピュータネットワークアクセスを含んでいてもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへの、パスワードで保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク化された開発者による私的使用のための、ウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含み得る。

ある実施形態では、クラウドインフラストラクチャシステム１１０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼でき、高可用性で、かつ安全な態様で顧客に配信される、アプリケーション、ミドルウェアおよびデータベースサービス提供物一式を含んでいてもよい。そのようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクル・パブリック・クラウド（Oracle
Public Cloud）である。

さまざまな実施形態では、クラウドインフラストラクチャシステム１１０２は、クラウドインフラストラクチャシステム１１０２によって提供されるサービスへの顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するように適合されてもよい。クラウドインフラストラクチャシステム１１０２は、異なるデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム１１０２がクラウドサービスを販売する組織によって所有され（たとえば、オラクルによって所有され）、サービスが一般大衆または異なる産業企業にとって利用可能とされる、パブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム１１０２が単一の組織のためにのみ動作され、その組織内の１つ以上のエンティティのためのサービスを提供し得る、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスはまた、クラウドインフラストラクチャシステム１１０２、およびクラウドインフラストラクチャシステム１１０２によって提供されるサービスが、関連するコミュニティにおけるいくつかの組織によって共有される、コミュニティクラウドモデルの下で提供されてもよい。クラウドサービスはまた、２つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１１０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリー、プラットフォーム・アズ・ア・サービス（ＰａａＳ）カテゴリー、インフラストラクチャ・アズ・ア・サービス（Infrastructure as a Service：ＩａａＳ）カテゴリー、または、ハ
イブリッドサービスを含むサービスの他のカテゴリーの下で提供される、１つ以上のサー
ビスを含んでいてもよい。顧客は、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスを、サブスクリプションオーダーを介してオーダーしてもよい。クラウドインフラストラクチャシステム１１０２は次に、顧客のサブスクリプションオーダーにおけるサービスを提供するために処理を行なう。

いくつかの実施形態では、クラウドインフラストラクチャシステム１１０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを、何ら限定されることなく含んでいてもよい。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上にオンデマンドアプリケーション一式を構築し、配信するための能力を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得できる。さまざまな異なるＳａａＳサービスが提供されてもよい。例は、大型組織のための販売実績管理、企業統合、およびビジネス柔軟性についてのソリューションを提供するサービスを、何ら限定されることなく含む。

いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリーに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例は、（オラクルなどの）組織が共有の共通アーキテクチャ上で既存のアプリケーションを統合できるようにするサービスと、プラットフォームによって提供される共有のサービスを活用する新しいアプリケーションを構築するための能力とを、何ら限定されることなく含んでいてもよい。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本ソフトウェアおよびインフラストラクチャを管理し、制御してもよい。顧客は、顧客が別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを取得できる。プラットフォームサービスの例は、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクル・データベース・クラウド・サービス（Database Cloud Service：ＤＢＣＳ）などを、何ら限定されることなく含む。

ＰａａＳプラットフォームによって提供されるサービスを利用することにより、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを採用するとともに、デプロイメントされたサービスを制御することもできる。いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえば、オラクル・フュージョン・ミドルウェア（Oracle Fusion Middleware）サービス）、およびＪａｖａクラウドサービスを含んでいてもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形をしたデータベース・アズ・ア・サービスを顧客に提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発してデプロイメントするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、顧客がクラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイメントするためのプラットフォームを提供してもよい。

クラウドインフラストラクチャシステムにおいて、さまざまな異なるインフラストラクチャサービスが、ＩａａＳプラットフォームによって提供されてもよい。これらのインフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のための、ストレージ、ネットワーク、ならびに他の基礎的コンピューティングリソースなどの基本コンピューティングリソースの管理および制御を容易にする。

ある実施形態では、クラウドインフラストラクチャシステム１１０２はまた、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１１３０を含んでいてもよい。一実施形態では、インフラストラクチャリソース１１３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するためのサーバ、ストレージ、およびネットワーキングリソースなどのハードウェアの予め統合され最適化された組合せを含んでいてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１１０２におけるリソースは、複数のユーザによって共有され、要望ごとに動的に再配分されてもよい。加えて、リソースは、異なる時間帯におけるユーザに配分されてもよい。たとえば、クラウドインフラストラクチャシステム１１３０は、第１の時間帯における第１の一組のユーザが、特定数の時間、クラウドインフラストラクチャシステムのリソースを利用することを可能にし、次に、異なる時間帯に位置する別の一組のユーザへの同じリソースの再配分を可能にして、それによりリソースの利用を最大化してもよい。

ある実施形態では、クラウドインフラストラクチャシステム１１０２の異なるコンポーネントまたはモジュールによって、および、クラウドインフラストラクチャシステム１１０２が提供するサービスによって共有される、多くの内部共有サービス１１３２が提供されてもよい。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウィルススキャニングおよびホワイトリストサービス、高可用性、バックアップおよび復旧サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを、何ら限定されることなく含んでいてもよい。

ある実施形態では、クラウドインフラストラクチャシステム１１０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的管理を提供してもよい。一実施形態では、クラウド管理機能性は、クラウドインフラストラクチャシステム１１０２によって受信された顧客のサブスクリプションをプロビジョニングし、管理し、追跡するための能力などを含んでいてもよい。

一実施形態では、図に示すように、クラウド管理機能性は、オーダー管理モジュール１１２０、オーダーオーケストレーションモジュール１１２２、オーダープロビジョニングモジュール１１２４、オーダー管理および監視モジュール１１２６、ならびにアイデンティティ管理モジュール１１２８などの１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、もしくは任意の他の適切な構成および／または組合せであり得る、１つ以上のコンピュータおよび／またはサーバを含んでいてもよく、もしくはそれらを使用して提供されてもよい。

例示的な動作１１３４では、クライアントコンピューティングデバイス１１０４、１１
０６または１１０８などのクライアントデバイスを使用する顧客は、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスについてサブスクリプションオーダーを出すことにより、クラウドインフラストラクチャシステム１１０２と対話してもよい。ある実施形態では、顧客は、クラウドユーザインターフェイス（User Interface：ＵＩ）、クラウドＵＩ１１１２、クラウドＵＩ１１１４および／またはクラウドＵＩ１１１６にアクセスし、これらのＵＩを介してサブスクリプションオーダーを出してもよい。顧客がオーダーを出したことに応答してクラウドインフラストラクチャシステム１１０２が受信したオーダー情報は、顧客と、顧客が加入するつもりである、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスとを識別する情報を含んでいてもよい。

顧客によってオーダーが出された後で、オーダー情報が、クラウドＵＩ１１１２、１１１４、および／または１１１６を介して受信される。

動作１１３６で、オーダーがオーダーデータベース１１１８に格納される。オーダーデータベース１１１８は、クラウドインフラストラクチャシステム１１１８によって動作され、他のシステムエレメントとともに動作される、いくつかのデータベースのうちの１つであり得る。

動作１１３８で、オーダー情報がオーダー管理モジュール１１２０へ発送されてもよい。場合によっては、オーダー管理モジュール１１２０は、オーダーを立証し、立証後にオーダーを予約するといった、オーダーに関連する請求および課金機能を行なうように構成されてもよい。

動作１１４０で、オーダーに関する情報が、オーダーオーケストレーションモジュール１１２２へ通信されてもよい。オーダーオーケストレーションモジュール１１２２は、顧客によって出されたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションするために、オーダー情報を利用してもよい。場合によっては、オーダーオーケストレーションモジュール１１２２は、オーダープロビジョニングモジュール１１２４のサービスを使用して加入サービスをサポートするために、リソースのプロビジョニングをオーケストレーションしてもよい。

ある実施形態では、オーダーオーケストレーションモジュール１１２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にして、オーダーがプロビジョニングへ進むべきかどうかを判断するためにビジネスロジックを適用する。動作１１４２で、新規サブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール１１２２は、リソースを配分してサブスクリプションオーダーを遂行するために必要とされるそれらのリソースを構成することを求める要求を、オーダープロビジョニングモジュール１１２４へ送信する。オーダープロビジョニングモジュール１１２４は、顧客によってオーダーされたサービスのためのリソースの配分を可能にする。オーダープロビジョニングモジュール１１２４は、クラウドインフラストラクチャシステム１１００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。オーダーオーケストレーションモジュール１１２２はこのため、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または予めプロビジョニングされて要求時にのみ配分され／割当てられるか否かといった実装詳細から切り離されてもよい。

動作１１４４で、サービスおよびリソースが一旦プロビジョニングされると、提供されたサービスの通知が、クラウドインフラストラクチャシステム１１０２のオーダープロビ
ジョニングモジュール１１２４によって、クライアントデバイス１１０４、１１０６、および／または１１０８上の顧客へ送信されてもよい。

動作１１４６で、顧客のサブスクリプションオーダーが、オーダー管理および監視モジュール１１２６によって管理され、追跡されてもよい。場合によっては、オーダー管理および監視モジュール１１２６は、使用されるストレージの量、転送されるデータの量、ユーザの数、システムアップタイムおよびシステムダウンタイムの量といった、サブスクリプションオーダーにおけるサービスについての使用率統計を収集するように構成されてもよい。

ある実施形態では、クラウドインフラストラクチャシステム１１００は、アイデンティティ管理モジュール１１２８を含んでいてもよい。アイデンティティ管理モジュール１１２８は、クラウドインフラストラクチャシステム１１００においてアクセス管理および認証サービスなどのアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態では、アイデンティティ管理モジュール１１２８は、クラウドインフラストラクチャシステム１１０２によって提供されるサービスを利用したい顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのアクションを行なうことが認可されているかを記述する情報とを含み得る。アイデンティティ管理モジュール１１２８はまた、各顧客についての記述的情報と、その記述的情報が誰によってどのようにアクセスされ、修正され得るかについての記述的情報との管理を含んでいてもよい。

図１２は、本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステム１２００を示す。システム１２００は、上述のコンピュータシステムのうちのいずれかを実現するために使用されてもよい。図に示すように、コンピュータシステム１２００は、バスサブシステム１２０２を介して多くの周辺サブシステムと通信する処理部１２０４を含む。これらの周辺サブシステムは、処理加速部１２０６と、Ｉ／Ｏサブシステム１２０８と、記憶サブシステム１２１８と、通信サブシステム１２２４とを含んでいてもよい。記憶サブシステム１２１８は、有形のコンピュータ読取可能記憶媒体１２２２と、システムメモリ１２１０とを含む。

バスサブシステム１２０２は、コンピュータシステム１２００のさまざまなコンポーネントおよびサブシステムを意図されるように互いに通信させるためのメカニズムを提供する。バスサブシステム１２０２は単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施形態は複数のバスを利用してもよい。バスサブシステム１２０２は、さまざまなバスアーキテクチャのうちのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、強化ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準組織（Video Electronics Standards Association：ＶＥＳＡ）
ローカルバス、および周辺コンポーネント相互接続（Peripheral Component Interconnect：ＰＣＩ）バスを含んでいてもよく、それは、ＩＥＥＥ Ｐ１３８６．１規格で製造さ
れるメザニンバスとして実現可能である。

１つ以上の集積回路（たとえば、従来のマイクロプロセッサまたはマイクロコントローラ）として実現され得る処理部１２０４は、コンピュータシステム１２００の動作を制御する。処理部１２０４には、１つ以上のプロセッサが含まれていてもよい。これらのプロ
セッサは、シングルコアまたはマルチコアプロセッサを含んでいてもよい。ある実施形態では、処理部１２０４は、各処理部に含まれるシングルまたはマルチコアプロセッサを有する、１つ以上の独立した処理部１２３２および／または１２３４として実現されてもよい。他の実施形態では、処理部１２０４はまた、２つのデュアルコアプロセッサをシングルチップへと集積することによって形成されるクアッドコア処理部として実現されてもよい。

さまざまな実施形態では、処理部１２０４は、プログラムコードに応答してさまざまなプログラムを実行でき、同時に実行される複数のプログラムまたはプロセスを維持できる。任意の所与の時間において、実行されるべきプログラムコードのうちのいくつかまたはすべては、プロセッサ１２０４に、および／または記憶サブシステム１２１８にあり得る。好適なプログラミングを通して、プロセッサ１２０４は、上述のさまざまな機能性を提供できる。コンピュータシステム１２００は加えて、処理加速部１２０６を含んでいてもよく、それは、デジタル信号プロセッサ（digital signal processor：ＤＳＰ）、専用プロセッサなどを含み得る。

Ｉ／Ｏサブシステム１２０８は、ユーザインターフェイス入力デバイスと、ユーザインターフェイス出力デバイスとを含んでいてもよい。ユーザインターフェイス入力デバイスは、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システム付き音声入力デバイス、マイクロホン、および他のタイプの入力デバイスを含んでいてもよい。ユーザインターフェイス入力デバイスは、たとえば、ジェスチャーおよび口頭コマンドを使用する自然のユーザインターフェイスを通して、マイクロソフトＸｂｏｘ（登録商標）３６０ゲームコントローラなどの入力デバイスをユーザが制御し、それと対話することを可能にする、マイクロソフトＫｉｎｅｃｔ（登録商標）運動センサなどの運動感知および／またはジェスチャー認識デバイスを含んでいてもよい。ユーザインターフェイス入力デバイスはまた、ユーザから目の活動（たとえば、写真撮影中および／またはメニュー選択中の「まばたき」）を検出し、アイジェスチャーを入力デバイス（たとえば、グーグル・グラス（登録商標））への入力として変換する、グーグル・グラス（登録商標）まばたき検出器などのアイジェスチャー認識デバイスを含んでいてもよい。加えて、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを通して音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）と対話できるようにする音声認識感知デバイスを含んでいてもよい。

ユーザインターフェイス入力デバイスはまた、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルビデオカメラ、携帯型メディアプレイヤー、ウェブカメラ、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザー測距器、および視線追跡デバイスなどの音声／視覚デバイスを、何ら限定されることなく含んでいてもよい。加えて、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影装置、磁気共鳴撮像装置、ポジトロン放出断層撮影装置、医療用超音波検査装置などの医療用撮像入力デバイスを含んでいてもよい。ユーザインターフェイス入力デバイスはまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力デバイスを含んでいてもよい。

ユーザインターフェイス出力デバイスは、表示サブシステム、表示灯、または、音声出力デバイスなどの非視覚的ディスプレイを含んでいてもよい。表示サブシステムは、陰極線管（cathode ray tube：ＣＲＴ）、液晶ディスプレイ（liquid crystal display：ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネルデバイス、投影デ
バイス、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という用語の使用は、コンピュータシステム１２００からユーザまたは他のコンピュータへ情報を出力するためのあらゆる可能なタイプのデバイスおよびメカニズムを含むよう意図されている。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドホン、自動車ナビゲーションシステム、プロッタ、音声出力デバイス、およびモデムといった、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示デバイスを、何ら限定されることなく含んでいてもよい。

コンピュータシステム１２００は、現在システムメモリ１２１０内に位置するように図示されたソフトウェア要素を含む記憶サブシステム１２１８を含んでいてもよい。システムメモリ１２１０は、処理部１２０４上でロード可能および実行可能なプログラム命令、ならびに、これらのプログラムの実行中に生成されたデータを格納してもよい。

コンピュータシステム１２００の構成およびタイプに依存して、システムメモリ１２１０は、揮発性（ランダムアクセスメモリ（random access memory：ＲＡＭ）など）および／または不揮発性（読出専用メモリ（read-only memory：ＲＯＭ）、フラッシュメモリなど）であってもよい。ＲＡＭは典型的には、処理部１２０４に直ちにアクセス可能である、および／または、処理部１２０４によって現在動作され実行されている、データおよび／またはプログラムモジュールを含む。いくつかの実現化例では、システムメモリ１２１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）といった、複数の異なるタイプのメモリを含んでいてもよい。いくつかの実現化例では、起動中などにコンピュータシステム１２００内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入力／出力システム（basic input/output
system：ＢＩＯＳ）が、典型的にはＲＯＭに格納されてもよい。限定のためではなく例
として、システムメモリ１２１０はまた、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含み得るアプリケーションプログラム１２１２と、プログラムデータ１２１４と、オペレーティングシステム１２１６とを示す。例として、オペレーティングシステム１２１６は、マイクロソフト・ウィンドウズ（登録商標）、アップル・マッキントッシュ（登録商標）、および／またはリナックスオペレーティングシステムのさまざまなバージョン、商業的に入手可能なさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ様オペレーティングシステム（さまざまなＧＮＵ／リナックスオペレーティングシステム、グーグル・クローム（登録商標）ＯＳなどを何ら限定されることなく含む）、および／または、ｉＯＳ、ウィンドウズ（登録商標）フォン、アンドロイド（登録商標）ＯＳ、ブラックベリー（登録商標）１０ＯＳ、パーム（登録商標）ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムを含んでいてもよい。

記憶サブシステム１２１８はまた、いくつかの実施形態の機能性を提供するデータ構造および基本プログラミングを格納するための有形のコンピュータ読取可能記憶媒体を提供してもよい。プロセッサによって実行されると上述の機能性を提供するソフトウェア（プログラム、コードモジュール、命令）が、記憶サブシステム１２１８に格納されてもよい。これらのソフトウェアモジュールまたは命令は、処理部１２０４によって実行されてもよい。記憶サブシステム１２１８はまた、本発明に従って使用されるデータを格納するためのリポジトリを提供してもよい。

記憶サブシステム１２００はまた、コンピュータ読取可能記憶媒体１２２２にさらに接続され得るコンピュータ読取可能記憶媒体リーダ１２２０を含んでいてもよい。システムメモリ１２１０とともに、およびオプションでシステムメモリ１２１０と組合わされて、コンピュータ読取可能記憶媒体１２２２は、リモート、ローカル、固定および／またはリムーバブルの記憶装置に加えて、コンピュータ読取可能情報を一時的におよび／またはよ
り永続的に含み、格納し、伝送し、検索するための記憶媒体を包括的に表わしてもよい。

コードまたはコードの一部を含むコンピュータ読取可能記憶媒体１２２２はまた、情報の格納および／または伝送のための任意の方法または技術において実現された揮発性および不揮発性、リムーバブルおよび非リムーバブルの媒体などといった記憶媒体および通信媒体を含む、当該技術分野において公知の、または使用されている任意の適切な媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的消去可能プログラマブルＲＯＭ（electronically erasable programmable ROM：ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（digital versatile disk：ＤＶＤ）、または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、もしくは他の有形のコンピュータ読取可能媒体といった、有形のコンピュータ読取可能記憶媒体を含み得る。これはまた、所望の情報を伝送するために使用可能であり、コンピューティングシステム１２００によってアクセス可能であるデータ信号、データ伝送、または任意の他の媒体といった、非有形のコンピュータ読取可能媒体を含み得る。

例として、コンピュータ読取可能記憶媒体１２２２は、非リムーバブルの不揮発性磁気媒体との間で読出および書込を行なうハードディスクドライブ、リムーバブルの不揮発性磁気媒体との間で読出および書込を行なう磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、Ｂｌｕ－Ｒａｙ（登録商標）ディスク、または他の光学媒体といった、リムーバブルの不揮発性光ディスクとの間で読出および書込を行なう光ディスクドライブを含んでいてもよい。コンピュータ読取可能記憶媒体１２２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（universal serial bus：ＵＳＢ）フラッシュドライブ、セキュアデジタル（secure digital：ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでいてもよいが、それらに限定されない。コンピュータ読取可能記憶媒体１２２２はまた、フラッシュメモリベースのソリッドステートドライブ（solid-state drive：ＳＳＤ）、企業フラッシュドライブ、ソリッドステート
ＲＯＭといった、不揮発性メモリに基づいたＳＳＤ、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤといった、揮発性メモリに基づいたＳＳＤ、および、ＤＲＡＭベースのＳＳＤとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤを含んでいてもよい。ディスクドライブおよびそれらの関連付けられたコンピュータ読取可能媒体は、コンピュータシステム１２００のためのコンピュータ読取可能命令、データ構造、プログラムモジュール、および他のデータの不揮発性格納を提供してもよい。

通信サブシステム１２２４は、他のコンピュータシステムおよびネットワークへのインターフェイスを提供する。通信サブシステム１２２４は、コンピュータシステム１２００とは別のシステムからデータを受信し、別のシステムにデータを送信するためのインターフェイスとして機能する。たとえば、通信サブシステム１２２４は、コンピュータシステム１２００がインターネットを介して１つ以上のデバイスに接続できるようにしてもよい。いくつかの実施形態では、通信サブシステム１２２４は、（たとえば、３Ｇ、４Ｇ、またはＥＤＧＥ（enhanced data rates for global evolution：エンハンスト・データレート・フォー・グローバル・エボリューション）、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格）、または他のモバイル通信技術、またはそれらの任意の組合せといった携帯電話技術、高度なデータネットワーク技術を使用した）無線音声および／またはデータネットワークにアクセスするための無線周波数（radio frequency：ＲＦ）トランシーバコン
ポーネント、全地球測位システム（global positioning system：ＧＰＳ）受信機コンポ
ーネント、および／または他のコンポーネントを含んでいてもよい。いくつかの実施形態では、通信サブシステム１２２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえば、イーサネット）を提供できる。

いくつかの実施形態では、通信サブシステム１２２４はまた、構造化および／または非構造化データフィード１２２６、イベントストリーム１２２８、イベント更新１２３０などの形をした入力通信を、コンピュータシステム１２００を使用する１人以上のユーザのために受信してもよい。

例として、通信サブシステム１２２４は、ツイッター（登録商標）フィード、フェースブック（登録商標）更新、リッチ・サイト・サマリー（Rich Site Summary：ＲＳＳ）フ
ィードなどのウェブフィード、および／または１つ以上の第三者情報源からのリアルタイム更新といった、ソーシャルネットワークおよび／または他の通信サービスのユーザからのデータフィード１２２６をリアルタイムで受信するように構成されてもよい。

加えて、通信サブシステム１２２４はまた、リアルタイムイベントのイベントストリーム１２２８および／またはイベント更新１２３０を含み得る、明確な終わりがなく本質的に連続的または無限であり得る連続データストリームの形をしたデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを含んでいてもよい。

通信サブシステム１２２４はまた、構造化および／または非構造化データフィード１２２６、イベントストリーム１２２８、イベント更新１２３０などを、コンピュータシステム１２００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。

コンピュータシステム１２００は、ハンドヘルド携帯デバイス（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば、グーグル・グラス（登録商標）頭部装着型ディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または任意の他のデータ処理システムを含む、さまざまなタイプのうちの１つであり得る。

コンピュータおよびネットワークの絶えず変化する性質により、図に示されるコンピュータシステム１２００の説明は、単に特定の一例として意図される。図に示されるシステムよりも多い、または少ないコンポーネントを有する多くの他の構成が可能である。たとえば、カスタマイズされたハードウェアも使用されてもよく、および／または、特定の要素が、ハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組合せで実現されてもよい。さらに、ネットワーク入力／出力デバイスといった他のコンピューティングデバイスへの接続が採用されてもよい。ここに提供される開示および教示に基づいて、当業者であれば、さまざまな実施形態を実現するための他のやり方および／または方法を理解するであろう。

前述の記載では、説明の目的のため、多くの特定の詳細が、本発明のさまざまな実施形態の完全な理解を提供するために述べられた。しかしながら、これらの特定の詳細のうちのいくつかがなくても本発明の実施形態は実践され得る、ということは、当業者には明らかであろう。他の例では、周知の構造およびデバイスは、ブロック図の形で示される。

前述の記載は例示的な実施形態のみを提供しており、この開示の範囲、利用可能性、または構成を限定するよう意図されてはいない。むしろ、例示的な実施形態の前述の記載は、例示的な実施形態を実現するための実施可能な説明を当業者に提供するであろう。添付された請求項で述べられるようなこの発明の精神および範囲から逸脱することなく、要素
の機能および配置においてさまざまな変更が行なわれてもよい、ということが理解されるべきである。

前述の記載では、実施形態の完全な理解を提供するために、特定の詳細が与えられる。しかしながら、これらの特定の詳細がなくても実施形態は実践され得る、ということは、当業者には理解されるであろう。たとえば、実施形態を必要以上に詳細に記して不明瞭にすることがないように、回路、システム、ネットワーク、プロセス、および他のコンポーネントは、ブロック図の形のコンポーネントとして示されたかもしれない。他の例では、実施形態を不明瞭にしないように、周知の回路、プロセス、アルゴリズム、構造、および手法は、不要な詳細なしで示されたかもしれない。

また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明されたかもしれないということに留意されたい。フローチャートは動作を順次プロセスとして説明したかもしれないが、動作の多くは並行してまたは同時に行なうことが可能である。加えて、動作の順序は並べ替えられてもよい。プロセスは、その動作が完了すると終了するが、図に含まれない追加のステップを有していてもよい。プロセスは、方法、機能、手順、サブルーチン、サブプログラムなどに対応していてもよい。プロセスがある機能に対応している場合、その終了は、その機能が呼出し元の機能または主機能に戻ることに対応可能である。

「コンピュータ読取可能媒体」という用語は、命令および／またはデータを格納し、含み、または担持することができる、携帯型または固定式記憶装置、光学記憶装置、無線チャネル、ならびにさまざまな他の媒体を含むものの、それらに限定されない。コードセグメントまたはマシン実行可能命令が、手順、機能、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、もしくは、命令、データ構造またはプログラム文の任意の組合せを表わしてもよい。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を渡し、および／または受信することによって、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク伝送などを含む任意の好適な手段を介して渡され、発送され、または伝送されてもよい。

さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組合せによって実現されてもよい。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードで実現される場合、必要なタスクを行なうためのプログラムコードまたはコードセグメントが、マシン読取可能媒体に格納されてもよい。プロセッサが、必要なタスクを行なってもよい。

前述の明細書では、この発明の局面がその特定の実施形態に関して説明されているが、当業者であれば、この発明がそれらに限定されないことを認識するであろう。上述の発明のさまざまな特徴および局面は、個々にまたはともに使用されてもよい。また、実施形態は、明細書のより広範な精神および範囲から逸脱することなく、ここに説明されたものを超えるあらゆる数の環境および用途において利用され得る。したがって、明細書および図面は、限定的ではなく例示的であるとみなされるべきである。

加えて、例示のために、方法は特定の順序で説明された。代替的な実施形態では、方法は、説明されたものとは異なる順序で行なわれてもよい、ということが理解されるべきである。上述の方法はハードウェアコンポーネントによって行なわれてもよく、もしくは、汎用または専用プロセッサ、もしくは命令でプログラミングされた論理回路といったマシンに方法を行なわせるために使用され得るマシン実行可能命令のシーケンスで具現化され
てもよい、ということも理解されるべきである。これらのマシン実行可能命令は、１つ以上のマシン読取可能媒体、たとえば、ＣＤ－ＲＯＭまたは他のタイプの光ディスク、フロッピー（登録商標）ディスケット、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、フラッシュメモリ、もしくは、電子命令を格納するのに好適である他のタイプのマシン読取可能媒体上に格納されてもよい。それに代えて、方法は、ハードウェアとソフトウェアとの組合せによって行なわれてもよい。

Claims (20)

1. マルチテナント環境において要求をサービスするためにコンテナを使用してテナント同士を分離する方法であって、前記方法は、
   第１のテナントによって提供される第１のサービスに対する第１の要求を受信するステップと、
   前記マルチテナント環境における空コンテナを選択するステップと、
   前記第１のサービスを実現する第１の構成を前記コンテナにロードするステップと、
   前記コンテナから前記第１の要求をサービスするステップと、
   第２のテナントによって提供される第２のサービスに対する第２の要求を受信するステップと、
   前記コンテナから前記第１の構成をフラッシュするステップと、
   前記コンテナから前記第２の要求をサービスするステップとを含む、方法。
2. 前記コンテナは、クライアントデバイスからの要求をサービスするためにインスタンス化される、前記マルチテナント環境における複数のコンテナのうちの１つである、請求項１に記載の方法。
3. 前記第１の構成は、前記第１のサービスによって使用され得るメモリにおけるヒープのサイズを含む、請求項１に記載の方法。
4. 前記コンテナから前記第１の構成をフラッシュした後で、前記コンテナは、埋込まれたサーバと内部エンドポイントとを有する実行時プロセスを含む、請求項１に記載の方法。
5. 前記内部エンドポイントは、前記第２の要求をサービスするために、前記マルチテナント環境におけるルータによって呼び出される、請求項４に記載の方法。
6. 前記第１の構成は、要求をサービスするためにともにつながれる複数のアクションを含む、請求項１に記載の方法。
7. 前記マルチテナント環境は、前記コンテナが、異なるテナントに関連付けられた要求を同時にサービスすることを防止する、請求項１に記載の方法。
8. 前記マルチテナント環境は、前記コンテナが、単一のテナントに関連付けられた要求を同時にサービスすることを可能にする、請求項１に記載の方法。
9. 前記第２のテナントによって提供される前記第２のサービスに対する第３の要求を受信するステップと、
   前記コンテナから第２の構成をフラッシュすることなく、前記コンテナから前記第３の要求をサービスするステップとをさらに含む、請求項１に記載の方法。
10. 前記第１のサービスは、前記マルチテナント環境を通して利用可能になるパブリックＡＰＩを含む、請求項１に記載の方法。
11. １つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含む、非一時的コンピュータ読取可能媒体であって、前記動作は、
    第１のテナントによって提供される第１のサービスに対する第１の要求を受信することと、
    前記マルチテナント環境における空コンテナを選択することと、
    前記第１のサービスを実現する第１の構成を前記コンテナにロードすることと、
    前記コンテナから前記第１の要求をサービスすることと、
    第２のテナントによって提供される第２のサービスに対する第２の要求を受信することと、
    前記コンテナから前記第１の構成をフラッシュすることと、
    前記コンテナから前記第２の要求をサービスすることとを含む、非一時的コンピュータ読取可能媒体。
12. 前記第１の構成は、前記第１のサービスによって使用され得るメモリにおけるヒープのサイズを含む、請求項１１に記載の非一時的コンピュータ読取可能媒体。
13. 前記コンテナから前記第１の構成をフラッシュした後で、前記コンテナは、埋込まれたサーバと内部エンドポイントとを有する実行時プロセスを含む、請求項１１に記載の非一時的コンピュータ読取可能媒体。
14. 前記内部エンドポイントは、前記第２の要求をサービスするために、前記マルチテナント環境におけるルータによって呼び出される、請求項１３に記載の非一時的コンピュータ読取可能媒体。
15. 前記第１の構成は、要求をサービスするためにともにつながれる複数のアクションを含む、請求項１１に記載の非一時的コンピュータ読取可能媒体。
16. システムであって、
    １つ以上のプロセッサと、
    １つ以上のメモリデバイスとを含み、前記１つ以上のメモリデバイスは、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含み、前記動作は、
    第１のテナントによって提供される第１のサービスに対する第１の要求を受信することと、
    前記マルチテナント環境における空コンテナを選択することと、
    前記第１のサービスを実現する第１の構成を前記コンテナにロードすることと、
    前記コンテナから前記第１の要求をサービスすることと、
    第２のテナントによって提供される第２のサービスに対する第２の要求を受信することと、
    前記コンテナから前記第１の構成をフラッシュすることと、
    前記コンテナから前記第２の要求をサービスすることとを含む、システム。
17. 前記第１の構成は、前記第１のサービスによって使用され得るメモリにおけるヒープのサイズを含む、請求項１６に記載のシステム。
18. 前記コンテナから前記第１の構成をフラッシュした後で、前記コンテナは、埋込まれたサーバと内部エンドポイントとを有する実行時プロセスを含む、請求項１６に記載のシステム。
19. 前記内部エンドポイントは、前記第２の要求をサービスするために、前記マルチテナント環境におけるルータによって呼び出される、請求項１８に記載のシステム。
20. 前記第１の構成は、要求をサービスするためにともにつながれる複数のアクションを含む、請求項１６に記載のシステム。

Images