JP5855663B2 - サーバ負荷状態に基づきサーバをバランスさせるシステムと方法 - Google Patents

Description

本発明は、概してデータ通信に関し、より具体的には負荷バランサにサービスする方法とシステムに関する。

ウェブサービスとクラウドコンピューティングは前例のない速さで展開されている。データセンターには毎日、新しいサーバが運ばれ、設置されている。あらゆる方向から、ウェブサービスとコーポレートコンピューティングへの需要がある。消費者向けサービスには、ｉＰｈｏｎｅアプリ、ロケーションベースサービスなどの携帯アプリ、ナビゲーションサービス、キンドルなどの電子ブックサービス、ユーチューブやＨｕｌｕなどのビデオアプリケーション、パンドラやｉＴｕｎｅｓなどの音楽アプリケーション、Ｎｅｔｆｌｉｘなどのインターネットテレビジョンサービス、その他の急速に成長している多数の消費者向けウェブサービスなどがある。企業面では、Google(TM) docs、Microsoft(TM) Office Live、Sharepoint(TM) softwareなどのサービスに基づくクラウドコンピューティング、Salesforce.com(TM)のオンラインソフトウェアサービス、テレプレゼンス、及びウェブ会議サービス、及びその他の多数の企業クラウドコンピューティングサービスがある。

結果として、増大するコンピューティング需要を満たすため、ますます多くのサービスが展開されている。従来、これらのサーバはサーバ負荷バランサ（ＳＬＢ）により管理されている。ＳＬＢは典型的には、Ａ１０ネットワーク社のＡＸシリーズ トラフィックマネージャなどのネットワーク機器である。ＳＬＢは、入来するサービス要求に基づき、サーバの負荷バランシングを管理する。サーバ間で負荷をバランスさせる一般的な方法は、アプリケーション（ＨＴＴＰ、ＦＴＰなど）、ＵＲＬなどのサービスアドレス、ネットワークインタフェースに基づく優先度、又はホストＩＰアドレスに基づきサービス要求を分配することである。ＳＬＢは、サーバに均等に負荷がかかっていると仮定し、確認して、ラウンドロビン方式でもサービス要求を、サーバに分配する。しかし、サービス要求が異なれば、サービス計算結果は異なる。サーバによっては、少数のサービス要求だけでフルロード状態になるものもあれば、多数のサービス要求があってもほとんどアイドル状態のままであるものもある。ＳＬＢは、不適切にも、アイドル状態のサーバに要求を送る替わりに、ビジー状態のサーバが利用可であると誤解して、そのビジー状態のサーバに要求を送ってしまうことがある。

ＳＬＢがサーバの計算負荷状態を知って、サービス要求を処理するサーバをよりよく選択できるようにすることができればよい。

それゆえ、サーバ負荷バランサがサーバ負荷状態に基づきサーバを選択するシステムと方法が必要である。

本発明の一実施形態による、サーバ負荷状態に基づきサーバをバランスさせる方法は、サービスゲートウェイが、一サーバから、サービス要求に対するサービス応答であって前記サービス要求の処理結果と前記サーバの計算負荷状態を示すサーバステータスとを含むサービス応答を受信するステップと、前記サービスゲートウェイが、前記サービス応答から前記サーバステータスを取得するステップと、前記サービスゲートウェイが、一ホストから、ユニフォームリソースロケータ（ＵＲＬ）を含む次のサービス要求を受信するステップと、前記サービスゲートウェイが、前記サーバが前記ＵＲＬを処理するように構成されていると判断するステップと、前記サービスゲートウェイが、前記サーバが前記次のサービス要求を処理できることを前記サーバステータスが示すか判断するステップと、前記サーバが前記次のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記次のサービス要求を前記サーバに送るステップとを有する。

本発明の一態様において、前記方法は、前記サービスゲートウェイと前記サーバとの間のサービスセッションを確立するステップと、前記サービスゲートウェイが、前記サービス要求を前記サーバに送るステップと、前記サービスゲートウェイが、前記サーバから、前記サーバによる前記サービス要求の処理結果と前記サーバの計算負荷状態を示す前記サーバステータスとを含む前記サービス応答を受信するステップとを有する。

本発明の一態様において、前記方法は、前記サービスゲートウェイが、前記サービス応答から前記サーバステータスを取得するステップと、前記サービスゲートウェイが、前記サービス応答から前記サーバステータスを削除することにより前記サービス応答を修正するステップと、前記サービスゲートウェイが、前記サービス要求を送ったホストに、前記修正されたサービス応答を送るステップとを有する。

本発明の一態様において、前記方法は、前記サービスゲートウェイが、前記サーバがプライマリサーバとして又はセカンダリサーバとして前記ＵＲＬを処理するように構成されているか判断するステップと、前記サーバがプライマリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記サービスゲートウェイが、前記次のサービス要求を、プライマリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第１のバッファに格納するステップと、前記サーバがセカンダリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記サービスゲートウェイが、前記次のサービス要求を、セカンダリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第２のバッファに格納するステップとを有する。

本発明の一態様において、前記サーバは、プライマリサーバとして前記ＵＲＬを処理するように構成されていると判断され、前記方法は、前記サービスゲートウェイが、前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断するステップと、前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記第１のバッファ中の前記次のサービス要求を発見するステップと、前記サービスゲートウェイが、前記次のサービス要求を前記サーバに送るステップとを有する。

本発明の一態様において、前記サーバは、セカンダリサーバとして前記ＵＲＬを処理するように構成されていると判断され、前記方法は、前記サービスゲートウェイが、前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断するステップと、前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記サーバを選択するか判断するステップと、前記サーバを選択するとの判断に応じて、前記サービスゲートウェイが、前記第２のバッファにおいて前記次のサービス要求を発見するステップと、前記サービスゲートウェイが、前記次のサービス要求を前記サーバに送るステップとを有する。

本発明の一態様において、前記方法は、前記サービスゲートウェイが、前記サーバが所定のハッシュ値を有するサービス要求を処理するように構成されていると判断するステップと、前記サービスゲートウェイが、前記次のサービス要求中のＵＲＬにハッシュ関数を適用するステップと、前記サービスゲートウェイが、前記ＵＲＬのハッシュ値が前記所定のハッシュ値と一致すると判断するステップとを有する。

本発明の一態様において、前記方法は、前記サービスゲートウェイが、前記サーバが前記ＵＲＬを処理するように構成されていると判断するステップと、前記サービスゲートウェイが、前記次のサービス要求の所定のパラメータに基づき、前記次のサービス要求の優先度を判断するステップと、前記サービスゲートウェイが、前記所定の優先度を有するサービス要求を格納するように構成されているバッファに、前記次のサービス要求を格納するステップと、前記サービスゲートウェイが、前記サーバが前記サービス要求を処理できることを前記サーバステータスが示すか判断するステップと、前記サーバが前記次のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記サーバが前記所定の優先度を有するサービス要求を処理するか判断するステップと、前記サーバが前記所定の優先度を有するサービス要求を処理するとの判断に応じて、前記サービスゲートウェイが、前記所定の優先度を有するサービス要求を格納するように構成されたバッファにおいて前記次のサービス要求を発見するステップと、前記サービスゲートウェイが、前記次のサービス要求を前記サーバに送るステップとを有する。

上記の方法に対応するシステムとコンピュータプログラム製品もここに説明し特許請求の範囲に記載した。

本発明による、サービスゲートウェイの一実施形態とサーバプールの一実施形態とを示す図である。 サービスゲートウェイによるサービス要求の処理の一実施形態を示すブロック図である。 サーバステータスの取り得る値を示す図である。 サーバステータスを受信後の、サービスゲートウェイによるサービス要求の処理の一実施形態を示すブロック図である。 サービス優先度に応じてサービス要求を処理するサービスゲートウェイを示す図である。 サービスゲートウェイ１１０によるサービス要求の処理の一実施形態を示す図である。 サービスゲートウェイによるサービス要求の処理方法の一実施形態を示すフローチャートである。

発明実施するための形態

以下の説明は、当業者が本発明の生産と使用をすることができるように説明するものであり、特許出願とその要件の文脈で説明するものである。当業者には、実施形態の様々な修正が容易に明らかになり、ここに説明する一般的な原理は他の実施形態にも適用できるだろう。このように、本発明は、図示した実施形態に限定されるものではなく、ここに説明する原理と特徴と一致する最も広い範囲を与えられるべきである。

本発明の実施形態は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはハードウェアとソフトウェアを両方含む実施形態の形式を取ることができる。好ましい一実施形態では、本発明は、ソフトウェアで実施できる。ソフトウェアは、ファームウェア、レジデントソフトウェア、マイクロコードなどを含むが、これらの限定されない。

さらに、本発明は、コンピュータや命令実行システムにより使用されるプログラムコードを提供するコンピュータ利用可能媒体またはコンピュータ読み取り可能媒体からアクセスできるコンピュータプログラム製品の形体を取りうる。本開示の目的では、コンピュータ使用可能またはコンピュータ読み取り可能媒体は、命令実行システム、装置、まはたデバイスにより、またはそれらに関して使用される、プログラムを包含、格納、伝達、伝送、搬送できる任意の装置である。

この媒体は、電子的媒体、磁気的媒体、光媒体、光磁気媒体、赤外線媒体、半導体システム（または装置やデバイス）、伝達媒体などである。コンピュータ読み取り可能媒体の例としては、半導体または固体メモリ、磁気テープ、リムーバブルコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、固定磁気ディスク、光ディスクなどがある。光ディスクの例としては、コンパクトディスク−リードオンリメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）、及びＤＶＤなどがある。

プログラムコードを格納及び／又は実行するのに好適なデータ処理システムは、システムバスを通してメモリ要素に直接的または間接的に結合された少なくとも１つのプロセッサを含む。メモリエレメントは、プログラムコードの実行時に使われるローカルメモリと、バルク記憶と、実行時にコードをバルク記憶から読み出さねばならない回数を低減するために、少なくともプログラムコードの一部を一時的に記憶するキャッシュメモリと、を含む。

（キーボード、ディスプレイ、ポインティングデバイスなどを含むがこれに限定されない）入出力すなわちＩ／Ｏデバイスを、直接的に、またはＩ／Ｏコントローラを介在させて、システムに結合できる。

ネットワークアダプタをシステムに結合して、データ処理システムを、プライベートネットワークやパブリックネットワークを通して、他のデータ処理システムやリモートプリンタや記憶装置に結合することもできる。モデム、ケーブルモデム及びイーサネット（登録商標）カードは、現在利用できるネットワークアダプタの一部である。

図のフローチャートとブロック図は、本発明の様々な実施形態によるシステム、方法及びコンピュータプログラム製品のアーキテクチャ、機能及びありうる実装の動作を示す。これに関連して、フローチャートやブロック図の各ブロックは、モジュール、セグメント、コードの一部分を表す。これは指定されたローカル機能を実装する一又は複数の実行可能命令を含む。留意すべき点として、代替的な実施形態では、ブロックに示した機能は図面に示した順序でない順序で行ってもよい。例えば、順次的に示された２つのブロックは、その機能に応じて、実際には、実質的に同時に実行してもよく、逆の順序で実行してもよい。また、留意点として、ブロック図及び／又はフローチャートの各ブロック、及びブロック図及び／又はフローチャートのブロックの組合せは、指定された機能や動作を実行する特定目的ハードウェアベースシステムにより、又は特定目的ハードウェアとコンピュータ命令との組合せにより実施できる。

ここで用いる用語は、具体的な実施形態を説明することを目的としており、本発明の限定を意図したものではない。ここで、冠詞「a」、「an」、及び「the」は、明らかに文脈に反しない限り、複数の場合も含む。さらに、言うまでもなく、「有する」との用語は、本明細書で用いるとき、記載した特徴、整数、ステップ、動作、要素及び／又はコンポーネントがあることを示し、その他の特徴、整数、ステップ、動作、要素、コンポーネント及び／またはこれらのグループがあることを排除するものではない。

図１は、本発明による、サービスゲートウェイ１１０の一実施形態とサーバプール２００の一実施形態とを示す図である。サービスゲートウェイ１１０は、ホスト１００からサービス要求３０１を受信する。サービス要求３０１はデータネットワーク１５３によりデリバリされる。一実施形態では、サービス要求３０１は、ウェブサービス要求であり、例えば、HTTP(Hypertext Transport Protocol)要求、セキュアHTTP要求、FTP(File Transfer Protocol)要求、ファイル転送要求、SIP(Session Initiation Protocol)セッション要求、ウェブ技術に基づく要求、ビデオ又はオーディオストリーミング要求、ウェブ会議セッション要求、又はインターネット又は企業ネットワーク上の任意の要求である。

ホスト１００はネットワークアクセス機能を有するコンピューティング装置である。ホスト１００は、プロセッサ１０３及びコンピュータ読み取り可能媒体１０４に動作可能に結合している。コンピュータ読み取り可能媒体１０４は、ここに説明する、本発明の様々な実施形態を実施するコンピュータ読み取り可能プログラムコードを格納している。一実施形態では、ホスト１００はワークステーション、デスクトップパーソナルコンピュータ、又はラップトップパーソナルコンピュータである。一実施形態では、ホスト１００はパーソナルデータアシスタント（ＰＤＡ）、スマートホン、又はセルラー電話である。一実施形態では、ホスト１００は、セットトップボックス、インターネットメディアビュアー、インターネットメディアプレーヤ、スマートセンサ、スマートメディカルデバイス、ネットトップボックス、ネットワークテレビジョンセット、ネットワークＤＶＲ、ネットワークＢｌｕ−ｒａｙ（登録商標）プレーヤ、又はメディアセンターである。

一実施形態では、データネットワーク１５３はインターネットプロトコル（ＩＰ）ネットワークである。一実施形態では、データネットワーク１５３は、企業データネットワーク又は地域企業データネットワークである。一実施形態では、データネットワーク１５３はインターネットサービスプロバイダネットワークである。一実施形態では、データネットワーク１５３は住居データネットワークである。一実施形態では、データネットワーク１５３は、イーサネット（登録商標）などの有線ネットワークを含む。一実施形態では、データネットワーク１５３は、ＷｉＦｉネットワーク、セルラーネットワークなどの無線ネットワークを含む。

サービスゲートウェイ１１０は、プロセッサ１１３及びコンピュータ読み取り可能媒体１１４に動作可能に結合している。コンピュータ読み取り可能媒体１１４は、ここに説明する、プロセッサ１１３により実行された時、本発明の様々な実施形態を実施するコンピュータ読み取り可能プログラムコードを格納している。ある実施形態では、サービスゲートウェイ１１０は、複数のサーバへの負荷を分配する、サーバ負荷バランサ、アプリケーションデリバリコントローラ、サービスデリバリプラットフォーム、トラフィックマネージャ、セキュリティゲートウェイ、ファイアウォールシステムの一コンポーネント、仮想プライベートネットワーク（ＶＰＮ）の一コンポーネント、ビデオサーバの負荷バランサ、又はゲートウェイとして実装される。

サーバプール２００は、サーバ２１０などの複数のサーバを含む。サーバ２１０は、プロセッサ２１３及びコンピュータ読み取り可能媒体２１４に動作可能に結合している。コンピュータ読み取り可能媒体２１４は、ここに説明する、プロセッサ２１３により実行された時、本発明の様々な実施形態を実施するコンピュータ読み取り可能プログラムコードを格納している。ある実施形態では、コンピュータ読み取り可能プログラムコードは、サーバ２１０を、ウェブサーバ、ファイルサーバ、ビデオサーバ、データベースサーバ、アプリケーションサーバ、ボイスシステム、会議サーバ、メディアゲートウェイ、ＳＩＰサーバ、リモートアクセスサーバ、ＶＰＮサーバ、又はメディアセンターとして実施する。

一実施形態では、サーバプール２００は、さらに、サーバ２２０とサーバ２３０を含む。一実施形態では、サーバプール２００はデータセンター、サーバルーム、又はオフィスに配置されている。一実施形態では、サーバプール２００の複数のサーバは、地理的に複数の場所や複数のデータセンターにわたって配置されている。サービスゲートウェイ１１０はデータネットワーク１５５を介してサーバプール２００に接続している。一実施形態では、データネットワーク１５５はデータネットワーク１５３と同じものである。一実施形態では、データネットワーク１５５はデータネットワーク１５３と違うものである。一実施形態では、ホスト１００は、データネットワーク１５５には直接アクセスしない。一実施形態では、ホスト１００は、データネットワーク１５５には直接的にアクセスできる。

図２は、サービスゲートウェイによるサービス要求の処理の一実施形態を示すブロック図である。サービスゲートウェイ１１０は、サービス要求３０１中の情報に基づき、サービス要求３０１を処理するサーバ２１０を選択する。一実施形態では、サービス要求３０１は、ＵＲＬ（Universal Resource Locatｉｏｎ）を含む。

サービスゲートウェイ１１０は、サービス要求ＵＲＬ３１１に基づきサーバ２１０を選択する。サーバプール２００は、サービス要求ＵＲＬ３１１を用いて、サービス要求３０１を効率的に処理するように構成されている。サーバプール２００中のサーバは、あるＵＲＬに対してはプライマリサーバとして構成され、他のＵＲＬに対してはセカンダリサーバとして構成されている。一実施形態では、サーバ２１０は、ＵＲＬ３１１に対してプライマリサーバとして構成され、サーバ２２０はＵＲＬ３１１に対してセカンダリサーバとして構成されている。この実施形態では、サービスゲートウェイ１１０は、好ましくは、サービス要求３０１を処理するのにサーバ２１０を選択する。サーバ２１０がＵＲＬ３１１に対してプライマリサーバとして構成されているからである。サービスゲートウェイ１１０は、ある状況では、サービス要求３０１を処理するのにサーバ２２０を選択してもよい。サーバ２２０がＵＲＬ３１１に対してセカンダリサーバとして構成されているからである。一実施形態では、第２のサービス要求ＵＲＬ３１２があり第２のサービス要求３０２に対応している。サーバ２２０は、要求ＵＲＬ３１２を有するサービス要求をプライマリサーバとして処理するように構成されていてもよい。

図７は、サービスゲートウェイによるサービス要求の処理方法の一実施形態を示すフローチャートである。図２と図７を両方とも参照して、サービスゲートウェイ１１０は、サーバ２１０とサービスセッション１６０を確立し、サーバ２１０にサービス要求３０１を送る（７００）。サーバ２１０は、サービス要求３０１を処理する時、サービスゲートウェイ１１０にサービス応答３２１を送る（７０１）。サーバ２１０は、サービス応答３２１にサーバステータス２１８を含める。サーバステータス２１８は、サーバ２１０の可用性（availability）又は計算負荷状態を示すものである。一実施形態では、サーバステータス２１８は、ＣＰＵ利用、メモリ利用、ネットワーク利用、記憶利用、又はこれらの利用の一又は複数の組合せを反映する。一般的に、サーバステータス２１８は、サーバ２１０がどのくらいビジー状態であるかを示す（summarize）するものである。

サービスゲートウェイ１１０は、サーバ応答３２１からサーバステータス２１８を取得し（７０２）、そのサービス応答３２１をホスト１００にリレーする（７０３）。一実施形態では、サービスゲートウェイ１１０は、サービス応答３２１からサーバステータス２１８を削除して、サービス応答３２１を修正する。サービスゲートウェイ１１０は、次に、修正したサービス応答をホスト１００に送る。

サービス応答３２１は、サービス要求３１０のサービス結果を含む。サービス応答３２１は、さらに、タグ３２４を伴うサーバステータス２１８を含む。サービスゲートウェイ１１０は、サービス応答３２１のタグ３２４を識別して、タグ３２４を伴うサーバステータス２１８を取り出す。一実施形態では、サービス要求３０１はＨＴＴＰリクエストであり、サービス応答はＨＴＴＰレスポンスである。この実施形態では、タグ３２４はＨＴＴＰレスポンスのＨＴＴＰヘッダの中にある。一実施形態では、サービス応答３２１はＨＴＭＬ文書を含む。この実施形態では、タグ３２４はＨＴＭＬタグである。他の一実施形態では、サービス応答３２１はＸＭＬ文書を含み、タグ３２４はＸＭＬタグである。一実施形態では、サービス応答３２１はＳＩＰレスポンスパケットであり、タグ３２４はＳＩＰタグである。一実施形態では、サービス応答３２１はＦＴＰレスポンスであり、タグ３２４はＦＴＰリプライコードである。

図３は、サーバステータス２１８の取り得る値を示す図である。サーバステータス２１８について、システムの必要性に応じて、他の値を設定することもできる。一実施形態では、サーバステータス２１８の値０は、サーバがビジー状態ではないことを示す。サーバ２１０は遅延せずに新しい要求を処理できる。例えば、サービスゲートウェイ１１０は、要求ＵＲＬ３１１を有するサービス要求３０１を受信すると、サービス要求３０１を処理するためサーバ２１０を選択する。

サーバステータス２１８の値１は、サーバ２１０がビジー状態であることを示す。サーバ２１０は、ＵＲＬ３１１のプライマリサーバとしてサービスを続けられるが、セカンダリサーバとしてはサービスできない。例えば、サーバ２１０は、ＵＲＬ３１２のセカンダリサーバとして構成されているとする。サービスゲートウェイ１１０は、要求ＵＲＬ３１２を有するサービス要求３０２を受信しても、サービス要求３０２を処理するためにサーバ２１０は選択しない。

サーバステータス２１８の値２は、サーバ２１０がベリービジー（very busy）状態であることを示す。サーバステータス２１８の値が２であるということは、サーバ２１０がセカンダリサーバとしてサービスできないことを示すのに加え、新しいサービス要求をプライマリサーバとして処理するためにサーバ２１０を選択する前に、制限をかけるべきことも示す。例えば、サービスゲートウェイ１１０は、要求ＵＲＬ３１１を有するサービス要求３０１を受信すると、サービス要求３０１を処理するためにサーバ２１０を選択する前に制限をかける。この制限については、図４を参照してさらに詳しく説明する。

図４は、サーバ状態を受信後の、サービスゲートウェイによるサービス要求の処理の一実施形態を示すブロック図である。一実施形態では、サービスゲートウェイ１１０はサービス要求バッファ３３１を含む。サービス要求バッファ３３１は、要求ＵＲＬ３１１を有するサービス要求を格納するように構成されている。一実施形態では、サーバ２１０は、ＵＲＬ３１１に対してプライマリサーバとして構成され、要求ＵＲＬ３１３に対してセカンダリサーバとして構成されている。サービスゲートウェイ１１０はさらにサービス要求バッファ３３２を含み、サービス要求バッファ３３２は要求ＵＲＬ３１３を有するサービス要求を格納するように構成されている。一例では、サービス要求バッファ３３２は要求ＵＲＬ３１３を有するサービス要求３０３を含む。

サービスゲートウェイ１１０は、図２に示した前のサービス要求へのサービス応答で、サーバ２１０からサーバステータス２１８を受信している。図４と図７を参照して、サービスゲートウェイ１１０は、ホスト１００から次のサービス要求４１０を受信する（７０４）。サービスゲートウェイ１１０は、サービス要求バッファ３３１に、要求ＵＲＬ３１１を有するサービス要求４１０を格納し、サーバステータス２１８の値に応じてサービス要求バッファ中のサービス要求４１０を処理する。

一実施形態では、サーバステータス２１８の値は０であり、サーバ２１０が「ビジー状態ではない」ことを示す。サービスゲートウェイ１１０は、（第１の）サービス要求バッファ３３１を調べ、（第１の）要求ＵＲＬ３１１を有するサービス要求４１０を発見する。サーバ２１０はこの要求ＵＲＬに対してプライマリサーバとして構成されている（７０５）。サービスゲートウェイ１１０は、サーバ２１０を選択し、サーバ２１０にサービス要求４１０を送る（７０７）。一実施形態では、サービスゲートウェイ１１０が要求ＵＲＬ３１１を有する次のサービス要求を受信した時、サービス要求バッファ３３１は空である。サービスゲートウェイ１１０は、このサービス要求を、サービ要求バッファ３３１に入れずに、サーバ２１０に送る。

サーバステータス２１８の値が０であるこの実施形態では、サービスゲートウェイ１１０は、（第２の）サービス要求バッファ３３２を調べ、（第２の）要求ＵＲＬ３１３を有するサービス要求４１１を発見する。サーバ２１０はこの要求ＵＲＬ３１３に対してセカンダリサーバとして構成されている（７０６）。サーバステータス２１８は、サーバ２１０がセカンダリサーバとしてサービスできることを示しているので、サービスゲートウェイ１１０はサービス要求４１１を処理するためにサーバ２１０を選択する（７１１）。

一実施形態では、サービスゲートウェイ１１０が要求ＵＲＬ３１３を含む次のサービス要求を受信した時、サービス要求バッファ３３２は空である。サービスゲートウェイ１１０は、このサービス要求をサービス要求バッファ３３２に入れずに、このサービス要求を処理するためにサーバ２１０を選択してもよい。

一実施形態では、サーバステータス２１８の値は１であり、サーバ２１０がビジー状態であり、ＵＲＬ３１３のセカンダリサーバとしてサービスできないが、プライマリサーバとしてはサービスできることを示す。サービスゲートウェイ１１０は、サービス要求バッファ３３１を調べる。一実施形態では、サービスゲートウェイ１１０は、サービス要求バッファ３３１中にサービス要求４１０を発見する（７０５）。サービスゲートウェイ１１０は、サービス要求４１０をサーバ２１０に送る（７０８）。一実施形態では、サービスゲートウェイ１１０が要求ＵＲＬ３１１を含む次のサービス要求を受信した時、サービス要求バッファ３３１は空である。サービスゲートウェイ１１０は、このサービス要求を、サービ要求バッファ３３１に入れずに、サーバ２１０に送る。

サーバステータス２１８の値が１であるこの実施形態では、サービスゲートウェイ１１０は、サービス要求バッファ３３２を調べて、サービス要求バッファ３３２中にサービス要求４１１を見つける（７０６）。サービスゲートウェイ１１０は、サービス要求４１１を処理するためにサーバ２１０を選択しない（７１２）。その替わり、サービスゲートウェイ１１０は、サービス要求４１１を処理するために、サーバプール２００中の他のサーバを選択する（７１３）。一シナリオでは、サービスゲートウェイ１１０が要求ＵＲＬ３１３を含む次のサービス要求を受信した時、サービス要求バッファ３３２は空である。サービスゲートウェイ１１０は、サービス要求を処理するためにサーバ２１０を選択しない（７１２）。

一実施形態では、サーバステータス２１８の値は２であり、サーバ２１０が「ベリービジー状態」であることを示す。この実施形態では、サーバ２１０は、ＵＲＬ３１３に対してセカンダリサーバとしてサービスできず、制限付きでプライマリサーバとしてサービスできる。サーバステータス２１８の値が２であるこの実施形態では、サービスゲートウェイ１１０は、サービス要求バッファ３３１を調べて、サービス要求４１０を見つける（７０５）。サービスゲートウェイ１１０は、サーバ２１０には、サービス要求４１０を自動的には送らない。一実施形態では、サービスゲートウェイ１１０はタイマー１１７を含む。サービスゲートウェイ１１０は、タイマー１１７が満了するのを待ち（７０９）、それからサーバ２１０を選択して、要求４１０をサーバ２１０に送る（７１０）。一実施形態では、サービスゲートウェイ１１０は、サーバステータス２１８の値２であるステータス応答３２１を受信してからタイマー１１７を設定する。タイマー１１７は、例えば、１分、３０秒、１秒、４００ミリ秒、５ミリ秒、３００マイクロ秒、その他のサービス要求４１０に対するサービスに大きな影響を与えない長さに設定できる。一実施形態では、タイマー１１７の時間的長さは、サービス要求４１０のセッションプロトコルタイムアウト時間に基づく。

サーバステータス２１８の値が２である一実施形態では、サービスゲートウェイ１１０が要求ＵＲＬ３１１を有する次のサービス要求を受信した時、サービス要求バッファ３３１は空である。サービスゲートウェイ１１０は、このサービス要求をサービス要求バッファ３３１に格納する。後でタイマー１１７が満了した時、サービスゲートウェイ１１０は、サービス要求バッファ３３１を調べて、このサービス要求を見つける（７０５）。タイマー１１７が満了した時（７０９）、サービスゲートウェイ１１０はサーバ２１０を選択し、このサービス要求をサーバ２１０に送る（７１０）。一実施形態では、サービスゲートウェイ１１０はサービス要求バッファ３３１を処理した後に、再びタイマー１１７を設定する。一実施形態では、サービスゲートウェイ１１０は、サービス要求バッファ３３１中の複数の要求を処理してから、タイマー１１７を再び設定する。一実施形態では、サービスゲートウェイ１１０は、値０又は１であるサーバステータス２１８を受信した時に、タイマー１１７をキャンセルする。

サーバステータス２１８の値が２であるこの実施形態では、サービスゲートウェイ１１０は、サービス要求バッファ３３２を調べて、サービス要求バッファ３３２中にサービス要求４１１を見つける（７０６）。サービスゲートウェイ１１０は、サービス要求４１１を処理するためにサーバ２１０を選択しない（７１４）。その替わり、サービスゲートウェイ１１０は、サービス要求４１１を処理するために、サーバプール２００中の他のサーバを選択する（７１３）。一実施形態では、サービスゲートウェイ１１０が要求ＵＲＬ３１３を含む次のサービス要求を受信した時、サービス要求バッファ３３２は空である。サービスゲートウェイ１１０は、サービス要求を処理するためにサーバ２１０を選択しない。

図５は、サービス優先度に応じてサービス要求を処理するサービスゲートウェイを示す図である。サービス優先度は、サービス要求の要求ＵＲＬ、サービス要求が送信されたホスト、サービスゲートウェイ１１０がサービス要求を受信するデータネットワークなど、様々なパラメータに基づき設定できる。一実施形態では、優先度とパラメータ値との間のサービス優先度関連付け（service priority association）５５０がサービスゲートウェイ１１０に格納される。例えば、優先度４０１がＵＲＬ３１１と関連付けられ、優先度４０１とＵＲＬ３１１との間の関連付け（association）５５０がサービスゲートウェイ１１０に格納される。他の一例では、優先度４０１は、ホスト１００のＩＰアドレスやホスト１００のユーザ識別情報など、ホスト１００と関連付けられている。優先度４０１とホスト１００との間の関連付け５５０がサービスゲートウェイ１１０に格納される。他の一例では、優先度４０１は、サービス要求４１０を受信したネットワークインタフェースと関連付けられ、優先度４０１とネットワークインタフェースとの間の関連付け５５０がサービスゲートウェイ１１０に格納される。一実施形態では、サービスゲートウェイ１１０は関連付け５５０を格納するデータストア（図示せず）を含む。サービスゲートウェイ１１０は、サービス要求４１０の適切なパラメータを格納された関連付け５５０とマッチングさせて、サービス要求４１０の優先度４０１を決定する。

一実施形態では、サービスゲートウェイ１１０は、要求ＵＲＬ３１１を有するサービス要求を格納するように構成されたサービス要求バッファ３３３と、ＵＲＬ３１１に対するサービス要求を格納するようにも構成されたサービス要求バッファ３３１を含む。サービス要求バッファ３３３は、サービス優先度４０１より高いサービス優先度４０３を有するサービス要求を格納するように構成されている。サービス要求バッファ３３１は、サービス優先度４０１を有するサービス要求を格納するように構成されている。一実施形態では、サーバステータス２１８の値は２であり、サービスゲートウェイ１１０は、要求ＵＲＬ３１１と優先度４０１とを有するサービス要求をサービス要求バッファ３３１に格納する。サービスゲートウェイ１１０は、さらに、要求ＵＲＬ３１１とサービス優先度４０３とを有するサービス要求４１２を受信する。サービスゲートウェイ１１０は、サービス要求４１２をサービス要求バッファ３３３に格納する。

タイマー１１７が満了すると、サービスゲートウェイ１１０は、高い方の優先度４０３を有するサービス要求バッファ３３３を調べてから、低い方の優先度４０１を有するサービス要求バッファ３３１を調べる。この例では、サービスゲートウェイ１１０は、サービス要求４１０を処理してから、サービス要求４１２を処理する。

一実施形態では、サービスゲートウェイ１１０は、サーバ２１０の値が０又は１である新しいサーバステータス２１９を受け取り、高い方の優先度４０３を有するサービス要求バッファ３３３を調べ続けてから、低い方の要求４０１を有するサービス要求バッファ３３１を調べる。この例では、サービスゲートウェイ１１０は、サービス要求４１２を処理してから、サービス要求４１１を処理する。

一実施形態では、サービスゲートウェイ１１０は、サーバステータス２１８の値にかかわらず、サービス要求バッファ３３３を処理する前に、サービス要求バッファ３３２のすべてのサービス要求を処理する。一実施形態では、サービスゲートウェイ１１０はサービス比率（serving ratio）１１９を含み、比率１１９に応じて、サービス要求バッファ３３３とサービス要求バッファ３３１中のサービス要求を処理する。サービス比率１１９は、サービス要求バッファ３３１中に優先度が低いサービス要求が無くならないように、優先度が低いサービス要求バッファ３３１よりも優先度が高いサービス要求バッファ３３３を優先して処理する。

好ましい実施形態では、サーバ２１０は、複数のＵＲＬのプライマリサーバとしてサービスするように構成されている。図６は、サービスゲートウェイ１１０によるサービス要求の処理の一実施形態を示す図である。一実施形態では、ＵＲＬ３１１とＵＲＬ３１３にハッシュ関数５０２を適用する。ＵＲＬ３１１にハッシュ関数５０２を適用すると、その結果ハッシュ値５１１が得られる。同様に、ＵＲＬ３１３にハッシュ関数５０２を適用すると、その結果ハッシュ値５１３が得られる。一実施形態では、サーバ２１０はハッシュ値５２０に対するプライマリサーバとしてサービスするように構成されている。一実施形態では、サービスゲートウェイ１１０は、ハッシュ関数５０２とハッシュ値５２０とを格納している。ハッシュ関数５０２の例としては、ＭＤ５（Message-Digest algorithm 5）ハッシュ関数、Ｊｅｎｋｉｎｓハッシュ関数、文字列に適用可能なハッシュ関数、テーブルルックアップ用のハッシュ関数などがある。

サービスゲートウェイ１１０は、要求ＵＲＬ３１１を有するサービス要求４１０を受信すると、要求ＵＲＬ３１１にハッシュ関数５０２を適用してハッシュ値５１１を求める。サービスゲートウェイ１１０はハッシュ値５１１をハッシュ値５２０と比較する。ハッシュ値５１１がハッシュ値５２０と一致すると、サービスゲートウェイ１１０は、上記のようにサービス要求３０１を処理するため、サーバ２１０を選択する。一実施形態では、サービスゲートウェイ１１０は、要求ＵＲＬ３１３を有するサービス要求４１１を受信する。サービスゲートウェイ１１０は、要求ＵＲＬ３１３にハッシュ関数５０２を適用してハッシュ値５１３を求める。サービスゲートウェイ１１０はハッシュ値５１３をハッシュ値５２０と比較する。ハッシュ値５１３がハッシュ値５２０と一致すると、サービスゲートウェイ１１０は、サービス要求４１１を処理するため、サーバ２１０を選択する。一実施形態では、ハッシュ値５１３がハッシュ値５２０と一致せず、サービスゲートウェイ１１０はサーバ２１０を自動的に選択しない。

一実施形態では、サーバ２１０はハッシュ値５１３に対するセカンダリサーバとしてサービスするように構成されている。サービスゲートウェイ１１０はサーバ２１０を選択する。一実施形態では、サーバ２１０はハッシュ値５１３にサービスするようには構成されておらず、サービスゲートウェイ１１０はサービス要求４１１を処理するためにサーバ２１０を選択しない。

この実施形態では、サービスゲートウェイ１１０は、サービス要求を処理する時、そのサービス要求にハッシュ関数５０２を適用する。サービスゲートウェイ１１０は、サーバ２１０がハッシュ値５１３に対してプライマリサーバ又はセカンダリサーバのどちらとして構成されているか判断し、サーバステータス２１８を用いて上記のようにサービス要求４１０を処理する。当業者には、本発明の精神と範囲から逸脱することなく、ハッシュ関数の適用を上記のプロセスとどのように組み合わせればよいか、分かるだろう。

本発明を実施形態を参照して説明したが、本技術分野の当業者には言うまでもなく、これらの実施形態にはバリエーションがあり、これらのバリエーションも本発明の精神と範囲に含まれる。したがって、本技術分野の当業者は、添付した特許請求の範囲の精神と範囲から逸脱せずに、多くの修正をすることができる。

Claims (24)

1. サーバ負荷状態に基づいて複数のサーバをバランスさせる方法であって、
   （ａ）サービスゲートウェイが、第１と第２のサーバから、それぞれ第１と第２のユニフォームリソースロケータ（ＵＲＬ）を含む第１と第２のサービス要求に対する第１と第２のサービス応答を受信するステップと、
   （ｂ）前記サービスゲートウェイが、前記第１と第２のサービス応答からそれぞれ前記第１と第２のサーバステータスを取得するステップと、
   （ｃ）前記サービスゲートウェイが、一ホストから、第３のＵＲＬを含む第３のサービス要求を受信するステップと、
   （ｄ）前記サービスゲートウェイが、前記第１のサーバがプライマリサーバとして前記第３のＵＲＬを処理するように構成されており、前記第２のサーバがセカンダリサーバとして前記第３のＵＲＬを処理するように構成されていると判断するステップと、
   （ｅ）前記サービスゲートウェイが、前記第１のサーバが一時的にプライマリサーバとして前記第３のサービス要求を処理できないことを前記第１のサーバステータスが示し、前記第２のサーバが一時的にセカンダリサーバとして前記第３のサービス要求を処理できることを前記第２のサーバステータスが示すと判断するステップと、
   （ｆ）前記第１のサーバが一時的にプライマリサーバとして前記第３のサービス要求を処理できないことを前記第１のサーバステータスが示し、前記第２のサーバが一時的にセカンダリサーバとして前記第３のサービス要求を処理できることを前記第２のサーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記第３のサービス要求を前記第２のサーバに送るステップと
   を有する、方法。
2. 前記受信するステップ（ａ）は、
   （ａ１）前記サービスゲートウェイと前記サーバとの間のサービスセッションを確立するステップと、
   （ａ２）前記サービスゲートウェイが、前記サービス要求を前記サーバに送るステップと、
   （ａ３）前記サービスゲートウェイが、前記サーバから、前記サーバによる前記サービス要求の処理結果と前記サーバの計算負荷状態を示す前記サーバステータスとを含む前記サービス応答を受信するステップとを有する、
   請求項１に記載の方法。
3. 前記取得するステップ（ｂ）は、
   （ｂ１）前記サービスゲートウェイが、前記サービス応答から前記サーバステータスを取得するステップと、
   （ｂ２）前記サービスゲートウェイが、前記サービス応答から前記サーバステータスを削除することにより前記サービス応答を修正するステップと、
   （ｂ３）前記サービスゲートウェイが、前記サービス要求を送ったホストに、前記修正されたサービス応答を送るステップとを有する、
   請求項２に記載の方法。
4. 前記判断するステップ（ｄ）は、
   （ｄ１）前記サービスゲートウェイが、前記サーバがプライマリサーバとして又はセカンダリサーバとして前記ＵＲＬを処理するように構成されているか判断するステップと、
   （ｄ２）前記サーバがプライマリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記サービスゲートウェイが、前記第３のサービス要求を、プライマリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第１のバッファに格納するステップと、
   （ｄ３）前記サーバがセカンダリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記サービスゲートウェイが、前記第３のサービス要求を、セカンダリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第２のバッファに格納するステップとを有する、
   請求項１に記載の方法。
5. 前記サーバは、プライマリサーバとして前記ＵＲＬを処理するように構成されていると判断され、
   前記判断するステップ（ｅ）と送るステップ（ｆ）は、
   （ｅ１）前記サービスゲートウェイが、前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断するステップと、
   （ｆ１）前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記第１のバッファにおいて前記第３のサービス要求を発見するステップと、
   （ｆ２）前記サービスゲートウェイが、前記第３のサービス要求を前記サーバに送るステップとを有する、
   請求項４に記載の方法。
6. 前記サーバは、セカンダリサーバとして前記ＵＲＬを処理するように構成されていると判断され、
   前記判断するステップ（ｅ）と送るステップ（ｆ）は、
   （ｅ１）前記サービスゲートウェイが、前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断するステップと、
   （ｆ１）前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記サーバを選択するか判断するステップと、
   （ｆ２）前記サーバを選択するとの判断に応じて、前記サービスゲートウェイが、前記第２のバッファにおいて前記第３のサービス要求を発見するステップと、
   （ｆ３）前記サービスゲートウェイが、前記第３のサービス要求を前記サーバに送るステップとを有する、
   請求項４に記載の方法。
7. 前記判断するステップ（ｄ）は、
   （ｄ１）前記サービスゲートウェイが、前記サーバが所定のハッシュ値を有するサービス要求を処理するように構成されていると判断するステップと、
   （ｄ２）前記サービスゲートウェイが、前記第３のサービス要求中のＵＲＬにハッシュ関数を適用するステップと、
   （ｄ３）前記サービスゲートウェイが、前記ＵＲＬのハッシュ値が前記所定のハッシュ値と一致すると判断するステップとを有する、
   請求項１に記載の方法。
8. 前記判断するステップ（ｄ）と判断するステップ（ｅ）と送るステップ（ｆ）は、
   （ｄ１）前記サービスゲートウェイが、前記サーバが前記ＵＲＬを処理するように構成されていると判断するステップと、
   （ｄ２）前記サービスゲートウェイが、前記第３のサービス要求の所定のパラメータに基づき、前記第３のサービス要求の優先度を判断するステップと、
   （ｄ３）前記サービスゲートウェイが、前記所定の優先度を有するサービス要求を格納するように構成されているバッファに、前記第３のサービス要求を格納するステップと、
   （ｅ１）前記サービスゲートウェイが、前記サーバが前記サービス要求を処理できることを前記サーバステータスが示すか判断するステップと、
   （ｆ１）前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サービスゲートウェイが、前記サーバが前記所定の優先度を有するサービス要求を処理するか判断するステップと、
   （ｆ２）前記サーバが前記所定の優先度を有するサービス要求を処理するとの判断に応じて、前記サービスゲートウェイが、前記所定の優先度を有するサービス要求を格納するように構成されたバッファにおいて前記第３のサービス要求を発見するステップと、
   （ｆ３）前記サービスゲートウェイが、前記第３のサービス要求を前記サーバに送るステップとを有する、
   請求項１に記載の方法。
9. サーバ負荷状態に基づいて複数のサーバをバランスさせるコンピュータプログラムであって、コンピュータに、
   第１と第２のサーバから、それぞれ第１と第２のユニフォームリソースロケータ（ＵＲＬ）を含む第１と第２のサービス要求に対する第１と第２のサービス応答を受信し、
   前記第１と第２のサービス応答からそれぞれ前記第１と第２のサーバステータスを取得し、
   一ホストから、第３のＵＲＬを含む第３のサービス要求を受信し、
   前記第１のサーバがプライマリサーバとして前記第３のＵＲＬを処理するように構成されており、前記第２のサーバがセカンダリサーバとして前記第３のＵＲＬを処理するように構成されていると判断し、
   前記第１のサーバが一時的にプライマリサーバとして前記第３のサービス要求を処理できないことを前記第１のサーバステータスが示し、前記第２のサーバが一時的にセカンダリサーバとして前記第３のサービス要求を処理できることを前記第２のサーバステータスが示すと判断し、
   前記第１のサーバが一時的にプライマリサーバとして前記第３のサービス要求を処理できないことを前記第１のサーバステータスが示し、前記第２のサーバが一時的にセカンダリサーバとして前記第３のサービス要求を処理できることを前記第２のサーバステータスが示すとの判断に応じて、前記第３のサービス要求を前記第２のサーバに送らせる、
   コンピュータプログラム。
10. 前記コンピュータに、さらに、
    前記サーバとサービスセッションを確立し、
    前記サーバに前記サービス要求を送り、
    前記サーバから、前記サーバによる前記サービス要求の処理結果と前記サーバの計算負荷状態を示す前記サーバステータスとを含む前記サービス応答を受信させる、
    請求項９に記載のコンピュータプログラム。
11. 前記コンピュータに、さらに、
    前記サービス応答から前記サーバステータスを取得し、
    前記サービス応答から前記サーバステータスを削除することにより前記サービス応答を修正し、
    前記サービス要求を送ったホストに前記修正されたサービス応答を送らせる、
    請求項１０に記載のコンピュータプログラム。
12. 前記コンピュータに、さらに、
    前記サーバがプライマリサーバとして又はセカンダリサーバとして前記ＵＲＬを処理するように構成されているか判断し、
    前記サーバがプライマリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記第３のサービス要求を、プライマリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第１のバッファに格納し、
    前記サーバがセカンダリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記第３のサービス要求を、セカンダリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第２のバッファに格納させる、請求項９に記載のコンピュータプログラム。
13. 前記サーバは、プライマリサーバとして前記ＵＲＬを処理するように構成されていると判断され、
    前記コンピュータに、さらに、
    前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断し、
    前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記第１のバッファにおいて前記第３のサービス要求を発見させる、
    前記サーバに前記第３のサービス要求を送る
    ように構成された、請求項１２に記載のコンピュータプログラム。
14. 前記サーバは、セカンダリサーバとして前記ＵＲＬを処理するように構成されていると判断され、
    前記コンピュータに、さらに、
    前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断し、
    前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サーバを選択するか判断し、
    前記サーバを選択するとの判断に応じて、前記第２のバッファにおいて前記第３のサービス要求を発見し、
    前記サーバに前記第３のサービス要求を送らせる、請求項１２に記載のコンピュータプログラム。
15. 前記コンピュータに、さらに、
    前記サーバが所定のハッシュ値を有するサービス要求を処理するように構成されていると判断し、
    前記第３のサービス要求中のＵＲＬにハッシュ関数を適用し、
    前記ＵＲＬのハッシュ値が前記所定のハッシュ値と一致すると判断させる、請求項９に記載のコンピュータプログラム。
16. 前記コンピュータに、さらに、
    前記サーバが前記ＵＲＬを処理するように構成されていると判断し、
    前記第３のサービス要求の所定のパラメータに基づき、前記第３のサービス要求の優先度を判断し、
    前記判断された優先度を有するサービス要求を格納するように構成されたバッファに、前記第３のサービス要求を格納し、
    前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すか判断し、
    前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サーバが前記所定の優先度を有するサービス要求を処理するか判断し、
    前記サーバが前記所定の優先度を有するサービス要求を処理するとの判断に応じて、前記所定の優先度を有するサービス要求を格納するように構成されたバッファにおいて前記第３のサービス要求を発見し、
    前記サーバに前記第３のサービス要求を送らせる、請求項９に記載のコンピュータプログラム。
17. サービス要求を処理する第１と第２のサーバと、
    プロセッサと、コンピュータ読み取り可能プログラムコードを有するコンピュータ読み取り可能記憶媒体とを有するサービスゲートウェイとを有するシステムであって、
    前記コンピュータ読み取り可能プログラムコードは、前記プロセッサにより実行されると、前記サービスゲートウェイに、
    第１と第２のサーバから、それぞれ第１と第２のユニフォームリソースロケータ（ＵＲＬ）を含む第１と第２のサービス要求に対する第１と第２のサービス応答を受信し、
    前記第１と第２のサービス応答からそれぞれ前記第１と第２のサーバステータスを取得し、
    一ホストから、第３のＵＲＬを含む第３のサービス要求を受信し、
    前記第１のサーバがプライマリサーバとして前記第３のＵＲＬを処理するように構成されおり、前記第２のサーバがセカンダリサーバとして前記第３のＵＲＬを処理するように構成されていると判断し、
    前記第１のサーバが一時的にプライマリサーバとして前記第３のサービス要求を処理できないことを前記第１のサーバステータスが示し、前記第２のサーバが一時的にセカンダリサーバとして前記第３のサービス要求を処理できることを前記第２のサーバステータスが示すと判断し、
    前記第１のサーバが一時的にプライマリサーバとして前記第３のサービス要求を処理できないことを前記第１のサーバステータスが示し、前記第２のサーバが一時的にセカンダリサーバとして前記第３のサービス要求を処理できることを前記第２のサーバステータスが示すとの判断に応じて、前記第３のサービス要求を前記第２のサーバに送る
    ように構成された、システム。
18. 前記サーバから前記サービス要求に対するサービス応答を受信することは、
    前記サーバとサービスセッションを確立し、
    前記サーバに前記サービス要求を送り、
    前記サーバから、前記サーバによる前記サービス要求の処理結果と前記サーバの計算負荷状態を示す前記サーバステータスとを含む前記サービス応答を受信することを含む、
    請求項１７に記載のシステム。
19. 前記サービス応答から前記サーバステータスを取得することは、
    前記サービス応答から前記サーバステータスを取得し、
    前記サービス応答から前記サーバステータスを削除することにより前記サービス応答を修正し、
    前記サービス要求を送ったホストに前記修正されたサービス応答を送る、
    請求項１８に記載のシステム。
20. プライマリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第１のバッファと、セカンダリサーバとして前記サーバにより処理されるサービス要求を格納するように構成された第２のバッファとをさらに有し、
    前記サーバが前記ＵＲＬを処理するように構成されていると判断することは、
    前記サーバがプライマリサーバとして又はセカンダリサーバとして前記ＵＲＬを処理するように構成されているか判断し、
    前記サーバがプライマリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記第１のバッファに前記第３のサービス要求を格納し、
    前記サーバがセカンダリサーバとして前記ＵＲＬを処理するように構成されているとの判断に応じて、前記第２のバッファに前記第３のサービス要求を格納する
    ことを含む、請求項１７に記載のシステム。
21. 前記サーバは、プライマリサーバとして前記ＵＲＬを処理するように構成されていると判断され、
    前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すか判断することと、前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記第３のサービス要求を前記サーバに送ることとは、
    前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断し、
    前記サーバがプライマリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記第１のバッファにおいて前記第３のサービス要求を発見し、
    前記サーバに前記第３のサービス要求を送る
    ことを含む、請求項２０に記載のシステム。
22. 前記サーバは、セカンダリサーバとして前記ＵＲＬを処理するように構成されていると判断され、
    前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すか判断することと、前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記第３のサービス要求を前記サーバに送ることとは、
    前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すか判断し、
    前記サーバがセカンダリサーバとして前記サービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サーバを選択するか判断し、
    前記サーバを選択するとの判断に応じて、前記第２のバッファにおいて前記第３のサービス要求を発見し、
    前記サーバに前記第３のサービス要求を送る
    ことを含む、請求項２０に記載のシステム。
23. 前記サーバが前記ＵＲＬを処理するように構成されていると判断することは、
    前記サーバが所定のハッシュ値を有するサービス要求を処理するように構成されていると判断し、
    前記第３のサービス要求中のＵＲＬにハッシュ関数を適用し、
    前記ＵＲＬのハッシュ値が前記所定のハッシュ値と一致すると判断する
    ことを含む、請求項１７に記載のシステム。
24. 前記サービスゲートウェイは優先度を有するサービス要求を格納するように構成されたバッファを有し、
    前記サーバが前記ＵＲＬを処理するように構成されていると判断することと、前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すか判断することと、前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記第３のサービス要求を前記サーバに送ることとは、
    前記サーバが前記ＵＲＬを処理するように構成されていると判断し、
    前記第３のサービス要求の所定のパラメータに基づき、前記第３のサービス要求の優先度を決定し、
    前記バッファに前記第３のサービス要求を格納し、
    前記サーバが前記サービス要求を処理できることを前記サーバステータスが示すか判断し、
    前記サーバが前記第３のサービス要求を処理できることを前記サーバステータスが示すとの判断に応じて、前記サーバが前記優先度を有するサービス要求を処理するか判断し、
    前記サーバが前記所定の優先度を有するサービス要求を処理するとの判断に応じて、前記優先度を有するサービス要求を格納するように構成されたバッファにおいて前記第３のサービス要求を発見し、
    前記サーバに前記第３のサービス要求を送る
    ことを含む、請求項１７に記載のシステム。

Images