JP7537528B2 - リソース割当装置、リソース割当方法、および、リソース割当プログラム - Google Patents
リソース割当装置、リソース割当方法、および、リソース割当プログラム Download PDFInfo
- Publication number
- JP7537528B2 JP7537528B2 JP2022581105A JP2022581105A JP7537528B2 JP 7537528 B2 JP7537528 B2 JP 7537528B2 JP 2022581105 A JP2022581105 A JP 2022581105A JP 2022581105 A JP2022581105 A JP 2022581105A JP 7537528 B2 JP7537528 B2 JP 7537528B2
- Authority
- JP
- Japan
- Prior art keywords
- allocation
- group
- state management
- calculation unit
- management unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/502—Proximity
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/509—Offload
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
本発明は、リソース割当装置、リソース割当方法、および、リソース割当プログラムに関する。
分散クラウド環境は、NW（Network）内にDC（Data Center）が分散して配置されたアーキテクチャである（非特許文献１，２）。DCは、サーバやユーザが従来担っていた処理をオフロード（代行）するための計算機資源（リソース）を提供する。
以下、DCに割り当てる対象として、ステート管理部を例示する。なお、「ステート」とは、複数のユーザ間でリアルタイムにやりとりするサービスに用いられるデータである。「ステート管理部」とは、各ユーザから受信したアクセス内容をもとに、自身の管理するステートを更新し、その更新後のステートを各ユーザにデータ共有する処理部である。
以下、DCに割り当てる対象として、ステート管理部を例示する。なお、「ステート」とは、複数のユーザ間でリアルタイムにやりとりするサービスに用いられるデータである。「ステート管理部」とは、各ユーザから受信したアクセス内容をもとに、自身の管理するステートを更新し、その更新後のステートを各ユーザにデータ共有する処理部である。
図７は、ステート管理部５ｚをオフロードする前のオンラインシステム９ｚ１の構成図である。
オンラインシステム９ｚ１では、サービス提供装置１ｚは、ステートを複数のユーザ端末４ｚ間でリアルタイムにデータ共有させるサービスを提供する。ステート管理部５ｚが管理するステートは、例えば以下が挙げられる。
・オンラインゲーム：アバタの位置・加速度・動作・装備、ダメージ判定や戦闘不能のステータスなど。
・XR(Extended_Reality)：アバタ（ユーザ）の動作や五感情報、仮想世界において発生する事象など。
・オンライン会議：ユーザや画面共有の音声・映像データプレゼンタ権限やミュートの設定など。
このオンラインシステム９ｚ１では、サービス提供装置１ｚと各ユーザ端末４ｚとの間の通信距離が長いため、大きな通信遅延がサービスの品質を低下させる要因となる。
オンラインシステム９ｚ１では、サービス提供装置１ｚは、ステートを複数のユーザ端末４ｚ間でリアルタイムにデータ共有させるサービスを提供する。ステート管理部５ｚが管理するステートは、例えば以下が挙げられる。
・オンラインゲーム：アバタの位置・加速度・動作・装備、ダメージ判定や戦闘不能のステータスなど。
・XR(Extended_Reality)：アバタ（ユーザ）の動作や五感情報、仮想世界において発生する事象など。
・オンライン会議：ユーザや画面共有の音声・映像データプレゼンタ権限やミュートの設定など。
このオンラインシステム９ｚ１では、サービス提供装置１ｚと各ユーザ端末４ｚとの間の通信距離が長いため、大きな通信遅延がサービスの品質を低下させる要因となる。
図８は、ステート管理部５ｚをＤＣ３ｚにオフロードした後のオンラインシステム９ｚ２の構成図である。
オンラインシステム９ｚ２では、ステート管理部５ｚを動作させる装置を、サービス提供装置１ｚから、ユーザ端末４ｚに近いＤＣ３ｚにオフロードさせている。このオフロードにより、下記のような効果が得られる。
・ユーザ：計算コスト・遅延の低減。
・通信事業者：トラフィック量・輻輳の軽減。
・サービス提供者：サーバ負荷・メンテナンスコストの削減。
オンラインシステム９ｚ２では、ステート管理部５ｚを動作させる装置を、サービス提供装置１ｚから、ユーザ端末４ｚに近いＤＣ３ｚにオフロードさせている。このオフロードにより、下記のような効果が得られる。
・ユーザ：計算コスト・遅延の低減。
・通信事業者：トラフィック量・輻輳の軽減。
・サービス提供者：サーバ負荷・メンテナンスコストの削減。
つまり、サービス品質を向上させるためには、複数のＤＣ３ｚの候補から、どのＤＣ３ｚにステート管理部５ｚを配置するかを選択することが重要となる。非特許文献３には、各ユーザ端末４ｚの間の遅延を求め、その遅延の最大値（最大のE2E遅延）を小さくするようなリソース割当方法が記載されている。
Alicherry and T. V. Lakshman, "Network aware resource allocation in distributed clouds," in 2012 Proceedings IEEE INFOCOM, pp. 963-971, 2012.
M. Mukherjee, L. Shu, and D. Wang, "Survey of fog computing: Fundamental, network applications, and research challenges," in IEEE Communications Surveys & Tutorials, Vol. 20, No. 3, pp. 1826-1857, 2018.
A. Kawabata, B. C. Chatterjee, S. Ba and E. Oki, "A Real-Time Delay-Sensitive Communication Approach Based on Distributed Processing," in IEEE Access, vol. 5, pp. 20235-20248, 2017.
同じオンラインシステムの環境を利用するユーザでも、ユーザのグループごとに様々なアプリケーションを実行させる。その際、例えば、以下の問題を定義する。
・複数のDCと多数のユーザとが、NW内に散在している。
・ユーザ同士で比較的少人数（例：2人～10人）のグループを形成済みである。
・複数のグループに所属するユーザは存在しない。
・全グループのステート管理部を、それぞれ適切なDCに各々収容したい。
・複数のDCと多数のユーザとが、NW内に散在している。
・ユーザ同士で比較的少人数（例：2人～10人）のグループを形成済みである。
・複数のグループに所属するユーザは存在しない。
・全グループのステート管理部を、それぞれ適切なDCに各々収容したい。
また、上記の問題に対して、以下の前提条件がすでに与えられているものと仮定する。
・形成されたすべてのグループとそのメンバ。
・全ユーザと全DC間の遅延時間（例：ping一回の測定値や複数回の平均値など）。
・各DCに収容可能なユーザ数と、ユーザが満たすべき遅延要件（許容可能な遅延の最大値など）。
・形成されたすべてのグループとそのメンバ。
・全ユーザと全DC間の遅延時間（例：ping一回の測定値や複数回の平均値など）。
・各DCに収容可能なユーザ数と、ユーザが満たすべき遅延要件（許容可能な遅延の最大値など）。
図９は、ステート管理部を複数のＤＣにオフロードした場合の分散クラウド環境８ｚの構成図である。
分散クラウド環境８ｚでは、波線で示すNW内に２つのＤＣ（DC1,DC2）が存在し、そのＤＣには５人のユーザ（UA1,UA2,UA3,UB1,UB2）が収容されている。図９の例では、各ユーザは最寄りのＤＣに収容される。よって、DC1には、ユーザ（UA1,UA2,UB1）が収容される。DC2には、ユーザ（UA3,UB2）が収容される。
分散クラウド環境８ｚでは、波線で示すNW内に２つのＤＣ（DC1,DC2）が存在し、そのＤＣには５人のユーザ（UA1,UA2,UA3,UB1,UB2）が収容されている。図９の例では、各ユーザは最寄りのＤＣに収容される。よって、DC1には、ユーザ（UA1,UA2,UB1）が収容される。DC2には、ユーザ（UA3,UB2）が収容される。
ここで、前記の問題定義で説明したように、ユーザ間で第１グループ（UA1,UA2,UA3：２文字目が「A」のグループ）と、第２グループ（UB1,UB2：２文字目が「B」のグループ）とが形成されたとする。第１グループのメンバ同士で同じ対戦ゲームをするためには、UA1,UA2のステート（ST1）とUA3のステート（ST2）とをDC間で共有（同期）する必要がある。第２グループも同様である。
また、第１グループのアプリケーションと、第２グループのアプリケーションとで、サービス要件が異なることもある。
例えば、第１グループで遊ばれるサバイバルゲームでは、１００人など参加人数が多いことを重視し、対戦相手の情報は対戦格闘ゲームほど厳密には求められない。
一方、第２グループで遊ばれる対戦格闘ゲームでは、１対１などの少人数であるがメンバが見る画面情報やメンバの入力した操作情報がすばやく（フレーム単位で）相手側に反映される必要がある。
例えば、第１グループで遊ばれるサバイバルゲームでは、１００人など参加人数が多いことを重視し、対戦相手の情報は対戦格闘ゲームほど厳密には求められない。
一方、第２グループで遊ばれる対戦格闘ゲームでは、１対１などの少人数であるがメンバが見る画面情報やメンバの入力した操作情報がすばやく（フレーム単位で）相手側に反映される必要がある。
このようなサービス要件を考慮しつつ、効率的にグループごとに適したリソース割当を行う手法が求められる。しかし、非特許文献３などの従来のリソース割当技術では、複数のグループが存在し、各グループが様々なサービス要件を求めるような複雑な状況には対応できなかった。
そこで、本発明は、複数のユーザが形成したグループごとの要件に沿ったリソース割当を行うことを主な課題とする。
前記課題を解決するために、本発明のリソース割当装置は、以下の特徴を有する。
本発明は、複数のユーザ端末から構成されるグループごとのステートをグループ内で共有させるためのステート管理部を、分散クラウド環境に配備された複数のデータセンタのうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部と、
前記グループが要求する要件に応じた割当指標を用いて、前記ステート管理部を前記各データセンタに割り当てるときの割当コストを計算し、その割当コストに従って前記ステート管理部の割当先の前記データセンタを決定する割当計算部とを有することを特徴とする。
本発明は、複数のユーザ端末から構成されるグループごとのステートをグループ内で共有させるためのステート管理部を、分散クラウド環境に配備された複数のデータセンタのうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部と、
前記グループが要求する要件に応じた割当指標を用いて、前記ステート管理部を前記各データセンタに割り当てるときの割当コストを計算し、その割当コストに従って前記ステート管理部の割当先の前記データセンタを決定する割当計算部とを有することを特徴とする。
本発明によれば、複数のユーザが形成したグループごとの要件に沿ったリソース割当を行うことができる。
以下、図面を参照して本実施形態を説明する。
図１は、オンラインシステム９の構成図である。
オンラインシステム９は、サービス提供装置１と、リソース割当装置２と、分散クラウド環境８とがネットワークで接続されて構成される。分散クラウド環境８では、ステートを複数のユーザ端末４間でリアルタイムにデータ共有させるサービスが提供される。
そのため、ステート管理部５はグループごとのステートを管理する。各ステート管理部５はいずれかのＤＣ３に配置される。
オンラインシステム９は、サービス提供装置１と、リソース割当装置２と、分散クラウド環境８とがネットワークで接続されて構成される。分散クラウド環境８では、ステートを複数のユーザ端末４間でリアルタイムにデータ共有させるサービスが提供される。
そのため、ステート管理部５はグループごとのステートを管理する。各ステート管理部５はいずれかのＤＣ３に配置される。
まず、リソース割当装置２は、（手順１Ａ）～（手順５Ａ）のようなグループマッチング処理を行う。
（手順１Ａ）ユーザ端末４はサービス提供装置１にアクセスする。
（手順２Ａ）ユーザ端末４はサービス提供装置１上で、ステートを共有する相手である任意の（複数の）ユーザ端末４とマッチングし、グループを形成する。例えばオンラインゲームにおいては、「チームメイトや対戦相手」がステートを共有する相手になる。または、オンライン会議システムの場合は「同じ会議の参加者」がステートを共有する相手になる。
（手順３Ａ）サービス提供装置１は、（手順２Ａ）で形成されたグループのオフロード先として適切なＤＣ３を選択し、そのＤＣ３にグループごとのステート管理部５を配置することでサービスを開始する。
（手順４Ａ）ステート管理部５には、サービスを提供するサーバ機能（オンラインゲームにおける対戦機能など）があらかじめVMやコンテナで実装されている。ステート管理部５は、グループ内で仮想空間などのステートを更新することで、サービスを提供する。
（手順５Ａ）対戦終了後にグループが解散された場合は、解散されたグループメンバのユーザ端末４をサービス提供装置１に返却し、（手順２Ａ）に戻る。
（手順１Ａ）ユーザ端末４はサービス提供装置１にアクセスする。
（手順２Ａ）ユーザ端末４はサービス提供装置１上で、ステートを共有する相手である任意の（複数の）ユーザ端末４とマッチングし、グループを形成する。例えばオンラインゲームにおいては、「チームメイトや対戦相手」がステートを共有する相手になる。または、オンライン会議システムの場合は「同じ会議の参加者」がステートを共有する相手になる。
（手順３Ａ）サービス提供装置１は、（手順２Ａ）で形成されたグループのオフロード先として適切なＤＣ３を選択し、そのＤＣ３にグループごとのステート管理部５を配置することでサービスを開始する。
（手順４Ａ）ステート管理部５には、サービスを提供するサーバ機能（オンラインゲームにおける対戦機能など）があらかじめVMやコンテナで実装されている。ステート管理部５は、グループ内で仮想空間などのステートを更新することで、サービスを提供する。
（手順５Ａ）対戦終了後にグループが解散された場合は、解散されたグループメンバのユーザ端末４をサービス提供装置１に返却し、（手順２Ａ）に戻る。
そして、（手順４Ａ）の詳細として、ＤＣ３は、各グループのステート管理部５が自身の管理するステートを更新する処理を行う。例えば、オンラインの対戦ゲームでは、以下の（手順１Ｂ）～（手順４Ｂ）に示すように、各ユーザ端末４はＤＣ３にコマンドを送り、それと同時に、すでに同期処理され生成された仮想空間（ステート）をＤＣ３から受信する。これにより、ユーザ端末４はＤＣ３と１対１通信を行うだけで他のユーザ端末４のコマンドも取得できる。
（手順１Ｂ）各ユーザ端末４はＤＣ３上のステート管理部５に自身のコマンドを書き込む。例えば、コントローラを用いて自身のアバタを前に進めるためのコマンドを送る。
（手順２Ｂ）ＤＣ３上のステート管理部５が各ユーザ端末４からの（手順１Ｂ）のコマンドを集約・同期する。例えば、各ユーザ端末４から届いたコマンドにしたがって、各ユーザのアバタに移動やアクションを実行させる。すなわち、先ほどよりも僅かに時間が経過した後の仮想世界をステートとして生成する。
（手順３Ｂ）ＤＣ３上のステート管理部５は（手順２Ｂ）の情報を用いて仮想世界をレンダリング（画像化）するなどし、全ユーザ端末４に対してステートを送信する。例えば、ステート管理部５は全ユーザ端末４のコマンドを反映させたゲーム画面（の１コマ）を配信する。
（手順４Ｂ）ステートを受信した各ユーザ端末４は再びコマンドを送信する。例えば、敵が攻撃してくるのが見えたので回避コマンドを入力する。そして（手順１Ｂ）に戻る。
（手順２Ｂ）ＤＣ３上のステート管理部５が各ユーザ端末４からの（手順１Ｂ）のコマンドを集約・同期する。例えば、各ユーザ端末４から届いたコマンドにしたがって、各ユーザのアバタに移動やアクションを実行させる。すなわち、先ほどよりも僅かに時間が経過した後の仮想世界をステートとして生成する。
（手順３Ｂ）ＤＣ３上のステート管理部５は（手順２Ｂ）の情報を用いて仮想世界をレンダリング（画像化）するなどし、全ユーザ端末４に対してステートを送信する。例えば、ステート管理部５は全ユーザ端末４のコマンドを反映させたゲーム画面（の１コマ）を配信する。
（手順４Ｂ）ステートを受信した各ユーザ端末４は再びコマンドを送信する。例えば、敵が攻撃してくるのが見えたので回避コマンドを入力する。そして（手順１Ｂ）に戻る。
以上は、オンラインの対戦ゲームの事例だが、IoT（Internet of Things）環境などにおいて、複数の特定モジュールを組み合わせて最終的な処理結果を得る事例に分散クラウド環境８を適用してもよい。
例えば、気象予測モジュール用のユーザ端末４と、土壌分析モジュール用のユーザ端末４と、農作物分析モジュール用のユーザ端末４とを個別に用意する。そして、これら３つのモジュールをグループ化し、そのグループに属するモジュール群の出力結果を受け取り、それらを処理したり田畑を管理したりする処理部（前記のステート管理部５に対応する処理部）をＤＣ３に配置する。
例えば、気象予測モジュール用のユーザ端末４と、土壌分析モジュール用のユーザ端末４と、農作物分析モジュール用のユーザ端末４とを個別に用意する。そして、これら３つのモジュールをグループ化し、そのグループに属するモジュール群の出力結果を受け取り、それらを処理したり田畑を管理したりする処理部（前記のステート管理部５に対応する処理部）をＤＣ３に配置する。
（手順３Ａ）において、リソース割当装置２は、サービス提供装置１からオフロードされるステート管理部５を、どのＤＣ３に配置するか（以下「ＤＣ配置」と呼ぶ）を、複数のユーザが形成したグループごとの要件（例えば、グループが利用しているアプリケーションごとの要件や、グループが利用しているサービスごとの要件）に沿って選択する。そのため、リソース割当装置２は、リクエスト受信部２１と、NWデータ収集部２２と、割当計算部２３と、制御部２４とを有する。
リクエスト受信部２１は、グループ構成と、ユーザの遅延要件とを含むグループごとのリクエストをサービス提供装置１から受信する。このリクエストは、複数のユーザ端末４から構成されるグループごとにデータ交換するためのステート管理部５を、分散クラウド環境８に配備された複数のＤＣ３のうちのいずれかに割り当てる旨の内容である。
NWデータ収集部２２は、各ユーザ端末４と各ＤＣ３との間の遅延情報と、各ＤＣ３の空き容量（割当可能なユーザの数）情報とを含むNWデータを分散クラウド環境８から測定および収集する。
NWデータ収集部２２は、各ユーザ端末４と各ＤＣ３との間の遅延情報と、各ＤＣ３の空き容量（割当可能なユーザの数）情報とを含むNWデータを分散クラウド環境８から測定および収集する。
割当計算部２３は、リクエスト受信部２１からのリクエストと、割当計算部２３からのNWデータとをもとに、リソース割当スキーム（以下「スキーム」）に従ってグループごとのＤＣ配置を計算する。スキームは、ステート管理部５をどのDCに、どの程度、どのようなポリシで割り当てるかを決定するための情報（主にどの割当指標を重視するか）であり、分散クラウド環境８の性能はスキームに強く依存する。
なお、スキームは、リソース割当装置２がサービス提供装置１からリクエストとして受信してもよい。または、割当計算部２３は、リソース割当装置２がサービス提供装置１からリクエストとして受信したアプリケーション種別をもとに、データベースを参照してスキームを求めてもよい。データベースには、アプリケーション種別ごとに対応するスキームが事前に登録されている。
または、割当計算部２３は、グループ内のメンバからスキームの指定を受けてもよい。
制御部２４は、割当計算部２３からのＤＣ配置に従って、各ステート管理部５を各ＤＣ３にリソース割り当てを行う。
または、割当計算部２３は、グループ内のメンバからスキームの指定を受けてもよい。
制御部２４は、割当計算部２３からのＤＣ配置に従って、各ステート管理部５を各ＤＣ３にリソース割り当てを行う。
図２は、リソース割当装置２のハードウェア構成図である。
リソース割当装置２は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
通信Ｉ／Ｆ９０５は、外部の通信装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（リクエスト受信部２１、NWデータ収集部２２、割当計算部２３、制御部２４に備わるリソース割当プログラムなど）を実行することにより、各処理部を制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
リソース割当装置２は、ＣＰＵ９０１と、ＲＡＭ９０２と、ＲＯＭ９０３と、ＨＤＤ９０４と、通信Ｉ／Ｆ９０５と、入出力Ｉ／Ｆ９０６と、メディアＩ／Ｆ９０７とを有するコンピュータ９００として構成される。
通信Ｉ／Ｆ９０５は、外部の通信装置９１５と接続される。入出力Ｉ／Ｆ９０６は、入出力装置９１６と接続される。メディアＩ／Ｆ９０７は、記録媒体９１７からデータを読み書きする。さらに、ＣＰＵ９０１は、ＲＡＭ９０２に読み込んだプログラム（リクエスト受信部２１、NWデータ収集部２２、割当計算部２３、制御部２４に備わるリソース割当プログラムなど）を実行することにより、各処理部を制御する。そして、このプログラムは、通信回線を介して配布したり、ＣＤ－ＲＯＭ等の記録媒体９１７に記録して配布したりすることも可能である。
図３は、割当計算部２３がグループごとにステート管理部を割り当てる分散クラウド環境８の構成図である。
なお、図９の分散クラウド環境８ｚではグループの概念を考慮せず、ユーザ単位でＤＣの選択を行っていたために、ＤＣ間のステート共有が必要であった。そのため、ステート共有による余分なオーバーヘッドの影響で、ユーザ間の通信遅延も増大してしまっていた。
一方、図３の分散クラウド環境８では、割当計算部２３はグループ単位でのＤＣ配置を行う。これにより、１グループあたり１つのステート管理部５が１台のＤＣ３に割り当てられる。例えば、第１グループ（UA1,UA2,UA3）用のステート管理部（STA）がDC1に割り当てられる一方、第２グループ（UB1,UB2）用のステート管理部（STB）がDC2に割り当てられる。よって、ステート共有時のオーバーヘッドを抑制し、厳しいリアルタイム要件に対応できる。
なお、図９の分散クラウド環境８ｚではグループの概念を考慮せず、ユーザ単位でＤＣの選択を行っていたために、ＤＣ間のステート共有が必要であった。そのため、ステート共有による余分なオーバーヘッドの影響で、ユーザ間の通信遅延も増大してしまっていた。
一方、図３の分散クラウド環境８では、割当計算部２３はグループ単位でのＤＣ配置を行う。これにより、１グループあたり１つのステート管理部５が１台のＤＣ３に割り当てられる。例えば、第１グループ（UA1,UA2,UA3）用のステート管理部（STA）がDC1に割り当てられる一方、第２グループ（UB1,UB2）用のステート管理部（STB）がDC2に割り当てられる。よって、ステート共有時のオーバーヘッドを抑制し、厳しいリアルタイム要件に対応できる。
また、割当計算部２３は、グループごとのアプリケーション種別に適したスキームをリクエストから参照することで、グループごとの要件に適したＤＣ配置を立案できる。
つまり、割当計算部２３は、グループごとの要件に応じたスキームの割当指標を用いて、ステート管理部５を各データセンタに割り当てるときの割当コストを計算し、その割当コストに従ってステート管理部５の割当先のデータセンタを決定する。以下、アプリケーション種別とスキームとの組み合わせとして事例を例示する。
つまり、割当計算部２３は、グループごとの要件に応じたスキームの割当指標を用いて、ステート管理部５を各データセンタに割り当てるときの割当コストを計算し、その割当コストに従ってステート管理部５の割当先のデータセンタを決定する。以下、アプリケーション種別とスキームとの組み合わせとして事例を例示する。
「事例１：完全同期型」は、グループに属するすべてのユーザの通信を逐一待ってからステートを同期することで、グループに属するすべてのユーザが同じ画面を閲覧させるアプリケーションである。以下、完全同期型のアプリケーションを例示する。
・１対１の対戦格闘ゲーム。
・図１の説明で前記した田畑を管理するシステム。
完全同期型のスキーム（割当指標）は、「グループ内の最大遅延」を最小化するものである。グループ全体のQoS（Quality of Service）やQoE（Quality of Experience）が最も遅延の大きなユーザに依存するためである。
・１対１の対戦格闘ゲーム。
・図１の説明で前記した田畑を管理するシステム。
完全同期型のスキーム（割当指標）は、「グループ内の最大遅延」を最小化するものである。グループ全体のQoS（Quality of Service）やQoE（Quality of Experience）が最も遅延の大きなユーザに依存するためである。
「事例２：準同期型」は、ユーザ間で厳密な同期を取らない（取れない）アプリケーションであり、例えば、１００人程度のFPS（First-Person Shooter）のサバイバルゲームである。グループに属する遅延の大きいユーザの通信を待たずにステートを同期することで、遅延の大きいユーザが見る画面がカクついたり、遅延の大きいユーザのキャラクターの最新位置が他ユーザに見えなくなったりする。
準同期型のスキーム（割当指標）は、「グループ内の平均遅延」を最小化するものである。例えば１００人のグループのうちの３人程度のメンバだけ大きな遅延が発生したとしても、その不便を感じるのは３人だけで、残りの９７人は小さい平均遅延で快適な環境が提供されれば充分である。
準同期型のスキーム（割当指標）は、「グループ内の平均遅延」を最小化するものである。例えば１００人のグループのうちの３人程度のメンバだけ大きな遅延が発生したとしても、その不便を感じるのは３人だけで、残りの９７人は小さい平均遅延で快適な環境が提供されれば充分である。
「事例３：公平環境型」は、ユーザ間のプレイ環境において公平性が特に求められるリアルタイムアプリケーションであり、以下に例示する。
・１０人程度が同時に同じサーキットを走行するレースゲーム。
・XR空間やバーチャル会議室では、ユーザの動作が視界に反映されるまでの時間（motion-to-photonlatency）が20[ms]以下になることが望ましい。
・現実の街を模した仮想空間内で会話をするアプリケーションでも、レスポンスを低下させないために一つの空間に滞在可能なユーザ数が制限されている。
公平環境型のスキーム（割当指標）は、「グループ内の遅延のばらつき（分散または標準偏差）」を最小化するものである。
一般に遅延が大きいほどQoS・QoEが低下し、仮想世界における優位性（例：ゲームのスコア）にも影響する。よって、公平環境型のアプリケーションに限らず、他の事例のアプリケーションでも、グループ内の遅延のばらつきを小さくすることが望ましい。
・１０人程度が同時に同じサーキットを走行するレースゲーム。
・XR空間やバーチャル会議室では、ユーザの動作が視界に反映されるまでの時間（motion-to-photonlatency）が20[ms]以下になることが望ましい。
・現実の街を模した仮想空間内で会話をするアプリケーションでも、レスポンスを低下させないために一つの空間に滞在可能なユーザ数が制限されている。
公平環境型のスキーム（割当指標）は、「グループ内の遅延のばらつき（分散または標準偏差）」を最小化するものである。
一般に遅延が大きいほどQoS・QoEが低下し、仮想世界における優位性（例：ゲームのスコア）にも影響する。よって、公平環境型のアプリケーションに限らず、他の事例のアプリケーションでも、グループ内の遅延のばらつきを小さくすることが望ましい。
以上、３種類のスキームを例示したが、例えば、準同期型のスキームとして「グループ内の平均遅延」および「グループ内の最大遅延」の最小化を同時に行うなど、複数の割当指標を組み合わせてもよい。同様に、公平環境型のスキームとして、「グループ内の平均遅延」と、「グループ内の最大遅延」と、「グループ内の遅延のばらつき」という３つの割当指標をバランスよく最小化してもよい。
以下では、グループ内の遅延の最小化と平等化を両立するための定式化を行う。具体的には、３つの割当指標を総合的に評価可能なモデルを説明する。まず、モデルに用いられるパラメータを定義する。
記号「i∈I」は、ユーザiとその集合Iを示す。
記号「j∈J」は、グループj(j=1,2,...,n)とその集合Jを示す。
記号「k∈K」は、ＤＣk（k番目のＤＣ、k=1,2,...,m）とその集合Kを示す。
記号「Ij⊂I」は、グループjに属するユーザの集合Ijを示す。
記号「wij」は、二値変数であり、ユーザiがグループjに属しているなら「1」、そうでなければ「0」の値をとる。
記号「dik」は、ユーザi-ＤＣk間の遅延時間を示す。
記号「Di」は、ユーザiの遅延要件を示す。
記号「Ck」は、ＤＣkが収容可能なユーザ数を示す。
これらの各パラメータは、リクエスト受信部２１のリクエストや、NWデータ収集部２２の収集データとして、割当計算部２３に与えられる。
記号「i∈I」は、ユーザiとその集合Iを示す。
記号「j∈J」は、グループj(j=1,2,...,n)とその集合Jを示す。
記号「k∈K」は、ＤＣk（k番目のＤＣ、k=1,2,...,m）とその集合Kを示す。
記号「Ij⊂I」は、グループjに属するユーザの集合Ijを示す。
記号「wij」は、二値変数であり、ユーザiがグループjに属しているなら「1」、そうでなければ「0」の値をとる。
記号「dik」は、ユーザi-ＤＣk間の遅延時間を示す。
記号「Di」は、ユーザiの遅延要件を示す。
記号「Ck」は、ＤＣkが収容可能なユーザ数を示す。
これらの各パラメータは、リクエスト受信部２１のリクエストや、NWデータ収集部２２の収集データとして、割当計算部２３に与えられる。
割当計算部２３は、割当指標として（式１）および（式２）を計算する。最大遅延の計算式は（式４）で後記する。
（式１）の左辺「ajk」は、グループjをＤＣkに収容した場合のユーザi∈Ijの平均遅延を示す。
（式２）の左辺「v2 jk」は、グループjをＤＣkに収容した場合のユーザi∈Ijの遅延分散を示す。
（式１）の左辺「ajk」は、グループjをＤＣkに収容した場合のユーザi∈Ijの平均遅延を示す。
（式２）の左辺「v2 jk」は、グループjをＤＣkに収容した場合のユーザi∈Ijの遅延分散を示す。
（式３）はＤＣ割当の目的関数を示す。この目的関数は、グループjの割当コストの総和を最小化（minimize）する問題に帰着する。
記号「cjk」は、グループjをＤＣkに収容した場合の割当コストである。
記号「xjk」は、割当計算部２３の計算結果である。「xjk」は決定変数であり、グループjをＤＣkに収容したら「1」の値、そうでなければ「0」の値をとる。
割当計算部２３が割当コストcjkを求める具体的な計算式として（式４）または（式５）を説明する。なお、遅延のばらつきを示す数値として、（式４）では分散を採用し、（式５）では標準偏差を採用した。分散の代わりに標準偏差を用いることで、２乗を含む項がなくなるので、各項のスケールをある程度合わせることができる。
記号「cjk」は、グループjをＤＣkに収容した場合の割当コストである。
記号「xjk」は、割当計算部２３の計算結果である。「xjk」は決定変数であり、グループjをＤＣkに収容したら「1」の値、そうでなければ「0」の値をとる。
割当計算部２３が割当コストcjkを求める具体的な計算式として（式４）または（式５）を説明する。なお、遅延のばらつきを示す数値として、（式４）では分散を採用し、（式５）では標準偏差を採用した。分散の代わりに標準偏差を用いることで、２乗を含む項がなくなるので、各項のスケールをある程度合わせることができる。
α,β(α,β≧0, α+β≦1)は３つの割当指標間のトレードオフを調整するためのパラメータであり、サービス要件等に応じて、サービス提供者、ユーザ、または、NW事業者などが任意に決定する。
（式４）の右辺第１項の「1-α-β」は、その数値が大きいほど「グループ内の平均遅延」を重視するハイパーパラメータである。
（式４）の右辺第２項の「α」は、その数値が大きいほど「グループ内の遅延のばらつき」を重視するハイパーパラメータである。
（式４）の右辺第３項の「β」は、その数値が大きいほど「グループ内の最大遅延」を重視するハイパーパラメータである。なお、右辺第３項のβよりも後の計算式はグループ内の最大遅延の計算式である。
（式４）の右辺第１項の「1-α-β」は、その数値が大きいほど「グループ内の平均遅延」を重視するハイパーパラメータである。
（式４）の右辺第２項の「α」は、その数値が大きいほど「グループ内の遅延のばらつき」を重視するハイパーパラメータである。
（式４）の右辺第３項の「β」は、その数値が大きいほど「グループ内の最大遅延」を重視するハイパーパラメータである。なお、右辺第３項のβよりも後の計算式はグループ内の最大遅延の計算式である。
つまり、（式４）または（式５）では、以下のように３つのハイパーパラメータの配分に応じて、３種類の指標の優先度合いを調整できる。
・α=0かつβ=0とした場合は、平均遅延のみを最適化する（事例２：準同期型に適した設定）。
・α≠0かつβ=0(α+β<1)とした場合は（例：α=0.5,β=0）、平均遅延と分散（標準偏差）とを最適化する。
・α=1かつβ=0(α+β=1)とした場合は、分散（標準偏差）のみを最適化する（事例３：公平環境型に適した設定）。
・α=0かつβ≠0(α+β<1)とした場合は、平均遅延と最大遅延とを最適化する。
・α=0かつβ=1(α+β=1)とした場合は、最大遅延のみを最適化する（事例１：完全同期型に適した設定）。
・α≠0かつβ≠0(α+β=1)とした場合は、分散（標準偏差）と最大遅延とを最適化する。
・α≠0かつβ≠0(α+β<1)とした場合は、平均遅延・分散（標準偏差）・最大遅延のすべてを最適化する。
・α=0かつβ=0とした場合は、平均遅延のみを最適化する（事例２：準同期型に適した設定）。
・α≠0かつβ=0(α+β<1)とした場合は（例：α=0.5,β=0）、平均遅延と分散（標準偏差）とを最適化する。
・α=1かつβ=0(α+β=1)とした場合は、分散（標準偏差）のみを最適化する（事例３：公平環境型に適した設定）。
・α=0かつβ≠0(α+β<1)とした場合は、平均遅延と最大遅延とを最適化する。
・α=0かつβ=1(α+β=1)とした場合は、最大遅延のみを最適化する（事例１：完全同期型に適した設定）。
・α≠0かつβ≠0(α+β=1)とした場合は、分散（標準偏差）と最大遅延とを最適化する。
・α≠0かつβ≠0(α+β<1)とした場合は、平均遅延・分散（標準偏差）・最大遅延のすべてを最適化する。
なお、割当計算部２３は、割当コストcjkを求める計算式として、分散を用いる（式４）の代わりに（式６）を用いてもよいし、標準偏差を用いる（式５）の代わりに（式７）を用いてもよい。
（式６）および（式７）では、３種類のハイパーパラメータ（α,β,γ）を用いている。これにより、パラメータ設定の自由度が高いが，その分扱い（最適なパラメータ設定）が難しくなる。
（式６）および（式７）では、３種類のハイパーパラメータ（α,β,γ）を用いている。これにより、パラメータ設定の自由度が高いが，その分扱い（最適なパラメータ設定）が難しくなる。
右辺第１項の「α」は、その数値が大きいほど「グループ内の平均遅延」を重視するハイパーパラメータである。
右辺第２項の「β」は、その数値が大きいほど「グループ内の遅延のばらつき」を重視するハイパーパラメータである。
右辺第３項の「γ」は、その数値が大きいほど「グループ内の最大遅延」を重視するハイパーパラメータである。
一方、（式４）や（式５）では、パラメータが一つ少なく設定範囲も狭い。しかし、割合で重みが設定できることもあり、３種類のハイパーパラメータ（α,β,γ）を用いるよりも、扱いが容易になる可能性が高い。
右辺第２項の「β」は、その数値が大きいほど「グループ内の遅延のばらつき」を重視するハイパーパラメータである。
右辺第３項の「γ」は、その数値が大きいほど「グループ内の最大遅延」を重視するハイパーパラメータである。
一方、（式４）や（式５）では、パラメータが一つ少なく設定範囲も狭い。しかし、割合で重みが設定できることもあり、３種類のハイパーパラメータ（α,β,γ）を用いるよりも、扱いが容易になる可能性が高い。
（式８）は、（式３）の目的関数に対応する制約条件（subject to）を示す。制約条件は以下の通りである。
・1グループに割当てられるDCは1個以下である。
・収容されるユーザ数が各DCの容量を超えない。
・各ユーザの実際の遅延が遅延要件を満たす。
・1グループに割当てられるDCは1個以下である。
・収容されるユーザ数が各DCの容量を超えない。
・各ユーザの実際の遅延が遅延要件を満たす。
以上、（式３）～（式８）として定式化した問題は、組み合わせ最適化問題であり、大域的最適解を求めるためには、割当計算部２３は、すべての組み合わせを調査（総当たり計算）する必要がある。このときの本問題の計算量は、グループ数をn、DC数をmとして計算量オーダ(mのn乗)であり膨大である。
そこで、割当計算部２３が総当たり計算の代わりに用いる近似アルゴリズムとして、貪欲法（greedy algorithm）と、局所探索法とを順に説明する。割当計算部２３は、貪欲法を単独で用いる、または、貪欲法と局所探索法とを併用する。これにより、総当たり計算で求まる最適解（または最適解に近いスコアの準最適解）を、総当たり計算よりも少ない計算量で求めることができる。
図４は、貪欲法のメイン処理を示すフローチャートである。なお、貪欲法とは、１つの大きな問題を複数の小さな問題に分割し、小さな問題を個別に評価して評価値の高い候補を採用する手法である。
割当計算部２３は、リクエスト受信部２１からのリクエストと、NWデータ収集部２２からのNWデータとをもとに、図６で後記するコストテーブルを作成する（Ｓ１０１）。割当計算部２３は、Ｓ１０１のコストテーブルの各グループについて、コストの最小値を算出する（Ｓ１０２）。
割当計算部２３は、コストテーブルの各グループについてコストの最小値について昇順ソートする（Ｓ１０３）。
割当計算部２３は、リクエスト受信部２１からのリクエストと、NWデータ収集部２２からのNWデータとをもとに、図６で後記するコストテーブルを作成する（Ｓ１０１）。割当計算部２３は、Ｓ１０１のコストテーブルの各グループについて、コストの最小値を算出する（Ｓ１０２）。
割当計算部２３は、コストテーブルの各グループについてコストの最小値について昇順ソートする（Ｓ１０３）。
割当計算部２３は、グループの変数jに初期値1を代入する（Ｓ１０４）。
ここで、割当計算部２３は、グループjをコストテーブルのグループ数まで1つずつ順番に選択するループを実行し（Ｓ１０５～Ｓ１０７）、このループ内でグループjにDC割当を行うサブルーチン（図５）を呼び出す（Ｓ１０６）。
なお、Ｓ１０６の処理において、あるユーザの遅延要件を満たせるような割当先DCが存在しないとき、もしくはDCのキャパシティが十分でない場合は、割当できないグループが発生する可能性がある。
ここで、割当計算部２３は、グループjをコストテーブルのグループ数まで1つずつ順番に選択するループを実行し（Ｓ１０５～Ｓ１０７）、このループ内でグループjにDC割当を行うサブルーチン（図５）を呼び出す（Ｓ１０６）。
なお、Ｓ１０６の処理において、あるユーザの遅延要件を満たせるような割当先DCが存在しないとき、もしくはDCのキャパシティが十分でない場合は、割当できないグループが発生する可能性がある。
図５は、図４の貪欲法のサブルーチン処理（Ｓ１０６）を示すフローチャートである。
割当計算部２３は、コストテーブルの第jグループ行を読み込み（Ｓ１１１）、その中でコストが最小となるＤＣに割当を試みる（Ｓ１１２）。
割当計算部２３は、ユーザの遅延要件を満たし（Ｓ１１３,Yes）、かつ、ＤＣの容量が充分にある（Ｓ１１４,Yes）場合に、グループｊをそのＤＣに割り当てる（Ｓ１１５）。
一方、（Ｓ１１３,No）、または、（Ｓ１１４,No）の場合は、割当計算部２３は、そのＤＣを第ｊグループのコストテーブルから削除する（Ｓ１１６）。
割当計算部２３は、コストテーブルの第jグループ行を読み込み（Ｓ１１１）、その中でコストが最小となるＤＣに割当を試みる（Ｓ１１２）。
割当計算部２３は、ユーザの遅延要件を満たし（Ｓ１１３,Yes）、かつ、ＤＣの容量が充分にある（Ｓ１１４,Yes）場合に、グループｊをそのＤＣに割り当てる（Ｓ１１５）。
一方、（Ｓ１１３,No）、または、（Ｓ１１４,No）の場合は、割当計算部２３は、そのＤＣを第ｊグループのコストテーブルから削除する（Ｓ１１６）。
図６は、図４、図５の貪欲法の処理例を示す説明図である。
説明をわかりやすくするため、図６では以下の問題設定とする。
・6個のグループ（G1-G6）を3個のＤＣ（DC1-DC3）に割り当てたい。
・各DCは2グループまで割当可能である。なお、本来のCkの単位はユーザ数であるが、ここでは簡単のためグループ数で指定した。
・簡単のため、ユーザの遅延要件は考えない（つまりD=∞）。
・平均遅延のみを考慮するため、α=β=0とする。もちろん他のパラメータ設定を用いてもよい。
説明をわかりやすくするため、図６では以下の問題設定とする。
・6個のグループ（G1-G6）を3個のＤＣ（DC1-DC3）に割り当てたい。
・各DCは2グループまで割当可能である。なお、本来のCkの単位はユーザ数であるが、ここでは簡単のためグループ数で指定した。
・簡単のため、ユーザの遅延要件は考えない（つまりD=∞）。
・平均遅延のみを考慮するため、α=β=0とする。もちろん他のパラメータ設定を用いてもよい。
コストテーブル２０１は、グループjをＤＣkに収容した場合の割当コストcjkについて、グループjを行としＤＣkを列としたときの２次元のテーブルである。割当計算部２３は図４のＳ１０１でコストテーブル２０１を作成する。そして、割当計算部２３は、コストテーブル２０１を最小値で昇順ソートした結果をコストテーブル２０２とする（Ｓ１０３）。
ＤＣ割当テーブル２１１～２１７は、コストテーブル２０２をもとにした割当計算部２３の計算結果「xjk」をテーブル形式にしたものである。例えば、ＤＣ割当テーブル２１４では、DC1に「G4,G2」という２グループが割り当てられ、DC2にはグループが未割当であり（記号「-」）、DC3に「G5」という１グループが割り当てられている。
ＤＣ割当テーブル２１１～２１７は、コストテーブル２０２をもとにした割当計算部２３の計算結果「xjk」をテーブル形式にしたものである。例えば、ＤＣ割当テーブル２１４では、DC1に「G4,G2」という２グループが割り当てられ、DC2にはグループが未割当であり（記号「-」）、DC3に「G5」という１グループが割り当てられている。
以下の手順により、割当計算部２３は、コストテーブル２０２の上位に位置するグループから順に、Ｓ１０６のサブルーチンを呼び出すことで各グループを各ＤＣに割り当てる。
（第１行のG4）割当計算部２３は、G4をコスト最小（＝6.0）となるDC1に割り当てる（ＤＣ割当テーブル２１１→ＤＣ割当テーブル２１２）。
（第２行のG2）割当計算部２３は、G2をコスト最小となるDC1に割り当てる（ＤＣ割当テーブル２１２→ＤＣ割当テーブル２１３）。
（第３行のG5）割当計算部２３は、G5をコスト最小となるDC3に割り当てる（ＤＣ割当テーブル２１３→ＤＣ割当テーブル２１４）。
（第４行のG6）割当計算部２３は、G6をコスト最小となるDC1に割り当てようとするも、DC1は容量不足である。よって、割当計算部２３は、G6をコストが２番目に小さいDC3に割り当てる（ＤＣ割当テーブル２１４→ＤＣ割当テーブル２１５）。
（第５行のG3）割当計算部２３は、G3をコスト最小となるDC2に割り当てる（ＤＣ割当テーブル２１５→ＤＣ割当テーブル２１６）。
（第６行のG1）割当計算部２３は、G1をコスト最小となるDC2に割り当てる（ＤＣ割当テーブル２１６→ＤＣ割当テーブル２１７）。
（第１行のG4）割当計算部２３は、G4をコスト最小（＝6.0）となるDC1に割り当てる（ＤＣ割当テーブル２１１→ＤＣ割当テーブル２１２）。
（第２行のG2）割当計算部２３は、G2をコスト最小となるDC1に割り当てる（ＤＣ割当テーブル２１２→ＤＣ割当テーブル２１３）。
（第３行のG5）割当計算部２３は、G5をコスト最小となるDC3に割り当てる（ＤＣ割当テーブル２１３→ＤＣ割当テーブル２１４）。
（第４行のG6）割当計算部２３は、G6をコスト最小となるDC1に割り当てようとするも、DC1は容量不足である。よって、割当計算部２３は、G6をコストが２番目に小さいDC3に割り当てる（ＤＣ割当テーブル２１４→ＤＣ割当テーブル２１５）。
（第５行のG3）割当計算部２３は、G3をコスト最小となるDC2に割り当てる（ＤＣ割当テーブル２１５→ＤＣ割当テーブル２１６）。
（第６行のG1）割当計算部２３は、G1をコスト最小となるDC2に割り当てる（ＤＣ割当テーブル２１６→ＤＣ割当テーブル２１７）。
以上、図４～図６を参照して貪欲法について説明した。
以下では、貪欲法のアルゴリズムを詳細に説明する疑似コードを例示する。この疑似コードは、代入「A←1」（変数Aに値１を代入）、繰り返し制御「for～end for、while～end while」、分岐制御「if～end if」などを行う手続型言語である。また、疑似コードの行頭には、説明用の行番号（L01,L02,…）を付加した。
各関数（function）は、「Input:～」で与えられた入力変数をもとに、所定の計算を行い、その計算結果を「Output:～」で示す出力変数として応答（return）する。
以下では、貪欲法のアルゴリズムを詳細に説明する疑似コードを例示する。この疑似コードは、代入「A←1」（変数Aに値１を代入）、繰り返し制御「for～end for、while～end while」、分岐制御「if～end if」などを行う手続型言語である。また、疑似コードの行頭には、説明用の行番号（L01,L02,…）を付加した。
各関数（function）は、「Input:～」で与えられた入力変数をもとに、所定の計算を行い、その計算結果を「Output:～」で示す出力変数として応答（return）する。
まず、Greedy_Allocation関数を示す。
Input: α,β,wij,dik,Di, and Ck for ∀i∈I,∀j∈J, and ∀k∈K
Output: xjk for ∀j∈J and ∀k∈K
L01: function Greedy_Allocation(α,β,wij,dik,Di,Ck)
L02: for all i∈I,j∈J,k∈K do
L03: w[i][j]←wij,d[i][k]←dik
L04: D[i]←Di,C[k]←Ck
L05: Calculate cjkusing （式4）～（式7）
L06: c[j][k]←cjk
L07: end for
L08: for all j∈J do
L09: J[j]←j,L[j]←minkc[j][k]
L10: end for
L11: Sort J in ascending order of L
L12: X←GroupDC_Mapping(J,c,w,d,D,C)
L13: return X
L14: end function
Input: α,β,wij,dik,Di, and Ck for ∀i∈I,∀j∈J, and ∀k∈K
Output: xjk for ∀j∈J and ∀k∈K
L01: function Greedy_Allocation(α,β,wij,dik,Di,Ck)
L02: for all i∈I,j∈J,k∈K do
L03: w[i][j]←wij,d[i][k]←dik
L04: D[i]←Di,C[k]←Ck
L05: Calculate cjkusing （式4）～（式7）
L06: c[j][k]←cjk
L07: end for
L08: for all j∈J do
L09: J[j]←j,L[j]←minkc[j][k]
L10: end for
L11: Sort J in ascending order of L
L12: X←GroupDC_Mapping(J,c,w,d,D,C)
L13: return X
L14: end function
Greedy_Allocation関数(α,β,wij,dik,Di,Ck)では、αおよびβを用いてコスト表を作成し（L05）、表の中で最小コストが小さいグループから優先的に（L11）DC割当を行うための前処理を行う。なお、実際のDC割当については引数wij,dik,Di,Ckと、ここで作成されたコスト表cおよびコスト表を参照する順列Jを引数としたGroupDC_Mapping関数を呼び出して実行する（L12）。
図４のフローチャートでは、Ｓ１００がL01に、Ｓ１０１がL05に、Ｓ１０２がL09に、Ｓ１０３がL11に、Ｓ１０６がL12に、それぞれ対応する。
図４のフローチャートでは、Ｓ１００がL01に、Ｓ１０１がL05に、Ｓ１０２がL09に、Ｓ１０３がL11に、Ｓ１０６がL12に、それぞれ対応する。
次に、GroupDC_Mapping関数を示す。
L16: function GroupDC_Mapping(J,c,w,d,D,C)
L17: for j'=1 to size(J) do
L18: j←J[j']
L19: Discover Ijfrom I using w
L20: X[j]←DC_Selection(c[j],Ij,d,D,C)
L21: if X[j]=∞ then
L22: D[i]←∞ for ∀i∈Ij
L23: X[j]←DC_Selection(c[j],Ij,d,D,C)
L24: end if
L25: end for
L26: return X
L27: end function
L16: function GroupDC_Mapping(J,c,w,d,D,C)
L17: for j'=1 to size(J) do
L18: j←J[j']
L19: Discover Ijfrom I using w
L20: X[j]←DC_Selection(c[j],Ij,d,D,C)
L21: if X[j]=∞ then
L22: D[i]←∞ for ∀i∈Ij
L23: X[j]←DC_Selection(c[j],Ij,d,D,C)
L24: end if
L25: end for
L26: return X
L27: end function
GroupDC_Mapping関数(J,c,w,d,D,C)では、与えられたコスト表cを順列Jにしたがって（L17）順に参照し（すなわちコスト表のある行c[j]を抽出し）、各グループにDCを割り当てるためのDC_Selection関数を順次呼び出して割当を得る（L20,L23）。仮にDC_Selection関数がユーザの遅延要件Dを満たすことのできるDCが存在しないことを示した場合には、遅延要件Dを無視して割当を行う。
なお、L20,L23のX[j]←kは、割り当て有なら値１（xjk’=1 if k’=k）、または、割り当て無なら値０（xjk’=0 otherwise）と等価である。
図４のフローチャートでは、Ｓ１０４、Ｓ１０５、および、Ｓ１０７がL17～L25のfor文に、Ｓ１１２がL20およびL23に、それぞれ対応する。
なお、L20,L23のX[j]←kは、割り当て有なら値１（xjk’=1 if k’=k）、または、割り当て無なら値０（xjk’=0 otherwise）と等価である。
図４のフローチャートでは、Ｓ１０４、Ｓ１０５、および、Ｓ１０７がL17～L25のfor文に、Ｓ１１２がL20およびL23に、それぞれ対応する。
さらに、DC_Selection関数を示す。
L29: function DC_Selection(c[j],Ij,d,D,C)
L30: tmp←c[j]
L31: while True do
L32: k←arg mink'tmp[k']
L33: if tmp[k]=∞ then
L34: return ∞
L35: end if
L36: if d[i][k]≦D[i] for ∀i∈I and |Ij|≦C[k] then
L37: C[k]←C[k]-|Ij|
L38: return k
L39: else
L40: tmp[k]←∞
L41: end if
L42: end while
L43: end function
L29: function DC_Selection(c[j],Ij,d,D,C)
L30: tmp←c[j]
L31: while True do
L32: k←arg mink'tmp[k']
L33: if tmp[k]=∞ then
L34: return ∞
L35: end if
L36: if d[i][k]≦D[i] for ∀i∈I and |Ij|≦C[k] then
L37: C[k]←C[k]-|Ij|
L38: return k
L39: else
L40: tmp[k]←∞
L41: end if
L42: end while
L43: end function
DC_Selection関数(c[j],Ij,d,D,C)では、グループメンバIjについて、各ユーザの遅延要件Dを満たし、残容量Cがグループサイズ|Ij|より大きいDCの中から（L36）、遅延コストc[j][k]が最も小さいDCkを割当先として選択する（L37,L38）。
図５のフローチャートでは、Ｓ１１３およびＳ１１４がL36に、Ｓ１１５がL37に、Ｓ１１６がL40に、それぞれ対応する。なお、L40の「tmp[k]←∞」とは、グループコストを無限大にすることで、そのグループを割り当て対象から削除することと等価である。
図５のフローチャートでは、Ｓ１１３およびＳ１１４がL36に、Ｓ１１５がL37に、Ｓ１１６がL40に、それぞれ対応する。なお、L40の「tmp[k]←∞」とは、グループコストを無限大にすることで、そのグループを割り当て対象から削除することと等価である。
以上説明したように、割当計算部２３は、貪欲法を単独で用いる場合は、Greedy_Allocation関数を呼び出せばよい。これにより、グループをソートし、コストが小さいものから優先的に割り当てていくことで、少ない計算時間で高精度な最適化が可能となる。一方、割当計算部２３は、提案法と局所探索法とを組み合わせることで、さらに良い解を求めてもよい。
以下は、提案法と局所探索法とを組み合わせたアルゴリズムの疑似コードである。
Input: N,α,β,wij,dik,Di, and Ck
Output: xjk
M01: X←Greedy_Allocation(α,β,wij,dik,Di,Ck)
M02: Calculate the total cost tx of X like （式3）
M03: n←0
M04: while n++<N do
M05: Randomize the order of J
M06: X'←GroupDC_Mapping(J,c,w,d,D,C)
M07: Calculate the total cost t'xof X'
M08: if t'x<txthen
M09: X←X',tx←t'x
M10: end if
M11: end while
Input: N,α,β,wij,dik,Di, and Ck
Output: xjk
M01: X←Greedy_Allocation(α,β,wij,dik,Di,Ck)
M02: Calculate the total cost tx of X like （式3）
M03: n←0
M04: while n++<N do
M05: Randomize the order of J
M06: X'←GroupDC_Mapping(J,c,w,d,D,C)
M07: Calculate the total cost t'xof X'
M08: if t'x<txthen
M09: X←X',tx←t'x
M10: end if
M11: end while
この疑似コード（M01～M11）では、まず、割当計算部２３は、Greedy_Allocation関数を実行する（M01）。次に、割当計算部２３は、GroupDC_Mapping関数を一定回数（M04のN回）実行する（M06）。このとき、「コストテーブルのソート」の部分で、割当計算部２３は、グループの順列をランダムに変更する（M05）。そして、割当計算部２３は、N回の繰り返しの中で最も全体のコストが低かった割当を選択する（M08～M10）。
この疑似コード（M01～M11）により、GroupDC_Mapping関数をN回繰り返す旨の探索回数の追加により、計算コストは増えるものの、貪欲法よりも割当コストがさらに小さくなる可能性がある。なお、探索回数Nはサービス提供者や分散環境運用者が任意に設定する。
この疑似コード（M01～M11）により、GroupDC_Mapping関数をN回繰り返す旨の探索回数の追加により、計算コストは増えるものの、貪欲法よりも割当コストがさらに小さくなる可能性がある。なお、探索回数Nはサービス提供者や分散環境運用者が任意に設定する。
ここで、リクエスト受信部２１に与えられるグループ数に着目して、以下のように分類する。
（分類１）オフライン割当は、割り当てるべきすべてのグループがあらかじめリクエスト受信部２１に与えられる場合である。
（分類２）バッチ割当は、割り当てるべきグループの一部（複数のグループ）が逐次リクエスト受信部２１に与えられ、その都度（比較的小規模な）オフライン割当を実行する場合である。例えば大規模システムでは、例えば10秒の間にいくつものグループが作成されるため、この場合は10秒ごとにバッチ割当をおこなうニーズが出てくる。
（分類３）オンライン割当は、割り当てるべきグループが一つずつリクエスト受信部２１に与えられ、その都度割当を実行する場合である。例えば、バッチ処理を実行するほど頻繁にグループが形成されない場合や、グループ形成から割当完了までの時間を可能な限り小さくしたい場合などが挙げられる。
（分類１）オフライン割当は、割り当てるべきすべてのグループがあらかじめリクエスト受信部２１に与えられる場合である。
（分類２）バッチ割当は、割り当てるべきグループの一部（複数のグループ）が逐次リクエスト受信部２１に与えられ、その都度（比較的小規模な）オフライン割当を実行する場合である。例えば大規模システムでは、例えば10秒の間にいくつものグループが作成されるため、この場合は10秒ごとにバッチ割当をおこなうニーズが出てくる。
（分類３）オンライン割当は、割り当てるべきグループが一つずつリクエスト受信部２１に与えられ、その都度割当を実行する場合である。例えば、バッチ処理を実行するほど頻繁にグループが形成されない場合や、グループ形成から割当完了までの時間を可能な限り小さくしたい場合などが挙げられる。
これまで説明したGreedy_Allocation関数は、リクエスト受信部２１にまとまった数のグループが与えられた場合（オフライン割当やバッチ処理）を想定している。一方、リクエスト受信部２１に割り当てるべきグループが逐次やってくる場合には、以下に示すオンライン割当の疑似コードを実行すればよい。
Input: α,β,wij,dik,Di, and Ck for ∀i∈I,∀j∈J, and ∀k∈K
Output: xjk for ∀j∈J and ∀k∈K
N01: while True do
N02: if receive an offload request for group j then
N03: Calculate cjkfor ∀k∈K
N04: c[k]←cjk
N05: X[j]←DC_Selection(c[j],Ij,d,D,C)
N06: if X[j]=∞ then
N07: D[i]←∞ for ∀i∈Ij
N08: X[j]←DC_Selection(c[j],Ij,d,D,C)
N09: end if
N10: return X[j]
N11: end if
N12: end while
Input: α,β,wij,dik,Di, and Ck for ∀i∈I,∀j∈J, and ∀k∈K
Output: xjk for ∀j∈J and ∀k∈K
N01: while True do
N02: if receive an offload request for group j then
N03: Calculate cjkfor ∀k∈K
N04: c[k]←cjk
N05: X[j]←DC_Selection(c[j],Ij,d,D,C)
N06: if X[j]=∞ then
N07: D[i]←∞ for ∀i∈Ij
N08: X[j]←DC_Selection(c[j],Ij,d,D,C)
N09: end if
N10: return X[j]
N11: end if
N12: end while
この疑似コード（N01～N12）では、まず、割当計算部２３は、グループjの割当リクエストを受信したとき（N02）、そのグループjと各DC間の割当コストcjkをすべて計算し（N03）、グループjについてのみのコストテーブルを作成する（N04）。
そして、割当計算部２３は、グループjについてDC_Selection関数を実行する（N05,N08）。このとき、割当計算部２３は、各DCの容量Ck=C[k]を常にモニタしておき、グループjがDCを離れたときはその分容量を増やす。
そして、割当計算部２３は、グループjについてDC_Selection関数を実行する（N05,N08）。このとき、割当計算部２３は、各DCの容量Ck=C[k]を常にモニタしておき、グループjがDCを離れたときはその分容量を増やす。
以下、（分類１）～（分類３）それぞれの計算量を示すため、各分類の関数の呼び出す回数を例示する。
（分類１）オフライン割当として、グループ数＝10がいっぺんに与えられる場合は、以下の通りである。
（分類１）で貪欲法だけを実行する場合は、Greedy_Allocation関数を1回、GroupDC_Mapping関数を1回、DC_Selection関数を10回以上実行する。なお、DC_Selection関数を呼び出す回数が10回を超える場合は、ユーザの遅延要件を満たせるDCがなかった場合（L20行目の返り値が∞となった場合）に、L23行目に移って再びDC_Selection関数が呼び出される場合である。
（分類１）で貪欲法と局所探索とを併せて実行する場合は、Greedy_Allocation関数を１回実行した後、GroupDC_Mapping関数およびDC_Selection関数をワンセットとしてN回繰り返す（Greedy_Allocation関数を1回、GroupDC_Mapping関数を1+N回、DC_Selection関数を10×(1+N)回以上）。Nはオペレータ等が任意に設定可能なパラメータである。
（分類１）オフライン割当として、グループ数＝10がいっぺんに与えられる場合は、以下の通りである。
（分類１）で貪欲法だけを実行する場合は、Greedy_Allocation関数を1回、GroupDC_Mapping関数を1回、DC_Selection関数を10回以上実行する。なお、DC_Selection関数を呼び出す回数が10回を超える場合は、ユーザの遅延要件を満たせるDCがなかった場合（L20行目の返り値が∞となった場合）に、L23行目に移って再びDC_Selection関数が呼び出される場合である。
（分類１）で貪欲法と局所探索とを併せて実行する場合は、Greedy_Allocation関数を１回実行した後、GroupDC_Mapping関数およびDC_Selection関数をワンセットとしてN回繰り返す（Greedy_Allocation関数を1回、GroupDC_Mapping関数を1+N回、DC_Selection関数を10×(1+N)回以上）。Nはオペレータ等が任意に設定可能なパラメータである。
（分類２）バッチ割当として、グループ数＝10が、「グループ数＝5」→「グループ数＝3」→「グループ数＝2」の順に３段階で与えられる場合は、以下の通りである。
（分類２）で貪欲法だけを実行する場合は、以下のようになる。
・Greedy_Allocation関数を1回（グループ数5のとき）＋1回（グループ数3のとき）＋1回（グループ数2のとき）で計3回実行する。
・GroupDC_Mapping関数を1回（グループ数5のとき）＋1回（グループ数3のとき）＋1回（グループ数2のとき）で計3回実行する。
・DC_Selection関数を5回以上（グループ数5のとき）＋3回以上（グループ数3のとき）＋2回以上（グループ数2のとき）で計10回以上実行する。
（分類２）で貪欲法だけを実行する場合は、以下のようになる。
・Greedy_Allocation関数を1回（グループ数5のとき）＋1回（グループ数3のとき）＋1回（グループ数2のとき）で計3回実行する。
・GroupDC_Mapping関数を1回（グループ数5のとき）＋1回（グループ数3のとき）＋1回（グループ数2のとき）で計3回実行する。
・DC_Selection関数を5回以上（グループ数5のとき）＋3回以上（グループ数3のとき）＋2回以上（グループ数2のとき）で計10回以上実行する。
（分類２）で貪欲法と局所探索とを併せて実行する場合は、Greedy_Allocation関数を各１回ずつ行った後、GroupDC_Mapping関数およびDC_Selection関数をワンセットとして各バッチ処理時にN回ずつ繰り返すことになるため、以下のようになる。
・Greedy_Allocation関数を各1回ずつ計3回実行する。
・GroupDC_Mapping関数を各(1+N)ずつ×3回実行する。
・DC_Selection関数を5×(1+N)回以上＋3×(1+N)回以上＋2×(1+N)回以上で計10×(1+N)回以上実行する。
・Greedy_Allocation関数を各1回ずつ計3回実行する。
・GroupDC_Mapping関数を各(1+N)ずつ×3回実行する。
・DC_Selection関数を5×(1+N)回以上＋3×(1+N)回以上＋2×(1+N)回以上で計10×(1+N)回以上実行する。
（分類３）オンライン割当として、グループ数＝10が１つずつ与えられる場合は、以下のようになる。
（分類３）で貪欲法だけを実行する場合は、DC_Selection関数を1回or2回ずつ10回呼び出されるため計10回以上実行する。
（分類３）で貪欲法と局所探索とを併せて実行することは不可である。1つのグループしかない場合は、割当順序が関係ないため、局所探索をおこなう余地がないためである。
（分類３）で貪欲法だけを実行する場合は、DC_Selection関数を1回or2回ずつ10回呼び出されるため計10回以上実行する。
（分類３）で貪欲法と局所探索とを併せて実行することは不可である。1つのグループしかない場合は、割当順序が関係ないため、局所探索をおこなう余地がないためである。
［効果］
本発明のリソース割当装置２は、複数のユーザ端末４から構成されるグループごとのステートをグループ内で共有させるためのステート管理部５を、分散クラウド環境８に配備された複数のＤＣ３のうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部２１と、
グループが要求する要件に応じた割当指標を用いて、ステート管理部５を各ＤＣ３に割り当てるときの割当コストを計算し、その割当コストに従ってステート管理部５の割当先のＤＣ３を決定する割当計算部２３とを有することを特徴とする。
本発明のリソース割当装置２は、複数のユーザ端末４から構成されるグループごとのステートをグループ内で共有させるためのステート管理部５を、分散クラウド環境８に配備された複数のＤＣ３のうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部２１と、
グループが要求する要件に応じた割当指標を用いて、ステート管理部５を各ＤＣ３に割り当てるときの割当コストを計算し、その割当コストに従ってステート管理部５の割当先のＤＣ３を決定する割当計算部２３とを有することを特徴とする。
これにより、グループのメンバであるユーザ端末４が、そのグループでステート管理部５を共有して行うアプリケーションに適した割当先にステート管理部５を割り当てることができる。よって、複数のユーザが形成したグループごとの要件に沿ったリソース割当を行うことができる。
本発明は、割当計算部２３が、グループを構成する各ユーザ端末４とＤＣ３との間の遅延時間を求め、それらの求めた遅延時間の平均遅延をステート管理部５の割当指標とすることを特徴とする。
これにより、サバイバルゲームなどの多人数が参加するアプリケーションにおいて、その多数が満足する割当先を発見できる。
本発明は、割当計算部２３が、グループを構成する各ユーザ端末４とＤＣ３との間の遅延時間を求め、それらの求めた遅延時間の最大遅延をステート管理部５の割当指標とすることを特徴とする。
これにより、対戦格闘ゲームなどのグループに属するすべてのユーザの通信で厳密な同期を要するアプリケーションに適した割当先を発見できる。
本発明は、割当計算部２３が、グループを構成する各ユーザ端末４とＤＣ３との間の遅延時間を求め、それらの求めた遅延時間の分散または標準偏差をステート管理部５の割当指標とすることを特徴とする。
これにより、レースゲームなどのユーザ間のプレイ環境の公平性が特に求められるリアルタイムアプリケーションに適した割当先を発見できる。
本発明は、割当計算部２３が、リクエスト受信部２１が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法を用いた近似アルゴリズムにより、各グループの割当先を計算することを特徴とする。
これにより、組み合わせ最適化問題に対して総当たり計算よりも少ない計算量で、妥当な割当先を計算することができる。
本発明は、割当計算部２３が、リクエスト受信部２１が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法と局所探索法とを併用する近似アルゴリズムにより、各グループの割当先を計算することを特徴とする。
これにより、貪欲法を単独で用いる場合と比べて、さらに良い割当先を発見する可能性が高まる。
１ サービス提供装置
２ リソース割当装置
３ ＤＣ（データセンタ）
４ ユーザ端末
５ ステート管理部
８ 分散クラウド環境
９ オンラインシステム
２１ リクエスト受信部
２２ NWデータ収集部
２３ 割当計算部
２４ 制御部
２ リソース割当装置
３ ＤＣ（データセンタ）
４ ユーザ端末
５ ステート管理部
８ 分散クラウド環境
９ オンラインシステム
２１ リクエスト受信部
２２ NWデータ収集部
２３ 割当計算部
２４ 制御部
Claims (8)
- 複数のユーザ端末から構成されるグループごとのステートをグループ内で共有させるためのステート管理部を、分散クラウド環境に配備された複数のデータセンタのうちのいずれかに割り当てる旨のリクエストを受信するリクエスト受信部と、
前記グループが要求する要件に応じた割当指標を用いて、前記ステート管理部を前記各データセンタに割り当てるときの割当コストを計算し、その割当コストに従って前記ステート管理部の割当先の前記データセンタを決定する割当計算部とを有することを特徴とする
リソース割当装置。 - 前記割当計算部は、グループを構成する前記各ユーザ端末と前記データセンタとの間の遅延時間を求め、それらの求めた遅延時間の平均遅延を前記ステート管理部の割当指標とすることを特徴とする
請求項１に記載のリソース割当装置。 - 前記割当計算部は、グループを構成する前記各ユーザ端末と前記データセンタとの間の遅延時間を求め、それらの求めた遅延時間の最大遅延を前記ステート管理部の割当指標とすることを特徴とする
請求項１に記載のリソース割当装置。 - 前記割当計算部は、グループを構成する前記各ユーザ端末と前記データセンタとの間の遅延時間を求め、それらの求めた遅延時間の分散または標準偏差を前記ステート管理部の割当指標とすることを特徴とする
請求項１に記載のリソース割当装置。 - 前記割当計算部は、前記リクエスト受信部が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法を用いた近似アルゴリズムにより、各グループの割当先を計算することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のリソース割当装置。 - 前記割当計算部は、前記リクエスト受信部が受信したリクエストの各グループの割当コストの総和を最小化する組み合わせ最適化問題に対して、貪欲法と局所探索法とを併用する近似アルゴリズムにより、各グループの割当先を計算することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のリソース割当装置。 - リソース割当装置は、リクエスト受信部と、割当計算部とを有しており、
前記リクエスト受信部は、複数のユーザ端末から構成されるグループごとのステートをグループ内で共有させるためのステート管理部を、分散クラウド環境に配備された複数のデータセンタのうちのいずれかに割り当てる旨のリクエストを受信し、
前記割当計算部は、前記グループが要求する要件に応じた割当指標を用いて、前記ステート管理部を前記各データセンタに割り当てるときの割当コストを計算し、その割当コストに従って前記ステート管理部の割当先の前記データセンタを決定することを特徴とする
リソース割当方法。 - コンピュータを、請求項１ないし請求項６のいずれか１項に記載のリソース割当装置として機能させるためのリソース割当プログラム。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2021/005175 WO2022172389A1 (ja) | 2021-02-12 | 2021-02-12 | リソース割当装置、リソース割当方法、および、リソース割当プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2022172389A1 JPWO2022172389A1 (ja) | 2022-08-18 |
| JP7537528B2 true JP7537528B2 (ja) | 2024-08-21 |
Family
ID=82838538
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022581105A Active JP7537528B2 (ja) | 2021-02-12 | 2021-02-12 | リソース割当装置、リソース割当方法、および、リソース割当プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20240126612A1 (ja) |
| JP (1) | JP7537528B2 (ja) |
| WO (1) | WO2022172389A1 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115412563B (zh) * | 2022-08-22 | 2024-03-22 | 西南交通大学 | 一种边缘设备资源分配方法、装置、设备及可读存储介质 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI98973C (fi) * | 1994-11-22 | 1997-09-10 | Nokia Telecommunications Oy | Menetelmä ryhmätietojen ylläpitämiseksi matkaviestinjärjestelmässä ja matkaviestinjärjestelmä |
| US8370490B2 (en) * | 2010-07-01 | 2013-02-05 | International Business Machines Corporation | Cloud service cost-optimal data center assignment |
| US8869157B2 (en) * | 2012-06-21 | 2014-10-21 | Breakingpoint Systems, Inc. | Systems and methods for distributing tasks and/or processing recources in a system |
| US11086723B2 (en) * | 2019-01-31 | 2021-08-10 | Rubrik, Inc. | Distributed streaming parallel database restores |
| US10838759B2 (en) * | 2019-02-04 | 2020-11-17 | Verizon Patent And Licensing Inc. | Elastic container platform architecture |
| US11650851B2 (en) * | 2019-04-01 | 2023-05-16 | Intel Corporation | Edge server CPU with dynamic deterministic scaling |
| US11010195B2 (en) * | 2019-07-19 | 2021-05-18 | International Business Machines Corporation | K-tier architecture scheduling |
| US12443831B1 (en) * | 2020-01-23 | 2025-10-14 | Nvidia Corporation | Neural network execution streams |
| US11593112B2 (en) * | 2020-03-06 | 2023-02-28 | Microsoft Technology Licensing, Llc | Automated runtime configuration for dataflows |
| US12530237B2 (en) * | 2020-09-17 | 2026-01-20 | Ntt, Inc. | Device, system, method, and computer program product for dynamic workload offloading and accelerator allocation |
| US20230109096A1 (en) * | 2020-12-18 | 2023-04-06 | Strong Force Vcn Portfolio 2019, Llc | Maintenance Prediction and Health Monitoring for Robotic Fleet Management |
| US11200096B1 (en) * | 2021-03-26 | 2021-12-14 | SambaNova Systems, Inc. | Resource allocation for reconfigurable processors |
-
2021
- 2021-02-12 JP JP2022581105A patent/JP7537528B2/ja active Active
- 2021-02-12 US US18/276,474 patent/US20240126612A1/en active Pending
- 2021-02-12 WO PCT/JP2021/005175 patent/WO2022172389A1/ja not_active Ceased
Non-Patent Citations (1)
| Title |
|---|
| 佐藤諒平ほか，ＩＣＮにおける低コストなキャッシュ配置最適化手法の一検討，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，2020年02月27日，Ｖｏｌ．１１９ Ｎｏ．４６０，４５５～４６０ページ |
Also Published As
| Publication number | Publication date |
|---|---|
| JPWO2022172389A1 (ja) | 2022-08-18 |
| US20240126612A1 (en) | 2024-04-18 |
| WO2022172389A1 (ja) | 2022-08-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111400001B (zh) | 一种面向边缘计算环境的在线计算任务卸载调度方法 | |
| CN111669444A (zh) | 基于边缘计算的云游戏服务质量增强方法及系统 | |
| KR102352375B1 (ko) | 유전 알고리즘 기반의 엣지 컴퓨팅 최적화 장치 및 방법 | |
| US20100113159A1 (en) | Method and apparatus for partitioning virtual worlds using prioritized topic spaces in virtual world systems | |
| CN116319522B (zh) | 一种算力网络中的多路径转发方法及系统 | |
| Jia et al. | Delay-sensitive multiplayer augmented reality game planning in mobile edge computing | |
| CN117640413B (zh) | 雾计算中基于强化学习的微服务和数据库联合部署方法 | |
| US20210006459A1 (en) | Network and Method for Servicing a Computation Request | |
| CN113742048B (zh) | 一种酒店云服务系统及其服务方法 | |
| Lakshmi et al. | An adaptive multi-cloud offloading using hierarchical game-theoretic approach | |
| CN111211984A (zh) | 优化cdn网络的方法、装置及电子设备 | |
| Aloqaily et al. | Trustworthy cooperative UAV-based data management in densely crowded environments | |
| CN114638415A (zh) | 一种基于Geohash索引的实时空间众包任务分配方法 | |
| JP2017037445A (ja) | サーバ管理装置およびサーバ管理方法 | |
| CN116668354B (zh) | 一种基于数字孪生的sdn路由优化方法 | |
| WO2022172389A1 (ja) | リソース割当装置、リソース割当方法、および、リソース割当プログラム | |
| Zou et al. | A multipath routing approach for tile-based virtual reality video streaming based on sdn | |
| CN118394486B (zh) | 一种算力网络任务调度方法及装置 | |
| CN116633932B (zh) | 一种云计算资源池动态调度系统 | |
| CN118796443A (zh) | 资源调度方法、装置与系统、电子设备、存储介质与产品 | |
| Kumari et al. | QoS CBSC: an enhanced metaheuristic strategy on QoS-cloud-based service in cloud | |
| Morillo et al. | An ACS-based partitioning method for distributed virtual environment systems | |
| Morillo et al. | A comparison study of modern heuristics for solving the partitioning problem in distributed virtual environment systems | |
| CN114466385B (zh) | 基于用户移动感知的无缝服务迁移方法及计算机系统 | |
| Selvakumar et al. | A novel approach in load balancing for dynamic cloud environment using ACO |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230612 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20240709 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20240722 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7537528 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |