JP2013218449A - クラウドコンピューティングシステム - Google Patents

Abstract

【課題】業務システムの中で，クラウドコンピューティングシステム上の仮想サーバを待機サーバとして利用する場合，クラウドコンピューティングシステム側では使用予測ができない。
【解決手段】クラウドコンピューティングシステムへのユーザからのリクエストに基づき，待機サーバがリクエストを処理可能な状態かどうかを判断し，処理可能な場合はリクエストを待機サーバに送信することでユーザからのリクエストに応じるとともに，待機サーバがリクエストを処理可能な状態でない場合には，リクエストを一時的に保持すると共に，新しい待機サーバを起動させ，起動が完了したのちに保持していたリクエストを送信するリクエスト処理装置を設けた。
【選択図】 図１

Description

本発明は，物理サーバ上に仮想サーバを設けたクラウドコンピューティングシステムに関する。

近年，所有している情報システムの負荷増大や，障害により情報システム内の装置が利用できなくなった場合に備え，クラウドコンピューティングシステムを利用するケースが増加している。

負荷増大や障害対応のためにクラウドコンピューティングシステムを利用しない場合，特許文献１では，待機サーバを稼動サーバへ切り替える指標となる閾値にリソース使用量が達するまでの予測時間を計算して，計算した予測時間内に生成可能な待機サーバの待機方式を選択し，その待機方式の待機サーバを生成することが開示されている。

特開2011-243162号公報

特許文献１では予測により待機サーバを生成するが，待機サーバを全てクラウドコンピューティングシステムで賄うことにより，待機サーバの所有は不要となる。

しかし実際の業務システムの中で，クラウドコンピューティングシステム上の仮想サーバを待機サーバとして利用する場合，クラウドコンピューティングシステム側では使用予測ができない。そのため、，クラウドコンピューティングシステム上の待機サーバは，常に利用可能な状態である必要がある。

これは，結局，クラウドコンピューティングシステムにおいて，ITリソース（CPUやメモリ，ディスクなど）を確保することになり，クラウドコンピューティングシステムを含めた全体では，ITリソース量は全く減らないことになる。もちろん，消費電力も全体としては全く減らないことになる。

そこで，本発明は，必要に応じて，ITリソースを待機サーバに割当てるクラウドコンピューティングシステムを提供することを目的とする。

本発明では，クラウドコンピューティングシステムへのユーザからのリクエストに基づき，待機サーバがリクエストを処理可能な状態かどうかを判断し，処理可能な場合はリクエストを待機サーバに送信することでユーザからのリクエストに応じるとともに，待機サーバがリクエストを処理可能な状態でない場合には，リクエストを一時的に保持すると共に，新しい待機サーバを起動させ，起動が完了したのちに保持していたリクエストを送信するリクエスト処理装置を設けた。

上記リクエスト処理装置により，クラウドコンピューティングシステムは，待機サーバを常に起動しておく必要がなくなり，ITリソース及び消費電力を低減できる。

クラウドコンピューティングシステム１０３の構成図である。 ストレージ１５０で保管されるデータの詳細図である。 リクエスト処理ソフトウェア１２５と，リクエスト管理ソフトウェア１４５と，クラウド管理ソフトウェア１３５との間で通信されるデータを詳細図である。 ユーザからのリクエストに基づく，リクエスト処理ソフトウェア１２５と，リクエスト管理ソフトウェア１４５と，クラウド管理ソフトウェア１３５のリクエスト処理手順の詳細を表すフローチャートである。 時間経過に基づく，リクエスト処理ソフトウェア１２５と，リクエスト管理ソフトウェア１４５と，クラウド管理ソフトウェア１３５の仮想サーバ割り当て解除手順の詳細を表すフローチャートである。

図１は本発明を適用したクラウドコンピューティングシステム１０３の構成を表す実施例である。データセンタ１００は，複数の物理サーバと，ルータ、ストレージを具備する。複数の物理サーバ上では，仮想サーバが稼働している。

ユーザ１９０は業務システム１１０から，データセンタ１００に構築されたクラウドコンピューティングシステム１０３が提供する仮想サーバを利用する。

業務システム１１０は，ジョブ管理装置１１２により，実行するジョブが管理されている。ジョブ管理装置１１２は，管理しているジョブを複数のジョブ実行サーバ（１１６，１１８）で処理させるとともに，処理の実行状態を管理し，処理が失敗した場合は再度処理を行わせたり，処理が規定時間内に終わる見込みがない場合には，他のサーバに処理を振り分けるなどの処理を実施する。こうした処理の分散は，負荷分散装置１１３が実施してもよい。負荷分散装置１１３は，ジョブ管理装置１１２からリクエストを受け取ると，負荷の状態に合わせて，ジョブ実行サーバ（１１６，１１８）にリクエストを送信する。通常は、最もCPU使用率が少ないジョブ実行サーバや、最も応答が早いジョブ実行サーバが選択されリクエストが送信される。

負荷分散装置１１３は，各ジョブ実行サーバの負荷測定機能１１４と，生死監視機能１１５を持つ。負荷測定機能１１４は，ジョブ実行サーバに負荷測定用のリクエストを送信し，CPUの使用率やレスポンスまでにかかった時間などを考慮し，ジョブ実行サーバがリクエストを処理するのに適しているかを判断する機能などが該当する。この機能を用いることで負荷分散装置１１３は，その時点で最もCPUの使用率やレスポンスが早いジョブ実行サーバを選択することができるので、結果としてジョブ実行サーバ間の負荷を平準化し，処理を効率化できる。また生死監視機能１１５は，ジョブ実行サーバにpingなどの生死監視用のリクエストを送信し，レスポンスの有無や，期待した応答かどうかを判断する機能などが該当する。この機能を用いることで，負荷分散装置１１３は，ジョブ実行サーバがリクエストを処理可能な状態にあるかどうかを判断し，レスポンスがないなどの理由により、正常に処理ができないと判断した場合には，処理を他のジョブ実行サーバに切り替えることで，可用性を向上することができる。

業務システム１１０は，ジョブ実行サーバの負荷増大や障害発生時においても性能を維持し続けるために，クラウドコンピューティングシステム１０３内の仮想サーバを待機サーバとして利用する。

データセンタ１００は，業務システム１１０とネットワーク１９５で接続される。

データセンタ１００は，仮想サーバと業務システム１１０を接続するネットワーク１９５からの通信を適切な仮想サーバに受け渡すルータ１０５を持つ。ここでルータ１０５の機能として，外部との不正な接続を遮断するファイアウオール，外部からの不正な通信を監視及びフィルタリングするIntrusion Detection SystemやIntrusion Prevention System，データセンタ１００外部との通信に用いるIPアドレスとデータセンタ１００内部での通信に用いるIPアドレスを変換するNetwork Address Translation，ルータ１０５を複数台のルータとして論理的に動作させるVirtual Routing Forwarding，ネットワークを論理的に分割するVLANの機能を有していてもよく，またこうした機能を持つ装置と接続されていてもよい。

ルータ１０５は，アクセス元のIPアドレスに応じて接続先のネットワークを選択し，またアクセス先のIPアドレスに基づき，データを送信する装置を選択する。ルータ１０５は，仮想サーバ１６２，仮想サーバ１７２，仮想サーバ１７４，物理サーバ１６０，物理サーバ１７０，ハイパバイザ１６８，ハイパバイザ１７８などに接続されており，基本的な処理として業務システム１１０からのリクエストをこれらの仮想サーバに転送する役割を持つ。仮想サーバ１６２は物理サーバ１６０上の論理的に分割されたサーバであり，ハイパバイザ１６８上で動作するものである。仮想サーバ１７２および仮想サーバ１７４は物理サーバ１７０上の論理的に分割されたサーバであり，ハイパバイザ１７８上で動作する。ハイパバイザ１６８および１７８は，物理サーバのCPU，メモリ，および物理サーバ１６０および１７０に接続されたネットワークの回線容量，物理サーバ１６０および１７０に接続されたストレージ１８０のデータ領域などを論理的に分割し，複数のOSを物理サーバにインストールして利用する。

ルータ１０５は，リクエスト処理装置１２０，リクエスト管理装置１４０に接続される。

リクエスト処理装置１２０は，業務システム１１０からリクエストを受信した場合に，リクエストの本来の送信先の仮想サーバがリクエストを処理可能な状態かどうかを判断し，リクエストが処理可能な場合には，その仮想サーバにリクエストを送信する処理を行う。またリクエストを処理可能でない場合には，リクエストを処理する仮想サーバの起動要求をリクエスト管理装置に送信し，仮想サーバが起動した後に，その仮想サーバにリクエストを送信する処理を行う。リクエスト処理装置１２０は，これらの処理を行うリクエスト処理ソフトウェア１２５を含む。ただし，リクエスト処理ソフトウェア１２５の実装は，ソフトウェアに加え，ハードウェアや，ハードウェアとソフトウェアを含むものであってもよい。

リクエスト管理装置１４０は，リクエスト処理装置１２０，クラウド管理装置１３０に接続される。リクエスト管理装置１４０は，リクエスト処理装置１２０より仮想サーバの起動要求を受け取ると，現在の仮想サーバの状態に応じた処理の要求をクラウド管理装置１３０に送信する。例えば仮想サーバが起動していない場合には，起動要求と、起動に必要なパラメータ、起動の前後に実施する処理を示す情報をクラウド管理装置１３０に送信する処理を行う。リクエスト管理装置１４０は，これらの処理を行うリクエスト管理ソフトウェア１４５を含む。ただし，リクエスト管理ソフトウェア１４５の実装は，ソフトウェアに加え，ハードウェアや，ハードウェアとソフトウェアを含むものであってもよい。

クラウド管理装置１３０は，リクエスト管理装置１４０、仮想サーバ１６２，仮想サーバ１７２，仮想サーバ１７４，物理サーバ１６０，物理サーバ１７０，ハイパバイザ１６８および１７８に接続される。クラウド管理装置１３０は，リクエスト管理装置１４０からの仮想サーバの起動または停止要求に基づき，仮想サーバの起動または停止する処理と、これらの処理の前後で実施するように指示された処理を行う。クラウド管理装置１３０は，これらの処理を行うクラウド管理ソフトウェア１３５を含む。ただし，リクエスト管理ソフトウェア１３５の実装は，ソフトウェアに加え，ハードウェアや，ハードウェアとソフトウェアを含むものであってもよい。

ここでリクエスト処理装置１２５，リクエスト管理装置１４５，クラウド管理装置１３５から起動処理または停止処理を行う対象は，仮想サーバだけでなく，物理サーバであってもよく，複数の仮想サーバ，複数の物理サーバであってもよい。

リクエスト処理装置１２０，リクエスト管理装置１４０，クラウド管理装置１３０の実装は，専用装置，物理サーバ，仮想サーバであってもよい。またこれらの装置は，一台の装置であってもよく，機能毎に分割された複数の装置であってもよい，またルータ１０５と統合された装置であってもよい。本発明の特徴は，これらの装置内の処理部にあるため，ハードウェアやソフトウェアの構成によらない。

クラウド管理装置１３０から物理サーバ１６０への接続は，ルータ１０５を経由する構成であってもよい。

ストレージ１５０は，クラウド管理装置１３０およびリクエスト管理装置１４０に接続される。ストレージ１５０には，仮想サーバの起動や停止に必要な情報が格納される。ストレージ１５０は，仮想サーバ管理データ１５２，物理サーバ管理データ１５４，スクリプト管理データ１５６，マシンイメージ１５８を含む。

図2は，仮想サーバ管理データ１５２，物理サーバ管理データ１５４，スクリプト管理データ１５６，マシンイメージ１５８の詳細を表している。
仮想サーバ管理データ１５２は，仮想サーバ毎に1つずつ定義されるデータであり，仮想サーバと物理サーバの対応や，起動および停止の際に実行される情報などを含むデータである。仮想サーバ管理データ１５２は，仮想サーバ名２１０，IPアドレス２１２，物理サーバ名２１４，設定情報２１６，性能情報２１８，スクリプト管理ID２５０，停止時刻２５２を含む。
仮想サーバ名２１０は，仮想サーバ毎にユニークな識別子である。IPアドレス２１２は，仮想サーバに割り当てられるIPアドレスである。

物理サーバ名２１４は，現在仮想サーバ名２１０により識別される仮想サーバが存在する物理サーバのユニークな識別子である。

設定情報２１６は，仮想サーバが属するネットワークのVLAN IDや，利用中のOS，ストレージシステム上のディスクへの接続のためのWorld Wide Nameなどの情報を含む。

性能情報２１８は，仮想サーバの性能情報で，CPUやメモリ，ネットワーク帯域，ディスクIO帯域，ディスク容量，起動状態などの情報を含む。

スクリプト管理ID２５０は，仮想サーバの起動や停止の前後で実行されるスクリプト毎にユニークな識別子である。仮想サーバ管理データ１５２は複数のスクリプト管理ID２５０を含んでもよい。その時，スクリプトID毎に個別の情報を設定情報２１６に含めてもよい。ただし，仮想サーバ管理データ１５２は，仮想サーバがクラスタとして組まれている場合など，仮想サーバのグループに対して用意されていても良い。この時，仮想サーバ名２１０は，仮想サーバ単体とは異なる情報が付与された仮想サーバ群毎にユニークな識別子であってもよい。

停止時刻２５２は，一定時間経過後にサーバを停止させるための時間である。停止時刻２５２は，正常に処理が終了した後のタイムアウト時間と，処理未完了時のタイムアウト時間の両方を含む。また停止時刻２５２は，夜間や日中，または特定の日や月だけ稼働させたい場合の停止時刻であってもよい。

物理サーバ管理データ１５４は，物理サーバ毎に1つずつ定義されるデータで，物理サーバの能力などに関わる情報などを含むデータである。物理サーバ管理データ１５４は，物理サーバ名２２０，IPアドレス２２２，設定情報２２４，性能情報２２６を含む。

物理サーバ名２２０は，物理サーバ毎にユニークな識別子である。
IPアドレス２２２は，物理サーバに割り当てられるIPアドレスである。
設定情報２２４は，物理サーバ上のハイパバイザの種類やバージョン，IPアドレスなどの情報や接続されているストレージシステムとの接続情報などを含む。

性能情報２２６は，物理サーバの性能情報で、CPUやメモリ，ネットワーク帯域，ディスクIO帯域，ディスク容量，起動状態などの情報を含む。

スクリプト管理データ１５６は，スクリプト毎に定義されるデータで，仮想サーバの起動時や停止時に実行するスクリプトに関する情報を含むデータである。スクリプト管理データ１５６は，スクリプト管理ID２３０，設定情報２３２，スクリプト２３４を含む。

スクリプト管理ID２３０は，スクリプト毎にユニークな識別子である。
設定情報２３２は，スクリプトの対象となる仮想サーバやユーザ１９０の識別情報，前提条件となる情報を含む。
スクリプト２３４は，起動時または停止時の前後に実行するスクリプトの本体である。

マシンイメージ１５８は，仮想サーバのシステムディスクのイメージデータである。マシンイメージ１５８は，マシンイメージID２４０，設定情報２４２，イメージデータ２４４を含む。

マシンイメージID２４０はマシンイメージ毎にユニークな識別子である。

設定情報２４２は，マシンイメージが展開可能なハイパバイザの種類やバージョン，マシンイメージの作成日時や管理者や利用範囲に関する情報，アクセス権などを含む。

イメージデータ２４４は仮想サーバのイメージデータの本体である。

ストレージ１５０内のデータは，リクエスト管理装置１４０，クラウド管理装置１３０内にあってもよい。リクエスト管理装置１４０やクラウド管理装置１３０は，自分が管理しないデータが必要な場合，他の管理装置にWeb APIなどを用いて要求し，取得してもよい。

業務システム１１０のジョブ管理装置１１２は，負荷分散装置１１３にリクエストを送信する。負荷分散装置１１３は，負荷増大や障害発生の理由により，現行のジョブ実行サーバのみでは処理しきれないと判断した場合に，受信したリクエストを業務システム１１０内のジョブ実行サーバに送る代わりに、ネットワーク１９５を利用してデータセンタ１００に送信する。

業務システム１１０からネットワーク１９５を通じてデータセンタ１００に送信されたリクエストは，ルータ１０５で本来のリクエストの送信先である仮想サーバに送られる代わりに、リクエスト処理装置１２０に送られる。リスクエスト処理装置１２０は，ルータ１０５からリクエストを受け取ると、本来のリクエストの送信先の仮想サーバがリクエストを処理可能な状態かどうかを判断する。リクエストの送信先の仮想サーバが，リクエストを処理可能な場合，リクエスト処理装置１２０からルータ１０５経由で本来のリクエスト送信先の仮想サーバにリクエストを送る。

負荷分散装置１１３は，負荷測定機能１１４と，生死監視機能１１５を持ち，ジョブ管理サーバ１１６や１１８の状態を測定または監視することで、ジョブ実行サーバの負荷状態や生死状態を把握する。負荷分散装置１１３は，業務システム１１０内のジョブ実行サーバだけでなく、データセンタ１００内の仮想サーバに対しても，負荷状態や生死状態の測定や監視を行ってもよい。その場合、負荷分散装置１１３は，データセンタ１００の仮想サーバに対し、pingやTCP SYNスキャンのようなリクエストを送信する。リクエスト処理装置１２０は，これらのリクエストを受信した場合，実際の仮想サーバの状態に関わらず、正常に動作していることを示す応答を行う。これにより負荷分散装置１１３は、データセンタ１００の仮想サーバがリクエストを処理可能な状態と判断する。

負荷分散装置１１３は負荷測定機能１１４および生死監視機能１１５により，業務システム１１０内でジョブが処理しきれないと判断した場合，ジョブ管理装置１１２から受信したリクエストをデータセンタ１００に送信し，データセンタ１００に処理を行わせることができる。

業務システム１１０は，データセンタ１００相当の設備を有してもよい。このとき，負荷分散装置１１３は，ジョブ管理装置１１２から受信したリクエストを，業務システム１１０外のデータセンタ１００に送信する代わりに，業務システム１１０内のデータセンタ１００相当の設備に送信してもよい。また，負荷分散装置１１３はデータセンタ１００と，業務システム１１０内のデータセンタ１００相当の設備の双方を利用してもよい。

図4は，データセンタ１００で業務システム１１０からのリクエストを受け取った際の，リクエスト処理ソフトウェア１２５，リクエスト管理ソフトウェア１４５，クラウド管理ソフトウェア１３５の処理の詳細である。データセンタ１００が業務システム１１０からネットワーク１９５経由でリクエストを受信すると，ルータ１０５からLANなどのネットワークを利用してリクエスト処理装置１２０に，リクエストを送る。リクエスト処理装置１２０内のリクエスト処理ソフトウェア１２５は，リクエスト処理装置１２０がリクエストを受信すると (４００)，受信リクエストをキューに保持する（４０２）。ここでキューとは，リクエスト処理装置１２０内のメモリ領域の一部を指す。

その後リクエスト処理ソフトウェア１２５は，キュー上の受信リクエストのパケットのヘッダを調べ，生死監視パケットかどうか判断する（４１８）。ここで，生死監視パケットとは，負荷分散装置１１３の負荷測定機能１１４または生死監視機能１１５により送信されてきた，対象の仮想サーバがネットワークの応答が可能な状態かどうかを調べるためのパケットである。受信リクエストが生死監視パケットである場合，リクエスト処理ソフトウェア１２５は，仮想サーバが正常に稼働中であることを示すレスポンスを業務システム１１０に対してを返す（４２２）。この時のレスポンスは，生死監視パケットICMPのエコー要求の場合は，応答用のICMPパケットを生成し，これにICMPエコー要求を送ってきた業務システム１１０内の装置のIPアドレスを送信先IPアドレスをIPヘッダに設定し，これにEthernet（登録商標）ヘッダを付与したものが該当する。リクエスト処理ソフトウェア１２５は，レスポンスをネットワーク経由でルータ１０５に送信した後，キュー内のリクエストを削除する。

受信リクエストが生死監視パケットでない場合，次は起動要求パケットであるかどうかを判断する（４２０）。ここで起動要求パケットは，仮想サーバを起動するためのパケットである。本発明では，仮想サーバが正常に稼働しているかどうかに関わらず受信したリクエストに対して処理を行い，結果を返すことを特徴としている。しかし仮想サーバが正常に稼働している場合と，正常に稼働していない場合とでは，処理完了までの時間が異なる。そこで予め業務システムが負荷の増大や障害の発生を予見した場合，業務システム１１０から起動要求パケットを送信して仮想サーバを起動しておくことで，実際のリクエストの発行時に，仮想サーバの準備完了まで待つことなく処理が可能になる。受信リクエストが起動要求パケットである場合，リクエスト処理ソフトウェア１２５は，pingや監視パケットを仮想サーバに送信し、正常に稼働中かを確認する（４２３）。正常に稼働中の場合，起動済みであることを示すレスポンスを業務システム１１０に送信する（４２５）。起動要求パケットは，業務システム１１０とリクエスト処理ソフトウェア１２５の双方で定められた形式であればよい。例えば，ICMPパケットのエコー要求を送信する際に，ICMPパケット中のコードに0xAAなどの通常では利用しないデータを格納するとともに，現在の時刻，業務システム１１０とリクエスト処理ソフトウェア１２５が保有する秘密のデータ，乱数，シーケンス番号，起動対象の仮想サーバ名またはIPアドレスなどを，業務システム１１０とリクエスト処理ソフトウェア１２５が保有する別の秘密のデータで暗号化し，ICMPパケットのデータとして送信する。リクエスト処理ソフトウェア１２５はこのパケットを受信した後に，復号し，現在の時刻と予め決められた時間差であるか確認し，秘密のデータが一致しているか確認する。一致している場合，パケット内に格納された仮想サーバ名の仮想サーバを起動することにしてもよい。こうした起動要求パケットの認証方式は上記の方式によらず，安全に起動する仮想サーバが指定できる方式であればよい。正常稼働していない場合，現状起動している仮想サーバを停止し，新しい仮想サーバを起動して処理を行わせる必要がある。そのため，リクエスト処理ソフトウェア１２５は，リクエスト管理装置１４０に，ネットワーク経由でデータ４６０を送信する（４２４）。データ４６０の詳細については後述する。

このときの仮想サーバの停止処理と起動処理は、同時に行ってもよい。その際、リクエスト管理装置１４０は、ルータ１０５から対象の仮想サーバへの接続を遮断し、新規に作成した仮想サーバに先のIPアドレスを割り当てて起動してもよい。ルータ１０５から切断された仮想サーバは、任意のタイミングで停止すればよい。

本書では、リクエスト処理ソフトウェア１２５、リクエスト管理ソフトウェア１４５、クラウド管理ソフトウェア１３５間でのデータの送受信として記載しているが、実際は、リクエスト処理装置１２０，リクエスト管理装置１４０，クラウド管理装置１３０間の通信として、LANなどのネットワーク経由で送信される。ただし、これらのソフトウェア（１２５、１４５、１３５）は同じ装置内で実行されていてもよい、その場合はソフトウェア間の通信は、それぞれのソフトウェアが管理するメモリ領域へのデータコピー処理や、データのアドレスの受け渡し処理となる。またこれらの装置（１２０、１４０、１３０）が同じ装置内にあり、I2Cなどの内部バスにより接続されていてもよい。いずれも場合も、正しく指定のソフトウェアにデータが送信できる方式であればよい。したがって以降の記載においては，特に断りがない限りソフトウェア間でのデータ送受信として記述することとするが、物理的および論理的な実装の違いにより本発明の効果が変化しないことは自明である。

手順４２０で受信リクエストが起動要求パケットでない場合，リクエスト送付先の仮想サーバの起動・生死確認を行う（４０６）。リクエスト送付先の仮想サーバが正常に稼働している場合，キューに格納していた業務システム１１０からのパケットを，送信先IPアドレスで指定された仮想サーバに送信し(４１４)，レスポンス待機状態に入る(４１６)。このときキューのデータに対して，送信済みであることを示すフラグを付与するか，送信済みパケットを管理するキューにデータを移動させる。データを送信した仮想サーバからレスポンスがあった場合，レスポンスを業務システム１１０に送信し，送信完了後キュー内のデータを削除する。

正常に稼働していない場合，リクエスト処理ソフトウェア１２５は，リクエスト管理ソフトウェア１４５に，データ４６０を送信する（４０８）。

図３のデータ４６０に，データ４６０の詳細を示す。データ４６０は，命令コード３０２と，IPアドレス３０４を含む。命令コード３０２は，仮想サーバの起動を指示するコードである。IPアドレス３０４は，リクエスト送付先の仮想サーバのIPアドレスである。ここでデータ４６０に含まれる情報はこのシステムに必要最低限の情報であり，その並び順やエンコード形式によらず，他の情報が追加されていてもよい。本書において特に断りがない限り，他のデータにおいても同様である。

リクエスト処理ソフトウェア１２５は，起動要求送信後，起動待機状態に入る（４１０）。ここで起動待機状態とは，リクエスト管理ソフトウェア１４５よりデータ４６６の受信を待機する処理を指す。この後，リクエスト処理ソフトウェア１２５は，リクエスト管理ソフトウェア１４５からデータ４６６を受信する（４１２）と，再度リクエスト送付先の仮想サーバが正常に稼働しているかを確認する（４０４）。

図3のデータ４６６に，データ４６６の詳細を示す。データ４６６は，IPアドレス３３２と，エラーコード３３４を含む。IPアドレス４６６は，データ４６０でリクエスト処理ソフトウェア１２５からリクエスト管理ソフトウェア１４５に送信したIPアドレスと同じものである。エラーコード３３４は，データ４６０に含まれる命令コード３０２の処理結果を通知するためのコードである。

手順４１２においてリクエスト処理ソフトウェア１２５は，仮想サーバの起動が失敗したなどのエラーを受け取った場合，起動要求を再びリクエスト管理ソフトウェアに送信してもよい。一回以上の起動失敗のエラーを受け取った際に，この後手順４２０を実行する代わりに，仮想サーバの起動失敗を示すエラーコードを業務システム１１０に送信してもよい。

次に図４におけるリクエスト管理ソフトウェア１４５の処理について説明する。リクエスト管理ソフトウェア１４５は，仮想サーバ起動要求４０８または４２４の処理の結果として，データ４６０を受け取る（４３０）と，データ４６０に含まれるIPアドレス３０４の仮想サーバが起動中かを確認する。起動中である場合，図５における異常終了指示５４０，待機状態５４２，停止通知受信５４４と同じ処理を行う。リクエスト管理ソフトウェア１４５は，クラウド管理ソフトウェア１３５から停止通知を受け取ると，仮想サーバ起動指示を行い(４３８)，データ４６２をクラウド管理ソフトウェア１３５に送信する。

図3のデータ４６２に，データ４６２の詳細を示す。データ４６２は，命令コード３１２と，IPアドレス３１４と，仮想サーバ名３１６と物理サーバ名３１８を含む。命令コードは仮想サーバの起動の指示と，起動方法を表す。ここで起動方法とは，CPU数やメモリ容量，接続するネットワークやディスク，マシンイメージの種類など，起動パラメータとなる情報を含んでいてもよい。IPアドレス３１４は，データ４６０で送信されたIPアドレス３０４に基づき決められたIPアドレスである。例えば，IPアドレス３０４がグローバルIPアドレスの場合，IPアドレス３１４は，IPアドレス３０４に対応付けられたローカルIPアドレスであってもよい。仮想サーバ名３１６は，仮想サーバ管理データ１５２におけるIPアドレス２１２と，IPアドレス３０４が一致したデータにおける仮想サーバ名である。物理サーバ名３１８は，仮想サーバ管理データ１５２において指定された物理サーバ名であってもよいし，他の物理サーバでの起動が行える場合には，起動可能な物理サーバ名であってもよい。

リクエスト管理ソフトウェア１４５は，仮想サーバ起動指示４３８後，起動待機状態に移る（４４０）。この後，リクエスト管理ソフトウェア１４５は，クラウド管理ソフトウェア１３５から，データ４６４を受信すると(４４２)，リクエスト処理ソフトウェア１２５にデータ４６６を送信する（４４４）。

図３のデータ４６４に，データ４６４の詳細を示す。データ４６４は，IPアドレス３２２と，エラーコード３２４を含む。IPアドレス３２２は，データ４６２でクラウド管理ソフトウェア１３５が受信したIPアドレスである。エラーコード３２４は，クラウド管理ソフトウェア１３５による仮想サーバ起動処理の結果を表すコードである。

リクエスト管理ソフトウェア１４５は手順４４２において起動が未完了であることを示すエラーコードを受け取った際に，再びクラウド管理ソフトウェア１３５に起動の指示を行ってもよい。この時，命令コード３１２内の起動パラメータを変更してもよいし，物理サーバ名３１８を変更してもよい。一回以上の任意の回数の処理の失敗をもって，手順４４４からエラーコード３３４として，リクエスト処理ソフトウェア１２５に送信してもよい。

次にクラウド管理ソフトウェア１３５の処理を説明する。クラウド管理ソフトウェア１３５はデータ４６２を受信する(４８０)と，仮想サーバ起動前処理を実施する（４８２）。仮想サーバ起動前処理は，仮想サーバを起動する前に実行する処理である。クラウド管理ソフトウェア１３５は，データ４６２を受信すると，データ４６２に含まれる命令コード３１２が起動前処理の実行を要求するコードかどうかを判別し，起動前処理の実行が要求されている場合，IPアドレス３１４をもとに，同じIPアドレスを持つ仮想サーバ管理データ１５２を選択する。次に，仮想サーバ管理データ１５２内の起動前処理用のスクリプト管理ID２５０を取り出す。その後，スクリプト管理ID２５０によって識別されるスクリプト管理データ１５６を検索し，そのスクリプトの内容を実行する。起動前処理としては，起動する際のマシンイメージのコピーやネットワークの設定，仮想サーバの作成などの処理が含まれる。命令コード３１２により起動前処理が指定されていない場合，処理の実行を省略してもよい。

起動前処理４８２実施後，クラウド管理ソフトウェア１３５は，仮想サーバを起動する（４８４）。起動後，クラウド管理ソフトウェア１３５は，仮想サーバ起動後処理を実施する（４８６）。仮想サーバ起動後処理は，仮想サーバを起動後に実行する処理である。クラウド管理ソフトウェア１３５は，データ４６２に含まれる命令コード３１２が起動後処理の実行を要求するコードかどうかを判別し，起動後処理の実行が要求されている場合，IPアドレス３１４をもとに，同じIPアドレスを持つ仮想サーバ管理データ１５２を選択する。次に，仮想サーバ管理データ１５２内の起動後処理用のスクリプト管理ID２５０を取り出す。その後，スクリプト管理ID２５０によって識別されるスクリプト管理データ１５６を検索し，そのスクリプトの内容を実行する。起動後処理としては，起動後の仮想マシンの設定や，DBサーバやActive Direcrtoryサーバへの接続処理，クラウド管理ソフトウェア１３５への登録処理などが含まれる。命令コード３１２により起動後処理が指定されていない場合，処理の実行を省略してもよい。

命令コード３１２は，起動前処理と起動後処理の指示を両方含んでいてもよい。例えば，命令コード中のある一バイトが0x01の時に起動前処理の実施を意味し，またある一バイトが0x02の時に起動後処理の実施を意味するものである場合，ある一バイトが0x03の時は，起動前処理と起動後処理の実施を意味すると判断してもよい。

クラウド管理ソフトウェア１３５は，仮想サーバ起動後処理終了後，仮想サーバ起動完了通知として，データ４６４をリクエスト管理ソフトウェア１４５に送信する。

このように，リクエスト処理ソフトウェア１２５，リクエスト管理ソフトウェア１４５，クラウド管理ソフトウェア１３５の処理により，業務システムからのリクエストに基づき，データセンタ１００内の仮想サーバが起動中かどうかに関わらず，また正常に稼働しているかどうかに関わらず，リクエストを処理することができる。

本実施例において，データセンタ１００で用意可能な仮想サーバを予め決めておき，用意した仮想サーバのIPアドレスを業務システム１１０内の負荷分散装置１１３に登録しておくことで，利用が可能になる。ただし，本実施例の応用として，リクエスト処理ソフトウェア１２５で負荷を平準化させるために，手順４０６のタイミングで業務システム１１０に接続されたデータセンタ１００内の仮想サーバからの応答を調べ，正常に稼働している場合は一番負荷の少ない仮想サーバに対してリクエストを送信してもよい。

このとき，リクエスト処理装置１２５は，既に起動中の仮想サーバなど，優先的に処理を行わせたい仮想サーバがある場合，その仮想サーバが選択されるように，応答時間を変更したり，応答内容を変更してもよい。負荷分散装置は，負荷分散先の仮想サーバが複数ある場合，アルゴリズムにより，最も早く応答を返したサーバにリクエストを送信する機能を持つ。負荷分散装置がこの機能を利用する場合，リクエスト処理装置１２５が応答時間を調整することで，負荷分散装置１１３に最も応答時間が短くなるように調整した仮想サーバにリクエストを送信させるようにすることができる。これにより，不要な仮想サーバを可能な限り起動させず，起動する仮想サーバ数を減らす効果がある。

また，負荷が大きく予め負荷分散装置１１３に登録していた仮想サーバでは足りない場合がある。例えばこれは、指定された仮想サーバは起動中であるが、既に処理負荷が高く、追加のリクエストを処理可能な状態にない場合が該当する。このときリクエスト処理ソフト１２５の手順４０６において仮想サーバが起動中である場合、手順４１４を実行する前に、その仮想サーバの負荷を調べる。負荷が予め定めた値と同じか小さく、追加の処理が可能な場合は手順４１４を実行する。負荷が予め定めた値よりも大きく、追加の処理が困難と推測される場合、リクエスト処理ソフトウェア１２５は、新しいIPアドレスを用意し、新しい仮想サーバの起動要求をリクエスト管理ソフトウェア１４５に送信する。この時のデータの形式は、データ４６０と同じで、新規に用意したIPアドレスに変更したものになる。このとき、業務システム１１０からは新しい仮想サーバのIPアドレスはわからないため、仮想サーバからレスポンスがあった場合、これをリクエスト処理ソフトウェア１２５でいったん受信し、送信元のIPアドレスをもとの仮想サーバのIPアドレスに変更した上で送信してもよい。このように処理を変更することで，業務システム１１０内の負荷分散装置１１３には一つのIPアドレスのみを登録しておくだけで済み，データセンタ１００内の仮想サーバの負荷分散を考慮しなくても済むという効果がある。

ただし，仮想サーバをデータセンタ１００内で自動で起動するシステムでは，負荷が下がった後に適切なタイミングで仮想サーバの割り当てを解除する機能がないと，割り当てたITリソースが解放されず，クラウドコンピューティングシステム全体の効率的な利用が図れない。

図５は，仮想サーバを停止する仕組みとして，時間経過により仮想サーバを停止する処理について説明する。この時の時間経過とは，レスポンスを返した後の時間経過と，レスポンスが未受信の場合の時間経過とを含む。

リクエスト処理ソフトウェア１２５は，仮想サーバがリクエストの処理終了後に新規のリクエストの受け付けがなく、停止時刻２５２に達した仮想サーバや，停止時刻２５２経過後も処理完了をしない仮想サーバに対し，仮想サーバの停止処理を行う。停止時刻２５２は，ユーザ１９０や業務システム１１０，ジョブ毎に定めてもよい。

本発明では仮想サーバ毎に停止時刻２５２を設定し，この時刻が経過した後に仮想サーバを停止させることで，クラウドコンピューティングシステムの効率的な利用や，消費電力の削減する効果が得られる。この仕組みは，先に述べた仮想サーバの自動起動と組み合わせることで，ユーザの業務システムに極力影響を与えずに，自動で仮想サーバの起動状態と停止状態を変更できるという効果がある。

リクエスト処理ソフトウェア１２５は，停止時刻２５２が経過すると（５００），時間が経過した仮想サーバの起動や生死確認を行う（５０２）。これは，仮想サーバの現在の状態によって実施する処理が変化するためである。

この結果を用いて，リクエスト処理ソフトウェア１２５は，まず対象の仮想サーバからのレスポンスが受信済みかどうかを判断する（５０４）。レスポンスを受信済みである場合，リクエスト処理ソフトウェア１２５は，データ５６１によってリクエスト管理ソフトウェア１４５に仮想サーバ停止要求を送信する（５１０）。

図３のデータ５６１に，データ５６１の詳細を示す。データ５６１は，命令コード３４１と，IPアドレス３４２を含む。命令コード３４１は，仮想サーバの停止指示と停止のパターンを表すコードである。ここでは正常終了に伴う停止が指示される。IPアドレス３４２は，停止対象の仮想サーバのIPアドレスである。

リクエスト処理ソフトウェア１２５は，手順５０４でレスポンスが受信済みでない場合，なんらかのエラーが発生しているとみなす。まずリクエスト処理ソフトウェア１２５は，仮想サーバが正常に稼働しているかどうかを確認する（５０６）。仮想サーバが正常に稼働している場合，まだ処理中である可能性があるため，仮想サーバは停止させず，業務システム１１０にエラーを送信する（５１２）。エラーを送信する仕掛けとしては，本来の仮想サーバからのレスポンスとしてエラーを送信してもよいし，メールや電話により業務システム１１０のユーザ１９０にエラーの発生を連絡してもよい。

仮想サーバが正常に稼働していない場合，リクエスト処理ソフトウェア１２５は，データ５６０により，リクエスト管理ソフトウェア１４５に対して仮想サーバの停止要求を行う（５０８）。

図３のデータ５６０に，データ５６０の詳細を示す。データ５６０は，命令コード３４５と，IPアドレス３４６を含む。命令コード３４５は，仮想サーバの停止指示と，停止のパターンを表すコードである。ここで停止指示は異常終了に伴う仮想サーバの停止を示すコードである。停止のパターンとしては，OSの機能によるシャットダウンやリブート，ハイパバイザや物理サーバの機能を使った強制終了などを示すコードが含まれる。IPアドレス３４６は，停止対象の仮想サーバのIPアドレスである。

リクエスト処理ソフトウェア１２５は，仮想サーバ停止要求送信後，待機状態に入る（５１４）。この後，リクエスト処理ソフトウェア１２５はリクエスト管理ソフトウェア１４５から，データ５７０を受信すると，仮想サーバ停止処理が完了したものとし，処理を終了する（５１６）。起動中の仮想サーバを識別する情報は，リクエスト処理ソフトウェア１２５がログとして保持しておき，ユーザ１９０または業務システム１１０から参照できてもよい。

図３のデータ５７０に，データ５７０の詳細を示す。データ５７０は，IPアドレス３９２と，エラーコード３９４を含む。IPアドレス３９２は，データ５６１または５６０でリクエスト処理ソフトウェア１２５から送信したIPアドレスである。エラーコード３９４は，リクエスト管理ソフトウェア１４５による仮想サーバ停止処理の結果を表すコードである。

次にリクエスト管理ソフトウェア１４５の処理を説明する。リクエスト管理ソフトウェア１４５は，手順５１０の結果として，データ５６１を受信する（５３０）と，クラウド管理ソフトウェア１３５に対して，データ５６２を送信する（５３２）。

図３のデータ５６２に，データ５６２の詳細を示す。データ５６２は，命令コード３５２と，IPアドレス３５４を含む。命令コード３５２は，仮想サーバの停止の指示と仮想サーバ停止のパラメータを表すコードである。ここでは停止指示として，正常終了に伴う停止を意味するコードが含まれる。パラメータとしては，仮想サーバ停止前処理や，仮想サーバ停止後処理の有無を示す情報や，停止時に実施する際のバックアップ先などの情報が含まれる。IPアドレス３４６は，停止対象の仮想サーバのIPアドレスであり，データ５６１のIPアドレス３４２に基づき決定される。

リクエスト管理ソフトウェア１４５は，手順５３２を実施後，待機状態５４２に移行する。この後，リクエスト管理ソフトウェア１４５は，クラウド管理ソフトウェア１３５から，データ５６８を受信する（５４４）と，リクエスト管理ソフトウェア１４５は停止通知として，データ５７０を，リクエスト処理ソフトウェア１２５に送信する。

図３のデータ５６８に，データ５６８の詳細を示す。データ５６８は，IPアドレス３８２と，エラーコード３８４を含む。IPアドレス３８２は，データ５６２または５６６でリクエスト管理ソフトウェア１４５から送信したIPアドレスである。エラーコード３９４は，クラウド管理ソフトウェア１３５による仮想サーバ停止処理の結果を表すコードである。

リクエスト管理ソフトウェア１４５は，手順５４４において，停止処理が正常に終了しない場合，再度停止処理を試みてもよい。

また，リクエスト管理ソフトウェア１４５は，手順５０８の結果として，データ５６０を受信する（５３８）と，データ５６６を作成し，クラウド管理ソフトウェア１３５にデータ５６６を送信し（５４０），待機状態（５４２）に入る。

図３のデータ５６６に，データ５６６の詳細を示す。データ５６６は，命令コード３７２と，IPアドレス３７４を含む。命令コード３７２は，仮想サーバの停止指示と仮想サーバ停止のパラメータを表すコードである。ここでは停止指示として，異常終了に伴う停止を意味するコードが含まれる。またパラメータとしては，仮想サーバ停止前処理や，仮想サーバ停止後処理で利用するスクリプトのIDを示す情報や，停止時に実施するデータのダンプ先などの情報が含まれる。IPアドレス３４６は，停止対象の仮想サーバのIPアドレスであり，データ５６０のIPアドレス３４６に基づき決定される。

次にクラウド管理ソフトウェア１３５の処理を説明する。クラウド管理ソフトウェア１３５はリクエスト管理ソフトウェア１４５における手順５３２の結果としてデータ５６２または５６６による停止指示を受信する(５８０)と，仮想サーバ停止前処理を実施する（５８２）。仮想サーバ停止前処理は，仮想サーバを停止前に実行する処理である。クラウド管理ソフトウェア１３５は，データ５６２または５６６に含まれる命令コード３５２または３７２が停止前処理の実行を要求するコードかどうかを判別し，停止前処理の実行が要求されている場合，IPアドレス３５４または３７４をもとに，同じIPアドレスを持つ仮想サーバ管理データ１５２を選択する。次に，仮想サーバ管理データ１５２内の停止前処理用のスクリプト管理ID２５０を取り出す。その後，スクリプト管理ID２５０によって識別されるスクリプト管理データ１５６を検索し，そのスクリプトの内容を実行する。停止前処理としては，アプリケーションで利用するメモリ上のデータのディスクへの書き出しや，DBサーバやActive Directoryサーバなどの関連装置との切断処理や，停止前のスナップショットやバックアップの作成処理，機密データの消去処理などが含まれる。命令コード３５２または３７２により停止前処理が指定されていない場合，処理の実行を省略してもよい。

停止前処理５８２実施後，クラウド管理ソフトウェア１３５は，仮想サーバを停止する（５８４）。停止後，クラウド管理ソフトウェア１３５は，仮想サーバ停止後処理を実施する（５８６）。仮想サーバ停止後処理は，仮想サーバを停止後に実行する処理である。クラウド管理ソフトウェア１３５は，データ５６２または５６６に含まれる命令コード３５２または３７２が停止後処理の実行を要求するコードかどうかを判別し，停止後処理の実行が要求されている場合，IPアドレス３５４または３７４をもとに，同じIPアドレスを持つ仮想サーバ管理データ１５２を選択する。次に，仮想サーバ管理データ１５２内の停止前処理用のスクリプト管理ID２５０を取り出す。その後，スクリプト管理ID２５０によって識別されるスクリプト管理データ１５６を検索し，そのスクリプトの内容を実行する。停止後処理としては，仮想マシンに割り当てていたデータの消去や，CPUやメモリ，ネットワークやストレージの設定の解除処理などが含まれる。命令コード３５２または３７２により停止後処理が指定されていない場合，処理の実行を省略してもよい。

命令コード３５２または３７２は，停止前処理と停止後処理の指示を両方含んでいてもよい。例えば，命令コード中のある一バイトが0x04の時に停止前処理の実施を意味し，またある一バイトが0x08の時に停止後処理の実施を意味するものである場合，ある一バイトが0x0Cの時は，停止前処理と停止後処理の実施を意味すると判断してもよい。

クラウド管理ソフトウェア１３５は，仮想サーバ停止後処理終了後，仮想サーバ停止通知として，データ５６８をリクエスト管理ソフトウェア１４５に送信する（５８８）。

このように，リクエスト処理ソフトウェア１２５，リクエスト管理ソフトウェア１４５，クラウド管理ソフトウェア１３５を用いた処理を行うことで，時間経過に基づき，自動で仮想サーバを停止することができる。

また，リクエスト処理ソフトウェア１２５は，業務システム１１０からの明示的な停止要求パケットを受け付けてもよい。業務システム１１０は停止要求パケットに，停止要求を表すコードと，停止対象のIPアドレスを含めて送信し，リクエスト処理ソフトウェア１２５がこれを受け取ると，時間経過したのと同じく，手順５０２からの処理を実行してもよい。この時，停止対象の仮想サーバの指定に業務システム１１０から送信されたIPアドレスを用いる。

１００…データセンタ
１０３…クラウドコンピューティングシステム
１０５…ルータ
１１０…業務システム
１１２…ジョブ管理装置
１１３…負荷分散装置
１１６・１１８…ジョブ実行サーバ
１２０…ネットワーク
１６０・１７０…物理サーバ
１６８・１７８…ハイパバイザ
１６２・１７２・１７４…仮想サーバ
１２０…リクエスト処理装置
１２５…リクエスト処理ソフトウェア
１３０…クラウド管理装置
１３５…クラウド管理ソフトウェア
１４０…リクエスト管理サーバ
１４５…リクエスト管理ソフトウェア

Claims (8)

1. 業務システムからのリクエストに基づき前記リクエストの送付先の起動の有無を確認する機能を有するリクエスト処理装置と，
   前記リクエスト処理装置からの要求に基づき起動または停止する仮想サーバを決定する機能を有するリクエスト管理装置と，
   仮想サーバの起動および停止を行う機能を有するクラウド管理装置と，
   前記クラウド管理装置により起動および停止され，また前記業務システムからのリクエストを処理する機能を有する仮想サーバと，を有し，
   前記リクエスト処理装置は，前記業務システムから前記仮想サーバに送付されたリクエストを一時的に保持，前記仮想サーバがリクエストを処理可能な状態かを判断し，処理可能な場合には一時的に保持していたリクエストを前記仮想サーバに送信し，前記仮想サーバがリクエストを処理可能な状態でない場合には，前記リクエスト管理装置に仮想サーバの準備を要求し，仮想サーバがリクエストを処理可能な状態になった後に一時的に保持していたリクエストを前記仮想サーバに送信する機能を有し，
   前記リクエスト管理装置は，前記リクエスト処理装置からの仮想サーバの準備要求に基づき，クラウド管理装置に，仮想サーバの準備方法を含む準備要求を送信する機能を有することを特徴とするクラウドコンピューティングシステム。
2. 請求項１において，前記リクエスト処理装置は，業務システムから生死監視のためのリクエストが送信された場合，本来のリクエストの送付先の仮想サーバの状態に関わらず，正常な動作を示すレスポンスを返すことを特徴とするクラウドコンピューティングシステム。
3. 請求項１または２に記載のクラウドコンピューティングシステムにおいて，前記リクエスト管理装置は，時間の経過に伴い停止してもよい仮想サーバを選択し，選択した仮想サーバが処理を完了している場合と，前記選択した仮想サーバが処理を完了していない場合とに基づき，前記クラウド管理装置に対して異なる停止方法により仮想サーバを停止させることを指示することを特徴とするクラウドコンピューティングシステム。
4. 請求項１から３のいずれか一つに記載のクラウドコンピューティングシステムにおいて，前記リクエスト管理装置は，リクエスト処理装置からの指示に基づき停止してもよい仮想サーバを選択し，選択した仮想サーバが処理を完了している場合と，前記選択した仮想サーバが処理を完了していない場合とに基づき，前記クラウド管理装置に対して異なる停止方法により仮想サーバを停止させることを指示することを特徴とするクラウドコンピューティングシステム。
5. 請求項１から４のいずれか一つに記載のクラウドコンピューティングシステムにおいて，前記クラウド管理装置は，前記リクエスト管理装置からの指示に基づき，それが仮想サーバの準備の要求である場合に，仮想サーバの起動前後に，前記リクエスト処理装置からの指示に対応した処理を選択して実行する機能を有し，それが仮想サーバの停止要求である場合には，仮想サーバの停止前後に，前記リクエスト処理装置からの指示に対応した処理を選択して実行する機能を有することを特徴とするクラウドコンピューティングシステム。
6. 請求項１から５のいずれか一つに記載のクラウドコンピューティングシステムにおいて，前記リクエスト処理装置は，業務システムから生死監視のためのリクエストが送信された場合，処理を行わせたい仮想サーバ以外のレスポンスを遅らせて返すことで，業務システムに前記処理を行わせたい仮想サーバへリクエストを送信させることを特徴とするクラウドコンピューティングシステム。
7. 請求項１から６のいずれか一つに記載のクラウドコンピューティングシステムにおいて，前記リクエスト処理装置は，本来リクエストを処理する仮想サーバが起動中であるが、処理負荷が高く、追加のリクエスト処理が困難であると判断した場合に、新しい仮想サーバを起動し、その仮想サーバに対してリクエストを送信する機能を有することを特徴とするクラウドコンピューティングシステム。
8. サーバと、
   サーバの負荷状態や故障の有無を監視し、負荷状態が高い場合や、故障が発生した場合に、前記業務システム内の、本来情報処理を行うサーバへリクエストを送信する代わりに、クラウドコンピューティングシステムにリクエストを送信する負荷分散装置とを有し、
   前記負荷分散装置は、業務システム内のサーバと、クラウドコンピューティングシステム内の仮想サーバからの生死監視のためのパケットの応答時間からリクエストを処理するサーバを選択する際に、業務システム内のサーバへのアクセスに必要な最小の時間と、クラウドコンピューティングシステム内の仮想サーバへのアクセスに必要な最小の時間との差分を考慮し，リクエストを処理するサーバを選択する機能を有する業務システム。

Images