(57)【要約】【課題】  ＷｅｂＳｏｃｋｅｔ接続されてなるシステムにおいて、通信中のアプリケーションサーバが通信不可になった場合、それを早期に検知し、自動的かつ短時間で、新たなＷｅｂＳｏｃｋｅｔ接続を確立すること。【解決手段】  実施形態によれば、クライアントアプリケーションと、複数のアプリケーションサーバのうちの何れかのアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続を確立するための負荷分散装置であって、複数のアプリケーションサーバを監視するとともに、ＷｅｂＳｏｃｋｅｔ接続によって通信しているアプリケーションサーバとの通信状態を検知する監視部と、アプリケーションサーバとの通信不可が検知された場合、通信可能なアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する接続管理部とを備える。【選択図】図１
2019057091.tif 000002
【特許請求の範囲】
【請求項１】
クライアントアプリケーションと、複数のアプリケーションサーバのうちの何れかのアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続を確立するための負荷分散装置であって、
前記複数のアプリケーションサーバを監視するとともに、前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているアプリケーションサーバとの通信状態を検知する監視部と、
前記アプリケーションサーバとの通信不可が検知された場合、通信可能なアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する接続管理部と、
を備える負荷分散装置。
【請求項２】
クライアントアプリケーションと、複数のアプリケーションサーバのうちの何れかのアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続を仲介するための負荷分散装置であって、
前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているクライアントアプリケーションとアプリケーションサーバとを示す接続情報を記憶する記憶部と、
前記複数のアプリケーションサーバを監視するとともに、前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているアプリケーションサーバとの通信状態を検知する監視部と、
前記通信しているアプリケーションサーバとの通信不可が検知された場合、前記記憶部に記憶された接続情報に基づいて、前記通信不可が検知されたアプリケーションサーバと前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているクライアントアプリケーションを特定し、前記特定されたクライアントアプリケーションとのＷｅｂＳｏｃｋｅｔ接続を維持しながら、通信可能なアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する接続管理部と、
を備える負荷分散装置。
【請求項３】
前記接続管理部によって特定されたクライアントアプリケーションに対して、前記ＷｅｂＳｏｃｋｅｔ接続の再接続が必要であることを通知する通知部、をさらに備える請求項２に記載の負荷分散装置。
【請求項４】
前記通知部によって通知されたクライアントアプリケーションから、前記再接続の要求があった場合に、前記接続管理部が、通信不可が検知されなかったアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する、請求項３に記載の負荷分散装置。
【請求項５】
前記接続管理部は、通信不可が検知されなかったアプリケーションサーバから、予め定められた負荷分散アルゴリズムに従って、前記ＷｅｂＳｏｃｋｅｔ接続を確立すべきアプリケーションサーバを選択する、請求項１乃至４のうち何れか１項に記載の負荷分散装置。
【請求項６】
クライアントアプリケーションと、複数のアプリケーションサーバのうちの何れかのアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続を確立するためにプロセッサによって実施される負荷分散方法であって、
前記プロセッサが、
前記複数のアプリケーションサーバを監視するとともに、前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているアプリケーションサーバとの通信状態を検知し、
前記アプリケーションサーバとの通信不可が検知された場合、通信可能なアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立するようにした、負荷分散方法。
【請求項７】
クライアントアプリケーションと、複数のアプリケーションサーバのうちの何れかのアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続を仲介するためにプロセッサによって実施される負荷分散方法であって、
前記プロセッサが、
前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているクライアントアプリケーションとアプリケーションサーバとを示す接続情報を記憶装置に記憶し、
前記複数のアプリケーションサーバを監視するとともに、前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているアプリケーションサーバとの通信状態を検知し、
前記通信しているアプリケーションサーバとの通信不可が検知された場合、前記記憶装置に記憶された接続情報に基づいて、前記通信不可が検知されたアプリケーションサーバと前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているクライアントアプリケーションを特定し、
前記特定されたクライアントアプリケーションとのＷｅｂＳｏｃｋｅｔ接続を維持しながら、通信可能なアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する、負荷分散方法。
【請求項８】
前記プロセッサはさらに、前記特定されたクライアントアプリケーションに対して、前記ＷｅｂＳｏｃｋｅｔ接続の再接続が必要であることを通知する、請求項７に記載の負荷分散方法。
【請求項９】
前記プロセッサはさらに、前記通知されたクライアントアプリケーションから、前記再接続の要求があった場合に、通信不可が検知されなかったアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する、請求項８に記載の負荷分散方法。
【請求項１０】
前記プロセッサはさらに、通信不可が検知されなかったアプリケーションサーバから、予め定められた負荷分散アルゴリズムに従って、前記ＷｅｂＳｏｃｋｅｔ接続を確立すべきアプリケーションサーバを選択する、請求項６乃至９のうち何れか１項に記載の負荷分散方法。
【請求項１１】
クライアントアプリケーションと、複数のアプリケーションサーバのうちの何れかのアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続を確立するためのプログラムであって、
前記複数のアプリケーションサーバを監視するとともに、前記ＷｅｂＳｏｃｋｅｔ接続によって通信しているアプリケーションサーバとの通信状態を検知する機能と、
前記アプリケーションサーバとの通信不可が検知された場合、通信可能なアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する機能と、をコンピュータに実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ＷｅｂＳｏｃｋｅｔが適用されたネットワーク環境に適用される負荷分散装置、負荷分散方法、およびプログラムに関する。
【背景技術】
【０００２】
従来、ｈｔｔｐプロトコル（以下、単に「ｈｔｔｐ」と称する）をベースとしたＷｅｂアプリケーションシステムでは、クライアントアプリケーションからアプリケーションサーバへの負荷集中の回避や、可用性向上のために、クライアントアプリケーションとアプリケーションサーバとの間に、負荷分散装置が設けられている。そして、負荷分散装置によって、クライアントアプリケーションからのリクエストが、複数のアプリケーションサーバのうちの何れかに振り分けられている。この振り分け処理によって、特定のアプリケーションサーバへの負荷の集中が回避されている。
【０００３】
負荷分散装置によってなされる振り分け処理のための負荷分散アルゴリズムのメカニズムとしては、クライアントアプリケーションと、接続先のアプリケーションサーバとの対応付けの事前設定に基づく方式、各アプリケーションサーバのＣＰＵ使用率に基づく方式、各アプリケーションサーバへの監視リクエストに対する応答遅延時間に基づく方式、ラウンドロビン方式、アプリケーションサーバへのクライアント接続数に基づく方式等が知られている。
【０００４】
ところで、ｈｔｔｐが適用されたＷｅｂアプリケーションシステムでは、クライアントアプリケーションからのリクエスト毎に、クライアントアプリケーションとアプリケーションサーバとの間に接続リンクが確立される。そして、この接続リンクは、リクエストに対する応答が終了すると解除される。このように、接続リンクは、リクエスト毎に不連続的に確立される。
【０００５】
一方、近年、ｈｔｔｐの発展形であるＷｅｂＳｏｃｋｅｔプロトコル（以下、単に「ＷｅｂＳｏｃｋｅｔ」と称する）の利用も進んでいる。そして、ＷｅｂＳｏｃｋｅｔが適用されたＷｅｂアプリケーションシステムにおいても同様に、負荷分散装置が利用されている。
【０００６】
ＷｅｂＳｏｃｋｅｔが適用されたＷｅｂアプリケーションシステムでは、クライアントアプリケーションとアプリケーションサーバとの間で、ＷｅｂＳｏｃｋｅｔが適用された接続（以下、「ＷｅｂＳｏｃｋｅｔ接続」と称する）が一旦確立されると、クライアントアプリケーションとアプリケーションサーバでは、ＷｅｂＳｏｃｋｅｔ接続が切断されるまで、ともにＴＣＰコネクションが維持される。そのため、ＷｅｂＳｏｃｋｅｔは、クライアントサーバと、アプリケーションサーバとの間での双方向リアルタイム通信の実現のために適用されている。
【０００７】
ＷｅｂＳｏｃｋｅｔが適用されたＷｅｂアプリケーションシステムでは、一般にクライアントアプリケーションとアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続が確立されると、切断されるまでの間に発生したクライアントからのリクエストは、情報の一貫性を保つために、負荷分散装置によって、同一のアプリケーションサーバへ振り分けられる。
【０００８】
ＷｅｂＳｏｃｋｅｔでは、一般に、接続先との通信の正常性を確認するために、ｐｉｎｇ／ｐｏｎｇメッセージという機能が備えられている。したがって、Ｗｅｂアプリケーションシステムでは、ｐｉｎｇ／ｐｏｎｇメッセージが、クライアントアプリケーションとアプリケーションサーバとの間で定期的に通信されることによって、通信の正常性が確認される。
【０００９】
ｐｉｎｇ／ｐｏｎｇメッセージの交換周期は、一般に、３０秒〜１分である。従って、アプリケーションサーバが故障等によって通信不可となった場合、通信不可をクライアントアプリケーションへ通知するためには、３０秒〜１分程度の時間を要する。よって、クライアントアプリケーションは、その間、アプリケーションサーバと通信できないことになり、双方向リアルタイム通信を実現できなくなってしまう。
【００１０】
ｐｉｎｇ／ｐｏｎｇメッセージの交換周期は変更可能である。したがって、交換周期を短縮すれば、通信不可の検知に要する時間も短縮化される。しかしながら、アプリケーションサーバは、接続先の全てのクライアントアプリケーションとｐｉｎｇ／ｐｏｎｇメッセージの通信を行う必要がある。例えば、多数のクライアントアプリケーションを接続して構成される大規模なＷｅｂＳｏｃｋｅｔシステムでは、１つのアプリケーションサーバに接続されているクライアントアプリケーションの数は、数千にもなりうる。このため、ｐｉｎｇ／ｐｏｎｇメッセージの交換周期をわずかに短縮しただけでも、アプリケーションサーバのＣＰＵリソースの消費量は著しく増加してしまう。
【００１１】
したがって、多数のクライアントアプリケーションを接続して構成される大規模なＷｅｂＳｏｃｋｅｔシステムでは、アプリケーションサーバの通信不可を早期に検知するために、ｐｉｎｇ／ｐｏｎｇメッセージを利用することは現実的ではない。
【００１２】
一方で負荷分散装置では、アプリケーションサーバの故障等による通信不可を早期に検知するために、負荷分散装置によって定期的になされる死活監視が利用されている。死活監視の方式としては、負荷分散装置から各アプリケーションサーバへのＩＣＭＰによる接続確認や、アプリケーションサーバ内の監視ページへの接続確認等が知られている。この種の死活監視によれば、監視周期を１秒とすれば、アプリケーションサーバの通信不可を１秒以内に検知することができるので、アプリケーションサーバの負荷を増加させることなく、検知速度を格段に高めることができる。
【００１３】
これによって、クライアントアプリケーションからの新たなリクエストは、負荷分散装置によって、故障等により通信不可になったアプリケーションサーバへはもはや振り分けられず、新たにＷｅｂＳｏｃｋｅｔ接続したアプリケーションサーバへ振り分けられるようになる。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２０１５−１７０２８６号公報
【特許文献２】特開２０１５−１１８４８０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
しかしながら、ＷｅｂＳｏｃｋｅｔ接続は、クライアントアプリケーションからの接続リクエストに基づいて行われる。したがって、アプリケーションサーバの通信不可検知が早期になされても、クライアントアプリケーションがそれに気付き、接続リクエストを発行しない限り、新たなＷｅｂＳｏｃｋｅｔ接続は確立されない。
【００１６】
よって、クライアントアプリケーションが、アプリケーションサーバが通信不可であることに気付かなければ、新たなＷｅｂＳｏｃｋｅｔ接続は確立されず、クライアントアプリケーションが、アプリケーションサーバの通信不可に気付き、接続要求を発行するまでの間、クライアントアプリケーションは、アプリケーションサーバと通信することができず、双方向リアルタイム通信を実現できなくなるという問題がある。
【００１７】
本発明が解決しようとする課題は、クライアントアプリケーションとアプリケーションサーバとがＷｅｂＳｏｃｋｅｔ接続されてなるシステムにおいて、通信中のアプリケーションサーバが通信不可になった場合、それを早期に検知し、自動的かつ短時間で、新たなＷｅｂＳｏｃｋｅｔ接続を確立することが可能な負荷分散装置、負荷分散方法、およびプログラムを提供することである。
【課題を解決するための手段】
【００１８】
実施形態の負荷分散装置は、クライアントアプリケーションと、複数のアプリケーションサーバのうちの何れかのアプリケーションサーバとの間のＷｅｂＳｏｃｋｅｔ接続を確立するための負荷分散装置であって、複数のアプリケーションサーバを監視するとともに、ＷｅｂＳｏｃｋｅｔ接続によって通信しているアプリケーションサーバとの通信状態を検知する監視部と、アプリケーションサーバとの通信不可が検知された場合、通信可能なアプリケーションサーバとのＷｅｂＳｏｃｋｅｔ接続を確立する接続管理部とを備える。
【図面の簡単な説明】
【００１９】
【図１】第１の実施形態の負荷分散装置が適用されたＷｅｂＳｏｃｋｅｔシステムの構成例を示す概要図である。
【図２】負荷分散装置の構成例を示すブロック図である。
【図３】負荷分散装置によってなされるＷｅｂＳｏｃｋｅｔ接続処理の流れを示すシーケンス図である。
【図４】ＷｅｂＳｏｃｋｅｔ接続マップの構成例を示すデータテーブルである。
【図５】負荷分散装置によってなされる双方向リアルタイム通信時の処理の流れを示すシーケンス図である。
【図６】負荷分散装置によってなされるアプリケーションサーバの通信不可検知処理の流れを示すシーケンス図である。
【図７】ＷｅｂＳｏｃｋｅｔシステムを適用して構成される電子商取引システムの構成例を示すブロック図である。
【図８】第２の実施形態の負荷分散装置によってなされるアプリケーションサーバの通信不可検知処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【００２０】
以下に、本発明の各実施形態の負荷分散方法が適用された負荷分散装置を、図面を参照して説明する。
【００２１】
（第１の実施形態）
図１は、第１の実施形態の負荷分散装置１０が適用されたＷｅｂＳｏｃｋｅｔシステム４０の構成例を示す概要図である。
【００２２】
ＷｅｂＳｏｃｋｅｔシステム４０は、クライアントアプリケーション２０と、アプリケーションサーバ群３０との間に、負荷分散装置１０を設けて構成される。
【００２３】
クライアントアプリケーション２０は、クライアント端末２１によって操作されるＷｅｂアプリケーションである。クライアントアプリケーション２０には、１つまたは複数のクライアント端末２１（１）〜２１（ｍ）が接続される（ｍは、１以上の整数）。クライアント端末２１は、例えばユーザのパソコンやスマートフォン等であり、有線や無線を介してクライアントアプリケーション２０にアクセスすることができる通信端末である。
【００２４】
また、アプリケーションサーバ群３０は、複数のアプリケーションサーバ３１（１）〜３１（ｎ）を含んでいる（ｎは、１以上の整数）。
【００２５】
負荷分散装置１０は、クライアントアプリケーション２０と、アプリケーションサーバ３１との間のＷｅｂＳｏｃｋｅｔ接続を実現するために、クライアントアプリケーション２０からのＷｅｂＳｏｃｋｅｔ接続を終端するＷｅｂＳｏｃｋｅｔサーバとして機能する。
【００２６】
負荷分散装置１０はさらに、予め決定された負荷分散アルゴリズムに従って、クライアントアプリケーション２０と通信するアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））をアプリケーションサーバ群３０から選択した後、改めてＷｅｂＳｏｃｋｅｔクライアントとして、クライアントアプリケーション２０とアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））とを接続する。
【００２７】
このようにして、負荷分散装置１０は、クライアントアプリケーション２０とアプリケーションサーバ３１との間のＷｅｂＳｏｃｋｅｔ接続を実現する。
【００２８】
このようなＷｅｂＳｏｃｋｅｔ接続を実現するために、負荷分散装置１０は、図２のブロック図に例示されるような構成をしている。
【００２９】
負荷分散装置１０は、ＷｅｂＳｏｃｋｅｔサーバ部１１、ＷｅｂＳｏｃｋｅｔ接続管理部１２、ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３、死活監視部１５、負荷分散処理部１６、およびＷｅｂＳｏｃｋｅｔクライアント部１７を備える。
【００３０】
ＷｅｂＳｏｃｋｅｔサーバ部１１、ＷｅｂＳｏｃｋｅｔ接続管理部１２、死活監視部１５、負荷分散処理部１６、およびＷｅｂＳｏｃｋｅｔクライアント部１７は、例えばＦＰＧＡ（field-programmable gate array）もしくはＣＰＵ（Central Processing Unit）もしくはこれらの組合せおよびプログラムメモリ（例えばＳＳＤ（Solid State Drive）やＨＤＤ（Hard Disk Drive）等の随時書き込みおよび読み出しが可能な不揮発性メモリ）を有するコンピュータによって実現され、本実施形態を実施するために必要な制御機能を実現する。これら制御機能はいずれも上記プログラムメモリに格納されたプログラムを上記ＦＰＧＡやＣＰＵに実行させることにより実現される。ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３は、プログラムメモリ（例えばＳＳＤ（Solid State Drive）やＨＤＤ（Hard Disk Drive）等の随時書き込みおよび読み出しが可能な不揮発性メモリ）により実現される。
【００３１】
図３は、負荷分散装置１０によってなされるＷｅｂＳｏｃｋｅｔ接続処理の流れを示すシーケンス図である。
【００３２】
ＷｅｂＳｏｃｋｅｔ接続を実現するためには、先ず、ユーザがクライアント端末２１を用いてクライアントアプリケーション２０にアクセスし、クライアントアプリケーション２０を起動する。クライアントアプリケーション２０は、起動後、負荷分散装置１０に対してＷｅｂＳｏｃｋｅｔ接続要求Ａを送信する（Ｓ１）。
【００３３】
負荷分散装置１０は、ＷｅｂＳｏｃｋｅｔ接続要求Ａを、ＷｅｂＳｏｃｋｅｔサーバ部１１において受信する。ＷｅｂＳｏｃｋｅｔサーバ部１１は、ＷｅｂＳｏｃｋｅｔ接続要求Ａの送信元のクライアントアプリケーション２０から、クライアントアプリケーション２０のクライアントＩＤを把握し、把握したクライアントＩＤと、ＷｅｂＳｏｃｋｅｔ接続要求Ａとを、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力する（Ｓ２）。
【００３４】
ＷｅｂＳｏｃｋｅｔ接続管理部１２は、ＷｅｂＳｏｃｋｅｔサーバ部１１から出力されたクライアントＩＤとＷｅｂＳｏｃｋｅｔ接続要求Ａとに基づいて、後述する図４に示すように、ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３に記憶されているＷｅｂＳｏｃｋｅｔ接続マップ１４を更新する（Ｓ３）とともに、アプリケーションサーバ選択要求Ｂを生成する。そして、アプリケーションサーバ選択要求Ｂを、クライアントＩＤとともに負荷分散処理部１６へ出力する（Ｓ４）。
【００３５】
図４は、ＷｅｂＳｏｃｋｅｔ接続マップ１４の構成例を示すデータテーブルである。
【００３６】
コネクションＩＤ  ａは、ＷｅｂＳｏｃｋｅｔ接続の識別番号を示し、クライアントＩＤ  ｂは、接続元のクライアントアプリケーション２０のクライアントＩＤを示し、アプリケーションサーバＩＤ  ｄは、接続先のアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））のＩＤを示し、ＷｅｂＳｏｃｋｅｔクライアントＩＤ  ｃは、接続先のアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））と通信するＷｅｂクライアント部１７（例えば、Ｗｅｂクライアント部１７（１））のＩＤを示し、通信状態ｅは、クライアントアプリケーション２０とアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））との間の通信状態を示す。通信状態ｅは、ＷｅｂＳｏｃｋｅｔ接続が完了し、通信している状態を示す「通信中」、ＷｅｂＳｏｃｋｅｔ接続されていないが、アプリケーションサーバＩＤ  ｄに該当するアプリケーションサーバ３１が故障しておらず、ＷｅｂＳｏｃｋｅｔ接続可能な状態である「接続可能」、アプリケーションサーバＩＤ  ｄに該当するアプリケーションサーバ３１と通信できない状態を示す「通信不可」等を含むが、その他必要な状態を適宜設定しても良い。例えば、「通信不可」である状態が、具体的に故障によるものであれば、さらに「故障中」という状態を設定しても良い。
【００３７】
再び図２および図３を参照して説明する。
【００３８】
ＷｅｂＳｏｃｋｅｔクライアント部１７は、複数（例えばｎ個）存在し、それぞれが、アプリケーションサーバ３１と１対１で対応している。
【００３９】
死活監視部１５は、アプリケーションサーバ群３０内の各アプリケーションサーバ３１（１）〜３１（ｎ）の死活監視を、定期的（例えば、１秒間隔程度）に実行する（Ｓ５）。そして、生存している（故障しておらず、正常に動作する）アプリケーションサーバ３１を示す生存情報Ｄを生成する。
【００４０】
死活監視部１５によってなされる死活監視の方式は、各アプリケーションサーバ３１（１）〜３１（ｎ）へのＩＣＭＰによる接続確認、アプリケーションサーバ（１）〜３１（ｎ）内の監視ページへの接続確認等を含むが、これらに限定されるものではない。
【００４１】
負荷分散処理部１６は、死活監視部１５から生存情報Ｄを取得し（Ｓ６）、生存情報Ｄと負荷分散アルゴリズムとに従って、接続元のクライアントアプリケーション２０が接続すべきアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））を選択し、選択結果Ｅを、接続元のクライアントアプリケーション２０のクライアントＩＤとともに、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力する（Ｓ７）。
【００４２】
接続すべきアプリケーションサーバ３１を選択するための負荷分散アルゴリズムのメカニズムは、クライアントアプリケーション２０と、接続先のアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））との対応付けの事前設定に基づく方式、各アプリケーションサーバ３１（１）〜３１（ｎ）のＣＰＵ使用率に基づく方式、各アプリケーションサーバ３１（１）〜３１（ｎ）への監視リクエストに対する応答遅延時間に基づく方式、ラウンドロビン方式、アプリケーションサーバへのクライアント接続数に基づく方式等があるが、これらに限定されるものではない。
【００４３】
次に、ＷｅｂＳｏｃｋｅｔ接続管理部１２が、選択結果Ｅに基づいて、対応するＷｅｂＳｏｃｋｅｔクライアント部１７へ、クライアントＩＤと、アプリケーションサーバ３１への接続指示Ｆとを出力する（Ｓ８）。例えば、選択結果Ｅが、アプリケーションサーバ３１（１）へ接続すべきであることを示すのであれば、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、アプリケーションサーバ３１（１）に対応するＷｅｂＳｏｃｋｅｔクライアント部１７（１）へ、クライアントＩＤと接続指示Ｆとを出力するという具合である。
【００４４】
接続指示Ｆを出力されたＷｅｂＳｏｃｋｅｔクライアント部１７は、接続元のクライアントアプリケーション２０の代わりに、限定される訳ではないが、例えばＲＦＣ６４５５に記載されているようなＷｅｂＳｏｃｋｅｔ接続手順に従って、アプリケーションサーバ３１とＷｅｂＳｏｃｋｅｔ接続を確立する（Ｓ９）。
【００４５】
ＷｅｂＳｏｃｋｅｔ接続が確立されたＷｅｂＳｏｃｋｅｔクライアント部１７は、接続元のクライアントアプリケーション２０のクライアントＩＤと、ＷｅｂＳｏｃｋｅｔ接続が確立したことを示す確立情報Ｇとを、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力する（Ｓ１０）。
【００４６】
出力されたクライアントＩＤおよび確立情報Ｇに基づいて、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、例えば図４に示すように、ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３に記憶されているＷｅｂＳｏｃｋｅｔ接続マップ１４を更新する（Ｓ１１）。さらに、更新されたＷｅｂＳｏｃｋｅｔ接続マップ１４に従って、ＷｅｂＳｏｃｋｅｔサーバ部１１に対して、クライアントＩＤ  ｂに対応するクライアントアプリケーション２０とのＷｅｂＳｏｃｋｅｔ接続を確立するように指示する接続指示Ｈを出力する（Ｓ１２）。
【００４７】
この接続指示Ｈに応じて、ＷｅｂＳｏｃｋｅｔサーバ部１１は、クライアントＩＤ  ｂに対応するクライアントアプリケーション２０とのＷｅｂＳｏｃｋｅｔ接続を確立する（Ｓ１３）。そして、このＷｅｂＳｏｃｋｅｔ接続が確立すると、ＷｅｂＳｏｃｋｅｔサーバ部１１は、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ、接続確立応答Ｉと、対応するクライアントアプリケーション２のクライアントＩＤとを出力する（Ｓ１４）。
【００４８】
ＷｅｂＳｏｃｋｅｔサーバ部１１から接続確立応答ＩおよびクライアントＩＤが出力されると、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、この接続内容に応じて、例えば図４に示すように、ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３に記憶されているＷｅｂＳｏｃｋｅｔ接続マップ１４の内容を更新する（Ｓ１５）。
【００４９】
負荷分散装置１０は、このようにして、ＷｅｂＳｏｃｋｅｔ接続を確立する。
【００５０】
次に、このような双方向リアルタイム通信時の処理の流れについて説明する。
【００５１】
図５は、第１の実施形態の負荷分散装置１０によってなされる双方向リアルタイム通信時の処理の流れを示すシーケンス図である。
【００５２】
ＷｅｂＳｏｃｋｅｔ接続の確立後、クライアントアプリケーション２０から負荷分散装置１０に向けて送信データＪがクライアントＩＤとともに送信されると、ＷｅｂＳｏｃｋｅｔサーバ部１１が受信する（Ｓ２１）。
【００５３】
ＷｅｂＳｏｃｋｅｔサーバ部１１は、送信データＪおよびクライアントＩＤを受信すると、ＷｅｂＳｏｃｋｅｔ接続管理部１２に、クライアントＩＤを送信することによって、送信元のクライアントアプリケーション２０のＷｅｂＳｏｃｋｅｔ接続に関与しているＷｅｂＳｏｃｋｅｔクライアント部１７を問い合わせる（Ｓ２２）。
【００５４】
この問い合せに応じて、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、ＷｅｂＳｏｃｋｅｔ接続マップ１４を参照して、送信元のクライアントアプリケーション２０のクライアントＩＤ  ｂとの通信状態ｅが「通信中」であるＷｅｂＳｏｃｋｅｔクライアントＩＤ  ｃを把握し（Ｓ２３）、把握結果Ｋを、ＷｅｂＳｏｃｋｅｔサーバ部１１へ出力する（Ｓ２４）。
【００５５】
ＷｅｂＳｏｃｋｅｔサーバ部１１は、把握結果Ｋで指定されたＷｅｂＳｏｃｋｅｔクライアントＩＤ  ｃを有するＷｅｂＳｏｃｋｅｔクライアント部１７へ、送信データＪを出力する（Ｓ２５）。
【００５６】
ＷｅｂＳｏｃｋｅｔクライアント部１７は、この送信データＪを、ＷｅｂＳｏｃｋｅｔ接続によって、接続先のアプリケーションサーバ３１へ送信する（Ｓ２６）。
【００５７】
送信データＪに応じて、アプリケーションサーバ３１が、ＷｅｂＳｏｃｋｅｔクライアント部１７に対して返信データＬを送信した場合は、ＷｅｂＳｏｃｋｅｔクライアント部１７が、返信データＪを受信し（Ｓ２７）、送信データＪを、クライアントＩＤ  ｂとともにＷｅｂＳｏｃｋｅｔサーバ部１１へ出力する（Ｓ２８）。これに応じて、ＷｅｂＳｏｃｋｅｔサーバ部１１が、クライアントＩＤ  ｂに対応するクライアントアプリケーション２０へ、返信データＬを送信する（Ｓ２９）。
【００５８】
次に、負荷分散装置１０によるアプリケーションサーバ３１の通信不可検知について説明する。
【００５９】
図６は、第１の実施形態の負荷分散装置１０によってなされるアプリケーションサーバ３１の通信不可検知処理の流れを示すシーケンス図である。
【００６０】
前述したように、死活監視部１５は、アプリケーションサーバ群３０内の各アプリケーションサーバ３１（１）〜３１（ｎ）の死活監視を、定期的（例えば、１秒間隔程度）に実行している。例えば、ＷｅｂＳｏｃｋｅｔ接続しているアプリケーションサーバ３１が故障発生等により、通信不可となった場合（Ｓ３０）、死活監視部１５は、それを直ちに検知し、負荷分散処理部１６を経由して、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ、通信不可であるアプリケーションサーバ３１を示す通信不可情報Ｍを出力する（Ｓ３１）。
【００６１】
ＷｅｂＳｏｃｋｅｔ接続管理部１２は、出力された通信不可情報Ｍと、ＷｅｂＳｏｃｋｅｔ接続マップ１４とを参照して（Ｓ３２）、故障等により通信不可となったアプリケーションサーバ３１とＷｅｂＳｏｃｋｅｔ接続しているクライアントアプリケーション２０のクライアントＩＤ、およびＷｅｂＳｏｃｋｅｔクライアント部１７を特定し（Ｓ３３）、特定されたＷｅｂＳｏｃｋｅｔクライアント部１７に対して、アプリケーションサーバ３１とのＷｅｂＳｏｃｋｅｔ接続をクローズするように指示する指示情報Ｎを出力する（Ｓ３４）。
【００６２】
ＷｅｂＳｏｃｋｅｔ接続管理部１２はさらに、通信不可情報Ｍに応じて、例えば図４に示すように、ＷｅｂＳｏｃｋｅｔ接続マップ１４を更新する（Ｓ３５）とともに、クライアントＩＤ  ｂに対応するクライアントアプリケーション２０のためのＷｅｂＳｏｃｋｅｔ接続の再確立要求Ｐを負荷分散処理部１６へ出力する（Ｓ３６）。
【００６３】
負荷分散処理部１６は、再確立要求Ｐに応じて、死活監視部１５から生存情報Ｄを取得し（Ｓ３７）、その後、負荷分散アルゴリズムに従って、生存情報Ｄにおいて示されている生存しているアプリケーションサーバ３１の中から、適切なアプリケーションサーバ（例えば、アプリケーションサーバ３１（２））を選択し、選択結果Ｑを、クライアントＩＤ  ｂとともに、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力する（Ｓ３８）。
【００６４】
選択結果Ｑに応じて、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、選択されたクライアントサーバ３１（２）に対応しているＷｅｂＳｏｃｋｅｔクライアント部１７（２）へ、クライアントＩＤ  ｂと、アプリケーションサーバ３１（２）への接続指示Ｒとを出力する（Ｓ３９）。
【００６５】
この接続指示Ｒに応じて、ＷｅｂＳｏｃｋｅｔクライアント部１７（２）は、クライアントアプリケーション２０の代わりに、アプリケーションサーバ３１（２）とのＷｅｂＳｏｃｋｅｔ接続を確立する（Ｓ４０）。ＷｅｂＳｏｃｋｅｔクライアント部１７（２）はその後、クライアントＩＤ  ｂ、およびＷｅｂＳｏｃｋｅｔ接続が確立したことを示す確立情報ＵをＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力する（Ｓ４１）。
【００６６】
この確立情報Ｕに応じて、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、例えば図４に示すように、ＷｅｂＳｏｃｋｅｔ接続マップ１４を更新する（Ｓ４２）。
【００６７】
以上説明したように、本実施形態の負荷分散装置１０は、アプリケーションサーバ３１（１）が故障等により通信不可となった場合、それを直ちに検知し、クライアントアプリケーション３１（１）の代わりに、例えばアプリケーションサーバ３１（２）とのＷｅｂＳｏｃｋｅｔ接続を直ちに確立する。
【００６８】
次に、以上のように構成した第１の実施形態の負荷分散装置１０の動作について説明する。
【００６９】
まず、負荷分散装置１０によってなされるＷｅｂＳｏｃｋｅｔ接続処理時の動作を、図３を用いて説明する。
【００７０】
ＷｅｂＳｏｃｋｅｔ接続を実現するためには、先ず、ユーザがクライアント端末２１を用いてクライアントアプリケーション２０にアクセスし、クライアントアプリケーション２０を起動する。これによって、クライアントアプリケーション２０から、負荷分散装置１０に対して、ＷｅｂＳｏｃｋｅｔ接続要求Ａが送信される（Ｓ１）。
【００７１】
ＷｅｂＳｏｃｋｅｔ接続要求Ａは、負荷分散装置１０のＷｅｂＳｏｃｋｅｔサーバ部１１において受信される。ＷｅｂＳｏｃｋｅｔサーバ部１１では、ＷｅｂＳｏｃｋｅｔ接続要求Ａの送信元のクライアントアプリケーション２０から、クライアントアプリケーション２０のクライアントＩＤが把握され、把握したクライアントＩＤと、ＷｅｂＳｏｃｋｅｔ接続要求Ａとが、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力される（Ｓ２）。
【００７２】
ＷｅｂＳｏｃｋｅｔ接続管理部１２では、ＷｅｂＳｏｃｋｅｔサーバ部１１から出力されたクライアントＩＤとＷｅｂＳｏｃｋｅｔ接続要求Ａとに基づいて、ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３に記憶されているＷｅｂＳｏｃｋｅｔ接続マップ１４が更新される（Ｓ３）とともに、アプリケーションサーバ選択要求Ｂが生成され、ＷｅｂＳｏｃｋｅｔ接続管理部１２から、クライアントＩＤとともに負荷分散処理部１６へ出力される（Ｓ４）。
【００７３】
死活監視部１５では、アプリケーションサーバ群３０内の各アプリケーションサーバ３１（１）〜３１（ｎ）の死活監視が、定期的（例えば、１秒間隔程度）に実行される（Ｓ５）。そして、死活監視部１５によって、生存している（故障しておらず、正常に動作する）アプリケーションサーバ３１を示す生存情報Ｄが生成され、負荷分散処理部１６へ出力される（Ｓ６）。
【００７４】
負荷分散処理部１６では、生存情報Ｄと負荷分散アルゴリズムとに従って、接続元のクライアントアプリケーション２０が接続すべきアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１））が選択され、選択結果Ｅが、接続元のクライアントアプリケーション２０のクライアントＩＤとともに、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力される（Ｓ７）。
【００７５】
次に、ＷｅｂＳｏｃｋｅｔ接続管理部１２からは、選択結果Ｅに基づいて、対応するＷｅｂＳｏｃｋｅｔクライアント部１７へ、クライアントＩＤと、アプリケーションサーバ３１（１）への接続指示Ｆとが出力される（Ｓ８）。
【００７６】
接続指示Ｆを出力されたＷｅｂＳｏｃｋｅｔクライアント部１７（１）では、接続元のクライアントアプリケーション２０の代わりに、アプリケーションサーバ３１（１）とのＷｅｂＳｏｃｋｅｔ接続が確立される（Ｓ９）。
【００７７】
ＷｅｂＳｏｃｋｅｔ接続が確立されたＷｅｂＳｏｃｋｅｔクライアント部１７（１）からは、クライアントＩＤと、ＷｅｂＳｏｃｋｅｔ接続が確立したことを示す確立情報Ｇとが、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力される（Ｓ１０）。
【００７８】
ＷｅｂＳｏｃｋｅｔ接続管理部１２では、出力されたクライアントＩＤおよび確立情報Ｇに基づいて、ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３に記憶されているＷｅｂＳｏｃｋｅｔ接続マップ１４が更新される（Ｓ１１）。さらに、更新されたＷｅｂＳｏｃｋｅｔ接続マップ１４に従って、ＷｅｂＳｏｃｋｅｔサーバ部１１に対して、クライアントＩＤ  ｂに対応するクライアントアプリケーション２０とのＷｅｂＳｏｃｋｅｔ接続を確立するように指示する接続指示Ｈが、クライアントＩＤとともに出力される（Ｓ１２）。
【００７９】
この接続指示Ｈに応じて、ＷｅｂＳｏｃｋｅｔサーバ部１１では、クライアントＩＤに対応するクライアントアプリケーション２０とのＷｅｂＳｏｃｋｅｔ接続が確立される（Ｓ１３）。そして、ＷｅｂＳｏｃｋｅｔ接続が確立されると、ＷｅｂＳｏｃｋｅｔサーバ部１１から、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ、接続確立応答Ｉが出力される（Ｓ１４）。
【００８０】
ＷｅｂＳｏｃｋｅｔサーバ部１１から接続確立応答Ｉが出力されると、ＷｅｂＳｏｃｋｅｔ接続管理部１２では、この接続内容に応じて、ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置１３に記憶されているＷｅｂＳｏｃｋｅｔ接続マップ１４の内容が更新される（Ｓ１５）。
【００８１】
このようにして、負荷分散装置１０によって、ＷｅｂＳｏｃｋｅｔ接続が確立される。ＷｅｂＳｏｃｋｅｔ接続の確立後は、情報の一貫性を保つために、クライアントアプリケーション２０からの送信データＪが、同一のアプリケーションサーバ３１へ出力され、ＷｅｂＳｏｃｋｅｔ接続が切断されるまで、クライアントアプリケーション２０とアプリケーションサーバ３１との両方のＴＣＰコネクションが確保される。これによって、クライアントアプリケーション２０とアプリケーションサーバ３１との間の双方向リアルタイム通信が実現される。
【００８２】
このような双方向リアルタイム通信時における負荷分散装置１０の動作を、図５を用いて説明する。
【００８３】
ＷｅｂＳｏｃｋｅｔ接続の確立後、クライアントアプリケーション２０から負荷分散装置１０に向けて送信データＪが送信されると、送信データＪは、クライアントアプリケーション２０のクライアントＩＤとともにＷｅｂＳｏｃｋｅｔサーバ部１１によって受信される（Ｓ２１）。
【００８４】
ＷｅｂＳｏｃｋｅｔサーバ部１１による送信データＪの受信に応じて、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、ＷｅｂＳｏｃｋｅｔサーバ部１１から、クライアントＩＤが出力され、送信元のクライアントアプリケーション２０のＷｅｂＳｏｃｋｅｔ接続に関与しているＷｅｂＳｏｃｋｅｔクライアント部１７の問い合わせがなされる（Ｓ２２）。
【００８５】
この問い合せに応じて、ＷｅｂＳｏｃｋｅｔ接続管理部１２では、ＷｅｂＳｏｃｋｅｔ接続マップ１４を参照して、送信元のクライアントアプリケーション２０のクライアントＩＤ  ｂとの通信状態ｅが「通信中」であるＷｅｂＳｏｃｋｅｔクライアントＩＤ  ｃが把握され（Ｓ２３）、把握結果Ｋが、ＷｅｂＳｏｃｋｅｔサーバ部１１へ出力される（Ｓ２４）。
【００８６】
ＷｅｂＳｏｃｋｅｔサーバ部１１では、把握結果Ｋで指定されたＷｅｂＳｏｃｋｅｔクライアントＩＤ  ｃを有するＷｅｂＳｏｃｋｅｔクライアント部１７へ、送信データＪが出力される（Ｓ２５）。
【００８７】
ＷｅｂＳｏｃｋｅｔクライアント部１７では、送信データＪが、ＷｅｂＳｏｃｋｅｔ接続によって、接続先のアプリケーションサーバ３１へ送信される（Ｓ２６）。
【００８８】
送信データＪに応じて、アプリケーションサーバ３１から、ＷｅｂＳｏｃｋｅｔクライアント部１７へ返信データＬが送信された場合は、ＷｅｂＳｏｃｋｅｔクライアント部１７によって返信データＬが受信され（Ｓ２７）、送信データＬが、クライアントＩＤ  ｂとともにＷｅｂＳｏｃｋｅｔサーバ部１１へ出力される（Ｓ２８）。これに応じて、ＷｅｂＳｏｃｋｅｔサーバ部１１から、クライアントＩＤ  ｂに対応するクライアントアプリケーション２０へ、返信データＬが送信される（Ｓ２９）。
【００８９】
次に、負荷分散装置１０によるアプリケーションサーバ３１の通信不可検知時の動作を図６を用いて説明する。
【００９０】
死活監視部１５によって、アプリケーションサーバ群３０内の各アプリケーションサーバ３１（１）〜３１（ｎ）の死活監視が、定期的（例えば、１秒間隔程度）に実行され、ＷｅｂＳｏｃｋｅｔ接続しているアプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１）とする）が故障等により通信不可となった場合（Ｓ３０）、死活監視部１５によってそれが直ちに検知され、負荷分散処理部１６を経由して、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ、通信不可情報Ｍが出力される（Ｓ３１）。
【００９１】
ＷｅｂＳｏｃｋｅｔ接続管理部１２では、通信不可情報Ｍと、ＷｅｂＳｏｃｋｅｔ接続マップ１４とが参照され（Ｓ３２）、アプリケーションサーバ３１（１）とＷｅｂＳｏｃｋｅｔ接続しているクライアントアプリケーション２０のクライアントＩＤ、およびＷｅｂＳｏｃｋｅｔクライアント部１７（１）が特定され（Ｓ３３）、特定されたＷｅｂＳｏｃｋｅｔクライアント部１７（１）に対して、アプリケーションサーバ３１（１）とのＷｅｂＳｏｃｋｅｔ接続をクローズするように指示する指示情報Ｎが出力される（Ｓ３４）。
【００９２】
ＷｅｂＳｏｃｋｅｔ接続管理部１２ではさらに、通信不可情報Ｍに応じて、ＷｅｂＳｏｃｋｅｔ接続マップ１４が更新される（Ｓ３５）とともに、クライアントアプリケーション２０のためのＷｅｂＳｏｃｋｅｔ接続の再確立要求Ｐが負荷分散処理部１６へ出力される（Ｓ３６）。
【００９３】
負荷分散処理部１６では、再確立要求Ｐに応じて、死活監視部１５から生存情報Ｄが取得され（Ｓ３７）、その後、負荷分散アルゴリズムに従って、生存情報Ｄにおいて示されている生存しているアプリケーションサーバ３１の中から、適切なアプリケーションサーバ（例えば、アプリケーションサーバ３１（２））を選択され、選択結果Ｑが、クライアントＩＤ  ｂとともに、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力される（Ｓ３８）。
【００９４】
選択結果Ｑに応じて、ＷｅｂＳｏｃｋｅｔ接続管理部１２では、クライアントサーバ３１（２）に対応しているＷｅｂＳｏｃｋｅｔクライアント部１７（２）へ、クライアントＩＤ  ｂと、アプリケーションサーバ３１（２）への接続指示Ｒとが出力される（Ｓ３９）。
【００９５】
この接続指示Ｒに応じて、ＷｅｂＳｏｃｋｅｔクライアント部１７（２）では、クライアントアプリケーション２０の代わりに、アプリケーションサーバ３１（２）とのＷｅｂＳｏｃｋｅｔ接続が確立される（Ｓ４０）。ＷｅｂＳｏｃｋｅｔクライアント部１７（２）からはその後、クライアントＩＤ  ｂ、およびＷｅｂＳｏｃｋｅｔ接続が確立したことを示す確立情報Ｕが、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力される（Ｓ４１）。
【００９６】
この確立情報Ｕに応じて、ＷｅｂＳｏｃｋｅｔ接続管理部１２では、ＷｅｂＳｏｃｋｅｔ接続マップ１４が更新される（Ｓ４２）。
【００９７】
以上説明したように、本実施形態の負荷分散装置１０では、アプリケーションサーバ３１（１）が故障等により通信不可となった場合、それが直ちに検知され、クライアントアプリケーション３１（１）の代わりに、アプリケーションサーバ３１（２）とのＷｅｂＳｏｃｋｅｔ接続が直ちに確立される。これによって、クライアントアプリケーション２０が、アプリケーションサーバ３１（１）が通信不可になったことを意識することなく、また、ＷｅｂＳｏｃｋｅｔ接続の再確立のための要求をする必要なく、クライアントアプリケーション２０とアプリケーションサーバ３１（２）との間の双方向のリアルタイム通信の早期復元が実現される。
【００９８】
以上説明したように、本実施形態の負荷分散装置１０によれば、クライアントアプリケーション２０とアプリケーションサーバ３１とから構成されるＷｅｂＳｏｃｋｅｔシステム４０において、通信中のアプリケーションサーバ３１（１）が故障等により通信不可となった場合であっても、それを早期に検知し、生存している別のアプリケーションサーバ３１（２）との新たなＷｅｂＳｏｃｋｅｔ接続を、自動的かつ短時間で確立することができるので、双方向リアルタイム通信を実現することが可能となる。
【００９９】
この通信不可検知には、ｐｉｎｇ／ｐｏｎｇメッセージを使用しないので、アプリケーションサーバ３１に負荷をかけることなく実施することが可能である。
【０１００】
また、負荷分散装置１０は、このような新たなＷｅｂＳｏｃｋｅｔ接続のために必要な手順を、クライアントアプリケーション２０になり代わって実施する。したがって、クライアントアプリケーション２０は、アプリケーションサーバ３１（１）が故障等によって通信不可になったことや、新たなアプリケーションサーバ３１（２）との切替処理を意識することなく、連続的にリクエストを送信することができる。
【０１０１】
このようにＷｅｂＳｏｃｋｅｔシステム４０は、双方向のリアルタイム通信が可能であることから、電子商取引システムへの適用が好適である。
【０１０２】
図７は、ＷｅｂＳｏｃｋｅｔシステム４０を適用して構成される電子商取引システム５０の構成例を示すブロック図である。
【０１０３】
図７に示すように、ユーザが、パソコンやスマートフォン等のクライアント端末２１を用いて、オンライン店舗のウエブサイトを提供するクライアントアプリケーション２０へアクセスし、商品を問い合わせる問合情報Ｖを入力すると、問合情報Ｖが、クライアントアプリケーション２０から、負荷分散装置１０を介して、アプリケーションサーバ３１（１）へ送信され、アプリケーションサーバ３１（１）が、在庫データベース５１にアクセスし、問合情報Ｖで指定された商品の在庫状況や、入荷状況等の情報を取得し、クライアントアプリケーション２０へ返信する。これによって、ユーザは、商品の在庫状況や入荷状況を確認し、この商品を注文するための注文情報Ｗを入力することによって、発注が完了する。
【０１０４】
仮に、通信中のアプリケーションサーバ３１（１）が故障等により通信不可となった場合であっても、前述したように、負荷分散装置１０によって、自動的かつ短時間で、ＷｅｂＳｏｃｋｅｔ接続が復旧されるので、クライアントアプリケーション２０とアプリケーションサーバ３１との間の双方向リアルタイム通信は維持される。
【０１０５】
これによって、ユーザは、通信中のアプリケーションサーバ３１（１）が故障等により通信不可となった場合であっても、その時点における正しい在庫状況および／または入荷状況を把握できるので、商品の発注を継続することができる。
【０１０６】
もしも、通信中のアプリケーションサーバ３１（１）の故障等によって、双方向リアルタイム通信が維持されなくなれば、クライアントアプリケーション２０は、その時点における在庫状況や入荷状況を取得することができなくなる。それによって、例えば、在庫有りと通知されていたにも関わらず、故障中に、その商品が他の人によって購入されていてしまった結果、在庫が無くなり、購入できなくなることや、逆に、在庫なしと通知されていたが、商品が入荷し、在庫が確保されたとしても、依然として在庫なしと通知されていることにより、ユーザが購入を断念することが生じる可能性がある。実際、従来のｈｔｔｐを使ったＷｅｂＳｏｃｋｅｔシステムでは、そのようなことが起こり得る。
【０１０７】
しかしながら、本実施形態に係る負荷分散方法が適用された負荷分散装置１０によれば、通信中のアプリケーションサーバが故障等により通信不可となった場合であっても、それを早期に検知し、自動的かつ短時間で、新たなＷｅｂＳｏｃｋｅｔ接続を確立することによって、双方向リアルタイム通信を実現することができるので、上述したような不具合の発生を阻止することが可能となる。
【０１０８】
（第２の実施形態）
第１の実施形態の負荷分散装置１０は、通信中のアプリケーションサーバ３１（１）が故障等により通信不可となった場合であっても、それを早期に検知し、生存している別のアプリケーションサーバ３１（２）との新たなＷｅｂＳｏｃｋｅｔ接続を、自動的かつ短時間で確立している。
【０１０９】
本実施形態では、それに加えて、アプリケーションサーバ３１が故障等により通信不可となった場合、クライアントアプリケーション２０からの要求に応じて、新たなＷｅｂＳｏｃｋｅｔ接続を確立する機能をも備えた負荷分散装置１０について説明する。
【０１１０】
したがって、以下では、クライアントアプリケーション２０と、アプリケーションサーバ３１（１）とがＷｅｂＳｏｃｋｅｔ接続している状態において、アプリケーションサーバ３１（１）が故障等により通信不可となった場合以降の負荷分散装置１０の処理について、図８を用いて説明する。負荷分散装置１０の構成、および、クライアントアプリケーション２０と、アプリケーションサーバ３１（１）とがＷｅｂＳｏｃｋｅｔ接続するまでの処理は、第１の実施形態と同一であるので、重複説明を避ける。
【０１１１】
図８は、第２の実施形態の負荷分散装置１０によってなされるアプリケーションサーバ３１の通信不可検知処理の流れを示すシーケンス図である。
【０１１２】
すなわち、図８に示すシーケンスは、図６に示すシーケンスにおけるステップＳ３５、Ｓ３６が削除され、代わりに、ステップＳ３３からステップＳ４０までの間に、新たなステップＳ５０乃至Ｓ５５を挿入している。図８では、図６と同一の処理に、同一の付番を付している。
【０１１３】
ステップＳ３３において、ＷｅｂＳｏｃｋｅｔ接続管理部１２は、故障等により通信不可となったアプリケーションサーバ３１（１）とＷｅｂＳｏｃｋｅｔ接続しているクライアントアプリケーション２０のクライアントＩＤ、およびＷｅｂＳｏｃｋｅｔクライアント部１７を特定すると、ＷｅｂＳｏｃｋｅｔ接続管理部１２はさらに、クライアントＩＤおよび通信不可情報ＭをＷｅｂＳｏｃｋｅｔサーバ部１１へ出力する（Ｓ５０）。
【０１１４】
ＷｅｂＳｏｃｋｅｔサーバ部１１は、通信不可情報Ｍを、クライアントＩＤに対応するクライアントアプリケーション２０へ送信する（Ｓ５１）。
【０１１５】
クライアントアプリケーション２０は、通信不可情報Ｍを受信すると、既存のＷｅｂＳｏｃｋｅｔ接続を切断し、負荷分散装置１０に対して、ＷｅｂＳｏｃｋｅｔ接続の再確立要求Ｐを送信する（Ｓ５２）。
【０１１６】
負荷分散装置１０では、この再確立要求Ｐを、ＷｅｂＳｏｃｋｅｔサーバ部１１において受信し、ＷｅｂＳｏｃｋｅｔサーバ部１１が、この再確立要求Ｐを、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力する（Ｓ５３）。
【０１１７】
ＷｅｂＳｏｃｋｅｔ接続管理部１２は、再確立要求Ｐに応じて、ＷｅｂＳｏｃｋｅｔ接続マップ１４を更新する（Ｓ５４）とともに、再確立要求Ｐを負荷分散処理部１６へ出力する（Ｓ５６）。
【０１１８】
その後は、ステップＳ３７〜ステップＳ４２と同様の処理によって、負荷分散装置１０が、クライアントアプリケーション２０の代わりに、アプリケーションサーバ３１（２）とのＷｅｂＳｏｃｋｅｔ接続を確立し、ＷｅｂＳｏｃｋｅｔ接続マップ１４を更新する。
【０１１９】
次に、以上のように構成した第２の実施形態の負荷分散装置１０の動作を図８を用いて説明する。
【０１２０】
アプリケーションサーバ３１（例えば、アプリケーションサーバ３１（１）とする）が故障等により通信不可となった場合（Ｓ３０）、死活監視部１５によって、それが直ちに検知され、負荷分散処理部１６を経由して、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ、通信不可情報Ｍが出力され（Ｓ３１）、ＷｅｂＳｏｃｋｅｔ接続管理部１２では、通信不可情報Ｍと、ＷｅｂＳｏｃｋｅｔ接続マップ１４とが参照され（Ｓ３２）、ＷｅｂＳｏｃｋｅｔ接続管理部１２では、通信不可となったアプリケーションサーバ３１（１）とＷｅｂＳｏｃｋｅｔ接続しているクライアントアプリケーション２０のクライアントＩＤ、およびＷｅｂＳｏｃｋｅｔクライアント部１７が特定される（Ｓ３３）。
【０１２１】
その後、ＷｅｂＳｏｃｋｅｔ接続管理部１２から、クライアントＩＤおよび通信不可情報ＭがＷｅｂＳｏｃｋｅｔサーバ部１１へ出力される（Ｓ５０）。
【０１２２】
さらに、ＷｅｂＳｏｃｋｅｔサーバ部１１から、通信不可情報Ｍが、クライアントＩＤに対応するクライアントアプリケーション２０へ送信される（Ｓ５１）。
【０１２３】
クライアントアプリケーション２０では、通信不可情報Ｍに応じて、既存のＷｅｂＳｏｃｋｅｔ接続が切断され、負荷分散装置１０へ、ＷｅｂＳｏｃｋｅｔ接続の再確立要求Ｐが送信される（Ｓ５２）。
【０１２４】
負荷分散装置１０では、この再確立要求Ｐが、ＷｅｂＳｏｃｋｅｔサーバ部１１において受信され、ＷｅｂＳｏｃｋｅｔサーバ部１１から、再確立要求Ｐが、ＷｅｂＳｏｃｋｅｔ接続管理部１２へ出力される（Ｓ５３）。
【０１２５】
ＷｅｂＳｏｃｋｅｔ接続管理部１２では、再確立要求Ｐに応じて、ＷｅｂＳｏｃｋｅｔ接続マップ１４が更新される（Ｓ５４）とともに、再確立要求Ｐが負荷分散処理部１６へ出力される（Ｓ５５）。
【０１２６】
その後は、前述したステップＳ３７〜ステップＳ４３と同様の処理によって、負荷分散装置１０によって、クライアントアプリケーション２０の代わりに、アプリケーションサーバ３１（２）とのＷｅｂＳｏｃｋｅｔ接続が確立され、ＷｅｂＳｏｃｋｅｔ接続マップ１４が更新される。
【０１２７】
以上説明したように、本実施形態の負荷分散装置１０によれば、クライアントアプリケーション２０とアプリケーションサーバ３１とから構成されるＷｅｂＳｏｃｋｅｔシステム４０において、通信中のアプリケーションサーバ３１（１）が故障等によって通信不可となった場合、それを早期に検知し、クライアントアプリケーション２０に通知することができる。そして、クライアントアプリケーション２０からの要求に応じて、生存している別のアプリケーションサーバ３１（２）との新たなＷｅｂＳｏｃｋｅｔ接続を短時間で確立することができる。このような処理によっても、クライアントアプリケーション２０とアプリケーションサーバ３１との間の双方向リアルタイム通信を実現することが可能となる。
【０１２８】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【０１２９】
１０・・負荷分散装置、１１・・ＷｅｂＳｏｃｋｅｔサーバ部、１２・・ＷｅｂＳｏｃｋｅｔ接続管理部、１３・・ＷｅｂＳｏｃｋｅｔ接続マップ記憶装置、１４・・ＷｅｂＳｏｃｋｅｔ接続マップ、１５・・死活監視部、１６・・負荷分散処理部、１７・・ＷｅｂＳｏｃｋｅｔクライアント部、２０・・クライアントアプリケーション、２１・・クライアント端末、３０・・アプリケーションサーバ群、３１・・アプリケーションサーバ、４０・・ＷｅｂＳｏｃｋｅｔシステム、５０・・電子商取引システム、５１・・在庫データベース。
【図１】
2019057091.tif 000003
【図２】
2019057091.tif 000004
【図３】
2019057091.tif 000005
【図４】
2019057091.tif 000006
【図５】
2019057091.tif 000007
【図６】
2019057091.tif 000008
【図７】
2019057091.tif 000009
【図８】
2019057091.tif 000010