特許 7192645 情報処理装置、分散処理システム及び分散処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-12-12

(45)【発行日】2022-12-20

(54)【発明の名称】情報処理装置、分散処理システム及び分散処理プログラム

(51)【国際特許分類】

   H04L 67/00 20220101AFI20221213BHJP

   G06F 16/172 20190101ALI20221213BHJP

【ＦＩ】

H04L67/00

G06F16/172

【請求項の数】 6

(21)【出願番号】P 2019085417

(22)【出願日】2019-04-26

(65)【公開番号】P2020181474

(43)【公開日】2020-11-05

【審査請求日】2022-01-11

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100087480

【弁理士】

【氏名又は名称】片山 修平

(72)【発明者】

【氏名】雨宮 宏一郎

【審査官】木村 雅也

(56)【参考文献】

【文献】特開２００５－０３１９８７（ＪＰ，Ａ）

【文献】国際公開第２０１２／１４４５８４（ＷＯ，Ａ１）

【文献】特開２０１５－１７６３５０（ＪＰ，Ａ）

【文献】特開２０１５－１６２６８６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ６７／００

Ｇ０６Ｆ １６／１７２

(57)【特許請求の範囲】

【請求項1】

過去におけるデータへのアクセス履歴に基づいて、記憶部に一時的に記憶するデータの候補を特定する記憶候補特定部と、
第１の時間間隔で他の情報処理装置から負荷情報を取得する第１取得部と、
前記第１取得部が取得した前記他の情報処理装置の負荷情報と自装置の負荷情報とに基づいて、前記記憶部に一時的に記憶されているデータの中から、特定した前記記憶するデータの候補の代わりに前記記憶部から削除するデータの候補を特定する削除候補特定部と、
前記第１の時間間隔よりも短い第２の時間間隔で、前記記憶するデータの候補を保持する情報処理装置と、前記削除するデータの候補を保持する情報処理装置とから負荷情報を取得する第２取得部と、
前記記憶するデータの候補へのアクセスがあった場合に、前記第２取得部が取得した負荷情報と自装置の負荷情報とに基づいて、前記アクセスがあったデータを前記記憶部に一時的に記憶するか否か、及び前記アクセスがあったデータを前記記憶部に一時的に記憶する場合に前記削除するデータの候補のいずれを削除するかを決定する決定部と、
を備える情報処理装置。

【請求項2】

前記削除候補特定部は、前記第１の時間間隔で前記他の情報処理装置から取得した負荷情報と、自装置の負荷情報とに基づいて、自装置の負荷情報と前記他の情報処理装置の負荷情報の相関関係を算出し、算出した前記相関関係と自装置の負荷情報とから推定される前記他の情報処理装置の負荷情報を用いて、前記削除するデータの候補を特定する、ことを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記削除候補特定部は、
前記記憶するデータの候補を前記記憶部に記憶しないときよりも、前記記憶するデータの候補を前記記憶部に記憶し、前記記憶部に記憶されていたデータを削除したときの方が、前記記憶するデータの候補を処理する際のスループットが高い場合に、前記記憶部に記憶されていたデータを前記削除するデータの候補として特定する、請求項１又は２に記載の情報処理装置。

【請求項4】

前記決定部が前記アクセスがあったデータを前記記憶部に一時的に記憶しないと決定した場合に、各情報処理装置の負荷情報と、前記アクセスがあったデータをいずれの情報処理装置が保持しているか、に基づいて、前記アクセスがあったデータの処理を実行する情報処理装置を選定する選定部、を更に備える請求項１～３のいずれか一項に記載の情報処理装置。

【請求項5】

ネットワークに接続された複数の情報処理装置を有する分散処理システムであって、
前記情報処理装置は、
過去におけるデータへのアクセス履歴に基づいて、記憶部に一時的に記憶するデータの候補を特定する記憶候補特定部と、
第１の時間間隔で他の情報処理装置から負荷情報を取得する第１取得部と、
前記第１取得部が取得した前記他の情報処理装置の負荷情報と自装置の負荷情報とに基づいて、前記記憶部に一時的に記憶されているデータの中から、特定した前記記憶するデータの候補の代わりに前記記憶部から削除するデータの候補を特定する削除候補特定部と、
前記第１の時間間隔よりも短い第２の時間間隔で、前記記憶するデータの候補を保持する情報処理装置と、前記削除するデータの候補を保持する情報処理装置とから負荷情報を取得する第２取得部と、
前記記憶するデータの候補へのアクセスがあった場合に、前記第２取得部が取得した負荷情報と自装置の負荷情報とに基づいて、前記アクセスがあったデータを前記記憶部に一時的に記憶するか否か、及び前記アクセスがあったデータを前記記憶部に一時的に記憶する場合に前記削除するデータの候補のいずれを削除するかを決定する決定部と、
を備えることを特徴とする分散処理システム。

【請求項6】

ネットワークに接続された複数の情報処理装置のコンピュータに、
過去におけるデータへのアクセス履歴に基づいて、記憶部に一時的に記憶するデータの候補を特定し、
第１の時間間隔で他の情報処理装置から負荷情報を取得し、取得した前記他の情報処理装置の負荷情報と自装置の負荷情報とに基づいて、前記記憶部に一時的に記憶されているデータの中から、特定した前記記憶するデータの候補の代わりに前記記憶部から削除するデータの候補を特定し、
前記第１の時間間隔よりも短い第２の時間間隔で、前記記憶するデータの候補を保持する情報処理装置と、前記削除するデータの候補を保持する情報処理装置とから負荷情報を取得し、
前記記憶するデータの候補へのアクセスがあった場合に、前記第２の時間間隔で取得した負荷情報と自装置の負荷情報とに基づいて、前記アクセスがあったデータを前記記憶部に一時的に記憶するか否か、及び前記アクセスがあったデータを前記記憶部に一時的に記憶する場合に前記削除するデータの候補のいずれを削除するかを決定する、
処理を実行させる分散処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、分散処理システム及び分散処理プログラムに関する。

【背景技術】

【0002】

従来、複数のエッジサーバに分散して蓄積された人やモノの動的情報をユーザからの要求に応じて処理し、ユーザに提供する分散処理システムが知られている。このようなシステムは、タクシー需給予測サービスや、リアルタイムでタクシーを検索したり、配車するサービスなどに利用されている。

【先行技術文献】

【特許文献】

【0003】

【文献】国際公開第２０１５／０７５９６２号

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記のような分散処理システムにおいては、処理に必要なデータの位置や、各エッジサーバの負荷情報に応じて、処理をどのエッジサーバで実行すればシステム全体の処理スループットが高くなるかが変化する。したがって、システム全体の処理スループットを高くするためには、データの処理要求があったときの状況に基づいて、キャッシュするデータを決定したり、処理を実行するエッジサーバを決定したりする必要がある。上記決定を迅速に行うためには、各エッジサーバの負荷情報を常時収集しておくことが好ましいが、収集頻度が高いほどネットワークのトラフィック量が多くなる。

【0005】

１つの側面では、本発明は、アクセスがあったデータの一時記憶に関する決定を行うための情報収集におけるトラフィック量の削減を図ることが可能な情報処理装置、分散処理システム及び分散処理プログラムを提供することを目的とする。

【課題を解決するための手段】

【0006】

一つの態様では、情報処理装置は、過去におけるデータへのアクセス履歴に基づいて、記憶部に一時的に記憶するデータの候補を特定する記憶候補特定部と、第１の時間間隔で他の情報処理装置から負荷情報を取得する第１取得部と、前記第１取得部が取得した前記他の情報処理装置の負荷情報と自装置の負荷情報とに基づいて、前記記憶部に一時的に記憶されているデータの中から、特定した前記記憶するデータの候補の代わりに前記記憶部から削除するデータの候補を特定する削除候補特定部と、前記第１の時間間隔よりも短い第２の時間間隔で、前記記憶するデータの候補を保持する情報処理装置と、前記削除するデータの候補を保持する情報処理装置とから負荷情報を取得する第２取得部と、前記記憶するデータの候補へのアクセスがあった場合に、前記第２取得部が取得した負荷情報と自装置の負荷情報とに基づいて、前記アクセスがあったデータを前記記憶部に一時的に記憶するか否か、及び前記アクセスがあったデータを前記記憶部に一時的に記憶する場合に前記削除するデータの候補のいずれを削除するかを決定する決定部と、を備えている。

【発明の効果】

【0007】

アクセスがあったデータの一時記憶に関する決定を行うための情報収集におけるトラフィック量の削減を図ることができる。

【図面の簡単な説明】

【0008】

【図1】第１の実施形態に係る分散処理システムの概要図である。

【図2】エッジサーバにおけるタスク実行が完了するまでの時間の計算方法を説明するための図である。

【図3】図３（ａ）～図３（ｃ）は、エッジサーバの負荷や、データソース量、処理結果データ、処理要求データに応じて、タスクを実行するアプリが異なることを説明するための図（その１）である。

【図4】図４（ａ）～図４（ｃ）は、エッジサーバの負荷や、データソース量、処理結果データ、処理要求データに応じて、タスクを実行するアプリが異なることを説明するための図（その２）である。

【図5】図５（ａ）～図５（ｃ）は、エッジサーバの負荷や、データソース量、処理結果データ、処理要求データに応じて、タスクを実行するアプリが異なることを説明するための図（その３）である。

【図6】図６（ａ）は、処理受付エッジサーバにおいてキャッシュを生成しない場合を模式的に示す図であり、図６（ｂ）は、処理受付エッジサーバにおいてキャッシュを生成する場合を模式的に示す図である。

【図7】キャッシュ変更による影響を説明するための図（その１）である。

【図8】キャッシュ変更による影響を説明するための図（その２）である。

【図9】エッジサーバのリソース情報について説明するための図である。

【図10】図１０（ａ）、図１０（ｂ）は、キャッシュ変更（パターン１）を説明するための図である。

【図11】図１１（ａ）は、図１０（ａ）に対応する各エッジサーバの負荷を示す図であり、図１１（ｂ）は、図１０（ｂ）に対応する各エッジサーバの負荷を示す図である。

【図12】図１２（ａ）は、図１０（ａ）に対応する処理スループットの算出方法を示す図であり、図１２（ｂ）は、図１０（ｂ）に対応する処理スループットの算出方法を示す図である。

【図13】図１３（ａ）は、キャッシュ変更（パターン２）を説明するための図であり、図１３（ｂ）は、図１３（ａ）に対応する各エッジサーバの負荷を示す図である。

【図14】図１３（ａ）に対応する処理スループットの算出方法を示す図である。

【図15】図１５（ａ）、図１５（ｂ）は、キャッシュ変更（パターン３）を説明するための図である。

【図16】図１６（ａ）は、図１５（ａ）に対応する各エッジサーバの負荷を示す図であり、図１６（ｂ）は、図１５（ｂ）に対応する各エッジサーバの負荷を示す図である。

【図17】図１７（ａ）は、図１５（ａ）に対応する処理スループットの算出方法を示す図であり、図１７（ｂ）は、図１５（ｂ）に対応する処理スループットの算出方法を示す図である。

【図18】図１８（ａ）は、キャッシュ変更（パターン４）を説明するための図であり、図１８（ｂ）は、図１８（ａ）に対応する各エッジサーバの負荷を示す図である。

【図19】図１８（ａ）に対応する処理スループットの算出方法を示す図である。

【図20】エッジサーバｉ以外でのエッジサーバｉにおけるキャッシュ変更に関連するデータＡ、Ｂの処理スループットの算出方法を示す図である。

【図21】第１の実施形態に係る分散処理システムの構成を示す図である。

【図22】図２２（ａ）は、クラウドサーバのハードウェア構成を示す図であり、図２２（ｂ）は、エッジサーバのハードウェア構成を示す図である。

【図23】データ位置情報テーブルのデータ構造を示す図である。

【図24】エッジサーバの機能ブロック図である。

【図25】図２５（ａ）は、リソース情報一時記憶テーブルを示す図であり、図２５（ｂ）は、データアクセス統計テーブルを示す図であり、図２５（ｃ）は、キャッシュテーブルを示す図である。

【図26】図２６（ａ）は、高頻度対象テーブルを示す図であり、図２６（ｂ）は、リソース情報テーブルを示す図である。

【図27】図２７（ａ）は、アプリ処理要求のメッセージ（ｍ１）の構造を示す図であり、図２７（ｂ）は、アプリ処理応答のメッセージ（ｍ２）の構造を示す図である。

【図28】図２８（ａ）は、アプリ処理要求のメッセージ（ｍ１’）の構造を示す図であり、図２８（ｂ）は、アプリ処理応答のメッセージ（ｍ２’）の構造を示す図である。

【図29】図２９（ａ）は、データ取得要求のメッセージ（ｍ３）の構造を示す図であり、図２９（ｂ）は、データ取得応答のメッセージ（ｍ４）の構造を示す図である。

【図30】図３０（ａ）は、データ／キャッシュ位置要求のメッセージ（ｍ５）の構造を示す図であり、図３０（ｂ）は、データ／キャッシュ位置応答のメッセージ（ｍ６）の構造を示す図であり、図３０（ｃ）は、リソース情報交換のメッセージ（ｍ７）の構造を示す図である。

【図31】低頻度処理を示すフローチャートである。

【図32】高頻度処理を示すフローチャートである。

【図33】要求実行処理を示すフローチャートである。

【図34】図３３のステップＳ５６の処理を示すフローチャートである。

【図35】第１の実施形態の処理の概要を示す図である。

【図36】第２の実施形態に係るエッジサーバの機能ブロック図である。

【図37】第２の実施形態に係るデータ位置情報管理テーブルのデータ構造を示す図である。

【発明を実施するための形態】

【0009】

《第１の実施形態》
以下、第１の実施形態に係る分散処理システムについて、図１～図３５に基づいて詳細に説明する。

【0010】

図１には、本第１の実施形態に係る分散処理システムの概要が示されている。本第１の実施形態の分散処理システムは、複数のエッジサーバを有しており、各エッジサーバのデータベース（ＤＢ）に分散して蓄積された人やモノ（例えば車）に関する動的情報を、ユーザ（例えば車に乗ったユーザ）の要求に応じて処理し、処理結果を提供する。例えば、分散処理システムは、タクシー需給予測サービス、リアルタイムタクシー検索・配車サービスなどに用いることができる。

【0011】

各エッジサーバにおいては、図１に示すように、（１）フィールドに存在している人やモノの動的情報を収集したり、適宜加工してエッジサーバ上のデータベースに格納する。一方、（２）例えば車に乗ったユーザが、周辺の人やモノの動的情報やその情報から得られる処理結果をエッジサーバに対して要求すると、（３）エッジサーバのアプリは、自装置内のデータベースや周辺のエッジサーバのデータベースから必要なデータを取得する。そして、（４）アプリは、人やモノに関する動的情報を処理し、（５）処理結果をユーザに提供する。

【0012】

ここで、本第１の実施形態の分散処理システムにおいては、いずれかのエッジサーバに対してユーザからタスク実行要求があった場合に、応答性能が最も高いエッジサーバにおいて処理を実行することとしている。

【0013】

図２は、エッジサーバにおいてタスク実行要求があってからタスク実行が完了するまでの時間の計算方法を説明するための図である。

【0014】

図２に示すように、あるエッジサーバ（図２ではエッジサーバ２）に対して、ユーザからエッジサーバ３のデータベース（ＤＢｃ）に格納されているデータＣの処理要求（タスク実行要求）があったとする。ここで、図２のａ１～ａ３は、タスク実行場所制御部がアプリに対してタスク実行要求を行うのに要する時間と、アプリからの応答を転送するのに要する時間（タスク実行要求・応答転送時間）を意味する。また、ｂ１～ｂ３は、アプリがタスクを実行する時間と実行待ちの時間（タスク実行・実行待ち時間）を意味し、ｃ１～ｃ３は、アプリにデータＣが転送されるまでの時間（データ転送時間）を意味する。

【0015】

この場合、タスク完了までの時間は、
タスク完了までの時間
＝タスク実行要求・応答転送時間＋タスク実行・実行待ち時間＋データ転送時間
…（１）
と表される。したがって、エッジサーバ２のタスク実行場所制御部は、タスク実行要求を受け付けた際に、エッジ間で共有しているデータ位置や負荷情報に基づいて、タスク完了までの時間（ａ１＋ｂ１＋ｃ１、ａ２＋ｂ２＋ｃ２、ａ３＋ｂ３＋ｃ３）を算出する。そして、タスク実行場所制御部は、算出した時間が最小となるアプリをタスク実行場所として選択する。

【0016】

図３（ａ）～図５（ｃ）は、エッジサーバの負荷や、データソース量、処理結果データ、処理要求データに応じて、タスクを実行するアプリが異なることを説明するための図である。

【0017】

図３（ａ）～図３（ｃ）には、データソース量が多い場合、すなわちアプリがタスクを実行する際にデータベースから取得するデータ量が多い場合が示されている。データソース量が多い場合において、図３（ａ）に示すように、エッジ負荷が均等である場合には、データ保持エッジサーバのアプリがタスクを実行したほうが、タスク完了までの時間は短くなる。また、図３（ｃ）に示すように、処理受付エッジサーバの方が負荷が高い場合にも、データ保持エッジサーバのアプリがタスクを実行したほうが、タスク完了までの時間は短くなる。これに対し、図３（ｂ）に示すように、エッジ保持サーバの方が負荷が高い場合には、各エッジサーバのアプリでタスクを実行するときのタスク完了までの時間を上式（１）に基づいて算出し、当該時間が短くなる方のアプリでタスクを実行する。

【0018】

図４（ａ）～図４（ｃ）には、アプリにおける処理結果データが多い場合が示されている。処理結果データが多い場合において、図４（ａ）に示すように、エッジ負荷が均等である場合には、処理受付エッジサーバのアプリがタスクを実行したほうが、タスク完了までの時間は短くなる。また、図４（ｂ）に示すように、データ保持エッジサーバの方が負荷が高い場合にも、処理受付エッジサーバのアプリがタスクを実行したほうが、タスク完了までの時間は短くなる。これに対し、図４（ｃ）に示すように、処理受付サーバの方が負荷が高い場合には、各エッジサーバのアプリでタスクを実行するときのタスク完了までの時間を上式（１）に基づいて算出し、当該時間が短くなる方のアプリでタスクを実行する。

【0019】

図５（ａ）～図５（ｃ）には、処理要求データが多い場合が示されている。処理要求データが多い場合において、図５（ａ）に示すように、エッジ負荷が均等である場合には、処理受付エッジサーバのアプリがタスクを実行したほうが、タスク完了までの時間は短くなる。また、図５（ｂ）に示すように、データ保持エッジサーバの方が負荷が高い場合にも、処理受付エッジサーバのアプリがタスクを実行したほうが、タスク完了までの時間は短くなる。これに対し、図５（ｃ）に示すように、処理受付サーバの方が負荷が高い場合には、各エッジサーバのアプリでタスクを実行するときのタスク完了までの時間を上式（１）に基づいて算出し、当該時間が短くなる方のアプリでタスクを実行する。

【0020】

ここで、本第１の実施形態では、処理受付エッジサーバにおけるキャッシュについてもさらに考慮して、タスクを実行するアプリを選択するものとする。図６（ａ）には、処理受付エッジサーバにおいてキャッシュを生成しない場合が模式的に示され、図６（ｂ）には、処理受付エッジサーバにおいてキャッシュを生成する場合が模式的に示されている。

【0021】

図６（ａ）の上段に示すように、先行利用者からのタスク実行要求があった場合において、データ保持エッジサーバのアプリがタスク処理を実行するとする。そして、その後に、図６（ｂ）の下段に示すように、後続利用者からの同一のタスク実行要求があった場合も同様にデータ保持エッジサーバのアプリがタスク処理を実行するとする。この場合のスループットは、データ保持エッジサーバのアプリにおける処理時間をＴｂ１、処理受付エッジサーバとデータ保持エッジサーバとの間のタスク実行要求・応答時間をＴａ２１とすると、
スループット＝１／（Ｔｂ１＋Ｔａ２１）[rps] …（２）
と表すことができる。

【0022】

一方、図６（ｂ）の上段に示すように、先行利用者からのタスク実行要求があった場合において、処理受付エッジサーバのアプリがタスク処理を実行して、利用したデータをキャッシュしておくとする。そして、その後に、図６（ｂ）の下段に示すように、後続利用者からの同一のタスク実行要求があった場合に、処理受付エッジサーバのアプリがキャッシュを用いてタスク処理を実行するとする。この場合のスループットは、処理受付エッジサーバのアプリにおける処理時間をＴｂ２、先行利用者のタスク処理の際のデータ転送時間をＴｃ２１とすると、
スループット＝ｎ／（全タスク処理におけるＴｂ２の合計＋Ｔｃ２１）[rps]
…（３）
と表すことができる。

【0023】

したがって、キャッシュを生成すべきか否かは、上式（２）、（３）を用いて算出されるスループットを比較して、スループットが大きくなる方を選択することとすればよい。なお、本例では、アクティブキャッシュはせずに、実際にタスク実行に用いたデータをキャッシュすることとしている。

【0024】

図７には、３つの処理受付エッジサーバのうち、１つの処理受付エッジサーバに処理Ｂ（データＢを用いた処理）の実行要求が出され、２つの処理受付エッジサーバに処理Ａ（データＡを用いた処理）と処理Ｂの実行要求が出された例が示されている。図７においては、タスク実行要求を受け付けたエッジサーバにおいて、各処理が実行されるようになっており、図７の上から１つ目の処理受付エッジサーバは、データＢを保持するデータ保持エッジサーバからデータを取得する。また、図７の上から２つ目と３つ目の処理受付エッジサーバは、３つ目の処理受付エッジサーバのキャッシュからデータＢを取得し、データＡを保持するデータ保持エッジサーバからデータＡを取得する。

【0025】

この場合において、図８に示すように、上から３つ目の処理受付エッジサーバが、当該エッジサーバの負荷を基準として、データＢに代えてデータＡをキャッシュしたとする（キャッシュ変更）。この場合、図８に示すように、データＢを保持するデータ保持エッジサーバにおけるアクセス負荷が増大し、データＢへのアクセスがボトルネックとなって、系全体のスループットが低下するおそれがある。

【0026】

したがって、本第１の実施形態では、キャッシュを変更する処理受付エッジサーバのみならず、キャッシュを変更したことによる系全体のデータアクセスを考慮して、キャッシュを変更する場合としない場合のうち、総スループットが高くなる方を選択する。すなわち、図７の状態で上から３つ目の処理受付エッジサーバに処理Ａの実行要求があったときに、データＢをキャッシュアウトしてデータＡをキャッシュインするか、キャッシュを図７のまま維持するかを、総スループットに基づいて決定する。

【0027】

なお、処理受付エッジサーバは、上記決定を行う際に、各処理受付エッジサーバやデータ保持エッジサーバの負荷などの情報を含むリソース情報を利用する。

【0028】

（リソース情報）
ここで、上記決定の際に利用するリソース情報について、図９に基づいて説明する。図９に示すようなエッジサーバｉのリソース情報には、π_i、δ_i、Π_i、Δ_iが含まれる。π_iは、エッジサーバｉのデータ処理負荷総量である。δ_iは、エッジサーバｉのデータアクセス負荷総量である。Π_iは、エッジサーバｉのデータ処理容量である。Δ_iは、エッジサーバｉのデータアクセス容量である。いずれも単位時間当たりのリクエスト数や、単位時間当たりの使用ＣＰＵ Ｃｌｏｃｋｓ等で表される。π_i、δ_iは、定期的に収集するものであるが、Π_i、Δ_iは、起動時や設定変更時にのみ収集するものである。なお、図９に示すλ^A _i、λ^B _iは、エッジサーバｉに対する処理Ａ、処理Ｂに関するアクセス量を意味する。また、λ_iは、エッジサーバｉに対するアクセス総量であり、次式（４）にて表すことができる。

【0029】

【数1】

【0030】

なお、λ^M _iは、エッジサーバｉでのデータＭに対するアクセス負荷π^M _iと、エッジサーバｉでのデータＭの処理負荷δ^M _iとを用いて、λ^M _i→π^M _i，δ^M _ｉと表すことができる。

【0031】

また、エッジサーバｉのデータ処理負荷総量π_i、及びエッジサーバｉのデータアクセス負荷総量δ_iは次式（５）、（６）にて表される。

【0032】

【数2】

【0033】

ここで、オリジナルのデータ及びキャッシュデータが複数のエッジサーバに分散配置されており、その総数をｃで表すとする。また、それぞれのオリジナルのデータ又はキャッシュデータには他エッジサーバからのアクセスがあるため、その負荷は平均でδ／ｃとなる。また、図９に示すようにエッジサーバｉにキャッシュデータＢが存在する場合、エッジサーバｉ以外からのキャッシュデータＢへのアクセス負荷は、δ^B _≠i／ｃ^Bと表される。なお、ｃ^BはデータＢの総数であり、δ^B _≠iはエッジサーバｉ以外からのデータＢアクセス負荷の合計である。同様に、図９のエッジサーバｉにオリジナルのデータＡが存在する場合、エッジサーバｉ以外からのデータＡへのアクセス負荷は、δ^A _≠i／ｃ^Aと表される。なお、ｃ^AはデータＡの総数であり、δ^A _≠iはエッジサーバｉ以外からのデータＡアクセス負荷の合計である。なお、エッジサーバｉのデータアクセス負荷総量δ_iには上記他エッジサーバからのアクセス負荷が含まれている。

【0034】

（データのキャッシュイン・アウト時の想定負荷）
以下、データのキャッシュイン・アウト時の想定負荷について説明する。

【0035】

（１）パターン１
前提として、図１０（ａ）に示すように、エッジサーバｉがキャッシュデータＢを保持しており、エッジサーバｊがオリジナルのデータＡ、エッジサーバｋがオリジナルのデータＢを保持しているとする。なお、キャッシュを維持した場合の、各エッジサーバｉ，ｊ，ｋのリソース情報は、図１０（ａ）のとおりである。

【0036】

パターン１では、キャッシュ維持時及びキャッシュ変更時のいずれにおいても、エッジサーバｉがデータＡ、Ｂの処理を実行するものとする。なお、キャッシュ変更時には、図１０（ｂ）に示すように、データＢをキャッシュアウトし、データＡをキャッシュインする。

【0037】

このキャッシュ変更が行われた後の各エッジサーバｉ，ｊ，ｋのリソース情報は、図１０（ｂ）のとおりである。図１０（ｂ）に示すようにキャッシュデータが変更されると、それに応じて、他のエッジサーバからのアクセスについても増減する。

【0038】

図１１（ａ）には、図１０（ａ）に示すようにキャッシュ維持した場合の各エッジサーバｉ，ｊ，ｋのデータ処理負荷総量と、データアクセス負荷総量とが示されている。一方、図１１（ｂ）には、図１０（ｂ）のようにキャッシュ変更した場合の各エッジサーバｉ，ｊ，ｋのデータ処理負荷総量と、データアクセス負荷総量が示されている。図１１（ｂ）に示すように、データ処理負荷総量については、図１１（ａ）から変化はないが、データアクセス負荷総量については、各エッジサーバにおいて図１１（ａ）から変化する。図１１（ｂ）のようにキャッシュデータが変更されることにより、例えばキャッシュデータが増えた場合には、系全体として負荷が分散されるため、それぞれのデータへのアクセス負荷が減少する。

【0039】

図１２（ａ）には、図１０（ａ）の場合におけるエッジサーバｉでのデータ処理の処理スループットの計算方法が示されている。エッジサーバｉでのデータＡの処理スループットＴＰ^A _iは、データアクセススループットＴＰ^A,δ，iとデータ処理スループットＴＰ^A,π，iのうち低い方に律速されるため、ＴＰ^A,δ，i及びＴＰ^A,π，iの小さいほうの値とする。

【0040】

また、データアクセススループットについては、図１２（ａ）に示すように、処理要求から発生するデータアクセス負荷と、処理を実行するエッジサーバのデータアクセス容量を比較し、負荷が容量以下の場合には負荷分のスループットとする。同様に、データ処理スループットについては、処理要求から発生するデータ処理負荷と、処理を実行するエッジサーバのデータ処理容量を比較し、負荷が容量以下の場合には負荷分のスループットとする。一方、処理要求から発生するデータアクセス負荷及びデータ処理負荷が各容量を超える場合には、全体として容量に収まるように負荷に係数をかけた値をスループットとする。

【0041】

図１２（ｂ）には、図１０（ｂ）の場合におけるエッジサーバｉでのデータ処理の処理スループットＴＰ’^A _i、ＴＰ’^B _iの計算方法が示されている。図１２（ｂ）についても、図１２（ａ）と同様の計算方法が採用されている。

【0042】

（２）パターン２
パターン２では、キャッシュ維持時はパターン１と同様であるが、キャッシュ変更時には、図１３（ａ）に示すように、エッジサーバｉがデータＡの処理を実行し、エッジサーバｋがデータＢの処理を実行する。このパターン２における各エッジサーバｉ，ｊ，ｋのリソース情報は、図１３（ａ）のとおりである。

【0043】

図１３（ｂ）には、図１３（ａ）のパターン２における各エッジサーバｉ，ｊ，ｋのデータ処理負荷総量と、データアクセス負荷総量が示されている。図１３（ｂ）に示すように、データ処理負荷総量については、図１１（ａ）から変化はないが、データアクセス負荷総量については、各エッジサーバにおいて図１１（ａ）から変化する。図１３（ａ）のようにキャッシュデータが変更されることにより、例えばキャッシュデータが増えた場合には、系全体として負荷が分散されるため、それぞれのデータへのアクセス負荷が減少する。

【0044】

図１４には、図１３（ａ）のパターン２におけるエッジサーバｉでのデータ処理の処理スループットの計算方法が示されている。このパターン２においても、パターン１の場合と同様に、エッジサーバｉでのデータ処理の処理スループットＴＰ’^A _i、ＴＰ’^B _iが計算される。

【0045】

（３）パターン３
パターン３では、図１５（ａ）に示すように、キャッシュ維持時にエッジサーバｉがデータＢの処理を実行し、エッジサーバｊがデータＡの処理を実行する。一方、キャッシュ変更時には、図１５（ｂ）に示すように、エッジサーバｉがデータＡ、Ｂの処理を実行する。

【0046】

図１６（ａ）には、図１５（ａ）に示すようにキャッシュ維持した場合の各エッジサーバｉ，ｊ，ｋのデータ処理負荷総量と、データアクセス負荷総量とが示されている。一方、図１６（ｂ）には、図１５（ｂ）のパターン３における各エッジサーバｉ，ｊ，ｋのデータ処理負荷総量と、データアクセス負荷総量が示されている。図１６（ｂ）に示すように、データ処理負荷総量については、エッジサーバｉ、ｊのデータ処理負荷総量が図１６（ａ）から変化し、データアクセス負荷総量については、各エッジサーバのデータアクセス負荷総量が図１６（ａ）から変化する。

【0047】

図１７（ａ）には、図１５（ａ）の場合におけるエッジサーバｉでのデータ処理の処理スループットの計算方法が示されている。エッジサーバｉでのデータＡの処理スループットＴＰ^A _iは、データアクセススループットＴＰ^A,δ，iとデータ処理スループットＴＰ^A,π，iのうち低い方に律速されるため、ＴＰ^A,δ，i及びＴＰ^A,π，iの小さいほうの値とする。

【0048】

また、データアクセススループットについては、図１７（ａ）に示すように、処理要求から発生するデータアクセス負荷と、処理を実行するエッジサーバのデータアクセス容量を比較し、負荷が容量以下の場合には負荷分のスループットとする。同様に、データ処理スループットについては、処理要求から発生するデータ処理負荷と、処理を実行するエッジサーバのデータ処理容量を比較し、負荷が容量以下の場合には負荷分のスループットとする。一方、処理要求から発生するデータアクセス負荷及びデータ処理負荷が容量を超える場合には、全体として容量に収まるように負荷に係数をかけた値をスループットとする。

【0049】

図１７（ｂ）には、図１５（ｂ）の場合におけるエッジサーバｉでのデータ処理の処理スループットＴＰ’^A _i、ＴＰ’^B _iの計算方法が示されている。図１７（ｂ）についても、図１７（ａ）と同様の計算方法が採用されている。

【0050】

（４）パターン４
パターン４では、キャッシュ維持時はパターン３（図１５（ａ））と同様であるが、キャッシュ変更時には、図１８（ａ）に示すように、エッジサーバｉがデータＡの処理を実行し、エッジサーバｋがデータＢの処理を実行する。このパターン４における各エッジサーバｉ，ｊ，ｋのリソース情報は、図１８（ａ）のとおりである。

【0051】

図１８（ｂ）には、図１８（ａ）のパターン４における各エッジサーバｉ，ｊ，ｋのデータ処理負荷総量と、データアクセス負荷総量が示されている。図１８（ｂ）に示すように、各エッジサーバのデータ処理負荷総量及びデータアクセス負荷総量は、図１６（ａ）から変化する。

【0052】

図１９には、図１８（ａ）のパターン４におけるエッジサーバｉでのデータ処理の処理スループットの計算方法が示されている。このパターン４においても、パターン１～３の場合と同様に、エッジサーバｉでのデータ処理の処理スループットＴＰ’^A _i、ＴＰ’^B _iが計算される。

【0053】

（他エッジサーバのスループットの算出）
次に、エッジサーバｉ以外でのエッジサーバｉにおけるキャッシュ変更に関連するデータＡ、Ｂの処理スループットの算出方法について説明する。なお、このエッジサーバｉ以外での処理スループットの算出方法は、上記パターン１～４において共通である。

【0054】

図２０には、キャッシュ維持時における、エッジサーバｉ以外でのデータＡ、データＢの処理スループットＴＰ^A _≒i、ＴＰ^B _≒iが示されている。図２０に示すように、データＡの処理スループットは、データＡを保持するエッジのデータアクセス容量とデータＡに対する処理要求量との大小関係から決定する。同様に、データＢの処理スループットについても、データＢを保持するエッジのデータアクセス容量とデータＢに対する処理要求量との大小関係から決定する。

【0055】

なお、キャッシュ変更時におけるエッジサーバｉ以外でのデータＡ、データＢの処理スループットＴＰ’^A _≒i、ＴＰ’^B _≒iについても、同様に算出することができる。

【0056】

（キャッシュ変更判定）
キャッシュ変更を行うか否かを判定する場合、キャッシュ維持時のデータＡ，Ｂの処理スループットの総計ＴＰと、キャッシュ変更時のデータＡ，Ｂの処理スループットの総計ＴＰ’とを比較する。そして、キャッシュ変更時の処理スループットの総計の方が大きければ（ＴＰ＜ＴＰ’であれば）、キャッシュ変更を行うこととする。

【0057】

ここで、キャッシュ維持時の処理スループットの総計ＴＰと、キャッシュ変更時の処理スループットの総計ＴＰ’は、次式（７）、（８）より求めることができる。
ＴＰ＝ＴＰ^A _i＋ＴＰ^B _i＋ＴＰ^A _≒i＋ＴＰ^B _≒i …（７）
ＴＰ’＝ＴＰ’^A _i＋ＴＰ’^B _i＋ＴＰ’^A _≒i＋ＴＰ’^B _≒i …（８）

【0058】

このキャッシュ変更判定は、各エッジサーバが、データ処理要求を受け付けた際に実行する。したがって、エッジサーバはキャッシュ変更判定の際に他のエッジサーバの最新の負荷情報を取得する必要がある。ただし、各エッジサーバが他のエッジサーバすべてから負荷情報を高頻度で収集することとすると、トラフィック量が多くなる。一方、トラフィック量の削減を目的として、データ処理要求を受け付けるごとに、他のエッジサーバに問合せすることとすると、サービス応答性が劣化するおそれがある。本実施形態では、サービス応答性を高く維持しながら、トラフィック量の削減を図るため、以下の構成を採用する。

【0059】

図２１には、本第１の実施形態に係る分散処理システム１００の装置構成が概略的に示されている。図２１に示すように、分散処理システム１００は、クラウドサーバ１０と、情報処理装置としての複数のエッジサーバ７０と、を備える。クラウドサーバ１０と複数のエッジサーバ７０は、インターネットなどのネットワーク１１０に接続されている。

【0060】

クラウドサーバ１０は、図２２（ａ）に示すようなハードウェア構成を有する。図２２（ａ）に示すように、クラウドサーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体９１に記憶されたデータやプログラムを読み取り可能な可搬型記憶媒体用ドライブ９９等を備えている。これらクラウドサーバ１０の構成各部は、バス９８に接続されている。クラウドサーバ１０は、ＨＤＤ９６等において、データがどのエッジサーバ７０において保持されているかを示すデータ位置情報テーブル１２を有している。

【0061】

図２３には、データ位置情報テーブル１２のデータ構造が示されている。図２３に示すように、データ位置情報テーブル１２においては、「データＩＤ」、「データ属性」、「データ位置」、「アクセス統計」が管理されている。「データＩＤ」は、データを識別する識別情報であり、「データ属性」は、データの各種属性値である。「データ位置」は、データアクセスエンドポイントの配列である。データアクセスエンドポイントには、エッジサーバアドレスが含まれるとともに、データがオリジナルのデータであれば「true」、キャッシュであれば「false」が含まれる。「アクセス統計」は、システム全体でのデータに対する単位時間当たりのアクセス数である。

【0062】

エッジサーバ７０は、人やモノに関する動的なデータをユーザの端末からの処理要求に応じて処理し、処理結果をユーザに提供する。

【0063】

図２２（ｂ）には、エッジサーバ７０のハードウェア構成が示されている。図２２（ｂ）に示すように、エッジサーバ７０は、クラウドサーバ１０と同様、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、ネットワークインタフェース１９７、及び可搬型記憶媒体用ドライブ１９９等を備えている。これらエッジサーバ７０の構成各部は、バス１９８に接続されている。エッジサーバ７０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム（分散処理プログラムを含む）、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体９１から読み取ったプログラム（分散処理プログラムを含む）をＣＰＵ１９０が実行することにより、図２４に示す、各部の機能が実現される。なお、図２４の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。

【0064】

図２４には、エッジサーバ７０の機能ブロック図が示されている。図２４に示すように、エッジサーバ７０は、ＣＰＵ１９０がプログラムを実行することにより、データ管理部４０、リソース情報管理部５０、タスク実行場所制御部７８として機能する。また、エッジサーバ７０ではアプリ８０がデータ処理を実行する。

【0065】

データ管理部４０は、データ記憶部４２と、分散データ位置管理部４４と、を有する。データ記憶部４２は、オリジナルのデータを記憶したり、キャッシュを記憶したりする。分散データ位置管理部４４は、クラウドサーバ１０のデータ位置情報テーブル１２に、データ記憶部４２に記憶されているデータを登録する。また、分散データ位置管理部４４は、要求受付部７２やアプリ８０からの要求に応じて、データ位置情報テーブル１２を参照し、要求受付部７２やアプリ８０が必要とするデータ位置情報を提供する。

【0066】

リソース情報管理部５０は、自装置情報収集部５２と、第１取得部としての低頻度収集部５４と、キャッシュイン／アウト候補選出部５６と、第２取得部としての高頻度収集部５８と、を有する。

【0067】

自装置情報収集部５２は、自装置の負荷情報を収集して、リソース情報一時記憶テーブル６４に格納する。また、低頻度収集部５４は、低頻度で（時間Ｔごとに）他のエッジサーバ７０から負荷情報を収集して、リソース情報一時記憶テーブル６４に格納する。

【0068】

ここで、リソース情報一時記憶テーブル６４は、図２５（ａ）に示すようなデータ構造を有する。具体的には、リソース情報一時記憶テーブル６４には、エッジサーバの識別情報である「エッジサーバＩＤ」と、各エッジサーバの負荷情報（Π：データ処理容量、Δ：データアクセス容量、π：データ処理負荷総量、δ：データアクセス負荷総量）が格納される。

【0069】

キャッシュイン／アウト候補選出部５６は、リソース情報一時記憶テーブル６４と、データアクセス統計テーブル６２と、キャッシュテーブル６５と、に基づいて、キャッシュイン候補のデータ、キャッシュアウト候補のデータを選出する処理を実行する。

【0070】

ここで、データアクセス統計テーブル６２は、データアクセスに関する情報（アクセス履歴）を管理するテーブルである。具体的には、データアクセス統計テーブル６２は、図２５（ｂ）に示すように、「データＩＤ」に対応付けて、「自装置のアクセス統計」と、「システム全体のアクセス統計」と、を管理している。「自装置のアクセス統計」は、自装置の要求受付部７２が受け付けた、単位時間あたりの各データの処理要求数である。「システム全体のアクセス統計」は、システム全体における単位時間当たりの各データの処理要求数である。このシステム全体のアクセス統計は、要求受付部７２が分散データ位置管理部４４に対してデータ位置を問い合わせたときに取得したアクセス統計（図２３のアクセス統計）である。

【0071】

キャッシュテーブル６５は、自装置においてキャッシュされているデータを管理するテーブルであり、具体的には、図２５（ｃ）に示すように、キャッシュされているデータの「データＩＤ」に対応付けて、「パス」と、「アクセス統計」と、が格納されている。「パス」は、ファイルシステム上のキャッシュデータへのパスを意味し、「アクセス統計」は、キャッシュデータへの単位時間当たりのアクセス数を意味する。

【0072】

キャッシュイン／アウト候補選出部５６は、選出したキャッシュイン候補のデータのオリジナルデータを保持するエッジサーバ７０の情報を、高頻度対象テーブル６６に格納する。また、キャッシュイン／アウト候補選出部５６は、キャッシュアウト候補のデータのオリジナルデータを保持するエッジサーバ７０の情報を、高頻度対象テーブル６６に格納する。ここで、高頻度対象テーブル６６は、図２６（ａ）に示すようなテーブルであり、対象のエッジサーバの識別情報である「エッジサーバＩＤ」を管理している。

【0073】

図２４に戻り、高頻度収集部５８は、キャッシュイン候補のデータのオリジナルデータを保持するエッジサーバと、キャッシュアウト候補のデータのオリジナルデータを保持するエッジサーバから、高頻度で（時間τ（τ＜Ｔ）ごとに）負荷情報を収集する。高頻度収集部５８は、高頻度で収集した負荷情報を、リソース情報テーブル６８に格納する。

【0074】

ここで、リソース情報テーブル６８は、図２６（ｂ）に示すようなテーブルであり、前述したリソース情報一時記憶テーブル６４と同様のデータ構造を有している。

【0075】

図２４に戻り、タスク実行場所制御部７８は、要求受付部７２と、キャッシュイン／アウト判定部７４と、選定部としての処理実行場所決定部７６と、を有する。

【0076】

要求受付部７２は、ユーザの端末からデータの処理要求を受け付け、キャッシュイン／アウト判定部７４に通知する。

【0077】

キャッシュイン／アウト判定部７４は、処理要求があったデータをキャッシュインし、他のデータをキャッシュアウトする（キャッシュ変更する）か、あるいはキャッシュを維持するかを判定する。

【0078】

処理実行場所決定部７６は、キャッシュイン／アウト判定部７４がキャッシュ変更を行うと判定した場合には、自装置を処理実行場所として決定する。また、処理実行場所決定部７６は、キャッシュイン／アウト判定部７４がキャッシュ変更を行わないと判定した場合に、いずれのエッジサーバ７０においてデータ処理を実行するかを決定する。そして、処理実行場所決定部７６は、決定結果を要求受付部７２に通知し、要求受付部７２は、通知された処理実行場所（自装置のアプリ８０又は他のエッジサーバ７０）に対して、処理実行要求のメッセージを通知する。

【0079】

アプリ８０は、自装置の要求受付部７２又は他のエッジサーバ７０から処理実行要求のメッセージを受信すると、受信したメッセージに従って処理を実行する。

【0080】

本実施形態においては、エッジサーバ７０が有する各機能は、図２４に示すように、エッジサーバ７０内の機能間、他のエッジサーバとの間、クラウドサーバ１０との間、ユーザの端末との間で、メッセージ（ｍ１～ｍ９、ｍ１’、ｍ２’）をやり取りする。図２７～図３０には、やり取りされるメッセージの構造の例が示されている。

【0081】

図２７（ａ）には、ユーザの端末から要求受付部７２に送信されてくるアプリ処理要求のメッセージ（ｍ１）の構造が示されている。図２７（ａ）に示すように、メッセージｍ１には、宛先アドレス（エッジサーバ７０のアドレス）、送信元アドレス（端末のアドレス）、アプリパス、処理対象データと処理内容を記述したボディが含まれる。

【0082】

図２７（ｂ）には、要求受付部７２が端末に返すアプリ処理応答のメッセージ（ｍ２）の構造を示されている。図２７（ｂ）に示すように、メッセージｍ２には、宛先アドレス（端末のアドレス）、送信元アドレス（エッジサーバ７０のアドレス）、処理結果を示す処理応答、が含まれる。

【0083】

図２８（ａ）には、要求受付部７２が自装置内のアプリや他のエッジサーバ７０に送信する、アプリ処理要求のメッセージ（ｍ１’）の構造が示されている。このメッセージｍ１’は、上述したメッセージｍ１と同様の構成を有するが、メッセージｍ１とは宛先アドレスや送信元アドレスの内容が異なっている。

【0084】

図２８（ｂ）には、要求受付部７２がメッセージｍ１’の送信先から受け取る、アプリ処理応答のメッセージ（ｍ２’）の構造が示されている。このメッセージｍ２’は、上述したメッセージｍ２と同様の構成を有するが、メッセージｍ２とは宛先アドレスや送信元アドレスの内容が異なっている。

【0085】

図２９（ａ）には、アプリ８０が自装置内のデータ記憶部４２や、他のエッジサーバ７０に送信する、データ取得要求のメッセージ（ｍ３）の構造が示されている。このメッセージｍ３には、宛先アドレス、送信元アドレス、データを格納するデータベースの名称（ＤＢ名）、及びデータ要求クエリが記述されるボディ、が含まれる。

【0086】

図２９（ｂ）には、アプリ８０がメッセージｍ３の送信先から受け取る、データ取得応答のメッセージ（ｍ４）の構造が示されている。このメッセージｍ４には、宛先アドレス、送信元アドレス、及びアプリ８０が要求したデータ、が含まれる。

【0087】

図３０（ａ）には、要求受付部７２から分散データ位置管理部４４に送信するとともに、分散データ位置管理部４４からクラウドサーバ１０に送信する、データ／キャッシュ位置要求のメッセージ（ｍ５）の構造が示されている。このメッセージｍ５には、宛先アドレス、送信元アドレス、及びデータやキャッシュの位置要求クエリが記述されるボディ、が含まれる。

【0088】

図３０（ｂ）には、クラウドサーバ１０から分散データ位置管理部４４に送信するとともに、分散データ位置管理部４４から要求受付部７２に送信する、データ／キャッシュ位置応答のメッセージ（ｍ６）の構造が示されている。このメッセージｍ６には、宛先アドレス、送信元アドレス、及びクラウドサーバ１０が特定したデータやキャッシュの位置情報（データ位置）、が含まれる。

【0089】

図３０（ｃ）には、低頻度収集部５４や高頻度収集部５８が他のエッジサーバ７０の負荷情報を取得する際に、他のエッジサーバ７０から送信されてくる、リソース情報交換のメッセージ（ｍ７）の構造が示されている。このメッセージｍ７には、宛先アドレス、送信元アドレス、及び送信元の他のエッジサーバ７０の負荷情報が記述されるボディ、が含まれる。

【0090】

（エッジサーバ７０の処理について）
次に、図３１～図３４のフローチャートに沿って、エッジサーバ７０の処理について詳細に説明する。本第１の実施形態においては、エッジサーバ７０は、低頻度で実行される低頻度処理（図３１）と、高頻度で実行される高頻度処理（図３２）と、ユーザからの処理要求に応じて実行される要求実行処理（図３３、図３４）と、を並行して実行する。

【0091】

（低頻度処理）
以下、低頻度処理について、図３１に基づいて詳細に説明する。

【0092】

図３１の処理では、まずステップＳ１０において、低頻度収集部５４が、ネットワーク１１０に接続されている他のエッジサーバ７０から情報収集を行う。この場合、低頻度収集部５４は、他のエッジサーバ７０からメッセージｍ７（図３０（ｃ））を取得することで、他のエッジサーバ７０のデータ処理負荷総量（π）、データアクセス負荷総量（δ）、データ処理容量（Π）、データアクセス容量（Δ）を取得する。

【0093】

次いで、ステップＳ１２では、キャッシュイン／アウト候補選出部５６が、データアクセス統計テーブル６２（図２５（ｂ））から、自装置のアクセス統計を取得する。

【0094】

次いで、ステップＳ１４では、キャッシュイン／アウト候補選出部５６が、自装置のアクセス統計に基づいて、キャッシュイン候補データを選出する。具体的には、キャッシュイン／アウト候補選出部５６は、予め定めた基準以上のアクセスがあるデータであり、かつキャッシュテーブル６５に格納されていないデータをキャッシュイン候補として選出する。

【0095】

次いで、ステップＳ１６では、キャッシュイン／アウト候補選出部５６が、キャッシュイン候補データ（オリジナルデータ）を保持するエッジサーバ７０を高頻度情報収集対象として設定する。キャッシュイン／アウト候補選出部５６は、高頻度情報収集対象として設定したエッジサーバ７０の情報を高頻度対象テーブル６６（図２６（ａ））に格納する。

【0096】

次いで、ステップＳ１８では、キャッシュイン／アウト候補選出部５６が、自装置内のキャッシュデータの情報を格納するキャッシュテーブル６５（図２５（ｃ））からキャッシュデータを１つ選択する。

【0097】

次いで、ステップＳ２０では、キャッシュイン／アウト候補選出部５６が、ステップＳ１４で選出したキャッシュイン候補データの１つを選択する。

【0098】

次いで、ステップＳ２２では、キャッシュイン／アウト候補選出部５６が、選択したキャッシュイン候補データをデータＡ、選択したキャッシュデータをデータＢとして、上述した式（７）、（８）に基づいてＴＰ，ＴＰ’を計算する。なお、ＴＰは、データＢのキャッシュを維持し、データＡをキャッシュしない場合（キャッシュ維持時）の処理スループットであり、ＴＰ’は、データＢの代わりにデータＡをキャッシュする場合（キャッシュ変更時）の処理スループットである。

【0099】

次いで、ステップＳ２４では、キャッシュイン／アウト候補選出部５６が、ＴＰ’がＴＰよりも高いか否か（ＴＰ’＞ＴＰ？）を判断する。このステップＳ２４の判断が肯定された場合、すなわち、キャッシュ変更した方が処理スループットが高くなる場合には、ステップＳ２６に移行する。

【0100】

ステップＳ２６に移行すると、キャッシュイン／アウト候補選出部５６は、選択したキャッシュデータをキャッシュアウト候補データとし、スコア（ＴＰ’－ＴＰ）を算出する。その後は、ステップＳ２８に移行する。

【0101】

なお、ステップＳ２４の判断が否定された場合、すなわち、キャッシュ維持した方が処理スループットが高い場合には、ステップＳ２６を経ずに、ステップＳ２８に移行する。

【0102】

ステップＳ２８に移行すると、キャッシュイン／アウト候補選出部５６は、全キャッシュイン候補データを選択したか否かを判断する。このステップＳ２８の判断が否定された場合には、ステップＳ２０に戻る。そして、ステップＳ２８の判断が肯定されるまで、ステップＳ２０～Ｓ２８の処理、判断を繰り返す。これにより、キャッシュデータ（データＢ）を固定したまま、各キャッシュイン候補データ（データＡ）がキャッシュアウト候補データとなるかを判定し、キャッシュアウト候補データとなる場合には、そのスコア（ＴＰ’－ＴＰ）を算出することができる。

【0103】

その後、ステップＳ２８の判断が肯定されると、ステップＳ３０に移行する。

【0104】

ステップＳ３０に移行すると、キャッシュイン／アウト候補選出部５６が、保有するキャッシュアウト候補リストにキャッシュアウト候補データをスコアの最大値とともに格納する。

【0105】

次いで、ステップＳ３２では、キャッシュイン／アウト候補選出部５６が、全キャッシュデータを選択したか否かを判断する。このステップＳ３２の判断が否定された場合には、ステップＳ１８に戻る。そして、ステップＳ３２の判断が肯定されるまで、ステップＳ１８～Ｓ３０の処理、判断を繰り返す。これにより、全キャッシュデータについて、キャッシュアウト候補データとなるかを判定し、キャッシュアウト候補データとなる場合には、キャッシュアウト候補リストに、そのデータをスコア（ＴＰ’－ＴＰ）の最大値とともに格納することができる。

【0106】

その後、ステップＳ３２の判断が肯定されると、ステップＳ３４に移行する。

【0107】

ステップＳ３４に移行すると、キャッシュイン／アウト候補選出部５６は、キャッシュアウト候補リストの上位Ｎ個を選択し、同データのオリジナルデータを保持するエッジサーバ７０を高頻度情報収集対象として設定する。キャッシュイン／アウト候補選出部５６は、高頻度情報収集対象として設定したエッジサーバ７０の情報を高頻度対象テーブル６６（図２６（ａ））に格納する。

【0108】

次いで、ステップＳ３６では、低頻度収集部５４が、時間（Ｔ）待機する。この時間Ｔは、低頻度でステップＳ１０～Ｓ３４の処理を繰り返すための、予め定められた繰返し周期である。

【0109】

その後は、ステップＳ１０に戻り、時間Ｔごとに（低頻度で）ステップＳ１０～Ｓ３４の処理が繰り返し実行されるようになっている。

【0110】

（高頻度処理）
次に、高頻度処理について、図３２のフローチャートに沿って説明する。

【0111】

図３２の処理では、まず、ステップＳ４０において、高頻度収集部５８が、高頻度対象テーブル６６を参照して、高頻度情報収集対象のエッジサーバ７０を特定し、特定したエッジサーバ７０からリソース情報を収集する。そして、高頻度収集部５８は、収集したリソース情報を、リソース情報テーブル６８（図２６（ｂ））に格納する。

【0112】

次いで、ステップＳ４２では、高頻度収集部５８は、時間（τ）だけ待機する。この時間τは、前述した時間Ｔよりも短い時間であり、予め定められた高頻度の繰返し周期である。

【0113】

ステップＳ４２の後は、ステップＳ４０に戻る。すなわち、図３２の処理においては、ステップＳ４０の処理が時間τ毎に（高頻度で）繰り返し実行される。

【0114】

（要求実行処理）
次に、要求実行処理について、図３３、図３４のフローチャートに沿って詳細に説明する。

【0115】

図３３の処理では、まず、ステップＳ５０において、要求受付部７２が、ユーザの端末から処理実行要求を受信するまで待機する。端末から処理実行要求があると、ステップＳ５２に移行し、要求受付部７２は、データアクセス統計テーブル６２を更新する。

【0116】

次いで、ステップＳ５４では、要求受付部７２が、対象データがキャッシュイン候補データであるか否かを判断する。この場合、要求受付部７２は、上述したステップＳ１４のキャッシュイン／アウト候補選出部５６の処理と同様に、データアクセス統計テーブル６２を参照して、キャッシュイン候補データを選出し、対象データがキャッシュイン候補データであるか否かを判断する。

【0117】

このステップＳ５４の判断が肯定された場合には、ステップＳ５６に移行するが、否定された場合には、ステップＳ６２に移行する。

【0118】

ステップＳ５４の判断が肯定されて、ステップＳ５６に移行すると、キャッシュアウトデータ選定処理のサブルーチンが実行される。このキャッシュアウトデータ選定処理においては、図３４のフローチャートに沿った処理が実行される。

【0119】

図３４の処理では、まず、ステップＳ８０において、要求受付部７２が、キャッシュアウト候補データを１つ選択する。なお、要求受付部７２は、キャッシュイン／アウト候補選出部５６が選出したキャッシュアウト候補データの情報を取得しているものとし、キャッシュアウト候補データの中から、１つを選択するものとする。

【0120】

次いで、ステップＳ８２では、要求受付部７２は、選択したキャッシュイン候補データをデータＡ、選択したキャッシュアウト候補データをデータＢとして、リソース情報テーブル６８のデータに基づいて、ＴＰ，ＴＰ’を計算する。なお、この計算においては、上式（７）、（８）を用いるものとする。なお、ＴＰは、データＢのキャッシュを維持し、データＡをキャッシュしない場合（キャッシュ維持時）の処理スループットであり、ＴＰ’は、データＢの代わりにデータＡをキャッシュする場合（キャッシュ変更時）の処理スループットである。なお、要求受付部７２は、算出したＴＰ，ＴＰ’をキャッシュイン／アウト判定部７４に送信する。

【0121】

次いで、ステップＳ８４では、キャッシュイン／アウト判定部７４が、ＴＰ’の方がＴＰよりも大きく、かつＴＰ’がＴＰ’_MAXよりも大きいか否かを判断する。ここで、ＴＰ’_MAXは、初期値が０であるものとする。このステップＳ８４の判断が肯定された場合には、ステップＳ８６に移行する。

【0122】

ステップＳ８６に移行すると、キャッシュイン／アウト判定部７４は、選択したキャッシュアウト候補データをキャッシュアウトデータとし、ＴＰ’_MAXをＴＰ’とする。その後は、ステップＳ８８に移行する。

【0123】

一方、ステップＳ８４の判断が否定された場合には、ステップＳ８６を経ずにステップＳ８８に移行する。

【0124】

ステップＳ８８に移行すると、要求受付部７２は、すべてのキャッシュアウト候補データを選択したか否かを判断する。このステップＳ８８の判断が否定された場合には、ステップＳ８０に戻り、ステップＳ８８の判断が肯定されるまでステップＳ８０～Ｓ８８の処理、判断を繰り返し実行する。

【0125】

そして、ステップＳ８８の判断が肯定された場合には、図３４の全処理を終了し、図３３のステップＳ５８に移行する。

【0126】

ステップＳ５８に移行すると、キャッシュイン／アウト判定部７４は、キャッシュアウトデータが無いか否かを判断する。このステップＳ５８の判断が否定された場合、すなわち、キャッシュアウトデータが存在する場合には、ステップＳ６０に移行する。一方、ステップＳ５８の判断が肯定された場合、すなわち、キャッシュアウトデータが存在しない場合には、ステップＳ６２に移行する。

【0127】

ステップＳ５８の判断が否定されて、ステップＳ６０に移行すると、キャッシュイン／アウト判定部７４は、処理対象データをキャッシュインし、キャッシュアウトデータをキャッシュアウトする。また、処理実行場所決定部７６は、処理実行場所を自装置のアプリとする。その後は、ステップＳ６４に移行し、要求受付部７２は、処理実行場所（自装置のアプリ８０）にメッセージｍ１’を送信して、アプリ８０に処理を実行させる。

【0128】

一方、ステップＳ６２に移行した場合、処理実行場所決定部７６は、処理実行場所計算の結果に基づいて処理実行場所を決定する。具体的には、処理実行場所決定部７６は、上式（１）を用いて説明した方法で、処理が完了するまでの時間が最小となる処理実行場所を決定する。この場合、処理実行要求のあったデータをいずれのエッジサーバ７０が保持しているか、に基づいて、処理実行場所を決定していることになる。そして、ステップＳ６４に移行すると、要求受付部７２は、決定した処理実行場所にメッセージｍ１’を送信して、処理を実行させる。

【0129】

上述したように、ステップＳ６４の処理が実行されると、図３３の全処理が終了する。なお、図３３の処理は、繰り返し実行されるようになっている。

【0130】

これまでの説明から明らかなように、本第１の実施形態では、キャッシュイン／アウト候補選出部５６により、キャッシュイン候補データを特定する記憶候補特定部及びキャッシュアウト候補データを特定する削除候補特定部としての機能が実現されている。また、本第１の実施形態では、要求受付部７２と、キャッシュイン／アウト判定部７４とにより、キャッシュ維持するかキャッシュ変更するかを決定する決定部としての機能が実現されている。

【0131】

以上詳細に説明したように、本第１の実施形態によると、キャッシュイン／アウト候補選出部５６は、過去におけるデータへのアクセス履歴を格納するデータアクセス統計テーブル６２及びキャッシュテーブル６５に基づいて、キャッシュイン候補データを特定する。また、低頻度収集部５４は、時間Ｔごとに（低頻度で）他のエッジサーバ７０から負荷情報を取得する。これに対し、キャッシュイン／アウト候補選出部５６は、リソース情報一時記憶テーブル６４に格納されている他のエッジサーバ７０の負荷情報と自装置の負荷情報とに基づいて、キャッシュデータの中から、キャッシュアウト候補データを特定する。また、高頻度収集部５８は、時間τごとに（高頻度で）、キャッシュイン候補データ又はキャッシュアウト候補データを保持する他のエッジサーバ７０の負荷情報を取得する。そして、要求受付部７２及びキャッシュイン／アウト判定部７４は、キャッシュイン候補データの処理要求があった場合に、高頻度で取得された他のエッジサーバ７０の負荷情報と自装置の負荷情報とに基づいて、キャッシュを維持するか変更するかを決定する。このように、本実施形態では、図３５に示すように、エッジサーバ７０が、（１）他のエッジサーバから低頻度で負荷情報を収集し、（２）収集した情報を用いて、高頻度で負荷情報を収集する対象の他のエッジサーバを決定する（絞り込む）。また、エッジサーバ７０は、（３）決定した（絞り込んだ）エッジサーバのみから高頻度で負荷情報を収集する。そして、エッジサーバ７０は、（４）処理実行要求があった場合に、（５）高頻度で収集した負荷情報を用いて、キャッシュ維持するか、キャッシュ変更するかを決定する。したがって、本実施形態では、すべてのエッジサーバから高頻度で負荷情報を収集しなくても、キャッシュ維持するかキャッシュ変更するかを適切に決定することができるため、トラフィック量を削減することができる。また、トラフィック量を削減するために、処理実行要求があった後にエッジサーバに対して負荷情報を問い合わせるというようなことはしないため、サービス応答性を良好にすることが可能である。

【0132】

また、本実施形態では、キャッシュイン／アウト候補選出部５６は、キャッシュデータを維持した場合と、キャッシュイン候補データをキャッシュデータと変更した場合との処理スループットを比較する（Ｓ２２）。そして、キャッシュイン／アウト候補選出部５６は、キャッシュデータを変更した方が処理スループットが高い場合に、そのキャッシュデータをキャッシュアウト候補データとする。これにより、キャッシュアウト候補データとして適切なキャッシュデータを選定することができる。

【0133】

また、本実施形態では、処理実行場所決定部７６は、キャッシュ変更しない場合（Ｓ５４：否定、Ｓ５８：肯定）に、処理実行場所計算の結果に基づいて処理実行場所を決定する（Ｓ６２）。これにより、処理時間の短いエッジサーバ７０において処理を行うことができる。

【0134】

《第２の実施形態》
次に、第２の実施形態について、図３６に基づいて説明する。本第２の実施形態においては、どのデータをどのエッジサーバで保持しているかの情報（データ位置情報）を各エッジサーバで保持することとしている。

【0135】

図３６には、本第２の実施形態のエッジサーバ７０の機能ブロック図が示されている。図３６に示すように、本第２の実施形態においては、分散データ位置管理部４４がデータ位置情報管理テーブルと、データ位置情報テーブルを有している点が第１の実施形態（図２４）と異なる。なお、データ位置情報テーブルは、第１の実施形態で説明した図２３のようなテーブルであるが、エッジサーバそれぞれが、すべてのデータの位置情報を保持していないものとする。このため、分散データ位置管理部４４は、データ位置情報管理テーブルにおいて、自装置内で管理していないデータの位置情報について問い合わせる際の問い合わせ先のエッジサーバの情報を管理している。

【0136】

図３７には、データ位置情報管理テーブルのデータ構造が示されている。図３７に示すように、データ位置情報管理テーブルにおいては、自装置内で位置情報を管理していないデータのデータＩＤと、当該データの位置情報を管理しているエッジサーバの識別情報（管理担当エッジサーバＩＤ）と、を対応付けて記憶している。

【0137】

このようにすることで、第１の実施形態のように、クラウドサーバ１０においてデータの位置情報を管理しなくても、データの位置情報をエッジサーバ７０において分散管理することができる。

【0138】

なお、データの位置情報をエッジ間で分担して管理するために、ＤＨＴ（Distributed Hash Table：分散ハッシュテーブル）を用いて効率化を図ることとしてもよい。

【0139】

なお、上記各実施形態においては、キャッシュイン／アウト候補選出部５６は、低頻度で収集される各エッジサーバ７０（自装置及び他のエッジサーバ）の負荷情報を用いて、自装置の負荷情報と、他エッジサーバそれぞれの負荷情報との相関関係を算出してもよい。

【0140】

例えば、自装置のデータ処理負荷総量をπ_i、データアクセス負荷総量をδ_iとしたときに、他のエッジサーバｓのデータ処理負荷総量π_s、データアクセス負荷総量δ_sが、次式（９）、（１０）にて表されるとする。
π_s＝α^π _s×π_i＋β^π _s …（９）
δ_s＝α^δ _s×δ_i＋β^δ _s …（１０）

【0141】

この場合、キャッシュイン／アウト候補選出部５６は、相関関係として、自装置の負荷情報とエッジサーバｓの負荷情報を統計処理して、α^π _s、α^δ _s及びβ^π _s、β^δ _sを求める。

【0142】

キャッシュイン／アウト候補選出部５６は、ある時刻における他のエッジサーバそれぞれの負荷情報を、ある時刻における自装置の負荷情報と、上式（９）、（１０）とに基づいて推定することができる。したがって、キャッシュイン／アウト候補選出部５６は、推定したある時刻における他のエッジサーバの負荷情報に基づいてキャッシュアウト候補データを選定することができる。

【0143】

このようにすることで、低頻度での他のエッジサーバ７０の負荷情報の収集頻度を更に低頻度化することが可能である。

【0144】

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。

【0145】

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

【0146】

プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

【0147】

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

【0148】

なお、以上の第１、第２の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） 過去におけるデータへのアクセス履歴に基づいて、記憶部に一時的に記憶するデータの候補を特定する記憶候補特定部と、
第１の時間間隔で他の情報処理装置から負荷情報を取得する第１取得部と、
前記第１取得部が取得した前記他の情報処理装置の負荷情報と自装置の負荷情報とに基づいて、前記記憶部に一時的に記憶されているデータの中から、特定した前記記憶するデータの候補の代わりに前記記憶部から削除するデータの候補を特定する削除候補特定部と、
前記第１の時間間隔よりも短い第２の時間間隔で、前記記憶するデータの候補を保持する情報処理装置と、前記削除するデータの候補を保持する情報処理装置とから負荷情報を取得する第２取得部と、
前記記憶するデータの候補へのアクセスがあった場合に、前記第２取得部が取得した負荷情報と自装置の負荷情報とに基づいて、前記アクセスがあったデータを前記記憶部に一時的に記憶するか否か、及び前記アクセスがあったデータを前記記憶部に一時的に記憶する場合に前記削除するデータの候補のいずれを削除するかを決定する決定部と、
を備える情報処理装置。
（付記２） 前記削除候補特定部は、前記第１の時間間隔で前記他の情報処理装置から取得した負荷情報と、自装置の負荷情報とに基づいて、自装置の負荷情報と前記他の情報処理装置の負荷情報の相関関係を算出し、算出した前記相関関係と自装置の負荷情報とから推定される前記他の情報処理装置の負荷情報を用いて、前記削除するデータの候補を特定する、ことを特徴とする付記１に記載の情報処理装置。
（付記３） 前記削除候補特定部は、
前記記憶するデータの候補を前記記憶部に記憶しないときよりも、前記記憶するデータの候補を前記記憶部に記憶し、前記記憶部に記憶されていたデータを削除したときの方が、前記記憶するデータの候補を処理する際のスループットが高い場合に、前記記憶部に記憶されていたデータを前記削除するデータの候補として特定する、付記１又は２に記載の情報処理装置。
（付記４） 前記決定部が前記アクセスがあったデータを前記記憶部に一時的に記憶しないと決定した場合に、各情報処理装置の負荷情報と、前記アクセスがあったデータをいずれの情報処理装置が保持しているか、に基づいて、前記アクセスがあったデータの処理を実行する情報処理装置を選定する選定部、を更に備える付記１～３のいずれかに記載の情報処理装置。
（付記５） ネットワークに接続された複数の情報処理装置を有する分散処理システムであって、
前記情報処理装置は、
過去におけるデータへのアクセス履歴に基づいて、記憶部に一時的に記憶するデータの候補を特定する記憶候補特定部と、
第１の時間間隔で他の情報処理装置から負荷情報を取得する第１取得部と、
前記第１取得部が取得した前記他の情報処理装置の負荷情報と自装置の負荷情報とに基づいて、前記記憶部に一時的に記憶されているデータの中から、特定した前記記憶するデータの候補の代わりに前記記憶部から削除するデータの候補を特定する削除候補特定部と、
前記第１の時間間隔よりも短い第２の時間間隔で、前記記憶するデータの候補を保持する情報処理装置と、前記削除するデータの候補を保持する情報処理装置とから負荷情報を取得する第２取得部と、
前記記憶するデータの候補へのアクセスがあった場合に、前記第２取得部が取得した負荷情報と自装置の負荷情報とに基づいて、前記アクセスがあったデータを前記記憶部に一時的に記憶するか否か、及び前記アクセスがあったデータを前記記憶部に一時的に記憶する場合に前記削除するデータの候補のいずれを削除するかを決定する決定部と、
を備えることを特徴とする分散処理システム。
（付記６） ネットワークに接続された複数の情報処理装置のコンピュータに、
過去におけるデータへのアクセス履歴に基づいて、記憶部に一時的に記憶するデータの候補を特定し、
第１の時間間隔で他の情報処理装置から負荷情報を取得し、取得した前記他の情報処理装置の負荷情報と自装置の負荷情報とに基づいて、前記記憶部に一時的に記憶されているデータの中から、特定した前記記憶するデータの候補の代わりに前記記憶部から削除するデータの候補を特定し、
前記第１の時間間隔よりも短い第２の時間間隔で、前記記憶するデータの候補を保持する情報処理装置と、前記削除するデータの候補を保持する情報処理装置とから負荷情報を取得し、
前記記憶するデータの候補へのアクセスがあった場合に、前記第２の時間間隔で取得した負荷情報と自装置の負荷情報とに基づいて、前記アクセスがあったデータを前記記憶部に一時的に記憶するか否か、及び前記アクセスがあったデータを前記記憶部に一時的に記憶する場合に前記削除するデータの候補のいずれを削除するかを決定する、
処理を実行させる分散処理プログラム。
（付記７） 前記削除するデータの候補を特定する処理では、前記第１の時間間隔で前記他の情報処理装置から取得した負荷情報と、自装置の負荷情報とに基づいて、自装置の負荷情報と前記他の情報処理装置の負荷情報の相関関係を算出し、算出した前記相関関係と自装置の負荷情報とから推定される前記他の情報処理装置の負荷情報を用いて、前記削除するデータの候補を特定する、ことを特徴とする付記６に記載の分散処理プログラム。
（付記８） 前記削除するデータの候補を特定する処理では、
前記記憶するデータの候補を前記記憶部に記憶しないときよりも、前記記憶するデータの候補を前記記憶部に記憶し、前記記憶部に記憶されていたデータを削除したときの方が、前記記憶するデータの候補を処理する際のスループットが高い場合に、前記記憶部に記憶されていたデータを前記削除するデータの候補として特定する、付記６又は７に記載の分散処理プログラム。
（付記９） 前記決定する処理において、前記アクセスがあったデータを前記記憶部に一時的に記憶しないと決定した場合に、各情報処理装置の負荷情報と、前記アクセスがあったデータをいずれの情報処理装置が保持しているか、に基づいて、前記アクセスがあったデータの処理を実行する情報処理装置を選定する、処理を前記コンピュータに更に実行させることを特徴とする付記６～８のいずれかに記載の分散処理プログラム。

【符号の説明】

【0149】

５４ 低頻度収集部（第１取得部）
５６ キャッシュイン／アウト候補選出部（記憶候補特定部、削除候補特定部）
５８ 高頻度収集部（第２取得部）
６２ データアクセス統計テーブル（アクセス履歴）
７０ エッジサーバ（情報処理装置）
７２ 要求受付部（決定部の一部）
７４ キャッシュイン／アウト判定部（決定部の一部）
７６ 処理実行場所決定部（選定部）
１００ 分散処理システム
１１０ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】