JP2021039423A

JP2021039423A - システム、および制御方法

Info

Publication number: JP2021039423A
Application number: JP2019158664A
Authority: JP
Inventors: 佑太郎小澤; Yutaro Ozawa
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-08-30
Filing date: 2019-08-30
Publication date: 2021-03-11
Also published as: US20210067583A1; US11184431B2

Abstract

【課題】動作確認などを目的とした外部装置からのリクエストが直接Ｇｒｅｅｎ環境へ送信される仕組みには、セキュリティリスクや作業者の負荷がある。【解決手段】現行バージョンのアプリケーションが動作する第１の処理システムと、次バージョンのアプリケーションが動作する第２の処理システムと、管理サーバとを含むシステムであって、管理サーバは、第２の処理システムにアクセスするための情報を、システムのデータベースに登録する。第１の処理システムは、外部装置からのリクエストを、第１の処理システムに含まれる負荷分散装置を介して受信し、前記受信したリクエストが第２の処理システムでの処理対象となるリクエストである場合、データベースに登録されている第２の処理システムにアクセスするための情報を用いて、前記受信したリクエストを第２の処理システムに対して送信する。【選択図】図８

Description

本発明は、現行バージョンのアプリケーションが動作する第１の処理システムと、次バージョンのアプリケーションが動作する第２の処理システムと、管理サーバとを含むシステム、および制御方法に関する。

クラウドベンダーがコンピューティング資源をＩａａＳ（ＩｎｆｒａｓｔｒｕｃｔｕｒｅｓａｓａＳｅｒｖｉｃｅ）やＰａａＳ（ＰｌａｔｆｏｒｍａｓａＳｅｒｖｉｃｅ）として提供するクラウドサービスがある。企業や組織はＩａａＳやＰａａＳなどのクラウドサービスを利用して、社内業務や顧客へのサービス提供のためのシステムを構築する。

また、クラウドサービスを用いたシステムにおいては、システムのバージョンを更新する手段として、ＢｌｕｅＧｒｅｅｎデプロイメントと呼ばれる方式が利用されている（特許文献１）。このＢｌｕｅＧｒｅｅｎデプロイメントでは、現行バージョンのアプリケーションが動作するＢｌｕｅ環境および次バージョンのアプリケーションが動作するＧｒｅｅｎ環境が構築されていて、それぞれの処理システムがロードバランサを有している。クライアントがシステムにアクセスする際に参照するＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）レコードをＢｌｕｅ環境に含まれるロードバランサのＩＰアドレスからＧｒｅｅｎ環境に含まれるロードバランサのＩＰアドレスに変更する。これにより、システムを停止することなくバージョンアップできる。

上述したＢｌｕｅＧｒｅｅｎデプロイメントを用いてバージョンを更新する前に、Ｇｒｅｅｎ環境のアクセス確認や簡単な機能確認等を含む動作テストが、動作確認クライアントによって行われることが一般的である。この場合、ＤＮＳレコードが変更される前であるため、動作確認クライアントがＧｒｅｅｎ環境へアクセスするためには、ロードバランサのＩＰアドレスを直接指定する必要がある。これを実現する方法として、ＰＣ内に標準搭載されているｈｏｓｔｓファイル（ＩＰアドレスとドメイン名の対応付けを記載するテキストファイル）にＧｒｅｅｎ環境のロードバランサＩＰアドレスとドメインを記載しアクセスする方法がある。ｈｏｓｔｓファイルはＤＮＳよりも先に参照されるため、動作確認クライアントＰＣのｈｏｓｔｓファイルを書き換えることでＧｒｅｅｎ環境へのアクセスが可能となる。

特開２０１８−０８８１１４号公報

上述した、動作確認クライアントなどの外部装置がｈｏｓｔｓファイルを用いて、動作確認のために、Ｇｒｅｅｎ環境での処理対象となるリクエストを直接Ｇｒｅｅｎ環境へ送信することには、以下のような課題がある。

動作確認クライアントでは、Ｇｒｅｅｎ環境へアクセスするためにｈｏｓｔｓファイルの書き換えを行う必要がある。ここで、ｈｏｓｔｓファイルは、一般的にＰＣのセキュリティソフトの監視対象になっている。その理由は、ｈｏｓｔｓファイルはファーミング（ＤＮＳのＩＰアドレスを書き換えることで、正しいＵＲＬにアクセスしていると見せかけて別のサイトへ誘導する手法）で改ざんされる対象となるためである。そこで、動作確認クライアントでは、ｈｏｓｔｓファイルの書き換えを行うために、ｈｏｓｔｓファイルをセキュリティソフトの監視対象から外す必要がある。したがって、動作確認クライアントとして動作するＰＣのセキュリティリスクが高まる懸念がある。

また、動作確認を行う作業者は、Ｇｒｅｅｎ環境へのアクセスに用いる情報を調べることが必要となる。例えば、Ｇｒｅｅｎ環境の負荷分散装置のＩＰアドレスなどを調べる必要がある。そのためには、クラウドベンダーが提供するＷｅｂＵＩへログインしＩＰアドレスを取得するためのキー情報を調べる必要があり、動作確認を行う作業者にとっては手間がかかる。

以上説明したように、動作確認などを目的とした外部装置からのリクエストが直接Ｇｒｅｅｎ環境へ送信される仕組みには、セキュリティリスクや作業者の負荷がある。

そこで、本発明は、次バージョンのアプリケーションが動作する処理システムでの処理対象となるリクエストを当該処理システムへ直接送信することなく、当該処理システムで処理するための仕組みを提供することを目的とする。

上記課題を解決するために、本発明は、現行バージョンのアプリケーションが動作する第１の処理システムと、次バージョンのアプリケーションが動作する第２の処理システムと、管理サーバとを含むシステムであって、前記管理サーバは、前記第２の処理システムにアクセスするための情報を、前記システムのデータベースに登録する登録手段を有し、前記第１の処理システムは、外部装置からのリクエストを、前記第１の処理システムに含まれる負荷分散装置を介して受信する受信手段と、前記受信したリクエストが前記第２の処理システムでの処理対象となるリクエストである場合、前記データベースに登録されている前記第２の処理システムにアクセスするための前記情報を用いて、前記受信したリクエストを前記第２の処理システムに対して送信する送信手段と、を有することを特徴とする。

本発明によれば、次バージョンのアプリケーションが動作する処理システムでの処理対象となるリクエストを当該処理システムへ直接送信することなく、当該処理システムで処理することができる。

本発明の実施形態に係るネットワークシステムの構成を示す図である。管理サーバのハードウェア構成を示す図である。管理サーバのソフトウェア構成を示す図である。アプリケーションサーバのソフトウェア構成の一例を示す図である。ＩＰアドレス情報管理テーブルの一例を示す図である。ＨＴＴＰリクエストの一例を示す図である。ロードバランサＩＰアドレス登録処理の一例を示すフローチャートである。リクエスト転送処理の一例を示すフローチャートである。ＩＰアドレス情報管理テーブルの一例を示す図である。ロードバランサＩＰアドレス登録処理の一例を示すフローチャートである。リクエスト転送処理の一例を示すフローチャートである。ＩＰアドレスキャッシュ情報の一例を示す図である。リクエスト転送処理の一例を示すフローチャートである。ＩＰアドレス取得ポーリング処理の一例を示すフローチャートである。ＩＰアドレス情報管理テーブルの一例を示す図である。ロードバランサＩＰアドレス登録処理の一例を示すフローチャートである。リクエスト転送処理の一例を示すフローチャートである。ＩＰアドレス取得ポーリング処理の一例を示すフローチャートである。

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

（実施例１）
図１は、本発明の実施形態に係るネットワークシステムの構成の一例を示す図である。情報処理システム１００は、クライアントコンピュータ１０５からの要求を受け付けて処理をする機能を提供するクラウドサービスである。クライアントコンピュータ１０５は、ユーザが操作するＰＣや、ユーザにサービスを提供するアプリケーションサーバ等が想定される。クライアントコンピュータ１０５は、インターネット１０６を経由して情報処理システム１００に接続する。システム管理者コンピュータ１０４は、システム管理者による情報処理システム１００を運用するための各種指示を管理サーバ１０１に実行させる。システム管理者コンピュータ１０４は、インターネット１０６を経由して管理サーバ１０１に接続する。

情報処理システム１００は、ＤＮＳサーバ１０２、ＤＢ（データベース）１０３、現行バージョンのアプリケーションが動作する処理システムであるＢｌｕｅ環境１０７を含む。ＢｌｕｅＧｒｅｅｎデプロイメントを実施する際には、情報処理システム１００は、次バージョンのアプリケーションが動作する処理システムであるＧｒｅｅｎ環境１１０をさらに含む。Ｂｌｕｅ環境１０７およびＧｒｅｅｎ環境１１０は、ロードバランサ１０８および１１１、アプリケーションサーバ１０９および１１２を含む。このうち、ＤＮＳサーバ１０２、ロードバランサ１０８および１１１はクラウドベンダーによって提供される。

ＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバ１０２は、クライアントコンピュータ１０５が情報処理システム１００にアクセスする際に参照するＤＮＳレコードおよびクラウドベンダーが提供する各ロードバランサを表すＤＮＳレコードを管理する。ＤＮＳサーバ１０２はインターネット１０６に接続されており、クライアントコンピュータ１０５はインターネット１０６を介してＤＮＳサーバ１０２へアクセスする。ＤＢ１０３は、サービスを提供するための各種データ等が格納されているデータベースである。特に本実施例では、ＤＢ１０３には、Ｇｒｅｅｎ環境１１０にアクセスするための情報が登録されている。Ｇｒｅｅｎ環境１１０にアクセスするための情報は、例えば、Ｇｒｅｅｎ環境１１０に含まれるロードバランサ１１１のＩＰアドレスなどであるがこれに限られない。

ロードバランサ１０８および１１１は、クライアントコンピュータ１０５からのリクエストをアプリケーションサーバ１０９および１１２に転送する負荷分散装置である。アプリケーションサーバ１０９は、ロードバランサ１０８を介して受信したリクエストを処理する仮想マシンである。アプリケーションサーバ１１２は、ロードバランサ１１１を介して受信したリクエストを処理する仮想マシンである。アプリケーションサーバ１０９、１１２は、オートスケール機能によってそれぞれ複数台が起動されていてもよい。本実施例では、アプリケーションサーバ１０９は、Ｇｒｅｅｎ環境での処理対象となるリクエストを受信した場合、Ｇｒｅｅｎ環境のロードバランサ１１１に対してリクエストを転送する処理を行う。

ここで、仮想マシンとは、仮想化技術によって、サーバを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピュータである。なお、アプリケーションサーバ１０９および１１２は仮想マシンに限られず、サーバレスの技術を用いたイベント駆動型コンピューティングサービスによってリクエストの処理が実行されてもよい。イベント駆動型コンピューティングサービスには、例えば、ＡＷＳＬａｍｂｄａ、ＧｏｏｇｌｅＣｌｏｕｄＦｕｎｃｔｉｏｎｓ、ＭｉｃｒｏｓｏｆｔＡｚｕｒｅＦｕｎｃｔｉｏｎｓ等がある。イベント駆動型コンピューティングサービスを構成するサーバは、クラウドコンピューティングサービスとして提供されるものである。そして、後述する図２に示す各ハードウェアの機能は、それぞれ、仮想マシンソフトウェアによってアプリケーションソフトウェアとして実現され、物理ハードウェア要素と同様の挙動をとるものとする。

図２は、管理サーバ１０１、アプリケーションサーバ１０９および１１２として機能する情報処理装置のハードウェア構成の一例を示す図である。管理サーバ１０１においてハードディスク（ＨＤＤ）２１２には、管理サーバソフトウェアのプログラムが格納される。なお、管理サーバ１０１、アプリケーションサーバ１０９および１１２が仮想マシンである場合においては、それらとして機能する仮想マシンが動作するサーバーコンピューターも、情報処理装置に含まれる。

ＣＰＵ２０１は、管理サーバ１０１の全体の制御を司る。ＣＰＵ２０１が、ＨＤＤ２１２に記録されたデバイス管理プログラムをＲＡＭ２０３等に読み出して実行することにより、図３に示す管理サーバ１０１のソフトウェア構成及び後述する図７、図１０、図１４、図１６、図１８のフローチャートの処理が実現される。

ＲＯＭ２０２には、ＢＩＯＳのプログラムやブートプログラムが格納されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード（ＫＢ）２０９やポインティングデバイス（ＰＤ）２１０等からの指示入力を制御する。ディスプレイコントローラ（ＤＳＰＣ）２０６は、ディスプレイ（ＤＳＰ）２１１の表示を制御する。

ディスクコントローラ（ＤＫＣ）２０７は、ハードディスク（ＨＤＤ）２１２やＣＤＲＯＭ（ＣＤ）２１３等の記憶装置へのアクセスを制御する。ＨＤＤ２１２及びＣＤ−ＲＯＭ（ＣＤ）２１３等には、ブートプログラム、オペレーティングシステムのプログラム、データベース、管理サーバソフトウェアプログラム及びデータ等が記憶されている。インタフェースコントローラ（ＩＦＣ）２０８は、インターネット１０６を介してシステム管理者コンピュータ１０４とのデータ通信を行う。

これらの各構成要素は、システムバス２０４上に配置される。

なお、本実施形態に係るプログラムは、ＣＤ−ＲＯＭ等の記憶媒体に格納された形で供給されてもよい。その場合には図２に示すＣＤ２１３等によって記憶媒体からプログラムが読み取られ、ＨＤＤ２１２にインストールされる。またロードバランサ１０８および１１１、アプリケーションサーバ１０９および１１２のハードウェア構成も図２に示す通りである。各装置のＣＰＵが各装置のＨＤＤ等に記憶されたプログラムに基づき処理を実行することによって各装置の機能等が実現される。

図３は、管理サーバ１０１のソフトウェア構成の一例を示す図である。管理サーバ１０１は、システム管理者がシステム管理者コンピュータ１０４を通じてリクエストした処理を実行する。管理サーバ１０１は、環境構築部３０１、環境削除部３０２、ＤＮＳ更新部３０３、ＩＰアドレス取得部３０４、ＩＰアドレス登録部３０５、ＩＰアドレス削除部３０６を含む。

環境構築部３０１は、次バージョン環境であるＧｒｅｅｎ環境１１０を構築する。構築の際はクラウドベンダーが提供するＡＰＩを実行することで、Ｇｒｅｅｎ環境１１０の各構成要素を作成する。

環境削除部３０２は、ＢｌｕｅＧｒｅｅｎデプロイメントによって旧バージョン環境となったＢｌｕｅ環境１０７を削除する。削除の際はクラウドベンダーが提供するＡＰＩを実行することで、Ｂｌｕｅ環境１０７の各構成要素を削除する。

ＤＮＳ更新部３０３は、ＤＮＳサーバ１０２が管理するＤＮＳレコードを更新する。本実施例では、本番環境として動作する処理システムに係るレコードがＤＮＳ更新部３０３によって書き換えられることで、ＢｌｕｅＧｒｅｅｎデプロイメントが実行される。なお、Ｇｒｅｅｎ環境の動作確認中は、ＤＮＳサーバ１０２ではＧｒｅｅｎ環境に係るレコードは管理されていない。

ＩＰアドレス取得部３０４は、環境構築部３０１が構築したＧｒｅｅｎ環境１１０のロードバランサ１１１のＩＰアドレス取得キーを取得し、該ＩＰアドレス取得キーを用いてロードバランサ１１１のＩＰアドレスを取得する。ＩＰアドレス取得キーはクラウドベンダーが提供するＡＰＩを使用することで取得する。ＩＰアドレス取得は該ＩＰアドレス取得キーを引数にコマンドラインツールを実行することで取得する。Ｇｒｅｅｎ環境１１０の動作確認中は、ＤＮＳサーバ１０２ではＧｒｅｅｎ環境に係るレコードは管理されていないため、本実施例では、Ｇｒｅｅｎ環境１１０のロードバランサ１１１のＩＰアドレスをＤＢ１０３で管理するようにする。

ＩＰアドレス登録部３０５は、ＩＰアドレス取得部３０４が取得したＩＰアドレスやその他付加情報をＤＢ１０３へ登録する。

ＩＰアドレス削除部３０６は、ＩＰアドレス登録部３０５がＤＢ１０３へ登録したＩＰアドレス等を削除する。本実施例では、Ｇｒｅｅｎ環境１１０の動作確認が終了すると、Ｇｒｅｅｎ環境１１０のロードバランサ１１１のＩＰアドレスはＤＢ１０３から削除される。

図４は、アプリケーションサーバ１０９および１１２のソフトウェア構成の一例を示す図である。それぞれロードバランサ１０８および１１１から転送されたリクエストを処理する。アプリケーションサーバ１０９および１１２はリクエスト受信部４０１、リクエスト判断部４０２、ＩＰアドレス情報管理部４０３、リクエスト振り分け部４０４を含む。

リクエスト受信部４０１はロードバランサ１０８および１１１からのリクエストを受信する。

リクエスト判断部４０２はリクエスト受信部４０１で受信したリクエストの内容から、動作確認権限を持つユーザ（後述）からのリクエストかどうかを判断する。なお、判定方法については後述する。

ＩＰアドレス情報管理部４０３はリクエスト判断部４０２の判断結果に従って、ＩＰアドレス登録部３０５によって登録されるＤＢ１０３上のＩＰアドレス情報管理テーブル（後述）のデータを取得する。

リクエスト振り分け部４０４は、ＩＰアドレス情報管理部４０３が取得したＩＰアドレスへリクエストを振り分ける。

図５は、ＩＰアドレス情報管理テーブルの一例を示す図である。該テーブルはＤＢ１０３で保持される。該テーブルには、ＩＰアドレス登録部３０５が登録したロードバランサ１１１のＩＰアドレスが登録されている。なお、クラウドベンダーの仕様によって複数のＩＰを持つロードバランサの場合にはその全てを登録する（図５では一例としてＩＰアドレスを二つ記載）。本テーブルでは、動作確認中であるＧｒｅｅｎ環境にアクセスするための情報として、Ｇｒｅｅｎ環境のロードバランサのＩＰアドレスが管理される。

図６は動作確認権限をもつユーザの操作によりクライアントコンピュータ１０５からロードバランサ１０８へ送信されるＨＴＴＰリクエストの構成の一例を示す図である。情報６０１はＨＴＴＰメソッドおよびリクエストＵＲＬを表している。情報６０２はＨＴＴＰヘッダを表している。情報６０３はリクエストのＢｏｄｙを表しており、ここにリクエスト元ユーザの権限タイプが記載される。図６では動作確認権限を表す文字列としてＴｅｓｔＭａｓｔｅｒを設定している。該リクエストは認証サーバ（不図示）で検証を通過するとアプリケーションサーバ１０９へ送信される。アプリケーションサーバ１０９は情報６０３を確認し、権限タイプが動作確認権限を表す文字列かどうかを検証する。

図７は管理サーバ１０１のロードバランサＩＰアドレス登録処理の一例を示すフローチャートである。本フローチャートに示す処理は、新たに構築されたＧｒｅｅｎ環境のロードバランサのＩＰアドレスをＤＢに登録するために管理サーバ１０１により実行される。本フローチャートの処理は、ＣＰＵ２０１が、ＲＯＭ２０２やＲＡＭ２０３、ＨＤＤ２１２などに記録されたプログラムを読み出して実行することにより実現される。

Ｓ７０１にて、環境構築部３０１は、Ｇｒｅｅｎ環境１１０を構築する。

Ｓ７０２にて、ＩＰアドレス取得部３０４は、クラウドベンダーが提供するＡＰＩを使用してＩＰアドレス取得キーを取得する。

Ｓ７０３にて、ＩＰアドレス取得部３０４は、Ｓ７０２で取得したＩＰアドレス取得キーを引数にコマンドラインツールを実行し、ロードバランサ１１１のＩＰアドレスを取得する。

Ｓ７０４にて、ＩＰアドレス登録部３０５は、Ｓ７０３で取得したロードバランサ１１１のＩＰアドレスをＩＰアドレス情報管理テーブルとしてＤＢ１０３へ登録する。

図８はアプリケーションサーバ１０９のリクエスト転送処理の一例を示すフローチャートである。本フローチャートで示す処理は、Ｇｒｅｅｎ環境が構築された後の動作確認中に行われる処理である。本フローチャートの処理は、アプリケーションサーバ１０９のＣＰＵ２０１が、ＲＯＭ２０２やＲＡＭ２０３、ＨＤＤ２１２などに記録されたプログラムを読み出して実行することにより実現される。

Ｓ８０１にて、リクエスト受信部４０１が、ロードバランサ１０８を介して、外部装置からのリクエストを受信する。リクエストは、図６で示す構成を有する。

Ｓ８０２にて、リクエスト判断部４０２がＳ８０１で受信したリクエストＢｏｄｙ内の権限タイプが動作確認権限を表す文字列と一致するかどうか検証する。一致する場合、Ｓ８０３へ進む。一致しない場合、Ｓ８０５へ進む。

Ｓ８０３にて、ＩＰアドレス情報管理部４０３がＤＢ１０３からＩＰアドレス情報管理テーブルを取得する。

Ｓ８０４にて、リクエスト振り分け部４０４がＳ８０３で取得したＩＰアドレスへリクエストを送信する。

Ｓ８０５にて、Ｓ８０１で受信したリクエストのうち動作確認権限を持たないユーザからのリクエストを処理する。

本実施例では、動作確認権限を表す所定の識別子がリクエストに含まれていることに基づいて、Ｇｒｅｅｎ環境での処理対象となるリクエストであるとの判断が行われる。他の方法としては、例えば、リクエストの処理種別などに基づいて、Ｇｒｅｅｎ環境での処理対象となるリクエストであるとの判断が行われるという方法などでもよい。

なおフローチャート上に図示していないが、動作確認作業が完了した後にシステム管理者コンピュータ１０４からの操作により、ＩＰアドレス削除部３０６がＤＢ１０３上のＩＰアドレス情報管理テーブルを削除する。また、ＤＮＳ更新部３０３がＤＮＳサーバ１０２へロードバランサ１１１のＩＰアドレスを登録し、Ｇｒｅｅｎ環境とＢｕｌｅ環境を切り替える。その後、環境削除部３０２が旧Ｂｌｕｅ環境となったＢｌｕｅ環境１０７を削除する。

以上説明したように、実施例１によれば、管理サーバがＧｒｅｅｎ環境構築時にロードバランサのＩＰアドレスを取得してＤＢに登録することで、外部装置からのリクエストはＢｌｕｅ環境経由でＧｒｅｅｎ環境へ送信されて処理される。これにより、Ｇｒｅｅｎ環境での処理対象となるリクエストを、外部装置から直接Ｇｒｅｅｎ環境へ送信する必要がなくなるため、ＩＰアドレス取得キーの調査および動作確認者のＰＣ上のｈｏｓｔｓファイルを書き換えが不要となる。つまり、動作確認作業者の作業負荷と作業ＰＣのセキュリティリスクを低減したＧｒｅｅｎ環境へのアクセスが可能となる。

（実施例２）
実施例１では、Ｂｌｕｅ環境のアプリケーションサーバ１０９が、ＤＢに登録されているＧｒｅｅｎ環境のロードバランサのＩＰアドレスを用いてリクエストをＧｒｅｅｎ環境のロードバランサへ送信するようにした。しかしながら、Ｇｒｅｅｎ環境のロードバランサのＩＰアドレスは予告なしに変更されてしまうことがある。その際、Ｂｌｕｅ環境のアプリケーションサーバ１０９は、Ｇｒｅｅｎ環境へのアクセスに失敗する。そこで、本実施例では、Ｇｒｅｅｎ環境へのアクセスに失敗した場合に、アプリケーションサーバ１０９は、変更後のＩＰアドレスを取得してＤＢに登録し、変更後のＩＰアドレスを用いてＧｒｅｅｎ環境へリクエストを送信するようにする。

実施例２では、図１〜図４、図６に示す構成が実施例１と同じであり、実施例１と同様の部分については同一の符号を用いてその説明を省略する。以下、実施例１と異なる点を主に説明する。

図９はＳ７０４でＩＰアドレス登録部３０５がＤＢ１０３へ登録するＩＰアドレス情報管理テーブルを示す図である。図５との差異は、ＩＰアドレスを取得するためのキー情報も保持している点である。本実施例では、ＩＰアドレスが変更された際に、アプリケーションサーバ１０９は、このＩＰアドレス取得キーを用いてＩＰアドレスを再取得する。

図１０は管理サーバ１０１のロードバランサＩＰアドレス登録処理の一例を示すフローチャートである。本フローチャートに示す処理は、新たに構築されたＧｒｅｅｎ環境のロードバランサのＩＰアドレスをＤＢに登録するために管理サーバ１０１により実行される。本フローチャートの処理は、ＣＰＵ２０１が、ＲＯＭ２０２やＲＡＭ２０３、ＨＤＤ２１２などに記録されたプログラムを読み出して実行することにより実現される。

図７と比較して、Ｓ７０４がＳ１００１と置き換わっている点で異なる。図７と同一の処理は、同一の符号を用いることで説明を省略する。

Ｓ１００１にて、ＩＰアドレス登録部３０５はＳ７０２およびＳ７０３で取得したＩＰアドレス取得キーおよびＩＰアドレスをＩＰアドレス情報管理テーブルとしてＤＢ１０３に登録する。

図１１はアプリケーションサーバ１０９のリクエスト転送処理の一例を示すフローチャートである。本フローチャートで示す処理は、Ｇｒｅｅｎ環境が構築された後の動作確認中に行われる処理である。本フローチャートの処理は、アプリケーションサーバ１０９のＣＰＵ２０１が、ＲＯＭ２０２やＲＡＭ２０３、ＨＤＤ２１２などに記録されたプログラムを読み出して実行することにより実現される。

図８と比較して、Ｓ１１０１〜Ｓ１１０５が追加されている点で異なる。図８と同一の処理は、同一の符号を用いることで説明を省略する。

Ｓ１１０１にて、リクエスト振り分け部４０４はＳ８０４で送信したリクエストが失敗しているかどうかを判定する。失敗していた場合、Ｓ１１０２へ進む。成功している場合、リクエスト転送処理を終了する。

Ｓ１１０２にてリクエスト振り分け部４０４はＳ８０３で取得したＩＰアドレス情報管理テーブルのデータ内に別のＩＰアドレスが存在するか判定する。存在する場合、Ｓ８０４へ進む。存在しない場合、Ｓ１１０３へ進む。

Ｓ１１０３にて、ＩＰアドレス情報管理部４０３はＤＢ１０３上で管理しているＩＰアドレス情報管理テーブル内のＩＰアドレス取得キーを取得する。

Ｓ１１０４にて、Ｓ１１０３で取得したＩＰアドレス取得キーを使ってロードバランサ１１１のＩＰアドレスを取得する。

Ｓ１１０５にて、Ｓ１１０３およびＳ１１０４で取得したＩＰアドレス取得キーおよびＩＰアドレスをＩＰアドレス情報管理テーブルとしてＤＢ１０３に登録する。

なお、Ｓ１１０３〜Ｓ１１０５は実施例中ではアプリケーションサーバ１０９が行っているが、管理サーバ１０１が行ってもよい。

以上説明したように、実施例２によれば、Ｇｒｅｅｎ環境のロードバランサのＩＰアドレスが変更されていてアクセスに失敗した場合に、ＩＰアドレスを再登録することで、動作確認者の作業効率を下げることなくＧｒｅｅｎ環境へのアクセスが可能となる。

（実施例３）
実施例１および実施例２では、アプリケーションサーバ１０９は、Ｇｒｅｅｎ環境での処理対象となるリクエストを受信するたびに、ＤＢに登録されているＩＰアドレスを取得していた。これに対して、本実施例では、アプリケーションサーバ１０９は、ＤＢから取得したＩＰアドレスを有効期限付きで保持するようにする。実施例３では、図１〜図４、図６、図９、図１０に示す構成が実施例２と同じであり、実施例２と同様の部分については同一の符号を用いてその説明を省略する。以下、実施例２と異なる点を主に説明する。

図１２はアプリケーションサーバ１０９で保持するＩＰアドレスキャッシュ情報の一例を示す図である。該キャッシュ情報はＩＰアドレス情報管理部４０３がＤＢ１０３から取得したＩＰアドレス情報管理テーブル内のＩＰアドレス情報に、有効期限を追加し格納される。図１２中で有効期限はｙｙｙｙｍｍｄｄ−ｈｈｍｍｓｓ形式で記載されている。

図１３はアプリケーションサーバ１０９のリクエスト転送処理の一例を示すフローチャートである。図１１と比較して、Ｓ１３０１〜Ｓ１３０２が追加されている点で異なる。図１１と同一の処理は、同一の符号を用いることで説明を省略する。

Ｓ１３０１にて、ＩＰアドレス情報管理部４０３がＩＰアドレスキャッシュ情報を保持しているか、かつ有効期限内かどうかを判定する。ＩＰアドレスキャッシュ情報を保持しているかつ有効期限内である場合、Ｓ８０４へ進む。該判定条件に当てはまらない場合、Ｓ８０３へ進む。

Ｓ１３０２にて、ＩＰアドレス情報管理部４０３がＳ８０３で取得したＩＰアドレス情報管理テーブル内のＩＰアドレスに有効期限を付与し、ＩＰアドレスキャッシュ情報を更新する。

実施例３によれば、アプリケーションサーバ１０９が、ＩＰアドレス情報をキャッシュすることで、ＩＰアドレス情報管理テーブルへのアクセスを減らすことができる。

（実施例４）
実施例２では、Ｇｒｅｅｎ環境のロードバランサのＩＰアドレスが変更されていてアクセスに失敗した際に、アプリケーションサーバ１０９がＩＰアドレスを再取得していた。これに対して、実施例４では、アプリケーションサーバ１０９が、任意のタイミングで定期的にＩＰアドレス取得キーを用いてＩＰアドレスを取得し、ＤＢに登録するようにする。実施例４は、図１〜図４、図６、図９、図１０、図１２、図１３に示す構成が実施例３と同じであり、実施例３と同様の部分については同一の符号を用いてその説明を省略する。以下、実施例３と異なる点を主に説明する。

図１４はアプリケーションサーバ１０９のＩＰアドレス取得ポーリング処理の一例を示すフローチャートである。本フローチャートに記載の処理はシステム管理者が設定した所定のスケジュールに従い実行される。

Ｓ１４０１にて、ＩＰアドレス情報管理部４０３がＤＢ１０３にＩＰアドレス情報管理テーブルがあるか判定する。判定の結果該テーブルが存在する場合、Ｓ１４０２へ進む。該データが存在しない場合、ＩＰアドレス取得ポーリング処理を終了する。

Ｓ１４０２にて、ＩＰアドレス情報管理部４０３はＤＢ１０３上で管理しているＩＰアドレス情報管理テーブル内のＩＰアドレス取得キーを取得する。

Ｓ１４０３にて、Ｓ１４０２で取得したＩＰアドレス取得キーを使ってロードバランサ１１１のＩＰアドレスを取得する。

Ｓ１４０４にて、Ｓ１４０２およびＳ１４０３で取得したＩＰアドレス取得キーおよびＩＰアドレスをＩＰアドレス情報管理テーブルとしてＤＢ１０３に登録する。

なお、本フローチャートの処理は、アプリケーションサーバ１０９により実行されるものとして説明したが、管理サーバ１０１によって実行されても良い。

以上説明したように、実施例４によれば、ポーリング処理によりＩＰアドレス管理テーブルのＩＰアドレスとロードバランサのＩＰアドレスが異なる時間を極力短くすることによって、ロードバランサのＩＰアドレス再取得処理の発生頻度を減らすことができる。

（実施例５）
実施例５では、アプリケーションサーバ１０９が、Ｇｒｅｅｎ環境のロードバランサのＩＰアドレスだけでなく、ＩＰアドレスの取得日時の情報と関連づけて登録するようにする。実施例５では、図１〜図４、図６、図１２に示す構成が実施例４と同じであり、実施例４と同様の部分については同一の符号を用いてその説明を省略する。以下、実施例４と異なる点を主に説明する。

図１５はＩＰアドレス登録部３０５がＤＢ１０３へ登録するＩＰアドレス情報管理テーブルを示す図である。図９との差異は、ロードバランサ１１１のＩＰアドレスを取得した日時も含んでいる点である。

図１６は管理サーバ１０１のロードバランサＩＰアドレス登録処理の一例を示すフローチャートである。図１０と比較して、Ｓ１００１がＳ１６０１と置き換わっている点で異なる。図１０と同一の処理は、同一の符号を用いることで説明を省略する。

Ｓ１６０１にて、ＩＰアドレス登録部３０５はＳ７０２およびＳ７０３で取得したＩＰアドレス取得キーおよびＩＰアドレスにＩＰアドレス取得日時を付与し、ＩＰアドレス情報管理テーブルとしてＤＢ１０３に登録する。

図１７はアプリケーションサーバ１０９のリクエスト転送処理の一例を示すフローチャートである。図１３と比較して、Ｓ１７０１が追加されている点およびＳ１１０５がＳ１７０２で置き換わっている点で異なる。図１３と同一の処理は、同一の符号を用いることで説明を省略する。

Ｓ１７０１にて、ＩＰアドレス情報管理部４０３がＤＢ１０３にすでに登録されているＩＰアドレス管理情報テーブル内のＩＰ取得日時よりも、これから登録しようとしているＩＰアドレス管理情報テーブルのＩＰ取得日時が新しいかを判定する。判定の結果、新しい場合はＳ１７０２へ進む。古い場合はＳ８０３へ進む。

Ｓ１７０２にて、ＩＰアドレス情報管理部４０３はＳ１１０３およびＳ１１０４で取得したＩＰアドレス取得キーおよびＩＰアドレスにＩＰアドレス取得日時を付与し、ＩＰアドレス情報管理テーブルとしてＤＢ１０３に登録する。

図１８はアプリケーションサーバ１０９のＩＰアドレス取得ポーリング処理の一例を示すフローチャートである。図１４と比較して、Ｓ１８０１が追加されている点およびＳ１４０４がＳ１８０２で置き換わっている点で異なる。図１４と同一の処理は、同一の符号を用いることで説明を省略する。

Ｓ１８０１にて、ＩＰアドレス登録部３０５は、ＤＢ１０３にすでに登録されているＩＰアドレス管理情報テーブル内のＩＰ取得日時に基づき、ＩＰアドレスを登録するか否かを決定する。ＩＰアドレス登録部３０５は、ＤＢ１０３にすでに登録されているＩＰアドレス管理情報テーブル内のＩＰ取得日時よりも、これから登録しようとしているＩＰアドレス管理情報テーブルのＩＰ取得日時が新しいかを判定する。判定の結果、新しい場合はＳ１４０４へ進む。古い場合はＩＰアドレス取得ポーリング処理を終了する。

Ｓ１８０２にて、ＩＰアドレス登録部３０５がＳ１４０２およびＳ１４０３で取得したＩＰアドレス取得キーおよびＩＰアドレスにＩＰアドレス取得日時を付与し、ＩＰアドレス情報管理テーブルとしてＤＢ１０３に登録する。

上記第５の実施形態によれば、古いロードバランサＩＰアドレス情報がＤＢへ登録されてしまうことを防ぐことができるため、アクセス失敗が発生する頻度を低減させ、動作確認者の作業効率を下げることなくＧｒｅｅｎ環境へのアクセスが可能となる。

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

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

１００情報処理システム
１０１管理サーバ
１０３ＤＢ
１０７Ｂｌｕｅ環境
１１０Ｇｒｅｅｎ環境
２０１ＣＰＵ

Claims

現行バージョンのアプリケーションが動作する第１の処理システムと、次バージョンのアプリケーションが動作する第２の処理システムと、管理サーバとを含むシステムであって、
前記管理サーバは、
前記第２の処理システムにアクセスするための情報を、前記システムのデータベースに登録する登録手段を有し、
前記第１の処理システムは、
外部装置からのリクエストを、前記第１の処理システムに含まれる負荷分散装置を介して受信する受信手段と、
前記受信したリクエストが前記第２の処理システムでの処理対象となるリクエストである場合、前記データベースに登録されている前記第２の処理システムにアクセスするための前記情報を用いて、前記受信したリクエストを前記第２の処理システムに対して送信する送信手段と、を有することを特徴とするシステム。
前記登録手段は、前記第２の処理システムにアクセスするための情報として、前記第２の処理システムに含まれる負荷分散装置のＩＰアドレスを前記データベースに登録することを特徴とする請求項１に記載のシステム。
前記外部装置からのリクエストは、前記システムのデータベースとは異なるＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバで管理される前記第１の処理システムに含まれる負荷分散装置に係るレコードに従い、前記第１の処理システムに含まれる負荷分散装置に送信されることを特徴とする請求項１または２に記載のシステム。
前記登録手段は、前記第２の処理システムにアクセスするための情報として、前記第２の処理システムに含まれる負荷分散装置のＩＰアドレス、および、前記第２の処理システムに含まれる負荷分散装置のＩＰアドレスを取得するためのキー情報を前記データベースに登録し、
前記第１の処理システムは、前記データベースに登録されている前記キー情報を用いてＩＰアドレスを取得する取得手段をさらに有し、
前記取得手段は、前記データベースに登録されている前記ＩＰアドレスの情報を用いて、前記受信したリクエストを前記第２の処理システムに対して送信できなかった場合、前記データベースに登録されている前記キー情報を用いてＩＰアドレスを取得し、当該取得したＩＰアドレスを前記データベースに登録し、
前記送信手段は、前記取得されたＩＰアドレスを用いて、前記受信したリクエストを前記第２の処理システムに対して送信することを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
前記第１の処理システムは、前記第２の処理システムにアクセスするための情報として、前記第２の処理システムに含まれる負荷分散装置のＩＰアドレスを有効期限付きで保持する保持手段をさらに有し、
前記送信手段は、前記保持されているＩＰアドレスが有効期限内である場合、前記保持されているＩＰアドレスを用いて、前記受信したリクエストを前記第２の処理システムに対して送信し、
前記保持手段は、前記保持されているＩＰアドレスが有効期限内でない場合、前記データベースに登録されているＩＰアドレスを取得し、当該取得したＩＰアドレスを保持し、
前記送信手段は、前記保持されているＩＰアドレスを用いて、前記受信したリクエストを前記第２の処理システムに対して送信することを特徴とする請求項４に記載のシステム。
前記取得手段は、所定のスケジュールに従い、前記データベースに登録されている前記キー情報を用いてＩＰアドレスを取得し、当該取得したＩＰアドレスを前記データベースに登録することを特徴とする請求項４または５に記載のシステム。
前記取得手段は、前記データベースに登録されている前記キー情報を用いてＩＰアドレスを取得し、当該取得したＩＰアドレスを取得日時の情報と関連づけて前記データベースに登録し、
前記取得手段は、前記取得したＩＰアドレスを前記データベースに登録する際に、前記データベースに登録されているＩＰアドレスと関連づく取得日時の情報に基づいて、前記取得したＩＰアドレスを前記データベースに登録するか否かを決定することを特徴とする請求項４乃至６のいずれか１項に記載のシステム。
前記第２の処理システムでの処理対象となるリクエストは、前記第２の処理システムの動作確認のためのリクエストであり、
前記第１の処理システムは、前記受信したリクエストが前記第２の処理システムでの処理対象となるリクエストであるかどうかを判定する判定手段をさらに有し、
前記判定手段は、前記受信したリクエストに所定の識別子が含まれる場合に、当該リクエストが前記第２の処理システムでの処理対象となるリクエストであると判定することを特徴とする請求項１乃至７のいずれか１項に記載のシステム。
現行バージョンのアプリケーションが動作する第１の処理システムと、次バージョンのアプリケーションが動作する第２の処理システムと、管理サーバとを含むシステムの制御方法であって、
前記管理サーバが、前記第２の処理システムにアクセスするための情報を、前記システムのデータベースに登録する登録工程を有し、
前記第１の処理システムが、外部装置からのリクエストを、前記第１の処理システムに含まれる負荷分散装置を介して受信する受信工程と、
前記第１の処理システムが、前記受信したリクエストが前記第２の処理システムでの処理対象となるリクエストである場合、前記データベースに登録されている前記第２の処理システムにアクセスするための前記情報を用いて、前記受信したリクエストを前記第２の処理システムに対して送信する送信工程と、を有することを特徴とする制御方法。