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

Abstract

本発明の資源管理システムは、所定の機能をサービスとして提供する１つ以上の機能単位５０１と、機能単位５０１にサービスを実行するための資源を割り当てる資源割当部５０２と、ユーザおよび機能単位５０１の各々について、サービスを受けるために必要な仮想通貨であるポイントの保有数を管理するポイント管理部５０３とを備え、機能単位５０１の各々は、サービスを、要求元のユーザまたは他の機能単位が保有するポイントと引き換えに提供し、資源割当部５０２は、資源を、割り当て先の機能単位が保有するポイントを減じることにより割り当てる。

Description

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

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

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

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

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

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

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

課題は、悪意のあるユーザや機能単位が存在していたときに、不適切な資源の割り当てが行われてしまうことである。一例として、悪意のあるユーザや機能単位が、資源が不足していないにも関わらず資源要求を行い、それを基に管理エンティティが資源を割り当ててしまう状況が挙げられる。そのような資源要求を防ぐため、上述したようなモニタリングを行うことが考えられる。

しかし、モニタリングを行う場合であっても、例えば、１つの機能単位が、悪意のあるユーザからサービス提供が伴わない空の要求等を繰り返し受信すると、サービス提供の実態がない状況でも資源が不足する状況になりうる。また、例えば、ある機能単位がウィルス等に感染した場合、実際にサービス提供を行っていないにも関わらず、他の処理等で資源を使用するなどしてサービス提供のための資源が不足しているように見せかけることができる。すると、そのような状況を検知した管理エンティティが過大なリソースを割り当ててしまう場合がある。

そのようなサービス提供の実態が伴っていない機能単位に対して多くの資源が割り当てられると、他の機能単位等で実際にサービス提供のために資源が必要となった場合に、割り当てられる資源が不足するといった問題が生じる。

本発明は、上述した課題に鑑みて、サービス提供の実態と合致した資源の割り当てが可能な資源管理システム、管理装置、資源管理方法および資源管理プログラムを提供することを目的とする。

本発明による資源管理システムは、所定の機能をサービスとして提供する１つ以上の機能単位と、機能単位にサービスを実行するための資源を割り当てる資源割当部と、ユーザおよび機能単位の各々について、サービスを受けるために必要な仮想通貨であるポイントの保有数を管理するポイント管理部とを備え、機能単位の各々は、サービスを、要求元のユーザまたは他の機能単位が保有するポイントと引き換えに提供し、資源割当部は、資源を、割り当て先の機能単位が保有するポイントを減じることにより割り当てることを特徴とする。

また、本発明による管理装置は、ユーザおよび所定の機能をサービスとして提供する１つ以上の機能単位の各々について、サービスを受けるために必要な仮想通貨であるポイントの保有数を把握可能なポイント管理情報を保持する情報保持部と、機能単位におけるサービスの提供に応じて要求元のユーザまたは他の機能単位から要求先の機能単位へポイントを移動させる処理および機能単位への資源の割り当てに応じて割り当て先の機能単位が保有するポイントを減少させる処理を、情報保持部に保持されているポイント管理情報を更新または追記することにより行うポイント更新部とを備えたことを特徴とする。

また、本発明による資源管理方法は、所定の機能をサービスとして提供する１つ以上の機能単位と、機能単位にサービスを実行するための資源を割り当てる資源割当部とを備えた資源管理システムにおける資源管理方法であって、１つ以上の情報処理装置が、ユーザおよび機能単位の各々について、サービスを受けるために必要な仮想通貨であるポイントの保有数を管理し、機能単位におけるサービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へポイントを移動させ、機能単位への資源の割り当てに応じて、割り当て先の機能単位が保有するポイントを減少させることを特徴とする。

また、本発明による資源管理プログラムは、コンピュータに、ユーザおよび所定の機能をサービスとして提供する１つ以上の機能単位の各々について、サービスを受けるために必要な仮想通貨であるポイントの保有数を管理する処理、機能単位におけるサービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へポイントを移動させる処理、および機能単位への資源の割り当てに応じて、割り当て先の機能単位が保有するポイントを減少させる処理を実行させることを特徴とする。

本発明によれば、サービス提供の実態と合致した資源の割り当てが可能となる。

本発明の概要を示す説明図である。 ポイントの使用例を示す説明図である。 第１の実施形態の資源管理システムの構成例を示すブロック図である。 第１の実施形態の資源管理システムの他の構成例を示すブロック図である。 ブロックチェーン４１のデータ構造の例を示す説明図である。 ブロックチェーン４１の改ざん耐性を説明するための説明図である。 台帳管理システム４が備える台帳管理ノード４２の例を示すブロック図である。 管理情報の例を示す説明図である。 資源管理部３の動作の一例を示すブフローチャートである。 サービス呼び出し先のエンティティ（機能単位１）の動作例を示すフローチャートである。 サービス呼び出し側のエンティティの動作例を示すフローチャートである。 機能単位１の動作例を示すフローチャートである。 ブロックチェーンの管理方法の例を示す説明図である。 第２の実施形態の概要を示す説明図である。 機能単位１におけるマイニング処理のタイミングの例を示す説明図である。 第２の実施形態の資源管理システムの構成例を示すブロック図である。 第３の実施形態の概要を示す説明図である。 空き時間の例を示す説明図である。 本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。 本発明の資源管理システムの概要を示すブロック図である。 マイクロサービスを利用したサービス提供プログラムの例を示す説明図である。 ＭＳＡにおける資源管理方法の例を示す説明図である。

以下、本発明の実施形態を、図面を参照して説明する。まず、本発明のコンセプトを簡単に説明する。図１は、本発明の概要を示す説明図である。本発明は、ポイント（仮想通貨）を用いて、各機能単位におけるサービスの利用状況を管理する。そして、該ポイントに基づいて、機能単位に対する資源の割当量を決定する。

機能単位におけるサービス提供の利用状況を管理するために、本発明では、より具体的に、サービス提供のエンドポイントとなるユーザに対して一定数のポイントを付与する。ここで、ポイントは、実際にユーザが使用する端末等に付与してもよいが、管理データ上でのみの付与であってもよい。

図２は、本発明におけるポイントの使用例を示す説明図である。図２に示すように、本発明では、ユーザは、サービスを利用する毎に要求先の機能単位に対してポイントを支払う。また、各機能単位も、他の機能単位を利用する毎に利用先の機能単位に対してポイントを支払う。このようにして、各機能単位に支払われたポイント数により、サービス提供の実態が表わされるようにする。そして、そのようなサービス提供の度に増加または減少するポイントを使って、各機能単位に資源を割り当てる。例えば、管理エンティティは、各機能単位に、資源獲得時やその後定期的に、当該ポイントで資源使用料を支払わせる。また、管理エンティティは、資源使用料を支払えない場合、資源を割り当てないまたは取り上げる（解放する）等の措置を行う。

また、このようなポイントの移動を、サービスの利用情報、資源の割当情報などとともに、システムが保有する１つ以上の情報保持基盤によって管理する。ここで、情報保持基盤は、記憶装置やデータベースシステムといった、情報を保持できる基盤であれば特に問わないが、情報を複数の装置で共有できるブロックチェーンがより好ましい。

実施形態１．

図３は、第１の実施形態の資源管理システム１００の構成例を示すブロック図である。図３に示す資源管理システム１００は、複数の機能単位１と、ポイント管理部２と、資源管理部３とを備える。

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

本実施形態の機能単位１は、サービス提供部１１と、ポイント記録部１２とを含む。

サービス提供部１１は、要求に応じて所定の機能を提供する。

ポイント記録部１２は、ユーザまたは他の機能単位から要求を受け付けた場合や他の機能単位に要求を行った場合など、自身が保有するポイントに変化が生じた場合に、その変化を、後述するポイント管理部２に通知し、記録させる。このとき、ポイント記録部１２は、変化したポイント数だけでなく、支払先、支払い元、支払い対象（サービス利用／資源利用等）など、ポイントの取引明細を通知してもよい。

ポイント記録部１２は、例えば、サービス提供部１１に対するモニタリングやサービス提供部１１からの通知により、自身（当該ポイント記録部１２を有する機能単位１）が保有するポイントの変化を検出してもよい。また、ポイント記録部１２は、保有ポイントに変化が生じる度に通知するとトランザクションが多くなりすぎる場合は、一定時間毎や一定回数毎に、前回からの変化をまとめて通知してもよい。

ポイント管理部２は、ユーザおよび機能単位１を含む各エンティティについて、ポイントの保有数を管理する。例えば、ポイント管理部２は、システム内での該ポイントの流れを全て記憶することにより、各エンティティのポイントの保有数を管理する。また、ポイント管理部２は、システムまたは各機能単位でサービス利用に必要なポイント数など、各機能単位におけるサービス利用条件を管理してもよい。

また、ポイント管理部２は、システム内でポイントを循環させるために、ユーザに対して、一定時間ごとにポイントを回復させる。このとき、回復後のポイントが、ユーザが保持可能なポイントの上限を超えないものとする。また、ユーザおよび機能単位１の各々に、予め初期ポイントが付与されてもよい。例えば、ユーザのシステム加入時に、初期ポイントが付与されてもよい。なお、ユーザのポイント回復や初期ポイントの付与を行う処理部は特に限定されず、資源管理部３や、別途設けたユーザ管理部（不図示）などが行ってもよい。

ポイント管理部２は、各エンティティのポイントの保有数を管理するために、例えば、各エンティティの保有ポイントを把握可能な情報を保持する情報保持部２１と、各エンティティからの要求または所定の条件に応じて、上記の情報保持部に保持されている保有ポイントを把握可能な情報を更新または追記することにより、ポイントを移動または増減させるポイント更新部２２とを含んでいてもよい。

資源管理部３は、当該システムの資源を管理し、必要に応じて機能単位１の各々に資源を割り当てたり、割り当てた資源を解放する等の制御を行う。資源管理部３は、図３に示すように、割当制御部３１と、資源割当部３２とを含む。また、図３では、１つの資源管理部３を示しているが、資源管理部３は複数であってもよい。

割当制御部３１は、機能単位１の資源の利用状況のモニタリングの結果または要求に基づいて、機能単位１の各々に対する資源の割り当て量を決定する。また、割当制御部３１は、機能単位１に資源を割り当てた場合に、割り当て量に応じたポイントを該機能単位１から徴収する。また、割当制御部３１は、割り当て量に応じたポイントを徴収できない場合は、新たな資源を割り当てず、要求を拒否したり、または割り当て済みの資源を回収してもよい。このように、割当制御部３１は、サービス提供の実態に応じて機能単位１に蓄積されるポイントを減じることで、該機能単位１に資源を提供する。

資源割当部３２は、割当制御部３１が決定した割り当て量に基づいて、各機能単位に資源を割り当てる。

また、図４に示すように、資源管理システム１００は、ポイント管理部２として、ブロックチェーン４１を利用した台帳管理システム４を備えていてもよい。以下では、ポイント管理部２が台帳管理システム４である場合を例に説明する。

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

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

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

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

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

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

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

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

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

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

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

図６は、ブロックチェーン４１の改ざん耐性を説明するための説明図である。図６に示すように、ある端末が過去のブロックに書き込まれた情報（図中の“block n”の“data n”）を改ざんしたとする。すると、当該ブロックのハッシュ値が変化するため、変化後のハッシュ値がターゲット値を超えた場合には、任意の検証タイミングで改ざんが検出される。したがって、改ざんを検出されないようにするためには、当該ブロックのノンス（図中の“nonce n”）を再設定し、ターゲット値以下にする必要がある。

しかし、当該ブロックのハッシュ値が変化することにかわりないため、次ブロックに含まれる「前ブロックのハッシュ値」（図中の“block n+1”の“Hach(block n)”）と一致しなくなる。このため、当該ブロックだけでなく、以降の全てのブロックのノンスを再設定する必要がある。一般に、改ざんのためには、膨大の計算量（ブロックチェーンを管理するノードの総計算量の５０％以上）が必要になると言われている。

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

図７に示す台帳管理ノード４２は、データ受付部４２１と、ブロック生成部４２２と、ブロック共有部４２３と、情報記憶部４２４と、ブロック検証部４２５と、データ出力部４２６とを含む。なお、本例の場合、情報記憶部４２４が上記の情報保持部２１に相当し、ブロック生成部４２２が上記のポイント更新部２２に相当する。

データ受付部４２１は、外部ノードから、ブロックチェーン４１に記録する情報を受け付ける。本実施形態では、データ受付部４２１は、ブロックチェーン４１に記録する情報として、後述するサービス利用情報や、資源割当情報や、ポイント支払情報等を受け付ける。

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

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

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

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

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

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

ブロックチェーン４１を用いる場合、各ユーザの端末および各機能単位は、ブロックチェーン４１を利用するエンティティとして動作する。典型的には、各エンティティは、秘密鍵、公開鍵のペアを持ち、秘密鍵でトランザクションに署名を付加してマイナー（例えば、上記の台帳管理ノード４２）に送付する。各マイナーは、送付されたトランザクションに基づき、ブロックチェーンへブロックを追加する。各エンティティは、システムに参加する際、他のエンティティ等からマイナーの情報を取得可能とする。

また、図８は、ポイント管理部２（本例では、ブロックチェーン４１）が保持するポイント管理情報の例を示す説明図である。ポイント管理部２は、ポイント管理情報として、例えば、サービス利用情報と、資源割当情報と、支払い情報とを記憶してもよい。

サービス利用情報は、各機能単位におけるサービスの利用状況を示す情報である。サービス利用情報は、例えば、トランザクション種別と、時刻と、呼び出し元識別子と、呼び出し先識別子と、利用回数と、支払いポイントとを含んでいてもよい。

ここで、トランザクション種別は、当該レコードを発行したトランザクションの種類を表す。例えば、図中の“T1”は、当該レコードがサービス利用情報のトランザクションであることを表している。当該トランザクションは、例えば、サービスを呼び出したエンティティ（呼び出し元エンティティ）により発行される。時刻は、サービスが利用された時間または時間帯を表す。呼び出し元識別子は、サービスを呼び出したエンティティの識別子を表す。呼び出し先識別子は、サービスが呼び出されたエンティティの識別子を表す。利用回数は、時刻が示す時間または時間帯に行われた、当該読み出し元と読み出し先の組によるサービス利用の回数を表す。なお、サービス利用の度にサービス利用情報を登録する場合には、利用回数は省略可能である。支払いポイントは、当該レコードが示すサービス利用によって支払われたポイント数を表す。ここで、該ポイント数は、より具体的には、当該レコードの時刻が示す時間または時間帯において、読み出し元エンティティが読み出し先エンティティに支払ったポイントの総数である。

また、資源割当情報は、各機能単位への資源割り当て状況を示す情報である。資源割当情報は、例えば、トランザクション種別と、割り当て開始時刻と、資源情報と、割り当て先識別子と、支払いポイントとを含んでいてもよい。

トランザクション種別は、当該レコードを発行したトランザクションの種類を表す。例えば、図中の“T2”は、当該レコードが資源割当情報のトランザクションであることを表している。当該トランザクションは、例えば、資源割り当てを行ったエンティティ（資源管理部３）により発行される。割り当て開示時刻は、資源割り当てを開始した時間を表す。資源情報は、割り当てた資源の詳細を表す。ここで、資源情報には、割り当てた資源を特定可能な情報（識別子等）と、割り当てた資源の量とが含まれていることが好ましい。割り当て先識別子は、資源の割り当て先のエンティティ（より具体的には機能単位）の識別子である。支払いポイントは、当該レコードが示す資源の割り当てによって支払われたポイント数を表す。ここで、該ポイント数は、より具体的には、当該レコードが示す時間において割り当て先エンティティに当該資源を割り当てた時に、該エンティティが支払ったポイントの総数である。

また、支払い情報は、定期的な資源使用料や、ユーザへのポイント回復等、サービス利用が伴わないポイントの支払い状況を示す情報である。支払い情報は、例えば、トランザクション種別と、時刻と、支払い元識別子と、支払い先識別子と、支払い対象と、支払いポイントとを含んでいてもよい。

トランザクション種別は、当該レコードを発行したトランザクションの種類を表す。例えば、図中の“T3”は、当該レコードが支払い情報のトランザクションであることを表している。時刻は、当該レコードが示すポイントの支払いが行われた時間を表す。支払い元識別子は、当該レコードが示すポイントの支払い元エンティティの識別子を表す。支払い先識別子は、当該レコードが示すポイントの支払い先エンティティの識別子を表す。支払い対象は、当該レコードが示すポイントの支払いが行われた対象（支払い事由）を表す。支払い対象を示す情報は、例えば、割り当て済みの資源にかかる使用料であれば、資源割当情報に含まれる資源を特定する情報であってもよい。また、例えば、支払い対象を示す情報は、例えば、ユーザへの定期的なポイントの回復であれば、回復を表す情報であってもよい。

なお、上記のポイント管理情報に関し、例えば、情報の内容から、どのような情報が記憶されているかが把握可能な場合は、トランザクション種別は省略可能である。また、機能単位ごとの１回の呼び出しにかかるポイント数の情報や、資源ごとの割り当てにかかるポイント数の情報などが予めポイント管理部２に保持されている場合など、サービス利用および／または資源割り当てにかかるポイント数が他の情報から把握可能であれば、支払いポイントは省略可能である。また、支払いポイントに代えてまたは支払いポイントとともに、支払い元および支払い先のポイント支払い前後のポイント数を含んでいてもよい。

また、ポイント管理部２は、上記情報に加えて、ユーザに関する情報や、ユーザおよび機能単位の各々が保有するポイントを管理するポイント情報を記憶してもよい。なお、ポイント情報以外の情報を参照することにより、各エンティティの保有ポイントを把握可能な場合は、ポイント情報は省略可能である。ユーザに関する情報は、例えば、特定の管理エンティティにユーザ追加の特権を与え、そのエンティティのみがユーザに関する情報を追加、変更できるようにしてもよい。なお、ユーザに関する情報の管理をポイント管理部２では行わずに、別途専用のエンティティ（データベースなど）に行わせてもよい。

また、ポイント管理部２は、上記情報に加えて、機能単位のサービス利用料（機能単位使用料）や、資源の使用料（資源使用料）を示す使用料情報を記憶してもよい。特に、使用料が時刻や他の条件等によって変動する場合、条件とともに、使用対象（機能単位の識別子や資源の種別等）と使用料とを含む使用料情報を記憶してもよい。

なお、図８には、表形式でポイント管理情報を保持する例が示されているが、ブロックチェーン４１を利用する場合には、各々のレコードの内容をそれぞれ、データ（図５中の“data”）として含むブロックを作成し、ブロックチェーン４１に随時追加していけばよい。

次に、本実施形態の動作を説明する。図９は、本実施形態の資源管理部３の動作の一例を示すフローチャートである。図９に示す例では、まず、割当制御部３１が、資源割り当て要求を受信したか否かを判定する（ステップＳ１０１）。割当制御部３１は、資源割り当て要求を受信した場合（ステップＳ１０１のＹｅｓ）、要求元の保有ポイントを確認する（ステップＳ１０２）。要求元が該要求に応じたポイントを所持していた場合（ステップＳ１０３のＹｅｓ）、割当制御部３１は、資源割当部３２に依頼して、要求に応じた資源の割り当てを実行させる（ステップＳ１０４）。そして、割当制御部３１は、割り当て結果に応じて、要求元からポイントを徴収する（ステップＳ１０５：ポイントの移動）。

一方、要求元が該要求に応じたポイントを所持していなかった場合（ステップＳ１０３のＮｏ）、割当制御部３１は、要求を拒否する（ステップＳ１０６）。

また、割当制御部３１は、現在のタイミングが、資源使用料の徴収タイミングか否かを判定する（ステップＳ１０７）。資源使用料の徴収タイミングか否かは、例えば、資源の割り当て後又は前回徴収後から一定の時間が経過したか否かにより判定してもよい。

徴収タイミングであった場合（ステップＳ１０７のＹｅｓ）、割当制御部３１は、割り当て済みの資源に対する使用料を、割り当て先のエンティティから徴収する（ステップＳ１０８：ポイントの移動）。徴収タイミングでなかった場合（ステップＳ１０７のＮｏ）、割当制御部３１は、そのままステップＳ１０９に進む。

ステップＳ１０９で、割当制御部３１は、現在のタイミングが、ユーザのポイント回復タイミングか否かを判定する。ユーザのポイント回復タイミングか否かは、例えば、ユーザがサービス加入後又は前回回復後から一定の時間が経過したか否かにより判定してもよい。

回復タイミングであった場合（ステップＳ１０９のＹｅｓ）、割当制御部３１は、当該ユーザのポイントを所定数もしくは所定の上限まで回復させる（ステップＳ１１０）。回復タイミングでなかった場合（ステップＳ１０９のＮｏ）、割当制御部３１は、そのまま処理を終了する。なお、ステップＳ１０９〜Ｓ１１０の動作は、割当制御部３１以外の処理部が行ってもよい。

また、図１０は、サービスを呼び出された機能単位１の動作例を示すフローチャートである。図１０に示す例では、まず機能単位１のサービス提供部１１がサービスを受け付ける（ステップＳ２０１）。該サービスの要求元は、例えば、本システムに登録したユーザの端末や、該端末から呼び出された機能単位である。

サービス提供部１１がサービスを受け付けると、まずポイント記録部１２が、要求元の保有ポイントを確認する（ステップＳ２０２）。要求元が該要求に応じたポイントを所持していた場合（ステップＳ２０３のＹｅｓ）、サービス提供部１１は、要求されたサービスを実行する（ステップＳ２０４）。そして、該サービスの実行に伴い、ポイント記録部１２が、要求元からポイントを徴収する（ステップＳ２０５：ポイントの移動）。これにより、サービス要求元のエンティティからサービス提供側のエンティティにポイントが移動する。

なお、サービス呼び出し時にポイントを徴収した上で、サービス提供部１１がサービス提供を行うことも可能である。このとき、サービス提供部１１は、サービスの提供に失敗した場合、要求元のエンティティにポイントを支払ってもよい。支払うポイントは、呼び出し時に徴収したポイントと同額でもよいし、予め決められた一定の値でもよい。また、サービス要求時に、サービス提供に失敗した場合に支払われるポイント数を指定してもよい。

一方、要求元が該要求に応じたポイントを所持していなかった場合（ステップＳ２０３のＮｏ）、サービス提供部１１は、該要求を拒否する（ステップＳ２０６）。

また、図１１は、サービス呼び出し側のエンティティの動作例を示すフローチャートである。図１１に示す例では、まずあるエンティティが、他の機能単位１のサービスを呼び出す（ステップＳ２１１）。そして、サービスが提供されると、該サービスに応じたポイントを支払う（ステップＳ２１２：ポイント移動）。なお、ステップＳ２１２の動作は、図１０のステップＳ２０５の動作に対応する。

また、図１２は、ある機能単位１が新たな資源の割り当てを要求する場合の動作例を示すフローチャートである。図１２に示す例では、まず機能単位１のサービス提供部１１が、資源の割り当てが必要か否かを判定する（ステップＳ２２１）。資源の割り当てが必要と判定された場合（ステップＳ２２１のＹｅｓ）、サービス提供部１１は、資源の割当要求を資源管理部３に送信する（ステップＳ２２２）。

そして、資源の割り当てが完了すると、割り当てられた資源に応じたポイントを支払う（ステップＳ２２２：ポイント移動）。なお、ステップＳ２２２の動作は、図９のステップＳ１０５の動作に対応する。

尚、上記の各例において、保有ポイントの確認は、ポイント管理部２（本例では、ブロックチェーン４１）が保持している情報を参照することにより行ってもよい。また、ポイントの移動および回復は、対象と移動ポイント等の情報を含むトランザクションを発行し、ブロックチェーン４１に該移動よび回復を記録させることにより行ってもよい。このとき、該トランザクションは、台帳管理システム４の台帳管理ノード４２のいずれかに受信され、所定のコンセンサス処理を経て、ブロックチェーン４１に該トランザクションの情報を含むブロックが追加される。

また、上記実施形態において、資源使用料を、システム内の資源の使用状況に基づいて定めてもよい。例えば、割り当てられる資源の残量が少ないほど、使用料を高くしてもよい。このようにすれば、ポイントを多く保有している機能単位すなわちより多く利用されている機能単位に、優先的に資源を割り当てることができる。このとき、ポイント管理部２は、資源の残量を示す情報や使用料を示す情報を保持してもよい。

また、機能単位１が資源を自主的に解放（返却）できるようにしてもよい。このとき、ポイントの返却はあってもよいし、なくてもよい。ポイントの返却がない場合でも、資源を解放することで、以降の定期的な使用料の支払いをなくすことができる。機能単位１の各々は、資源を解放する際には、資源割り当て時と同様、その旨を示すトランザクションを発行すればよい。

また、機能単位１の各々におけるサービス利用料を、当該サービスの輻輳状態に基づいて決定してもよい。例えば、同時に多くの呼び出しを受けているサービスほど、利用料を高くしてもよい。このようにすれば、ポイントを多く保有しているエンティティに優先的にサービスを提供できるため、ＤｏＳ攻撃等に対する防御をより高められる。このとき、ポイント管理部２は、サービスの利用状況を示す情報やサービス利用料を示す情報を保持してもよい。

また、例えば、サービス利用料を、提供元の機能単位１が所属するデータセンタやインスタンスごとに設定することも可能である。例えば、多くのユーザや他の機能単位に対してサービスを提供しているインスタンスほどサービスの使用料を高く設定することができる。こうすることで、よりサービス利用料が少ないインスタンスの利用が促進され、負荷分散を行うことができる。

また、サービス利用料の支払いタイミングによって該利用料を変動させてもよい。例えば、前払いか後払いかによって、また前払いと後払いの配分によって、サービス利用料を変えてもよい。前払いと後払いとによって支払いを分けることで、呼び出す側と呼び出される側で、サービス提供が失敗した場合のリスクを分担することができる。また、サービス利用料だけでなくサービスの優先度を変更することも可能である。

また、過去にサービス利用料や資源使用料が未払いとなったエンティティに対して、所定回数分のサービスの拒否や優先度を下げる等のペナルティを課すことも可能である。

以上のように、本実施形態によれば、各機能単位は、資源を割り当てられるためには、ユーザや他の機能単位からサービスを利用されなければならない。したがって、サービス提供の実態が伴っていない架空のビジー状態を装って資源の割り当て要求を行うなどといった、不正な資源割り当て要求を抑制できる。また、本実施形態によれば、各ユーザが時間あたりに使用できるポイントが限られるため、ＤｏＳ攻撃等、ユーザ側の悪意ある呼び出し等によるビジー状態および該ビジー状態を起因とする不適切な資源割り当ても抑制できる。その結果、不適切な資源割り当てが減り、実際にサービスを提供している機能単位に優先的に資源を割り当てることができる。

また、本実施形態によれば、例えば、結合度の弱いマイクロサービスを利用したＭＳＡのように、個々の機能単位が独立して資源を要求する場合であっても、ポイントを通して市場原理が働くことで需要にマッチした資源の割り当てが実現される。

例えば、機能単位１のサービス利用料に関して、予め初期値を定めておき、その後需要に合わせて変動させる。そのようにすれば、輻輳時において、より多くのポイントを持っている（需要の多い）機能単位１が優先して他のサービスを利用できるという市場原理が働き、適切な資源割り当てが行われる。また、例えば、データセンタやインスタンス毎にサービス利用料を設定できるようにすることで、同じ機能を提供する機能単位１でも、正常な値段のインスタンスに処理が流れるようにできる。なお、この場合も、安すぎる設定の場合は資源が維持できないようにできるので、ぼったくりや不当廉売といった異常な値段設定をするインスタンスを排除する市場原理が働き、適切な資源割り当てが行われる。

また、例えば、資源使用料に関して、予め初期値を定めておき、その後需要に合わせて変動させてもよい。そのようにすれば、輻輳時において、より多くのポイントを持っている（需要の多い）機能単位１が優先して資源を利用できるという市場原理が働き、適切な資源割り当てが行われる。また、例えば、割り当て先の機能単位１における資源の使用量（割り当て量）に応じて、資源使用料を変動させてもよい。そのようにして、１つの機能単位が多くの資源を持ちすぎないようにもできる。

また、本システムで働くであろう市場原理の他の例および効果として、ユーザは、配布されるポイント分しかサービスを利用できないため、利用する必要が高いサービスや安いサービスを利用することにより、負荷が分散されるというメリットがある。

また、機能単位１の各々は、例えば、割り当て済みの資源量に対してサービス需要が多い場合に、サービス利用料を上げて、要求者を減らすことができる。また、需要が多い場合はそれだけポイント増加につながるため、ポイントが増加した分、新たな資源を取得できる。一方、割り当て済みの資源量に対してサービス需要が少ない場合は、資源を返却してポイントの支払いを減らすことができる。このように、需要に合わせて適切な量の資源を保持できる。

また、本実施形態によれば、リソースサーバ（より具体的には、資源管理部３）が、自身の資源の残量が多い場合は使用料を低めに設定し、少ない場合は使用料を高めに設定できる。これにより、より必要度が高い（多くのユーザからアクセスされていて、ポイントを多く保有している）機能単位に優先的に資源を割り当てられるようにしてもよい。また、このようにして使用料を変動させることにより、資源が多く残っているリソースサーバを優先的に利用されやすくできる。

また、輻輳時の上記挙動の他の効果として、ＤｏＳ状態に陥りサービスが困難な機能単位は、サービス需要があってもサービス提供ができなくなるため、資源使用料が払えず資源を維持できなくなる。これを利用して、フロントエンド側のサービスに資源が偏ってしまった場合に、偏りを平衡化できる。

また、例えば、ネットワークが分断するなどして、サービスの需要と供給のバランスが変化した場合も、需要が減った機能単位は資源を解放し、需要が増えた機能単位は新たな資源を確保するといった動作が期待される。このように、本実施形態によれば、需要に合わせて資源の割り当て量を最適化できる。

また、本実施形態では、各エンティティの保有ポイントを確認するだけで資源を割り当てることができるので、１つの管理エンティティがシステム全体を監視して、サービス提供に必要な資源等を管理する必要がない。すなわち、ポイントを介して各機能単位の利用状況を定量化することにより、機能単位１および資源管理部３がそれぞれ完全分散的に動作して資源の獲得と解放を行うことができるので、各々の独立性を高く保つことができる。また、そのようにして各エンティティの独立性を高くしても、各ユーザが所持できるポイントの総数を制限することにより、過大な資源の割り当てを抑制できる。

例えば、悪意のあるユーザが、ＤｏＳ攻撃目的で特定の機能単位への呼び出しを繰り返したとしても、ポイントが枯渇するため一定量以上の呼び出しを防止できる。仮に、複数のユーザが結託した場合であっても、需要高により該機能単位のサービス利用料を上げることで、ＤｏＳ攻撃の効果を薄めることができる。

同様に、例えば、悪意のある機能単位が、他の機能単位にＤｏＳ攻撃を行ったり、使用しない資源の過大要求を行ったとしても、ポイントが枯渇するため一定量以上の攻撃や要求を防止できる。

また、ブロックチェーンへの記録に関して、ブロックが後ろに追加されるのを待たずに情報を信じる「０ ｃｏｎｆｉｒｍａｔｉｏｎ」で処理を進め、不整合が起きた場合に後でペナルティを与えることも可能である。

例えば、あるエンティティが、ｎ重支払い等の不正な機能単位の使用や、使用したのに使用していないと申告するような不正を働いたとしても、改ざん耐性の高いブロックチェーンを利用するなどして不正の有無をチェックすることで、以降のサービスや資源割り当てを拒否するといったペナルティを課すことができる。

実施形態２．
次に、第２の実施形態について説明する。本実施形態では、ポイント管理部２として台帳管理システム４を用いることを前提に、機能単位１の各々にブロックチェーン４１の管理機能を持たせる。

図１３は、リソースサーバのみが空きリソースを用いてブロックチェーンの管理（より具体的にはＰｏＷ）を行う場合の問題点を説明するための説明図である。図１３に示すように、リソースサーバのみが空きリソースを用いてブロックチェーンの管理を行う場合、ＣＰＵリソースが逼迫する状況で、ブロックチェーンを管理するのが難しくなる。これは、ブロックチェーンにブロックを追加する際に必要となるＰｏＷに使用できるリソースが不足して、改ざん防止に必要な計算量が確保できず、ブロックチェーンのセキュリティが低下するためである。

そこで、本実施形態では、機能単位１の各々にもマイニング、すなわちＰｏＷを行う機能を持たせる。そして、マイニング成功時には、インセンティブとしてポイントを付与する。このとき、特定の機能単位が計算量を保持しすぎないように、インセンティブ料や資源使用料を決定してもよい。

図１４および図１５は、本実施形態の概要を示す説明図である。図１４に示すように、本実施形態では、機能単位１の各々は、さらにマイニングを行うマイナーとしても動作する。例えば、“機能単位Ａ”は、“マイナーＡ”としても動作する。機能単位１の各々は、例えば、図１５に示すように、割り当てたリソースを使用して空き時間にマイニングに参加する。ここで、空き時間の例としては、他のエンティティからのリクエスト（サービス要求）の量が減った時間や、他の機能単位からのレスポンス待ちの時間などが挙げられる。

図１６は、本実施形態の資源管理システムの構成例を示すブロック図である。図１６に示すように、本実施形態では、機能単位または機能単位を稼働させるコンテナとしてのサーバ１０（仮想化基盤等）に、台帳管理ノード４２の各機能またはその一部（例えば、図７のブロック生成部４２２と情報記憶部４２４等）を実装したＰｏＷ部１３を追加する。

ＰｏＷ部１３は、例えば、自身が生成したブロックまたは他の台帳管理ノード４２が生成したブロックに対して、所定のコンセンサス処理を行って、成功した場合に該ブロックをブロックチェーン４１に追加する処理を行う。

図１６に示す例において、ある機能単位１は、サーバ（仮想化基盤）１０に備えられている。このとき、サーバ１０は、２以上の機能単位１を実装してもよい。そして、そのようなサーバ１０やサーバ１０上で動作する機能単位１に、機能単位１に割り当てられた資源を用いて所定のコンセンサス処理を少なくとも行うＰｏＷ部１３を設ける。なお、図１６では、１つのブロックチェーン４１を示しているが、ブロックチェーン４１は、実際には台帳管理ノード４２の各々に保持される。このとき、該台帳管理ノード４２には、ＰｏＷ部１３を有する機能単位１やサーバ１０が含まれていてもよい。

なお、マイニング成功時のインセンティブ料は、次のように定められるのが好ましい。すなわち、マイニングのターゲット値と資源使用料とに基づいて、インセンティブ料が定められるのが好ましい。

一例として、ターゲット値をＴ、単位時間あたりで行える一方向性関数の計算回数（マイニングに費やす計算量）をＣ、ノンスの最大値をＮ_ｍａｘ、単位時間当たりのマイニング成功確率をＰ（Ｔ，Ｃ）＝１−（１−Ｔ／Ｎ_ｍａｘ）、単位時間当たりの資源使用料をＶ_ｒ、インセンティブをＶ_ｉとしたとき、以下に示す式（１）を満たすようにすると好ましい。

Ｖ_ｉ＊Ｐ（Ｔ，Ｃ）＜Ｖ_ｒ ・・・（１）

ここで、上記の式（１）におけるマイニングに費やす計算量Ｃを、割り当て済みの資源量のみを用いて計算してもよいし、サービス利用状況を含めて計算することも可能である。他の例としては、単純に、割り当て済みの資源が多いほどインセンティブを小さくしてもよい。なお、単位時間当たりの資源使用料を、マイニングのターゲット値とマイニング成功時のインセンティブ料とに基づいて定めることも可能である。

いずれにしても、マイニングだけをし続けると赤字になるように、インセンティブ料または資源の単位時間当たりの使用料が設定されればよい。これにより、悪意のある機能単位１やサーバ１０が、自身または自身の上で動作する機能単位に割り当てられた資源を全てマイニングに費やしてブロックチェーン４１を改ざんしようとする試みを抑制する。

以上のように、本実施形態によれば、インセンティブを与えて各機能単位１にマイニング作業に従事するまたはそのための資源の貸し出しを行う動機付けを行うことにより、悪意あるノードからの改ざん防止に必要な計算量を確保する。その結果、ブロックチェーンのセキュリティ低下を防止できる。

また、本実施形態によれば、割り当てられた資源量に対してサービス需要が少ない機能単位１が一時的にマインニングに参加してポイントを得ることができるので、機能単位１における需要の変動に対する資源量の変動を緩やかにできる。なお、他の点は第１の実施形態と同様である。

実施形態３．
本実施形態では、ユーザに優先度を持たせ、優先度に応じたサービス提供の優先制御が行われるようにする。

図１７は、本実施形態の概要を示す説明図である。図１７に示す例では、各ユーザが、他の機能単位を利用する際に、追加料金（追加ポイント）の支払いを行うことができるようにしている。要求を受け取った側は、追加料金が多いほど、その要求を優先的に処理する。

本実施形態では、ユーザに優先度を設定する。その上で、優先度ごとに追加料金の上限を設定する。ユーザは、自身に設定された優先度に応じた上限に収まる範囲で、自由に追加料金を設定できる。また、要求を受け取った機能単位は、追加料金に応じて優先的にサービスを提供する。

優先度ごとの追加料金の上限は、呼び出し先の機能単位１のサービス利用料に対する割合として定められてもよいし、呼び出し先の機能単位１に関わらず、全ての機能単位１に対して一律に定められてもよい。

また、優先度の情報や優先度ごとの追加料金の上限の情報は、例えば、ブロックチェーン４１に記憶してもよいし、管理サーバやデータベース等を用いて共有してもよい。

なお、呼び出し先の機能単位１の各々における優先処理の仕方は、特に問わない。一例として、機能単位１は、追加料金に応じて処理順序を変えてもよい。また、例えば、機能単位１は、「追加料金がｘｘ以上であれば、資源の使用率がｙｙ以上であってもサービスを提供する」など、追加料金に応じて混雑時のサービス提供の可否の判定基準を変えてもよい。また、例えば、機能単位１は、追加料金に応じて、現在提供中のサービスのうち追加料金が低いサービスの提供を中止し、追加料金の高いサービスのための資源を確保してもよい。このとき、機能単位１は、中止したサービスに対して、サービス失敗時の補償ポイントを支払ってもよい。さらに、機能単位１は、現在提供中のサービスのサービス失敗時の補償ポイントが新たに受け付けたサービスの追加料金以下ならば、現在提供中のサービスを中止するといった判断を行ってもよい。

また、本実施形態では、機能単位１が、追加料金が支払われたサービスを行うために他の機能単位１を呼び出す場合、該サービスに対し支払われた追加料金の範囲内で呼び出し先の機能単位１に追加料金を払うことができるようにする（図１８参照）。また、機能単位１は、サービス提供に失敗した場合には、追加料金相当またはそれよりも多いポイントを払い戻すようにしてもよい。このようにすることで、機能単位１において、追加料金をもらっておきながら通常の優先度でサービスを提供するような振る舞いを抑制できる。

また、優先度が高いユーザほど定期的に回復させるポイント数を多くしてもよい。なお、他の点は第１の実施形態および第２の実施形態と同様でよい。

本実施形態によれば、ユーザに優先度を持たせることができ、優先度が高いユーザであって優先制御を所望するユーザに対して、優先的にサービスを提供できる。

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

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

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

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

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

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

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

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

次に、本発明の資源管理システムの概要を説明する。図２０は、本発明の資源管理システムの概要を示すブロック図である。図２０に示す資源管理システム５００は、１つ以上の機能単位５０１と、資源割当部５０２と、ポイント管理部５０３とを備える。

機能単位５０１（例えば、機能単位１）の各々は、所定の機能をサービスとして提供する。このとき、機能単位５０１の各々は、サービスを、要求元のユーザまたは他の機能単位５０１が保有するポイントと引き換えに提供する。

資源割当部５０２（例えば、資源管理部３）は、機能単位５０１にサービスを実行するための資源を割り当てる。このとき、資源割当部５０２は、資源を、割り当て先の機能単位５０１が保有するポイントを減じることにより割り当てる。

ポイント管理部５０３（例えば、ポイント管理部２）は、ユーザおよび機能単位５０１の各々について、サービスを受けるために必要な仮想通貨であるポイントの保有数を管理する。

このような構成により、サービス提供の実態と合致した資源の割り当てが可能となる。

また、資源管理システムは、一定時間ごとにユーザのポイントを回復させるポイント回復部と、割り当て済みの資源について、割り当て先の機能単位から一定時間ごとにポイントを徴収するポイント徴収部とをさらに備えていてもよい。

また、ポイント管理部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、ユーザおよび機能単位の各々のポイントの保有数を管理してもよい。

また、このとき、機能単位または機能単位を稼働させているサーバが、機能単位に割り当てた資源を用いて、ブロックチェーンにブロックを追加するための所定のコンセンサス処理を行ってもよい。

また、このとき、所定のコンセンサス処理の成功時に、インセンティブとして機能単位にポイントが支払われ、インセンティブ料が、所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められていてもよい。

また、上記の資源管理システムにおいて、単位時間あたりの資源使用料が、資源を管理する資源割当部における資源の残数に応じて変動する、または、機能単位のサービスの利用料が、機能単位におけるサービスの輻輳状態に応じて変動してもよい。

また、上記の資源管理システムにおいて、ユーザごとに優先度が予め決定されており、ユーザは、機能単位にサービスを要求する際に、優先度に応じて上限が定められている追加ポイントを付与することができ、機能単位は、追加ポイントに応じて、要求を優先的に処理してもよい。

また、ポイント管理部は、ユーザおよび機能単位の各々の保有ポイントを把握可能なポイント管理情報を保持する情報保持部と、ユーザ、機能単位または資源割当部からの要求に応じて、情報保持部に保持されているポイント管理情報を更新または追記することにより、ポイントを移動または増減させるポイント更新部とを含み、情報保持部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを管理する１つ以上のノードに実装され、ポイントの移動または増減を示す情報を含むブロックが順次追加されるチェーンブロックを記憶し、ポイント更新部は、１つ以上のノードに実装され、ポイントの移動または増減を示す情報を含むブロックをブロックチェーンに追加する処理を行ってもよい。

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

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

１００ 資源管理システム
１ 機能単位
１０ サーバ
１１ サービス提供部
１２ ポイント記録部
１３ ＰｏＷ部
２ ポイント管理部
２１ 情報保持部
２２ ポイント更新部
４ 台帳管理システム
４１ ブロックチェーン
４２ 台帳管理ノード
４２１ データ受付部
４２２ ブロック生成部
４２３ ブロック共有部
４２４ 情報記憶部
４２５ ブロック検証部
４２６ データ出力部
３ 資源管理部
３１ 割当制御部
３２ 資源割当部
１０００ コンピュータ
１００１ ＣＰＵ
１００２ 主記憶装置
１００３ 補助記憶装置
１００４ インタフェース
１００５ ディスプレイ装置
１００６ 入力デバイス
５００ 資源管理システム
５０１ 機能単位
５０２ 資源割当部
５０３ ポイント管理部

Claims (10)

1. 所定の機能をサービスとして提供する１つ以上の機能単位と、
   前記機能単位に前記サービスを実行するための資源を割り当てる資源割当部と、
   ユーザおよび前記機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理するポイント管理部とを備え、
   前記機能単位の各々は、前記サービスを、要求元のユーザまたは他の機能単位が保有する前記ポイントと引き換えに提供し、
   前記資源割当部は、前記資源を、割り当て先の機能単位が保有する前記ポイントを減じることにより割り当てる
   ことを特徴とする資源管理システム。
2. 一定時間ごとに前記ユーザのポイントを回復させるポイント回復部と、
   割り当て済みの資源について、割り当て先の機能単位から一定時間ごとにポイントを徴収するポイント徴収部とを備えた
   請求項１記載の資源管理システム。
3. 前記ポイント管理部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、前記ユーザおよび前記機能単位の各々のポイントの保有数を管理する
   請求項１または請求項２に記載の資源管理システム。
4. 前記機能単位または前記機能単位を稼働させているサーバが、前記機能単位に割り当てられた資源を用いて、前記ブロックチェーンにブロックを追加するための前記所定のコンセンサス処理を行う
   請求項３記載の資源管理システム。
5. 前記所定のコンセンサス処理の成功時に、インセンティブとして前記機能単位にポイントが支払われ、
   インセンティブ料が、前記所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、前記所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められている
   請求項４記載の資源管理システム。
6. 単位時間あたりの資源使用料が、前記資源を管理する資源割当部における資源の残数に応じて変動する、または、前記機能単位のサービス利用料が、前記機能単位におけるサービスの輻輳状態に応じて変動する
   請求項１から請求項５のうちいずれかに記載の資源管理システム。
7. 前記ユーザごとに優先度が予め決定されており、
   前記ユーザは、前記機能単位にサービスを要求する際に、前記優先度に応じて上限が定められている追加ポイントを付与することができ、
   前記機能単位は、前記追加ポイントに応じて、要求を優先的に処理する
   請求項１から請求項６のうちいずれかに記載の資源管理システム。
8. ユーザおよび所定の機能をサービスとして提供する１つ以上の機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を把握可能なポイント管理情報を保持する情報保持部と、
   前記機能単位における前記サービスの提供に応じて要求元のユーザまたは他の機能単位から要求先の機能単位へ前記ポイントを移動させる処理および前記機能単位への前記資源の割り当てに応じて割り当て先の機能単位が保有する前記ポイントを減少させる処理を、前記情報保持部に保持されている前記ポイント管理情報を更新または追記することにより行うポイント更新部とを備えた
   ことを特徴とする管理装置。
9. 所定の機能をサービスとして提供する１つ以上の機能単位と、前記機能単位に前記サービスを実行するための資源を割り当てる資源割当部とを備えた資源管理システムにおける資源管理方法であって、
   １つ以上の情報処理装置が、
   ユーザおよび前記機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理し、
   前記機能単位における前記サービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へ前記ポイントを移動させ、
   前記機能単位への前記資源の割り当てに応じて、割り当て先の機能単位が保有する前記ポイントを減少させる
   ことを特徴とする資源管理方法。
10. コンピュータに、
    ユーザおよび所定の機能をサービスとして提供する１つ以上の機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理する処理、
    前記機能単位における前記サービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へ前記ポイントを移動させる処理、および
    前記機能単位への前記資源の割り当てに応じて、割り当て先の機能単位が保有する前記ポイントを減少させる処理
    を実行させるための資源管理プログラム。

Images