JP6903888B2 - 疑似サーバ制御装置、疑似サーバ制御方法、および疑似サーバ制御プログラム - Google Patents

Description

本発明は、主に、ウェブサービスを提供するウェブサービスシステムに用いられる疑似サーバ制御装置、疑似サーバ制御方法、および疑似サーバ制御プログラムに関する。

ウェブサービスを提供する場合、サービス提供者にとって、特にサービス可用性（Availabilityとも呼ばれる／システムなどが使用できる状態を維持し続ける能力）の維持は重要なミッションである。可用性を維持するために、例えば、リクエストの集中アクセス等によってサーバが高負荷状態になってもダウンせずに正常に動作するシステム設計が求められる。通常、これらのシステム設計は、製品出荷前（例えば、設計段階）に十分検討されるので、多くの場合、問題は発生しない。

しかしながら、客先にて実際の運用が開始されてから、想定外の数のリクエストがサーバに集中することが判明する場合がある。サーバの負荷が所定のレベルを超えた場合、最悪、サーバがダウンする虞がある。

そこで、サービス提供者は、上記の如き状況にならないようにサービス可用性の観点から、実際の運用が開始された後でも予め状況把握や可用性管理に向けた計画を立ててそれを実施する必要がある。

例えば、実際にユーザにウェブサービスを提供するための環境である本番環境にて、本来の運用サービスを実行しながら並行して実際に運用される本番サーバ自身がその状況の把握および問題解消に向けた計画の立案等を実行する方法が考えられる。

また、例えば、ウェブサービスが実際にユーザに提供する本番環境とは別に、本番環境と同等のリクエスト状況が再現可能な疑似環境を作り出し、この疑似環境上で本番環境の性能チューニング（可用性を維持可能なシステム規模への変更）を行う手法が考えられる。

なお、特許文献１には、リクエストを一旦キューに格納し、システムで決定した待機時間だけ待機した後本番サーバに送信する技術が記載されている。

特許文献２には、パケット交換型ネットワークにおいて、ネットワーク負荷分散を行うことにより、通常だと破棄せざるを得なかったパケットを別経路で転送するなどして救済する技術についての記載がある。

特許文献３には、ウェブサーバからの処理要求（リクエスト）を、本番系サーバへ送信するとともに処理待ちキューに登録する処理要求転送装置についての記載がある。この処理要求転送装置により、リクエストを試験系サーバに転送することができ、且つそのリクエストの転送間隔も制御することが可能となる。

特開２００４−３４８４９１号公報 特開２００３−０７８５５５号公報 特開２０１５−１０２９５１号公報

しかしながら、近年、ウェブサービスシステム（特に、クライアントやウェブ利用回数の増加に伴う本番環境のサーバの数）の大規模化が顕著になっている。従って、本番環境上にて本来サービスと並行して状況把握や計画立案を実施する手法の場合、それら可用性対応処理の負荷自体が本番サーバ全体の負荷を高めることになり、結果として、本来サービスの処理能力が低下する虞もある。

一方、疑似環境上で本番環境の性能チューニングを行う構成の場合、本番環境を再現するとの宿命上、本番環境の大規模化につれて、どうしても、疑似環境のコストの増大化および装置構成の複雑化が懸念される。

特許文献１や特許文献２の技術は、いずれも本番サーバにおけるデータ（特にリクエスト）の取りこぼしを防ぐための技術であり、サービス可用性を維持するための状況把握や状況改善に向けた計画立案のための技術ではない。

また、特許文献３の処理要求転送装置は、ウェブサーバと実際に処理を行うアプリケーションサーバとの間に配置されている。従って、ウェブサーバだけで処理が完結する静的コンテンツのリクエストなどは対象とならない。すなわち、特許文献３の技術ではシステム全体を行き交うリクエストの全てを把握できないため、状況把握や状況改善に向けた計画立案を確実に実施することはできない。

本発明は、上記課題を解決するためになされたものであり、サービス可用性を維持するための状況把握や状況改善に向けた計画立案を確実且つ容易に実施することが可能な疑似サーバ制御装置、疑似サーバ制御方法、および疑似サーバ制御プログラムを提供することを目的とする。

本発明の疑似サーバ制御装置は、処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送するリクエスト転送モジュールと、前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御するリクエスト蓄積モジュールと、を備える。

本発明の疑似サーバ制御方法は、処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送し、前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御することを特徴とする。

本発明の疑似サーバ制御プログラムは、処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送するリクエスト転送処理と、前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御するリクエスト蓄積処理と、をコンピュータに実行させるためのプログラムである。

本発明によれば、サービス可用性を維持するための状況把握や状況改善に向けた計画立案を確実且つ容易に実施することが可能となる。

本発明の第１の実施形態の疑似サーバ制御装置の構成例を示すブロック図である。 図１に示す疑似サーバ制御装置の動作例を説明するためのフローチャートである。 本発明の第２の実施形態の疑似サーバ制御装置の構成例を示すブロック図である。 本発明の第３の実施形態の疑似サーバ制御装置を含むウェブサービスシステムの構成例を示すブロック図である。 図４に示すリクエスト転送モジュールとその周辺のモジュールを含むシステムの構成例を示すブロック図である。 図４に示すリクエスト蓄積モジュールを含む疑似系ネットワークのシステムの構成例を示すブロック図である。 リクエストデータベースに構築されるリクエスト管理テーブルの構成例を示すデータ構成図である。 リクエスト転送モジュールの動作例を説明するためのフローチャートである。 リクエスト蓄積モジュールの第１の動作例（リクエストをリクエストデータベースに格納するまでの動作）を説明するためのフローチャートである。 リクエスト蓄積モジュールの第２の動作例（リクエストをリクエストデータベースから読み出して疑似サーバに転送するまでの動作）を説明するためのフローチャートである。

［第１の実施形態］
（構成の説明）
図１は、本発明の第１の実施形態の疑似サーバ制御装置１０の構成例を示すブロック図である。疑似サーバ制御装置１０は、リクエスト転送モジュール１２と、リクエスト蓄積モジュール１４と、を備える。リクエスト転送モジュール１２は、処理のリクエストを発生する機器（例えば、エンドユーザ機器）から受け付けたリクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送する。ここで、本番サーバとは、例えば、ウェブサービスが実際にユーザに提供する本番環境に用いられる実運用サーバのことである。リクエスト蓄積モジュール１４は、疑似系ネットワークに転送されたリクエストを一時的に蓄積し、疑似サーバの負荷状態に応じて、リクエストの疑似サーバへの送信タイミングを制御する。
（動作の説明）
図２は、図１に示す疑似サーバ制御装置１０の動作例を説明するためのフローチャートである。リクエスト転送モジュール１２は、エンドユーザ機器から受け付けたリクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送する（ステップＳ１）。リクエスト蓄積モジュール１４は、疑似系ネットワークに転送されたリクエストを一時的に蓄積し、疑似サーバの負荷状態に応じて、例えば、サーバが高負荷状態とならないように、リクエストの疑似サーバへの送信タイミングを制御する（ステップＳ２）。
（効果の説明）
以上説明した第１の実施形態において、エンドユーザ機器からのリクエストは、リクエスト転送モジュール１２によって疑似系ネットワークに転送（ミラーリング）された後、リクエスト蓄積モジュール１４に一時的に蓄積される。そして、蓄積されたリクエストは、リクエスト蓄積モジュール１４によって、疑似サーバの負荷状態に応じて疑似サーバへ送信される。

第１の実施形態により、疑似系ネットワーク（特に、疑似サーバ）上で本番系ネットワーク（特に、本番サーバ）と同等のリクエスト状況を再現することが可能となる。従って、本番系ネットワークへの処理負荷に影響を与えることなく、しかも確実に、サービス可用性を維持するための状況把握や状況改善に向けた計画立案を実施することが可能となる。

さらに、第１の実施形態の場合、リクエストはリクエスト蓄積モジュール１４に一時的に蓄積され、且つその送信タイミングは疑似サーバが高負荷状態とならないように調整することができる。すなわち、第１の実施形態によれば、疑似系ネットワークを、ロードバランサや多数の本番サーバから成る本番系ネットワークに比して簡素且つ低コストに構築することが可能となる。

以上を纏めると、第１の実施形態によれば、サービス可用性を維持するための状況把握や状況改善に向けた計画立案を確実且つ容易に実施することが可能となる。
［第２の実施形態］
図３は、本発明の第２の実施形態の疑似サーバ制御装置３０の構成例を示すブロック図である。疑似サーバ制御装置３０は、記憶部３２と、制御部３４と、を備える。記憶部３２は、コンピュータ読み取り可能な記録媒体であり、疑似サーバ制御プログラム４０を記憶する。疑似サーバ制御プログラム４０は、図２に示される処理を制御部３４に実行させるためのプログラムである。

以上説明した第２の実施形態によれば、第１の実施形態と同様に、サービス可用性を維持するための状況把握や状況改善に向けた計画立案を確実且つ容易に実施することが可能となる。

なお、制御部３４の例としては、例えば、ＣＰＵ（Central Processing Unit）とＣＰＵが実行する命令を記憶するメモリを挙げることができる。また、コンピュータ読み取り可能な記録媒体は、例えば、非一時的な記憶装置である。非一時的な記憶装置の例としては、例えば、光磁気ディスク、ＲＯＭ（Read Only Memory）、不揮発性半導体メモリ等の可搬媒体、コンピュータシステムに内蔵されるハードディスクを挙げることができる。また、コンピュータ読み取り可能な記録媒体は、一時的な記憶装置を含んでももよい。一時的な記憶装置の例としては、例えば、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線、あるいは、コンピュータシステム内部の揮発性メモリを挙げることができる。
［第３の実施形態］
（構成の説明）
図４は、本発明の第３の実施形態に係る疑似サーバ制御装置１５０を含むウェブサービスシステム１００の構成例を示すブロック図である。

ウェブサービスシステム１００は、１つ以上のエンドユーザ機器１０２−１〜１０２−ｎ（ｎは自然数）と、ロードバランサパッケージ１０４と、１つ以上の本番サーバ１０６−１〜１０６−ｎと、リクエスト蓄積モジュール１０８と、疑似サーバ１１０と、を含む。

エンドユーザ機器１０２−１〜１０２−ｎは、所望のウェブサービスを受けるために、本番サーバ１０６−１〜１０６−ｎに対して、リクエスト（処理要求）を送信する。

本番サーバ１０６−１〜１０６−ｎは、エンドユーザ機器１０２−１〜１０２−ｎから受信したリクエストに対応したサービスを提供する。

エンドユーザ機器１０２−１〜１０２−ｎから送信されたリクエストは、一旦、ロードバランサパッケージ１０４に入力する。ロードバランサパッケージ１０４は、ロードバランサモジュール１２０と、リクエスト転送モジュール１２２とを含む。

リクエスト転送モジュール１２２は、エンドユーザ機器１０２−１〜１０２−ｎから受け付けたリクエストを、本番サーバ１０６−１〜１０６−ｎを少なくとも含む本番系ネットワークと、疑似サーバ１１０を少なくとも含む疑似系ネットワークとに転送する。具体的には、リクエスト転送モジュール１２２は、リクエストを、本番系ネットワークを構成する要素の１つであるロードバランサモジュール１２０に転送するとともに、疑似系ネットワークを構成するリクエスト蓄積モジュール１０８へ転送（この転送をミラーリングと呼ぶ場合がある）する。

ロードバランサモジュール１２０は、受信したリクエストを、本番サーバ１０６−１〜１０６−ｎの負荷が分散されるように考慮しながら送信する。

本実施形態の疑似サーバ制御装置１５０（図４において、一点鎖線で示す）は、リクエスト転送モジュール１２２と、リクエスト蓄積モジュール１０８と、を備える。疑似サーバ制御装置１５０は、第１の実施形態の疑似サーバ制御装置１０の一例であり、また、第２の実施形態の疑似サーバ制御装置３０のようなプロセッサを含むコンピュータによって構成されてもよい。

図５は、図４に示すリクエスト転送モジュール１２２とその周辺のモジュールを含むシステムの構成例を示すブロック図である。リクエスト転送モジュール１２２は、リクエスト受付部２００（リクエスト受付手段の一例）と、リクエスト転送部２０２（リクエスト転送手段の一例）と、を備える。

リクエスト受付部２００は、エンドユーザ機器１０２−１〜１０２−ｎからのリクエストを受け付け、受け付けたリクエストを、ロードバランサモジュール１２０（本番系ネットワークを構成する要素の一つ）へ転送する。さらに、リクエスト受付部２００は、受け付けたリクエストをリクエスト転送部２０２（疑似系ネットワークを構成する要素の一つ）へミラーリングする。

リクエスト転送部２０２は、リクエスト受付部２００によってミラーリングされたリクエストをリクエスト蓄積モジュール１０８へ転送する。

なお、リクエスト転送モジュール１２２は、ロードバランサモジュール１２０を少なくとも含むロードバランサパッケージ１０４内に配置されてもよい。

図６は、図４に示すリクエスト蓄積モジュール１０８を含む疑似系ネットワークのシステムの構成例を示すブロック図である。リクエスト蓄積モジュール１０８は、リクエストデータベース３００と、リクエスト蓄積制御部３０２（リクエスト蓄積制御手段）と、リクエスト送信制御部３０４（リクエスト送信制御手段）と、を備える。

リクエストデータベース３００は、リクエスト転送モジュール１２２から転送されたリクエストを一時的に保持する。そして、少なくとも、リクエスト転送モジュール１２２からリクエストを受信してそのリクエストが疑似サーバ１１０に転送されるまでの間、リクエストデータベース３００には、リクエストの送信を管理するためのリクエスト管理テーブル３３０が作成される。

図７は、リクエストデータベース３００に構築されるリクエスト管理テーブル３３０の構成例を示すデータ構成図である。リクエスト管理テーブル３３０は、リクエスト自体とこのリクエストの送信を管理するための少なくとも１つのフィールド情報とからなる、少なくとも１つのレコード情報を含む。

フィールド情報とは、図７において、列方向のデータ（例えば、Index、Method、Request等）のことである。レコード情報とは、図７において、行方向のデータ（例えば、Index＝１についての各フィールド情報およびリクエスト（request）の集まり）である。

なお、図７において、Indexは、レコード情報を識別するために割り振られる数字であり、通常、そのレコード情報に含まれるリクエストの受信順に割り振られる（つまり、先に受信されたリクエストを含むレコード情報のIndexほど小さい値になる）。

Methodは、ウェブサイト（＝ウェブサーバ、本実施形態の本番サーバ１０６−１〜１０６−ｎに相当）にデータを受け渡すときに用いる方法のことである。Methodには、例えば、ＧＥＴメソッドとＰＯＳＴメソッドがある。一般的に、リクエストは、ＵＲＬ（Uniform Resource Locator）を含むヘッダ部とボディ部とで構成される。ＧＥＴメソッドは、ＵＲＬの後にフォーム入力などのユーザデータを付加するメソッドである。これに対して、ＰＯＳＴメソッドは、ボディ部にユーザデータを収容するメソッドである。

Requestは、本実施形態等で使用しているリクエストそのものである。Hostは、ウェブサーバ（例えば、本番サーバ１０６−１〜１０６−ｎ）の名前である。Cookieは、ウェブブラウザ（例えば、エンドユーザ機器１０２−１〜１０２−ｎ）でウェブサイト（例えば、本番サーバ１０６−１〜１０６−ｎ）にアクセスした際に、そのサイトから送信されるファイル（情報）である。Cookieには、例えば、ウェブサイト（ウェブサーバ）側が指定したデータを保存しておくことができる。Content-Lengthは、データの長さ、例えば、レコード情報のデータの長さ、あるいはリクエストのデータの長さを示す。

リクエスト蓄積制御部３０２は、リクエストのリクエストデータベース３００への蓄積、より詳細にはリクエスト管理テーブル３３０への書き込みを制御する。リクエスト蓄積制御部３０２は、リクエストをリクエスト管理テーブル３３０に書き込む際、リクエストの宛先情報を疑似サーバ１１０の宛先情報に書き換える。

リクエスト送信制御部３０４は、疑似サーバ１１０の負荷状態に応じてリクエストの疑似サーバ１１０への送信タイミングを制御する。本実施形態では、負荷状態に応じた制御の一例として、疑似サーバ１１０が高負荷状態とならないように制御する場合を例に挙げる。例えば、リクエスト送信制御部３０４は、所定のリクエストを送信する際、その所定のリクエストの前に送信された別のリクエストのＴＡＴ（Turn Around Time）の値が所定の閾値を下回っている場合、疑似サーバ１１０が高負荷状態ではないと判断し、所定のリクエストを疑似サーバ１１０へ送信する。

すなわち、リクエスト送信制御部３０４は、ただ単に、リクエスト管理テーブル３３０のリクエストを送信するのではなく、疑似サーバ１１０が高負荷にならないように疑似サーバ１１０への単位時間当たりのリクエスト送信数を制御し、必要があればリクエストの送信を遅延させる。

これによりリクエストの取りこぼしが回避される。すなわち、疑似サーバ１１０は、本番サーバ１０６−１〜１０６−ｎと同数のリクエストを受信することができる。このことは、疑似サーバ１１０上に本番サーバ１０６−１〜１０６−ｎと同一の環境が再現されたことを意味する。
（動作の説明）
以下、疑似サーバ制御装置１５０の動作について説明する。なお、図４における疑似サーバ制御装置１５０と直接関係の無い装置の動作（例えば、ロードバランサモジュール１２０や本番サーバ１０６−１〜１０６−ｎ等の動作）についての説明は、省略する。

図８は、リクエスト転送モジュール１２２の動作例を説明するためのフローチャートである。リクエスト転送モジュール１２２のリクエスト受付部２００は、エンドユーザ機器１０２−１〜１０２−ｎからのリクエストを受け付け、受け付けたリクエストを、ロードバランサモジュール１２０へ転送する（ステップＳ１０）。さらに、リクエスト受付部２００は、受け付けたリクエストをリクエスト転送部２０２へミラーリングする（ステップＳ１１）。リクエスト転送モジュール１２２のリクエスト転送部２０２は、リクエスト受付部２００によってミラーリングされたリクエストをリクエスト蓄積モジュール１０８へ転送する（ステップＳ１２）。

図９は、リクエスト蓄積モジュール１０８の第１の動作例（リクエストをリクエストデータベース３００に格納するまでの動作）を説明するためのフローチャートである。リクエスト蓄積モジュール１０８のリクエスト蓄積制御部３０２は、リクエスト転送モジュール１２２から転送されたリクエストの宛先情報を疑似サーバ１１０の宛先情報に書き換える（ステップＳ２０）。宛先情報は、例えば、ＦＱＤＮ（Fully Qualified Domain Name）やホスト（例えば、本番サーバ１０６−１〜１０６−ｎ）の名前である。リクエスト蓄積制御部３０２は、このリクエストをリクエスト管理テーブル３３０へ登録する（ステップＳ２１）。

図１０は、リクエスト蓄積モジュール１０８の第２の動作例（リクエストをリクエストデータベース３００から読み出して疑似サーバ１１０に転送するまでの動作）を説明するためのフローチャートである。

リクエスト蓄積モジュール１０８のリクエスト送信制御部３０４は、リクエスト管理テーブル３３０に送信すべきリクエストが存在するか否か判定する（ステップＳ３０）。送信すべきリクエストが存在しない場合（ステップＳ３０においてＮｏ）、リクエスト送信制御部３０４は、ステップＳ３０の処理を再度実行する。

リクエスト管理テーブル３３０に送信すべきリクエストが存在する場合、リクエスト送信制御部３０４は、疑似サーバ１１０が高負荷状態にあるか否かを判定する（ステップＳ３１）。ここで、高負荷状態とは、例えば、負荷を示すある物理量の値が所定の閾値を上回っている状態のことを指す。例えば、リクエスト送信制御部３０４は、送信しようとするリクエストの前に送信された別のリクエストのＴＡＴ（時間）に基づいて疑似サーバ１１０の負荷状態を判定することができる。

疑似サーバ１１０が高負荷状態にある場合（ステップＳ３１においてＹｅｓ）、リクエスト送信制御部３０４は、当該リクエストの送信を行わず、ステップＳ３１の処理を再度実行する。すなわち、この場合、リクエストは、疑似サーバ１１０が低負荷状態になるまでウェイトされて送信されることはない。

疑似サーバ１１０が低負荷状態にある場合（ステップＳ３１においてＮｏ）、リクエスト送信制御部３０４は、リクエスト管理テーブル３３０からIndexが最も小さいレコード情報に含まれるリクエストを抽出する（ステップＳ３２）。リクエスト送信制御部３０４は、抽出したリクエストを、疑似サーバ１１０へ送信する（ステップＳ３３）。
（効果の説明）
以上説明した第３の実施形態において、エンドユーザ機器１０２−１〜１０２−ｎからのリクエストは、リクエスト転送モジュール１２２によってミラーリングされた後、リクエスト蓄積モジュール１０８に一時的に蓄積される。そして、蓄積されたリクエストは、リクエスト蓄積モジュール１０８によって、疑似サーバ１１０が高負荷状態とならないように疑似サーバ１１０へ送信される。

第３の実施形態により、疑似系ネットワーク（特に、疑似サーバ１１０）上で本番系ネットワーク（特に、本番サーバ１０６−１〜１０６−ｎ）と同等のリクエスト状況を再現することが可能となる。従って、本番系ネットワークへの処理負荷に影響を与えることなく、しかも確実に、サービス可用性を維持するための状況把握や状況改善に向けた計画立案を実施することが可能となる。

さらに、第３の実施形態の場合、リクエストはリクエスト蓄積モジュール１０８に一時的に蓄積され且つその送信タイミングは疑似サーバ１１０が高負荷状態とならないように調整されている。すなわち、第３の実施形態によれば、疑似系ネットワークを、ロードバランサモジュール１２０や多数の本番サーバ１０６−１〜１０６−ｎから成る本番系ネットワークに比して簡素且つ低コストに構築することが可能となる。

以上を纏めると、第３の実施形態によれば、サービス可用性を維持するための状況把握や状況改善に向けた計画立案を確実且つ容易に実施することが可能となる。
（変形例の説明）
以上説明した第３の実施形態において、リクエスト管理テーブル３３０（図７参照）を複数（例えば、さらにもう一つ追加する）設けることができる。これにより、疑似サーバ１１０を複数作成することが可能となる。

そして、この追加されたリクエスト管理テーブル３３０にリクエストを登録する際、例えば、特定のリクエストのみを格納するとのルールが設けられてもよい。このことにより、通常の疑似サーバ１１０に加え、ある特定のリクエストのみを集中させた別の疑似サーバ１１０を追加することができる。このことは、現在の本番環境をスケールアウト（本番サーバ１０６−１〜１０６−ｎの追加）させる場合の調査分析等にとって極めて有用である。

また、以上説明した第３の実施形態において、疑似サーバ制御装置１５０と疑似サーバ１１０との間を専用線で結び、セキュアな通信を約束することが可能である。これにより、漏洩が許されない本番環境の情報を、サービス運用者側のクローズドな社内網に構築することが可能となる。

さらに、以上説明した第３の実施形態において、リクエスト蓄積制御部３０２は、リクエストのメソッドを解析し、ＧＥＴリクエストおよびＰＯＳＴリクエストそれぞれに対してメソッドに応じた処理を追加することができる。例えば、「ＧＥＴリクエストについては疑似サーバ１１０からのレスポンスは受け取らない」や「ＰＯＳＴリクエストについては応答を拾い、ｈｔｔｐレスポンスに従った処理分岐を設ける」等の処理を追加することができる。これにより、疑似サーバ制御装置１５０は、疑似サーバ１１０の状態を任意に制御することが可能となる。

また、以上説明した第３の実施形態は、例えば、第２の実施形態のように、図８〜１０に示す動作がプログラムとして記述されてコンピュータ読み取り可能な記録媒体に記憶され、そのプログラムがＣＰＵ等の演算装置により実行される構成とすることもできる。なお、図８〜図１０の動作を一つのコンピュータで実行できない場合、複数のコンピュータが分担してこれらの動作を実行してもよい。

以上、各実施形態を用いて本発明を説明したが、本発明の技術的範囲は、上記各実施形態の記載に限定されない。上記各実施形態に多様な変更又は改良を加えることが可能であることは当業者にとって自明である。従って、そのような変更又は改良を加えた形態もまた本発明の技術的範囲に含まれることは説明するまでもない。また、以上説明した各実施形態において使用される、数値や各構成の名称等は例示的なものであり適宜変更可能である。

また、上述した各実施形態の一部又は全部は、以下の付記のようにも記載されうる。
（付記１）
処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送するリクエスト転送モジュールと、
前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御するリクエスト蓄積モジュールと、
を備えることを特徴とする疑似サーバ制御装置。
（付記２）
前記リクエスト蓄積モジュールは、
前記リクエスト転送モジュールから転送された前記リクエストを一時的に保持するリクエストデータベースと、
前記リクエストの前記リクエストデータベースへの蓄積を制御するリクエスト蓄積制御手段と、
前記リクエストの前記送信タイミングを制御するリクエスト送信制御手段と
を備えることを特徴とする付記１記載の疑似サーバ制御装置。
（付記３）
前記リクエスト送信制御手段は、所定の前記リクエストを送信する前に送信された別の前記リクエストのＴＡＴ（Turn Around Time）の値が所定の閾値を下回っている場合に、所定の前記リクエストを前記疑似サーバへ送信することを特徴とする付記２記載の疑似サーバ制御装置。
（付記４）
少なくとも、前記リクエスト転送モジュールから前記リクエストを受信してその前記リクエストが前記疑似サーバに転送されるまでの間、前記リクエストデータベースには、前記リクエストの送信を管理するためのテーブルであり、前記リクエスト自体とこの前記リクエストの送信を管理するための少なくとも１つのフィールド情報とからなる、少なくとも１つのリクエストレコード情報を備えるリクエスト管理テーブルが構築されることを特徴とする付記２または３記載の疑似サーバ制御装置。
（付記５）
前記リクエスト蓄積制御手段は、前記リクエストを前記リクエスト管理テーブルに蓄積する際、前記リクエストの宛先情報を前記疑似サーバの宛先情報に書き換えることを特徴とする付記４記載の疑似サーバ制御装置。
（付記６）
前記リクエスト転送モジュールは、
前記エンドユーザ機器からの前記リクエストを受け付け、受け付けた前記リクエストを、前記本番系ネットワークへ転送するとともに、前記疑似系ネットワークへミラーリングするリクエスト受付手段と、
前記リクエスト受付手段によってミラーリングされた前記リクエストを前記リクエスト蓄積モジュールへ転送するリクエスト転送手段と、
を含むことを特徴とする付記１−５のいずれか１項に記載の疑似サーバ制御装置。
（付記７）
前記リクエスト受付手段は、受け付けた前記リクエストを、前記本番サーバへの負荷分散を行うロードバランサモジュールへ転送することを特徴とする付記６記載の疑似サーバ制御装置。
（付記８）
前記リクエスト転送モジュールは、前記ロードバランサモジュールを少なくとも含むロードバランサパッケージ内に配置されることを特徴とする付記７記載の疑似サーバ制御装置。
（付記９）
処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送し、
前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御する
ことを特徴とする疑似サーバ制御方法。
（付記１０）
前記疑似系ネットワークに転送された前記リクエストを、リクエストデータベースに一時的に保持し、
前記リクエストの前記リクエストデータベースへの蓄積を制御し、
前記リクエストの前記送信タイミングを制御する
ことを特徴とする付記９記載の疑似サーバ制御方法。
（付記１１）
処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送するリクエスト転送処理と、
前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御するリクエスト蓄積処理と、
をコンピュータに実行させるための疑似サーバ制御プログラム。
（付記１２）
前記リクエスト蓄積処理は、
前記疑似系ネットワークに転送された前記リクエストを、リクエストデータベースに一時的に保持する保持処理と、
前記リクエストの前記リクエストデータベースへの蓄積を制御するリクエスト蓄積制御処理と、
前記リクエストの前記送信タイミングを制御するリクエスト送信制御処理と
を含むことを特徴とする付記１１記載の疑似サーバ制御プログラム。

１０ 疑似サーバ制御装置
１２ リクエスト転送モジュール
１４ リクエスト蓄積モジュール
３０ 疑似サーバ制御装置
３２ 記憶部
３４ 制御部
４０ 疑似サーバ制御プログラム
１００ ウェブサービスシステム
１０２−１〜１０２−ｎ エンドユーザ機器
１０４ ロードバランサパッケージ
１０６−１〜１０６−ｎ 本番サーバ
１０８ リクエスト蓄積モジュール
１１０ 疑似サーバ
１２０ ロードバランサモジュール
１２２ リクエスト転送モジュール
１５０ 疑似サーバ制御装置
２００ リクエスト受付部
２０２ リクエスト転送部
３００ リクエストデータベース
３０２ リクエスト蓄積制御部
３０４ リクエスト送信制御部
３３０ リクエスト管理テーブル

Claims (9)

1. 処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送するリクエスト転送モジュールと、
   前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御するリクエスト蓄積モジュールと、
   を備え、
   前記リクエスト転送モジュールは、
   エンドユーザ機器からの前記リクエストを受け付け、受け付けた前記リクエストを、前記本番系ネットワークへ転送するとともに、前記疑似系ネットワークへミラーリングするリクエスト受付手段と、
   前記リクエスト受付手段によってミラーリングされた前記リクエストを前記リクエスト蓄積モジュールへ転送するリクエスト転送手段と、
   を含むことを特徴とする疑似サーバ制御装置。
2. 前記リクエスト蓄積モジュールは、
   前記リクエスト転送モジュールから転送された前記リクエストを一時的に保持するリクエストデータベースと、
   前記リクエストの前記リクエストデータベースへの蓄積を制御するリクエスト蓄積制御手段と、
   前記リクエストの前記送信タイミングを制御するリクエスト送信制御手段と
   を備えることを特徴とする請求項１記載の疑似サーバ制御装置。
3. 前記リクエスト送信制御手段は、所定の前記リクエストを送信する前に送信された別の前記リクエストのＴＡＴ（Turn Around Time）の値が所定の閾値を下回っている場合に、所定の前記リクエストを前記疑似サーバへ送信することを特徴とする請求項２記載の疑似サーバ制御装置。
4. 少なくとも、前記リクエスト転送モジュールから前記リクエストを受信してその前記リクエストが前記疑似サーバに転送されるまでの間、前記リクエストデータベースには、前記リクエストの送信を管理するためのテーブルであり、前記リクエスト自体とこの前記リクエストの送信を管理するための少なくとも１つのフィールド情報とからなる、少なくとも１つのリクエストレコード情報を備えるリクエスト管理テーブルが構築されることを特徴とする請求項２または３記載の疑似サーバ制御装置。
5. 前記リクエスト蓄積制御手段は、前記リクエストを前記リクエスト管理テーブルに蓄積する際、前記リクエストの宛先情報を前記疑似サーバの宛先情報に書き換えることを特徴とする請求項４記載の疑似サーバ制御装置。
6. 前記リクエスト受付手段は、受け付けた前記リクエストを、前記本番サーバへの負荷分散を行うロードバランサモジュールへ転送することを特徴とする請求項１−５のいずれか１項に記載の疑似サーバ制御装置。
7. 前記リクエスト転送モジュールは、前記ロードバランサモジュールを少なくとも含むロードバランサパッケージ内に配置されることを特徴とする請求項６記載の疑似サーバ制御装置。
8. リクエスト転送モジュールが、処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送し、
   リクエスト蓄積モジュールが、前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御する
   ことを特徴とする疑似サーバ制御方法であって、
   前記リクエスト転送モジュールは、
   エンドユーザ機器からの前記リクエストを受け付け、受け付けた前記リクエストを、前記本番系ネットワークへ転送するとともに、前記疑似系ネットワークへミラーリングし、
   ミラーリングされた前記リクエストを前記リクエスト蓄積モジュールへ転送する、
   ことを特徴とする疑似サーバ制御方法。
9. リクエスト転送モジュールにおいて、処理のリクエストを発生する機器から受け付けた前記リクエストを、本番サーバを少なくとも含む本番系ネットワークと、疑似サーバを少なくとも含む疑似系ネットワークとに転送するリクエスト転送処理と、
   リクエスト蓄積モジュールにおいて、前記疑似系ネットワークに転送された前記リクエストを一時的に蓄積し、前記疑似サーバの負荷状態に応じて、前記リクエストの前記疑似サーバへの送信タイミングを制御するリクエスト蓄積処理と、
   をコンピュータに実行させるための疑似サーバ制御プログラムであって、
   前記リクエスト転送モジュールにおいて、
   エンドユーザ機器からの前記リクエストを受け付け、受け付けた前記リクエストを、前記本番系ネットワークへ転送するとともに、前記疑似系ネットワークへミラーリングする処理と、
   ミラーリングされた前記リクエストを前記リクエスト蓄積モジュールへ転送する処理と、
   をコンピュータに実行させるための疑似サーバ制御プログラム。

Images