特許 7356026 ロードバランサ配備位置決定方法、及びロードバランサ配備位置決定プログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-09-26

(45)【発行日】2023-10-04

(54)【発明の名称】ロードバランサ配備位置決定方法、及びロードバランサ配備位置決定プログラム

(51)【国際特許分類】

   H04L 47/125 20220101AFI20230927BHJP

【ＦＩ】

H04L47/125

【請求項の数】 6

(21)【出願番号】P 2020006068

(22)【出願日】2020-01-17

(65)【公開番号】P2021114683

(43)【公開日】2021-08-05

【審査請求日】2022-09-08

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100087480

【弁理士】

【氏名又は名称】片山 修平

(72)【発明者】

【氏名】佐藤 昌浩

【審査官】中川 幸洋

(56)【参考文献】

【文献】特開２００６－３３２８２５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１０／００５７９３５（ＵＳ，Ａ１）

【文献】特開２０１８－１２９７１８（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１８／０２２７７７６（ＵＳ，Ａ１）

【文献】特開２０１４－１０３６３７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０３１０５８３（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４７／１２５

(57)【特許請求の範囲】

【請求項1】

コンピュータが、
複数の第１のクラウド拠点の各々に構築されたシステムがリクエストを受け付けたときに実行する処理に要する処理時間を前記第１のクラウド拠点ごとに取得し、
前記第１のクラウド拠点と第２のクラウド拠点との間の通信時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに取得し、
前記処理時間と前記通信時間とを加算した応答時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに算出し、
複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点の各々との間における前記応答時間のばらつきが基準値未満となる第２のクラウド拠点を、前記リクエストを複数の前記第１のクラウド拠点の各々に振り分けるロードバランサの配備先の候補とすること、
を特徴とするロードバランサ配備位置決定方法。

【請求項2】

前記コンピュータが、
前記ばらつきが前記基準値未満となる複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点との間における前記応答時間の最大値が最も小さい第２のクラウド拠点を前記配備先に決定することを特徴とする請求項１に記載のロードバランサ配備位置決定方法。

【請求項3】

前記コンピュータが、
前記ばらつきが前記基準値未満となる前記第２のクラウド拠点に、同一の事業者が提供する複数の第２のクラウド拠点が含まれている場合には、前記事業者が提供する複数の前記第２のクラウド拠点のうちの一つを前記候補にすることを特徴とする請求項１に記載のロードバランサ配備位置決定方法。

【請求項4】

前記コンピュータが、
前記ばらつきを定期的に算出することにより、定期的に前記候補を更新することを特徴とする請求項１に記載のロードバランサ配備位置決定方法。

【請求項5】

前記コンピュータが、
前記更新前に前記ロードバランサを配備していた前記第２のクラウド拠点と複数の前記第１のクラウド拠点の各々との間における前記応答時間の前記ばらつきが前記基準値以上となった場合には、前記更新後の前記候補に含まれる前記ロードバランサのいずれかのIP(Internet Protocol)アドレスを、当該ロードバランサのドメイン名と対応付けてDNS(Domain Name System)サーバに登録することを特徴とする請求項４に記載のロードバランサ配備位置決定方法。

【請求項6】

複数の第１のクラウド拠点の各々に構築されたシステムがリクエストを受け付けたときに実行する処理に要する処理時間を前記第１のクラウド拠点ごとに取得する処理と、
前記第１のクラウド拠点と第２のクラウド拠点との間の通信時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに取得する処理と、
前記処理時間と前記通信時間とを加算した応答時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに算出する処理と、
複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点の各々との間における前記応答時間のばらつきが基準値未満となる第２のクラウド拠点を、前記リクエストを複数の前記第１のクラウド拠点の各々に振り分けるロードバランサの配備先の候補にする処理と、
をコンピュータに実行させるためのロードバランサ配備位置決定プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ロードバランサ配備位置決定方法、及びロードバランサ配備位置決定プログラムに関する。

【背景技術】

【0002】

仮想化技術の発展に伴い、データセンタ内で起動している仮想マシンを利用して種々のサービスを利用者に提供するクラウドサービスが普及しつつある。クラウドサービスでは、サービスに必要なデータやプログラム等を仮想マシン側で管理するため、これらを利用者が管理する必要がなくなり、利用者の業務の効率化やコストダウンを図ることができる。なお、以下ではクラウドサービスのことを単にクラウドとも呼ぶ。

【0003】

クラウドの可用性を高める技術として、複数のクラウドを組み合わせたマルチクラウドと呼ばれる技術がある。マルチクラウドにおいては、データセンタの障害等によってあるクラウドを使用できない状況になっても、残りのクラウドを利用することができるため、クラウドの可用性を高めることができる。

【0004】

但し、マルチクラウドには、利用者がサービスのリクエストを出してからそのサービスの提供を受けるまでの時間のばらつきを抑制するという点で改善の余地がある。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１８－０８４９８６号公報

【発明の概要】

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

【0006】

一側面によれば、利用者がサービスのリクエストを出してからそのサービスの提供を受けるまでの時間のばらつきを抑制することを目的とする。

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

【0007】

一側面によれば、コンピュータが、複数の第１のクラウド拠点の各々に構築されたシステムがリクエストを受け付けたときに実行する処理に要する処理時間を前記第１のクラウド拠点ごとに取得し、前記第１のクラウド拠点と第２のクラウド拠点との間の通信時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに取得し、前記処理時間と前記通信時間とを加算した応答時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに算出し、複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点の各々との間における前記応答時間のばらつきが基準値未満となる第２のクラウド拠点を、前記リクエストを複数の前記第１のクラウド拠点の各々に振り分けるロードバランサの配備先の候補とするロードバランサ配備位置決定方法が提供される。

【発明の効果】

【0008】

一側面によれば、利用者がサービスのリクエストを出してからそのサービスの提供を受けるまでの時間のばらつきを抑制することができる。

【図面の簡単な説明】

【0009】

【図1】図１は、検討に使用したマルチクラウドのシステム構成図である。

【図2】図２（ａ）、（ｂ）は、問題について説明するための模式図である。

【図3】図３は、検討に使用したシステムの運用方法について説明するための模式図である。

【図4】図４は、検討に使用したシステムの第１のクラウド拠点に障害が発生した場合の模式図である。

【図5】図５は、本実施形態に係るシステムの構成図である。

【図6】図６は、本実施形態に係る第１の測定用仮想マシンの機能について説明するための模式図である。

【図7】図７は、本実施形態に係る第２の測定用仮想マシンの機能について説明するための模式図である。

【図8】図８は、本実施形態に係る管理サーバによる応答時間の算出結果について説明するための模式図である。

【図9】図９は、本実施形態に係る管理サーバによる応答時間のばらつきの算出結果について説明するための模式図である。

【図10】図１０は、本実施形態に係るロードバランサの配備先の決定方法の一例を示す模式図である。

【図11】図１１は、本実施形態において、複数の第２のクラウド拠点にロードバランサを配備した場合の本実施形態に係るシステムのシステム構成図である。

【図12】図１２は、管理サーバが定期的にばらつきを監視する場合の本実施形態に係るシステムのシステム構成図である。

【図13】図１３は、本実施形態に係る管理サーバの機能構成図である。

【図14】図１４は、本実施形態に係るロードバランサ配備位置決定方法の一例を示すフローチャート（その１）である。

【図15】図１５は、本実施形態に係るロードバランサ配備位置決定方法の一例を示すフローチャート（その２）である。

【図16】図１６は、本実施形態に係る処理時間管理テーブル作成処理について示すフローチャートである。

【図17】図１７は、本実施形態に係る通信時間管理テーブル作成処理について示すフローチャートである。

【図18】図１８は、本実施形態に係る管理サーバのハードウェア構成図である。

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

【0010】

本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。

【0011】

図１は、検討に使用したマルチクラウドのシステム構成図である。
このシステム１は、マルチクラウドを実現するシステムであり、第１のクラウド拠点２と第２のクラウド拠点３とを有する。このうち、第１のクラウド拠点２は、拠点Ａに設置されたデータセンタの計算機を利用して事業者Ａが提供するクラウドの拠点である。また、第２のクラウド拠点３は、拠点Ｂに設置されたデータセンタの計算機を利用して事業者Ｂが提供するクラウドの拠点である。

【0012】

これらのクラウド拠点２、３の各々は、ネットワーク４を介して利用者端末５と接続されており、利用者端末５に対して種々のサービスを提供する。なお、ここではネットワーク４としてインターネットを想定する。また、利用者端末５は、マルチクラウドを利用する利用者が操作するPC(Personal Computer)等の情報処理装置である。

【0013】

更に、このシステム１においては、第１のクラウド拠点の事業者Aと第２のクラウド拠点の事業者Bとを別の主体にする。これにより、一方の事業者がクラウドを提供できない状況になっても、残りの事業者のクラウドを利用して利用者にサービスを提供できるため、サービスの可用性を高めることができる。

【0014】

各々のクラウド拠点２、３には、サービスを提供するためのシステム１０が構築される。システム１０は、データセンタ内で起動している仮想マシンを利用して構築されており、利用者のニーズに応えるための様々なサービスを提供する。

【0015】

ここでは、第１のクラウド拠点２に第１～第３の仮想マシンVM1～VM3を起動した場合を想定する。このうち、第１の仮想マシンVM1は、利用者端末５からHTTP(Hypertext Transfer Protocol)のリクエストReqを受け付ける仮想サーバである。リクエストReqは、システム１０に対してサービスに応じた処理を依頼する要求である。その処理をシステム１０が終えると、第１の仮想マシンVM1は、処理の結果を応答Ackとして利用者端末５に返す。

【0016】

また、第２の仮想マシンVM2は、第１の仮想マシンVM1が受け付けたリクエストReqに応じた処理を行い、その処理の結果を第１の仮想マシンVM1に返す仮想サーバである。そして、第３の仮想マシンVM3は、その処理を行うのに要する仮想データベースDBである。

【0017】

例えば、システム１０がEC(Electronic Commerce)サイトを構築するシステムである場合には、第１の仮想マシンVM1が利用者端末５から商品検索のリクエストを受け付ける。そして、第２の仮想マシンVM2が仮想データベースDBに登録されている商品を検索し、その結果を第１の仮想マシンVM1に返すことになる。

【0018】

ここでは、システム１０がリクエストReqを受け付けてから応答Ackを返すまでの時間を処理時間T1と呼ぶ。

【0019】

また、第２のクラウド拠点３の内部にも、第１のクラウド拠点２におけるのと同じシステム１０が構築される。

【0020】

更に、この例では、利用者端末５が送信したリクエストReqを第１のクラウド拠点２と第２のクラウド拠点３の各々に振り分けるロードバランサ８を第１のクラウド拠点２の内部に配備する。ロードバランサ８は、第１のクラウド拠点２に起動している仮想マシンによって実現することができ、ラウンドロビン等の所定のアルゴリズムに従って第１のクラウド拠点２と第２のクラウド拠点３の各々にリクエストReqを振り分ける。

【0021】

なお、ロードバランサ８とシステム１０との間の通信の往復時間を以下では通信時間T2と呼ぶ。

【0022】

このようなシステム１によれば、二つのクラウド拠点２、３に同じシステム１０を構築し、ロードバランサ８が利用者端末５のリクエストReqを各クラウド拠点２、３に振り分ける。よって、例えば第１のクラウド拠点２に障害が発生してその内部のシステム１０を利用できない状況になっても、利用者端末５は第２のクラウド拠点３のシステム１０を利用することができ、サービスの可用性を高めることができる。
但し、このシステム１０には以下のような問題が発生することがある。

【0023】

図２（ａ）、（ｂ）は、その問題について説明するための模式図である。
図２（ａ）においては、利用者端末５がシステム１にリクエストを複数回送信した場合の模式図である。ここでは、１回目のリクエストをReq 1で表し、このリクエストReq 1に対してシステム１が利用者端末５に返す応答をAck 1で表す。そして、利用者端末５がリクエストReq 1を送信してから応答Ack 1を受信するまでの時間間隔をΔt1で表す。

【0024】

同様に、２回目のリクエストと応答をそれぞれReq 2、Ack 2で表し、これらの時間間隔をΔt2で表す。そして、３回目のリクエストと応答をそれぞれReq 3、Ack 3で表し、これらの時間間隔をΔt3で表す。

【0025】

図２（ａ）の例では各時間間隔Δt1～Δt3が略一定であり、利用者端末５がシステム１から安定したサービスを受けられる状態にある。

【0026】

一方、図２（ｂ）の例では、各時間間隔Δt1～Δt3が不均一となっている。この原因としては、例えばシステム１０の処理時間T1が第１のクラウド拠点２と第２のクラウド拠点３とで異なることが挙げられる。また、システム１０とロードバランサ８との間の通信時間T2が第１のクラウド拠点２と第２のクラウド拠点３とで異なることも各時間間隔Δt1～Δt3が不均一となる原因の一つである。

【0027】

このような状態では、利用者端末５がリクエストReqを送信してから応答Ackを受信するまでの時間が不安定となるため、利用者端末５がシステム１から安定したサービスを受けることができない。

【0028】

また、マルチクラウドを提供する事業者によっては、管理サーバを利用してシステム１が正常に動作しているかどうかを監視することがある。その場合、管理サーバは、システム１にダミーのリクエストを送信し、そのリクエストに対する応答を管理サーバがシステム１から受信する。システム１に障害等の異常が発生している場合には、管理サーバがダミーのリクエストを送信してから応答を受信するまでの時間間隔Δtが長くなることが想定される。よって、管理者は、システム１に異常が発生しているとみなすための閾値tsを予め定めておく。そして、Δt＜tsの場合にはシステム１は正常であると管理サーバが判断し、Δt≧tsの場合にはシステム１は異常であると管理サーバが判断する。

【0029】

そのような場合に各時間間隔Δt1～Δt3が不均一となっていると、システム１に異常がないにも関わらず、例えばΔt3≧tsとなってしまい異常と誤判定するおそれがある。よって、異常と正常とを切り分けるのに適切な閾値tsを設定するのが困難となり、マルチクラウドに異常があるかどうかを事業者が監視するのが難しくなる。

【0030】

なお、各時間間隔Δt1～Δt3が不均一になるのを防止するために、以下のようにシステム１を運用することも考えられる。

【0031】

図３は、システム１の運用方法について説明するための模式図である。
図３の例では、利用者端末５から送信されたリクエストReqをロードバランサ８が常に第１のクラウド拠点２に振り分ける。このように第１のクラウド拠点２のみを利用すれば、各クラウド拠点２、３における処理時間T1や通信時間T2の相違に起因して時間間隔Δt1～Δt3が不均一になるのを抑制できる。

【0032】

しかし、このような運用方法では、第１のクラウド拠点２に障害が発生した場合に以下のように時間間隔Δt1～Δt3が不均一になるおそれがある。

【0033】

図４は、第１のクラウド拠点２に障害が発生した場合の模式図である。
この場合には利用者端末５が第１のクラウド拠点２のシステム１０を使用することができないため、ロードバランサ８がリクエストReqの振り分け先を第２のクラウド拠点３に切り替える。

【0034】

しかし、システム１０の処理時間T1が第１のクラウド拠点２と第２のクラウド拠点３とで異なる場合には、利用者端末５がリクエストReqを送信してから応答Ackを受信するまでの時間が切り替えの前後で異なってしまう。同様に、システム１０とロードバランサ８との間の通信時間T2が第１のクラウド拠点２と第２のクラウド拠点３とで異なる場合にも、リクエストReqの送信から応答Ackの受信までの時間が切り替えの前後で異なってしまう。これにより、図２（ｂ）の例と同様に、ロードバランサ８の振り分け先の切り替えの前後において各時間間隔Δt1～Δt3が不均一となるおそれがある。

【0035】

以下に、利用者端末がリクエストを送信してから応答を受信するまでの時間間隔が不均一となるのを抑制することが可能な各実施形態について説明する。

【0036】

（本実施形態）
[全体構成]
図５は、本実施形態に係るシステムの構成図である。
このシステム２０は、マルチクラウドを実現するシステムであり、複数の第１のクラウド拠点２１と、複数の第２のクラウド拠点２２とを有する。なお、これらのクラウド拠点２１、２２の各々は、クラウドを提供する事業者と、そのクラウドを提供するための計算機を収容したデータセンタが設置されている拠点との組み合わせで特定されるコンピューティングシステムを示す。このうち、第１のクラウド拠点２１には、利用者端末２７にサービスを提供するためのシステム２３が構築される。この例では、第１のクラウド拠点２１に第１～第３の仮想マシン２１ａ～２１ｃを配備し、これらの仮想マシン２１ａ～２１ｃによりシステム２３を実現する。

【0037】

各仮想マシン２１ａ～２１ｃの機能は特に限定されない。例えば、第１の仮想マシン２１ａは、利用者端末２７からHTTPのリクエストReqを受け付ける仮想サーバである。リクエストReqは、システム２３に対してサービスに応じた処理を依頼する要求である。その処理をシステム２３が終えると、第１の仮想マシン２１ａは、処理の結果を応答Ackとして利用者端末２７に返す。

【0038】

第２の仮想マシン２１ｂは、第１の仮想マシン２１ａが受け付けたリクエストReqに応じた処理を行い、その処理の結果を第１の仮想マシン２１ａに返す仮想サーバである。そして、第３の仮想マシン２１ｃは、その処理を行うのに要する仮想データベースDBである

【0039】

更に、第１のクラウド拠点２１には、システム２３の処理時間を測定するための第１の測定用仮想マシン２４ａが配備される。更に、第１のクラウド拠点２１と第２のクラウド拠点２２との間の通信時間を測定するための第２の測定用仮想マシン２４ｂも第１のクラウド拠点２１内に配備される。

【0040】

一方、第２のクラウド拠点２２は、ロードバランサ２５の配備先の候補のクラウド拠点である。この例では複数の第２のクラウド拠点２２を用意し、このうちのいずれかに最終的にロードバランサ２５が配備される。なお、ロードバランサ２５は、第２のクラウド拠点２２の内部に起動する仮想マシンによって実現することができる。更に、第２のクラウド拠点２２には、前述の第２の測定用仮想マシン２４ｂも配備される。

【0041】

第１のクラウド拠点２１と第２のクラウド拠点２２の各々はネットワーク２６を介して利用者端末２７と接続される。ネットワーク２６は特に限定されない。例えば、インターネット、VPN(Virtual Private Network)、及びLAN(Local Area Network)等をネットワーク２６として採用し得る。

【0042】

利用者端末２７は、マルチクラウドを利用する利用者が操作するPC等の情報処理装置である。利用者の操作を受け付けると、利用者端末２７は、第１のクラウド拠点２１のシステム２３からサービスを受けるためにロードバランサ２５に対してリクエストReqを送信する。ロードバランサ２５は、ラウンドロビン等のアルゴリズムによってそのリクエストReqを複数の第１のクラウド拠点２１のいずれかに振り分ける。そして、リクエストReqが振り分けられた第１のクラウド拠点２１のシステム２３が所定の処理を行う。その後、システム２３は、その処理の結果をリクエストReqに対する応答Ackとして利用者端末２７に送信する。

【0043】

また、複数の第１のクラウド拠点２１の各々を提供する事業者は特に限定されず、複数の第１のクラウド拠点２１ごとに事業者が異なってもよいし、複数の第１のクラウド拠点２１の中に同一事業者が提供するクラウド拠点が存在してもよい。但し、システム２０の可用性を高めるためには、複数の第１のクラウド拠点２１の各々の事業者を異なるようにするのが好ましい。

【0044】

図５においては、第１のクラウド拠点２１と第２のクラウド拠点２２の各々においてクラウドを提供する事業者を事業者A、事業者B、事業者C、…等で表す。また、各クラウド拠点２１、２２が提供するクラウドを実現するための計算機が収容されているデータセンタの拠点を拠点A、拠点B、拠点C、…等で表す。拠点A、拠点B、拠点C、…は、各々が異なる国に位置してもよいし、これらの中に同一国内の拠点が含まれてもよい。

【0045】

更に、このシステム２０は、各クラウド拠点２１、２２を管理するための管理サーバ３０を有する。管理サーバ３０はネットワーク２６に接続されており、複数の第１のクラウド拠点２１と複数の第２のクラウド拠点２２の各々にアクセス可能となっている。なお、管理サーバ３０の形態は特に限定されず、物理サーバや仮想サーバ等のコンピュータを管理サーバ３０として採用し得る。

【0046】

このようなシステム２０においては、前述のようにロードバランサ２５が複数の第１のクラウド拠点２１にリクエストReqを振り分ける。そのため、利用者端末２７がリクエストReqを送信してから応答Ackを受信するまでの時間間隔Δtは、振り分け先の第１のクラウド拠点２１におけるシステム２３の処理時間によって変わる。更に、ロードバランサ２５が配備されている第２のクラウド拠点２２と第１のクラウド拠点２１との間の往復の通信時間によっても時間間隔Δtは変わる。

【0047】

リクエストReqを送信する度に時間間隔Δtが大きく変動すると、図２（ｂ）で例示したように第１のクラウド拠点２１が正常に動作しているかを監視するのが困難となる。しかも、利用者にとっては、システム２３から安定してサービスを受けることができないため不便である。

【0048】

そこで、本実施形態では、以下のようにして複数の第２のクラウド拠点２２のうちで時間間隔Δtのばらつきを抑制することが可能なクラウド拠点にロードバランサ２５を配備する。

【0049】

[ロードバランサ配備位置決定方法]
図６は、第１の測定用仮想マシン２４ａの機能について説明するための模式図である。

【0050】

第１の測定用仮想マシン２４ａは、自身が配備されている第１のクラウド拠点２１内のシステム２３に対してHTTPのダミーのリクエストReq_dを送信する。ダミーのリクエストReq_dとしては、例えばHTTPのGETメソッドを含むリクエストがある。そして、第１の測定用仮想マシン２４ａは、ダミーのリクエストReq_dを送信してからそれに対する応答Ack_dをシステム２３から受信するまでの時間を処理時間T1として取得する。処理時間T1は、システム２３がダミーのリクエストReq_dを受け付けたときに実行する処理に要する時間である。

【0051】

なお、第１の測定用仮想マシン２４ａがシステム２３にダミーのリクエストReq_dを複数回送信し、各々のリクエストReq_dに対する応答Ack_dを複数回受信してもよい。その場合、第１の測定用仮想マシン２４ａがリクエストReq_dを送信してから応答Ack_dを受信するまでの時間を各回で平均した値を処理時間T1として採用し得る。

【0052】

更に、ダミーのリクエストReq_dに代えて、利用者端末２７が送信するリクエストReqを利用して第１の測定用仮想マシン２４ａが処理時間T1を測定してもよい。その場合は、第１の測定用仮想マシン２４ａが、システム２３に出入りするパケットをキャプチャすることにより、リクエストReqの受信時刻と応答Ackの送信時刻との差を処理時間T1として特定すればよい。

【0053】

管理サーバ３０は、第１のクラウド拠点２１ごとに、ネットワーク２６を介して第１の測定用仮想マシン２４ａから処理時間T1を取得する。更に、管理サーバ３０は、その処理時間T1と第１のクラウド拠点２１とを対応付けた処理時間管理テーブルTB1を生成する。処理時間管理テーブルTB1において複数の第１のクラウド拠点２１の各々を識別する識別子として、ここでは第１のクラウド拠点２１の事業者と拠点との組み合わせを採用する。例えば、「事業者A/拠点A」という組み合わせによって、第１のクラウド拠点２１を一意に識別することができる。

【0054】

図７は、第２の測定用仮想マシン２４ｂの機能について説明するための模式図である。

【0055】

図７に示すように、第１のクラウド拠点２１の第２の測定用仮想マシン２４ｂは、自身が配備されている第１のクラウド拠点２１と第２のクラウド拠点２２との間における通信時間T2を測定する。その通信時間T2として、ここでは往復の通信時間RTT(Round Trip Time)を採用する。この場合、第１のクラウド拠点２１の第２の測定用仮想マシン２４ｂが、第２のクラウド拠点２２の第２の測定用仮想マシン２４ｂにping用のパケットを送信する。そして、第１のクラウド拠点２１の第２の測定用仮想マシン２４ｂは、ping用のパケットを送信してからそれに対する応答パケットを第２のクラウド拠点２２の第２の測定用仮想マシン２４ｂから受信するまでの時間を通信時間T2として測定する。

【0056】

なお、第２の測定用仮想マシン２４ｂがRTTの測定を複数回行い、RTTの平均値を通信時間T2として算出するようにしてもよい。また、第１のクラウド拠点２１と第２のクラウド拠点２２との間の往復の通信時間を２で除した片道の通信時間を通信時間T2として採用してもよい。

【0057】

そして、管理サーバ３０は、ネットワーク２６を介して複数の第１のクラウド拠点２１の各々にアクセスし、第１のクラウド拠点２１内の第２の測定用仮想マシン２４ｂから通信時間T2を取得する。

【0058】

更に、管理サーバ３０は、その通信時間T2を含む通信時間管理テーブルTB2を生成する。通信時間管理テーブルTB2は、第１のクラウド拠点２１、第２のクラウド拠点２２、及び通信時間T2の各々を対応付けたテーブルである。

【0059】

その通信時間管理テーブルTB2においては、処理時間管理テーブルTB1と同様に、第１のクラウド拠点２１と第２のクラウド拠点２２の各々を事業者と拠点との組み合わせにより識別する。

【0060】

そして、管理サーバ３０は、上記の処理時間管理テーブルTB1と通信時間管理テーブルTB2を利用して、次のように応答時間を算出する。

【0061】

図８は、管理サーバ３０による応答時間の算出結果３１について説明するための模式図である。

【0062】

応答時間T3は、処理時間T1と通信時間T2との和で定義される。管理サーバ３０は、そのような応答時間T3を、第１のクラウド拠点２１と第２のクラウド拠点２２との組み合わせごとに算出する。

【0063】

例えば、「事業者A/拠点A」の第１のクラウド拠点２１と、「事業者A/拠点C」の第２のクラウド拠点２２との組み合わせについて考える。この場合は、処理時間管理テーブルTB1の一行目を参照すると、「事業者A/拠点A」の第１のクラウド拠点２１の処理時間T1は１００msecである。また、通信時間管理テーブルTB2の一行目を参照すると、「事業者A/拠点A」の第１のクラウド拠点２１と「事業者A/拠点C」の第２のクラウド拠点２２との間の通信時間T2は５０msecである。よって、応答時間T3は１５０msec（＝１００msec＋５０msec）となる。

【0064】

次に、管理サーバ３０は、応答時間T3の算出結果３１を利用して、次のようにして応答時間T3のばらつきΔTを算出する。

【0065】

図９は、管理サーバ３０による応答時間T3のばらつきΔTの算出結果３２について説明するための模式図である。

【0066】

応答時間T3のばらつきΔTは、一つの第２のクラウド拠点２２と、複数の第１のクラウド拠点２１との間における応答時間T3の最大値T3_maxと最小値T3_minとの差である。

【0067】

例えば、算出結果３１における第２のクラウド拠点２２が「事業者A/拠点C」である場合について考える。この場合、算出結果３１において「事業者A/拠点C」に対応する第１のクラウド拠点２１としては「事業者A/拠点A」と「事業者B/拠点B」がある。このうち、「事業者A/拠点C」と「事業者A/拠点A」との間における応答時間T3は１５０msecである。そして、「事業者A/拠点C」と「事業者B/拠点B」との間における応答時間T3は１５０msecである。よって、第２のクラウド拠点２２が「事業者A/拠点C」の場合は、応答時間T3の最大値T3_maxと最小値T3_minはいずれも１５０msecとなり、ばらつきΔTは０msec（＝１５０msec－１５０msec）となる。

【0068】

次に、算出結果３１における第２のクラウド拠点２２が「事業者A/拠点D」である場合について考える。上記と同様に算出すると、「事業者A/拠点D」と「事業者A/拠点A」との間における応答時間T3は１５０msecとなる。そして、「事業者A/拠点D」と「事業者B/拠点B」との間における応答時間T3は１５５msecとなる。よって、第２のクラウド拠点２２が「事業者A/拠点D」である場合には、応答時間T3の最大値T3_maxは１５５msecとなり、応答時間T3の最小値T3_minは１５０msecとなる。これにより、ばらつきΔTは５msec（＝１５５msec－１５０msec）となる。

【0069】

管理サーバ３０は、このような計算を複数の第２のクラウド拠点２２の全てに対して行い、応答時間T3のばらつきΔTの算出結果３２を得る。

【0070】

そのばらつきΔTが大きいと前述のように第１のクラウド拠点２１が正常に動作しているかを管理者が監視するのが困難となると共に、利用者端末２７がシステム２３から安定してサービスを受けることができない。

【0071】

そこで、本実施形態では、管理者が、ばらつきΔTに予め基準値ΔTthを設定しておく。そして、管理サーバ３０が、ばらつきΔTが基準値ΔTth未満となる第２のクラウド拠点２２を、ロードバランサ２５の配備先の候補とする。

【0072】

図９の例では、管理者が基準値ΔTthを１０msecに設定している。この場合は、管理サーバ３０は、「事業者A/拠点C」、「事業者A/拠点D」、及び「事業者C/拠点C」の三つの第２のクラウド拠点２２を、ロードバランサ２５の配備先の候補３５とする。

【0073】

これにより、システム２０の管理者が、ばらつきΔTが基準値ΔTth未満とすることが可能なロードバランサ２５の配備先の候補３５を取得できる。そして、実際に管理者がその候補３５にロードバランサ２５を配備することで、管理者が第１のクラウド拠点２１が正常に動作しているかを監視し易くなると共に、利用者端末２７がシステム２３から安定してサービスを受けることが可能となる。

【0074】

なお、このように候補３５に複数の第２のクラウド拠点２２が含まれている場合には、管理サーバ３０は、それらのうちの一つをロードバランサ２５の配備先として決定してもよい。

【0075】

図１０は、ロードバランサ２５の配備先の決定方法の一例を示す模式図である。

【0076】

図１０の例では、管理サーバ３０が、候補３５のうちで複数の第１のクラウド拠点２１との間における応答時間T3の最大値T3_maxが最も小さい第２のクラウド拠点２２をロードバランサ２５の配備先に決定する。ここでは、図９に示したように、「事業者A/拠点C」の応答時間T3の最大値T3_maxは１５０msecである。また、「事業者A/拠点D」の応答時間T3の最大値は１５５msecであり、「事業者C/拠点C」の応答時間T3の最大値T3_maxは１６０msecである。よって、管理サーバ３０は、応答時間T3の最大値T3_maxが最も小さい「事業者A/拠点C」をロードバランサ２５の配備先に決定する。

【0077】

これにより、利用者端末２７がリクエストReqを送信してから応答Ackを受信するまでの時間間隔が最も短くなるようなロードバランサ２５の配備先を管理者が特定できる。また、実際に管理者がその配備先にロードバランサ２５を配備することにより、利用者端末２７がシステム２３から速やかにサービスを受けることができ、利用者の利便性を向上させることができる。

【0078】

なお、配備先を決定する際の基準として用いる値は最大値T3_maxに限定されない。例えば、管理サーバ３０が、候補３５にある複数の第２のクラウド拠点２２のうちでコストが最も安価なクラウド拠点をロードバランサ２５の配備先に決定してもよい。一例として、第２のクラウド拠点２２の事業者が従量課金制でロードバランサ２５の利用料金を設定している場合には、単位時間当たりの利用料金が最も安価な第２のクラウド拠点２２をロードバランサ２５の配備先に決定してもよい。これにより、システム２０の管理者のコスト減を図ることができ、管理者が利用者に安価なシステム２０を提供することができる。

【0079】

なお、ロードバランサ２５の可用性を高めるために、候補３５にある全ての第２のクラウド拠点２２にロードバランサ２５を配備すると共に、そのうちの一つを現用系にし、残りを待機系にしてもよい。

【0080】

図１１は、このように複数の第２のクラウド拠点２２にロードバランサ２５を配備した場合の本実施形態に係るシステム２０のシステム構成図である。

【0081】

図１１の例では、「事業者A/拠点C」の第２のクラウド拠点２２に現用系のロードバランサ２５を配備し、「事業者C/拠点C」の第２のクラウド拠点２２に待機系のロードバランサ２５を配備している。これにより、「事業者A/拠点C」のロードバランサ２５に障害が発生した場合には、「事業者C/拠点C」にあるロードバランサ２５を利用することにより利用者端末２７が引き続きシステム２３からサービスを受けることができる。

【0082】

なお、ある事業者自身に障害が発生すると、その事業者が提供している全ての第２のクラウド拠点２２が使用できなくなり、ロードバランサ２５の可用性が低下する。そのため、複数の第２のクラウド拠点２２の各々の事業者は全て異なるのが好ましい。図１１の例では、二つの第２のクラウド拠点２２の事業者が「事業者A」と「事業者C」で異なるため、一方の事業者に障害が発生しても、他方の事業者の第２のクラウド拠点２２においてロードバランサ２５を使用することができる。

【0083】

また、この例のように複数の第２のクラウド拠点２２にロードバランサ２５を配備する場合には、次のように管理サーバ３０が定期的に応答時間T3のばらつきΔTを算出するのが好ましい。

【0084】

図１２は、管理サーバ３０が定期的にばらつきΔTを監視する場合の本実施形態に係るシステム２０のシステム構成図である。

【0085】

システム２０においては、運用途中で第１のクラウド拠点２１の事業者や拠点が変更される場合がある。例えば、事業者や拠点を変えた方が第１のクラウド拠点２１のコストが安くなる場合にこのような変更が生じることがある。

【0086】

図１２においては、複数の第１のクラウド拠点２１のうちの一つの拠点が、拠点Aから拠点Fに変更された場合を例示している。この場合には、拠点が変更された時点で応答時間T3のばらつきΔTが変化する。このようにばらつきΔTが変化すると候補３５も変わるため、管理サーバ３０は、例えば１日に一回程度の周期で定期的にばらつきΔTを算出し、その算出結果に応じて定期的に候補３５を更新するのが好ましい。

【0087】

また、候補３５を更新した結果、拠点の変更前では「事業者A/拠点C」が候補３５に含まれていたものの、拠点の変更後では「事業者A/拠点C」が候補３５から外れることがある。ここでは、拠点の変更によってこのように候補３５から「事業者A/拠点C」が外れ、かつ候補３５に「事業者C/拠点C」が含まれた場合について説明する。

【0088】

その場合には、「事業者A/拠点C」のロードバランサ２５から「事業者C/拠点C」のロードバランサ２５に切り替えることにより、「事業者C/拠点C」のロードバランサ２５がリクエストReqの振り分けを行うようにすればよい。但し、利用者端末２７は、切り替え後の「事業者C/拠点C」のロードバランサ２５のIPアドレスを取得していないため、このままでは当該ロードバランサ２５にアクセスすることができない。

【0089】

そこで、この例では、管理サーバ３０が、更新後の候補３５に含まれるロードバランサ２５のIP(Internet Protocol)アドレスを、当該ロードバランサ２５のドメイン名と対応付けてDNS(Domain Name System)サーバ３６に登録する。

【0090】

ここでは、複数の第２のクラウド拠点２２の全てのロードバランサ２５のドメイン名を「lb.cloud.com」とし、利用者端末２７の記憶部には当該ドメイン名「lb.cloud.com」が格納されているものとする。また、「事業者A/拠点C」の第２のクラウド拠点２２にあるロードバランサ２５のIPアドレスは「1.1.1.1」であり、「事業者C/拠点C」の第２のクラウド拠点２２にあるロードバランサ２５のIPアドレスは「2.2.2.2」であるとする。

【0091】

そのIPアドレスは、ロードバランサ２５のドメイン名と対応付けてDNSサーバ３６の管理情報３６ａに格納される。上記の例では、候補３５の更新前においてはドメイン名「lb.cloud.com」とIPアドレス「1.1.1.1」とが対応付けられて管理情報３６ａに格納される。そして、候補３５が更新されると、管理サーバ３０は、管理情報３６ａにおいてドメイン名「lb.cloud.com」に対応するIPアドレスとして「2.2.2.2」を登録することにより、管理情報３６ａを更新する。

【0092】

これにより、利用者端末２７が「事業者C/拠点C」のロードバランサ２５のIPアドレスを取得できる。その結果、利用者端末２７は、そのIPアドレスを送信先アドレスに設定してロードバランサ２５にリクエストReqを送信できるようになる。

【0093】

[機能構成]
次に、本実施形態に係る管理サーバ３０の機能構成について説明する。
図１３は、本実施形態に係る管理サーバ３０の機能構成図である。
図１３に示すように、管理サーバ３０は、通信部４１、制御部４２、及び記憶部４３を有する。

【0094】

通信部４１は、例えばNIC(Network Interface Card)によって実現される処理部である。ここでは、通信部４１は、ネットワーク２６を介して管理サーバ３０を第１のクラウド拠点２１、第２のクラウド拠点２２、及びDNSサーバ３６の各々に接続するインターフェースとして機能する。

【0095】

制御部４２は、CPU(Central Processing Unit)等のプロセッサがDRAM(Dynamic Random Access Memory)等のメモリと協働して本実施形態に係るロードバランサ配備位置決定プログラムを実行することにより実現される処理部である。

【0096】

その制御部４２は、第１の取得部４４、第２の取得部４５、算出部４６、候補決定部４７、及びアドレス登録部４８を有する。

【0097】

第１の取得部４４は、複数の第１のクラウド拠点２１の各々の第１の測定用仮想マシン２４ａから処理時間T1を取得することにより、第１のクラウド拠点２１ごとに処理時間T1を取得する処理部である。また、第１の取得部４４は、取得した処理時間T1を第１のクラウド拠点２１と対応付けて処理時間管理テーブルTB1を生成し、それを記憶部４３に格納する。

【0098】

第２の取得部４５は、複数の第１のクラウド拠点２１と複数の第２のクラウド拠点２２との組み合わせごとに通信時間T2を取得する処理部である。例えば、第２の取得部４５は、第１のクラウド拠点２１の第２の測定用仮想マシン２４ｂから通信時間T2を取得することにより、第１のクラウド拠点２１と第２のクラウド拠点２２との組み合わせごとの通信時間T2を取得する。更に、第２の取得部４５は、取得した通信時間T2を第１のクラウド拠点２１と第２のクラウド拠点２２の各々と対応付けて通信時間管理テーブルTB2を生成し、それを記憶部４３に格納する。

【0099】

一方、算出部４６は、処理時間管理テーブルTB1と通信時間管理テーブルTB2とを参照することにより、処理時間T1と通信時間T2とを加算した応答時間T3を第１のクラウド拠点２１と第２のクラウド拠点２２との組み合わせごとに算出する。

【0100】

また、候補決定部４７は、複数の第１のクラウド拠点２１の各々との間における応答時間T3のばらつきΔTが基準値ΔTth未満となる第２のクラウド拠点２２をロードバランサ２５の配備先の候補３５として決定する処理部である。更に、候補決定部４７は、その候補３５が列挙された候補データCDを作成し、それを記憶部４３に格納する。

【0101】

そして、アドレス登録部４８は、ロードバランサ２５のIPアドレスをそのドメイン名と対応付けてDNSサーバ３６に登録する処理部である。例えば、アドレス登録部４８は、図１２に示したように、ばらつきΔTを定期的に監視した結果候補３５が更新された場合に、更新後の候補３５に含まれるロードバランサ２５のIPアドレスをDNSサーバ３６に登録する。

【0102】

一方、記憶部４３は、HDD等の記憶装置とDRAM等のメモリとによって実現され、前述の処理時間管理テーブルTB1、通信時間管理テーブルTB2、及び候補データCDの各々を記憶する。

【0103】

[処理の流れ]
次に、本実施形態に係る管理サーバ３０の動作について説明する。
図１４及び図１５は、本実施形態に係るロードバランサ配備位置決定方法の一例を示すフローチャートである。

【0104】

まず、第１の取得部４４が、記憶部４３に処理時間管理テーブルTB1があるかどうかを判断する（ステップＳ１１）。ここで、記憶部４３に処理時間管理テーブルTB1がないと第１の取得部４４が判断した場合は（ステップＳ１１：否定）、後述の処理時間管理テーブル作成処理（ステップＳ１２）を実行した後に再びステップＳ１１からやり直す。

【0105】

一方、処理時間管理テーブルTB1があると第１の取得部４４が判断した場合は（ステップＳ１１:肯定）、第１の取得部４４は、処理時間管理テーブルTB1から第１のクラウド拠点２１ごとに処理時間T1を取得する（ステップＳ１３）。

【0106】

その後、第１の取得部４４は、全ての第１のクラウド拠点２１の処理時間T1を取得したかを判断する（ステップＳ１４）。ここで、全ての第１のクラウド拠点２１の処理時間T1を取得していないと第１の取得部４４が判断した場合（ステップＳ１４：否定）にはステップＳ１３に戻る。

【0107】

一方、全ての第１のクラウド拠点２１の処理時間T1を取得したと第１の取得部４４が判断した場合（ステップＳ１４：肯定）にはステップＳ１５に移る。

【0108】

ステップＳ１５においては、第２の取得部４５が、記憶部４３に通信時間管理テーブルTB2があるかどうかを判断する。

【0109】

ここで、記憶部４３に通信時間管理テーブルTB2がないと第２の取得部４５が判断した場合は（ステップＳ１５：否定）、後述の通信時間管理テーブル作成処理（ステップＳ１６）を実行した後に再びステップＳ１５からやり直す。

【0110】

一方、通信時間管理テーブルTB2があると第２の取得部４５が判断した場合は（ステップＳ１５:肯定）、第２の取得部４５は、通信時間管理テーブルTB2から通信時間T2を取得する（ステップＳ１７）。このとき、第２の取得部４５は、第１のクラウド拠点２１と第２のクラウド拠点２２との組み合わせごとに通信時間T2を取得する。

【0111】

次いで、第２の取得部４５は、第１のクラウド拠点２１と第２のクラウド拠点２２の全ての組み合わせについて通信時間T2を取得したかを判断する（ステップＳ１８）。ここで、全ての組み合わせについて通信時間T2を取得していないと第２の取得部４５が判断した場合（ステップＳ１８：否定）にはステップＳ１７に戻る。

【0112】

一方、第２の取得部４５が全ての組み合わせについて通信時間T2を取得したと判断した場合（ステップＳ１８：肯定）にはステップＳ１９に移る。

【0113】

ステップＳ１９においては、算出部４６が、第１のクラウド拠点２１と第２のクラウド拠点２２との組み合わせを一つ選択し、選択した組み合わせに対して応答時間T3を算出する。応答時間T3は、ステップＳ１３とステップＳ１７の各々で取得した処理時間T1と通信時間T2とを用いて、図８に例示した方法で算出される。

【0114】

例えば、図８の「事業者A/拠点A」と「事業者A/拠点C」との組み合わせについては、「事業者A/拠点A」の処理時間T1が１００msecであり、「事業者A/拠点A」と「事業者A/拠点C」との間の通信時間T2が５０msecである。よって、算出部４６が算出する応答時間T3は１５０msec（＝１００msec＋５０msec）となる。

【0115】

次いで、算出部４６が、ステップＳ１９で算出した応答時間T3が最大値T3_maxよりも大きいかどうかを判断する（ステップＳ２０）。最大値T3_maxは、一つの第２のクラウド拠点２２と、複数の第１のクラウド拠点２１との間における応答時間T3の最大値であり、第２のクラウド拠点２２ごとに定まる値である。例えば、図８の算出結果３１に示すように、第２のクラウド拠点２２が「事業者A/拠点D」の場合には、応答時間T3は１５０msecと１５５msecとなるため、最大値T3_maxは１５５msecとなる。

【0116】

ステップＳ２０においては、応答時間T3の算出対象となった第１のクラウド拠点２１と第２のクラウド拠点２２との組み合わせにおいて、第２のクラウド拠点２２に対応する最大値T3_maxと応答時間T3との大小関係が算出部４６によって判断される。

【0117】

なお、算出部４６は、このフローチャートを実行する前に、複数の第２のクラウド拠点２２の各々の最大値T3_maxを十分小さな初期値に初期化しておく。一例として、算出部４６は、最大値T3_maxの初期値を０msecに設定する。

【0118】

そして、応答時間T3が最大値T3_maxよりも大きいと算出部４６が判断した場合には（ステップＳ２０：肯定）、算出部４６がその応答時間T3を新たな最大値T3_maxとする（ステップＳ２１）。

【0119】

一方、応答時間T3が最大値T3_maxよりも大きくないと算出部４６が判断した場合（ステップＳ２０：否定）にはステップＳ２２に移る。

【0120】

ステップＳ２２においては、算出部４６が、ステップＳ１９で算出した応答時間T3が最小値T3_minよりも小さいかどうかを判断する。最小値T3_minは、一つの第２のクラウド拠点２２と、複数の第１のクラウド拠点２１との間における応答時間T3の最小値であり、第２のクラウド拠点２２ごとに定まる値である。例えば、図８の算出結果３１に示すように、第２のクラウド拠点２２が「事業者A/拠点D」の場合には、前述のように応答時間T3が１５０msecと１５５msecとなるため、最小値T3_minは１５０msecとなる。

【0121】

ステップＳ２２においては、応答時間T3の算出対象となった第１のクラウド拠点２１と第２のクラウド拠点２２との組み合わせにおいて、第２のクラウド拠点２２に対応する最小値T3_minと応答時間T3との大小関係が算出部４６によって判断される。

【0122】

なお、算出部４６は、このフローチャートを実行する前に、複数の第２のクラウド拠点２２の各々の最小値T3_minを十分大きな初期値に初期化しておく。一例として、算出部４６は、最小値T3_minの初期値を1000msecに設定する。

【0123】

ここで、応答時間T3が最小値T3_minよりも小さいと算出部４６が判断した場合には（ステップＳ２２：肯定）、算出部４６がその応答時間T3を新たな最小値T3_minとする（ステップＳ２３）。

【0124】

上記のようにしてステップＳ２１とステップＳ２３を終えた後はステップＳ２４に移る。なお、応答時間T3が最小値T3_minよりも小さくないと算出部４６が判断した場合（ステップＳ２２：否定）にもステップＳ２４に移る。

【0125】

ステップＳ２４においては、算出部４６が、第１のクラウド拠点２１と第２のクラウド拠点２２の全ての組み合わせに対して応答時間T3を算出したかどうかを判断する。

【0126】

ここで、全ての組み合わせに対して応答時間T3を算出していないと算出部４６が判断した場合（ステップＳ２４：否定）にはステップＳ１９からやり直す。

【0127】

一方、全ての組み合わせに対して応答時間T3を算出したと算出部４６が判断した場合（ステップＳ２４：肯定）にはステップＳ２５に移る。

【0128】

ステップＳ２５においては、候補決定部４７が、候補データCDに格納されている候補３５を空に初期化する。

【0129】

次に、算出部４６が、第２のクラウド拠点２２の応答時間T3のばらつきΔTを算出する（ステップＳ２６）。図９を参照して説明したように、ばらつきΔTは、一つの第２のクラウド拠点２２の応答時間T3の最大値T3_maxと最小値T3_minとの差として定義される。

【0130】

次いで、候補決定部４７が、ばらつきΔTが基準値ΔTth未満かどうかを判断する（ステップＳ２７）。基準値ΔTthは、利用者端末２７が各システム２３から安定してサービスを受けることができる目安となる値である。ここでは、管理者が基準値ΔTthを１０msecに設定する。

【0131】

そして、ばらつきΔTが基準値ΔTth未満であると候補決定部４７が判断した場合（ステップＳ２７：肯定）にはステップＳ２８に移る。

【0132】

ステップＳ２８においては、候補決定部４７が、ステップＳ２７においてばらつきΔTが基準値ΔTth未満と判断された第２のクラウド拠点２２と同一の事業者のクラウド拠点が候補データCDの候補３５に含まれているかを判断する。

【0133】

ここで、同一事業者の複数の第２のクラウド拠点２２の各々にロードバランサ２５を配備すると、その事業者に障害が生じたときに、前述のように当該事業者が提供する全てのロードバランサ２５が使用できなくなってしまう。

【0134】

そこで、同一の事業者の第２のクラウド拠点２２が候補３５に含まれていると候補決定部４７が判断した場合には（ステップＳ２８：肯定）、ステップＳ２９において、候補決定部４７が複数の第２のクラウド拠点２２から一つを選択する。その選択の基準として、ここでは応答時間T3の最大値T3_maxを採用する。

【0135】

例えば、候補決定部４７は、ステップＳ２７においてばらつきΔTが基準値ΔTth未満と判断された第２のクラウド拠点２２の最大値T3_{max_A}が、候補３５にある同一事業者の第２のクラウド拠点２２の最大値T3_{max_B}よりも小さいかを判断する。

【0136】

そして、最大値T3_{max_A}が最大値T3_{max_B}よりも小さいと判断された場合（ステップＳ２９：肯定）にはステップＳ３０に移る。

【0137】

ステップＳ３０においては、候補決定部４７が、最大値T3_{max_A}を有する第２のクラウド拠点２２をロードバランサ２５の配備先の候補３５とする。これにより、同一事業者が提供する複数の第２のクラウド拠点２２のうちで最大値T3_maxがより小さい第２のクラウド拠点２２がロードバランサ２５の配備先の候補となる。そのため、実際にその第２のクラウド拠点２２にロードバランサ２５を配備することにより、利用者端末２７がリクエストを送信してから応答を受信するまでの時間を短くすることができる。

【0138】

なお、ステップＳ２８において同一の事業者の第２のクラウド拠点２２が候補３５に含まれていないと候補決定部４７が判断した場合にもステップＳ３０を実行する。この場合も、候補決定部４７が、ステップＳ２７においてばらつきΔTが基準値ΔTth未満と判断された第２のクラウド拠点２２を候補３５に登録する。

【0139】

一方、ステップＳ２９において最大値T3_{max_A}が最大値T3_{max_B}よりも小さくないと判断された場合にはステップＳ３０をスキップする。

【0140】

次に、候補決定部４７が、全ての第２のクラウド拠点２２に対してばらつきΔTを算出したかどうかを判断する（ステップＳ３１）。なお、ステップＳ２７においてばらつきΔTが基準値ΔTth未満ではないと候補決定部４７が判断した場合も、ステップＳ２８～Ｓ３０をスキップしてステップＳ３１を実行する。

【0141】

そして、全ての第２のクラウド拠点２２に対してばらつきΔTを算出していないと候補決定部４７が判断した場合（ステップＳ３１：否定）にはステップＳ２６に戻り、そうでない場合（ステップＳ３１：肯定）には処理を終える。

【0142】

次に、ステップＳ１２の処理時間管理テーブル作成処理について説明する。
図１６は、処理時間管理テーブル作成処理について示すフローチャートである。

【0143】

まず、第１の取得部４４は、複数の第１の測定用仮想マシン２４ａの各々に対し処理時間T1を送信するように要求する（ステップＳ４１）。

【0144】

次に、第１の取得部４４は、全ての第１の測定用仮想マシン２４ａから処理時間T1を受信したかどうかを判断する（ステップＳ４２）。ここで、全ての第１の測定用仮想マシン２４ａから処理時間T1を受信していないと第１の取得部４４が判断した場合（ステップＳ４２：否定）にはステップＳ４１からやり直す。

【0145】

一方、全ての第１の測定用仮想マシン２４ａから処理時間T1を受信したと第１の取得部４４が判断した場合（ステップＳ４２：肯定）にはステップＳ４３に移る。

【0146】

ステップＳ４３においては、第１の取得部４４が、第１の測定用仮想マシン２４ａが配備されている第１のクラウド拠点２１と処理時間T1と対応付けて処理時間管理テーブルTB1に格納する。
以上により、処理時間管理テーブル作成処理を終える。

【0147】

次に、ステップＳ１６の通信時間管理テーブル作成処理について説明する。
図１７は、通信時間管理テーブル作成処理について示すフローチャートである。

【0148】

まず、第２の取得部４５は、複数の第２の測定用仮想マシン２４ｂの各々に対し通信時間T2を送信するように要求する（ステップＳ５１）。

【0149】

次に、第２の取得部４５は、全ての第２の測定用仮想マシン２４ｂから通信時間T2を受信したかどうかを判断する（ステップＳ５２）。ここで、全ての第２の測定用仮想マシン２４ｂから通信時間T2を受信していないと第２の取得部４５が判断した場合（ステップＳ５２：否定）にはステップＳ５１からやり直す。

【0150】

一方、全ての第２の測定用仮想マシン２４ｂから通信時間T2を受信したと第２の取得部４５が判断した場合（ステップＳ５２：肯定）にはステップＳ５３に移る。

【0151】

ステップＳ５３においては、第２の取得部４５が、通信時間T2を第１のクラウド拠点２１と第２のクラウド拠点２２の各々と対応付けて通信時間管理テーブルTB2に格納する。
以上により、通信時間管理テーブル作成処理を終える。

【0152】

[ハードウェア構成]
図１８は、本実施形態に係る管理サーバ３０のハードウェア構成図である。
図１８に示すように、管理サーバ３０は、記憶装置３０ａ、メモリ３０ｂ、プロセッサ３０ｃ、通信インターフェース３０ｄ、表示装置３０ｅ、及び入力装置３０ｆを有する。これらの各部は、バス３０ｇにより相互に接続される。

【0153】

このうち、記憶装置３０ａは、HDDやSSD(Solid State Drive)等の不揮発性のストレージデバイスであり、本実施形態に係るロードバランサ配備位置決定プログラム５０を記憶する。

【0154】

なお、ロードバランサ配備位置決定プログラム５０をコンピュータが読み取り可能な記録媒体３０ｈに記録させておき、プロセッサ３０ｃに記録媒体３０ｈのロードバランサ配備位置決定プログラム５０を読み取らせるようにしてもよい。

【0155】

そのような記録媒体３０ｈとしては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体３０ｈとして使用してもよい。これらの記録媒体３０ｈは、物理的な形態を持たない搬送波のような一時的な媒体ではない。

【0156】

更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置にロードバランサ配備位置決定プログラム５０を記憶させてもよい。その場合は、プロセッサ３０ｃがそのロードバランサ配備位置決定プログラム５０を読み出して実行すればよい。

【0157】

一方、メモリ３０ｂは、DRAM等のようにデータを一時的に記憶するハードウェアであって、その上に前述のロードバランサ配備位置決定プログラム５０が展開される。

【0158】

プロセッサ３０ｃは、管理サーバ３０の各部を制御するCPU(Central Processing Unit)やGPU(Graphical Processing Unit)等のハードウェアである。また、プロセッサ３０ｃは、メモリ３０ｂと協働してロードバランサ配備位置決定プログラム５０も実行する。

【0159】

このようにメモリ３０ｂとプロセッサ３０ｃとが協働してロードバランサ配備位置決定プログラム５０を実行することにより、図１３の第１の取得部４４、第２の取得部４５、算出部４６、候補決定部４７、及びアドレス登録部４８を備えた制御部４２が実現される。また、図１３の記憶部４３は、記憶装置３０ａとメモリ３０ｂによって実現される。

【0160】

更に、通信インターフェース３０ｄは、管理サーバ３０をネットワーク２６に接続するためのインターフェースである。その通信インターフェース３０ｄにより、図１３の通信部４１が実現される。

【0161】

そして、表示装置３０ｅは、液晶表示装置等のハードウェアであって、システム２０の管理者に種々の情報を表示する。また、入力装置３０ｆは、キーボードやマウス等のハードウェアである。例えば、管理者は、入力装置３０ｆを操作することにより、管理サーバ３０に対して種々の指示を出すことになる。

【0162】

以上説明した各実施形態に関し、更に以下の付記を開示する。
（付記１） コンピュータが、
複数の第１のクラウド拠点の各々に構築されたシステムがリクエストを受け付けたときに実行する処理に要する処理時間を前記第１のクラウド拠点ごとに取得し、
前記第１のクラウド拠点と第２のクラウド拠点との間の通信時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに取得し、
前記処理時間と前記通信時間とを加算した応答時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに算出し、
複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点の各々との間における前記応答時間のばらつきが基準値未満となる第２のクラウド拠点を、前記リクエストを複数の前記第１のクラウド拠点の各々に振り分けるロードバランサの配備先の候補とすること、
を特徴とするロードバランサ配備位置決定方法。
（付記２） 前記ばらつきは、一つの前記第２のクラウド拠点と、複数の前記第１のクラウド拠点との間における前記応答時間の最大値と最小値との差であることを特徴とする付記１に記載のロードバランサ配備位置決定方法。
（付記３） 前記コンピュータが、
前記ばらつきが前記基準値未満となる複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点との間における前記応答時間の最大値が最も小さい第２のクラウド拠点を前記配備先に決定することを特徴とする付記１に記載のロードバランサ配備位置決定方法。
（付記４） 前記コンピュータが、
前記ばらつきが前記基準値未満となる複数の前記第２のクラウド拠点のうち、コストが最も安価な第２のクラウド拠点を前記配備先に決定することを特徴とする付記１に記載のロードバランサ配備位置決定方法。
（付記５） 前記コンピュータが、
前記ばらつきが前記基準値未満となる前記第２のクラウド拠点に、同一の事業者が提供する複数の第２のクラウド拠点が含まれている場合には、前記事業者が提供する複数の前記第２のクラウド拠点のうちの一つを前記候補にすることを特徴とする付記１に記載のロードバランサ配備位置決定方法。
（付記６） 前記コンピュータが、
前記事業者が提供する複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点との間における前記応答時間の最大値が最も小さい第２のクラウド拠点を前記候補にすることを特徴とする付記５に記載のロードバランサ配備位置決定方法。
（付記７） 複数の前記第１のクラウド拠点の各々を提供する複数の事業者の各々が異なることを特徴とする付記１に記載のロードバランサ配備位置決定方法。
（付記８） 前記コンピュータが、
前記ばらつきを定期的に算出することにより、定期的に前記候補を更新することを特徴とする付記１に記載のロードバランサ配備位置決定方法。
（付記９） 前記コンピュータが、
前記更新前に前記ロードバランサを配備していた前記第２のクラウド拠点と複数の前記第１のクラウド拠点の各々との間における前記応答時間の前記ばらつきが前記基準値以上となった場合には、前記更新後の前記候補に含まれる前記ロードバランサのいずれかのIPアドレスを、当該ロードバランサのドメイン名と対応付けてDNSサーバに登録することを特徴とする付記８に記載のロードバランサ配備位置決定方法。
（付記１０） 複数の第１のクラウド拠点の各々に構築されたシステムがリクエストを受け付けたときに実行する処理に要する処理時間を前記第１のクラウド拠点ごとに取得する処理と、
前記第１のクラウド拠点と第２のクラウド拠点との間の通信時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに取得する処理と、
前記処理時間と前記通信時間とを加算した応答時間を、複数の前記第１のクラウド拠点と複数の前記第２のクラウド拠点との組み合わせごとに算出する処理と、
複数の前記第２のクラウド拠点のうち、複数の前記第１のクラウド拠点の各々との間における前記応答時間のばらつきが基準値未満となる第２のクラウド拠点を、前記リクエストを複数の前記第１のクラウド拠点の各々に振り分けるロードバランサの配備先の候補とする処理と、
をコンピュータに実行させるためのロードバランサ配備位置決定プログラム。

【符号の説明】

【0163】

１…システム、２…第１のクラウド拠点、３…第２のクラウド拠点、４…ネットワーク、５…利用者端末、８…ロードバランサ、１０…システム、２０…システム、２１…第１のクラウド拠点、２１ａ～２１ｃ…第１～第３の仮想マシン、２２…第２のクラウド拠点、２３…システム、２４ａ…第１の測定用仮想マシン、２４ｂ…第２の測定用仮想マシン、２５…ロードバランサ、２６…ネットワーク、２７…利用者端末、３０…管理サーバ、３０ａ…記憶装置、３０ｂ…メモリ、３０ｃ…プロセッサ、３０ｄ…通信インターフェース、３０ｅ…表示装置、３０ｆ…入力装置、３０ｇ…バス、３０ｈ…記録媒体、３１、３２…算出結果、３５…候補、３６…DNSサーバ、３６ａ…管理情報、４１…通信部、４２…制御部、４３…記憶部、４４…第１の取得部、４５…第２の取得部、４６…算出部、４７…候補決定部、４８…アドレス登録部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】