(57)【要約】【課題】  システム内に２つの処理環境が共存し、それぞれでリクエスト数を制限するための前述の上限値が設定される場合には、システム全体で、単位時間あたりにその上限値を超えるリクエストを受け付けてしまう可能性がある。【解決手段】  システムは、リクエストを受け付けて処理する処理環境を少なくとも２つ備え、前記処理環境のそれぞれでは単位時間あたりに処理可能なリクエストの数の制限を行い。システムは、リクエストを処理すべき処理環境についての設定である第１の設定を保持し、前記第１の設定に係る処理環境とは異なる処理環境が受け付けたリクエストを前記第１の設定に係る処理環境に転送する。前記第１の設定に係る処理環境では、前記制限に従い、前記転送されてきたリクエスト、及び、前記別の処理環境を経由せずに前記第１の設定に係る処理環境で受け付けたリクエストが、処理される。【選択図】  図８
2018190043.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置からのリクエストを受け付けて、該リクエストを処理する処理環境を少なくとも２つ備え、前記処理環境のそれぞれでは単位時間あたりに処理可能なリクエストの数の制限を行うシステムであって、
前記クライアント装置からのリクエストを処理すべき処理環境についての設定である第１の設定を保持する第１の保持手段と、
前記第１の設定に係る処理環境とは異なる別の処理環境が前記クライアント装置からのリクエストを受け付けた場合に、該リクエストを前記第１の設定に係る処理環境に転送する転送手段と、を有し、
前記第１の設定に係る処理環境では、前記制限に従い、前記転送手段により転送されてきたリクエスト、及び、前記別の処理環境を経由せずに前記第１の設定に係る処理環境で受け付けたリクエストが、処理されることを特徴とするシステム。
【請求項２】
前記クライアント装置からのリクエストが所定のリクエストであるか否かを判定する判定手段を更に有し、
前記第１の保持手段は、前記第１の設定として、前記所定のリクエストを処理すべき処理環境についての設定を保持し、
前記転送手段は、前記クライアント装置からのリクエストが前記所定のリクエストであると判定された場合に、前記クライアント装置からのリクエストを前記第１の設定に係る処理環境に転送することを特徴とする請求項１に記載のシステム。
【請求項３】
前記所定のリクエストは、当該リクエストを処理する際に、単位時間あたりのアクセス数の上限が定められている、前記システムとは異なる別の外部システムへのアクセスが必要となるリクエストであることを特徴とする請求項２に記載のシステム。
【請求項４】
前記処理環境のそれぞれは、前記クライアント装置からのリクエストを処理するフロント処理部と、該フロント処理部で処理された後のリクエストを処理するバック処理部とを少なくとも備え、
前記第１の保持手段は、前記第１の設定として、前記クライアント装置からリクエストを処理すべきバック処理部についての設定を保持し、
前記フロント処理部は前記転送手段を有し、該転送手段は、前記クライアント装置からのリクエストを前記第１の設定に係るバック処理部に転送することを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
【請求項５】
前記フロント処理部は、さらに前記クライアント装置からのリクエストが所定のリクエストであるか否かを判定する判定手段を有しており、
前記フロント処理部の有する前記転送手段は、
前記クライアント装置からのリクエストが前記所定のリクエストであると前記判定手段により判定された場合、前記クライアント装置からのリクエストを前記第１の設定に係るバック処理部に転送し、
前記クライアント装置からのリクエストが前記所定のリクエストでないと前記判定手段により判定された場合、前記クライアントからのリクエストを前記フロント処理部が含まれる処理環境が備えるバック処理部に転送することを特徴とする請求項４に記載のシステム。
【請求項６】
前記第１の設定に係るバック処理部とは異なる別のバック処理部に対して、いずれかのフロント処理部から前記クライアントからのリクエストが転送された場合、該別のバック処理部は、該転送されたリクエストを拒否することを特徴とする請求項４または５に記載のシステム。
【請求項７】
前記バック処理部は、さらに、リクエストを格納可能なキューと、該キューから取得したリクエストを処理可能な仮想マシンを備え、
前記第１の設定に係るバック処理部とは異なる別のバック処理部に含まれる、リクエストを処理可能な仮想マシンが、前記クライアントからのリクエストを取得した場合に、該仮想マシンは、前記第１の設定に係るバック処理部に含まれるキューに、該取得したリクエストを格納することを特徴とする請求項４乃至６のいずれか１項に記載のシステム。
【請求項８】
前記システムは、クライアント装置からのリクエストを処理可能な処理環境として、第１の処理環境と第２の処理環境とを備え、
前記クライアント装置からのリクエストを受け付ける負荷分散装置についての設定である第２の設定を保持する第２の保持手段を更に有し、
前記第２の設定に係る負荷分散装置が前記第２の処理環境の負荷分散装置に設定された際に、前記第１の設定に係る処理環境は前記第２の処理環境に設定されることを特徴とする請求項１乃至７のいずれか１項に記載のシステム。
【請求項９】
前記第１の処理環境および前記第２の処理環境のそれぞれは、前記クライアント装置からのリクエストを処理するフロント処理部と、該フロント処理部で処理された後のリクエストを処理するバック処理部とを少なくとも備え、
前記システムの記憶部には、前記第２の設定の変更に関するステータスフラグを記憶可能であり、
前記バック処理部は、前記記憶部に前記ステータスフラグが記憶されている場合に、前記第１の設定を確認することを特徴とする請求項８に記載のシステム。
【請求項１０】
前記システムは、前記第２の設定として、前記フロント処理部に含まれる負荷分散装置についての設定を保持し、
前記システムは、前記第１の設定として、前記バック処理部に含まれる負荷分散装置についての設定を保持することを特徴とする請求項９に記載のシステム。
【請求項１１】
前記第２の処理環境で動作するアプリケーションのバージョンは、前記第１の処理環境で動作するアプリケーションのバージョンよりも新しいことを特徴とする請求項８乃至１０のいずれか１項に記載のシステム。
【請求項１２】
クライアント装置からのリクエストを受け付けて、該リクエストを処理する処理環境を少なくとも２つ備え、前記処理環境のそれぞれでは単位時間あたりに処理可能なリクエストの数の制限を行うシステムの制御方法であって、
前記クライアント装置からのリクエストを処理すべき処理環境についての設定である第１の設定を保持する第１の保持工程と、
前記第１の設定に係る処理環境とは異なる別の処理環境が前記クライアント装置からのリクエストを受け付けた場合に、該リクエストを前記第１の設定に係る処理環境に転送する転送工程と、を有し、
前記第１の設定に係る処理環境では、前記制限に従い、前記転送工程で転送されてきたリクエスト、及び、前記別の処理環境を経由せずに前記第１の設定に係る処理環境で受け付けたリクエストが、処理されることを特徴とする制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、単位時間あたりに処理可能なリクエストの数を制限するシステム、および、その制御方法に関する。
【背景技術】
【０００２】
近年、アプリケーションや仮想マシン、ストレージなどのコンピュータリソースをユーザが必要なときに必要な分だけ利用できるクラウドサービスが増えてきた。このようなクラウドサービスは、ＳａａＳ、ＰａａＳ、ＩａａＳなどと呼ばれ、クラウドサービスベンダが提供するアプリケーションやコンピュータリソースをユーザが独自に組み合わせて使用することができる。ユーザはクラウド上にシステムを構築することで、自身がシステム管理者となり、そのシステムを用いてクライアントへサービスを提供することができる。
【０００３】
ここで、クラウドサービスを用いたシステムのバージョンを更新する方法の一つとして、ＢｌｕｅＧｒｅｅｎデプロイメントが利用されている。この技術によって、サービスの提供を停止することなくシステムを更新することができる。ＢｌｕｅＧｒｅｅｎデプロイメントでは、Ｂｌｕｅ環境（第１の処理環境）とＧｒｅｅｎ環境（第２の処理環境）とをシステム内に構築し、クライアントからのリクエストを受け付ける処理環境がＢｌｕｅ環境からＧｒｅｅｎ環境になるように設定を変更する。設定を変更する方法としては、システム管理者が管理するＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバのＤＮＳレコードが記載された設定ファイルを書き換えるという方法などがある。この方法の場合、クライアントは、ＤＮＳサーバに問い合わせることで取得したＤＮＳレコードを用いて、システム内に構築された処理環境にリクエストを送信することができる。
【０００４】
また、クラウドサービスを用いたシステムでは、外部システムとの連携やシステムのアーキテクチャ上の制約等の理由により、単位時間当たりに受け付け可能なリクエストの数（同時アクセス数）の上限を設定することがある。特許文献１は、クラウドサービスに関する文献ではないが、ユーザ端末からのアクセス要求の対象となるオブジェクト（ＨＴＭＬファイルなど）それぞれに対して同時にアクセス可能な上限を表す上限値を管理するウェブサーバについての開示がある。そのウェブサーバは、アクセス要求を受け付けた際にそのオブジェクトに対してアクセス中のサービス接続数が上限値に達している場合にはそのアクセス要求を拒否することで、オブジェクトに対するアクセス数を制限する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−３１０６５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したクラウドサービスを用いたシステムに対してリクエストを送信するクライアントは、ＤＮＳサーバに問い合わせることで取得したＤＮＳレコードのキャッシュを一定期間、保持することが一般的である。キャッシュの有効期限を超過していない場合、クライアントは、ＤＮＳレコードの問い合わせは実行せず、キャッシュとして保持しているＤＮＳレコードを用いてシステムに対してリクエストを送信する。そのため、上述したＢｌｕｅＧｒｅｅｎデプロイメントを実行する際に、ＤＮＳサーバが保持するＤＮＳレコードを更新後のある期間は、２つの処理環境どちらもが、クライアントからのリクエストを受け付ける可能性がある。
【０００７】
ここで、上述した特許文献１の技術を用いると、１オブジェクトとしての１つの処理環境で単位時間あたりに処理可能なリクエストの数の上限値を設けて、同時アクセス数を制限することはできる。しかしながら、システム内に２つの処理環境が共存し、それぞれでリクエスト数を制限するための前述の上限値が設定される場合には、システム全体で、単位時間あたりにその上限値を超えるリクエストを受け付けてしまう可能性がある。ここで、サービスの提供を停止させずにシステムのバージョンアップを実現するための技術であるＢｌｕｅＧｒｅｅｎデプロイメントの性質上、２つの処理環境それぞれには同様の上限値が設定されることが一般的である。
【０００８】
そこで、本発明は、システムが備える少なくとも２つの処理環境のそれぞれに対して前述の上限値が設定されてしまう場合であっても、当該システムにおいて、単位時間あたりに処理可能なリクエストの数を適切に制限することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明は、クライアント装置からのリクエストを受け付けて、該リクエストを処理する処理環境を少なくとも２つ備え、前記処理環境のそれぞれでは単位時間あたりに処理可能なリクエストの数の制限を行うシステムであって、前記クライアント装置からのリクエストを処理すべき処理環境についての設定である第１の設定を保持する第１の保持手段と、前記第１の設定に係る処理環境とは異なる別の処理環境が前記クライアント装置からのリクエストを受け付けた場合に、該リクエストを前記第１の設定に係る処理環境に転送する転送手段と、を有し、前記第１の設定に係る処理環境では、前記制限に従い、前記転送手段により転送されてきたリクエスト、及び、前記別の処理環境を経由せずに前記第１の設定に係る処理環境で受け付けたリクエストが、処理されることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、システムが備える少なくとも２つの処理環境のそれぞれに対して前述の上限値が設定されてしまう場合であっても、当該システムにおいて、単位時間あたりに処理可能なリクエストの数を適切に制限することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】システムの構成例を示す図である。
【図２】管理サーバ１０１の構成例を示す図である。
【図３】フロントサーバ１２２および１３２の構成例を示す図である。
【図４】バックサーバ１２４および１３４の構成例を示す図である。
【図５】同時アクセス数制御ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）管理テーブル５０１の一例を示す図である。
【図６】ＨＴＴＰリクエスト６０１の構成例を示す図である。
【図７】情報処理システム１００内で使用するＤＮＳの構成例を示す図である。
【図８】フロントサーバ１２２および１３２のリクエスト振り分け処理を示すフローチャートである。
【図９】管理サーバ１０１のＢｌｕｅＧｒｅｅｎデプロイメント処理を示すフローチャートである。
【図１０】リクエスト受入判断部をさらに含むバックサーバ１２４および１３４の構成例を示す図である。
【図１１】ＨＴＴＰレスポンスの構成例を示す図である。
【図１２】バックサーバ１２４および１３４のリクエスト受入判断処理を示すフローチャートである。
【図１３】キュー１３０１および１３１１、バックサーバ１４０１および１４１１、バッチサーバ１５０１および１５１１をさらに含むシステムの構成例を示す図である。
【図１４】同時アクセス数制御部を含まないバックサーバ１４０１および１４１１の構成例を示す図である。
【図１５】バッチサーバ１５０１および１５１１の構成例を示す図である。
【図１６】バッチサーバ１５０１および１５１１のリクエスト受入判断処理を示すフローチャートである。
【図１７】ＢｌｕｅＧｒｅｅｎフラグ１７０１の構成例を示す図である。
【図１８】バックサーバ１４０１および１４１１のリクエスト受入判断処理を示すフローチャートである。
【図１９】ハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１３】
（実施例１）
図１は、本発明の実施形態に係るネットワークシステムの構成例を示す図である。情報処理システム１００は、クライアントコンピュータ１１１からの要求を受け付けて処理をする機能を提供するクラウドサービスである。本実施例の情報処理システムは、ＩａａＳやＰａａＳなどのクラウドサービスによって提供されるプラットフォームやリソースを利用して構築され、クライアントに対してサービスを提供するシステムである。
【００１４】
クライアントコンピュータ１１１は、クライアント装置であり、ユーザが操作するＰＣや、ユーザにサービスを提供するアプリケーションサーバ等が想定される。クライアントコンピュータ１１１は、ネットワーク１１３を経由して情報処理システム１００に接続される。なお、システムとクライアントコンピュータ１１１との間に存在するネットワーク上の中継機器（不図示）が、システムに対してリクエストを送ってもよい。システム管理者コンピュータ１１０は、システム管理者による情報処理システム１００を運用するための各種指示を管理サーバ１０１に実行させる。システム管理者コンピュータ１１０は、ネットワーク１１２を経由して管理サーバ１０１に接続する。
【００１５】
情報処理システム１００は、内部ＤＮＳサーバ１０３、ＤＢ（データベース）１０４、現行バージョンの処理環境であるＢｌｕｅ環境１２０を含む。情報処理システム１００は、ＢｌｕｅＧｒｅｅｎデプロイメントを実行する際には、次バージョンの処理環境であるＧｒｅｅｎ環境１３０をさらに含む。また、情報処理システム１００は、ＤＮＳサーバ１０２にアクセス可能である。本実施例におけるシステムには、情報処理システム１００およびＤＮＳサーバ１０２が含まれるものとする。
【００１６】
ＤＮＳサーバ１０２は、クライアントコンピュータ１１１が情報処理システム１００にアクセスする際に参照するＤＮＳレコードおよびクラウドベンダーが提供する各ロードバランサを表すＤＮＳレコードを管理する。内部ＤＮＳサーバ１０３は、本実施例で使用する振り分け用ＤＮＳレコードを管理する。ＤＢ１０４には、サービスを提供するための各種データ等や、実施例４で後述するステータスフラグなどを記憶可能である。
【００１７】
Ｂｌｕｅ環境１２０は、フロントロードバランサ１２１、フロントサーバ１２２、バックロードバランサ１２３、およびバックサーバ１２４を含む。フロントロードバランサ１２１は、クライアントコンピュータ１１１からのリクエストを受け付けて、フロントサーバ１２２に対して転送する負荷分散装置である。ここで、フロントロードバランサ１２１とフロントサーバ１２２とを、Ｂｌｕｅ環境１２０のフロント処理部と呼ぶ。バックロードバランサ１２３は、フロントサーバ１２２または１３２から転送されたリクエストをバックサーバ１２４に対して転送する負荷分散装置である。ここで、バックロードバランサ１２３とバックサーバ１２４とを、Ｂｌｕｅ環境１２０のバック処理部と呼ぶ。
【００１８】
Ｂｌｕｅ環境１２０と同様に、Ｇｒｅｅｎ環境１３０は、フロントロードバランサ１３１、フロントサーバ１３２、バックロードバランサ１３３、およびバックサーバ１３４を含む。フロントロードバランサ１３１は、クライアントコンピュータ１１１からのリクエストを受け付けて、フロントサーバ１３２に対して転送する負荷分散装置である。ここで、フロントロードバランサ１３１とフロントサーバ１３２とを、Ｇｒｅｅｎ環境１３０のフロント処理部と呼ぶ。バックロードバランサ１３３は、フロントサーバ１３２または１２２から転送されたリクエストをバックサーバ１３４に対して転送する負荷分散装置である。ここで、バックロードバランサ１３３とバックサーバ１３４とを、Ｇｒｅｅｎ環境１３０のバック処理部と呼ぶ。
【００１９】
なお、Ｂｌｕｅ環境１２０およびＧｒｅｅｎ環境１３０はそれぞれ独立しているため、別途記載がない限り、通常はＢｌｕｅ環境１２０およびＧｒｅｅｎ環境１３０を横断したリクエストの送受信は発生しない。つまり、各ロードバランサは同一環境内の各サーバに対してリクエストの転送を行い、また、各サーバは同一環境内の各ロードバランサに対してリクエストの転送を行う。
【００２０】
また、フロントサーバやバックサーバなどは、クラウドサービスベンダによって提供されるリソースとしての仮想マシンで構成される。ここで、仮想マシンとは、仮想化技術によって、サーバを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピュータである。また、ＤＮＳサーバやロードバランサなども、クラウドサービスベンダによって提供される。
【００２１】
なお、Ｂｌｕｅ環境１２０またはＧｒｅｅｎ環境１３０のどちらにクライアントコンピュータ１１１がリクエストを送信するかの制御は、図７を用いて後述する、クライアントコンピュータ１１１が参照するＤＮＳレコードを更新することによって実現する。
【００２２】
バックサーバ１２４および１３４は、転送されたリクエストを処理した後、外部連携システム１９０にそのリクエストを送信する。また、バックサーバ１２４および１３４はそれぞれ、単位時間あたりに処理可能なリクエストの数（同時アクセス数）を制限している。特に、バックサーバ１２４および１３４はそれぞれ、転送されたリクエストのうち、外部連携システム１９０へのアクセスを必要とするリクエストの数を制限している。
【００２３】
外部連携システム１９０は、情報処理システム１００からのリクエストを受けて処理を実行する外部システムである。この外部連携システム１９０が同時に処理可能なアクセス数には上限があり、上限を超えた場合には外部連携システム１９０の可用性が低下する場合がある。また、その影響を受けて情報処理システム１００も可用性が低下する場合がある。そのため、情報処理システム１００から外部連携システム１９０への同時アクセス数が上限を超えることがないよう制御する必要がある。
【００２４】
図１９は、ハードウェア構成例を示す図である。フロントサーバ１２２および１３２、バックサーバ１２４および１３４、管理サーバ１０１を構成するサーバのハードウェア構成を示す。この構成は、サーバ全体を制御する中央演算処理装置（ＣＰＵ）１９１１、処理中の情報を一時的に記憶する主記憶装置（ＲＡＭ）１９１２、実行するプログラムを備える補助記憶装置（ＨＤＤ）１９１３を備える。また、情報処理システム１００内の他の機器と接続するためのネットワークインタフェース１９１４、上記１９１１から１９１４の各構成要素を接続するシステムバス１９１５を備える。
【００２５】
ＣＰＵ１９１１は、システムバス１９１５を介してＲＡＭ１９１２、ＨＤＤ１９１３、ネットワークインタフェース１９１４に接続されている。当該サーバは、ＣＰＵ１９１１がＨＤＤ１９１３に格納されているプログラムを実行することで、所定の機能を提供する。
【００２６】
図２は、管理サーバ１０１の構成例を示す図である。管理サーバ１０１は、システム管理者がシステム管理者コンピュータ１１０を通じてリクエストした処理を実行する。管理サーバ１０１は、環境構築部２０１、環境削除部２０２、ＤＮＳ更新部２０３を含む。
【００２７】
環境構築部２０１は、次バージョン環境であるＧｒｅｅｎ環境１３０を構築する。構築の際はクラウドベンダーが提供するＡＰＩを実行することで、Ｇｒｅｅｎ環境１３０の各構成要素を作成する。
【００２８】
環境削除部２０２は、ＢｌｕｅＧｒｅｅｎデプロイメントによって旧バージョン環境となったＢｌｕｅ環境１２０を削除する。削除の際はクラウドベンダーが提供するＡＰＩを実行することで、Ｂｌｕｅ環境１２０の各構成要素を削除する。
【００２９】
ＤＮＳ更新部２０３は、ＤＮＳサーバ１０２および内部ＤＮＳサーバ１０３が管理するＤＮＳレコードを更新する。なお、更新処理については後述する。
【００３０】
図３は、フロントサーバ１２２および１３２の構成例を示す図である。フロントサーバ１２２および１３２は、それぞれフロントロードバランサ１２１および１３１から転送されたリクエストを処理する。フロントサーバ１２２および１３２は、リクエスト判断部３０１、リクエスト振り分け部３０２を含む。
【００３１】
リクエスト判断部３０１は、受信したリクエストの内容から外部連携システム１９０への同時アクセス数を制御するリクエストかどうかを判断する。なお、判断方法については後述する。
【００３２】
リクエスト振り分け部３０２は、リクエスト判断部３０１の判断結果に従って、Ｂｌｕｅ環境１２０のバックロードバランサ１２３、もしくはＧｒｅｅｎ環境１３０のバックロードバランサ１３３のどちらかにリクエストを送信する。この際、Ｂｌｕｅ環境１２０およびＧｒｅｅｎ環境１３０を横断したリクエストが発生する場合がある。なお、フロントロードバランサ１２１または１３１が、同一環境のバックロードバランサにリクエストを振り分けるか、異なる環境のロードバランサにリクエストを振り分けるかの判定方法は後述する。
【００３３】
図４は、バックサーバ１２４および１３４の構成例を示す図である。バックサーバ１２４および１３４は、バックロードバランサ１２３およびバックロードバランサ１３３から転送されたリクエストを処理する。バックサーバ１２４および１３４は、同時アクセス数制御部４０１を含む。
【００３４】
同時アクセス数制御部４０１は、外部連携システム１９０に対する同時アクセス数の制御を行う。同時アクセス数制御部４０１は、外部連携システム１９０に対する同時アクセス数の上限数を表す同時アクセス上限数と、外部連携システム１９０に対して実行中のリクエスト数を表す同時アクセス数を持つ。外部連携システム１９０に対してリクエストを実行すると、同時アクセス数の値を１増やし、当該リクエストが完了すると、同時アクセス数の値を１減らす。また、バックロードバランサ１２３およびバックロードバランサ１３３から外部連携システム１９０に対するリクエストが転送された際に、同時アクセス数が同時アクセス上限数より小さくない場合は、当該リクエストを受け付けない。
【００３５】
図５は、同時アクセス数制御ＡＰＩ管理テーブル５０１の一例を示す図である。当該テーブルはフロントサーバ１２２およびフロントサーバ１３２によって保持される。当該テーブルには、同時アクセス数の制御が必要な同時アクセス数制御ＡＰＩが保持される。なお、同時アクセス数制御部４０１が保持する同時アクセス上限数は、同時アクセス数制御ＡＰＩ管理テーブル５０１に記載のＡＰＩ全体に対するものであり、ＡＰＩごとの同時アクセス数上限ではない。
【００３６】
図６は、ＨＴＴＰリクエスト６０１の構成例を示す図である。ＨＴＴＰリクエスト６０１には、ＨＴＴＰリクエストパス６１１が含まれる。
【００３７】
リクエスト判断部３０１は、ＨＴＴＰリクエストパス６１１が、同時アクセス数制御ＡＰＩ管理テーブル５０１に含まれる同時アクセス数制御ＡＰＩの何れかと前方一致する場合に、同時アクセス数の制御対象となるリクエストであると判断する。
【００３８】
図７は、情報処理システム１００で使用するＤＮＳの構成例を示す図である。レコード７１１から７１５はＤＮＳサーバ１０２が管理し、レコード７１６は内部ＤＮＳサーバ１０３が管理する。ＤＮＳサーバ１０２は、クライアントコンピュータ１１１からのリクエストを受け付けるロードバランサについて設定を保持する。内部ＤＮＳサーバ１０３は、同時アクセス数の制御対象となるリクエストを処理すべき処理環境についての設定を保持する。
【００３９】
レコード７１１は、クライアントコンピュータ１１１が情報処理システム１００にアクセスする際に使用するＤＮＳレコードを表し、フロントロードバランサ１２１または１３１のＤＮＳのＨｏｓｔをＣｏｎｔｅｎｔとして持つ。レコード７１１のＣｏｎｔｅｎｔを更新することによって、Ｂｌｕｅ環境１２０またはＧｒｅｅｎ環境１３０のどちらにクライアントコンピュータ１１１からのリクエストが送信されるかを制御することが可能である。レコード７１２は、フロントロードバランサ１２１のＤＮＳレコードを表す。レコード７１３は、フロントロードバランサ１３１のＤＮＳレコードを表す。レコード７１４は、バックロードバランサ１２３のＤＮＳレコードを表す。レコード７１５は、バックロードバランサ１３３のＤＮＳレコードを表す。なお、レコード７１２から７１５のＨｏｓｔに含まれる８桁の数値はＢｌｕｅ環境１２０またはＧｒｅｅｎ環境１３０のバージョンを示す。
【００４０】
レコード７１６は、リクエスト振り分け部３０２が使用する振り分け用ＤＮＳレコードを表し、レコード７１４または７１５のＨｏｓｔをＣｏｎｔｅｎｔとして持つ。同時アクセス数の制御対象となるリクエストは、レコード７１６で設定されたバック処理部に転送されることになり、そのバック処理部にて、単位時間当たりに処理可能なリクエストの数を制限することができる。より具体的には、レコード７１６で指定されるバック処理部が含まれる処理環境は、別の処理環境から転送されてきたリクエストと、別の処理環境を経由せずにレコード７１６で指定されるバック処理部が含まれる処理環境で受け付けたリクエストとを、処理する。つまり、Ｂｌｕｅ環境１２０とＧｒｅｅｎ環境１３０が共存している期間においても、いずれかの処理環境のバック処理部のみで制限することができる。特に、Ｂｌｕｅ環境１２０の方がＧｒｅｅｎ環境１３０よりも先に削除されることとなるため、同時アクセス数の制御対象となるリクエストを処理すべき処理環境としてＧｒｅｅｎ環境１３０を設定することが望ましい。さらには、ＤＮＳサーバ１０２で保持される設定で示される本番環境が、Ｂｌｕｅ環境からＧｒｅｅｎ環境に切り替えられる前は内部ＤＮＳサーバ１０３ではＢｌｕｅ環境１２０を設定し、切り替えられた後はＧｒｅｅｎ環境１３０を設定することが望ましい。このようにすることで、外部連携システム１９０などに対するアクセス数を制限することができる。
【００４１】
図８は、フロントサーバ１２２および１３２のリクエスト振り分け処理を示すフローチャートである。フロントサーバ１２２および１３２は、フロントロードバランサ１２１または１３１から転送された、クライアントコンピュータ１１１からのリクエストを受け付けて、リクエスト振り分け処理を実行する。
【００４２】
Ｓ８０２では、リクエスト判断部３０１が同時アクセス数を制御するリクエストであると判断した場合はＳ８０３を実行し、そうでない場合はＳ８０４を実行する。Ｓ８０３では、リクエスト振り分け部３０２がリクエストの送信先として振り分け用ＤＮＳレコード（レコード７１６）を指定する。Ｓ８０４では、リクエスト振り分け部３０２は、リクエストの送信先として、当該処理を実行しているのがフロントサーバ１２２であればレコード７１４を、フロントサーバ１３２であればレコード７１５を指定する。Ｓ８０５では、リクエスト振り分け部３０２は、フロントサーバ１２２およびフロントサーバ１３２が保持する、Ｓ８０３またはＳ８０４で指定したＤＮＳのキャッシュを使用してリクエストを転送する。当該キャッシュの有効期限を過ぎている場合は、リクエスト振り分け部３０２は、内部ＤＮＳサーバ１０３に当該ＤＮＳの問い合わせを行う。そして、リクエスト振り分け部３０２は、問い合わせ結果をキャッシュし、当該結果を使用してリクエストを送信する。
【００４３】
振り分け用ＤＮＳのＣｏｎｔｅｎｔがバックロードバランサ１３３のＤＮＳレコードとなっている場合の例を示す。フロントロードバランサ１２１が受信した同時アクセス数制御ＡＰＩのリクエストは、バックサーバ１３４が処理する。フロントロードバランサ１２１が受信した同時アクセス数制御ＡＰＩ以外のリクエストは、バックサーバ１２４が処理する。フロントロードバランサ１３１が受信した同時アクセス数制御ＡＰＩのリクエストは、バックサーバ１３４が処理する。フロントロードバランサ１２１が受信した同時アクセス数制御ＡＰＩ以外のリクエストは、バックサーバ１３４が処理する。なお、同時アクセス数制御ＡＰＩに限定することで、実装および評価において生じる手間やコストを低減させることができる、
図９は、管理サーバ１０１のＢｌｕｅＧｒｅｅｎデプロイメント処理を示すフローチャートである。管理サーバ１０１は、システム管理者からの指示を受けてＢｌｕｅＧｒｅｅｎデプロイメント処理を開始する。
【００４４】
Ｓ９０２では、管理サーバ１０１は次バージョン環境（Ｇｒｅｅｎ環境１３０）を構築する。Ｓ９０３では、管理サーバ１０１は振り分け用ＤＮＳレコード７１６のＣｏｎｔｅｎｔを、レコード７１４のＨｏｓｔからレコード７１５のＨｏｓｔに更新する。この処理により、同時アクセス数制御ＡＰＩのリクエストを処理すべきバック処理部が、Ｂｌｕｅ環境１２０のバック処理部からＧｒｅｅｎ環境１３０のバック処理部に設定変更される。Ｓ９０４では、外部公開ＤＮＳ（レコード７１１）のＣｏｎｔｅｎｔを、レコード７１２のＨｏｓｔからレコード７１３のＨｏｓｔに更新する。この処理により、クライアントコンピュータ１１１からのリクエストを受け付けるロードバランサが、Ｂｌｕｅ環境１２０のフロントロードバランサ１２１からＧｒｅｅｎ環境１３０のフロントロードバランサ１３１に設定変更される。Ｓ９０５では、クライアントコンピュータ１１１からＢｌｕｅ環境１２０へのリクエストがなくなるまで待機したのち、Ｂｌｕｅ環境１２０を削除する。なお、Ｓ９０３とＳ９０４は同時でもよいし、Ｓ９０４の直後にＳ９０３が行われてもよい。
【００４５】
上記で示すように、振り分け用ＤＮＳを用いることで同時アクセス数制御ＡＰＩに対するリクエストを一方の処理環境の同時アクセス数制御部４０１に集約させる仕組みを設ける。これにより、ＢｌｕｅＧｒｅｅｎデプロイメントによって同時に２つの処理環境が稼働している状況においても、同時アクセス数制御部４０１によって適切に同時アクセス数を制御することが可能となる。
【００４６】
（実施例２）
フロントサーバ１２２および１３２は、内部ＤＮＳサーバ１０３やネットワークへの負荷を軽減するために、ＤＮＳ問い合わせ結果をキャッシュとして一定期間保持する。そのため、振り分け用ＤＮＳを更新してからキャッシュの有効期限を過ぎるまでの間、フロントサーバ１２２および１３２はキャッシュを利用してバックロードバランサ１２３または１３３にリクエストを送信する。これによって、Ｂｌｕｅ環境１２０およびＧｒｅｅｎ環境１３０の両処理環境の同時アクセス数制御部４０１がリクエストを処理することとなり、規定のアクセスの上限数を超えてしまうおそれがある。
【００４７】
そこで、本実施例では、フロントサーバだけでなく、バックサーバも、リクエストの受入の許否を判断するようにする。本実施例のバックサーバ１２４および１３４が、振り分け用ＤＮＳのＣｏｎｔｅｎｔに応じてリクエストの受入の許否を判断することで前述の課題を解決する手法について記述する。
【００４８】
本実施例では、図１０、図１１、および図１２を用いて実施例１との差異を中心に記述する。
【００４９】
図１０は、実施例２におけるバックサーバ１２４および１３４の構成例を示す図である。実施例２におけるバックサーバ１２４および１３４はそれぞれ、同時アクセス数制御部４０１に加え、リクエスト判断部３０１およびリクエスト受入判断部１０２１をさらに含む。
【００５０】
リクエスト受入判断部１０２１は、受信した同時アクセス数制御ＡＰＩに対するリクエストがＢｌｕｅ環境１２０またはＧｒｅｅｎ環境１３０のどちらで処理すべきリクエストであるか判断する。リクエスト受入判断部１０２１は、同時アクセス数制御ＡＰＩに対するリクエストを受信すると、内部ＤＮＳサーバ１０３に振り分け用ＤＮＳのＣｏｎｔｅｎｔを問い合わせる。Ｃｏｎｔｅｎｔの値に自身が所属する環境のバージョンと同じ数値が含まれている場合、このまま処理すべきリクエストと判断し、そうでない場合、もう一方の環境が処理すべきリクエストと判断する。
【００５１】
図１１は、ＨＴＴＰレスポンス１１０１の構成例を示す図である。リクエスト受入判断部１０２１がもう一方の環境が処理すべきリクエストと判断した場合、バックサーバ１２４および１３４は、リクエストを拒否し、フロントサーバ１２２および１３２にＨＴＴＰレスポンス１１０１を返す。フロントサーバ１２２および１３２は、ＨＴＴＰレスポンス１１０１を受け取ると、レスポンス中のＬｏｃａｔｉｏｎヘッダ１１１０に記載されたリダイレクト先を指定してリクエストを再送する。例えば、図１１の場合、Ｌｏｃａｔｉｏｎヘッダ１１１０の値が図７のレコード７１５のＣｏｎｔｅｎｔと同じため、バックロードバランサ１３３がリクエストの再送先であると判断する。
【００５２】
図１２は、バックサーバ１２４および１３４のリクエスト受入判断処理を示すフローチャートである。バックサーバ１２４および１３４は、リクエストを受信するとリクエスト受入判断処理を開始する。
【００５３】
Ｓ１２０２では、リクエスト判断部３０１が同時アクセス数を制御するリクエストであると判断した場合はＳ１２０３を実行し、そうでない場合はＳ１２０５を実行する。Ｓ１２０３では、リクエスト受入判断部１０２１は内部ＤＮＳサーバ１０３に振り分け用ＤＮＳのＣｏｎｔｅｎｔについて問い合わせを実行する。Ｓ１２０４では、問い合わせたＣｏｎｔｅｎｔの値に従ってこのまま処理すべきと判断した場合は、Ｓ１２０５を実行し、そうでない場合は、Ｓ１２０６を実行する。Ｓ１２０５では、受信したリクエストを処理する。リクエストを処理する際は、同時アクセス数制御部４０１によって、同時アクセス数の制御を実施する。Ｓ１２０６では、ＨＴＴＰレスポンス１１０１のＬｏｃａｔｉｏｎヘッダ１１１０に取得したＣｏｎｔｅｎｔを記載して、フロントサーバ１２２または１３２に返す。
【００５４】
上記で示すように、同時アクセス数制御ＡＰＩに対するリクエストを受信した際に、内部ＤＮＳサーバ１０３に問い合わせを行い、振り分け用ＤＮＳの向き先を確認する処理を設ける。これにより、フロントサーバ１２２および１３２がキャッシュを使用して誤った環境にリクエストを送信した場合でも、一方の環境の同時アクセス数制御部４０１にリクエストを集約させ、適切に同時アクセス数を制御することが可能となる。
【００５５】
（実施例３）
情報処理システム１００は、同時アクセス数制御ＡＰＩへのリクエストをキューイングして管理してもよい。
【００５６】
同時アクセス数制御ＡＰＩへのリクエストをキューイングして管理する場合、ＢｌｕｅＧｒｅｅｎデプロイメントによって環境が切り替わったのちに、Ｂｌｕｅ環境１２０のキューに残っていたリクエストが処理される場合がある。これによって、Ｂｌｕｅ環境１２０およびＧｒｅｅｎ環境１３０の両環境の同時アクセス数制御部４０１がリクエストを処理することとなり、規定のアクセスの上限数を超えてしまうおそれがある。
【００５７】
そこで、本実施例では、キュー１３０１または１３１１からリクエストを取得したバッチサーバ１５０１および１５１１が、振り分け用ＤＮＳのＣｏｎｔｅｎｔに応じてリクエストの受入の許否を判断することで前述の課題を解決する手法について記述する。
【００５８】
本実施例では、図１３、図１４、図１５および図１６を用いて既述の実施例との差異を中心に記述する。
【００５９】
図１３は、キュー１３０１および１３１１、バックサーバ１４０１および１４１１、バッチサーバ１５０１および１５１１をさらに含むネットワークシステムの構成例を示す図である。キューは、クラウドベンダーによって提供される。
【００６０】
バックサーバ１４０１は、リクエストを処理したのち、そのリクエストをキュー１３０１に格納する。キュー１３０１は、リクエストを格納可能である。バッチサーバ１５０１は、キュー１３０１からリクエストを取得し、受け取ったリクエストを処理し、外部連携システム１９０にリクエストを送る。また、バッチサーバ１５０１は、外部連携システム１９０への同時アクセス数を制御する。なお、本実施例でのＢｌｕｅ環境１２０におけるバック処理部には、バックロードバランサ１２３およびバックサーバ１４０１だけでなく、さらにキュー１３０１およびバッチサーバ１５０１が含まれる。
【００６１】
バックサーバ１４１１は、リクエストを処理したのち、そのリクエストをキュー１３１１に格納する。キュー１３１１は、リクエストを格納可能である。バッチサーバ１５１１は、キュー１３１１からリクエストを取得し、受け取ったリクエストを処理し、外部連携システム１９０にリクエストを送る。また、バッチサーバ１５１１は、外部連携システム１９０への同時アクセス数を制御する。なお、本実施例でのＧｒｅｅｎ環境１３０におけるバック処理部には、バックロードバランサ１３３およびバックサーバ１４１１だけでなく、さらにキュー１３１１およびバッチサーバ１５１１が含まれる。
【００６２】
図１４は、同時アクセス数制御部を含まないバックサーバ１４０１および１４１１の構成例を示す図である。実施例２と比較して、同時アクセス数制御はバッチサーバ１５０１および１５１１が実施するため、同時アクセス数制御部４０１を持たない。
【００６３】
リクエスト判断部３０１およびリクエスト受入判断部１０２１の動作については既述の実施例と同様である。なお、バックサーバ１４０１および１４１１は、処理を実行したのち、同時アクセス数を制御するリクエストである場合には、キュー１３０１または１３１１にリクエストをキューイングする。
【００６４】
図１５は、バッチサーバ１５０１および１５１１の構成例を示す図である。リクエスト取得部１５１０およびリクエスト受入判断部１０２１を含む。
【００６５】
リクエスト取得部１５１０は、キュー１３０１および１３１１からリクエストを取得する。リクエストの取得は並列処理によって実行される。この並列処理の並列実行数によって、外部連携システム１９０への同時アクセス数を制御する。
【００６６】
リクエスト受入判断部１０２１の動作については既述の実施例と同様である。
【００６７】
図１６は、バッチサーバ１５０１および１５１１のリクエスト受入判断処理を示すフローチャートである。バッチサーバ１５０１および１５１１は、リクエスト取得部１５１０がリクエストを取得すると、リクエスト受入判断処理を開始する。
【００６８】
Ｓ１６０２では、リクエスト受入判断部１０２１は内部ＤＮＳサーバ１０３に振り分け用ＤＮＳのＣｏｎｔｅｎｔについて問い合わせを実行する。Ｓ１６０３では、問い合わせたＣｏｎｔｅｎｔの値に従ってこのまま処理すべきと判断した場合は、Ｓ１６０４を実行し、そうでない場合は、Ｓ１６０５を実行する。Ｓ１６０４では、取得したリクエストを処理する。Ｓ１６０５では、取得したＣｏｎｔｅｎｔに含まれるバージョンを示す数値から、もう一方の環境のキュー１３０１または１３１１を特定し、リクエスト受入判断部１０２１が、取得したリクエストを当該キューにキューイングする。この際、Ｂｌｕｅ環境１２０およびＧｒｅｅｎ環境１３０を横断したキューイングが発生する場合がある。
【００６９】
上記で示すように、バッチサーバ１５０１および１５１１が同時アクセス数制御ＡＰＩに対するリクエストを取得した際に、内部ＤＮＳサーバ１０３に問い合わせを行い、振り分け用ＤＮＳの向き先を確認する処理を設ける。Ｂｌｕｅ環境１２０にリクエストがキューイングされている状態でＢｌｕｅＧｒｅｅｎデプロイメントが実際された場合でも、キュー１３０１または１３１１にリクエストを集約させ、適切に同時アクセス数を制御することが可能となる。
【００７０】
（実施例４）
リクエスト受入判断部１０２１は、ＢｌｕｅＧｒｅｅｎデプロイメント実行時にのみ内部ＤＮＳサーバ１０３に振り分け用ＤＮＳのＣｏｎｔｅｎｔの問い合わせを実行してもよい。
【００７１】
実施例２においては、同時アクセス数制御ＡＰＩに対するリクエストを受信するごとに、内部ＤＮＳサーバ１０３への問い合わせが発生する。内部ＤＮＳサーバ１０３への高頻度な問い合わせは、内部ＤＮＳサーバ１０３や情報処理システム１００を構成するネットワークの負荷を高める。高負荷に耐えられる内部ＤＮＳサーバ１０３やネットワークを構築するとコストが高くなるという課題が発生する。そのため、内部ＤＮＳサーバ１０３への問い合わせは必要最小限に抑えることが望ましい。
【００７２】
そこで、本実施例では、リクエスト受入判断部１０２１が、ＢｌｕｅＧｒｅｅｎデプロイメントが実行中か否かに応じて内部ＤＮＳサーバ１０３への問い合わせ処理の有無を判断することで、前述の課題を解決する手法について記述する。
【００７３】
本実施例では、図１７および図１８を用いて実施例２との差異を中心に記述する。
【００７４】
図１７は、ＢｌｕｅＧｒｅｅｎフラグ１７０１の構成例を示す図である。ＢｌｕｅＧｒｅｅｎフラグ１７０１は、記憶部として機能するＤＢ１０４で記憶されるステータスフラグであり、管理サーバ１０１によってその値が更新される。
【００７５】
ＢｌｕｅＧｒｅｅｎフラグ１７０１は、図９のＳ９０３を実行する１０分前に値を「ｔｒｕｅ」に更新され、Ｓ９０５の実行から１０分後に値を「ｆａｌｓｅ」に更新される。「ｔｒｕｅ」はＢｌｕｅＧｒｅｅｎデプロイメントが実行中であることを示し、「ｆａｌｓｅ」はＢｌｕｅＧｒｅｅｎデプロイメントが実行中ではないことを示す。
【００７６】
バックサーバ１４０１および１４１１は、５分間隔でＤＢ１０４からＢｌｕｅＧｒｅｅｎフラグ１７０１の値を取得し、その値を当該サーバ内にキャッシュする。キャッシュした値を、ＢｌｕｅＧｒｅｅｎフラグキャッシュと呼ぶこととする。
【００７７】
図１８は、バックサーバ１４０１および１４１１のリクエスト受入判断処理を示すフローチャートである。バックサーバ１４０１および１４１１は、リクエストを受信するとリクエスト受入判断処理開始する。
【００７８】
Ｓ１８０２では、リクエスト判断部３０１が同時アクセス数を制御するリクエストであると判断した場合はＳ１８０３を実行し、そうでない場合はＳ１８０６を実行する。Ｓ１８０３では、ＢｌｕｅＧｒｅｅｎフラグキャッシュを参照し、ＢｌｕｅＧｒｅｅｎデプロイメントが実行中であれば、Ｓ１８０４を実行し、そうでない場合、Ｓ１８０６を実行する。Ｓ１８０４では、内部ＤＮＳサーバ１０３に振り分け用ＤＮＳのＣｏｎｔｅｎｔについて問い合わせを実行する。Ｓ１８０５では、問い合わせたＣｏｎｔｅｎｔの値に従ってこのまま処理すべきと判断した場合は、Ｓ１８０６を実行し、そうでない場合は、Ｓ１８０７を実行する。Ｓ１８０６では、受信したリクエストを処理する。リクエストを処理する際は、同時アクセス数制御部４０１によって、同時アクセス数の制御を実施する。Ｓ１８０７では、ＨＴＴＰレスポンス１１０１のＬｏｃａｔｉｏｎヘッダ１１１０に取得したＣｏｎｔｅｎｔを記載して、フロントサーバ１２２または１３２に返す。
【００７９】
上記で示すように、ＢｌｕｅＧｒｅｅｎデプロイメントの実施中にのみ内部ＤＮＳサーバ１０３に問い合わせを実行する仕組みを設ける。これにより同時アクセス数制御ＡＰＩに対するリクエストを受信するごとに行われていた内部ＤＮＳサーバ１０３への問い合わせを削減することが可能となる。
【００８０】
（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置やその方法も含まれるものとする。
【００８１】
ここで、本発明は、上述した実施形態の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【００８２】
１００  情報処理システム
３０２  リクエスト振り分け部
１０２１  リクエスト受入判断部
【図１】
2018190043.tif 000003
【図２】
2018190043.tif 000004
【図３】
2018190043.tif 000005
【図４】
2018190043.tif 000006
【図５】
2018190043.tif 000007
【図６】
2018190043.tif 000008
【図７】
2018190043.tif 000009
【図８】
2018190043.tif 000010
【図９】
2018190043.tif 000011
【図１０】
2018190043.tif 000012
【図１１】
2018190043.tif 000013
【図１２】
2018190043.tif 000014
【図１３】
2018190043.tif 000015
【図１４】
2018190043.tif 000016
【図１５】
2018190043.tif 000017
【図１６】
2018190043.tif 000018
【図１７】
2018190043.tif 000019
【図１８】
2018190043.tif 000020
【図１９】
2018190043.tif 000021