(57)【要約】【課題】  クライアント環境の設定により、クライアントからのリクエストが第１の処理環境の装置に送信された場合であっても、該リクエストを第２の処理環境の仮想マシンで処理させることを可能とする。【解決手段】  管理システムは、負荷分散装置から、いずれの仮想マシンにリクエストを転送させるかを管理し、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないよう管理する。【選択図】  図５
2018088114.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからのリクエストを処理可能な複数の仮想マシンと、前記複数の仮想マシンにリクエストを転送する負荷分散装置とを少なくとも備える複数の処理環境を管理する管理システムであって、
負荷分散装置から、いずれの仮想マシンにリクエストを転送させるかを管理する管理手段を有し、
前記管理手段は、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から前記第１の処理環境とは別の第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないよう管理することを特徴とする管理システム。
【請求項２】
負荷分散装置から、転送先の候補となる仮想マシンへリクエストを転送可能であるか否かの確認を、前記負荷分散装置に対して指示する第１の指示手段を有し、
前記指示に基づき、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンへリクエストを転送可能であると確認された際に、前記第１の処理環境の負荷分散装置が受け付けたリクエストが前記第２の処理環境の仮想マシンに転送されることを特徴とする請求項１に記載の管理システム。
【請求項３】
前記管理手段は、前記第１の指示手段の指示に基づき、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンへリクエストを転送可能であると確認された際に、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないように管理することを特徴とする請求項２に記載の管理システム。
【請求項４】
クライアントからのリクエストを受け付ける装置についての設定は、前記管理システムがアクセス可能なＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバーで保持されることを特徴とする請求項１乃至３のいずれか１項に記載の管理システム。
【請求項５】
仮想マシンの生成または削除を実行するリソース管理部に対して指示を行う第２の指示手段を有し、
前記第２の指示手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更されてから第１の所定期間が経過した際に、前記第１の処理環境の仮想マシンを削除するための指示を前記リソース管理部に対して行うことを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
【請求項６】
前記第２の指示手段は、前記リソース管理部に対して、負荷分散装置の生成または削除の指示を更に行うことが可能であり、
前記第２の指示手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更されてから前記第１の所定期間よりも長い第２の所定期間が経過した際に、前記第１の処理環境の負荷分散装置を削除するための指示を前記リソース管理部に対して行うことを特徴とする請求項５に記載の管理システム。
【請求項７】
前記第２の指示手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更されてから前記第２の所定期間が経過した際に、前記第１の処理環境の負荷分散装置がクライアントからのリクエストを受け付けていない場合には、前記第１の処理環境の負荷分散装置を削除するための指示を前記リソース管理部に対して行うことを特徴とする請求項６に記載の管理システム。
【請求項８】
前記第２の処理環境の仮想マシンで動作するアプリケーションのバージョンは、前記第１の処理環境の仮想マシンで動作するアプリケーションのバージョンよりも新しいことを特徴とする請求項１乃至７のいずれか１項に記載の管理システム。
【請求項９】
前記第１の処理環境は複数存在することを特徴とする請求項８に記載の管理システム。
【請求項１０】
前記管理手段は、クライアントからのリクエストを受け付ける装置についての設定が、前記第１の処理環境の負荷分散装置から前記第２の処理環境の装置に変更された後、更に前記第１の処理環境の負荷分散装置へ変更された際に、
前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させるよう管理し、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させないよう管理し、前記第２の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第２の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させないよう管理することを特徴とする請求項１乃至８のいずれか１項に記載の管理システム。
【請求項１１】
クライアントからのリクエストを処理可能な複数の仮想マシンと、前記複数の仮想マシンにリクエストを転送する負荷分散装置とを少なくとも備える複数の処理環境を管理する管理システムの制御方法であって、
負荷分散装置からいずれの仮想マシンにリクエストを転送させるかを管理する管理工程を有し、
前記管理工程では、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から前記第１の処理環境とは別の第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストが転送されるよう管理され、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストが転送されないよう管理されることを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想マシンと負荷分散装置を含む処理環境を管理する管理システム、および制御方法に関する。
【背景技術】
【０００２】
近年、アプリケーションや仮想マシン、ストレージなどのコンピュータリソースをユーザが必要なときに必要な分だけ利用できるクラウドサービスが増えてきた。このようなクラウドサービスは、ＳａａＳ、ＰａａＳ、ＩａａＳなどと呼ばれ、クラウドサービスベンダが提供するアプリケーションやコンピュータリソースをユーザが独自に組み合わせて使用することができる。ユーザはクラウド上にシステムを構成することで、自身がサービスベンダとなり、エンドユーザにサービスを提供することができる。クラウドサービスベンダはユーザが利用したアプリケーションやコンピュータリソースの量に応じて課金する仕組みとなっている。
【０００３】
従来、システムを構築する際には提供する機能やサービスの規模を考慮した上でシステム構成を決定し、アプリケーションを動作させるためのコンピュータリソースを選定する必要があった。サービスを運用していく過程でシステム構成を変更したい場合や、システムへの負荷やパフォーマンスを考慮してマシンスペックを上げたい場合は、コンピュータリソースを変更・追加する必要がある。しかし、稼働中の環境においてコンピュータリソースを変更・追加することは容易ではなく、既存コンピュータリソースへの設定ファイルやプログラムのデプロイメントとシステムの切り戻しを考慮して停止時間を設けていた。
【０００４】
停止時間を設けなければならないことや作業中のオペレーションミスなどを改善するために、近年は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントと呼ばれるシステムバージョンアップの方法が利用されている。ここで、システムのバージョンアップとは、例えば、システム内の仮想マシンで実行されるアプリケーションのバージョンアップが含まれる。バージョンアップ後のシステムは、提供できる機能が追加されたり、管理するデータの種類や形式が変更されたりする。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピューターである。
【０００５】
ここで、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによるシステムバージョンアップの方法を説明する。まず、クラウドサービス上で、クライアントからのリクエストを受け付ける設定が行われている装置（ロードバランサ、仮想マシン）の属する処理環境が、本番環境として機能している。処理環境は、少なくとも、リクエストを処理する１以上の仮想マシンと、それらにリクエストを分散させる負荷分散装置として機能するロードバランサとを有する。そこで、処理環境をバージョンアップさせたい場合に、現行のバージョンの処理環境とは異なる、バージョンアップ後の処理環境をクラウドサービス上に更に構築する。その後、バージョンアップさせたいタイミングになったら、クライアントからのリクエストを受け付ける装置についての設定の変更などを行い、本番環境として機能させる処理環境を切り替える。この切り替えによって、システムのバージョンアップが実現される。ここで、接続先を切り替える方法としては、サービス提供者が管理するＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバーのＤＮＳレコードが記載された設定ファイルを書き換えるという方法などがある。
【０００６】
特許文献１には、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによるシステムバージョンアップの方法が記載されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１６−１１５３３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したＢｌｕｅ−Ｇｒｅｅｎデプロイメントの実行によって、本番環境として機能する処理環境が切り替えられたにも関わらず、旧本番環境の負荷分散装置がクライアントからのリクエストを受け付けてしまうことがある。例えば、クライアント環境の設定として、クライアントのローカルネットワーク環境にあるＤＮＳサーバーの更新が遅れていたり、クライアントのキャッシュサーバーなどで古いＤＮＳキャッシュを保持し続けていたりする場合がある。そのような場合に、クライアントがリクエストを送信する際に、古いＤＮＳレコードが名前解決に使用される。すると、本番環境として機能する処理環境が切り替えられたにも関わらず、クライアントからのリクエストは、旧本番環境（第１の処理環境）が受け付けることとなり、現在の本番環境（第２の処理環境）で処理されなくなってしまう。つまり、バージョンアップ後のサービスがクライアントへ提供されなくなってしまう。また、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントが実行された直後に、新しいバージョンの処理環境（第１の処理環境）での異常発生により本番環境を古いバージョンの処理環境（第２の処理環境）に戻した場合においても、同様である。
【０００９】
本発明は、クライアント環境の設定により、クライアントからのリクエストが第１の処理環境の装置に送信された場合であっても、該リクエストを第２の処理環境の仮想マシンで処理させることを可能とするための仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明は、クライアントからのリクエストを処理可能な複数の仮想マシンと、前記複数の仮想マシンにリクエストを転送する負荷分散装置とを少なくとも備える複数の処理環境を管理する管理システムであって、負荷分散装置から、いずれの仮想マシンにリクエストを転送させるかを管理する管理手段を有し、前記管理手段は、クライアントからのリクエストを受け付ける装置についての設定が、第１の処理環境の負荷分散装置から前記第１の処理環境とは別の第２の処理環境の装置に変更された際に、前記第１の処理環境の負荷分散装置から前記第２の処理環境の仮想マシンにリクエストを転送させるよう管理し、かつ、前記第１の処理環境の負荷分散装置から前記第１の処理環境の仮想マシンにリクエストを転送させないよう管理することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、クライアント環境の設定により、クライアントからのリクエストが第１の処理環境の装置に送信された場合であっても、該リクエストを第２の処理環境の仮想マシンで処理させることが可能となる。
【図面の簡単な説明】
【００１２】
【図１】ネットワークシステム構成の一例を示す図
【図２】情報処理機能を有するハードウェアの構成例を示す図
【図３】クラウドシステムの構成例を示す図
【図４】コンピュータリソースの設定値を管理するテーブルの一例を示す図
【図５】Ｂｌｕｅ−Ｇｒｅｅｎデプロイメント実行後のクラウドシステムの構成例を示す図
【図６】デプロイ処理の手順例を示すフローチャート
【図７】実施例２のクラウドシステムの構成例を示す図
【図８】処理環境のバージョン管理テーブルの例を示す図
【図９】バージョン管理テーブルの更新の手順例を示すフローチャート
【図１０】旧Ｂｌｕｅのコンピュータリソースの削除処理の手順例を示すフローチャート
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１４】
（実施例１）
図１は、本発明の実施形態に係るネットワークシステム構成の一例を示す図である。情報処理装置１０４は、光回線などでプロバイダ１０３と通信し、プロバイダ１０３を介してインターネット１０２と繋がるＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）やプリンター、複合機などである。情報処理端末１０７は基地局１０６と無線で通信し、コアネットワーク１０５を介してインターネット１０２と繋がる端末で、例えばタブレットやスマートフォン、ノートＰＣなどである。情報処理端末１０７には、無線通信機能を備えたデスクトップＰＣやプリンターなども含まれる。サーバー１０１は、インターネット１０２を介し、各情報処理端末にＷｅｂページやＷｅｂ  ＡＰＩを提供するクラウドシステムとして機能する。本実施例のクラウドシステムは、ＩａａＳやＰａａＳなどのクラウドサービスによって提供されるプラットフォームやリソースを利用して構築される、ネットワークデバイスやそれらを保有する顧客を管理するためのサービスを提供するシステムである。なお、複数台のサーバー１０１によってクラウドシステムが構築されてもよい。
【００１５】
図２は、サーバー１０１、情報処理装置１０４、情報処理端末１０７、およびクラウドシステムが構築されるデータセンター上に存在するサーバーコンピューターなどの情報処理機能を有するハードウェアの構成例を示す図である。
【００１６】
入出力インターフェース２０１は、ディスプレイ、キーボード、マウス、タッチパネル、ボタンなどによる、情報や信号の入出力を行う。なお、これらのハードウェアを備えないコンピューターは、リモートデスクトップやリモートシェルなどにより、他のコンピューターから接続・操作することも可能である。ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行う。ＲＯＭ２０４には、組込済みプログラムおよびデータが記録されている。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤやフラッシュメモリに代表されるような記憶装置である。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行する。各部は、内部バス２０７を介して接続されている。サーバー１０１などは、ＲＯＭ２０４に格納されているプログラムを実行するＣＰＵ２０３を備え、内部バス２０７を介して各部を総括的に制御する。
【００１７】
図３は、クラウドシステムの構成例を示す図である。図３（ａ）は、クラウドシステムの全体構成の一例を示す図である。３０１はサービスを提供するために必要なコンピュータリソースから構成されるクラウドシステムである。３０２はクラウドシステム３０１で管理するサービスを利用する情報処理装置１０４、情報処理端末１０７などの情報処理機能を有するクライアントである。
【００１８】
３１０は、ロードバランサ３１１、仮想マシン３１２、キュー３１３および仮想マシン３１４を含む処理環境である。処理環境３１０は、クライアント３０２からのリクエストを受け付ける設定がＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバー３４０によって行われている。ＤＮＳサーバー３４０の設定において、クライアントからのリクエストを受け付ける設定が行われている装置（ロードバランサ、仮想マシンなど）の属する処理環境を、以下では、Ｂｌｕｅ環境または本番環境と呼ぶ。３１１はＢｌｕｅ環境のロードバランサ（負荷分散装置）であり、クライアント３０２からのリクエストを受け付ける。なお、ロードバランサはリクエストの分散先である仮想マシンに対して、ヘルスチェックを定期的に実行しているものとする。ヘルスチェックでは、仮想マシンが正常に稼働しているか、仮想マシンと通信可能であるかなどの確認が行われる。３１２はロードバランサ３１１によるリクエストの転送先であり、転送されたリクエストを処理可能な仮想マシン（以下ＶＭと呼ぶ）である。ここで、仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピューターである。ＶＭ３１２は、単位時間あたりのリクエスト数やＶＭ３１２自身のリソースの使用率に応じて自動的にスケールアウトする設定がなされていてもよい。
【００１９】
３１３は、ＶＭ３１２が処理依頼を示すデータを格納するキューである。３１４はキューに格納されるデータ（タスク、メッセージなどとも呼ばれる）を定期的に取得して処理するＶＭである。ＶＭ３１４はキュー３１３の存在により、通常はＶＭ３１２のように自動的にスケールアウトされる設定を行われない。ただし、キュー３１３に格納されるデータを規定時間内に処理できない場合や、キュー３１３自身が定期的にＶＭ３１４に対してデキューを行う場合などには、自動的にスケールアウトする設定がなされていてもよい。
【００２０】
３２０は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントの実行後に本番環境となる処理環境である。３２０内のＶＭでは、３１０内のＶＭと比べて、バージョンアップされたアプリケーションが動作する。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントの実行後に本番環境となる処理環境を、以下では、Ｇｒｅｅｎ環境と呼ぶ。３２１はＧｒｅｅｎ環境のロードバランサであり、３２２はロードバランサ３２１によるリクエストの分散先となるＶＭである。ＶＭ３２２は、Ｂｌｕｅ環境のＶＭ３１２と比較して、バージョンアップされたアプリケーションが動作している。３２３は、ＶＭ３２２が処理依頼を示すデータを格納するキューである。３２４はキューに格納されるデータを定期的に取得して処理するＶＭである。ＶＭ３２４は、Ｂｌｕｅ環境のＶＭ３１４と比較して、バージョンアップされたアプリケーションが動作している。Ｇｒｅｅｎ環境には、通常はクライアント３０２からリクエストが送信されることはない。ただし、テスト目的などで、クライアント３０２やシステム管理部３６０などがＧｒｅｅｎ環境のエンドポイントを指定してリクエストを送信した場合は、Ｂｌｕｅ環境と同様に処理を実行することも可能である。
【００２１】
上述したように、Ｂｌｕｅ環境３１０とＧｒｅｅｎ環境３２０はそれぞれ、基本的には同じ構成を備えている。ただしバージョンアップに伴い、Ｇｒｅｅｎ環境は、Ｂｌｕｅ環境と比較して、コンピュータリソースの数やスペックないしはアプリケーションロジックが変更されている。
【００２２】
ここで、クラウドサービスを利用して構築されるシステムは、比較的短期間でバージョンアップを繰り返すことが多く、一日に数十回、数百回とバージョンアップされる場合もある。そのような場合においても、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントを行うことにより、サービス提供者はコンピュータリソースの変更やアプリケーションのバージョンアップも無停止かつ容易に行うことができる。また、サービスは止まることがないため、クライアントはサービス側の変更を意識することなく、継続的にサービスを利用することができる。
【００２３】
接続先の切り替えでは、ＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）を変更せずに、外部リクエストの接続先が新たな本番環境へ切り替わるように設定ファイルが書き換えられる。クライアントは、更新されたＤＮＳレコードをもとに名前解決を行うため、ＦＱＤＮの変更を行うことなく新しい本番環境へリクエストを送信することができる。しかしながら、サービス提供者が管理するＤＮＳサーバーでＴＴＬ（Ｔｉｍｅ  ｔｏ  Ｌｉｖｅ）を設定していたとしても、エンドユーザの階層上にあるＤＮＳサーバーの更新間隔が必ずしも保証されるわけではない。例えば、クライアントのローカルネットワーク環境にある特定のＤＮＳサーバーで更新が遅れていたり、クライアントのキャッシュサーバーなどでＤＮＳキャッシュを保持し続けていたりする場合に、更新前の古いＤＮＳレコードが名前解決に使用される。したがって、クライアントからのリクエストは、新しいバージョンである現在の本番環境ではなく、古いバージョンである旧本番環境で処理されてしまう。
【００２４】
図３（ａ）の説明に戻る。３３０はＢｌｕｅ環境３１０やＧｒｅｅｎ環境３２０が使用するデータストアである。データストア３３０は、冗長化目的で複数配置されていたり、システムの特性により異なる種類のデータストアが複数配置されていたりしてもよい。なお、図３ではＢｌｕｅ環境とＧｒｅｅｎ環境でデータストアを共有しているが、それぞれの処理環境ごとにデータストアが配置されていてもよい。３４０はＤＮＳレコードなどが記載された設定ファイルとして、ドメイン情報やクラウドシステム３０１内の各エンドポイントの紐付け情報を管理するＤＮＳサーバーである。後述するリソース管理部３５０がＤＮＳサーバー３４０の設定ファイルを書き換えることで、Ｂｌｕｅ環境とＧｒｅｅｎ環境を切り替えるＢｌｕｅ−Ｇｒｅｅｎデプロイメントを実現している。具体的にはリソース管理部３５０が、ロードバランサ３１１、３２１のエンドポイントをクラウドシステム３０１で管理するサービスの正式なＦＱＤＮに紐付けるようにＤＮＳサーバー３４０の設定ファイルを書き換えることで処理環境の切り替えを行っている。
【００２５】
図３（ｂ）は、リソース管理部の構成の一例を示す図である。３５０は、クラウドシステム３０１内のコンピュータリソースの監視や操作を行うためのリソース管理部で、クラウドサービスベンダによって提供される機能である。３５１は、処理環境やデータストアなどのコンピュータリソースを生成する機能を有するリソース生成部である。３５２は、ＤＮＳサーバー３４０の設定ファイル（後述する図４（ａ））を更新する機能を有する設定値更新部である。設定値更新部３５２は、システム管理部３６０のリソース操作部３６１から指示を受けて、ＤＮＳサーバー３４０の設定ファイルを直接書き換えたり、各コンピュータリソースが提供するＡＰＩを呼び出したりすることによって設定値の更新を行う。３５３はクラウドシステム３０１内のコンピュータリソースの状態やアクセスログ、動作ログを監視する機能を有するリソース監視部である。３５４はクラウドシステム３０１内のコンピュータリソースを削除する機能を有するリソース削除部である。リソース削除部３５４は、予め削除処理をスケジューラに登録しておくことで、定期的に不要なコンピュータリソースを削除するように設定されていてもよい。
【００２６】
図３（ｃ）は、システム管理部の構成の一例を示す図である。３６０は、クラウドシステム３０１内の各コンピュータリソースを操作するためにリソース管理部３５０に対して指示を出すシステム管理部である。システム管理部３６０は、本実施例の管理システムとして機能し、クラウドシステム３０１を管理するシステム開発者によって作成される。システム管理部３６０は、ＤＮＳサーバー３４０、リソース管理部３５０および管理用データストア３７０と通信可能である。３６１は、クラウドシステム３０１を管理するシステム開発者の開発ＰＣなどからリクエストを受け付け、クラウドシステム３０１のコンピュータリソースを操作するために前述したリソース管理部３５０の各部に対して指示を出すリソース操作部である。リソース操作部３６１は、各処理環境の構成情報を管理するテーブル（後述する図４（ｂ））や、各処理環境のロードバランサの設定情報を管理するテーブル（後述する図４（ｃ））などを管理する。３６２は、各処理環境の動作・通信確認を行うためのテスト用リクエストを処理環境に送信する機能を有するアプリケーションテスト部である。アプリケーションテスト部３６２（以下、テスト部３６２）は、クラウドシステム３０１を管理するサービス提供者が予め作成したテストを管理用データストア３７０などに配置しておく。テスト部３６２は、テストを実行する際にテストツールなどを用いてテスト用リクエストを任意の処理環境に対して送信する。また、テスト部３６２はリソース管理部３５０を介して、ロードバランサ３１１、３２１からＶＭ３１２、３２２に対してヘルスチェックを実行する指示を出すことも可能である。３７０はリソース操作部３６１の指示を記した管理用プログラムや処理環境３１０、３２０のアプリケーションプログラム、アクセスログなどのクラウドシステム３０１内で使用・生成されるデータを格納する管理用のデータストアである。
【００２７】
図４は、コンピュータリソースの設定値を管理するテーブルの一例を示す図である。後述するが、図４の各テーブルの設定値は、図５のＤＮＳサーバー３４０および処理環境５１０、５２０の状態に関係する。また、本実施例では、テーブルのようなマトリクス形式で設定値を管理しているが、ＪＳＯＮのようなキーバリュー形式の設定ファイルとして管理することも可能である。
【００２８】
図４（ａ）で示す４００は、ＤＮＳサーバー３４０のＤＮＳレコードが記載された設定ファイルである。設定ファイル４００は、ＤＮＳサーバー３４０で保持される。クライアント３０２は設定ファイル４００をもとに名前解決を行う。４０１はクライアント３０２がＢｌｕｅ環境３１０にリクエストを送信する際の宛先となるホスト名を示している。４０２はＤＮＳレコードのレコードタイプを示している。４０３は４０１で設定されているホスト名に紐付けるエンドポイントの宛先を示している。４０４は各ＤＮＳレコードが有効である期間を示すＴＴＬである。４０５は各レコードが有効であるか無効であるかを示している。
【００２９】
図４（ｂ）で示す４１０は、各処理環境の構成情報を管理するテーブルである。テーブル４１０は、管理用データストア３７０で保持される。リソース生成部３５１や設定値更新部３５２、リソース削除部３５４により処理環境および処理環境内のコンピュータリソースが生成、更新、削除された場合に、リソース操作部３６１により管理テーブル４１０は更新される。４１１は処理環境のシステムバージョンを示している。システムバージョンはリソース生成部３５１により処理環境が生成された際に発行される処理環境を区別するためのユニークなＩＤである。４１２はロードバランサ３１１、３２１などのクライアント３０２からアクセス可能な外部公開されているロードバランサを示すユニークなＩＤである。４１３はＶＭ３１２、３２２などの処理環境のフロントエンドサーバーに該当するＶＭを示すユニークなＩＤである。４１４はキュー３１３、３２３などの処理環境のキューに該当するキューを示すユニークなＩＤである。４１５はＶＭ３１４や３２４などの処理環境のバックエンドサーバーやバッチサーバーに該当するＶＭを示すユニークなＩＤである。
【００３０】
４１６は、処理環境内のロードバランサがリクエストを転送する対象となるＶＭを示す設定値である。処理環境内のロードバランサは、４１６で示すＶＭのいずれかにリクエストを転送する。４１６の設定値は、Ｂｌｕｅ−Ｇｒｅｅｎ切り替え後に、リソース操作部３６１により更新される。管理テーブル４１０では、１行目（“ＳＹＳＴＥＭ  ＶＥＲＳＩＯＮ”が２０１６０１０１−００００００の行）の処理環境は、４１２に記載のロードバランサでリクエストを受けた後、４１６に設定されたＶＭにリクエストを転送することを示している。管理テーブル４１０の１行目の処理環境では、４１２に記載のロードバランサは管理テーブル４１０の２行目の処理環境に記載の４１３のＶＭに対してリクエストを転送している。管理テーブル４１０の２行目の処理環境では、４１６が“ｍｙｓｅｌｆ”であるため、他の処理環境のＶＭではなく、同じ処理環境のＶＭにリクエストを転送していることを示す。つまり、管理テーブル４１０で、ロードバランサ４１２と、リクエストの転送先となるＶＭ４１６との対応付けが管理されている。
【００３１】
つまり、ここでは、１行目の処理環境が旧本番環境で、２行目の処理環境が現在の本番環境であり、旧本番環境のロードバランサから本番環境のＶＭにリクエストが転送されることを示している。また、本番環境のロードバランサは、従来通り、本番環境のＶＭにリクエストを転送する。なお、テーブル４１０は処理環境のシステム構成によってテーブル定義が変わるため、処理環境構成情報を管理するテーブルはテーブル４１０のテーブル定義に限定するわけではない。
【００３２】
図４（ｃ）で示す４２０は、各処理環境のロードバランサの設定情報を管理するテーブルである。テーブル４２０は、管理用データストア３７０で保持される。リソース生成部３５１や設定値更新部３５２、リソース削除部３５４によりロードバランサが生成、更新、削除された場合に、リソース操作部３６１によりテーブル４２０が更新される。４２１はロードバランサ３１１、３２１などのクライアント３０２からアクセス可能な外部公開されているロードバランサを示すユニークなＩＤであり、４１２と対応している。４２２はロードバランサのエンドポイントを示す値であり、ＤＮＳ名やＩＰアドレスが設定されている。４２３はロードバランサのファイアウォールの設定値を示している。ファイアウォールの設定値４２３には通信を許可するプロトコルやポート、インバウンド、アウトバウンドのルールなどが記載されている。４２４はヘルスチェックの設定値を示している。ヘルスチェックの設定値４２４には、ヘルスチェックで送信するリクエストの宛先やポート番号、ヘルスチェックが正常であるためのルールなどが記載されている。ファイアウォールの設定値４２３やヘルスチェックの設定値４２４は、図４のようにテーブル４２０には設定ファイルを指定してもよいし、直接値を設定してもよい。
【００３３】
図５は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメト実行後の処理環境の構成例を示す図である。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメント実行後とは、設定値更新部３５２が設定ファイル４００を書き換えることで、クラウドシステム３０１で管理するサービスの正式なＦＱＤＮとロードバランサのＤＮＳ名などの紐付けを切り替えた後のことを意味する。Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントのことを、以下では単に切り替えと呼ぶ。
【００３４】
５０２は、切り替え後にクライアントのネットワーク環境でＤＮＳキャッシュが更新されないなどが原因で、旧処理環境にリクエストを送信し続けるクライアントである。５０３は、切り替え後に正しく新処理環境にリクエストを送信するクライアントである。５１０は切り替え後の旧処理環境である。以下旧処理環境のことを旧Ｂｌｕｅ環境とも呼ぶ。一方、５２０は新処理環境であり、以下Ｂｌｕｅ環境とも呼ぶ。旧Ｂｌｕｅ環境は切り替え後も稼働している。
【００３５】
前述した通り、図４の管理テーブル４１０の１行目の処理環境と旧Ｂｌｕｅ環境５１０の処理環境は対応している。５１１は旧Ｂｌｕｅ環境のロードバランサであり、管理テーブル４１０の１行目の処理環境の４１２と対応している。切り替え後であっても旧Ｂｌｕｅ環境は稼働し続けているため、ロードバランサ５１１はクライアント５０２からのリクエストを受け付ける。切り替え後、リソース操作部３６１は、ロードバランサ５１１からＶＭ５２２にリクエストを転送させるようにロードバランサ５１１の設定値を更新する。さらに、リソース操作部３６１は、ロードバランサ５１１からＶＭ５１２にリクエストを転送させないようにロードバランサ５１１の設定値を更新する。このとき、管理テーブル４１０の１行目（旧Ｂｌｕｅ環境５１０の処理環境構成情報）の４１６には管理テーブル４１０の２行目（Ｂｌｕｅ環境５２０の処理環境構成情報）の４１３（ＶＭ５２２）が設定値としてリソース操作部３６１により更新される。この更新により、旧Ｂｌｕｅ環境５１０のエンドポイントであるロードバランサ５１１がクライアント５０２からリクエストを受けた場合でも、実際のリクエストの転送先はＶＭ５２２であるため、Ｂｌｕｅ環境にリクエストを転送する。なお、ＶＭ５１２、キュー５１３、ＶＭ５１４は稼働しているため、新規にリクエストが転送されることはないが、処理中のリクエストは正常に処理される。５２０は切り替え後の新処理環境であり、前述した通りＢｌｕｅ環境に相当する処理環境である。Ｂｌｕｅ環境は、クラウドシステム３０１で管理するサービスの正式なＦＱＤＮと紐付いたロードバランサ５２１を有する処理環境である。
【００３６】
また、図４の管理テーブル４１０の２行目の処理環境とＢｌｕｅ環境５２０の処理環境は対応している。５２１はＢｌｕｅ環境のロードバランサである。ロードバランサ５２１は、切り替え後にクライアントのネットワーク環境でＤＮＳキャッシュが更新され、正しく送信されたリクエストを受け付けるロードバランサである。ロードバランサ５２１は、旧ＢｌｕｅリクエストをＶＭ５２２に転送し、その後、キュー５２３、ＶＭ５２４へと処理を渡していく。Ｂｌｕｅ環境５２０では旧Ｂｌｕｅ環境５１０とは違い、クライアント５０３からのリクエストを他の処理環境に転送する必要がないため、管理テーブル４１０は更新されない。
【００３７】
なお、旧Ｂｌｕｅ環境５１０のロードバランサ５１１がクライアントからのリクエストを受け付けた際に、送信元となるクライアントにエラーを返すなどして、クライアントに新しいＤＮＳレコードを取得させるといったことも考えられる。ただし、クラウドシステム３０１にアクセスする全てのクライアントにそのような仕組みを設ける必要がある。
【００３８】
図６は、デプロイ処理の手順例を示すフローチャートである。図６のフローチャートに示す処理は、システム管理部３６０により実行される。すなわち、図６のフローチャートの処理は、データセンター上のサーバーコンピューターのＣＰＵ２０３が、ＲＯＭ２０４または二次記憶装置２０６に記録されたプログラムを読み出して実行することにより実現される。
【００３９】
Ｓ６０１では、リソース操作部３６１が、リソース生成部３５１に対してＧｒｅｅｎ環境の構築を指示する。Ｇｒｅｅｎ環境が構築されると、テーブル４１０および４２０に各種コンピュータリソースの情報が追加される。Ｓ６０２では、リソース操作部３６１が、設定値更新部３５２に対して、Ｂｌｕｅ−Ｇｒｅｅｎ切り替えの実行を指示する。具体的には、ＤＮＳサーバー３４０の設定ファイルが更新されることで、クラウドシステムの外部にいるクライアントからのリクエストを受け付けるロードバランサが変更される。Ｓ６０３では、リソース操作部３６１が、設定値更新部３５２に問い合わせて、正常に切り替えが行われたことが確認された場合はＳ６０４を実行し、正常に切り替えが行われなかったことが確認された場合は、本フローチャートの処理を終了する。Ｓ６０４ではテスト部３６２がＢｌｕｅ環境５２０に対して動作・通信確認テストを行うなどして正常に稼働しているか確認する。テスト部３６２は、Ｂｌｕｅ環境５２０が正常に稼働していると判断した場合はＳ６０５を実行し、正常に稼働していないと判断した場合はＳ６１０を実行する。
【００４０】
Ｓ６０５では、リソース操作部３６１が、旧Ｂｌｕｅ環境５１０のロードバランサ５１１とＢｌｕｅ環境５２０のＶＭ５２２とを対応付けるようにテーブル４１０を更新する。具体的には、管理テーブル４１０の１行目の４１６に、管理テーブル４１０の２行目の４１３のＶＭが、リクエストの転送先の候補として追加される。この対応付けが行われた時点では、旧Ｂｌｕｅ環境５１０のロードバランサ５１１からＢｌｕｅ環境５２０のＶＭ５２２へのヘルスチェックが完了していないため、クライアント５０２からのリクエストはＢｌｕｅ環境５２０のＶＭ５２２に転送されない。Ｓ６０６ではテスト部３６２が、旧Ｂｌｕｅ環境５１０のロードバランサ５１１に、Ｓ６０５で追加したＢｌｕｅ環境５２０のＶＭ５２２に対してヘルスチェックを行うように指示する。ヘルスチェックでは、仮想マシンが正常に稼働しているか、仮想マシンと通信可能であるかなどの確認が行われる。なお、旧Ｂｌｕｅ環境５１０のロードバランサ５１１からＢｌｕｅ環境５２０のＶＭ５２２へのヘルスチェックを実行する際に、旧Ｂｌｕｅ環境５１０とＢｌｕｅ環境５２０でロードバランサの設定値に差異があり、ヘルスチェックが失敗する可能性がある。従って、テスト部３６２は、テーブル４２０の情報をもとにＢｌｕｅ環境５２０のロードバランサ５２１の設定値を旧Ｂｌｕｅ環境５１０のロードバランサ５１１に適用した上でヘルスチェックの実行指示を出してもよい。Ｓ６０７ではテスト部３６２がＳ６０６で実行したヘルスチェックの結果に基づき、Ｂｌｕｅ環境５２０のＶＭ５２２にリクエストを転送可能であると確認された場合はＳ６０８を実行し、転送可能でないと確認された場合はＳ６１２を実行する。なお、ヘルスチェックに失敗した場合も、テスト部３６２はＳ６１２を実行する。
【００４１】
Ｓ６０８ではリソース操作部３６１が、旧Ｂｌｕｅ環境５１０のロードバランサ５１１に対して、クライアント５０２からのリクエストをＳ６０５で追加したＢｌｕｅ環境５２０のＶＭ５２２へ転送するように指示する。Ｓ６０９ではリソース操作部３６１は、クライアント５０２からのリクエストが旧Ｂｌｕｅ環境のＶＭに転送されないように、旧Ｂｌｕｅ環境５１０のロードバランサ５１１とＶＭ５１２との対応付けを解除するようにテーブル４１０を更新する。すなわち、リソース操作部３６１が、管理テーブル４１０の１行目の処理環境の４１３、４１４、４１５に設定された値を削除したり、あるいは取り外しフラグを付与したりするなどして、管理テーブル４１０を更新する。ロードバランサ５１１の設定で、ロードバランサ５１１からリクエストの分散先であるＶＭ５１２への通信を閉塞できる場合は、ロードバランサ５１１とＶＭ５１２との対応付けを解除せず、通信を閉塞するだけでもよい。通信を閉塞する場合においても同様に、リソース操作部３６１が管理テーブル４１０の４１３、４１４、４１５の設定値を更新する。その後、本デプロイ処理を終了する。
【００４２】
Ｓ６１０ではリソース操作部３６１は、設定値更新部３５２に対して、Ｓ６０２で実行した設定ファイル４００の更新を再度実行し、Ｂｌｕｅ環境５２０から旧Ｂｌｕｅ環境５１０へ切り戻すよう指示する。Ｓ６１１ではリソース操作部３６１は、切り戻しにより旧Ｂｌｕｅ環境になった処理環境５２０のロードバランサ５２１に、切り戻しによりＢｌｕｅ環境になった処理環境５１０のＶＭ５１２を、追加するようにテーブル４１０を更新する。なお、Ｓ６１１の時点では、クライアントからのリクエストはＶＭ５１２にはまだ転送されない。
【００４３】
Ｓ６１２ではリソース操作部３６１は、Ｂｌｕｅ環境のＶＭと旧Ｂｌｕｅ環境の外部公開しているロードバランサとの対応付けを解除するようにテーブル４１０を再度更新し、デプロイ処理を終了する。なお、ヘルスチェックが不要である場合は、Ｓ６０６およびＳ６０７を省略して、Ｓ６０８に処理を進めてもよい。また、Ｓ６０８でリソース操作部３６１がロードバランサ５１１に対する指示を行わずに、図４（ｂ）のテーブルで対応付けが行われたことに応じて、ロードバランサ５１１がＶＭ５２２へリクエストを転送してもよい。
【００４４】
本実施例で説明したように、処理環境５２０がクライアントからのリクエストを受け付ける設定がＤＮＳサーバーのレコードで保持されている場合であっても、処理環境５１０のロードバランサがクライアントからのリクエストを受け付けることがある。その場合に、本実施例では、システム管理部３６０が、処理環境５１０のロードバランサと処理環境５２０の仮想マシンとの対応付けを行い、かつ、処理環境５１０のロードバランサと処理環境５１０の仮想マシンとの対応付けを解除した。本実施例により、ＤＮＳサーバーで本番環境として設定されていない処理環境の負荷分散装置が受け付けたリクエストを、本番環境として設定されている処理環境の仮想マシンで処理することが可能となる。
【００４５】
（実施例２）
実施例１では切り替え後のＢｌｕｅ環境と旧Ｂｌｕｅ環境の２つの環境に対して、ロードバランサからＶＭにリクエストを転送するための設定値の更新フローを説明した。しかし、処理環境のバージョンアップが頻繁に行われる場合、並存する環境は２つに限られない。バージョンアップごとに処理環境を作成して、不要になった処理環境を削除するというデプロイメント手法がしばしば用いられる。つまり、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントにおいて接続先の切り替えが完了し、システムに問題がないことが確認できた場合には、旧本番環境は不要となるため旧本番環境を削除することも可能である。そのような場合においても実施例１で説明した同様の理由で、古い処理環境にリクエストを送信し続けるクライアントは存在するため、クライアントのリクエスト送信先を最新バージョンの処理環境に向ける必要がある。実施例２では実施例１の応用例として、本番環境ではない処理環境が複数存在する場合の処理環境の管理方法について説明する。
【００４６】
図７は、切り替え後に処理環境が３以上存在する場合のクラウドシステム構成例を示す図である。７０２と７０３は実施例１と同様に、クライアントのネットワーク環境でＤＮＳキャッシュが更新されないなどが原因で、旧処理環境にリクエストを送信し続けるクライアントである。クライアント７０３は旧Ｂｌｕｅ環境７２０にリクエストを送信し、クライアント７０２は旧Ｂｌｕｅより更に古い処理環境（旧々Ｂｌｕｅと呼ぶ）７１０にリクエストを送信するクライアントである。クライアント７０４はクラウドシステム３０１で管理するサービスの正式なＦＱＤＮと紐付いたロードバランサ７３１を有するＢｌｕｅ環境７３０にリクエストを送信するクライアントである。切り替え後、リソース操作部３６１は、ロードバランサ７１１、７２１からＶＭ７３２にリクエストを転送するようにロードバランサ７１１と７２１の設定値を更新する。それと共に、リソース操作部３６１は、ロードバランサ７１１からはＶＭ７１２に、ロードバランサ７２１からはＶＭ７２２にリクエストを転送しないようにロードバランサ７１１と７２１設定値を更新する。
【００４７】
図８は、処理環境の管理テーブルを処理工程ごとに示した図である。８００は処理環境をバージョンごとに管理するための管理テーブルである。管理テーブル８００は、図４の管理テーブル４１０を拡張したテーブルを想定しているが、新たに用意したテーブルでもよい。管理テーブル８００は、管理用データストア３７０で保持されて、デプロイメント中の各工程においてリソース操作部３６１により更新される。
【００４８】
８０１は処理環境のバージョンを示しており、図４の４１１に対応する。８０２は外部公開しているロードバランサをユニークなＩＤで示したものであり、４１２に相当する。８０３は外部公開しているロードバランサ７１１、７２１、７３１などがリクエストを転送する先のＭＶを示しており、図４の４１６に対応する。８０４は処理環境のシステムモードを示している。本実施例では説明の便宜上“ｏｌｄ  ｂｌｕｅ”，  “ｂｌｕｅ”，  “ｇｒｅｅｎ”，  “ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”，  “ｓｗｉｔｃｈ  ｂａｃｋ”の５つのシステムモードを定義した。“ｏｌｄ  ｂｌｕｅ”は過去にＢｌｕｅ環境として稼働していた処理環境である。“ｂｌｕｅ”は、Ｂｌｕｅ環境として稼働している処理環境であり、実施例１で説明したような他の処理環境のロードバランサからのリクエストの転送先であるＶＭを有する処理環境である。“ｇｒｅｅｎ”は、Ｇｒｅｅｎ環境として稼働している処理環境であり、“ｂｌｕｅ”の処理環境にリクエストを転送しない唯一の処理環境である。“ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”は、過去にＢｌｕｅ環境であったが、切り戻しがある場合に再度Ｂｌｕｅ環境になり得る処理環境であり、前回“ｂｌｕｅ”であった処理環境が切り替えにより“ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”となる。“ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”は、所定期間が経過した後、“ｂｌｕｅ”が正常稼働していると判断された後に、“ｏｌｄ  ｂｌｕｅ”になる。所定期間としては、１週間から１か月程度の期間が想定される。“ｓｗｉｔｃｈ  ｂａｃｋ”は、Ｂｌｕｅ環境で異常が発生した際などに、切り戻されて再度Ｂｌｕｅ環境になった処理環境である。８０５はシステムモードが変更された際のシステムモード更新日時を示している。
【００４９】
図８（ａ）はＧｒｅｅｎ環境を構築してから切り替え前までの管理テーブル８００である。図８（ｂ）は切り替え後から“ｂｌｕｅ”が正常に稼働していると判断されるまでの管理テーブル８００である。図８（ｃ）は“ｂｌｕｅ”が正常に稼働していると判断されず、切り戻しを行った後の管理テーブル８００の例である。具体的には、後述する図９のＳ９０２後の状態が図８（ａ）、Ｓ９０５後の状態が図８（ｂ）、Ｓ９１３後の状態が図８（ｃ）に対応している。
【００５０】
図９は処理環境の管理テーブルを用いた一連のデプロイメント処理の手順例を示すフローチャートである。すなわち、図９のフローチャートの処理は、データセンター上のサーバーコンピューターのＣＰＵ２０３が、ＲＯＭ２０４または二次記憶装置２０６に記録されたプログラムを読み出して実行することにより実現される。
【００５１】
Ｓ９０１では、リソース操作部３６１が、Ｓ６０１と同様にリソース生成部３５１に対してＧｒｅｅｎ環境の構築の指示を行う。Ｓ９０２では、リソース操作部３６１は、Ｓ９０１で構築されたＧｒｅｅｎ環境を管理テーブル８００に追加する。Ｓ９０３は、リソース操作部３６１が、Ｓ６０２と同様に切り替えを指示する。Ｓ９０４では、正常に切り替えが実行されたか確認を行い、正常に切り替えられた場合はＳ９０５を実行し、正常に切り替えられなかった場合はデプロイメント処理を終了する。
【００５２】
Ｓ９０５では、リソース操作部３６１は、管理テーブル８００の各環境の情報を更新する。まず、リソース操作部３６１はシステムモード８０２が“ｂｌｕｅ”である処理環境を“ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”に、“ｇｒｅｅｎ”である処理環境を“ｂｌｕｅ”に更新する。次に、リソース操作部３６１は、システムモード８０２が更新された処理環境のシステムモード更新日時８０５を更新する。最後に、リソース操作部３６１は、システムモードが“ｏｌｄ  ｂｌｕｅ”，“ｗａｉｔｉｎｇ  ｏｌｄ”に更新された処理環境のロードバランサのリクエストの転送先のＶＭを“ｂｌｕｅ”のＶＭに更新する。Ｓ９０６ではシステムモード８０２が“ｂｌｕｅ”の処理環境が正常に稼働しているかどうかが確認され、正常に稼働している場合はＳ９０７を実行し、正常に稼働していない場合はＳ９１２を実行する。正常に稼働しているかどうかは、テスト部３６２が実行したテストをパスしたことや、一定時間経過後、一定リクエスト処理後にエラーが発生しなかったこと、などを基準に判断される。
【００５３】
Ｓ９０７では、リソース操作部３６１はシステムモード８０２が“ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”の処理環境を“ｏｌｄ  ｂｌｕｅ”に変更すると共に、システムモード更新日時８０５を更新する。Ｓ９０８ではテスト部３６２およびリソース操作部３６１は、システムモード８０２が“ｏｌｄ  ｂｌｕｅ”のロードバランサと、リクエストの転送先としての“ｂｌｕｅ”のＶＭとの対応付けを行う。さらにテスト部３６２は、ヘルスチェックを実行するように指示する。Ｓ９０９では、Ｓ６０７と同様にヘルスチェックの結果に基づき、テスト部３６２は、“ｂｌｕｅ”のＶＭへリクエストを転送可能であると確認された場合はＳ９１０を実行し、転送可能でないと確認された場合はＳ９１５を実行する。なお、ヘルスチェックに失敗した場合も、テスト部３６２はＳ９１５を実行する。
【００５４】
Ｓ９１０ではリソース操作部３６１は、Ｓ９０９にてヘルスチェックが成功したロードバランサとＶＭの組に対して、ロードバランサからＶＭにリクエストを転送するように指示する。Ｓ９１１ではリソース操作部３６１は、管理テーブル８００の情報をもとに、システムモード８０２が“ｏｌｄ  ｂｌｕｅ”および“ｓｗｉｔｃｈ  ｂａｃｋ”の処理環境のロードバランサと自身の環境のＶＭとの対応付けを解除する。なお、Ｓ６０９と同様に、リソース操作部３６１は、ロードバランサとＶＭとの対応付けを解除するのではなく、通信を閉塞するだけでもよい。
【００５５】
Ｓ９１２では、リソース操作部３６１はＳ６１０と同様に切り戻しを実行する。このとき、切り戻した結果Ｂｌｕｅ環境になるのは、システムモード８０２が“ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”である処理環境である。Ｓ９１３では、まず、リソース操作部３６１はシステムモード８０２が“ｗａｉｔｉｎｇ  ｏｌｄ  ｂｌｕｅ”であった処理環境を“ｂｌｕｅ”に、“ｂｌｕｅ”であった処理環境が“ｓｗｉｔｃｈ  ｂａｃｋ”になるように管理テーブル８００を更新する。次に、リソース操作部３６１はシステムモード８０２を変更した処理環境のシステムモード更新日時８０５を更新する。最後に、リソース操作部３６１はロードバランサからのリクエストの転送先ＶＭを“ｂｌｕｅ”の処理環境ＶＭに設定する。Ｓ９１４ではテスト部３６２およびリソース操作部３６１は、切り戻された処理環境（この時点で“ｓｗｉｔｃｈ  ｂａｃｋ”）のロードバランサに、切り戻した処理環境（この時点で“ｂｌｕｅ”）のＶＭを追加し、ヘルスチェックを実行する。
【００５６】
Ｓ９１５ではリソース操作部３６１は、ヘルスチェックに失敗した“ｏｌｄ  ｂｌｕｅ”と“ｓｗｉｔｃｈ  ｂａｃｋ”の処理環境のロードバランサとリクエストの転送先である“ｂｌｕｅ”のＶＭとの対応付けを解除する。
【００５７】
前述した通り、バージョンアップの頻度が高いサービスの場合、旧Ｂｌｕｅ環境を残し続けることも可能であるが、運用コストが高くなるため、不要な処理環境は削除するのが望ましい。クライアントがアクセス可能な外部公開しているロードバランサをのみを残し、ロードバランサ配下のコンピュータリソースを条件に応じて削除する方法を説明する。
【００５８】
図１０は旧Ｂｌｕｅ環境のリソースの削除処理の手順例を示すフローチャートである。Ｓ１００１では、リソース監視部３５３は、システムモード８０２が、“ｏｌｄ  ｂｌｕｅ”の処理環境の各種コンピュータリソースの使用状況、アクセスログ、動作ログなどをリソース監視部３５３が監視する。Ｓ１００２では、リソース監視部３５３は、システムモード８０２が“ｏｌｄ  ｂｌｕｅ”の処理環境の外部公開されているロードバランサ以外のコンピュータリソースの使用状況を確認する。リソース監視部３５３は、サーバーに一定時間以上アクセスが無いか、キューにデータがないかなどの条件で判断を行い、条件を満たすと判断した場合はＳ１００３を実行する。そうでない場合は再度時間をおいてリソース監視部３５３がコンピュータリソースの使用状況やログを確認する。Ｓ１００３ではシステムモード８０２が“ｏｌｄ  ｂｌｕｅ”の処理環境の外部公開されているロードバランサ以外のコンピュータリソースを削除する。Ｓ１００４ではシステムモード８０２が“ｏｌｄ  ｂｌｕｅ”の処理環境の外部公開されているロードバランサのアクセスログを確認する。一定時間以上アクセスログが確認できない場合は、Ｓ１００５を実行し、一定時間以内にアクセスログがある場合は再度時間をおいてリソース監視部３５３がロードバランサのアクセスログを確認する。Ｓ１００５ではシステムモード８０２が“ｏｌｄ  ｂｌｕｅ”の処理環境の外部公開されているロードバランサを削除する。
【００５９】
なお、Ｓ１００３において、旧Ｂｌｕｅ環境のキューにメッセージがまだ残っている場合には、旧Ｂｌｕｅ環境のＶＭ７２２のみを削除して、旧Ｂｌｕｅ環境のキューおよびキュー内のメッセージを処理するＶＭを削除しないようにしてもよい。
【００６０】
本実施例では、クラウドシステム内に処理環境が３つ並存する場合に、システム管理部３６０は、ＤＮＳサーバーで本番環境として設定されていない処理環境の負荷分散装置と、本番環境として設定されている処理環境の仮想マシンとを対応付けた。さらに、システム管理部３６０は、本番環境として設定されていない処理環境の仮想マシンを削除した。本実施例により、ＤＮＳサーバーで本番環境として設定されていない処理環境の負荷分散装置が受け付けたリクエストを、本番環境として設定されている処理環境の仮想マシンで処理することが可能となる。
【００６１】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
【００６２】
ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【００６３】
１０１  サーバー
２０３  ＣＰＵ
３０１  クラウドシステム
３６０  システム管理部
３６１  リソース操作部
【図１】
2018088114.tif 000003
【図２】
2018088114.tif 000004
【図３】
2018088114.tif 000005
【図４】
2018088114.tif 000006
【図５】
2018088114.tif 000007
【図６】
2018088114.tif 000008
【図７】
2018088114.tif 000009
【図８】
2018088114.tif 000010
【図９】
2018088114.tif 000011
【図１０】
2018088114.tif 000012