知財求人 - 知財ポータルサイト「IP Force」
▶ インターナショナル・ビジネス・マシーンズ・コーポレーションの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-05-20
(45)【発行日】2025-05-28
(54)【発明の名称】コンテナ化環境におけるキャッシュされたクラスデータの共有
(51)【国際特許分類】
G06F 9/455 20180101AFI20250521BHJP
G06F 8/60 20180101ALI20250521BHJP
G06F 12/0815 20160101ALI20250521BHJP
【ＦＩ】
G06F9/455
G06F8/60
G06F12/0815
【請求項の数】
20
(21)【出願番号】P 2023517723
(86)(22)【出願日】2021-07-20
(65)【公表番号】
(43)【公表日】2023-10-11
(86)【国際出願番号】 CN2021107456
(87)【国際公開番号】W WO2022062613
(87)【国際公開日】2022-03-31
【審査請求日】2023-12-12
(31)【優先権主張番号】17/029,483
(32)【優先日】2020-09-23
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【住所又は居所原語表記】Ｎｅｗ Ｏｒｃｈａｒｄ Ｒｏａｄ， Ａｒｍｏｎｋ， Ｎｅｗ Ｙｏｒｋ １０５０４， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100112690
【弁理士】
【氏名又は名称】太佐 種一
(74)【代理人】
【識別番号】100120710
【弁理士】
【氏名又は名称】片岡 忠彦
(72)【発明者】
【氏名】ユー、アンヤン
(72)【発明者】
【氏名】チョプラ、ドゥルーヴ
(72)【発明者】
【氏名】バデル、アレン
(72)【発明者】
【氏名】スンダレサン、ヴィジャイ
(72)【発明者】
【氏名】ピルヴ、マリウス
(72)【発明者】
【氏名】ドーソン、マイケル
(72)【発明者】
【氏名】ハイディンガ、ダニエル
【審査官】児玉 崇晶
(56)【参考文献】
【文献】特開２００３－０９１４２０（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１５／００３３２１５（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ８／６０
Ｇ０６Ｆ ９／４５５
Ｇ０６Ｆ １２／０８１５
(57)【特許請求の範囲】
【請求項1】
キャッシュされたクラスデータを共有するためのコンピュータ実装方法であって、前記コンピュータが、コンテナ化環境のコンテナにおいてマネージドランタイムアプリケーションの起動を開始することと、
前記コンピュータが、アプリケーションイメージ識別子、前記マネージドランタイムアプリケーションに関連する引数、および当該マネージドランタイムアプリケーションに関連するワーカノードに対応するワーカノード識別子を含む、当該マネージドランタイムアプリケーションに関する情報を受信することと、
前記コンピュータが、前記アプリケーションイメージ識別子と前記引数との組み合わせによってキーされた第１の共有クラスキャッシュ（ＳＣＣ）を、サーバによって管理される中央ＳＣＣリポジトリ内で特定することと、
前記第１のＳＣＣを特定したことに応じて、
前記コンピュータが、前記第１のＳＣＣを前記ワーカノードに関連するクライアントに送信することと、
前記コンピュータが、前記第１のＳＣＣをローカルＳＣＣリポジトリに格納することと、
を含む方法。
【請求項2】
前記コンピュータが、前記クライアントから、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、前記マネージドランタイムアプリケーションのタイプに関連する第１の更新要求を受信することと、前記コンピュータが、前記第１の更新要求を受け入れることを決定することと、
前記第１の更新要求を受け入れたことに応じて、
前記コンピュータが、前記第１の更新要求を含む複数の更新要求を分析して、分析済み更新要求データを作成することと、
前記コンピュータが、前記分析済み更新要求データに基づいて、当該分析済み更新要求データが、前記複数の更新要求のうちの２つ以上の更新要求に共通する新たなデータを含むと判断することと、
前記コンピュータが、前記新たなデータに基づいて、前記第１のＳＣＣを修正して第２のＳＣＣを生成することと、
をさらに含む、請求項１に記載の方法。
【請求項3】
前記コンピュータが、前記クライアントから、前記マネージドランタイムアプリケーションによって発信され、前記第１のＳＣＣに関連する第１の更新要求を受信することであって、当該第１の更新要求は、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、当該マネージドランタイムアプリケーションのタイプに関連する、ことと、前記コンピュータが、前記第１の更新要求を拒否することを決定することと、
前記コンピュータが、前記第１の更新要求を拒否したことに応じて、前記クライアントに第２のＳＣＣを送信することと、
をさらに含む、請求項１に記載の方法。
【請求項4】
前記マネージドランタイムアプリケーションの前記タイプは、前記アプリケーションイメージ識別子に基づいており、共通のアプリケーションイメージ識別子を有する複数のマネージドランタイムアプリケーションが、同じタイプとなる、請求項２に記載の方法。
【請求項5】
前記サーバは、前記ワーカノードと分離した別個の専用ノードに配置される、請求項１に記載の方法。
【請求項6】
前記サーバは、前記マネージドランタイムアプリケーションの前記起動に連動して、前記コンテナに前記第１のＳＣＣを提供することと、
コンテナオーケストレーションシステムと通信し、前記サーバの範囲内にあるマネージドランタイムアプリケーションイメージに関する情報を取得することと、
前記中央ＳＣＣリポジトリを管理することと、
前記コンテナを対応するクライアントに関連付けることと、
前記クライアントから受信した更新要求にしたがって、前記第１のＳＣＣを更新することと、
からなる群から選択されるタスクを実行する、
請求項１に記載の方法。
【請求項7】
前記第１の更新要求を拒否することを決定することは、（ｉ）前記第１のＳＣＣが満杯であること、（ｉｉ）前記マネージドランタイムアプリケーションがエラーコードを返していること、（ｉｉｉ）当該マネージドランタイムアプリケーションが予想外のリターンコードを返していること、および（ｉｖ）前記第２のＳＣＣが当該第１のＳＣＣよりも新しいこと、からなる群から選択される要因に基づく、請求項３に記載の方法。
【請求項8】
キャッシュされたクラスデータを共有するためのコンピュータプログラムであって、
コンテナ化環境のコンテナにおいてマネージドランタイムアプリケーションの起動を開始することと、
アプリケーションイメージ識別子、前記マネージドランタイムアプリケーションに関連する引数、および当該マネージドランタイムアプリケーションに関連するワーカノードに対応するワーカノード識別子を含む、当該マネージドランタイムアプリケーションに関する情報を受信することと、
前記アプリケーションイメージ識別子と前記引数との組み合わせによってキーされた第１の共有クラスキャッシュ（第１のＳＣＣ）を、サーバによって管理される中央ＳＣＣリポジトリ内で特定することと、
前記第１のＳＣＣを特定したことに応じて、
前記第１のＳＣＣを前記ワーカノードに関連するクライアントに送信することと、
前記第１のＳＣＣをローカルＳＣＣリポジトリに格納することと、
をコンピュータに実行させる、コンピュータプログラム。
【請求項9】
前記クライアントから、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、前記マネージドランタイムアプリケーションのタイプに関連する第１の更新要求を受信することと、前記第１の更新要求を受け入れることを決定することと、
前記第１の更新要求を受け入れたことに応じて、
前記第１の更新要求を含む複数の更新要求を分析して、分析済み更新要求データを作成することと、
前記分析済み更新要求データに基づいて、当該分析済み更新要求データが、前記複数の更新要求のうちの２つ以上の更新要求に共通する新たなデータを含むと判断することと、
前記新たなデータに基づいて、前記第１のＳＣＣを修正して第２のＳＣＣを生成することと、
をさらにコンピュータに実行させる、請求項８に記載のコンピュータプログラム。
【請求項10】
前記クライアントから、前記マネージドランタイムアプリケーションによって発信され、前記第１のＳＣＣに関連する第１の更新要求を受信することであって、当該第１の更新要求は、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、当該マネージドランタイムアプリケーションのタイプに関連する、ことと、前記第１の更新要求を拒否することを決定することと、
前記第１の更新要求を拒否したことに応じて、前記クライアントに第２のＳＣＣを送信することと、
をさらにコンピュータに実行させる、請求項８に記載のコンピュータプログラム。
【請求項11】
前記マネージドランタイムアプリケーションの前記タイプは、前記アプリケーションイメージ識別子に基づいており、共通のアプリケーションイメージ識別子を有する複数のマネージドランタイムアプリケーションが、同じタイプとなる、請求項９に記載のコンピュータプログラム。
【請求項12】
前記サーバは、前記ワーカノードと分離した別個の専用ノードに配置される、請求項８に記載のコンピュータプログラム。
【請求項13】
前記サーバは、前記マネージドランタイムアプリケーションの前記起動に連動して、前記コンテナに前記第１のＳＣＣを提供することと、
コンテナオーケストレーションシステムと通信し、前記サーバの範囲内にあるマネージドランタイムアプリケーションイメージに関する情報を取得することと、
前記中央ＳＣＣリポジトリを管理することと、
前記コンテナを対応するクライアントに関連付けることと、
前記クライアントから受信した更新要求にしたがって、前記第１のＳＣＣを更新することと、
からなる群から選択されるタスクを実行する、
請求項８に記載のコンピュータプログラム。
【請求項14】
前記第１の更新要求を拒否することを決定することは、（ｉ）前記第１のＳＣＣが満杯であること、（ｉｉ）前記マネージドランタイムアプリケーションがエラーコードを返していること、（ｉｉｉ）当該マネージドランタイムアプリケーションが予想外のリターンコードを返していること、および（ｉｖ）前記第２のＳＣＣが当該第１のＳＣＣよりも新しいこと、からなる群から選択される要因に基づく、請求項１０に記載のコンピュータプログラム。
【請求項15】
キャッシュされたクラスデータを共有するためのコンピュータシステムであって、プロセッサセットと、
１つ以上のコンピュータ可読記憶媒体と、を含み、
前記プロセッサセットは、前記１つ以上のコンピュータ可読記憶媒体に記憶されたプログラム命令を実行するように構成、配置、接続、もしくはプログラムされ、またはその組み合わせが行われ、
前記プログラム命令は、
コンテナ化環境のコンテナにおいてマネージドランタイムアプリケーションの起動を開始することと、
クラス共有オーケストレータ（ＣＳＯ）中央サーバによって、アプリケーションイメージ識別子、前記マネージドランタイムアプリケーションに関連する引数、および当該マネージドランタイムアプリケーションに関連するワーカノードに対応するワーカノード識別子を含む、当該マネージドランタイムアプリケーションに関する情報を受信することと、
前記アプリケーションイメージ識別子と前記引数との組み合わせによってキーされた第１の共有クラスキャッシュ（第１のＳＣＣ）を、前記ＣＳＯ中央サーバによって管理される中央ＳＣＣリポジトリ内で特定することと、
前記第１のＳＣＣを特定したことに応じて、
前記第１のＳＣＣを前記ワーカノードに関連するＣＳＯクライアントに送信することと、
前記第１のＳＣＣをローカルＳＣＣリポジトリに格納することと、
を実行するようにプログラムされた命令を含む、コンピュータシステム。
【請求項16】
前記ＣＳＯクライアントから、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、前記マネージドランタイムアプリケーションのタイプに関連する第１の更新要求を受信することと、前記第１の更新要求を受け入れることを決定することと、
前記第１の更新要求を受け入れたことに応じて、
前記第１の更新要求を含む複数の更新要求を分析して、分析済み更新要求データを作成することと、
前記分析済み更新要求データに基づいて、当該分析済み更新要求データが、前記複数の更新要求のうちの２つ以上の更新要求に共通する新たなデータを含むと判断することと、
前記新たなデータに基づいて、前記第１のＳＣＣを修正して第２のＳＣＣを生成することと、
を実行するようにプログラムされた命令をさらに含む、請求項１５に記載のコンピュータシステム。
【請求項17】
前記ＣＳＯクライアントから、前記マネージドランタイムアプリケーションによって発信され、前記第１のＳＣＣに関連する第１の更新要求を受信することであって、当該第１の更新要求は、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、当該マネージドランタイムアプリケーションのタイプに関連する、ことと、前記第１の更新要求を拒否することを決定することと、
前記第１の更新要求を拒否したことに応じて、前記ＣＳＯクライアントに第２のＳＣＣを送信することと、
を実行するようにプログラムされた命令をさらに含む、請求項１５に記載のコンピュータシステム。
【請求項18】
前記マネージドランタイムアプリケーションの前記タイプは、前記アプリケーションイメージ識別子に基づいており、共通のアプリケーションイメージ識別子を有する複数のマネージドランタイムアプリケーションが、同じタイプとなる、請求項１６に記載のコンピュータシステム。
【請求項19】
前記第１の更新要求を拒否することを決定することは、（ｉ）前記第１のＳＣＣが満杯であること、（ｉｉ）前記マネージドランタイムアプリケーションがエラーコードを返していること、（ｉｉｉ）当該マネージドランタイムアプリケーションが予想外のリターンコードを返していること、および（ｉｖ）前記第２のＳＣＣが当該第１のＳＣＣよりも新しいこと、からなる群から選択される要因に基づく、請求項１７に記載のコンピュータシステム。
【請求項20】
前記ＣＳＯ中央サーバは、前記マネージドランタイムアプリケーションの前記起動に連動して、前記コンテナに前記第１のＳＣＣを提供することと、
コンテナオーケストレーションシステムと通信し、前記ＣＳＯ中央サーバの範囲内にあるマネージドランタイムアプリケーションイメージに関する情報を取得することと、
前記中央ＳＣＣリポジトリを管理することと、
前記コンテナを対応するＣＳＯクライアントに関連付けることと、
前記ＣＳＯクライアントから受信した更新要求にしたがって、前記第１のＳＣＣを更新することと、
からなる群から選択されるタスクを実行する、
請求項１５に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般に、大規模コンピューティングの分野に関し、より具体的には、複数の分離されたユーザ空間（「コンテナ」と呼ばれることもある）を有する「サービスとしてのプラットフォーム」コンピューティング環境に関する。
【背景技術】
【0002】
「サービスとしてのプラットフォーム」コンピューティング環境では、オペレーティングシステムレベルで実装される仮想化によって、ユーザ空間は互いに分離される。
【0003】
いくつかの動的言語コンピューティング環境（dynamic language computing environment）では、アプリケーションが実行時にジャストインタイム（ＪＩＴ：just-in-time）コンパイルを実行し、読み出し専用クラスデータ（read-only class data）および実行される事前（ＡＯＴ：ahead-of-time）コンパイルコードを含むクラスファイルがオンデマンドでロードされる。一部のシステムでは、キャッシュ機構（caching mechanism）を使用している。キャッシュ機構においては、アプリケーションのスタートアップ時に、必要なクラスがメモリマップファイル（ＲＡＭに常駐する共有クラスキャッシュ）から迅速にロードされる一方で、ＪＩＴコンパイルが、キャッシュされたＡＯＴコンパイル済みボディ（AOT compiled bodies）を迅速にロードする。
【発明の概要】
【0004】
本発明の一態様によれば、キャッシュされたクラスデータを共有するための方法、コンピュータプログラム製品、もしくはシステムまたはその組み合わせであって、以下の動作（必ずしも以下の順序ではない）を実行するものが提供される：（ｉ）コンテナ化環境のコンテナにおいてマネージドランタイムアプリケーションの起動を開始し、（ｉｉ）アプリケーションイメージ識別子、前記マネージドランタイムアプリケーションに関連する引数、および当該マネージドランタイムアプリケーションに関連するワーカノードに対応するワーカノード識別子を含む、当該マネージドランタイムアプリケーションに関する情報を受信し、（ｉｉｉ）前記アプリケーションイメージ識別子と前記引数との組み合わせによってキーされた第１の共有クラスキャッシュ（ＳＣＣ）を、サーバによって管理される中央ＳＣＣリポジトリ内で特定し、（ｉｖ）前記第１のＳＣＣを特定したことに応じて、（ａ）前記第１のＳＣＣを前記ワーカノードに関連するクライアントに送信し、（ｂ）前記第１のＳＣＣをローカルＳＣＣリポジトリに格納し、（ｖ）前記クライアントから、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、前記マネージドランタイムアプリケーションのタイプに関連する第１の更新要求を受信し、（ｖｉ）前記第１の更新要求を受け入れることを決定し、（ｖｉｉ）前記第１の更新要求を受け入れたことに応じて、（ａ）前記第１の更新要求を含む複数の更新要求を分析して、分析済み更新要求データを作成し、（ｂ）前記分析済み更新要求データに基づいて、当該分析済み更新要求データが、前記複数の更新要求のうちの２つ以上の更新要求に共通する新たなデータを含むと判断し、（ｃ）前記新たなデータに基づいて、前記第１のＳＣＣを修正して第２のＳＣＣを生成する。
【0005】
本発明のさらなる態様によれば、キャッシュされたクラスデータを共有するための方法、コンピュータプログラム製品、もしくはシステムまたはその組み合わせであって、以下の動作（必ずしも以下の順序ではない）を実行するものが提供される：（ｉ）コンテナ化環境のコンテナにおいてマネージドランタイムアプリケーションの起動を開始し、（ｉｉ）アプリケーションイメージ識別子、前記マネージドランタイムアプリケーションに関連する引数、および当該マネージドランタイムアプリケーションに関連するワーカノードに対応するワーカノード識別子を含む、当該マネージドランタイムアプリケーションに関する情報を受信し、（ｉｉｉ）前記アプリケーションイメージ識別子と前記引数との組み合わせによってキーされた第１の共有クラスキャッシュ（ＳＣＣ）を、サーバによって管理される中央ＳＣＣリポジトリ内で特定し、（ｉｖ）前記第１のＳＣＣを特定したことに応じて、（ａ）前記第１のＳＣＣを前記ワーカノードに関連するクライアントに送信し、（ｂ）前記第１のＳＣＣをローカルＳＣＣリポジトリに格納し、（ｖ）前記クライアントから、前記マネージドランタイムアプリケーションによって発信され、前記第１のＳＣＣに関連する第１の更新要求を受信することであって、当該第１の更新要求は、前記アプリケーションイメージ識別子、前記引数、前記ワーカノードに関する情報、追加のクラスデータ、事前コンパイルデータ、ならびに前記第１のＳＣＣに関して経時的に生成および蓄積された実行データを含む、当該マネージドランタイムアプリケーションのタイプに関連し、（ｖｉ）前記第１の更新要求を拒否することを決定し、（ｖｉｉ）前記第１の更新要求を拒否したことに応じて、前記クライアントに第２のＳＣＣを送信する。
【図面の簡単な説明】
【0006】
【図1】本発明の一実施形態に係るクラウドコンピューティング環境を示す図である。
【図2】本発明の一実施形態に係る抽象化モデルレイヤを示す図である。
【図3】本発明の少なくとも１つの実施形態に係るシステムのブロック図である。
【図4】本発明の少なくとも１つの実施形態に従って少なくとも部分的に実行される方法を示すフローチャートである。
【図5】、本発明の少なくとも１つの実施形態に係るシステムの機械論理（例えば、ソフトウェア）部分を示すブロック図である。
【図6】本発明の少なくとも１つの実施形態に係るシステムの一部のコンポーネントを示すブロック図である。
【図7】本発明の少なくとも１つの実施形態に係る様々なシステムコンポーネント間の情報フローを示すブロック図である。
【発明を実施するための形態】
【0007】
本発明のいくつかの実施形態に係るコンテナオーケストレータ（container orchestrator）は、クラス共有オーケストレータ（ＣＳＯ：class sharing orchestrator）サブシステムを備えている。ＣＳＯは、クラウド環境におけるコンテナ化されたアプリケーション間でのクラスデータの共有を管理し、アプリケーションのスタートアップ性能、ＣＰＵ消費、およびメモリ使用量を改善する。共有クラスキャッシュは、互いに分離して動作する複数の仮想マシンが、アプリケーションクラスデータを保持する単一のキャッシュ（本明細書では「共有クラスキャッシュ」（ＳＣＣ：shared class cache）と称する）を共有することを可能にする。メモリマップファイル（memory mapped file）として構成されたクラスキャッシュは、（１）クラスの不変部分（immutable part）、（２）事前（ＡＯＴ）コンパイルコード、（３）プロファイリングデータという３つの情報を格納する。
【0008】
この詳細な説明のセクションは、以下の（ｉ）「ハードウェアおよびソフトウェア環境」、（ｉｉ）「実施形態例」、（ｉｉｉ）「さらなる注記もしくは実施形態またはその両方」、および（ｉｖ）「定義」のサブセクションに分かれている。
【0009】
Ｉ．ハードウェアおよびソフトウェア環境
本発明は、任意の可能な技術詳細レベルで統合されたシステム、方法もしくはコンピュータプログラム製品またはそれらの組み合わせとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでもよい。
本発明は、任意の可能な技術詳細レベルで統合されたシステム、方法もしくはコンピュータプログラム製品またはそれらの組み合わせとすることができる。コンピュータプログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでもよい。
【0010】
コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持し、記憶することができる有形の装置とすることができる。コンピュータ可読記憶媒体は、一例として、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置またはこれらの適切な組み合わせであってよい。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ（またはフラッシュメモリ）、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化された装置、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶媒体は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体として解釈されるべきではない。
【0011】
本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピュータ装置／処理装置へダウンロード可能である。あるいは、ネットワーク（例えばインターネット、ＬＡＮ、ＷＡＮもしくはワイヤレスネットワークまたはこれらの組み合わせ）を介して、外部コンピュータまたは外部記憶装置へダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータもしくはエッジサーバまたはこれらの組み合わせを備えることができる。各コンピュータ装置／処理装置内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、当該コンピュータ可読プログラム命令を、各々のコンピュータ装置／処理装置におけるコンピュータ可読記憶媒体に記憶するために転送する。
【0012】
本発明の動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用構成データ、または、スモールトークやＣ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードもしくはオブジェクトコードのいずれかとすることができる。コンピュータ可読プログラム命令は、スタンドアロン型ソフトウェアパッケージとして完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または、完全にリモートコンピュータもしくはサーバ上で実行可能である。後者の場合、リモートコンピュータは、ＬＡＮやＷＡＮを含む任意の種類のネットワークを介してユーザのコンピュータに接続してもよいし、外部コンピュータに（例えば、インターネットサービスプロバイダを使用してインターネットを介して）接続してもよい。いくつかの実施形態において、例えばプログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行する目的で当該電子回路をカスタマイズするために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。
【0013】
本発明の態様は、本明細書において、本発明の実施形態に係る方法、装置（システム）、およびコンピュータプログラム製品のフローチャートもしくはブロック図またはその両方を参照して説明されている。フローチャートもしくはブロック図またはその両方における各ブロック、および、フローチャートもしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実行可能である。
【0014】
これらのコンピュータ可読プログラム命令は、機械を生産するために、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサに提供することができる。これにより、このようなコンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行するための手段を創出する。これらのコンピュータ可読プログラム命令はさらに、コンピュータ、プログラマブルデータ処理装置もしくは他の装置またはこれらの組み合わせに対して特定の態様で機能するよう命令可能なコンピュータ可読記憶媒体に記憶することができる。これにより、命令が記憶された当該コンピュータ可読記憶媒体は、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作の態様を実行するための命令を含む製品を構成する。
【0015】
また、コンピュータ可読プログラム命令を、コンピュータ、他のプログラマブル装置、または他の装置にロードし、一連の動作ステップを当該コンピュータ、他のプログラマブル装置、または他の装置上で実行させることにより、コンピュータ実行プロセスを生成してもよい。これにより、当該コンピュータ、他のプログラマブル装置、または他の装置上で実行される命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行する。
【0016】
図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に係るシステム、方法およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実行するための１つ以上の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表すことができる。他の一部の実装形態において、ブロック内に示した機能は、各図に示す順序とは異なる順序で実行されてもよい。例えば、関係する機能に応じて、連続して示される２つのブロックが、実際には、１つの工程として達成されてもよいし、同時もしくは略同時に実行されてもよいし、部分的もしくは全体的に時間的に重複した態様で実行されてもよいし、ブロックが場合により逆順で実行されてもよい。なお、ブロック図もしくはフローチャートまたはその両方における各ブロック、および、ブロック図もしくはフローチャートまたはその両方における複数のブロックの組み合わせは、特定の機能もしくは動作を行う、または専用ハードウェアとコンピュータ命令との組み合わせを実行する、専用ハードウェアベースのシステムによって実行可能である。
【0017】
本開示は、クラウドコンピューティングに関する詳細な説明を含むが、本明細書に記載された教示の実装形態は、クラウドコンピューティング環境に限定されないことを理解されたい。むしろ、本発明の実施形態は、現在知られている又は後に開発される任意の他のタイプのコンピューティング環境と組み合わせて実施することが可能である。
【0018】
クラウドコンピューティングは、設定可能なコンピューティングリソースの共有プール（例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシンおよびサービス）へ、簡便かつオンデマンドのネットワークアクセスを可能にするためのサービス提供のモデルであり、リソースは、最小限の管理労力または最小限のサービスプロバイダとのやり取りによって速やかに準備（provision）およびリリースできるものである。このクラウドモデルは、少なくとも５つの特性、少なくとも３つのサービスモデル、および少なくとも４つの展開モデルを含むことができる。
【0019】
特性は以下の通りである。
【0020】
オンデマンド・セルフサービス：クラウドの消費者は、サービスプロバイダとの人的な対話を必要することなく、必要に応じて自動的に、サーバ時間やネットワークストレージなどのコンピューティング能力を一方的に準備することができる。
【0021】
ブロード・ネットワークアクセス：コンピューティング能力はネットワーク経由で利用可能であり、また、標準的なメカニズムを介してアクセスできる。それにより、異種のシンまたはシッククライアントプラットフォーム（例えば、携帯電話、ラップトップ、ＰＤＡ）による利用が促進される。
【0022】
リソースプーリング：プロバイダのコンピューティングリソースはプールされ、マルチテナントモデルを利用して複数の消費者に提供される。様々な物理リソースおよび仮想リソースが、需要に応じて動的に割り当ておよび再割り当てされる。一般に消費者は、提供されたリソースの正確な位置を管理または把握していないため、位置非依存（location independence）の感覚がある。ただし消費者は、より高い抽象レベル（例えば、国、州、データセンタ）では場所を特定可能な場合がある。
【0023】
迅速な柔軟性（elasticity）：コンピューティング能力は、迅速かつ柔軟に準備することができるため、場合によっては自動的に、直ちにスケールアウトし、また、速やかにリリースされて直ちにスケールインすることができる。消費者にとって、準備に利用可能なコンピューティング能力は無制限に見える場合が多く、任意の時間に任意の数量で購入することができる。
【0024】
測定されるサービス：クラウドシステムは、サービスの種類（例えば、ストレージ、処理、帯域幅、アクティブユーザアカウント）に適したある程度の抽象化レベルでの測定機能を活用して、リソースの使用を自動的に制御し最適化する。リソース使用量を監視、制御、および報告して、利用されるサービスのプロバイダおよび消費者の両方に透明性を提供することができる。
【0025】
サービスモデルは以下の通りである。
【0026】
サービスとしてのソフトウェア（ＳａａＳ）：消費者に提供される機能は、クラウドインフラストラクチャ上で動作するプロバイダのアプリケーションを利用できることである。当該そのアプリケーションは、ウェブブラウザ（例えばウェブメール）などのシンクライアントインタフェースを介して、各種のクライアント装置からアクセスできる。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージや、個別のアプリケーション機能さえも含めて、基礎となるクラウドインフラストラクチャの管理や制御は行わない。ただし、ユーザ固有の限られたアプリケーション構成の設定はその限りではない。
【0027】
サービスとしてのプラットフォーム（ＰａａＳ）：消費者に提供される機能は、プロバイダによってサポートされるプログラム言語およびツールを用いて、消費者が作成または取得したアプリケーションを、クラウドインフラストラクチャに展開（deploy）することである。消費者は、ネットワーク、サーバ、オペレーティングシステム、ストレージを含む、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、展開されたアプリケーションを制御でき、かつ場合によってはそのホスティング環境の構成も制御できる。
【0028】
サービスとしてのインフラストラクチャ（ＩａａＳ）：消費者に提供される機能は、オペレーティングシステムやアプリケーションを含む任意のソフトウェアを消費者が展開および実行可能な、プロセッサ、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースを準備することである。消費者は、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、オペレーティングシステム、ストレージ、および展開されたアプリケーションを制御でき、かつ場合によっては一部のネットワークコンポーネント（例えばホストファイアウォール）を部分的に制御できる。
【0029】
展開モデルは以下の通りである。
【0030】
プライベートクラウド：このクラウドインフラストラクチャは、特定の組織専用で運用される。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
【0031】
コミュニティクラウド：このクラウドインフラストラクチャは、複数の組織によって共有され、共通の関心事（例えば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンス）を持つ特定のコミュニティをサポートする。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
【0032】
パブリッククラウド：このクラウドインフラストラクチャは、不特定多数の人々や大規模な業界団体に提供され、クラウドサービスを販売する組織によって所有される。
【0033】
ハイブリッドクラウド：このクラウドインフラストラクチャは、２つ以上のクラウドモデル（プライベート、コミュニティまたはパブリック）を組み合わせたものとなる。それぞれのモデル固有の実体は保持するが、標準または個別の技術によってバインドされ、データとアプリケーションの可搬性（例えば、クラウド間の負荷分散のためのクラウドバースティング）を実現する。
【0034】
クラウドコンピューティング環境は、ステートレス性（statelessness）、低結合性（low coupling）、モジュール性（modularity）および意味論的相互運用性（semantic interoperability）に重点を置いたサービス指向型環境である。クラウドコンピューティングの中核にあるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。
【0035】
ここで、図１に例示的なクラウドコンピューティング環境５０を示す。図示するように、クラウドコンピューティング環境５０は１つ以上のクラウドコンピューティングノード１０を含む。これらに対して、クラウド消費者が使用するローカルコンピュータ装置（例えば、ＰＤＡもしくは携帯電話５４Ａ、デスクトップコンピュータ５４Ｂ、ラップトップコンピュータ５４Ｃ、もしくは自動車コンピュータシステム５４Ｎまたはこれらの組み合わせなど）は通信を行うことができる。ノード１０は互いに通信することができる。ノード１０は、例えば、上述のプライベート、コミュニティ、パブリックもしくはハイブリッドクラウドまたはこれらの組み合わせなど、１つ以上のネットワークにおいて、物理的または仮想的にグループ化（不図示）することができる。これにより、クラウドコンピューティング環境５０は、サービスとしてのインフラストラクチャ、プラットフォームもしくはソフトウェアまたはこれらの組み合わせを提供することができ、クラウド消費者はこれらについて、ローカルコンピュータ装置上にリソースを維持する必要がない。なお、図１に示すコンピュータ装置５４Ａ～Ｎの種類は例示に過ぎず、コンピューティングノード１０およびクラウドコンピューティング環境５０は、任意の種類のネットワークもしくはネットワークアドレス指定可能接続（例えば、ウェブブラウザの使用）またはその両方を介して、任意の種類の電子装置と通信可能であることを理解されたい。
【0036】
ここで、クラウドコンピューティング環境５０（図１）によって提供される機能的抽象化レイヤのセットを図２に示す。なお、図２に示すコンポーネント、レイヤおよび機能は例示に過ぎず、本発明の実施形態はこれらに限定されないことをあらかじめ理解されたい。図示するように、以下のレイヤおよび対応する機能が提供される。
【0037】
ハードウェアおよびソフトウェアレイヤ６０は、ハードウェアコンポーネントおよびソフトウェアコンポーネントを含む。ハードウェアコンポーネントの例には、メインフレーム６１、縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャベースのサーバ６２、サーバ６３、ブレードサーバ６４、記憶装置６５、ならびにネットワークおよびネットワークコンポーネント６６が含まれる。いくつかの実施形態において、ソフトウェアコンポーネントは、ネットワークアプリケーションサーバソフトウェア６７およびデータベースソフトウェア６８を含む。
【0038】
仮想化レイヤ７０は、抽象化レイヤを提供する。当該レイヤから、例えば、仮想サーバ７１、仮想ストレージ７２、仮想プライベートネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティングシステム７４、仮想クライアント７５、ならびにクラス共有オーケストレータ７６などの仮想エンティティを提供することができる。
【0039】
一例として、管理レイヤ８０は以下の機能を提供することができる。リソース準備８１は、クラウドコンピューティング環境内でタスクを実行するために利用されるコンピューティングリソースおよび他のリソースの動的な調達を可能にする。計量および価格設定８２は、クラウドコンピューティング環境内でリソースが利用される際のコスト追跡、およびこれらのリソースの消費に対する請求またはインボイス送付を可能にする。一例として、これらのリソースはアプリケーションソフトウェアのライセンスを含んでもよい。セキュリティは、データおよび他のリソースに対する保護のみならず、クラウド消費者およびタスクの識別確認を可能にする。ユーザポータル８３は、消費者およびシステム管理者にクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、要求されたサービスレベルが満たされるように、クラウドコンピューティングリソースの割り当ておよび管理を可能にする。サービス品質保証（ＳＬＡ）の計画および履行８５は、ＳＬＡに従って将来必要になると予想されるクラウドコンピューティングリソースの事前手配および調達を可能にする。
【0040】
ワークロードレイヤ９０は、クラウドコンピューティング環境の利用が可能な機能の例を提供する。このレイヤから提供可能なワークロードおよび機能の例には、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想教室教育の配信９３、データ分析処理９４、取引処理９５が含まれる。
【0041】
次に、本発明に係るソフトウェアもしくは方法またはその両方のために可能なハードウェアおよびソフトウェア環境の一実施形態を、図面を参照して詳細に説明する。図３は、ネットワーク化コンピュータシステム１００の様々な部分を示す機能ブロック図である。ネットワーク化コンピュータシステム１００は、コンテナオーケストレータサブシステム１０２、クライアントコンピュータサブシステム１０４、通信ネットワーク１１４、サーバコンピュータ２００、通信ユニット２０２、プロセッサセット２０４、入出力（Ｉ／Ｏ）インタフェースセット２０６、メモリ２０８、持続性ストレージ２１０、ディスプレイデバイス２１２、外部デバイス２１４、ランダムアクセスメモリ（ＲＡＭ２３０）、キャッシュ２３２、およびコンテナオーケストレータプログラム３００を含む。
【0042】
コンテナオーケストレータサブシステム１０２は、多くの点で、本発明における様々なコンピュータサブシステムを代表している。したがって、コンテナオーケストレータサブシステム１０２のいくつかの部分について、以下の段落にて説明する。
【0043】
コンテナオーケストレータサブシステム１０２は、ラップトップコンピュータ、タブレットコンピュータ、ネットブックコンピュータ、パーソナルコンピュータ（ＰＣ）、デスクトップコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、または通信ネットワーク１１４を介してクライアントサブシステムと通信可能な任意のプログラム可能電子デバイスとすることができる。コンテナオーケストレータプログラム３００は、この詳細な説明のセクションにおける「実施形態例」サブセクションにて以下で詳述する特定のソフトウェア機能を作成、管理、および制御するために使用される機械可読命令もしくはデータまたはその両方の集合体である。
【0044】
コンテナオーケストレータサブシステム１０２は、通信ネットワーク１１４を介して他のコンピュータサブシステムと通信可能である。通信ネットワーク１１４は、例えば、ローカルエリアネットワーク（ＬＡＮ）、インターネットなどのワイドエリアネットワーク（ＷＡＮ）、またはその組み合わせとすることができ、有線、無線、または光ファイバ接続を含むことができる。一般に、通信ネットワーク１１４は、サーバおよびクライアントサブシステム間の通信をサポートする接続およびプロトコルの任意の組み合わせとすることができる。
【0045】
コンテナオーケストレータサブシステム１０２は、多くの両矢印を有するブロック図として示される。これらの両矢印（個別の参照数字はない）は、コンテナオーケストレータサブシステム１０２の様々なコンポーネント間の通信を実現する、通信ファブリックを表す。この通信ファブリックは、プロセッサ（マイクロプロセッサ、通信およびネットワークプロセッサなど）、システムメモリ、周辺デバイス、およびシステム内の他の任意のハードウェアコンポーネント間でデータもしくは制御情報またはその両方を渡すために設計された任意のアーキテクチャで実装することができる。例えば、通信ファブリックは、少なくとも部分的に、１つ以上のバスで実装することができる。
【0046】
メモリ２０８および持続性ストレージ（persistent storage）２１０は、コンピュータ可読記憶媒体である。一般に、メモリ２０８は、任意の適切な揮発性または不揮発性のコンピュータ可読記憶媒体を含むことができる。なお、現在もしくは近い将来またはその両方において、（ｉ）外部デバイス２１４が、メモリの一部または全部をコンテナオーケストレータサブシステム１０２に供給できる可能性があること、もしくは（ｉｉ）コンテナオーケストレータサブシステム１０２の外部のデバイスが、コンテナオーケストレータサブシステム１０２にメモリを提供できる可能性があること、またはその両方の可能性があることに留意されたい。
【0047】
コンテナオーケストレータプログラム３００は、（通常はメモリ２０８の１つ以上のメモリを通じて）それぞれのコンピュータプロセッサセット２０４の１つ以上がアクセスもしくは実行またはその両方を行うために、持続性ストレージ２１０に記憶される。持続性ストレージ２１０は、（ｉ）少なくとも一時的な信号よりも持続性があり、（ｉｉ）プログラム（そのソフトロジックもしくはデータまたはその両方を含む）を、有形媒体（磁気または光学ドメインなど）上に記憶し、（ｉｉｉ）永久ストレージ（permanent storage）よりも実質的に持続性が低いものである。あるいは、データストレージは、持続性ストレージ２１０によって提供されるストレージの種類よりも持続的もしくは永久的またはその両方であってもよい。
【0048】
コンテナオーケストレータプログラム３００は、機械可読かつ機械実行可能命令もしくは実体データ（すなわち、データベースに記憶されたデータ種類）またはその両方を含んでもよい。この特定の実施形態では、持続性ストレージ２１０は、磁気ハードディスクドライブを含む。いくつかの可能な変形例を挙げると、持続性ストレージ２１０は、ソリッドステートハードドライブ、半導体記憶装置、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、フラッシュメモリ、またはプログラム命令またはデジタル情報を記憶可能な他の任意のコンピュータ可読記憶媒体を含むことができる。
【0049】
持続性ストレージ２１０が使用する媒体は、取り外し可能であってもよい。例えば、リムーバブルハードドライブが持続性ストレージ２１０に使用されてもよい。他の例としては、持続性ストレージ２１０の一部でもある別のコンピュータ可読記憶媒体上に転送するためにドライブに挿入される光および磁気ディスク、サムドライブ、ならびにスマートカードが挙げられる。
【0050】
通信ユニット２０２は、これらの例では、コンテナオーケストレータサブシステム１０２の外部の他のデータ処理システムまたはデバイスとの通信を可能にする。これらの例では、通信ユニット２０２は、１つ以上のネットワークインタフェースカードを含む。通信ユニット２０２は、物理的および無線通信リンクのいずれかまたは両方を使用して通信を実現してもよい。本明細書で説明するソフトウェアモジュールは、通信ユニット（通信ユニット２０２など）を介して（持続性ストレージ２１０などの）持続性記憶装置にダウンロードされてもよい。
【0051】
Ｉ／Ｏインタフェースセット２０６は、サーバコンピュータ２００とのデータ通信においてローカル接続可能な他のデバイスとのデータの入出力を可能にする。例えば、Ｉ／Ｏインタフェースセット２０６は、外部デバイス２１４との接続を実現する。外部デバイス２１４は、キーボード、キーパッド、タッチスクリーン、もしくは他の適切な入力デバイスまたはその組み合わせなどのデバイスを含んでもよい。外部デバイス２１４は、例えば、サムドライブ、ポータブル光ディスクまたは磁気ディスク、およびメモリカードなどのポータブル・コンピュータ可読記憶媒体を含むこともできる。本発明の実施形態を実施するために使用されるソフトウェアおよびデータ（例えば、コンテナオーケストレータプログラム３００）は、このようなポータブル・コンピュータ可読記憶媒体に記憶することができる。これらの実施形態において、関連するソフトウェアは、その全体または一部が、Ｉ／Ｏインタフェースセット２０６を介して持続性ストレージ２１０にロードされてもよい（または、ロードされなくてもよい）。また、Ｉ／Ｏインタフェースセット２０６は、ディスプレイデバイス２１２ともデータ通信接続する。
【0052】
ディスプレイデバイス２１２は、データをユーザに表示する機構を実現するものであり、例えば、コンピュータモニタまたはスマートフォンの表示画面であってもよい。
【0053】
本明細書に記載のプログラムは、本発明の特定の実施形態において当該プログラムが実装される用途に基づいて識別される。しかしながら、本明細書におけるいかなる具体的なプログラム名称も、便宜上使用しているに過ぎない。したがって本発明は、そのような名称によって識別もしくは示唆またはその両方がなされるいずれかの特定の用途における使用に限定されるべきものではない。
【0054】
本発明の種々の実施形態を例示として説明してきたが、網羅的であることや、開示した実施形態に限定することを意図したものではない。当業者には明らかなように、記載した各実施形態の範囲から逸脱することなく、多くの変更および変形が可能である。本明細書で用いられる用語は、各実施形態の原理、実際の用途、または市場で確認される技術に対する技術的な改善を最もよく説明するために、または、他の当業者が本明細書に開示する各実施形態を理解できるように選択されたものである。
【0055】
ＩＩ．実施形態例
図４は、本発明に従った方法を示すフローチャート２５０である。図５は、フローチャート２５０の方法動作の少なくとも一部を実行するためのコンテナオーケストレータプログラム３００を示す図である。本方法および関連するソフトウェアを、図４（方法動作ブロックについて）および図５（ソフトウェアブロックについて）を主に参照しながら、以下の段落を通じて説明する。図５のコンテナオーケストレータプログラム３００を記憶可能な物理的領域の１つとして、持続性ストレージ２１０（図３参照）が挙げられる。
図４は、本発明に従った方法を示すフローチャート２５０である。図５は、フローチャート２５０の方法動作の少なくとも一部を実行するためのコンテナオーケストレータプログラム３００を示す図である。本方法および関連するソフトウェアを、図４（方法動作ブロックについて）および図５（ソフトウェアブロックについて）を主に参照しながら、以下の段落を通じて説明する。図５のコンテナオーケストレータプログラム３００を記憶可能な物理的領域の１つとして、持続性ストレージ２１０（図３参照）が挙げられる。
【0056】
処理は、動作Ｓ２５５から開始する。Ｓ２５５にて、コンテナオーケストレータプログラム３００は、コンテナ化環境の第１のコンテナにおけるマネージドランタイムアプリケーション（managed runtime application）の起動を開始する。コンテナオーケストレータプログラム３００のクラス共有オーケストレータモジュール（ＣＳＯモジュール３１０）は、アプリケーションイメージ識別子、マネージドランタイムアプリケーションの第１のインスタンスに渡される引数のリスト、およびマネージドランタイムアプリケーションの第１のインスタンスをホストするワーカノードに対応するワーカノード識別子を含む、マネージドランタイムアプリケーションに関する情報を受信する。
【0057】
処理は、動作Ｓ２６０に進む。Ｓ２６０にて、コンテナオーケストレータプログラム３００の共有クラスキャッシュモジュール３１２は、マネージドランタイムアプリケーションによる使用に適した共有クラスキャッシュ（ＳＣＣ：shared class cache）を中央ＳＣＣリポジトリから検索する。ここでの適性は、マネージドランタイムアプリケーションに関連する特定の属性に基づく。これらの属性は、アプリケーションイメージに関連する識別子、アプリケーションの起動または操作に関連する１つ以上の引数、もしくは第１のコンテナに関連する識別子またはその組み合わせを含むことができる。
【0058】
処理は、動作Ｓ２６５に進む。Ｓ２６５にて、コンテナオーケストレータプログラム３００のＣＳＯモジュール３１０のキャッシュ共有オーケストレータクライアントサブモジュール（ＣＳＯクライアントサブモジュール３１６）は、共有クラスキャッシュをマネージドランタイムアプリケーションにローカルに、すなわち第１のコンテナに格納する。
【0059】
処理は、動作Ｓ２７０に進む。Ｓ２７０にて、ＣＳＯ中央サーバサブモジュール３１４は、ＣＳＯクライアントサブモジュール３１６（マネージドランタイムアプリケーション、または第１のコンテナの内部もしくは外部で実行されている他のアプリケーションに対応）から更新要求を受信する。
【0060】
処理は、判断Ｓ２７５に進む。Ｓ２７５にて、ＣＳＯ中央サーバサブモジュール３１４は、上述の動作Ｓ２７０に関連して受信した更新要求を受け入れるか拒否するかを判断する。ＣＳＯ中央サーバサブモジュール３１４が更新要求を拒否すると判断した場合、（判断Ｓ２７５にて「拒否」の分岐）、処理は動作Ｓ２８０に進む。Ｓ２８０にて、ＣＳＯ中央サーバサブモジュール３１４は、要求者（この場合、ＣＳＯクライアントサブモジュール３１６）に、マネージドランタイムアプリケーションが使用するための第２の共有クラスキャッシュを送信する。
【0061】
ＣＳＯ中央サーバサブモジュール３１４が更新要求を受け入れると判断した場合（判断Ｓ２７５にて「受諾」の分岐）、処理は動作Ｓ２８５に進む。Ｓ２８５にて、ＣＳＯ中央サーバサブモジュール３１４は、過去に受信され格納された他の要求（ある場合）と共に、更新要求を格納する。
【0062】
要求が閾値数（threshold number）だけ蓄積されると（または、他のトリガイベントが発生すると）、ＣＳＯ中央サーバサブモジュール３１４は、蓄積された複数の更新要求を分析する。図４の実施形態では、ＣＳＯ中央サーバサブモジュール３１４は、２つ以上の更新要求が少なくともいくつかの共通データを共有していると判定する。なお、いくつかの実施形態では、同じアプリケーションタイプに関連する複数の更新要求が一緒に分析される。
【0063】
処理は、動作Ｓ２９０に進む。Ｓ２９０にて、ＣＳＯ中央サーバサブモジュール３１４は、２つ以上の更新要求が共通データを共有していると判断したことに応じて、共通データを第１の共有クラスキャッシュに追加し、第２の共有クラスキャッシュを生成する。
【0064】
処理は、動作Ｓ２９５に進む。Ｓ２９５にて、ＣＳＯ中央サーバサブモジュール３１４は、第１の共有クラスキャッシュに関連するデプロイメントからのその後の更新要求を拒否する。
【0065】
ＩＩＩ．さらなる注記もしくは実施形態またはその両方
本発明のいくつかの実施形態は、動的言語環境（例えば、Ｊａｖａ）に関する現在の技術水準に関して、以下の事実、潜在的な問題、もしくは潜在的な改善領域またはその組み合わせのうちの１つ以上を認識することができる：（ｉ）ジャストインタイム（ＪＩＴ）コンパイルは、オーバーヘッドを追加する可能性があり、これが特に、ＪＩＴコンパイルの大部分が行われるスタートアップ時に、アプリケーションのパフォーマンスに悪影響を与える可能性があること、（ｉｉ）ＪＩＴコンパイルは、高速なアプリケーションのスタートアップおよびランプアップを妨げる可能性があること、もしくは（ｉｉｉ）クラスファイルはオンデマンドでロードされるが、ロードするクラス数が多いアプリケーションでは、クラスロードがアプリケーションスタートアップの遅れの大きな原因となる可能性があること、またはこれらの組み合わせ。
本発明のいくつかの実施形態は、動的言語環境（例えば、Ｊａｖａ）に関する現在の技術水準に関して、以下の事実、潜在的な問題、もしくは潜在的な改善領域またはその組み合わせのうちの１つ以上を認識することができる：（ｉ）ジャストインタイム（ＪＩＴ）コンパイルは、オーバーヘッドを追加する可能性があり、これが特に、ＪＩＴコンパイルの大部分が行われるスタートアップ時に、アプリケーションのパフォーマンスに悪影響を与える可能性があること、（ｉｉ）ＪＩＴコンパイルは、高速なアプリケーションのスタートアップおよびランプアップを妨げる可能性があること、もしくは（ｉｉｉ）クラスファイルはオンデマンドでロードされるが、ロードするクラス数が多いアプリケーションでは、クラスロードがアプリケーションスタートアップの遅れの大きな原因となる可能性があること、またはこれらの組み合わせ。
【0066】
いくつかの実施形態において、「アプリケーション」という用語は、「ジャストインタイム」コンパイルを実行することができる仮想マシン上で動作するソフトウェアプログラムを指す。このようなアプリケーションの非限定的な例としては、Ｓｐｒｉｎｇ Ｂｏｏｔで構築された証券取引所ウェブアプリケーションや、Ｏｐｅｎ Ｌｉｂｅｒｔｙで構築されたホテル予約ウェブアプリケーションが挙げられる。Ｓｐｒｉｎｇ ＢｏｏｔおよびＯｐｅｎ Ｌｉｂｅｒｔｙは、Ｊａｖａ仮想マシンの上で動作する。
【0067】
本明細書では、特定の製品（例えば、「Ｊａｖａ」、「ＯｐｅｎＪ９」、および「ＪＶＭ」）を参照しているが、本発明の実施形態は、このような製品に限定されるものではない。いくつかの実施形態は、共有クラスキャッシュなどの特定のキャッシュ機構を採用する他の動的実行環境にも同様に適用される。（なお、「Ｓｐｒｉｎｇ Ｂｏｏｔ」、「Ｏｐｅｎ Ｌｉｂｅｒｔｙ」、「Ｊａｖａ」、「Ｊａｖａ仮想マシン」、「ＯｐｅｎＪ９」、もしくは「ＪＶＭ」という用語またはその組み合わせは、世界中の様々な法域における商標権の対象となる可能性があり、ここでは、このような商標権が存在し得る範囲で標章によって適正に称される製品またはサービスに対して言及する場合にのみ使用される）。
【0068】
本発明のいくつかの実施形態は、以下の特徴、特性、もしくは利点またはその組み合わせのうちの１つ以上を含むことができる：（ｉ）コンパイルされたメソッドのキャッシュを継続的に改善する、（ｉｉ）継続的かつ段階的な改善アプローチを採用して、ＪＩＴは、追跡してキャッシュにマージ可能なメソッドの高速バージョンをコンパイルする、（ｉｉｉ）クラウド上のアプリケーションランタイムのユースケースを最適化する、（ｉｖ）コンテナ構成を自動化するオーケストレーションフレームワークを中心としたソリューション、（ｖ）パフォーマンスの向上に使用可能な統計情報を中央領域に送信して再利用し、アプリケーションのコンパイルプロファイルを継続的に改善する、（ｖｉ）コンパイルプロファイルは動的で、中央で通信（communicate centrally）でき、それぞれのワークロードに関連するコンパイルプロファイルをオンデマンドで取得し改善することができる。
【0069】
本発明のいくつかの実施形態は、本明細書においてＯｐｅｎＪ９に関連して説明されるが、ＯｐｅｎＪ９への適用可能性という点で限定されるものではない。ＯｐｅｎＪ９では、Ｊａｖａアプリケーションのクラスデータは、共有クラスキャッシュ（ＳＣＣ）に格納される。共有クラスキャッシュ（ＳＣＣ）とは、以下を含む情報を格納するメモリマップファイルである：（ｉ）クラスの不変部分、（ｉｉ）事前（ＡＯＴ）コンパイルコード、および（ｉｉｉ）プロファイリングデータ。必要なクラスはメモリマップファイル（ＲＡＭに常駐している場合が多いＳＣＣ）から素早くロードでき、ＪＩＴコンパイルは、キャッシュされたＡＯＴコンパイル済みボディを迅速にロードするように削減されるので、アプリケーションのスタートアップが加速される。ＳＣＣのデータ投入（population）は実行時に透過的に生成されるため、アプリケーションに必要なクラスとメソッドのみがキャッシュされ、ＡＯＴボディは少なくともある程度、実行中アプリケーションに合わせて調整されるようになる（なお、「ＯｐｅｎＪ９」もしくは「Ｊａｖａ」という用語またはその両方は、世界中の様々な法域における商標権の対象となる可能性があり、ここでは、このような商標権が存在し得る範囲で標章によって適正に称される製品またはサービスに対して言及する場合にのみ使用される）。
【0070】
本発明のいくつかの実施形態に係るクラス共有オーケストレータ（ＣＳＯ）は、少なくとも以下の機能を実行する：（ｉ）クラウド上のＪａｖａアプリケーションのすべてのデプロイメントに、互換性のある高品質のＳＣＣを提供する、（ｉｉ）実行中のアプリケーションからＳＣＣデータを収集し、収集したＳＣＣデータに基づいてオフライン処理を実行することによって、実行中のアプリケーションへの影響を最小限にしながら各デプロイメントに提供するＳＣＣの品質を継続的に向上させる。
【0071】
クラス共有オーケストレータ（ＣＳＯ）は、以下のようにして従来のソリューションを改善する：（ｉ）共有クラスキャッシュ（ＳＣＣ）の品質を向上させる、もしくは、（ｉｉ）コンテナ環境におけるＪａｖａアプリケーションのＳＣＣ共有機能の使い勝手を向上させる、またはその両方を行う。これらの改善方法については、以下の段落にて列挙して説明する。
【0072】
（ＳＣＣの品質の向上）
いくつかの実施形態において、実行中のコンテナ化Ｊａｖａアプリケーションは、ＳＣＣ統合メカニズム（SCC consolidation mechanism）を介して、対応する（元の）ＳＣＣに自身のランタイムクラスデータを寄与する。統合メカニズムは、同種の実行中アプリケーションからの更新を結合して、将来のアプリケーションが使用するために、より高品質の新たに形成されたＳＣＣを生成する。このメカニズムは、新たに形成されたＳＣＣが、元のＳＣＣと少なくとも同等か、またはそれ以上の性能を持つことを保証するものである。
いくつかの実施形態において、実行中のコンテナ化Ｊａｖａアプリケーションは、ＳＣＣ統合メカニズム（SCC consolidation mechanism）を介して、対応する（元の）ＳＣＣに自身のランタイムクラスデータを寄与する。統合メカニズムは、同種の実行中アプリケーションからの更新を結合して、将来のアプリケーションが使用するために、より高品質の新たに形成されたＳＣＣを生成する。このメカニズムは、新たに形成されたＳＣＣが、元のＳＣＣと少なくとも同等か、またはそれ以上の性能を持つことを保証するものである。
【0073】
（コンテナ環境におけるＪａｖａアプリケーションのＳＣＣ共有機能の使い勝手の向上）
いくつかの実施形態において、ＳＣＣ更新メカニズムは、クラウド上の実行中アプリケーション間のＳＣＣデータ交換のサイズ、およびＳＣＣデータ交換の時間を最適化し、実行中アプリケーションおよびネットワーク帯域幅に対するＣＳＯの影響を最小化する。
いくつかの実施形態において、ＳＣＣ更新メカニズムは、クラウド上の実行中アプリケーション間のＳＣＣデータ交換のサイズ、およびＳＣＣデータ交換の時間を最適化し、実行中アプリケーションおよびネットワーク帯域幅に対するＣＳＯの影響を最小化する。
【0074】
図６のブロック図６００は、本発明に係るシステムのコンポーネントの概要を示す図である。このシステムは、コンテナオーケストレータ６０２（新たなＪａｖａアプリケーションを起動する）、クラス共有オーケストレータ（ＣＳＯ）中央サーバエージェント６０４、ＳＣＣ統合メカニズム６０６、ＳＣＣセットアップメカニズム６０８、ＳＣＣ更新メカニズム６１０、ＣＳＯクライアントエージェント６１２、中央共有クラスキャッシュ（ＳＣＣ）リポジトリ６１４、およびローカルＳＣＣリポジトリ６１６を含む。様々なシステムコンポーネント間でのインタラクションおよび情報のフローを矢印で示し、以下の数段落にて説明する。
【0075】
いくつかの実施形態では、ＣＳＯに以下のソフトウェアエージェントを追加する：（ｉ）ＣＳＯ中央サーバエージェント６０４もしくは（ｉｉ）ＣＳＯクライアントエージェント６１２またはその両方。
【0076】
（ＣＳＯ中央サーバエージェント）
【0077】
いくつかの実施形態では、ＣＳＯ中央サーバエージェント６０４を、ＣＳＯクライアントエージェント（例えばＣＳＯクライアントエージェント６１２など）をホストするノードから分離した別個の専用ノードに配置する。ＣＳＯ中央サーバエージェント６０４は、以下の機能を実行する：（ｉ）スタートアップ時に、新たに起動されたＪａｖａアプリケーションコンテナに適切なＳＣＣを提供する。ここで、ＣＳＯ中央サーバエージェント６０４は、ＣＳＯが（ＣＳＯの範囲内で）実行中のすべてのＪａｖａアプリケーションイメージに関する情報を持つことができるように、既存のコンテナオーケストレーションシステムと通信する、（ｉｉ）各ＪａｖａアプリケーションイメージのＳＣＣを維持するために使用される中央共有クラスキャッシュ（ＳＣＣ）リポジトリ６１４を管理する、（ｉｉｉ）複数のＪａｖａアプリケーションコンテナをそれぞれ対応する複数のＣＳＯクライアントエージェント６１２と関連付ける、もしくは（ｉｖ）ＣＳＯクライアントエージェント６１２からの更新を処理して、各Ｊａｖａアプリケーションイメージのためにより高品質のＳＣＣを生成する、またはその組み合わせを行う。
【0078】
（ＣＳＯクライアントエージェント）
【0079】
ＣＳＯクライアントエージェント６１２は、各ワーカノード上で実行されると共に、そこで実行されているアプリケーションにサービスを提供するバックグラウンドプロセスである。ＣＳＯクライアントエージェント６１２の機能は、以下のものを含む：（ｉ）Ｊａｖａ仮想マシン（ＪＶＭ）の状態を監視する。ここで、状態は「アクティブ」、「アイドル」、または「終了（exiting）」を含む、（ｉｉ）アプリケーション状態が「アイドル」または「終了」のいずれかである場合にＣＳＯ中央サーバエージェント６０４に更新を送信する、もしくは、（ｉｉｉ）ワーカノード上の共有クラスキャッシュ（ＳＣＣ）を維持するローカルＳＣＣリポジトリ６１６を管理する、またはその両方を行う。
【0080】
中央サーバオーケストレータ（ＣＳＯ）は、ＣＳＯ中央サーバエージェント６０４およびＣＳＯクライアントエージェント６１２と共に実装される、以下を含む３つのメカニズムを有する：（ｉ）ＳＣＣセットアップメカニズム６０８、（ｉｉ）ＳＣＣ更新メカニズム６１０、もしくは（ｉｉｉ）ＳＣＣ統合メカニズム６０６、またはその組み合わせ。
【0081】
＜ＳＣＣセットアップメカニズム＞
【0082】
ＳＣＣセットアップメカニズム６０８は、以下の動作の少なくともいくつかを実行することによって、新たに起動したＪａｖａアプリケーションインスタンスのために適切なベースＳＣＣをセットアップする：（ｉ）新たなＪａｖａアプリケーションインスタンスに関する情報を受信する、（ｉｉ）ベースＳＣＣをＣＳＯクライアントエージェント６１２に送信する、もしくは（ｉｉｉ）ベースＳＣＣをローカルＳＣＣリポジトリ６１６に格納する、またはその組み合わせを行う。これらの動作について、以下の数段落にてさらに説明する。
【0083】
（新たなＪａｖａアプリケーションインスタンスに関する情報の受信）
【0084】
ＣＳＯ中央サーバエージェント６０４は、既存のコンテナオーケストレーションシステム（コンテナオーケストレータ６０２）から、これから起動されるＪａｖａアプリケーションインスタンスに関連する情報を受信し、適切なベースＳＣＣの発見を試みる。なお、関連するコンテナは、イメージ構築時（image build time）に供給されたＳＣＣを既に含んでいてもよい。コンテナオーケストレータ６０２から受信した情報は、以下を含む：（ｉ）適切なベースＳＣＣを識別するために使用されるイメージ識別子（イメージＩＤ）、（ｉｉ）適切なベースＳＣＣを識別するために使用される、Ｊａｖａアプリケーションインスタンスに渡される引数、もしくは（ｉｉ）関連するＣＳＯクライアントエージェント６１２を発見するために使用される、Ｊａｖａアプリケーションインスタンスを実行するノード、またはその組み合わせ。中央ＳＣＣリポジトリ６１４内のすべてのベースＳＣＣは、イメージＩＤおよびＪａｖａアプリケーションインスタンスに渡された引数によってキーされる（keyed）。その結果、同じイメージＩＤおよび同じ引数を持つ複数のＪａｖａアプリケーションインスタンスは、同じベースＳＣＣを共有する。
【0085】
（ＣＳＯクライアントエージェントへのベースＳＣＣの送信）
【0086】
ＣＳＯ中央サーバエージェント６０４は、ノード情報に少なくとも部分的に基づいて、適切なベースＳＣＣを特定する。ＣＳＯ中央サーバエージェント６０４は、ベースＳＣＣを対応するＣＳＯクライアントエージェント６１２に送信する。ＣＳＯ中央サーバエージェント６０４は、アプリケーションが必要とするベースＳＣＣを、関連するＣＳＯクライアントエージェント６１２を介して送信する。各アプリケーションは、同じノード上にあるため、ＣＳＯクライアントと関連付けられている。
【0087】
（ベースＳＣＣのローカル格納）
【0088】
ＣＳＯクライアントエージェント６１２は、ベースＳＣＣをローカルＳＣＣリポジトリ６１６に格納する。ローカルＳＣＣリポジトリ６１６において、ベースＳＣＣは新たなＪａｖａアプリケーションインスタンスによって使用できるようになる。
【0089】
＜ＳＣＣ更新メカニズム＞
【0090】
ＳＣＣ更新メカニズム６１０は、以下の動作の少なくともいくつかを実行することによって、ＳＣＣ更新を管理する：（ｉ）元のＳＣＣを更新する、（ｉｉ）実行中アプリケーションをＣＳＯクライアント（ＣＳＯクライアントエージェント６１２を参照）と関連付ける、（ｉｉｉ）ＳＣＣを増大させる（grow）、もしくは（ｉｖ）ＳＣＣ更新要求をＣＳＯ中央サーバエージェント６０４に送信する、またはその組み合わせ。ＣＳＯ中央サーバエージェント６０４は、複数の理由によって要求を拒否する可能性もある。上述の動作、ならびに要求を拒否する潜在的な理由およびそれに対する関連応答について、以下の数段落にて説明する。
【0091】
（元のＳＣＣの更新）
【0092】
更新とは本質的に、新たなＪａｖａアプリケーションインスタンスのスタートアップ時にアプリケーションのＪａｖａ仮想マシン（ＪＶＭ）に対して利用可能にされる元の（ベース）ＳＣＣと、ＪＶＭがその後に生成する新たな追加ＳＣＣとの差（ｄｉｆｆ）である。
【0093】
（実行中アプリケーションとＣＳＯクライアントとの関連付け）
【0094】
いくつかの実施形態では、クラウド内のすべての実行中アプリケーションをＣＳＯクライアント（ＣＳＯクライアントエージェント６１２を参照）に関連付ける。その結果、各ワーカノードに対して１つのＣＳＯクライアントエージェント６１２が存在する。ＣＳＯクライアントエージェント６１２は、各アプリケーションの更新（クラスキャッシュ）を計算し、アプリケーションが「アイドル」状態にあるとき、または実行が終了したとき（「終了」状態にあるとき）に、更新をＣＳＯ中央サーバエージェント６０４に送信する。アプリケーションが「アイドル」状態または「終了」状態のいずれかになるのを待つことにより、ＣＳＯクライアントエージェント６１２は、ネットワークトラフィックの最適化に寄与する。これは、更新がネットワーク帯域幅についてアプリケーションと競合しなくなるためである。更新が行われる時間は、アプリケーションもしくはアプリケーションのワークロードまたはその両方に応じて異なる。ＣＳＯクライアントは、ＪＶＭアイドル検出メカニズムを利用して、アプリケーションの更新をＣＳＯ中央サーバ（ＣＳＯ中央サーバエージェント６０４を参照）に送信するスケジュールを立てる。
【0095】
（ＳＣＣの増大）
【0096】
共有クラスキャッシュ（ＳＣＣ）は、両端から中央に向かって増大し、クラスデータはＳＣＣの一端に追加され、ＪＩＴデータは他端に追加される。ＳＣＣに関しては、元のＳＣＣのための２つの「ベースポインタ」と、ＪＶＭによって新たに追加されたＳＣＣのための２つの「カレントポインタ」とが存在する。ＳＣＣの更新は、ベースポインタとカレントポインタとの間のコンテンツを含む。ＣＳＯクライアントエージェント６１２は、ベースポインタを追跡し、各ＪａｖａアプリケーションインスタンスについてＳＣＣ更新を生成する。
【0097】
（ＣＳＯ中央サーバへのＳＣＣ更新要求の送信）
【0098】
ＳＣＣ更新要求を送信する前に、（特定のノードに関連する）ＣＳＯクライアントエージェント６１２は、ＳＣＣ更新がさらなる処理のために受け入れられるかどうかを確認するために、ＣＳＯ中央サーバエージェント６０４に要求を送信する。ＣＳＯ中央サーバエージェント６０４が要求を拒否した場合、ＣＳＯ中央サーバエージェント６０４はその要求を破棄する。その後、特定のノード上のアプリケーションの次のインスタンスは、ＣＳＯ中央サーバエージェント６０４によって提供される新たなＳＣＣを使用する。ＳＣＣ更新要求は、以下の情報を含む：（ｉ）アプリケーションイメージＩＤ（アプリケーションタイプの識別用）、（ｉｉ）コンテナに渡される引数（アプリケーションタイプの識別用）、（ｉｉｉ）ハードウェア情報（アプリケーションタイプの識別用）、（ｉｖ）ノード情報（更新要求の送信元ＣＳＯクライアントの識別用）、（ｖ）ＳＣＣメタデータ（例えば、ベースＳＣＣバージョン、サイズなど）、もしくは（ｖｉ）実行動作データ（例えば、アプリケーションが正しい／期待される／一般的な方法で終了したか）、またはその組み合わせ。
【0099】
いくつかの実施形態では、「アプリケーションタイプ」、「マネージドランタイムアプリケーションタイプ」、および同様の用語は、Ｄｏｃｋｅｒイメージ識別子（アプリケーションイメージＩＤ）を指す。例えば、証券取引所のウェブアプリケーションを考える。ウェブアプリケーションをクラウドで起動し稼働させるために、いくつかの実施形態において、ウェブアプリケーションはＤｏｃｋｅｒイメージにパッケージ化される。ウェブアプリケーションのＤｏｃｋｅｒイメージＩＤは、「アプリケーションイメージＩＤ」である。本発明の実施形態における、クラスデータ共有に関連するメカニズムもしくは特徴またはその両方は、同じタイプのアプリケーションに適用される。同じアプリケーションのインスタンスは、互いにデータを共有することができる。上述のＤｏｃｋｅｒの例に関して、証券取引所ウェブアプリケーションに関連するＤｏｃｋｅｒイメージは、クラウド内の異なるマシン（これらは、様々な物理的場所に位置する、様々な物理的マシンを使用して証券取引サービスを提供してもよい）上で展開された多くの異なるインスタンス（Ｄｏｃｋｅｒコンテナ）を有することができる。すべてのインスタンスは同じＤｏｃｋｅｒイメージＩＤを有し、その結果、同じタイプであるとみなされ、互いにデータを共有することができる。次に、別のアプリケーション、例えばビデオストリーミングウェブアプリケーションを考える。ビデオストリーミングウェブアプリケーションと証券取引所ウェブアプリケーションとは、異なるＤｏｃｋｅｒイメージＩＤを有するため、同じタイプではない。ビデオストリーミングアプリケーションの各インスタンスは同じＤｏｃｋｅｒイメージＩＤを有し、その結果、互いにデータを共有することができる。しかし、ビデオストリーミングアプリケーションのインスタンスは、証券取引アプリケーションのインスタンスとデータを共有することはできない。
【0100】
なお、「Ｄｏｃｋｅｒ」という用語は、世界中の様々な法域における商標権の対象となる可能性があり、ここでは、このような商標権が存在し得る範囲で標章によって適正に称される製品またはサービスに対して言及する場合にのみ使用される。
【0101】
（要求を拒否する潜在的な理由および関連応答）
【0102】
ＣＳＯ中央サーバエージェント６０４は、以下の理由または要因のうちの少なくとも１つによって、要求を拒否する場合がある：（ｉ）ＣＳＯ中央サーバ上のアプリケーションタイプ用のＳＣＣが満杯（full）であり、新たな更新を受け付けない（この場合、ＣＳＯクライアントエージェント６１２は、対応するＪａｖａアプリケーションインスタンスに関する更新の計算および送信を停止する）、（ｉｉ）ＣＳＯ中央サーバエージェント６０４が、アプリケーションが正常に動作しなかった（たとえば、アプリケーションがエラーコード、まれなリターンコード、もしくは予想外のリターンコードまたはその組み合わせを返した）と判断し、これに応じて更新を無効とみなす、もしくは、（ｉｉｉ）ＣＳＯ中央サーバエージェント６０４がＳＣＣ更新を古い（outdated）と判断し、その結果、このような古いバージョンからの更新を受け入れなくなる、またはこれらの組み合わせ。ＣＳＯ中央サーバエージェント６０４が更新に関連するベースＳＣＣバージョンに比べて新しいベースＳＣＣバージョンを有する場合、ＳＣＣ更新は古いとみなされ、この場合、ＣＳＯクライアントエージェント６１２は、対応するＪａｖａアプリケーションインスタンスに関するＳＣＣ更新の計算および送信を停止する。
【0103】
＜ＳＣＣ統合メカニズム＞
【0104】
本発明のいくつかの実施形態に係るＳＣＣ統合は、ＣＳＯクライアント（たとえばＣＳＯクライアントエージェント６１２）によって提供されるＳＣＣ更新に少なくとも部分的に基づいて、より高品質のＳＣＣを生成する。ＣＳＯ中央サーバエージェント６０４は、最近受信したＳＣＣ更新の閾値数を（オフラインで）分析し、同じタイプの後続のすべてのＪａｖａアプリケーションインスタンスによって使用可能な新たなベースＳＣＣを構築する。各ＳＣＣは、アプリケーションタイプに対応する。あるアプリケーションのインスタンスがキャッシュを満たす（populate）が、当該アプリケーションのすべてのインスタンスが同じＳＣＣを共有する。
【0105】
ＣＳＯ中央サーバエージェント６０４は、新たなベースＳＣＣを以下のように構築する。
【0106】
ＣＳＯ中央サーバは、あるアプリケーションタイプの更新を受信するたびに、後の処理のためにその更新を格納する。
【0107】
ＣＳＯ中央サーバエージェント６０４は、閾値数の更新を受信すると、新たな更新の受信を停止し、格納された更新に基づいて新たなＳＣＣを作成する（閾値数は、ヒューリスティクスに基づき、例えばいくつかの実施形態では、ＣＳＯ中央サーバからの同じベースＳＣＣを現在使用しているすべてのアプリケーションインスタンスの８０％に設定される）。
【0108】
アプリケーションタイプに関連付けられたベースＳＣＣがＣＳＯ中央サーバに存在する場合、そのベースＳＣＣのすべてのコンテンツが新たなベースＳＣＣで使用される。
【0109】
複数のＳＣＣ更新間で共通する新たなデータが存在する場合、ＣＳＯ中央サーバエージェント６０４は、その新たなデータを新たなＳＣＣに追加する（例えば、更新の半分以上が同じメソッドのコンパイルを示す場合、ＣＳＯ中央サーバエージェント６０４はそのメソッドを「重要」とみなし、そのメソッドを新たなベースＳＣＣに含める）。
【0110】
ＣＳＯ中央サーバエージェント６０４が新たなベースＳＣＣを生成すると、ＣＳＯ中央サーバエージェント６０４は、古いＳＣＣを使用して起動したデプロイメントから受信したすべての更新要求を拒否し、その後は、新たなベースＳＣＣを使用して起動したデプロイメントから受信した更新のみを受け付ける。
【0111】
本発明のいくつかの実施形態は、以下の特徴、特性、もしくは利点またはその組み合わせの１つ以上を含むことができる：（ｉ）共有クラスキャッシュ（ＳＣＣ）は、静的（読み取り専用）ではなく、動的（読み取り／書き込み）であってもよい、（ｉｉ）プロファイリングデータ、および他のジャストインタイム（ＪＩＴ）コンパイラヒントは、実行ごとに異なってもよい、（ｉｉｉ）プロファイリングデータを経時的に蓄積して、アプリケーションの状態をより良く把握することができる、もしくは、（ｉｖ）ＳＣＣ内の動的データによって、開発者は、様々なアプリケーションの状態についてオフライン分析を実行し、各アプリケーションに対して最適かつよりコンパクトになるようにＳＣＣを動的に修正することができる、またはこれらの組み合わせ。
【0112】
本発明のいくつかの実施形態は、現在の技術水準に関して、以下の事実、潜在的な問題、もしくは潜在的な改善領域またはその組み合わせのうちの１つ以上を認識することができる。（ｉ）ＳＣＣはメモリマップファイルである、（ｉｉ）ＳＣＣ内のクラスデータは、クラスの不変部分を含む、（ｉｉｉ）ジャストインタイム（ＪＩＴ）コンパイルデータは事前（ＡＯＴ）コンパイルコードおよびプロファイリングデータを含む場合がある、（ｉｖ）共有クラスキャッシュを満たすために「ウォームアップ実行」が必要な場合がある、（ｖ）その後の実行は、スタートアップ時間およびメモリ使用量が改善する場合がある、もしくは（ｖｉ）同一のノード上に存在する必要がある場合がある、またはこれらの組み合わせ。
【0113】
図７のブロック図７００は、本発明のいくつかの実施形態に係る、共有クラスキャッシュをセットアップ、更新、および統合するためのプロセスを示す。ブロック図７００は、以下を含む：ＣＳＯ中央サーバエージェント６０４、第１のＣＳＯクライアントエージェント６１２－１、第２のＣＳＯクライアントエージェント６１２－２、中央ＳＣＣリポジトリ６１４（ＳＣＣ５、ＳＣＣ６、・・・ＳＣＣｋを含む）、第１のローカルＳＣＣリポジトリ６１６－１（ＳＣＣ１、ＳＣＣ２、・・・ＳＣＣｎを含む）、第２のローカルＳＣＣレポジトリ６１６－２（ＳＣＣ３、ＳＣＣ４、・・・ＳＣＣｍを含む）、ＪＶＭ１７０１、ＪＶＭ２７０２、ＪＶＭ３７０３、ＪＶＭ４７０４、第１のノード７２１、第２のノード７２２、第３のノード７２３、もしくは保留差分（pending diffs）７２４、またはこれらの組み合わせ。
【0114】
以下の動作１～１１は、それぞれ、図７における同番号の矢印に対応する。本発明のいくつかの実施形態に係る（そして図６を参照して上述した）３つのプロセスは、ＳＣＣセットアップ（動作１～７）、ＳＣＣ更新（動作８～１０）、およびＳＣＣ統合（動作１１）からなる。
【0115】
（ＳＣＣセットアップ）
【0116】
１．キャッシュ共有オーケストレータ（第１のＣＳＯクライアントエージェント６１２－１）は、第１のローカル共有クラスキャッシュリポジトリ（第１のローカルＳＣＣリポジトリ６１６－１）から、起動するコンテナイメージ、および関連パラメータに関する情報を受信する。第１のＣＳＯクライアントエージェント６１２－１は、適切なＳＣＣをローカルリポジトリ６１６－１から検索する。
【0117】
２．第１のＣＳＯクライアントエージェント６１２－１は、適切なＳＣＣを発見した場合、そのＳＣＣをＪａｖａ仮想マシンコンテナ（例えば、ＪＶＭ１７０１）にマウントする。
【0118】
３．第１のＣＳＯクライアントエージェント６１２－１は、ローカルの第１のローカルＳＣＣリポジトリ６１６－１内で適切なＳＣＣを発見しなかった場合、ＣＳＯ中央サーバエージェント６０４に、適切なＳＣＣを特定する要求を送信する。
【0119】
４．ＣＳＯ中央サーバエージェント６０４は、中央ＳＣＣリポジトリ６１４（グローバルＳＣＣリポジトリ）を検索して、適切なＳＣＣを発見および取得する。
【0120】
５．ＣＳＯ中央サーバエージェント６０４は、適切なＳＣＣを第１のＣＳＯクライアントエージェント６１２－１に返す。
【0121】
６．第１のＣＳＯクライアントエージェント６１２－１は、ローカルリポジトリに適切なＳＣＣをインストールする。
【0122】
７．また、第１のＣＳＯクライアントエージェント６１２－１は、適切なＳＣＣをＪＶＭ１７０１にマウントする。
【0123】
（ＳＣＣ更新）
【0124】
８．第２のＣＳＯクライアントエージェント６１２－２は、関連するＪＶＭ（ＪＶＭ３７０３、ＪＶＭ４７０４）のステータスを照会する。第２のＣＳＯクライアントエージェント６１２－２はさらに、第２のローカルＳＣＣリポジトリ６１６－２に保持されるＳＣＣのステータスを照会して、ＪＶＭ３７０３もしくはＪＶＭ４７０４またはその両方が、第２のローカルＳＣＣリポジトリ６１６－２の対応するＳＣＣに存在しない新たなコンテンツを有しているかどうかを決定する。閾値数の新たなコンテンツがＪＶＭ３７０３もしくはＪＶＭ４７０４またはその両方に存在する場合、第２のＣＳＯクライアントエージェント６１２－２は、第２のローカルＳＣＣリポジトリ６１６－２にキャッシュされたコンテンツに照らして、ＪＶＭ３７０３もしくはＪＶＭ４７０４またはその両方に関連付けられた新たなコンテンツに基づく差（「差分（diff）」）を計算する。
【0125】
９．第２のＣＳＯクライアントエージェント６１２－２は、差分を含む更新要求をＣＳＯ中央サーバエージェント６０４に送信する。いくつかの実施形態において、第２のＣＳＯクライアントエージェント６１２－２は最初に、ＣＳＯ中央サーバエージェント６０４が更新要求を受け入れるかどうかを確認するために「プローブメッセージ（probe message）」を送信する。
【0126】
１０．更新要求を受け入れたことに応じて、ＣＳＯ中央サーバエージェント６０４は、差分を保留差分７２４に格納する。
【0127】
（ＳＣＣ統合）
【0128】
１１．保留差分７２４に閾値数の新たな更新要求が蓄積されたことに応じて、ＣＳＯサーバは、更新要求（それぞれ対応する保留差分を含む）を分析し、中央ＳＣＣリポジトリ６１４（グローバルリポジトリ）に伝播するための情報を選択する。中央ＳＣＣリポジトリ６１４は、更新される共有クラスキャッシュ（ＳＣＣ５、ＳＣＣ６、・・・ＳＣＣｋ）のベースバージョンをインクリメントする。ＣＳＯ中央サーバエージェント６０４は、より低いバージョンを対象とする更新を拒否する。
【0129】
本発明のいくつかの実施形態は、以下の特徴、特性、もしくは利点またはその組み合わせのうちの１つ以上を含んでもよい：（ｉ）動的なクラスデータを共有する、（ｉｉ）クラウド環境におけるクラスデータの品質を継続的に改善する、（ｉｉｉ）キャッシュ更新システムが、すべてのノードにソフトウェアエージェントをデプロイすると共にクラウド環境で実行中の各アプリケーションの共有クラスキャッシュベーススナップショットを追跡することによって、共有クラスキャッシュ更新を効率的に生成する、（ｉｖ）キャッシュ統合システムが、ソフトウェアエージェントからクラスキャッシュ更新を効率的に収集すると共に従来のソリューションに対する改善を保証するルールセットを使用して更新を効率的に統合することによって、キャッシュの質を継続的に改善する、（ｖ）キャッシュオーケストレーションシステムが、クラウド環境におけるすべての実行中アプリケーションからのキャッシュデータを管理する、（ｖｉ）キャッシュ更新および統合システムが、経時的にキャッシュ結果を継続的に改善する、（ｖｉｉ）クラウド環境における動的共有クラスデータの適用性を改善する、（ｖｉｉｉ）クラス共有オーケストレータを提供する、（ｉｘ）クラウド全体のクラスデータおよび／もしくはクラスタ全体のクラスデータを共有する、もしくは、（ｘ）コンテナ化環境においてクラス共有オーケストレータによるマネージドランタイムアプリケーションの起動を開始する、またはこれらの組み合わせ。
【0130】
本発明のいくつかの実施形態は、キャッシュされたクラスデータを共有するための、コンピュータ実装方法、当該方法を実行するためのコンピュータプログラム製品、もしくは当該方法を実行するためのコンピュータシステム、またはその組み合わせを含む。方法は、（ｉ）コンテナ化環境において、コンテナオーケストレータがマネージドランタイムアプリケーションの起動を開始したことに応じて、クラス共有オーケストレータ中央サーバによって、イメージＩＤ、マネージドランタイムアプリケーションのインスタンスに渡される引数、およびインスタンスを実行するワーカノードの識別子を含む情報をコンテナオーケストレータから受信することと、（ｉｉ）クラス共有オーケストレータ中央サーバが、イメージＩＤおよびマネージドランタイムアプリケーションインスタンスに渡された引数のリストを含む検索基準に基づいて、中央共有クラスキャッシュリポジトリ内で適切なベース共有クラスキャッシュを特定したことに応じて、クラス共有オーケストレータ中央サーバによって、適切なベース共有クラスキャッシュを、ワーカノードの情報を使用して識別された対応するクラス共有オーケストレータクライアントに送信することと、（ｉｉｉ）クラス共有オーケストレータ中央サーバから適切なベース共有クラスキャッシュを受信したことに応じて、対応するクラス共有オーケストレータクライアントによって、適切なベース共有クラスキャッシュを、マネージドランタイムアプリケーションのインスタンスによる使用のためにローカルの共有クラスキャッシュリポジトリに格納することと、（ｉｖ）クラス共有オーケストレータ中央サーバが、対応するクラス共有オーケストレータクライアントから、イメージＩＤ、渡された引数、ハードウェア情報、ノード情報、クラス共有オーケストレータクライアントが受信したベースＳＣＣに関する追加の共有クラスデータを含む更新を処理する要求を受信したことに応じて、クラス共有オーケストレータ中央サーバによって、更新を受け入れるかどうかを判断することと、（ｖ）クラス共有オーケストレータ中央サーバが、更新を処理する要求を拒否したことに応じて、クラス共有オーケストレータ中央サーバによって、更新を破棄することと、（ｖｉ）クラス共有オーケストレータ中央サーバによって、新たな共有クラスキャッシュを対応するクラス共有オーケストレータクライアントに送信することと、（ｖｉｉ）クラス共有オーケストレータ中央サーバが、更新を処理する要求を受け入れたことに応じて、マネージドランタイムアプリケーションの特定のタイプについて、クラス共有オーケストレータ中央サーバによる後のオフライン処理のために更新を格納することと、（ｖｉｉｉ）クラス共有オーケストレータ中央サーバが受信した、設定可能な数の最近の更新を分析して分析データを作成することと、（ｉｘ）クラス共有オーケストレータ中央サーバが、分析データを用いて、特定のタイプについてクラス共有オーケストレータ中央サーバ上に古いベース共有クラスキャッシュが存在すると判断したことに応じて、古いベース共有クラスキャッシュのすべてのコンテンツを使用して新たなベース共有クラスキャッシュを生成することと、（ｘ）クラス共有オーケストレータ中央サーバが、１つ以上の更新の間で共通する新たなデータが存在すると判断したことに応じて、クラス共有オーケストレータ中央サーバによって、新たなデータを新たなベース共有クラスキャッシュに追加することと、（ｘｉ）新たなベース共有クラスキャッシュが生成されたことに応じて、クラス共有オーケストレータ中央サーバによって、古い共有クラスキャッシュを使用して起動されたデプロイメントからの更新要求を拒否することと、を含む。
【0131】
例示的な実施形態において、３つのノード（ノード－１、ノード－２、ノード－３）がそれぞれ、アプリケーションの３つのインスタンス（ａｐｐ－１、ａｐｐ－２、ａｐｐ－３、すべて所与のアプリケーションタイプ）、３つのローカルキャッシュ共有オーケストレータ（ＣＳＯ）クライアント（ＣＳＯ－１、ＣＳＯ－２、ＣＳＯ－３）、および３つのローカルキャッシュリポジトリ（キャッシュ－１、キャッシュ－２、キャッシュ－３）をホストする場合を考える。第４のノード（ノード－４）は、ＣＳＯ中央サーバと、当該所与のアプリケーションタイプのアプリケーションに固有のベース共有クラスキャッシュ（ＳＣＣ）を有する中央キャッシュリポジトリとをホストする。
【0132】
ＣＳＯ中央サーバは、ＣＳＯ－１、ＣＳＯ－２、ＣＳＯ－３と通信して、ａｐｐ－１、ａｐｐ－２、ａｐｐ－３が実行中に生成したローカルキャッシュ更新を受信する。ＣＳＯ中央サーバは、受信したローカルキャッシュ更新に基づき、中央キャッシュリポジトリ内の所与のアプリケーションタイプに対応するベースＳＣＣを更新する。
【0133】
ａｐｐ－１の実行中、ＣＳＯ－１は関連するキャッシュデータを収集し、ローカルキャッシュリポジトリ（キャッシュ－１）に格納する。ここで、ＣＳＯ－１が最終的に更新要求を生成し、その要求をＣＳＯ中央サーバに送信することを考える。ＣＳＯ中央サーバは、中央キャッシュリポジトリから適切なベースＳＣＣを検索する。ＣＳＯ中央サーバは、ベースＳＣＣを特定すると、（ａｐｐ－１に対してローカルの）キャッシュ－１が古くなったと判断する。これに応じて、ＣＳＯ中央サーバは、ＣＳＯ－１からの更新要求を拒否し、中央キャッシュリポジトリから、ノード－１上のＣＳＯ－１にベースＳＣＣを送信する。ａｐｐ－２およびａｐｐ－３についても同じプロセスが行われ、ＣＳＯ－２およびＣＳＯ－３はそれぞれ、関連するキャッシュデータを収集し、それぞれのローカルキャッシュに格納し、ＣＳＯ中央サーバに更新要求を送信し、ＣＳＯ中央サーバによってそれぞれのローカルキャッシュが古いと判断された場合に、更新済みのベースＳＣＣを受信してそれぞれのローカルキャッシュを更新する。
【0134】
下記の特許請求の範囲におけるすべてのミーンズプラスファンクション要素またはステッププラスファンクション要素の対応する構造、材料、動作、および均等物は、具体的に特許請求されるように、他の特許請求される要素と組み合わせて機能を実行するためのあらゆる構造、材料、または動作を含むことを意図している。本開示を例示および説明のために提示してきたが、網羅的であることや、開示した形態に本開示を限定することを意図したものではない。本開示の範囲および要旨から逸脱することなく、多くの変更および変形が当業者には明らかである。本実施形態は、本開示の原理および実際の応用例を最もよく説明するために、かつ他の当業者が、企図している特定の用途に適した各種の変更を伴う各種の実施形態について本開示を理解できるように選択され記載されたものである。
【0135】
ＩＶ．定義
本発明：「本発明」という用語によって記載される主題が、出願時の特許請求の範囲または特許審査手続き後に最終的に発行される特許請求の範囲のいずれかの範囲に含まれることの絶対的な指標として解釈すべきものではない。「本発明」という用語は、読者が、本明細書において潜在的に新規であると考えられる開示についての一般的な心証を得ることを助けるために使用されるものであるが、この理解は、「本発明（現在の発明）（present invention）」という用語の使用によって示されるように、仮の、暫定的なものであり、特許審査の過程で、関連情報が現れたとき、および場合によって請求項が補正されたときに、変更される可能性がある。
本発明：「本発明」という用語によって記載される主題が、出願時の特許請求の範囲または特許審査手続き後に最終的に発行される特許請求の範囲のいずれかの範囲に含まれることの絶対的な指標として解釈すべきものではない。「本発明」という用語は、読者が、本明細書において潜在的に新規であると考えられる開示についての一般的な心証を得ることを助けるために使用されるものであるが、この理解は、「本発明（現在の発明）（present invention）」という用語の使用によって示されるように、仮の、暫定的なものであり、特許審査の過程で、関連情報が現れたとき、および場合によって請求項が補正されたときに、変更される可能性がある。
【0136】
実施形態：上記「本発明」の定義を参照。同様の注記が用語「実施形態」にも当てはまる。
【0137】
および／または：包含的論理和（inclusive）、例えば、Ａ、Ｂ「および／または」Ｃは、ＡまたはＢまたはＣのうちの少なくとも１つが真であり該当することを意味する。
【0138】
含む：別段の明示的な記載がない限り、「含むが必ずしもこれ（これらに）限定されない」を意味する。
【0139】
ユーザ／加入者（subscriber）：（ｉ）１人の人間、（ｉｉ）ユーザまたは加入者として機能するための十分な知性を有する人工知能エンティティ、もしくは（ｉｉｉ）関連するユーザまたは加入者のグループ、またはその組み合わせを含むが、必ずしもこれらに限定されない。
【0140】
電気的に接続される：直接的に電気的に接続されるか、または介在要素が存在するように間接的に電気的に接続されるかのいずれかを意味する。電気的接続には、コンデンサ、インダクタ、トランス、真空管などの素子が含まれるが、必ずしもこれらに限定されない。
【0141】
データ通信：無線通信、有線通信、ならびに、無線および有線部分を含む通信経路を含む、現在既知の、または、将来開発される任意の種類のデータ通信方式であり、データ通信は、（ｉ）直接データ通信、（ｉｉ）間接データ通信、もしくは（ｉｉｉ）フォーマット、パケット化ステータス、媒体、暗号化ステータス、および／もしくはプロトコルがデータ通信の全体の過程において一定のままであるデータ通信、またはその組み合わせに必ずしも限定されない。
【0142】
受信する／提供する／送信する／入力する／出力する：別段の明示的な規定がない限り、これらの単語は、（ｉ）これらの主体および客体間の関係に関する具体的な直接性（directness）の程度、もしくは（ｉｉ）これらの主体および客体間に挿入される中間コンポーネント、動作および／もしく物が存在しないこと、またはその両方を意味すると解釈すべきではない。
【0143】
実質的に人間が介入しない：人間による入力がほとんど、または全く存在せずに（多くの場合、ソフトウェアなどの機械論理の動作によって）自動的に発生するプロセスを意味する。「実質的に人間が介入しない」ことを含む例としては、（ｉ）コンピュータが複雑な処理を実行しており、電力系統の停止に起因して処理の継続が中断されないように、人間がコンピュータを代替電源に切り替えること、（ｉｉ）コンピュータが、リソース消費型（resource-intensive）の処理を実行しようとしており、人間が、リソース消費型の処理が本当に実行されるべきであるかどうかを確認すること（この場合、確認のプロセスは、それ単独で考えた場合、実質的な人間の介入を伴うが、リソース消費型の処理は（人間によって行われる必要のある単純な「はい／いいえ」形式の確認はあるが）どのような実質的な人間の介入も含まない）、および（ｉｉｉ）コンピュータが、機械論理を使用して重要な決定（例えば、悪天候を予想して、すべての飛行機を飛行禁止にすることの決定）を行うが、この重要な決定を実施する前に、コンピュータが、単純な「はい／いいえ」形式の確認を人間側から得なければならないこと、が挙げられる。
【0144】
自動的に：人間による介入がないことを意味する。
【0145】
モジュール／サブモジュール：ある種類の機能を行うように動作可能に働くハードウェア、ファームウェアもしくはソフトウェアまたはその組み合わせの任意のセットであって、当該モジュールは、（ｉ）単一の局所的近傍（single local proximity）にある、（ｉｉ）広域に分散している、（ｉｉｉ）ソフトウェアコードのより大きな部分内の単一の近傍にある、（ｉｖ）ソフトウェアコードの単一部分内に位置する、（ｖ）単一のストレージデバイス、メモリまたは媒体内に位置する、（ｖｉ）機械的に接続されている、（ｖｉｉ）電気的に接続されている、もしくは（ｖｉｉｉ）データ通信接続されている、またはその組み合わせのいずれかを問わない。
【0146】
コンピュータ：顕著なデータ処理能力もしくは機械可読命令読み取り能力またはその両方を有する任意のデバイスであって、デスクトップコンピュータ、メインフレームコンピュータ、ラップトップコンピュータ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）ベースのデバイス、スマートフォン、携帯情報端末（ＰＤＡ）、身体装着式もしくは挿入式コンピュータ、埋込みデバイス型コンピュータ、もしくは特定用途向け集積回路（ＡＳＩＣ）ベースのデバイスまたはその組み合わせを含む（ただし、これらに限定されない）。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】