JP2023032752A - 管理装置、方法、およびプログラム - Google Patents
管理装置、方法、およびプログラム Download PDFInfo
- Publication number
- JP2023032752A JP2023032752A JP2021139054A JP2021139054A JP2023032752A JP 2023032752 A JP2023032752 A JP 2023032752A JP 2021139054 A JP2021139054 A JP 2021139054A JP 2021139054 A JP2021139054 A JP 2021139054A JP 2023032752 A JP2023032752 A JP 2023032752A
- Authority
- JP
- Japan
- Prior art keywords
- data processing
- user
- upper limit
- data
- users
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 22
- 238000011084 recovery Methods 0.000 claims abstract description 13
- 238000007726 management method Methods 0.000 claims 14
- 238000005516 engineering process Methods 0.000 abstract description 4
- 230000002349 favourable effect Effects 0.000 abstract 1
- 238000010586 diagram Methods 0.000 description 9
- 235000017166 Bambusa arundinacea Nutrition 0.000 description 2
- 235000017491 Bambusa tulda Nutrition 0.000 description 2
- 241001330002 Bambuseae Species 0.000 description 2
- 241001562081 Ikeda Species 0.000 description 2
- 235000015334 Phyllostachys viridis Nutrition 0.000 description 2
- 239000011425 bamboo Substances 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 235000008331 Pinus X rigitaeda Nutrition 0.000 description 1
- 235000011613 Pinus brutia Nutrition 0.000 description 1
- 241000018646 Pinus brutia Species 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Telephonic Communication Services (AREA)
Abstract
【課題】マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現する技術を提供する。【解決手段】クラウド上で複数のユーザにより共有されるリソースによってデータ処理を実行するマルチテナント型サービスにおいて、ユーザからデータ処理の呼び出しを受け付けて、リソースによりデータ処理を実行させる管理装置は、カウント値が上限値に達していたら、バースト時間の間、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、データ処理を受け付け、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、データ処理を受け付け、ユーザのデータ処理によるデータがデータサイズに到達していれば、所定の回復時間だけ待機した後、データ処理を受け付ける。【選択図】図2
Description
本開示は、クラウド上でマルチテナント型サービスを提供する技術に関する。
クラウド上のリソースを利用してアプリケーションをマルチテナント型で提供するサービス事業者がある。クラウドにはブロックチェーン技術を利用したものがある。
サービス事業者は、複数のサービス利用者に対して、仮想プロセッサや仮想メモリのリソースを公平かつ効率的に分配することが求められる。一般的には、サービス提供者は、複数のサービス利用者のそれぞれに利用可能なリソースの上限をキャッピングし、固定の割合でリソースを分配している。また、特許文献1には、リソース通貨値を使ったオークションにより、オンデマンドサービス環境におけるリソース割り当てを行う技術が開示されている。また、特許文献2には、通常モードとバーストモードのそれぞれにトークンを設け、バーストモードによって余剰リソースを融通することにより、リソースの効率的な利用を可能にする技術が開示されている。
ブロックチェーン技術には様々な特有の性質がある。あるサービス利用者がクラウドに書き込んだデータが他のサービス利用者によってブロックチェーンネットワーク上で情報共有される。情報共有に貢献するサービス利用者は、自身に割り当てられているリソースを他社のために提供する。そのようなサービス利用者の貢献により他のサービス利用者が利益を受けることになる。また、ブロックチェーンでは、データは、所定サイズのブロックにブロック化されてクラウドに書き込まれる。そのため、小さいサイズのデータをブロックへ追加で書き込むことが頻繁に起こると、処理性能が低下する。
これまで、このようなブロックチェーンの性質を考慮して好適なリソースの分配を実現する手法は提案されて来なかった。
本開示のひとつの目的は、マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現する技術を提供することである。
本開示のひとつの態様による管理装置は、クラウド上で複数のユーザにより共有されるリソースによって、複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、ユーザからデータ処理の呼び出しを受け付けて、リソースによりデータ処理を実行させる管理装置であり、カウント値が上限値に達していたら、バーストモードとして、バースト時間の間、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、データ処理を受け付け、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、データ処理を受け付け、ユーザのデータ処理によるデータがデータサイズに到達していれば、所定の回復時間だけ待機した後、データ処理を受け付ける。
本開示のひとつの態様によれば、マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現することができる。
以下、本発明の実施形態について図面を参照して説明する。
図1は、マルチテナント型サービスシステムの構成を示すブロック図である。
マルチテナント型サービスシステムは、マルチテナント型サービスを提供するシステムである。マルチテナント型サービスは、ユーザのデータをブロックチェーンによって記憶する構成である。また、マルチテナント型サービスは、API(アプリケーション・プログラミング・インタフェース)を呼び出すことで実行されるアプリケーションプログラムにより構築されている。アプリケーションプログラムは、クラウド11上の仮想的な処理装置13および記憶装置14を含むリソース12によって実行される。リソース12は、マルチテナント型サービスの利用契約を行った複数のユーザA16A、ユーザB16B、ユーザC16Cに共用される。以下、複数のユーザA16A、ユーザB16B、ユーザC16Cをまとめてユーザ16と呼ぶ場合がある。なお、ここでいうユーザ16は企業等の組織であってもよいし、個人であってもよい。
マルチテナント型サービスシステムには、ユーザ16からAPIの呼び出しを受け付けて、リソース12にAPIにより呼び出される処理を実行させる管理装置15が設けられている。
図2は、管理装置のブロック図である。管理装置15は、ユーザ管理部21とAPI制御部25を有する。なお、本実施形態では、複数のユーザ16に対して共通の管理装置15が配置される構成が示されているが、物理的構成および論理的構成がこれに限定されることはない。管理装置15は、ユーザ16毎にそれぞれ設けられ、当該ユーザ16からのAPIの呼び出しを受け付ける複数のゲートウェイ装置により構成され、複数のゲートウェイ装置が相互に連携することで実現されるものであってもよい。その場合もゲートウェイ装置はクラウド11に構築可能である。また、本実施形態では、管理装置15はクラウド11上に構築されるものとして例示されるが、本例に限定されることはない。プロセッサおよびメモリを物理的に備え、プロセッサによってソフトウェアプログラムを実行するサーバ装置等のコンピュータによって管理装置15を構築してもよい。
ユーザ管理部21は、マルチテナント型サービスを利用するユーザ16を管理する。図2に示したように、ユーザ管理部21は、契約プラン受付部22、上限決定部23、および優先順位決定部24を有する。
契約プラン受付部22は、マルチテナント型サービスの利用契約をしようとするユーザ16に様々な料金の契約プランを提示し、ユーザ16の希望に応じて利用する契約プランを決定する。
上限決定部23は、ユーザ16の希望に応じて、単位時間当たりのAPIの呼び出しの受付可能な回数の上限値を決定する。以下、単位時間当たりのAPIの呼び出しの受付可能な回数の上限値をAPI上限値と呼ぶ場合がある。API上限値は、契約プランに応じて定まるものであってもよい。
API上限値は絶対的な上限値ではなく、バーストモードにおいてはAPI上限値を超えてAPIの呼び出しを受け付けることができる。上限決定部23は、API上限値を超えてAPIの呼び出しを受け付け可能な時間であるバースト時間を決定する。バースト時間は、リソース12を共用する全てのユーザ16のAPI上限値の合計に対する各ユーザ16のAPI上限値の割合に応じて単位時間を分配した時間であってもよい。以下、全ユーザのAPI上限値の合計に対する各ユーザのAPI上限値の割合をAPI上限値割合と呼ぶ場合がある。
優先順位決定部24は、各ユーザ16のAPIの呼び出しの処理における優先順位を決定する。優先順位は、全ユーザのAPI上限値の合計に対する各ユーザのAPI上限値の割合が高い順としてもよい。
API制御部25は、ユーザ16によるAPIの呼び出しによる処理の実行を制御する。図2に示したように、API制御部25は、キュー登録部26、データベースキュー27、キュー取出部28、およびAPI実行受付部29を有する。以下、データベースをDBと略す場合がある。
キュー登録部26は、ユーザ16からのAPIの呼び出しを受信し、DBキュー27に登録する。
DBキュー27は、各ユーザ16から受信されたAPIの呼び出しを管理するキューである。
キュー取出部28は、API実行受付部29の決定に従ってDBキュー27からAPIの呼び出しを取り出す。
API実行受付部29は、単位時間毎にユーザ16によるAPIの受け付け済みの呼び出しの回数をカウント値として計測し、カウント値がAPI上限値に達していなければAPIの呼び出しを受け付け、カウント値がAPI上限値に達していたら、バーストモードとして、バースト時間に基づいて、ユーザ16からのAPIの呼び出しの受け付けを制御する。詳細な処理は後述する。
図3は、ユーザ管理処理のフローチャートである。ユーザ管理処理は、ユーザ管理部21の契約プラン受付部22、上限決定部23、および優先順位決定部24により実行される。
ステップ101にて、契約プラン受付部22は、予め定められた複数の契約プランをユーザ16に提示して選択を促す。
図4は、契約プラン一覧を示す図である。
契約プランは、「松」「竹」「梅」「格安」の4種類である。「松」は、料金が月額10万円であり、API上限値が1秒当たり100回である。「竹」は、料金が月額5万円であり、API上限値が1秒当たり40回である。「梅」は、料金が月額3万円であり、API上限値が1秒当たり20回である。「格安」は、料金が月額1万円であり、API上限値が1秒当たり0回である。APIの呼び出しに対するレスポンスの種別はいずれの契約プランもベストエフォートである。ユーザ16は、これらの契約プランの中から利用する契約プランを選択する。
ステップ102にて、契約プラン受付部22は、各ユーザ16の選択に基づき、各ユーザ16が利用する契約プランを決定する。
ステップ103にて、上限決定部23は、各ユーザ16の契約プランに基づいて各ユーザ16のAPI上限値を決定し、それに伴い、当該ユーザ16のAPI上限値割合を決定する。
ステップ104にて、ユーザ管理部21は、マルチテナント型サービスでリソース12を共用する全てのユーザ16を管理するユーザテーブルを作成する。
図5は、ユーザテーブルを示す図である。ユーザテーブルには、各ユーザのユーザ名、API上限値、API上限値割合、およびAPI実割合が登録される。ユーザ名が「日立」であるユーザは、図4に示した契約プラン「松」を契約している。ユーザ名が「池田」であるユーザは、図4に示した契約プラン「竹」を契約している。ユーザ名が「戸塚」であるユーザは、図4に示した契約プラン「梅」を契約している。ユーザ名が「吉田」であるユーザは、図4に示した契約プラン「格安」を契約している。
API上限値割合は、上述の通り、全ユーザのAPI上限値の合計に対する各ユーザのAPI上限値の割合である。例えば、図5において、ユーザ名が「日立」であるユーザのAPI上限値割合は式(1)により計算される。
API上限値割合(日立)=100回/(100+60+40)=50% …(1)
API実割合は、全てのユーザ16によるAPIの呼び出しが行われた回数の合計に対する、当該ユーザ16によるAPIの呼び出しが行われた回数の割合である。ユーザテーブルが作成された段階ではAPI実割合には数値が入らない。
図3に戻り、ステップ105にて、優先順位決定部24は、各ユーザ16のバースト時間を算出する。
バースト時間は、上述の通り、全てのユーザ16のAPI上限値の合計に対する各ユーザ16のAPI上限値の割合(すなわちAPI上限値割合)に応じて単位時間を分配した時間である。例えば、図5において、ユーザ名が「日立」であるユーザのバースト時間は式(2)により計算される。
バースト時間(日立)=1秒×(API上限値割合(日立))=0.2秒 …(2)
ステップ106にて、優先順位決定部24は、各ユーザ16のバーストモードを適用する優先順位を決定し、各ユーザ16のAPIの呼び出しに対する処理における優先順位を示す優先順位テーブルを作成する。
優先順位決定部24は、上述の通り、各ユーザ16に対してAPI上限値割合が高い順に優先順位を付与していく。
図6は、優先順位テーブルを示す図である。優先順位テーブルには、優先順位を示す数値と、その優先順位に該当するユーザのユーザ名とが記録されている。例えば、ユーザ名が「日立」であるユーザの優先順位が「1」であり、ユーザ名が「池田」であるユーザの優先順位が「2」である。
図7は、API受け付け処理のフローチャートである。API受け付け処理は、キュー登録部26により実行される。
キュー登録部26は、ステップ201にて、ユーザ16から受信したAPIの呼び出しを取得し、ステップ202にて、APIの呼び出しを受信した時刻を取得する。以下、APIの呼び出しを受信した時刻を受信時刻と呼ぶ場合がある。
ステップ203にて、キュー登録部26は、APIの呼び出しおよびその管理情報をデータベースおよびDBキュー27に登録する。
ステップ204にて、キュー登録部26は、新たなAPIの呼び出しがDBキュー27に登録されたことを示すシグナルを送出する。
図8は、データベースを示す図である。データベースには、各API呼び出しについて、識別子、ユーザ名、処理名、受信時刻、および開始時刻が記録される。識別子は、API呼び出しを個々に識別するための識別情報である。ユーザ名は、当該APIの呼び出しを送信したユーザ16を示す情報である。処理名は、当該APIの呼び出しにより呼び出され実行される処理を示す処理名である。受信時刻は、当該APIの呼び出しの受信時刻である。開始時刻は、当該APIの呼び出しによる処理が開始される時刻である。APIの呼び出しがデータベースに登録された段階では、開始時刻は記録されない。
DBキュー27には、各ユーザ16から受信されたAPIの呼び出しが受信された順番に記録される。DBキュー27の構成は特に限定されないが、ユーザ16毎にAPIの呼び出しが受信された順番を特定可能に構成される。例えば、DBキュー27は、ユーザ16毎の個別のキューにより構成されてもよい。また、例えば、DBキュー27をデータベースと兼用とし、複数のユーザ16に対して共通に設けられ、各APIを送信したユーザ16を特定可能にする情報(例えばユーザ名)と共に記録し、所望のユーザ16のAPIの呼び出しを取り出すことが可能な構成であってもよい。図8の例で、ユーザ名が「日立」のユーザが処理対象であれば、識別子が1001のAPIの呼び出しよりも前に、識別子が1003のAPIの呼び出しが取り出されることがある。
図9は、優先順位処理のフローチャートである。優先順位処理は、優先的にバーストモードを適用するユーザを決める処理である。優先順位処理は、ユーザ管理部21により実行される。
ステップ301にて、ユーザ管理部21は、所定の条件が満たされると優先順位テーブルのカレントポインタを1つ進める。所定の条件には、現在の優先対象ユーザのバースト時間が満了したこと、および現在の優先対象ユーザのAPIの呼び出しがなくなったことが含まれる。
ステップ302にて、ユーザ管理部21は、優先順位テーブルのカレントポインタが指している新たな優先対象ユーザを特定する。
ステップ303にて、ユーザ管理部21は、新たな優先対象ユーザに優先的にバーストモードを適用する。
図10は、API呼び出し受付処理のフローチャートである。API呼び出し受付処理は、優先対象ユーザを優先し、シグナルが送出されているユーザ16に対して実行される。ここでは、処理の対象となるユーザ16をユーザAとしている。API呼び出し受付処理は、API制御部25のAPI実行受付部29により実行される。
API実行受付部29は、単位時間毎に、ユーザAを含む各ユーザ16のそれぞれに、受け付け済みのAPIの呼び出しの回数を計測している。以下、この受け付け済みのAPIの呼び出しの回数をAPI呼び出し回数と呼ぶ場合がある。
API実行受付部29は、APIの呼び出しがあると(ステップ401)、ステップ402にて、ユーザAのAPI呼び出し回数がユーザAの上限値に到達しているか否か判定する。ユーザAのAPI呼び出し回数がユーザAの上限値に到達していなければ、API実行受付部29は、ステップ403にて、ユーザAによるAPIの呼び出しを受け付け、ステップ404にて、ユーザAのAPI呼び出し回数に1を加算する。APIの呼び出しが受け付けられると、呼び出された処理がクラウド11のリソース12により実行される。
ステップ402の判定で、ユーザAのAPI呼び出し回数がユーザAの上限値に到達していれば、API実行受付部29は、ステップ405にて、バースト時間内にユーザAによるAPIの呼び出しのみが実施されているか否か判定する。バースト時間内にユーザAによるAPIの呼び出しのみが実施されているのであれば、API実行受付部29は、ステップ406にて、ユーザAによるAPIの呼び出しを受け付け、ステップ404に進む。
ステップ405の判定で、バースト時間内にユーザAによるAPIの呼び出しのみが実施されているのでなければ、API実行受付部29は、ステップ407にて、ユーザAによるAPIの呼び出しの処理により生じ、未だブロックチェーンに書き込まれていないデータの総量が、ブロックチェーンのブロックのサイズに到達しているか否か判定する。ブロックチェーンのブロックのサイズを以下ブロックサイズと呼ぶ場合がある。ユーザAによるAPIの呼び出しの処理により生じ、未だブロックチェーンに書き込まれていないデータの総量がブロックサイズに到達していなければ、API実行受付部29は、ステップ406に進む。ステップ406では、ユーザAによるAPIの呼び出しが受け付けられ、呼び出された処理により生じるデータは、未だブロックチェーンに書き込まれていないデータと一緒にブロックに書き込まれる。
ユーザAによるAPIの呼び出しの処理により生じ、未だブロックチェーンに書き込まれていないデータの総量がブロックサイズに到達していれば、API実行受付部29は、ステップ408にて、APIの呼び出しの受け付けを所定の回復時間だけ一時停止した後に回復し、ステップ403に進む。なお、回復時間は、API上限値を超えたAPIの呼び出しの受け付けを停止して待ち受ける時間を示すシステムパラメータであり、API実行受付部29がこれを予め定めておく。
本実施形態では、各ユーザの契約プランと連動するAPI上限値や料金に応じたバースト時間まで、APIの個数の上限値を超えたバーストモードでのAPIの処理を行い、ブロックチェーンのブロックへできるだけまとめてデータの書き込みが行われるように制御する。API上限値を超えたAPIの呼び出しを、API上限値に応じて決まるバースト時間まで受け付けるので、ユーザに公平感が与えられる。また、データをブロックサイズにまとめてブロックチェーンへの書き込むので、書き込み処理の発生回数を低減することができる。
以上説明した本実施形態には、以下に示す事項が含まれる。ただし、本実施形態に含まれる事項が以下に示すものだけに限定されることはない。
(事項1)
クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースにより前記データ処理を実行させる管理装置であって、
前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定するユーザ管理部と、
単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、前記カウント値が前記上限値に達していたら、前記バースト時間に基づいて、前記ユーザからのデータ処理の呼び出しの受け付けを制御するデータ処理制御部と、
を有し、
前記データ処理制御部は、
前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
管理装置。
クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースにより前記データ処理を実行させる管理装置であって、
前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定するユーザ管理部と、
単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、前記カウント値が前記上限値に達していたら、前記バースト時間に基づいて、前記ユーザからのデータ処理の呼び出しの受け付けを制御するデータ処理制御部と、
を有し、
前記データ処理制御部は、
前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
管理装置。
これによれば、データ処理のカウント値が上限値に達していたら、バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザが無ければ、データ処理を受け付け、バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあっても、ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、データ処理を受け付ける。これにより、マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現することができる。
(事項2)
前記マルチテナント型サービスは、前記複数のユーザのデータをブロックチェーンによって記憶するサービスであり、
前記データサイズが前記ブロックチェーンのブロックのサイズに基づいて決定され、
前記データ処理制御部は、前記リソースに前記データ処理を実行させたことにより生じるデータを前記ブロックにまとめて前記ブロックチェーンに記録する、
事項1に記載の管理装置。
前記マルチテナント型サービスは、前記複数のユーザのデータをブロックチェーンによって記憶するサービスであり、
前記データサイズが前記ブロックチェーンのブロックのサイズに基づいて決定され、
前記データ処理制御部は、前記リソースに前記データ処理を実行させたことにより生じるデータを前記ブロックにまとめて前記ブロックチェーンに記録する、
事項1に記載の管理装置。
これによれば、ブロックチェーンの性質を考慮してクラウド上の好適なリソース分配を実現することができる。ブロックチェーンは、所定サイズのブロック単位でデータの書き込みが行われるので、小さいデータをブロックにまとめることで、書き込みの回数および書き込まれるデータの個数を低減することができる。
(事項3)
前記データ処理が、アプリケーション・プログラミング・インタフェースによる処理である、
事項1に記載の管理装置。
前記データ処理が、アプリケーション・プログラミング・インタフェースによる処理である、
事項1に記載の管理装置。
これによれば、APIの呼び出しの単位でクラウド上のリソースを好適に分配することができる。
(事項4)
前記ユーザ管理部は、
前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのデータ処理における優先順位を示す優先順位テーブルを予め生成し、
前記優先順位テーブルにおいて、前記データ処理の受け付けを優先する優先対象ユーザを示すカレントポインタを設定し、
前記データ処理制御部に、前記優先対象ユーザを優先して前記バーストモードを適用させ、
前記バースト時間が満了したとき、あるいは、前記優先対象ユーザのデータ処理の呼び出しがなくなったとき、前記カレントポインタを前記優先順位テーブルにおける次のユーザに進める、
事項1に記載の管理装置。
前記ユーザ管理部は、
前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのデータ処理における優先順位を示す優先順位テーブルを予め生成し、
前記優先順位テーブルにおいて、前記データ処理の受け付けを優先する優先対象ユーザを示すカレントポインタを設定し、
前記データ処理制御部に、前記優先対象ユーザを優先して前記バーストモードを適用させ、
前記バースト時間が満了したとき、あるいは、前記優先対象ユーザのデータ処理の呼び出しがなくなったとき、前記カレントポインタを前記優先順位テーブルにおける次のユーザに進める、
事項1に記載の管理装置。
これによれば、与えられた上限値の割合に基づく優先順位に従ってリソースを分配する処理を実現することができる。
(事項5)
前記上限値は、ユーザが利用する前記マルチテナント型サービスの契約プランにより定まり、
前記ユーザ管理部は、前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのそれぞれのバースト時間を設定する、
事項1に記載の管理装置。
前記上限値は、ユーザが利用する前記マルチテナント型サービスの契約プランにより定まり、
前記ユーザ管理部は、前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのそれぞれのバースト時間を設定する、
事項1に記載の管理装置。
これによれば、契約プランにより定まる上限値の割合に応じたバースト時間で上限値を超えたバーストモードでのデータ処理の受け付けを行うので、ユーザに公平感を与えることができる。
(事項6)
前記データ処理制御部は、
前記ユーザによるデータ処理の呼び出しをユーザ毎の呼び出しキューにエンキューし、
前記カウント値が前記上限値に達していなければ前記呼び出しキューから前記データ処理をデキューして受け付け、
前記カウント値が前記上限値に達していたら、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザが無ければ、前記呼び出しキューから前記データ処理をデキューして受け付け、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあれば、
前記ユーザのデータ処理によるデータが前記データサイズに到達していなければ、前記キューから前記データ処理をデキューして受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、データ処理の呼び出しの受け付けを停止する、
事項1に記載の管理装置。
前記データ処理制御部は、
前記ユーザによるデータ処理の呼び出しをユーザ毎の呼び出しキューにエンキューし、
前記カウント値が前記上限値に達していなければ前記呼び出しキューから前記データ処理をデキューして受け付け、
前記カウント値が前記上限値に達していたら、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザが無ければ、前記呼び出しキューから前記データ処理をデキューして受け付け、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあれば、
前記ユーザのデータ処理によるデータが前記データサイズに到達していなければ、前記キューから前記データ処理をデキューして受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、データ処理の呼び出しの受け付けを停止する、
事項1に記載の管理装置。
これによれば、データ処理をキューによって管理し、処理するので、リアルタイムでの処理ができない場合でもデータ処理に対する好適なリソースの分配が可能である。
(事項7)
前記データ処理制御部は、
前記上限値を超えたデータ処理の呼び出しの受け付けを停止して待ち受ける時間である回復時間を予め定め、
前記カウント値が前記上限値に達しており、前記リソースを共有する複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあり、前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、前記回復時間だけ、データ処理の呼び出しの受け付けを停止する、
事項1に記載の管理装置。
前記データ処理制御部は、
前記上限値を超えたデータ処理の呼び出しの受け付けを停止して待ち受ける時間である回復時間を予め定め、
前記カウント値が前記上限値に達しており、前記リソースを共有する複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあり、前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、前記回復時間だけ、データ処理の呼び出しの受け付けを停止する、
事項1に記載の管理装置。
これによれば、適切な回復時間によりリソース分配の処理を運用することができる。
(事項8)
前記管理装置は、ユーザ毎に設けられ当該ユーザからデータ処理の呼び出しを受け付ける複数のゲートウェイにより構成され、
前記ゲートウェイは、前記クラウド上に構築される、
事項1に記載の管理装置。
前記管理装置は、ユーザ毎に設けられ当該ユーザからデータ処理の呼び出しを受け付ける複数のゲートウェイにより構成され、
前記ゲートウェイは、前記クラウド上に構築される、
事項1に記載の管理装置。
また、上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の範囲を逸脱することなしに、他の様々な態様で本発明を実施することができる。
11…クラウド、12…リソース、13…処理装置、14…記憶装置、15…管理装置、16A…ユーザA、16B…ユーザB、16C…ユーザC、16…ユーザ、21…ユーザ管理部、22…契約プラン受付部、23…上限値決定部、24…優先順位決定部、25…API制御部、26…キュー登録部、27…データベースキュー、28…キュー取出部、29…API実行受付部
Claims (10)
- クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースにより前記データ処理を実行させる管理装置であって、
前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定するユーザ管理部と、
単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、前記カウント値が前記上限値に達していたら、前記バースト時間に基づいて、前記ユーザからのデータ処理の呼び出しの受け付けを制御するデータ処理制御部と、
を有し、
前記データ処理制御部は、
前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
管理装置。 - 前記マルチテナント型サービスは、前記複数のユーザのデータをブロックチェーンによって記憶するサービスであり、
前記データサイズが前記ブロックチェーンのブロックのサイズに基づいて決定され、
前記データ処理制御部は、前記リソースに前記データ処理を実行させたことにより生じるデータを前記ブロックにまとめて前記ブロックチェーンに記録する、
請求項1に記載の管理装置。 - 前記データ処理が、アプリケーション・プログラミング・インタフェースによる処理である、
請求項1に記載の管理装置。 - 前記ユーザ管理部は、
前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのデータ処理における優先順位を示す優先順位テーブルを予め生成し、
前記優先順位テーブルにおいて、前記データ処理の受け付けを優先する優先対象ユーザを示すカレントポインタを設定し、
前記データ処理制御部に、前記優先対象ユーザを優先して前記バーストモードを適用させ、
前記バースト時間が満了したとき、あるいは、前記優先対象ユーザのデータ処理の呼び出しがなくなったとき、前記カレントポインタを前記優先順位テーブルにおける次のユーザに進める、
請求項1に記載の管理装置。 - 前記上限値は、ユーザが利用する前記マルチテナント型サービスの契約プランにより定まり、
前記ユーザ管理部は、前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのそれぞれのバースト時間を設定する、
請求項1に記載の管理装置。 - 前記データ処理制御部は、
前記ユーザによるデータ処理の呼び出しをユーザ毎の呼び出しキューにエンキューし、
前記カウント値が前記上限値に達していなければ前記呼び出しキューから前記データ処理をデキューして受け付け、
前記カウント値が前記上限値に達していたら、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザが無ければ、前記呼び出しキューから前記データ処理をデキューして受け付け、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあれば、
前記ユーザのデータ処理によるデータが前記データサイズに到達していなければ、前記キューから前記データ処理をデキューして受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、データ処理の呼び出しの受け付けを停止する、
請求項1に記載の管理装置。 - 前記データ処理制御部は、
前記上限値を超えたデータ処理の呼び出しの受け付けを停止して待ち受ける時間である回復時間を予め定め、
前記カウント値が前記上限値に達しており、前記リソースを共有する複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあり、前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、前記回復時間だけ、データ処理の呼び出しの受け付けを停止する、
請求項1に記載の管理装置。 - 前記管理装置は、ユーザ毎に設けられ当該ユーザからデータ処理の呼び出しを受け付ける複数のゲートウェイにより構成され、
前記ゲートウェイは、前記クラウド上に構築される、
請求項1に記載の管理装置。 - クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースに前記データ処理を実行させるための管理方法であって、
コンピュータが、
前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定し、
単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、
前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、
前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
ことを実行する管理方法。 - クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースに前記データ処理を実行させるための管理プログラムであって、
コンピュータに、
前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定し、
単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、
前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、
前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
ことを実行させるための管理プログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021139054A JP2023032752A (ja) | 2021-08-27 | 2021-08-27 | 管理装置、方法、およびプログラム |
PCT/JP2022/031761 WO2023027081A1 (ja) | 2021-08-27 | 2022-08-23 | 管理装置、方法、およびプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021139054A JP2023032752A (ja) | 2021-08-27 | 2021-08-27 | 管理装置、方法、およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2023032752A true JP2023032752A (ja) | 2023-03-09 |
Family
ID=85322790
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021139054A Pending JP2023032752A (ja) | 2021-08-27 | 2021-08-27 | 管理装置、方法、およびプログラム |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP2023032752A (ja) |
WO (1) | WO2023027081A1 (ja) |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
SG10201709194PA (en) * | 2013-06-25 | 2017-12-28 | Amazon Tech Inc | Burst mode control |
US11405183B2 (en) * | 2020-01-29 | 2022-08-02 | Salesforce.Com, Inc. | Using cache objects to store events for adding corresponding objects in a blockchain |
-
2021
- 2021-08-27 JP JP2021139054A patent/JP2023032752A/ja active Pending
-
2022
- 2022-08-23 WO PCT/JP2022/031761 patent/WO2023027081A1/ja unknown
Also Published As
Publication number | Publication date |
---|---|
WO2023027081A1 (ja) | 2023-03-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108776934B (zh) | 分布式数据计算方法、装置、计算机设备及可读存储介质 | |
WO2019120217A1 (zh) | 一种令牌获取方法、装置、服务器、用户终端及介质 | |
US9015227B2 (en) | Distributed data processing system | |
CN111901249B (zh) | 业务限流方法、装置、设备及存储介质 | |
US8495648B1 (en) | Managing allocation of computing capacity | |
US20210218842A1 (en) | Method, device, server and storage medium of agent allocation | |
US20080263553A1 (en) | Dynamic Service Level Manager for Image Pools | |
CN111130810B (zh) | 云服务用量包的计费方法、装置及相关设备 | |
CN110764872A (zh) | 一种基于云服务架构的自动报税方法、系统及相关设备 | |
CN107659739B (zh) | 名单分配方法和装置 | |
CN113312160B (zh) | 用于任务分配系统中的行为配对的方法和系统 | |
CN111858055B (zh) | 任务处理方法、服务器及存储介质 | |
CN109873910A (zh) | 会话请求的处理方法、装置及存储介质 | |
CN110377415A (zh) | 一种请求处理方法和服务器 | |
CN110191160A (zh) | 一种并发控制方法和装置 | |
CN111092814B (zh) | 业务办理请求报文分配方法及设备 | |
CN110599148A (zh) | 集群数据处理方法、装置、计算机集群及可读存储介质 | |
CN115348264A (zh) | 多租户云服务管理方法、装置、设备及存储介质 | |
CN113327053A (zh) | 任务处理方法及装置 | |
WO2023027081A1 (ja) | 管理装置、方法、およびプログラム | |
CN111459666A (zh) | 任务派发方法、装置、任务执行系统和服务器 | |
CN110750353A (zh) | 号码发放方法、装置、号码发放系统和计算机程序介质 | |
CN110633946A (zh) | 任务分配系统 | |
CN108964932A (zh) | 一种计费方法、装置和计算机可读存储介质 | |
CN111274006A (zh) | 基于预定义调度策略的工作平台任务分配方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20240308 |