(57)【要約】      （修正有）【課題】第１の処理システムから第２の処理システムへのリクエスト処理の本番環境の切り替えの際に、第２の処理システムでのリクエストの処理が滞らないようにするリクエスト振り分けシステムを提供する。【解決手段】リクエストの処理に用いるリソースを調整可能な第１の処理システム及び第２の処理システムと接続するリクエスト振り分けシステムであって、所定のネットワークシステムからのリクエストを処理する処理システムを、第１の処理システムから第２の処理システムへ切り替える際に、切り替えが開始されてから完了する前までの間、受信された複数のリクエストを前記第１の処理システム及び第２の処理システムに振り分けるように、該複数のリクエストのそれぞれの送信先となる処理システムを決定する。【選択図】図６
2016218530.tif 000002
【特許請求の範囲】
【請求項１】
リクエストの処理に用いるリソースを調整可能な第１の処理システムおよび第２の処理システムと接続するリクエスト振り分けシステムであって、
リクエストを受信する受信手段と、
前記受信手段により受信されたリクエストの送信先となる処理システムを決定する決定手段と、
前記決定手段により決定された処理システムに前記受信手段により受信されたリクエストを送信する送信手段と、を有し、
前記決定手段は、所定のネットワークシステムからのリクエストを処理する処理システムを、前記第１の処理システムから前記第２の処理システムへ切り替える際に、当該切り替えが開始されてから完了する前までの間、前記受信手段により受信された複数のリクエストを前記第１の処理システムおよび前記第２の処理システムに振り分けるように、該複数のリクエストのそれぞれの送信先となる処理システムを決定することを特徴とするリクエスト振り分けシステム。
【請求項２】
前記決定手段は、前記切り替えが開始されてから完了する前までの間、前記受信手段により受信された複数のリクエストの一部に対応する送信先を前記第２の処理システムに決定し、その他のリクエストの送信先を前記第１の処理システムに決定することを特徴とする請求項１に記載のリクエスト振り分けシステム。
【請求項３】
前記決定手段は、前記切り替えが開始されてから完了する前までの間、前記受信手段により受信されたリクエストについて、該リクエストに含まれる識別情報に従い、該リクエストの送信先となる処理システムを決定することを特徴とする請求項１または２に記載のリクエスト振り分けシステム。
【請求項４】
前記決定手段は、要求元として第１の識別情報を含む第１のリクエストを前記受信手段により受信した場合、該第１のリクエストの送信先を前記第２の処理システムに決定し、
要求元以外の情報として前記第１の識別情報を含む第２のリクエストを前記受信手段により受信した場合、該第２のリクエストの送信先を前記第２の処理システムに決定することを特徴とする請求項１乃至３のいずれか１項に記載のリクエスト振り分けシステム。
【請求項５】
前記リクエスト振り分けシステムは、
リクエストの送信先となる処理システムを決定するための指定情報として、前記所定のネットワークシステムに属する複数の利用者のうち一部の利用者を示す情報を指定する指定手段を更に有し、
前記決定手段は、前記切り替えが開始されてから完了する前までの間、前記受信手段により受信されたリクエストについて、該リクエストに含まれる識別情報および前記指定手段による指定に従い、該リクエストの送信先となる処理システムを決定することを特徴とする請求項１乃至３に記載のリクエスト振り分けシステム。
【請求項６】
前記決定手段は、前記受信手段により受信されたリクエストに含まれる複数の識別情報および前記指定手段による指定に従い、該リクエストの送信先となる処理システムを決定することを特徴とする請求項５に記載のリクエスト振り分けシステム。
【請求項７】
前記決定手段は、前記受信手段により受信されたリクエストに要求元として含まれる第２の識別情報が前記指定手段により指定されていなかった場合であっても、該リクエストに、前記指定手段により指定された、前記第２の識別情報とは異なる第１の識別情報が含まれる際には、該リクエストの送信先を第２の処理システムに決定することを特徴とする請求項５または６に記載のリクエスト振り分けシステム。
【請求項８】
前記決定手段は、前記受信手段により受信されたリクエストに要求元として含まれる第２の識別情報が前記指定手段により指定されていなかった場合であっても、該リクエストに、前記指定手段により指定された、前記第２の識別情報とは異なる第１の識別情報が含まれる際には、該リクエストの送信先を第２の処理システムに決定することを特徴とする請求項５または６に記載のリクエスト振り分けシステム。
【請求項９】
前記指定手段は、前記切り替えを開始するための指示が前記リクエスト振り分けシステムにより受信されたことに応じて、前記複数の利用者を示す情報のうち一部を指定する処理を開始することを特徴とする請求項５乃至７のいずれか１項に記載のリクエスト振り分けシステム。
【請求項１０】
前記指定手段は、前記切り替えを開始するための指示が前記リクエスト振り分けシステムにより受信された後、前記受信手段が初めてリクエストを受信した時に、前記複数の利用者を示す情報のうち一部を指定する処理を開始することを特徴とする請求項５乃至９のいずれか１項に記載のリクエスト振り分けシステム。
【請求項１１】
前記指定手段は、前記複数の利用者のうち一部の利用者を示す情報を指定する処理を開始した後、前記複数の利用者の全てを示す情報が指定されるまで、所定の時間間隔ごとに、前記複数の利用者のうち一部の利用者を示す情報を指定する処理を繰り返し実行することを特徴とする請求項５乃至１０のいずれか１項に記載のリクエスト振り分けシステム。
【請求項１２】
前記第１の処理システム及び前記第２の処理システムは、１以上のサーバコンピュータにより提供されるリソースとしての１以上の仮想マシンで構築され、
前記リソースの調整には、前記所定のネットワークシステムからのリクエストの量または該リクエストを処理するための負荷に応じた仮想マシンの台数の増減が含まれることを特徴とする請求項１乃至１１のいずれか１項に記載のリクエスト振り分けシステム。
【請求項１３】
前記第２の処理システムは、前記所定のネットワークシステムからのリクエストの処理において前記第１の処理システムで扱えないデータを扱う処理システムであることを特徴とする請求項１乃至１２のいずれか１項に記載のリクエスト振り分けシステム。
【請求項１４】
リクエストの処理に用いるリソースを調整可能な第１の処理システムおよび第２の処理システムを含むシステムであって、
リクエストを受信する受信手段と、
前記受信手段により受信されたリクエストの送信先となる処理システムを決定する決定手段と、
前記決定手段により決定された処理システムに前記受信手段により受信されたリクエストを送信する送信手段と、を有し、
前記決定手段は、所定のネットワークシステムからのリクエストを処理する処理システムを、前記第１の処理システムから前記第２の処理システムへ切り替える際に、当該切り替えが開始されてから完了する前までの間、前記受信手段により受信された複数のリクエストを前記第１の処理システムおよび前記第２の処理システムに振り分けるように、該複数のリクエストのそれぞれの送信先となる処理システムを決定することを特徴とする管理システム。
【請求項１５】
前記管理システムは、
リクエストの送信先となる処理システムを決定するための指定情報として、前記システムを利用する複数の利用者のうち一部の利用者を示す情報を指定する指定手段を更に有し、
前記決定手段は、前記切り替えが開始されてから完了する前までの間、前記受信手段により受信されたリクエストについて、該リクエストに含まれる識別情報および前記指定手段による指定に従い、該リクエストの送信先となる処理システムを決定することを特徴とする請求項１４に記載の管理システム。
【請求項１６】
前記管理システムは、
リクエストの接続先を指定するための指示を行う接続先指定手段を有し、
前記接続先指定手段は、前記システムに対する前記切り替えの開始の要求に従い、前記受信手段と前記決定手段と前記送信手段とが生成された後に、リクエストの接続先を前記受信手段に指定するよう指示することを特徴とする請求項１４または１５に記載の管理システム。
【請求項１７】
前記接続先指定手段が、前記システムを利用する複数の利用者の全てを示す情報が前記指定手段により指定された後、リクエストの接続先を前記第２の処理システムに指定するよう指示したことに応じて、前記受信手段と前記決定手段と前記送信手段とが削除されることを特徴とする請求項１４乃至１６のいずれか１項に記載の管理システム。
【請求項１８】
前記管理システムは、
少なくとも前記受信手段および前記送信手段の動作を確認する動作確認手段を有し、
前記接続先指定手段は、前記システムに対する前記切り替えの開始の要求に従い、リクエストの接続先を前記第１の環境および前記受信手段に指定するよう指示し、
前記接続先指定手段は、前記動作確認手段によりサーバが正常に動作することが確認された場合、リクエストの接続先を前記受信手段に指定するよう指示することを特徴とする請求項１４乃至１７のいずれか１項に記載の管理システム。
【請求項１９】
前記管理システムは、
システム内にあるファイアウォールの設定を変更するよう指示する設定変更手段を有し、
前記設定変更手段は、
前記接続先指定手段がリクエストの接続先を前記信手段に指定するよう指示したことに応じて、前記第１の処理システム内にあるファイアウォールについて、前記送信手段により送信されたリクエスト以外のリクエストを受け付けないよう設定することを指示し、
前記接続先指定手段がリクエストの接続先を前記第２の処理システムに指定するよう指示したことに応じて、前記第１の処理システム内にあるファイアウォールについて、前記設定を解除するよう指示することを特徴とする請求項１４乃至１８のいずれか１項に記載の管理システム。
【請求項２０】
リクエストの処理に用いるリソースを調整可能な第１の処理システムおよび第２の処理システムと接続するリクエスト振り分けシステムにおける制御方法であって、
リクエストを受信する受信工程と、
前記受信工程で受信されたリクエストの送信先となる処理システムを決定する決定工程と、
前記決定工程で決定された処理システムに前記受信工程で受信されたリクエストを送信する送信工程と、を有し、
前記決定工程では、所定のネットワークシステムからのリクエストを処理する処理システムを、前記第１の処理システムから前記第２の処理システムへ切り替える際に、当該切り替えが開始されてから完了する前までの間、前記受信工程で受信された複数のリクエストが前記第１の処理システムおよび前記第２の処理システムに振り分けられるように、該複数のリクエストのそれぞれの送信先となる処理システムが決定されることを特徴とする制御方法。
【請求項２１】
前記決定工程では、前記切り替えが開始されてから完了する前までの間、前記受信工程で受信されたリクエストについて、該リクエストに含まれる識別情報に従い、該リクエストの送信先となる処理システムが決定されることを特徴とする請求項２０に記載の制御方法。
【請求項２２】
前記決定工程では、要求元として第１の識別情報を含む第１のリクエストが前記受信工程で受信された場合、該第１のリクエストの送信先が前記第２の処理システムに決定され、
要求元以外の情報として前記第１の識別情報を含む第２のリクエストが前記受信工程で受信された場合、該第２のリクエストの送信先が前記第２の処理システムに決定されることを特徴とする請求項２０または２１に記載の制御方法。
【請求項２３】
前記リクエスト振り分けシステムの制御方法は、
リクエストの送信先となる処理システムを決定するための指定情報として、前記所定のネットワークシステムに属する複数の利用者のうち一部の利用者を示す情報を指定する指定工程を更に有し、
前記決定工程では、前記切り替えが開始されてから完了する前までの間、前記受信工程で受信されたリクエストについて、該リクエストに含まれる識別情報および前記指定工程による指定に従い、該リクエストの送信先となる処理システムが決定されることを特徴とする請求項２０または２１に記載の制御方法。
【請求項２４】
リクエストの処理に用いるリソースを調整可能な第１の処理システムおよび第２の処理システムを含む管理システムにおける制御方法であって、
リクエストを受信する受信工程と、
前記受信工程で受信されたリクエストの送信先となる処理システムを決定する決定工程と、
前記決定工程で決定された処理システムに前記受信工程で受信されたリクエストを送信する送信工程と、を有し、
前記決定工程では、所定のネットワークシステムからのリクエストを処理する処理システムを、前記第１の処理システムから前記第２の処理システムへ切り替える際に、当該切り替えが開始されてから完了する前までの間、前記受信工程で受信された複数のリクエストが前記第１の処理システムおよび前記第２の処理システムに振り分けられるように、該複数のリクエストのそれぞれの送信先となる処理システムが決定されることを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理システムの切り替え時における処理システムのリクエストの振り分け技術に関する。
【背景技術】
【０００２】
近年、インターネット上にあるサーバで動作する各種アプリケーションを利用することができるサービスとして、クラウドサービスがある。ＩａａＳやＰａａＳなどのクラウドサービスでは、クラウドサービスベンダーが、ネットワークを介して、仮想マシンやストレージなどのリソースをシステム管理者に提供する。仮想マシンとは、仮想化技術によって、サーバを物理的な構成にとらわれずに論理的な単位で分割または統合し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピュータである。システム管理者は、クラウドサービスベンダーによって提供される仮想マシンやストレージなどのリソースを用いて、独自のサービスを提供するためのシステムを構築することができる。
【０００３】
クラウドサービスを用いて構築されるシステムは、システム管理者の任意の設定に従い、受け付けるリクエストの量やそれらの処理のための負荷に応じて、自動的にリソースを調整することができる。例えば、特許文献１には、プログラムの実行に必要なコンピューティング資源を自動的に割り当て、プログラムの実行を開始した後に、割り当てられた資源を変更するというオートスケール機能が記載されている。
【０００４】
このようなリソースの調整処理は、クラウドサービスで用意されているリソースマネージャが実行する。リクエストの量とは、クラウドサービスを用いて構築されるシステム内にあるロードバランサが単位時間当たりに受け付けるリクエストの数である。また、処理のための負荷とは、仮想マシンでの処理にかかる負荷であり、仮想マシンのＣＰＵ使用率やメモリ使用率、レスポンスの応答時間などを指す。リソースの調整には、仮想マシンの台数を増やすスケールアウトと、仮想マシンに対するハードウェア資源の割り当てを増やすスケールアップなどが含まれる。さらに、リソース調整には、仮想マシンの台数を減らすスケールインと、仮想マシンに対するハードウェア資源の割り当てを減らすスケールダウンも含まれる。ハードウェア資源は、ＣＰＵやメモリ、ストレージなどである。また、ロードバランサも、受け付けるリクエストの量に基づき、自動的にスケールアウトなどすることができる。
【０００５】
また、近年、上述したクラウドサービスを用いて構築されるシステムをバージョンアップする際などに、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントと呼ばれる技術が利用されることがある。ここで、システムのバージョンアップとは、例えば、システム内の仮想マシンで実行されるアプリケーションのバージョンアップが含まれる。バージョンアップ後のシステムは、提供できる機能が追加されたり、管理するデータの種類や形式が変更されたりする。
【０００６】
ここで、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントについて説明する。
【０００７】
まず、クラウドサービス上では、外部ネットワークからのリクエストを受付けて処理を行っている本番環境としての処理システムが動作している。そして、該処理システムをバージョンアップさせたい場合には、現行のバージョンの該処理システムとは異なるバージョンアップ後の処理システムをクラウドサービス上に更に構築する。その後、バージョンアップさせたいタイミングになったら、クラウドサービス上で外部ネットワークからのリクエストの送信対象を示す接続先の設定の変更などを行い、本番環境となる処理システムを切り替える。ここでは、本番環境がバージョンアップ後の処理システムに切り替えられる。この切り替えによって、システムのバージョンアップが実現される。
【０００８】
ここで、前述した現行のバージョンのシステムが動作する処理システム、つまり切り替え前の処理システムは、Ｂｌｕｅ環境と呼ばれる。一方で、前述したバージョンアップ後のシステムが構築された処理システム、つまり切り替え後の処理システムは、Ｇｒｅｅｎ環境と呼ばれる。以降、Ｂｌｕｅ環境を第１の処理システムと、Ｇｒｅｅｎ環境を第２の処理システムと呼ぶ場合もある。
【０００９】
なお、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによる処理システムの切り替えは、上述したシステムのバージョンアップ以外にも利用され得る。例えば、障害やバグが発生した処理システム（ここでは、第１の処理システム）から正常な別の処理システム（ここでは、第２の処理システム）にリクエストを処理する環境を切り替える場合などである。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特表２０１３−５４３１７１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ここで、前述したようなシステムは、例えば、一日に数回のバージョンアップを予定していることがある。このようなシステムの場合、次のバージョンアップ時期が近いため、リクエストの量の推移などを考慮しつつ、前述した処理システムの切り替えを行うことは難しい。また、システム運用上、新しいバージョンのシステムのリリース日程を大きく後ろにずらすことができない場合もある。したがって、外部ネットワークから大量のリクエストを受け付けており、第１の処理システムにかかる処理の負荷が大きい時であっても、バージョンアップなどのために、それらのリクエストの処理システムの切り替え処理を開始しなければならない場合がある。
【００１２】
第１の処理システムにかかるリクエストに係る処理の負荷が大きい時には、前述したリソースマネージャが、該第１の処理システム内でリクエストを処理するロードバランサなどに対して大量のリソースが提供されるように調整処理を行っている。一方、バージョンアップのための切り替えを見越して事前に用意された第２の処理システムでは、まだ外部ネットワークからのリクエストを受け付けて処理していないため、リソースマネージャによるリソースの調整処理が行われていない。また、システム管理者がシステムの維持コストの節約を考慮する場合には、事前に用意する第２の処理システムを比較的少ないリソース量で構成していることがある。このような状況下で前述した切り替え処理を行うと、第２の処理システムで一気に大量のリクエストを受け付けることになる。すると、リソースマネージャによるリソースの調整処理が間に合わない場合には第２の処理システムでのリクエストの処理が滞ることが考えられる。
【００１３】
本発明は、上述した第１の処理システムから第２の処理システムへの切り替え処理の際に、第２の処理システムでのリクエストの処理が滞らないようにすることを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、本発明のリクエスト振り分けシステムは、リクエストの処理に用いるリソースを調整可能な第１の処理システムおよび第２の処理システムと接続するリクエスト振り分けシステムであって、リクエストを受信する受信手段と、前記受信手段により受信されたリクエストの送信先となる処理システムを決定する決定手段と、前記決定手段により決定された処理システムに前記受信手段により受信されたリクエストを送信する送信手段と、を有し、前記決定手段は、所定のネットワークシステムからのリクエストを処理する処理システムを、前記第１の処理システムから前記第２の処理システムへ切り替える際に、当該切り替えが開始されてから完了する前までの間、前記受信手段により受信された複数のリクエストを前記第１の処理システムおよび前記第２の処理システムに振り分けるように、該複数のリクエストのそれぞれの送信先となる処理システムを決定することを特徴とする。
【００１５】
上記課題を解決するために、本発明の管理システムは、リクエストの処理に用いるリソースを調整可能な第１の処理システムおよび第２の処理システムを含む管理システムであって、リクエストを受信する受信手段と、前記受信手段により受信されたリクエストの送信先となる処理システムを決定する決定手段と、前記決定手段により決定された処理システムに前記受信手段により受信されたリクエストを送信する送信手段と、を有し、前記決定手段は、所定のネットワークシステムからのリクエストを処理する処理システムを、前記第１の処理システムから前記第２の処理システムへ切り替える際に、当該切り替えが開始されてから完了する前までの間、前記受信手段により受信された複数のリクエストを前記第１の処理システムおよび前記第２の処理システムに振り分けるように、該複数のリクエストのそれぞれの送信先となる処理システムを決定することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、上述した第１の処理システムから第２の処理システムへの切り替え処理の際に、第２の処理システムでのリクエストの処理が滞らないようにすることができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態に係るシステム構成の概略を示す図である。
【図２】本発明の実施形態に係る情報処理装置のハードウェアの構成例を示す図である。
【図３】本発明の実施形態に係る管理システム１００の構成を示す図である。
【図４】本発明の実施形態に係る顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータに提供される画面の例を示す図である。
【図５】本発明の実施形態に係るディスパッチサーバ３０４のソフトウェアモジュールの構成例を示す図である。
【図６】本発明の実施形態に係る処理システム切り替え処理におけるシーケンスの例を示す図である。
【図７】本発明の実施形態に係るテナントの割り当て処理の流れの例を示すフローチャートである。
【図８】本発明の実施形態に係るディスパッチサーバ３０４が管理するテナント管理テーブルの例を示す図である。
【図９】本発明の実施形態に係る受信部５０１が受信するＨＴＴＰリクエストの例を示す図である。
【図１０】本発明の実施形態に係るリクエストの送信先の決定処理の流れの例を示すフローチャートである。
【図１１】本発明の実施形態に係るテナントの割り当て処理の流れの例を示すフローチャートである。
【図１２】本発明の実施形態に係るディスパッチサーバ３０４が管理するテナント管理テーブルの例を示す図である。
【図１３】本発明の実施形態に係る処理システム切り替え処理におけるシーケンスの例を示す図である。
【図１４】本発明の実施形態に係るディスパッチサーバ３０４のソフトウェアモジュールの構成例を示す図である。
【図１５】本発明の実施形態に係る処理システム切り替え処理におけるシーケンスの例を示す図である。
【図１６】本発明の実施形態に係る管理システム１００の構成を示す図である。
【図１７】本発明の実施形態に係るディスパッチサーバ３０４のソフトウェアモジュールの構成例を示す図である。
【図１８】本発明の実施形態に係る処理システム切り替え処理におけるシーケンスの例を示す図である。
【発明を実施するための形態】
【００１８】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１９】
本発明では、クラウドサービスを用いて構築されるネットワークシステムとして、複数の顧客や各顧客が保有するネットワークデバイスを、ネットワークを介して遠隔地から管理する管理システムを例に挙げて説明する。管理システムでは、顧客ごとの顧客ネットワーク環境に存在するネットワークデバイスから機器情報や、ログ情報や障害情報などの稼働情報を収集して、分析することにより様々なデバイス管理サービスを提供する。具体的には、管理システムは、ネットワークデバイスの稼働状況のレポーティングサービスや、故障したネットワークデバイスの保守に必要なサービスを提供している。管理システムは、サービスを提供するために、例えば、管理対象となるネットワークデバイスの新規登録や、レポート作成、ネットワークデバイスのログ情報の登録などのリクエストを、ネットワークなどを介して受け付けるように構成されている。
【００２０】
また、顧客のデバイス等の管理を顧客から業務委託される顧客管理者がいる場合もある。この場合、顧客管理者は、管理システムを利用して、顧客それぞれが保有するデバイスを管理し、その顧客に対して様々なサービスを提供する。管理システムの利用者には、顧客管理者と顧客とが含まれる。
【００２１】
（実施例１）
図１は、システム全体の構成の概略を示す図である。ネットワークデバイスや顧客情報を管理する管理システム１００と、ネットワークデバイスが設置されている複数の顧客環境１３０とがインターネットを介して接続されている。また、管理システム１００を管理するためのシステム管理者用のコンピュータ１１０や、ネットワークデバイスの販売会社の担当者（顧客管理者）用のコンピュータ１２０が、同様に管理システム１００とネットワークを介して接続されている。
【００２２】
管理システム１００は、ＩａａＳやＰａａＳなどのクラウドサービスを用いて提供されるプラットフォームやリソースを利用して構築される、ネットワークデバイスやそれらを保有する顧客を管理するためのサービスを提供するシステムである。クラウドサービスは、リソースとして、例えばインターネット上のデータセンターに存在するサーバコンピュータ上で動作する複数の仮想マシンやストレージなどを提供する。複数の仮想マシン上で様々なアプリケーションプログラムを実行することで、管理システム１００としての様々な管理サービスが実現される。サービス内容としては、具体的には、顧客環境１３０に設置されたネットワークデバイスの機器情報を収集した場合に、当該顧客の情報と関連付けて管理するサービスがある。ほかに、顧客環境１３０に設置されたネットワークデバイスのログ情報や障害情報などの稼働情報を収集して、分析することで、顧客や販売会社の担当者のためにレポーティングを行うといったサービスがある。ほかにも、故障したネットワークデバイスの保守に必要な情報を販売会社の担当者のために電子メールなどで通知するといったサービスもある。なお、ネットワークデバイスには、プリンターやネットワークカメラなどの画像処理装置などが含まれる。プリンターには、トナーなどを利用した電子写真方式のものや、インクを利用して印刷を行うインクジェット方式のものが存在する。管理システム１００は、それぞれの方式によって特有な稼働情報（例えば、トナー使用量やインク使用量）を収集して、異なる管理サービスを提供することも可能である。
【００２３】
コンピュータ１１０は、システム管理者が利用するコンピュータであり、管理システム１００が提供する管理者用の管理画面を、インストールされているウェブブラウザなどを用いて表示できる。システム管理者はコンピュータ１１０に表示される管理画面を介して、管理システム１００に対する各種設定などを行うためのリクエストの送信を指示できる。例えば、システム管理者は、前述したＢｌｕｅ−ＧｒｅｅｎデプロイメントのためのＧｒｅｅｎ環境の生成のためのリクエストや、Ｂｌｕｅ環境からＧｒｅｅｎ環境へリクエスト処理システムを切り替えるためのリクエストの送信を指示できる。
【００２４】
コンピュータ１２０は、ネットワークデバイスの販売会社の担当者が利用するコンピュータであり、管理システム１００が提供する担当者用の画面を、ウェブブラウザなどを用いて表示できる。管理システム１００が提供する担当者用の画面には、顧客環境１３０に設置されたネットワークデバイスのログ情報や障害情報などの稼働情報を確認できる画面などがある。他にも、担当者用の画面としては、顧客環境１３０に設置されたネットワークデバイスの監視設定を行うための画面も表示できる。
【００２５】
顧客環境１３０は、管理システム１００が管理する顧客ごとにネットワーク上に存在するネットワーク環境を示す。顧客環境１３０には、顧客が保有する１以上のネットワークデバイスと、ネットワークデバイスと管理システム１００との通信を中継する中継装置がＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）により接続されている。中継装置は、ネットワーク上のネットワークデバイスを探索して、発見した場合に管理システム１００に該ネットワークデバイスの機器情報を通知するためのリクエストを生成して送信するための機能をもつ。また、前記中継装置は、ネットワークデバイスから収集した稼働情報を、管理システム１００に通知するためのリクエストを生成して送信するための機能をもつ。
【００２６】
図２は、情報処理装置のハードウェアの構成例を示す図である。本実施例における情報処理装置としては、管理システム１００を実現するためのデータセンター上に存在するサーバコンピュータ、コンピュータ１１０、コンピュータ１２０、顧客環境１３０内に存在する中継装置としてのコンピュータなどがある。
【００２７】
情報処理装置は、ＲＯＭ２５３に格納されているプログラムを実行するＣＰＵ２５１を備え、内部バス２５６を介して各デバイスを総括的に制御する。内部バス２５６には、ＲＡＭ２５２、ＲＯＭ２５３、記憶装置２５４、ネットワークＩ／Ｆ２５５、入出力Ｉ／Ｆ２５７が接続されている。また入出力Ｉ／Ｆ２５７は、例えばＰＳ２やＵｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ  Ｉ／Ｆ）、アナログやデジタルのディスプレイＩ／Ｆを備える。入出力Ｉ／Ｆ２５７により、情報処理装置に対して、不図示のキーボードやマウス、ＣＲＴや液晶ディスプレイなどを接続することができる。情報処理装置はネットワークＩ／Ｆ２５５によりＬＡＮ、イントラネット環境、インターネットを介した通信を行う。それにより、情報処理装置は、ネットワークデバイスや、他の情報処理装置と通信を行うことができる。ＣＰＵ２５１は、ＲＡＭ２５２やＲＯＭ２５３と共にプログラムの実行処理を行う。さらに、ＣＰＵ２５１は、仮想化技術を実現するためのプログラムを実行することも可能である。また、ＣＰＵ２５１は、記憶装置２５４等の記録媒体にデータを記録する処理を行う。記憶装置２５４は外部記憶装置として機能し、様々な情報を記憶するほか、ＲＡＭ２５２に代わって、各種システム情報及び処理情報を保存することも可能である。
【００２８】
図３は、管理システム１００の構成を示す図である。管理システム１００は、クラウドサービスを用いて提供されるリソースを利用して構築されるネットワークデバイスやネットワークデバイスを保有する顧客を管理するためのサービスなどを提供するためのシステムである。図３（Ａ）では、現在、システム外部の所定のネットワークシステム（コンピュータ１２０や顧客環境１３０など）からのリクエストを受け付けて処理している処理システムであるＢｌｕｅ環境３１０を含む管理システム１００の構成例を示している。また、図３（Ｂ）では、図３（Ａ）で示した構成に対して、さらにＢｌｕｅ環境３１０とは別個の処理システムであるＧｒｅｅｎ環境３５０などが生成された後の管理システム１００の構成例を示している。
【００２９】
図３（Ａ）で示す管理システム１００は、システムマネージャ３００と、ドメインネームシステム（以降、ＤＮＳと呼ぶ）３０１と、データベース３０２と、リソースマネージャ３０３と、Ｂｌｕｅ環境３１０を含む。
【００３０】
ＤＮＳ３０１には、それぞれの仮想マシンやロードバランサ（以降、ＬＢとも呼ぶ）のＩＰアドレスとホスト名が登録されている。システム管理者用のコンピュータ１１０や顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスは、インターネットなどのネットワークを経由して、ＤＮＳ３０１と通信を行う。前記コンピュータやネットワークデバイスは、ＤＮＳ３０１に、リクエストの接続先となる処理システム内のＬＢのホスト名に該当するＩＰアドレスを問合せて、ＤＮＳ３０１から返ってきたＩＰアドレスにリクエストを送る。受け付けたリクエストに対して、ＤＮＳ３０１は、ＤＮＳ名に紐づくＤＮＳレコードを使って、リクエストの接続先となる処理システム内のＬＢを示すホスト名またはＩＰアドレスを返す。管理システム１００を構成する仮想マシンは、それぞれ、固有のＩＰアドレスを持つ。したがって、ロードバランサを構成する仮想マシンのＩＰアドレスによって、該ロードバランサのＩＰアドレスは特定され得る。
【００３１】
データベース３０２には、本管理システムを実現するためのプログラムや、顧客管理者にサービスを提供するための各種データなどが格納されている。本実施例に係る管理システム１００において、顧客管理者や顧客の情報は、それぞれ、データベース３０２内の専用の記憶領域であるテナントで管理される。顧客が管理システムで管理される情報にアクセスする場合には、自分の所属するテナントのデータにしかアクセスできず、他のテナントへのアクセスを制限される。一方、顧客管理者は、その権限において、自分の所属するテナントのデータだけでなく、管理対象となるネットワークデバイスの所有者である１以上の顧客のテナントのデータにもアクセスすることができる。管理システム１００において顧客管理者に対しては顧客からの承認を必要とするアクセス手段（不図示）が提供されており、それを用いることで、顧客管理者は顧客のテナントに格納されているデータにアクセスすることができる。例えば、コンピュータ１２０で表示された管理画面を介して、顧客管理者は、顧客のテナントにアクセスし、顧客のデバイスを管理するための設定情報を書き換える指示のリクエストを送信することができる。
【００３２】
システムマネージャ３００は、管理システム１００内の処理システムの設定に関するリクエストなどをシステム管理者用のコンピュータ１１０から受け付ける。システムマネージャ３００は、受け付けたリクエストに基づいて、リソースマネージャ３０３に対して、処理システムを構成するリソースと当該リソースを用いた処理システムの生成を指示したり、管理システム１００内のリソース調整を指示したりする。また、システムマネージャ３００は、ＤＮＳ３０１に登録されているＤＮＳレコードを書き換えるリクエストをシステム管理者から受け付ける。システムマネージャ３００は、受け付けたリクエストに基づいて、リソースマネージャ３０３に対して、ＤＮＳ３０１に登録されているＤＮＳレコードの書き換えを指示する。また、システムマネージャ３００は、処理システム切り替え処理を開始するリクエスト受信後、ディスパッチサーバ３０４に対してテナントの割り当て処理開始を指示することができる。割り当て処理については、後に、図７を用いて説明する。
【００３３】
リソースマネージャ３０３は、システムマネージャ３００の指示に基づいて、処理システムを構成するリソースを生成したり、管理システム１００内のリソースを調整したりする。システム管理者からのリクエストは、システムマネージャ３００へ送られ、リソースマネージャ３０３に対して、例えば、Ｂｌｕｅ環境３１０内の仮想マシンをスケールアウトさせることなどを要求して、リソースを調整することができる。さらに、リソースマネージャ３０３は、Ｂｌｕｅ環境３１０に対するリクエストの量などを監視して、自動でリソースを調整することもできる。
【００３４】
また、リソースマネージャ３０３は、システムマネージャが受け付けたリクエストに従って、ＤＮＳ３０１に登録されているＤＮＳレコードを書き換える。これによって、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスからのリクエストの接続先が変更される。
【００３５】
ここで、リクエストの接続先を変更する方法としては、上記の方法の他にも、ロードバランサやリバースプロキシをアクセスポイントとして用意するという方法、システムにアクセスするためのＵＲＬを書き換えるという方法などがある。
【００３６】
管理システム１００内に生成される処理システムは、リクエストに対する各種処理を実行する複数の層で構成される。各層は仮想マシン群とロードバランサで構成され、ＷｅｂＵＩ層とフロントエンド層とバックエンド層とがある。ＷｅｂＵＩ層は、顧客管理者用のコンピュータ１２０や顧客環境１３０内にあるコンピュータからのリクエストを受け付けて処理し、それらのコンピュータにＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を提供する。フロントエンド層では、顧客環境１３０内にある中継装置やネットワークデバイスからのリクエストを受け付けて処理する。バックエンド層では、フロントエンド層での処理を経たリクエストを受け付けて処理する。なお、バックエンド層には、フロントエンド層とは非同期に動作する、キューメッセージを処理するバッチ処理部を含んでも良い。
【００３７】
ここでは、Ｂｌｕｅ環境３１０は、ＬＢ３２１および仮想マシン３２２を備えるＷｅｂＵＩ層３２０と、ＬＢ３３１および仮想マシン３３２を備えるフロントエンド層３３０と、ＬＢ３４１および仮想マシン３４２を備えるバックエンド層３４０で構成される。Ｂｌｕｅ環境３１０は、現在、所定のネットワークシステムからのリクエストを受け付けて処理している本番環境である。所定のネットワークシステムには、例えば、顧客管理者用のコンピュータ１２０、顧客環境１３０（具体的には、顧客環境１３０内のコンピュータやネットワークデバイス）などが含まれる。
【００３８】
ＷｅｂＵＩ層３２０では、仮想マシン３２２を利用して、顧客管理者用のコンピュータ１２０や顧客環境１３０内にあるコンピュータから受け付けたリクエストが処理される。この処理には、顧客管理者用のコンピュータ１２０や顧客環境１３０内にあるコンピュータ上のウェブブラウザを介して、様々な画面を提供するといった処理が含まれる。ここで、仮想マシン３２２は、顧客管理者や顧客からのリクエストを処理するＷｅｂサーバとしての機能を担う１台以上の仮想マシン群である。Ｗｅｂサーバは、上述した様々な画面を、ネットワークを介して接続されたコンピュータ上のウェブブラウザに対して提供する機能を持つ。ここで提供される画面については、図４を用いて後述する。顧客管理者用のコンピュータ１２０からのリクエストには、例えば、管理対象となるネットワークデバイスの新規登録や、レポートの作成などを含む。また、顧客環境１３０内にあるコンピュータからのリクエストには、例えば、顧客管理者が作成したレポートのダウンロードなどを含む。
【００３９】
図４は、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータに提供される表示の内容の例である。
【００４０】
図４（Ａ）は、顧客管理者用のコンピュータ１２０での表示画面の例を示す図である。図４（Ａ）のＧＵＩは、ＷｅｂＵＩ層３２０での処理によって提供される。表示内容には、４００乃至４３０の各項目が表示される。顧客管理者は、例えば、顧客設定４１０に含まれる項目を選択し、管理対象となる顧客の情報の変更や参照が行える。また、デバイス設定４２０に含まれる項目を選択し、管理対象となる顧客が所有するデバイスの探索設定を変更したり参照したりすることができる。また、レポート設定４３０に含まれる項目を選択し、管理対象となる顧客が所有するデバイスの稼働情報を用いたレポート作成が指示できる。
【００４１】
図４（Ｂ）は、顧客環境１３０内のコンピュータの画面の例を示す図である。ＷｅｂＵＩ層３２０での処理によって、顧客環境１３０内のコンピュータに、このようなＧＵＩが提供される。顧客環境１３０内のコンピュータの画面には、４４０乃至４６０の各項目が表示される。顧客は、例えば、探索設定４６０の探索設定情報で示す項目を選択し、顧客が所有するデバイスの探索設定を参照することができる。
【００４２】
ここで、図３の説明に戻る。フロントエンド層３３０では、仮想マシン３３２を利用して、顧客環境１３０内にあるコンピュータやネットワークデバイスから受け付けたリクエストが処理される。ここで、仮想マシン３３２は、顧客環境１３０内にあるネットワークデバイスからのリクエストを処理する仮想マシン群である。フロントエンド層３３０で処理されるリクエストには、例えば、ネットワークデバイスのログ情報の登録要求などを含む。
【００４３】
バックエンド層３４０では、仮想マシン３４２を利用して、ＷｅｂＵＩ層３２０またはフロントエンド層３３０での処理を経て受け付けたリクエストが処理される。なお、バックエンド層３４０では、ＷｅｂＵＩ層３２０またはフロントエンド層３３０での処理とは非同期に実行される、バッチ処理部を含んでも良い。バッチ処理部では、例えば、フロントエンド層３３０を経由して受け付けたログ情報の集計処理が実行され、データベースに格納されるといった処理が行われる。
【００４４】
ＬＢ３２１、３３１および３４１は、受け付けたリクエストをそれぞれの層の仮想マシン３２２、３３２および３４２に振り分ける。
【００４５】
図３（Ｂ）は、図３（Ａ）で示した管理システム１００に対して、ディスパッチサーバ３０４と、Ｇｒｅｅｎ環境３５０が追加された構成を示している。ここで、Ｇｒｅｅｎ環境３５０は、Ｂｌｕｅ環境とは別個の処理システムとして用意される処理システムである。また、ディスパッチサーバ３０４は、詳細は後述するが、外部ネットワークからのリクエストを、Ｂｌｕｅ環境とＧｒｅｅｎ環境とに振り分けるための構成（リクエスト振り分けシステム）である。
【００４６】
システム管理者用のコンピュータ１１０からシステムマネージャ３００に対してＧｒｅｅｎ環境３５０の生成要求が送られる。システム管理者用のコンピュータ１１０からの要求を受け取ったシステムマネージャ３００は、リソースマネージャ３０３に対してＧｒｅｅｎ環境３５０の生成指示を出す。システムマネージャ３００からの指示を受けたリソースマネージャ３０３は、Ｇｒｅｅｎ環境３５０を生成する。Ｂｌｕｅ環境３１０では現行のバージョンのアプリケーションによるサービスが提供されているのに対して、Ｇｒｅｅｎ環境３５０ではバージョンアップされたアプリケーションによるサービスが提供される。例えば、Ｇｒｅｅｎ環境３５０で動作するアプリケーションによって、提供されるサービスや管理するデータの種類が増えたり、データベースで管理されるデータのフォーマットが変更されたりする。
【００４７】
Ｇｒｅｅｎ環境３５０は、ＬＢ３６１および仮想マシン３６２を備えるＷｅｂＵＩ層３６０と、ＬＢ３７１および仮想マシン３７２を備えるフロントエンド処理部３７０と、ＬＢ３８１および仮想マシン３８２を備えるバックエンド処理部３８０で構成される。Ｇｒｅｅｎ環境３５０内の仮想マシン３６２、３７２、および、３８２のうち少なくとも一部分で、Ｂｌｕｅ環境３１０内の仮想マシン３２２、３３２、および、３４２と比較してバージョンアップされたアプリケーションが動作している。リソースマネージャ３０３は、Ｇｒｅｅｎ環境３５０に対しても、リクエストの量などを監視して、自動でリソースを調整することができる。  ＬＢ３６１、３７１および３８１は、受け付けたリクエストをそれぞれの層の仮想マシン３６２、３７２および３８２に振り分ける。
【００４８】
なお、システム管理者がＧｒｅｅｎ環境を生成する際、費用の節約を考慮して、できるだけ少ない仮想マシンでもってＧｒｅｅｎ環境を構成する場合が多い。また、Ｇｒｅｅｎ環境は、管理システム１００内に複数存在しても良い。システムの外部からのリクエストの接続先となる処理システムを切り替える際には、システム管理者は、切り替え先の処理システムとして、任意のＧｒｅｅｎ環境を選択するといったことも可能である。
【００４９】
ディスパッチサーバ３０４の機能は、１以上の仮想マシンからなる処理システム上で実現される。この仮想マシンは、Ｇｒｅｅｎ環境３５０と同様の手順で生成される。システム管理者用のコンピュータ１１０からシステムマネージャ３００に対してディスパッチサーバ３０４の生成要求が送られる。システム管理者用のコンピュータ１１０からの要求を受け取ったシステムマネージャ３００は、リソースマネージャ３０３に対してディスパッチサーバ３０４の生成指示を出す。システムマネージャ３００からの指示を受けたリソースマネージャ３０３は、ディスパッチサーバ３０４を生成する。なお、システム管理者は、ある条件の下、Ｇｒｅｅｎ環境３５０の生成時に、ディスパッチサーバを自動的に構築するようにしても良い。
【００５０】
ディスパッチサーバ３０４は、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスなどからのリクエストを受け付ける。その後、該リクエストの送信先をＢｌｕｅ環境３１０とＧｒｅｅｎ環境３５０とのいずれかに決定し、決定された処理システムへ該リクエストを送信する。また、ディスパッチサーバ３０４は、システムマネージャ３００からの指示を受けて、ＤＮＳ３０１に登録されるＤＮＳレコードを書き換える。さらに、ディスパッチサーバ３０４は、リクエストをＧｒｅｅｎ環境３５０で処理されるべきテナントを徐々に決定する割り当て処理を実行する。割り当て処理の結果であるテナントの情報も管理する。ディスパッチサーバ３０４が実行する処理によって、処理システム切り替え時に、Ｇｒｅｅｎ環境でのリクエストの処理が滞ることを防止できる。
【００５１】
ここで、ディスパッチサーバ３０４による処理について、更に補足する。
【００５２】
ディスパッチサーバ３０４は、リクエストに含まれる識別情報を利用して、リクエストの送信先となる処理システムを決定する決定処理を実行する。具体的には、ディパッチサーバ３０４がリクエストを受け付けた時、該リクエストの要求元に対応するシステム利用者のテナントが割り当てられている処理システムで該リクエストが処理されるように決定処理を行う。
【００５３】
しかしながら、依存関係にある複数のリクエストがそれぞれＢｌｕｅ環境３１０とＧｒｅｅｎ環境３５０に振り分けられて、別環境で処理されると、後段でのリクエストの処理において不具合が発生する場合がある。ここで、依存関係にある複数のリクエストとは、リクエストの要求元や処理内容によって関連することが特定できるリクエストをいう。
【００５４】
このような依存関係にある複数のリクエストの処理における不具合について、説明する。
【００５５】
本実施例では、Ｂｌｕｅ環境３１０とＧｒｅｅｎ環境３５０とでデータベース３０２を共有している。そのため、Ｇｒｅｅｎ環境３５０で処理されたリクエストによって書き換えられたデータを、Ｂｌｕｅ環境３１０で処理されたリクエストによって参照することになる。この際、旧バージョンのアプリケーションなどが動作するＢｌｕｅ環境３１０では、Ｇｒｅｅｎ環境３５０によって処理された処理結果を正常に参照することができない場合がある。
【００５６】
より具体的には、まず、最初のリクエストが、バージョンアップ後のシステムが動作するＧｒｅｅｎ環境３５０で処理されたとする。例えば、顧客管理者が送信を指示したリクエストによって、該顧客管理者が管理する顧客のテナントの情報である設定内容を、Ｂｌｕｅ環境３１０でサポートされていない形式のデータを用いて書き換える。このあとで、２つ目のリクエストが、バージョンアップ前のシステムが動作するＢｌｕｅ環境３１０で処理されたとする。例えば、顧客が送信を指示したリクエストによって、最初のリクエストによって書き換えられたデータを参照する。このような場合には、Ｇｒｅｅｎ環境３５０での処理結果のデータ（種類や形式など）がＢｌｕｅ環境３１０でサポートされておらず、Ｂｌｕｅ環境３１０でその２つ目のリクエストを適切に処理できない。
【００５７】
そこで、この不具合を解消するために、ディスパッチサーバは、リクエストに含まれる、要求元以外の識別情報も利用して、リクエストの送信先となる処理システムを決定する。本実施例では、ディパッチサーバ３０４がリクエストを受け付けた時、リクエストの要求元に対応するテナントを示す情報だけでなく、他の利用者に関するテナントを示す情報についてもチェックする。例えば、顧客管理者が特定の顧客の設定の変更などを指示した場合のリクエストには、要求元となる顧客管理者のテナントを示す情報だけでなく、設定変更の対象となる情報を管理する該顧客のテナントを示す情報も含まれることになる。そして、ディパッチサーバ３０４は、リクエストに複数のテナントを示す情報が含まれる場合には、該複数のテナントのそれぞれが割り当てられている処理システムを考慮して、該リクエストの送信先となる処理システムを決定する。この決定処理については、図１０を用いてより詳細に後述する。
【００５８】
なお、要求元以外の識別情報は、本実施例で用いる、他の利用者に関するテナントを示す情報に限られない。例えば、要求元以外の識別情報は、リクエストに含まれる処理対象や処理内容を示す情報の一部であってもよい。
【００５９】
また、各処理システムでデータベースを保有している場合であっても本実施形態を適用できる。リクエストが異なる処理システムで処理されることによって、データの更新が一方のデータベースにしか反映されず、データの不整合が起こり得るからである。
【００６０】
本実施例は、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントに限らず、ディスパッチサーバ３０４によるリクエストの複数の処理システムへの振り分け処理に際した、上述したような複数のリクエストに起因する不具合に対する解決手段についても説明するものである。
【００６１】
図５は、ディスパッチサーバ３０４のソフトウェアモジュールの構成例を示す図である。ディスパッチサーバ３０４は、受信部５０１と、決定部５０２と、送信部５０３と、接続先変更部５０４と、割り当て管理部５０５とを有する。
【００６２】
受信部５０１は、顧客管理者用のコンピュータ１２０や顧客環境１３０内にあるコンピュータからのリクエストを受信する。受信部５０１を示すＤＮＳレコードがＤＮＳ３０１に登録されている時、受信部５０１は、顧客管理者用のコンピュータ１２０や顧客環境１３０内にあるコンピュータからのリクエストを受信する。
【００６３】
決定部５０２は、受信部５０１が受信したリクエストを、Ｂｌｕｅ環境３１０またはＧｒｅｅｎ環境３５０のどちらで処理すべきかを決定する。決定部５０２は、リクエストをＢｌｕｅ環境３１０およびＧｒｅｅｎ環境３５０に振り分けるように、該リクエストの送信先を決定する。
【００６４】
送信部５０３は、受信部５０１が受信したリクエストを、決定部５０２が決定した処理システムへ送信する。
【００６５】
接続先変更部５０４は、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードを書き換えるよう指示する。接続先変更部５０４は、リクエストの接続先を指定するための指示を行う構成（接続先指定手段）である。
【００６６】
割り当て管理部５０５は、各テナントがＢｌｕｅ環境３１０とＧｒｅｅｎ環境３５０のどちらの処理システムに割り当てられているかを管理する。リクエストがＧｒｅｅｎ環境３５０で処理されるべきテナントを管理するための指定を行うことで割り当て処理を実行する。テナントの割り当て処理について、後に、図６、７などを用いて説明する。
【００６７】
図６は、処理システム切り替え処理におけるシーケンスの例を示す図である。本シーケンスは、前述した図３（Ｂ）で示すシステムが構築された後に開始される。
【００６８】
Ｓ６０１で、システム管理者用のコンピュータ１１０は、システムマネージャ３００に対して、処理システム切り替え処理開始を要求する。システム管理者は、処理システム切り替え処理の実行をスケジュールで管理しても良いし、また、自動で実行されるように設定しても良い。
【００６９】
Ｓ６０２で、システムマネージャ３００は、ディスパッチサーバ３０４に対して、処理システム切り替え処理の開始を指示する。さらに、システムマネージャ３００は、ディスパッチサーバ３０４の接続先変更部５０４に対して、リクエストの接続先を示すレコードの情報を与える。リクエストの接続先を示すレコードには、例えば、Ｂｌｕｅ環境３１０内の構成（ＬＢ３２１及び３３１など）を示すレコードやＧｒｅｅｎ環境３５０内の構成（ＬＢ３６１及び３７１など）を示すレコードが含まれる。なお、前記開始指示に、これらのレコードの情報を含めても良い。後のＳ６０３やＳ６０４、Ｓ６０７、Ｓ６０８の処理の際に、該情報は用いられる。
【００７０】
Ｓ６０３で、ディスパッチサーバ３０４の接続先変更部５０４は、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードを書き換えるよう指示する。なお、システム管理者用のコンピュータ１１０からＤＮＳ３０１のレコードを変更するためのリクエストを受け付けたことによって、システムマネージャ３００が、ＤＮＳ３０１のレコードを変更するよう指示しても良い。
【００７１】
Ｓ６０４で、リソースマネージャ３０３は、ＤＮＳ３０１のＤＮＳレコードについて、Ｂｌｕｅ環境３１０内の構成（ＬＢ３２１及び３３１など）を示すレコードから、ディスパッチサーバ３０４の受信部５０１を示すレコードに書き換える。すなわち、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータからのリクエストの接続先は、Ｂｌｕｅ環境３１０内のＷｅｂＵＩ層３２０にあるＬＢ３２１から、ディスパッチサーバ３０４の受信部５０１に変更される。また、顧客環境１３０内のネットワークデバイスからのリクエストの接続先は、Ｂｌｕｅ環境３１０内のフロントエンド層３３０にあるＬＢ３３１から、ディスパッチサーバ３０４の受信部５０１に変更される。
【００７２】
Ｓ６０５で、ディスパッチサーバ３０４は、受信部５０１でリクエストを受け付けられるのを待機する。Ｓ６０４でレコードが書き換えられた後、受信部５０１が初めてリクエストを受け付けた時に、Ｓ６０６へ移る。なお、システム管理者は、Ｓ６０６で示す処理に移るタイミングを手動で指示したり、ディスパッチサーバ３０４に対してスケジュールで設定したりしてもよい。
【００７３】
Ｓ６０６で、ディスパッチサーバ３０４の割り当て管理部５０５は、テナントの割り当て処理（図７）を行う。さらに、受信部５０１がリクエスト受け付けるたびに、ディスパッチサーバ３０４の決定部５０２は、該リクエストを処理すべき処理システムを決定する決定処理（図１０）を行う。
【００７４】
Ｓ６０７で、ディスパッチサーバ３０４の接続先変更部５０４は、割り当て管理部５０５でのテナントの割り当て処理の完了を検出すると、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードを書き換えるよう指示する。
【００７５】
なお、ディスパッチサーバ３０４の接続先変更部５０４が、Ｇｒｅｅｎ環境３５０内の構成（ＬＢ３６１及び３７１など）を示すレコードの情報を受け取るタイミングは、Ｓ６０２ではなく、Ｓ６０２の後からＳ６０７の前までの間であってもよい。ディスパッチサーバ３０４の接続先変更部５０４は、システムマネージャ３００から与えられたＧｒｅｅｎ環境３５０内の構成（ＬＢ３６１及び３７１など）を示すレコードの情報を用いて、Ｓ６０７やＳ６０８の処理を行う。
【００７６】
Ｓ６０８で、リソースマネージャ３０３は、ＤＮＳ３０１のＤＮＳレコードについて、ディスパッチサーバ３０４の受信部５０１を示すレコードから、Ｇｒｅｅｎ環境３５０内の構成（ＬＢ３６１及び３７１など）を示すレコードに書き換える。すなわち、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータからのリクエストの接続先は、ディスパッチサーバ３０４の受信部５０１から、Ｇｒｅｅｎ環境３５０内のＷｅｂＵＩ層３６０にあるＬＢ３６１に変更される。また、顧客環境１３０内のネットワークデバイスからのリクエストの接続先は、ディスパッチサーバ３０４の受信部５０１から、Ｇｒｅｅｎ環境３５０内のフロントエンド層３７０にあるＬＢ３７１に変更される。これによって、処理システム切り替え処理が完了する。
【００７７】
また、接続先変更部５０４は、リソースマネージャ３０３によるＤＮＳレコードの書き換えが行われたことを検出すると、ディスパッチサーバ３０４自体を削除、または停止するような処理を実行してもよい。
【００７８】
図７は、割り当て管理部５０５により実行される、テナントの割り当て処理の流れの例を示すフローチャートである。
【００７９】
割り当て管理部５０５は、Ｓ７０１乃至Ｓ７０３で示す処理ループで、Ｓ７０１で示す条件を満たすまで、Ｓ７０２で示す処理を繰り返し実行する。Ｓ７０１で示す条件とは、管理システム１００の管理対象となるすべてのテナントがＧｒｅｅｎ環境３５０に割り当てられることである。Ｓ７０２では、割り当て管理部５０５は、管理システム１００を利用する顧客管理者や顧客の全テナントのうち、Ｂｌｕｅ環境に割り当てられている一部のテナントを指定し、Ｇｒｅｅｎ環境に割り当てる処理を行う。割り当てに関する情報（指定情報）は、後述する決定処理（図１０）で用いられる。処理システム切り替え処理の開始の指示が行われた後に、本処理を開始した時点では、管理システム１００を利用する顧客管理者や顧客の全テナントはＢｌｕｅ環境に割り当てられており、それらを要求元とするリクエストは、Ｂｌｕｅ環境で処理されることになっている。割り当て管理部５０５は、Ｓ７０２の処理でＧｒｅｅｎ環境に割り当てられているテナントに関する情報と、管理システム１００を利用する全テナントに関する情報とを、それぞれのテーブルで管理する。このテーブルについては、図８で後述する。
【００８０】
Ｓ７０３で、全テナントがＧｒｅｅｎ環境に割り当てられていなければ、Ｓ７０１に戻る。Ｇｒｅｅｎ環境に割り当てられているテナントに関する情報を管理するテーブルの内容と、管理システム１００を利用する全テナントに関する情報を管理するテーブルの内容とが一致したとする。その時、割り当て管理部５０５は、全テナントがＧｒｅｅｎ環境に割り当てられたと判断する。そして、割り当て管理部５０５は、割り当て処理の完了を接続先変更部５０４に対して通知する。そして、接続先変更部５０４により、リソースマネージャ３０３に対するＤＮＳ３０１のレコードを書き換えの指示が実行される。
【００８１】
なお、Ｓ７０２のテナントの割り当て処理の実行後は、所定時間が経過した後にＳ７０３に移る。つまり、Ｓ７０２の割り当て処理は所定の時間間隔ごとに繰り返されることになる。
【００８２】
ここで、本処理は、大量のリクエストが管理システム１００に対して行われている場合にも、Ｇｒｅｅｎ環境でそのリクエストの処理が滞らないように、Ｂｌｕｅ環境とＧｒｅｅｎ環境とにリクエストを振り分けるための処理である。つまり、結果的に、リソースマネージャ３０３によるＧｒｅｅｎ環境に対するオートスケール処理などのリソースの調整処理が間に合うような時間をかけて、Ｇｒｅｅｎ環境にリクエストの振り分けが行われればよい。ここで、リソースマネージャ３０３によるＧｒｅｅｎ環境に対するリソースの調整処理は、ある程度の大きな負荷のリクエストの処理を行ってから数分間で完了する。リソース調整後は、Ｇｒｅｅｎ環境においても大量のリクエストの処理が可能となる。従って、本処理全体は、最初にディスパッチサーバ３０４がリクエストを受信してから、数十分から、長くても数時間の間に完了するよう、Ｓ７０２で割り当てるテナント数、または前述の所定の時間間隔が決定されるものとする。
【００８３】
割り当て処理の完了に従い、システムのバージョンアップは完了することになる。本発明では、外部ネットワークから大量のリクエストを受け付けており、第１の処理システムにかかる処理の負荷が大きい時であっても、Ｇｒｅｅｎ環境での処理が滞ることなく、比較的短時間でのバージョンアップが可能となる。
【００８４】
また、管理システム１００へのリクエスト数が少なくなった場合などに、割り当て処理の完了を早めるために、前述の所定の時間間隔は、ディスパッチサーバ３０４により自動的に、またはシステム管理者によって手動で変更されても良い。
【００８５】
なお、前述の図６では、割り当て管理部５０５がテナントの割り当て処理を開始するタイミングは、ディスパッチサーバ３０４の受信部５０１が初めてリクエストを受け付け（Ｓ６０６）た後であると説明した。しかしながら、この開始タイミングは、このタイミングに限らず、受信部５０１が初めてリクエストを受け付ける前であってもよい。ただし、ディスパッチサーバ３０４の受信部５０１が初めてリクエストを受け付ける前までに、テナントの割り当て処理が完了しないようにする必要がある。テナントの割り当て処理が完了してしまうと、ディスパッチサーバ３０４は、受信部５０１で受け付けられた全てのリクエストをＧｒｅｅｎ環境に転送してしまう。これでは、リソースマネージャ３０３によるＧｒｅｅｎ環境に対するオートスケール処理などのリソースの調整処理が間に合わない懸念がある。そこで、本発明では、割り当て処理の開始タイミングを受信部５０１が初めてリクエストを受け付ける前とした場合には、割り当て管理部５０５がＮ回目（Ｎ＞＝２）以降のＳ７０２の処理を受信部５０１が初めてリクエストを受け付けた後に実行するよう制御するものとする。
【００８６】
図８は、ディスパッチサーバ３０４が管理するテナント管理テーブルの例を示す図である。図８（Ａ）に示すテナント管理テーブルでは、Ｇｒｅｅｎ環境に割り当てられているテナントを管理する。また、図８（Ｂ）に示すテナント管理テーブルでは、管理システム１００を利用する顧客管理者や顧客の全テナントを管理する。
【００８７】
図８（Ａ）は、割り当て管理テーブルの例を示す図である。割り当て管理部５０５は、Ｓ７０２での処理に従いＧｒｅｅｎ環境に割り当てられているテナントに関する情報を、割り当て管理テーブルで管理する。割り当て管理部５０５による割り当て処理が実行されるたびに、徐々に、このテーブルで管理されるテナントを示すレコード数が増加することになる。
【００８８】
当該テーブルには、Ｇｒｅｅｎ環境に割り当てられているテナントのテナントＩＤ８００が記載される。割り当て管理部５０５は、例えば、レコード８０１乃至８０５で示されるように、Ｇｒｅｅｎ環境に割り当てられているテナントのテナントＩＤを管理する。テナントＩＤとは、管理システム１００において扱われる、顧客及び顧客管理者のそれぞれが属するテナントを一意に識別するための情報である。割り当て管理部５０５は、Ｇｒｅｅｎ環境に割り当てるべき対象のテナントのテナントＩＤを取得するために、次に説明する図８（Ｂ）のテナント一覧テーブルを参照する。
【００８９】
図８（Ｂ）は、テナント一覧テーブルの例を示す図である。割り当て管理部５０５は、管理システム１００を利用する顧客管理者や顧客の全テナントに関する情報を、テナント一覧テーブルで管理する。
【００９０】
当該テーブルには、管理システム１００を利用する顧客管理者や顧客の全テナントのテナントＩＤが記載される。」割り当て管理部５０５は、管理システム１００を利用する顧客管理者や顧客の全テナントに関する情報をデータベース３０２から取得する。または、ディスパッチサーバ３０４の生成時に、データベース３０２に格納されているテナントに関するデータを割り当て管理部５０５に持たせるようにしても良い。割り当て管理部５０５は、例えば、レコード８１１乃至８１７で示されるように、管理システム１００を利用する顧客管理者や顧客の全テナントのテナントＩＤを管理する。
【００９１】
図９は、受信部５０１が所定のネットワークシステムから受信するＨＴＴＰリクエストの例を示す図である。このＨＴＴＰリクエストには、リクエストの要求元を示すテナントＩＤと、リクエストの処理対象を示すテナントＩＤとが含まれる。ＨＴＴＰリクエスト９００は、あるテナントＩＤ「ＳＰ＿ＵＳ」に対応する利用者が、別のテナントＩＤ「ＡＢＣ＿ＵＳ」で識別されるテナントで管理される“ｃｏｎｆｉｇ”のデータを要求するリクエストの例を示している。
【００９２】
顧客管理者用のコンピュータ１２０や顧客環境１３０内にあるコンピュータからのリクエストには、リクエストの送信を指示した顧客管理者または顧客のテナント（以降、送信テナントと呼ぶ）を識別するための情報が含まれる。また、顧客管理者用のコンピュータ１２０からのリクエストには、当該リクエストの処理に関係する顧客のテナントを識別するための情報が含まれる場合がある。
【００９３】
例えば、顧客のテナントで管理されるデータを書き換えたり参照したりするためのリクエストを顧客管理者が送ったとする。その場合、当該リクエストには、送信テナントを示す情報（顧客管理者のテナントＩＤなど）とは異なるテナントを示す情報が含まれる。例えば、該異なるテナントを示す情報は、リクエストの処理結果の格納先を示す情報の一部として含まれる。このように、リクエストの要求元を示すテナントとリクエストの処理対象を示すテナントとが異なる場合、リクエストの処理対象を示すテナントを関係テナントと呼ぶ。
【００９４】
ＨＴＴＰリクエスト９００には、認証ヘッダの値として、リクエストの送信を指示した顧客管理者または顧客に対応するテナントＩＤを示す情報９０１が含まれる。この例の場合には、認証ヘッダに含まれる情報９０１をＢａｓｅ６４エンコード方式によって復号化することで、「ＳＰ＿ＵＳ」というテナントＩＤを得ることが可能である。
【００９５】
また、ＨＴＴＰリクエスト９００には、リクエストＵＲＩの一部として、リクエストの処理に関係する顧客に対応するテナントＩＤ９０２が含まれる。この例の場合には、テナントＩＤ９０２で識別されるテナント「ＡＢＣ＿ＵＳ」で管理されている“ｃｏｎｆｉｇ”データに関するリクエストであると判断することができる。
【００９６】
受信部５０１が図９で示すＨＴＴＰリクエスト９００を受信したとする。その場合には、受信部５０１および決定部５０２は、当該リクエストに含まれる送信テナント「ＳＰ＿ＵＳ」および関係テナント「ＡＢＣ＿ＵＳ」をそれぞれ識別するための情報を取得することができる。
【００９７】
なお、送信テナントおよび関係テナントの識別は、上述した方法以外に、他のＨＴＴＰヘッダやＨＴＴＰリクエストボディなどによっても実現可能である。また、ＨＴＴＰリクエストに限定はされず、他のプロトコルのリクエストによっても実現可能である。
【００９８】
決定部５０２は、リクエストに含まれる、送信テナントや関係テナントを識別するための情報と、図８（Ａ）の割り当て管理テーブルの情報とを用いて、当該リクエストを処理すべき処理システムを決定する。
【００９９】
図１０は、決定部５０２により実行される、受信部５０１の受信したリクエストの送信先となる処理システムの決定処理の流れの例を示すフローチャートである。受信部５０１がリクエストを受信すると、本処理が開始される。本処理によって、リクエストを処理すべき処理システムを適切に決定できる。なお、本処理は、図７で説明した割り当て処理とは非同期で実行されることになる。
【０１００】
Ｓ１００１で、決定部５０２は、受信部５０１が受信したリクエストに関係テナントの情報が含まれるかを判定する。受信部５０１が受信したリクエストに関係テナントの情報が含まれていない場合にはＳ１００２に進み、含まれている場合にはＳ１００３に進む。
【０１０１】
Ｓ１００２で、決定部５０２は、図８（Ａ）の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる送信テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００２で、送信テナントが割り当て管理テーブルに記載されていない場合にはＳ１００８へ進み、記載されている場合にはＳ１００９に進む。
【０１０２】
Ｓ１００３で、決定部５０２は、図８（Ａ）の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる送信テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００３で、送信テナントが割り当て管理テーブルに記載されている場合にはＳ１００４へ進み、記載されていない場合にはＳ１００５に進む。
【０１０３】
Ｓ１００４で、決定部５０２は、図８（Ａ）の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる関係テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００４で、関係テナントが割り当て管理テーブルに記載されていない場合にはＳ１００６へ進み、記載されている場合にはＳ１００９に進む。Ｓ１００６では、割り当て管理部５０５が、関係テナントとして取得されたテナントＩＤをＧｒｅｅｎ環境に割り当てるための割り当て処理を行う。具体的には、割り当て管理部５０５が関係テナントとして取得されたテナントＩＤを割り当て管理テーブルに対して追加で登録する。そして、Ｓ１００６での処理後には、Ｓ１００９に進む。
【０１０４】
Ｓ１００５で、決定部５０２は、図８（Ａ）の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる関係テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００５で、関係テナントが当該テーブルに記載されている場合にはＳ１００７へ進み、記載されていない場合にはＳ１００８へ進む。Ｓ１００７では、割り当て管理部５０５が、送信テナントをＧｒｅｅｎ環境に割り当てるための割り当て処理を行う。具体的には、割り当て管理部５０５が送信テナントとして取得されたテナントＩＤを割り当て管理テーブルに対して追加で登録する。そして、Ｓ１００７での処理後には、Ｓ１００９に進む。
【０１０５】
Ｓ１００８で、決定部５０２は、今回受信したリクエストを処理すべき処理システムをＢｌｕｅ環境に決定する。一方で、Ｓ１００９で、決定部５０２は、今回受信したリクエストを処理すべき処理システムをＧｒｅｅｎ環境に決定する。この決定後に、ディスパッチサーバ３０４の送信部５０３により、決定部５０２が決定した処理システムに存在する構成（ＬＢなど）に対して、リクエストが送信される。
【０１０６】
なお、あるテナントに属する顧客が、他の顧客のテナントや顧客管理者のテナントのデータにアクセスする権限を持たない場合には、原則的に、顧客からの指示に従うリクエストには関係テナントの情報が含まれない。一方で、顧客管理者は管理対象の顧客のテナントのデータにアクセス可能なため、顧客管理者からの指示に従うリクエストのみに関係テナントの情報が含まれる。
【０１０７】
このような場合、顧客からの指示に従うリクエストには、該顧客を管理する顧客管理者のテナントの情報が含まれないため、送信テナントの割り当てのみによってリクエストを処理すべき処理システムが、前述のＳ１００２で決定されてしまう。したがって、顧客からの指示に従うリクエストを顧客管理者からの指示に従うリクエストと同じ処理システムで処理させるために、前述したＳ１００６及びＳ１００７の処理が必要となる。つまり、顧客管理者からの指示に従うリクエストを受け付けた時点で、割り当て管理部５０５が、該リクエストに含まれる関係テナントである顧客管理者の管理対象の顧客のテナントについて割り当て処理を行うようにしている。しかし、顧客からの指示に従うリクエストにも関係テナントとして、自身を管理する顧客管理者の情報が含ませるような場合には、Ｓ１００６およびＳ１００７の処理を省略しても良い。
【０１０８】
上記で示すように、本実施例では、割り当て管理部５０５が、複数の処理システムへのリクエストの振り分け処理が行われるように、テナントＩＤを、図８（Ａ）の割り当て管理テーブルに徐々に追加していく。リクエストの振り分け処理を行うことで、Ｇｒｅｅｎ環境でのリクエストの処理が滞らないようにすることができる。
【０１０９】
その一方で、決定部５０２が、受信リクエストに含まれる送信テナントや関係テナントを識別するための情報と、図８（Ａ）の割り当て管理テーブルの情報とを用いて、当該リクエストを処理すべき処理システムを決定する。この決定部５０２の処理により、管理システム１００は、例えば、同じデータを参照するような顧客管理者及び顧客からの指示に従う複数のリクエストを同じ処理システムで処理できるようになる。したがって、それらのリクエストがそれぞれ異なる処理システムで処理されることによって起こり得るリクエスト処理での不具合を防ぐことができる。
【０１１０】
（実施例２）
実施例１では、テナントの割り当て処理において、割り当て管理部５０５は、Ｇｒｅｅｎ環境に割り当てられているテナントに関する情報を割り当て管理テーブルで管理していた。一方、本実施例では、割り当て管理部５０５は、Ｂｌｕｅ環境に割り当てられているテナントに関する情報を割り当て管理テーブルで管理する。実施例１との相違点を中心に説明する。
【０１１１】
図１１は、割り当て管理部５０５により実行される、テナントの割り当て処理の流れの例を示すフローチャートである。
【０１１２】
割り当て管理部５０５は、Ｓ１１０１乃至Ｓ１１０３で示す処理ループで、Ｓ１１０１で示す条件を満たすまで、Ｓ１１０２のテナントの割り当て処理を繰り返し実行する。Ｓ１１０１で示す条件とは、管理システム１００の管理対象となるすべてのテナントのうちＢｌｕｅ環境３１０に割り当てられているテナントがなくなることである。
【０１１３】
Ｓ１１０２では、割り当て管理部５０５は、管理システム１００を利用する顧客管理者や顧客の全テナントのうち、Ｂｌｕｅ環境に割り当てられているテナントの一部を指定し、Ｇｒｅｅｎ環境に割り当てる処理を行う。処理システム切り替え処理の開始の指示が行われた後に、本処理を開始した時点では、管理システム１００を利用する顧客管理者や顧客の全テナントを要求元とするリクエストは、Ｂｌｕｅ環境で処理されることになっている。割り当て管理部５０５は、Ｓ１１０２の処理でＢｌｕｅ環境に割り当てられているテナントに関する情報と、管理システム１００を利用する全テナントに関する情報とを、それぞれのテーブルで管理する。このテーブルについては、図１２で後述する。
【０１１４】
Ｓ１１０３で、Ｂｌｕｅ環境に割り当てられているテナントがあれば、Ｓ１１０１に戻る。Ｂｌｕｅ環境に割り当てられているテナントに関する情報を管理するテーブルが空になった時に、割り当て管理部５０５は、全テナントがＢｌｕｅ環境に割り当てられているテナントがなくなったと判断する。そして、割り当て管理部５０５は、処理システム切り替え処理の完了を接続先変更部５０４に対して通知する。そして、接続先変更部５０４により、リソースマネージャ３０３に対するＤＮＳ３０１のレコードを書き換えの指示が実行される。
【０１１５】
なお、Ｓ１１０２のテナントの割り当て処理の実行後は、所定時間が経過した後にＳ７０３に移る。つまり、Ｓ７０２の割り当て処理は所定の時間間隔ごとに繰り返されることになる。また、管理システム１００へのリクエスト数が少なくなった場合などに、割り当て処理の完了を早めるために、ここでの時間の間隔は、ディスパッチサーバ３０４により自動的に、またはシステム管理者によって手動で変更されても良い。また、一回の割り当て処理でＧｒｅｅｎ環境に割り当てられるテナントは、一つであっても、複数であっても良い。
【０１１６】
図１２は、ディスパッチサーバ３０４が管理する割り当て管理テーブルの例を示す図である。
【０１１７】
割り当て管理部５０５は、Ｓ１１０２での処理に従いＢｌｕｅ環境に割り当てられているテナントに関する情報を、割り当て管理テーブルで管理する。割り当て管理部５０５による割り当て処理が実行されるたびに、徐々に、このテーブルで管理されるテナントを示すレコード数が減少することになる。
【０１１８】
当該テーブルには、Ｂｌｕｅ環境に割り当てられているテナントのテナントＩＤ１２００が記載される。割り当て管理部５０５は、例えば、レコード１２０１、１２０２で示されるように、Ｂｌｕｅ環境に割り当てられているテナントのテナントＩＤを管理する。
【０１１９】
本実施例における割り当て管理テーブルには、処理システムの切り替え処理開始時、管理システム１００を利用する顧客管理者や顧客の全テナントに関する情報が記載されている。処理システムの切り替え処理が実行される前に、割り当て管理部５０５は、管理システム１００を利用する顧客管理者や顧客の全テナントに関する情報を取得する。しかし、本実施例では、割り当て管理部５０５は、処理システムの切り替え処理の実行中に、図７（Ｂ）のテナント一覧テーブルを保持していなくても良い。
【０１２０】
本実施例における決定処理の流れを、図１０を用いて説明する。ここで、実施例１での図１０の説明との違いは、図１２で示す割り当て管理テーブルを利用する点である。ここでは、その点を踏まえて、詳細に説明を行う。
【０１２１】
Ｓ１００１で、決定部５０２は、受信部５０１が受信したリクエストに関係テナントの情報が含まれるかを判定する。受信部５０１が受信したリクエストに関係テナントの情報が含まれていない場合にはＳ１００２に進み、含まれている場合にはＳ１００３に進む。
【０１２２】
Ｓ１００２で、決定部５０２は、図１２の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる送信テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００２で、送信テナントが割り当て管理テーブルに記載されており、送信テナントがＧｒｅｅｎ環境に割り当てられていない場合にはＳ１００８へ進む。また、送信テナントが割り当て管理テーブルに記載されておらず、送信テナントがＧｒｅｅｎ環境に割り当てられている場合にはＳ１００９に進む。
【０１２３】
Ｓ１００３で、決定部５０２は、図１２の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる送信テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００３で、送信テナントが割り当て管理テーブルに記載されておらず、送信テナントがＧｒｅｅｎ環境に割り当てられている場合にはＳ１００４へ進む。また、送信テナントが割り当て管理テーブルに記載されており、送信テナントがＧｒｅｅｎ環境に割り当てられていない場合にはＳ１００５に進む。
【０１２４】
Ｓ１００４で、決定部５０２は、図１２の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる関係テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００４で、関係テナントが割り当て管理テーブルに記載されており、関係テナントがＧｒｅｅｎ環境に割り当てられていない場合にはＳ１００６へ進む。また、関係テナントが割り当て管理テーブルに記載されておらず、関係テナントがＧｒｅｅｎ環境に割り当てられている場合にはＳ１００９に進む。Ｓ１００６では、割り当て管理部５０５が、関係テナントとして取得されたテナントＩＤをＧｒｅｅｎ環境に割り当てるための割り当て処理を行う。具体的には、割り当て管理部５０５が関係テナントとして取得されたテナントＩＤを割り当て管理テーブルから削除する。そして、Ｓ１００６での処理後には、Ｓ１００９に進む。
【０１２５】
Ｓ１００５で、決定部５０２は、図１２の割り当て管理テーブルを参照し、受信部５０１が受信したリクエストに含まれる関係テナントが当該テーブルに記載されているかどうかを判定する。Ｓ１００５で、関係テナントが割り当て管理テーブルに記載されておらず、関係テナントがＧｒｅｅｎ環境に割り当てられている場合にはＳ１００７へ進む。また、関係テナントが割り当て管理テーブルに記載されており、関係テナントがＧｒｅｅｎ環境に割り当てられていない場合にはＳ１００８へ進む。Ｓ１００７では、割り当て管理部５０５が、送信テナントをＧｒｅｅｎ環境に割り当てるための割り当て処理を行う。具体的には、割り当て管理部５０５が送信テナントとして取得されたテナントＩＤを割り当て管理テーブルから削除する。そして、Ｓ１００７での処理後には、Ｓ１００９に進む。
【０１２６】
Ｓ１００８で、決定部５０２は、今回受信したリクエストを処理すべき処理システムをＢｌｕｅ環境に決定する。一方で、Ｓ１００９で、決定部５０２は、今回受信したリクエストを処理すべき処理システムをＧｒｅｅｎ環境に決定する。この決定後に、ディスパッチサーバ３０４の送信部５０３により、決定部５０２が決定した処理システムに存在する構成（ＬＢなど）に対して、リクエストが送信される。
【０１２７】
本実施例では、割り当て管理方法に関して、実施例１と異なる方法を採用する。実施例１と違って、本実施例では、割り当て管理部５０５は、処理システムの切り替え処理の実行中に、図７（Ｂ）のテナント一覧テーブルを保持していなくても良い。
【０１２８】
（応用例１）
実施例１および実施例２では、Ｇｒｅｅｎ環境３５０の生成と同時に、または、Ｇｒｅｅｎ環境３５０の生成のタイミングに応じて、リソースマネージャ３０３はディスパッチサーバ３０４を生成していた。本応用例では、システム管理者から処理システム切り替え処理開始の要求があった後に、リソースマネージャ３０３がディスパッチサーバ３０４を生成し、処理システムの切り替え処理が完了した後に、リソースマネージャ３０３がディスパッチサーバ３０４を削除する。
【０１２９】
図１３は、処理システム切り替え処理におけるシーケンスの例を示す図である。
【０１３０】
Ｓ１３０１で、システム管理者用のコンピュータ１１０は、システムマネージャ３００に対して、処理システム切り替え処理開始を要求する。システム管理者は、処理システム切り替え処理の実行をスケジュールで管理しても良いし、また、自動で実行されるように設定しても良い。
【０１３１】
Ｓ１３０２で、システムマネージャ３００は、リソースマネージャ３０３に対して、ディスパッチサーバ３０４の生成を指示する。
【０１３２】
Ｓ１３０３で、リソースマネージャ３０３は、ディスパッチサーバ３０４を生成する。
【０１３３】
その後、Ｓ１３０４で、リソースマネージャ３０３は、ディスパッチサーバ３０４に対して、処理システム切り替え処理開始を指示する。さらに、システムマネージャ３００は、ディスパッチサーバ３０４の接続先変更部５０４に対して、リクエストの接続先を示すレコードの情報を与える。リクエストの接続先を示すレコードには、例えば、Ｂｌｕｅ環境３１０内の構成（ＬＢ３２１及び３３１など）を示すレコードやＧｒｅｅｎ環境３５０内の構成（ＬＢ３６１及び３７１など）を示すレコードが含まれる。なお、処理システム切り替え処理開始の指示に、これらのレコードの情報を含めても良い。後のＳ１３０５やＳ１３０６、Ｓ１３０９、Ｓ１３１０の処理の際に、該情報は用いられる。
【０１３４】
Ｓ１３０５で、ディスパッチサーバ３０４の接続先変更部５０４は、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードを書き換えるよう指示する。
【０１３５】
なお、システム管理者用のコンピュータ１１０からＤＮＳ３０１のレコードを変更するためのリクエストを受け付けたことによって、システムマネージャ３００が、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードを変更するよう指示しても良い。
【０１３６】
Ｓ１３０６で、リソースマネージャ３０３は、ＤＮＳ３０１のＤＮＳレコードについて、Ｂｌｕｅ環境３１０内の構成（ＬＢ３２１及び３３１など）を示すレコードから、ディスパッチサーバ３０４の受信部５０１を示すレコードに書き換える。すなわち、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータからのリクエストの接続先は、Ｂｌｕｅ環境３１０内のＷｅｂＵＩ層３２０にあるＬＢ３２１から、ディスパッチサーバ３０４の受信部５０１に変更される。また、顧客環境１３０内のネットワークデバイスからのリクエストの接続先は、Ｂｌｕｅ環境３１０内のフロントエンド層３３０にあるＬＢ３３１から、ディスパッチサーバ３０４の受信部５０１に変更される。
【０１３７】
Ｓ１３０７で、ディスパッチサーバ３０４は、受信部５０１がリクエストを受け付けるのを待つ。Ｓ１３０５でレコードが書き換えられた後、Ｓ１３０６で受信部５０１がリクエストを受け付けるのを待ち、受信部５０１が初めてリクエストを受け付けた時に、Ｓ１３０７へ移る。なお、システム管理者は、Ｓ８０６へ移り、割り当て処理を開始するタイミングをスケジュールで管理しても良いし、また、自動で割り当て処理が実行されるように設定しても良い。
【０１３８】
Ｓ１３０８で、ディスパッチサーバ３０４の割り当て管理部５０５は、テナントの割り当て処理（図７、または図１１）を行う。さらに、受信部５０１がリクエスト受け付けるたびに、ディスパッチサーバ３０４の決定部５０２は、該リクエストを処理すべき処理システムを決定する決定処理（図１０）を行う。
【０１３９】
Ｓ１３０９で、割り当て管理部５０５でのテナントの割り当て処理が完了すると、ディスパッチサーバ３０４の接続先変更部５０４は、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードを書き換えるよう指示する。
【０１４０】
なお、ディスパッチサーバ３０４の接続先変更部５０４が、Ｇｒｅｅｎ環境３５０内の構成（ＬＢ３６１及び３７１など）を示すレコードの情報を受け取るタイミングは、Ｓ１３０２ではなく、Ｓ１３０２の後からＳ１３０７の前までの間であってもよい。ディスパッチサーバ３０４の接続先変更部５０４は、システムマネージャ３００から与えられたＧｒｅｅｎ環境３５０内の構成（ＬＢ３６１及び３７１など）を示すレコードの情報を用いて、Ｓ１３０９やＳ１３１０の処理を行う。
【０１４１】
Ｓ１３１０で、リソースマネージャ３０３は、ＤＮＳ３０１のＤＮＳレコードについて、ディスパッチサーバ３０４を示すレコードから、Ｇｒｅｅｎ環境３５０を示すレコードに書き換える。すなわち、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータからのリクエストの接続先は、ディスパッチサーバ３０４の受信部５０１から、Ｇｒｅｅｎ環境３５０内のＷｅｂＵＩ層３６０にあるＬＢ３６１に変更される。また、顧客環境１３０内のネットワークデバイスからのリクエストの接続先は、ディスパッチサーバ３０４の受信部５０１から、Ｇｒｅｅｎ環境３５０内のフロントエンド層３７０にあるＬＢ３７１に変更される。これによって、処理システム切り替え処理が完了する。
【０１４２】
Ｓ１３１１で、リソースマネージャ３０３は、ディスパッチサーバ３０４を削除する。なお、ディスパッチサーバ３０４は、処理システム切り替え処理が完了した後に、自動的に削除されるように予めディスパッチサーバ３０４内で設定されていても良い。また、システム管理者用のコンピュータ１１０が、システムマネージャ３００に対してディスパッチサーバ３０４削除を要求して、システムマネージャ３００が、リソースマネージャ３０３に対してディスパッチサーバ３０４の削除を指示しても良い。
【０１４３】
なお、割り当て管理部５０５がテナントの割り当て処理を開始するタイミングは、上述したようなＳ１３０７であっても、または、Ｓ１３０３乃至Ｓ１３０６のいずれかであっても良い。
【０１４４】
なお、上述の説明では、Ｓ１３０９で、割り当て処理が完了してから、ディスパッチサーバ３０４の接続先変更部５０４は、ＤＮＳ３０１のレコードを書き換えるよう指示していた。
【０１４５】
しかしながら、リソースマネージャ３０３によってＧｒｅｅｎ環境のリソースが調整された場合には、Ｇｒｅｅｎ環境で大量のリクエストを処理することが可能となる。したがって、割り当て管理部５０５による割り当て処理が完了していなくても、リソースマネージャ３０３によってＧｒｅｅｎ環境のリソースが調整されていれば、ディスパッチサーバ３０４はレコードの書き換えを指示しても良い。また、その場合、システムマネージャ３００が、リソースマネージャ３０３に対して、レコードの書き換えの指示と、ディスパッチサーバ３０４の削除の指示をしてもよい。
【０１４６】
図１３のシーケンスでは、図６のシーケンスに対して、主にＳ１３０３とＳ１３１１が新たに追加されている。処理システム切り替え処理を行う時のみディスパッチサーバを設けることで、本応用例では、実施例１や実施例２と比較して、ディスパッチサーバ３０４の維持にかかるリソースやその費用を抑えることが可能となる。
【０１４７】
（応用例２）
実施例１、実施例２および応用例１では、Ｓ６０４やＳ１３０５で、リソースマネージャ３０３は、ＤＮＳ３０１のＤＮＳレコードをディスパッチサーバ３０４の受信部５０１を示すレコードに書き換える。このようにレコードが書き換えられた後、全てのリクエストをディスパッチサーバ３０４の受信部５０１が受け付けることになる。ディスパッチサーバ３０４の設定や処理能力等に何かしらの不具合が起こった際の影響を小さくするために、本応用例では、ディスパッチサーバ３０４の受信部５０１が受け付けるリクエストが段階的に増えるようにする。リソースマネージャ３０３は、ＤＮＳ３０１による振り分け機能を有効にして、ディスパッチサーバ３０４の受信部５０１が受け付けるリクエストを段階的に増加させるようにする。
【０１４８】
図１４は、ディスパッチサーバ３０４のソフトウェアモジュールの構成例を示す図である。ディスパッチサーバ３０４は、受信部５０１と、決定部５０２と、送信部５０３と、接続先変更部５０４と、割り当て管理部５０５と、振り分け機能設定変更部１４０６とを有する。本応用例では、実施例１や実施例２、応用例１と比較して、ディスパッチサーバ３０４に、振り分け機能設定変更部１４０６が新たに追加される。
【０１４９】
受信部５０１と、決定部５０２と、送信部５０３と、接続先変更部５０４と、割り当て管理部５０５とは、前述した説明と同じである。
【０１５０】
振り分け機能設定変更部１４０６は、リソースマネージャ３０３に対して、ＤＮＳ３０１のリクエスト振り分け機能の設定を変更するよう指示する。リクエスト振り分け機能とは、ＤＮＳ３０１に登録されている複数のレコードを用いて、リクエストを複数の接続先に振り分ける機能である。
【０１５１】
図１５は、処理システム切り替え処理におけるシーケンスの例を示す図である。本シーケンスについては、Ｓ１５０３〜Ｓ１５１０以外の処理については、図６と同様であるためその説明を省略する。
【０１５２】
Ｓ１５０３で、ディスパッチサーバ３０４の接続先変更部５０４は、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードについて、ディスパッチサーバ３０４の受信部５０１を示すレコードを追記するよう指示する。
【０１５３】
なお、システム管理者用のコンピュータ１１０からＤＮＳ３０１のレコードを変更するためのリクエストを受け付けたことによって、システムマネージャ３００が、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードを追記するよう指示しても良い。
【０１５４】
Ｓ１５０４で、リソースマネージャ３０３は、ＤＮＳ３０１に対して、Ｂｌｕｅ環境３１０内の構成（ＬＢ３２１及び３３１など）を示すレコードに加えて、ディスパッチサーバ３０４の受信部５０１を示すレコードを追記する。
【０１５５】
その後、Ｓ１５０５で、ディスパッチサーバ３０４の振り分け機能設定変更部１４０６は、リソースマネージャ３０３に対して、ＤＮＳ３０１のリクエスト振り分け機能の設定を有効にするよう指示する。
【０１５６】
Ｓ１５０６で、リソースマネージャ３０３は、ＤＮＳ３０１に対して、リクエスト振り分け機能の設定を有効にする。すると、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータからのリクエストは、Ｂｌｕｅ環境３１０内のＷｅｂＵＩ層３２０にあるＬＢ３２１と、ディスパッチサーバ３０４の受信部５０１とに振り分けられる。また、顧客環境１３０内のネットワークデバイスからのリクエストは、Ｂｌｕｅ環境３１０内のフロントエンド層３３０にあるＬＢ３３１と、ディスパッチサーバ３０４の受信部５０１とに振り分けられる。なお、ディスパッチサーバ３０４の受信部５０１がリクエストを受信したら、決定部５０２は、決定処理（図１０）を開始する。なお、割り当て処理（図１０）が開始されるまでに受信部５０１が受信したリクエストについては、すべてＢｌｕｅ環境３１０で処理されることとなる。
【０１５７】
Ｓ１５０７で、システムマネージャ３００は、ディスパッチサーバ３０４が正常に動作するかを確認する。Ｓ１５０８で、システムマネージャ３００は、ディスパッチサーバ３０４に対して、ディスパッチサーバ３０４の動作確認が完了した旨を通知する。
【０１５８】
なお、Ｓ１５０７で、ディスパッチサーバ３０４が正常に動作しないことが確認された場合、システムマネージャ３００は、リソースマネージャ３０３に対して、ＤＮＳ３０１のレコードの変更するよう指示する。この変更内容としては、Ｂｌｕｅ環境３１０内の構成（ＬＢ３２１及び３３１など）を示すレコードに変更するような指示となる。そして、その指示に従い、リソースマネージャ３０３がＤＮＳ３０１のレコードを変更する。この処理により、ディスパッチサーバ３０４を用いた処理システムの切り替え処理全体を一旦中止することができ、システム管理者用のコンピュータ１１０が、ディスパッチサーバ３０４の構成の異常部分を修正するなどの対応をとることが可能となる。
【０１５９】
Ｓ１５０９で、ディスパッチサーバ３０４の振り分け機能設定変更部１４０６は、リソースマネージャ３０３に対して、ＤＮＳ３０１のリクエスト振り分け機能の設定を無効にするよう指示する。なお、この場合、振り分け機能の設定が無効にされると、ＤＮＳ３０１のレコードは、ディスパッチサーバ３０４の受信部５０１を示すレコードとなる。
【０１６０】
Ｓ１５１０で、リソースマネージャ３０３は、ＤＮＳ３０１に対して、リクエスト振り分け機能の設定を無効にする。そして、ＤＮＳ３０１のレコードは、ディスパッチサーバ３０４の受信部５０１を示すレコードとなる。
【０１６１】
Ｓ１５１１で、ディスパッチサーバ３０４の割り当て管理部５０５は、テナントの割り当て処理（図７）を行う。
【０１６２】
本応用例では、ディスパッチサーバ３０４に設定や処理能力等に異常が見つかった際にディスパッチサーバ３０４にリクエストを流さないように対応することで、ディスパッチサーバの異常によって障害を受けるリクエストを少なくすることが可能となる。
【０１６３】
（応用例３）
実施例１、実施例２、応用例１および応用例２では、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータは、管理システム１００に対してリクエストを送る際に、ＤＮＳ３０１に登録されているリクエストの接続先を示す情報を保持していた。
【０１６４】
しかし、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータは、リクエストを送るたびに毎回、ＤＮＳ３０１に、リクエストの接続先を問合せるとは限らない。顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータのウェブブラウザなどでは、ある一定期間、リクエストの接続先を示す情報（ＩＰアドレスなど）をキャッシュとして保持することができる。顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータのウェブブラウザを用いたリクエストは、保持された情報が接続先として利用される場合がある。顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータでリクエストの接続先を示す情報が保持している期間内に、リソースマネージャ３０３がＤＮＳ３０１のレコードを変更することが考えられる。この場合、リソースマネージャ３０３がＤＮＳ３０１のレコードを変更した後に、顧客管理者用のコンピュータ１２０などからＢｌｕｅ環境３１０にリクエストが送信されてしまうことが起こり得る。
【０１６５】
本応用例では、リソースマネージャ３０３がＤＮＳ３０１のレコードを変更した後に、古いＩＰアドレスを使って送信されてきたリクエストを受付けないための構成について説明する。具体的には、管理システム１００がそのリクエストを受け付けないようにするために、リソースマネージャ３０３は各処理システム内にあるファイアウォールの設定を変更する。以降、ファイアウォールをＦＷと呼ぶ場合もある。
【０１６６】
図１６は、ＦＷを含めた管理システム１００の構成を示す図である。ＦＷ１６１１および１６５１はそれぞれ、リソースマネージャ３０３による設定に応じて、許可されていないリクエストがＢｌｕｅ環境３１０およびＧｒｅｅｎ環境３５０に入らないよう制御する。
【０１６７】
図１６は、図３（Ｂ）と比較して、Ｂｌｕｅ環境３１０内にＦＷ１６１１が追加され、Ｇｒｅｅｎ環境３５０内にＦＷ１６５１が追加される。
【０１６８】
図１７は、ディスパッチサーバ３０４のソフトウェアモジュールの構成例を示す図である。ディスパッチサーバ３０４は、受信部５０１と、決定部５０２と、送信部５０３と、接続先変更部５０４と、割り当て管理部５０５と、ＦＷ設定変更部１７０６とを有する。本応用例では、ディスパッチサーバ３０４に、ＦＷ設定変更部１７０６が新たに追加される。
【０１６９】
受信部５０１と、決定部５０２と、送信部５０３と、接続先変更部５０４と、割り当て管理部５０５とは、前述した説明と同じである。
【０１７０】
ＦＷ設定変更部１７０６は、リソースマネージャ３０３に対して、ＦＷ１６１１および１６５１の設定を変更するよう指示する。
【０１７１】
図１８は、処理システム切り替え処理におけるシーケンスの例を示す図である。本シーケンスについては、Ｓ１８０５〜Ｓ１８１０以外の処理については、図６と同様であるためその説明を省略する。
【０１７２】
Ｓ１８０５で、Ｓ６０２の開始指示を受けて、さらに、ディスパッチサーバ３０４のＦＷ設定変更部１７０６は、リソースマネージャ３０３に対して、ＦＷ１６１１および１６５１について設定変更を指示する。ここでの指示は、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスからのリクエストであってディスパッチサーバ３０４を経由しないリクエストを拒否するよう設定を変更するための指示である。なお、ＦＷ設定変更部１７０６は、ＦＷ１６１１のみ設定変更を指示しても良い。また、システムマネージャ３００が、リソースマネージャ３０３に対して、設定変更を指示しても良い。
【０１７３】
Ｓ１８０６で、リソースマネージャ３０３は、ＦＷ１６１１および１６５１について、設定変更を行う。ここでの変更は、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスからのリクエストであってディスパッチサーバ３０４を経由しないリクエストを拒否するようにするための設定変更である。これにより、顧客管理者用のコンピュータ１２０や顧客環境１３０内のコンピュータが、ＤＮＳ３０１のレコードが変更される前のＩＰアドレスを使ってリクエストを送った場合に、管理システム１００が、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスからのリクエストであってディスパッチサーバ３０４を経由しないリクエストを受け付けること防ぐことが可能となる。
【０１７４】
その後、Ｓ１８０７で、リソースマネージャ３０３は、ディスパッチサーバ３０４に対して、割り当て処理（図７）および決定処理（図１０）を開始するよう指示する。なお、リソースマネージャ３０３がＦＷ１６１１および１６５１について設定を変更した後、受信部５０１がリクエストを受け付けるのを待ち、受信部５０１が初めてリクエストを受け付けた時に、Ｓ１７０８へ移っても良い。
【０１７５】
Ｓ１８０８で、ディスパッチサーバ３０４の割り当て管理部５０５は、テナントの割り当て処理（図７）を行う。さらに、受信部５０１がリクエスト受け付けるたびに、ディスパッチサーバ３０４の決定部５０２は、該リクエストを処理すべき処理システムを決定する決定処理を行う。
【０１７６】
Ｓ１８０９で、割り当て管理部５０５でのテナントの割り当て処理が完了すると、ディスパッチサーバ３０４のＦＷ設定変更部１７０６は、リソースマネージャ３０３に対して、ＦＷ１６１１および１６５１について設定変更を指示する。ここでの指示は、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスからのリクエストであってディスパッチサーバ３０４を経由しないリクエストを拒否する設定を解除するよう設定を変更するための指示である。
【０１７７】
Ｓ１８１０で、リソースマネージャ３０３は、ＦＷ１６１１および１６５１について設定変更を行う。ここでの変更は、顧客管理者用のコンピュータ１２０、顧客環境１３０内のコンピュータやネットワークデバイスからのリクエストであってディスパッチサーバ３０４を経由しないリクエストを拒否する設定を解除するための設定変更である。
【０１７８】
本応用例では、顧客管理者用のコンピュータ１２０や顧客環境１３０内にあるコンピュータからのリクエストが、ディスパッチサーバ３０４を経由せずに、Ｂｌｕｅ環境３１０やＧｒｅｅｎ環境３５０で受け付けられることを防ぐことが可能となる。ディスパッチサーバ３０４を経由せずにリクエストがＢｌｕｅ環境３１０やＧｒｅｅｎ環境３５０へ送られることによる、リクエストの処理における不具合の発生を防ぐことができる。
【０１７９】
（実施例３）
実施例１、実施例２、応用例１、応用例２および応用例３では、顧客管理者と顧客との依存関係が複雑であるため、テナントの割り当て処理（図７）において、依存関係にある顧客管理者および顧客を同時にまとめて割り当てることができなかった。依存関係にある顧客管理者および顧客を同時にまとめて割り当ててしまうと、割り当て管理部５０５は、一回の割り当て処理で、管理システム１００を利用する利用者の全テナントのうち一部ではなく、大部分のテナントをＧｒｅｅｎ環境に割り当てることになる。すると、決定部５０２の決定処理により受信部５０１で受け付けられたリクエストが全てＧｒｅｅｎ環境に送信され、リクエストが大量である場合には該大量のリクエストに対する処理が滞る恐れがある。そのため、前述の実施例では、依存関係にある顧客管理者および顧客を同時にまとめて割り当てなかった。
【０１８０】
本実施例では、顧客管理者と顧客との依存関係が複雑でない場合を想定する。顧客管理者と顧客との依存関係が複雑でないとは、例えば、一人の顧客に対応する顧客管理者が一人であるような場合である。テナントの割り当て処理（図７）において、依存関係にある顧客管理者および顧客をまとめて割り当てることで、複数のリクエストを処理する場合であっても、リクエストの処理で不具合が発生しないようにリクエストを処理すべき処理システムを適切に決定できる。
【０１８１】
本実施例におけるテナントの割り当て処理の流れを、図７を用いて説明する。
【０１８２】
図７は、割り当て管理部５０５により実行される、テナントの割り当て処理の流れの例を示すフローチャートである。本実施例でテナントの割り当て処理の流れについて、Ｓ７０２以外の処理については、前述の実施例と同様であるためその説明を省略する。
【０１８３】
Ｓ７０２では、割り当て管理部５０５は、管理システム１００を利用する顧客管理者や顧客の全テナントのうち、依存関係にある顧客管理者および顧客のテナントをまとめてＧｒｅｅｎ環境に割り当てる処理を行う。
【０１８４】
顧客管理者および顧客の依存関係を示す情報はデータベース３０２に格納されている。ディスパッチサーバ３０４の生成時に、割り当て管理部５０４が該情報をデータベース３０２から取得し、保持しても良い。また、割り当て管理部５０４は、Ｓ７０２の処理を行うたびに、該情報をデータベース３０２から取得し、参照しても良い。なお、割り当て管理部５０４は、システムマネージャ３００を通じて、該情報を取得しても良い。
【０１８５】
本実施例における決定処理について、図１０を用いて説明する。
【０１８６】
上述したように、本実施例における割り当て処理では、依存関係にある顧客管理者および顧客のテナントをまとめて割り当てるため、受信部５０１が受信したリクエストに含まれる送信テナントと関係テナントは同じ処理システムに割り当てられていることとなる。したがって、決定部５０２は、関係テナントを考慮せずに、送信テナントの割り当てにしたがって適切な処理システムを決定できる。つまり、Ｓ１００４乃至Ｓ１００７を省略できる。なお、受信部５０１が受信したリクエストに関係テナントが含まれる場合、決定部５０２は、送信テナントを考慮せずに、関係テナントの割り当てにしたがって処理システムを決定することも可能である。
【０１８７】
顧客管理者と顧客との依存関係が複雑でない場合に、本実施例を適用できる。テナントの割り当て処理（図７）において、依存関係にある顧客管理者および顧客をまとめて割り当てることで、受信したリクエストに含まれる送信テナントおよび関係テナントのいずれかのみの割り当てに従い、処理システムを適切に決定できる。
【０１８８】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
【０１８９】
ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【０１９０】
１００  管理システム
３０４  ディスパッチサーバ
５０１  受信部
５０２  決定部
５０３  送信部
【図１】
2016218530.tif 000003
【図２】
2016218530.tif 000004
【図３】
2016218530.tif 000005
【図４】
2016218530.tif 000006
【図５】
2016218530.tif 000007
【図６】
2016218530.tif 000008
【図７】
2016218530.tif 000009
【図８】
2016218530.tif 000010
【図９】
2016218530.tif 000011
【図１０】
2016218530.tif 000012
【図１１】
2016218530.tif 000013
【図１２】
2016218530.tif 000014
【図１３】
2016218530.tif 000015
【図１４】
2016218530.tif 000016
【図１５】
2016218530.tif 000017
【図１６】
2016218530.tif 000018
【図１７】
2016218530.tif 000019
【図１８】
2016218530.tif 000020