Some content of this application is unavailable at the moment.
If this situation persist, please contact us atFeedback&Contact
1. (WO2018220708) RESOURCE ALLOCATION SYSTEM, MANAGEMENT DEVICE, METHOD, AND PROGRAM
Document

明 細 書

発明の名称 資源割当システム、管理装置、方法およびプログラム

技術分野

0001  

背景技術

0002   0003   0004   0005   0006  

先行技術文献

特許文献

0007  

発明の概要

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

0008   0009   0010   0011   0012   0013  

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

0014   0015   0016   0017  

発明の効果

0018  

図面の簡単な説明

0019  

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

0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   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   0122   0123   0124   0125   0126   0127  

産業上の利用可能性

0128  

符号の説明

0129  

請求の範囲

1   2   3   4   5   6   7   8   9   10   11   12   13  

図面

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18  

明 細 書

発明の名称 : 資源割当システム、管理装置、方法およびプログラム

技術分野

[0001]
 本発明は、所定の機能をサービスとして提供する1つ以上の機能単位に資源を割り当てる資源割当システム、管理装置、資源割当方法および資源割当プログラムに関する。

背景技術

[0002]
 サービス提供側において、障害が起きた場合や悪意のある装置等が存在する場合であっても、正規のユーザに対してサービスを継続的に提供したいという要求がある。そのため、そのようなサービス提供基盤が所望されている。
[0003]
 サービス提供アーキテクチャの1つに、マイクロサービスアーキテクチャ(micro service architecture,以下、MSAという)がある。MSAは、一枚岩(モノリシック)なソフトウェアアーキテクチャを細かく分割して、結合度の低い機能単位の集まりとし、それらを連携させることによって同等のサービスを提供するアーキテクチャである。MSAは、サービス提供に必要な機能を独立して扱えるので、開発およびデプロイの迅速化や、優れた回復性、スケーラビリティを実現できるというメリットがある。
[0004]
 図16は、マイクロサービスを利用したサービス提供プログラムの例を示す説明図である。図16に示す例は、ユーザからのサービスリクエストをフロントエンドサービスが受け付け、後段のマイクロサービスに適宜処理を実行させ、その処理連携により、該ユーザにサービスを提供するアーキテクチャの例である。マイクロサービスの例としては、認証サービス、アクセス許可、データの管理(更新、削除、抽出)、レコメンデーションなどが挙げられる。MSAは、クラウド上でサービスを提供する際のアーキテクチャとして利用されている。
[0005]
 以下、このような複数の機能単位を連携させてサービスを提供するサービスシステムにおける資源管理を考える。図17は、MSAにおける資源管理方法の例を示す説明図である。MSAでは、例えば、管理エンティティが、各マイクロサービスにおける資源の使用状況をモニタリングし、あるマイクロサービスの資源使用率等が基準を上回った場合に、新たに資源を割り当てる。また、管理エンティティは、あるマイクロサービスの資源使用率等が基準を下回った場合に、資源を解放する。ここで、資源の割り当ては、該当するマイクロサービスのインスタンスを複製することであってもよい。また、資源の解放は、該当するマイクロサービスのインスタンスを削除することであってもよい。また、マイクロサービス自身が資源使用状況を判断して資源割当要求を管理エンティティに送信する場合もある。
[0006]
 また、特許文献1には、分散環境下における個々のユーザ(ホストコンピュータ)の要求に基づいて、資源の輻輳状態に対応した動的な適応性をもった資源配分制御を行う方法が記載されている。

先行技術文献

特許文献

[0007]
特許文献1 : 特開平11-66018号公報

発明の概要

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

[0008]
 課題は、個々の機能単位の資源使用状況や要求に対して、各リソースサーバが自身の資源の残量に基づいて単純に資源を割り当てるだけでは、適切な資源の割り当てができず、機能単位間で不均衡な割り当てとなることにある。特に、以下で割り当て応答速度と呼ぶ、割当頻度や1回の割当量が適切でない場合には、機能単位間で資源の割り当てに不均衡が生じるおそれがある。
[0009]
 図18は、MSAにおける資源の割り当て応答速度の例を示す説明図である。図18は、リソースサーバの資源が限られている場合において、ユーザ数の増加等に伴い、資源割当要求がフロントエンド側から順番に発生する状況における資源の割り当ての例を示している。ここで、ユーザに要求されたサービスを提供するためには、フロントエンドサービスX、マイクロサービスA、マイクロサービスB、マイクロサービスCの順で処理が必要であるとする。このとき、サービスが輻輳状態にない場合からユーザ数が増加すると、まずフロントエンドサービスXが資源不足となり、リソースサーバに資源割当要求を行う。資源が割り当てられた結果、フロントエンドサービスXが要求を処理可能になると、次に呼び出されるマイクロサービスAが輻輳状態となり、資源不足となる。そこで、マイクロサービスAがリソースサーバに資源割当要求を行う。
[0010]
 このとき、リソースサーバが資源に余裕がない状態で個々の機能単位からの資源割当要求に応じて要求量を即座に割り当てると、フロントエンド側で資源を使い果たしてしまう。すると、次に輻輳状態となるマイクロサービスBから資源割当要求が来たとしても、割り当て可能な資源がなく、資源を割り当てることができない。結果として、機能単位間で資源の不均衡が生じてしまう。また、本例の場合、マイクロサービスCの処理まで完了しないとユーザへのサービスは完了しないため、フロントエンド側に資源を多く割り当てた結果、サービス提供が失敗する結果となる。
[0011]
 このような資源の偏重を抑制する方法として、例えば、リソースサーバが、受け付けた要求に対して要求量を即座に割り当てずに一定時間待ち、その間に貯まった要求群を基に割当量や優先順位などを決定することが考えられる。しかし、MSAのような機能単位間の独立性が高いサービスシステムの場合、実際に資源を割り当ててサービス処理を実行してからでないと、次にどのサービスが混雑するのかがわからない場合が多い。したがって、要求をバッファリングするだけでは上記問題を解決できない。なお、リソースサーバが、即座に要求量の一部のみを先に割り当てることも考えられるが、機能単位間の結合度が弱いシステムでは、どれだけの速さでどれだけの量を割り当てればよいかを、個々のリソースサーバが現在認識している要求だけで判断するのは困難である。
[0012]
 また、その一方で、リソースサーバに資源が十分ある場合には、資源が不足している機能単位に対して、即座に要求量の資源を割り当てたいという要望もある。このように、適切な応答速度はリソースサーバの資源の利用状況によっても変化する。
[0013]
 本発明は、上述した課題に鑑みて、1つ以上の機能単位を連携させてサービスを提供するサービスシステムにおいて、該機能単位に対し資源を割り当てる場合であっても、機能単位間での資源割り当ての不均衡を抑制できる資源割当システム、管理装置、資源割当方法および資源割当プログラムを提供することを目的とする。

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

[0014]
 本発明による資源割当システムは、所定の機能をサービスとして提供する1つ以上の機能単位に、サービスを実行するための資源を割り当てる資源割当部と、資源を提供する2以上の資源提供部と、2以上の資源提供部のうちの所定の資源提供部から余り資源量を取得する余り資源量取得部と、余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定するパラメータ決定部とを備えたことを特徴とする。
[0015]
 また、本発明による管理装置は、所定の機能をサービスとして提供する1つ以上の機能単位に割り当てる資源を提供する2以上の資源提供部が提供する資源の管理単位として設けられる複数のデータセンタのいずれかに配置される管理装置であって、機能単位に、自データセンタの管理対象の資源より資源を割り当てる資源割当部と、管理対象の資源提供部から余り資源量を取得する余り資源量取得部と、2以上の資源提供部における資源の割当状況を管理する割当状況管理部であって、他のデータセンタに配置された割当状況管理部との間で、所定のコンセンサス処理を経てデータセンタのいずれかに対する資源割当要求に基づく割当に関する割当情報を含むブロックが追加されるブロックチェーンを共有することにより、割当状況を管理する割当状況管理部と、余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定するパラメータ決定部とを備え、資源割当部は、パラメータ決定部による決定に基づいて行われるコンセンサス処理の結果、ブロックチェーンに記録された情報に基づいて、資源の割り当てを行うことを特徴とする。
[0016]
 また、本発明による資源割当方法は、情報処理装置が、所定の機能をサービスとして提供する1つ以上の機能単位に割り当てる資源を提供する2以上の資源提供部のうちの所定の資源提供部から余り資源量を取得し、余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定することを特徴とする。
[0017]
 また、本発明による資源割当プログラムは、コンピュータに、所定の機能をサービスとして提供する1つ以上の機能単位に割り当てる資源を提供する2以上の資源提供部のうちの所定の資源提供部から余り資源量を取得する処理、および余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定する処理を実行させることを特徴とする。

発明の効果

[0018]
 本発明によれば、1つ以上の機能単位を連携させてサービスを提供するサービスシステムにおいて、該機能単位に対し資源を割り当てる場合であっても、機能単位間での資源割り当ての不均衡を抑制できる。

図面の簡単な説明

[0019]
[図1] 第1の実施形態の概要を示す説明図である。
[図2] 第1の実施形態の資源割当システム100の構成例を示すブロック図である。
[図3] 第1の実施形態の資源割当システム100の動作例を示すフローチャートである。
[図4] ブロックチェーンのデータ構造の例を示す説明図である。
[図5] 台帳管理システム4が備える台帳管理ノード42の例を示すブロック図である
[図6] 第2の実施形態の概要を示す説明図である。
[図7] 第2の実施形態の資源割当システム100の構成例を示すブロック図である。
[図8] 第2の実施形態のDC3の動作例を示すフローチャートである
[図9] マイニングブロックに含ませる要求の選択方法の例を示す説明図である。
[図10] マイニングブロックに含ませる要求の選択方法の他の例を示す説明図である。
[図11] マイニングパラメータの決定方法の例を示す説明図である。
[図12] 割当可能量の制御例を示す説明図である。
[図13] 本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。
[図14] 本発明の資源割当システムの概要を示すブロック図である。
[図15] 本発明の資源割当システムの他の構成例を示すブロック図である。
[図16] マイクロサービスを利用したサービス提供プログラムの例を示す説明図である。
[図17] MSAにおける資源管理方法の例を示す説明図である。
[図18] MSAにおける資源の割り当て応答速度の例を示す説明図である。

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

[0020]
 以下、本発明の実施形態を、図面を参照して説明する。図1は、第1の実施形態の概要を示す説明図である。図1に示すように、本実施形態の資源割当システム100は、リソースサーバ2からそれぞれ余り資源量を収集し、収集した余り資源量に基づいて、機能単位1に対して資源の割り当てを行う。このとき、資源割当システム100は、余り資源量に基づいて、資源の割り当ての応答速度(具体的には、割当タイミング、1回の割当可能量等)を決定し、その決定に基づいて資源の割り当てを行う。
[0021]
 ここで、機能単位1は、上記のマイクロサービスなど、サービス提供のための所定の機能を実装し、要求に応じて該機能を提供する独立したユニットである。なお、機能単位1は、独立した装置に限らず、該機能を提供するプログラムであってもよい。すなわち、1つのサーバや仮想化基盤に複数の機能単位1が実装されていてもよい。そのような場合であっても、各々の機能単位1は独立したユニットであるとみなす。また、本発明では、機能単位が提供する機能もサービスの1つとみなす。
[0022]
 図2は、本実施形態の資源割当システム100の構成例を示すブロック図である。図2に示す資源割当システム100は、資源利用状況管理部101と、利用状況取得部102と、パラメータ決定部103と、資源割当部104とを備える。
[0023]
 資源利用状況管理部101は、割り当て対象とされる資源を管理する1つ以上のリソースサーバ2における資源の利用状況を管理(収集、保持)する。ここで、資源利用状況管理部101が管理する資源の利用状況は、リソースサーバ2の各々の余り資源量を含む。なお、さらに、過去の割当状況(どの機能単位1にどれだけ割り当てたか等)が含まれていてもよい。
[0024]
 利用状況取得部102は、資源利用状況管理部101からリソースサーバ2の各々の資源の利用状況を取得する。取得のタイミングは特に問わないが、例えば、一定の周期ごと、資源割当要求を受信したとき、資源割当要求を受信した後一定時間経過後などの所定のタイミングでよい。
[0025]
 パラメータ決定部103は、利用状況取得部102が取得したリソースサーバ2の各々の資源の利用状況を基に、資源割当パラメータを決定する。ここで、資源割当パラメータには、資源の割当頻度と、1回の割当可能量とが含まれる。なお、資源割当パラメータは、いずれか一方であってもよい。その場合、他方は予め決められた値を用いる。また、割当頻度は、資源割当部104における割り当て制御を行うタイミングである割当タイミングを定めるものであれば特に問わない。例えば、割当頻度は、単位時間あたりの割当可能回数であってもよいし、割当間隔であってもよい。また、資源割当パラメータには、さらに、要求に対する優先順序に関するルール(以下、割当順序ルールという)が含まれていてもよい。
[0026]
 資源割当部104は、パラメータ決定部103が決定した資源割当パラメータに基づいて、機能単位1に資源を割り当てる。資源割当部104は、例えば、要求バッファに既にあるまたはこれから受信する資源割当要求に対して、資源割当パラメータが示す割当頻度で、かつ割当可能量の範囲内で、資源を割り当てる。
[0027]
 なお、要求バッファに既に存在する要求元からの資源割当要求を再度受信したときは、受信した資源割当要求またはバッファ内の資源割当要求のいずれかを破棄してもよい。
[0028]
 次に、本実施形態の動作を説明する。図3は、本実施形態の資源割当システム100の動作例を示すフローチャートである。図3に示す例では、まず、資源利用状況管理部101が、リソースサーバ2の各々から資源の利用状況として余り資源量を収集する(ステップS101)。
[0029]
 次いで、パラメータ決定部103が、取得された余り資源量に基づいて、資源割当パラメータを決定する(ステップS102)。
[0030]
 次いで、資源割当部104が、資源割当パラメータに基づいて、機能単位1に対して資源を割り当てる(ステップS103)。
[0031]
 ステップS102において、パラメータ決定部103は、リソースサーバ全体において資源に余裕がない場合には、以下に示すような省資源ポリシに基づき、資源割当パラメータを決定してもよい。また、パラメータ決定部103は、例えば、リソースサーバ全体において資源に余裕がある場合には、以下に示すような高性能ポリシに基づき、資源割当パラメータを決定してもよい。ここで、資源に余裕があるか否かは、例えば、余り資源量の合計が所定の閾値以上か否かや、全資源量に対して所定の割合以上か否かで判定してもよい。
[0032]
[省資源ポリシ]
・割当頻度を低くする
 制御例:優先度が低い要求を破棄
 制御例:要求量が少ない要求を優先
・1回の割当可能量を少なくする
[0033]
[高性能ポリシ]
・1回の割当可能量を多くする
・割当頻度を高くするまたは即座に割当可能とする
[0034]
 なお、資源割当パラメータは、リソースサーバ全体に対して設定してもよいし、リソースサーバ2の各々に対して設定してもよい。後者の場合、パラメータ決定部103は、全体の余り資源量に対する対象のリソースサーバ2の余り資源量の割合を考慮して、ポリシを選択するなどして、資源割当パラメータを決定してもよい。
[0035]
 また、パラメータ決定部103は、既に要求を受け付けている場合であって、要求に対して優先度が付与されている場合には、さらに要求の優先度に基づいて、資源割当パラメータを決定することも可能である。例えば、パラメータ決定部103は、優先度が高い要求程、短時間で割り当てられるようにしてもよい。また、パラメータ決定部103は、まず割当頻度を決定し、次に、予想される資源割り当てまでにかかる時間(割当所要時間)に応じて、1回の割当可能量を決定することも可能である。すなわち、割当所要時間が多ければ1回の割当可能量を増やしたり、割当所要時間が少なければ1回の割当可能量を減らすなどの調整を行ってもよい。
[0036]
 また、パラメータ決定部103は、さらに過去の割当状況を基に、過去の割当頻度が低い機能単位に優先して資源を割り当てるよう、割当順序ルールを決定してもよい。
[0037]
 例えば、本実施形態の資源割当システム100は、機能単位1から直接要求された場合に限らず、図17に示すような管理エンティティが、機能単位1の資源の使用状況をモニタリングした結果、資源使用率が閾値を超えたと判断した際に発行される資源割当要求に対して、上記の動作を行うことも可能である。なお、資源割当システム100が管理エンティティとして、各機能単位から資源の使用状況をモニタリングし、資源を割り当てることも可能である。
[0038]
 このような場合においても、資源割当システム100は、資源使用率が閾値を超えた機能単位1に対して、リソースサーバ2から取得した余り資源量に応じて定められる割当可能量を超えない範囲で資源を割り当てる。なお、割当可能量は、余り資源が少ないほど小さくなるものとする。なお、割当可能量を生成可能なインスタンス数としてもよい。
[0039]
 また、資源割当システム100は、資源使用率が閾値を超えた機能単位1に対して、リソースサーバ2から取得した余り資源量に応じて定められる割当可能インターバルを基に、資源を割り当てる。例えば、資源割当システム100は、資源を割り当てる際、前回割り当てを行った時から割当可能インターバルが経過するまでの間は、資源の割り当てを保留してもよい。
[0040]
 割当頻度の別の制御方法として、資源割当システム100は、資源割当要求に対して、確率的な遅延を設けることができる。すなわち、資源割当システム100は、受信した資源割当要求に対し、ある決められた値を平均とする確率分布(以下、遅延分布)を定め、資源割当要求ごとに当該確率分布に従って定められる遅延を設定することができる。このとき、資源割当部104は、設定された遅延時間経過後に、該資源割当要求に対して資源を割り当てる。また、別の確率的な遅延を設ける方法として、資源割当システム100は、一定時間ごとに確率的に資源を割り当てるか否かを決定することができる。この場合、資源割当部104は、一定時間ごとに、要求バッファにある一つ以上の資源割当要求に対して、当該資源割当要求ごとに定められる確率(以下、資源割当確率)で資源を割り当てるかを決定する。こうすることで、確率的に遅延を設けることができる。
[0041]
 資源割当要求に対して確率的な遅延を設ける場合、その遅延分布または遅延割当確率は資源割当要求ごとに決めることができ、過去の割当状況や資源割当要求の要求度等に基づいて決定することができる。また、これらの資源割当要求ごとに定められる遅延分布または資源割当確率は省資源ポリシや高性能ポリシなどのポリシに基づいて定めることができる。例えば、省資源ポリシの場合は、遅延の平均値が大きくなるような遅延分布としたり、資源割当確率を小さく設定してもよい。逆に、高性能ポリシの場合は、遅延の平均値が小さくなるような遅延分布としたり、資源割当確率を大きく設定してもよい。
[0042]
 以上のように、本実施形態によれば、機能単位同士の関係性が不透明なサービスシステムに対して資源を割り当てる場合であっても、余り資源量や過去の割当状況に合わせて、資源の割り当ての応答速度を適切にできる。その結果、例えば、フロントエンドサービス側に資源が偏重して、後段の機能単位でサービスが混雑する前に資源が枯渇するなどといった機能単位間での資源割り当ての不均衡を抑制できる。
[0043]
実施形態2.
 次に、本発明の第2の実施形態を説明する。本実施形態では、例えば地理的に点在する複数の資源管理単位としてのデータセンタ(DC)間のネットワークが分断されても、他のDCを利用してサービスを継続できるようにする。このため、本実施形態では、複数のデータセンタにまたがって資源割り当てを行うことができるようにする。さらに、データセンタ間のネットワークが分断されてもサービスが継続できるよう、集中管理エンティティを置かない構成をとる。
[0044]
 より具体的に、本実施形態の資源割当システムは、ブロックチェーン技術を利用した分散台帳システムにおける分散的にコンセンサスを取る仕組みと、それによる共有情報保持機構とを利用して、データセンタ間で、要求に基づく割り当てに関する情報や、過去の割り当て状況の共有を行う。
[0045]
 まず、ブロックチェーン技術について簡単に説明する。ブロックチェーン技術は、特定の集中管理サーバに依存せず、分散的に情報共有を行うことができるアーキテクチャである。分散台帳システムに参加している各端末(後述する台帳管理ノード42)が、ブロックチェーンにブロックを追加する際に所定のコンセンサスアルゴリズムに従う処理(以下、コンセンサス処理という)を行うことにより、改ざんが困難なブロックチェーンを端末間で共有する。
[0046]
 図4は、ブロックチェーン41のデータ構造の例を示す説明図である。図4に示すように、ブロックチェーン41は、ブロックと呼ばれる所定のデータ構造を備えたデータを繋げた構成をとる。また、ブロックの各々は、前のブロックのハッシュ値(図中の“Hash x”)、ノンス(図中の“nonce x”)、当該ブロックに格納するデータ(図中の“data x”)を含む。ここで、“x”はブロックを識別する識別子を表している。例えば、ブロックnは、ブロックn-1のハッシュ値と、ノンスnと、データnとを含む。なお、データnは、取引情報など、任意のデータでよい。
[0047]
 このような改ざんが困難なブロックチェーン41を台帳として利用して、取引明細等のデータ、アプリケーション情報、その他の管理情報、認証情報といった情報を保持させることにより、情報の検証等に利用できる。
[0048]
 ここで、ノンスは、当該ブロックチェーン41の改ざん耐性に影響する検証情報であり、具体的には、PoW(Proof of Work)と呼ばれるコンセンサスアルゴリズムを実行する過程で設定される検証情報としての役割を持つ。
[0049]
 PoWでは、あるデータについて、そのデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように、当該データ内に含まれるノンス領域に設定する値を探す処理(以降、単にノンスを探す処理と呼ぶ)が行われる。
[0050]
 このとき、一方向性関数として、例えば、ハッシュ関数を用いることができる。また、そのときの規則を、「ハッシュ値が閾値(ターゲット値)以下であること」とすることができる。一般に、ノンスを探す処理は一方向性関数の性質から効率良く行うことができないため、当該処理を行う装置は、実際にはノンスに適当な値を設定して規則を満たすか否かを確認する作業を繰り返すこととなる。このような設定と確認の作業を多くのノードに並列して行わせ、最も早く規則を満たすノンスを見つけたノードが他のノードに情報を発信することにより、当該情報に基づいて全ノードに当該ノンスの値を含むデータの状態を確定させる(コンセンサスをとる)。
[0051]
 次に、そのようなブロックチェーン41における一般的なブロック追加の流れを説明する。ブロックは、例えば、以下の(1)~(5)のような動作が行われることにより、ブロックチェーン41に追加される。
[0052]
(1)ブロックチェーン41に情報を記録したい端末は、該情報を当該ブロックチェーン41に参加している端末のいずれかまたはその全てに通知する。
(2)各端末は通知された情報の整合性をチェックし、問題がなければブロックを生成する。
(3)各端末は生成されたブロックについてPoWを開始する。
(4)PoWを終了した端末は、当該PoWで発見されたノンスを設定したブロックを全ての端末に通知する。
(5)ノンスが設定されたブロックを通知された端末は、ハッシュ値や、ブロックに記憶されている情報の整合性をチェックし、問題なければ自身が管理しているブロックチェーン41の末尾にブロックを追加する。
[0053]
 なお、上記の(2)の動作において、通知された情報の整合性のチェック方法は、当該ブロックチェーン41を利用するアプリケーションに依存する。また、ブロックを生成する際に、複数の情報を1つのブロックにまとめることが可能である。
[0054]
 また、上記の(3)のPoW動作において、各端末は、さらに次の動作を行う。
(3-1)各端末は、まず生成したブロックにランダムなノンス(ノンスの候補)を設定する。
(3-2)次いで、各端末は、ブロックのハッシュ値が所定の規則を満たすか(例えば、あるターゲット値以下であるか)を確認する。
(3-3)規則を満たしていれば、処理を終了し、満たしていなければ、設定したノンスを変更し、(3-2)に戻る。
[0055]
 なお、情報が通知された全ての端末が上記の(3)のPoW動作を同時に平行して行う。そして、PoWを最も早く終了した端末は、ブロックチェーン41にブロックを追加する権利を得た端末とみなされる。
[0056]
 図5は、台帳管理システム4が備える台帳管理ノード42の例を示すブロック図である。台帳管理システム4は、2以上の台帳管理ノード42(図示省略)を備えており、ブロックチェーンに新たなブロックを追加する際に、各台帳管理ノードが所定のコンセンサス処理を行い、ブロックチェーン41のコピーを保持する。なお、台帳管理システム4におけるコンセンサスアルゴリズムは、PoWに限定されない。例えば、PoW以外にもBFT(Byzantine fault tolerance)等のコンセンサスアルゴリズムも利用可能である。
[0057]
 図5に示す台帳管理ノード42は、データ受付部421と、ブロック生成部422と、ブロック共有部423と、情報記憶部424と、ブロック検証部425と、データ出力部426とを含む。
[0058]
 データ受付部421は、外部ノードから、ブロックチェーン41に記録する情報を受け付ける。本実施形態では、データ受付部421は、ブロックチェーン41に記録する情報として、後述する資源割当要求(トランザクション)に基づく割当情報等を受け付ける。
[0059]
 ブロック生成部422は、データ受付部421が受け付けた情報を用いて、ブロックチェーンに追加するブロックを生成する。ブロック生成部422は、前ブロックに基づく情報(Hash値等)と、データ受付部421が受け付けた情報とを含むブロックを生成する。また、ブロック生成部422は、自身が生成したブロックまたは後述するブロック共有部423を介して他の台帳管理ノード42が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理や署名を付与する処理を行った上で、自身が管理するブロックチェーン(ブロックチェーン41のコピーに相当)にブロックを追加する。なお、ブロック生成部422が生成したブロックに対して、複数の台帳管理ノード42が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン41に追加されるブロックとなる。以下、コンセンサス処理を含む、ブロックチェーンにブロックを追加するための処理を、マイニングと呼ぶ場合がある。また、マイニングを行うノードをマイナーと呼ぶ場合がある。
[0060]
 ブロック共有部423は、台帳管理システム4に属する台帳管理ノード42間で情報交換を行う。ブロック共有部423は、より具体的には、データ受付部421が受け付けた情報や、ブロック生成部422が生成したブロックや、他の台帳管理ノード42から受け付けたブロック等を、適宜他の台帳管理ノード42に送信する。これにより、可能な限り全ての台帳管理ノード42でこれらの情報および最新のブロックチェーン41を共有する。
[0061]
 情報記憶部424は、ブロックチェーン41のコピーを記憶する。なお、情報記憶部424は、ブロックチェーン41のコピー以外にも、例えば、後述するブロック検証部425での検証処理に必要な情報などを記憶してもよい。
[0062]
 ブロック検証部425は、自身が保持するブロックチェーンにブロックを追加する際に、該ブロック内の検証を行う。例えば、ブロック検証部425は、追加するブロックが実際に規則を満たしているか、ブロックを作成したノードと署名が一致するか、追加するブロックに含まれる前ブロックに基づく情報が実際の前ブロックから生成した情報と一致するかなどを検証してもよい。
[0063]
 データ出力部426は、外部ノードからの要求に応じて、自身が保持するブロックチェーン41の中から所望の情報を含むブロックを検索して出力する。
[0064]
 なお、図5の構成はあくまで一例であって、台帳管理ノード42は、上記の特徴を有するブロックチェーン41を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて台帳への情報追加および台帳の参照が可能なノードであれば、具体的な構成は問わない。
[0065]
 次に、本実施形態でのブロックチェーンの利用方法を説明する。図6は、本実施形態の概要を示す説明図である。図6に示すように、本実施形態では、資源の管理単位であるデータセンタ(DC)3に、PoWの実行ノードであるマイナー(台帳管理ノード42)を設ける。そして、DC3の各々で、自身が保持しているブロックチェーン41と自身が管理するリソースサーバ2とから、ローカルで資源の割当状況や余り資源量を収集し、当該DC3における資源割当ポリシ(応答時間やどの機能単位に資源を割り当てるか等)を決定する。その上で、決定した資源割当ポリシに従い、処理対象とする要求や該要求に基づく割当内容等を含むブロックを生成し、該ブロックについてPoWを利用して分散的にコンセンサスを取る。なお、本実施形態では、機能単位1や監視エンティティ1Aは、資源割当要求を、資源の割り当てを望む全てのリソースサーバ2に送付する。
[0066]
 このようにすると、各DCにおける資源の割り当ての際に、より多くのマイナーに支持されるポリシが選ばれやすくなる。これは、例えば、2つのマイナーが決定した資源割当ポリシは、該マイナーの各々により作成される計2つのブロックに反映されてコンセンサス処理に供されるので、1つのマイナーに支持されるポリシに比べてマイニングにかけられる計算量が2倍になるためである。
[0067]
 各DCでは、ポリシに従い、ブロックに含めるトランザクション(要求)の内容や数を変更することで1回の割り当て制御における割当可能量を制御できるだけでなく、マイニング時のパラメータ(特に、コンセンサス処理の難易度に関するパラメータ)を変更することで、割当タイミングも制御できる。
[0068]
 図6に示す例は、機能単位A、機能単位Dおよび機能単位Eがそれぞれ、資源割当要求を、DCα、DCβおよびDCγに送付した例である。このとき、DCαが管理するリソースサーバ2の資源利用状況が“平常状態(通常時並みに余裕がある状態)”であったとする。一方、DCβが管理するリソースサーバ2の資源利用状況が“逼迫状態(余裕がない状態)”であったとする。また、DCγが管理するリソースサーバ2の資源利用状況が“空き状態(余裕が大きい状態)”であったとする。
[0069]
 このような場合、DCαは、自身が持つ情報を基に、例えば、“優先度順”という資源割当ポリシを決定する。また、DCβは、自身が持つ情報を基に、例えば、“少資源優先”という資源割当ポリシを決定する。また、DCγは、自身が持つ情報を基に、例えば、“高速応答”という資源割当ポリシを決定する。ここで、“優先度順”は、自身が割り当てられる範囲内で、優先度が高い要求に対して優先的に資源を割り当てるポリシである。また、“少資源優先”は、自身が割り当てられる範囲内で、要求量が少ない要求に対して優先的に資源を割り当てるポリシである。また、“高速応答”は、自身が割り当てられる範囲内で、受け付けた順に即座に資源を割り当てるポリシである。
[0070]
 このようにして、同じ要求の受け付け状態であっても、DCごとに、自身の資源の利用状況に従って決定されるポリシが決定される。そのようにして決定したポリシに基づき、選択される要求やその数が異なりうるブロックが生成され、各DC内でコンセンサス処理に供される。その結果、最も早くコンセンサスがとれたブロックがブロックチェーン41に追加され、各DCで共有される。ブロックチェーン41にブロックが追加されると、各DCは、追加されたブロックに含まれる情報に従って、資源の割り当てを行う。例えば、各DCは、ブロックに、各要求に付与された識別子を含ませ、ブロックチェーンにどの要求が登録されたかがわかるようにしてもよい。
[0071]
 また、このような動作の繰り返しにより、ブロックチェーン41にはシステム全体における過去の割当状況が保持されることとなる。したがって、各DCは、他のDC3に毎度問い合わせなくても、自身が管理するリソースサーバ2における最新の利用状況だけでなく、他のDC3を含むシステム全体における過去の割当状況を取得できる。
[0072]
 図7は、第2の実施形態の資源割当システムの構成例を示すブロック図である。本実施形態の資源割当システム100は、例えば、1つ以上の機能単位1や、それら機能単位1を監視する監視エンティティ1Aなどを含むサービスシステム200において、機能単位1に対して資源提供部2Aが保有する資源を割り当てる資源割当システムとして動作する。
[0073]
 図7に示す資源割当システム100は、1つ以上のデータセンタ(DC)3を備える。なお、DC3の各々は、ネットワークを介して互いに接続されている。
[0074]
 DC3の各々は、資源提供部2Aと、台帳管理部31と、利用状況取得部32と、パラメータ決定部33と、資源割当部34とを備える。なお、DC3は、任意の資源の管理単位であって、地理的および物理的な構成は特に限定されない。また、図7では、1つのDC3に対して1つの資源提供部2Aが割り当てられているが、サービスシステム200が備える2以上の資源提供部2Aのうちのいずれか1つ以上の資源提供部2Aが割り当てられていればよく、資源提供部2Aの数は特に限定されない。
[0075]
 本例では、各DC内の台帳管理部31が上記のマイナーとして動作する。また、機能単位1や監視エンティティ1A等の資源割当要求を送付するノードが、ブロックチェーン41を利用するエンティティとして動作する。典型的には、各エンティティは、秘密鍵、公開鍵のペアを持ち、秘密鍵でトランザクションに署名を付加してマイナー(本例では、自DC内の台帳管理部31)に送付する。マイナーは、送付されたトランザクションに基づき、ブロックを生成し、コンセンサス処理を経てブロックチェーンへブロックを追加する。各エンティティは、システムに参加する際、他のエンティティ等からマイナーの情報を取得可能とする。
[0076]
 なお、図7では、1つのブロックチェーン41を示しているが、ブロックチェーン41は、実際には台帳管理システム4に含まれる台帳管理ノード42としての台帳管理部31の各々に保持される。
[0077]
 また、本例において、資源提供部2A、台帳管理部31、利用状況取得部32、パラメータ決定部33および資源割当部34は、それぞれ第1の実施形態のリソースサーバ2、資源利用状況管理部101、利用状況取得部102、パラメータ決定部103および資源割当部104に相当する。なお、本実施形態では、台帳管理部31が、さらにパラメータ決定部103の機能の一部を担う。
[0078]
 資源提供部2Aは、当該DCで割り当て可能な資源を管理する。
[0079]
 台帳管理部31は、例えば、図5に示した台帳管理ノード42の各構成要素を備える。本実施形態では、台帳管理部31は、後述するパラメータ決定部33より、ブロックに含ませる要求(トランザクション)およびマイニングパラメータが指定されると、該トランザクションを含むブロックを生成して、指定されたマイニングパラメータに従ってマイニングを行う。そして、台帳管理部31は、マイニングが成功すると、自身のブロックチェーン41に追加するともに、他の台帳管理部31間で共有処理を行う(マイニングが成功したブロックを送付する)。また、台帳管理部31は、自身が管理するブロックチェーン41に新たにブロックが追加された場合に、その旨をパラメータ決定部33または資源割当部34に通知してもよい。
[0080]
 利用状況取得部32は、所定のタイミングで、資源提供部2Aおよびブロックチェーン41(より具体的には、台帳管理部31の情報記憶部424に保持されるブロックチェーン41のコピー)から、自DCにおける資源利用状況および各DCでの過去の資源割当状況を取得する。所定のタイミングは、特に問わないが、一例として、一定の周期ごと、資源割当要求を受信したとき、資源割当要求を受信した後一定時間経過後などが挙げられる。
[0081]
 パラメータ決定部33は、利用状況取得部32によって取得された情報を基に、マイニングブロックに含ませる要求の選択方法およびマイニングパラメータを決定する。ここで、マイニングブロックは、マイナーがマイニングの対象とするブロックである。また、マイニングブロックに含ませる要求の選択方法は、次の割り当て処理の対象とする要求を選択する方法であって、例えば、何を基準に、かつどれだけの量の要求を選択するかを規定する。また、マイニングパラメータは、マイニングの所要時間を決定づけるパラメータなど、コンセンサス処理の難易度に関するパラメータであればよく、例えば、PoWのターゲット値である。
[0082]
 例えば、パラメータ決定部33は、予め要求の選択方法とマイニングパラメータの組が設定された資源割当ポリシの中から1つのポリシを選択することにより、要求の選択方法およびマイニングパラメータを決定してもよい。
[0083]
 また、パラメータ決定部33は、要求の選択方法およびマイニングパラメータが決定すると、決定した選択方法または該選択方法に従って選択した要求(トランザクション)を指定したブロック追加要求を、マイニングパラメータとともに台帳管理部31に通知する。このとき、パラメータ決定部33は、選択した要求について、当該DCで受け付けた要求量とは異なる要求量に変更することも可能である。
[0084]
 資源割当部34は、台帳管理部31が管理するブロックチェーン41にブロックが追加されると、該ブロックに含まれるトランザクションを基に、資源の割り当てを行う。例えば、資源割当部34は、該ブロックに含まれるトランザクションに対して、自身が可能な範囲内で資源を割り当ててもよい。
[0085]
 次に、本実施形態の動作を説明する。図8は、本実施形態の資源割当システム100におけるDC3の動作例を示すフローチャートである。
[0086]
 図8に示す例では、まず、各DC3が資源割当要求を受け付ける(ステップS201)。ここで受け付けた資源割当要求は逐次バッファリングされる。資源割当要求の送信元は、特に問わない。例えば、機能単位1であってもよいし、監視エンティティ1Aであってもよい。
[0087]
 次いで、利用状況取得部32は、自DCで保持している情報から自DCにおける資源利用状況および各DCでの過去の資源割当状況を取得する(ステップS202)。ステップS202でh、利用状況取得部32は、例えば、自DCにおける資源利用状況および各DCでの過去の資源割当状況を取得する。
[0088]
 次いで、パラメータ決定部33は、取得された情報を基に、マイニングブロックに含ませる要求の選択方法およびマイニングパラメータを決定する(ステップS203)。
[0089]
 次いで、台帳管理部31が、決定された選択方法に従い、受け付けた要求の中から選択された要求を含むマイニングブロックを生成し、該マイニングブロックに対して、決定されたマイニングパラメータに従いマイニングを行う(ステップS204)。ここで、マイニングブロックには、資源割当要求に基づく資源の割り当て情報(どの機能単位にどれだけの資源を割り当てるかを示す情報)が含まれるものとする。
[0090]
 なお、ステップS204の動作は各DCで同時並列的に行われる。一般に、最も早くマイニングを成功したブロックが共有処理により、各DCのブロックチェーン41に追加される。なお、各DCの台帳管理部31は、検証の結果、ブロックの追加を拒否することも可能である。
[0091]
 ブロックチェーン41に新たなブロックが追加されると、資源割当部34が、該ブロックに含まれる情報に基づいて、資源を割り当てる(ステップS205)。
[0092]
 各DCは、例えば、ブロックが追加されて1回の割り当て制御を終える度に、次の割り当て制御に移る(ステップS202に戻る)。各回の割り当て制御では、それまでに届いている要求を対象に、ステップS202~ステップS205の動作を行えばよい。
[0093]
 図9は、マイニングブロックに含ませる要求の選択方法の例を示す説明図である。図9に示す例において、DCαの管理対象の資源提供部2Aの資源利用状況は“空き状態”であり、DCβおよびDCγの管理対象の資源提供部2Aの資源利用状況はそれぞれ“逼迫状態”である。また、各DCの要求バッファには、機能単位Aからの資源割当要求(“トランザクションA”)と、機能単位Bからの資源割当要求(“トランザクションB”)と、機能単位Cからの資源割当要求(“トランザクションC”)とがこの順で格納されている。なお、“トランザクションA”の要求量は、“トランザクションB”および“トランザクションC”の要求量よりも少ない。
[0094]
 このような場合、DCαのパラメータ決定部33は、資源割当ポリシとして上述した“高性能ポリシ”を選択してもよい。“高性能ポリシ”は、1回の制御で多くの資源を割り当てるポリシである。当該ポリシが選択されると、例えば、要求バッファに格納されている要求が全て選択される。また、DCβおよびDCγのパラメータ決定部33は、資源割当ポリシとして上述した“省資源ポリシ”を選択してもよい。“省資源ポリシ”は、優先度が低い要求を破棄したり、要求量が少ない要求を優先するなどして、1回の制御あたりで割り当てる資源量を少なくするポリシである。当該ポリシが選択されると、例えば、要求バッファに格納されている要求の中から、要求の優先度および要求量に基づいて所定数の要求が選択される。このとき、選択されなかった残りの要求は要求バッファに格納されたままとなるが、要求を受信してから一定時間経過後、破棄することができる。
[0095]
 なお、図9には、DCαのマイニングブロックとして、“トランザクションA”、“トランザクションB”および“トランザクションC”を含むブロックが生成される例が示されている。また、DCβおよびDCγのマイニングブロックとして、“トランザクションA”を含むブロックが生成される例が示されている。
[0096]
 また、図10は、マイニングブロックに含ませる要求の選択方法の他の例を示す説明図である。図10に示す例において、DCα、DCβおよびDCγの管理対象の資源提供部2Aの資源利用状況はいずれも“平常状態”である。また、本例における各DCの要求バッファの状態は、図9と同様である。また、本例において、ブロックチェーン41が示す各DCでの過去の割当状況より、機能単位B>機能単位A>機能単位Cという機能単位1に対する割当頻度の関係が把握される。
[0097]
 このような場合、各DCのパラメータ決定部33は、“頻度優先ポリシ”を選択してもよい。“頻度優先ポリシ”は、例えば、予め定められた数の要求を含ませるものとし、その際に、割当頻度が低い機能単位からの要求ほど、高い確率でブロックに含ませるポリシである。なお、当該ポリシは、他のポリシと独立して選択されてもよいし、他のポリシと組み合わせて選択されてもよい。“頻度優先ポリシ”は、例えば、他のポリシによって選択された要求数に対して、優先順位を定めるために用いることができる。
[0098]
 また、例えば、パラメータ決定部33は、自DC内の資源利用状況に基づく制御と、各DCでの過去の過去の割当状況に基づく制御の結果を基に、最終的な要求の選択方法を決定してもよい。
[0099]
 次に、マイニングパラメータの決定方法について説明する。パラメータ決定部33は、例えば、管理対象の資源提供部2Aの余り資源量に応じて、PoWのターゲット値を決定してもよい。一例として、資源が余っているほど、ターゲット値を高く(マイニングを簡単に)してもよい。マイニングを簡単にすることで、早い応答速度にできる。
[0100]
 また、パラメータ決定部33は、例えば、マイニングブロックに含まれる要求に応じて、PoWのターゲット値を決定してもよい。一例として、ブロック内の要求群の優先度が高いほど、ターゲット値を高く(マイニングを簡単に)してもよい。これに関連して、パラメータ決定部33は、台帳管理部31においてマイニングブロックのマインング中に、自DCが新たに高い優先度の要求を受け付けた場合、マイニングブロックを再構成してもよい。その場合、パラメータ決定部33は、台帳管理部31に現在のマイニングを中止させ、再構成したマイニングブロックを通知し、マイニングをやり直させる。
[0101]
 このような要求の優先度に基づく制御によって、優先度が低い要求に対して過度に資源が割り当てられるのを抑制できる。図11は、マイニングパラメータの決定方法の例を示す説明図である。図11に示す例では、優先度に基づいてターゲット値を設定する例である。
[0102]
 また、図12は、割当可能量の制御例を示す説明図である。各マイナー(より具体的には、台帳管理部31やパラメータ決定部33や資源割当部34)は、制御対象とされたブロックのマイニングの所要時間に応じて、割当可能量を変更してもよい。ここで、マイニングの所要時間は、見積もり時間であっても、実際に要した時間であってもよく、また実質的に前ブロックが追加されてから該ブロックが追加されるまでの経過時間でもよい。一例として、所要時間が短いほど割当可能量を少なくし、所要時間が長いほど割り当て量を多くしてもよい。
[0103]
 本実施形態では、DCの各々で、マイナーとされる管理装置等が自DC内にある情報に基づいて、マイニングブロックに含ませる要求を選択し、また、マイニングパラメータを設定する。そして、各DCのマイナーが別々のポリシで作成した異なるマイニングブロックを別々のポリシで設定したマイニングパラメータを用いてマイニングする。各マイナーのマイニングの結果、コンセンサスがとられ、各DCにてブロックチェーンにブロックが追加される。ブロックが追加されると、追加されたブロックに記録された情報に従って、各DCが資源を割り当てる。
[0104]
 なお、各DCは、ブロックに、処理対象とする要求(トランザクション)ではなく、資源割当ポリシそのものを記録してもよい。その場合、各DCは、自身が持つブロックチェーン41に新たなブロックが追加されたタイミングで、該ブロックに記録された資源割当ポリシに従った資源の割り当てを行う。この場合、ブロックの追加タイミングが、資源割当ポリシの更新タイミングとされる。このようなブロックに含ませる情報の例として挙げた要求やその識別子、選択された要求に基づいて決定した割り当て内容、資源割当ポリシ等をまとめて、「資源割当要求に基づく割当に関する割当情報」と呼ぶ場合がある。
[0105]
 このように、本実施形態では、分散台帳システムのPoWに基づくコンセンサス処理を利用して、資源の割り当ての応答速度を調整する。結果として、各エンティティの独立性を保ったまま、システム全体でバランスのとれた資源割り当てが可能になる。例えば、図9に示す例では、特定のDCのみ資源に余裕がある場合でも、省資源ポリシが採用されやすくなるなど、偏った要求や情報収集により生じる資源の枯渇や偏重を抑制できる。
[0106]
 次に、本発明の実施形態にかかるコンピュータの構成例を示す。図13は、本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ1000は、CPU1001と、主記憶装置1002と、補助記憶装置1003と、インタフェース1004と、ディスプレイ装置1005と、入力デバイス1006とを備える。
[0107]
 上述した機能単位1やDC3内の各構成要素や台帳管理ノード42は、例えば、コンピュータ1000に実装されてもよい。その場合、これら各装置(機能単位、構成要素、ノードを実装した装置)の動作は、プログラムの形式で補助記憶装置1003に記憶されていてもよい。CPU1001は、プログラムを補助記憶装置1003から読み出して主記憶装置1002に展開し、そのプログラムに従って上記の実施形態における所定の処理を実施する。
[0108]
 補助記憶装置1003は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース1004を介して接続される磁気ディスク、光磁気ディスク、CD-ROM、DVD-ROM、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ1000に配信される場合、配信を受けたコンピュータは1000がそのプログラムを主記憶装置1002に展開し、上記の実施形態における所定の処理を実行してもよい。
[0109]
 また、プログラムは、各実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置1003に既に記憶されている他のプログラムとの組み合わせで上記の実施形態における所定の処理を実現する差分プログラムであってもよい。
[0110]
 インタフェース1004は、他の装置との間で情報の送受信を行う。また、ディスプレイ装置1005は、ユーザに情報を提示する。また、入力デバイス1006は、ユーザからの情報の入力を受け付ける。
[0111]
 また、実施形態における処理内容によっては、コンピュータ1000の一部の要素は省略可能である。例えば、装置がユーザに情報を提示しないのであれば、ディスプレイ装置1005は省略可能である。
[0112]
 また、各装置の各構成要素の一部または全部は、汎用または専用の回路(Circuitry)、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
[0113]
 各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
[0114]
 次に、本発明の資源管理システムの概要を説明する。図14は、本発明の資源割当システムの概要を示すブロック図である。図14に示す資源割当システム500は、資源割当部501と、2以上の資源提供部502と、余り資源量取得部503と、パラメータ決定部504とを備える。
[0115]
 資源割当部501(例えば、資源割当部104、資源割当部34)は、所定の機能をサービスとして提供する1つ以上の機能単位に、サービスを実行するための資源を割り当てる。
[0116]
 資源提供部502(例えば、リソースサーバ2、資源提供部2A)は、資源を提供する。
[0117]
 余り資源量取得部503(例えば、利用状況取得部102、利用状況取得部32)は、2以上の資源提供部のうちの所定の資源提供部から余り資源量を取得する。
[0118]
 パラメータ決定部504(例えば、パラメータ決定部103、パラメータ決定部33)は、取得された余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定する。
[0119]
 このような構成により、機能単位同士の関係性が不透明なサービスシステムに対して資源を割り当てる場合であっても、適切な応答速度で資源の割り当てが行えるので、機能単位間での資源割り当ての不均衡を抑制できる。
[0120]
 また、図15は、本発明の資源割当システムの他の構成例を示すブロック図である。本発明の資源割当システム500は、例えば、図15に示す構成であってもよい。
[0121]
 すなわち、資源割当システム500は、2以上の資源提供部502における資源の割当状況を管理する割当状況管理部505と、2以上の資源提供部502が提供する資源の管理単位としての複数のデータセンタとをさらに備えていてもよい。そして、これらデータセンタのいずれかに配置される管理装置を備え、各管理装置が、資源割当部501、余り資源量取得部503、パラメータ決定部504および割当状況管理部505を含んでいてもよい。
[0122]
 このような構成において、資源割当部501は、機能単位に、自データセンタの管理対象の資源より資源を割り当てる。
[0123]
 また、余り資源量取得部503は、管理対象の資源を提供する資源提供部から余り資源量を取得する。
[0124]
 また、パラメータ決定部504は、余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定する。
[0125]
 また、割当状況管理部505(例えば、資源利用状況管理部101、台帳管理部31)は、他のデータセンタに配置された割当状況管理部505(不図示)との間で、所定のコンセンサス処理を経てデータセンタのいずれかに対する資源割当要求に基づく割当に関する割当情報を含むブロックが追加されるブロックチェーンを共有することにより、割当状況を管理する。そして、資源割当部501が、パラメータ決定部504による決定に基づいて行われるコンセンサス処理の結果、ブロックチェーンに記録された情報に基づいて、資源の割り当てを行う。
[0126]
 このような構成によれば、台帳管理システムにおける分散的にコンセンサスを取る仕組みと、それによる共有情報保持機構とを利用することにより、データセンタ内の情報だけで、適切な応答速度で資源の割り当てが行えるので、機能単位間での資源割り当ての不均衡を抑制できる。
[0127]
 以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

産業上の利用可能性

[0128]
 本発明は、レジリエントにサービスを提供する用途に好適に適用可能である。

符号の説明

[0129]
 100 資源割当システム
 101 資源利用状況管理部
 102 利用状況取得部
 103 パラメータ決定部
 104 資源割当部
 200 サービスシステム
 1 機能単位
 1A 監視エンティティ
 2 リソースサーバ
 2A 資源提供部
 3 DC
 31 台帳管理部
 32 利用状況取得部
 33 パラメータ決定部
 34 資源割当部
 4 台帳管理システム
 41 ブロックチェーン
 42 台帳管理ノード
 421 データ受付部
 422 ブロック生成部
 423 ブロック共有部
 424 情報記憶部
 425 ブロック検証部
 426 データ出力部
 1000 コンピュータ
 1001 CPU
 1002 主記憶装置
 1003 補助記憶装置
 1004 インタフェース
 1005 ディスプレイ装置
 1006 入力デバイス
 500 資源割当システム
 501 資源割当部
 502 資源提供部
 503 余り資源量取得部
 504 パラメータ決定部
 505 割当状況管理部

請求の範囲

[請求項1]
 所定の機能をサービスとして提供する1つ以上の機能単位に、前記サービスを実行するための資源を割り当てる資源割当部と、
 前記資源を提供する2以上の資源提供部と、
 前記2以上の資源提供部のうちの所定の資源提供部から余り資源量を取得する余り資源量取得部と、
 前記余り資源量に基づいて、前記資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定するパラメータ決定部とを備えた
 ことを特徴とする資源割当システム。
[請求項2]
 前記2以上の資源提供部における資源の割当状況を管理する割当状況管理部を備え、
 前記パラメータ決定部は、前記余り資源量と、前記割当状況とに基づいて、前記割当タイミング、前記割当可能量および前記優先順位を決定する
 請求項1記載の資源割当システム。
[請求項3]
 前記2以上の資源提供部における資源の割当状況を管理する割当状況管理部と、
 前記2以上の資源提供部が提供する資源の管理単位としての複数のデータセンタとを備え、
 前記資源割当部、前記余り資源量取得部、前記パラメータ決定部および前記割当状況管理部は、前記データセンタの各々に配置され、
 前記余り資源量取得部は、自データセンタの管理対象の資源を提供する資源提供部から余り資源量を取得し、
 前記割当状況管理部は、他のデータセンタに配置された割当状況管理部との間で、所定のコンセンサス処理を経て前記複数のデータセンタのいずれかに対する資源割当要求に基づく割当に関する割当情報を含むブロックが追加されるブロックチェーンを共有し、
 前記パラメータ決定部は、前記余り資源量に基づいて、自データセンタにおける前記割当タイミング、前記割当可能量および前記優先順位のうち少なくとも1つを決定し、前記決定に基づいて、自データセンタの前記割当状況管理部に対し、前記コンセンサス処理を要求し、
 前記資源割当部は、自データセンタの前記ブロックチェーンに記録された情報に基づいて、前記管理対象の資源より資源の割り当てを行う
 請求項1記載の資源割当システム。
[請求項4]
 前記2以上の資源提供部における資源の割当状況を管理する割当状況管理部と、
 前記2以上の資源提供部が提供する資源の管理単位としての複数のデータセンタとを備え、
 前記資源割当部、前記余り資源量取得部、前記パラメータ決定部および前記割当状況管理部は、前記データセンタの各々に配置され、
 前記余り資源量取得部は、自データセンタの管理対象の資源を提供する資源提供部から余り資源量を取得し、
 前記割当状況管理部は、他のデータセンタに配置された割当状況管理部との間で、所定のコンセンサス処理を経て前記複数のデータセンタのいずれかに対する資源割当要求に基づく割当に関する割当情報を含むブロックが追加されるブロックチェーンを共有し、
 前記パラメータ決定部は、前記余り資源量と、自データセンタの前記ブロックチェーンにより示される過去の資源の割当状況とに基づいて、自データセンタにおける前記割当タイミング、前記割当可能量および前記優先順位のうち少なくとも1つを決定する
 請求項1記載の資源割当システム。
[請求項5]
 前記資源割当部は、自データセンタの前記ブロックチェーンに新たにブロックが追加されたタイミングで、当該ブロックに含まれる割当情報に基づいて、前記管理対象の資源より資源の割り当てを行う
 請求項3または請求項4記載の資源割当システム。
[請求項6]
 前記割当タイミングの決定が、前記コンセンサス処理の難易度に関するパラメータの決定により行われる
 請求項3から請求項5のうちのいずれかに記載の資源割当システム。
[請求項7]
 前記パラメータ決定部は、前記決定に基づいて、受け付けた資源割当要求の中から制御対象とする要求を選択し、選択された前記要求に基づく前記割当情報を含むブロックについて前記コンセンサス処理を要求する
 請求項3から請求項6のうちのいずれかに記載の資源割当システム。
[請求項8]
 前記パラメータ決定部は、決定された前記割当可能量と、受け付けた資源割当要求の優先度、受け付けた資源割当要求の要求量または自データセンタの前記ブロックチェーンに記録された情報から把握される各機能単位への過去の割当頻度とに基づいて、要求を選択する
 請求項7記載の資源割当システム。
[請求項9]
 前記パラメータ決定部は、選択した要求の優先度または要求量に基づいて、前記コンセンサス処理の難易度に関するパラメータを決定する
 請求項7または請求項8記載の資源割当システム。
[請求項10]
 前記コンセンサス処理に要した時間に応じて前記割当可能量が変更される
 請求項3から請求項9のうちのいずれかに記載の資源割当システム。
[請求項11]
 所定の機能をサービスとして提供する1つ以上の機能単位に割り当てる資源を提供する2以上の資源提供部が提供する資源の管理単位として設けられる複数のデータセンタのいずれかに配置される管理装置であって、
 前記機能単位に、自データセンタの管理対象の資源より資源を割り当てる資源割当部と、
 前記管理対象の資源を提供する資源提供部から余り資源量を取得する余り資源量取得部と、
 前記2以上の資源提供部における資源の割当状況を管理する割当状況管理部であって、他のデータセンタに配置された割当状況管理部との間で、所定のコンセンサス処理を経てデータセンタのいずれかに対する資源割当要求に基づく割当に関する割当情報を含むブロックが追加されるブロックチェーンを共有することにより、前記割当状況を管理する割当状況管理部と、
 前記余り資源量に基づいて、前記資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定するパラメータ決定部とを備え、
 前記資源割当部は、前記パラメータ決定部による決定に基づいて行われる前記コンセンサス処理の結果、前記ブロックチェーンに記録された情報に基づいて、資源の割り当てを行う
 ことを特徴とする管理装置。
[請求項12]
 情報処理装置が、
 所定の機能をサービスとして提供する1つ以上の機能単位に割り当てる資源を提供する2以上の資源提供部のうちの所定の資源提供部から余り資源量を取得し、
 前記余り資源量に基づいて、前記資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定する
 ことを特徴とする資源割当方法。
[請求項13]
 コンピュータに、
 所定の機能をサービスとして提供する1つ以上の機能単位に割り当てる資源を提供する2以上の資源提供部のうちの所定の資源提供部から余り資源量を取得する処理、および
 前記余り資源量に基づいて、前記資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、1回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも1つを決定する処理
 を実行させるための資源割当プログラム。

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]

[ 図 13]

[ 図 14]

[ 図 15]

[ 図 16]

[ 図 17]

[ 図 18]