JP2023032752A - 管理装置、方法、およびプログラム - Google Patents

Abstract

【課題】マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現する技術を提供する。【解決手段】クラウド上で複数のユーザにより共有されるリソースによってデータ処理を実行するマルチテナント型サービスにおいて、ユーザからデータ処理の呼び出しを受け付けて、リソースによりデータ処理を実行させる管理装置は、カウント値が上限値に達していたら、バースト時間の間、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、データ処理を受け付け、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、データ処理を受け付け、ユーザのデータ処理によるデータがデータサイズに到達していれば、所定の回復時間だけ待機した後、データ処理を受け付ける。【選択図】図２

Description

本開示は、クラウド上でマルチテナント型サービスを提供する技術に関する。

クラウド上のリソースを利用してアプリケーションをマルチテナント型で提供するサービス事業者がある。クラウドにはブロックチェーン技術を利用したものがある。

サービス事業者は、複数のサービス利用者に対して、仮想プロセッサや仮想メモリのリソースを公平かつ効率的に分配することが求められる。一般的には、サービス提供者は、複数のサービス利用者のそれぞれに利用可能なリソースの上限をキャッピングし、固定の割合でリソースを分配している。また、特許文献１には、リソース通貨値を使ったオークションにより、オンデマンドサービス環境におけるリソース割り当てを行う技術が開示されている。また、特許文献２には、通常モードとバーストモードのそれぞれにトークンを設け、バーストモードによって余剰リソースを融通することにより、リソースの効率的な利用を可能にする技術が開示されている。

特表２０１５－５３５９７５号公報 特開２０１８－７７８５２号公報

ブロックチェーン技術には様々な特有の性質がある。あるサービス利用者がクラウドに書き込んだデータが他のサービス利用者によってブロックチェーンネットワーク上で情報共有される。情報共有に貢献するサービス利用者は、自身に割り当てられているリソースを他社のために提供する。そのようなサービス利用者の貢献により他のサービス利用者が利益を受けることになる。また、ブロックチェーンでは、データは、所定サイズのブロックにブロック化されてクラウドに書き込まれる。そのため、小さいサイズのデータをブロックへ追加で書き込むことが頻繁に起こると、処理性能が低下する。

これまで、このようなブロックチェーンの性質を考慮して好適なリソースの分配を実現する手法は提案されて来なかった。

本開示のひとつの目的は、マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現する技術を提供することである。

本開示のひとつの態様による管理装置は、クラウド上で複数のユーザにより共有されるリソースによって、複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、ユーザからデータ処理の呼び出しを受け付けて、リソースによりデータ処理を実行させる管理装置であり、カウント値が上限値に達していたら、バーストモードとして、バースト時間の間、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、データ処理を受け付け、リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、データ処理を受け付け、ユーザのデータ処理によるデータがデータサイズに到達していれば、所定の回復時間だけ待機した後、データ処理を受け付ける。

本開示のひとつの態様によれば、マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現することができる。

マルチテナント型サービスシステムの構成を示すブロック図である。 管理装置のブロック図である。 ユーザ管理処理のフローチャートである。 契約プラン一覧を示す図である。 ユーザテーブルを示す図である。 優先順位テーブルを示す図である。 ＡＰＩ受け付け処理のフローチャートである。 データベースを示す図である。 優先順位処理のフローチャートである。 ＡＰＩ呼び出し受付処理のフローチャートである。

以下、本発明の実施形態について図面を参照して説明する。

図１は、マルチテナント型サービスシステムの構成を示すブロック図である。

マルチテナント型サービスシステムは、マルチテナント型サービスを提供するシステムである。マルチテナント型サービスは、ユーザのデータをブロックチェーンによって記憶する構成である。また、マルチテナント型サービスは、ＡＰＩ（アプリケーション・プログラミング・インタフェース）を呼び出すことで実行されるアプリケーションプログラムにより構築されている。アプリケーションプログラムは、クラウド１１上の仮想的な処理装置１３および記憶装置１４を含むリソース１２によって実行される。リソース１２は、マルチテナント型サービスの利用契約を行った複数のユーザＡ１６Ａ、ユーザＢ１６Ｂ、ユーザＣ１６Ｃに共用される。以下、複数のユーザＡ１６Ａ、ユーザＢ１６Ｂ、ユーザＣ１６Ｃをまとめてユーザ１６と呼ぶ場合がある。なお、ここでいうユーザ１６は企業等の組織であってもよいし、個人であってもよい。

マルチテナント型サービスシステムには、ユーザ１６からＡＰＩの呼び出しを受け付けて、リソース１２にＡＰＩにより呼び出される処理を実行させる管理装置１５が設けられている。

図２は、管理装置のブロック図である。管理装置１５は、ユーザ管理部２１とＡＰＩ制御部２５を有する。なお、本実施形態では、複数のユーザ１６に対して共通の管理装置１５が配置される構成が示されているが、物理的構成および論理的構成がこれに限定されることはない。管理装置１５は、ユーザ１６毎にそれぞれ設けられ、当該ユーザ１６からのＡＰＩの呼び出しを受け付ける複数のゲートウェイ装置により構成され、複数のゲートウェイ装置が相互に連携することで実現されるものであってもよい。その場合もゲートウェイ装置はクラウド１１に構築可能である。また、本実施形態では、管理装置１５はクラウド１１上に構築されるものとして例示されるが、本例に限定されることはない。プロセッサおよびメモリを物理的に備え、プロセッサによってソフトウェアプログラムを実行するサーバ装置等のコンピュータによって管理装置１５を構築してもよい。

ユーザ管理部２１は、マルチテナント型サービスを利用するユーザ１６を管理する。図２に示したように、ユーザ管理部２１は、契約プラン受付部２２、上限決定部２３、および優先順位決定部２４を有する。

契約プラン受付部２２は、マルチテナント型サービスの利用契約をしようとするユーザ１６に様々な料金の契約プランを提示し、ユーザ１６の希望に応じて利用する契約プランを決定する。

上限決定部２３は、ユーザ１６の希望に応じて、単位時間当たりのＡＰＩの呼び出しの受付可能な回数の上限値を決定する。以下、単位時間当たりのＡＰＩの呼び出しの受付可能な回数の上限値をＡＰＩ上限値と呼ぶ場合がある。ＡＰＩ上限値は、契約プランに応じて定まるものであってもよい。

ＡＰＩ上限値は絶対的な上限値ではなく、バーストモードにおいてはＡＰＩ上限値を超えてＡＰＩの呼び出しを受け付けることができる。上限決定部２３は、ＡＰＩ上限値を超えてＡＰＩの呼び出しを受け付け可能な時間であるバースト時間を決定する。バースト時間は、リソース１２を共用する全てのユーザ１６のＡＰＩ上限値の合計に対する各ユーザ１６のＡＰＩ上限値の割合に応じて単位時間を分配した時間であってもよい。以下、全ユーザのＡＰＩ上限値の合計に対する各ユーザのＡＰＩ上限値の割合をＡＰＩ上限値割合と呼ぶ場合がある。

優先順位決定部２４は、各ユーザ１６のＡＰＩの呼び出しの処理における優先順位を決定する。優先順位は、全ユーザのＡＰＩ上限値の合計に対する各ユーザのＡＰＩ上限値の割合が高い順としてもよい。

ＡＰＩ制御部２５は、ユーザ１６によるＡＰＩの呼び出しによる処理の実行を制御する。図２に示したように、ＡＰＩ制御部２５は、キュー登録部２６、データベースキュー２７、キュー取出部２８、およびＡＰＩ実行受付部２９を有する。以下、データベースをＤＢと略す場合がある。

キュー登録部２６は、ユーザ１６からのＡＰＩの呼び出しを受信し、ＤＢキュー２７に登録する。

ＤＢキュー２７は、各ユーザ１６から受信されたＡＰＩの呼び出しを管理するキューである。

キュー取出部２８は、ＡＰＩ実行受付部２９の決定に従ってＤＢキュー２７からＡＰＩの呼び出しを取り出す。

ＡＰＩ実行受付部２９は、単位時間毎にユーザ１６によるＡＰＩの受け付け済みの呼び出しの回数をカウント値として計測し、カウント値がＡＰＩ上限値に達していなければＡＰＩの呼び出しを受け付け、カウント値がＡＰＩ上限値に達していたら、バーストモードとして、バースト時間に基づいて、ユーザ１６からのＡＰＩの呼び出しの受け付けを制御する。詳細な処理は後述する。

図３は、ユーザ管理処理のフローチャートである。ユーザ管理処理は、ユーザ管理部２１の契約プラン受付部２２、上限決定部２３、および優先順位決定部２４により実行される。

ステップ１０１にて、契約プラン受付部２２は、予め定められた複数の契約プランをユーザ１６に提示して選択を促す。

図４は、契約プラン一覧を示す図である。

契約プランは、「松」「竹」「梅」「格安」の４種類である。「松」は、料金が月額１０万円であり、ＡＰＩ上限値が１秒当たり１００回である。「竹」は、料金が月額５万円であり、ＡＰＩ上限値が１秒当たり４０回である。「梅」は、料金が月額３万円であり、ＡＰＩ上限値が１秒当たり２０回である。「格安」は、料金が月額１万円であり、ＡＰＩ上限値が１秒当たり０回である。ＡＰＩの呼び出しに対するレスポンスの種別はいずれの契約プランもベストエフォートである。ユーザ１６は、これらの契約プランの中から利用する契約プランを選択する。

ステップ１０２にて、契約プラン受付部２２は、各ユーザ１６の選択に基づき、各ユーザ１６が利用する契約プランを決定する。

ステップ１０３にて、上限決定部２３は、各ユーザ１６の契約プランに基づいて各ユーザ１６のＡＰＩ上限値を決定し、それに伴い、当該ユーザ１６のＡＰＩ上限値割合を決定する。

ステップ１０４にて、ユーザ管理部２１は、マルチテナント型サービスでリソース１２を共用する全てのユーザ１６を管理するユーザテーブルを作成する。

図５は、ユーザテーブルを示す図である。ユーザテーブルには、各ユーザのユーザ名、ＡＰＩ上限値、ＡＰＩ上限値割合、およびＡＰＩ実割合が登録される。ユーザ名が「日立」であるユーザは、図４に示した契約プラン「松」を契約している。ユーザ名が「池田」であるユーザは、図４に示した契約プラン「竹」を契約している。ユーザ名が「戸塚」であるユーザは、図４に示した契約プラン「梅」を契約している。ユーザ名が「吉田」であるユーザは、図４に示した契約プラン「格安」を契約している。

ＡＰＩ上限値割合は、上述の通り、全ユーザのＡＰＩ上限値の合計に対する各ユーザのＡＰＩ上限値の割合である。例えば、図５において、ユーザ名が「日立」であるユーザのＡＰＩ上限値割合は式（１）により計算される。

ＡＰＩ上限値割合（日立）＝１００回／（１００＋６０＋４０）＝５０％ …（１）

ＡＰＩ実割合は、全てのユーザ１６によるＡＰＩの呼び出しが行われた回数の合計に対する、当該ユーザ１６によるＡＰＩの呼び出しが行われた回数の割合である。ユーザテーブルが作成された段階ではＡＰＩ実割合には数値が入らない。

図３に戻り、ステップ１０５にて、優先順位決定部２４は、各ユーザ１６のバースト時間を算出する。

バースト時間は、上述の通り、全てのユーザ１６のＡＰＩ上限値の合計に対する各ユーザ１６のＡＰＩ上限値の割合（すなわちＡＰＩ上限値割合）に応じて単位時間を分配した時間である。例えば、図５において、ユーザ名が「日立」であるユーザのバースト時間は式（２）により計算される。

バースト時間（日立）＝１秒×（ＡＰＩ上限値割合（日立））＝０．２秒 …（２）

ステップ１０６にて、優先順位決定部２４は、各ユーザ１６のバーストモードを適用する優先順位を決定し、各ユーザ１６のＡＰＩの呼び出しに対する処理における優先順位を示す優先順位テーブルを作成する。

優先順位決定部２４は、上述の通り、各ユーザ１６に対してＡＰＩ上限値割合が高い順に優先順位を付与していく。

図６は、優先順位テーブルを示す図である。優先順位テーブルには、優先順位を示す数値と、その優先順位に該当するユーザのユーザ名とが記録されている。例えば、ユーザ名が「日立」であるユーザの優先順位が「１」であり、ユーザ名が「池田」であるユーザの優先順位が「２」である。

図７は、ＡＰＩ受け付け処理のフローチャートである。ＡＰＩ受け付け処理は、キュー登録部２６により実行される。

キュー登録部２６は、ステップ２０１にて、ユーザ１６から受信したＡＰＩの呼び出しを取得し、ステップ２０２にて、ＡＰＩの呼び出しを受信した時刻を取得する。以下、ＡＰＩの呼び出しを受信した時刻を受信時刻と呼ぶ場合がある。

ステップ２０３にて、キュー登録部２６は、ＡＰＩの呼び出しおよびその管理情報をデータベースおよびＤＢキュー２７に登録する。

ステップ２０４にて、キュー登録部２６は、新たなＡＰＩの呼び出しがＤＢキュー２７に登録されたことを示すシグナルを送出する。

図８は、データベースを示す図である。データベースには、各ＡＰＩ呼び出しについて、識別子、ユーザ名、処理名、受信時刻、および開始時刻が記録される。識別子は、ＡＰＩ呼び出しを個々に識別するための識別情報である。ユーザ名は、当該ＡＰＩの呼び出しを送信したユーザ１６を示す情報である。処理名は、当該ＡＰＩの呼び出しにより呼び出され実行される処理を示す処理名である。受信時刻は、当該ＡＰＩの呼び出しの受信時刻である。開始時刻は、当該ＡＰＩの呼び出しによる処理が開始される時刻である。ＡＰＩの呼び出しがデータベースに登録された段階では、開始時刻は記録されない。

ＤＢキュー２７には、各ユーザ１６から受信されたＡＰＩの呼び出しが受信された順番に記録される。ＤＢキュー２７の構成は特に限定されないが、ユーザ１６毎にＡＰＩの呼び出しが受信された順番を特定可能に構成される。例えば、ＤＢキュー２７は、ユーザ１６毎の個別のキューにより構成されてもよい。また、例えば、ＤＢキュー２７をデータベースと兼用とし、複数のユーザ１６に対して共通に設けられ、各ＡＰＩを送信したユーザ１６を特定可能にする情報（例えばユーザ名）と共に記録し、所望のユーザ１６のＡＰＩの呼び出しを取り出すことが可能な構成であってもよい。図８の例で、ユーザ名が「日立」のユーザが処理対象であれば、識別子が１００１のＡＰＩの呼び出しよりも前に、識別子が１００３のＡＰＩの呼び出しが取り出されることがある。

図９は、優先順位処理のフローチャートである。優先順位処理は、優先的にバーストモードを適用するユーザを決める処理である。優先順位処理は、ユーザ管理部２１により実行される。

ステップ３０１にて、ユーザ管理部２１は、所定の条件が満たされると優先順位テーブルのカレントポインタを１つ進める。所定の条件には、現在の優先対象ユーザのバースト時間が満了したこと、および現在の優先対象ユーザのＡＰＩの呼び出しがなくなったことが含まれる。

ステップ３０２にて、ユーザ管理部２１は、優先順位テーブルのカレントポインタが指している新たな優先対象ユーザを特定する。

ステップ３０３にて、ユーザ管理部２１は、新たな優先対象ユーザに優先的にバーストモードを適用する。

図１０は、ＡＰＩ呼び出し受付処理のフローチャートである。ＡＰＩ呼び出し受付処理は、優先対象ユーザを優先し、シグナルが送出されているユーザ１６に対して実行される。ここでは、処理の対象となるユーザ１６をユーザＡとしている。ＡＰＩ呼び出し受付処理は、ＡＰＩ制御部２５のＡＰＩ実行受付部２９により実行される。

ＡＰＩ実行受付部２９は、単位時間毎に、ユーザＡを含む各ユーザ１６のそれぞれに、受け付け済みのＡＰＩの呼び出しの回数を計測している。以下、この受け付け済みのＡＰＩの呼び出しの回数をＡＰＩ呼び出し回数と呼ぶ場合がある。

ＡＰＩ実行受付部２９は、ＡＰＩの呼び出しがあると（ステップ４０１）、ステップ４０２にて、ユーザＡのＡＰＩ呼び出し回数がユーザＡの上限値に到達しているか否か判定する。ユーザＡのＡＰＩ呼び出し回数がユーザＡの上限値に到達していなければ、ＡＰＩ実行受付部２９は、ステップ４０３にて、ユーザＡによるＡＰＩの呼び出しを受け付け、ステップ４０４にて、ユーザＡのＡＰＩ呼び出し回数に１を加算する。ＡＰＩの呼び出しが受け付けられると、呼び出された処理がクラウド１１のリソース１２により実行される。

ステップ４０２の判定で、ユーザＡのＡＰＩ呼び出し回数がユーザＡの上限値に到達していれば、ＡＰＩ実行受付部２９は、ステップ４０５にて、バースト時間内にユーザＡによるＡＰＩの呼び出しのみが実施されているか否か判定する。バースト時間内にユーザＡによるＡＰＩの呼び出しのみが実施されているのであれば、ＡＰＩ実行受付部２９は、ステップ４０６にて、ユーザＡによるＡＰＩの呼び出しを受け付け、ステップ４０４に進む。

ステップ４０５の判定で、バースト時間内にユーザＡによるＡＰＩの呼び出しのみが実施されているのでなければ、ＡＰＩ実行受付部２９は、ステップ４０７にて、ユーザＡによるＡＰＩの呼び出しの処理により生じ、未だブロックチェーンに書き込まれていないデータの総量が、ブロックチェーンのブロックのサイズに到達しているか否か判定する。ブロックチェーンのブロックのサイズを以下ブロックサイズと呼ぶ場合がある。ユーザＡによるＡＰＩの呼び出しの処理により生じ、未だブロックチェーンに書き込まれていないデータの総量がブロックサイズに到達していなければ、ＡＰＩ実行受付部２９は、ステップ４０６に進む。ステップ４０６では、ユーザＡによるＡＰＩの呼び出しが受け付けられ、呼び出された処理により生じるデータは、未だブロックチェーンに書き込まれていないデータと一緒にブロックに書き込まれる。

ユーザＡによるＡＰＩの呼び出しの処理により生じ、未だブロックチェーンに書き込まれていないデータの総量がブロックサイズに到達していれば、ＡＰＩ実行受付部２９は、ステップ４０８にて、ＡＰＩの呼び出しの受け付けを所定の回復時間だけ一時停止した後に回復し、ステップ４０３に進む。なお、回復時間は、ＡＰＩ上限値を超えたＡＰＩの呼び出しの受け付けを停止して待ち受ける時間を示すシステムパラメータであり、ＡＰＩ実行受付部２９がこれを予め定めておく。

本実施形態では、各ユーザの契約プランと連動するＡＰＩ上限値や料金に応じたバースト時間まで、ＡＰＩの個数の上限値を超えたバーストモードでのＡＰＩの処理を行い、ブロックチェーンのブロックへできるだけまとめてデータの書き込みが行われるように制御する。ＡＰＩ上限値を超えたＡＰＩの呼び出しを、ＡＰＩ上限値に応じて決まるバースト時間まで受け付けるので、ユーザに公平感が与えられる。また、データをブロックサイズにまとめてブロックチェーンへの書き込むので、書き込み処理の発生回数を低減することができる。

以上説明した本実施形態には、以下に示す事項が含まれる。ただし、本実施形態に含まれる事項が以下に示すものだけに限定されることはない。

（事項１）
クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースにより前記データ処理を実行させる管理装置であって、
前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定するユーザ管理部と、
単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、前記カウント値が前記上限値に達していたら、前記バースト時間に基づいて、前記ユーザからのデータ処理の呼び出しの受け付けを制御するデータ処理制御部と、
を有し、
前記データ処理制御部は、
前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
管理装置。

これによれば、データ処理のカウント値が上限値に達していたら、バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザが無ければ、データ処理を受け付け、バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあっても、ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、データ処理を受け付ける。これにより、マルチテナント型のサービスにおいてクラウド上の好適なリソース分配を実現することができる。

（事項２）
前記マルチテナント型サービスは、前記複数のユーザのデータをブロックチェーンによって記憶するサービスであり、
前記データサイズが前記ブロックチェーンのブロックのサイズに基づいて決定され、
前記データ処理制御部は、前記リソースに前記データ処理を実行させたことにより生じるデータを前記ブロックにまとめて前記ブロックチェーンに記録する、
事項１に記載の管理装置。

これによれば、ブロックチェーンの性質を考慮してクラウド上の好適なリソース分配を実現することができる。ブロックチェーンは、所定サイズのブロック単位でデータの書き込みが行われるので、小さいデータをブロックにまとめることで、書き込みの回数および書き込まれるデータの個数を低減することができる。

（事項３）
前記データ処理が、アプリケーション・プログラミング・インタフェースによる処理である、
事項１に記載の管理装置。

これによれば、ＡＰＩの呼び出しの単位でクラウド上のリソースを好適に分配することができる。

（事項４）
前記ユーザ管理部は、
前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのデータ処理における優先順位を示す優先順位テーブルを予め生成し、
前記優先順位テーブルにおいて、前記データ処理の受け付けを優先する優先対象ユーザを示すカレントポインタを設定し、
前記データ処理制御部に、前記優先対象ユーザを優先して前記バーストモードを適用させ、
前記バースト時間が満了したとき、あるいは、前記優先対象ユーザのデータ処理の呼び出しがなくなったとき、前記カレントポインタを前記優先順位テーブルにおける次のユーザに進める、
事項１に記載の管理装置。

これによれば、与えられた上限値の割合に基づく優先順位に従ってリソースを分配する処理を実現することができる。

（事項５）
前記上限値は、ユーザが利用する前記マルチテナント型サービスの契約プランにより定まり、
前記ユーザ管理部は、前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのそれぞれのバースト時間を設定する、
事項１に記載の管理装置。

これによれば、契約プランにより定まる上限値の割合に応じたバースト時間で上限値を超えたバーストモードでのデータ処理の受け付けを行うので、ユーザに公平感を与えることができる。

（事項６）
前記データ処理制御部は、
前記ユーザによるデータ処理の呼び出しをユーザ毎の呼び出しキューにエンキューし、
前記カウント値が前記上限値に達していなければ前記呼び出しキューから前記データ処理をデキューして受け付け、
前記カウント値が前記上限値に達していたら、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザが無ければ、前記呼び出しキューから前記データ処理をデキューして受け付け、
前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあれば、
前記ユーザのデータ処理によるデータが前記データサイズに到達していなければ、前記キューから前記データ処理をデキューして受け付け、
前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、データ処理の呼び出しの受け付けを停止する、
事項１に記載の管理装置。

これによれば、データ処理をキューによって管理し、処理するので、リアルタイムでの処理ができない場合でもデータ処理に対する好適なリソースの分配が可能である。

（事項７）
前記データ処理制御部は、
前記上限値を超えたデータ処理の呼び出しの受け付けを停止して待ち受ける時間である回復時間を予め定め、
前記カウント値が前記上限値に達しており、前記リソースを共有する複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあり、前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、前記回復時間だけ、データ処理の呼び出しの受け付けを停止する、
事項１に記載の管理装置。

これによれば、適切な回復時間によりリソース分配の処理を運用することができる。

（事項８）
前記管理装置は、ユーザ毎に設けられ当該ユーザからデータ処理の呼び出しを受け付ける複数のゲートウェイにより構成され、
前記ゲートウェイは、前記クラウド上に構築される、
事項１に記載の管理装置。

また、上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の範囲を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１１…クラウド、１２…リソース、１３…処理装置、１４…記憶装置、１５…管理装置、１６Ａ…ユーザＡ、１６Ｂ…ユーザＢ、１６Ｃ…ユーザＣ、１６…ユーザ、２１…ユーザ管理部、２２…契約プラン受付部、２３…上限値決定部、２４…優先順位決定部、２５…ＡＰＩ制御部、２６…キュー登録部、２７…データベースキュー、２８…キュー取出部、２９…ＡＰＩ実行受付部

Claims (10)

1. クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースにより前記データ処理を実行させる管理装置であって、
   前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定するユーザ管理部と、
   単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、前記カウント値が前記上限値に達していたら、前記バースト時間に基づいて、前記ユーザからのデータ処理の呼び出しの受け付けを制御するデータ処理制御部と、
   を有し、
   前記データ処理制御部は、
   前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
   前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
   前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
   前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
   前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
   管理装置。
2. 前記マルチテナント型サービスは、前記複数のユーザのデータをブロックチェーンによって記憶するサービスであり、
   前記データサイズが前記ブロックチェーンのブロックのサイズに基づいて決定され、
   前記データ処理制御部は、前記リソースに前記データ処理を実行させたことにより生じるデータを前記ブロックにまとめて前記ブロックチェーンに記録する、
   請求項１に記載の管理装置。
3. 前記データ処理が、アプリケーション・プログラミング・インタフェースによる処理である、
   請求項１に記載の管理装置。
4. 前記ユーザ管理部は、
   前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのデータ処理における優先順位を示す優先順位テーブルを予め生成し、
   前記優先順位テーブルにおいて、前記データ処理の受け付けを優先する優先対象ユーザを示すカレントポインタを設定し、
   前記データ処理制御部に、前記優先対象ユーザを優先して前記バーストモードを適用させ、
   前記バースト時間が満了したとき、あるいは、前記優先対象ユーザのデータ処理の呼び出しがなくなったとき、前記カレントポインタを前記優先順位テーブルにおける次のユーザに進める、
   請求項１に記載の管理装置。
5. 前記上限値は、ユーザが利用する前記マルチテナント型サービスの契約プランにより定まり、
   前記ユーザ管理部は、前記複数のユーザの前記上限値の合計に対する各ユーザの前記上限値の割合に応じて、前記各ユーザのそれぞれのバースト時間を設定する、
   請求項１に記載の管理装置。
6. 前記データ処理制御部は、
   前記ユーザによるデータ処理の呼び出しをユーザ毎の呼び出しキューにエンキューし、
   前記カウント値が前記上限値に達していなければ前記呼び出しキューから前記データ処理をデキューして受け付け、
   前記カウント値が前記上限値に達していたら、
   前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザが無ければ、前記呼び出しキューから前記データ処理をデキューして受け付け、
   前記複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあれば、
   前記ユーザのデータ処理によるデータが前記データサイズに到達していなければ、前記キューから前記データ処理をデキューして受け付け、
   前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、データ処理の呼び出しの受け付けを停止する、
   請求項１に記載の管理装置。
7. 前記データ処理制御部は、
   前記上限値を超えたデータ処理の呼び出しの受け付けを停止して待ち受ける時間である回復時間を予め定め、
   前記カウント値が前記上限値に達しており、前記リソースを共有する複数のユーザの中に、前記バースト時間内のデータ処理の呼び出しの受け付けが実施されている他のユーザがあり、前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、前記回復時間だけ、データ処理の呼び出しの受け付けを停止する、
   請求項１に記載の管理装置。
8. 前記管理装置は、ユーザ毎に設けられ当該ユーザからデータ処理の呼び出しを受け付ける複数のゲートウェイにより構成され、
   前記ゲートウェイは、前記クラウド上に構築される、
   請求項１に記載の管理装置。
9. クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースに前記データ処理を実行させるための管理方法であって、
   コンピュータが、
   前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定し、
   単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、
   前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、
   前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
   前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
   前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
   前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
   前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
   ことを実行する管理方法。
10. クラウド上で複数のユーザにより共有されるリソースによって、前記複数のユーザのデータ処理を実行するマルチテナント型サービスにおいて、前記ユーザからデータ処理の呼び出しを受け付けて、前記リソースに前記データ処理を実行させるための管理プログラムであって、
    コンピュータに、
    前記ユーザ毎に、単位時間当たりのデータ処理の呼び出しの回数の上限値と、前記上限値を超えてデータ処理の呼び出しを受け付け可能な時間であるバースト時間を予め設定し、
    単位時間毎に前記ユーザによるデータ処理の受け付け済みの呼び出しの回数をカウント値として計測し、
    前記カウント値が前記上限値に達していなければ前記データ処理を受け付け、
    前記カウント値が前記上限値に達していたら、バーストモードとして、前記バースト時間の間、
    前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザが無ければ、前記データ処理を受け付け、
    前記リソースを共有する複数のユーザの中に、データ処理の呼び出しのある他のユーザがあれば、
    前記ユーザのデータ処理によるデータが所定のデータサイズに到達していなければ、前記データ処理を受け付け、
    前記ユーザのデータ処理によるデータが前記データサイズに到達していれば、所定の回復時間だけ待機した後、前記データ処理を受け付ける、
    ことを実行させるための管理プログラム。

Images