特許第6860067号(P6860067)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電気株式会社の特許一覧
特許6860067資源管理システム、管理装置、方法およびプログラム
<>
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000002
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000003
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000004
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000005
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000006
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000007
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000008
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000009
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000010
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000011
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000012
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000013
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000014
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000015
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000016
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000017
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000018
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000019
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000020
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000021
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000022
  • 特許6860067-資源管理システム、管理装置、方法およびプログラム 図000023
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6860067
(24)【登録日】2021年3月30日
(45)【発行日】2021年4月14日
(54)【発明の名称】資源管理システム、管理装置、方法およびプログラム
(51)【国際特許分類】
   G06Q 20/06 20120101AFI20210405BHJP
   G06Q 10/06 20120101ALI20210405BHJP
【FI】
   G06Q20/06
   G06Q10/06
【請求項の数】10
【全頁数】27
(21)【出願番号】特願2019-521568(P2019-521568)
(86)(22)【出願日】2017年5月30日
(86)【国際出願番号】JP2017020083
(87)【国際公開番号】WO2018220709
(87)【国際公開日】20181206
【審査請求日】2019年11月19日
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103090
【弁理士】
【氏名又は名称】岩壁 冬樹
(74)【代理人】
【識別番号】100124501
【弁理士】
【氏名又は名称】塩川 誠人
(72)【発明者】
【氏名】井ノ口 真樹
【審査官】 相澤 祐介
(56)【参考文献】
【文献】 特開2011−154532(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 99/00
(57)【特許請求の範囲】
【請求項1】
所定の機能をサービスとして提供する1つ以上の機能単位と、
前記機能単位に前記サービスを実行するための資源を割り当てる資源割当部と、
ユーザおよび前記機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理するポイント管理部とを備え、
前記機能単位の各々は、前記サービスを、要求元のユーザまたは他の機能単位が保有する前記ポイントと引き換えに提供し、
前記資源割当部は、前記資源を、割り当て先の機能単位が保有する前記ポイントを減じることにより割り当て
前記ポイント管理部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、前記ユーザおよび前記機能単位の各々のポイントの保有数を管理し、
前記機能単位または前記機能単位を稼働させているサーバが、前記機能単位に割り当てられた資源を用いて、前記ブロックチェーンにブロックを追加するための前記所定のコンセンサス処理を行い、
前記所定のコンセンサス処理の成功時に、インセンティブとして前記機能単位にポイントが支払われ、
インセンティブ料が、前記所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、前記所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められている
ことを特徴とする資源管理システム。
【請求項2】
一定時間ごとに前記ユーザのポイントを回復させるポイント回復部と、
割り当て済みの資源について、割り当て先の機能単位から一定時間ごとにポイントを徴収するポイント徴収部とを備えた
請求項1記載の資源管理システム。
【請求項3】
単位時間あたりの資源使用料が、前記資源を管理する資源割当部における資源の残数に応じて変動する、または、前記機能単位のサービス利用料が、前記機能単位におけるサービスの輻輳状態に応じて変動する
請求項1または請求項2に記載の資源管理システム。
【請求項4】
前記ユーザごとに優先度が予め決定されており、
前記ユーザは、前記機能単位にサービスを要求する際に、前記優先度に応じて上限が定められている追加ポイントを付与することができ、
前記機能単位は、前記追加ポイントに応じて、要求を優先的に処理する
請求項1から請求項のうちいずれかに記載の資源管理システム。
【請求項5】
ユーザおよび所定の機能をサービスとして提供する1つ以上の機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を把握可能なポイント管理情報を保持する情報保持部と、
前記機能単位における前記サービスの提供に応じて要求元のユーザまたは他の機能単位から要求先の機能単位へ前記ポイントを移動させる処理および前記機能単位への前記資源の割り当てに応じて割り当て先の機能単位が保有する前記ポイントを減少させる処理を、前記情報保持部に保持されている前記ポイント管理情報を更新または追記することにより行うポイント更新部とを備え
前記情報保持部および前記ポイント更新部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、前記ユーザおよび前記機能単位の各々のポイントの保有数を管理し、
前記機能単位または前記機能単位を稼働させているサーバが、前記機能単位に割り当てられた資源を用いて、前記ブロックチェーンにブロックを追加するための前記所定のコンセンサス処理を行い、
前記所定のコンセンサス処理の成功時に、インセンティブとして前記機能単位にポイントが支払われ、
インセンティブ料が、前記所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、前記所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められている
ことを特徴とする管理装置。
【請求項6】
所定の機能をサービスとして提供する1つ以上の機能単位と、前記機能単位に前記サービスを実行するための資源を割り当てる資源割当部とを備えた資源管理システムにおける資源管理方法であって、
1つ以上の情報処理装置が、
ユーザおよび前記機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理し、
前記機能単位における前記サービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へ前記ポイントを移動させ、
前記機能単位への前記資源の割り当てに応じて、割り当て先の機能単位が保有する前記ポイントを減少させ
所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、前記ユーザおよび前記機能単位の各々のポイントの保有数を管理し、
前記機能単位または前記機能単位を稼働させているサーバが、
前記機能単位に割り当てられた資源を用いて、前記ブロックチェーンにブロックを追加するための前記所定のコンセンサス処理を行い、
前記所定のコンセンサス処理の成功時に、インセンティブとして前記機能単位にポイントが支払われ、
インセンティブ料が、前記所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、前記所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められている
ことを特徴とする資源管理方法。
【請求項7】
1つ以上の情報処理装置が、
一定時間ごとに前記ユーザのポイントを回復させ、
割り当て済みの資源について、割り当て先の機能単位から一定時間ごとにポイントを徴収する
請求項6記載の資源管理方法。
【請求項8】
単位時間あたりの資源使用料が、前記資源を管理する資源割当部における資源の残数に応じて変動する、または、前記機能単位のサービス利用料が、前記機能単位におけるサービスの輻輳状態に応じて変動する
請求項6または請求項7に記載の資源管理方法。
【請求項9】
コンピュータに、
ユーザおよび所定の機能をサービスとして提供する1つ以上の機能単位の各々について、前記サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理する処理、
前記機能単位における前記サービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へ前記ポイントを移動させる処理
前記機能単位への前記資源の割り当てに応じて、割り当て先の機能単位が保有する前記ポイントを減少させる処理、および
所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、前記ユーザおよび前記機能単位の各々のポイントの保有数を管理する処理を実行させるための資源管理プログラムであって、
前記機能単位または前記機能単位を稼働させているサーバが、
前記機能単位に割り当てられた資源を用いて、前記ブロックチェーンにブロックを追加するための前記所定のコンセンサス処理を行い、
前記所定のコンセンサス処理の成功時に、インセンティブとして前記機能単位にポイントが支払われ、
インセンティブ料が、前記所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、前記所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められている
資源管理プログラム
【請求項10】
コンピュータに、
一定時間ごとに前記ユーザのポイントを回復させる処理、および
割り当て済みの資源について、割り当て先の機能単位から一定時間ごとにポイントを徴収する処理を実行させる
請求項9記載の資源管理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、所定の機能をサービスとして提供する1つ以上の機能単位に割り当てる資源を管理するための資源管理システム、管理装置、資源管理方法および資源管理プログラムに関する。
【背景技術】
【0002】
サービス提供側において、障害が起きた場合や悪意のある装置等が存在する場合であっても、正規のユーザに対してサービスを継続的に提供したいという要求がある。そのため、そのようなサービス提供基盤が所望されている。
【0003】
サービス提供アーキテクチャの1つに、マイクロサービスアーキテクチャ(micro service architecture,以下、MSAという)がある。MSAは、一枚岩(モノリシック)なソフトウェアアーキテクチャを細かく分割して、結合度の低い機能単位の集まりとし、それらを連携させることによって同等のサービスを提供するアーキテクチャである。MSAは、サービス提供に必要な機能を独立して扱えるので、開発およびデプロイの迅速化や、優れた回復性、スケーラビリティを実現できるというメリットがある。
【0004】
図21は、マイクロサービスを利用したサービス提供プログラムの例を示す説明図である。図21に示す例は、ユーザからのサービスリクエストをフロントエンドサービスが受け付け、後段のマイクロサービスに適宜処理を実行させ、その処理連携により、該ユーザにサービスを提供するアーキテクチャの例である。マイクロサービスの例としては、認証サービス、アクセス許可、データの管理(更新、削除、抽出)、レコメンデーションなどが挙げられる。MSAは、クラウド上でサービスを提供する際のアーキテクチャとして利用されている。
【0005】
以下、このような複数の機能単位を連携させてサービスを提供するサービスシステムにおける資源管理を考える。図22は、MSAにおける資源管理方法の例を示す説明図である。MSAでは、例えば、管理エンティティが、各マイクロサービスにおける資源の使用状況をモニタリングし、あるマイクロサービスの資源使用率等が基準を上回った場合に、新たに資源を割り当てる。また、管理エンティティは、あるマイクロサービスの資源使用率等が基準を下回った場合に、資源を解放する。ここで、資源の割り当ては、該当するマイクロサービスのインスタンスを複製することであってもよい。また、資源の解放は、該当するマイクロサービスのインスタンスを削除することであってもよい。また、マイクロサービス自身が資源使用状況を判断して資源要求を管理エンティティに送信する場合もある。
【0006】
また、特許文献1には、分散環境下における個々のユーザ(ホストコンピュータ)の要求に基づいて、資源の輻輳状態に対応した動的な適応性をもった資源配分制御を行う方法が記載されている。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開平11−66018号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
課題は、悪意のあるユーザや機能単位が存在していたときに、不適切な資源の割り当てが行われてしまうことである。一例として、悪意のあるユーザや機能単位が、資源が不足していないにも関わらず資源要求を行い、それを基に管理エンティティが資源を割り当ててしまう状況が挙げられる。そのような資源要求を防ぐため、上述したようなモニタリングを行うことが考えられる。
【0009】
しかし、モニタリングを行う場合であっても、例えば、1つの機能単位が、悪意のあるユーザからサービス提供が伴わない空の要求等を繰り返し受信すると、サービス提供の実態がない状況でも資源が不足する状況になりうる。また、例えば、ある機能単位がウィルス等に感染した場合、実際にサービス提供を行っていないにも関わらず、他の処理等で資源を使用するなどしてサービス提供のための資源が不足しているように見せかけることができる。すると、そのような状況を検知した管理エンティティが過大なリソースを割り当ててしまう場合がある。
【0010】
そのようなサービス提供の実態が伴っていない機能単位に対して多くの資源が割り当てられると、他の機能単位等で実際にサービス提供のために資源が必要となった場合に、割り当てられる資源が不足するといった問題が生じる。
【0011】
本発明は、上述した課題に鑑みて、サービス提供の実態と合致した資源の割り当てが可能な資源管理システム、管理装置、資源管理方法および資源管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【0012】
本発明による資源管理システムは、所定の機能をサービスとして提供する1つ以上の機能単位と、機能単位にサービスを実行するための資源を割り当てる資源割当部と、ユーザおよび機能単位の各々について、サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理するポイント管理部とを備え、機能単位の各々は、サービスを、要求元のユーザまたは他の機能単位が保有するポイントと引き換えに提供し、資源割当部は、資源を、割り当て先の機能単位が保有するポイントを減じることにより割り当て、ポイント管理部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、ユーザおよび機能単位の各々のポイントの保有数を管理し、機能単位または機能単位を稼働させているサーバが、機能単位に割り当てられた資源を用いて、ブロックチェーンにブロックを追加するための所定のコンセンサス処理を行い、所定のコンセンサス処理の成功時に、インセンティブとして機能単位にポイントが支払われ、インセンティブ料が、所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められていることを特徴とする。
【0013】
また、本発明による管理装置は、ユーザおよび所定の機能をサービスとして提供する1つ以上の機能単位の各々について、サービスを受けるために必要な仮想通貨とされるポイントの保有数を把握可能なポイント管理情報を保持する情報保持部と、機能単位におけるサービスの提供に応じて要求元のユーザまたは他の機能単位から要求先の機能単位へポイントを移動させる処理および機能単位への資源の割り当てに応じて割り当て先の機能単位が保有するポイントを減少させる処理を、情報保持部に保持されているポイント管理情報を更新または追記することにより行うポイント更新部とを備え、情報保持部およびポイント更新部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、ユーザおよび機能単位の各々のポイントの保有数を管理し、機能単位または機能単位を稼働させているサーバが、機能単位に割り当てられた資源を用いて、ブロックチェーンにブロックを追加するための所定のコンセンサス処理を行い、所定のコンセンサス処理の成功時に、インセンティブとして機能単位にポイントが支払われ、インセンティブ料が、所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められていることを特徴とする。
【0014】
また、本発明による資源管理方法は、所定の機能をサービスとして提供する1つ以上の機能単位と、機能単位にサービスを実行するための資源を割り当てる資源割当部とを備えた資源管理システムにおける資源管理方法であって、1つ以上の情報処理装置が、ユーザおよび機能単位の各々について、サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理し、機能単位におけるサービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へポイントを移動させ、機能単位への資源の割り当てに応じて、割り当て先の機能単位が保有するポイントを減少させ、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、ユーザおよび機能単位の各々のポイントの保有数を管理し、機能単位または機能単位を稼働させているサーバが、機能単位に割り当てられた資源を用いて、ブロックチェーンにブロックを追加するための所定のコンセンサス処理を行い、所定のコンセンサス処理の成功時に、インセンティブとして機能単位にポイントが支払われ、インセンティブ料が、所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められていることを特徴とする。
【0015】
また、本発明による資源管理プログラムは、コンピュータに、ユーザおよび所定の機能をサービスとして提供する1つ以上の機能単位の各々について、サービスを受けるために必要な仮想通貨とされるポイントの保有数を管理する処理、機能単位におけるサービスの提供に応じて、要求元のユーザまたは他の機能単位から要求先の機能単位へポイントを移動させる処理機能単位への資源の割り当てに応じて、割り当て先の機能単位が保有するポイントを減少させる処理、および所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、ユーザおよび機能単位の各々のポイントの保有数を管理する処理を実行させるための資源管理プログラムであって、機能単位または機能単位を稼働させているサーバが、機能単位に割り当てられた資源を用いて、ブロックチェーンにブロックを追加するための所定のコンセンサス処理を行い、所定のコンセンサス処理の成功時に、インセンティブとして機能単位にポイントが支払われ、インセンティブ料が、所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められていることを特徴とする。
【発明の効果】
【0016】
本発明によれば、サービス提供の実態と合致した資源の割り当てが可能となる。
【図面の簡単な説明】
【0017】
図1】本発明の概要を示す説明図である。
図2】ポイントの使用例を示す説明図である。
図3】第1の実施形態の資源管理システムの構成例を示すブロック図である。
図4】第1の実施形態の資源管理システムの他の構成例を示すブロック図である。
図5】ブロックチェーン41のデータ構造の例を示す説明図である。
図6】ブロックチェーン41の改ざん耐性を説明するための説明図である。
図7】台帳管理システム4が備える台帳管理ノード42の例を示すブロック図である。
図8】管理情報の例を示す説明図である。
図9】資源管理部3の動作の一例を示すブフローチャートである。
図10】サービス呼び出し先のエンティティ(機能単位1)の動作例を示すフローチャートである。
図11】サービス呼び出し側のエンティティの動作例を示すフローチャートである。
図12】機能単位1の動作例を示すフローチャートである。
図13】ブロックチェーンの管理方法の例を示す説明図である。
図14】第2の実施形態の概要を示す説明図である。
図15】機能単位1におけるマイニング処理のタイミングの例を示す説明図である。
図16】第2の実施形態の資源管理システムの構成例を示すブロック図である。
図17】第3の実施形態の概要を示す説明図である。
図18】空き時間の例を示す説明図である。
図19】本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。
図20】本発明の資源管理システムの概要を示すブロック図である。
図21】マイクロサービスを利用したサービス提供プログラムの例を示す説明図である。
図22】MSAにおける資源管理方法の例を示す説明図である。
【発明を実施するための形態】
【0018】
以下、本発明の実施形態を、図面を参照して説明する。まず、本発明のコンセプトを簡単に説明する。図1は、本発明の概要を示す説明図である。本発明は、ポイント(仮想通貨)を用いて、各機能単位におけるサービスの利用状況を管理する。そして、該ポイントに基づいて、機能単位に対する資源の割当量を決定する。
【0019】
機能単位におけるサービス提供の利用状況を管理するために、本発明では、より具体的に、サービス提供のエンドポイントとなるユーザに対して一定数のポイントを付与する。ここで、ポイントは、実際にユーザが使用する端末等に付与してもよいが、管理データ上でのみの付与であってもよい。
【0020】
図2は、本発明におけるポイントの使用例を示す説明図である。図2に示すように、本発明では、ユーザは、サービスを利用する毎に要求先の機能単位に対してポイントを支払う。また、各機能単位も、他の機能単位を利用する毎に利用先の機能単位に対してポイントを支払う。このようにして、各機能単位に支払われたポイント数により、サービス提供の実態が表わされるようにする。そして、そのようなサービス提供の度に増加または減少するポイントを使って、各機能単位に資源を割り当てる。例えば、管理エンティティは、各機能単位に、資源獲得時やその後定期的に、当該ポイントで資源使用料を支払わせる。また、管理エンティティは、資源使用料を支払えない場合、資源を割り当てないまたは取り上げる(解放する)等の措置を行う。
【0021】
また、このようなポイントの移動を、サービスの利用情報、資源の割当情報などとともに、システムが保有する1つ以上の情報保持基盤によって管理する。ここで、情報保持基盤は、記憶装置やデータベースシステムといった、情報を保持できる基盤であれば特に問わないが、情報を複数の装置で共有できるブロックチェーンがより好ましい。
【0022】
実施形態1.
【0023】
図3は、第1の実施形態の資源管理システム100の構成例を示すブロック図である。図3に示す資源管理システム100は、複数の機能単位1と、ポイント管理部2と、資源管理部3とを備える。
【0024】
機能単位1は、上記のマイクロサービスなど、サービス提供のための所定の機能を実装し、要求に応じて該機能を提供する独立したユニットである。なお、機能単位1は、独立した装置に限らず、該機能を提供するプログラムであってもよい。すなわち、1つのサーバや仮想化基盤に複数の機能単位1が実装されていてもよい。そのような場合であっても、各々の機能単位1は独立したユニットであるとみなす。また、本発明では、機能単位が提供する機能もサービスの1つとみなす。
【0025】
本実施形態の機能単位1は、サービス提供部11と、ポイント記録部12とを含む。
【0026】
サービス提供部11は、要求に応じて所定の機能を提供する。
【0027】
ポイント記録部12は、ユーザまたは他の機能単位から要求を受け付けた場合や他の機能単位に要求を行った場合など、自身が保有するポイントに変化が生じた場合に、その変化を、後述するポイント管理部2に通知し、記録させる。このとき、ポイント記録部12は、変化したポイント数だけでなく、支払先、支払い元、支払い対象(サービス利用/資源利用等)など、ポイントの取引明細を通知してもよい。
【0028】
ポイント記録部12は、例えば、サービス提供部11に対するモニタリングやサービス提供部11からの通知により、自身(当該ポイント記録部12を有する機能単位1)が保有するポイントの変化を検出してもよい。また、ポイント記録部12は、保有ポイントに変化が生じる度に通知するとトランザクションが多くなりすぎる場合は、一定時間毎や一定回数毎に、前回からの変化をまとめて通知してもよい。
【0029】
ポイント管理部2は、ユーザおよび機能単位1を含む各エンティティについて、ポイントの保有数を管理する。例えば、ポイント管理部2は、システム内での該ポイントの流れを全て記憶することにより、各エンティティのポイントの保有数を管理する。また、ポイント管理部2は、システムまたは各機能単位でサービス利用に必要なポイント数など、各機能単位におけるサービス利用条件を管理してもよい。
【0030】
また、ポイント管理部2は、システム内でポイントを循環させるために、ユーザに対して、一定時間ごとにポイントを回復させる。このとき、回復後のポイントが、ユーザが保持可能なポイントの上限を超えないものとする。また、ユーザおよび機能単位1の各々に、予め初期ポイントが付与されてもよい。例えば、ユーザのシステム加入時に、初期ポイントが付与されてもよい。なお、ユーザのポイント回復や初期ポイントの付与を行う処理部は特に限定されず、資源管理部3や、別途設けたユーザ管理部(不図示)などが行ってもよい。
【0031】
ポイント管理部2は、各エンティティのポイントの保有数を管理するために、例えば、各エンティティの保有ポイントを把握可能な情報を保持する情報保持部21と、各エンティティからの要求または所定の条件に応じて、上記の情報保持部に保持されている保有ポイントを把握可能な情報を更新または追記することにより、ポイントを移動または増減させるポイント更新部22とを含んでいてもよい。
【0032】
資源管理部3は、当該システムの資源を管理し、必要に応じて機能単位1の各々に資源を割り当てたり、割り当てた資源を解放する等の制御を行う。資源管理部3は、図3に示すように、割当制御部31と、資源割当部32とを含む。また、図3では、1つの資源管理部3を示しているが、資源管理部3は複数であってもよい。
【0033】
割当制御部31は、機能単位1の資源の利用状況のモニタリングの結果または要求に基づいて、機能単位1の各々に対する資源の割り当て量を決定する。また、割当制御部31は、機能単位1に資源を割り当てた場合に、割り当て量に応じたポイントを該機能単位1から徴収する。また、割当制御部31は、割り当て量に応じたポイントを徴収できない場合は、新たな資源を割り当てず、要求を拒否したり、または割り当て済みの資源を回収してもよい。このように、割当制御部31は、サービス提供の実態に応じて機能単位1に蓄積されるポイントを減じることで、該機能単位1に資源を提供する。
【0034】
資源割当部32は、割当制御部31が決定した割り当て量に基づいて、各機能単位に資源を割り当てる。
【0035】
また、図4に示すように、資源管理システム100は、ポイント管理部2として、ブロックチェーン41を利用した台帳管理システム4を備えていてもよい。以下では、ポイント管理部2が台帳管理システム4である場合を例に説明する。
【0036】
一般に、ブロックチェーンは、特定の集中管理サーバに依存せず、分散的に情報共有を行うことができる。ブロックチェーンに参加している各端末(後述する台帳管理ノード42)は、ブロックチェーンにブロックを追加する際に所定のコンセンサスアルゴリズムに従う処理(以下、コンセンサス処理という)を行うことにより、改ざんが困難なブロックチェーンを端末間で共有する。なお、図4では、1つのブロックチェーン41を示しているが、ブロックチェーン41は、実際には台帳管理システム4に含まれる台帳管理ノード42の各々に保持される。
【0037】
図5は、ブロックチェーン41のデータ構造の例を示す説明図である。図5に示すように、ブロックチェーン41は、ブロックと呼ばれる所定のデータ構造を備えたデータを繋げた構成をとる。また、ブロックの各々は、前のブロックのハッシュ値(図中の“Hash x”)、ノンス(図中の“nonce x”)、当該ブロックに格納するデータ(図中の“data x”)を含む。ここで、“x”はブロックを識別する識別子を表している。例えば、ブロックnは、ブロックn−1のハッシュ値と、ノンスnと、データnとを含む。なお、データnは、取引情報など、任意のデータでよい。
【0038】
このような改ざんが困難なブロックチェーン41を台帳として利用して、取引明細等のデータ、アプリケーション情報、その他の管理情報、認証情報といった情報を保持させることにより、情報の検証等に利用できる。
【0039】
ここで、ノンスは、当該ブロックチェーン41の改ざん耐性に影響する検証情報であり、具体的には、PoW(Proof of Work)と呼ばれるコンセンサスアルゴリズムを実行する過程で設定される検証情報としての役割を持つ。
【0040】
PoWでは、あるデータについて、そのデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように、当該データ内に含まれるノンス領域に設定する値を探す処理(以降、単にノンスを探す処理と呼ぶ)が行われる。
【0041】
このとき、一方向性関数として、例えば、ハッシュ関数を用いることができる。また、そのときの規則を、「ハッシュ値が閾値(ターゲット値)以下であること」とすることができる。一般に、ノンスを探す処理は一方向性関数の性質から効率良く行うことができないため、当該処理を行う装置は、実際にはノンスに適当な値を設定して規則を満たすか否かを確認する作業を繰り返すこととなる。このような設定と確認の作業を多くのノードに並列して行わせ、最も早く規則を満たすノンスを見つけたノードが他のノードに情報を発信することにより、当該情報に基づいて全ノードに当該ノンスの値を含むデータの状態を確定させる(コンセンサスをとる)。
【0042】
次に、そのようなブロックチェーン41における一般的なブロック追加の流れを説明する。ブロックは、例えば、以下の(1)〜(5)のような動作が行われることにより、ブロックチェーン41に追加される。
【0043】
(1)ブロックチェーン41に情報を記録したい端末は、該情報を当該ブロックチェーン41に参加している端末のいずれかまたはその全てに通知する。
(2)各端末は通知された情報の整合性をチェックし、問題がなければブロックを生成する。
(3)各端末は生成されたブロックについてPoWを開始する。
(4)PoWを終了した端末は、当該PoWで発見されたノンスを設定したブロックを全ての端末に通知する。
(5)ノンスが設定されたブロックを通知された端末は、ハッシュ値や、ブロックに記憶されている情報の整合性をチェックし、問題なければ自身が管理しているブロックチェーン41の末尾にブロックを追加する。
【0044】
なお、上記の(2)の動作において、通知された情報の整合性のチェック方法は、当該ブロックチェーン41を利用するアプリケーションに依存する。また、ブロックを生成する際に、複数の情報を1つのブロックにまとめることが可能である。
【0045】
また、上記の(3)のPoW動作において、各端末は、さらに次の動作を行う。
(3−1)各端末は、まず生成したブロックにランダムなノンス(ノンスの候補)を設定する。
(3−2)次いで、各端末は、ブロックのハッシュ値が所定の規則を満たすか(例えば、あるターゲット値以下であるか)を確認する。
(3−3)規則を満たしていれば、処理を終了し、満たしていなければ、設定したノンスを変更し、(3−2)に戻る。
【0046】
なお、情報が通知された全ての端末が上記の(3)のPoW動作を同時に平行して行う。そして、PoWを最も早く終了した端末は、ブロックチェーン41にブロックを追加する権利を得た端末とみなされる。
【0047】
図6は、ブロックチェーン41の改ざん耐性を説明するための説明図である。図6に示すように、ある端末が過去のブロックに書き込まれた情報(図中の“block n”の“data n”)を改ざんしたとする。すると、当該ブロックのハッシュ値が変化するため、変化後のハッシュ値がターゲット値を超えた場合には、任意の検証タイミングで改ざんが検出される。したがって、改ざんを検出されないようにするためには、当該ブロックのノンス(図中の“nonce n”)を再設定し、ターゲット値以下にする必要がある。
【0048】
しかし、当該ブロックのハッシュ値が変化することにかわりないため、次ブロックに含まれる「前ブロックのハッシュ値」(図中の“block n+1”の“Hach(block n)”)と一致しなくなる。このため、当該ブロックだけでなく、以降の全てのブロックのノンスを再設定する必要がある。一般に、改ざんのためには、膨大の計算量(ブロックチェーンを管理するノードの総計算量の50%以上)が必要になると言われている。
【0049】
図7は、台帳管理システム4が備える台帳管理ノード42の例を示すブロック図である。台帳管理システム4は、2以上の台帳管理ノード42(図示省略)を備えており、ブロックチェーンに新たなブロックを追加する際に、各台帳管理ノードが所定のコンセンサス処理を行い、ブロックチェーン41のコピーを保持する。なお、台帳管理システム4におけるコンセンサスアルゴリズムは、PoWに限定されない。例えば、PoW以外にもBFT(Byzantine fault tolerance)等のコンセンサスアルゴリズムも利用可能である。
【0050】
図7に示す台帳管理ノード42は、データ受付部421と、ブロック生成部422と、ブロック共有部423と、情報記憶部424と、ブロック検証部425と、データ出力部426とを含む。なお、本例の場合、情報記憶部424が上記の情報保持部21に相当し、ブロック生成部422が上記のポイント更新部22に相当する。
【0051】
データ受付部421は、外部ノードから、ブロックチェーン41に記録する情報を受け付ける。本実施形態では、データ受付部421は、ブロックチェーン41に記録する情報として、後述するサービス利用情報や、資源割当情報や、ポイント支払情報等を受け付ける。
【0052】
ブロック生成部422は、データ受付部421が受け付けた情報を用いて、ブロックチェーンに追加するブロックを生成する。ブロック生成部422は、前ブロックに基づく情報(Hash値等)と、データ受付部421が受け付けた情報とを含むブロックを生成する。また、ブロック生成部422は、自身が生成したブロックまたは後述するブロック共有部423を介して他の台帳管理ノード42が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理や署名を付与する処理を行った上で、自身が管理するブロックチェーン(ブロックチェーン41のコピーに相当)にブロックを追加する。なお、ブロック生成部422が生成したブロックに対して、複数の台帳管理ノード42が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン41に追加されるブロックとなる。以下、コンセンサス処理を含む、ブロックチェーンにブロックを追加するための処理を、マイニングと呼ぶ場合がある。
【0053】
ブロック共有部423は、台帳管理システム4に属する台帳管理ノード42間で情報交換を行う。ブロック共有部423は、より具体的には、データ受付部421が受け付けた情報や、ブロック生成部422が生成したブロックや、他の台帳管理ノード42から受け付けたブロック等を、適宜他の台帳管理ノード42に送信する。これにより、可能な限り全ての台帳管理ノード42でこれらの情報および最新のブロックチェーン41を共有する。
【0054】
情報記憶部424は、ブロックチェーン41のコピーを記憶する。なお、情報記憶部424は、ブロックチェーン41のコピー以外にも、例えば、後述するブロック検証部425での検証処理に必要となる情報などを記憶してもよい。
【0055】
ブロック検証部425は、自身が保持するブロックチェーンにブロックを追加する際に、該ブロック内の検証を行う。例えば、ブロック検証部425は、追加するブロックが実際に規則を満たしているか、ブロックを作成したノードと署名が一致するか、追加するブロックに含まれる前ブロックに基づく情報が実際の前ブロックから生成した情報と一致するかなどを検証してもよい。
【0056】
データ出力部426は、外部ノードからの要求に応じて、自身が保持するブロックチェーン41の中から所望の情報を含むブロックを検索して出力する。
【0057】
なお、図7の構成はあくまで一例であって、台帳管理ノード42は、改ざんが困難なブロックチェーン41を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて台帳への情報追加および台帳の参照が可能なノードであれば、具体的な構成は問わない。
【0058】
ブロックチェーン41を用いる場合、各ユーザの端末および各機能単位は、ブロックチェーン41を利用するエンティティとして動作する。典型的には、各エンティティは、秘密鍵、公開鍵のペアを持ち、秘密鍵でトランザクションに署名を付加してマイナー(例えば、上記の台帳管理ノード42)に送付する。各マイナーは、送付されたトランザクションに基づき、ブロックチェーンへブロックを追加する。各エンティティは、システムに参加する際、他のエンティティ等からマイナーの情報を取得可能とする。
【0059】
また、図8は、ポイント管理部2(本例では、ブロックチェーン41)が保持するポイント管理情報の例を示す説明図である。ポイント管理部2は、ポイント管理情報として、例えば、サービス利用情報と、資源割当情報と、支払い情報とを記憶してもよい。
【0060】
サービス利用情報は、各機能単位におけるサービスの利用状況を示す情報である。サービス利用情報は、例えば、トランザクション種別と、時刻と、呼び出し元識別子と、呼び出し先識別子と、利用回数と、支払いポイントとを含んでいてもよい。
【0061】
ここで、トランザクション種別は、当該レコードを発行したトランザクションの種類を表す。例えば、図中の“T1”は、当該レコードがサービス利用情報のトランザクションであることを表している。当該トランザクションは、例えば、サービスを呼び出したエンティティ(呼び出し元エンティティ)により発行される。時刻は、サービスが利用された時間または時間帯を表す。呼び出し元識別子は、サービスを呼び出したエンティティの識別子を表す。呼び出し先識別子は、サービスが呼び出されたエンティティの識別子を表す。利用回数は、時刻が示す時間または時間帯に行われた、当該読み出し元と読み出し先の組によるサービス利用の回数を表す。なお、サービス利用の度にサービス利用情報を登録する場合には、利用回数は省略可能である。支払いポイントは、当該レコードが示すサービス利用によって支払われたポイント数を表す。ここで、該ポイント数は、より具体的には、当該レコードの時刻が示す時間または時間帯において、読み出し元エンティティが読み出し先エンティティに支払ったポイントの総数である。
【0062】
また、資源割当情報は、各機能単位への資源割り当て状況を示す情報である。資源割当情報は、例えば、トランザクション種別と、割り当て開始時刻と、資源情報と、割り当て先識別子と、支払いポイントとを含んでいてもよい。
【0063】
トランザクション種別は、当該レコードを発行したトランザクションの種類を表す。例えば、図中の“T2”は、当該レコードが資源割当情報のトランザクションであることを表している。当該トランザクションは、例えば、資源割り当てを行ったエンティティ(資源管理部3)により発行される。割り当て開示時刻は、資源割り当てを開始した時間を表す。資源情報は、割り当てた資源の詳細を表す。ここで、資源情報には、割り当てた資源を特定可能な情報(識別子等)と、割り当てた資源の量とが含まれていることが好ましい。割り当て先識別子は、資源の割り当て先のエンティティ(より具体的には機能単位)の識別子である。支払いポイントは、当該レコードが示す資源の割り当てによって支払われたポイント数を表す。ここで、該ポイント数は、より具体的には、当該レコードが示す時間において割り当て先エンティティに当該資源を割り当てた時に、該エンティティが支払ったポイントの総数である。
【0064】
また、支払い情報は、定期的な資源使用料や、ユーザへのポイント回復等、サービス利用が伴わないポイントの支払い状況を示す情報である。支払い情報は、例えば、トランザクション種別と、時刻と、支払い元識別子と、支払い先識別子と、支払い対象と、支払いポイントとを含んでいてもよい。
【0065】
トランザクション種別は、当該レコードを発行したトランザクションの種類を表す。例えば、図中の“T3”は、当該レコードが支払い情報のトランザクションであることを表している。時刻は、当該レコードが示すポイントの支払いが行われた時間を表す。支払い元識別子は、当該レコードが示すポイントの支払い元エンティティの識別子を表す。支払い先識別子は、当該レコードが示すポイントの支払い先エンティティの識別子を表す。支払い対象は、当該レコードが示すポイントの支払いが行われた対象(支払い事由)を表す。支払い対象を示す情報は、例えば、割り当て済みの資源にかかる使用料であれば、資源割当情報に含まれる資源を特定する情報であってもよい。また、例えば、支払い対象を示す情報は、例えば、ユーザへの定期的なポイントの回復であれば、回復を表す情報であってもよい。
【0066】
なお、上記のポイント管理情報に関し、例えば、情報の内容から、どのような情報が記憶されているかが把握可能な場合は、トランザクション種別は省略可能である。また、機能単位ごとの1回の呼び出しにかかるポイント数の情報や、資源ごとの割り当てにかかるポイント数の情報などが予めポイント管理部2に保持されている場合など、サービス利用および/または資源割り当てにかかるポイント数が他の情報から把握可能であれば、支払いポイントは省略可能である。また、支払いポイントに代えてまたは支払いポイントとともに、支払い元および支払い先のポイント支払い前後のポイント数を含んでいてもよい。
【0067】
また、ポイント管理部2は、上記情報に加えて、ユーザに関する情報や、ユーザおよび機能単位の各々が保有するポイントを管理するポイント情報を記憶してもよい。なお、ポイント情報以外の情報を参照することにより、各エンティティの保有ポイントを把握可能な場合は、ポイント情報は省略可能である。ユーザに関する情報は、例えば、特定の管理エンティティにユーザ追加の特権を与え、そのエンティティのみがユーザに関する情報を追加、変更できるようにしてもよい。なお、ユーザに関する情報の管理をポイント管理部2では行わずに、別途専用のエンティティ(データベースなど)に行わせてもよい。
【0068】
また、ポイント管理部2は、上記情報に加えて、機能単位のサービス利用料(機能単位使用料)や、資源の使用料(資源使用料)を示す使用料情報を記憶してもよい。特に、使用料が時刻や他の条件等によって変動する場合、条件とともに、使用対象(機能単位の識別子や資源の種別等)と使用料とを含む使用料情報を記憶してもよい。
【0069】
なお、図8には、表形式でポイント管理情報を保持する例が示されているが、ブロックチェーン41を利用する場合には、各々のレコードの内容をそれぞれ、データ(図5中の“data”)として含むブロックを作成し、ブロックチェーン41に随時追加していけばよい。
【0070】
次に、本実施形態の動作を説明する。図9は、本実施形態の資源管理部3の動作の一例を示すフローチャートである。図9に示す例では、まず、割当制御部31が、資源割り当て要求を受信したか否かを判定する(ステップS101)。割当制御部31は、資源割り当て要求を受信した場合(ステップS101のYes)、要求元の保有ポイントを確認する(ステップS102)。要求元が該要求に応じたポイントを所持していた場合(ステップS103のYes)、割当制御部31は、資源割当部32に依頼して、要求に応じた資源の割り当てを実行させる(ステップS104)。そして、割当制御部31は、割り当て結果に応じて、要求元からポイントを徴収する(ステップS105:ポイントの移動)。
【0071】
一方、要求元が該要求に応じたポイントを所持していなかった場合(ステップS103のNo)、割当制御部31は、要求を拒否する(ステップS106)。
【0072】
また、割当制御部31は、現在のタイミングが、資源使用料の徴収タイミングか否かを判定する(ステップS107)。資源使用料の徴収タイミングか否かは、例えば、資源の割り当て後又は前回徴収後から一定の時間が経過したか否かにより判定してもよい。
【0073】
徴収タイミングであった場合(ステップS107のYes)、割当制御部31は、割り当て済みの資源に対する使用料を、割り当て先のエンティティから徴収する(ステップS108:ポイントの移動)。徴収タイミングでなかった場合(ステップS107のNo)、割当制御部31は、そのままステップS109に進む。
【0074】
ステップS109で、割当制御部31は、現在のタイミングが、ユーザのポイント回復タイミングか否かを判定する。ユーザのポイント回復タイミングか否かは、例えば、ユーザがサービス加入後又は前回回復後から一定の時間が経過したか否かにより判定してもよい。
【0075】
回復タイミングであった場合(ステップS109のYes)、割当制御部31は、当該ユーザのポイントを所定数もしくは所定の上限まで回復させる(ステップS110)。回復タイミングでなかった場合(ステップS109のNo)、割当制御部31は、そのまま処理を終了する。なお、ステップS109〜S110の動作は、割当制御部31以外の処理部が行ってもよい。
【0076】
また、図10は、サービスを呼び出された機能単位1の動作例を示すフローチャートである。図10に示す例では、まず機能単位1のサービス提供部11がサービスを受け付ける(ステップS201)。該サービスの要求元は、例えば、本システムに登録したユーザの端末や、該端末から呼び出された機能単位である。
【0077】
サービス提供部11がサービスを受け付けると、まずポイント記録部12が、要求元の保有ポイントを確認する(ステップS202)。要求元が該要求に応じたポイントを所持していた場合(ステップS203のYes)、サービス提供部11は、要求されたサービスを実行する(ステップS204)。そして、該サービスの実行に伴い、ポイント記録部12が、要求元からポイントを徴収する(ステップS205:ポイントの移動)。これにより、サービス要求元のエンティティからサービス提供側のエンティティにポイントが移動する。
【0078】
なお、サービス呼び出し時にポイントを徴収した上で、サービス提供部11がサービス提供を行うことも可能である。このとき、サービス提供部11は、サービスの提供に失敗した場合、要求元のエンティティにポイントを支払ってもよい。支払うポイントは、呼び出し時に徴収したポイントと同額でもよいし、予め決められた一定の値でもよい。また、サービス要求時に、サービス提供に失敗した場合に支払われるポイント数を指定してもよい。
【0079】
一方、要求元が該要求に応じたポイントを所持していなかった場合(ステップS203のNo)、サービス提供部11は、該要求を拒否する(ステップS206)。
【0080】
また、図11は、サービス呼び出し側のエンティティの動作例を示すフローチャートである。図11に示す例では、まずあるエンティティが、他の機能単位1のサービスを呼び出す(ステップS211)。そして、サービスが提供されると、該サービスに応じたポイントを支払う(ステップS212:ポイント移動)。なお、ステップS212の動作は、図10のステップS205の動作に対応する。
【0081】
また、図12は、ある機能単位1が新たな資源の割り当てを要求する場合の動作例を示すフローチャートである。図12に示す例では、まず機能単位1のサービス提供部11が、資源の割り当てが必要か否かを判定する(ステップS221)。資源の割り当てが必要と判定された場合(ステップS221のYes)、サービス提供部11は、資源の割当要求を資源管理部3に送信する(ステップS222)。
【0082】
そして、資源の割り当てが完了すると、割り当てられた資源に応じたポイントを支払う(ステップS222:ポイント移動)。なお、ステップS222の動作は、図9のステップS105の動作に対応する。
【0083】
尚、上記の各例において、保有ポイントの確認は、ポイント管理部2(本例では、ブロックチェーン41)が保持している情報を参照することにより行ってもよい。また、ポイントの移動および回復は、対象と移動ポイント等の情報を含むトランザクションを発行し、ブロックチェーン41に該移動よび回復を記録させることにより行ってもよい。このとき、該トランザクションは、台帳管理システム4の台帳管理ノード42のいずれかに受信され、所定のコンセンサス処理を経て、ブロックチェーン41に該トランザクションの情報を含むブロックが追加される。
【0084】
また、上記実施形態において、資源使用料を、システム内の資源の使用状況に基づいて定めてもよい。例えば、割り当てられる資源の残量が少ないほど、使用料を高くしてもよい。このようにすれば、ポイントを多く保有している機能単位すなわちより多く利用されている機能単位に、優先的に資源を割り当てることができる。このとき、ポイント管理部2は、資源の残量を示す情報や使用料を示す情報を保持してもよい。
【0085】
また、機能単位1が資源を自主的に解放(返却)できるようにしてもよい。このとき、ポイントの返却はあってもよいし、なくてもよい。ポイントの返却がない場合でも、資源を解放することで、以降の定期的な使用料の支払いをなくすことができる。機能単位1の各々は、資源を解放する際には、資源割り当て時と同様、その旨を示すトランザクションを発行すればよい。
【0086】
また、機能単位1の各々におけるサービス利用料を、当該サービスの輻輳状態に基づいて決定してもよい。例えば、同時に多くの呼び出しを受けているサービスほど、利用料を高くしてもよい。このようにすれば、ポイントを多く保有しているエンティティに優先的にサービスを提供できるため、DoS攻撃等に対する防御をより高められる。このとき、ポイント管理部2は、サービスの利用状況を示す情報やサービス利用料を示す情報を保持してもよい。
【0087】
また、例えば、サービス利用料を、提供元の機能単位1が所属するデータセンタやインスタンスごとに設定することも可能である。例えば、多くのユーザや他の機能単位に対してサービスを提供しているインスタンスほどサービスの使用料を高く設定することができる。こうすることで、よりサービス利用料が少ないインスタンスの利用が促進され、負荷分散を行うことができる。
【0088】
また、サービス利用料の支払いタイミングによって該利用料を変動させてもよい。例えば、前払いか後払いかによって、また前払いと後払いの配分によって、サービス利用料を変えてもよい。前払いと後払いとによって支払いを分けることで、呼び出す側と呼び出される側で、サービス提供が失敗した場合のリスクを分担することができる。また、サービス利用料だけでなくサービスの優先度を変更することも可能である。
【0089】
また、過去にサービス利用料や資源使用料が未払いとなったエンティティに対して、所定回数分のサービスの拒否や優先度を下げる等のペナルティを課すことも可能である。
【0090】
以上のように、本実施形態によれば、各機能単位は、資源を割り当てられるためには、ユーザや他の機能単位からサービスを利用されなければならない。したがって、サービス提供の実態が伴っていない架空のビジー状態を装って資源の割り当て要求を行うなどといった、不正な資源割り当て要求を抑制できる。また、本実施形態によれば、各ユーザが時間あたりに使用できるポイントが限られるため、DoS攻撃等、ユーザ側の悪意ある呼び出し等によるビジー状態および該ビジー状態を起因とする不適切な資源割り当ても抑制できる。その結果、不適切な資源割り当てが減り、実際にサービスを提供している機能単位に優先的に資源を割り当てることができる。
【0091】
また、本実施形態によれば、例えば、結合度の弱いマイクロサービスを利用したMSAのように、個々の機能単位が独立して資源を要求する場合であっても、ポイントを通して市場原理が働くことで需要にマッチした資源の割り当てが実現される。
【0092】
例えば、機能単位1のサービス利用料に関して、予め初期値を定めておき、その後需要に合わせて変動させる。そのようにすれば、輻輳時において、より多くのポイントを持っている(需要の多い)機能単位1が優先して他のサービスを利用できるという市場原理が働き、適切な資源割り当てが行われる。また、例えば、データセンタやインスタンス毎にサービス利用料を設定できるようにすることで、同じ機能を提供する機能単位1でも、正常な値段のインスタンスに処理が流れるようにできる。なお、この場合も、安すぎる設定の場合は資源が維持できないようにできるので、ぼったくりや不当廉売といった異常な値段設定をするインスタンスを排除する市場原理が働き、適切な資源割り当てが行われる。
【0093】
また、例えば、資源使用料に関して、予め初期値を定めておき、その後需要に合わせて変動させてもよい。そのようにすれば、輻輳時において、より多くのポイントを持っている(需要の多い)機能単位1が優先して資源を利用できるという市場原理が働き、適切な資源割り当てが行われる。また、例えば、割り当て先の機能単位1における資源の使用量(割り当て量)に応じて、資源使用料を変動させてもよい。そのようにして、1つの機能単位が多くの資源を持ちすぎないようにもできる。
【0094】
また、本システムで働くであろう市場原理の他の例および効果として、ユーザは、配布されるポイント分しかサービスを利用できないため、利用する必要が高いサービスや安いサービスを利用することにより、負荷が分散されるというメリットがある。
【0095】
また、機能単位1の各々は、例えば、割り当て済みの資源量に対してサービス需要が多い場合に、サービス利用料を上げて、要求者を減らすことができる。また、需要が多い場合はそれだけポイント増加につながるため、ポイントが増加した分、新たな資源を取得できる。一方、割り当て済みの資源量に対してサービス需要が少ない場合は、資源を返却してポイントの支払いを減らすことができる。このように、需要に合わせて適切な量の資源を保持できる。
【0096】
また、本実施形態によれば、リソースサーバ(より具体的には、資源管理部3)が、自身の資源の残量が多い場合は使用料を低めに設定し、少ない場合は使用料を高めに設定できる。これにより、より必要度が高い(多くのユーザからアクセスされていて、ポイントを多く保有している)機能単位に優先的に資源を割り当てられるようにしてもよい。また、このようにして使用料を変動させることにより、資源が多く残っているリソースサーバを優先的に利用されやすくできる。
【0097】
また、輻輳時の上記挙動の他の効果として、DoS状態に陥りサービスが困難な機能単位は、サービス需要があってもサービス提供ができなくなるため、資源使用料が払えず資源を維持できなくなる。これを利用して、フロントエンド側のサービスに資源が偏ってしまった場合に、偏りを平衡化できる。
【0098】
また、例えば、ネットワークが分断するなどして、サービスの需要と供給のバランスが変化した場合も、需要が減った機能単位は資源を解放し、需要が増えた機能単位は新たな資源を確保するといった動作が期待される。このように、本実施形態によれば、需要に合わせて資源の割り当て量を最適化できる。
【0099】
また、本実施形態では、各エンティティの保有ポイントを確認するだけで資源を割り当てることができるので、1つの管理エンティティがシステム全体を監視して、サービス提供に必要な資源等を管理する必要がない。すなわち、ポイントを介して各機能単位の利用状況を定量化することにより、機能単位1および資源管理部3がそれぞれ完全分散的に動作して資源の獲得と解放を行うことができるので、各々の独立性を高く保つことができる。また、そのようにして各エンティティの独立性を高くしても、各ユーザが所持できるポイントの総数を制限することにより、過大な資源の割り当てを抑制できる。
【0100】
例えば、悪意のあるユーザが、DoS攻撃目的で特定の機能単位への呼び出しを繰り返したとしても、ポイントが枯渇するため一定量以上の呼び出しを防止できる。仮に、複数のユーザが結託した場合であっても、需要高により該機能単位のサービス利用料を上げることで、DoS攻撃の効果を薄めることができる。
【0101】
同様に、例えば、悪意のある機能単位が、他の機能単位にDoS攻撃を行ったり、使用しない資源の過大要求を行ったとしても、ポイントが枯渇するため一定量以上の攻撃や要求を防止できる。
【0102】
また、ブロックチェーンへの記録に関して、ブロックが後ろに追加されるのを待たずに情報を信じる「0 confirmation」で処理を進め、不整合が起きた場合に後でペナルティを与えることも可能である。
【0103】
例えば、あるエンティティが、n重支払い等の不正な機能単位の使用や、使用したのに使用していないと申告するような不正を働いたとしても、改ざん耐性の高いブロックチェーンを利用するなどして不正の有無をチェックすることで、以降のサービスや資源割り当てを拒否するといったペナルティを課すことができる。
【0104】
実施形態2.
次に、第2の実施形態について説明する。本実施形態では、ポイント管理部2として台帳管理システム4を用いることを前提に、機能単位1の各々にブロックチェーン41の管理機能を持たせる。
【0105】
図13は、リソースサーバのみが空きリソースを用いてブロックチェーンの管理(より具体的にはPoW)を行う場合の問題点を説明するための説明図である。図13に示すように、リソースサーバのみが空きリソースを用いてブロックチェーンの管理を行う場合、CPUリソースが逼迫する状況で、ブロックチェーンを管理するのが難しくなる。これは、ブロックチェーンにブロックを追加する際に必要となるPoWに使用できるリソースが不足して、改ざん防止に必要な計算量が確保できず、ブロックチェーンのセキュリティが低下するためである。
【0106】
そこで、本実施形態では、機能単位1の各々にもマイニング、すなわちPoWを行う機能を持たせる。そして、マイニング成功時には、インセンティブとしてポイントを付与する。このとき、特定の機能単位が計算量を保持しすぎないように、インセンティブ料や資源使用料を決定してもよい。
【0107】
図14および図15は、本実施形態の概要を示す説明図である。図14に示すように、本実施形態では、機能単位1の各々は、さらにマイニングを行うマイナーとしても動作する。例えば、“機能単位A”は、“マイナーA”としても動作する。機能単位1の各々は、例えば、図15に示すように、割り当てたリソースを使用して空き時間にマイニングに参加する。ここで、空き時間の例としては、他のエンティティからのリクエスト(サービス要求)の量が減った時間や、他の機能単位からのレスポンス待ちの時間などが挙げられる。
【0108】
図16は、本実施形態の資源管理システムの構成例を示すブロック図である。図16に示すように、本実施形態では、機能単位または機能単位を稼働させるコンテナとしてのサーバ10(仮想化基盤等)に、台帳管理ノード42の各機能またはその一部(例えば、図7のブロック生成部422と情報記憶部424等)を実装したPoW部13を追加する。
【0109】
PoW部13は、例えば、自身が生成したブロックまたは他の台帳管理ノード42が生成したブロックに対して、所定のコンセンサス処理を行って、成功した場合に該ブロックをブロックチェーン41に追加する処理を行う。
【0110】
図16に示す例において、ある機能単位1は、サーバ(仮想化基盤)10に備えられている。このとき、サーバ10は、2以上の機能単位1を実装してもよい。そして、そのようなサーバ10やサーバ10上で動作する機能単位1に、機能単位1に割り当てられた資源を用いて所定のコンセンサス処理を少なくとも行うPoW部13を設ける。なお、図16では、1つのブロックチェーン41を示しているが、ブロックチェーン41は、実際には台帳管理ノード42の各々に保持される。このとき、該台帳管理ノード42には、PoW部13を有する機能単位1やサーバ10が含まれていてもよい。
【0111】
なお、マイニング成功時のインセンティブ料は、次のように定められるのが好ましい。すなわち、マイニングのターゲット値と資源使用料とに基づいて、インセンティブ料が定められるのが好ましい。
【0112】
一例として、ターゲット値をT、単位時間あたりで行える一方向性関数の計算回数(マイニングに費やす計算量)をC、ノンスの最大値をNmax、単位時間当たりのマイニング成功確率をP(T,C)=1−(1−T/Nmax)、単位時間当たりの資源使用料をV、インセンティブをVとしたとき、以下に示す式(1)を満たすようにすると好ましい。
【0113】
*P(T,C)<V ・・・(1)
【0114】
ここで、上記の式(1)におけるマイニングに費やす計算量Cを、割り当て済みの資源量のみを用いて計算してもよいし、サービス利用状況を含めて計算することも可能である。他の例としては、単純に、割り当て済みの資源が多いほどインセンティブを小さくしてもよい。なお、単位時間当たりの資源使用料を、マイニングのターゲット値とマイニング成功時のインセンティブ料とに基づいて定めることも可能である。
【0115】
いずれにしても、マイニングだけをし続けると赤字になるように、インセンティブ料または資源の単位時間当たりの使用料が設定されればよい。これにより、悪意のある機能単位1やサーバ10が、自身または自身の上で動作する機能単位に割り当てられた資源を全てマイニングに費やしてブロックチェーン41を改ざんしようとする試みを抑制する。
【0116】
以上のように、本実施形態によれば、インセンティブを与えて各機能単位1にマイニング作業に従事するまたはそのための資源の貸し出しを行う動機付けを行うことにより、悪意あるノードからの改ざん防止に必要な計算量を確保する。その結果、ブロックチェーンのセキュリティ低下を防止できる。
【0117】
また、本実施形態によれば、割り当てられた資源量に対してサービス需要が少ない機能単位1が一時的にマインニングに参加してポイントを得ることができるので、機能単位1における需要の変動に対する資源量の変動を緩やかにできる。なお、他の点は第1の実施形態と同様である。
【0118】
実施形態3.
本実施形態では、ユーザに優先度を持たせ、優先度に応じたサービス提供の優先制御が行われるようにする。
【0119】
図17は、本実施形態の概要を示す説明図である。図17に示す例では、各ユーザが、他の機能単位を利用する際に、追加料金(追加ポイント)の支払いを行うことができるようにしている。要求を受け取った側は、追加料金が多いほど、その要求を優先的に処理する。
【0120】
本実施形態では、ユーザに優先度を設定する。その上で、優先度ごとに追加料金の上限を設定する。ユーザは、自身に設定された優先度に応じた上限に収まる範囲で、自由に追加料金を設定できる。また、要求を受け取った機能単位は、追加料金に応じて優先的にサービスを提供する。
【0121】
優先度ごとの追加料金の上限は、呼び出し先の機能単位1のサービス利用料に対する割合として定められてもよいし、呼び出し先の機能単位1に関わらず、全ての機能単位1に対して一律に定められてもよい。
【0122】
また、優先度の情報や優先度ごとの追加料金の上限の情報は、例えば、ブロックチェーン41に記憶してもよいし、管理サーバやデータベース等を用いて共有してもよい。
【0123】
なお、呼び出し先の機能単位1の各々における優先処理の仕方は、特に問わない。一例として、機能単位1は、追加料金に応じて処理順序を変えてもよい。また、例えば、機能単位1は、「追加料金がxx以上であれば、資源の使用率がyy以上であってもサービスを提供する」など、追加料金に応じて混雑時のサービス提供の可否の判定基準を変えてもよい。また、例えば、機能単位1は、追加料金に応じて、現在提供中のサービスのうち追加料金が低いサービスの提供を中止し、追加料金の高いサービスのための資源を確保してもよい。このとき、機能単位1は、中止したサービスに対して、サービス失敗時の補償ポイントを支払ってもよい。さらに、機能単位1は、現在提供中のサービスのサービス失敗時の補償ポイントが新たに受け付けたサービスの追加料金以下ならば、現在提供中のサービスを中止するといった判断を行ってもよい。
【0124】
また、本実施形態では、機能単位1が、追加料金が支払われたサービスを行うために他の機能単位1を呼び出す場合、該サービスに対し支払われた追加料金の範囲内で呼び出し先の機能単位1に追加料金を払うことができるようにする(図18参照)。また、機能単位1は、サービス提供に失敗した場合には、追加料金相当またはそれよりも多いポイントを払い戻すようにしてもよい。このようにすることで、機能単位1において、追加料金をもらっておきながら通常の優先度でサービスを提供するような振る舞いを抑制できる。
【0125】
また、優先度が高いユーザほど定期的に回復させるポイント数を多くしてもよい。なお、他の点は第1の実施形態および第2の実施形態と同様でよい。
【0126】
本実施形態によれば、ユーザに優先度を持たせることができ、優先度が高いユーザであって優先制御を所望するユーザに対して、優先的にサービスを提供できる。
【0127】
次に、本発明の実施形態にかかるコンピュータの構成例を示す。図19は、本発明の実施形態にかかるコンピュータの構成例を示す概略ブロック図である。コンピュータ1000は、CPU1001と、主記憶装置1002と、補助記憶装置1003と、インタフェース1004と、ディスプレイ装置1005と、入力デバイス1006とを備える。
【0128】
上述した機能単位1や資源管理部3や台帳管理ノード42といった資源管理システムの構成要素は、例えば、コンピュータ1000に実装されてもよい。その場合、各装置の動作は、プログラムの形式で補助記憶装置1003に記憶されていてもよい。CPU1001は、プログラムを補助記憶装置1003から読み出して主記憶装置1002に展開し、そのプログラムに従って上記の実施形態における所定の処理を実施する。
【0129】
補助記憶装置1003は、一時的でない有形の媒体の一例である。一時的でない有形の媒体の他の例として、インタフェース1004を介して接続される磁気ディスク、光磁気ディスク、CD−ROM、DVD−ROM、半導体メモリ等が挙げられる。また、このプログラムが通信回線によってコンピュータ1000に配信される場合、配信を受けたコンピュータは1000がそのプログラムを主記憶装置1002に展開し、上記の実施形態における所定の処理を実行してもよい。
【0130】
また、プログラムは、各実施形態における所定の処理の一部を実現するためのものであってもよい。さらに、プログラムは、補助記憶装置1003に既に記憶されている他のプログラムとの組み合わせで上記の実施形態における所定の処理を実現する差分プログラムであってもよい。
【0131】
インタフェース1004は、他の装置との間で情報の送受信を行う。また、ディスプレイ装置1005は、ユーザに情報を提示する。また、入力デバイス1006は、ユーザからの情報の入力を受け付ける。
【0132】
また、実施形態における処理内容によっては、コンピュータ1000の一部の要素は省略可能である。例えば、装置がユーザに情報を提示しないのであれば、ディスプレイ装置1005は省略可能である。
【0133】
また、各装置の各構成要素の一部または全部は、汎用または専用の回路(Circuitry)、プロセッサ等やこれらの組み合わせによって実施される。これらは単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、各装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
【0134】
各装置の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
【0135】
次に、本発明の資源管理システムの概要を説明する。図20は、本発明の資源管理システムの概要を示すブロック図である。図20に示す資源管理システム500は、1つ以上の機能単位501と、資源割当部502と、ポイント管理部503とを備える。
【0136】
機能単位501(例えば、機能単位1)の各々は、所定の機能をサービスとして提供する。このとき、機能単位501の各々は、サービスを、要求元のユーザまたは他の機能単位501が保有するポイントと引き換えに提供する。
【0137】
資源割当部502(例えば、資源管理部3)は、機能単位501にサービスを実行するための資源を割り当てる。このとき、資源割当部502は、資源を、割り当て先の機能単位501が保有するポイントを減じることにより割り当てる。
【0138】
ポイント管理部503(例えば、ポイント管理部2)は、ユーザおよび機能単位501の各々について、サービスを受けるために必要な仮想通貨であるポイントの保有数を管理する。
【0139】
このような構成により、サービス提供の実態と合致した資源の割り当てが可能となる。
【0140】
また、資源管理システムは、一定時間ごとにユーザのポイントを回復させるポイント回復部と、割り当て済みの資源について、割り当て先の機能単位から一定時間ごとにポイントを徴収するポイント徴収部とをさらに備えていてもよい。
【0141】
また、ポイント管理部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを利用して、ユーザおよび機能単位の各々のポイントの保有数を管理してもよい。
【0142】
また、このとき、機能単位または機能単位を稼働させているサーバが、機能単位に割り当てた資源を用いて、ブロックチェーンにブロックを追加するための所定のコンセンサス処理を行ってもよい。
【0143】
また、このとき、所定のコンセンサス処理の成功時に、インセンティブとして機能単位にポイントが支払われ、インセンティブ料が、所定のコンセンサス処理に用いられるターゲット値と単位時間あたりの資源使用料とに基づいて定められている、または、単位時間あたりの資源使用料が、所定のコンセンサス処理に用いられるターゲット値とインセンティブ料とに基づいて定められていてもよい。
【0144】
また、上記の資源管理システムにおいて、単位時間あたりの資源使用料が、資源を管理する資源割当部における資源の残数に応じて変動する、または、機能単位のサービスの利用料が、機能単位におけるサービスの輻輳状態に応じて変動してもよい。
【0145】
また、上記の資源管理システムにおいて、ユーザごとに優先度が予め決定されており、ユーザは、機能単位にサービスを要求する際に、優先度に応じて上限が定められている追加ポイントを付与することができ、機能単位は、追加ポイントに応じて、要求を優先的に処理してもよい。
【0146】
また、ポイント管理部は、ユーザおよび機能単位の各々の保有ポイントを把握可能なポイント管理情報を保持する情報保持部と、ユーザ、機能単位または資源割当部からの要求に応じて、情報保持部に保持されているポイント管理情報を更新または追記することにより、ポイントを移動または増減させるポイント更新部とを含み、情報保持部は、所定のコンセンサス処理を経てブロックが追加されるブロックチェーンを管理する1つ以上のノードに実装され、ポイントの移動または増減を示す情報を含むブロックが順次追加されるチェーンブロックを記憶し、ポイント更新部は、1つ以上のノードに実装され、ポイントの移動または増減を示す情報を含むブロックをブロックチェーンに追加する処理を行ってもよい。
【0147】
以上、実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【産業上の利用可能性】
【0148】
本発明は、レジリエントにサービスを提供する用途に好適に適用可能である。
【符号の説明】
【0149】
100 資源管理システム
1 機能単位
10 サーバ
11 サービス提供部
12 ポイント記録部
13 PoW部
2 ポイント管理部
21 情報保持部
22 ポイント更新部
4 台帳管理システム
41 ブロックチェーン
42 台帳管理ノード
421 データ受付部
422 ブロック生成部
423 ブロック共有部
424 情報記憶部
425 ブロック検証部
426 データ出力部
3 資源管理部
31 割当制御部
32 資源割当部
1000 コンピュータ
1001 CPU
1002 主記憶装置
1003 補助記憶装置
1004 インタフェース
1005 ディスプレイ装置
1006 入力デバイス
500 資源管理システム
501 機能単位
502 資源割当部
503 ポイント管理部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22