(57)【要約】      （修正有）【課題】同一ロードバランサ配下に仮想マシンを生成した際に、同一の設定の仮想マシンであっても利用可能状態になるまでの時間に差がある場合も、効率的に仮想マシンを利用可能な状態にする。【解決手段】第１のサーバーは、第２のサーバーから、第１のサーバーが正常に稼働していることを確認するための確認要求を受け付ける受け付け手段と、確認要求に基づき、複数のサービスそれぞれに対する確認処理を行う確認手段と、確認手段による確認結果に基づき、第２のサーバーに対し、確認要求に対する応答を送信する応答手段とを備える。応答手段は、所定の期間に設定される第１のモード時において、確認手段による確認結果が複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、第２のサーバーによって第１のサーバーが正常に稼働していないと判定されないための通知を応答する。【選択図】図６
2018124827.tif 000002
【特許請求の範囲】
【請求項１】
複数のサービスを実行可能な第１のサーバーであって、
第２のサーバーから、前記第１のサーバーが正常に稼働していることを確認するための確認要求を受け付ける受け付け手段と、
前記確認要求に基づき、前記複数のサービスそれぞれに対する確認処理を行う確認手段と、
前記確認手段による確認結果に基づき、前記第２のサーバーに対し、前記確認要求に対する応答を送信する応答手段と
を備え、
前記応答手段は、所定の期間に設定される第１のモード時において、
前記確認手段による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、前記第１のサーバーが正常に稼働していることを示す通知を応答し、
前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーによって前記第１のサーバーが正常に稼働していないと判定されないための通知を応答することを特徴とする第１のサーバー。
【請求項２】
前記応答手段は、前記第１のモード時において、前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーに対し、前記第１のサーバーが正常に稼働していることを示す通知と正常に稼働していないことを示す通知のうち、同じ状態を示す通知を所定の回数連続して送信しないように選択的に応答することを特徴とする請求項１に記載の第１のサーバー。
【請求項３】
前記応答手段は、前記所定の期間の経過後に設定される第２のモード時において、
前記確認手段による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、前記第２のサーバーに対し、前記第１のサーバーが正常に稼働していることを示す通知を応答し、
前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーに対し、前記第１のサーバーが正常に稼働していないことを示す通知を応答することを特徴とする請求項１に記載の第１のサーバー。
【請求項４】
前記第１のサーバーは、仮想マシンにより構成されることを特徴とする請求項１乃至３のいずれか一項に記載の第１のサーバー。
【請求項５】
前記所定の期間は、前記第１のサーバーが起動後に最初の確認要求を受信してから所定の時間が経過するまでであることを特徴とする請求項１乃至４のいずれか一項に記載の第１のサーバー。
【請求項６】
複数のサービスを実行可能な第１のサーバーと、前記第１のサーバーと通信を行う第２のサーバーとを含むシステムであって、
前記第２のサーバーは、前記第１のサーバーに対して、前記第１のサーバーが正常に稼働していることを確認するための確認要求を定期的に行う要求手段を有し、
前記第１のサーバーは、
前記第２のサーバーから前記確認要求を受け付ける受け付け手段と、
前記確認要求に基づき、前記複数のサービスそれぞれに対する確認処理を行う確認手段と、
前記確認手段による確認結果に基づき、前記第２のサーバーに対し、前記確認要求に対する応答を送信する応答手段と
を備え、
前記応答手段は、所定の期間に設定される第１のモード時において、
前記確認手段による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、前記第１のサーバーが正常に稼働していることを示す通知を応答し、
前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーによって前記第１のサーバーが正常に稼働していないと判定されないための通知を応答することを特徴とするシステム。
【請求項７】
前記応答手段は、前記第１のモード時において、前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーに対し、前記第１のサーバーが正常に稼働していることを示す通知と正常に稼働していないことを示す通知のうち、同じ状態を示す通知を所定の回数連続して送信しないように選択的に応答することを特徴とする請求項６に記載のシステム。
【請求項８】
前記応答手段は、前記所定の期間の経過後に設定される第２のモード時において、
前記確認手段による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、前記第２のサーバーに対し、前記第１のサーバーが正常に稼働していることを示す通知を応答し、
前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーに対し、前記第１のサーバーが正常に稼働していないことを示す通知を応答することを特徴とする請求項６または７に記載のシステム。
【請求項９】
前記第１のサーバーは、仮想マシンにより構成されることを特徴とする請求項６乃至８のいずれか一項に記載のシステム。
【請求項１０】
前記第２のサーバーは、複数の前記第１のサーバーを管理するロードバランサであり、
前記第２のサーバーは、正常に稼働していると判定した第１のサーバーに対し処理要求を送信することを特徴とする請求項６乃至９のいずれか一項に記載のシステム。
【請求項１１】
前記第２のサーバーの前記要求手段は、前記第１のサーバーが起動処理を開始してから所定の時間が経過した後、前記確認要求の送信を開始することを特徴とする請求項６乃至１０のいずれか一項に記載のシステム。
【請求項１２】
前記第２のサーバーは、前記第１のサーバーに対して送信した確認要求に対する応答として、同じ状態を示す通知を所定の回数連続して受け付けた場合、当該第１のサーバーは前記通知が示す状態であると判定することを特徴とする請求項６乃至１１のいずれか一項に記載のシステム。
【請求項１３】
前記複数のサービスは、Ｗｅｂサービスであり、
前記第１のサーバーは更に、前記複数のサービスとは異なる第２のサービスを実行可能であり、
前記第１のサーバーは更に、前記第２のサービスが正常に稼働していることを確認する第２の確認手段を備え、
前記応答手段は更に、前記第２の確認手段による前記第２のサービスに対する確認結果に基づいて、応答を行うことを特徴とする請求項６乃至１２のいずれか一項に記載のシステム。
【請求項１４】
複数のサービスを実行可能な第１のサーバーを管理する第２のサーバーであって、
前記第１のサーバーに対して、前記第１のサーバーが正常に稼働していることを確認するための確認要求を定期的に行う要求手段と、
前記確認要求に対する応答を管理する管理手段と、
前記管理手段にて管理された情報に基づいて、前記第１のサーバーが正常に稼働しているか否かを判定する第１の判定手段と、
当該第１のサーバーが起動処理を開始してから第１の期間であるか、前記第１の期間が経過した後の第２の期間であるかを判定する第２の判定手段と
を有し、
前記第１の判定手段は、
前記管理手段にて管理している前記第１のサーバーからの確認要求に対する応答が、所定の回数連続して正常に稼働していることを示す場合、当該第１のサーバーは正常に起動していると判定し、
前記管理手段にて管理している前記第１のサーバーからの確認要求に対する応答が、所定の回数連続して正常に稼働していないことを示し、かつ、前記第２の判定手段が前記第１の期間であると判定した場合、判定を行わず、前記要求手段による更なる確認要求に対する応答が行われるまで待機することを特徴とする第２のサーバー。
【請求項１５】
前記第１の判定手段は、前記管理手段にて管理している前記第１のサーバーからの確認要求に対する応答が、所定の回数連続して正常に稼働していないことを示し、かつ、前記第２の判定手段が前記第２の期間であると判定した場合、当該第１のサーバーは正常に稼働していないと判定することを特徴とする請求項１４に記載の第２のサーバー。
【請求項１６】
前記第１のサーバーは、仮想マシンにより実装され、
前記第２のサーバーは、複数の前記第１のサーバーを管理するロードバランサであることを特徴とする請求項１４または１５に記載の第２のサーバー。
【請求項１７】
複数のサービスを実行可能な第１のサーバーの制御方法であって、
第２のサーバーから、前記第１のサーバーが正常に稼働していることを確認するための確認要求を受け付ける受け付け工程と、
前記確認要求に基づき、前記複数のサービスそれぞれに対する確認処理を行う確認工程と、
前記確認工程による確認結果に基づき、前記第２のサーバーに対し、前記確認要求に対する応答を送信する応答工程と
を有し、
前記応答工程では、所定の期間に設定される第１のモード時において、
前記確認工程による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、前記第１のサーバーが正常に稼働していることを示す通知を応答し、
前記確認工程による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーによって前記第１のサーバーが正常に稼働していないと判定されないための通知を応答することを特徴とする制御方法。
【請求項１８】
複数のサービスを実行可能な第１のサーバーと、前記第１のサーバーと通信を行う第２のサーバーとを含むシステムの制御方法であって、
前記第２のサーバーにおいて、前記第１のサーバーに対して、前記第１のサーバーが正常に稼働していることを確認するための確認要求を定期的に行う要求工程を有し、
前記第１のサーバーにおいて、
前記第２のサーバーから前記確認要求を受け付ける受け付け工程と、
前記確認要求に基づき、前記複数のサービスそれぞれに対する確認処理を行う確認工程と、
前記確認工程による確認結果に基づき、前記第２のサーバーに対し、前記確認要求に対する応答を送信する応答工程と
を有し、
前記応答工程では、所定の期間に設定される第１のモード時において、
前記確認工程による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、前記第１のサーバーが正常に稼働していることを示す通知を応答し、
前記確認工程による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーによって前記第１のサーバーが正常に稼働していないと判定されないための通知を応答することを特徴とする制御方法。
【請求項１９】
複数のサービスを実行可能な第１のサーバーを管理する第２のサーバーの制御方法であって、
前記第１のサーバーに対して、前記第１のサーバーが正常に稼働していることを確認するための確認要求を定期的に行う要求工程と、
前記確認要求に対する応答を記憶部にて管理する管理工程と、
前記管理工程にて管理された情報に基づいて、前記第１のサーバーが正常に稼働しているか否かを判定する第１の判定工程と、
当該第１のサーバーが起動処理を開始してから第１の期間であるか、前記第１の期間が経過した後の第２の期間であるかを判定する第２の判定工程と
を有し、
前記第１の判定工程において、
前記記憶部にて管理している前記第１のサーバーからの確認要求に対する応答が、所定の回数連続して正常に稼働していることを示す場合、当該第１のサーバーは正常に起動していると判定し、
前記記憶部にて管理している前記第１のサーバーからの確認要求に対する応答が、所定の回数連続して正常に稼働していないことを示し、かつ、前記第２の判定工程にて前記第１の期間であると判定した場合、判定を行わず、前記要求工程による更なる確認要求に対する応答が行われるまで待機することを特徴とする制御方法。
【請求項２０】
コンピューターを、
サービスが正常に稼働していることを確認するための確認要求を受け付ける受け付け手段、
前記確認要求に基づき、複数のサービスそれぞれに対する確認処理を行う確認手段、
前記確認手段による確認結果に基づき、前記確認要求に対する応答を送信する応答手段
として機能させ、
前記応答手段は、所定の期間に設定される第１のモード時において、
前記確認手段による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、正常に稼働していることを示す通知を応答し、
前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記確認要求の送信元によって正常に稼働していないと判定されないための通知を応答することを特徴とするプログラム。
【請求項２１】
コンピューターを、
サービスを提供するアプリケーションに対して、当該アプリケーションが正常に稼働していることを確認するための確認要求を定期的に行う要求手段、
前記確認要求に対する応答を管理する管理手段、
前記管理手段にて管理された情報に基づいて、前記アプリケーションが正常に稼働しているか否かを判定する第１の判定手段、
当該アプリケーションが起動処理を開始してから第１の期間であるか、前記第１の期間が経過した後の第２の期間であるかを判定する第２の判定手段
として機能させ、
前記第１の判定手段は、
前記管理手段にて管理している前記アプリケーションからの確認要求に対する応答が、所定の回数連続して正常に稼働していることを示す場合、当該アプリケーションは正常に起動していると判定し、
前記管理手段にて管理している前記アプリケーションからの確認要求に対する応答が、所定の回数連続して正常に稼働していないことを示し、かつ、前記第２の判定手段が前記第１の期間であると判定した場合、判定を行わず、前記要求手段による更なる確認要求に対する応答が行われるまで待機することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１のサーバー、第２のサーバー、システム、およびそれらの制御方法、並びにプログラムに関する。
【背景技術】
【０００２】
近年、アプリケーションや仮想マシン、ストレージなどのコンピュータリソースをユーザが必要なときに必要な分だけ利用できるクラウドサービスが増加している。クラウドサービスを利用すると、ユーザは、仮想マシンの生成や削除などの操作を簡単に行うことができ、さらに外部から仮想マシンの監視や制御を行うこともできる。
【０００３】
例えば、配下の仮想マシンに対してリクエストを転送するロードバランサにスケーリングの設定を行っておくことで、配下の仮想マシンがダウンしてしまった場合でもロードバランサから仮想マシンを切り離し、自動で再生成することも可能である。この際、ロードバランサは配下の仮想マシンに対して定期的にヘルスチェック（仮想マシンの死活監視）を行っており、Ｗｅｂサーバーの場合、ＨＴＴＰリクエストなどを一定間隔で仮想マシンに対して送信している。ヘルスチェックの方法やそれに付随したマシンに対する制御方法はロードバランサによって異なる。例えば、特許文献１では、単にマシンの状態を確認するだけでなく、ロードバランサから仮想マシンへのリクエストの転送を適切に制御し、復旧の見込みが立たないマシンを切り離すような設定が可能な構成としている。
【０００４】
一方、近年のクラウドプラットフォームで提供されているロードバランサでは、ヘルスチェックの連続成功回数と連続失敗回数にそれぞれ閾値が設けられている。このようなロードバランサは、ヘルスチェックが閾値回数以上連続で成功した仮想マシンに対してはリクエストを転送し、閾値回数以上連続で失敗した仮想マシンに対しては切り離すように設定することができる。また、そのロードバランサ配下の仮想マシンの常時稼働数や、高負荷時に自動的にスケールアウトする仮想マシンの上限数なども設定することができる。このように、ロードバランサに関する設定を適切に行うことで、リクエストの転送先の制御や異常状態にある仮想マシンの検知と切り離しを自動で行うことができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−１１８４８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
仮想マシンの起動後、Ｗｅｂサービスや監視エージェントなどのサービスが起動を開始する。連続成功・失敗回数の閾値で正常・異常を判断するロードバランサを使用した場合、仮想マシンの起動直後にヘルスチェックを開始するのは好ましくない。これは、ヘルスチェックに対してレスポンスを返すＷｅｂサービスの起動が完了していない可能性があり、正常に起動中であるのにも関わらず異常と判断されロードバランサから切り離されてしまうからである。
【０００７】
これを回避するためにヘルスチェックを開始するまでの準備期間をロードバランサ側で設定することができる。同一ロードバランサ配下の仮想マシンであっても、その仮想マシンが稼働するＩＴインフラのリソースの使用状況や仮想マシンのスペック、仮想マシンの内容によっては準備時間が異なるため、ヘルスチェック開始までの準備期間は長めに確保する必要がある。しかし、準備期間を長めに確保すると、同一ロードバランサ配下の他の仮想マシンに比べて短期間で準備が完了した仮想マシンには準備期間が終わるまでロードバランサからリクエストが転送されないという課題がある。さらに、準備期間を長く確保しすぎると、起動中に本当に異常があった場合には検知が遅れてしまうという課題もある。一方、準備期間を短くする代わりに、ヘルスチェックの間隔を長くしたり、異常検知までの連続失敗回数の閾値を増やしたりすることで、異常と判断されるまでの期間を延ばすことは可能である。しかし、処理環境をデプロイメントした時点では問題なかったとしても、稼働中の処理環境においては仮想マシンの異常検知に遅れが生じてしまうため、ヘルスチェックの間隔を長くしたり、連続失敗回数の閾値を増やしたりするのは好ましくない。
【０００８】
本発明は、上記課題を解決するためになされたものであり、同一ロードバランサ配下の複数の仮想マシン間で起動してから準備が完了するまでの時間に差があった場合においても、仮想マシンを効率的に利用可能な状態にすることを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために本願発明は以下の構成を有する。すなわち、複数のサービスを実行可能な第１のサーバーであって、第２のサーバーから、前記第１のサーバーが正常に稼働していることを確認するための確認要求を受け付ける受け付け手段と、前記確認要求に基づき、前記複数のサービスそれぞれに対する確認処理を行う確認手段と、前記確認手段による確認結果に基づき、前記第２のサーバーに対し、前記確認要求に対する応答を送信する応答手段とを備え、前記応答手段は、所定の期間に設定される第１のモード時において、前記確認手段による確認結果が前記複数のサービスの全てが正常に稼働していることを示す場合、前記第１のサーバーが正常に稼働していることを示す通知を応答し、前記確認手段による確認結果が前記複数のサービスの少なくとも１つが正常に稼働していないことを示す場合、前記第２のサーバーによって前記第１のサーバーが正常に稼働していないと判定されないための通知を応答する。
【発明の効果】
【００１０】
本願発明により、同一ロードバランサ配下の仮想マシン間で起動してからの準備が完了するまでの時間に差があった場合においても、仮想マシンを効率的に利用可能な状態にすることができる。
【図面の簡単な説明】
【００１１】
【図１】本願発明に係るシステム構成およびネットワーク構成の例を示す図。
【図２】本願発明に係る情報処理装置のハードウェア構成の例を示す図。
【図３】本願発明に係る処理システムの構成の例を示す図。
【図４】第１の実施形態に係るロードバランサと仮想マシンの構成の例を示す図。
【図５】第１の実施形態に係るヘルスチェックとスケーリングの設定の例を示す図。
【図６】従来のシステムと本願発明のシステムとの比較を説明するための図。
【図７】本願発明に係るヘルスチェックエージェントの処理を示すフローチャート。
【図８】第２の実施形態に係るロードバランサと仮想マシンの構成の例を示す図。
【図９】第３の実施形態に係るヘルスチェックとスケーリングの設定の例を示す図。
【図１０】第３の実施形態に係る仮想マシンを管理するテーブル構成の例を示す図。
【図１１】第３の実施形態に係る処理を示すフローチャート。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための一形態について図面を用いて説明する。
【００１３】
＜第１の実施形態＞
［システム構成］
図１は、本実施形態に係るシステムのネットワーク構成例を示す図である。情報処理装置１０４は、光回線などでプロバイダ１０３と通信し、プロバイダ１０３を介してインターネット１０２と接続されたＰＣやプリンター、複合機などである。情報処理端末１０７は基地局１０６と無線で通信し、コアネットワーク１０５を介してインターネット１０２と接続された端末で、例えばタブレットやスマートフォン、ノートＰＣなどである。ここでの無線通信機能の仕様等は特に限定するものではない。情報処理端末１０７には、無線通信機能を備えたデスクトップＰＣやプリンターなども含まれる。サーバー１０１は、インターネット１０２を介し、各情報処理端末にＷｅｂコンテンツやＷｅｂ  ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を提供するシステムである。なお、ここでは各装置が１台ずつ示されているが、これに限定するものではなく、更に多くの装置が通信可能に接続されていてもよい。
【００１４】
［ハードウェア構成］
図２は、サーバー１０１、情報処理装置１０４、情報処理端末１０７などの情報処理機能を有するハードウェアの構成例を示す図である。入出力インターフェース２０１は、ＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）であり、ディスプレイ、キーボード、マウス、タッチパネル、ボタンなどによる、情報や信号の入出力を行う。なお、これらのハードウェアを備えないコンピューターは、リモートデスクトップやリモートシェルなどにより、他のコンピューターから接続・操作することも可能である。ネットワークインターフェース２０２は、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行う。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶部である。ＲＡＭ２０５は、一時メモリ領域のとしての記憶部である。二次記憶装置２０６は、ＨＤＤやフラッシュメモリに代表されるような記憶部である。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などからプログラムや各種データ読み出し、適時実行する。各部は、内部バス２０７を介して通信可能に接続されている。
【００１５】
以下の説明では特に、図２に示すハードウェア構成の例は、クラウドサービスを提供するための基盤となるデータセンター等に配置されたサーバー１０１のハードウェア構成の例として説明する。なお、上述したように、サーバー１０１は、複数台のハードウェアから構成されることが想定されるため、図２に示す各部位も物理的に複数台から構成されるものであってよい。
【００１６】
［ソフトウェア構成］
図３は、本実施形態に係るシステムの構成例を示す図である。クライアント３００は、管理システム３１０が提供しているサービスを利用する情報処理装置１０４、情報処理端末１０７などの情報処理機能を有する装置である。管理システム３１０は、クラウドサービスベンダが提供しているプラットフォームを利用してシステム開発者が構築した管理システムである。処理システム３２０は、クライアント３００からリクエストを受け付け、リクエストの処理を実行する部位であり、１または複数のサーバー１０１からなる集合体である。つまり、クライアント３００と、サーバー１０１に設けられる管理システム３１０は、インターネット１０２を介して接続されることとなる。処理システム３２０は、開発環境と本番稼働環境を一斉に切り替える方法であるブルーグリーンデプロイメントなどを行うために、管理システム３１０内に複数存在していてもよい。処理システムは、１または複数のロードバランサ（以下、ＬＢと呼ぶ）と、複数の仮想マシン（以下、ＶＭと呼ぶ）を含んで構成される。
【００１７】
ＬＢ３２１は、クライアント３００やＶＭ３２２、キューなどからリクエストを受け付け、配下のＶＭ３２２にリクエストを転送する。ＬＢ３２１は、配下にＶＭ３２２が複数存在する場合は、ＶＭ３２２それぞれの状態に応じてリクエストを適切に分散する機能（負荷分散機能）を有する。ＬＢ３２１は、配下のＶＭ３２２に対してヘルスチェック（死活監視などとも言う）を定期的に行っており、プログラムエラーや高負荷などが原因でＶＭ３２２が使用不可能状態に陥っていないか確認を行う。ここで、ＶＭ３２２が使用不可能状態となる原因については、特に限定するものではないが、ＶＭ３２２が未起動である場合や起動動作中である場合なども含まれる。例えば、ＶＭ３２２がＷｅｂサーバーの場合、ＨＴＴＰリクエストなどを定期的に送信し、正常なレスポンス（例えば、ＨＴＴＰステータスコード２００など）が返されるか否かにより、ＶＭ３２２が正常に稼働しているかを確認している。ＬＢ３２１に関する具体的な設定例については後述する。
【００１８】
ＶＭ３２２は、ＬＢ３２１から転送されるリクエストを処理するＶＭである。ＶＭ３２２は、単位時間当たりのリクエスト数やＶＭ３２２自身のリソースの使用状況に応じて動的にスケーリング（スケールアウトやスケールインなど）するように設定することができる。ＶＭ３２２では、１または複数のサービスが実行可能であり、ここでのサービスとは、Ｗｅｂサービスの他、内部処理を行う各種サービスが該当する。ＶＭ３２２に関する具体的なスケーリングの設定例については後述する。
【００１９】
データベース３３０は、処理システム３２０内で処理した結果などを格納するデータベースである。データベース３３０は、冗長化目的で同一のデータベースが複数配置されていたり、処理システム３２０の特性により異なる種類のデータベースが複数配置されていたりしてもよい。
【００２０】
リソース管理部３４０は、管理システム３１０内のコンピュータリソースの監視や操作を行うためのリソース管理部であり、クラウドサービスベンダによって提供される機能である。リソース管理部３４０の各機能はＣＵＩ（Ｃｈａｒａｃｔｅｒ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）とＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）の両方で提供されている。主にシステム管理部３５０がコンピュータリソースの操作を行う場合はＣＵＩが用いられ、システム管理者がコンピュータリソースの監視を行う場合はＧＵＩが用いられる。
【００２１】
リソース管理部３４０は、リソース生成部３４１、リソース監視部３４２、設定値更新部３４３、およびリソース削除部３４４を含んで構成される。リソース生成部３４１は、管理システム３１０内のコンピュータリソースを生成する機能を有する。リソース監視部３４２は、管理システム３１０内のコンピュータリソースの状態を監視する機能を有する。リソース監視部３４２は、例えば、ＶＭ３２２のＣＰＵ２０３やＲＡＭ２０５の使用状況、ＬＢ３２１へのアクセス状況などを監視する。設定値更新部３４３は、処理システム３２０のコンピュータリソースに関する設定値を更新する機能を有する。リソース削除部３４４は、管理システム３１０内のコンピュータリソースを削除する機能を有する。リソース削除部３４４は、削除処理をスケジューラに予め登録しておくことで、定期的にもしくは所定のタイミングで、不要なコンピュータリソースや処理システム３２０を削除するように設定されていてもよい。
【００２２】
システム管理部３５０は、管理システム３１０内のコンピュータリソースを管理し、リソース管理部３４０に対してコンピュータリソースの操作指示を行う。システム管理部３５０は、管理システム３１０を管理するシステム開発者が独自に生成する機能である。データストア３６０は、システム管理部３５０がリソース管理部３４０に対する操作指示を記した管理用プログラムや、処理システム３２０で動作するアプリケーションプログラム、監視ログなどのデータを格納する管理用のデータストア（ストレージ）である。
【００２３】
［仮想マシンの構成例］
図４は、本実施形態に係るＶＭ３２２の構成例を示す図である。Ｗｅｂサービス４００は、外部のクライアント３００や外部のＶＭ３２２とＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などのプロトコルで通信するＷｅｂサービスである。なお、Ｗｅｂサービス４００は、アプリケーションとして構成されていてもよい。Ｗｅｂサービス４００内では複数のプロセスが起動しており、外部から受信するリクエストの内容（宛先であるＵＲＬや使用するＨＴＴＰメソッドなど）に応じてプロセス４２０がリクエストの処理を行った後、リクエストの送信元に適切なレスポンスを返す。
【００２４】
ヘルスチェックエージェント４１０は、ＬＢ３２１から受信したヘルスチェック用のリクエスト（確認要求）を処理し、ＬＢ３２１にレスポンスを返す本発明の特徴であるヘルスチェック用のプロセスである。ヘルスチェックエージェント４１０は、ＬＢ３２１からヘルスチェックリクエストを受け取った後、さらにプロセス４２０に対してローカルホスト宛のヘルスチェック（確認処理）を行う。このローカルホスト宛のヘルスチェックで、全てのプロセスが正常なレスポンスを返し、問題無く稼働していることが確認できた場合、ヘルスチェックエージェント４１０は、ＬＢ３２１に対して正常である旨のレスポンスを返す。この動作モードを以下、「通常モード」と呼ぶ。本発明において、ヘルスチェックエージェント４１０は通常モード以外の動作モードも有するが、詳細に関しては後述する。
【００２５】
プロセス４２０は、ＬＢ３２１から通常のアプリケーションに関するリクエスト（処理要求）を受信し、Ｗｅｂコンテンツや処理結果を返すＷｅｂサービス上で稼働するプロセスである。ヘルスチェックエージェント４１０、プロセス４２０はいずれもＷｅｂサービスを提供するためのプロセスであり、ＶＭ３２２が起動した後に順次起動するが、起動順序は指定できる。そのため、本発明においてはヘルスチェックエージェント４１０をプロセス４２０より先に起動するものとする。サービス４３０は、Ｗｅｂサービス４００以外のサービスを示しており、例えばログ監視やウイルス検知、ファイル改竄検知などのサービスが挙げられる。
【００２６】
図５は、ＬＢ３２１と配下のＶＭ３２２に関するヘルスチェックとスケーリングの設定例５００を示す。なお、設定例５００の各種設定項目は全てクラウドサービスベンダが提供しているプラットフォームのパラメータであるため、利用するプラットフォームによって異なる場合がある。つまり、設定項目の数が増減する場合や、設定項目に対する値として範囲が指定されたり、設定可能な値が限定されたりする場合もある。
【００２７】
図５に示す設定例５００の各設定項目において、ＬＢ３２１ごとに異なる設定値を適用することができる。設定例５００の設定項目「ロードバランサ名」は、設定の対象となるＬＢ３２１の名前であり、管理システム３１０内でユニークな値である。設定項目「ＤＮＳ名」は、ＬＢ３２１のエンドポイントを示すＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）であり、ＤＮＳレコードに紐付けることが可能である。設定項目「プロトコル」、「ポート」、および「ヘルスチェックパス」は、ＬＢ３２１の配下のＶＭ３２２内のヘルスチェックエージェント４１０に対してヘルスチェックを行う際の通信プロトコルおよび宛先ポートとパスを示している。図５に設定例５００の設定値の場合、“ｈｔｔｐ：／／ｅｘｔｅｒｎａｌ−ｗｅｂ−２０１６１１０１−００００００−ａｂｃｄｅｆ．ｅｘａｍｐｌｅ．ｃｏ．ｊｐ：８０／ｍｎｇ／ｈｃ”がヘルスチェックエージェント４１０の宛先である。
【００２８】
また、ＬＢ３２１は、設定項目「正常レスポンス」で設定したＨＴＴＰステータスコードがレスポンスとして返された場合に、ヘルスチェックを行ったＶＭ３２２が正常であると判断する。それ以外のＨＴＴＰステータスコードがレスポンスとして返された場合はヘルスチェックを行ったＶＭ３２２が異常であると判断する。設定項目「タイムアウト時間」は、ＬＢ３２１がヘルスチェックリクエストを送信後、ヘルスチェックエージェント４１０から返されるレスポンスを待機する上限の時間である。この時間内にヘルスチェックエージェント４１０からレスポンスが返されない場合、ＬＢ３２１は、ＶＭ３２２を異常であると判断する。
【００２９】
設定項目「ヘルスチェック間隔」は、ＬＢ３２１がヘルスチェックエージェント４１０に対してヘルスチェックリクエストを送信する間隔であり、図５の設定例５００の設定値は３０秒であることを示している。設定項目「連続異常閾値」は、ＬＢ３２１からＶＭ３２２を切り離す判断をするためのヘルスチェックの連続異常回数の閾値である。ヘルスチェックエージェント４１０がこの閾値以上連続して異常のレスポンスを返した場合、ＬＢ３２１はＶＭ３２２を切り離す。以下、ＬＢ３２１によって連続異常回数の閾値を超えたと判断された場合、ＶＭ３２２は「アンヘルシー（ｕｎｈｅａｌｔｈｙ）」であるという。
【００３０】
設定項目「連続正常閾値」は、ＬＢ３２１からＶＭ３２２にリクエストを転送してよいか判断するためのヘルスチェックの連続正常回数の閾値である。ヘルスチェックエージェント４１０がこの閾値以上連続して正常のレスポンスを返した場合、ＬＢ３２１は自身が受け付けたリクエストをＶＭ３２２に転送する。以下、ＬＢ３２１によって連続正常回数の閾値を超えたと判断された場合、ＶＭ３２２は「ヘルシー（ｈｅａｌｔｈｙ）」であるという。
【００３１】
設定項目「準備期間」は、ＬＢ３２１配下にＶＭ３２２が起動してから、ＬＢ３２１がヘルスチェックエージェント４１０に対してヘルスチェックを行うまでに待機する時間である。図５の設定例５００の設定値の場合、６０秒待機することを示している。一般的にＶＭ３２２の準備が完了するまでのおおよその時間を設定するが、短すぎるとＬＢ３２１のヘルスチェックでアンヘルシーであると判断され、ＶＭ３２２はＬＢ３２１から切り離されてしまう。その一方で、長く設定しすぎるとＶＭ３２２の準備が完了しているのにも関わらず、ＬＢ３２１はＶＭ３２２に対してリクエストを転送しない期間が生じてしまう。なお、準備期間を０秒に設定すると、ＶＭ３２２が起動後、直ちにヘルスチェックが開始されてしまうが、設定することは可能である。
【００３２】
設定項目「通常マシン数」は、ＬＢ３２１配下のＶＭ３２２が常時起動しているべき最小のマシン数を示している。例えば、図５の設定例５００では設定値として２台が指定されており、なんらかの理由で２台のうち１台がロードバランサから切り離されてしまった場合でも、最低２台が起動している状態を保つように動的にスケールアウトする。設定項目「最大マシン数」は、設定項目「スケーリングポリシ」の条件に従ってスケールアウトした際の、同時に稼働する合計マシン数の上限を示している。設定項目「スケーリングポリシ」は、ＬＢ３２１配下のＶＭ３２２をスケールアウトする際の条件を記述した定義プロファイルを示している。定義プロファイルには、例えば、単位時間当たりのＬＢ３２１へのアクセス数が所定の閾値を超える、あるいは、ＬＢ３２１配下のＶＭ３２２のＣＰＵの使用率が所定の閾値を超える、などといった条件を記述することができる。また、同様にスケールインする際の条件を記述することもできる。
【００３３】
設定項目「イメージファイル」は、スケールアウトする際に使用する、予め用意されたマシンイメージを示している。設定項目「マシンタイプ」は、スケールアウトする際に生成されるＶＭ３２２のマシン性能を示している。クラウドサービスベンダが提供しているプラットフォーム上にデフォルトで用意されているマシンタイプを指定したり、システム開発者が独自にカスタマイズしたマシンタイプを指定したりすることができる。
【００３４】
［動作の説明］
図６は、従来の処理システムと本願発明を適用した処理システム３２０との比較を示すタイミングチャートである。なお、従来の処理システムも本発明の処理システム３２０と同様のシステム構成を成しており、図５の設定例５００と同様の設定を行うことができるが、ヘルスチェックエージェント４１０の挙動は通常モードのみである。
【００３５】
図６（ａ）は、従来の処理システムにおいてＶＭ３２２が起動後、準備に時間がかかっている場合のタイミングチャートである。Ｔ０は、ＶＭ３２２が起動する時刻を示す。つまり、ＶＭ３２２の起動処理が開始される時刻を示す。これにより、Ｗｅｂサービス４００（更には、ヘルスチェックエージェント４１０やプロセス４２０）や、サービス４３０が順次起動される。Ｔ１は、ヘルスチェックが開始される時刻を示す。Ｐ０は、図５に示した設定例５００の設定項目「準備期間」として指定した期間であり、時刻Ｔ１−時刻Ｔ０と同値である。Ｔ２は、ＬＢ３２１配下のＶＭ３２２の準備が完了する予定の時刻を示す。Ｐ１は、準備に時間がかかっているＶＭ３２２の準備期間であり、時刻Ｔ２−時刻Ｔ０と同値である。図６（ａ）の場合、時刻Ｔ１からヘルスチェックが開始され、時刻Ｔ１から時刻Ｔ２の間にヘルスチェックにてＬＢ３２１がアンヘルシーと判断した場合、ＬＢ３２１は配下のＶＭ３２２を切り離すこととなる。
【００３６】
図６（ｂ）は、従来の処理システムにおいて、準備を早く終えたＶＭ３２２のタイミングチャートである。図６（ｂ）の時刻Ｔ０と時刻Ｔ１、期間Ｐ０は図６（ａ）のそれと同値である。Ｔ２’は、準備を早く終えたＶＭ３２２の準備完了時刻を示す。Ｐ１’は、準備を早く終えたＶＭ３２２の準備時間であり、時刻Ｔ２’−時刻Ｔ０と同値である。また、Ｐ１＞Ｐ１’である。図６（ｂ）の場合、時刻Ｔ１のヘルスチェックの後、ヘルシーと判断されると、ＬＢ３２１からＶＭ３２２に対してリクエストが転送される。しかし、ヘルスチェックは時刻Ｔ１まで開始されないため、時刻Ｔ２’から時刻Ｔ１の期間でＶＭ３２２の準備が完了しているのにも関わらず、ＬＢ３２１はＶＭ３２２にリクエストを転送しない。その結果、無駄な時間が生じている。
【００３７】
図６（ｃ）は、本願発明を適用した場合の処理システム３２０内のＶＭ３２２のタイミングチャートである。図６（ｃ）の時刻Ｔ０、時刻Ｔ２、時刻Ｔ２’期間Ｐ０、および期間Ｐ１は、図６（ａ）、（ｂ）のそれと同値である。Ｔ１’は、本発明を適用した場合のヘルスチェック開始時刻を示し、Ｔ１＞Ｔ１’である。Ｐ０’は、本発明を適用した場合の準備期間を示し、Ｐ０＞Ｐ０’である。つまり、従来の処理システムに対して、本実施形態に係る処理システム３２０は、ヘルスチェック開始までの準備期間を短く設定している。したがって、準備期間Ｐ０’が経過すると、ヘルスチェックが開始される。
【００３８】
Ｔ３は、本発明で定義した準備期間Ｐ０’後に設けた新たな期間（以下、延命期間と呼ぶ）の終了時刻を示す。Ｔ３＞Ｔ１’である。延命期間中、ヘルスチェックエージェント４１０は、新たに定義する延命モードと呼ぶモードになる。通常モード時には、ヘルスチェックエージェント４１０がプロセス４２０に対してヘルスチェックを行い、プロセス４２０の全てに対して正常に稼働していることを確認できた場合にのみ、ＬＢ３２１に対して正常である旨のレスポンスを返す。一方、延命モード時には、Ｗｅｂサービス４００の全てのプロセスが稼働していなかった場合、ヘルスチェックエージェント４１０はＬＢ３２１に対して、ＶＭ３２２が正常である旨と異常である旨のレスポンスを交互に返す。Ｐ２は、延命期間を示しており、Ｔ３−Ｔ１’と同値である。つまり、延命期間Ｐ２は、準備期間Ｐ０’の経過後、設定される。時刻Ｔ３の延命期間終了後、ヘルスチェックエージェント４１０は延命モードから通常モードになる。
【００３９】
本実施形態に係るヘルスチェックエージェント４１０の処理の詳細は後述するが、延命モード時にはＶＭ３２２の起動準備が完了していない場合、正常である旨と異常である旨のレスポンスを交互に（選択的に）返す。そのため、ＬＢ３２１は、ＶＭ３２２の切り離しを行わない。つまり、異常である旨のレスポンスを一度受信したとしても、その時点では異常であるとは判定しない。
【００４０】
一方、準備が完了しているＶＭ３２２は正常である旨のレスポンスを返すため、ヘルスチェックによりヘルシーであることが確認できた時点でＬＢ３２１はＶＭ３２２に対してリクエストを転送できる。このように、延命期間を設けることで準備期間を短くすることができるため、準備が速いＶＭ３２２に関しては、準備が完了した段階でＬＢ３２１はリクエストを転送することができる。さらに、準備が遅いＶＭ３２２に関しては、予め設定した延命期間内であれば、何らかの理由で少し準備が遅れていたとしても、ＬＢ３２１から切り離されることなく、正常に稼働させることができる。
【００４１】
なお、ＶＭ３２２内のプロセスの起動順序はシステム開発者が指定することができるため、ＶＭ３２２が起動してからヘルスチェックエージェント４１０が起動するまでの時間を短くすることが可能である。ヘルスチェックエージェント４１０が起動するまでの時間を短くすることで、準備期間Ｐ０’を限りなく短くすることができ、効率的にＶＭ３２２や処理システム３２０をデプロイメントすることが可能になる。
【００４２】
［処理フロー］
図７は、ヘルスチェックエージェント４１０がヘルスチェックリクエストを受信した際にレスポンスを返すまでの処理を示すフローチャートである。なお、本処理フローの開始の起因となるヘルスチェックリクエストを受信した時点では、図６（ｃ）に示したような準備期間Ｐ０’（図５の設定項目「準備期間」に相当）は経過しているものとする。
【００４３】
本処理フローは、管理システム３１０を備えるサーバー１０１において、ＣＰＵ２０３が二次記憶装置２０６等に格納された各種プログラムを読み出して実行することにより実現される。図７（ａ）は、ヘルスチェックエージェント４１０の処理の全体の流れを示す。また、図７（ｂ）は、本実施形態に係る延命モード時の処理を示し、図７（ｃ）は、通常モード時の処理を示す。
【００４４】
Ｓ７０１にて、ヘルスチェックエージェント４１０は、クライアント３００から受信したヘルスチェックリクエストが初回の受信であるか否かを判定する。つまり、Ｗｅｂサービス４００が起動してから最初に受信したヘルスチェックリクエストか否かを判定する。初回の受信である場合（Ｓ７０１にてＹＥＳ）Ｓ７０２へ進み、そうでない場合は（Ｓ７０１にてＮＯ）Ｓ７０３へ進む。
【００４５】
Ｓ７０２にて、ヘルスチェックエージェント４１０は、自身の動作モードを延命モードに変更し、システム開発者が指定した延命期間の設定値に基づいて終了時刻（例えば、現在時刻から３００秒後など）を設定する。さらに、ヘルスチェックエージェント４１０は、最終的にヘルスチェックレスポンスとしてＬＢ３２１に返す値の候補値（「正常」あるいは「異常」である旨の値）に「異常」を設定する。
【００４６】
Ｓ７０３にて、ヘルスチェックエージェント４１０は、自身の動作モードが延命モードであるか否かを判定する。自身の動作モードが延命モードである場合は（Ｓ７０３にてＹＥＳ）Ｓ７０４に進み、そうでない場合は（通常モードである場合：Ｓ７０４にてＮＯ）Ｓ７０７に進む。
【００４７】
Ｓ７０４にて、ヘルスチェックエージェント４１０は、現在時刻が延命期間終了時刻（図６（ｃ）のＴ３に相当）に達していないかの判定を行う。つまり、ヘルスチェックエージェント４１０は、現在時刻が自身の延命期間内であるか否かの判定を行う。現在時刻が延命期間終了時刻に達していない場合（Ｓ７０４にてＹＥＳ）Ｓ７０５へ進み、そうでない場合は（Ｓ７０４にてＮＯ）Ｓ７０６へ進む。
【００４８】
Ｓ７０５にて、ヘルスチェックエージェント４１０は、図７（ｂ）に示す延命モード時の処理を開始する。ここでの処理については後述する。その後、本処理フローを終了する。
【００４９】
Ｓ７０６にて、ヘルスチェックエージェント４１０は、自身の動作モードを通常モードに変更する。
【００５０】
Ｓ７０７にて、ヘルスチェックエージェント４１０は、図７（ｃ）に示す通常モード時の処理を開始する。その後、本処理フローを終了する。
【００５１】
次に、図７（ｂ）を用いて、延命モード時の処理を説明する。これは、図７（ａ）のＳ７０５の工程に対応する。
【００５２】
Ｓ７１１にて、ヘルスチェックエージェント４１０は、Ｗｅｂサービス４００内の全てのプロセスに対してヘルスチェックを行い、全てのプロセスが正常に稼働しているかの確認を行う。全てのプロセスが正常に稼働している場合は（Ｓ７１１にてＹＥＳ）Ｓ７１２へ進み、そうでない場合は（Ｓ７１１にてＮＯ）Ｓ７１４へ進む。
【００５３】
Ｓ７１２にて、ヘルスチェックエージェント４１０は、自身の動作モードを通常モードに変更する。
【００５４】
Ｓ７１３にて、ヘルスチェックエージェント４１０は、「正常」のヘルスチェックレスポンスをＬＢ３２１に返す。その後、本処理フローを終了する。
【００５５】
Ｓ７１４にて、ヘルスチェックエージェント４１０は、Ｓ７０２で設定したヘルスチェックレスポンスの候補値を反転（「正常」なら「異常」に、「異常」なら「正常」）した上で再設定を行い、その値をレスポンスとしてＬＢ３２１に返す。そして、本処理フローを終了する。
【００５６】
次に、図７（ｃ）を用いて、通常モード時の処理を説明する。これは、図７（ａ）のＳ７０７の工程に対応する。
【００５７】
Ｓ７２１にて、ヘルスチェックエージェント４１０は、Ｗｅｂサービス４００内の全てのプロセスに対してヘルスチェックを行い、全てのプロセスが正常に稼働しているかの確認を行う。全てのプロセスが正常に稼働している場合は（Ｓ７２１にてＹＥＳ）Ｓ７２２へ進み、そうでない場合は（Ｓ７２１にてＮＯ）Ｓ７２３に進む。
【００５８】
Ｓ７２２にて、ヘルスチェックエージェント４１０は、「正常」のヘルスチェックレスポンスをＬＢ３２１に返す。そして、本処理フローを終了する。
【００５９】
Ｓ７２３にて、ヘルスチェックエージェント４１０は、「異常」のヘルスチェックレスポンスをＬＢ３２１に返す。そして、本処理フローを終了する。
【００６０】
なお、上記の処理フローの例では、図７（ａ）のＳ７０２にてヘルスチェックエージェント４１０はヘルスチェックレスポンスの候補値を設定し、図７（ｂ）のＳ７１４にて候補値を反転してレスポンスを返している。つまり、所定の回数連続して同じ内容の通知が行われることで、その通知による状態であると判定されることを防止している。この処理の目的は、ＶＭ３２２の起動準備中にヘルスチェックにて従来はアンヘルシーと判断される場合であっても、延命期間中であればＬＢ３２１からＶＭ３２２を切り離さないようにすることである。したがって、ヘルスチェックエージェント４１０のレスポンスの返し方は、ＬＢ３２１からＶＭ３２２が切り離されず、且つ、ＬＢ３２１からＶＭ３２２にリクエストが転送されないような返し方であれば別の方法で応答を通知してもよい。
【００６１】
例えば、図５に示す設定例５００の設定項目「正常閾値」と「異常閾値」を超えない範囲であれば、連続して同一のレスポンスを返すことは可能である。さらに、これまでの説明では異常・正常の連続発生回数の閾値をもとにヘルシー／アンヘルシーの判断を行っていたが、ＬＢ３２１に関する設定項目のパラメータはプラットフォームによって異なる。したがって、本発明においてはヘルシー／アンヘルシーの判断条件は閾値に限定せず、ヘルスチェックエージェント４１０は延命モード時に、ＬＢ３２１がヘルシーともアンヘルシーとも判断しないようなレスポンスの返し方をすれば特に方法は問わない。
【００６２】
以上、本実施形態により、仮想マシンの起動時間に変動がある場合においても、仮想マシンを効率的に利用可能な状態にすることを目的とする。
【００６３】
＜第２の実施形態＞
本願発明の第２の実施形態について説明する。前述した通り、ＶＭ３２２が起動開始後、Ｗｅｂサービス４００以外にもログ監視やウイルス検知、ファイル改竄検知などのサービス４３０が起動を開始する。第１の実施形態では、ＬＢ３２１のヘルスチェックリクエストを受けて、ヘルスチェックエージェント４１０がＷｅｂサービス４００内のプロセス４２０それぞれのヘルスチェックを行っていた。しかし、Ｗｅｂサービス４００に対するヘルスチェックが正常で、ＬＢ３２１がヘルシーと判断したとしても、サービス４３０の起動確認が終わっていない場合、ＶＭ３２２はリクエストを受け付けるべきではない。
【００６４】
そこで、第２の実施形態では、第１の実施形態でのヘルスチェックエージェント４１０の処理に加え、サービス４３０の起動確認を含めてＶＭ３２２の起動準備の確認を行う方法を説明する。なお、第２の実施形態においても処理システム３２０と同様のシステム構成を成しており、ＬＢ３２１に関する設定は図５の設定例５００と類似した設定がなされていることとして説明を行う。
【００６５】
図８は、本実施形態に係る、ヘルスチェック時にサービス４３０の起動確認も行う場合のＶＭ３２２の構成例を示す図である。サービス起動確認部８００は、サービス４３０の起動確認を行う。サービス起動確認部８００は、スクリプト実行部８０１、スクリプト８０２、および確認結果ファイル８０３を含んで構成される。
【００６６】
スクリプト実行部８０１は、スクリプト８０２を実行する。スクリプト実行部８０１は、サービス起動確認部８００に内包されているものを使用してもよいし、ＶＭ３２２内に予め配置されているものを使用してもよい。スクリプト実行部８０１が実行するスクリプト言語の種類は問わない。スクリプト実行部８０１はスクリプト８０２を実行し、その結果を確認結果ファイル８０３として出力する。また、スクリプト実行部８０１は、ＶＭ３２２が起動後、定期的にスクリプト８０２を実行する。
【００６７】
スクリプト８０２は、サービス４３０の起動を確認するためのスクリプトであり、スクリプト実行部８０１によって実行される。スクリプト８０２に記載するサービス４３０の起動確認のためのコードは、サービス４３０が起動しているか否かだけでなく、サービス４３０が正しい挙動を示しているか否かの確認を行うコードを含んでいてもよい。結果確認ファイル７０３は、スクリプト実行部８０１がスクリプト８０２を実行した結果を出力したファイルである。
【００６８】
ヘルスチェックエージェント４１０は、ＬＢ３２１からヘルスチェックリクエストを受信した際に確認結果ファイル８０３を確認し、サービス４３０が正常に起動しているかの確認を行う。本実施形態におけるヘルスチェックエージェント４１０は、第１の実施形態にて述べた図７（ｂ）のＳ７１１と図７（ｃ）のＳ７２１にてＷｅｂサービス４００内のプロセス４２０の起動確認と併せてサービス４３０の起動確認を行う。
【００６９】
なお、本実施形態では、ＶＭ３２２内のＷｅｂサービス４００とサービス４３０の全てが起動したことを確認することが目的であるが、ＶＭ３２２の起動準備が完了し、ヘルシーになった後も継続してサービス４３０の稼働確認を行ってもよい。
【００７０】
また、本実施形態では、サービス４３０の起動確認を行うために、一旦、確認結果ファイル８０３を出力し、それをヘルスチェックエージェント４１０が確認する方法を説明した。これは、スクリプト実行部８０１がスクリプト８０２の実行を終えるまでに時間がかかってしまい、ヘルスチェック時にＬＢ３２１とヘルスチェックエージェント４１０がタイムアウトしてしまう可能性を考慮しているためである。従って、ＬＢ３２１のタイムアウト時間内にＷｅｂサービス４００のヘルスチェックとスクリプト８０２の実行および結果の確認を終えることができれば、スクリプト８０２を定期的に実行し、その結果を取得するような構成でもよい。この場合、確認結果ファイル８０３を別途出力する必要はない。
【００７１】
以上、本実施形態により、第１の実施形態の効果に加え、サービスの起動状態を確認することで、適切な要求への応答が可能となる。
【００７２】
＜第３の実施形態＞
本願発明に係る第３の実施形態について説明する。第１、第２の実施形態では、クラウドサービスベンダが提供する従来のＬＢを利用して、ＶＭ側が適切にヘルスチェックレスポンスを返すことで、効率的にＶＭを利用可能な状態にする方法を説明した。
【００７３】
本実施形態では、第１、第２の実施形態で説明した延命期間の機能概念をロードバランサ側の機能として拡張し、効率的にＶＭを利用可能な状態にする方法を説明する。なお、本実施形態においても処理システム３２０と同様の構成を成しているものとするが、本実施形態ではＬＢ３２１の拡張機能について説明するため、ＶＭ３２２がヘルスチェックエージェント４１０を備えていることは想定しないものとする。
【００７４】
図９は、本実施形態に係るヘルスチェックとスケーリングに関する設定例９００であり、上述した図５の設定例５００の設定項目に加え、新たに設定項目「延命期間」９０１が設けられている。第１、第２の実施形態と同様に、設定項目「準備期間」９０１に設定した期間が終了した後に、延命期間が開始される。
【００７５】
延命期間中は、ＬＢ３２１がヘルシーと判断したＶＭ３２２に対してはリクエストを転送し、アンヘルシーと判断したＶＭ３２２に対しては切り離しを行わず、ヘルスチェックを継続する。一方、延命期間終了後は、ＬＢ３２１がヘルシーと判断したＶＭ３２２に対してはリクエストを転送し、アンヘルシーと判断したＶＭ３２２に対しては切り離しを行う。
【００７６】
なお、ＬＢ３２１は、Ｗｅｂサービス４００に対するＨＴＴＰリクエストによるヘルスチェックに基づいてリクエストの転送制御を行うため、サービス４３０が起動しているか否かの確認はＶＭ３２２側でしか行うことができない。本実施形態においては、第２の実施形態とは異なり、ＬＢ３２１側から見たＶＭ３２２の実装は不明であるため、サービス４３０の起動を含めてＶＭ３２２の準備が完了しているかは確認できない。しかし、システム開発者がＶＭ３２２内の各種サービスの起動順序を適切に設定し、設定項目「準備期間」と「延命期間」の値を調整することで、ＶＭ３２２を効率的に利用可能な状態にすることができる。また、設定項目「準備期間」の値を０秒に設定することは可能であり、延命期間のみでＶＭ３２２の起動準備を完了させることができれば、より効率的に処理システム３２０をデプロイメントすることができる。
【００７７】
図１０は、ＬＢ３２１配下のＶＭ３２２を管理するテーブル１０００の構成例を示す。このテーブル１０００は、クラウドサービスベンダが提供するプラットフォーム側でＬＢ３２１ごとに管理される。図１０のテーブル１０００に示す例では、５つのＶＭ（ＶＭ＿Ａ〜ＶＭ＿Ｅ）が管理されているものとする。
【００７８】
図１０に示すテーブル１０００は、「ＶＭ名」「連続正常回数」「連続異常回数」「稼働」「受付」「延命期間」のカラムを有する。カラム「ＶＭ名」は、ＬＢ３２１配下のＶＭ３２２を識別するためのユニークな値を示す。カラム「連続正常回数」は、ＬＢ３２１がＶＭ３２２に対して行ったヘルスチェックが連続で正常と判断された回数を示す。カラム「連続異常回数」は、ＬＢ３２１がＶＭ３２２に対して行ったヘルスチェックが連続で異常と判断された回数を示す。カラム「稼働」は、ＶＭ３２２の稼働状況を示す。カラム「稼働」の値が“ｔｒｕｅ”である場合はＶＭ３２２がその時点で稼働していることを示し、“ｆａｌｓｅ”である場合はＶＭ３２２がその時点でＬＢ３２１から切り離されていることを示す。
【００７９】
カラム「受付」は、ＬＢ３２１にヘルシーなＶＭ３２２であると判断され、ＬＢ３２１からリクエストが転送されるＶＭ３２２を示す。カラム「受付」の値が“ｔｒｕｅ”であるＶＭはＬＢ３２１からリクエストを受け付けるＶＭ３２２を示し、“ｆａｌｓｅ”であるＶＭはＬＢ３２１からリクエストを受け付けないＶＭ３２２を示す。ＶＭ３２２の稼働状況が“ｔｒｕｅ”であっても、ヘルシーと判断されていない場合には、カラム「受付」の値は“ｆａｌｓｅ”となる。カラム「延命期間」はＶＭ３２２が延命期間中であるか否かを示す。カラム「延命期間」の値が“ｔｒｕｅ”である場合は延命期間中であることを示し、“ｆａｌｓｅ”である場合は延命期間外であることを示す。
【００８０】
図１０に示すテーブル１０００におけるＶＭ３２２それぞれの状態を簡単に説明する。ＶＭ＿Ａは、ＬＢ３２１配下で正常に稼働しているＶＭ３２２である。ＶＭ＿Ｂは、正常に稼働していたが、ヘルスチェックで異常値のレスポンスを返し始めたＶＭ３２２である。ＶＭ＿Ｃは、ＬＢ３２１が過去にアンヘルシーであると判断し、既に切り離されたＶＭ３２２である。ＶＭ＿Ｄは、起動準備中のＶＭ３２２であり、起動中に異常が起こりつつある、あるいは起動準備が遅れているＶＭ３２２である。ＶＭ＿Ｅは、起動準備中のＶＭ３２２であり、正常に起動しているＶＭ３２２である。
【００８１】
［処理フロー］
図１１は、第３の実施形態に係るＬＢ３２１の処理の手順例を示すフローチャートである。処理フローは、管理システム３１０を備えるサーバー１０１において、ＣＰＵ２０３が二次記憶装置２０６等に格納された各種プログラムを読み出して実行することにより実現される。図１１（ａ）は、ＬＢ３２１がＶＭ３２２に対するリクエストを受け付けた際の処理の流れを示す。また、図１１（ｂ）は、ＬＢ３２１が配下のＶＭ３２２に対してヘルスチェックを行う際の処理を示す。
【００８２】
ＬＢ３２１がクライアント３００あるいは処理システム３２０内のＶＭ３２２からリクエストを受け付けた際に図１１（ａ）の処理が開始される。
【００８３】
Ｓ１１０１にて、ＬＢ３２１は、配下のＶＭ３２２がリクエストを受け付け可能か否かの判定を行う。リクエストを受け付け可能か否かは、図１０に示すテーブル１０００のカラム「受付」の値に基づいて判定することができる。
【００８４】
Ｓ１１０２にて、ＬＢ３２１は、Ｓ１１０１での判定結果に基づき、リクエストを受け付け可能なＶＭ３２２に対してリクエストを転送する。ＬＢ３２１がＶＭ３２２に対してリクエストを転送する際には、ＬＢ３２１に予め設定されている分散ポリシーに従ってリクエストを分散する。ここでは、分散ポリシーの詳細については説明を省略するが、リクエストの内容やリソースの状況などに基づいて分散が行われることとなる。そして、本処理フローを終了する。
【００８５】
ＬＢ３２１が配下のＶＭ３２２に対してヘルスチェックを行う際に、図１１（ｂ）の処理が開始される。
【００８６】
Ｓ１１１１にて、ＬＢ３２１は、ヘルスチェックにより正常なレスポンスが返されたか否かを判定する。正常と判定した場合は（Ｓ１１１１にてＹＥＳ）Ｓ１１１２へ進み、異常と判定した場合は（Ｓ１１１１にてＮＯ）Ｓ１１１５へ進む。
【００８７】
Ｓ１１１２にて、ＬＢ３２１は、図１０のテーブル１０００においてカラム「連続正常回数」の値をインクリメントし、カラム「連続異常回数」の値を“０”にする。
【００８８】
Ｓ１１１３にて、ＬＢ３２１は、テーブル１０００のカラム「連続正常回数」の値と図９の設定例９００の設定項目「正常閾値」の値を比較する。連続正常回数が正常閾値以上であった場合（Ｓ１１１３にてＹＥＳ）Ｓ１１１４へ進み、そうでない場合は（Ｓ１１１３にてＮＯ）本処理フローを終了する。
【００８９】
Ｓ１１１４にて、ＬＢ３２１は、Ｓ１１１３で連続正常回数が正常閾値以上であったＶＭ３２２をリクエスト受付可能であると判定して、テーブル１０００のカラム「受付」の値を“ｔｒｕｅ”に更新する。そして、本処理フローを終了する。
【００９０】
Ｓ１１１５にて、ＬＢ３２１は、テーブル１０００においてカラム「連続異常回数」の値をインクリメントし、カラム「連続正常回数」の値を０にする。
【００９１】
Ｓ１１１６にて、ＬＢ３２１は、Ｓ１１１１でヘルスチェックにより異常であると判定されたＶＭ３２２をリクエスト受け付け不可能であると判定し、テーブル１０００のカラム「受付」の値を“ｆａｌｓｅ”に更新する。
【００９２】
Ｓ１１１７にて、ＬＢ３２１は、テーブル１０００のカラム「連続異常回数」の値と図９の設定例９００の設定項目「異常閾値」の値とを比較する。連続異常回数が異常閾値以上であった場合（Ｓ１１１７にてＹＥＳ）Ｓ１１１８に進み、そうでない場合は（Ｓ１１１７にてＮＯ）本処理フローを終了する。
【００９３】
Ｓ１１１８にて、ＬＢ３２１は、テーブル１０００のカラム「延命期間」に基づいて、該ＶＭが延命期間中のＶＭ３２２であるか否かを判定する。延命期間中である場合は（Ｓ１１１８にてＹＥＳ）本処理フローを終了し、そうでない場合は（Ｓ１１１８にてＮＯ）Ｓ１１１９へ進む。
【００９４】
Ｓ１１１９にて、ＬＢ３２１は、該ＶＭをＬＢ３２１から切り離す。そして、本処理フローを終了する。
なお、第３の実施形態で説明した処理フローおよび図９、図１０に示すパラメータはＬＢ３２１の拡張機能を実現するための一例であり、これに限定されるものではない。
【００９５】
以上、本実施形態により、ロードバランサ側に延命期間に関する構成を設けることで、第１の実施形態と同様の効果を奏することができる。
【００９６】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００９７】
３００…クライアント、３１０…管理システム、３２０…処理システム、３２１…ロードバランサ（ＬＢ）、３２２…仮想マシン（ＶＭ）、３３０…データストア、３４０…リソース管理部、３５０…システム管理部、３６０…データストア、４００…Ｗｅｂサービス、４１０…ヘルスチェックエージェント、４２０…プロセス、４３０…サービス
【図１】
2018124827.tif 000003
【図２】
2018124827.tif 000004
【図３】
2018124827.tif 000005
【図４】
2018124827.tif 000006
【図５】
2018124827.tif 000007
【図６】
2018124827.tif 000008
【図７】
2018124827.tif 000009
【図８】
2018124827.tif 000010
【図９】
2018124827.tif 000011
【図１０】
2018124827.tif 000012
【図１１】
2018124827.tif 000013