JP6548540B2 - 管理システムおよび管理システムの制御方法 - Google Patents

Description

本発明は、処理システムの切り替え時における、処理システムを構成するリソースのリソース量調整技術に関する。

近年、インターネット上にあるサーバーで動作する各種アプリケーションを利用することができるサービスとして、クラウドサービスがある。ＩａａＳやＰａａＳなどのクラウドサービスでは、クラウドサービスベンダーが、ネットワークを介して、仮想マシンやストレージなどのリソースをシステム管理者に提供する。仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピュータである。システム管理者は、クラウドサービスベンダーによって提供される仮想マシンやストレージなどのリソースを用いて、独自のサービスを提供するためのシステムを構築することができる。

クラウドサービスを用いて構築されるシステムは、システム管理者の任意の設定に従い、受け付けるリクエストの量やそれらの処理のための負荷に応じて、自動的にリソース量を調整することができる。例えば、特許文献１には、プログラムの実行に必要なリソースを自動的に割り当て、プログラムの実行を開始した後に、割り当てられた資源を変更するというオートスケール機能が記載されている。

このようなリソース量の調整処理は、クラウドサービスで用意されているリソースマネージャによって実行される。リクエストの量とは、単位時間当たりにロードバランサーが受け付けるリクエストの数であり、処理のための負荷とは、仮想マシンでの処理にかかる負荷であり、仮想マシンのＣＰＵ使用率やメモリ使用率、レスポンスの応答時間などを指す。リソース量の調整には、仮想マシンの台数を増やすスケールアウトと、仮想マシンに対するハードウェア資源の割り当てを増やすスケールアップなどが含まれる。さらに、リソース量の調整には、仮想マシンの台数を減らすスケールインと、仮想マシンに対するハードウェア資源の割り当てを減らすスケールダウンも含まれる。ハードウェア資源は、ＣＰＵやメモリ、ストレージなどである。また、ロードバランサーも、受け付けるリクエストの量に基づき、自動的にスケールアウトなどすることができる。

また、近年、上述したクラウドサービスを用いて構築されるシステムをバージョンアップする際などに、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントと呼ばれる技術が利用されることがある。ここで、システムのバージョンアップとは、例えば、システム内の仮想マシンで実行されるアプリケーションのバージョンアップが含まれる。バージョンアップ後のシステムは、提供できる機能が追加されたり、管理するデータの種類や形式が変更されたりする。

ここで、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントについて説明する。
まず、クラウドサービス上では、外部ネットワークからのリクエストを受付けて処理を行っている本番環境としての処理システムが動作している。処理システムは、少なくとも、リクエストを処理する１以上の仮想マシンと、それらにリクエストを分散させる負荷分散装置として機能するロードバランサーとで構成される。そして、該処理システムをバージョンアップさせたい場合には、現行のバージョンの該処理システムとは異なるバージョンアップ後の処理システムをクラウドサービス上に更に構築する。その後、バージョンアップさせたいタイミングになったら、クラウドサービス上で外部ネットワークからのリクエストの送信対象を示す接続先の設定の変更などを行い、本番環境となる処理システムを切り替える。ここでは、本番環境がバージョンアップ後の処理システムに切り替えられる。この切り替えによって、システムのバージョンアップが実現される。

ここで、前述した現行のバージョンのシステムが動作する処理システム、つまり切り替え前の処理システムは、Ｂｌｕｅ環境と呼ばれる。一方で、前述したバージョンアップ後のシステムが構築された処理システム、つまり切り替え後の処理システムは、Ｇｒｅｅｎ環境と呼ばれる。以降、Ｂｌｕｅ環境を第１の処理システムと、Ｇｒｅｅｎ環境を第２の処理システムと呼ぶ場合もある。

なお、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによる処理システムの切り替えは、上述したシステムのバージョンアップ以外にも利用され得る。例えば、障害やバグが発生した処理システム（ここでは、第１の処理システム）から正常な別の処理システム（ここでは、第２の処理システム）にリクエストを処理する環境を切り替える場合などである。

特表２０１３−５４３１７１号公報

ここで、前述したようなシステムは、例えば、一日に数回のバージョンアップを予定していることがある。このようなシステムの場合、次のバージョンアップ時期が近いため、リクエストの量の推移などを考慮しつつ、前述した処理システムの切り替えを行うことは難しい。

また、システム運用上、新しいバージョンのシステムのリリース日程を大きく後ろにずらすことができない場合もある。したがって、外部ネットワークから大量のリクエストを受け付けており、第１の処理システムにかかる処理の負荷が大きい時であっても、バージョンアップなどのために、それらのリクエストの処理システムの切り替え処理を実行しなければならない場合がある。

第１の処理システムにかかるリクエストに係る処理の負荷が大きい時には、前述したリソースマネージャが、該第１の処理システム内でリクエストを処理するロードバランサーなどに対して大量のリソースが提供されるように調整処理を行っている。一方、バージョンアップのための切り替えを見越して事前に用意された第２の処理システムでは、まだ外部ネットワークからのリクエストを受け付けて処理していないため、リソースマネージャによるリソースの調整処理が行われていない。

また、システム管理者がシステムの維持コストの節約を考慮する場合には、事前に用意する第２の処理システムは比較的少ないリソース量で構成されていることがある。このような状況下で前述した切り替え処理を行うと、第２の処理システムは一気に大量のリクエストを受け付けることになる。すると、リソースマネージャによるリソースの調整処理が間に合わない場合には第２の処理システムでのリクエストの処理が滞ることが考えられる。

本発明は、上述した第１の処理システムから第２の処理システムへの切り替え処理の際に、第２の処理システムでのリクエストの処理が滞らないようにすることを目的とする。

上記課題を解決するために、本発明の管理システムは、リクエストを処理する１以上の仮想マシンと、該仮想マシンにリクエストを分散させる負荷分散装置とを少なくとも備える処理システムを複数有する管理システムであって、所定のネットワークシステムからのリクエストを処理する処理システムを、前記複数の処理システムに含まれる第１の処理システムから第２の処理システムへ切り替えるための指示に応じて、該第１の処理システムを実現するために使用されているリソースの量の調整に関する情報を取得する取得手段と、前記取得手段が取得した情報に基づく前記第２の処理システムのリソースの量の調整指示として、前記第２の処理システムの仮想マシンの台数を増やすための指示を行う調整指示手段と、を有し、前記調整指示手段による前記調整指示に応じて、所定のネットワークシステムからのリクエストを処理する処理システムが、前記第１の処理システムから前記第２の処理システムへ切り替わることを特徴とする。

本発明によれば、上述した第１の処理システムから第２の処理システムへの切り替え処理の際に、第２の処理システムでのリクエストの処理が滞らないようにすることができる。

本発明の実施形態に係るシステム構成の概略を示す図である。 情報処理装置のハードウェアの構成例を示す図である。 管理システム１００の構成例を示す図である。 リソースマネージャ３０３の構成例を示す図である。 リソース情報管理テーブルを示す図である。 監視状態管理テーブルを示す図である。 オートスケール状態管理テーブルを示す図である。 スタック情報管理テーブルを示す図である。 スタックテンプレートの一例を示す図である。 スタックテンプレートの一例を示す図である。 スタックテンプレートの一例を示す図である。 本番環境の切り替え処理の流れを示すフローチャートである。 Ｇｒｅｅｎ環境のリソース量調整処理の流れを示すフローチャートである。 スタックテンプレートの一例を示す図である。 移行方法テーブルを示す図である。

以下、本発明を実施するための最良の形態について図面を用いて説明する。

本発明では、クラウドサービスを用いて構築されるネットワークシステムとして、複数の顧客や各顧客が保有するネットワークデバイスを、ネットワークを介して遠隔地から管理する管理システムを例に挙げて説明する。管理システムでは、顧客ごとの顧客ネットワーク環境に存在するネットワークデバイスから機器情報や、ログ情報や障害情報などの稼働情報を収集して、分析することにより様々なデバイス管理サービスを提供する。具体的には、管理システムは、ネットワークデバイスの稼働状況のレポーティングサービスや、故障したネットワークデバイスの保守に必要なサービスを提供している。管理システムは、サービスを提供するために、例えば、管理対象となるネットワークデバイスの新規登録や、レポート作成、ネットワークデバイスのログ情報の登録などのリクエストを、ネットワークなどを介して受け付けるように構成されている。

また、顧客のデバイス等の管理を顧客から業務委託される顧客管理者がいる場合もある。この場合、顧客管理者は、管理システムを利用して、顧客それぞれが保有するデバイスを管理し、その顧客に対して様々なサービスを提供する。管理システムの利用者には、顧客管理者と顧客とを含む。

（実施例１）
図１は、システム全体の構成の概略を示す図である。ネットワークデバイスや顧客情報を管理する管理システム１００と、ネットワークデバイスが設置されている複数の顧客環境１３０とがインターネットを介して接続されている。また、管理システム１００を管理するためのシステム管理者用のコンピュータ１１０や、ネットワークデバイスの販売会社の担当者（顧客管理者）用のコンピュータ１２０が、同様に管理システム１００とネットワークを介して接続されている。

管理システム１００は、ＩａａＳやＰａａＳなどのクラウドサービスによって提供されるプラットフォームやリソースを利用して構築される、ネットワークデバイスやそれらを保有する顧客を管理するためのサービスを提供するシステムである。クラウドサービスは、リソースとして、例えばインターネット上のデータセンターに存在するサーバーコンピュータ上で動作する複数の仮想マシンやストレージなどを提供する。仮想マシンとは、仮想化技術によって、サーバーを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピュータである。複数の仮想マシン上で様々なアプリケーションプログラムを実行することで、管理システム１００としての様々な管理サービスが実現される。サービス内容としては、具体的には、顧客環境１３０に設置されたネットワークデバイスの機器情報を収集した場合に、当該顧客の情報と関連付けて管理するサービスがある。ほかに、顧客環境１３０に設置されたネットワークデバイスのログ情報や障害情報などの稼働情報を収集して、分析することで、顧客や販売会社の担当者のためにレポーティングを行うといったサービスがある。ほかにも、故障したネットワークデバイスの保守に必要な情報を販売会社の担当者のために電子メールなどで通知するといったサービスもある。なお、ネットワークデバイスには、プリンターやネットワークカメラなどの画像処理装置などが含まれる。プリンターには、トナーなどを利用した電子写真方式のものや、インクを利用して印刷を行うインクジェット方式のものが存在する。管理システム１００は、それぞれの方式によって特有な稼働情報（例えば、トナー使用量やインク使用量）を収集して、異なる管理サービスを提供することも可能である。

コンピュータ１１０は、システム管理者が利用するコンピュータであり、管理システム１００が提供する管理者用の管理画面を、インストールされているウェブブラウザなどを用いて表示できる。システム管理者はコンピュータ１１０に表示される管理画面を介して、管理システム１００に対する各種設定などを行うためのリクエストの送信を指示できる。例えば、システム管理者は、前述したＢｌｕｅ−ＧｒｅｅｎデプロイメントのためのＧｒｅｅｎ環境の生成のためのリクエストや、Ｂｌｕｅ環境からＧｒｅｅｎ環境へリクエスト処理システムを切り替えるためのリクエストの送信を指示できる。処理システムは、少なくとも、リクエストを処理する１以上の仮想マシンと、それらにリクエストを分散させる負荷分散装置として機能するロードバランサーとを備える。

コンピュータ１２０は、ネットワークデバイスの販売会社の担当者が利用するコンピュータであり、管理システム１００が提供する担当者用の画面を、ウェブブラウザなどを用いて表示できる。管理システム１００が提供する担当者用の画面には、顧客環境１３０に設置されたネットワークデバイスのログ情報や障害情報などの稼働情報を確認できる画面などがある。他にも、担当者用の画面としては、顧客環境１３０に設置されたネットワークデバイスの監視設定を行うための画面も表示できる。

顧客環境１３０は、管理システム１００が管理する顧客ごとにネットワーク上に存在するネットワーク環境を示す。顧客環境１３０には、顧客が保有する１以上のネットワークデバイスと、ネットワークデバイスと管理システム１００との通信を中継する中継装置がＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）により接続されている。中継装置は、ネットワーク上のネットワークデバイスを探索して、発見した場合に管理システム１００に該ネットワークデバイスの機器情報を通知するためのリクエストを生成して送信するための機能をもつ。また、前記中継装置は、ネットワークデバイスから収集した稼働情報を、管理システム１００に通知するためのリクエストを生成して送信するための機能をもつ。なお、コンピュータ１２０や顧客環境１３０は、それぞれ複数存在してもよい。

図２は、情報処理装置のハードウェアの構成例を示す図である。本実施例における情報処理装置としては、管理システム１００を実現するためのデータセンター上に存在するサーバーコンピュータ、コンピュータ１１０、コンピュータ１２０、顧客環境１３０内に存在する中継装置としてのコンピュータなどがある。

情報処理装置は、ＲＯＭ２５３に格納されているプログラムを実行するＣＰＵ２５１を備え、内部バス２５６を介して各デバイスを総括的に制御する。内部バス２５６には、ＲＡＭ２５２、ＲＯＭ２５３、記憶装置２５４、ネットワークＩ／Ｆ２５５、入出力Ｉ／Ｆ２５７が接続されている。また入出力Ｉ／Ｆ２５７は、例えばＰ／Ｓ２やＵｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ Ｉ／Ｆ）、アナログやデジタルのディスプレイＩ／Ｆを備える。入出力Ｉ／Ｆ２５７により、情報処理装置に対して、不図示のキーボードやマウス、ＣＲＴや液晶ディスプレイなどを接続することができる。情報処理装置はネットワークＩ／Ｆ２５５によりＬＡＮ、イントラネット環境、インターネットを介した通信を行う。それにより、情報処理装置は、ネットワークデバイスや、他の情報処理装置と通信を行うことができる。ＣＰＵ２５１は、ＲＡＭ２５２やＲＯＭ２５３と共にプログラムの実行処理を行う。さらに、ＣＰＵ２５１は、仮想化技術を実現するためのプログラムを実行することも可能である。また、ＣＰＵ２５１は、記憶装置２５４等の記録媒体にデータを記録する処理を行う。記憶装置２５４は外部記憶装置として機能し、様々な情報を記憶するほか、ＲＡＭ２５２に代わって、各種システム情報及び処理情報を保存することも可能である。

図３は、管理システム１００の構成例を示す図である。管理システム１００は、コンピュータ１１０を操作するシステム管理者によって構築、管理され、顧客管理者が操作するコンピュータ１２０、顧客環境１３０内のネットワークデバイスおよび中継装置から送られるリクエストを処理してサービスを提供する。

図３（Ａ）は、Ｇｒｅｅｎ環境３５０が生成される前の管理システム１００を表す図である。図３（Ａ）において、管理システム１００は、システムマネージャ３００と、ＤＮＳ３０１と、データベース３０２と、リソースマネージャ３０３と、Ｂｌｕｅ環境３３０とで構成される。一方、図３（Ｂ）は、Ｇｒｅｅｎ環境３５０が生成された後の管理システム１００を示す図である。図３（Ｂ）の管理システム１００の構成は、図３（Ａ）の管理システム１００の構成に、Ｇｒｅｅｎ環境３５０が追加される。Ｇｒｅｅｎ環境３５０は、動作確認やテストが行われた後に、Ｂｌｕｅ環境３３０と代わって本番環境となる。本番環境の切り替え処理について、図１０を用いて後述する。

ＤＮＳ３０１には、それぞれの仮想マシンやロードバランサーのＩＰアドレスなどのアドレス情報とホスト名が登録されている。システム管理者用のコンピュータ１１０や顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスは、インターネットなどのネットワークを経由して、ＤＮＳ３０１と通信を行う。前記コンピュータやネットワークデバイスは、ＤＮＳ３０１に、リクエストの接続先となる処理システム内のロードバランサーのホスト名に該当するアドレス情報を問合せて、ＤＮＳ３０１から返ってきたアドレス情報にリクエストを送る。受け付けたリクエストに対して、ＤＮＳ３０１は、ＤＮＳ名に紐づくＤＮＳレコードを使って、リクエストの接続先となる処理システム内のロードバランサーを示すホスト名またはアドレス情報を返す。管理システム１００を構成する仮想マシンは、それぞれ、固有のＩＰアドレスなどのアドレス情報を持つ。したがって、ロードバランサーを構成する仮想マシンのアドレス情報によって、該ロードバランサーのアドレス情報は特定され得る。

データベース３０２には、本管理システムを実現するためのプログラムや、サービスを提供するための各種データ、後述する図５〜８、１３の各テーブルなどが格納されている。

システムマネージャ３００は、管理システム１００内の処理システムの設定に関するリクエストなどをシステム管理者用のコンピュータ１１０から受け付ける。システムマネージャ３００は、システム管理者からのリクエストに基づいて、リソースマネージャ３０３への指示を行う。例えば、システムマネージャ３００は、処理システムを構成するリソースと当該リソースを用いた処理システムの生成を指示したり、リソース量を調整するための調整指示をしたりする。

リソースマネージャ３０３は、システムマネージャ３００の指示に基づいて、処理システムを構成するリソースを生成または削除したり、管理システム１００内のリソース量の調整処理を実行したりする。リソース量の調整には、仮想マシンの台数を増やすスケールアウトと、仮想マシンに対するハードウェア資源の割り当てを増やすスケールアップなどが含まれる。さらに、リソース量の調整には、仮想マシンの台数を減らすスケールインと、仮想マシンに対するハードウェア資源の割り当てを減らすスケールダウンも含まれる。ハードウェア資源は、ＣＰＵ（コア数）やメモリ（サイズ）、ストレージ（サイズ）などである。

リソースマネージャ３０３は、Ｂｌｕｅ環境３３０に対するリクエストの量を監視して、自動でリソース量を調整することもできる。リクエストの量とは、単位時間当たりにＢｌｕｅ環境３３０内のロードバランサー３３１が受け付けるリクエストの数である。また、リソースマネージャ３０３は、Ｂｌｕｅ環境３３０にかかる処理負荷を監視して、自動でリソース量を調整するようにしてもよい。処理負荷とは、仮想マシンでの処理にかかる負荷であり、仮想マシンのＣＰＵ使用率やメモリ使用率、レスポンスの応答時間などを指す。監視されるリクエスト量や処理負荷が予め設定された条件に合致した場合にリソースマネージャ３０３により実行されるリソース量の調整のことを、オートスケールという。

また、リソースマネージャ３０３は、システムマネージャ３００の指示に従って、ＤＮＳ３０１に登録されているＤＮＳレコードを書き換えるなどして、本番環境を切り替える。本番環境を切り替える方法については、図４における切り替え部４０５の説明部分で詳細に述べる。

Ｂｌｕｅ環境３３０は、現行バージョンのアプリケーションが動作する処理システムであり、ロードバランサー３３１と、仮想マシン３３２および３３４と、キュー３３３とを有する。Ｇｒｅｅｎ環境３５０で動作するアプリケーションは、Ｂｌｕｅ環境３３０で動作するアプリケーションと比較して少なくとも一つの機能が追加または拡張されバージョンアップされている。Ｇｒｅｅｎ環境３５０は、ロードバランサー３５１と、仮想マシン３５２および３５４と、キュー３５３とを含む処理システムである。なお、ロードバランサー３３１、３５１、仮想マシン３３２、３３４、３５２、３５４などは、それぞれの環境において、複数あっても良い。

Ｂｌｕｅ環境３３０において、ロードバランサー３３１は、受け付けたリクエストを仮想マシン３３２に分散させる負荷分散装置である。仮想マシン３３２は、Ｂｌｕｅ環境３３０におけるリクエスト処理システムであって、リクエストを受け付けて処理するＷｅｂサーバーなどである。キュー３３３は、仮想マシン３３２により処理されたリクエストに対応するメッセージを管理するためのキューである。仮想マシン３３４は、Ｂｌｕｅ環境３３０におけるバッチ処理システムであって、キュー３３３内のメッセージキューを処理（バッチ処理）するバッチサーバーなどである。仮想マシン３３２におけるリクエスト処理と、仮想マシン３３４におけるバッチ処理とは、非同期に実行される。

Ｇｒｅｅｎ環境３５０において、ロードバランサー３５１は、受け付けたリクエストを仮想マシン３５２に分散させる負荷分散装置である。仮想マシン３５２は、Ｇｒｅｅｎ環境３５０におけるリクエスト処理システムであって、リクエストを受け付けて処理するＷｅｂサーバーなどである。キュー３５３は、仮想マシン３５２により処理されたリクエストに対応するメッセージを管理するためのキューである。仮想マシン３５４は、Ｇｒｅｅｎ環境３５０におけるバッチ処理システムであって、キュー３５３内のメッセージキューを処理（バッチ処理）するバッチサーバーなどである。仮想マシン３５２におけるリクエスト処理と、仮想マシン３５４におけるバッチ処理とは、非同期に実行される。

なお、管理システム１００は、Ｇｒｅｅｎ環境３５０を複数有することも可能である。本番環境を切り換える際には、複数用意されているＧｒｅｅｎ環境のうちの一つを選択するといったことも可能である。

図４は、本発明の実施形態に係るリソースマネージャ３０３の構成例を示す図である。リソースマネージャ３０３は、リソース生成部４０１と、リソース監視部４０２と、オートスケール管理部４０３と、スタック受け付け部４０４と、切り替え部４０５とを有する。

リソース生成部４０１は、管理システム１００のリソースに対するシステム管理者からの要求を受信し、要求に基づいて仮想マシンやサーバーコンポーネントを生成する。システム管理者は、仮想マシン３３２、３３４、３５２および３５４を生成し利用可能にするようリソース生成部４０１に要求できる。リソース生成部４０１は、システム管理者からの要求を様々な方法で受信する。例えば、リソース生成部４０１は、管理システム１００が提供するＧＵＩやＡＰＩなどを用いてシステム管理者からの要求を受信するようにしてもよい。システム管理者からの要求は、仮想マシン３３２、３３４、３５２および３５４の数やタイプなどを含む。

仮想マシン３３２、３３４、３５２および３５４は、システム管理者が選択可能なＯＳ、アプリケーションサーバー、およびシステムやアプリケーション構成などを含むことができる。サーバーコンポーネントは、ロードバランサー３３１および３５１や、キュー３３３および３５３などを含むが、それらに限定されない。管理システム１００が、システム管理者の要求を満たす仮想マシン３３２、３３４、３５２および３５４を生成した後、システム管理者は、仮想マシン３３２、３３４、３５２および３５４の設定を変更することができる。例えば、システム管理者は、仮想マシン３３２、３３４、３５２および３５４に関連する記憶装置またはネットワーク帯域幅の量もしくはタイプを変更することができる。

リソース監視部４０２は、仮想マシン３３２、３３４、３５２および３５４やサーバーコンポーネントの状態や性能などをモニタリングする。例えば、リソース監視部４０２は、ロードバランサーにおいては単位時間あたりのリクエスト数を、仮想マシンにおいてはＣＰＵ使用率やメモリ使用率などを、キューにおける未処理メッセージ数などを、監視項目としてモニタリングする。リソース監視部４０２は、Ｂｌｕｅ環境３３０やＧｒｅｅｎ環境３５０に接続し、前記監視項目の情報を取得する。その際、リソース監視部４０２は、管理システム１００内のネットワーク（不図示）を経由して、Ｂｌｕｅ環境３３０やＧｒｅｅｎ環境３５０に接続する。

モニタリングの結果、システム管理者によって予め定められた条件（後述の図９Ｂで示すスタックテンプレート内の定義）に合致する場合に、リソース監視部４０２はＡｌａｒｍイベントを発信する。オートスケール管理部４０３は、Ａｌａｒｍイベントを受信し、そのＡｌａｒｍイベントに応じて仮想マシンやサーバーコンポーネントなどを生成する。

オートスケール管理部４０３は、仮想マシン３３２、３３４、３５２および３５４やサーバーコンポーネントのオートスケールを管理する。オートスケール管理部４０３は、オートスケールの対象となる仮想マシン３３２、３３４、３５２および３５４やサーバーコンポーネントをグループ単位で管理する。このグループをオートスケールグループと呼ぶこととする。例えば、オートスケール管理部４０３は、複数台存在する仮想マシン３３２を１つのオートスケールグループとして管理する。

オートスケール管理部４０３は、オートスケールグループに属する仮想マシン３３２、３３４、３５２および３５４をロードバランサー３３１および３５１に接続し、オートスケールグループは、ロードバランサー３３１および３５１に関連付けられる。ロードバランサー３３１および３５１は、外部からのリクエストを仮想マシンに分散して送信し、仮想マシン３３２および３５２は受信したリクエストを処理する。

オートスケール管理部４０３は、オートスケールグループに属し稼働している仮想マシンやサーバーコンポーネントの台数が、必要台数として設定された台数になるようにコントロールする。必要台数はシステム管理者からの要求によって決まる。なお、必要台数は予めクラウドサービス提供者によって設定されても良い。

オートスケール管理部４０３は、稼働台数が必要台数より少なければ、リソース生成部４０１に仮想マシンなどの生成を要求し、生成された仮想マシンなどを該当するオートスケールグループに追加する。オートスケールグループがロードバランサー３３１または３５１に関連付けられている場合には、オートスケール管理部４０３は、追加された仮想マシンを該当するロードバランサー３３１または３５１に接続する。

一方、稼働台数が必要台数より多ければ、オートスケール管理部４０３は、仮想マシンをオートスケールグループから削除し、リソース生成部４０１に仮想マシンを停止するよう要求する。オートスケールグループがロードバランサー３３１または３５１に関連付けられている場合には、オートスケール管理部４０３は、削除しようとする仮想マシンと該当するロードバランサー３３１または３５１との接続を解除するよう要求する。ロードバランサー３３１または３５１は、削除しようとする仮想マシンへリクエストを送信するのを止め、処理中のリクエストがなくなった後にロードバランサー３３１または３５１との接続を解除する。オートスケール管理部４０３は、仮想マシン３３２および３５２がロードバランサー３３１または３５１との接続が解除された後に、リソース生成部４０１に仮想マシンを停止するよう要求する。

また、リソース監視部４０２がＡｌａｒｍイベントを発信するときに、オートスケールグループの必要台数を設定する処理のことをオートスケールポリシーと呼ぶこととする。システム管理者は、例えば、必要台数を１台増やす、１台減らす、または、必要台数を２０に設定するなどの指定し、リソース監視部４０２は、システム管理者の要求に応じてリソース量の調整を行う。また、オートスケール管理部４０３は、オートスケール状態の情報を管理する。オートスケール状態の情報は、仮想マシンの台数およびスペックや、最後に実行されたオートスケールの操作などを含む。

スタック受け付け部４０４は、コンピュータ１１０でＡＰＩなどを用いて、仮想マシンやサーバーコンポーネントなどの生成または削除の要求をシステム管理者から受け付ける。その際、スタック受け付け部４０４は、スタックテンプレートを受信し、スタックテンプレートに記載された仮想マシンやサーバーコンポーネントの生成をリソース生成部４０１に要求する。スタックテンプレートは、仮想マシンやサーバーコンポーネントの生成についてシステム管理者からの要求を記載したテンプレートである。スタックテンプレートについて、図９を用いて後述する。スタックとは、同一のスタックテンプレートで生成される仮想マシンやサーバーコンポーネントの集合を指す。ここでは、Ｂｌｕｅ環境の仮想マシンやサーバーコンポーネントの生成と、Ｇｒｅｅｎ環境の仮想マシンやサーバーコンポーネントの生成とが、それぞれ一つのスタックテンプレートに記載される。

スタック受け付け部４０４は、上述したようなスタックテンプレートを受信し、リソース生成部４０１に対して仮想マシンやサーバーコンポーネントを生成するよう要求する。また、スタック受け付け部４０４は、リソース監視部４０２に監視条件を追加し、オートスケール管理部４０３にオートスケールに関する情報を登録する。ここでの処理により、図３（Ｂ）に示すＧｒｅｅｎ環境３５０が生成されることになる。

切り替え部４０５は、システム管理者からの環境を切り替える指示があった場合に、Ｂｌｕｅ環境とＧｒｅｅｎ環境のスタックＩＤ８０１の指定を受け付けて、Ｂｌｕｅ環境のリソース量の調整に関する情報を取得し、Ｇｒｅｅｎ環境へ反映させる。Ｇｒｅｅｎ環境のリソース調整処理が終了すると、切り替え部４０５は、ＤＮＳ３０１の設定を変更することで、本番環境をＢｌｕｅ環境からＧｒｅｅｎ環境へ切り替える。

切り替え部４０５は、本番環境をＢｌｕｅ環境からＧｒｅｅｎ環境へ切り替える。本番環境の切り替えは、例えば、ＤＮＳ３０１のレコードをＢｌｕｅ環境のものからＧｒｅｅｎ環境のものに変更することによって実現される。例えば、サービスのホスト名が、ｗｗｗ．ａ−ｓｅｒｖｉｃｅ．ｃｏｍである場合、Ｂｌｕｅ環境が本番環境である間は、下記のレコードが登録されている。
ｗｗｗ．ａ−ｓｅｒｖｉｃｅ．ｃｏｍ ＣＮＡＭＥ ｌｂ−Ｒ０１．ｃｌｏｕｄｓｅｒｖｉｃｅ．ｃｏｍ
ここで、ｌｂ−Ｒ０１．ｃｌｏｕｄｓｅｒｖｉｃｅ．ｃｏｍは、Ｂｌｕｅ環境のロードバランサーのホスト名である。このロードバランサーのホスト名を、切り替え時に、Ｇｒｅｅｎ環境のロードバランサーのホスト名であるｌｂ−Ｒ０２．ｃｌｏｕｄｓｅｒｖｉｃｅ．ｃｏｍに書き換える。ＤＮＳ３０１のレコードは下記のように変更される。
ｗｗｗ．ａ−ｓｅｒｖｉｃｅ．ｃｏｍ ＣＮＡＭＥ ｌｂ−Ｒ０２．ｃｌｏｕｄｓｅｒｖｉｃｅ．ｃｏｍ
このように変更することにより、管理システム１００の外部から接続するコンピュータ１２０などからのアクセスＵＲＬを変更することなく、切り替え部４０５は、接続先のサービスをＢｌｕｅ環境からＧｒｅｅｎ環境に切り替えることができる。

また、リソースマネージャ３０３は、システムマネージャ３００の指示に従って、ＤＮＳ３０１に登録されているＤＮＳレコードを書き換える。ＤＮＳレコードが書き換えられることによって、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスなど所定のネットワークシステムからのリクエストの接続先が変更されて、本番環境が切り替えられる。

なお、リクエストの接続先を変更する方法としては、上記の方法の他にも、ロードバランサーやリバースプロキシをアクセスポイントとして用意するという方法、システムにアクセスするためのＵＲＬを書き換えるという方法などがある。

図５は、本発明の実施形態に係るリソース情報管理テーブルを示す図である。テーブルの右端の数字はレコード番号を示しており、図６〜８、１３の各テーブルにおいても同様である。リソース情報管理テーブルの項目は、リソースＩＤ５０１と、タイプ７０２と、タグ５０３とを含む。リソース生成部４０１は、例えば、レコード５１１乃至５２３で示されるように、リソース情報を管理する。リソースとは、クラウドサービスによって提供されるリソースのことであり、仮想マシン３３２、３３４、３５２および３５４やサーバーコンポーネントを含む。

リソースＩＤ５０１は、リソース生成部４０１が生成したリソースを識別する識別子である。タイプ７０２は、リソース生成部４０１が生成したリソースのタイプを示す。リソースのタイプは、例えば、仮想マシンや、ロードバランサー、キューなどを含む。タグ５０３は、キーや値の組でリソースに付加する情報である。“Ｒｏｌｅ”属性は、処理システム内における仮想マシンやサーバーコンポーネントの役割を示し、“Ｗｅｂ”や“Ｂａｔｃｈ”などの値を設定する。また、“Ｖｅｒｓｉｏｎ”属性は、管理システム１００を識別するためのキーであり、Ｂｌｕｅ環境であるかＧｒｅｅｎ環境であるかなどのバージョンを示す。これらは、以降で説明する本番環境の切り替え時に参照する。

図６は、本発明の実施形態に係る監視状態管理テーブルを示す図である。リソース監視部４０２は、例えば、レコード６１１乃至６１８で示されるように、リソースの監視状態の情報を管理する。監視状態管理テーブルの項目は、監視条件名６０１と、監視リソース６０２と、監視項目６０３と、前回測定値６０４と、継続回数６０５とを含む。

監視条件名６０１は、監視条件を識別する名前である。後述するスタック受け付け部４０４が生成した監視条件の場合は、監視条件名６０１の文字列の先頭にスタックＩＤ８０１が付加される。監視リソース６０２は、リソース監視部４０２が監視する監視リソースの情報である。監視項目６０３は、リソース監視部４０２が監視する監視項目の情報である。例えば、レコード６１１では、リソース監視部４０２は、“Ｒ０４”のキューに格納されているメッセージ数を監視するということを示す。前回測定値６０４は、該当レコードで示される監視項目について、リソース監視部４０２が前回の計測時に取得した値である。継続回数６０５は、連続して同じ監視条件を満たした回数である。例えば、３００秒間隔で２回連続して同じ監視条件を満たすとシステム管理者へ通知を行うなどの場合に、継続回数６０５は使用される。

図７は、本発明の実施形態に係るオートスケール状態管理テーブルを示す図である。オートスケール管理部４０３は、例えば、レコード７１１乃至７１８で示されるように、オートスケールグループまたはサーバーコンポーネントのオートスケールに関する情報を管理する。オートスケール状態管理テーブルの項目は、オートスケール管理ＩＤ７０１と、タイプ７０２と、必要台数７０３と、稼働台数７０４と、スペック７０５と、最終実行操作７０６と、タグ７０７とを含む。

オートスケール管理ＩＤ７０１は、オートスケール状態管理が必要なオートスケールグループのＩＤやサーバーコンポーネントのリソースＩＤである。スタック受け付け部４０４が生成したオートスケールグループの場合は、オートスケール管理ＩＤの文字列の先頭にスタックＩＤ８０１が付加される。タイプ７０２は、オートスケール管理ＩＤで指定したオートスケール管理対象のリソースのタイプを格納する。例えば、リソースのタイプには、オートスケールグループやロードバランサー、キューなどが含まれる。

必要台数７０３は、オートスケールグループに必要とされている仮想マシンの台数である。稼働台数７０４は、オートスケールグループに関連付けられ稼働している仮想マシンの台数である。オートスケール管理部４０３は、必要台数７０３と等しくなるように稼働台数７０４をコントロールする。スペック７０５は、仮想マシンの処理能力を示す。

最終実行操作７０６は、オートスケールグループやサーバーコンポーネントなどに対してオートスケール管理部４０３が最後に実行した操作として保持される制御コマンドである。タグ７０７は、オートスケール管理ＩＤ７０１で指定したオートスケールグループやサーバーコンポーネントに付加したタグである。“Ｒｏｌｅ”属性と“Ｖｅｒｓｉｏｎ”属性については、タグ５０３での説明と同様である。

例えば、ロードバランサーやキューなどのサーバーコンポーネントなどは、予めクラウドサービス提供者が設定し、システム管理者に対してマネージドサービスとして提供される場合がある。このような場合、管理システム１００は、システム管理者にオートスケールの設定や状態を公開しないこともある。また、システム管理者がオートスケール機能について設定をせずに、管理システム１００が自動的にオートスケールの設定や管理をするようにしてもよい。

図８は、本発明の実施形態に係るスタック情報管理テーブルを示す図である。スタック受け付け部４０４は、スタック作成の要求を受け付けると、スタックを識別するためのスタックＩＤ８０１を生成し、生成した仮想マシンやサーバーコンポーネントやその他の設定情報と関連付けて管理する。スタック受け付け部４０４は、例えば、レコード８１１乃至８２３で示されるように、スタックテンプレートをスタックＩＤ８０１と関連付けて保持する。スタック情報管理テーブルの項目は、スタックＩＤ８０１と、リソースＩＤ８０２とを含む。

スタックＩＤ８０１は、スタック受け付け部４０４が発行するスタックの識別子である。リソースＩＤ８０２は、スタックに関連付けて生成した仮想マシン３３２、３３４、３５２および３５４やサーバーコンポーネントのリソースの識別子である。システム管理者がスタックの削除を指定した場合、スタック受け付け部４０４は、スタック情報管理テーブルを参照して、スタックに関連付けられたリソースを削除するよう要求する。さらに、スタック受け付け部４０４は、リソース監視部４０２やオートスケール管理部４０３が図５乃至図７の各テーブルに登録した各種設定情報を削除するよう要求する。

システム管理者は、複数のスタックを組み合わせて処理システムを構成できる。例えば、システム管理者は、システムのバージョンアップ時に置き換えないデータベースサーバーなどを含むスタックと、バージョンアップ時に置き換えるＷｅｂサーバーなどを含むスタックとを組み合わせることができる。

図９Ａ、図９Ｂおよび図９Ｃは、本発明の実施形態に係るスタックテンプレートを示す図である。スタック受け付け部４０４は、システム管理者の操作するコンピュータ１１０などからスタックテンプレートを受信する。左端の数字は行番号であり、図１２のスタックテンプレートにおいても同様である。図９Ａはスタックテンプレートの２行目から７１行目を示し、図９Ｂはスタックテンプレートの７２行目から１４０行目を示し、図９Ｃはスタックテンプレートの１４１行目から１８５行目を示す。以降、本実施例に関連する部分を抜粋しながら説明を行う。２行目から１８５行目では、スタックとして生成する仮想マシンやサーバーコンポーネント、オートスケール機能の設定などを指定する。

図９Ａの３行目から２５行目では、ＷｅｂＬＢというロードバランサーを生成し、タグとして、“Ｒｏｌｅ”属性の値が“Ｗｅｂ”であり、“Ｖｅｒｓｉｏｎ”属性の値が“１００”であることが指定される。スタック受け付け部４０４は、リソース生成部４０１にロードバランサーの生成を要求する。生成されたロードバランサーの情報はリソース情報管理テーブル（図５）に登録され、スタックＩＤ８０１とリソースＩＤの関連付けはスタック情報管理テーブル（図８）に登録される。

２６行目から４６行目では、ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐという名前のオートスケールグループを設定する。接続対象はロードバランサー：ＷｅｂＬＢであり、最小の仮想マシン台数（ＭｉｎＳｉｚｅ）は２であり、最大台数（ＭａｘＳｉｚｅ）は１０であることが指定される。初期の必要台数（ＤｅｓｉｒｅｄＣａｐａｃｉｔｙ）は２であり、仮想マシンの起動設定（ＬａｕｎｃｈＣｏｎｆｉｇｕｒａｔｉｏｎＮａｍｅ）は“ＷｅｂＬａｕｎｃｈＣｏｎｆｉｇ”であることが指定される。タグとして、“Ｒｏｌｅ”属性の値が“Ｗｅｂ”であり、“Ｖｅｒｓｉｏｎ”属性の値が“１００”であることが指定される。

４７行目から５３行目では、ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐで指定された“ＷｅｂＬａｕｎｃｈＣｏｎｆｉｇ”という仮想マシンを起動設定する。ＯＳイメージ（ＩｍａｇｅＩｄ）として“ｉｍａｇｅＷｅｂ１００”を使用し、ＣＰＵやメモリなどのスペックを指定するインスタンスタイプ（ＩｎｓｔａｎｃｅＴｙｐｅ）として“Ｌａｒｇｅ”が指定される。

このスタックテンプレートの例では、スタック受け付け部４０４は、オートスケール管理部４０３にオートスケールグループＳ０１＿ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐを登録し、必要台数を２に設定する（文字列の先頭にスタックＩＤ８０１を付加する）。必要台数（＝２）に対して稼働台数（＝０）であるため、オートスケール管理部４０３は、必要台数に達するまでＷｅｂＬａｕｎｃｈＣｏｎｆｉｇに基づいて仮想マシンを生成しオートスケールグループに追加する。

５４行目から７１行目では、ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐのオートスケールグループに関連付けられたオートスケールポリシーを指定する。ＷｅｂＳｃａｌｅＵｐＰｏｌｉｃｙは、必要台数を１台増やす（“ＳｃａｌｉｎｇＡｄｊｕｓｔｍｅｎｔ”：“１”）、操作を行うように指定されている。また、ＷｅｂＳｃａｌｅＤｏｗｎＰｏｌｉｃｙは必要台数を１台減らす（“ＳｃａｌｉｎｇＡｄｊｕｓｔｍｅｎｔ”：“−１”）操作を行うように指定される。ＷｅｂＳｃａｌｅＵｐＰｏｌｉｃｙは、スタック受け付け部４０４がスタックテンプレートに基づいて行う仮想サーバー群の設定の指示である。

図９Ｂの７２行目から９７行目では、ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐのオートスケールグループに関連付けられた監視・通知条件を設定する。

ＷｅｂＣＰＵＡｌａｒｍＨｉｇｈでは、“ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐ”について、監視項目（ＭｅｔｒｉｃＮａｍｅ）としてＣＰＵ使用率（“ＣＰＵＵｔｉｌｉｚａｔｉｏｎ”）の平均を監視する。そして、３００秒間隔で２回、閾値の９０％を超えた場合、ＡｌａｒｍＡｃｔｉｏｎで指定した“ＷｅｂＳｃａｌｅＵｐＰｏｌｉｃｙ”のオートスケールポリシーが参照され、リソース調整の実行が指定される。

このスタックテンプレートの例では、スタック受け付け部４０４は、リソース監視部４０２に監視条件Ｓ０１＿ＷｅｂＣＰＵＡｌａｒｍＨｉｇｈなどを登録する。

９８行目から１１３行目では、生成すべきキューが指定される。ここでは、“ＢａｔｃｈＱｕｅｕｅ”という名前のキューを生成することが指定される。タグとして、“Ｒｏｌｅ”属性の値が“Ｂａｔｃｈ”であり、“Ｖｅｒｓｉｏｎ”属性の値が“１００”であることが指定される。

このスタックテンプレートの例では、スタック受け付け部４０４は、リソース生成部４０１にキューの生成を要求する。生成されたキューの情報はリソース情報管理テーブル（図３）に登録され、スタックＩＤ８０１とリソースＩＤの関連付けは、スタック情報管理テーブル（図８）に格納される。

１１４行目から３５３行目では、ＢａｔｃｈＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐという名前のオートスケールグループが指定され、最小の仮想マシン台数（ＭｉｎＳｉｚｅ）が１であり、最大台数（ＭａｘＳｉｚｅ）が１０であると指定される。初期の必要台数（ＤｅｓｉｒｅｄＣａｐａｃｉｔｙ）が１であり、仮想マシンの起動設定（ＬａｕｎｃｈＣｏｎｆｉｇｕｒａｔｉｏｎＮａｍｅ）が“ＢａｔｃｈＬａｕｎｃｈＣｏｎｆｉｇ”で指定される。タグとして、“Ｒｏｌｅ”属性の値が“Ｂａｔｃｈ”であり、“Ｖｅｒｓｉｏｎ”属性の値が“１００”であることが指定される。ＢａｔｃｈＬａｕｎｃｈＣｏｎｆｉｇは、受け付けたリクエストに対応するキューに積まれた処理を順次実行するバッチ処理システムの設定の指示である。

３５４行目から１４０行目では、ＢａｔｃｈＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐで指定された“ＢａｔｃｈＬａｕｎｃｈＣｏｎｆｉｇ”という名前の仮想マシンを起動設定する。

図９Ｃの１４１行目から１５８行目では、ＢａｔｃｈＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐのオートスケールグループに関連付けられたオートスケールポリシーを指定する。ＢａｔｃｈＳｃａｌｅＵｐＰｏｌｉｃｙは、必要台数を１台増やす（“ＳｃａｌｉｎｇＡｄｊｕｓｔｍｅｎｔ”：“１”）操作を行うように指定される。また、ＢａｔｃｈＳｃａｌｅＤｏｗｎＰｏｌｉｃｙは、必要台数を１台減らす（“ＳｃａｌｉｎｇＡｄｊｕｓｔｍｅｎｔ”：“−１”）操作を行うように指定される。

１５９行目から１８４行目では、ＢａｔｃｈＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐのオートスケールグループに関連付けられた監視・通知条件が指定される。ＢａｔｃｈＱｕｅｕｅＡｌａｒｍＨｉｇｈでは、“ＢａｔｃｈＱｕｅｕｅ”について、監視項目（ＭｅｔｒｉｃＮａｍｅ）としてメッセージの数（“ＮｕｍｂｅｒＯｆＭｅｓｓａｇｅｓ”）の平均を監視する。そして、３００秒間隔で２回、閾値の１００を超えた場合、ＡｌａｒｍＡｃｔｉｏｎで指定した“ＢａｔｃｈＳｃａｌｅＵｐＰｏｌｉｃｙ”のオートスケールポリシーを実行することを設定する。

図１０は、本発明の実施形態に係る本番環境の切り替え処理の流れを示すフローチャートである。リソースマネージャ３０３が、本番環境の切り替え処理を実行する。

Ｓ１００１で、リソースマネージャ３０３は、システムマネージャ３００からの指示を受けて、Ｇｒｅｅｎ環境のリソース量調整処理を開始する。Ｓ１００２で、切り換え対象のＢｌｕｅ環境とＧｒｅｅｎ環境の指定をシステム管理者から受け付ける。システム管理者は、コンピュータ１１０を操作することによって切り換え対象のＢｌｕｅ環境とＧｒｅｅｎ環境とを指定し、切り替え部４０５は、この指定を含む要求を受信する。

指定方法としては、システム管理者が、Ｂｌｕｅ環境とＧｒｅｅｎ環境の各スタックＩＤ８０１を指定してもよいし、タグのＫｅｙとＶａｌｕｅで指定してもよい。Ｋｅｙはタグの属性であり、Ｖａｌｕｅは属性の値である。スタックＩＤ８０１で指定する場合、例えば、Ｂｌｕｅ環境のスタックＩＤ８０１をＳ０１、Ｇｒｅｅｎ環境のスタックＩＤ８０１をＳ０２として、システム管理者はＢｌｕｅ環境とＧｒｅｅｎ環境を指定する。システム管理者は、一度に複数のスタックを指定しても良い。タグを指定する場合には“Ｖｅｒｓｉｏｎ”のＫｅｙで識別し、例えば、Ｂｌｕｅ環境を“１００”、Ｇｒｅｅｎ環境を“１０１”として、システム管理者はＢｌｕｅ環境とＧｒｅｅｎ環境を指定する。

以降では例として、Ｂｌｕｅ環境のＫｅｙを“１００”、Ｇｒｅｅｎ環境のＫｅｙを“１０１”と設定するものとして説明する。またこの場合、オートスケールグループや仮想マシン、サーバーコンポーネントの所属するスタックのＩＤは、オートスケール管理ＩＤ７０１の文字列の先頭や、スタックＩＤ８０１などから取得され得る。

Ｓ１００３では、切り替え部４０５は、指定されたＢｌｕｅ環境とＧｒｅｅｎ環境のオートスケール状態の情報をオートスケール管理部４０３から取得する。Ｇｒｅｅｎ環境の情報として、“Ｖｅｒｓｉｏｎ”属性が“１０１”で示される。ここではオートスケール状態管理テーブル（図７）より、切り替え部４０５は、タグの中に「“Ｖｅｒｓｉｏｎ”：“１０１”」を含むリソース量の調整に関する情報（レコード７１５乃至７１８）を取得する。なお、切り替え部４０５は、指定されたＢｌｕｅ環境の情報のみを取得しても良い。また、Ｂｌｕｅ環境やＧｒｅｅｎ環境の情報は、管理システム１００内のデータベース３０２に格納されても良いし、管理システム１００の外部の記憶装置に格納されても良い。

続いて、リソースマネージャ３０３は、Ｇｒｅｅｎ環境のオートスケールグループまたはサーバーコンポーネントごとにＳ１００４からＳ１００７の処理を繰り返し行う。Ｓ１００７では、全てのオートスケールグループまたはサーバーコンポーネントに対する処理が終了したらループを抜ける。

Ｓ１００５では、切り替え部４０５は、オートスケールポリシーによる自動の調整機能を無効化する。無効化する自動の調整機能は、スケールインまたはスケールダウンのオートスケールポリシーによる自動の調整機能のみであってもよい。オートスケールの設定において、追加または削除する仮想マシンの数（ＳｃａｌｉｎｇＡｄｊｕｓｔｍｅｎｔ）が負の値であるオートスケールポリシーがスケールインの対象となる。なお、自動の調整機能を無効化するタイミングは、Ｓ１００５に限らず、Ｇｒｅｅｎ環境を生成した後からＧｒｅｅｎ環境のリソース量調整処理が開始されるまでのいずれかのタイミングでもよい。

Ｂｌｕｅ環境からＧｒｅｅｎ環境への切り替えの際には、Ｇｒｅｅｎ環境にかかる負荷が小さい状態で、Ｇｒｅｅｎ環境の仮想マシンの台数を増やしたり、サーバーコンポーネントをスケールアップさせたりする必要がある。スケールインのオートスケールポリシーを無効化することにより、Ｇｒｅｅｎ環境のリソースを増やした後にスケールインのＡｌａｒｍが発生して、Ｇｒｅｅｎ環境の仮想マシンの台数が減ったり、サーバーコンポーネントがスケールダウンしたりすることを防ぐ。また、オートスケールグループに対してオートスケールポリシーを適用する際に、ある一定時間、オートスケールグループへのオートスケールポリシーの適用を無効にするように設定するようにしても良い。

続いてＳ１００６で、リソース生成部４０１は、Ｇｒｅｅｎ環境のリソース量の調整処理を行う。Ｇｒｅｅｎ環境のリソース量の調整処理について、図１１を用いて後述する。

Ｓ１００７で、全てのオートスケールグループまたはサーバーコンポーネントに対する処理が終了していたら、切り替え部４０５はＳ１００８へ処理を進める。

Ｓ１００８で、切り替え部４０５は、本番環境をＢｌｕｅ環境からＧｒｅｅｎ環境に切り替える処理を行う。本番環境を切り替える方法については切り替え部４０５の説明部分で上述した通りである。本番環境を切り替える処理とは、具体的には、ＤＮＳ３０１のレコードをＢｌｕｅ環境のものからＧｒｅｅｎ環境のものに変更する処理などを指す。この処理によって、外部ネットワークからのリクエストを受け付けて処理する本番環境が切り替わる。さらに、本番環境が切り替わった後に、切り替え部４０５は、Ｓ１００５で無効化した自動の調整機能を有効化する。

図１１（ａ）は、本発明の実施形態に係るＧｒｅｅｎ環境のリソース量の調整処理の流れを示すフローチャートであり、「必要台数の適用」の移行方法を用いたＧｒｅｅｎ環境のリソース量の調整処理の流れを示す。Ｇｒｅｅｎ環境のリソース量の調整処理は、Ｇｒｅｅｎ環境のオートスケールグループまたはサーバーコンポーネントごとに実行される。

「必要台数の適用」とは、Ｂｌｕｅ環境において必要する仮想マシンの台数をＧｒｅｅｎ環境に適用するという移行方法である。Ｓ１１０１〜１１０４で、リソースマネージャ３０３は、「必要台数の適用」の移行方法によって、Ｇｒｅｅｎ環境のリソース量の調整処理を行う。「必要台数の適用」は、複数の仮想マシンを含むオートスケールグループなどに適用する場合に適している。

Ｓ１１０２では、切り替え部４０５は、繰り返し対象のオートスケールグループやサーバーコンポーネントなどに設定されている“Ｒｏｌｅ”属性の値が等しいＢｌｕｅ環境のオートスケールグループやサーバーコンポーネントの必要台数７０３を取得する。

切り替え部４０５は、オートスケール管理部４０３よりタグ７０７にＢｌｕｅ環境を示すタグ（“Ｖｅｒｓｉｏｎ”属性が“１００”）が含まれ、“Ｒｏｌｅ”属性の値が等しいオートスケールグループやサーバーコンポーネントを検索する。例えば、オートスケールＳ０２−ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐの場合、“Ｒｏｌｅ”属性の値は“Ｗｅｂ”である。このため、切り替え部４０５は、タグに「“Ｒｏｌｅ”：“Ｗｅｂ”」と「“Ｖｅｒｓｉｏｎ”：“１００”」が含まれ、かつ、タイプ７０２が同じである、行５１１のＳ０１−ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐを選択する。切り替え部４０５は、Ｓ０１−ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐの必要台数７０３の値である「５」を取得する。

続いて、Ｓ１１０３で、リソース生成部４０１は、Ｇｒｅｅｎ環境のオートスケールグループやサーバーコンポーネントなどに対して、リソース量の調整を行う。例えば、オートスケールＳ０２−ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐ（レコード５１５）の必要台数７０３が「５」に設定される。つまり、Ｓ１１０２で取得されたＢｌｕｅ環境のオートスケールグループやサーバーコンポーネントの必要台数７０３に基づいて、Ｇｒｅｅｎ環境のオートスケールグループやサーバーコンポーネントの必要台数７０３が設定される。オートスケール管理部４０３は、オートスケールＳ０２−ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐの稼働台数（＝２）が、必要台数（＝５）に達していないことを検知する。すると、オートスケール管理部４０３は、オートスケールグループのスタックＳ０２のＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐの仮想マシンの起動設定（ＷｅｂＬａｕｎｃｈＣｏｎｆｉｇ）に従い生成された仮想マシンをオートスケールグループに追加する。最終的に、稼働台数７０４が「５」になることにより、Ｂｌｕｅ環境の必要台数７０３がＧｒｅｅｎ環境に適用される。

なお、Ｂｌｕｅ環境の必要台数７０３がそのままＧｒｅｅｎ環境に適用されなくても良い。例えば、Ｂｌｕｅ環境の必要台数７０３やＧｒｅｅｎ環境の仮想マシンのスペック７０５の情報に基づいて、Ｇｒｅｅｎ環境の必要台数７０３が設定されても良い。

なお、現在本番環境であるＢｌｕｅ環境の処理能力にある程度の余裕を持たせるために、Ｂｌｕｅ環境にかかっている負荷を処理するために必要な台数よりも多くの台数の仮想マシンを稼働させている場合がある。その場合には、切り替え部４０５は、それらを考慮してＧｒｅｅｎ環境の必要台数７０３を設定しても良い。

なお、システムマネージャ３００は、本番環境切り替え前の所定期間においてＢｌｕｅ環境が受け付けたリクエスト量に基づいて、本番環境切り替え時のリクエスト量を予測してもよい。例えば、単位時間当たりのリクエスト数を表すグラフを使って、Ｂｌｕｅ環境でのリソース量調整に関する情報取得時における、リクエスト量の増減を表す傾きを求める。システムマネージャ３００は、Ｂｌｕｅ環境の必要台数に、更にリクエスト数の増減を考慮して、Ｇｒｅｅｎ環境の必要台数を定めてもよい。後述の応用例においても同様である。

Ｓ１１０４で、切り替え部４０５は、図１０のフローチャートへ戻り、処理を進める。

本実施例では、本番環境を第１の処理システムから第２の処理システムへ切り替える前に、切り替え先の処理システムである第２の処理システムの仮想マシンの台数を、第１の処理システムの仮想マシンの台数と同じにする。本実施例によって、本番環境の切り替えの際に、第２の処理システムでのリクエストの処理が滞らないようにすることができる。

（実施例２）
本実施例においては、実施例１と基本的には同様であるため、その差分のみを説明する。Ｓ１００６のＧｒｅｅｎ環境のリソース量の調整処理において、実施例１では「必要台数の適用」の移行方法を用いたが、本実施例では「負荷状態の適用」の移行方法を用いる。本実施例では、監視されるリクエスト量や処理負荷の情報が、Ｇｒｅｅｎ環境のリソース量調整処理に用いられる。

図１１（ｂ）は、本発明の実施形態に係るＧｒｅｅｎ環境における処理の流れを示すフローチャートであり、「負荷状態の適用」の移行方法によるＧｒｅｅｎ環境のリソース量の調整処理の流れの例を示す。Ｇｒｅｅｎ環境のリソース量の調整処理は、Ｇｒｅｅｎ環境のオートスケールグループまたはサーバーコンポーネントごとに実行される。

「負荷状態の適用」とは、Ｂｌｕｅ環境の負荷状態の情報をＧｒｅｅｎ環境に適用するという移行方法である。Ｓ１１１１からＳ１１１５で、リソースマネージャ３０３は、「負荷状態の適用」の移行方法によって、Ｇｒｅｅｎ環境のリソース量の調整処理を行う。「負荷状態の適用」は、Ｇｒｅｅｎ環境がＢｌｕｅ環境とサーバー構成や仮想マシンのスペックなどで違いがある場合など、Ｂｌｕｅ環境の必要台数７０３をそのまま適用する方法が適当でない場合に適している。「負荷状態の適用」は、必要台数の情報を取得することができない場合にも適用できる。

Ｓ１１１２では、切り替え部４０５は、Ｂｌｕｅ環境のオートスケールグループやサーバーコンポーネントの負荷状態を示す情報を取得する。

例えば、オートスケールグループＳ０２−ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐの場合、関連付けられているオートスケールポリシーは、ＷｅｂＳｃａｌｅＵｐＰｏｌｉｃｙとＷｅｂＳｃａｌｅＤｏｗｎＰｏｌｉｃｙである。さらに関連する監視条件は、ＷｅｂＣＰＵＡｌａｒｍＨｉｇｈとＷｅｂＣＰＵＡｌａｒｍＬｏｗであり、切り替え部４０５はこれら２つの監視条件を検索する。Ｒ１４のキューでは、２つの監視条件Ｓ０２−ＢａｔｃｈＱｕｅｕｅＡｌａｒｍＨｉｇｈとＳ０２−ＢａｔｃｈＱｕｅｕｅＡｌａｒｍＬｏｗが関連付けられている。切り替え部４０５は、これらの監視条件で監視リソース６０２として指定されているリソースと“Ｒｏｌｅ”属性の値が等しいＢｌｕｅ環境のオートスケールグループやサーバーコンポーネントのオートスケール状態の情報を取得する。

例えば、Ｒ１４のキューの場合には、リソース情報管理テーブル（図５）のレコード５２２より、Ｒ１４のタグ情報より、“Ｒｏｌｅ”属性の値は“Ｂａｔｃｈ”であることがわかる。切り替え部４０５は、Ｂｌｕｅ環境で“Ｒｏｌｅ”属性の値が“Ｂａｔｃｈ”であるキューは行５１４のＲ０４であることを検索し、Ｒ０４の負荷状態（ＮｕｍｂｅｒＯｆＭｅｓｓａｇｅｓ）を取得する。

続いて、Ｓ１１１２で取得したＢｌｕｅ環境のリクエスト量や処理負荷など負荷状態の情報に基づいて、Ｓ１１１３で、切り替え部４０５は、Ｇｒｅｅｎ環境のリソース量の調整が必要であるかどうかを判定する。

例えば、キューＲ１４の場合には、切り替え部４０５は、キューＲ０４の負荷状態を元にＳ０２−ＢａｔｃｈＱｕｅｕｅＡｌａｒｍＨｉｇｈまたはＳ０２−ＢａｔｃｈＱｕｅｕｅＡｌａｒｍＬｏｗの条件に合致するかを判定する。負荷状態を指定間隔で複数回測定する設定である場合には、切り替え部４０５は、複数回測定するようにしてもよいし、１回の測定で代替えすることもできる。なお、本番環境切り替え時にのみ参照されるオートスケールポリシーが用意されてもよい。

Ｇｒｅｅｎ環境のリソース量の調整が必要であると判定された場合、Ｓ１１１４に進み、リソース生成部４０１は、Ｇｒｅｅｎ環境のリソース量を調整する。なお、Ｇｒｅｅｎ環境のリソース量の調整が必要でないと判定された場合は、Ｓ１１１５に進む。

Ｓ１１１５で、切り替え部４０５は、図１０のフローチャートへ戻って処理を進める。

なお、リソースマネージャ３０３は、Ｂｌｕｅ環境の処理能力にある程度の余裕を持たせるようにして、Ｇｒｅｅｎ環境の必要台数７０３やスペック７０５を設定しても良い。

オートスケールグループの場合には、リソースマネージャ３０３は、Ｓ１１１３で上限に合致した監視条件に関連付けられたオートスケールポリシーに基づいて、必要台数などを設定する。この時、Ｂｌｕｅ環境３３０のロードバランサー３３１が受け付けるリクエスト量と、Ｇｒｅｅｎ環境で処理可能なリクエスト量とが一致するように、必要台数７０３などが設定される。キューなどマネージドサービスとして提供されるサーバーコンポーネントなどでシステム管理者はオートスケールの設定を指定できない場合もある。このような場合は、オートスケール管理部４０３の内部で管理する設定に基づき、リソースマネージャ３０３は、必要台数やスペックを計算しサーバーコンポーネントに適用する。 なお、システムマネージャ３００は、本番環境切り替え前の所定期間においてＢｌｕｅ環境が受け付けたリクエスト量に基づいて、本番環境切り替え時のリクエスト量を予測してもよい。システムマネージャ３００は、Ｂｌｕｅ環境のロードバランサーが受け付けているリクエスト量に、更にリクエスト量の増減を考慮して、Ｇｒｅｅｎ環境が処理可能となるリクエスト量を定めてもよい。後述の応用例においても同様である。

本実施例では、本番環境を第１の処理システムから第２の処理システムへ切り替える前に、第１の処理システムの負荷状態の情報を用いて、第２の処理システムのリソース量を増やす。第２の処理システムのリソース量を増やす方法として、第２の処理システムが本番環境である時に実行されるように設定されているオートスケールによるリソース量の調整処理が実行されてもよい。また他の方法として、本番環境の切り替え処理の時に実行されるリソース量の調整処理を設定しておき、そのリソース量の調整処理が実行されてもよい。本実施例によって、第１の処理システムと第２の処理システムとで、サーバー構成や仮想マシンのスペックなどで違いがある場合などにも、本番環境の切り替えの際に、第２の処理システムでのリクエストの処理が滞らないようにすることができる。

（実施例３）
本実施例においては、実施例１と基本的には同様であるため、その差分のみを説明する。Ｓ１００６のＧｒｅｅｎ環境のリソース量の調整処理において、実施例１では「必要台数の適用」、実施例２では「負荷状態の適用」の移行方法を用いたが、本実施例では「最終実行操作の適用」の移行方法を用いる。本実施例では、Ｂｌｕｅ環境のリソース量の調整に関する情報の取得時において、Ｂｌｕｅ環境で最後に実行されたリソース量の調整処理が、Ｇｒｅｅｎ環境においても実行される。

図１１（ｃ）は、本発明の実施形態に係るＧｒｅｅｎ環境における処理の流れを示すフローチャートであり、「最終実行操作の適用」の移行方法によるＧｒｅｅｎ環境のリソース量の調整処理の流れの例を示す。Ｇｒｅｅｎ環境のリソース量の調整処理は、Ｇｒｅｅｎ環境のオートスケールグループまたはサーバーコンポーネントごとに実行される。

「最終実行操作の適用」とは、Ｂｌｕｅ環境のサーバーコンポーネントなどに対して最後に実行された操作として保持される制御コマンドを、Ｇｒｅｅｎ環境の該当するサーバーコンポーネントなどに対して実行し、適用するという移行方法である。Ｓ１１２１からＳ１１２４で、リソースマネージャ３０３は、「最終実行操作の適用」の移行方法によって、Ｇｒｅｅｎ環境のリソース量の調整処理を行う。「最終実行操作の適用」は、必要台数の情報や負荷状態の情報を取得することができない場合などにも適用できる。

Ｓ１１２２では、切り替え部４０５は、“Ｒｏｌｅ”属性が同一である、Ｂｌｕｅ環境のサーバーコンポーネントに対して、最終実行操作７０６を取得する。Ｓ１１２２での取得時において、最終実行操作７０６は、Ｂｌｕｅ環境のサーバーコンポーネントで最後に実行されたリソース量の調整処理である。切り替え部４０５は、繰り返し対象のオートスケールグループやサーバーコンポーネントなどに設定されている“Ｒｏｌｅ”属性の値が等しいＢｌｕｅ環境のオートスケールグループやサーバーコンポーネントの最終実行操作７０６を取得する。切り替え部４０５は、タグ７０７にＢｌｕｅ環境を示すタグ（“Ｖｅｒｓｉｏｎ”属性が“１００”）が含まれ、“Ｒｏｌｅ”属性の値が等しいオートスケールグループ、サーバーコンポーネントを検索する。

例えば、ロードバランサーＲ１１の場合、切り替え部４０５は、“Ｒｏｌｅ”属性の値は“Ｗｅｂ”であるので、タグに「“Ｒｏｌｅ”：“Ｗｅｂ”」と「“Ｖｅｒｓｉｏｎ”：“１００”」が含まれ、タイプ７０２が同じ行５１２のロードバランサーＲ０１を選択する。そして、切り替え部４０５は、Ｒ１の最終実行操作７０６の値である「“Ｃｈａｎｇｅ Ｔｙｐｅ＝Ｍｉｄｉｕｍ”」を取得する。

続いて、Ｓ１１２３で、オートスケール管理部４０３は、Ｇｒｅｅｎ環境のオートスケールグループやサーバーコンポーネントなどに対して、同じオートスケール機能の設定の操作を実行する。

例えば、オートスケール管理部４０３は、ロードバランサーＲ１１に対して、Ｓ８１５で取得した情報の最終実行操作７０６「“Ｃｈａｎｇｅ Ｔｙｐｅ＝Ｍｉｄｉｕｍ”」を実行する。この操作を受けてロードバランサーＲ１１は、内包する仮想マシンの台数を増やすなどのオートスケールを実行する。

Ｓ１１２４で、切り替え部４０５は、図１０のフローチャートへ戻り、処理を進める。

なお、システムマネージャ３００は、本番環境切り替え前の所定期間においてＢｌｕｅ環境が受け付けたリクエスト量に基づいて、本番環境切り替え時のリクエスト量を予測してもよい。システムマネージャ３００は、Ｂｌｕｅ環境で最後に実行されたリソース量の調整処理に、更にリクエスト量の増減を考慮して、Ｇｒｅｅｎ環境のリソース量の調整処理を実行してもよい。後述の応用例においても同様である。

本実施例では、本番環境の切り替え指示に応じて、第１の処理システムで最後に実行されたリソース量の調整処理と同じ操作を第２の処理システムで実行する。本実施例によって、仮想マシンの台数や負荷状態を示す情報を取得できない場合にも、本番環境の切り替えの際に、第２の処理システムでのリクエストの処理が滞らないようにすることができる。

（応用例１）
Ｓ１００６のＧｒｅｅｎ環境のリソース量の調整処理においては、切り替え部４０５は、実施例１乃至３の移行方法のうち、どの移行方法を用いるかのスタックテンプレートでの任意の設定に従い、切り替えを制御しても良い。この設定は、処理システム内の全てのオートスケールグループやサーバーコンポーネントに共通しても良い。なお、本実施例では、オートスケールグループやサーバーコンポーネントごとに移行方法を設定する場合について述べる。

図１２は、本発明の実施形態に係るスタックテンプレートの例を示す図であり、移行方法が記載されている。１８６行目から１９９行目では、Ｂｌｕｅ環境とＧｒｅｅｎ環境の切り替えにおけるオートスケール状態情報の反映の動作設定を指定している。

１８６行目から１９９行目では、本番環境切り替え時におけるＧｒｅｅｎ環境のリソース量調整処理の際の移行方法に関する設定を指定する。例えば、この設定は、切り替え部４０５で切り替えの指示を受け付けた場合に参照される。

設定例として、１８７行目から１９３行目では、Ｋｅｙが“Ｒｏｌｅ”の属性の値として“Ｗｅｂ”が指定されたオートスケールグループについての動作設定がされている。その移行方法（ＭｉｇｒａｔｅＭｅｔｈｏｄ）として「必要台数の適用」（“ＣｏｐｙＤｅｓｉｒｅｄＣａｐａｃｉｔｙ”）が指定されている。

切り替え部４０５は、Ｇｒｅｅｎ環境のリソース量調整処理のために参照するＢｌｕｅ環境の情報を選択して、移行方法を設定する。まず、切り替え部４０５は、繰り返し対象のオートスケールグループまたはサーバーコンポーネントについてＧｒｅｅｎ環境のスタックテンプレートで指定されている移行方法に合致するものを検索する。切り替え部４０５は、Ｇｒｅｅｎ環境のスタックテンプレートをスタック受け付け部４０４から取得する。

オートスケール状態の情報５１５のオートスケールグループ“Ｓ０２−ＷｅｂＡｕｔｏＳｃａｌｉｎｇＧｒｏｕｐ”は、“Ｒｏｌｅ”属性が“Ｗｅｂ”であり、スタックテンプレートの１８７行目から１９３行目で指定された１つ目の移行設定に合致する。そして、その移行方法は「必要台数の適用」である。なお、切り替え部４０５は、スタックテンプレートを参照せずに、予め決められた移行方法を採用するようにしてもよい。

別の設定例として、１９４行目から１９８行目では、Ｋｅｙが“Ｒｏｌｅ”の属性の値として“Ｂａｔｃｈ”が指定されたオートスケールグループについての動作設定がされている。その移行方法（ＭｉｇｒａｔｅＭｅｔｈｏｄ）として「なし」（“Ｎｏｎｅ”）が指定されている。

リソースマネージャ３０３は、Ｂｌｕｅ環境の仮想マシン３３２の必要台数７０３をＧｒｅｅｎ環境の仮想マシン３５２に適用するが、Ｂｌｕｅ環境の仮想マシン３３４の必要台数７０３をＧｒｅｅｎ環境の仮想マシン３５４には適用しない。仮想マシン３３２はＷｅｂサーバーなどであり所定のネットワークシステムからの大量のリクエストを処理するため、環境切り替え前にＧｒｅｅｎ環境の仮想マシン３５２は必要台数７０３の分だけ用意される必要がある。しかし、仮想マシン３３４はバッチサーバーなどでありメッセージキューを受け取ってから処理するため、仮想マシン３５４はＧｒｅｅｎ環境のオートスケール機能により台数が増えればよい。所定のネットワークシステムからのリクエスト数に同期してメッセージキューが増えるわけではないからである。したがって、本番環境切り替え前にＧｒｅｅｎ環境の仮想マシン３５４を増やす必要はない。

１９４行目から１９８行目までの設定によって、システム管理者は、処理システムの切り替え時における、バッチサーバーのサーバー料金を節約することができる。

スタックテンプレートの移行方法に合致しない場合には、切り替え部４０５は、図１３を参照して、仮想マシンやサーバーコンポーネントなどの種別による移行方法を設定する。

図１３は、本発明の実施形態に係るサーバーコンポーネント別の移行方法テーブルの例を示す図である。切り替え部４０５が、例えば、レコード１３１１、１３１２で示されるような、移行方法の情報を管理する。タイプ１３０１は仮想マシンやサーバーコンポーネントなどの種別を示し、移行方法１３０２はタイプごとの移行方法を示す。例えば、リソースＩＤ５０１がＲ１１であるロードバランサーの移行方法を決定する際に、切り替え部４０５は、図１３の行１３１１を参照し、移行方法を“最終実行操作の適用”に決定する。また、Ｒ１４のキューの場合には、切り替え部４０５は、行１３１２を参照し、移行方法を“負荷状態の適用”に決定する。なお、移行方法が決まらない場合には、切り替え部４０５は、移行方法を“Ｎｏｎｅ”とする。

本実施例によって、処理システムを構成するリソースのグループごとに移行方法を設定し、本番環境の切り替えの際に、それぞれのグループについて設定された移行方法に則ったリソース量の調整処理が実行される。

（応用例２）
図１０、図１１のフローチャートで示される処理の一部は、リソースマネージャ３０３によってではなく、システムマネージャ３００によって実行されてもよい。

図１０で示されるＳ１００８では、Ｇｒｅｅｎ環境のリソース量が実際に調整された後に、本番環境がＢｌｕｅ環境からＧｒｅｅｎ環境へ切り替えられる。システムマネージャ３００が、リソースマネージャ３０３のリソース生成部４０１に対してリソース量の調整指示を出してから、実際にリソース量が調整されるまでに時間がかかる場合がある。そのため、例えば、システムマネージャ３００は、図７における稼働台数７０４が必要台数７０３と同じ値になったことを確認してから、本番環境の切り替え指示を出す。

また、切り替え指示が出された後、Ｇｒｅｅｎ環境のリソース量が調整されるタイミングは、実際に切り替えられた直後でもよい。ただし、オートスケールによってＧｒｅｅｎ環境のリソース量の調整が間に合う必要がある。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の一つである。また、そのプログラムは、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給され、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の一つとして、さらにそのプログラム自体、あるいは該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１００ 管理システム
３００ システムマネージャ

Claims (20)

1. リクエストを処理する１以上の仮想マシンと、該仮想マシンにリクエストを分散させる負荷分散装置とを少なくとも備える処理システムを複数有する管理システムであって、
   所定のネットワークシステムからのリクエストを処理する処理システムを、前記複数の処理システムに含まれる第１の処理システムから第２の処理システムへ切り替えるための指示に応じて、該第１の処理システムを実現するために使用されているリソースの量の調整に関する情報を取得する取得手段と、
   前記取得手段が取得した情報に基づく前記第２の処理システムのリソースの量の調整指示として、前記第２の処理システムの仮想マシンの台数を増やすための指示を行う調整指示手段と、を有し、
   前記調整指示手段による前記調整指示に応じて、所定のネットワークシステムからのリクエストを処理する処理システムが、前記第１の処理システムから前記第２の処理システムへ切り替わることを特徴とする管理システム。
2. 前記第１の処理システムおよび前記第２の処理システムはそれぞれ、前記負荷分散装置からリクエストを受け付けて処理する１以上の仮想マシンから構成されるリクエスト処理システムと、前記リクエスト処理システムで処理されたリクエストに対応するメッセージを処理する１以上の仮想マシンから構成されるバッチ処理システムと、を有し、
   前記調整指示手段は、前記取得手段が取得した情報に基づいて、前記第２の処理システムの前記バッチ処理システムではなく、前記第２の処理システムの前記リクエスト処理システムに対する調整指示を行うことを特徴とする請求項１に記載の管理システム。
3. 前記調整指示手段は、前記取得手段が取得した情報に基づく前記第２の処理システムのリソースの量の調整指示として、更に、前記第２の処理システムの仮想マシンに対するハードウェア資源の割り当てを増やすための指示を行うことを特徴とする請求項１または２に記載の管理システム。
4. 前記第１の処理システムおよび前記第２の処理システムのそれぞれが使用するリソースは、１以上のサーバーコンピュータにより提供されることを特徴とする請求項１乃至３のいずれか１項に記載の管理システム。
5. 所定のネットワークシステムからのリクエストを処理する処理システムが、前記第１の処理システムから前記第２の処理システムへ切り替わった後に、受け付けるリクエストの量に応じて前記第２の処理システムのリソースの量を減らす調整を自動で行う調整機能が有効化されることを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
6. 前記取得手段が取得する情報は、前記第１の処理システムの仮想マシンの台数、前記第１の処理システムが受け付けるリクエストの量、および、前記第１の処理システムで最後に実行された調整を示す情報のうちの少なくとも１つであることを特徴とする請求項１乃至５のいずれか１項に記載の管理システム。
7. 前記処理システムは、１以上の仮想マシンと１以上の負荷分散装置の少なくともいずれかから構成される複数のグループに分けられて管理されており、
   前記第２の処理システムが使用するリソースのグループごとに、前記調整指示手段による指示に用いる前記第１の処理システムの情報として、前記第１の処理システムの仮想マシンの台数、前記第１の処理システムが受け付けるリクエストの量、および、前記第１の処理システムで最後に実行された調整を示す情報のうちいずれか１つを設定する設定手段を更に有し、
   前記取得手段は、前記設定手段による設定に従い、前記第１の処理システムの仮想マシンの台数、前記第１の処理システムが受け付けるリクエストの量、および、前記第１の処理システムで最後に実行された調整を示す情報のうちの少なくとも１つを取得し、
   前記調整指示手段は、前記第２の処理システムが使用するリソースのグループごとに、前記取得手段が取得した情報に基づく前記第２の処理システムのリソースの量の調整指示を行うことを特徴とする請求項６に記載の管理システム。
8. 前記調整指示手段は、前記取得手段により前記第１の処理システムが受け付けるリクエストの量、または、前記第１の処理システムにかかるリクエスト処理のための負荷を示す情報が取得された場合に、当該取得された情報に基づいて、前記第２の処理システムのリソースの量の調整指示を行うことを特徴とする請求項１乃至６のいずれか１項に記載の管理システム。
9. 前記調整指示手段は、前記取得手段により前記第１の処理システムで最後に実行された調整を示す情報が取得された場合に、前記第２の処理システムのリソースの量を調整指示として、前記取得手段により取得された情報で示される調整を前記第２の処理システムで実行することを指示することを特徴とする請求項１乃至６のいずれか１項に記載の管理システム。
10. 前記第１の処理システムの仮想マシンで動作するアプリケーションと、前記第２の処理システムの仮想マシンで動作するアプリケーションとのバージョンがそれぞれ異なることを特徴とする請求項１乃至９のいずれか１項に記載の管理システム。
11. リクエストを処理する１以上の仮想マシンと、該仮想マシンにリクエストを分散させる負荷分散装置とを少なくとも備える処理システムを複数有する管理システムの制御方法であって、
    所定のネットワークシステムからのリクエストを処理する処理システムを、前記複数の処理システムに含まれる第１の処理システムから第２の処理システムへ切り替えるための指示に応じて、該第１の処理システムを実現するために使用されているリソースの量の調整に関する情報を取得する取得工程と、
    前記取得工程で取得された情報に基づく前記第２の処理システムのリソースの量の調整指示として、前記第２の処理システムの仮想マシンの台数を増やすための指示を行う調整指示工程と、を有し、
    前記調整指示工程での前記調整指示に応じて、所定のネットワークシステムからのリクエストを処理する処理システムが、前記第１の処理システムから前記第２の処理システムへ切り替わることを特徴とする制御方法。
12. 前記第１の処理システムおよび前記第２の処理システムはそれぞれ、前記負荷分散装置からリクエストを受け付けて処理する１以上の仮想マシンから構成されるリクエスト処理システムと、前記リクエスト処理システムで処理されたリクエストに対応するメッセージを処理する１以上の仮想マシンから構成されるバッチ処理システムと、を有し、
    前記調整指示工程では、前記取得工程で取得された情報に基づいて、前記第２の処理システムの前記バッチ処理システムではなく、前記第２の処理システムの前記リクエスト処理システムに対する調整指示が行われることを特徴とする請求項１１に記載の制御方法。
13. 前記調整指示工程では、前記取得工程で取得された情報に基づく前記第２の処理システムのリソースの量の調整指示として、更に、前記第２の処理システムの仮想マシンに対するハードウェア資源の割り当てを増やすための指示が行われることを特徴とする請求項１１または１２に記載の制御方法。
14. 前記第１の処理システムおよび前記第２の処理システムのそれぞれが使用するリソースは、１以上のサーバーコンピュータにより提供されることを特徴とする請求項１１乃至１３のいずれか１項に記載の制御方法。
15. 所定のネットワークシステムからのリクエストを処理する処理システムが、前記第１の処理システムから前記第２の処理システムへ切り替わった後に、受け付けるリクエストの量に応じて前記第２の処理システムのリソースの量を減らす調整を自動で行う調整機能が有効化されることを特徴とする請求項１１乃至１４のいずれか１項に記載の制御方法。
16. 前記取得工程で取得される情報は、前記第１の処理システムの仮想マシンの台数、前記第１の処理システムが受け付けるリクエストの量、および、前記第１の処理システムで最後に実行された調整を示す情報のうちの少なくとも１つであることを特徴とする請求項１１乃至１５のいずれか１項に記載の制御方法。
17. 前記処理システムは、１以上の仮想マシンと１以上の負荷分散装置の少なくともいずれかから構成される複数のグループに分けられて管理されており、
    前記第２の処理システムが使用するリソースのグループごとに、前記調整指示工程での指示に用いる前記第１の処理システムの情報として、前記第１の処理システムの仮想マシンの台数、前記第１の処理システムが受け付けるリクエストの量、および、前記第１の処理システムで最後に実行された調整を示す情報のうちいずれか１つを設定する設定工程を更に有し、
    前記取得工程では、前記設定工程での設定に従い、前記第１の処理システムの仮想マシンの台数、前記第１の処理システムが受け付けるリクエストの量、および、前記第１の処理システムで最後に実行された調整を示す情報のうちの少なくとも１つが取得され、
    前記調整指示工程では、前記第２の処理システムが使用するリソースのグループごとに、前記取得工程で取得された情報に基づく前記第２の処理システムのリソースの量の調整指示が行われることを特徴とする請求項１６に記載の制御方法。
18. 前記調整指示工程では、前記取得工程で前記第１の処理システムが受け付けるリクエストの量、または、前記第１の処理システムにかかるリクエスト処理のための負荷を示す情報が取得された場合に、当該取得された情報に基づいて、前記第２の処理システムのリソースの量の調整指示が行われることを特徴とする請求項１１乃至１６のいずれか１項に記載の制御方法。
19. 前記調整指示工程では、前記取得工程で前記第１の処理システムで最後に実行された調整を示す情報が取得された場合に、前記第２の処理システムのリソースの量を調整指示として、前記取得工程で取得された情報で示される調整を前記第２の処理システムで実行することが指示されることを特徴とする請求項１１乃至１６のいずれか１項に記載の制御方法。
20. 前記第１の処理システムの仮想マシンで動作するアプリケーションと、前記第２の処理システムの仮想マシンで動作するアプリケーションとのバージョンがそれぞれ異なることを特徴とする請求項１１乃至１９のいずれか１項に記載の制御方法。

Images