(57)【要約】【課題】クラスタを構成する処理サーバの故障時や、処理サーバの増減設時にも、通信サービス処理性能を低下させない通信制御システムを提供する。【解決手段】ユーザ端末２からの通信サービス要求を処理サーバ（アプリケーションサーバ２０）が処理するために必要なセッション情報を、データ管理サーバ３０にて一括して保持する。ロードバランサ１０は、個々の通信サービス要求に含まれるセッション識別情報を用いて、同一セッションについての新規及び継続の通信サービス要求を同じ処理サーバに振り分ける。処理サーバの故障や減設などの場合には、ロードバランサ１０が、稼働中の他の処理サーバに以降の継続の通信サービス要求を振り分け直す。セッションの途中から継続の通信サービス要求を振り分けられた処理サーバは、データ管理サーバ３０から必要なセッション情報を取得して、当該セッションの通信サービスを継続する。【選択図】図１
2014220675.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末から所定の手順で送信される通信サービス要求信号に基づいて前記ユーザ端末に所定の通信サービスを提供する複数の処理サーバと、前記ユーザ端末から送信される前記通信サービス要求信号を前記複数の処理サーバに振り分ける信号振分け装置と、前記通信サービスの提供に必要な情報を記憶し管理するデータ管理サーバと、を備える通信制御システムであって、
前記信号振分け装置は、前記ユーザ端末から新規の通信サービス要求信号を受信した場合には、所定の振分けアルゴリズムによって当該新規の通信サービス要求信号の振分け先とする処理サーバを決定するとともに、当該新規の通信サービス要求信号のなかに含まれるセッション識別情報と前記決定した振分け先の処理サーバとを対応付ける振分け履歴情報を自身の記憶部に記憶し、以降前記ユーザ端末から受信する前記通信サービス要求信号が、当該通信サービス要求信号のなかに前記振分け履歴情報として記憶したものと同一のセッション識別情報が含まれる継続の通信サービス要求信号である場合には、当該セッション識別情報に対応付けられた前記振分け先の処理サーバに、当該継続の通信サービス要求信号を振り分けるサービス要求振分け部を備え、
前記複数の処理サーバのそれぞれは、
自身に振り分けられた通信サービス要求信号が新規の通信サービス要求信号である場合には、当該新規の通信サービス要求信号に含まれるセッション識別情報に対応するセッション情報を生成して自身の記憶部に記憶したセッション情報を用いる一方で、自身に振り分けられた通信サービス要求信号が前記継続の通信サービス要求信号である場合には、当該継続の通信サービス要求信号に含まれるセッション識別情報に対応する自身の記憶部に記憶されたセッション情報を用いて、所定の処理を実行することで前記通信サービスを提供するセッション制御処理部と、
前記所定の処理が実行されて、前記通信サービスが所定の安定状態に遷移する毎に、当該遷移後の安定状態を表す情報を含む前記自身の記憶部に記憶したセッション情報を前記データ管理サーバに送信するセッション情報登録部と、
自身に振り分けられた通信サービス要求信号が新規の通信サービス要求信号ではなく、かつ、当該通信サービス要求信号に含まれるセッション識別情報に対応するセッション情報が前記自身の記憶部に記憶されていない場合には、当該セッション情報を前記データ管理サーバから取得して前記自身の記憶部に記憶するセッション情報取得部とを備え、
前記データ管理サーバは、前記複数の処理サーバから送信される前記セッション情報を自身の記憶部に記憶し、前記処理サーバからの要求に応じて前記セッション情報を要求元の当該処理サーバに返送するセッション情報管理部を備える
ことを特徴とする通信制御システム。
【請求項２】
請求項１に記載の通信制御システムにおいて、
前記信号振分け装置は、
前記複数の処理サーバの稼働状態を保持するサーバ状態管理テーブルを自身の記憶部に備え、
前記サービス要求振分け部は、前記振分け先の処理サーバへの前記通信サービス要求信号の送信に失敗した場合には、稼働状態が稼働中である他の処理サーバのいずれかに当該通信サービス要求信号を振り分ける
ことを特徴とする通信制御システム。
【請求項３】
請求項２に記載の通信制御システムにおいて、
前記サービス要求振分け部は、前記サーバ状態管理テーブルに保持されている前記振分け先の処理サーバの稼働状態が稼働中でない場合、または、前記振分け先の処理サーバの情報が前記サーバ状態管理テーブルから削除された場合には、稼働状態が稼働中である他の処理サーバのいずれかに、当該振分け先の処理サーバへの前記通信サービス要求信号を振り分ける
ことを特徴とする通信制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数台の処理サーバによるクラスタ構成にてＩＰ（Internet Protocol）電話等の通信サービスを提供する通信制御システムに関する。特に、処理サーバに障害が発生したり、需要に応じて処理サーバを増減設したりする場合においても、提供している通信サービスを中断することなく継続するための技術に関する。
【背景技術】
【０００２】
複数台の処理サーバによるクラスタ構成の通信制御システムでは、通信サービスを提供している処理サーバに障害が発生した場合にもサービスを継続できるようにするために、通信サービスの継続に必要なセッション情報を、他の処理サーバにも複製して記憶させている（例えば、特許文献１参照）。
【０００３】
個々の通信サービスは、ロードバランサ（信号振分け装置）によって振り分けられた特定の処理サーバで処理され、各処理サーバは通信サービスが所定の安定状態に遷移する毎に、その時点のセッション情報を他の処理サーバに複製して記憶させる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１２−２４８０９１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
前記従来の通信制御システムでは、通信サービスを提供している稼働中の処理サーバに障害が発生した場合や、稼働中の処理サーバを減設する場合には、ロードバランサが改めて当該処理サーバが提供していた通信サービスのセッション情報の複製を保持している他の処理サーバに、当該通信サービスを振り分け直す。このとき、セッション情報の複製を保持している特定のサーバに負荷が集中しないようにするために、その時点で提供されている全ての通信サービスのセッション情報を再配置したのち、新たな振分けによって通信サービスを継続するようにしていた。そのため、セッション情報の再配置が完了するまでの間に、一時的な通信サービス処理性能の低下が発生する場合があった。
【０００６】
また、通信サービスの需要の変化に応じてクラスタを構成する処理サーバの増設を行う場合、増設した処理サーバの処理能力を直ちに活かすように負荷を再配分するためには、同様にセッション情報の再配置を行う必要があった。したがって、この場合にも、セッション情報の再配置が完了するまでの間に、一時的な通信サービス処理性能の低下が発生することがあった。
【０００７】
本発明は、前記の課題を解決するためになされたものであり、クラスタを構成する処理サーバに障害が発生した場合や、処理サーバの増減設を行う場合にも、通信サービス処理性能の低下を発生させない通信制御システムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
前記の課題を解決するために、本発明は、ユーザ端末から所定の手順で送信される通信サービス要求信号に基づいて前記ユーザ端末に所定の通信サービスを提供する複数の処理サーバと、前記ユーザ端末から送信される前記通信サービス要求信号を前記複数の処理サーバに振り分ける信号振分け装置と、前記通信サービスの提供に必要な情報を記憶し管理するデータ管理サーバと、を備える通信制御システムであって、前記信号振分け装置は、前記ユーザ端末から新規の通信サービス要求信号を受信した場合には、所定の振分けアルゴリズムによって当該新規の通信サービス要求信号の振分け先とする処理サーバを決定するとともに、当該新規の通信サービス要求信号のなかに含まれるセッション識別情報と前記決定した振分け先の処理サーバとを対応付ける振分け履歴情報を自身の記憶部に記憶し、以降前記ユーザ端末から受信する前記通信サービス要求信号が、当該通信サービス要求信号のなかに前記振分け履歴情報として記憶したものと同一のセッション識別情報が含まれる継続の通信サービス要求信号である場合には、当該セッション識別情報に対応付けられた前記振分け先の処理サーバに、当該継続の通信サービス要求信号を振り分けるサービス要求振分け部を備え、前記複数の処理サーバのそれぞれは、自身に振り分けられた通信サービス要求信号が新規の通信サービス要求信号である場合には、当該新規の通信サービス要求信号に含まれるセッション識別情報に対応するセッション情報を生成して自身の記憶部に記憶したセッション情報を用いる一方で、自身に振り分けられた通信サービス要求信号が前記継続の通信サービス要求信号である場合には、当該継続の通信サービス要求信号に含まれるセッション識別情報に対応する自身の記憶部に記憶されたセッション情報を用いて、所定の処理を実行することで前記通信サービスを提供するセッション制御処理部と、前記所定の処理が実行されて、前記通信サービスが所定の安定状態に遷移する毎に、当該遷移後の安定状態を表す情報を含む前記自身の記憶部に記憶したセッション情報を前記データ管理サーバに送信するセッション情報登録部と、自身に振り分けられた通信サービス要求信号が新規の通信サービス要求信号ではなく、かつ、当該通信サービス要求信号に含まれるセッション識別情報に対応するセッション情報が前記自身の記憶部に記憶されていない場合には、当該セッション情報を前記データ管理サーバから取得して前記自身の記憶部に記憶するセッション情報取得部とを備え、前記データ管理サーバは、前記複数の処理サーバから送信される前記セッション情報を自身の記憶部に記憶し、前記処理サーバからの要求に応じて前記セッション情報を要求元の当該処理サーバに返送するセッション情報管理部を備えるものとした。
【０００９】
こうすることにより、クラスタを構成する処理サーバに障害が発生した場合や、処理サーバの増減設を行う場合にも、セッション情報を再配置する必要がなくなるので、通信サービス処理性能の低下を発生させない通信制御システムを提供することができる。
【００１０】
また、本発明は、前記の通信制御システムにおいて、前記信号振分け装置は、前記複数の処理サーバの稼働状態を保持するサーバ状態管理テーブルを自身の記憶部に備え、前記サービス要求振分け部は、前記振分け先の処理サーバへの前記通信サービス要求信号の送信に失敗した場合には、稼働状態が稼働中である他の処理サーバのいずれかに当該通信サービス要求信号を振り分けるものとした。
【００１１】
こうすることにより、稼働中の処理サーバに障害が発生した場合には、稼働中の他の処理サーバに、障害が発生した処理サーバが提供していた通信サービスを引き継がせることができる。
【００１２】
また、本発明は、前記の通信制御システムにおいて、前記サービス要求振分け部は、前記サーバ状態管理テーブルに保持されている前記振分け先の処理サーバの稼働状態が稼働中でない場合、または、前記振分け先の処理サーバの情報が前記サーバ状態管理テーブルから削除された場合には、稼働状態が稼働中である他の処理サーバのいずれかに当該振分け先の処理サーバへの前記通信サービス要求信号を振り分けるものとした。
【００１３】
こうすることにより、稼働中であった処理サーバがシステムから切り離されたり、稼働を停止したりした場合は、稼働中の他の処理サーバに、当該処理サーバが提供していた通信サービスを引き継がせることができる。
【発明の効果】
【００１４】
本発明によれば、クラスタを構成するサーバに障害が発生した場合や、サーバの増減設を行う場合にも、通信サービス処理性能の低下を発生させない通信制御システムを提供することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明に係る通信制御システムの構成例を示す図である。
【図２】ロードバランサ（信号振分け装置）の構成例を示す機能ブロック図である。
【図３】アプリケーションサーバの構成例を示す機能ブロック図である。
【図４】データ管理サーバの構成例を示す機能ブロック図である。
【図５】サーバ状態管理テーブルの構成及びデータ例を示す図である。
【図６】振分け管理テーブル（振分け履歴）の構成及びデータ例を示す図である。
【図７】セッション情報管理テーブル（セッション情報）の構成及びデータ例を示す図である。
【図８】ＳＩＰを用いたＩＰ電話サービスの安定状態についての説明図である。
【図９】ロードバランサ（信号振分け装置）が実行する振分け処理の例を示すフローチャートである。
【図１０】アプリケーションサーバが実行する通信サービス要求処理の例を示すフローチャートである。
【図１１】ＳＩＰを用いてＩＰ電話サービスを提供する場合の信号及び処理の流れの例を示すシーケンス図である。
【図１２】従来の通信制御システムの構成例を示す図である。
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態（以下、「実施形態」という。）を、適宜図面を参照して詳細に説明する。本実施形態では、ＳＩＰ（Session Initiation Protocol）を用いてＩＰ電話サービスを提供する通信制御システムが、呼制御処理を司る複数の処理サーバ（以下、「アプリケーションサーバ」ともいう。）からなるクラスタ構成をなす例について説明する。なお、本発明は、ＩＰ電話サービスに限らず、ユーザ端末との間にセッションを設定して提供される任意の通信サービスに適用可能であり、使用するプロトコルはＳＩＰに限られるものではない。
【００１７】
＜従来の通信制御システム＞
まず、比較例として従来の通信制御システムの構成例及び動作概要を、図１２を参照して説明する。図１２は、従来の通信制御システムの構成例を示す図である。
【００１８】
図１２に示すように、ネットワーク３に接続される複数のユーザ端末２に対してＩＰ電話サービスなどの通信サービスを提供する従来の通信制御システム１Ａは、ロードバランサ１０Ａと、クラスタを構成する複数のアプリケーションサーバ２０Ａ−１，２０Ａ−２，２０Ａ−３，・・・と、データ管理サーバ３０Ａとを備えて構成されている。
【００１９】
ロードバランサ１０Ａは、各ユーザ端末２から所定の手順で送信される通信サービス要求信号（以下、「要求信号」と略記する場合がある。）を、所定の振分けアルゴリズムによっていずれか１台のアプリケーションサーバに振り分け、振分け先のアプリケーションサーバから送信される応答信号を、要求元のユーザ端末２に中継して返送する。
【００２０】
振分けアルゴリズムとしては、ラウンドロビン方式、サーバ負荷判定付きラウンドロビン方式（サーバ負荷が一定値以上のサーバはスキップし次のサーバを割り当てる）、ハッシュ方式、サーバ負荷判定付きハッシュ方式（サーバ負荷が一定値以上のサーバはスキップし次のサーバを割り当てる）等が適用可能である。
【００２１】
ロードバランサ１０Ａによってユーザ端末２からの通信サービス要求信号を振り分けられたアプリケーションサーバ２０Ａは、所定の手順によってユーザ端末２との間にセッションを設定するとともに、通信サービスの提供に必要となる所定のセッション情報を生成して所定の処理を実行することで、当該ユーザ端末２に対して各種の通信サービスを提供する。
【００２２】
また、当該アプリケーションサーバ２０Ａは、提供している通信サービス（例えば、ＩＰ電話サービス）が所定の安定状態（例えば、「呼出し中」、「通話中」など）に遷移する毎に、遷移後の安定状態を表す情報を含んだセッション情報を他のアプリケーションサーバ２０Ａに複製し、バックアップとして保持させておく。図１２の例では、破線の矢印と矩形とで示すように、アプリケーションサーバ２０Ａ−１のセッション情報ｓ１はアプリケーションサーバ２０Ａ−２に複製され、アプリケーションサーバ２０Ａ−２のセッション情報ｓ２はアプリケーションサーバ２０Ａ−３に複製されるなどのように、複製元と複製先との組が所定のルールによって予め定められている。
【００２３】
ここで、稼働中の１台のアプリケーションサーバ２０Ａ（例えば、アプリケーションサーバ２０Ａ−１）に障害が発生し、当該サーバは、自身が分担して提供している通信サービスをもはや継続できなくなったものと仮定する。このとき、ロードバランサ１０Ａは、当該アプリケーションサーバ２０Ａ−１の故障を検知すると、当該アプリケーションサーバ２０Ａ−１に振り分けていた通信サービス要求信号を、当該通信サービスのセッション情報ｓ１の複製を保持しているアプリケーションサーバ２０Ａ−２に振り分ける。それによって、振分け先のアプリケーションサーバ２０Ａ−２は、自身が保持しているバックアップのセッション情報ｓ１を現用のセッション情報ｓ１に昇格させ、当該セッションの通信サービスを継続する。また、新たなバックアップ先となるアプリケーションサーバ２０Ａ−３に当該セッション情報ｓ１を複製して保持させる。
【００２４】
なお、単に故障したサーバの複製先となっていたサーバにそれ以降の通信サービス要求信号を振り分けるだけでは、当該複製先のサーバに以前の約２倍の負荷がかかってしまう。そこで、このような場合には、その時点で各アプリケーションサーバ２０Ａに振り分けられている全セッションの現用及びバックアップ用のセッション情報を、各サーバの負荷がほぼ均等となるように再配置する必要がある。そして、この再配置が完了するまでの間に、一時的な通信サービス処理性能の低下が発生する場合があった。
【００２５】
また、通信サービスの需要の変化に応じてアプリケーションサーバ２０Ａの台数を増減する場合においても、同様なセッション情報の再配置が必要となるので、やはり一時的な通信サービス処理性能の低下が発生することがあった。
【００２６】
なお、従来の通信制御システム１Ａでは、データ管理サーバ３０Ａは、通信サービス加入者の加入者情報３３１等のデータを保持して管理するが、通信サービスの提供に必要となるセッション情報は保持しない。
【００２７】
＜本発明の通信制御システム＞
続いて、本発明に係る通信制御システムの構成及び動作について、図１〜図１１を用いて詳細に説明する。
【００２８】
図１は、本発明に係る通信制御システムの構成例を示す図である。図１に示すように、ネットワーク３に接続される複数のユーザ端末２に対してＩＰ電話サービスなどの通信サービスを提供する本発明に係る通信制御システム１は、ロードバランサ（信号振分け装置）１０と、クラスタを構成する複数のアプリケーションサーバ２０−１，２０−２，２０−３，・・・と、データ管理サーバ３０とを備えて構成されている。
【００２９】
ロードバランサ１０は、各ユーザ端末２から送信される新規の通信サービス要求信号を、所定の振分けアルゴリズムによっていずれか１台のアプリケーションサーバ２０に振り分け、振分け先のアプリケーションサーバ２０から送信される応答信号を、要求元のユーザ端末２に中継して返送する。
【００３０】
振り分けアルゴリズムとしては、ラウンドロビン方式、サーバ負荷判定付きラウンドロビン方式（サーバ負荷が一定以上のサーバはスキップし次のサーバを割り当てる）、ハッシュ方式、サーバ負荷判定付きハッシュ方式（サーバ負荷が一定以上のサーバはスキップし次のサーバを割り当てる）等が適用可能である。
【００３１】
また、ロードバランサ１０は、新規の通信サービス要求信号に含まれているセッション識別情報と振分け先のアプリケーションサーバ２０の識別情報とを対応付けて、振分け履歴１３２として保持しておき、以降同一のセッション識別情報を有する継続の通信サービス要求信号を、同じ振分け先のアプリケーションサーバ２０に振り分ける。
【００３２】
なお、図１の例では、ロードバランサ１０を一台としているが、振分け履歴１３２を複数のロードバランサ間で同期することにより、複数台で構成することも可能である。
【００３３】
ロードバランサ１０によって通信サービス要求信号を振り分けられたそれぞれのアプリケーションサーバ２０は、所定の手順にしたがってユーザ端末２との間のセッションを設定し、当該セッション上で所定の通信サービス（例えば、ＩＰ電話サービス）を提供する。このとき、各アプリケーションサーバ２０は、各セッション上で通信サービスを提供するために必要となるセッション識別情報やユーザ識別情報を含む所定のセッション情報を記憶部に保持し、それらのセッション情報を参照及び更新しながら所定の通信サービスを提供する。
【００３４】
また、アプリケーションサーバ２０は、提供している通信サービス（例えば、ＩＰ電話サービス）が所定の安定状態（例えば、「呼出し中」、「通話中」など）に遷移する毎に、遷移後の安定状態を表す情報を含んだセッション情報を、データ管理サーバ３０に送信してセッション情報３３２として保持させる。したがって、データ管理サーバ３０には、通信制御システム１が提供している全てのセッションの通信サービスについてのセッション情報が、セッション情報３３２として一括して保持される。
【００３５】
ここで、稼働中の１台のアプリケーションサーバ２０（例えば、アプリケーションサーバ２０−１）に障害が発生し、当該サーバは、自身が分担して提供していた通信サービスをもはや継続できなくなったものと仮定する。このとき、ロードバランサ１０は、当該アプリケーションサーバ２０−１の故障を検知すると、当該アプリケーションサーバ２０−１に振り分けていた通信サービス要求信号を、以降は他のアプリケーションサーバ２０の負荷がほぼ均等になるように、通信サービス要求信号の単位で個別に振り分ける。このとき、振分け先の各アプリケーションサーバ２０は、当該サービスの処理に必要なセッション情報（例えば、セッション情報ｓ１）を保持していないので、当該セッション情報をデータ管理サーバ３０から取得したのち、当該セッションの通信サービスを継続する。
【００３６】
このように、本発明に係る通信制御システム１では、稼働中のアプリケーションサーバ２０に障害が発生した場合であっても、ロードバランサ１０が他のアプリケーションサーバ２０に以降の通信サービス要求信号を振り分け直すだけで済むので、従来システムでは必要であったセッション情報の再配置を不要とすることができる。
【００３７】
また、通信サービスの需要の変化に応じてアプリケーションサーバ２０の台数を増減する場合においても、ロードバランサ１０が、以降の通信サービス要求信号を、増減後の全アプリケーションサーバ２０の負荷がほぼ均等になるように振り分け直すだけで済む。よって、この場合も、従来システムでは必要であったセッション情報の再配置を不要とすることができる。
【００３８】
なお、図１の例では、データ管理サーバ３０を一台としているが、公知のデータベース管理システムにおける分散技術（レプリケーション等）を適用することにより、複数台で構成することも可能である。
【００３９】
＜各装置の構成＞
次に、本発明に係る通信制御システム１が備える各装置の構成について、図２〜図４を参照して説明する（適宜、図５〜図７も参照）。
【００４０】
＜ロードバランサ（信号振分け装置）＞
図２は、ロードバランサ（信号振分け装置）１０の構成例を示す機能ブロック図である。図２に示すように、ロードバランサ１０は、制御部１１と、送受信部１２と、記憶部１３とを備えて構成される。
【００４１】
送受信部１２は、他の装置等との間の情報の送受信を行う。例えば、送受信部１２は、ユーザ端末２（図１参照）から入力される通信サービス要求信号（例えば、ＳＩＰメッセージ）や、アプリケーションサーバ２０から送信されるユーザ端末２宛の応答信号等を受信し、各アプリケーションサーバ２０に対してそれらの通信サービス要求信号を送信し、ユーザ端末２に対してそれらの応答信号等を送信する。
【００４２】
制御部１１は、ロードバランサ１０の動作の制御を司り、サービス要求受信部１１１と、サービス要求振分け部１１２と、サービス応答送信部１１３と、サーバ状態管理部１１４とを備える。これらを含む制御部１１の機能は、ロードバランサ１０が備える不図示のＣＰＵ（Central Processing Unit）が、記憶部１３に記憶されている所定のプログラムを不図示のメインメモリにロードして実行することによって具現化される。
【００４３】
サービス要求受信部１１１は、ユーザ端末２（図１参照）から送信されるサービス要求信号を送受信部１２を介して取得する。
【００４４】
サービス要求振分け部１１２は、サービス要求受信部１１１から新規の通信サービス要求信号を受け取った場合は、所定の振分けアルゴリズムを用いて当該要求信号の振分け先のアプリケーションサーバ２０を決定し、当該振分け先のアプリケーションサーバ２０に当該要求信号を送信する。また、このとき、サービス要求振分け部１１２は、当該要求信号なかに含まれるセッション識別情報と決定したアプリケーションサーバ２０とを対応付ける情報を生成し、振分け管理テーブル１３２に登録しておく。
【００４５】
そして、サービス要求振分け部１１２は、次にサービス要求受信部１１１から振分け管理テーブル１３２に登録したものと同じセッション識別情報を含んでいる継続の通信サービス要求信号を受け取った場合は、当該振分け管理テーブル１３２を参照することによって、当該継続の要求信号を、当該セッション識別情報に対応付けられているアプリケーションサーバ２０、つまり、新規の通信サービス要求信号の振分け先と同じアプリケーションサーバ２０に振り分けて送信する。
【００４６】
サービス応答送信部１１３は、振分け先のアプリケーションサーバ２０から送信される前記要求信号への応答信号を送受信部１２を介して取得し、当該応答信号を要求元のユーザ端末２に送受信部１２を介して送信する。
【００４７】
サーバ状態管理部１１４は、振分け先のアプリケーションサーバ２０の障害発生を検知した場合や、データ管理サーバ３０からアプリケーションサーバ２０の増設、減設、または故障等の通知を受信した場合、サーバ状態管理テーブル１３１に保持している当該アプリケーションサーバ２０に関する情報を追加、削除、または更新する。
【００４８】
記憶部１３は、ハードディスクや半導体メモリ等の記憶装置によって構成され、サーバ状態管理テーブル１３１と、振分け管理テーブル１３２とを備える。
【００４９】
図５は、サーバ状態管理テーブル１３１の構成及びデータ例を示す図である。図５に示すように、サーバ状態管理テーブル１３１には、サーバ識別子、サーバ状態、及びサーバ負荷からなるレコードが、管理対象となるアプリケーションサーバ２０毎に登録される。
【００５０】
ここで、サーバ識別子とは、各アプリケーションサーバ２０を一意に特定するために付される識別情報である。ここでは、便宜的にサーバ識別子の値を、「サーバＡ」、「サーバＢ」、「サーバＣ」、・・・と表している。サーバ状態とは、各アプリケーションサーバ２０の稼働状態を示すものである。サーバ状態には、例えば、正常稼働している状態を表す「稼働中」、故障していて動作不能な状態を表す「故障中」、稼働の準備が完了している状態を表す「待機中」、状態が未確認で不明であることを表す「状態確認中」のいずれかが格納される。また、サーバ負荷は、稼働中の各アプリケーションサーバ２０の負荷を、例えば、許容最大負荷に対する百分率で表したものである。なお、サーバ状態が「稼働中」以外となっているアプリケーションサーバ２０のサーバ負荷には、「−」が格納されている。
【００５１】
図６は、振分け管理テーブル（振分け履歴）１３２の構成及びデータ例を示す図である。図６は、ＳＩＰを用いて通信サービスが提供される場合の構成及びデータ例であり、振分け管理テーブル１３２には、Ｃａｌｌ−ＩＤ、サーバ識別子、及び最終振分け時刻からなるレコードが、通信サービスが提供されているセッション（呼）毎に登録される。
【００５２】
ここで、Ｃａｌｌ−ＩＤとは、各セッション（呼）を一意に特定するために、発信元のユーザ端末２によって指定される識別情報である。ここでは、便宜的にＣａｌｌ−ＩＤの値を、「呼識別子ｃ１」、「呼識別子ｃ２」、「呼識別子ｃ３」・・・と表している。サーバ識別子とは、当該セッションの通信サービス要求信号の振分け先として決定したアプリケーションサーバ２０に付されている識別情報（図５と同じ）である。また、最終振分け時刻とは、当該セッションにおいて最後に通信サービス要求信号を振り分けた時刻である。ここでは、便宜的に最終振分け時刻の値を、「時刻ｔ１」、「時刻ｔ２」、「時刻ｔ３」、・・・と表している。
【００５３】
＜アプリケーションサーバ＞
図３は、アプリケーションサーバ２０の構成例を示す機能ブロック図である。図３に示すように、アプリケーションサーバ２０は、制御部２１と、送受信部２２と、記憶部２３とを備えて構成される。
【００５４】
送受信部２２は、他の装置等との間の情報の送受信を行う。例えば、送受信部２２は、ユーザ端末２（図１参照）から入力され、ロードバランサ１０によって振り分けられた通信サービス要求信号（例えば、ＳＩＰメッセージ）受信し、ロードバランサ１０に対してユーザ端末２に返送する応答信号を送信する。また、データ管理サーバ３０との間では、セッション情報や、アプリケーションサーバ２０の状態変化等に関する情報の送受信を行う。
【００５５】
制御部２１は、アプリケーションサーバ２０の動作の制御を司り、セッション制御処理部２１１と、セッション情報登録部２１２と、セッション情報取得部２１３とを備える。これらを含む制御部２１の機能は、アプリケーションサーバ２０が備える不図示のＣＰＵが、記憶部２３に記憶されている所定のプログラムを不図示のメインメモリにロードして実行することによって具現化される。
【００５６】
セッション制御処理部２１１は、ユーザ端末２（図１参照）から送信され、ロードバランサ１０によって振り分けられた通信サービス要求信号（例えば、ＳＩＰメッセージ）を送受信部１２を介して取得し、通信サービス（例えば、ＩＰ電話サービス）を提供するために必要なセッション情報を生成したのち、当該セッション情報を参照及び更新しながらセッション制御処理（例えば、ＩＰ電話の呼制御処理）を実行する。
【００５７】
セッション情報登録部２１２は、セッション制御処理（例えば、呼制御処理）の実行に伴って通信サービスが所定の安定状態（例えば、「呼出し中」、「通話中」など）に遷移する毎に、当該遷移後の安定状態を表す情報を含むセッション情報（例えば、呼情報）を、送受信部１２を介してデータ管理サーバ３０に登録し、または更新する。
【００５８】
また、セッション情報取得部２１３は、ロードバランサ１０によって振り分けられた継続の通信サービス要求信号（例えば、ＳＩＰメッセージ）に対応するセッション制御処理（例えば、呼制御処理）の実行に必要なセッション情報（例えば、呼情報）を自身が保持していない場合、送受信部１２を介してデータ管理サーバ３０から当該セッション情報を取得する。
【００５９】
記憶部２３は、ハードディスクや半導体メモリ等の記憶装置によって構成され、セッション情報管理キャッシュテーブル２３１を備える。セッション情報管理キャッシュテーブル２３１には、図７を用いて後記するセッション情報管理テーブル３３２のレコードのうち、当該アプリケーションサーバ２０に振り分けられたセッションに該当するレコードと同じ内容が登録される。
【００６０】
＜データ管理サーバ＞
図４は、データ管理サーバ３０の構成例を示す機能ブロック図である。図４に示すように、データ管理サーバ３０は、制御部３１と、送受信部３２と、記憶部３３とを備えて構成される。
【００６１】
送受信部３２は、他の装置等との間の情報の送受信を行う。例えば、送受信部３２は、アプリケーションサーバ２０から送信される加入者情報やセッション情報の参照を要求する信号等を受信し、当該アプリケーションサーバ２０に対して要求された加入者情報やセッション情報等を送信する。さらに、アプリケーションサーバ２０から送信されるセッション情報の登録及び更新を要求する信号を受信し、また、不図示の管理者用端末からアプリケーションサーバ２０の故障や増減設についての情報を受信し、それらの情報を各アプリケーションサーバ２０に送信する。
【００６２】
制御部３１は、データ管理サーバ３０の動作の制御を司り、加入者情報管理部３１１と、セッション情報管理部３１２と、サーバ情報管理部３１３とを備える。これらを含む制御部３１の機能は、データ管理サーバ３０が備える不図示のＣＰＵが、記憶部３３に記憶されている所定のプログラムを不図示のメインメモリにロードして実行することによって具現化される。
【００６３】
加入者情報管理部３１１は、加入者情報管理テーブル３３１に保持される各加入者の情報の登録、削除、更新、参照などを行う。セッション情報管理部３１２は、セッション情報管理テーブル３３２に保持されるセッション情報の登録、削除、更新、参照などを行う。また、サーバ情報管理部３１３は、サーバ情報管理テーブル３３３に保持されるサーバ情報の登録、削除、更新、参照などを行う。
【００６４】
記憶部３３は、ハードディスクや半導体メモリ等の記憶装置によって構成され、加入者情報管理テーブル３３１、セッション情報管理テーブル３３２、及びサーバ情報管理テーブル３３３を備える。
【００６５】
このうち、加入者情報管理テーブル３３１には、ユーザ端末２からアプリケーションサーバ２０を介して送信される加入者情報が登録される。この加入者情報には、加入者の識別情報と、当該加入者が利用するユーザ端末２のＩＰアドレスとが含まれる（詳細構成についての図は省略）。サーバ情報管理テーブル３３３には、各アプリケーションサーバ２０のサーバ識別子、ＩＰアドレス、許容最大負荷等が含まれる。
【００６６】
図７は、セッション情報管理テーブル（セッション情報）３３２の構成及びデータ例を示す図である。図７は、ＳＩＰを用いて通信サービスが提供される場合の構成及びデータ例であり、セッション情報管理テーブル（セッション情報）３３２には、Ｃａｌｌ−ＩＤ、Ｖｉａ、Ｆｒｏｍ、Ｔｏ、ＣＳｅｑ、及びＳＩＰ安定状態からなるレコードが、通信サービスが提供されているセッション（呼）毎に登録される。
【００６７】
ここで、Ｃａｌｌ−ＩＤとは、図６の説明にて前記したように、各セッションを一意に特定するために、発信元のユーザ端末２によって指定される識別情報である。Ｖｉａとは、当該セッションの通信サービス要求信号に対する応答信号の応答先を指定する情報である。ここでは、便宜的にＶｉａの値を、「応答先ｒ１」、「応答先ｒ２」、「応答先ｒ３」、・・・と表している。Ｆｒｏｍは、サービス要求の発信元を示す情報であり、Ｔｏは、サービス要求の着信先を示す情報である。ＩＰ電話サービスの場合は、Ｆｒｏｍが発信元ユーザ、Ｔｏが着信先ユーザにそれぞれ対応する。ここでは、便宜的にＦｒｏｍ及びＴｏの値を、「ユーザｕ１」、「ユーザｕ２」、「ユーザｕ３」、・・・と表している。
【００６８】
ＣＳｅｑには、当該セッションにおける最新の通信サービス要求信号（例えば、ＳＩＰメッセージ）の情報が保持される。図７のデータ例では、ＣＳｅｑの値は、ＳＩＰメッセージに付される一連番号と、要求の種類を示す所定のリクエスト名（例えば、「ＩＮＶＩＴＥ」、「ＡＣＫ」等）とから構成されている。また、ＳＩＰ安定状態とは、当該セッションにおいて提供されている通信サービスがどの段階まで進んでいるかを示す情報である。
【００６９】
図８は、ＳＩＰを用いたＩＰ電話サービスにおけるＳＩＰ安定状態についての説明図である。図８に示すように、ＳＩＰを用いたＩＰ電話サービスでは、発信元ユーザ端末２Ａと着信先ユーザ端末２Ｂとの間で通話セッションを設定して開放するまでの一連の手順が規定されている。つまり、サービスの実行単位となる一つの通話のライフサイクルにおいて、これらの手順にしたがって、「呼出し」、「応答」、「切断」などの複数の異なる処理が実行される。詳しい説明は省略するが、ＳＩＰ安定状態とは、アプリケーションサーバ（ＳＩＰサーバ）２０の処理がどこまで進んでいるかを示すものであり、図８における「ＳＴ１」〜「ＳＴ１２」のいずれかの値をもつ。なお、データ管理サーバ３０が保持するセッション情報管理テーブル３３２には、例えば、「ＳＴ５」以降の値を格納するものとし、「ＳＴ１」〜「ＳＴ４」については、アプリケーションサーバ２０のローカル情報として、セッション情報管理キャッシュテーブル２３１側だけに保持するものとしてもよい。
【００７０】
＜ロードバランサの振分け処理＞
続いて、ロードバランサ１０が実行する振分け処理の詳細を、図９を参照して説明する。図９は、ロードバランサ１０が実行する振分け処理の例を示すフローチャートである。
【００７１】
ユーザ端末２からロードバランサ１０宛に送信される通信サービス要求信号は、送受信部１２を介してサービス要求受信部１１１が取得し、サービス要求振分け部１１２に引き渡される。サービス要求振分け部１１２は、ステップＳ１１にて、当該要求信号が新規のセッションに該当するものか否かを判定し、新規のセッションであれば（ステップＳ１１で「Ｙｅｓ」）ステップＳ１３に、新規のセッションでなければ（ステップＳ１１で「Ｎｏ」）ステップＳ１２に処理を進める。このとき、新規のセッションか否かを判定するに当たっては、振分け管理テーブル１３２（図６参照）が参照される。具体的には、振分け管理テーブル１３２に、当該要求信号に含まれるセッション識別情報（例えば、ＳＩＰのＣａｌｌ−ＩＤの値）と一致するレコードが登録されていれば新規のセッションではないと判定され、そうでなければ新規のセッションであると判定される。
【００７２】
ステップＳ１２では、サービス要求振分け部１１２は、振分け管理テーブル１３２の該当レコードからサーバ識別子の値を取得することによって振分け済みのアプリケーションサーバ２０を特定し、サーバ状態管理テーブル１３１を参照して当該サーバが稼働中か否かを判定する。そして、当該サーバが稼働中でなければ（ステップＳ１２で「Ｎｏ」）ステップＳ１３に、稼働中であれば（ステップＳ１２で「Ｙｅｓ」）ステップＳ１５に処理を進める。
【００７３】
ステップＳ１３では、サービス要求振分け部１１２は、所定の振分けアルゴリズムにより、稼働中のアプリケーションサーバ２０のなかから振分け先サーバを決定する。次に、ステップＳ１４にて、サービス要求振分け部１１２は、当該Ｃａｌｌ−ＩＤの値と当該振分け先サーバのサーバ識別子とを対応付ける新たなレコードを生成し、振分け管理テーブル１３２に追加登録する。一方、ステップＳ１５では、サービス要求振分け部１１２は、ステップＳ１２にて特定した当該サーバを振分け先サーバに決定する。
【００７４】
次に、サービス要求振分け部１１２は、ステップＳ１６にて、ステップＳ１３またはステップＳ１５で決定した振分け先サーバに、当該要求信号を送受信部１２を介して転送する。次に、サービス要求振分け部１１２は、ステップＳ１７にて、当該要求信号の転送が成功したか否かを判定し、転送が成功した場合は（ステップＳ１７で「Ｙｅｓ」）ステップＳ１８に、転送が失敗した場合は（ステップＳ１７で「Ｎｏ」）ステップＳ１９に処理を進める。
【００７５】
ステップＳ１８では、サービス要求振分け部１１２は、現在時刻を最終振分け時刻として振分け管理テーブル１３２の該当レコードに格納したのち、処理を終了する。一方、ステップＳ１９では、サービス要求振分け部１１２は、サーバ状態管理テーブル１３１に保持されている当該振分け先サーバのサーバ状態を「故障中」に変更したのち、結合子ＡによってステップＳ１３に処理を戻して、振分け先サーバを決定し直す。このとき、サーバ状態管理テーブル１３１にサーバ状態が「待機中」となっているアプリケーションサーバが登録されている場合は、そのいずれかのサーバ状態を「稼働中」に変更したのちに、振分けサーバを決定し直すものとしてもよい。
【００７６】
＜アプリケーションサーバのサービス要求処理＞
続いて、アプリケーションサーバ２０が実行するサービス要求処理の詳細を、図１０を参照して説明する。図１０は、アプリケーションサーバ２０が実行する振分け処理の例を示すフローチャートである。
【００７７】
ユーザ端末２から送信される通信サービス要求信号は、ロードバランサ１０によっていずれか１台のアプリケーションサーバ２０に振り分けられて送信される。振分け先のアプリケーションサーバ２０では、ロードバランサ１０から送信される通信サービス要求信号を、送受信部２２を介してセッション制御処理部２１１が取得する。
【００７８】
セッション制御処理部２１１は、ステップＳ２１にて、当該要求信号が新規のサービス要求（例えば、ＳＩＰのＩＮＶＩＴＥリクエスト）に該当するものか否かを判定し、新規のサービス要求であれば（ステップＳ２１で「Ｙｅｓ」）ステップＳ２２に、新規のサービス要求でなければ（ステップＳ２１で「Ｎｏ」）ステップＳ２３に処理を進める。
【００７９】
ステップＳ２２では、セッション制御処理部２１１は、当該要求信号に含まれるＣａｌｌ−ＩＤ、Ｖｉａ、Ｆｒｏｍ、Ｔｏ，及びＣＳｅｑの値を抽出して新たなセッション情報のレコードを生成し、セッション情報管理キャッシュテーブル２３１に追加登録する。
【００８０】
一方、ステップＳ２３では、セッション制御処理部２１１は、セッション情報管理キャッシュテーブル２３１（データ構成は、図７のセッション情報管理テーブル３３２と同一）に、当該セッションのセッション情報が保持されているか否かを判定する。そして、セッション情報が保持されていれば（ステップＳ２３で「Ｙｅｓ」）ステップＳ２５に、セッション情報が保持されていなければ（ステップＳ２３で「Ｎｏ」）ステップＳ２４に処理を進める。このとき、セッション情報管理キャッシュテーブル２３１に、当該要求信号に含まれるセッション識別情報（例えば、ＳＩＰのＣａｌｌ−ＩＤの値）と一致するレコードが登録されていればセッション情報が保持されていると判定され、そうでなければセッション情報が保持されていないと判定される。
【００８１】
ステップＳ２４では、セッション制御処理部２１１は、データ管理サーバ３０から当該セッション識別情報に該当するセッション情報を取得する。具体的には、当該セッション識別情報（例えば、Ｃａｌｌ−ＩＤの値）を含むセッション情報の取得要求信号を、送受信部２２を介してデータ管理サーバ３０に送信し、その応答信号を送受信部２２を介してデータ管理サーバ３０から受信することで必要なセッション情報を取得する。そして、取得したセッション情報を含んだ新たなレコードを生成し、セッション情報管理キャッシュテーブル２３１に追加登録する。
【００８２】
次に、セッション制御処理部２１１は、ステップＳ２５にて、セッション情報管理キャッシュテーブル２３１に保持されているセッション情報を参照しながら当該要求信号に対応する所定の処理を実行する。そして、処理の結果、当該セッションの安定状態が遷移した場合には、セッション情報管理キャッシュテーブル２３１の当該セッション情報を更新する。また、当該セッション情報の安定状態が所定の安定状態に更新された場合には、ステップＳ２６にてデータ管理サーバ３０がセッション情報管理テーブル３３２に保持している当該セッション情報の登録更新または更新を要求したのち、処理を終了する。
【００８３】
＜アプリケーションサーバ障害時の動作＞
最後に、稼働中のアプリケーションサーバ２０に障害が発生した場合の動作を、図１１を参照して説明する。図１１は、ＳＩＰを用いてＩＰ電話サービスを提供しているアプリケーションサーバ２０−１に障害が発生ときの信号及び処理の流れの例を示すシーケンス図である。
【００８４】
まず、ステップＳ３１にて、発信元ユーザ端末２Ａから呼接続を要求するＩＮＶＩＴＥリクエストがロードバランサに送信される。ロードバランサ１０は、この新規の通信サービス要求信号を、例えばアプリケーションサーバ２０−１に振り分け、当該アプリケーションサーバ２０−１によって着信先ユーザ端末２Ｂ（図８参照）を呼び出すための呼処理が順次実行される（ステップＳ３２〜Ｓ４０）。なお、ステップＳ３２〜Ｓ４０の処理の詳細は、図９、図１０で説明したため、ここでは省略する。
【００８５】
ここで、アプリケーションサーバ２０−１がステップＳ３９の応答信号をロードバランサ１０に送信した直後に障害が発生し、当該アプリケーションサーバ２０−１が動作不能状態に陥ったものとする。このとき、ロードバランサ１０は、発信元ユーザ端末２Ａから次に送信されるサービス要求信号Ｓ４１を当該アプリケーションサーバ２０−１に振り分けようと送信を試るが、送信に失敗してしまう。そこで、ロードバランサ１０は、当該アプリケーションサーバ２０−１が故障中であるものと判断し、所定の振分けアルゴリズムによって稼働中の他のアプリケーションサーバ（例えば、アプリケーションサーバ２０−２）に、当該要求信号を再振分けして送信する（ステップＳ４２）。
【００８６】
このとき、アプリケーションサーバ２０−２は、当該要求信号に対する呼処理を実行するために必要な呼情報（セッション情報）を保持していない。そこで、アプリケーションサーバ２０−２のセッション情報取得部２１３は、データ管理サーバ３０に対して当該呼情報の取得を要求する（ステップＳ４３）。呼情報の取得を要求されたデータ管理サーバ３０のセッション情報管理部３１２は、セッション情報管理テーブル３３２から要求された呼情報を読み出してアプリケーションサーバ２０−２に返送する（ステップＳ４４）。これにより、アプリケーションサーバ２０−２のセッション制御処理部２１１は、データ管理サーバ３０から返送された呼情報を自身のセッション情報管理キャッシュテーブル２３１に追加登録したのち、当該呼情報を用いて呼処理を実行する（ステップＳ４５〜Ｓ４７）。その結果、セッションの安定状態が遷移してセッション情報管理キャッシュテーブル２３１のセッション情報が更新された場合には、ステップＳ４５にて、アプリケーションサーバ２０−２のセッション情報登録部２１２が、更新された当該セッション情報をデータ管理サーバ３０に送信することで、当該更新されたセッション情報がデータ管理サーバ３０のセッション情報管理テーブル３３２に登録されて保持される。
【００８７】
なお、アプリケーションサーバ２０を増減設する場合においては、ロードバランサ１０が、サーバ状態管理部１１４によって増減設の結果が反映されたサーバ状態管理テーブル１３１を参照して、その時点で稼働中のアプリケーションサーバ２０に以降の通信サービス要求信号を振り分け直す。その結果、必要なセッション情報を保持していないアプリケーションサーバ２０に継続の通信サービス要求信号が振り分けられた場合であっても、当該アプリケーションサーバ２０が必要なセッション情報をその都度データ管理サーバ３０から取得するので、従来システムのようにセッション情報を再配置する必要はない。
【００８８】
以上説明したように、本実施形態では従来は各アプリケーションサーバ２０Ａ（図１２参照）が分散して保持していたセッション情報及びそのバックアップ情報を、データ管理サーバ３０にて一括して保持する。よって、アプリケーションサーバ２０Ａが故障したり増減設されたりした場合に従来は必要であったセッション情報及びそのバックアップ情報の再配置を不要とすることができる。そのため、本実施形態によれば、従来のシステムでは回避できなかった一時的な通信サービス処理性能の低下の発生を、確実に抑止することが可能となる。
【００８９】
また、従来技術では、各アプリケーションサーバ２０Ａ上にバックアップ分も含めたセッション情報が分散して保持されていたため、アプリケーションサーバ２０Ａ上の処理プログラムを更新する際は、セッション情報の世代管理（当該データの新旧を更新されたプログラムで識別して旧データを新データに変換する等の処理）が必要であった。これに対し、本実施形態によれば、アプリケーションサーバ２０上の処理が、ユーザ端末２からの通信サービス要求信号と、データ管理サーバ３０上のセッション情報のみに依存するように構成することができる。したがって、アプリケーションサーバ２０上の処理プログラムの更新が容易になるという効果をも奏する。
【００９０】
以上にて本発明の実施形態の説明を終えるが、本発明の実施の態様はこれに限られるものではなく、本発明の趣旨を逸脱しない範囲において各種変形が可能である。
【符号の説明】
【００９１】
１，１Ａ  通信制御システム
２    ユーザ端末
２Ａ  発信元ユーザ端末
２Ｂ  着信先ユーザ端末
３    ネットワーク
１０，１０Ａ  ロードバランサ
１１，２１，３１  制御部
１２，２２，３２  送受信部
１３，２３，３３  記憶部
２０，２０Ａ  アプリケーションサーバ（ＳＩＰサーバ）（処理サーバ）
３０，３０Ａ  データ管理サーバ
１１１  サービス要求受信部
１１２  サービス要求振分け部
１１３  サービス応答送信部
１１４  サーバ状態管理部
１３１  サーバ状態管理テーブル
１３２  振分け管理テーブル（振分け履歴）
２１１  セッション制御処理部
２１２  セッション情報登録部
２１３  セッション情報取得部
２３１  セッション情報管理キャッシュテーブル
３１１  加入者情報管理部
３１２  セッション情報管理部
３１３  サーバ情報管理部
３３１  加入者情報管理テーブル（加入者情報）
３３２  セッション情報管理テーブル（セッション情報）
３３３  サーバ情報管理テーブル
【図１】
2014220675.tif 000003
【図２】
2014220675.tif 000004
【図３】
2014220675.tif 000005
【図４】
2014220675.tif 000006
【図５】
2014220675.tif 000007
【図６】
2014220675.tif 000008
【図７】
2014220675.tif 000009
【図８】
2014220675.tif 000010
【図９】
2014220675.tif 000011
【図１０】
2014220675.tif 000012
【図１１】
2014220675.tif 000013
【図１２】
2014220675.tif 000014