JP7575845B2 - マルチ・テナント型サーバレス環境のための多層キャッシュ・メッシュ・システム - Google Patents

Description

本発明は、一般に、デジタル・コンピュータ・システムの分野に関し、より具体的には、作業負荷環境内のノード上でのステートレス・サービスのコンピュータ実施の実行に関する。

クラウド・コンピューティング・プラットホーム上及びクラウド・フレームワークにしばしばデプロイされる最近のコンピューティング環境は、複数の対話サービス若しくはマイクロ・サービス又はそれらの両方で構成される。そのようなマイクロ・サービスの特徴の１つは、それらが多くの場合、ステートレスであること、即ち、マイクロ・サービスのある起動から次の起動まで状態（ステート）が持続しないことである。しかし、いくつかの場合には、マイクロ・サービスのステートを、マイクロ・サービスの次のコールのために利用可能にすることが有用である。このことは、トランザクション・アプリケーションのための基本技術、例えば、技術的な電子取引インフラストラクチャとして興味深いだけでなく、クラウド・コンピューティング・フレームワーク、若しくはクラウド・コンピューティング環境内のマルチプロセッサ・システム、又はそれらの両方の管理のためにも興味深い。そのようなリソースは、異なる条件、性能レベル及びサービス・レベル・アグリーメントの下で、異なるプロバイダ機構から利用可能な場合がある。しかし、そのようなリソースのリソース管理が、ステートレスなサービス若しくはマイクロ・サービス又はそれらの両方の対話に基づくものでもある場合には、そのような状況において、それぞれのサービス／マイクロ・サービスの「古い」ステートにアクセスすることも有用であろう。

クラウド・プロバイダは、典型的には、クライアントがサービス・コンピューティング環境のリソースをサブスクライブして使用することができる物理又は仮想コンピューティング・リソースを提供し、一方、クラウド・プロバイダは、割り当てと基盤となるコンピューティング及びネットワーク・インフラストラクチャを管理することができる。この運用モデルは、クライアントにとって、運用コストを最適化することができるので有利である。他方、クラウド・プロバイダの正当な関心は、そのビジネス・モデルが実現可能であるように運用及び投資コストを最小にすることである。従って、クラウド・プロバイダは、典型的には、コンピュータ・リソース割り当てを制限し、その制限は、通常、特定のプログラミング方法によってサポートされる。従って、基盤となるプログラミング・モデルは、ステートレスでイベント駆動の処理時間が限定されるサーバレス・モデルである。

特定の実行要件に対しては有利であるが、このモデルは、幾つかの欠点も有する。明らかなことに、１つの欠点は、ステートレスであることであり、即ち、データ又はステート情報が、機能のある実行サイクルから次の実行サイクルへ、あるいは、異なる機能又はサービスの間で、容易に共用することができないことである。

作業負荷実行環境内のノード上でのステートレス・サービスの実行のための方法に関連する幾つかの開示が存在する。

特許文献ＵＳ ８１１２５２５ Ｂ２は、クラスタ・ネットワーク環境上で分散されたエンジン層及びステート層を備えたセッション開始プロトコル（ＳＩＰ）サーバを開示している。エンジン層は、種々のメッセージを送信し、受信し、処理することができる。ステート層は、種々のＳＩＰセッションに関連付けられるインメモリ・ステート・データを維持することができる。ステート層に含まれるステート・データの一部のローカル・コピーを維持するために、エンジン層にニア・キャッシュを常駐させることができる。エンジン層の種々のエンジンは、ニア・キャッシュが、ステート層からステート・データを検索する前に、メッセージを処理するために必要なステートの現在のバージョンを含むかどうかを判断することができる。

特許文献ＵＳ ８１６１１６３ Ｂ２は、サーバ・ステート情報を保持するステート・キャッシング・オブジェクトが、サーバ上ではなくクラインアント又はネットワーク内に維持されることを可能にするステートレス分散コンピュータ・アーキテクチャを開示している。一実施において、そのコンピュータ・アーキテクチャは、分散コンポーネント・オブジェクト・モデル（ＤＣＯＭ）によるオブジェクト指向プログラム・モジュールを実施する。オブジェクト指向ネットワーク・プロトコル（例えば、遠隔手続き呼び出し）を用いて、クライアント側のアプリケーションは、アプリケーション・プログラム・インターフェースを通して、サーバ・コンピュータ上に常駐するプログラム・オブジェクトを呼び出す。そのプログラム・オブジェクトは、呼び出しに応じて、クライアント接続に適するステート情報を含むステート・キャッシング・オブジェクトを作成する。サーバは、ステート・キャッシング・オブジェクトをローカル・スレット・コンテキスト内に挿入し、そのリクエストを処理して応答を生成する。

しかし、既知の解決策の欠点は、それらが、多くの場合、作業負荷実行環境内の永続的ストレージを介したステートの維持のフォーカスしていることであろう。従って、柔軟な作業負荷実行環境内で、ステートレス・ソフトウェア・コンテナのためのよりダイナミックなステート管理を提供する必要性があるであろう

本発明の実施形態は、作業負荷環境内のノード上でステートレス・サービスを実行するための方法、コンピュータ・システム、及びコンピュータ・プログラム製品を開示する。本発明は、複数のノードのそれぞれのノードについて少なくとも１つの作業負荷コンテナを定義することを含むことができ、少なくとも１つの作業負荷コンテナは、キャッシュ・メッシュのキャッシュ・コンポーネントを含み、キャッシュ・メッシュは、複数のキャッシュ・コンポーネントを含み、複数のキャッシュ・コンポーネントは、互いの間の通信用プロトコルを含む。

一態様によれば、本発明は、実行コンテナ内のキャッシュ・メッシュの複数のキャッシュ・コンポーネントの１つから、ステートレス要求サービスからのステート要求を受信することに応答して、ステート要求と関連付けられた要求されたステートが、関連する実行コンテナのキャッシュ・コンポーネント内に存在するかどうかを判断することを含むことができる。

一態様によれば、本発明は、キャッシュ・ミスに応答して、キャッシュ・メッシュの複数のキャッシュ・コンポーネントの他のキャッシュ・コンポーネントに対して、ステート要求をブロードキャストすることを含むことができる。

一態様によれば、本発明は、キャッシュ・メッシュの複数のキャッシュ・コンポーネントの他のキャッシュ・コンポーネントによって、要求されたステートが他のキャッシュ・コンポーネントのそれぞれのキャッシュ内に存在するかどうか判断することを含むことができる。

一態様によれば、本発明は、いずれかのキャッシュ・コンポーネントが要求されたステートを識別することに応答して、要求されたステートを、通信用プロトコルを用いて要求サービスへ送信することを含むことができる。

本発明の別の態様により、作業負荷実行環境内のノード上でステートレス・サービスを実行するための関連するキャッシュ・メッシュ・システムを提供することができる。作業負荷実行環境は、複数のノードを含むことができる。キャッシュ・メッシュ・システムは、複数のノードの各々について、キャッシュ・メッシュの一部であるキャッシュ・コンポーネントを含む少なくとも１つの作業負荷コンテナの定義を格納するように適合されたストレージを含むことができる。キャッシュ・メッシュのキャッシュ・コンポーネントは、互いの間の通信用プロトコルを使用することができる。

キャッシュ・メッシュ・システムは、さらに、実行コンテナ内のキャッシュ・メッシュのキャッシュ・コンポーネントの１つから、ステートレス要求サービスからのステート要求を受信すると、要求されたステートが、関連する実行コンテナのキャッシュ・コンポーネント内に存在するかどうかを判断することと、キャッシュ・ミスの際に、キャッシュ・メッシュのキャッシュ・コンポーネントに対してステート要求をブロードキャストし、キャッシュ・メッシュの他のキャッシュ・コンポーネントによって、要求されたステートがそれぞれのキャッシュ内に存在するかどうか判断し、いずれかのキャッシュ・コンポーネントが要求されたステートを識別すると、要求されたステートを、プロトコルを用いて要求サービスへ送信することとを含むことができる。

作業負荷環境内のノード上でステートレス・サービスを実行するための、提案されたコンピュータ実施の方法は、複数の利点、技術的効果若しくは向上又はこれらのすべてを提供することができる。

特に、キャッシュ・メッシュ・コンポーネント間の通信プロトコルの階層暗号化によって達成することができる、マルチ・テナント環境において安全に機能することもできる能力によって、従来技術の制限を克服することができる。さらに、本明細書において提案される概念は、キャッシュ・メッシュ・コンポーネントの形態のいわゆるサイドカー・コンテナを使用することによって、異なるポッドの間で欠落している分離を克服する。既存の元のサイドカー概念及びＫｕｂｅｒｎｅｔｅｓは、マルチ・テナントを可能にするようには設計されていない。

従って、提案される概念は、ステートレス・サービスのレベル１（Ｌ１）キャッシュの間でコンテンツを交換することを可能にすることができる。これにより、Ｌ１キャッシュ・サービスのプールは、キャッシュ・メッシュと呼ぶことができる。さらに、本明細書で提案される概念は、キャッシュ・メッシュ・コンポーネントの間で共通ステートを交換するように設定される多層キャッシュによって、強化することができる。そのために、キャッシュ・メッシュは、キャッシング・サービスの、特に、例えば、Ｊａｖａ、ｎｏｄｅ．ｊｓ、Ｐｈｙｔｈｏｎなどの同じ実行言語を用いるか又は作業負荷コンテナの同じ実行環境で実行される、類似のタイプの作業負荷を伴うサービスのための、プールである。

従って、本明細書で提案される概念は、キャッシュ・メッシュ実装を維持する実際の作業負荷実行環境の隣のサイドカー・コンポーネントに依存することができる。キャッシュ・メッシュを設定するために、使用されるプロトコルは、作業負荷タイプの理解によって拡張することができる。それによって、作業負荷タイプは、それらの実行パターン（例えば、ランタイム・エンジン、テナント情報若しくは他のメタデータ又は両方）に基づいて、定義することができる。作業負荷実行エンジンは、プル・アンド・プッシュに基づくモデルで、キャッシュ・メッシュ・サイドカーと対話することができる。一貫した第２レベルのキャッシュを確実にするために、集中キャッシュ・コンポーネント（Ｌ２）を用いて、異なるタイプの作業負荷の間でステートを共有することができる。従って、Ｌ１キャッシュ・メッシュのステートは、集中キャッシュ・コンポーネント（Ｌ２）内に格納される統一形式に変換することができる。最後に、グローバル・スケジューラ・コンポーネントが導入され、これにより、異なる位置における異なるクラスタ間であっても、安全な暗号キーに基づいて、ユーザの作業負荷の適切なルーティングを確実にすることができる。

最後に、伝統的なマルチ・テナント型サーバレス環境においては、実行コードと、実行のためのスケジュールされたノードとは相関を有しない。同じ機能の実行のために同じノードを使用することはできない。しかし、アップしているすべてのノードは、そのキャッシュ内に同じステートを保存することができる。サイドカーのメッシュを作成することにより、キャッシュされたステートは、異なるキャッシュ・メッシュ・コンポーネントの間で共有することができる。

以下では、本発明の概念の、本方法並びに関連するシステムに適用可能な、付加的な実施形態が説明されることになる。

本方法の１つの有用な実施形態によれば、通信用プロトコルを暗号化することができる。従って、キャッシュ間通信の安全性は損なわれないであろう。したがって、提供される作業負荷環境は、安全保護規格に従うように適合させることもできる。ユーザは、安全性の心配なく、それを使用することができる。

有利な一実施形態によれば、本方法は、さらに、ノード上での実行コンテナの実行が完了すると、又は完了に応答して、キャッシュ・メッシュに対して終了ステートをブロードキャストすることを含むことができる。したがって、実行が終了した実行コンテナのステートを要求するいずれかの他のノードは、通知を受けることができる。付加的な通信プロトコルは不要であろう。

別の有利な実施形態によれば、本方法は、さらに、複数のノードについての第１の集中キャッシュ・コンポーネントを準備することを含むことができる。これは、受信されたデータ、例えばステート情報を永続的に格納することができるノード（及び作業負荷コンテナ、例えばポッド）のためのレベル２キャッシュとみなすことができる。

別の有利な実施形態によれば、本方法は、さらに、要求されたステートが、キャッシュ・メッシュのいずれのキャッシュ・コンポーネント内でも入手できないと判断すると、要求されたステートを第１の集中キャッシュ・コンポーネントからロードすることを含むことができる。このことは、永続的キャッシュ・ミスを伴う状況を表す可能性がある。したがって、データ、例えば以前のステートを、例えばレベル２キャッシュとして機能する第１の集中キャッシュ・ストレージからロードすることができる。

本方法の１つのパーミッシブな実施形態によれば、通信用プロトコルは、ユーザの識別子、キャッシュされた値を識別するキー、及びキャッシュされた値（例えば、キャッシュ識別子を介して）からなる群から選択されたコンポーネントを含むことができる。さらに、他のパラメータ、例えば固有の作業負荷実行環境についてのパラメータが、交換されたプロトコル・データを強化することができる。

別のパーミッシブな実施形態によれば、本法はさらに、それぞれのノード上での実行コンテナの実行の完了に応答して、第１の集中キャッシュ・コンポーネントに対して終了ステートをブロードキャストすることを含むことができる。このステートの送信は、キャッシュ・メッシュの他のメンバ（例えば、キャッシュ・コンポーネント）へのステート送信と並行して行うことができる。したがって、実行コンテナの最後のステートは、いずれにしても永続的にセーブすることができる。これはまた、サービス（例えば、作業負荷コンテナ）の再インスタンス化の後に、同じサービス（例えば、新しいインスタンス）によって使用することができる。

本方法の１つの強化された実施形態によれば、キャッシュ・メッシュのキャッシュ・コンポーネントは、同等の作業負荷タイプを有するキャッシュ・コンポーネントのプールを含む。同等の作業負荷タイプは、同一のランタイム・エンジン（例えば、Ｊａｖａ、又はｎｏｄｅ．ｊｓ）、ユーザ情報（例えば、ユーザＩＤ）、及び同一のプログラミング言語からなる群から選択される実行パターンを含むことができる。幾つかの実施形態において、他のメタデータがさらに、同等の作業負荷タイプを定めることができる。このことはまた、使用される作業負荷実行環境に応じて定義することができる。

１つの拡張された実施形態により、本方法はさらに、第２の集中キャッシュ・コンポーネントを、複製プロトコルを用いて第１の集中キャッシュ・コンポーネントと同期させることを含むことができる。一実施形態において、第２の集中キャッシュ・コンポーネントは、第２の遠隔作業負荷実行環境内に保持することができる。それにより、提案される概念は、ローカル・コンピューティング環境（例えば、１つの単一データセンタ）だけでなく、データ・センタ間にわたって、さらには国や大陸間にわたって、機能することになる。従って、グローバルに活動するクラウド・コンピューティング・プロバイダにおける提案される概念の世界的な利用が可能になる。

さらに、実施形態は、コンピュータ使用可能又はコンピュータ可読媒体からアクセス可能な、関連するコンピュータ・プログラム製品の形態をとることができ、コンピュータ又は任意の命令実行システムによる、又は、それらに関連する使用のためのプログラム・コードを提供する。この説明のために、コンピュータ使用可能又はコンピュータ可読媒体は、命令実行システム、装置、又はデバイスによる、又は、それらに関連する使用のためのプログラムを格納し、通信し、伝搬し、又は移送するための手段を含むことができる任意の装置とすることができる。

本発明の実施形態は、種々異なる主題に関して説明されることに留意されたい。特に、幾つかの実施形態は、方法タイプの特許請求に関して説明され、他の実施形態は装置タイプの特許請求に関して説明される。しかし、当業者であれば、上記及び以下の説明から、別に公示されない限り、１つのタイプの主題に属する特徴の任意の組み合わせに加えて、異なる主題に関連する特徴の間、具体的には、方法タイプの特許請求の特徴と装置タイプの特許請求の特徴との間の任意の組み合わせもまた、本文書内で開示されていると考えられることを推測するであろう。

本発明の上記の態様及びさらに別の態様は、以下で説明される実施形態の例から明白となり、実施形態の例に関して説明されるが、本発明はそれらに限定されない。

本発明の好ましい実施形態が、例としてのみ、以下の図面を参照しながら説明されることになる。

少なくとも１つの実施形態による、作業負荷環境内のノード上でのステートレス・サービスの実行のためのプロセスを示すオペレーショナル・フローチャートである。 少なくとも１つの実施形態による、数個のノードを伴う実行環境のブロック図である。 少なくとも１つの実施形態による、実行環境の遠隔位置における拡張のブロック図である。 少なくとも１つの実施形態による、作業負荷環境内のノード上でのステートレス・サービスの実行のためのキャッシュ・メッシュ・システムのブロック図である。 少なくとも１つの実施形態による、図４のキャッシュ・メッシュ・システムを備えたコンピュータ・システムの内部及び外部コンポーネントのブロック図である。 本開示の一実施形態による、図５に示されたコンピュータ・システムを含む例証的なクラウド・コンピューティング環境のブロック図である。 本開示の一実施形態による、図６の例証的なクラウド・コンピューティング環境の機能層のブロック図である。

本説明の文脈において、以下の慣例、用語若しくは表現又はこれらのすべてが使用される場合がある。

本開示の少なくとも１つの実施形態により、用語「ステートレス・サービス（stateless service）」は、可能なときにはいつでもステート・データからスケーラブル・サービスを分離することによってそれらを設計するために、サービス指向設計パラダイム内で適用される設計原理に基づくコンピューティング機能を表すことができる。任意の２つのソフトウェア・プログラムの対話は、その後の対話が２つのソフトウェア・プログラムの間の以前の対話の結果に依存し得るので、対話固有のデータのトラックを保持することを含むことができる。しかし、ステートレス・コンピューティング環境においては、ソフトウェアのステートは、その実行が終了した後には維持されない。他の機構を使用するためにはステートの移送が必要となり得る。

本開示の少なくとも１つの実施形態により、用語「ノード（node）」は、使用されるクラスタに応じて、物理的コンピューティング機械又は仮想機械を表すことができる。各々のノードは、マスター・コンポーネントによって管理することができる。単一の機能又はサービスは、作業負荷コンテナ、作業負荷実行コンテナ、又は、作業負荷実行環境としてＫｕｂｅｒｎｅｔｅｓを使用する場合にはいわゆるポッドとして、実施することができる。

本開示の少なくとも１つの実施形態により、用語「作業負荷実行環境（workload execution environment）」は、クラスタ、ノード、並びに作業負荷コンテナ、例えば、特定のサービスにファイルするためのノード内のポッド、の定義を可能にするプログラミング・フレームワークを表すことができる。作業負荷実行環境の例としては、Ｍａｒａｔｈｏｎ ｆｏｒ Ａｐａｃｈｅ Ｍｅｓｏｓ（登録商標）（Ａｐａｃｈｅ Ｍｅｓｏｓ及び全てのＡｐａｃｈｅベースの商標及びロゴは、Ａｐａｃｈｅソフトウェア財団若しくはそのアフィリエート又はそれらの両方の商標又は登録商標である）、Ｄｏｃｋｅｒ（登録商標）Ｓｗａｒｍ（Ｄｏｃｋｅｒ及び全てのＤｏｃｋｅｒベースの商標及びロゴは、Ｄｏｃｋｅｒ社若しくはそのアフィリエート又はそれらの両方の商標又は登録商標である）、ＣｏｒｅＯＳ（登録商標）（ＣｏｒｅＯＳ及びすべてのＣｏｒｅＯＳベースの商標及びロゴは、ＣｏｒｅＯＳ社若しくはそのアフィリエート又はそれらの両方の商標すべて登録商標である）、ＲＥＤ Ｈａｔ Ｏｐｅｎｓｈｉｆｔ（登録商標）（ＲＥＤ Ｈａｔ Ｏｐｅｎｓｈｉｆｔ及びすべてのＲＥＤ Ｈａｔベースの商標及びロゴは、ＲＥＤ Ｈａｔ社若しくはそのアフィリエすべて又はそれらの両方の商標又は登録商標である）、及びＫｕｂｅｒｎｅｔｅｓ（登録商標）（Ｋｕｂｅｒｎｅｔｅｓ及びすべてのＫｕｂｅｒｎｅｔｅｓベースの商標及びロゴは、リナックス・ファウンデーション（Ｌｉｎｕｘ Ｆｏｕｎｄａｔｉｏｎ）若しくはそのアフィリエート又はそれらの両方の商標又は登録商標である）が挙げられる。

本開示の少なくとも１つの実施形態により、用語「作業負荷コンテナ（workload container）」は、作業負荷実行環境内でサービス又はマイクロ・サービスを供給することが可能な最小の内蔵ユニットを表すことができる。種々の実施形態において、用語「作業負荷実行コンテナ（workload execution container）」が使用される場合がある。

本開示の少なくとも１つの実施形態により、用語「キャッシュ・コンポーネント（cache component）」は、作業負荷コンテナのためのローカル・メモリとして使用される、作業負荷コンテナ内の特定のコンポーネントを表すことができる。キャッシュ・コンポーネントに関連するメモリは、作業負荷コンテナ又はサービスのステートを格納することができる。しかし、作業負荷コンテナがその実行を終了すると、キャッシュ・コンポーネント及び関連するメモリ内のデータは消える場合がある。従って、伝統的な作業負荷実行環境において、作業負荷コンテナ及びキャッシュ・コンポーネント内のステート情報は持続しない場合がある。本開示の実施形態はこの限界を克服することができる。

本開示の少なくとも１つの実施形態により、用語「キャッシュ・メッシュ（cache-mesh）」は、例えばノードにわたって及び同じノード内の作業負荷コンテナにわたって、ステート・データを交換することができる、クラスタ内の異なるノードにわたるキャッシュ・コンポーネントの緩く結合されたネットワークを表すことができる。

本開示の少なくとも１つの実施形態により、用語「キャッシュ・ミス（cache miss）」は、あるサービスが、そのキャッシュ・メモリに必要なステート・データにアクセスできないことを表すことができる。

本開示の少なくとも１つの実施形態により、用語「互いの間の通信用プロトコル（protocol for a communication between each other）」は、クラスタ内のキャッシュ・コンポーネントの間でメッセージ及びデータを交換するための通信プロトコルを表すことができる。提案される概念の拡張バージョンにより、キャッシュ・コンポーネントの間の通信用プロトコルは、異なる地域内のクラスタにわたって機能することもできる。プロトコルは、暗号化メッセージを使用することができる。

本開示の少なくとも１つの実施形態により、用語「ステート要求（state request）」は、クラスタ内の（又はクラスタにわたる）１つのキャッシュ・コンポーネントから任意の他のキャッシュ・コンポーネントへの要求を表すことができる。ステート要求は、ブロードキャストの形態で発信することができる。要求されたステートを配信することができる受信キャッシュ・コンポーネントは、その要求されたステートを、要求キャッシュ・コンポーネントへ返信することができる。

本開示の少なくとも１つの実施形態により、用語「集中キャッシュ・コンポーネント（centralized cache component）」は、種々のノード内の種々の実行コンテナのステート情報を永続的に格納するように適合された、クラスタ内の永続的ストレージを表すことができる。従って、種々の作業負荷コンテナの種々のキャッシュ・コンポーネントの間でステート・データを交換する代わりに、ステート情報を第１の集中キャッシュ・コンポーネントから要求することもできる。提案される概念は、第１の集中キャッシュ・コンポーネント及び第２の集中キャッシュ・コンポーネントに関する。それらは、第１の集中キャッシュ・コンポーネントのコンテンツを遠隔クラスタ及び他の集中キャッシュ・コンポーネントに利用可能にすることができる（逆も可能）という意味で互いに関連するだけである。両方の集中キャッシュ・コンポーネントは、ステート・ルータを用いて所定のプロトコルにより同期させることができる。

本開示の少なくとも１つの実施形態により、用語「遠隔作業負荷実行環境（remote workload execution environment）」は、初めの作業負荷実行環境から見て遠隔地にある第２のクラスタを表すことができる。

本開示の少なくとも１つの実施形態により、用語「クラウド・コンピューティング（cloud computing）」及び「クラウド・サービス環境（cloud service environment）」は、この文脈においては、最小の経営努力又はサービス・プロバイダの対話によって迅速に準備及び解除することができる構成可能なコンピューティング・リソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービス）の共用プールへの、便利でオンデマンドのネットワーク・アクセスを可能にするためのモデルとして解釈することができる。このクラウド・モデルは、可用性を高め、少なくとも五つの本質的特性、３つのサービス・モデル及び４つのデプロイメント・モデルで構成される。

クラウド・コンピューティングの本質的特性は以下を含む。
（ｉ）オンデマンド・セルフ・サービス。コンシューマは、各々のサービス・プロバイダと人的対話を必要とすることなく、サーバ・タイム及びネットワーク・ストレージのようなコンピューティング機能を、必要に応じて自動で一方的に準備することができる。
（ｉｉ）広いネットワーク・アクセス。機能は、ネットワーク上で利用可能であり、異種のシン又はシック・クライアント・プラットホーム（例えば、携帯電話、ラップトップ、及びＰＤＡｓ）による使用を促進する標準的機構を通してアクセスされる。
（ｉｉｉ）リソース・プーリング。プロバイダのコンピューティング・リソースがプールされ、マルチ・テナント・モデルを用いて、多数のコンシューマに、コンシューマの要求に従って動的に割り当て及び再割り当てされる種々の物理的及び仮想リソースを提供する。カスタマは、一般に、提供されるリソースの正確な位置についての制御又は知識を有しないが、高レベルで抽象化された位置（例えば、国、州、又はデータセンタ）を指定することはできる。リソースの例は、ストレージ、処理、メモリ、ネットワーク帯域幅及び仮想機械を含む。
（ｉｖ）迅速な弾力性。機能は、迅速にスケールアウトし、迅速にリリースしてスケールインするように、場合によっては自動的に、迅速かつ弾力的にプロビジョニングすることができる。コンシューマにとっては、プロビジョニングのために利用可能な機能は無制限であるように見えることが多く、任意の量を任意の時間に購入することができる。
（ｖ）実績によるサービス（Measured Service）。クラウド・システムは、サービスのタイプ（例えば、ストレージ、処理、帯域幅、及びアクティヴ・ユーザのアカウント）に適した抽象レベルの計量機能を活用することによって、リソースの使用を自動的に制御し、最適化する。リソースの使用は、監視、制御及びレポートすることができ、利用されるサービスのプロバイダ及びコンシューマの両方に対して透明性をもたらす。

使用されるクラウド・コンピューティングのサービス・モデルは以下を含む。
（ｉ）サービスとしてのクラウド・ソフトウェア（ＳａａＳ）。コンシューマに提供される機能は、クラウド・インフラストラクチャ上で実行されるプロバイダのアプリケーションを使用することである。アプリケーションは、種々のクライアント・デバイスから、ウェブ・ブラウザ（例えば、ウェブ・ベースのｅメール）などのシン・クライアント・インターフェースを通してアクセス可能である。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、ストレージ、又はさらに個々のアプリケーションの機能を含む、基盤となるクラウド・インフラストラクチャを、限定されたユーザ固有のアプリケーション構成設定は例外となる可能性はあるが、管理又は制御しない。
（ｉｉ）サービスとしてのクラウド・プラットホーム（ＰａａＳ）。コンシューマに提供される機能は、プロバイダによってサポートされるプログラミング言語及びツールを用いて作成されたコンシューマ作成又は獲得のアプリケーションを、クラウド・インフラストラクチャ上にデプロイすることである。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、又はストレージを含む、基盤となるクラウド・インフラストラクチャを管理又は制御しないが、デプロイされたアプリケーション及び場合により環境構成をホストするアプリケーションについての制御を有する。
（ｉｉｉ）サービスとしてのクラウド・インフラストラクチャ（ＩａａＳ）。コンシューマに提供される機能は、処理、ストレージ、ネットワーク、及び他の基本的なコンピューティング・リソースを準備することであり、コンシューマは、オペレーティング・システム及びアプリケーションを含むことができる任意のソフトウェアをデプロイし、実行することができる。コンシューマは、基盤となるクラウド・インフラストラクチャを管理又は制御しないが、オペレーティング・システム、ストレージ、デプロイされたアプリケーションについての制御、及び場合により選択されるネットワーキング・コンポーネント（例えば、ホスト・ファイヤウォール）の限定された制御を有する

クラウド・コンピューティングのためのデプロイ・モデルは以下を含む。
（ｉ）プライベート・クラウド。クラウド・インフラストラクチャは、一組織のみによって単独で運用される。クラウド・インフラストラクチャは、その組織又は第三者によって管理することができ、構内又は構外に存在することができる。
（ｉｉ）コミュニティ・クラウド。クラウド・インフラストラクチャは、数個の組織によって共用され、共有する関心事（例えば、ミッション、安全要件、ポリシ、及びコンプライアンス考慮）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、それら組織又は第三者によって管理することができ、構内又は構外に存在することができる。
（ｉｉｉ）パブリック・クラウド。クラウド・インフラストラクチャは、一般市民又は大規模産業グループに利用可能とされ、クラウド・サービスを販売する組織によって所有される。
（ｉｖ）ハイブリッド・クラウド。クラウド・インフラストラクチャは、固有のエンティティのままでありながら、データ及びアプリケーションの可搬性を可能にする標準化された技術又は独自の技術（例えば、クラウド間の負荷均衡化のためのクラウド・バースティング）によって結合された、２つ又はそれ以上のクラウド（プライベート、コミュニティ、又はパブリック）の混成物である。

クラウド・ソフトウェアは、ステートレス性（例外あり）、低結合、モジュール性、及び意味相互運用性に焦点をあてたサービス指向であることによって、クラウド・パラダイムを十分に利用していることに留意されたい。

以下に、図の詳細な説明が与えられることになる。図中の全ての説明は概要である。第１にすべて業負荷環境内のノード上でステートレス・サービスを実行するためのコンピュータ実施方法の一実施形態のブロック図が与えられる。その後、さらに別の実施形態並びに作業負荷実行環境内のノード上でステートレス・サービスを実行するためのキャッシュ・メッシュ・システムの実施形態が説明されることになる。

ここで図１を参照すると、作業負荷実行環境内のノード上でステートレス・サービス（例えば、アプリケーション）を実行するための、特に実行を加速するための、コンピュータ実施プロセス１００の例示的な一実施形態を示すオペレーショナル・フローチャートである。作業負荷実行環境の主要なターゲットは、Ｋｕｂｅｒｎｅｔｅｓとすることができる。しかし、このコンセプトは、Ｍａｒａｔｈｏｎ ｆｏｒ Ａｐａｃｈｅ Ｍｅｓｏｓ、Ｄｏｃｋｅｒ Ｓｗａｒｍ、ＣｏｒｅＯＳ、及びＲｅｄ Ｈａｔ Ｏｐｅｎｓｈｉｆｔのような他の同等の作業負荷実行環境と両立させることもできる。

１０２において、プロセス１００は、複数のノードの各々について、少なくとも１つの作業負荷コンテナを定義することを含む。一実施形態によれば、作業負荷実行環境は、複数のノードを含むことができる。複数のノードの各々について、（少なくとも）キャッシュ・コンポーネントを含む少なくとも１つの作業負荷コンテナ、例えば、Ｋｕｂｅｒｎｅｔｅｓにおける１つのポッドを、定義することができる。一実施形態において、キャッシュ・コンポーネントは、キャッシュ・メッシュの一部とすることができる。説明したように、キャッシュは、レベル１のキャッシュとして機能することができる。作業負荷コンテナはまた、例えば、Ｊａｖａランタイム、ｎｏｄｅ．ｊｓランタイムなどに類似したランタイム環境を備えることもできる。

一実施形態において、キャッシュ・メッシュのキャッシュ・コンポーネントは、完全には結合されなくてもよい。従って、キャッシュ・コンポーネントは、互いの間の通信用プロトコルを実装することができる。通信の一般原理は、作業負荷コンテナのキャッシュに対して、同一又は類似の実行パターンをブロードキャストすることによって行うことができる。これにより、ブロードキャストの範囲を限定し、従って高性能な環境をサポートすることができる。

１０４において、プロセス１００は、実行コンテナ内（例えば、ポッド内）のキャッシュ・メッシュのキャッシュ・コンポーネントの１つから、ステートレス要求サービスからのステート要求を受信すると、１０６において、要求されたステートが、関連する実行コンテナの、特にステートレス要求サービスに関連するキャッシュ・コンポーネント内に存在するかどうか判断することを行うことを含む。

ステップ１０８において、プロセス１００は、キャッシュ・ミスの際には、１１０において、類似の実行パターンを有するキャッシュ・メッシュのキャッシュ・コンポーネントに対してステート要求をブロードキャストすることを含む。プロセス１００はさらに、１１２において、キャッシュ・メッシュの他のキャッシュ・コンポーネントによって、要求されたステートがそれぞれのキャッシュ内に存在するかどうかを判断することと、いずれかのキャッシュ・コンポーネントが要求されたステートを識別すると、１１４において、要求されたステートを、プロトコルを用いて要求サービスへ送信すること（例えば、それを返送すること）とを含む。ノードは、他のデバイスとして又は仮想マシンとして実装することができることに留意されたい。

プロセス１００は、ユーザがステート操作を伴うサーバレス機能に基づいて電子取引サイトを設定することを望む場合の以下の例を用いて、例示することができる。

ショッピング・カートは、ステート情報を必要とする例である。従って、カスタマがある商品を自分のカートに加える場合、サーバレス機能は、彼の暗号キーを投入する電子取引ステートレス・アプリケーションによって起動されることになる。スケジューラ・コンポーネントは、カスタマを識別し、キャッシュ・ミスの可能性に備えるようにＬ２キャッシュ（例えば、中央キャッシュ・コンポーネント）に通知する。さらに、要求は、決定された機能タイプ（例えば、この場合にはｎｏｄｅ．ｊｓ環境とすることができる）の作業負荷実行エンジンに対してスケジュールされることになる。この機能がスケジュールされ、実行されると、機能は、キャッシュ・メッシュ・プロトコルに基づいて、ショッピング・カートの現在のステートにアクセスしようと試みることになる。

次に図２を参照すると、一実施形態による、実施に近い形態における数個のノードを伴う実行環境のブロック図２００が示される。１つ又は複数のクラスタ２０２は、複数のノード２０４、２０６、２０８（例えば、ノード１、ノード２、ノード３）を含むことができる。ノードの各々は、作業負荷コンテナを表す１つ又は複数のポッド２１０、２１６、２２２、２２８（例えば、ポッドＡ、ポッドＢ、ポッドＣ、ポッド＿）を含むことができる。作業負荷コンテナ（例えば、ポッド）の各々は、それぞれ、キャッシュ・コンポーネント（キャッシュ・メッシュ・コンポーネント（ＣＭＣ）とも呼ばれる）２１４、２２０、２２６、２３２を含むことができる。ポッド２１０、２１６、２２２、２２８の各々は、さらに、ランタイム環境２１２、２１８、２２４、２３０（例えば、Ｊａｖａランタイム・エンジン（Ｊａｖａ）、ｎｏｄｅ．ｊｓ（ＮＪＳ）、Ｐｈｙｔｈｏｎエンジン）を含むことができる。キャッシュ・メッシュ・コンポーネント２１４、２２０、２２６、２３２の各々は、キャッシュ・メッシュの他のキャッシュ・コンポーネントの１つからステート要求を受信する。キャッシュ・コンポーネントが、関連する実行コンテナ内に存在しない場合、ブロードキャスト・メッセージが発信され、キャッシュ・メッシュの他のメンバーによって受信される。要求キャッシュ・メッシュ・コンポーネントと関連する又は同等の作業負荷タイムを有するキャッシュ・メッシュ・コンポーネントのみがアドレス指定されることが好ましい。これは、プロトコルのタイプによって制御される場合がある。

要求されたキャッシュ・コンポーネントが、アドレス指定された他のキャッシュ・コンポーネントのいずれかにおいて識別される場合、要求されたステートは、基盤となる通信キャッシュ・メッシュ・プロトコルを用いて、要求サービスに返信される。作業負荷実行環境がＫｕｂｅｒｎｅｔｅｓである場合、キャッシュ・メッシュ・コンポーネントは、例えば、「サイドカー」として実装することができる。

しかし、ステート・コンポーネントが、クラスタ２０２内の種々のポッド内の他のキャッシュ・メッシュ・コンポーネントのいずれにも発見されない場合、要求されたステートは、ポッド２１０、２１６、２２２、２２８のステートを永続的に格納することができる中央キャッシング・コンポーネント２３４から要求されることがある。これは、予備的な解決策することができるが、クラスタ２０２内の複数のノード２０４、２０６、２０８について中央キャッシング・コンポーネント２３４にアクセスするための実行時間は、ステート要求のためのキャッシュ・メッシュ・コンポーネント２１４、２２２、２２６、２３２間の提案された直接通信より長くかかる場合がある。例として、キャッシュ・メッシュ・コンポーネント２１４とキャッシュ・メッシュ・コンポーネント２３２との間の矢印は、２つのキャッシュ・メッシュ・コンポーネントの間の直接通信を示す。さらに、キャッシュ・メッシュ・コンポーネント２２０と２２６の間の二重矢印及び関連線は、キャッシュ・メッシュ・プロトコルを用いるこのような直接的ステート交換を示す。

また、中央キャッシング・コンポーネント２３４とキャッシュ・メッシュ・コンポーネント２１４、２２２、２２６、２３２との間の点線によって示されるように、中央キャッシング・コンポーネント２３４は、種々のポッド２１０、２１６、２２２、２０８のステートの中央クラスタ指向の永続的ストレージを含むことができる。

さらに、スケジューラ／ゲートウェイ２３６は、ローカル実行環境２１２、２１８、２２４、２３０の実行起動のスケジューリングを制御することができる。それによって、キャッシュ・メッシュ・コンポーネントの安全なプロトコル管理のための暗号キーを、例えばユーザ又は別の制御プロセスから、受信することも可能になる。

一実施形態によれば、スケジューラ／ゲートウェイ２３６は、異なるクラスタ２０２及び３０２（例えば、図３を比較されたい）の間のステート情報を同期するように適合させることができるステート・ルータ２３８を含むことができる。

上に与えられた例（ショッピング・カート）に沿って、シナリオを次のように拡張することができる。ユーザが、作業負荷実行環境内でスニペットの実行のためのＲＥＳＴ要求を送信する。各々の要求により、ユーザの識別情報及び要求タイプに基づいて、キャッシュ・メッシュ・サイドカー・サービスが、以前に格納されたステート（存在する場合）をそのＬ１キャッシュにロードし、存在しない場合にはキャッシュ・メッシュを作成する（プロトコルは後に説明される）。

実行が行われようとしているノード上では、キャッシュ・メッシュ・コンポーネントは、以前に存在していたステートを対応するＬ１キャッシュにロードすることを決定する。Ｌ１キャッシュのサイズは限られているので、Ｌ１キャッシュのコンテンツは、他のキャッシュ・メッシュ・コンポーネントにブロードキャストされ、さらに実行が完了した後でＬ２キャッシュ（即ち、集中キャッシュ・コンポーネント２３４）にロード・バックされる。キャッシュ・メッシュ・コンポーネントは、次に説明されるプロトコルによって制御されるように振る舞う。

キャッシュ・メッシュ・コンポーネントは、関連する実行ノードに対するサイドカーとして各々が機能するキャッシング・サービスのプールである。メッシュは、１．ホスト・ノード実行環境（例えば、同一又は同等の実行環境を伴うノード）に基づき、２．実行のための単一のアプリケーションによって使用することができるノードによって、形成することができる。

ユーザ要求が到着すると、キャッシュ・メッシュ・サイドカー・コンポーネントは、以前のステートがそのキャッシュ内に存在するかどうかを確認する。キャッシュ・ミスの際には、キャッシュ・メッシュ・サイドカー・コンポーネントは、キャッシュされたステートを他のキャッシュ・メッシュ・コンポーネントから要求する（ブロードキャスト・メッセージにより）。要求しているキャッシュ・メッシュ・サイドカー・コンポーネントは、従って、キャッシュ・メッシュ内のユーザの識別情報及び要求タイプをブロードキャストすることができる。

メッシュ内のいずれかの他のャッシュ・メッシュ・サイドカー・コンポーネントは、キャッシュ・ヒットの際にユーザ及び要求タイプを検証した後、キャッシュされたステートを、要求しているキャッシュ・メッシュ・サイドカー・コンポーネントへ送信することができる。そのステートがキャッシュ・メッシュ内（例えば、他のキャッシュ・メッシュ・コンポーネント内）に存在しない場合、Ｌ２キャッシュからステートがロードされる。Ｌ２キャッシュ内のキャッシュ・ミスの際には、キャッシュされたコンテンツ若しくはステート又はこれらの両方が存在しない

ノード上の実行が完了すると、終了ステートがキャッシュ・メッシュ内でブロードキャストされる。従って、次の実行要求が同じユーザから到着し、メッシュ内の他のいずれのノードもスケジュールされている場合、キャッシュ・メッシュ・コンポーネントは、そのＬ１キャッシュ内に以前にロードされたステートを有する可能性がある。Ｌ１キャッシュのサイズは限られており、コンテンツは、基盤となるＦＩＦＯ（先入れ先出し）プロトコルに基づいて格納される。

適切なレベルの安全性を確保するために、各々の要求と共に、それぞれのキャッシュ・メッシュ・コンポーネントのコンテンツを暗号化／復号するために用いることができる暗号キーを送信することができる。

次に図３を参照すると、少なくとも１つの実施形態による、遠隔位置における実行環境の拡張のブロック図が示される。２つのクラスタ３０２及び２０２（図２を比較されたい）を、パブリック・ネットワーク、例えばインターネットを介して、接続することができる。さらに、クタスタ３０２は、複数のノード（例えば、「ノード＿」）を含むことができ、そのうちのノード３０４だけが示されている。さらにここで、複数の作業負荷実行コンテナ３１０（例えば、複数のポッド「ポッド＿」）は、各々、実行環境（例えば、Ｊａｖａ３１２）及び関連するキャッシュ・メッシュ・コンポーネント３１４を含むことができる。さらに、クラスタ３０２は、クラスタ３０２のノード３０４のポッド３１０のキャッシュ・メッシュ・コンポーネント３１４と通信可能に接触することができる中央キャッシング・コンポーネント３３４を含むことができる。さらにここで、異なる作業負荷実行コンテナ／ポッド３１０は、中央キャッシング・コンポーネント３３４に格納することができる。

符号３４０は、パブリック・ネットワーク（例えば、インターネット）を表すことができ、そこからの破線矢印は、図２の中央キャッシング・コンポーネント２３４を指すことができる。このリンクは、中央キャッシング・コンポーネント２３４と遠隔中央キャッシング・コンポーネント３３４との間の状態情報の複製のために使用することができる。このプロセスは、図２のステート・ルータ２３８によって、２つの波線矢印２４０、２４２によって示されるように、制御することができる。

次に図４を参照すると、少なくとも１つの実施形態による、作業負荷環境内のノード上でステートレス・サービスを実行するためのキャッシュ・メッシュ・システム４００が示される。一実施形態において、作業負荷実行環境は、複数のノード（図示されず）を含むことができる。キャッシュ・メッシュ・システム４００は、複数のノードの各々についての定義を（例えば、ストレージ・システム４０２に）格納することができ、定義は、（複数のノードの各々についての）少なくとも１つの作業負荷コンテナを示す。一実施形態において、作業負荷コンテナは、キャッシュ・メッシュのキャッシュ・コンポーネントを含むことができる。キャッシュ・メッシュのキャッシュ・コンポーネントは、互いの間の通信用プロトコルを使用することができる。

キャッシュ・メッシュ・システム４００は、実行コンテナ内のキャッシュ・メッシュのキャッシュ・コンポーネントの１つから、ステートレス要求サービスからのステート要求を受信すると、要求されたステートが、関連する実行コンテナのキャッシュ・コンポーネント内に存在するかどうかを判断し、キャッシュ・ミスの際には、キャッシュ・メッシュのキャッシュ・コンポーネントに対してステート要求をブロードキャストし、キャッシュ・メッシュの他のキャッシュ・コンポーネントによって、要求されたステートがそれぞれのキャッシュ内に存在するかどうかを判断し、いずれかのキャッシュ・コンポーネントが要求されたステートを識別すると、要求されたステートを、プロトコルを用いて要求サービスへ送信するように構成された受信コンポーネント（例えば、レシーバ又はトランシーバ・コンポーネント４０４）を含むことができる。上記のように、プロトコルは、より高度な安全性のために暗号化することができる。

ここで図５を参照すると、本開示の実施形態に関連するプログラム・コードを実行するのに適したコンピューティング・システム５００が示される。実施形態は、プラットフォームがプログラム・コードを格納する若しくは実行する又はその両方を行うのに適しているかどうかにかかわらず、実質的に任意のタイプのコンピュータと共に実施することができる。

コンピューティング・システム５００は、好適なコンピュータ・システムの一例に過ぎず、本明細書で説明される本発明の実施形態の使用範囲又は機能に関する何らかの制限を示唆することを意図するものではない。それにも関わらず、コンピュータ・システム５００は、上述した機能セットのいずれかを実装する若しくは実行する又はその両方を行うことができる。コンピュータ・システム５００において、多数の他の汎用又は専用コンピューティング・システム環境又は構成で動作するコンポーネントがある。コンピュータ・システム／サーバ５００と共に使用するのに好適であり得る周知のコンピューティング・システム、環境若しくは構成又はその両方の例として、これらに限定されるものではないが、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、手持ち式又はラップトップ型デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラム可能民生電子機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、及び、上述のシステム若しくはデバイスのいずれかを含む分散型クラウド・コンピューティング環境等が含まれる。コンピュータ・システム／サーバ５００は、コンピュータ・システム５００によって実行される、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含むことができる。コンピュータ・システム／サーバ５００は、通信ネットワークを通じてリンクされた遠隔処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境で実施することができる。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカル及び遠隔両方のコンピュータ・システム・ストレージ媒体内に配置することができる。

図に示されるように、コンピュータ・システム／サーバ５００は、汎用コンピューティング・デバイスの形で示される。コンピュータ・システム／サーバ５００のコンポーネントは、これらに限定されるものではないが、１つ又は複数のプロセッサ５０２、システム・メモリ５０４、及びシステム・メモリ５０４を含む種々のシステム・コンポーネントをプロセッサ５０２に結合するバス５０６を含むことができる。バス５０６は、メモリ・バス又はメモリ・コントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、及び種々のバス・アーキテクチャのいずれかを用いるプロセッサ又はローカル・バスを含む、幾つかのタイプのバス構造のうちのいずれかの１つ又は複数を表す。限定ではなく例としては、このようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture、ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（Micro Channel Architecture、ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカル・バス、及びＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスを含む。コンピュータ・システム／サーバ５００は、典型的には、種々のコンピュータ・システム可読媒体を含む。こうした媒体は、コンピュータ・システム／サーバ５００によりアクセス可能ないずれかの利用可能媒体とすることができ、揮発性媒体及び不揮発性媒体の両方と、取り外し可能媒体及び取り外し不能媒体の両方とを含む。

システム・メモリ５０４は、ランダム・アクセス・メモリ（ＲＡＭ）５０８若しくはキャッシュ・メモリ５１０又はその両方など、揮発性メモリの形のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ５００は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含むことができる。単なる例として、取り外し不能の不揮発性磁気媒体（図示されておらず、典型的には「ハード・ドライブ」と呼ばれる）との間の読み出し及び書き込みのために、ストレージ・システム８１２を設けることができる。図示されていないが、取り外し可能な不揮発性磁気ディスク（例えば、「フロッピー・ディスク」）との間の読み出し及び書き込みのための磁気ディスク・ドライブと、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ又は他の光媒体などの取り外し可能な不揮発性光ディスクとの間の読み出し及び書き込みのための光ディスク・ドライブとを設けることができる。このような例においては、それぞれを、１つ又は複数のデータ媒体インターフェースによってバス５０６に接続することができる。以下でさらに示され説明されるように、システム・メモリ５０４は、本発明の実施形態の機能を実行するように構成されたプログラム・モジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

限定ではなく例として、システム・メモリ５０４内に、プログラム・モジュール５１６のセット（少なくとも１つ）を有するプログラム／ユーティリティ、並びにオペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データを格納することができる。オペレーティング・システム、１つ又は複数のアプリケーション・プログラム、他のプログラム・モジュール、及びプログラム・データ、又はそれらの何らかの組み合わせの各々は、ネットワーキング環境の実装形態を含むことができる。プログラム・モジュール５１６は、一般に、本明細書で説明される本開示の実施形態の機能若しくは方法又はその両方を実行する。

コンピュータ・システム／サーバ５００は、キーボード、ポインティング・デバイス、ディスプレイ５２０等のような１つ又は複数の外部デバイス５１８、ユーザがコンピュータ・システム／サーバ５００と対話することを可能にする１つ又は複数のデバイス、及び／又はコンピュータ・システム／サーバ５００が１つ又は複数の他のコンピューティング・デバイスと通信することを可能にするいずれかのデバイス（例えば、ネットワーク・カード、モデムなど）と通信することもできる。こうした通信は、入力／出力（Ｉ／Ｏ）インターフェース５１４を経由して行うことができる。さらにまた、コンピュータ・システム／サーバ５００は、ネットワーク・アダプタ５２２を介して、ローカル・エリア・ネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）若しくはパブリック・ネットワーク（例えば、インターネット）又はその組み合わせなどの１つ又は複数のネットワークと通信することもできる。示されるように、ネットワーク・アダプタ５２２は、バス５０６を介して、コンピュータ・システム／サーバ５００の他のコンポーネントと通信する。図示されないが、コンピュータ・システム／サーバ５００と共に他のハードウェア若しくはソフトウェア・コンポーネント又はその両方を使用できることを理解されたい。例としては、これらに限定されるものではないが、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部のディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、及びデータ・アーカイブ・ストレージ・システムなどが含まれる。

付加的に、作業負荷実行環境におけるノード上でステートレス・サービスを実行するためのキャッシュ・メッシュ・システム４００をバス・システム５０６に取り付けることができる。

ここで図６を参照すると、例示的なクラウド・コンピューティング環境１０００が示される。図示のように、クラウド・コンピューティング環境１０００は、例えば、携帯情報端末（ＰＤＡ）又は携帯電話１０００Ａ、デスクトップ・コンピュータ１０００Ｂ、ラップトップ・コンピュータ１０００Ｃ、若しくはコンピュータ・システム１０００Ｎ又はそれらの組み合わせなどのような、クラウド・コンシューマによって使用されるローカル・コンピューティング・デバイスと通信することができる、１つ又は複数のクラウド・コンピューティング・ノード１００を含む。ノード１００は、互いに通信することができる。これらのノードは、プライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、若しくはハイブリッド・クラウド、又はこれらの組み合わせなど、１つ又は複数のネットワークにおいて物理的又は仮想的にグループ化することができる（図示せず）。このことは、クラウド・コンピューティング環境１０００が、クラウド・コンシューマがローカル・コンピューティング・デバイス上にリソースを保持する必要のない、ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ ｓｅｒｖｉｃｅ、ｐｌａｔｆｏｒｍ ａｓ ａ ｓｅｒｖｉｃｅ、若しくはｓｏｆｔｗａｒｅ ａｓ ａ ｓｅｒｖｉｃｅ、又はそれらの組み合わせを提供することを可能にする。図６に示されるコンピューティング・デバイス１０００Ａ～Ｎのタイプは単に例示であることを意図し、コンピューティング・ノード１００及びクラウド・コンピューティング環境１０００は、任意のタイプのネットワーク上で若しくはネットワーク・アドレス指定可能な接続（例えば、ウェブ・ブラウザを用いる）上で又はその両方で、任意のタイプのコンピュータ化されたデバイスと通信できることを理解されたい。

ここで図７を参照すると、クラウド・コンピューティング環境１０００によって提供される機能抽象化層のセットが示される。図７に示されるコンポーネント、層、及び機能は単に例示であることを意図し、本発明の実施形態はそれらに限定されないことを予め理解されたい。図示されるように、以下の層及び対応する機能が提供される。

ハードウェア及びソフトウェア層１１０２は、ハードウェア及びソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例として、メインフレーム１１０４と、ＲＩＳＣ（Reduced Instruction Set Computer（縮小命令セットコンピュータ））アーキテクチャ・ベースのサーバ１１０６と、サーバ１１０８と、ブレード・サーバ１１１０と、ストレージ・デバイス１１１２と、ネットワーク及びネットワーク・コンポーネント１１１４と、が含まれる。幾つかの実施形態においては、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア１１１６と、データベース・ソフトウェア１１１８とを含む。

仮想化層１１２０は、抽象化層を提供し、この層により、仮想エンティティの以下の例、すなわち、仮想サーバ１１２２、仮想ストレージ１１２４、仮想プライベート・ネットワークを含む仮想ネットワーク１１２６、仮想アプリケーション及びオペレーティング・システム１１２８、並びに仮想クライアント１１３０を提供することができる。

一例において、管理層１１３２は、以下で説明される機能を提供することができる。リソース・プロビジョニング１１３４は、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソース及び他のリソースの動的な調達を提供する。計量及び価格決定１１３６は、クラウド・コンピューティング環境内でリソースが利用される際のコスト追跡と、これらのリソースの消費に対する課金又は請求とを提供する。一例において、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、クラウド・コンシューマ及びタスクに対する識別情報の検証と、データ及び他のリソースに対する保護とを提供する。ユーザ・ポータル１１３８は、コンシューマ及びシステム管理者のために、クラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理１１４０、要求されるサービス・レベルが満たされるように、クラウド・コンピューティング・リソースの割り当て及び管理を提供する。サービス・レベル・アグリーメント（Service Level Agreement、ＳＬＡ）の計画及び履行１１４２は、ＳＬＡに従って将来の要件が予測されるクラウド・コンピューティング・リソースの事前配置及び調達を提供する。

作業負荷層１１４４は、クラウド・コンピューティング環境を利用することができる機能の例を提供する。この層から提供することができる作業負荷及び機能の例として、マッピング及びナビゲーション１４６、ソフトウェア開発及びライフサイクル管理１１４８、仮想教室教育配信１１５０、データ分析処理１１５２、トランザクション処理１１５４、及びキャッシュ・メッシュ・システム（図４、４００と比較）が挙げられる。

本発明の種々の実施形態の説明は、例証の目的で提示したものであるが、網羅的であることも、又は開示された実施形態に限定することも意図しない。当業者には、説明される実施形態の範囲及び趣旨から逸脱することなく、多くの修正及び変形が明らかであろう。本明細書で用いられる用語は、市場で見出される技術よりも優れた実施形態の原理、実際的な応用、又は技術的改善を最も良く説明するために、又は、当業者である他の者が、本明細書に開示される実施形態を理解することを可能にするために、選択されたものである。

本発明は、システム、方法若しくはコンピュータ・プログラム製品又はその組み合わせとして具体化することができる。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を有するコンピュータ可読ストレージ媒体（単数又は複数）を含むことができる。

媒体は、伝搬媒体のための、電子、磁気、光学、電磁気、赤外線又は半導体のシステムとすることができる。コンピュータ可読媒体の例として、半導体又はソリッド・ステート・メモリ、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、剛性磁気ディスク及び光ディスクが挙げられる。光ディスクの現在の例として、コンパクト・ディスク－読み出し専用メモリ（ＣＤ－ＲＯＭ）、コンパクト・ディスク－読み出し／書き込み（ＣＤ－Ｒ／Ｗ）、ＤＶＤ、及びブルーレイ・ディスク（Blu-Ray-Disk）が挙げられる。

コンピュータ可読ストレージ媒体は、命令実行デバイスにより使用される命令を保持及び格納できる有形デバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、これらに限定されるものではないが、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイス、又は上記のいずれかの適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のより具体的な例の非網羅的なリストとして、以下のもの：すなわち、ポータブル・コンピュータ・ディスケット、ハードディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フロッピー・ディスク、パンチカード若しくは命令がそこに記録された溝内の隆起構造のような機械的にエンコードされたデバイス、及び上記のいずれかの適切な組み合わせが挙げられる。本明細書で使用される場合、コンピュータ可読ストレージ媒体は、電波、又は他の自由に伝搬する電磁波、導波管若しくは他の伝送媒体を通じて伝搬する電磁波（例えば、光ファイバ・ケーブルを通る光パルス）、又はワイヤを通って送られる電気信号などの、一時的信号自体として解釈されない。

本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピューティング／処理デバイスに、又は、例えばインターネット、ローカル・エリア・ネットワーク、広域ネットワーク、及び／又は無線ネットワークなどのネットワークを介して外部コンピュータ又は外部ストレージ・デバイスにダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、及び／又はエッジ・サーバを含むことができる。各コンピューティング／処理デバイスにおけるネットワーク・アダプタ・カード又はネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受け取り、コンピュータ可読プログラム命令を転送して、それぞれのコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体内に格納する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路のための構成データ、又は、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、及び、「Ｃ」プログラミング言語若しくは類似のプログラミング言語などの従来の手続き型プログラミング言語を含む１つ又は複数のプログラミング言語の任意の組み合わせで記述されるソース・コード又はオブジェクト・コードとすることができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合もある。最後のシナリオにおいて、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの接続がなされる場合もある（例えば、インターネットサービスプロバイダを用いたインターネットを通じて）。幾つかの実施形態において、例えば、プログラム可能論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又はプログラム可能論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実施するために、コンピュータ可読プログラム命令の状態情報を利用することによってコンピュータ可読プログラム命令を実行して、電子回路を個別化することができる。

本発明の態様は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図若しくはブロック図又はその両方を参照して説明される。フローチャート図若しくはブロック図又はその両方の各ブロック、並びにフローチャート図若しくはブロック図又はその両方におけるブロックの組み合わせは、コンピュータ可読プログラム命令によって実装できることが理解されるであろう。

これらのコンピュータ可読プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えて機械を製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート若しくはブロック図又は両方の１つ又は複数のブロック内で指定された機能／動作を実施するための手段を作り出すようにすることができる。これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置若しくは他のデバイス又はその組み合わせを特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、それにより、そのコンピュータ可読媒体内に格納された命令が、フローチャート若しくはブロック図又は両方の１つ又は複数のブロックにおいて指定された機能／動作の態様を実施する命令を含む製品を含むようにすることもできる。

コンピュータ可読プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で行わせてコンピュータ実施のプロセスを生産し、それにより、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート若しくはブロック図又は両方の１つ又は複数のブロックにおいて指定された機能／動作を実行するためのプロセスを提供するようにすることもできる。

図面内のフローチャート及びブロック図は、本発明の様々な実施形態による、システム、方法、及びコンピュータ・プログラム製品の可能な実装の、アーキテクチャ、機能及び動作を示す。この点に関して、フローチャート内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含む、モジュール、セグメント、又はコードの一部を表すことができる。幾つかの代替的な実装において、ブロック内に示される機能は、図に示される順序とは異なる順序で生じることがある。例えば、連続して示される２つのブロックは、関与する機能に応じて、実際には実質的に同時に実行されることもあり、又はこれらのブロックはときとして逆順で実行されることもある。ブロック図若しくはフローチャート図又は両方の各ブロック、及びブロック図若しくはフローチャート図又は両方におけるブロックの組み合わせは、指定された機能又は動作を実行する、又は専用のハードウェアとコンピュータ命令との組み合わせを実行する、専用ハードウェア・ベースのシステムによって実装できることにも留意されたい。

本明細書で用いられる用語は、特定の実施形態を説明する目的のためのものに過ぎず、本発明を限定することを意図したものではない。本明細書で用いられる場合、単数形「１つの（a）」、「１つの（an）」及び「その（the）」は、文脈が特に明示しない限り、複数形も同様に含むことを意図したものである。用語「含む（comprise）」若しくは「含んでいる（comprising）」又はその両方は、本明細書で用いられる場合、記述された特徴、整数、ステップ、動作、要素 及び／又はコンポーネントの存在を指示するが、１つ又は複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらの群の存在又は追加を排除するものではないこともさらに理解されるであろう。

以下の特許請求の範囲における「手段又はステップと機能との組み合わせ（ミーンズ又はステップ・プラス・ファンクション）」要素の対応する構造、材料、動作及び均等物は、明確に特許請求された他の請求された要素と共に機能を実行するための任意の構造、材料、又は行為を含むことを意図したものである。本開示の説明は、例証及び説明のためだけに提示されたものであり、網羅的であること又は本発明を開示した形態に限定することを意図したものではない。当業者には、本発明の範囲から逸脱しない多くの修正物及び変形物が明らかとなるであろう。実施形態は、本発明の原理及び実際の用途を最もよく説明するため、及び、当業者が、企図した特定の用途に適するように種々の修正を有する種々の実施形態に関して本発明を理解することができるように、選択され記述された。

Claims (21)

1. コンピュータの情報処理により、作業負荷実行環境内のノード上でステートレス・サービスを実行するための方法であって、
   複数のノードのそれぞれのノードについて少なくとも１つの作業負荷コンテナを定義することであって、前記少なくとも１つの作業負荷コンテナはキャッシュ・メッシュのキャッシュ・コンポーネントを含み、前記キャッシュ・メッシュは複数のキャッシュ・コンポーネントを含み、前記複数のキャッシュ・コンポーネントは互いの間の通信用プロトコルを含む、定義することと、
   実行コンテナ内の前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントの１つから、ステートレス要求サービスからのステート要求を受信することに応答して、前記ステート要求と関連付けられた要求されたステートが、関連する実行コンテナの前記キャッシュ・コンポーネント内に存在するかどうか判断することと、
   キャッシュ・ミスに応答して、前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントの他のキャッシュ・コンポーネントに対して、前記ステート要求をブロードキャストすることと、
   前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントの前記他のキャッシュ・コンポーネントによって、前記要求されたステートが前記他のキャッシュ・コンポーネントのそれぞれのキャッシュ内に存在するかどうか判断することと、
   いずれかのキャッシュ・コンポーネントが前記要求されたステートを識別することに応答して、前記要求されたステートを、前記通信用プロトコルを用いて前記要求サービスへ送信することと
   を含む方法。
2. 前記通信用プロトコルは暗号化される、請求項１に記載の方法。
3. 前記それぞれのノード上での前記実行コンテナの実行の完了に応答して、前記キャッシュ・メッシュに対して終了ステートをブロードキャストすることをさらに含む、請求項１又は請求項２に記載の方法。
4. 前記複数のノードについての第１の集中キャッシュ・コンポーネントを準備することをさらに含む、請求項１～請求項３のいずれか１項に記載の方法。
5. 前記要求されたステートが、前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネント内で入手できないとの判断に応答して、前記要求されたステートを前記第１の集中キャッシュ・コンポーネントからロードすることをさらに含む、請求項４に記載の方法。
6. 前記通信用プロトコルは、ユーザの識別子、キャッシュされた値を識別するキー、及び前記キャッシュされた値からなる群から選択されたコンポーネントを含む、請求項１～請求項５のいずれか１項に記載の方法。
7. 前記それぞれのノード上での前記実行コンテナの前記実行の完了に応答して、前記第１の集中キャッシュ・コンポーネントに対して終了ステートをブロードキャストすることをさらに含む、請求項４に記載の方法。
8. 前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントは、同等の作業負荷タイプを有するキャッシュ・コンポーネントのプールを含む、請求項１～請求項７のいずれか１項に記載の方法。
9. 前記同等の作業負荷タイプは、同一のランタイム・エンジン、ユーザ情報、及び同一のプログミング言語からなる群から選択される実行パターンを含む、請求項８に記載の方法。
10. 第２の集中キャッシュ・コンポーネントを、複製プロトコルを用いて前記第１の集中キャッシュ・コンポーネントと同期させることをさらに含み、前記第２の集中キャッシュ・コンポーネントは、第２の遠隔作業負荷実行環境内に保持される、請求項４に記載の方法。
11. 作業負荷実行環境内のノード上でステートレス・サービスを実行するためのコンピュータ・システムであって、
    １つ又は複数のプロセッサと、１つ又は複数のコンピュータ可読メモリと、１つ又は複数のコンピュータ可読有形ストレージ媒体と、前記１つ又は複数のコンピュータ可読有形ストレージ媒体のうちの少なくとも１つに格納された、前記１つ又は複数のメモリのうちの少なくとも１つを介して前記１つ又は複数のプロセッサのうちの少なくとも１つによって実行するためのプログラム命令とを含み、
    複数のノードのそれぞれのノードについて少なくとも１つの作業負荷コンテナを定義することであって、前記少なくとも１つの作業負荷コンテナはキャッシュ・メッシュのキャッシュ・コンポーネントを含み、前記キャッシュ・メッシュは複数のキャッシュ・コンポーネントを含み、前記複数のキャッシュ・コンポーネントは互いの間の通信用プロトコルを含む、定義することと、
    実行コンテナ内の前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントの１つから、ステートレス要求サービスからのステート要求を受信することに応答して、前記ステート要求と関連付けられた要求されたステートが、関連する実行コンテナの前記キャッシュ・コンポーネント内に存在するかどうかを判断することと、
    キャッシュ・ミスに応答して、前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントの他のキャッシュ・コンポーネントに対して、前記ステート要求をブロードキャストすることと、
    前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントの前記他のキャッシュ・コンポーネントによって、前記要求されたステートが前記他のキャッシュ・コンポーネントのそれぞれのキャッシュ内に存在するかどうか判断することと、
    いずれかのキャッシュ・コンポーネントが前記要求されたステートを識別することに応答して、前記要求されたステートを、前記通信用プロトコルを用いて前記要求サービスへ送信することと
    を含む方法を行うことが可能な、
    コンピュータ・システム。
12. 前記それぞれのノード上での前記実行コンテナの実行の完了に応答して、前記キャッシュ・メッシュに対して終了ステートをブロードキャストすることをさらに含む、請求項１１に記載のコンピュータ・システム。
13. 前記複数のノードについての第１の集中キャッシュ・コンポーネントを準備することをさらに含む、請求項１１又は請求項１２に記載のコンピュータ・システム。
14. 前記要求されたステートが、前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネント内で入手できないとの判断に応答して、前記要求されたステートを前記第１の集中キャッシュ・コンポーネントからロードすることをさらに含む、請求項１３に記載のコンピュータ・システム。
15. 前記通信用プロトコルは、ユーザの識別子、キャッシュされた値を識別するキー、及び前記キャッシュされた値から成る群から選択されたコンポーネントを含む、請求項１１～請求項１４のいずれか１項に記載のコンピュータ・システム。
16. 前記それぞれのノード上での前記実行コンテナの前記実行の完了に応答して、前記第１の集中キャッシュ・コンポーネントに対して終了ステートをブロードキャストすることをさらに含む、請求項１３に記載のシステム。
17. 前記キャッシュ・メッシュの前記複数のキャッシュ・コンポーネントは、同等の作業負荷タイプを有するキャッシュ・コンポーネントのプールを含む、請求項１１～請求項１６のいずれか１項に記載のコンピュータ・システム。
18. 前記同等の作業負荷タイプは、同一のランタイム・エンジン、ユーザ情報、及び同一のプログミング言語から成る群から選択された実行パターンを含む、請求項１７に記載のコンピュータ・システム。
19. 第２の集中キャッシュ・コンポーネントを、複製プロトコルを用いて前記第１の集中キャッシュ・コンポーネントと同期させることをさらに含み、前記第２の集中キャッシュ・コンポーネントは、第２の遠隔作業負荷実行環境内に保持される、請求項１３に記載のコンピュータ・システム。
20. 作業負荷実行環境内のノード上でステートレス・サービスを実行するためのコンピュータ・プログラムであって、請求項１から請求項１０までのいずれか１項に記載の方法をコンピュータに実行させるプログラム命令を含む、
    コンピュータ・プログラム。
21. 請求項２０に記載のコンピュータ・プログラムを格納したコンピュータ可読ストレージ媒体。

Images