JP4616674B2 - リソース貸借方法、および、リソース貸借システム - Google Patents

Description

本発明は、計算機におけるリソース貸借方法、および、リソース貸借システムに関する。

インターネットなどに接続されたコンピュータが、オンラインショッピングなどの業務を提供する形態が普及している。オンラインショッピングの商品販売会社などのサービスの提供者は、サービスを行うコンピュータ（サーバ装置）を自前で用意する代わりに、専門の業者から間借り（レンタル）して用意する形態を取っていることも多い。このように、インターネットに情報を発信するコンピュータを間貸しするサービスは、一般的にホスティング（hosting）と呼ばれる。

リソースは、ホスティングにおいてレンタルの対象となるコンピュータ資源である。コンピュータ資源は、例えば、アプリケーションソフトを実行するためのハードウェア資源（特定用途向けサーバ装置、ＣＰＵ（Central Processing Unit）、メモリ、ＨＤＤ（Hard Disk Drive）、ロードバランサなど）だけでなく、アプリケーションソフトなどのソフトウェア資源なども挙げられる。

なお、リソースのＷｅｂサービス表現の規定（Management Using Web Services）、および、Ｗｅｂサービスとしての管理方法の規定（Management Of Web Services）は、ＷＳＤＭ（Web Services Distributed Management）（非特許文献１参照）に記載されている。

ホスティング業者のセンタ装置（以下、センタ装置を単にセンタと略す）は、間貸しするリソースを有し、そのリソースをもとに業務をユーザに提供する。例えば、Ｗｅｂサーバというリソースをもとに、オンラインショッピングの商品カタログ提示という業務を、ユーザ端末に提供する。よって、センタは、業務ごとに必要なリソースを確保し、ホスティングを行っている。必要なリソースをユーザに提供する割当方法は、例えば、本願出願人による分散計算機の処理方法及びシステム（特許文献１）が挙げられる。

なお、Ｗｅｂサービスを使った状態を持ったリソースへの一般的なモデル化とアクセス方法の規定は、ＷＳＲＦ（Web Services Resource Framework）（非特許文献２）、および、ＷＳＲＰ（Web Services Resource Properties）（非特許文献３）に記載されている。

ここで、装置故障などの障害によるリソースの利用不可、アクセス集中などによるリソースの処理能力を超過する業務処理の発生などで、既にホスティングを行っているリソースが、一時的に不足する事態が発生することもある。そのため、従来は、リソースの一時的な不足が発生する前に、リソースの不足要因を予測して、他のセンタから予備のリソースを借用する契約を結んでいた。

なお、リソースを借用する契約は、例えば、リソースプロバイダとコンシューマー間の契約情報のやり取りの規定であるＷＳ−Ａｇｒｅｅｍｅｎｔ（非特許文献４参照）に従って、行われる。リソースの不足が発生したときには、この予備のリソースを用いることにより、業務の停止を回避することができる。
特開２００４−２４０６７１号公報（段落[００１３]） ＯＡＳＩＳ（Organization for the Advancement of Structured Information Standards）、"ＷＳＤＭ（Web Services Distributed Management）"、[online]、［平成１７年２月１５日検索］、インターネット＜ＵＲＬ：http://docs.oasis-open.org/wsdm/2004/12/wsdm-1.0.zip＞ ＯＡＳＩＳ、"ＷＳＲＦ（Web Services Resource Framework）"、[online]、［平成１７年２月１５日検索］、インターネット＜ＵＲＬ：http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-Resource-1.2-draft-02.pdf＞ ＯＡＳＩＳ、"ＷＳＲＰ（Web Services Resource Properties）"、[online]、［平成１７年２月１５日検索］、インターネット＜ＵＲＬ：http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.pdf＞ ＧＧＦ（Global grid forum）ＧＲＡＡＰ−ＷＧ、"ＷＳ−Ａｇｒｅｅｍｅｎｔ"、[online]、［平成１７年２月１５日検索］、インターネット＜ＵＲＬ：http://www.gridforum.org/Public#Comment#Docs/Documents/Public#Comment#2004/WS-AgreementSpecification#v2.pdf＞

しかしながら、予備のリソースを借りる契約は、リソースの一時的な不足が発生する前に行われる固定的なものであり、融通性が無かった。よって、仮に、リソースの一時的な不足が発生しなくても、他のセンタからリソースを借り続ける費用は発生してしまう。この予備のリソースは、通常のホスティングを行うときには、使用しない無駄なリソースである。よって、予備のリソースを借りる固定的な契約では、センタのコストパフォーマンスが悪くなってしまう。

また、リソースの一時的な不足が発生したときにリソースを借りるという条件付きの契約とすれば、リソースの一時的な不足が発生するまでは、レンタル費用は発生しない。しかし、条件付きの契約を行う時期は、リソースの一時的な不足が発生する時期よりも前となる。よって、リソース部品の価格競争などにより、安いレンタル費用でリソースを提供するセンタが存在しているにもかかわらず、条件付きの契約を行ったセンタが提供する割高のリソースをレンタルしなくてはならず、コストパフォーマンスが悪くなってしまう。

そこで、本発明は、前記した問題を解決し、リソースの一時的な不足に対処できるホスティングを、低コストで実現することを主な目的とする。

前記課題を解決するため、本発明は、貸側センタ装置から借側センタ装置に計算機のリソースを貸し出すリソース貸借方法であって、
前記借側センタ装置が、
処理の要求元から順に、グローバルロードバランサ、ロードバランサ、Ｗｅｂサーバ、ＡＰサーバ、および、ＤＢサーバが接続されて構成される業務システムを有し、
貸し出す対象のリソースに関するリソース情報を前記貸側センタ装置から受信して管理テーブルに登録する手順と、
前記借側センタ装置のリソース不足を検知してボトルネックを前記Ｗｅｂサーバとして特定する手順と、
ボトルネックを解消するための前記ロードバランサ、および、前記Ｗｅｂサーバを含むリソースを、前記管理テーブルから検索し、検索したリソースを有する前記貸側センタ装置のセンタリストを作成する手順と、
前記センタリストの前記貸側センタ装置に、リソースの貸し出しを要求する手順と、
前記グローバルロードバランサと要求により貸し出されたリソースである前記ロードバランサとを接続するとともに、前記ＡＰサーバと要求により貸し出されたリソースである前記Ｗｅｂサーバとを接続する処理を含む、要求により貸し出されたリソースにアプリケーションをデプロイする旨の要求を前記貸側センタ装置に行う手順と、
を実行することを特徴とする。
その他の手段は、後記する。

本発明は、リソース不足の発生後に、リソースを要求することにより、リソースの一時的な不足に対処できるホスティングを、低コストで実現することを可能とした。

以下に、本発明が適用されるリソース賃借システムの一実施形態について、図面を参照して詳細に説明する。まず、本実施形態のリソース賃借システムの構成について、図１から図８を参照して説明する。

図１は、リソースの仮想化を示す説明図である。リソースは、自センタ内に実際に存在する実リソース、または、他センタ内の実リソースの内容を説明する仮想リソースに分類できる。例えば、センタＳＸは９つの実リソース（ＲＸ１〜ＲＸ９）を有し、センタＳＢは３つの実リソース（ＲＢ１〜ＲＢ３）を有する。そして、センタＳＸは、自ら有する２つの実リソース（ＲＸ３、ＲＸ６）を、センタＳＢに、仮想リソース（ＲＸ３、ＲＸ６）として、公開している。

このように、所定のセンタが、自ら有する実リソースを、別のセンタにオブジェクト（仮想リソース）として公開することを、リソースの仮想化と呼ぶ。例えば、センタＳＸは、センタＳＢの他に、実リソース（ＲＸ１，ＲＸ２，ＲＸ３）を図示しないセンタＳＡへ貸し出すために公開し、実リソース（ＲＸ５，ＲＸ６）を図示しないセンタＳＣへ貸し出すために公開する。

なお、リソースＲＸ３は、センタＳＡとセンタＳＢとの両方に公開しているが、所定の時期において貸し出せるのは、いずれか一方のセンタである。よって、公開したリソースは、他センタによって既に貸し出し済みとなっていることもあり、そのときには、リソースの貸し出しは行わない。

図２は、リソースの管理を示す説明図である。図２（ａ）は、センタＳＢが管理するリソースの一例を示す図である。センタＳＢは、自ら有する実リソース（ＲＢ１，ＲＢ２，ＲＢ３）の他に、センタＳＸから公開された仮想リソース（ＲＸ３、ＲＸ６）と、センタＳＹから公開された仮想リソース（ＲＹ１、ＲＹ２）と、を管理する。

図２（ｂ）は、リソースの管理を階層化した図である。全リソースは、所属するセンタごとに分類され、各センタのリソースは、Ｗｅｂ用、ＤＢ用などの用途別に分類される。

図３は、リソース賃借システムを示す構成図である。リソース賃借システムの各装置は、演算処理を行う際に用いられる記憶手段２０としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上のプログラムを実行することで、実現される。

センタＳＢ（借側センタ）は、自ら有するリソースおよびセンタＳＸ（貸側センタ）から借りたリソースをもとに、ホスティングサービスを提供する。そして、ユーザ端末１は、センタＳＸが提供するホスティングサービスを利用する端末である。

センタＳＢは、運用制御部１０Ｂ、業務システム１２Ｂ、ＦＷ／ＮＡＴ１４Ｂ、ユーザ側ＦＷ／ＮＡＴ１６Ｂ、および、記憶手段２０を有する。センタＳＸは、運用制御部１０Ｘ、業務システム１２Ｘ、ＦＷ／ＮＡＴ１４Ｘを有する。ＦＷ（firewall）は、外部のネットワークから不正な侵入を防ぐファイアウォールを示し、ＮＡＴ（Network Address Translation）は、１つのグローバルアドレスを複数のコンピュータで共有するためなどに使用されるアドレス変換を示す。

なお、センタＳＢとセンタＳＸとの関係は、リソースの賃借に関する相対的な関係にある。つまり、センタＳＸが別のホスティングサービスを提供するとき（つまり、借り側センタとなるとき）には、センタＳＸは、センタＳＢと同じ構成をとる。以下、各構成要素を具体的に説明する。

図４は、リソースの配備を示す説明図である。配備とは、業務を実現するアプリケーションを実行可能にするための前準備の総称であり、デプロイ（deploy）とも呼ばれる。前準備は、例えば、アプリケーションのインストールだけでなく、アプリケーションやアプリケーションが動作するＯＳ（Operating System）の設定をデフォルト（初期設定）から、業務に適した設定に変更する設定処理も含む。

図４（ａ）は、運用制御部１０Ｂおよび運用制御部１０Ｘの役割を示す図である。センタＳＢの運用制御部１０Ｂは、センタＳＸから借用したリソースをもとに、センタＳＸの運用制御部１０Ｘに対して、配備を指示する。指示を受けた運用制御部１０Ｘは、センタＳＢに貸し出したリソースに対して、配備を実行する。

図４（ｂ）は、配備に伴って行われるネットワークの設定処理を説明する図である。この設定は、ＦＷ／ＮＡＴ１４Ｂ、ＦＷ／ＮＡＴ１４Ｘ、および、ユーザ側ＦＷ／ＮＡＴ１６Ｂに行われる。ＮＡＴは、センタ内のローカルアドレス（ＬＩＰ：Local IP Address）と、インターネット接続のためのグローバルアドレス（ＧＩＰ：Global IP Address）の変換を行う。

まず、ＮＡＴは、例えば、図４（ｂ）に示すように、リソースごとにグローバルアドレスを割り振ってもよい（ＧＩＰ「Ｘ」−ＬＩＰ「Ａ」、ＧＩＰ「Ｙ」−ＬＩＰ「Ｂ」、ＧＩＰ「Ｚ」−ＬＩＰ「Ｃ」）。ＧＩＰ「Ｘ」−ＬＩＰ「Ａ」の表記は、グローバルアドレスの「Ｘ」は、ローカルアドレスの「Ａ」と対応する意である。

一方、ＮＡＴは、業務に割り振るＧＩＰは固定数（例えば１個）としてもよい（ＧＩＰ「Ｙ」＆Ｐｏｒｔ「Ｙ１」−ＬＩＰ「Ａ」＆Ｐｏｒｔ「α」、ＧＩＰ「Ｙ」＆Ｐｏｒｔ「Ｙ２」−ＬＩＰ「Ｂ」＆Ｐｏｒｔ「α」、ＧＩＰ「Ｙ」＆Ｐｏｒｔ「Ｙ３」−ＬＩＰ「Ｃ」＆Ｐｏｒｔ「α」）。ＧＩＰ「Ｙ」＆Ｐｏｒｔ「Ｙ１」−ＬＩＰ「Ａ」＆Ｐｏｒｔ「α」の表記は、グローバルアドレスが「Ｙ」でそのポート番号が「Ｙ１」というエントリは、ローカルアドレスが「Ａ」でそのポート番号が「α」というエントリと対応する意である。

図５〜図７は、業務システムを示す構成図である。業務システムとは、ホスティングサービスの業務を実行する計算機環境である。図５（ａ）は、リソースを借用する前の業務システム１２Ｂを示す。図５（ｂ）、図６、図７は、それぞれリソースを借用した後の業務システム１２Ｂおよび業務システム１２Ｘを示す。

ＬＢ（load balancer）は、受信したトランザクションを、Ｗｅｂサーバに振り分けることで、負荷分散を行う。Ｗｅｂサーバは、ＵＩ（User Interface）を提供し、その入力内容によりＣＧＩ（Common Gateway Interface）として、ＡＰ（Application）サーバを呼び出す。ＡＰサーバは、データアクセスを行うときには、ＤＢ（database）サーバを呼び出す。

なお、ＡＰサーバからＤＢサーバへのデータ要求は、例えば、ＳＱＬ（Structured Query Language）メッセージを、ＳＯＡＰ（Simple Object Access Protocol）のプロトコルに乗せて転送することにより行われる。これにより、インターネットを経由し、ファイアウォール（ＦＷ／ＮＡＴ１４Ｂ、ＦＷ／ＮＡＴ１４Ｘ）を超えることができる。

リソースを借用した後の業務システム１２Ｘ（図５（ｂ）、図６、図７）には、さらに、ＧＬＢ（Global load balancer）が追加される。ＧＬＢは、複数のＬＢを束ね、受信したトランザクションを、いずれかのＬＢに割り振る。これにより、エンドユーザからの要求（トランザクション）が振り分けられて、処理が独立化する。よって、複数のセンタに振り分けられるトランザクションについて、エンドユーザがＧＬＢという１つの窓口を知っていればよいことになり、利便性がよい。

次に、３つの業務システム１２Ｘ（図５（ｂ）、図６、図７）のいずれかを採用するかを判定する方式を説明する。複数の業務システム１２Ｘの候補から１つの業務システム１２Ｘを選別する基準は、リソースの一時不足を発生させる要因であるボトルネックの位置である。ボトルネックは、Ｗｅｂサーバ、ＡＰサーバ、または、ＤＢサーバとなる可能性がある。

まず、Ｗｅｂサーバがボトルネックのときには、図５（ｂ）に示すように、ＬＢ、Ｗｅｂサーバを追加する方式を選択する。または、ＡＰサーバがボトルネックのときには、図６に示すように、ＬＢ、Ｗｅｂサーバ、ＡＰサーバを追加する方式を選択する。または、ＤＢサーバがボトルネックのときには、図７に示すように、ＬＢ、Ｗｅｂサーバ、ＡＰサーバ、ＤＢサーバを追加する方式を選択する。なお、図７の追加されたＤＢサーバは、追加前のＤＢサーバとデータのレプリケーション（同期処理）を行い、データを互いにミラーリングする。

このように、ボトルネックの位置によって、採用する業務システム１２Ｘを選択する一例として、オンラインショッピングを挙げる。例えば、買い物の注文をしないで、商品を見ているユーザが多い場合は、商品のカタログを提示するＷｅｂサーバの負荷が高くなる。一方、買い物カゴに入れて注文をするユーザが多い場合は、ＡＰサーバ、または、ＤＢサーバの負荷が高くなる。

図８は、リソース（自センタが保持する実リソース、他センタから公開された仮想リソース）を管理する記憶手段２０を示す構成図である。センタリスト２２は、リソースをレンタルする相手となるセンタ候補の一覧である。

管理テーブル２４は、センタごとに、各センタがレンタル用に公開するリソースを提示するものである。公開するリソースは、用途別（Ｗｅｂ用、ＤＢ用、ＡＰ用）に分類され、全台数とそこからレンタル可能な空き台数との組となる。また、ロケーションは、自センタと、各レコードのセンタとの間の通信遅延時間を示し、値が小さいほど自センタから近い位置に各レコードのセンタがあることを示している。

詳細テーブル２６は、センタごとに用意されるテーブルであり、各センタの公開するリソースについての詳細情報を格納する。１つのレコードが１つのリソースに対応しており、例えば、項番１のリソースは、Ｗｅｂサーバに使用されるリソースであり、スペックが「Ｐｅｎ４、２［ＧＨｚ］」、貸し出し可能期間が「０５／０１／０１〜０６／０２／２８」、レンタル価格が「５０００円／ｈ」である。

以上、リソース賃借システムの構成について、説明した。次に、本実施形態のリソース賃借システムの動作のうち、ユーザ登録における処理について、図１から図８を参照しつつ、図９から図１１に沿って説明する。

図９は、リソースを管理する処理を示すフローチャートである。

まず、センタＳＢは、センタＳＸに、契約を実施する（Ｓ１０１）。なお、契約は、リソースの消費賃貸契約ではなく、センタＳＸがセンタＳＢに、貸し出す対象となるリソースに関する情報を提供する旨の契約である。この契約に基づいて、各センタは、一時的に融通し合えるリソースをお互いに連絡する。なお、この契約処理は、ネットワークを介してオンラインで行うこととしてもよいし、ＦＤ（flexible disk）媒体などのオフラインで行うこととしてもよい。

次に、センタＳＸは、センタＳＢに、Ｓ１０１の契約を行ったことを示す証明書（電子データ）を発行する（Ｓ１０２）。そして、センタＳＢは、Ｓ１０１の契約に従い、センタＳＸにリソース情報を要求する（Ｓ１０３）。さらに、センタＳＸは、Ｓ１０３の要求に含まれる契約の証明書を、Ｓ１０２で発行したものかどうかチェックする（Ｓ１０４）。そして、センタＳＸは、Ｓ１０４で確認がとれたときに、センタＳＢにリソース情報を返信する（Ｓ１０５）。さらに、センタＳＢは、受信したリソース情報をテーブル（管理テーブル２４、詳細テーブル２６）に登録する（Ｓ１０６）。

ここで、Ｓ１０５において、送信されるリソース情報の内容は、例えば以下のものが挙げられる。
・リソースのスペック
・空き情報
・レンタル価格
・ネットワーク構成（該当リソースが所属するネットワーク。該当リソースヘの配備ができるアドレスなど）
・稼動実績（遊休時間）
・リソース提供メーカー
・耐用年数
・稼動年数

なお、Ｓ１０５において、センタＳＸが公開しているリソース情報は、センタＳＸが抱えているすべてのリソースを見せているわけではなく、センタＳＢとの契約に基づいて、センタＳＸの少なくとも一部のリソースをセンタＳＢ向けに公開している。例えば、センタＳＸとセンタＳＣにＳ１０１とは別の契約がある場合には、センタＳＸがセンタＳＢに見せている情報とセンタＳＣに見せている情報は、基本的に異なっている（結果的に同じ場合もありうる）。

また、Ｓ１０５において、センタＳＸは、時々刻々と変化するリソース状況情報をＷｅｂサービスのインタフェースで提供する。公開されている情報は、スナップショットでの情報（例えば１時間おきや３０分おきなど）である。センタＳＢは、センタＳＸのリソースを使用すると判断したときに、そのリソースが既に他のセンタで使われている可能性があり、リソース状況情報としては古いものになってしまう。よって、リソース情報を取り込んだ時点で、その情報に変更があった場合は、センタＳＢは、センタＳＸに通知するように要求しておく。これにより、センタＳＢは、センタＳＸのリソース情報が変更した都度、センタＳＸから最新のリソース情報を取り込むことが可能になる。

さらに、リソース情報の返信（Ｓ１０５）およびテーブル（管理テーブル２４、詳細テーブル２６）の登録（Ｓ１０６）は、オンラインだけでなく、ダイレクトメールの郵送などのオフラインによる形式としてもよい。オフラインのときには、テーブル（管理テーブル２４、詳細テーブル２６）の登録（Ｓ１０６）は、紙面（ダイレクトメール）を元にした人手で行われることとなる。

ここで、センタＳＢとセンタＳＸは、ロケーション情報を測定する（Ｓ１１１）。そして、センタＳＸは、センタＳＢに、ロケーション情報の測定に対して応答する（Ｓ１１２）。具体的には、ロケーション情報は、自分センタと相手センタとの間の通信遅延である。自分センタは、相手センタのエンドポイントにアクセスすることで、応答時間を測定する。その測定結果の何回かの平均時間をもとめ、この情報をロケーション情報とする。よって、時間値が小さいほど、ネットワーク的距離が近いという判断である。さらに、センタＳＢは、Ｓ１１１およびＳ１１２で測定したロケーション情報を管理テーブル２４に格納する（Ｓ１１３）。

ここで、センタＳＸは、リソース状態の変化を検知する（Ｓ１２１）。リソース状態の変化は、例えば、リソースの故障やリソース使用状況の変化（他センタへの貸し出しなど）などである。そして、センタＳＸは、センタＳＢに、検知したリソース状態の変更を通知する（Ｓ１２２）。さらに、センタＳＢは、受信したリソース情報をテーブル（管理テーブル２４、詳細テーブル２６）に登録する（Ｓ１２３）。

図１０は、リソースの一時不足に対処する処理を示すフローチャートである。図１０の動作は、図９の動作の後に行われる。

まず、センタＳＢは、ホスティングとして既に提供しているリソースの一時不足を検知し、その要因となるボトルネックを特定する（Ｓ２０１）。要因は、例えば、リソースの障害や一時的な混雑によるＣＰＵの高負荷などであり、ボトルネックは、例えばＷｅｂサーバのみが混んでいる事象である。

なお、トランザクションの数は、時間とともに変化するのが一般的であり、ボトルネックは絶えず起こりうる。しかし、程度の小さいボトルネックまで全て対処すると、コストがかかってしまう。そこで、発生したボトルネックのうち、対処するボトルネックを選別する方法として、リソースを追加しなければ業務継続は不可と判断する程度の所定の閾値と発生したボトルネックとを比較することとしてもよい。この所定の閾値は、過去の統計データをもとに算出してもよい。

センタＳＢは、ボトルネックの特性に従って、ボトルネックを解消するリソースを自センタ内で検索し、発見できたら、他センタにリソースの貸し出しを要求する代わりに、自センタのリソースを割り当てる。一方、自センタ内に割り当てられるリソースがないときには、センタＳＢは、ボトルネックを解消するリソースを貸し出せるセンタを検索する（Ｓ２０２）。

なお、センタの検索処理（Ｓ２０２）は、後記する図１１において、詳細に説明する。その概要として、センタＳＢは、Ｓ１０１の契約に基づいて他センタの公開されているリソース情報を取得する。そして、センタＳＢは、Ｓ２０１のリソースの一時不足による業務のボトルネックと、取得したリソース情報を比較し、ボトルネックの解消に一番最適なセンタを選択する。

そして、センタＳＢは、Ｓ２０２で検索したセンタＳＸに、リソース貸し出しを要求する（Ｓ２０３）。ここで、リソースを取得しに行った段階でリソースがない状況もありえる。よって、センタＳＢは、Ｓ２０２で比較した時点で優先度を決めて、リソースをとりに行くセンタリスト２２を作成しておく。センタＳＢは、リソース情報の変更（Ｓ１２２）により逐次センタリスト２２におけるセンタ間の優先度を書き換え、最適なリソース選択ができる可能性を高めておく。

さらに、センタＳＸは、センタＳＢに、リソース貸し出しの結果を通知する（Ｓ２０４）。リソース貸し出しの結果は、貸し出し了解または貸し出し却下がある。貸し出し却下のときには、リソースをとりに行くセンタリスト２２の次候補のセンタに、リソース貸し出しを要求する（Ｓ２０３）。

このように、リソースの不足（Ｓ２０１）に連動してオンラインでリソースの消費賃貸契約を行う（Ｓ２０２、Ｓ２０３）ことにより、人手であいているリソースの情報を収集し、紙面でリソースの消費賃貸契約を行う作業に比べ、迅速なリソース不足の解消が実現できる。

そして、センタＳＢは、センタＳＸに、貸し出し了解により貸し出されたリソースに業務アプリの配備を要求する（Ｓ２０５）。さらに、センタＳＸは、センタＳＢからの配備要求を受け付ける（Ｓ２０６）。そして、センタＳＸは、業務アプリの配備を実施する（Ｓ２０７）。さらに、センタＳＸは、センタＳＢに配備完了を通知する（Ｓ２０８）。

ここで、センタＳＢは、業務アプリの配備（Ｓ２０７）に伴って、ネットワークの設定処理（ＦＷの設定、ＮＡＴの設定など）を行う。ネットワークの設定処理は、業務アプリを配備するための設定に加え、配備された業務アプリを、ユーザ端末に使用させるための設定も含む。

図１１は、リソースを要求するセンタを検索する処理（図１０のＳ２０２）を示すフローチャートである。

まず、センタＳＢは、Ｓ１０１で契約済のセンタに関する情報が格納されている管理テーブル２４について、全エントリをチェックする（Ｓ３０１）。次に、センタＳＢは、Ｓ２０１のボトルネックに対して必要になった用途に合う空き台数を満たすエントリを抜き出し、センタリスト２２を作成する（Ｓ３０２）。

そして、センタＳＢは、詳細テーブル２６から、センタリスト２２の全センタの詳細情報を参照する（Ｓ３０３）。さらに、センタＳＢは、詳細情報から利用可能なリソースを有していないセンタをセンタリスト２２から除外する（Ｓ３０４）。利用可能なリソースは、例えば、借りたい期間に空いているリソース、要求スペックを満たしているリソースである。

そして、センタＳＢは、センタリスト２２の全エントリについて詳細テーブル２６のレンタル価格を参照して、センタごとのコストを計算する（Ｓ３０５）。さらに、センタＳＢは、ロケーション値の小さい順、コスト値の小さい順にセンタリスト２２をソートする（Ｓ３０６）。なお、ロケーション値の小さい順にセンタをソートして、ロケーション値が同値のときにコスト値の小さい順にセンタをソートしてもよい。一方、コスト値の小さい順にセンタをソートして、コスト値が同値のときにロケーション値の小さい順にセンタをソートしてもよい。

なお、ロケーション値の小さいセンタからリソースをレンタルすることにより、低遅延でホスティングを提供できることとなり、アクセスするユーザ端末にとって、利点となる。一方、コスト値の小さいセンタからリソースをレンタルすることにより、低コストでホスティングの機材を調達できることとなり、センタにとって、利点となる。

そして、センタＳＢは、リソースが確保できるまで、センタリスト内のソート順で上位のセンタから順に、リソースを要求する（Ｓ３０７）。なお、ある一定以上のコストになる場合は、リソースのレンタルをあきらめることとしてもよい。

以上説明した本実施形態により、契約に基づいて選択したセンタから柔軟に貸し出しを受けることで、センタにとってホスティングをしてる業務のサービスレベルの維持が可能となる。さらに、リソースを提供してくれる契約センタは複数あることで、最適なリソースを貸してもらえる機会が増える。なお、リソース不足は、基本的には一時的なものであるが、将来にわたって不足すると考えられる場合は、Ｓ３０７においてリソースを購入してもよい。

以上説明した本発明は、以下のようにその趣旨を逸脱しない範囲で広く変形実施することができる。

例えば、センタリスト２２の作成（Ｓ３０２）において、原則は、必要なリソースを１箇所のセンタからレンタルする集中型とした。これは、リソースを要求する手間を１回に簡略化するためである。しかし、必要なリソースが複数存在するときには、各リソースを複数箇所のセンタからレンタルする分散型としてもよい。これにより、各リソースを最も低コストでレンタルすることができる。

本発明の一実施形態に関するリソースの仮想化を示す説明図である。 本発明の一実施形態に関するリソースの管理を示す説明図である。 本発明の一実施形態に関するリソース賃借システムを示す構成図である。 本発明の一実施形態に関するリソースの配備を示す説明図である。 本発明の一実施形態に関する業務システムを示す構成図である。 本発明の一実施形態に関する業務システムを示す構成図である。 本発明の一実施形態に関する業務システムを示す構成図である。 本発明の一実施形態に関するリソースを管理する記憶手段を示す構成図である。 本発明の一実施形態に関するリソースを管理する処理を示すフローチャートである。 本発明の一実施形態に関するリソースの一時不足に対処する処理を示すフローチャートである。 本発明の一実施形態に関するリソースを要求するセンタを検索する処理を示すフローチャートである。

符号の説明

ＳＢ，ＳＸ センタ
１０Ｂ，１０Ｘ 運用制御部
１２Ｂ，１２Ｘ 業務システム
１４Ｂ，１４Ｘ ＦＷ／ＮＡＴ
１６Ｂ ユーザ側ＦＷ／ＮＡＴ
２０ 記憶手段
２２ センタリスト
２４ 管理テーブル
２６ 詳細テーブル

Claims (11)

1. 貸側センタ装置から借側センタ装置に計算機のリソースを貸し出すリソース貸借方法であって、
   前記借側センタ装置が、
   処理の要求元から順に、グローバルロードバランサ、ロードバランサ、Ｗｅｂサーバ、ＡＰサーバ、および、ＤＢサーバが接続されて構成される業務システムを有し、
   貸し出す対象のリソースに関するリソース情報を前記貸側センタ装置から受信して管理テーブルに登録する手順と、
   前記借側センタ装置のリソース不足を検知してボトルネックを前記Ｗｅｂサーバとして特定する手順と、
   ボトルネックを解消するための前記ロードバランサ、および、前記Ｗｅｂサーバを含むリソースを、前記管理テーブルから検索し、検索したリソースを有する前記貸側センタ装置のセンタリストを作成する手順と、
   前記センタリストの前記貸側センタ装置に、リソースの貸し出しを要求する手順と、
   前記グローバルロードバランサと要求により貸し出されたリソースである前記ロードバランサとを接続するとともに、前記ＡＰサーバと要求により貸し出されたリソースである前記Ｗｅｂサーバとを接続する処理を含む、要求により貸し出されたリソースにアプリケーションをデプロイする旨の要求を前記貸側センタ装置に行う手順と、
   を実行することを特徴とするリソース貸借方法。
2. 貸側センタ装置から借側センタ装置に計算機のリソースを貸し出すリソース貸借方法であって、
   前記借側センタ装置が、
   処理の要求元から順に、グローバルロードバランサ、ロードバランサ、Ｗｅｂサーバ、ＡＰサーバ、および、ＤＢサーバが接続されて構成される業務システムを有し、
   貸し出す対象のリソースに関するリソース情報を前記貸側センタ装置から受信して管理テーブルに登録する手順と、
   前記借側センタ装置のリソース不足を検知してボトルネックを前記ＡＰサーバとして特定する手順と、
   ボトルネックを解消するための前記ロードバランサ、前記Ｗｅｂサーバ、および、前記ＡＰサーバを含むリソースを、前記管理テーブルから検索し、検索したリソースを有する前記貸側センタ装置のセンタリストを作成する手順と、
   前記センタリストの前記貸側センタ装置に、リソースの貸し出しを要求する手順と、
   前記グローバルロードバランサと要求により貸し出されたリソースである前記ロードバランサとを接続するとともに、前記ＤＢサーバと要求により貸し出されたリソースである前記ＡＰサーバとを接続する処理を含む、要求により貸し出されたリソースにアプリケーションをデプロイする旨の要求を前記貸側センタ装置に行う手順と、
   を実行することを特徴とするリソース貸借方法。
3. 貸側センタ装置から借側センタ装置に計算機のリソースを貸し出すリソース貸借方法であって、
   前記借側センタ装置が、
   処理の要求元から順に、グローバルロードバランサ、ロードバランサ、Ｗｅｂサーバ、ＡＰサーバ、および、ＤＢサーバが接続されて構成される業務システムを有し、
   貸し出す対象のリソースに関するリソース情報を前記貸側センタ装置から受信して管理テーブルに登録する手順と、
   前記借側センタ装置のリソース不足を検知してボトルネックを前記ＤＢサーバとして特定する手順と、
   ボトルネックを解消するための前記ロードバランサ、前記Ｗｅｂサーバ、前記ＡＰサーバ、および、前記ＤＢサーバを含むリソースを、前記管理テーブルから検索し、検索したリソースを有する前記貸側センタ装置のセンタリストを作成する手順と、
   前記センタリストの前記貸側センタ装置に、リソースの貸し出しを要求する手順と、
   前記グローバルロードバランサと要求により貸し出されたリソースである前記ロードバランサとを接続するとともに、前記業務システムの前記ＤＢサーバと要求により貸し出されたリソースである前記ＤＢサーバとの間でレプリケーションを行う処理を含む、要求により貸し出されたリソースにアプリケーションをデプロイする旨の要求を前記貸側センタ装置に行う手順と、
   を実行することを特徴とするリソース貸借方法。
4. 前記リソース情報はコストを含み、前記センタリストを作成する手順は、コストが小さい候補を有するセンタ装置順に作成し、前記リソースの貸し出しを要求する手順は、前記センタリストの順に貸し出しを要求することを特徴とする請求項１ないし請求項３のいずれか１項に記載のリソース貸借方法。
5. 前記借側センタ装置および前記貸側センタ装置は、互いの通信に関する通信遅延を測定し、前記センタリストを作成する手順は、通信遅延が小さいセンタ装置順に作成し、前記リソースの貸し出しを要求する手順は、前記センタリストの順に貸し出しを要求することを特徴とする請求項１ないし請求項３のいずれか１項に記載のリソース貸借方法。
6. 前記アプリケーションをデプロイする旨の要求には、前記貸側センタ装置および前記借側センタ装置のファイアウォールを設定する要求を含めることを特徴とする請求項１ないし請求項５のいずれか１項に記載のリソース貸借方法。
7. 前記アプリケーションをデプロイする旨の要求には、前記貸側センタ装置および前記借側センタ装置のＮＡＴを設定する要求を含めることを特徴とする請求項１ないし請求項５のいずれか１項に記載のリソース貸借方法。
8. 貸側センタ装置から借側センタ装置に計算機のリソースを貸し出すリソース貸借システムであって、
   前記借側センタ装置は、処理の要求元から順に、グローバルロードバランサ、ロードバランサ、Ｗｅｂサーバ、ＡＰサーバ、および、ＤＢサーバが接続されて構成される業務システムを有し、
   前記貸側センタ装置は、
   貸し出す対象のリソースに関するリソース情報を前記借側センタ装置に送信し、
   前記リソース情報のリソースの貸し出しの要求を前記借側センタ装置から受け付け、リソースの貸し出す構成を有し、
   前記借側センタ装置は、
   前記貸側センタ装置から受信した、貸し出す対象のリソースに関する前記リソース情報を登録する管理テーブルと、
   前記借側センタ装置のリソース不足を検知してボトルネックを前記Ｗｅｂサーバとして特定し、
   ボトルネックを解消するための前記ロードバランサ、および、前記Ｗｅｂサーバを含むリソースを、前記管理テーブルから検索し、検索したリソースを有する前記貸側センタ装置のセンタリストを作成し、
   前記センタリストの前記貸側センタ装置に、リソースの貸し出しを要求し、
   前記グローバルロードバランサと要求により貸し出されたリソースである前記ロードバランサとを接続するとともに、前記ＡＰサーバと要求により貸し出されたリソースである前記Ｗｅｂサーバとを接続する処理を含む、要求により貸し出されたリソースにアプリケーションをデプロイする旨の要求を前記貸側センタ装置に行う運用制御部を有すること
   を特徴とするリソース貸借システム。
9. 貸側センタ装置から借側センタ装置に計算機のリソースを貸し出すリソース貸借システムであって、
   前記借側センタ装置は、処理の要求元から順に、グローバルロードバランサ、ロードバランサ、Ｗｅｂサーバ、ＡＰサーバ、および、ＤＢサーバが接続されて構成される業務システムを有し、
   前記貸側センタ装置は、
   貸し出す対象のリソースに関するリソース情報を前記借側センタ装置に送信し、
   前記リソース情報のリソースの貸し出しの要求を前記借側センタ装置から受け付け、リソースの貸し出す構成を有し、
   前記借側センタ装置は、
   前記貸側センタ装置から受信した、貸し出す対象のリソースに関する前記リソース情報を登録する管理テーブルと、
   前記借側センタ装置のリソース不足を検知してボトルネックを前記ＡＰサーバとして特定し、
   ボトルネックを解消するための前記ロードバランサ、前記Ｗｅｂサーバ、および、前記ＡＰサーバを含むリソースを、前記管理テーブルから検索し、検索したリソースを有する前記貸側センタ装置のセンタリストを作成し、
   前記センタリストの前記貸側センタ装置に、リソースの貸し出しを要求し、
   前記グローバルロードバランサと要求により貸し出されたリソースである前記ロードバランサとを接続するとともに、前記ＤＢサーバと要求により貸し出されたリソースである前記ＡＰサーバとを接続する処理を含む、要求により貸し出されたリソースにアプリケーションをデプロイする旨の要求を前記貸側センタ装置に行う運用制御部を有すること
   を特徴とするリソース貸借システム。
10. 貸側センタ装置から借側センタ装置に計算機のリソースを貸し出すリソース貸借システムであって、
    前記借側センタ装置は、処理の要求元から順に、グローバルロードバランサ、ロードバランサ、Ｗｅｂサーバ、ＡＰサーバ、および、ＤＢサーバが接続されて構成される業務システムを有し、
    前記貸側センタ装置は、
    貸し出す対象のリソースに関するリソース情報を前記借側センタ装置に送信し、
    前記リソース情報のリソースの貸し出しの要求を前記借側センタ装置から受け付け、リソースの貸し出す構成を有し、
    前記借側センタ装置は、
    前記貸側センタ装置から受信した、貸し出す対象のリソースに関する前記リソース情報を登録する管理テーブルと、
    前記借側センタ装置のリソース不足を検知してボトルネックを前記ＤＢサーバとして特定し、
    ボトルネックを解消するための前記ロードバランサ、前記Ｗｅｂサーバ、前記ＡＰサーバ、および、前記ＤＢサーバを含むリソースを、前記管理テーブルから検索し、検索したリソースを有する前記貸側センタ装置のセンタリストを作成し、
    前記センタリストの前記貸側センタ装置に、リソースの貸し出しを要求し、
    前記グローバルロードバランサと要求により貸し出されたリソースである前記ロードバランサとを接続するとともに、前記業務システムの前記ＤＢサーバと要求により貸し出されたリソースである前記ＤＢサーバとの間でレプリケーションを行う処理を含む、要求により貸し出されたリソースにアプリケーションをデプロイする旨の要求を前記貸側センタ装置に行う運用制御部を有すること
    を特徴とするリソース貸借システム。
11. 前記リソース情報はコストを含み、前記センタリストを作成するときは、コストが小さい候補を有するセンタ装置順に作成し、リソースの貸し出しを要求するときは、前記センタリストの順に貸し出しを要求し、
    前記借側センタ装置および前記貸側センタ装置は、互いの通信に関する通信遅延を測定し、前記センタリストを作成するときは、通信遅延が小さいセンタ装置順に作成し、リソースの貸し出しを要求するときは、前記センタリストの順に貸し出しを要求すること
    を特徴とする請求項８ないし請求項１０のいずれか１項に記載のリソース貸借システム。

Images