特開 2024-133845 計算機システム、リソース調整方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024133845

(43)【公開日】2024-10-03

(54)【発明の名称】計算機システム、リソース調整方法、およびプログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240926BHJP

   G06F 9/455 20180101ALI20240926BHJP

【ＦＩ】

G06F9/50 120A

G06F9/455 150

【審査請求】未請求

【請求項の数】13

【出願形態】ＯＬ

(21)【出願番号】P 2023043833

(22)【出願日】2023-03-20

(71)【出願人】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(71)【出願人】

【識別番号】317015294

【氏名又は名称】東芝エネルギーシステムズ株式会社

(74)【代理人】

【識別番号】110001634

【氏名又は名称】弁理士法人志賀国際特許事務所

(72)【発明者】

【氏名】庄野 貴也

(72)【発明者】

【氏名】中井 昭祐

(72)【発明者】

【氏名】塩崎 和也

(72)【発明者】

【氏名】新田 能之

(72)【発明者】

【氏名】青山 敬三

(72)【発明者】

【氏名】久保 洋二

(72)【発明者】

【氏名】杉森 洋一

(72)【発明者】

【氏名】薬師 宏治

(72)【発明者】

【氏名】山根 翔太郎

(72)【発明者】

【氏名】向 利昌

(57)【要約】

【課題】複数のテナントが存在する環境下で、限られた契約範囲でのクラウドコンピューティング環境のリソース配分の最適化により、リソースを平準化し、契約範囲の極小化によりランニング費用を抑制することである。
【解決手段】実施形態の計算機システムにおけるトレーディングエージェント部は、各テナントからのリソース確保要求およびリソース解放要求に基づいて、テナント間のリソースの確保と解放のマッチングを行い、マッチング結果に基づいて各テナントへのリソースの割り当てを変更する融通処理を行うと共に、前記マッチング結果をリソーストレーディングマーケット処理部に送信する。リソーストレーディングマーケット処理部は、前記マッチング結果に基づいて、前記マッチングに伴う前記テナント間のリソース確保と解放の授受または融通に伴う、リソースの貸借関係の収支の調整処理を行う。
【選択図】図１

【特許請求の範囲】

【請求項1】

マルチテナント環境を構成する計算機システムであって、
各テナントからのリソース確保要求およびリソース解放要求に基づいて、テナント間のリソースの確保と解放のマッチングを行い、マッチング結果に基づいて各テナントへのリソースの割り当てを変更する融通処理を行うと共に、前記マッチング結果をリソーストレーディングマーケット処理部に送信するトレーディングエージェント部と、
前記マッチング結果に基づいて、前記マッチングに伴う前記テナント間のリソース確保と解放の授受または融通に伴う、リソースの貸借関係の収支の調整処理を行う前記リソーストレーディングマーケット処理部と、
を備える計算機システム。

【請求項2】

前記リソーストレーディングマーケット処理部は、優先度とＦＩＦＯに基づく方法、またはマーケットメイク方式によって、前記収支の調整処理を行う、
請求項１記載の計算機システム。

【請求項3】

前記リソーストレーディングマーケット処理部は、異なる種類のリソースの融通処理について、前記テナント間で共通の仮想価値を授受させることで、前記収支の調整処理を行う、
請求項１記載の計算機システム。

【請求項4】

前記リソーストレーディングマーケット処理部は、同じ種類のリソースの融通処理について、当該リソースの現物を異なる時間帯で授受させることで、前記収支の調整処理を行う、
請求項１記載の計算機システム。

【請求項5】

前記リソーストレーディングマーケット処理部は、異なる種類のリソースの融通処理について、テナント間で共通の仮想価値を授受させ、同じ種類のリソースの融通処理について、当該リソースの現物を異なる時間帯で授受させることで、前記収支の調整処理を行う、
請求項１記載の計算機システム。

【請求項6】

前記リソーストレーディングマーケット処理部は、リソースのバンキング機能を有し、前記テナントから余剰のリソースを預かると共に当該テナントに対価を付与する、
請求項１記載の計算機システム。

【請求項7】

前記リソーストレーディングマーケット処理部は、リソースのバンキング機能を有し、前記テナントにリソースを貸与すると共に当該テナントから対価を受領する、
請求項１記載の計算機システム。

【請求項8】

前記リソーストレーディングマーケット処理部は、前記テナント間での融通処理で全体のリソースが不足する場合、外部からリソースを調達し、当該調達の原因となった前記リソース確保要求を行ったテナントから対価を受領する、
請求項１記載の計算機システム。

【請求項9】

少なくとも前記リソース確保要求には、優先度が設定されている、
請求項１記載の計算機システム。

【請求項10】

前記トレーディングエージェント部は、所定の規則に従う順序で前記融通処理を行うと共に、前記優先度に基づいて前記融通処理の順序を入れ替える、
請求項９記載の計算機システム。

【請求項11】

前記融通処理によって低減されたエネルギー消費量を計算し、計算した値に基づいて環境貢献量取引を行う、
請求項１記載の計算機システム。

【請求項12】

マルチテナント環境を構成する計算機システムにより実行されるリソース調整方法であって、
各テナントからのリソース確保要求およびリソース解放要求に基づいて、テナント間のリソースの確保と解放のマッチングを行い、マッチング結果に基づいて各テナントへのリソースの割り当てを変更する融通処理を行うと共に、前記マッチング結果をリソーストレーディングマーケット処理部に送信することと、
前記マッチング結果に基づいて、前記マッチングに伴う前記テナント間のリソース確保と解放の授受または融通に伴う、リソースの貸借関係の収支の調整処理を行うことと、
を備えるリソース調整方法。

【請求項13】

マルチテナント環境を構成する計算機システムに、
各テナントからのリソース確保要求およびリソース解放要求に基づいて、テナント間のリソースの確保と解放のマッチングを行い、マッチング結果に基づいて各テナントへのリソースの割り当てを変更する融通処理を行うと共に、前記マッチング結果をリソーストレーディングマーケット処理部に送信することと、
前記マッチング結果に基づいて、前記マッチングに伴う前記テナント間のリソース確保と解放の授受または融通に伴う、リソースの貸借関係の収支の調整処理を行うことと、
を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、計算機システム、リソース調整方法、およびプログラムに関する。

【背景技術】

【0002】

プラットフォーマーとは、インターネット上でプラットフォーム(市場)を提供する事業者や企業のことを指す。プラットフォームは、「システムやサービス」の「土台や基盤となる環境」のことを指す。プラットフォーマーは、このプラットフォームを介して売り手と買い手を結び付け、さまざまなビジネスに発展させる。プラットフォームの特徴として、ユーザーや参加企業が増えれば増えるほど、新たなユーザーを呼び込むという点があげられる。少なくとも世界的に有名な幾つかの企業がプラットフォーマーに該当する。

【0003】

ユーザーはプラットフォームを通じてサービスを受ける際に、個人情報の登録を求められる。これを通じて集まった膨大なデータ(ビッグデータ)は、プラットフォーマーの強みであり、細かく分析し、活用することで、新たなビジネスモデルを次々に世へ送り出すことができる。

【0004】

近年、利用者の要求に応じてオンデマンドに計算機リソース（以降、リソースと呼称する）を提供するクラウドコンピューティングと呼ばれる計算機環境が広く普及している。クラウド・コンピューティングは下記のような種類に類別される。

【0005】

ＳａａＳ（Software as a Service：サース）は、サービスとしてのソフトウェアとも言われる。サーバからアプリケーションまですべてのリソースをクラウドで提供し、ユーザーはその機能だけを利用する形態である。提供しているリソースのメンテナンスやアップデートなどの運用管理もクラウドサービス提供側が行う。企業向けから個人向けまでさまざまなサービスがＳａａＳで提供されているため、エンドユーザーが直接目にする機会も多く、企業向けには多くの業務システムが用意されており、業務効率化に貢献する。

【0006】

ＰａａＳ（Platform as a Service：パース）はサービスとしてのプラットフォームとも呼ばれる。アプリケーションを開発、テスト、配信、管理、利用するためのプラットフォームである。サーバ、ストレージ、ネットワーク、ＯＳ、データベースなどのインフラを提供し、プログラムの実行環境を提供する。ＰａａＳを利用すれば、アプリケーションの開発のみにリソースを割くことが可能であり、ＰａａＳ上で利用するアプリケーションはユーザーが開発・用意する。

【0007】

ＩａａＳ（Infrastructure as a Service：アイアース、イアース）はサービスとしてのインフラストラクチャとも言われる。クラウドサービスの基本で、サーバ、ストレージ、ネットワークなどのＩＴインフラだけを提供するものである。ＩａａＳがあれば、ハードウェアの準備や、メンテナンスなどの運用管理を行う必要はない。ＩａａＳのＯＳ上で動くアプリケーションは、ユーザーが用意する。

【0008】

クラウドコンピューティング、とくにＰａａＳの最大の魅力の１つとして、サービス要求の量の変化に応じて柔軟に、サーバの規模を変化させられるということがある。クラウドコンピューティング環境では、様々な要件を持った異なる種別の業務システム（以降、テナントと呼称する）が計算機環境のリソースを共有しながら複数稼働する構成が一般的であり、そのような構成をマルチテナント環境と呼称する。マルチテナント環境とは、複数のテナントが時間帯に応じてリソースを確保したり開放したりして、一以上のリソースを共用する環境のことをいう。マルチテナント環境では、新規のテナントを投入する場合や稼働中のテナントにリソースを追加する場合に、マルチテナント環境に要求されるリソース確保要求に対して十分な空きが存在しない状況が生じ得る。

【0009】

このような要求をみたす１つの仕組みとして、ロード・バランサがあり、予め用意しておいた複数の段階の許容量までの要求の増加に対応できる。ただ、ロード・バランサの仕組みを実現するには、複数のサーバを予め用意して走らせておかなくてはならず、稼働しているサーバ・インスタンスで課金されると、クラウド環境のランニング費用が高額になる。

【0010】

プラットフォーマーがＷｅｂサービスなどの事業を展開する場合には、事業に関係する情報授受や分析、購買の基盤（プラットホーム）をクラウドコンピューティング環境に置く事例が多く、できるだけ限られたコンピュータリソースに多くの個別顧客向け、もしくは個別用途向けサービス（テナント）を稼働させ、当該コンピュータリソースの契約料などのランニング費用を抑制することが、プラットフォーマーとしての事業としては経営面での課題となる。

【0011】

上記に関連し、特許文献１には、複数のサービス間で余剰のリソースを融通し、余剰リソースの維持コストが低減できるリソース配分方法が記載されている。この方法では、待機系計算機リソースが、少なくともアプリケーションがインストールされていないデッドスタンバイ状態を持ち、このデッドスタンバイ状態の計算機リソースを複数サービスや複数ユーザで共有することで、遊休計算機リソースの使用率の向上やサーバ統合を実現し、計算機リソース維持に必要なコストを削減する。また、この方法では、個々のサービスに関し過去の稼動履歴を用いて負荷予測を行い、余剰のでるサービスから確保して維持している遊休計算機リソースを予測結果に応じて投入する。

【0012】

特許文献２には、動的スケーラビリティの品質要求指標を可変にし、与えられた指標を満たすように、様々な手段からなる事前準備を組み合わせたプラットフォーム・サービスについて記載されている。このサービスでは、クラウド・サーバは、ホット・スタンバイ、スワップ・アウト状態、コールド・スタンバイなどの様々な事前準備状況のプラットフォームを組み合わせて提供する。

【0013】

特許文献３には、リソースの割り当てを要求するテナントのリソース確保要求の要求期間や利用している機能など、テナントのリソース利用形態を考慮して、提供可能なリソースを算出してリソースの調停を行う方法が記載されている。

【0014】

特許文献４には、コンピュータリソースの提供要求に応じて、自身のリソースに複数の仮想マシンを起動して、クラスタ毎にリソースの割当要求を行うことについて記載されている。

【0015】

また、特許文献５～７には、ネットワーク上でユーザ（ノード）のコンピュータ資源またはそれによるサービスを相互に提供・利用することについて記載されている。

【0016】

また、上記に関連した非特許文献１、２が開示されている。非特許文献２におけるKubernetes（登録商標）は、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームである。Kubernetesはエコシステムのサービス、サポート、ツールは幅広い形で利用可能である。ここで、仮想化ソフトウェアとは、１つのサーバ上に複数台の仮想マシンを運用できるシステムのことで、１台のサーバに複数のＯＳを実行できるものである。コンテナとは、アプリケーションやミドルウェア、複数のＯＳを実行できる独立した環境のことで、仮想化ソフトウェアと非常に似ているが、大きな違いはコンテナレベルで空間をほかのシステムから分離させられる点である。これにより、異なるＯＳの実行が可能になるため、複数のＯＳが実行しているシステムを1つにまとめることができる。コンテナには、アプリケーションを実行する機能はあるが、コンテナを管理したり、ほかのサーバと連携させたりする機能を持ってはいない。そこで、「連携できない」という問題点を解決してくれるのがKubernetesである。

【0017】

Kubernetesはコンテナオーケストレーションツールのひとつである。コンテナオーケストレーションとは、複数あるコンテナを管理する技術のことである。複数のコンテナを運用する場合、ネットワークやストレージなどの連携管理を行う必要があり、コンテナオーケストレーションツールは、これらの管理を行ってくれるため、コンテナがダウンしたり、アプリケーションに高負荷がかかったりした場合もスムーズに運用できる。Kubernetesには、複数のコンテナを管理するKubernetes Podがあり、さらに複数のPodがNodeにまとめられている。そして、Nodeが集まったものが「クラスター」となる。つまり、クラスターは、Kubernetes全体構造の最上位階層に位置する部分といえる。Kubernetesがコンテナの配置や削除を行うとき、直接指示を出すのがクラスターで、これにより、システム効率がよくなり、リソースを最大限活用できたり、機密情報の管理なども容易に行えたりする。

【0018】

また、Kubernetesの機能のひとつであるリソースクォータは、複数のユーザーやチームが決められた数のノードを持つクラスターを共有しているとき、1つのチームが公平に使えるリソース量を超えて使用するといった問題が出てきた場合に、この問題に対処するための管理者向けツールである。Resource Quotaオブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供する。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、名前空間内のリソースによって消費されるコンピュートリソースの総量を制限できる。

【0019】

非特許文献３におけるIstioは、高機能なオープンソースのサービスメッシュであり、Kubernetesのようなプラットフォームにインストールして使用され、内部にサービスメッシュを展開する。サービスメッシュとは、マイクロサービスアーキテクチャーのようなサービスを複数展開し、相互に連携して全体の機能を実現しているときにそれらのサービス間のネットワークを仲介する機能である。例えば、サービス間で通信したいとなった際に通信相手のサービスの名前解決を行なったり、それらの通信に失敗したときのリトライ機能などを基本的な機能として持つ。これにより、マイクロサービスアーキテクチャーにおいて課題になりがちであった、サービス間の通信の障害や通信が増えることによる性能劣化といった問題を解決し、マイクロサービスアーキテクチャーを実現しやすくする。

【0020】

上述した特許文献１～７、および非特許文献１～３に記載の技術では、予め契約済みリソースの範囲内でのマルチテナント運用のパフォーマンス維持とランニング費用抑制が考慮されていない。上記各技術は、計算機環境のリソース量または使用量を参照して、要求されるリソース確保要求に対して割り当てリソース量を調節する機能を備えたリソース割当方法、または各テナントからの要求に応じて計算機環境のリソース量または使用量のみ考慮したリソース調整であるため、予め契約済みのリソースの範囲内での柔軟なプラットフォーマ・サービス運用に制約が多く発生し、個別顧客向け、もしくは個別用途向けサービスの稼働率や性能面のパフォーマンスの維持が難しい。

【0021】

また、マルチテナント環境の場合、クラウド環境コンピューティング環境のランタイム、ミドルウェア、ＯＳ、仮想化環境（ＶＭ）、ＣＰＵ、ストレージ、ネットワーク・ポートなどのリソースを複数テナントで共用するため、一部のテナントユーザが想定外の負荷の高いサービスを実行すると、同一環境下のほかのテナントサービスの稼働率が低下し十分なサービスを提供することができない問題がある。つまり、予め契約済みのリソースの範囲内での個別顧客向け、もしくは個別用途向けサービスの稼働率や性能面のパフォーマンスの維持が難しい。とくにマルチテナント環境の場合、余裕を多めに見積もったリソースを予め稼働させておくか、もしくはリソースが足らない場合にその都度リソースを追加しなければならず、稼働させるサーバリソース・インスタンスでその都度課金され、ランニング費用が高額になる。

【0022】

この場合、とくにＰａａＳやＳａａＳの事業形態で、限られたクラウドコンピューティング環境に複数の個別顧客向け、もしくは個別用途向けサービスを稼働させるプラットフォーマの場合は、事業の採算性が悪くなる。

【先行技術文献】

【特許文献】

【0023】

【特許文献1】特開２００５－１４１６０５号公報

【特許文献2】特許第５９３９７４０号

【特許文献3】特許第６１９０９６９号

【特許文献4】特許第５２７７０６２号

【特許文献5】特開２００４－２０６２７３号公報

【特許文献6】特開２００７－３２３４３９号公報

【特許文献7】特開２００２－９２３６６号公報

【非特許文献】

【0024】

【非特許文献1】“Amazon Elastic Compute Cloud (Amazon EC2)”、amazon web services（登録商標）、［２０２２年１月１８日検索］、インターネット＜ＵＲＬ：https://aws.amazon.com/jp/ec2/＞

【非特許文献2】“Kubernetes”、リソースクォータ、［２０２２年１月１８日検索］、インターネット＜ＵＲＬ：https://kubernetes.io/ja/docs/concepts/policy/resource-quotas/＞

【非特許文献3】“Istio”、［２０２２年１月１８日検索］、インターネット＜ＵＲＬ：https://istio.io/latest/＞

【発明の概要】

【発明が解決しようとする課題】

【0025】

本発明が解決しようとする課題は、複数のテナントが存在する環境下で、限られた契約範囲でのクラウドコンピューティング環境のリソース配分の最適化により、リソースを平準化し、契約範囲の極小化によりランニング費用を抑制することができる計算機システム、リソース調整方法、およびプログラムを提供することである。

【課題を解決するための手段】

【0026】

実施形態の計算機システムは、マルチテナント環境を構成する。計算機システムは、トレーディングエージェント部と、リソーストレーディングマーケット処理部とを持つ。トレーディングエージェント部は、各テナントからのリソース確保要求およびリソース解放要求に基づいて、テナント間のリソースの確保と解放のマッチングを行い、マッチング結果に基づいて各テナントへのリソースの割り当てを変更する融通処理を行うと共に、前記マッチング結果をリソーストレーディングマーケット処理部に送信する。リソーストレーディングマーケット処理部は、前記マッチング結果に基づいて、前記マッチングに伴う前記テナント間のリソース確保と解放の授受または融通に伴う、リソースの貸借関係の収支の調整処理を行う。

【図面の簡単な説明】

【0027】

【図1】計算機システムが利用される様子を示す図。

【図2】トレーディングエージェント部１１０の構成図。

【図3】テナント構成情報１２１の内容の一例を示す図。

【図4】テナントプロファイル情報１２２の内容の一例を示す図。

【図5】テナント１０としての確保要求に係る占有期間、ＣＰＵ割り当てに関する要求台数と確保要求時間帯、およびメモリ割り当てに関する要求メモリ量を示す図。

【図6】トレーディングエージェント部１１０がメモリ割り当てに関してリソースの融通処理を行った結果を示す図。

【図7】マーケットメイク方式による気配値を表示する画面を示す図。

【図8】優先度とＦＩＦＯによる方式を採用した場合におけるケースを類型化した図である。

【図9】融通処理の内容について説明するための図である。

【図10】カーボンクレジット取引が行われる様子を示す概念図。

【発明を実施するための形態】

【0028】

以下、実施形態の計算機システム、リソース調整方法、およびプログラムを、図面を参照して説明する。

【0029】

図１は、計算機システムが利用される様子を示す図である。計算機システム１００は、例えば、トレーディングエージェント部１１０と、リソーストレーディングマーケット部１３０とを備える。計算機システム１００は、一以上のテナント１０－１～１０－ｎ（ｎは自然数）からの確保要求または解放要求に応じて動作する。以下、いずれのテナントであるか区別しないときは、単にテナント１０と称する。テナント１０は、物理マシンであってもよいし、仮想マシンであってもよい。後者の場合、テナント１０は、リソース２００上に作成されたインスタンスであってもよい。テナント１０は、トレーディング・エージェント部１１０に対してリソース確保要求を送信したり、トレーディング・エージェント部１１０からの要請に従ってリソース融通を実行するサービスアプリケーション・グループである。マルチテナント環境におけるテナント１０は、１つ以上の物理的リソースまたは仮想的リソースで構成される。また、物理的リソースは１つ以上の物理マシンで構成され、物理マシンはリソースとして、例えば、ランタイム、ミドルウェア、OS、仮想化環境（VM）、ＣＰＵ、ストレージ、ネットワーク・ポートを備え、仮想マシンを実行する。テナント１０として稼動するサービスやアプリケーションには、例えばＷｅｂサーバと分散ＤＢで構成されるＷｅｂシステムや、最適化分析やその結果に応じた制御対象システムの制御を実行する監視制御システムが含まれる。

【0030】

テナント１０を利用する利用者は、インターネットやＷＡＮ（Wide Area Network）などのネットワークを介して計算機システム１００およびリソースにアクセスする。テナント１０は、計算機システム１００によって確保されたスケジュールに従って、リソース２００の一部を占有する。リソース２００のハードウェアは、計算機システム１００のハードウェアと共用されてもよい。リソース２００は、例えば、ランタイム、ミドルウェア、ＯＳ、仮想化環境（ＶＭ）、ＣＰＵ（Central Processing Unit）、ストレージ、ネットワーク・ポートなどのうち一部または全部を含む。

【0031】

このように、計算機システム１００は、マルチテナント環境を構成する。トレーディングエージェント部１１０は、テナント１０からのリソース確保要求およびリソース解放要求に基づいて、テナント１０間のリソースの確保と解放のマッチングを行い、マッチング結果に基づいて各テナントへのリソースの割り当てを変更すると共に、マッチング結果をリソーストレーディングマーケット処理部１３０に送信する。リソーストレーディングマーケット処理部１３０は、マッチング結果に基づいて、マッチングに伴う収支の調整処理を行う。

【0032】

図２は、トレーディングエージェント部１１０の構成図である。トレーディングエージェント部１１０は、例えば、リソースマッチング分析部１１１と、リソース要求処理部１１２と、リソース解放候補算出部１１３と、リソース確保・解放処理部１１４とを備える。これらの構成要素は、例えば、ＣＰＵ（Central Processing Unit）などのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）などのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭなどの着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。

【0033】

また、トレーディングエージェント部１１０は、記憶部１２０に格納された各種情報を参照して処理を行う。記憶部１２０には、テナント構成情報１２１、テナントプロファイル情報１２２、リソース利用情報１２３、リソース融通結果情報１２４、リソース状態監視情報１２５などの情報が格納される。

【0034】

図３は、テナント構成情報１２１の内容の一例を示す図である。テナント構成情報１２１は、テナント１０毎の物理マシンと仮想マシンを定義する構成情報で構成される。物理マシン構成情報は、物理マシン名と、マシンの総ＣＰＵ数と、マシンの総メモリ量、キャッシュ、Ｉ／Ｏ帯域幅、ネットワークポート数を含む。仮想マシン構成情報は、テナントに割り当てる仮想マシン名と、当該仮想マシンが稼働する物理マシン名と、当該仮想マシンに割り当てられているＣＰＵ数と、当該仮想マシンに割り当てられているメモリ割り当て量、Ｉ／Ｏ帯域幅、ネットワークポート数を含む。テナント構成情報１２１は、管理者によって手動で設定されてもよいし、管理ソフトウェアによって適宜自動的に新規作成、変更、更新されてもよい。

【0035】

図４は、テナントプロファイル情報１２２の内容の一例を示す図である。テナントプロファイル情報１２２は、例えば、テナントごとに、仮想マシン、ＣＰＵ割り当て数、メモリ割り当て量、Ｉ／Ｏ帯域幅、ネットワークポート数、ネットワークポート帯域、タイムスロット占有開始時刻および占有終了時刻、およびそれらの優先度（以下、テナント優先度）、並びにテナントポリシーなどの情報が設定されたものである。

【0036】

テナント優先度は、各リソース毎（テナントのＣＰＵ割当数、メモリ割当量、Ｉ／Ｏ帯域幅、ネットワークポート数、ネットワークポート帯域）に占有の優先度ランクを定義するものである。

【0037】

テナント優先度は、例えば以下に示すように１～５の５段階で設定される。５が最も優先度が高いことを示し、１が最も優先度が低いことを示す。優先度はリソースの解放側と要求側で意味合いが異なる。例えば、解放側の優先度をα、要求側の優先度をβとすると、α＋１＜βの場合に譲渡が成立する。
５：解放側→解放しない 、要求側→無条件に取得する（追加課金可）
４：解放側→解放しない 、要求側→クレジット取引に依存（優先度：高）
３：解放側→クレジット取引で譲渡可、要求側→クレジット取引に依存（優先度：通常）
２：解放側→クレジット取引で譲渡可、要求側→他テナントからは取得しない
１：解放側→無条件で譲渡可 、要求側→他テナントからは取得しない

【0038】

テナント優先度は、ほかのテナントリソースと優先度比較ができる情報であればよく、数値によるランク分けのほか、High、Middle、Lowや等の文字列の他に適宜ランク分けを表す数値やアルファベット等で表されてもよい。さらに、テナント優先度情報は静的に定義される情報に限らず、時間帯や曜日、日付、昼夜、季節といった情報を基に動的に変動するものであってもよい。

【0039】

「無条件に取得する」とは当該テナントが最低限確保することを保証しなければならないリソース量を示しており、図４に示すテナントでは、仮想マシンを４台と、メモリ割り当て量５１２［ＧＢ］を無条件で確保しなければならない。テナントを構成する仮想マシン台数で指定する他に、ＣＰＵ量やメモリ量等のリソース種別毎に指定してもよい。「無条件に取得する」を選択する場合、テナントは追加課金を許容する。

【0040】

「クレジット取引に依存（優先度：高）」とは、支払えるクレジット（後述）がある場合に占有することを示している。「クレジット取引で譲渡可」とは、確保後であってもクレジットの取得によって解放可能であることを示している。「無条件に譲渡可」とは、条件の如何によれず解放可能であることを示している。

【0041】

「タイムスロット」は、テナントがリソース確保要求を出す際に要求する占有開始時刻と占有終了時刻を指定する情報である。テナント単位でタイムスロットが指定されてもよいし、各リソース毎に個別のタイムスロットが指定されてもよい。「ＣＰＵ割当数」は、ＣＰＵに対する利用量が分かる情報であればよく、使用中の仮想ＣＰＵ数や周波数のほか、ＣＰＵ使用率といった情報が使用されてもよい。「メモリ割当量」は、メモリに対する利用量が分かる情報であればよく、メモリ割当量に対する使用比率が使用されてもよい。「ストレージ割当量」は仮想マシンに割り当てられているストレージに対する利用量が分かる情報であればよく、ディスクの読み込み／書き込み性能値やディスクの読み込み／書込み量、ディスクの使用容量や空き容量といった情報が使用されてもよい。「Ｉ／Ｏ帯域幅」は仮想マシンのＩ／Ｏ帯域利用量が分かる情報であればよく、単位時間あたりに仮想マシンが送受信するデータ量であり、単位時間あたりに仮想マシンが授受するデータ数や、特定時間内に仮想マシンが授受する総データ量といった情報が使用されてもよい。「ネットワークポート数」は仮想マシンのネットワークポート数が分かる情報であればよく、仮想マシン上のプロセス、アプリケーション、各種プロトコルに割り当てるポート数を指定する情報である。「ネットワークポート帯域」は仮想マシンのポートのネットワーク利用量が分かる情報であればよく、単位時間あたりに仮想マシンが送受信するパケット数や、特定時間内に仮想マシンが送受信する総データ量や総パケット数といった情報が使用されてもよい。

【0042】

リソース利用情報１２３とは、各テナントによるリソースの利用状況を示す情報である。リソース融通結果情報１２４とは、リソースの融通処理を行った結果を示す情報である。リソース状態監視情報１２５とは、各リソースの状態を示す情報である。

【0043】

図２に戻り、リソースマッチング分析部１１１は、テナントプロファイル情報およびリソース状態監視情報１２５を定期的または監視要求時に取得し、テナントプロファイル情報１２１およびテナント利用情報１２３として記憶部１２０に格納する。

【0044】

リソース要求処理部１１２は、テナント１０からのリソース確保要求を受信し、リソース確保処理後の結果をリソース確保要求元のテナント１０へ送信する。リソース確保要求には、例えば、物理マシン、仮想マシン、プログラム、サービスに割り当て可能なリソースの種別と量、当該リソースの利用期間、およびリソース占有の優先度ランクを示す情報が含まれる。リソースの種別としては、例えば、物理または仮想マシンの台数、ＣＰＵ数、ＣＰＵ周波数、ＣＰＵ１個あたりの占有量や予約量、割り込みタイミング、メモリ量、Ｉ／Ｏスループット、Ｉ／Ｏ帯域、Ｉ／Ｏ容量あたりの占有量や予約量、キャッシュ容量、ネットワークポート数、ネットワークポートの帯域などを設定できる。リソースの利用期間を設定する方法には、占有開始時刻と期間を指定する方法や、占有終了時刻を指定する方法、あるいは占有開始時刻のみを指定する方法がある。占有開始時刻と期間を指定する方法の例としては「現時刻から６時間利用」「８：００から１２時間利用」といった方法が挙げられる。占有終了時刻を指定する方法の例としては、「本日２０：００まで占有」「２０２２年１月１８日 １４：００まで利用」といった方法が挙げられる。占有開始時刻のみを指定する方法の例としては「現時刻より利用開始」「２０２２年１月１８日８：００より利用開始」といった方法が挙げられる。

【0045】

リソース解放候補算出部１１３は、テナント１０からのリソース確保要求に応じて、他のテナント１０が解放可能なリソース量を算出し、算出結果をリソース融通結果情報１２４に格納する。

【0046】

リソース確保・解放処理部１１４は、リソース融通結果情報の内容に従い、リソーストレーディングマーケット部１３０へリソース確保を指示する。

【0047】

リソーストレーディングマーケット部１３０は、物理的および仮想的リソース構成を制御する。リソース確保・解放処理部１１４は、リソース構成を制御するプロセスと、リソース構成情報を持つ。リソーストレーディングマーケット部１３０は、例えば、トレーディングエージェント部１１０または他のクラウド環境で稼動するプログラムからの実行命令を受けることで動作するが、これに限定されず、特定の指令権限や条件下において管理者からの人為的操作指令をトリガに動作してもよい。

【0048】

［割り当て計画］
以下、トレーディングエージェント部１１０によるリソース割り当て処理について説明する。トレーディングエージェント部１１０は、各テナント１０のテナントプロファイル情報１２２から、各リソースの確保要求とその各々の優先度を取得し、取得した情報に基づいてリソースの割り当て計画を立てる。

【0049】

図５は、テナント１０としての確保要求に係る占有期間、ＣＰＵ割り当てに関する要求台数と確保要求時間帯、およびメモリ割り当てに関する要求メモリ量を示す図である。これに対して、図６は、トレーディングエージェント部１１０がメモリ割り当てに関してリソースの融通処理を行った結果を示す図である。図６は、各テナント１０の各タイムスロットにおけるメモリ割り当てリソースの必要量と、その優先度によりテナント間で同一リソース（この場合はメモリ）を融通し合った例を示している。図中、「テナント１」と表記されているテナント１０（以下、単にテナント１と称する）は、ベース契約として１２８［ＧＢ］を確保しており、一時的に２５６［ＧＢ］が必要な時間帯が生じている。テナント２は３２［ＧＢ］を、テナント３は１６［ＧＢ］を、テナント４は８［ＧＢ］を、それぞれベース契約としている。テナント５は１６［ＧＢ］をベース契約とし、３２［ＧＢ］必要な時間帯と、８［ＧＢ］で十分な時間帯が生じている。テナントｎは２５６［ＧＢ］をベース契約とし、一時的に１２８［ＧＢ］で十分な時間帯が生じている。このような状態において、矢印内で示すようにメモリ割り当て量を融通し合うことで、外部からのリソースの追加を最小限に留めることができる。トレーディングエージェント部１１０は、例えば２時間ごとに区切られる単位時間ごとに、リソース要求がリソース解放候補に存在するか否かを、例えば５分毎に確認し、各テナントリソースの優先度とマッチングパターンのロジックに基づいて、成立するか否かを判定する。また、トレーディングエージェント部１１０は、例えば、キューにより先入れ先出し（First In First Out : FIFO）型の待ち行列モデルに従って融通処理の順序を決定し、融通処理の順序を変更する。詳しくは、後述する。

【0050】

テナント１０は、例えば、他のテナント１０から融通を受けたリソースの見返りに、自身がリソースを解放可能なタイムスロットに返却する。テナント１０は、自身が必ずしもリソースを必要としないタイムスロットでは、基本的にリソースの解放を承諾し、自身が必要とするタイムスロットに備えてクレジットの貯蓄をすることもできる。なお、トレーディングエージェント部１１０は、予め契約済みのリソースの範囲内の取引きではリソースが不足する場合、ロードバランサに代表されるリソース管理の仕組みを用いて、自動的にリソースを追加してもよい。この場合、リソーストレーディングマーケット処理部１３０による収支の調整処理の枠外でテナント１０に課金がなされる。

【0051】

［クレジット］
リソーストレーディングマーケット処理部１３０は、種類の異なるリソースに関して価値を正規化して示す仮想価値である単位：クレジットを導入し、仮想的にテナント１０にクレジットを授受させることで、種類の異なるリソースを融通し合うことを容易にしてもよい。クレジットは、次式のように、リソースの種別ごとの確保される単位（例えば、ＣＰＵ数、メモリ割り当て量、Ｉ／Ｏ帯域幅、ネットワークポート数、タイム・スロット等）に係数を乗算することで求められる。式中、Ｋｃｐｕ、Ｋｍｅｍ、Ｋｉｏ、Ｋｐｏｒｔのそれぞれはリソースの物理的、または概念的な種類の違いを吸収するための係数である。

【0052】

クレジット＝Ｋｃｐｕ×ＣＰＵ数×時間
＝Ｋｍｅｍ×メモリ割り当て量（ＭＢ）×時間
＝Ｋｉｏ×Ｉ／Ｏ帯域幅（バイト）×時間
＝Ｋｐｏｒｔ×ネットワークポート数×時間

【0053】

クレジットを使用する場合、テナントプロファイル情報１２２（リソーストレーディングマーケット処理部１３０が参照可能であるものとする）等に、テナントごとのクレジット保有量が格納されてよい。クレジットは、例えば任意のタイミングで現金その他の実価値と交換される。これによって、テナント１０は、種類の異なるリソースを円滑に融通し合うことが可能となる。なお、リソーストレーディングマーケット処理部１３０は、同じ種類のリソースに関してはクレジットに換算して収支の調整処理を行ってもよいし、現物取引（例えば「メモリ割り当て量（ＭＢ）×時間を借り入れ」といった情報を記憶しておき、別のタイミングでその一部を返却すること）によって収支の調整処理を行ってもよい。

【0054】

リソーストレーディングマーケット処理部１３０は、リソースの融通に関する対価を決定する際に、気配値を提示して売買注文を成立させるマーケットメイク方式などの方式や、優先度とＦＩＦＯによる方式を用いて対価を決定してもよい。図７は、マーケットメイク方式による気配値を表示する画面（「板」と通称されている）を示す図である。図示するように、現物取引を前提としたＣＰＵ板、メモリ板、或いはクレジットの取引を目的としたクレジット板が、リソーストレーディングマーケット処理部１３０の内部処理情報として管理され、或いはテナント１０に提示されてよい。これらの他にも、任意の売買形態が採用されてよい。

【0055】

以下、優先度とＦＩＦＯによる方式について説明する。リソースの融通に伴って授受されるクレジットの量は、例えば確保要求を出す側（要求側）のテナント１０の優先度に基づく重み（下記）によって決定されてもよい。例えば、リソースの量と基準値を乗算して計算されるクレジットに、要求側の優先度に基づいて決定される重みを乗算した値が、要求側のテナント１０から解放側のテナント１０に支払われる。更に、優先度が５の要求側のテナント１０に関しては、追加課金を支払うことで外部からのリソースの調達も行われる。

【0056】

（要求側の優先度：重み）
５：重み１．５
４：重み１．４
３：重み１．３

【0057】

図８は、優先度とＦＩＦＯによる方式を採用した場合におけるケースを類型化した図である。前述したように、「解放側の優先度をα、要求側の優先度をβとすると、α＋１＜βの場合に譲渡が成立する」規則が適用されるものとした場合、各ケースにおける譲渡の成否と対価は如何のようになる。

【0058】

ケースＡの場合、α＝４または５、β＝５であり、α＋１≧βとなるため譲渡は成立しない。この場合、追加リソースを確保するためのクレジットＣＯに、要求側の優先度に対応する重み１.５が乗算された１．５×ＣＯが要求側のテナント１０に追加課金されることで、要求側のテナント１０にリソースが割り当てられる。

【0059】

ケースＢの場合、α＝３、β＝５であり、α＋１＜βとなるため譲渡が成立する。この場合、テナント間譲渡に適用されるクレジットＣＩに、要求側の優先度に対応する重み１.５が乗算された１．５×ＣＩが要求側のテナント１０から解放側のテナント１０に支払われることで、解放側のテナント１０から要求側のテナント１０にリソースが譲渡される。ここで、例えばＣＯ≧ＣＩである。

【0060】

ケースＣの場合、α＝２、β＝５であり、α＋１＜βとなるため譲渡が成立する。この場合、テナント間譲渡に適用されるクレジットＣＩに、要求側の優先度に対応する重み１.５が乗算された１．５×ＣＩが要求側のテナント１０から解放側のテナント１０に支払われることで、解放側のテナント１０から要求側のテナント１０にリソースが譲渡される。

【0061】

ケースＤの場合、α＝１、β＝５であり、α＋１＜βとなるため譲渡が成立する。この場合、テナント間譲渡に適用されるクレジットＣＩに、要求側の優先度に対応する重み１.５が乗算された１．５×ＣＩが要求側のテナント１０から解放側のテナント１０に支払われることで、解放側のテナント１０から要求側のテナント１０にリソースが譲渡される。

【0062】

ケースＥの場合、α＝３～５、β＝４であり、α＋１≧βとなるため譲渡は成立しない。

【0063】

ケースＦの場合、α＝２、β＝４であり、α＋１＜βとなるため譲渡が成立する。この場合、テナント間譲渡に適用されるクレジットＣＩに、要求側の優先度に対応する重み１.４が乗算された１．４×ＣＩが要求側のテナント１０から解放側のテナント１０に支払われることで、解放側のテナント１０から要求側のテナント１０にリソースが譲渡される。

【0064】

ケースＧの場合、α＝１、β＝４であり、α＋１＜βとなるため譲渡が成立する。この場合、テナント間譲渡に適用されるクレジットＣＩに、要求側の優先度に対応する重み１.４が乗算された１．４×ＣＩが要求側のテナント１０から解放側のテナント１０に支払われることで、解放側のテナント１０から要求側のテナント１０にリソースが譲渡される。

【0065】

ケースＨの場合、α＝２~５、β＝３であり、α＋１≧βとなるため譲渡は成立しない。

【0066】

ケースＩの場合、α＝１、β＝３であり、α＋１＜βとなるため譲渡が成立する。この場合、テナント間譲渡に適用されるクレジットＣＩに、要求側の優先度に対応する重み１.３が乗算された１．３×ＣＩが要求側のテナント１０から解放側のテナント１０に支払われることで、解放側のテナント１０から要求側のテナント１０にリソースが譲渡される。

【0067】

［バンキング機能］
リソーストレーディングマーケット処理部１３０は、リソースのバンキング機能を有し、テナントから余剰のリソースを預かると共に当該テナントに対価（例えばクレジット）を付与したり、テナントにリソースを貸与すると共に当該テナントから対価（同）を受領したりしてもよい。この場合、リソーストレーディングマーケット処理部１３０は、どのテナント１０のベース契約にも該当しない余剰のリソースを予め保持するようにしてもよい。

【0068】

［ＦＩＦＯ］
前述したように、トレーディングエージェント部１１０は、ＦＩＦＯ型の待ち行列モデルに従って融通処理の順序を決定し、融通処理の順序を変更する。図９は、融通処理の内容について説明するための図である。トレーディングエージェント部１１０は、リソース要求側と、リソース解放候補とマッチングの照合順序については、たとえば、リソース要求側と、リソース解放候補のそれぞれをＦＩＦＯキューに挿入し、単位時間毎にマッチングのロジックが成立するか否かを照合判定する。図９の例では、トレーディングエージェント部１１０は、リソース要求の識別子Ｒ０００３に対し、解放候補の識別子Ｃ０００５のマッチング条件が成立し、双方のＦＩＦＯキューから削除された例を示している。このマッチングの照合判定をトレーディングエージェント部１１０は、例えば、毎日０時０分に実行する。この照合判定の実行頻度が例えば１時間毎、１分毎などに細分化されれば、予め契約済みのリソースの範囲内でのリソース平準化が促進される。

【0069】

それぞれの識別子［Ｒ＊＊＊＊］、［Ｃ＊＊＊＊］には、各リソースのテナントプロファイル情報、例えば、テナントごとに、仮想マシン、ＣＰＵ割り当て数、メモリ割り当て量、Ｉ／Ｏ帯域幅、ネットワークポート数、ネットワークポート帯域、タイムスロット占有開始時刻および占有終了時刻、およびそれらのテナント優先度、並びにテナントポリシーなどの情報が設定されている。

【0070】

さらに、トレーディングエージェント部１１０は、リソース要求側で照合単位時間における優先度以外が同条件であれば、ＦＩＦＯキュー内の照合順序の高／低を入れ替えてもよい。上記の例では、Ｒ０００６のほうがＲ０００３よりも優先度が高いため、ＦＩＦＯキュー内でマッチングの照合順序の入れ替えが起こっている。また、トレーディングエージェント部１１０は、解放候補側で照合単位時間における優先度以外が同条件であれば、ＦＩＦＯキュー内の照合順序の高／低を入れ替えてもよい。上記の例では、Ｃ０００５のほうがＣ０００２よりも優先度が低いため、ＦＩＦＯキュー内でマッチングの照合順序の入れ替えが起こっている。この、リソース要求側と、リソース解放候補それぞれで、照合単位時間における優先度以外の条件が同一であれば、それぞれの照合順序を入れ替えることにより、予め契約済みのリソースの範囲内でのマッチングの機会を増加させることになり、リソース平準化が促進される。

【0071】

なお、トレーディングエージェント部１１０は、ＦＩＦＯキューを用いた方法に代えて、目的関数を用いた制約付き最適化問題を解くことで処理を行ってもよい。目的関数Ｆ（ｘ１，ｘ２，…，Ｘｎ）は、Ｆ（仮想マシン、ＣＰＵ割り当て数、メモリ割り当て量、Ｉ／Ｏ帯域幅、ネットワークポート数、ネットワークポート帯域、タイムスロット、テナント優先度、テナントポリシー）と定義される。

【0072】

（目的関数）＝Ｆ（ｘ１，ｘ２，…，Ｘｎ）
＝予め契約済みのリソースの範囲内でのマッチングの機会の最大化
（制約）：解放側の優先度４以上は自リソースの解放を許容しない。

【0073】

なお、上記はマッチングの機会の最大化を目的としたが、状況に応じて、全テナントのパフォーマンス最大化であれば、追加課金も許容する外部リソースによる補填を優先させる解もあり得る。最適化手法は、古典的なラグランジュ定数法をはじめ種々あるが、近年主流であるソルバーやＡＩを活用してもよい。

【0074】

［カーボンクレジット等］
計算機システム１００は、融通処理によって低減されたエネルギー消費量を計算し、計算した値に基づいて環境貢献量取引を行ってもよい。環境貢献量取引とは、例えばカーボンクレジットである。図１０は、カーボンクレジット取引が行われる様子を示す概念図である。日本国内であれば経済産業省が主導する「Ｊ－クレジット」に登録することで、公的機関からクレジットの認証が得られる。欧米であればＥＴＳ（Emission Trading Scheme）がこれに相当する。

【0075】

［その他］
計算機システム１００は、テナント１０に割り当てられなかった余剰なリソースを、外部環境に提供し、提供した分の対価を計算機システム１００の運営者（例えばＰａａｓの運営者）の利益としてもよい。また、計算機システム１００は、外部から得られた利益を各テナント１０にクレジットとして分配してもよいし、外部から得られた利益に応じて、各テナント１０の契約料をディスカウントしてもよい。

【0076】

以上説明した少なくともひとつの実施形態によれば、各テナントからのリソース確保要求およびリソース解放要求に基づいて、テナント間のリソースの確保と解放のマッチングを行い、マッチング結果に基づいて各テナントへのリソースの割り当てを変更する融通処理を行うと共に、前記マッチング結果をリソーストレーディングマーケット処理部に送信するトレーディングエージェント部１１０と、前記マッチング結果に基づいて、前記マッチングに伴う前記テナント間の収支の調整処理を行う前記リソーストレーディングマーケット処理部１３０と、を持つことにより、複数のテナントが存在する環境下で、限られた契約範囲でのクラウドコンピューティング環境のリソース配分の最適化により、リソースを平準化し、契約範囲の極小化によりランニング費用を抑制することができる。

【0077】

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

【符号の説明】

【0078】

１０ テナント
１００ 計算機システム
１１０ トレーディングエージェント部
１３０ リソーストレーディングマーケット部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】