JP6881575B2 - 資源割当システム、管理装置、方法およびプログラム - Google Patents

Description

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

サービス提供側において、障害が起きた場合や悪意のある装置等が存在する場合であっても、正規のユーザに対してサービスを継続的に提供したいという要求がある。そのため、そのようなサービス提供基盤が所望されている。

サービス提供アーキテクチャの１つに、マイクロサービスアーキテクチャ（micro service architecture，以下、ＭＳＡという）がある。ＭＳＡは、一枚岩（モノリシック）なソフトウェアアーキテクチャを細かく分割して、結合度の低い機能単位の集まりとし、それらを連携させることによって同等のサービスを提供するアーキテクチャである。ＭＳＡは、サービス提供に必要な機能を独立して扱えるので、開発およびデプロイの迅速化や、優れた回復性、スケーラビリティを実現できるというメリットがある。

図１６は、マイクロサービスを利用したサービス提供プログラムの例を示す説明図である。図１６に示す例は、ユーザからのサービスリクエストをフロントエンドサービスが受け付け、後段のマイクロサービスに適宜処理を実行させ、その処理連携により、該ユーザにサービスを提供するアーキテクチャの例である。マイクロサービスの例としては、認証サービス、アクセス許可、データの管理（更新、削除、抽出）、レコメンデーションなどが挙げられる。ＭＳＡは、クラウド上でサービスを提供する際のアーキテクチャとして利用されている。

以下、このような複数の機能単位を連携させてサービスを提供するサービスシステムにおける資源管理を考える。図１７は、ＭＳＡにおける資源管理方法の例を示す説明図である。ＭＳＡでは、例えば、管理エンティティが、各マイクロサービスにおける資源の使用状況をモニタリングし、あるマイクロサービスの資源使用率等が基準を上回った場合に、新たに資源を割り当てる。また、管理エンティティは、あるマイクロサービスの資源使用率等が基準を下回った場合に、資源を解放する。ここで、資源の割り当ては、該当するマイクロサービスのインスタンスを複製することであってもよい。また、資源の解放は、該当するマイクロサービスのインスタンスを削除することであってもよい。また、マイクロサービス自身が資源使用状況を判断して資源割当要求を管理エンティティに送信する場合もある。

また、特許文献１には、分散環境下における個々のユーザ（ホストコンピュータ）の要求に基づいて、資源の輻輳状態に対応した動的な適応性をもった資源配分制御を行う方法が記載されている。

特開平１１−６６０１８号公報

課題は、個々の機能単位の資源使用状況や要求に対して、各リソースサーバが自身の資源の残量に基づいて単純に資源を割り当てるだけでは、適切な資源の割り当てができず、機能単位間で不均衡な割り当てとなることにある。特に、以下で割り当て応答速度と呼ぶ、割当頻度や１回の割当量が適切でない場合には、機能単位間で資源の割り当てに不均衡が生じるおそれがある。

図１８は、ＭＳＡにおける資源の割り当て応答速度の例を示す説明図である。図１８は、リソースサーバの資源が限られている場合において、ユーザ数の増加等に伴い、資源割当要求がフロントエンド側から順番に発生する状況における資源の割り当ての例を示している。ここで、ユーザに要求されたサービスを提供するためには、フロントエンドサービスＸ、マイクロサービスＡ、マイクロサービスＢ、マイクロサービスＣの順で処理が必要であるとする。このとき、サービスが輻輳状態にない場合からユーザ数が増加すると、まずフロントエンドサービスＸが資源不足となり、リソースサーバに資源割当要求を行う。資源が割り当てられた結果、フロントエンドサービスＸが要求を処理可能になると、次に呼び出されるマイクロサービスＡが輻輳状態となり、資源不足となる。そこで、マイクロサービスＡがリソースサーバに資源割当要求を行う。

このとき、リソースサーバが資源に余裕がない状態で個々の機能単位からの資源割当要求に応じて要求量を即座に割り当てると、フロントエンド側で資源を使い果たしてしまう。すると、次に輻輳状態となるマイクロサービスＢから資源割当要求が来たとしても、割り当て可能な資源がなく、資源を割り当てることができない。結果として、機能単位間で資源の不均衡が生じてしまう。また、本例の場合、マイクロサービスＣの処理まで完了しないとユーザへのサービスは完了しないため、フロントエンド側に資源を多く割り当てた結果、サービス提供が失敗する結果となる。

このような資源の偏重を抑制する方法として、例えば、リソースサーバが、受け付けた要求に対して要求量を即座に割り当てずに一定時間待ち、その間に貯まった要求群を基に割当量や優先順位などを決定することが考えられる。しかし、ＭＳＡのような機能単位間の独立性が高いサービスシステムの場合、実際に資源を割り当ててサービス処理を実行してからでないと、次にどのサービスが混雑するのかがわからない場合が多い。したがって、要求をバッファリングするだけでは上記問題を解決できない。なお、リソースサーバが、即座に要求量の一部のみを先に割り当てることも考えられるが、機能単位間の結合度が弱いシステムでは、どれだけの速さでどれだけの量を割り当てればよいかを、個々のリソースサーバが現在認識している要求だけで判断するのは困難である。

また、その一方で、リソースサーバに資源が十分ある場合には、資源が不足している機能単位に対して、即座に要求量の資源を割り当てたいという要望もある。このように、適切な応答速度はリソースサーバの資源の利用状況によっても変化する。

本発明は、上述した課題に鑑みて、１つ以上の機能単位を連携させてサービスを提供するサービスシステムにおいて、該機能単位に対し資源を割り当てる場合であっても、機能単位間での資源割り当ての不均衡を抑制できる資源割当システム、管理装置、資源割当方法および資源割当プログラムを提供することを目的とする。

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

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

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

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

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

第１の実施形態の概要を示す説明図である。 第１の実施形態の資源割当システム１００の構成例を示すブロック図である。 第１の実施形態の資源割当システム１００の動作例を示すフローチャートである。 ブロックチェーンのデータ構造の例を示す説明図である。 台帳管理システム４が備える台帳管理ノード４２の例を示すブロック図である 第２の実施形態の概要を示す説明図である。 第２の実施形態の資源割当システム１００の構成例を示すブロック図である。 第２の実施形態のＤＣ３の動作例を示すフローチャートである マイニングブロックに含ませる要求の選択方法の例を示す説明図である。 マイニングブロックに含ませる要求の選択方法の他の例を示す説明図である。 マイニングパラメータの決定方法の例を示す説明図である。 割当可能量の制御例を示す説明図である。 本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。 本発明の資源割当システムの概要を示すブロック図である。 本発明の資源割当システムの他の構成例を示すブロック図である。 マイクロサービスを利用したサービス提供プログラムの例を示す説明図である。 ＭＳＡにおける資源管理方法の例を示す説明図である。 ＭＳＡにおける資源の割り当て応答速度の例を示す説明図である。

以下、本発明の実施形態を、図面を参照して説明する。図１は、第１の実施形態の概要を示す説明図である。図１に示すように、本実施形態の資源割当システム１００は、リソースサーバ２からそれぞれ余り資源量を収集し、収集した余り資源量に基づいて、機能単位１に対して資源の割り当てを行う。このとき、資源割当システム１００は、余り資源量に基づいて、資源の割り当ての応答速度（具体的には、割当タイミング、１回の割当可能量等）を決定し、その決定に基づいて資源の割り当てを行う。

ここで、機能単位１は、上記のマイクロサービスなど、サービス提供のための所定の機能を実装し、要求に応じて該機能を提供する独立したユニットである。なお、機能単位１は、独立した装置に限らず、該機能を提供するプログラムであってもよい。すなわち、１つのサーバや仮想化基盤に複数の機能単位１が実装されていてもよい。そのような場合であっても、各々の機能単位１は独立したユニットであるとみなす。また、本発明では、機能単位が提供する機能もサービスの１つとみなす。

図２は、本実施形態の資源割当システム１００の構成例を示すブロック図である。図２に示す資源割当システム１００は、資源利用状況管理部１０１と、利用状況取得部１０２と、パラメータ決定部１０３と、資源割当部１０４とを備える。

資源利用状況管理部１０１は、割り当て対象とされる資源を管理する１つ以上のリソースサーバ２における資源の利用状況を管理（収集、保持）する。ここで、資源利用状況管理部１０１が管理する資源の利用状況は、リソースサーバ２の各々の余り資源量を含む。なお、さらに、過去の割当状況（どの機能単位１にどれだけ割り当てたか等）が含まれていてもよい。

利用状況取得部１０２は、資源利用状況管理部１０１からリソースサーバ２の各々の資源の利用状況を取得する。取得のタイミングは特に問わないが、例えば、一定の周期ごと、資源割当要求を受信したとき、資源割当要求を受信した後一定時間経過後などの所定のタイミングでよい。

パラメータ決定部１０３は、利用状況取得部１０２が取得したリソースサーバ２の各々の資源の利用状況を基に、資源割当パラメータを決定する。ここで、資源割当パラメータには、資源の割当頻度と、１回の割当可能量とが含まれる。なお、資源割当パラメータは、いずれか一方であってもよい。その場合、他方は予め決められた値を用いる。また、割当頻度は、資源割当部１０４における割り当て制御を行うタイミングである割当タイミングを定めるものであれば特に問わない。例えば、割当頻度は、単位時間あたりの割当可能回数であってもよいし、割当間隔であってもよい。また、資源割当パラメータには、さらに、要求に対する優先順序に関するルール（以下、割当順序ルールという）が含まれていてもよい。

資源割当部１０４は、パラメータ決定部１０３が決定した資源割当パラメータに基づいて、機能単位１に資源を割り当てる。資源割当部１０４は、例えば、要求バッファに既にあるまたはこれから受信する資源割当要求に対して、資源割当パラメータが示す割当頻度で、かつ割当可能量の範囲内で、資源を割り当てる。

なお、要求バッファに既に存在する要求元からの資源割当要求を再度受信したときは、受信した資源割当要求またはバッファ内の資源割当要求のいずれかを破棄してもよい。

次に、本実施形態の動作を説明する。図３は、本実施形態の資源割当システム１００の動作例を示すフローチャートである。図３に示す例では、まず、資源利用状況管理部１０１が、リソースサーバ２の各々から資源の利用状況として余り資源量を収集する（ステップＳ１０１）。

次いで、パラメータ決定部１０３が、取得された余り資源量に基づいて、資源割当パラメータを決定する（ステップＳ１０２）。

次いで、資源割当部１０４が、資源割当パラメータに基づいて、機能単位１に対して資源を割り当てる（ステップＳ１０３）。

ステップＳ１０２において、パラメータ決定部１０３は、リソースサーバ全体において資源に余裕がない場合には、以下に示すような省資源ポリシに基づき、資源割当パラメータを決定してもよい。また、パラメータ決定部１０３は、例えば、リソースサーバ全体において資源に余裕がある場合には、以下に示すような高性能ポリシに基づき、資源割当パラメータを決定してもよい。ここで、資源に余裕があるか否かは、例えば、余り資源量の合計が所定の閾値以上か否かや、全資源量に対して所定の割合以上か否かで判定してもよい。

［省資源ポリシ］
・割当頻度を低くする
制御例：優先度が低い要求を破棄
制御例：要求量が少ない要求を優先
・１回の割当可能量を少なくする

［高性能ポリシ］
・１回の割当可能量を多くする
・割当頻度を高くするまたは即座に割当可能とする

なお、資源割当パラメータは、リソースサーバ全体に対して設定してもよいし、リソースサーバ２の各々に対して設定してもよい。後者の場合、パラメータ決定部１０３は、全体の余り資源量に対する対象のリソースサーバ２の余り資源量の割合を考慮して、ポリシを選択するなどして、資源割当パラメータを決定してもよい。

また、パラメータ決定部１０３は、既に要求を受け付けている場合であって、要求に対して優先度が付与されている場合には、さらに要求の優先度に基づいて、資源割当パラメータを決定することも可能である。例えば、パラメータ決定部１０３は、優先度が高い要求程、短時間で割り当てられるようにしてもよい。また、パラメータ決定部１０３は、まず割当頻度を決定し、次に、予想される資源割り当てまでにかかる時間（割当所要時間）に応じて、１回の割当可能量を決定することも可能である。すなわち、割当所要時間が多ければ１回の割当可能量を増やしたり、割当所要時間が少なければ１回の割当可能量を減らすなどの調整を行ってもよい。

また、パラメータ決定部１０３は、さらに過去の割当状況を基に、過去の割当頻度が低い機能単位に優先して資源を割り当てるよう、割当順序ルールを決定してもよい。

例えば、本実施形態の資源割当システム１００は、機能単位１から直接要求された場合に限らず、図１７に示すような管理エンティティが、機能単位１の資源の使用状況をモニタリングした結果、資源使用率が閾値を超えたと判断した際に発行される資源割当要求に対して、上記の動作を行うことも可能である。なお、資源割当システム１００が管理エンティティとして、各機能単位から資源の使用状況をモニタリングし、資源を割り当てることも可能である。

このような場合においても、資源割当システム１００は、資源使用率が閾値を超えた機能単位１に対して、リソースサーバ２から取得した余り資源量に応じて定められる割当可能量を超えない範囲で資源を割り当てる。なお、割当可能量は、余り資源が少ないほど小さくなるものとする。なお、割当可能量を生成可能なインスタンス数としてもよい。

また、資源割当システム１００は、資源使用率が閾値を超えた機能単位１に対して、リソースサーバ２から取得した余り資源量に応じて定められる割当可能インターバルを基に、資源を割り当てる。例えば、資源割当システム１００は、資源を割り当てる際、前回割り当てを行った時から割当可能インターバルが経過するまでの間は、資源の割り当てを保留してもよい。

割当頻度の別の制御方法として、資源割当システム１００は、資源割当要求に対して、確率的な遅延を設けることができる。すなわち、資源割当システム１００は、受信した資源割当要求に対し、ある決められた値を平均とする確率分布（以下、遅延分布）を定め、資源割当要求ごとに当該確率分布に従って定められる遅延を設定することができる。このとき、資源割当部１０４は、設定された遅延時間経過後に、該資源割当要求に対して資源を割り当てる。また、別の確率的な遅延を設ける方法として、資源割当システム１００は、一定時間ごとに確率的に資源を割り当てるか否かを決定することができる。この場合、資源割当部１０４は、一定時間ごとに、要求バッファにある一つ以上の資源割当要求に対して、当該資源割当要求ごとに定められる確率（以下、資源割当確率）で資源を割り当てるかを決定する。こうすることで、確率的に遅延を設けることができる。

資源割当要求に対して確率的な遅延を設ける場合、その遅延分布または遅延割当確率は資源割当要求ごとに決めることができ、過去の割当状況や資源割当要求の要求度等に基づいて決定することができる。また、これらの資源割当要求ごとに定められる遅延分布または資源割当確率は省資源ポリシや高性能ポリシなどのポリシに基づいて定めることができる。例えば、省資源ポリシの場合は、遅延の平均値が大きくなるような遅延分布としたり、資源割当確率を小さく設定してもよい。逆に、高性能ポリシの場合は、遅延の平均値が小さくなるような遅延分布としたり、資源割当確率を大きく設定してもよい。

以上のように、本実施形態によれば、機能単位同士の関係性が不透明なサービスシステムに対して資源を割り当てる場合であっても、余り資源量や過去の割当状況に合わせて、資源の割り当ての応答速度を適切にできる。その結果、例えば、フロントエンドサービス側に資源が偏重して、後段の機能単位でサービスが混雑する前に資源が枯渇するなどといった機能単位間での資源割り当ての不均衡を抑制できる。

実施形態２．
次に、本発明の第２の実施形態を説明する。本実施形態では、例えば地理的に点在する複数の資源管理単位としてのデータセンタ（ＤＣ）間のネットワークが分断されても、他のＤＣを利用してサービスを継続できるようにする。このため、本実施形態では、複数のデータセンタにまたがって資源割り当てを行うことができるようにする。さらに、データセンタ間のネットワークが分断されてもサービスが継続できるよう、集中管理エンティティを置かない構成をとる。

より具体的に、本実施形態の資源割当システムは、ブロックチェーン技術を利用した分散台帳システムにおける分散的にコンセンサスを取る仕組みと、それによる共有情報保持機構とを利用して、データセンタ間で、要求に基づく割り当てに関する情報や、過去の割り当て状況の共有を行う。

まず、ブロックチェーン技術について簡単に説明する。ブロックチェーン技術は、特定の集中管理サーバに依存せず、分散的に情報共有を行うことができるアーキテクチャである。分散台帳システムに参加している各端末（後述する台帳管理ノード４２）が、ブロックチェーンにブロックを追加する際に所定のコンセンサスアルゴリズムに従う処理（以下、コンセンサス処理という）を行うことにより、改ざんが困難なブロックチェーンを端末間で共有する。

図４は、ブロックチェーン４１のデータ構造の例を示す説明図である。図４に示すように、ブロックチェーン４１は、ブロックと呼ばれる所定のデータ構造を備えたデータを繋げた構成をとる。また、ブロックの各々は、前のブロックのハッシュ値（図中の“Hash x”）、ノンス（図中の“nonce x”）、当該ブロックに格納するデータ（図中の“data x”）を含む。ここで、“x”はブロックを識別する識別子を表している。例えば、ブロックｎは、ブロックｎ−１のハッシュ値と、ノンスｎと、データｎとを含む。なお、データｎは、取引情報など、任意のデータでよい。

このような改ざんが困難なブロックチェーン４１を台帳として利用して、取引明細等のデータ、アプリケーション情報、その他の管理情報、認証情報といった情報を保持させることにより、情報の検証等に利用できる。

ここで、ノンスは、当該ブロックチェーン４１の改ざん耐性に影響する検証情報であり、具体的には、ＰｏＷ（Proof of Work）と呼ばれるコンセンサスアルゴリズムを実行する過程で設定される検証情報としての役割を持つ。

ＰｏＷでは、あるデータについて、そのデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように、当該データ内に含まれるノンス領域に設定する値を探す処理（以降、単にノンスを探す処理と呼ぶ）が行われる。

このとき、一方向性関数として、例えば、ハッシュ関数を用いることができる。また、そのときの規則を、「ハッシュ値が閾値（ターゲット値）以下であること」とすることができる。一般に、ノンスを探す処理は一方向性関数の性質から効率良く行うことができないため、当該処理を行う装置は、実際にはノンスに適当な値を設定して規則を満たすか否かを確認する作業を繰り返すこととなる。このような設定と確認の作業を多くのノードに並列して行わせ、最も早く規則を満たすノンスを見つけたノードが他のノードに情報を発信することにより、当該情報に基づいて全ノードに当該ノンスの値を含むデータの状態を確定させる（コンセンサスをとる）。

次に、そのようなブロックチェーン４１における一般的なブロック追加の流れを説明する。ブロックは、例えば、以下の（１）〜（５）のような動作が行われることにより、ブロックチェーン４１に追加される。

（１）ブロックチェーン４１に情報を記録したい端末は、該情報を当該ブロックチェーン４１に参加している端末のいずれかまたはその全てに通知する。
（２）各端末は通知された情報の整合性をチェックし、問題がなければブロックを生成する。
（３）各端末は生成されたブロックについてＰｏＷを開始する。
（４）ＰｏＷを終了した端末は、当該ＰｏＷで発見されたノンスを設定したブロックを全ての端末に通知する。
（５）ノンスが設定されたブロックを通知された端末は、ハッシュ値や、ブロックに記憶されている情報の整合性をチェックし、問題なければ自身が管理しているブロックチェーン４１の末尾にブロックを追加する。

なお、上記の（２）の動作において、通知された情報の整合性のチェック方法は、当該ブロックチェーン４１を利用するアプリケーションに依存する。また、ブロックを生成する際に、複数の情報を１つのブロックにまとめることが可能である。

また、上記の（３）のＰｏＷ動作において、各端末は、さらに次の動作を行う。
（３−１）各端末は、まず生成したブロックにランダムなノンス（ノンスの候補）を設定する。
（３−２）次いで、各端末は、ブロックのハッシュ値が所定の規則を満たすか（例えば、あるターゲット値以下であるか）を確認する。
（３−３）規則を満たしていれば、処理を終了し、満たしていなければ、設定したノンスを変更し、（３−２）に戻る。

なお、情報が通知された全ての端末が上記の（３）のＰｏＷ動作を同時に平行して行う。そして、ＰｏＷを最も早く終了した端末は、ブロックチェーン４１にブロックを追加する権利を得た端末とみなされる。

図５は、台帳管理システム４が備える台帳管理ノード４２の例を示すブロック図である。台帳管理システム４は、２以上の台帳管理ノード４２（図示省略）を備えており、ブロックチェーンに新たなブロックを追加する際に、各台帳管理ノードが所定のコンセンサス処理を行い、ブロックチェーン４１のコピーを保持する。なお、台帳管理システム４におけるコンセンサスアルゴリズムは、ＰｏＷに限定されない。例えば、ＰｏＷ以外にもＢＦＴ（Byzantine fault tolerance）等のコンセンサスアルゴリズムも利用可能である。

図５に示す台帳管理ノード４２は、データ受付部４２１と、ブロック生成部４２２と、ブロック共有部４２３と、情報記憶部４２４と、ブロック検証部４２５と、データ出力部４２６とを含む。

データ受付部４２１は、外部ノードから、ブロックチェーン４１に記録する情報を受け付ける。本実施形態では、データ受付部４２１は、ブロックチェーン４１に記録する情報として、後述する資源割当要求（トランザクション）に基づく割当情報等を受け付ける。

ブロック生成部４２２は、データ受付部４２１が受け付けた情報を用いて、ブロックチェーンに追加するブロックを生成する。ブロック生成部４２２は、前ブロックに基づく情報（Ｈａｓｈ値等）と、データ受付部４２１が受け付けた情報とを含むブロックを生成する。また、ブロック生成部４２２は、自身が生成したブロックまたは後述するブロック共有部４２３を介して他の台帳管理ノード４２が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理や署名を付与する処理を行った上で、自身が管理するブロックチェーン（ブロックチェーン４１のコピーに相当）にブロックを追加する。なお、ブロック生成部４２２が生成したブロックに対して、複数の台帳管理ノード４２が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン４１に追加されるブロックとなる。以下、コンセンサス処理を含む、ブロックチェーンにブロックを追加するための処理を、マイニングと呼ぶ場合がある。また、マイニングを行うノードをマイナーと呼ぶ場合がある。

ブロック共有部４２３は、台帳管理システム４に属する台帳管理ノード４２間で情報交換を行う。ブロック共有部４２３は、より具体的には、データ受付部４２１が受け付けた情報や、ブロック生成部４２２が生成したブロックや、他の台帳管理ノード４２から受け付けたブロック等を、適宜他の台帳管理ノード４２に送信する。これにより、可能な限り全ての台帳管理ノード４２でこれらの情報および最新のブロックチェーン４１を共有する。

情報記憶部４２４は、ブロックチェーン４１のコピーを記憶する。なお、情報記憶部４２４は、ブロックチェーン４１のコピー以外にも、例えば、後述するブロック検証部４２５での検証処理に必要な情報などを記憶してもよい。

ブロック検証部４２５は、自身が保持するブロックチェーンにブロックを追加する際に、該ブロック内の検証を行う。例えば、ブロック検証部４２５は、追加するブロックが実際に規則を満たしているか、ブロックを作成したノードと署名が一致するか、追加するブロックに含まれる前ブロックに基づく情報が実際の前ブロックから生成した情報と一致するかなどを検証してもよい。

データ出力部４２６は、外部ノードからの要求に応じて、自身が保持するブロックチェーン４１の中から所望の情報を含むブロックを検索して出力する。

なお、図５の構成はあくまで一例であって、台帳管理ノード４２は、上記の特徴を有するブロックチェーン４１を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて台帳への情報追加および台帳の参照が可能なノードであれば、具体的な構成は問わない。

次に、本実施形態でのブロックチェーンの利用方法を説明する。図６は、本実施形態の概要を示す説明図である。図６に示すように、本実施形態では、資源の管理単位であるデータセンタ（ＤＣ）３に、ＰｏＷの実行ノードであるマイナー（台帳管理ノード４２）を設ける。そして、ＤＣ３の各々で、自身が保持しているブロックチェーン４１と自身が管理するリソースサーバ２とから、ローカルで資源の割当状況や余り資源量を収集し、当該ＤＣ３における資源割当ポリシ（応答時間やどの機能単位に資源を割り当てるか等）を決定する。その上で、決定した資源割当ポリシに従い、処理対象とする要求や該要求に基づく割当内容等を含むブロックを生成し、該ブロックについてＰｏＷを利用して分散的にコンセンサスを取る。なお、本実施形態では、機能単位１や監視エンティティ１Ａは、資源割当要求を、資源の割り当てを望む全てのリソースサーバ２に送付する。

このようにすると、各ＤＣにおける資源の割り当ての際に、より多くのマイナーに支持されるポリシが選ばれやすくなる。これは、例えば、２つのマイナーが決定した資源割当ポリシは、該マイナーの各々により作成される計２つのブロックに反映されてコンセンサス処理に供されるので、１つのマイナーに支持されるポリシに比べてマイニングにかけられる計算量が２倍になるためである。

各ＤＣでは、ポリシに従い、ブロックに含めるトランザクション（要求）の内容や数を変更することで１回の割り当て制御における割当可能量を制御できるだけでなく、マイニング時のパラメータ（特に、コンセンサス処理の難易度に関するパラメータ）を変更することで、割当タイミングも制御できる。

図６に示す例は、機能単位Ａ、機能単位Ｄおよび機能単位Ｅがそれぞれ、資源割当要求を、ＤＣα、ＤＣβおよびＤＣγに送付した例である。このとき、ＤＣαが管理するリソースサーバ２の資源利用状況が“平常状態（通常時並みに余裕がある状態）”であったとする。一方、ＤＣβが管理するリソースサーバ２の資源利用状況が“逼迫状態（余裕がない状態）”であったとする。また、ＤＣγが管理するリソースサーバ２の資源利用状況が“空き状態（余裕が大きい状態）”であったとする。

このような場合、ＤＣαは、自身が持つ情報を基に、例えば、“優先度順”という資源割当ポリシを決定する。また、ＤＣβは、自身が持つ情報を基に、例えば、“少資源優先”という資源割当ポリシを決定する。また、ＤＣγは、自身が持つ情報を基に、例えば、“高速応答”という資源割当ポリシを決定する。ここで、“優先度順”は、自身が割り当てられる範囲内で、優先度が高い要求に対して優先的に資源を割り当てるポリシである。また、“少資源優先”は、自身が割り当てられる範囲内で、要求量が少ない要求に対して優先的に資源を割り当てるポリシである。また、“高速応答”は、自身が割り当てられる範囲内で、受け付けた順に即座に資源を割り当てるポリシである。

このようにして、同じ要求の受け付け状態であっても、ＤＣごとに、自身の資源の利用状況に従って決定されるポリシが決定される。そのようにして決定したポリシに基づき、選択される要求やその数が異なりうるブロックが生成され、各ＤＣ内でコンセンサス処理に供される。その結果、最も早くコンセンサスがとれたブロックがブロックチェーン４１に追加され、各ＤＣで共有される。ブロックチェーン４１にブロックが追加されると、各ＤＣは、追加されたブロックに含まれる情報に従って、資源の割り当てを行う。例えば、各ＤＣは、ブロックに、各要求に付与された識別子を含ませ、ブロックチェーンにどの要求が登録されたかがわかるようにしてもよい。

また、このような動作の繰り返しにより、ブロックチェーン４１にはシステム全体における過去の割当状況が保持されることとなる。したがって、各ＤＣは、他のＤＣ３に毎度問い合わせなくても、自身が管理するリソースサーバ２における最新の利用状況だけでなく、他のＤＣ３を含むシステム全体における過去の割当状況を取得できる。

図７は、第２の実施形態の資源割当システムの構成例を示すブロック図である。本実施形態の資源割当システム１００は、例えば、１つ以上の機能単位１や、それら機能単位１を監視する監視エンティティ１Ａなどを含むサービスシステム２００において、機能単位１に対して資源提供部２Ａが保有する資源を割り当てる資源割当システムとして動作する。

図７に示す資源割当システム１００は、１つ以上のデータセンタ（ＤＣ）３を備える。なお、ＤＣ３の各々は、ネットワークを介して互いに接続されている。

ＤＣ３の各々は、資源提供部２Ａと、台帳管理部３１と、利用状況取得部３２と、パラメータ決定部３３と、資源割当部３４とを備える。なお、ＤＣ３は、任意の資源の管理単位であって、地理的および物理的な構成は特に限定されない。また、図７では、１つのＤＣ３に対して１つの資源提供部２Ａが割り当てられているが、サービスシステム２００が備える２以上の資源提供部２Ａのうちのいずれか１つ以上の資源提供部２Ａが割り当てられていればよく、資源提供部２Ａの数は特に限定されない。

本例では、各ＤＣ内の台帳管理部３１が上記のマイナーとして動作する。また、機能単位１や監視エンティティ１Ａ等の資源割当要求を送付するノードが、ブロックチェーン４１を利用するエンティティとして動作する。典型的には、各エンティティは、秘密鍵、公開鍵のペアを持ち、秘密鍵でトランザクションに署名を付加してマイナー（本例では、自ＤＣ内の台帳管理部３１）に送付する。マイナーは、送付されたトランザクションに基づき、ブロックを生成し、コンセンサス処理を経てブロックチェーンへブロックを追加する。各エンティティは、システムに参加する際、他のエンティティ等からマイナーの情報を取得可能とする。

なお、図７では、１つのブロックチェーン４１を示しているが、ブロックチェーン４１は、実際には台帳管理システム４に含まれる台帳管理ノード４２としての台帳管理部３１の各々に保持される。

また、本例において、資源提供部２Ａ、台帳管理部３１、利用状況取得部３２、パラメータ決定部３３および資源割当部３４は、それぞれ第１の実施形態のリソースサーバ２、資源利用状況管理部１０１、利用状況取得部１０２、パラメータ決定部１０３および資源割当部１０４に相当する。なお、本実施形態では、台帳管理部３１が、さらにパラメータ決定部１０３の機能の一部を担う。

資源提供部２Ａは、当該ＤＣで割り当て可能な資源を管理する。

台帳管理部３１は、例えば、図５に示した台帳管理ノード４２の各構成要素を備える。本実施形態では、台帳管理部３１は、後述するパラメータ決定部３３より、ブロックに含ませる要求（トランザクション）およびマイニングパラメータが指定されると、該トランザクションを含むブロックを生成して、指定されたマイニングパラメータに従ってマイニングを行う。そして、台帳管理部３１は、マイニングが成功すると、自身のブロックチェーン４１に追加するともに、他の台帳管理部３１間で共有処理を行う（マイニングが成功したブロックを送付する）。また、台帳管理部３１は、自身が管理するブロックチェーン４１に新たにブロックが追加された場合に、その旨をパラメータ決定部３３または資源割当部３４に通知してもよい。

利用状況取得部３２は、所定のタイミングで、資源提供部２Ａおよびブロックチェーン４１（より具体的には、台帳管理部３１の情報記憶部４２４に保持されるブロックチェーン４１のコピー）から、自ＤＣにおける資源利用状況および各ＤＣでの過去の資源割当状況を取得する。所定のタイミングは、特に問わないが、一例として、一定の周期ごと、資源割当要求を受信したとき、資源割当要求を受信した後一定時間経過後などが挙げられる。

パラメータ決定部３３は、利用状況取得部３２によって取得された情報を基に、マイニングブロックに含ませる要求の選択方法およびマイニングパラメータを決定する。ここで、マイニングブロックは、マイナーがマイニングの対象とするブロックである。また、マイニングブロックに含ませる要求の選択方法は、次の割り当て処理の対象とする要求を選択する方法であって、例えば、何を基準に、かつどれだけの量の要求を選択するかを規定する。また、マイニングパラメータは、マイニングの所要時間を決定づけるパラメータなど、コンセンサス処理の難易度に関するパラメータであればよく、例えば、ＰｏＷのターゲット値である。

例えば、パラメータ決定部３３は、予め要求の選択方法とマイニングパラメータの組が設定された資源割当ポリシの中から１つのポリシを選択することにより、要求の選択方法およびマイニングパラメータを決定してもよい。

また、パラメータ決定部３３は、要求の選択方法およびマイニングパラメータが決定すると、決定した選択方法または該選択方法に従って選択した要求（トランザクション）を指定したブロック追加要求を、マイニングパラメータとともに台帳管理部３１に通知する。このとき、パラメータ決定部３３は、選択した要求について、当該ＤＣで受け付けた要求量とは異なる要求量に変更することも可能である。

資源割当部３４は、台帳管理部３１が管理するブロックチェーン４１にブロックが追加されると、該ブロックに含まれるトランザクションを基に、資源の割り当てを行う。例えば、資源割当部３４は、該ブロックに含まれるトランザクションに対して、自身が可能な範囲内で資源を割り当ててもよい。

次に、本実施形態の動作を説明する。図８は、本実施形態の資源割当システム１００におけるＤＣ３の動作例を示すフローチャートである。

図８に示す例では、まず、各ＤＣ３が資源割当要求を受け付ける（ステップＳ２０１）。ここで受け付けた資源割当要求は逐次バッファリングされる。資源割当要求の送信元は、特に問わない。例えば、機能単位１であってもよいし、監視エンティティ１Ａであってもよい。

次いで、利用状況取得部３２は、自ＤＣで保持している情報から自ＤＣにおける資源利用状況および各ＤＣでの過去の資源割当状況を取得する（ステップＳ２０２）。ステップＳ２０２でｈ、利用状況取得部３２は、例えば、自ＤＣにおける資源利用状況および各ＤＣでの過去の資源割当状況を取得する。

次いで、パラメータ決定部３３は、取得された情報を基に、マイニングブロックに含ませる要求の選択方法およびマイニングパラメータを決定する（ステップＳ２０３）。

次いで、台帳管理部３１が、決定された選択方法に従い、受け付けた要求の中から選択された要求を含むマイニングブロックを生成し、該マイニングブロックに対して、決定されたマイニングパラメータに従いマイニングを行う（ステップＳ２０４）。ここで、マイニングブロックには、資源割当要求に基づく資源の割り当て情報（どの機能単位にどれだけの資源を割り当てるかを示す情報）が含まれるものとする。

なお、ステップＳ２０４の動作は各ＤＣで同時並列的に行われる。一般に、最も早くマイニングを成功したブロックが共有処理により、各ＤＣのブロックチェーン４１に追加される。なお、各ＤＣの台帳管理部３１は、検証の結果、ブロックの追加を拒否することも可能である。

ブロックチェーン４１に新たなブロックが追加されると、資源割当部３４が、該ブロックに含まれる情報に基づいて、資源を割り当てる（ステップＳ２０５）。

各ＤＣは、例えば、ブロックが追加されて１回の割り当て制御を終える度に、次の割り当て制御に移る（ステップＳ２０２に戻る）。各回の割り当て制御では、それまでに届いている要求を対象に、ステップＳ２０２〜ステップＳ２０５の動作を行えばよい。

図９は、マイニングブロックに含ませる要求の選択方法の例を示す説明図である。図９に示す例において、ＤＣαの管理対象の資源提供部２Ａの資源利用状況は“空き状態”であり、ＤＣβおよびＤＣγの管理対象の資源提供部２Ａの資源利用状況はそれぞれ“逼迫状態”である。また、各ＤＣの要求バッファには、機能単位Ａからの資源割当要求（“トランザクションＡ”）と、機能単位Ｂからの資源割当要求（“トランザクションＢ”）と、機能単位Ｃからの資源割当要求（“トランザクションＣ”）とがこの順で格納されている。なお、“トランザクションＡ”の要求量は、“トランザクションＢ”および“トランザクションＣ”の要求量よりも少ない。

このような場合、ＤＣαのパラメータ決定部３３は、資源割当ポリシとして上述した“高性能ポリシ”を選択してもよい。“高性能ポリシ”は、１回の制御で多くの資源を割り当てるポリシである。当該ポリシが選択されると、例えば、要求バッファに格納されている要求が全て選択される。また、ＤＣβおよびＤＣγのパラメータ決定部３３は、資源割当ポリシとして上述した“省資源ポリシ”を選択してもよい。“省資源ポリシ”は、優先度が低い要求を破棄したり、要求量が少ない要求を優先するなどして、１回の制御あたりで割り当てる資源量を少なくするポリシである。当該ポリシが選択されると、例えば、要求バッファに格納されている要求の中から、要求の優先度および要求量に基づいて所定数の要求が選択される。このとき、選択されなかった残りの要求は要求バッファに格納されたままとなるが、要求を受信してから一定時間経過後、破棄することができる。

なお、図９には、ＤＣαのマイニングブロックとして、“トランザクションＡ”、“トランザクションＢ”および“トランザクションＣ”を含むブロックが生成される例が示されている。また、ＤＣβおよびＤＣγのマイニングブロックとして、“トランザクションＡ”を含むブロックが生成される例が示されている。

また、図１０は、マイニングブロックに含ませる要求の選択方法の他の例を示す説明図である。図１０に示す例において、ＤＣα、ＤＣβおよびＤＣγの管理対象の資源提供部２Ａの資源利用状況はいずれも“平常状態”である。また、本例における各ＤＣの要求バッファの状態は、図９と同様である。また、本例において、ブロックチェーン４１が示す各ＤＣでの過去の割当状況より、機能単位Ｂ＞機能単位Ａ＞機能単位Ｃという機能単位１に対する割当頻度の関係が把握される。

このような場合、各ＤＣのパラメータ決定部３３は、“頻度優先ポリシ”を選択してもよい。“頻度優先ポリシ”は、例えば、予め定められた数の要求を含ませるものとし、その際に、割当頻度が低い機能単位からの要求ほど、高い確率でブロックに含ませるポリシである。なお、当該ポリシは、他のポリシと独立して選択されてもよいし、他のポリシと組み合わせて選択されてもよい。“頻度優先ポリシ”は、例えば、他のポリシによって選択された要求数に対して、優先順位を定めるために用いることができる。

また、例えば、パラメータ決定部３３は、自ＤＣ内の資源利用状況に基づく制御と、各ＤＣでの過去の過去の割当状況に基づく制御の結果を基に、最終的な要求の選択方法を決定してもよい。

次に、マイニングパラメータの決定方法について説明する。パラメータ決定部３３は、例えば、管理対象の資源提供部２Ａの余り資源量に応じて、ＰｏＷのターゲット値を決定してもよい。一例として、資源が余っているほど、ターゲット値を高く（マイニングを簡単に）してもよい。マイニングを簡単にすることで、早い応答速度にできる。

また、パラメータ決定部３３は、例えば、マイニングブロックに含まれる要求に応じて、ＰｏＷのターゲット値を決定してもよい。一例として、ブロック内の要求群の優先度が高いほど、ターゲット値を高く（マイニングを簡単に）してもよい。これに関連して、パラメータ決定部３３は、台帳管理部３１においてマイニングブロックのマインング中に、自ＤＣが新たに高い優先度の要求を受け付けた場合、マイニングブロックを再構成してもよい。その場合、パラメータ決定部３３は、台帳管理部３１に現在のマイニングを中止させ、再構成したマイニングブロックを通知し、マイニングをやり直させる。

このような要求の優先度に基づく制御によって、優先度が低い要求に対して過度に資源が割り当てられるのを抑制できる。図１１は、マイニングパラメータの決定方法の例を示す説明図である。図１１に示す例では、優先度に基づいてターゲット値を設定する例である。

また、図１２は、割当可能量の制御例を示す説明図である。各マイナー（より具体的には、台帳管理部３１やパラメータ決定部３３や資源割当部３４）は、制御対象とされたブロックのマイニングの所要時間に応じて、割当可能量を変更してもよい。ここで、マイニングの所要時間は、見積もり時間であっても、実際に要した時間であってもよく、また実質的に前ブロックが追加されてから該ブロックが追加されるまでの経過時間でもよい。一例として、所要時間が短いほど割当可能量を少なくし、所要時間が長いほど割り当て量を多くしてもよい。

本実施形態では、ＤＣの各々で、マイナーとされる管理装置等が自ＤＣ内にある情報に基づいて、マイニングブロックに含ませる要求を選択し、また、マイニングパラメータを設定する。そして、各ＤＣのマイナーが別々のポリシで作成した異なるマイニングブロックを別々のポリシで設定したマイニングパラメータを用いてマイニングする。各マイナーのマイニングの結果、コンセンサスがとられ、各ＤＣにてブロックチェーンにブロックが追加される。ブロックが追加されると、追加されたブロックに記録された情報に従って、各ＤＣが資源を割り当てる。

なお、各ＤＣは、ブロックに、処理対象とする要求（トランザクション）ではなく、資源割当ポリシそのものを記録してもよい。その場合、各ＤＣは、自身が持つブロックチェーン４１に新たなブロックが追加されたタイミングで、該ブロックに記録された資源割当ポリシに従った資源の割り当てを行う。この場合、ブロックの追加タイミングが、資源割当ポリシの更新タイミングとされる。このようなブロックに含ませる情報の例として挙げた要求やその識別子、選択された要求に基づいて決定した割り当て内容、資源割当ポリシ等をまとめて、「資源割当要求に基づく割当に関する割当情報」と呼ぶ場合がある。

このように、本実施形態では、分散台帳システムのＰｏＷに基づくコンセンサス処理を利用して、資源の割り当ての応答速度を調整する。結果として、各エンティティの独立性を保ったまま、システム全体でバランスのとれた資源割り当てが可能になる。例えば、図９に示す例では、特定のＤＣのみ資源に余裕がある場合でも、省資源ポリシが採用されやすくなるなど、偏った要求や情報収集により生じる資源の枯渇や偏重を抑制できる。

次に、本発明の実施形態にかかるコンピュータの構成例を示す。図１３は、本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ１０００は、ＣＰＵ１００１と、主記憶装置１００２と、補助記憶装置１００３と、インタフェース１００４と、ディスプレイ装置１００５と、入力デバイス１００６とを備える。

上述した機能単位１やＤＣ３内の各構成要素や台帳管理ノード４２は、例えば、コンピュータ１０００に実装されてもよい。その場合、これら各装置（機能単位、構成要素、ノードを実装した装置）の動作は、プログラムの形式で補助記憶装置１００３に記憶されていてもよい。ＣＰＵ１００１は、プログラムを補助記憶装置１００３から読み出して主記憶装置１００２に展開し、そのプログラムに従って上記の実施形態における所定の処理を実施する。

補助記憶装置１００３は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース１００４を介して接続される磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ１０００に配信される場合、配信を受けたコンピュータは１０００がそのプログラムを主記憶装置１００２に展開し、上記の実施形態における所定の処理を実行してもよい。

また、プログラムは、各実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置１００３に既に記憶されている他のプログラムとの組み合わせで上記の実施形態における所定の処理を実現する差分プログラムであってもよい。

インタフェース１００４は、他の装置との間で情報の送受信を行う。また、ディスプレイ装置１００５は、ユーザに情報を提示する。また、入力デバイス１００６は、ユーザからの情報の入力を受け付ける。

また、実施形態における処理内容によっては、コンピュータ１０００の一部の要素は省略可能である。例えば、装置がユーザに情報を提示しないのであれば、ディスプレイ装置１００５は省略可能である。

また、各装置の各構成要素の一部または全部は、汎用または専用の回路（Circuitry）、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。

各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。

次に、本発明の資源管理システムの概要を説明する。図１４は、本発明の資源割当システムの概要を示すブロック図である。図１４に示す資源割当システム５００は、資源割当部５０１と、２以上の資源提供部５０２と、余り資源量取得部５０３と、パラメータ決定部５０４とを備える。

資源割当部５０１（例えば、資源割当部１０４、資源割当部３４）は、所定の機能をサービスとして提供する１つ以上の機能単位に、サービスを実行するための資源を割り当てる。

資源提供部５０２（例えば、リソースサーバ２、資源提供部２Ａ）は、資源を提供する。

余り資源量取得部５０３（例えば、利用状況取得部１０２、利用状況取得部３２）は、２以上の資源提供部のうちの所定の資源提供部から余り資源量を取得する。

パラメータ決定部５０４（例えば、パラメータ決定部１０３、パラメータ決定部３３）は、取得された余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、１回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも１つを決定する。

このような構成により、機能単位同士の関係性が不透明なサービスシステムに対して資源を割り当てる場合であっても、適切な応答速度で資源の割り当てが行えるので、機能単位間での資源割り当ての不均衡を抑制できる。

また、図１５は、本発明の資源割当システムの他の構成例を示すブロック図である。本発明の資源割当システム５００は、例えば、図１５に示す構成であってもよい。

すなわち、資源割当システム５００は、２以上の資源提供部５０２における資源の割当状況を管理する割当状況管理部５０５と、２以上の資源提供部５０２が提供する資源の管理単位としての複数のデータセンタとをさらに備えていてもよい。そして、これらデータセンタのいずれかに配置される管理装置を備え、各管理装置が、資源割当部５０１、余り資源量取得部５０３、パラメータ決定部５０４および割当状況管理部５０５を含んでいてもよい。

このような構成において、資源割当部５０１は、機能単位に、自データセンタの管理対象の資源より資源を割り当てる。

また、余り資源量取得部５０３は、管理対象の資源を提供する資源提供部から余り資源量を取得する。

また、パラメータ決定部５０４は、余り資源量に基づいて、資源割当部において資源の割り当て制御を行うタイミングである割当タイミング、１回の割り当て制御において割り当て可能な資源量である割当可能量および割り当てる際の優先順位のうち少なくとも１つを決定する。

また、割当状況管理部５０５（例えば、資源利用状況管理部１０１、台帳管理部３１）は、他のデータセンタに配置された割当状況管理部５０５（不図示）との間で、所定のコンセンサス処理を経てデータセンタのいずれかに対する資源割当要求に基づく割当に関する割当情報を含むブロックが追加されるブロックチェーンを共有することにより、割当状況を管理する。そして、資源割当部５０１が、パラメータ決定部５０４による決定に基づいて行われるコンセンサス処理の結果、ブロックチェーンに記録された情報に基づいて、資源の割り当てを行う。

このような構成によれば、台帳管理システムにおける分散的にコンセンサスを取る仕組みと、それによる共有情報保持機構とを利用することにより、データセンタ内の情報だけで、適切な応答速度で資源の割り当てが行えるので、機能単位間での資源割り当ての不均衡を抑制できる。

以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

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

１００ 資源割当システム
１０１ 資源利用状況管理部
１０２ 利用状況取得部
１０３ パラメータ決定部
１０４ 資源割当部
２００ サービスシステム
１ 機能単位
１Ａ 監視エンティティ
２ リソースサーバ
２Ａ 資源提供部
３ ＤＣ
３１ 台帳管理部
３２ 利用状況取得部
３３ パラメータ決定部
３４ 資源割当部
４ 台帳管理システム
４１ ブロックチェーン
４２ 台帳管理ノード
４２１ データ受付部
４２２ ブロック生成部
４２３ ブロック共有部
４２４ 情報記憶部
４２５ ブロック検証部
４２６ データ出力部
１０００ コンピュータ
１００１ ＣＰＵ
１００２ 主記憶装置
１００３ 補助記憶装置
１００４ インタフェース
１００５ ディスプレイ装置
１００６ 入力デバイス
５００ 資源割当システム
５０１ 資源割当部
５０２ 資源提供部
５０３ 余り資源量取得部
５０４ パラメータ決定部
５０５ 割当状況管理部

Claims (13)

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

Images