JP2008059060A - サービス連携サーバ及び負荷分散方法 - Google Patents

Abstract

【課題】高いスケーラビリティを実現し、また、急激な需要増に柔軟に対応可能とする。
【解決手段】ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０において、振り分け判定部は、信号を受信したときに、信号にセッション識別子が含まれているか判別し、信号にセッション識別子が含まれている場合には、サーバ２０−１〜２０−４に対する信号であるか否かを判別する。そして、サーバ２０−１〜２０−４に対する信号である場合には、セッション識別子から、セッション管理部にて埋め込んだＩＰアドレスを抽出し、そのＩＰアドレスに対して信号送信を行う。
【選択図】図１

Description

本発明は、ウェブサービスとテレコムサービスとを連携させるための連携サーバにおけるサービス連携サーバ及び負荷分散方法に関する。

ウェブサービスや、ＶｏＩＰ（Voice over Internet Protocol）サービスなどにおいて、高スケーラビリティを実現する場合、ロードバランサ（負荷分散装置）による負荷分散を行うのが一般的である（例えば、非特許文献１参照）。

ＨＴＴＰ（Hyper Text Transfer Protocol）や、ＳＩＰ（Session Initiation Protocol）などにおいて、複数のリクエストにおいて参照する必要がある共通のセッションデータが存在するサーバに対してロードバランサを適用する場合、ロードバランサにて、リクエストをセッションデータが存在するサーバに対して正しく振り分ける必要がある。

セッションを考慮したロードバランス方式としては、ＨＴＴＰにおけるＣｏｏｋｉｅＩＤや、ＳＩＰにおけるＣａｌｌ−ＩＤ等のセッション識別子を元にロードバランサにて負荷分散を行うことが一般的である。しかし、両者が連携するシステムにおいて、双方のセッションを同時に意識した振り分け方式は、検討されていない。
Tony Bourke著、鍋島公章 監訳、サーバ負荷分散技術、オライリー・ジャパン、２００１年、ｐ１８５−１８８

ところで、ウェブ系サービスとテレコム系サービスとを連携させる場合、複雑なテレコム系プロトコルをアプリケーションから扱いやすいＡＰＩに変換するサービス連携サーバの適用が有効である。サービス連携サーバは、ＨＴＴＰ等のウェブ系プロトコルと、Ｈ３２３やＳＩＰ等のテレコム系プロトコルの双方を同時に扱うシステムであり、双方のリクエストが１つのセッションデータを共有する場合がある。

一般的に、ＨＴＴＰのセッション識別子とＳＩＰのセッション識別子とは、各々、独立して設定されるため、そのようなシステムにおいて、ロードバランサによる負荷分散を実施する場合、既存方式であるセッション識別子による振り分け方式では、対応することができない。そのため、双方のプロトコルにおけるセッションを意識したロードバランス方式を実現する必要がある。

本発明は、このような事情を考慮してなされたものであり、その目的は、サービス連携サーバにおいて、高いスケーラビリティを実現することができ、また、急激な需要増に柔軟に対応することができるサービス連携サーバ及び負荷分散方法を提供することにある。

上述した課題を解決するために、本発明は、複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分けるサービス連携サーバであって、前記複数のプロトコルによるリクエストの初回発生時に、該リクエストのセッション識別子と、該リクエストに対応するサービスを提供するサーバのサーバ識別子とから、新たなセッション識別子を生成するセッション識別子生成手段と、前記リクエストの初回発生時以降に発生した前記複数のプロトコルによるリクエストが前記複数のサーバのいずれかに対するリクエストであるか否かを判別する判別手段と、前記判別手段により、前記リクエストが前記複数のサーバのいずれかに対するリクエストであると判別された場合、前記複数のプロトコルによるリクエストに含まれるセッション識別子からサーバ識別子を抽出する抽出手段と、前記抽出手段によって抽出されたサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定するサーバ特定手段とを具備することを特徴とするサービス連携サーバである。

上述した課題を解決するために、本発明は、複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分けるサービス連携サーバであって、
前記複数のサーバによって提供される全てのサービスにアクセス可能なように、前記複数のサーバによって提供されるサービスデータを一元的に管理するサービスデータ管理手段を具備することを特徴とするサービス連携サーバである。

上述した課題を解決するために、本発明は、複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分けるサービス連携サーバであって、前記リクエストに含まれるセッション識別子と前記複数のサーバのサーバ識別子とを対応付けて記憶する振り分け先管理記憶手段と、前記複数のプロトコルによるリクエストに含まれるセッション識別子に基づいて、前記振り分け先管理記憶手段から対応するサーバ識別子を取得するサーバ識別子取得手段と、前記サーバ識別子取得手段によって取得されたサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定するサーバ特定手段とを具備することを特徴とするサービス連携サーバである。

本発明は、上記に記載の発明において、前記複数のプロトコルによるリクエストが前記複数のサーバのいずれかに対するリクエストであるか否かを判別する判別手段と、前記判別手段により、前記リクエストが前記複数のサーバのいずれかに対するリクエストでないと判別された場合、前記リクエストに含まれるセッション識別子と、リクエスト送信元のサーバ識別子とを対応付けて前記振り分け先管理記憶手段に登録する登録手段とを具備することを特徴とする。

本発明は、複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分ける負荷分散方法であって、前記複数のプロトコルによるリクエストの初回発生時に、該リクエストのセッション識別子と、該リクエストに対応するサービスを提供するサーバのサーバ識別子とから、新たなセッション識別子を生成し、前記リクエストの初回発生時以降に発生した前記複数のプロトコルによるリクエストが前記複数のサーバのいずれかに対するリクエストであるか否かを判別し、前記複数のサーバのいずれかに対するリクエストであると判別された場合、前記複数のプロトコルによるリクエストに含まれるセッション識別子からサーバ識別子を抽出し、抽出したサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定することを特徴とする負荷分散方法である。

本発明は、複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分ける負荷分散方法であって、前記複数のサーバによって提供される全てのサービスにアクセス可能なように、前記複数のサーバによって提供されるサービスデータを一元的に管理することを特徴とする負荷分散方法である。

本発明は、複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分ける負荷分散方法であって、前記リクエストに含まれるセッション識別子と前記複数のサーバのサーバ識別子とを対応付けて記憶しておき、前記複数のプロトコルによるリクエストに含まれるセッション識別子に対応するサーバ識別子を取得し、取得したサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定することを特徴とする負荷分散方法である。

この発明によれば、複数のプロトコルによるリクエストの初回発生時に、該リクエストのセッション識別子と、該リクエストに対応するサービスを提供するサーバのサーバ識別子とから、新たなセッション識別子を生成し、前記初回発生時以降に発生した前記複数のプロトコルによるリクエストが前記複数のサーバのいずれかに対するリクエストであるか否かを判別し、複数のサーバのいずれかに対するリクエストであると判別された場合、複数のプロトコルによるリクエストに含まれるセッション識別子からサーバ識別子を抽出し、抽出されたサーバ識別子に基づいて、リクエストに対応するサービスを提供するサーバを特定する。したがって、複数のプロトコルによるリクエストから、該リクエストに対応するサービスを提供するサーバを容易に特定することができるという利点が得られる。

また、本発明によれば、複数のサーバによって提供される全てのサービスにアクセス可能なように、複数のサーバによって提供されるサービスデータを一元的に管理する。したがって、サービスデータの管理位置を意識せずに振り分けることができるという利点が得られる。

また、本発明によれば、リクエストに含まれるセッション識別子と複数のサーバのサーバ識別子とを対応付けて記憶しておき、複数のプロトコルによるリクエストに含まれるセッション識別子に対応するサーバ識別子を取得し、取得されたサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定する。したがって、セッション識別子を新たに生成することなく、複数のプロトコルによるリクエストから、該リクエストに対応するサービスを提供するサーバを容易に特定することができるという利点が得られる。

また、この発明によれば、複数のプロトコルによるリクエストが複数のサーバのいずれかに対するリクエストであるか否かを判別し、リクエストが複数のサーバのいずれかに対するリクエストでないと判別された場合、リクエストに含まれるセッション識別子と、リクエスト送信元のサーバ識別子とを対応付けて記憶する。したがって、リクエストに含まれるセッション識別子と複数のサーバのサーバ識別子との対応付けを容易に更新することができ、リクエストに対応するサービスを提供するサーバを常に最新の情報で容易に特定することができるという利点が得られる。

以下、本発明の一実施形態による負荷分散方式を、図面を参照して説明する。

Ａ．第１実施形態
図１は、本発明の第１実施形態による負荷分散方式を適用した、ＨＴＴＰプロトコルとＳＩＰプロトコルとによるサービスが連携するサービス連携サーバの構成を示すブロック図である。図１において、ウェブ−テレコム連携サーバ１０は、ＨＴＴＰ及びＳＩＰの信号を処理するサーバであり、複数のサーバ２０−１〜２０−４、ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０を備えている。

サーバ２０−１〜２０−４は、各々、リクエストに応じたサービスを提供する。ウェブ系プロトコルロードバランサ３０は、ＨＴＴＰを用いるインターネット４５に接続され、テレコム系プロトコルロードバランサ４０は、ＳＩＰを用いるテレコムネットワーク４６に接続されている。ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０は、各々、上記クライアント５０から発信されたＨＴＴＰ、ＳＩＰ双方のリクエストを、サービスデータが存在するサーバ２０−１〜２０−４のいずれかに振り分ける。

クライアント５０は、ＨＴＴＰ、ＳＩＰによる双方のリクエストを、それぞれ、インターネット４５、テレコムネットワーク４６を介して、ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０に発信する。

次に、図２は、上記サーバ２０−１〜２０−４と、ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０との機能構成を示すブロック図である。図２において、サーバ２０−１〜２０−４は、各々、サービスデータ管理部６０及びセッション管理部７０を備えている。サービスデータ管理部６０は、サーバにおけるサービス起動時にサービスデータを生成する。セッション管理部７０は、サービスを起動したリクエストや、起動されたサービスが生成したセッションに対して、セッション識別子を発行する。以降のリクエストにおいては、上記セッション識別子を指定してサービスデータへのアクセスが行われる。

上記構成において、ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０は、セッション識別子が指定されているリクエストについては、そのセッションと関連したサービスデータが存在するサービスデータ管理部６０を備えるサーバ２０−ｉ（ｉ＝１，２，３，４）に対してリクエスト信号を振り分ける必要がある。

そこで、本第１実施形態では、セッション管理部７０は、セッション識別子を発行する際に、該セッション識別子と、そのセッションが生成されたサーバ２０−ｉ（ｉ＝１，２，３，４）のＩＰアドレスとから、新たなセッション識別子を生成するようになっている。なお、新たなセッション識別子の生成方法としては、セッション識別子にＩＰアドレスを連結して新たなセッション識別子としてもよいし、セッション識別子とＩＰアドレスとから、ハッシュ演算などにより、新たにセッション識別子を生成してもよい。ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０での振り分け時には、セッション識別子に埋め込まれたＩＰアドレスを抽出し、該ＩＰアドレスに対応するサーバ２０−ｉに対して信号送信を行うようにすればよい。

次に、図３は、本第１実施形態による負荷分散方式を適用したウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０の動作を説明するためのフローチャートである。ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０において、振り分け判定部８０は、信号を受信したときに、信号にセッション識別子が含まれているか判別し（ステップＳ１０）、信号にセッション識別子が含まれている場合には、サーバ２０−１〜２０−４に対する信号であるか否かを判別する（ステップＳ１１）。そして、サーバ２０−１〜２０−４に対する信号である場合には、セッション識別子からＩＰアドレスを抽出し（ステップＳ１２）、そのＩＰアドレスに対して信号送信を行う。

例えば、あるサービスにおいて、ＳＩＰによってクライアント間に新規のセッションを生成する場合、図４に示すように、ＳＩＰのセッション識別子として用いられるＣａｌｌ−ＩＤにサーバ２０−ｉ（ｉ＝１，２，３，４）のＩＰアドレス等のサーバ識別子を連結し、その値を新たなＣａｌｌ−ＩＤとして用いる。そして、テレコム系プロトコルロードバランサ４０にてＳＩＰ信号を振り分ける際に、指定されているＣａｌｌ−ＩＤから連結されたＩＰアドレスを取り出すことにより、振り分け先のサーバ２０−ｉを判定する。

また、ＨＴＴＰの場合にも、ＨＴＴＰのセッション識別子にサーバ２０−ｉ（ｉ＝１，２，３，４）のＩＰアドレス等のサーバ識別子を連結して、新たなセッション識別子とすることで、ＨＴＴＰ信号を振り分ける際に、振り分け先のサーバ２０−ｉを判定することが可能となる。

Ｂ．第２実施形態
次に、本発明の第２実施形態について説明する。本第２実施形態では、サービスデータ管理部６０に対して、全てのサーバ２０−１〜２０−４からサービスデータへのアクセスを可能としている。

図５は、本第２実施形態によるサーバ２０−１〜２０−４の構成を示すブロック図である。図５において、全てのサーバ２０−１〜２０−４は、全てのサービスデータにアクセス可能なように、サービスデータを一元的に管理するサービスデータ一元管理部６１を備えている。なお、各サーバ２０−１〜２０−４にサービスデータ一元管理部６１を備える以外に、全てのサーバ２０−１〜２０−４から参照可能な共通のデータベースを別途設けるようにしてもよい。

各サーバ２０−１〜２０−４に振り分けられたリクエストがサービスデータにアクセスする際には、サービスデータ管理部６０にアクセスすることにより、処理を実施する。この場合、図２に示す振り分け先判定部８０は、特に、セッション識別子を意識した振り分けなどを行う必要はなく、ラウンドロビン方式、重み付けラウンドロビン方式等の周知の振り分け方式を用いることが可能である。

これにより、ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０においてサービスデータの管理位置を意識せずに振り分けることが可能となる。

Ｃ．第３実施形態
次に、本発明の第３実施形態について説明する。本第３実施形態では、サービスデータ管理部６０や、セッション管理部７０において、特別な処理を行うことなく、リクエスト信号の振り分けを行うようになっている。

図６は、本第３実施形態による負荷分散方式を適用したウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０の構成を示すブロック図である。図６において、ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０は、振り分け先管理テーブル８１を備えている。該振り分け先管理テーブル８１は、図７に示すように、セッション識別子Ｓ−ＩＤ１、Ｓ−ＩＤ２、Ｓ−ＩＤ３、…と、該セッション識別子に対応するサービスデータを提供するサーバ２０−１〜２０−４のＩＰアドレスＩＰ１、ＩＰ２、ＩＰ３、…とを対応付けて記憶している。

振り分け先判定部８０は、リクエスト信号を受信したときに、信号内にセッション識別子が存在した場合、それがサーバ２０−ｉ（ｉ＝１，２，３，４）に対する信号である場合には、振り分け先管理テーブル８１からセッション識別子に対応した振り分け先サーバのＩＰアドレスを取得し、該ＩＰアドレスのサーバ２０−ｉに対して信号を送信する。また、振り分け先判定部８０は、サーバ２０−１〜２０−４に対する信号でない場合、つまり、クライアント５０に対する信号である場合には、振り分け先管理テーブル８１にセッション識別子と信号送信元（サーバ２０−ｉ）のＩＰアドレスとを登録して送信先アドレスに信号を送信する。

次に、図８は、本第３実施形態の動作を説明するためのフローチャートである。ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０において、振り分け判定部８０は、信号を受信したときに、信号にセッション識別子が含まれているか判別し（ステップＳ２０）、信号にセッション識別子が含まれている場合には、サーバ２０−１〜２０−４に対する信号であるか否かを判別する（ステップＳ２１）。そして、サーバ２０−１〜２０−４に対する信号である場合には、振り分け先管理テーブル８１からセッション識別子に対応した振り分け先サーバのＩＰアドレスを取得し（ステップＳ２２）、該ＩＰアドレスに対して信号を送信する。

一方、サーバ２０−１〜２０−４に対する信号でない場合には、振り分け先管理テーブル８１にセッション識別子と信号送信元（サーバ２０−ｉ）のＩＰアドレスとを登録し（ステップＳ２３）、送信先アドレスに信号を送信する。

ここで、図９は、本第３実施形態の一動作例を説明するためのシーケンス図である。図９に示すシーケンスは、ＨＴＴＰよりＳＩＰによるセッションを制御された場合の動作例であり、クライアントＡは、ＨＴＴＰを用い、クライアントＢ、Ｃは、ＳＩＰを用いて通信を行う。ＨＴＴＰサーバ２０−Ａは、図１に示すサーバ２０−ｉ（ｉ＝１〜４）のいずれかに相当し、ＨＴＴＰを用いたサービスを提供する。また、ＳＩＰサーバ２０−Ｂは、図１に示すサーバ２０−ｉ（ｉ＝１〜４）のいずれかに相当し、ＳＩＰを用いたサービスを提供する。

まず、ＨＴＴＰのクライアントＡからＨＴＴＰサーバ２０−Ａに対して発呼要求（リクエスト）があると（ＳＳ１）、ＨＴＴＰサーバ２０−Ａは、ＨＴＴＰリクエストデータで指定されたＳＩＰのクライアントＢ、Ｃ間にセッション確立をするように、ＳＩＰサーバ２０−Ｂに対して、セッション開始要求を行う（ＳＳ２）。

次に、ＳＩＰサーバ２０−Ｂは、ＨＴＴＰサーバ２０−Ａに対して、ＳＩＰセッション識別子を通知する（ＳＳ３）。ＳＩＰサーバ２０−Ｂからの応答を受けたＨＴＴＰサーバ２０−Ａは、ＨＴＴＰセッション識別子を新たに発行し、ＨＴＴＰセッション識別子とＳＩＰセッション識別子との対応をＨＴＴＰセッションデータとして保存した後、ＨＴＴＰクライアントＡに対してＨＴＴＰセッション識別子を、ＨＴＴＰセッションの識別子として指定してセッション確立応答を送信する（ＳＳ４）。

このとき、セッション確立応答は、サーバに対するものではないので、上述したように、ウェブ系プロトコルロードバランサ３０では、振り分け先管理テーブル８１にＨＴＴＰセッション識別子と信号送信元（ＨＴＴＰサーバ２０−Ａ）のＩＰアドレスとを登録し（ＳＳ５）、ＨＴＴＰのクライアントＡに送信する（ＳＳ６）。

また、リクエストを受けたＳＩＰサーバ２０−Ｂは、新たにＳＩＰセッション識別子（Ｃａｌｌ−ＩＤ）を発行し、まず、当該ＳＩＰセッション識別子を指定してセッション開始をクライアントＢに通知する（ＳＳ７）。このとき、セッション開始通知は、サーバに対するものではないので、上述したように、テレコム系プロトコルロードバランサ４０では、振り分け先管理テーブル８１にＳＩＰセッション識別子と信号送信元（ＳＩＰサーバ２０−Ｂ）のＩＰアドレスとを登録し（ＳＳ８）、ＳＩＰのクライアントＢに送信する（ＳＳ９）。クライアントＢは、上記ＳＩＰセッション識別子を指定してセッション開始応答を返す（ＳＳ１０）。

テレコム系プロトコルロードバランサ４０では、クライアントＢからのセッション開始応答を受信すると、サーバに対する信号であるので、振り分け先管理テーブル８１からＳＩＰセッション識別子に対応した振り分け先サーバのＩＰアドレス、この場合、ＳＩＰサーバ２０−ＢのＩＰアドレスを取得し（ＳＳ１１）、該ＩＰアドレスに対してセッション開始応答を送信する（ＳＳ１２）。

同様に、ＳＩＰサーバ２０−Ｂは、新たに生成したＳＩＰセッション識別子を指定してセッション開始をクライアントＣに通知する（ＳＳ１３）。このとき、セッション開始通知は、サーバに対するものではないので、上述したように、テレコム系プロトコルロードバランサ４０では、振り分け先管理テーブル８１にＳＩＰセッション識別子と信号送信元（ＳＩＰサーバ２０−Ｂ）のＩＰアドレスとを登録し（ＳＳ１４）、ＳＩＰのクライアントＣに送信する（ＳＳ１５）。クライアントＣは、上記ＳＩＰセッション識別子を指定してセッション開始応答を返す（ＳＳ１６）。

テレコム系プロトコルロードバランサ４０では、クライアントＣからのセッション開始応答を受信すると、サーバに対する信号であるので、振り分け先管理テーブル８１からＳＩＰセッション識別子に対応した振り分け先サーバのＩＰアドレス、この場合、ＳＩＰサーバ２０−ＢのＩＰアドレスを取得し（ＳＳ１７）、該ＩＰアドレスに対してセッション開始応答を送信する（ＳＳ１８）。

なお、ＨＴＴＰサーバ２０−ＡにてＳＩＰセッションが確立されたか否かを確認するためには、ＳＩＰセッション識別子を指定してＳＩＰセッション状態の問い合わせを行うリクエストをＨＴＴＰサーバ２０−Ａに送信すると、ＳＩＰサーバ２０−Ｂに対して状態を問い合わせ、ＳＩＰのクライアントＣが応答する前であれば「接続待ち」、ＳＩＰのクライアントＣが応答した後であれば「接続中」の状態を表す値が返ってくる。ＨＴＴＰのクライアントＡは、上記値を確認して接続されたか否かを判断するようになっている。

セッション確立後、ＨＴＴＰのクライアントＡから、ＳＩＰセッションの終了や、ＳＩＰセッション状態情報の参照を行う場合、当該ＨＴＴＰセッション識別子を指定して、ＨＴＴＰサーバ２０−Ａに対してリクエストを送信する。例えば、ＳＩＰセッションの終了時では、ＨＴＴＰセッション識別子を指定して、ＨＴＴＰサーバ２０−Ａに対して終了要求を送信する（ＳＳ１９）。

ウェブ系プロトコルロードバランサ３０では、クライアントＡからの終了要求を受信すると、サーバに対する信号であるので、振り分け先管理テーブル８１からＨＴＴＰセッション識別子に対応した振り分け先サーバのＩＰアドレス、この場合、ＨＴＴＰサーバ２０−ＡのＩＰアドレスを取得し（ＳＳ２０）、該ＩＰアドレスに対して終了要求を送信する（ＳＳ２１）。ＨＴＴＰサーバ２０−Ａは、セッションデータからＳＩＰセッション識別子を取り出し、ＳＩＰサーバ２０−Ｂに対してセッション終了要求を行う（ＳＳ２２）。

ＳＩＰサーバ２０−Ｂは、上記ＳＩＰセッション識別子を指定して、クライアントＢに対してセッション終了通知を送信する（ＳＳ２３）。このとき、セッション終了通知は、サーバに対するものではないので、上述したように、ウェブ系プロトコルロードバランサ３０では、振り分け先管理テーブル８１にＳＩＰセッション識別子と信号送信元（ＳＩＰサーバ２０−Ｂ）のＩＰアドレスとを登録し（ＳＳ２４）、ＳＩＰのクライアントＢに送信する（ＳＳ２５）。クライアントＢからは、上記ＳＩＰセッション識別子を指定してセッション終了応答を返す（ＳＳ２６）。

テレコム系プロトコルロードバランサ４０では、クライアントＢからのセッション終了応答を受信すると、サーバに対する信号であるので、振り分け先管理テーブル８１からＳＩＰセッション識別子に対応した振り分け先サーバのＩＰアドレス、この場合、ＳＩＰサーバ２０−ＢのＩＰアドレスを取得し（ＳＳ２７）、該ＩＰアドレスに対してセッション終了応答を送信する（ＳＳ２８）。

同様に、ＳＩＰサーバ２０−Ｂは、クライアントＣにＳＩＰセッション識別子として指定したセッション終了通知を送信する（ＳＳ２９）。このとき、セッション終了通知は、サーバに対するものではないので、上述したように、テレコム系プロトコルロードバランサ４０では、振り分け先管理テーブル８１にＳＩＰセッション識別子と信号送信元（ＳＩＰサーバ２０−Ｂ）のＩＰアドレスとを登録し（ＳＳ３０）、ＳＩＰのクライアントＣに送信する（ＳＳ３１）。クライアントＣからは、上記ＳＩＰセッション識別子を指定してセッション終了応答を返す（ＳＳ３２）。

テレコム系プロトコルロードバランサ４０では、クライアントＣからのセッション終了応答を受信すると、サーバに対する信号であるので、振り分け先管理テーブル８１からＳＩＰセッション識別子に対応した振り分け先サーバのＩＰアドレス、この場合、ＳＩＰサーバ２０−ＢのＩＰアドレスを取得し（ＳＳ３３）、該ＩＰアドレスに対してセッション終了応答を送信する（ＳＳ３４）。ＳＩＰサーバ２０−Ｂは、上記セッション終了応答をＨＴＴＰサーバ２０−Ａに送信し（ＳＳ３５）、ＨＴＴＰサーバ２０−Ａは、ＨＴＴＰのクライアントＡに上記セッション終了応答を送信する（ＳＳ３６）。

なお、第１実施形態の構成にて、図８に示すシーケンスの動作を実現するためには、ＨＴＴＰサーバ２０−Ａ、ＳＩＰサーバ２０−Ｂにて、セッション識別子を発行する際に、ＩＰアドレス等のサーバ識別子を含めたものを発行するよう構成することになる。また、第２実施形態の構成では、ＨＴＴＰサーバ２０−ＡとＳＩＰサーバ２０−Ｂにおいて、上述したサービスデータ一元管理部６１を備えるよう構成することになる。

上述した第１ないし第３実施形態によれば、サービス連携サーバにおいて、高いスケーラビリティを実現することが可能となり、急激な需要増に柔軟に対応できるシステムを構築することが可能となる。

本発明の第１実施形態による負荷分散方式を適用した、ＨＴＴＰプロトコルとＳＩＰプロトコルとによるサービスが連携するサービス連携サーバの構成を示すブロック図である。 サーバ２０−１〜２０−４と、ウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０との機能構成を示すブロック図である。 本第１実施形態の動作を説明するためのフローチャートである。 セッション識別子へのＩＰアドレスの埋め込み例を示す概念図である。 本第２実施形態によるサーバ２０−１〜２０−４の構成を示すブロック図である。 本第３実施形態による負荷分散方式を適用したウェブ系プロトコルロードバランサ３０、テレコム系プロトコルロードバランサ４０の構成を示すブロック図である。 本第３実施形態による振り分け先管理テーブル８１のデータ構成を示す概念図である。 本第３実施形態の動作を説明するためのフローチャートである。 本第３実施形態の動作例を説明するためのシーケンス図である。

符号の説明

１０ ウェブ−テレコムサービス連携サーバ
２０−１〜２０−４ サーバ
３０ ウェブ系プロトコルロードバランサ
４０ テレコム系プロトコルロードバランサ
４５ インターネット
４６ テレコムネットワーク
５０ クライアント
６０ サービスデータ管理部
６１ サービスデータ一元管理部（サービスデータ管理手段）
７０ セッション管理部（セッション識別子生成手段）
８０ 振り分け先判定部（抽出手段、サーバ特定手段、判別手段、登録手段）
８１ 振り分け先管理テーブル（振り分け先管理記憶手段）
Ａ ＨＴＴＰのクライアント
Ｂ、Ｃ ＳＩＰのクライアント
２０−Ａ ＨＴＴＰサーバ
２０−Ｂ ＳＩＰサーバ

Claims (7)

1. 複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分けるサービス連携サーバであって、
   前記複数のプロトコルによるリクエストの初回発生時に、該リクエストのセッション識別子と、該リクエストに対応するサービスを提供するサーバのサーバ識別子とから、新たなセッション識別子を生成するセッション識別子生成手段と、
   前記リクエストの初回発生時以降に発生した前記複数のプロトコルによるリクエストが前記複数のサーバのいずれかに対するリクエストであるか否かを判別する判別手段と、
   前記判別手段により、前記リクエストが前記複数のサーバのいずれかに対するリクエストであると判別された場合、前記複数のプロトコルによるリクエストに含まれるセッション識別子からサーバ識別子を抽出する抽出手段と、
   前記抽出手段によって抽出されたサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定するサーバ特定手段と
   を具備することを特徴とするサービス連携サーバ。
2. 複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分けるサービス連携サーバであって、
   前記複数のサーバによって提供される全てのサービスにアクセス可能なように、前記複数のサーバによって提供されるサービスデータを一元的に管理するサービスデータ管理手段を具備することを特徴とするサービス連携サーバ。
3. 複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分けるサービス連携サーバであって、
   前記リクエストに含まれるセッション識別子と前記複数のサーバのサーバ識別子とを対応付けて記憶する振り分け先管理記憶手段と、
   前記複数のプロトコルによるリクエストに含まれるセッション識別子に基づいて、前記振り分け先管理記憶手段から対応するサーバ識別子を取得するサーバ識別子取得手段と、
   前記サーバ識別子取得手段によって取得されたサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定するサーバ特定手段と
   を具備することを特徴とするサービス連携サーバ。
4. 前記複数のプロトコルによるリクエストが前記複数のサーバのいずれかに対するリクエストであるか否かを判別する判別手段と、
   前記判別手段により、前記リクエストが前記複数のサーバのいずれかに対するリクエストでないと判別された場合、前記リクエストに含まれるセッション識別子と、リクエスト送信元のサーバ識別子とを対応付けて前記振り分け先管理記憶手段に登録する登録手段と
   を具備することを特徴とする請求項３記載のサービス連携サーバ。
5. 複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分ける負荷分散方法であって、
   前記複数のプロトコルによるリクエストの初回発生時に、該リクエストのセッション識別子と、該リクエストに対応するサービスを提供するサーバのサーバ識別子とから、新たなセッション識別子を生成し、
   前記リクエストの初回発生時以降に発生した前記複数のプロトコルによるリクエストが前記複数のサーバのいずれかに対するリクエストであるか否かを判別し、
   前記複数のサーバのいずれかに対するリクエストであると判別された場合、前記複数のプロトコルによるリクエストに含まれるセッション識別子からサーバ識別子を抽出し、抽出したサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定することを特徴とする負荷分散方法。
6. 複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分ける負荷分散方法であって、
   前記複数のサーバによって提供される全てのサービスにアクセス可能なように、前記複数のサーバによって提供されるサービスデータを一元的に管理することを特徴とする負荷分散方法。
7. 複数のサーバによって提供されるサービスに対する、複数のプロトコルによるリクエストを振り分ける負荷分散方法であって、
   前記リクエストに含まれるセッション識別子と前記複数のサーバのサーバ識別子とを対応付けて記憶しておき、前記複数のプロトコルによるリクエストに含まれるセッション識別子に対応するサーバ識別子を取得し、取得したサーバ識別子に基づいて、前記リクエストに対応するサービスを提供するサーバを特定することを特徴とする負荷分散方法。
   
   

Images