JP2018088041A - 接続数制御プログラム、振り分け装置および接続数制御方法 - Google Patents

Abstract

【課題】応答性能の劣化を抑制するように同時接続数を調整可能にすること。【解決手段】処理部１ｂは、第１の装置２により送信されたリクエストを受信してから当該リクエストを第２の装置４に送信するまでの第１の時間を記憶部１ａに記録する。処理部１ｂは、第２の装置４にリクエストを送信してから当該リクエストに対するレスポンスを受信するまでの第２の時間を記憶部１ａに記憶する。処理部１ｂは、第１の時間の統計値と第２の時間の統計値との比較に応じて、第２の装置４，５に対する同時接続数の上限を変更する。【選択図】図１

Description

本発明は接続数制御プログラム、振り分け装置および接続数制御方法に関する。

現在、複数の情報処理装置がネットワークを介して通信する情報処理システムが利用されている。例えば、クライアントサーバシステムでは、サービスを提供する装置（サーバと呼ばれる）と、サービスを利用する装置（クライアントと呼ばれる）とがネットワークを介して通信する。クライアントは、サーバに対するリクエストを送信する。サーバは、リクエストを受信し、リクエストに応じたレスポンスをクライアントに送信する。

サーバは、複数のクライアントから複数のリクエストを受信し得る。リクエスト数が増えるとサーバの負荷が増える。サーバの負荷が過大になると、クライアントに対するレスポンス遅延が増す可能性がある。そこで、クライアントとサーバとの間に、クライアントのリクエストを受信してサーバへのアクセスを代行する制御装置を設け、制御装置の機能によりサーバの負荷を抑える方法が考えられている。

例えば、サーバに対して同時に接続できるクライアントの許容最大数である最大接続数により、サーバへのリクエストの送信を制限するトラフィック制御装置の提案がある。この提案では、最大接続数はオペレータにより予め設定される。

また、サーバに送信済であるがサーバからレスポンスが返されていない応答待ちリクエストの数を制限する負荷制御装置の提案もある。負荷制御装置は、応答待ちリクエスト数が閾値に達しているならば、受信したリクエストをバッファに一時蓄積し、応答待ちリクエスト数が閾値を下回るまでバッファからのリクエストの送信を待ち合わせる。

なお、同時に並行して処理を進める処理プロセス上限値である臨界多重度を自身のハードウェアの動作状況から算出し、算出された臨界多重度を上限として、クライアントから自身への同時接続数を制御するデータベースサーバの提案もある。

特開２００５−１８４１６５号公報 国際公開第２００７／１２５９４２号 国際公開第２０１３／１２９０６１号

上記のように、所定の装置にサーバへの同時接続数の上限を設定することで、サーバに対するリクエストの送信を制限し、当該装置上で制限対象のリクエストを、接続数に空きが生じるまでバッファリングすることが考えられる。ここで、同時接続数の上限は、システムのサービス品質に影響を及ぼす。

例えば、同時接続数の上限が大きいほど、サーバでのリクエストの受信頻度が増えやすい。サーバでのリクエストの受信頻度が増すと、サーバでのリクエストの処理待ちの時間の増大を招き、クライアントに対するレスポンス遅延が悪化する。

一方、同時接続数の上限が小さいほど、接続数の空き待ちが生じやすくなる。空き待ちにより、サーバへのアクセスを代行する装置上でのリクエストの転送待ちの時間が増えると、クライアントに対するレスポンス遅延が悪化する。

そこで、例えば、ユーザが、サービスの利用状況の事前調査を行い、今後の利用状況の予測に基づき、同時接続数の上限の設定を予め行っておくことが考えられる。ところが、実際の運用と事前調査での環境とが常に同じであるとは限らない。例えば、同じシステムでも時間の経過に伴って装置構成やサービスの利用状況が変化することもある。このため、同時接続数の上限の当初の設定が、サービス品質を維持する上で、その後も常に良好な設定であるとは限らない。

１つの側面では、本発明は、応答性能の劣化を抑制するように同時接続数を調整可能にすることを目的とする。

１つの態様では、接続数制御プログラムが提供される。この接続数制御プログラムは、第１の装置により送信されたリクエストを受信してからリクエストを第２の装置に送信するまでの第１の時間と、第２の装置にリクエストを送信してからリクエストに対するレスポンスを受信するまでの第２の時間とを、複数のリクエストそれぞれに対して記録し、第１の時間の統計値と第２の時間の統計値との比較に応じて、第２の装置に対する同時接続数の上限を変更する、処理をコンピュータに実行させる。

１つの側面では、応答性能の劣化を抑制するように同時接続数を調整可能になる。

第１の実施の形態の振り分け装置を示す図である。 第２の実施の形態の情報処理システムの例を示す図である。 第２の実施の形態のプロキシサーバのハードウェア例を示す図である。 プロキシサーバの機能例を示す図である。 最大同時接続数に対する各時間の測定結果の例を示す図である。 最大同時接続数と各時間との関係の例を示す図である。 プロキシ処理部により出力されるログの例を示す図である。 履歴管理テーブルの例を示す図である。 統計値テーブルの例を示す図である。 最大同時接続数の初期設定の例である。 プロキシサーバの処理例を示すフローチャートである。 性能劣化の抑制例を示す図である。 最大同時接続数の変更例を示す図である。 最大同時接続数の他の制御例（その１）を示す図である。 最大同時接続数の他の制御例（その２）を示す図である。 最大同時接続数の他の制御例（その３）を示す図である。 他の制御例（その３）における履歴管理テーブルの例を示す図である。

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の振り分け装置を示す図である。振り分け装置１は、第１の装置２，３および第２の装置４，５と通信する。振り分け装置１および第１の装置２，３は、ネットワーク６に接続されている。振り分け装置１および第２の装置４，５は、ネットワーク７に接続されている。第１の装置２，３は、クライアントコンピュータ、または、クライアントと呼ばれてもよい。第２の装置４，５は、サーバコンピュータ、または、サーバと呼ばれてもよい。第２の装置４，５は、同じサービスを提供する。第１の装置２，３の数および第２の装置４，５の数は、３以上でもよい。

振り分け装置１は、第１の装置２，３からリクエストを受信し、受信したリクエストを、第２の装置４，５に振り分けることで、第２の装置４，５の負荷を分散させる。すなわち、振り分け装置１は、第２の装置４，５（送信先候補）の中からリクエストの送信先を所定の振り分けルールを基に選択し、選択した送信先にリクエストを送信する。振り分け装置１は、第２の装置４，５からリクエストに対するレスポンスを受信する。振り分け装置１は、リクエストの送信元である第１の装置２，３に、レスポンスを送信する。振り分け装置１は、負荷分散装置と呼ばれてもよい。

振り分け装置１による振り分けルールには、種々の方法が考えられる。例えば、振り分けルールは、ラウンドロビン（送信先候補を順番に選択）や最小コネクション（既存のＴＣＰ（Transmission Control Protocol）コネクション数が最小の送信先候補を選択）などである。

ここで、サービス品質（ＱｏＳ：Quality of Service）の劣化を抑制するため、振り分け装置１には、種々のパラメータが設定される。パラメータの１つに、最大同時接続数がある。ここで、「同時接続数」は、ある１つの第２の装置に対し、リクエストを送信したが、当該リクエストに対するレスポンスを未受信であるリクエスト（応答待ちリクエスト）の数により計算される。応答待ちリクエスト数を同時接続数と考えてもよい。最大同時接続数は、第２の装置の１つ当たりの応答待ちリクエスト数（すなわち、同時接続数）の上限である。

振り分け装置１は、リクエストを受信すると、リクエストを所定のバッファに格納する。振り分け装置１は、第２の装置４，５のうち、同時接続数が最大同時接続数に達しているものをリクエストの送信先候補から除外する。第２の装置４，５の何れもが送信先候補から除外される場合、リクエストを直ちに送信することはできない。このため、振り分け装置１は、第２の装置４，５の何れかで同時接続数に空きが生じるまで、リクエストをバッファに保持する。バッファに格納されたリクエストを、「転送待ちのリクエスト」と称することがある。

振り分け装置１は、最大同時接続数を動的に変化させる機能を提供する。振り分け装置１は、記憶部１ａおよび処理部１ｂを有する。
記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、フラッシュメモリなどの不揮発性記憶装置でもよい。処理部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１ｂはプログラムを実行するプロセッサでもよい。プロセッサは、複数のプロセッサの集合（マルチプロセッサ）を含み得る。

記憶部１ａは、バッファｄ１を含む。バッファｄ１は、転送待ちのリクエストを記憶する。記憶部１ａは、第１の時間および第２の時間を第２の装置４，５それぞれに対して記憶する。第１の時間は、バッファｄ１におけるリクエストの転送待ち時間（バッファｄ１に格納されてから転送されるまでの時間）である。第２の時間は、リクエストを第２の装置に送信してから、当該リクエストに対するレスポンスを第２の装置から受信するまでの時間である。第２の時間には、第２の装置の処理遅延の影響およびネットワーク７での通信遅延の影響が反映される。ネットワーク７での通信遅延は、第２の装置の処理遅延に比べて小さい。このため、第２の時間を、第２の装置によるリクエストの処理時間と呼んでもよい。

処理部１ｂは、第１の装置２，３から受信したリクエストの振り分け処理を行う。例えば、処理部１ｂは、第１の装置２からリクエストを受信する。処理部１ｂは、第２の装置４，５のうち、現在の同時接続数が最大同時接続数に達していない送信先候補の中から、振り分けルールに従って、リクエストの送信先を決定する。

第２の装置４，５の全てについて、現在の同時接続数が最大同時接続数に達している場合、処理部１ｂは、リクエストをバッファｄ１に格納し、同時接続数に空きができるまで待機する。バッファｄ１に既にリクエストが格納されている場合、例えば、第２の装置４で同時接続数に空きが生じると、処理部１ｂは、最も古いリクエストから順に、バッファｄ１から取り出して、該当の第２の装置に送信する。処理部１ｂは、リクエストに対するレスポンスを第２の装置４から受信すると、該当のリクエストの送信元である第１の装置２にレスポンスを送信する。

処理部１ｂは、第１の装置２により送信されたリクエストを受信してから当該リクエストを第２の装置４に送信するまでの第１の時間を、複数のリクエストそれぞれに対して記憶部１ａに記録する。また、処理部１ｂは、第２の装置４にリクエストを送信してから、当該リクエストに対するレスポンスを受信するまでの第２の時間を、複数のリクエストそれぞれに対して記憶部１ａに記録する。第１の実施の形態の例では、第２の装置４，５が複数なので、処理部１ｂは、第２の装置４，５それぞれの識別情報に対応付けて、第１の時間および第２の時間を記録してもよい。

処理部１ｂは、第１の時間の統計値Ｔ１と第２の時間の統計値Ｔ２との比較に応じて、第２の装置４，５に対する同時接続数の上限を変更する。具体的には次の通りである。
図１では、同時接続数の上限に対する第１の時間および第２の時間の関係の例を示している。系列Ａは、同時接続数の上限Ｘに対する第１の時間の統計値Ｔ１の関係（Ｔ１（Ｘ））を示す。系列Ｂは、同時接続数の上限Ｘに対する第２の時間の統計値Ｔ２の関係（Ｔ２（Ｘ））を示す。ここで、統計値としては、パーセンタイル値（例えば、９０パーセンタイル値など）や平均値などが考えられる。

系列Ｃは、同時接続数の上限Ｘに対する時間Ｔの関係（Ｔ（Ｘ））を示す。時間Ｔ＝Ｔ１＋Ｔ２である。すなわち、時間Ｔは、処理部１ｂが第１の装置２（あるいは、第１の装置３）からリクエストを受信してから、第１の装置２（あるいは、第１の装置３）へ当該リクエストに対するレスポンスを送るまでの時間（クライアントに対する応答時間）である。

系列Ａによれば、同時接続数の上限Ｘが小さいほど、転送待ち時間（第１の時間）が増す。振り分け装置１において転送待ちとなるリクエストの数が増すからである。一方、系列Ｂによれば、同時接続数の上限Ｘが小さいほど、第２の装置によるリクエストの処理時間（第２の時間）が減る。第２の装置の１つ当たりに同時に割り振られるリクエストの数が減り、第２の装置の負荷が小さくなるからである。また、系列Ｃによれば、同時接続数の上限Ｘが小さいほど、転送待ち時間が要因となって、クライアントに対する応答時間が増す。

更に、系列Ａによれば、同時接続数の上限Ｘが大きいほど、転送待ち時間（第１の時間）が減る。転送待ちとなるリクエストの数が減るからである。一方、系列Ｂによれば、同時接続数の上限Ｘが大きいほど、第２の装置によるリクエストの処理時間（第２の時間）が増す。第２の装置の１つ当たりに同時に割り振られるリクエストの数が増し、第２の装置の負荷が大きくなるからである。また、系列Ｃによれば、同時接続数の上限Ｘが大きいほど、第２の装置によるリクエストの処理時間が要因となって、クライアントに対する応答時間が増す。

そして、系列Ａ，Ｂによれば、同時接続数の上限がＸ１〜Ｘ２程度では、転送待ち時間および第２の装置によるリクエストの処理時間の両方が比較的短い。時間Ｔは、同時接続数の上限Ｘ１〜Ｘ２の範囲で極小値をとる。すなわち、同時接続数の上限がＸ１〜Ｘ２の範囲程度であれば、時間Ｔが悪化する可能性は低いと考えられる。

ここで、例えば、このような関係性を事前に調査して、時間Ｔが極小となる同時接続数の上限を振り分け装置１に予め設定しておくことが考えられる。しかし、調査時の環境がその後も常に維持されるとは限らない。例えば、第１の装置２，３の数が増減したり、あるいは、第２の装置４，５の数が増えたりすると、上記の関係性は変わり得る。また、調査時と現実の運用の環境が必ずしも一致しているとも限らない。このように、事前の調査などに基づく静的な設定では、サービス品質の劣化を抑制できない可能性がある。

そこで、処理部１ｂは、系列Ａ，Ｂ，Ｃにみられる、ある傾向に着目して、同時接続数の上限を変更する。すなわち、系列Ａ，Ｂによれば、同時接続数の上限が小さいほど、第１の時間の統計値Ｔ１が、第２の時間の統計値Ｔ２よりも大きくなる傾向にある（統計値Ｔ１，Ｔ２の差が大きくなる）。一方、系列Ａ，Ｂによれば、同時接続数の上限が大きいほど、第２の時間の統計値Ｔ２が、第１の時間の統計値Ｔ１よりも大きくなる傾向にある（統計値Ｔ１，Ｔ２の差が大きくなる）。したがって、処理部１ｂは、統計値Ｔ１，Ｔ２を比較し、統計値Ｔ１，Ｔ２に差がある場合に、同時接続数の上限を変更する。

具体的には、処理部１ｂは、第１の時間の統計値Ｔ１が第２の時間の統計値Ｔ２以上の場合、同時接続数の上限を増やす。一方、処理部１ｂは、第１の時間の統計値Ｔ１が第２の時間の統計値Ｔ２よりも小さい場合、同時接続数の上限を減らす。時間Ｔを極小値に近い値にシフトさせるためである。

処理部１ｂは、第２の装置４，５を区別せずに統計値Ｔ１，Ｔ２を求めて、第２の装置４，５のグループに対する同時接続数の上限を求めてもよい。この場合、例えば、処理部１ｂは、当該上限を第２の装置の数（この例では２）で割ることで、第２の装置４，５それぞれに対する同時接続数の上限を定めてもよい。あるいは、処理部１ｂは、第２の装置４，５を区別して、第２の装置４，５それぞれについて、統計値Ｔ１，Ｔ２を求めて、第２の装置４，５それぞれに対する同時接続数の上限を計算してもよい。

更に、処理部１ｂは、第１の時間の統計値Ｔ１と第２の時間の統計値Ｔ２との差に応じて、同時接続数の上限の変更量を決定してもよい。例えば、処理部１ｂは、差が大きいほど、変更量を大きくしてもよい。処理部１ｂは、差が小さいほど、変更量を小さくしてもよい。時間Ｔを早く極小値に近づけ、また、時間Ｔが比較的小さい状態を長い時間維持するためである。

このように、処理部１ｂは、第２の装置４，５に対する同時接続数の上限を動的に変更することで、応答性能の劣化を抑制するように同時接続数の上限を調整可能になる。特に第２の装置４，５への負荷が時間によって変動する場合や障害が発生した場合に、事前の調査などによって同時接続数の上限を静的に設定するよりも、クライアントに対する応答時間の劣化を抑えることができる。その結果、振り分け装置１および第２の装置４，５によるサービス品質の向上を図れる。

以下では、クラウドサービスを提供するシステムに振り分け装置１の機能を適用する例を示し、当該機能を更に具体的に説明する。
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムの例を示す図である。第２の実施の形態の情報処理システムは、プロキシサーバ１００、クライアント２００，２００ａ、処理サーバ３００，３００ａ，３００ｂおよび実行サーバ４００，４００ａ，４００ｂ，４００ｃを含む。

プロキシサーバ１００およびクライアント２００，２００ａは、ネットワーク１０に接続されている。ネットワーク１０は、インターネットやＷＡＮ（Wide Area Network）でもよい。あるいは、ネットワーク１０は、ＬＡＮ（Local Area Network）でもよい。プロキシサーバ１００および処理サーバ３００，３００ａ，３００ｂは、ネットワーク２０に接続されている。処理サーバ３００，３００ａ，３００ｂおよび実行サーバ４００，４００ａ，４００ｂ，４００ｃは、ネットワーク３０に接続されている。ネットワーク２０，３０は、例えば、データセンタ内のＬＡＮである。

プロキシサーバ１００は、クライアント２００，２００ａからリクエストを受信し、受信したリクエストを、処理サーバ３００，３００ａ，３００ｂに振り分けるサーバコンピュータである。プロキシサーバ１００は、第１の実施の形態の振り分け装置１の一例である。

クライアント２００，２００ａは、処理サーバ３００，３００ａ，３００ｂが提供するＷｅｂサービスに対するリクエストを送信するクライアントコンピュータである。クライアント２００，２００ａによるリクエストは、プロキシサーバ１００により受信され、プロキシサーバ１００の後段の処理サーバ３００，３００ａ，３００ｂの何れかに転送される。クライアントの数は、３以上でもよい。クライアント２００，２００ａは、第１の実施の形態の第１の装置２，３の一例である。

処理サーバ３００，３００ａ，３００ｂは、クライアント２００，２００ａに対して共通のＷｅｂサービスを提供するサーバコンピュータである。プロキシサーバ１００により、処理サーバ３００，３００ａ，３００ｂの負荷が分散される。処理サーバ３００，３００ａ，３００ｂの数は、２または４以上でもよい。処理サーバ３００，３００ａ，３００ｂは、第１の実施の形態の第２の装置４，５の一例である。

実行サーバ４００，４００ａ，４００ｂ，４００ｃは、仮想マシン（ＶＭ：Virtual Machine）を実行可能なサーバコンピュータである。例えば、実行サーバ４００，４００ａ，４００ｂ，４００ｃは、ハイパーバイザと呼ばれるソフトウェアを実行する。実行サーバ４００のハイパーバイザは、実行サーバ４００が備えるＲＡＭやプロセッサなどのハードウェアリソースを、仮想マシンに割り当てる（他の実行サーバも同様）。実行サーバ４００，４００ａ，４００ｂ，４００ｃ上の各仮想マシンは、処理サーバ３００，３００ａ，３００ｂの指示に応じて、所定の処理を実行し、処理サーバ３００，３００ａ，３００ｂに処理結果を提供する。

例えば、クライアント２００，２００ａは、実行サーバ４００，４００ａ，４００ｂ，４００ｃの何れかによる新たな仮想マシンの起動を指示するリクエストや仮想マシンを用いた業務処理のリクエストを、プロキシサーバ１００に送信することもできる。このように、ユーザ側でコンピュータを保有せずに、データセンタ側に設けられたコンピュータのリソースを、ネットワークを介して利用する利用形態をクラウドコンピューティングと呼ぶことがある。

クラウドコンピューティングの環境を提供するサービス（クラウドサービスと称することがある）を実現するソフトウェア基盤の１つとして、例えば、Ｏｐｅｎｓｔａｃｋ（登録商標）が挙げられる。Ｏｐｅｎｓｔａｃｋでは、ＲＥＳＴ ＡＰＩ（REpresentational State Transfer Application Programming Interface）と呼ばれるＡＰＩが用いられる。ＲＥＳＴ ＡＰＩでは、システム上のリソースをＵＲＩ（Uniform Resource Identifier）と呼ばれる識別子により表す。また、リソースに対する処理内容は、ＨＴＴＰ（HyperText Transfer Protocol）メソッド（ＧＥＴやＰＯＳＴなど）により指定される。クライアント２００，２００ａは、ＨＴＴＰメソッドおよびＵＲＩを指定したリクエストを発行し、当該リクエストに対する所定の形式のレスポンスを受信する。

例えば、認証トークンを取得するリクエストは、“ＰＯＳＴ ／ｖ３／ａｕｔｈ／ｔｏｋｅｎｓ”のように表される。“ＰＯＳＴ”部分がＨＴＴＰメソッドであり、それに後続する部分がＵＲＩである。また、例えば、起動済の仮想マシンのリストを取得するリクエストは、“ＧＥＴ ／ｓｅｒｖｅｒｓ／ｄｅｔａｉｌ”のように表される。更に、例えば、仮想ネットワークの作成を指示するリクエストは、“ＰＯＳＴ ／ｖ２．０／ｎｅｔｗｏｒｋｓ”のように表される。なお、リソースに対応するＵＲＩは、システムに応じて任意に定められる。

図３は、第２の実施の形態のプロキシサーバのハードウェア例を示す図である。プロキシサーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ（Hard Disk Drive）１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。各ハードウェアはプロキシサーバ１００のバスに接続されている。

プロセッサ１０１は、プロキシサーバ１００の情報処理を制御するハードウェアである。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、プロキシサーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。

ＨＤＤ１０３は、プロキシサーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＯＳのプログラム、アプリケーションプログラム、および各種データを記憶する。プロキシサーバ１００は、ＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

画像信号処理部１０４は、プロセッサ１０１からの命令に従って、プロキシサーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１として、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。

入力信号処理部１０５は、プロキシサーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２として、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。

媒体リーダ１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信インタフェース１０７は、ネットワーク１０を介して他の装置と通信を行う。通信インタフェース１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。

クライアント２００，２００ａ、処理サーバ３００，３００ａ，３００ｂおよび実行サーバ４００，４００ａ，４００ｂ，４００ｃも、プロキシサーバ１００と同様のハードウェアを用いて実現できる。

図４は、プロキシサーバの機能例を示す図である。プロキシサーバ１００は、記憶部１１０、設定処理部１２０、プロキシ処理部１３０および待ちバッファ１４０を有する。記憶部１１０は、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域を用いて実現される。設定処理部１２０およびプロキシ処理部１３０は、ＲＡＭ１０２に記憶されたプログラムをプロセッサ１０１が実行することで実現される。待ちバッファ１４０は、ＲＡＭ１０２の記憶領域を用いて実現される。

記憶部１１０は、プロキシ処理部１３０により出力されたリクエストおよびレスポンスに関するログを記憶する。また、記憶部１１０は、リクエストのプロキシサーバ１００上での転送待ち時間（プロキシ待ち時間と称する）を記憶する。更に、記憶部１１０は、プロキシサーバ１００から処理サーバ３００，３００ａ，３００ｂに送信されたリクエストに対するレスポンスをプロキシサーバ１００が受信するまでの時間（サーバ処理時間と称する）を記憶する。

設定処理部１２０は、プロキシ処理部１３０により出力されたログを解析することで、プロキシ待ち時間やサーバ処理時間を、リクエスト毎に取得し、記憶部１１０に格納する。設定処理部１２０は、所定のタイミングで、プロキシ待ち時間の統計値およびサーバ処理時間の統計値を計算し、両統計値の比較に応じて、処理サーバ３００，３００ａ，３００ｂに対する最大同時接続数を変更する。最大同時接続数は、プロキシ処理部１３０によるリクエストの振り分け処理に用いられるパラメータである。

プロキシ処理部１３０は、クライアント２００，２００ａから受信したリクエストを、処理サーバ３００，３００ａ，３００ｂに振り分けることで、処理サーバ３００，３００ａ，３００ｂの負荷を分散させる。プロキシ処理部１３０は、例えば、ラウンドロビンや最小コネクション（既存のＴＣＰコネクション数が最小の処理サーバにリクエストを振り分ける）などの負荷分散ルールにより、リクエストの振り分けを行う。

プロキシ処理部１３０が振り分け処理に用いるパラメータには、最大同時接続数、リクエストタイムアウト時間（レスポンス待ち時間の上限）およびリトライ回数（リトライ回数の上限）などが含まれる。ここでは、最大同時接続数に着目する。最大同時接続数は、処理サーバ３００，３００ａ，３００ｂに対する同時接続数の上限である。「同時接続数」は、ある処理サーバに対し、リクエストを送信したが、当該リクエストに対するレスポンスを未受信であるリクエスト（応答待ちリクエスト）の数に相当する。すなわち、最大同時接続数は、１つの処理サーバに対する応答待ちリクエスト数の上限といえる。

プロキシ処理部１３０は、新規のリクエストを受信すると、受信したリクエストを待ちバッファ１４０（キュー）に格納する。プロキシ処理部１３０は、負荷分散ルールによりリクエストの転送先を決定し、待ちバッファ１４０に記憶されたリクエストを、決定した転送先に送信する。ただし、処理サーバ３００，３００ａ，３００ｂの全てで、応答待ちリクエストの数が最大同時接続数に達している場合、プロキシ処理部１３０は、処理サーバ３００，３００ａ，３００ｂの何れかにおける同時接続数の空きを待つ。プロキシ処理部１３０は、処理サーバ３００，３００ａ，３００ｂの何れかで、同時接続数の空きが生じると、待ちバッファ１４０に格納されたリクエストを、同時接続数に空きのある処理サーバに送信する。

なお、プロキシ処理部１３０が負荷分散ルールに最小コネクションを使用した場合のコネクション数を、応答待ちリクエストの数と考えてもよい（プロキシ処理部１３０は、応答待ちリクエストの数が最小の処理サーバに新規のリクエストを振り分けてもよい）。応答待ちのリクエストがあれば、当該リクエストの通信に対応するＴＣＰコネクションも解放されずに残留するからである。

すなわち、プロキシ処理部１３０は、新たにリクエストを受信すると、処理サーバ３００，３００ａ，３００ｂに送信済のリクエストのうち、レスポンスを未受信であるリクエストの数（応答待ちリクエスト数）を求める。そして、プロキシ処理部１３０は、応答待ちリクエスト数と最大同時接続数との比較に応じて、受信したリクエストの処理サーバ３００，３００ａ，３００ｂへの送信を制限してもよい。具体的には、プロキシ処理部１３０は、応答待ちリクエスト数が最大同時接続数に達していない処理サーバに新規のリクエストを振り分け、応答待ちリクエスト数が最大同時接続数に達している処理サーバに新規のリクエストを振り分けないように制御してもよい。

また、プロキシ処理部１３０の機能は、例えば、ＲＡＭ１０２に記憶されたＨＡＰｒｏｘｙと呼ばれるソフトウェアをプロセッサ１０１が実行することで実現されてもよい。ＨＡＰｒｏｘｙは、負荷分散機能を提供するソフトウェアである。

待ちバッファ１４０は、プロキシ処理部１３０が受信したリクエストを保持するために用いられるバッファである。待ちバッファ１４０には、キューのデータ構造によりリクエストが格納される。すなわち、プロキシ処理部１３０は、待ちバッファ１４０に先に格納されたリクエストから順番に取り出して、転送先の処理サーバに送信する。

図５は、最大同時接続数に対する各時間の測定結果の例を示す図である。図５において、横軸は時間である。左側縦軸は、同時接続数（ａｃｔｉｖｅ＿ｃｏｎｎ）である。右側縦軸は、時間（Ｔｒ，Ｔｗ，Ｔｔ）（ミリ秒）である。ここで、Ｔｒは、サーバ処理時間である。Ｔｗは、プロキシ待ち時間である。Ｔｔは、クライアントに対する応答時間であり、Ｔｔ＝Ｔｒ＋Ｔｗである。ａｃｔｉｖｅ＿ｃｏｎｎ、Ｔｒ、ＴｗおよびＴｔの各系列は、処理サーバ３００，３００ａ，３００ｂの最大同時接続数を時間経過に応じて段階的に増加させながら、大量のリクエストをプロキシサーバ１００に送信した場合の結果を表す。Ｔｒの系列は、１０秒毎のサーバ処理時間の９９パーセンタイル値である。Ｔｗの系列は、１０秒毎のプロキシ待ち時間の９９パーセンタイル値である。

図５の測定結果によれば、次のことが分かる。
期間Ｐ１では、最大同時接続数が比較的小さく設定されたために、プロキシ待ち時間（Ｔｗ）が比較的大きく増加している。

期間Ｐ２では、サーバ処理時間（Ｔｒ）とプロキシ待ち時間（Ｔｗ）との和（Ｔｔ）が比較的小さい値で安定している。
期間Ｐ３では、最大同時接続数が比較的大きく設定されたために、処理サーバ３００，３００ａ，３００ｂにおける資源競合が発生し、サーバ処理時間（Ｔｒ）が比較的大きく増加している。

図６は、最大同時接続数と各時間との関係の例を示す図である。図５の測定結果によれば、最大同時接続数に対するＴｗ，Ｔｒ，Ｔｔの関係は、それぞれ系列Ａ１，Ｂ１，Ｃ１で表される。系列Ａ１，Ｂ１によれば、サーバ処理時間とプロキシ待ち時間とは、トレードオフの関係にあることが分かる。クライアントに対する応答時間（Ｔｔ＝Ｔｒ＋Ｔｗ）は、サーバ処理時間およびプロキシ待ち時間の間に比較的大きな差がある状況下で大きく悪化する傾向にある。一方、サーバ処理時間およびプロキシ待ち時間の間の差が比較的小さい状況下では、クライアントに対する応答時間が悪化する可能性は低い傾向にある。システムの構成変更（クライアント数の増減や処理サーバ数の増減など）に対して系列Ａ１，Ｂ１，Ｃ１の全体がグラフの横軸方向に（左右に）シフトするとしても、統計値Ｔｒ，Ｔｗの差が小さいほど応答時間Ｔｔも小さくなる傾向になることは変わらない。そこで、設定処理部１２０は、図６の関係性を基に、クライアントに対する応答時間が悪化する状況を回避するように、最大同時接続数を設定する。

次に、プロキシサーバ１００により処理される情報の具体例を説明する。
図７は、プロキシ処理部により出力されるログの例を示す図である。ログ１１１は、プロキシ処理部１３０により出力される。ログ１１１は、記憶部１１０に格納される。ログ１１１に含まれる１つのレコードは複数のフィールドを含む。各フィールドは、スペースで区切られる。ログ１１１で例示される各フィールドの値は、次の情報を示す。

“ｐｒｏｘｙ［１９２１４］”は、プロキシ処理部１３０のプロセス名（ｐｒｏｘｙ）およびプロセスＩＤ（１９２１４）である。
“１７２．２０．１２１．１００：３３０７０”は、当該リクエストの送信元のクライアントのＩＰ（Internet Protocol）アドレスおよびポート番号である。

“［０８／Ｓｅｐ／２０１６：０６：１９：１６．２４３］”は、当該リクエストをプロキシ処理部１３０により受け付けた時刻である。
“ｎｏｖａ＿ｃｏｍｐｕｔｅ＿ａｐｉ＿ｃｌｕｓｔｅｒ”は、記憶部１１０に記憶されている所定の設定ファイルに記述されているフロントエンド名である。

“ｎｏｖａ＿ｃｏｍｐｕｔｅ＿ａｐｉ＿ｃｌｕｓｔｅｒ／２−８”は、当該リクエストの振り分け先の処理サーバの情報である（バックエンド名／サーバ名というフォーマットである）。

“０／０／０／１６６１／１６６１”のスラッシュ記号“／”で区切られた各値の意味は次の通りである。１つ目の値は、クライアントがＨＴＴＰリクエスト全体を送信するのを待った時間である。２つ目の値は、プロキシサーバ１００上の待ちバッファ１４０での転送待ち時間（プロキシ待ち時間）である。３つ目の値は、バックエンドサーバ（処理サーバ）との接続確立に要した時間（リトライを含む）である。４つ目の値は、バックエンドサーバ（処理サーバ）からの応答時間（サーバ処理時間に相当）である。５つ目の値は、クライアントに応答するまでに要した総時間（クライアントに対する応答時間に相当）である。

“２００”は、ＨＴＴＰステータスコードである。
“１５５１”は、クライアントへのレスポンスとして送信したバイト数である。
“８６２／７８／７６／３／０”のスラッシュ記号で区切られた各値は、前から順に次の数を示す。すなわち、“接続中コネクション数／フロントエンドの接続中コネクション数／バックエンドの接続中コネクション数／バックエンドサーバの接続中コネクション数／バックエンドサーバへの接続リトライ回数”である。

“０／０”のスラッシュ記号で区切られた各値は、前から順に次の数を示す。すなわち、“サーバキューで待機中のリクエスト数／バックエンド全体のキュー待機中リクエスト数”である。

“ＧＥＴ ／ｖ２／ｃｆ２ｂ０３ｄｂ・・・ ＨＴＴＰ／１．１”は、リクエスト（ＨＴＴＰリクエスト）の具体的な内容を示す。
図８は、履歴管理テーブルの例を示す図である。履歴管理テーブル１１２は、記憶部１１０に格納される。履歴管理テーブル１１２は、時刻、リクエスト、サーバ、処理時間および待ち時間の項目を含む。

時刻の項目には、リクエストの受信時刻が登録される。リクエストの項目には、リクエストの具体的な内容が登録される。サーバの項目には、当該リクエストの振り分け先となった処理サーバの識別情報が登録される。例えば、処理サーバ３００の識別情報は“ＳＶ１”である。処理サーバ３００ａの識別情報は“ＳＶ２”である。処理サーバ３００ｂの識別情報は“ＳＶ３”である。処理時間の項目には、当該リクエストに関するサーバ処理時間が登録される。待ち時間の項目には、プロキシ待ち時間が登録される。サーバ処理時間およびプロキシ待ち時間の単位は、秒である。

例えば、履歴管理テーブル１１２には、時刻が“０９：４８：５０．０１２”、リクエストが“ＧＥＴ ／ｖ２／ｓｅｒｖｅｒｓ”、サーバが“ＳＶ２”、処理時間が“１０．５２４”、待ち時間が“３．４９１”というレコードが登録されている。

これは、９時４８分５０．０１２秒に受信したリクエストの内容が“ＧＥＴ ／ｖ２／ｓｅｒｖｅｒｓ”であり、処理サーバ３００ａに振り分けられたこと、サーバ処理時間が１０．５２４秒であり、プロキシ待ち時間が３．４９１秒であったことを示す。

履歴管理テーブル１１２には、リクエストおよび振り分け先の処理サーバ毎に、サーバ処理時間およびプロキシ待ち時間が登録される。
図９は、統計値テーブルの例を示す図である。統計値テーブル１１３は、記憶部１１０に格納される。統計値テーブル１１３は、９０パーセンタイル処理時間および９０パーセンタイル待ち時間の項目を含む。

９０パーセンタイル処理時間の項目には、直近のＮ個（Ｎは２以上の整数）のリクエストに関するサーバ処理時間の９０パーセンタイル値が登録される。９０パーセンタイル待ち時間の項目には、直近のＮ個のリクエストに関するプロキシ待ち時間の９０パーセンタイル値が登録される。統計値テーブル１１３に登録される何れの値も、単位は秒である。

例えば、統計値テーブル１１３には、９０パーセンタイル処理時間が“８．５４”、９０パーセンタイル待ち時間が“３．４２”という情報が登録される。
ここで、９０パーセンタイル値は、統計値の一例である。９０パーセンタイル値以外にも、９５パーセンタイル値、９９パーセンタイル値または中央値（５０パーセンタイル値）などを統計値として採用してもよい。また、直近のＮ個のリクエストに関するサーバ処理時間やプロキシ待ち時間の平均値を統計値として採用してもよい。

なお、Ｍパーセンタイル値（Ｍは正の整数）は、サンプル数を１００としたとき、小さい方から数えてＭ番目に位置する値を示す。Ｎ＝１００とすると、サーバ処理時間の９０パーセンタイル値は、直近の１００個のリクエストに関するサーバ処理時間のうち、小さい方から数えて９０番目のサーバ処理時間の値である。統計値としては、例えば、９０パーセンタイル値のように、サンプルのうち、比較的大きい値を反映できる統計値を採用することが好ましい。サーバ処理時間とプロキシ待ち時間との差が表れやすいからである。

図１０は、最大同時接続数の初期設定の例である。プロキシ処理部１３０は、処理サーバ３００，３００ａ，３００ｂそれぞれに対して、同時接続数を管理する。
設定処理部１２０は、プロキシ処理部１３０による振り分け処理に用いられる最大同時接続数の設定を行う。最大同時接続数は、処理サーバ毎に設定される。ここで、処理サーバ３００，３００ａ，３００ｂを、識別情報“ＳＶ１”などに含まれる番号ｋ（ｋは自然数）で識別するものとし、処理サーバ単位の最大同時接続数をｃ_k（ｋは自然数）と表す。この場合、処理サーバ全体の最大同時接続数ｃは、ｃ＝Σｃ_kである。ここで、Σはｋについて和を計算することを表すものとする。

設定処理部１２０は、最大同時接続数ｃの初期値を、最小値ｃ_minとする。最小値ｃ_minは、例えば、クライアントへのサービス提供において最低限求められる最大同時接続数として、予め定められる。このとき、ｃ_kは、処理サーバ３００，３００ａ，３００ｂで均等になるようにする（例えば、ｃ_min＝１５であれば、ｃ_k＝１５／３＝５とする）。

リクエスト数に対して最大同時接続数ｃが小さければ、待ちバッファ１４０に溜まるリクエスト数は増す。その分、プロキシ待ち時間が増し、サーバ処理時間が減る。リクエスト数に対して最大同時接続数ｃが大きければ、待ちバッファ１４０に溜まるリクエスト数は減る。その分、プロキシ待ち時間が減り、サーバ処理時間が増す。

次に、プロキシサーバ１００の処理手順を説明する。
図１１は、プロキシサーバの処理例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。下記のステップＳ１を起点とする手順は、例えば、プロキシサーバ１００の起動後、設定処理部１２０の起動をトリガとして実行開始される。

（Ｓ１）設定処理部１２０は、プロキシ処理部１３０の振り分け処理に用いられる制御パラメータの設定を行う。制御パラメータは、統計値の計算タイミングを決めるためのＮや、最大同時接続数ｃの初期値ｃ_minを含む。例えば、設定処理部１２０は、Ｎ＝１００、ｃ_min＝１５に設定する。

（Ｓ２）設定処理部１２０は、最大同時接続数ｃを、初期値ｃ_minに設定する。この場合、処理サーバ３００，３００ａ，３００ｂの総数をＫ（＝３）とすると、処理サーバ３００，３００ａ，３００ｂそれぞれの最大同時接続数ｃ_kは、ｃ_k＝ｃ_min／Ｋ＝ｃ_min／３である。プロキシ処理部１３０は、最大同時接続数ｃ_kに基づく各処理サーバに対するリクエストの振り分け処理を開始する。

（Ｓ３）設定処理部１２０は、記憶部１１０に記憶された履歴管理テーブル１１２を初期化する。すなわち、設定処理部１２０は、履歴管理テーブル１１２に登録されているレコードを消去する。また、設定処理部１２０は、リクエストの受信回数の計数に用いられるカウンタｎを、ｎ＝０とする。

（Ｓ４）設定処理部１２０は、何れかの処理サーバにより新規に処理完了したリクエストを検出する。すると、設定処理部１２０は、ｎをインクリメントする（ｎ＋１をｎに代入する）。なお、処理完了したリクエストが発生すると、プロキシ処理部１３０は、ログ（例えば、ログ１１１）を出力し、記憶部１１０に格納する。

（Ｓ５）設定処理部１２０は、プロキシ処理部１３０により出力されたログに基づいて、プロキシ待ち時間とサーバ処理時間とを履歴管理テーブル１１２に記録する。前述のように、設定処理部１２０は、ログのレコードのうち、リクエストの受け付け時刻、リクエスト内容、処理サーバの識別情報、サーバ処理時間およびプロキシ待ち時間のフィールドを参照して、履歴管理テーブル１１２の各項目に登録する値を得る。

（Ｓ６）設定処理部１２０は、ｎ＝Ｎであるか否かを判定する。ｎ＝Ｎの場合、処理をステップＳ７に進める。ｎ＝Ｎでない場合、処理をステップＳ４に進める。
（Ｓ７）設定処理部１２０は、履歴管理テーブル１１２を参照して、サーバ処理時間の統計値Ｔｒ、および、プロキシ待ち時間の統計値Ｔｗを計算する。統計値としては、例えば、前述のように９０パーセンタイル値（あるいは、９５パーセンタイル値や９９パーセンタイル値など）を採用することが考えられる。

（Ｓ８）設定処理部１２０は、Ｔｗ≧Ｔｒであるか否かを判定する。Ｔｗ≧Ｔｒである場合、処理をステップＳ９に進める。Ｔｗ≧Ｔｒでない場合（すなわち、Ｔｗ＜Ｔｒである場合）、処理をステップＳ１０に進める。

（Ｓ９）設定処理部１２０は、最大同時接続数ｃを所定数増やす。設定処理部１２０は、処理サーバ３００，３００ａ，３００ｂの個別の最大同時接続数ｃ_kを、ｃ_k＝ｃ／Ｋの式により計算し、ｃ_kの設定を更新する。そして、処理をステップＳ３に進める。

（Ｓ１０）設定処理部１２０は、最大同時接続数ｃを所定数減らす。設定処理部１２０は、処理サーバ３００，３００ａ，３００ｂの個別の最大同時接続数ｃ_kを、ｃ_k＝ｃ／Ｋの式により計算し、ｃ_kの設定を更新する。そして、処理をステップＳ１１に進める。

（Ｓ１１）設定処理部１２０は、ｃ＜ｃ_minであるか否かを判定する。ｃ＜ｃ_minである場合、処理をステップＳ２に進める。ｃ＜ｃ_minでない場合（すなわち、ｃ≧ｃ_minである場合）、処理をステップＳ３に進める。

なお、ステップＳ９，Ｓ１０では、統計値Ｔｗ，Ｔｒの差に応じて、最大同時接続数ｃの増減幅（変更量）ｄを決定してもよい。例えば、増減幅ｄの決定に、古典制御理論における比例制御を利用することが考えられる。具体的には、次の通りである。

まず、設定処理部１２０は、下記の式（１）により、Ｔｗ，Ｔｒの差を表す指標ｅｒｒｏｒを計算する。

ここで、式（１）の分母は、ｅｒｒｏｒの値を、−１＜ｅｒｒｏｒ＜１に正規化するものである。
設定処理部１２０は、増減幅ｄを、ｄ＝ｅｒｒｏｒ×ｋ_pとする。ここで、ｋ_pは、例えば、最小値ｃ_minである。そして、ステップＳ９，Ｓ１０では、設定処理部１２０は、ｃ＋ｄをｃに代入する。

図１２は、性能劣化の抑制例を示す図である。図１２のグラフは、実行サーバ４００，４００ａ，４００ｂ，４００ｃによるＶＭ起動のリクエストを、クライアント２００，２００ａにより大量に発行させて、ＶＭ起動時間（１つ当たりの仮想マシンの起動時間の統計値）を測定した結果である。例えば、ＶＭ起動時間は、プロキシサーバ１００がＶＭ起動のリクエストを受信してから、当該ＶＭ起動のリクエストに対する起動完了のレスポンスを、リクエスト元のクライアントに送信するまでの時間に相当する。したがって、ＶＭ起動時間は、ＶＭ起動のリクエストに関するプロキシ待ち時間およびサーバ処理時間の和である。

ここで、図１２のグラフの横軸は最大同時接続数ｃである。縦軸はＶＭ起動時間（単位は秒）である。１つの最大同時接続数ｃの設定（ここでは、１５，３０，・・・，１５０まで１５ずつ増やした場合）に対して、ＶＭ起動時間の９９パーセンタイル値、９５パーセンタイル値、９０パーセンタイル値、および、中央値（５０パーセンタイル値）が示されている。ａｄａｐｔｉｖｅは、図１１の手順により、最大同時接続数ｃの設定を動的に変化させた結果である。

図１２のグラフによれば、ＶＭ起動時間が比較的長くなる最大同時接続数ｃ＝１２０，１３５，１５０の設定に対して、４０〜５０％程度、ＶＭ起動時間を改善できたことが分かる。

図１３は、最大同時接続数の変更例を示す図である。図１３のグラフの横軸は、最大同時接続数ｃを初期値で運用開始した時点からの経過時間（単位は、秒）である。図１３のグラフの左側の縦軸は、時間（サーバ処理時間、プロキシ待ち時間およびクライアントへの応答時間であり、単位はミリ秒）である。図１３のグラフの右側の縦軸は、最大同時接続数ｃの設定値である。

設定処理部１２０は、サーバ処理時間の統計値Ｔｒとプロキシ待ち時間の統計値Ｔｗとの差に応じて最大同時接続数ｃを動的に変更する。図１３の例では、経過時間０秒〜１５０秒程度の時間帯は、Ｔｗ，Ｔｒの差が比較的大きい。設定処理部１２０は、このようにＴｗ，Ｔｒの差が比較的大きい時間帯では、最大同時接続数ｃをアグレッシブに変更する（すなわち、増減幅ｄを大きくする）。一方、設定処理部１２０は、それ以降のＴｗ，Ｔｒの差が比較的小さい時間帯では、最大同時接続数ｃの増減幅ｄを小さくする。

このように、設定処理部１２０は、統計値Ｔｗ，Ｔｒの差が大きいほど、増減幅ｄを大きくし、統計値Ｔｗ，Ｔｒの差が小さいほど、増減幅ｄを小さくする。これにより、クライアントへの応答時間の減少を早めることができ、また、クライアントへの応答時間が比較的小さい状態を長い時間維持できる。

以下では、第２の実施の形態の情報処理システムで想定される他の制御例を説明する。
図１４は、最大同時接続数の他の制御例（その１）を示す図である。処理サーバ３００，３００ａ，３００ｂは、プロキシサーバ１００（図１４では外部プロキシサーバ１００と表記する）と通信する他に、内部プロキシサーバ５００を介して、相互に通信することがある。例えば、内部プロキシサーバ５００は、ネットワーク３０に接続される。この場合、外部プロキシサーバ１００は、クライアント２００，２００ａからのリクエストを処理サーバ３００，３００ａ，３００ｂに振り分ける。一方、内部プロキシサーバ５００は、処理サーバ３００，３００ａ，３００ｂからのリクエスト（ＡＰＩリクエスト）を、処理サーバ３００，３００ａ，３００ｂに振り分ける。

この場合、内部プロキシサーバ５００は、処理サーバ３００，３００ａ，３００ｂからのリクエストについては、無制限に（最大同時接続数を設けずに）処理することが考えられる。すなわち、クライアント側のリクエストの振り分けには最大同時接続数を設け、処理サーバ３００，３００ａ，３００ｂ間のリクエストの振り分けには、最大同時接続数の制限をなくすことで、処理サーバ３００，３００ａ，３００ｂの処理時間を優先的に短縮する。

図１５は、最大同時接続数の他の制御例（その２）を示す図である。プロキシサーバ１００は、クライアント２００，２００ａからのリクエストの種別によって、異なる処理サーバにリクエストを振り分けることがある。リクエストの種別は、例えば、ＨＴＴＰメソッド（ＧＥＴやＰＯＳＴなど）やＵＲＩ（リソースが画像であるか音声であるかなど）によって区分される。例えば、処理サーバ３００，３００ａ，３００ｂに加えて、処理サーバ３００ｃ，３００ｄ，３００ｅがネットワーク２０に接続されているとする。

処理サーバ３００，３００ａ，３００ｂは、第１の種別のリクエストを処理する。処理サーバ３００，３００ａ，３００ｂは、処理サーバの第１のグループに属する。また、処理サーバ３００ｃ，３００ｄ，３００ｅは、第２の種別のリクエストを処理する。処理サーバ３００ｃ，３００ｄ，３００ｅは、処理サーバの第２のグループに属する。

この場合、待ちバッファ１４０は、第１の種別のリクエストのバッファリングに用いられる。また、プロキシサーバ１００は、第２の種別のリクエストのバッファリングに用いられる待ちバッファ１４０ａを更に有する。

プロキシ処理部１３０は、クライアント２００，２００ａから受信したリクエストの種別を判定し、判定された種別に応じて、何れかのグループの待ちバッファに、受信したリクエストを振り分ける（第１段階の振り分け）。すなわち、プロキシ処理部１３０は、クライアント２００，２００ａから受信した第１の種別のリクエストを待ちバッファ１４０に格納する。また、プロキシ処理部１３０は、クライアント２００，２００ａから受信した第２の種別のリクエストを待ちバッファ１４０ａに格納する。そして、振り分け先のグループ内で、当該リクエストの処理サーバへの振り分けを行う（第２段階の振り分け）。

この場合、設定処理部１２０は、第１のグループおよび第２のグループについて、別個に、履歴管理テーブル１１２および統計値テーブル１１３を作成する。そして、設定処理部１２０は、処理サーバ３００，３００ａ，３００ｂが属する第１のグループに対して最大同時接続数を設定する。また、設定処理部１２０は、処理サーバ３００ｃ，３００ｄ，３００ｅが属する第２のグループに対して最大同時接続数を設定する。

ここで、例えば、処理サーバ３００，３００ａ，３００ｂが比較的負荷の大きい処理（例えば比較的サイズの大きな画像データなどを扱う処理など）を主に行う場合がある。一方、処理サーバ３００ｃ，３００ｄ，３００ｅが比較的負荷の小さい処理（例えば比較的サイズの小さなデータを扱う処理など）を主に行う場合がある。このような場合に、両サーバ群に対するリクエストを混在させて統計値Ｔｗ，Ｔｒを取得すると、両サーバ群による処理内容の違いに見合った最大同時接続数を設定するのが難しくなる。そこで、上記のように、設定処理部１２０は、リクエストの種別に応じた処理サーバのグループ毎に、最大同時接続数を調整することで、処理サーバ側の処理内容に応じた最大同時接続数を設定できる。

なお、設定処理部１２０は、リクエストの種別毎に異なるタイミングで、最大同時接続数の変更を行ってもよい。例えば、設定処理部１２０は、履歴管理テーブル１１２および統計値テーブル１１３をリクエストの種別毎に設け、図１１の手順をリクエストの種別毎に並行して行ってもよい。

図１６は、最大同時接続数の他の制御例（その３）を示す図である。処理サーバ３００，３００ａ，３００ｂは、非同期処理を行うことがある。非同期処理とは、処理サーバ３００によるレスポンスの送信後に、処理サーバ３００内でリクエストに応じて実行される処理である。非同期処理に関する具体的なシーケンスは次の通りである。（１）プロキシサーバ１００は、リクエストを受信する。（２）プロキシサーバ１００は、処理サーバ３００にリクエストを送信する。（３）処理サーバ３００は、リクエストに応じたレスポンスをプロキシサーバ１００に送信する。（４）処理サーバ３００は、リクエストに応じた処理を非同期に実行する（非同期処理の実行）。

この場合、設定処理部１２０は、非同期処理を考慮して、サーバ処理時間の統計値Ｔｒを求めてもよい。
図１７は、他の制御例（その３）における履歴管理テーブルの例を示す図である。例えば、記憶部１１０は、履歴管理テーブル１１２に非同期処理時間の項目を追加した履歴管理テーブル１１２ａを、履歴管理テーブル１１２の代わりに記憶する。

非同期処理時間の項目には、リクエストの転送先の処理サーバにおける非同期処理の実行時間（単位は秒）が登録される。例えば、履歴管理テーブル１１２ａには、リクエスト“ＧＥＴ ／ｖ２／ｓｅｒｖｅｒｓ”に対して、処理サーバ３００ａにおける非同期処理時間が“０”（秒）というレコードが登録されている。また、履歴管理テーブル１１２ａには、リクエスト“ＨＥＡＤ ／ｖ１／ｕｓｅｒ”に対して、処理サーバ３００における非同期処理時間が“４．３９８”（秒）というレコードも登録されている。

設定処理部１２０は、例えば、各リクエストに関する非同期処理時間を、処理サーバ３００，３００ａ，３００ｂに問合せることで、各リクエストに関する非同期処理時間を処理サーバ３００，３００ａ，３００ｂから取得してもよい。あるいは、処理サーバ３００，３００ａ，３００ｂにより実行された処理のログを受信するＳｙｓｌｏｇサーバを、プロキシサーバ１００で動作させてもよい。この場合、設定処理部１２０は、Ｓｙｓｌｏｇサーバにより取得されたログを解析することで、各リクエストの非同期処理時間を取得する。

設定処理部１２０は、履歴管理テーブル１１２ａにおいて、処理時間の項目に記録された時間の統計値に、非同期処理時間の統計値を加算した値を、サーバ処理時間の統計値Ｔｒとする。例えば、設定処理部１２０は、統計値テーブル１１３ａに示されるように、履歴管理テーブル１１２ａにおける処理時間の値の９０パーセンタイル値（８．５４）と、非同期処理時間の値の９０パーセンタイル値（３．４２８）とを加算した値をＴｒとする。すなわち、設定処理部１２０は、図１５までに説明したサーバ処理時間の統計値を、処理サーバ３００，３００ａ，３００ｂによる非同期処理時間（または、非同期処理時間の統計値）に基づいて補正し、補正後の値を、サーバ処理時間の統計値Ｔｒとして採用する。

このように、設定処理部１２０は、非同期処理時間を考慮したサーバ処理時間の統計値Ｔｒを用いて、最大同時接続数の設定を行ってもよい。これにより、最大同時接続数の設定に対して、処理サーバ３００，３００ａ，３００ｃの負荷を、より適切に反映させることができる。

ここで、例えば、最大同時接続数を設定するために、図６の関係性を事前に調査して、クライアントに対する応答時間Ｔｔが極小となる最大同時接続数をプロキシサーバ１００に予め設定しておくことが考えられる。しかし、調査時の環境がその後も常に維持されるとは限らない。例えば、クライアントの数が増減したり、あるいは、処理サーバの数が増えたりすると、応答時間Ｔｔが極小をとる最大同時接続数は変わり得る。また、調査時と現実の運用の環境が必ずしも一致しているとも限らない。このように、事前の調査などに基づく静的な設定では、クラウドサービスにおけるサービス品質の劣化を抑制できない可能性がある。

そこで、設定処理部１２０は、図６における系列Ａ１，Ｂ１，Ｃ１にみられる、システム構成の変換に依らない特性に着目して、最大同時接続数を変更する。すなわち、系列Ａ１，Ｂ１によれば、最大同時接続数が小さいほど、プロキシ待ち時間の統計値Ｔｗが、サーバ処理時間の統計値Ｔｒよりも大きくなる傾向にある。一方、系列Ａ１，Ｂ１によれば、最大同時接続数が大きいほど、サーバ処理時間の統計値Ｔｒが、プロキシ待ち時間の統計値Ｔｗよりも大きくなる傾向にある。したがって、設定処理部１２０は、統計値Ｔｗ，Ｔｒを比較し、統計値Ｔｒ，Ｔｗに差がある場合に、最大同時接続数を変更する。

具体的には、設定処理部１２０は、プロキシ待ち時間の統計値Ｔｗがサーバ処理時間の統計値Ｔｒ以上の場合、最大同時接続数を増やす。一方、設定処理部１２０は、プロキシ待ち時間の統計値Ｔｗがサーバ処理時間の統計値Ｔｒよりも小さい場合、最大同時接続数を減らす。これにより、クライアントに対する応答時間Ｔｔを極小値に近い値にシフトさせる。

このように、設定処理部１２０は、処理サーバ３００，３００ａ，３００ｂに対する最大同時接続数を動的に変更することで、応答性能の劣化を抑制するように最大同時接続数を調整可能になる。特に、事前の調査などによって最大同時接続数を静的に設定するよりも、クライアントに対する応答時間の劣化を抑えることができる。例えば、処理サーバ３００，３００ａ，３００ｂへの負荷が時間によって変動する場合や障害が発生した場合でも、応答時間の劣化を抑えることができる。その結果、クラウドサービスにおけるサービス品質の向上を図れる。

なお、第１の実施の形態の情報処理は、処理部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。

例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

１ 振り分け装置
１ａ 記憶部
１ｂ 処理部
２，３ 第１の装置
４，５ 第２の装置
６，７ ネットワーク
Ａ，Ｂ，Ｃ 系列
ｄ１ バッファ

Claims (9)

1. 第１の装置により送信されたリクエストを受信してから前記リクエストを第２の装置に送信するまでの第１の時間と、前記第２の装置に前記リクエストを送信してから前記リクエストに対するレスポンスを受信するまでの第２の時間とを、複数のリクエストそれぞれに対して記録し、
   前記第１の時間の統計値と前記第２の時間の統計値との比較に応じて、前記第２の装置に対する同時接続数の上限を変更する、
   処理をコンピュータに実行させる接続数制御プログラム。
2. 前記上限の変更では、前記第１の時間の統計値が前記第２の時間の統計値以上の場合、前記上限を増やす、請求項１記載の接続数制御プログラム。
3. 前記上限の変更では、前記第１の時間の統計値が前記第２の時間の統計値よりも小さい場合、前記上限を減らす、請求項１または２記載の接続数制御プログラム。
4. 前記上限の変更では、前記第１の時間の統計値と前記第２の時間の統計値との差に応じて、変更量を決定する、請求項１乃至３の何れか１項に記載の接続数制御プログラム。
5. 前記上限の変更では、前記第１の時間の統計値と前記第２の時間の統計値とを前記リクエストの種別毎に求め、前記上限を前記種別毎に変更する、請求項１乃至４の何れか１項に記載の接続数制御プログラム。
6. 前記第１の時間および前記第２の時間の記録では、前記第２の装置による前記レスポンスの送信後に前記リクエストに応じて前記第２の装置により実行された非同期処理の実行時間を更に記録し、
   前記上限の変更では、前記非同期処理の実行時間に基づいて、前記第２の時間の統計値を補正する、
   請求項１乃至５の何れか１項に記載の接続数制御プログラム。
7. 前記第１の装置から前記リクエストを受信すると、前記第２の装置に送信済の前記リクエストのうち、前記レスポンスを未受信である前記リクエストの数と前記上限との比較に応じて、受信した前記リクエストの前記第２の装置への送信を制限する、処理を更に前記コンピュータに実行させる請求項１乃至６の何れか１項に記載の接続数制御プログラム。
8. 第１の装置により送信されたリクエストを受信してから前記リクエストを第２の装置に送信するまでの第１の時間と、前記第２の装置に前記リクエストを送信してから前記リクエストに対するレスポンスを受信するまでの第２の時間とを、複数のリクエストそれぞれに対して記憶する記憶部と、
   前記第１の時間と前記第２の時間とを前記記憶部に記録し、前記第１の時間の統計値と前記第２の時間の統計値との比較に応じて、前記第２の装置に対する同時接続数の上限を変更する処理部と、
   を有する振り分け装置。
9. コンピュータが、
   第１の装置により送信されたリクエストを受信してから前記リクエストを第２の装置に送信するまでの第１の時間と、前記第２の装置に前記リクエストを送信してから前記リクエストに対するレスポンスを受信するまでの第２の時間とを、複数のリクエストそれぞれに対して記録し、
   前記第１の時間の統計値と前記第２の時間の統計値との比較に応じて、前記第２の装置に対する同時接続数の上限を変更する、
   接続数制御方法。

Images