セッション制御方法およびセッション制御サーバ
【課題】マルチコアを搭載し、複数のプロセスを同時に並列して処理する制御サーバにおいて、適切に輻輳を制御する。
【解決手段】セッション制御サーバ１は、処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスと、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部５０と、を備える。ここで、受信処理部１０が輻輳状態の場合、呼制御処理部２０、３０または４０が処理を拒否する応答信号を出力する。呼制御処理部２０、３０または４０が輻輳状態の場合、受信処理部１０が処理を拒否する応答信号を出力する。受信処理部１０および呼制御処理部２０、３０または４０が輻輳状態の場合、呼制御処理部２０、３０または４０が処理を拒否する応答信号を出力する。
【解決手段】セッション制御サーバ１は、処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスと、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部５０と、を備える。ここで、受信処理部１０が輻輳状態の場合、呼制御処理部２０、３０または４０が処理を拒否する応答信号を出力する。呼制御処理部２０、３０または４０が輻輳状態の場合、受信処理部１０が処理を拒否する応答信号を出力する。受信処理部１０および呼制御処理部２０、３０または４０が輻輳状態の場合、呼制御処理部２０、３０または４０が処理を拒否する応答信号を出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法およびセッション制御サーバに関する。
【背景技術】
【０００２】
一般的に、電話通信システムなど、通信システムにおけるセッション制御システムにおいて、通信システムがその処理能力を超えて呼を受けると、通信システムの接続完了率が低下する状態に陥ってしまう。この状態は、輻輳と呼ばれる。輻輳の形態によって、企画型輻輳、災害型輻輳、サーバ輻輳の３つに分類される。企画型輻輳は、電話によるチケットの予約などにおいて、その予約開始時刻に呼が集中することによって、発生する。災害型輻輳は、災害が発生時などにおいて、住人の安否確認のための呼が集中することによって、発生する。
【０００３】
サーバ輻輳は、呼制御信号の集中やサーバリソースの逼迫により、呼処理能力が低下することによって、発生する。サーバリソースは、例えばサーバのＣＰＵやメモリであって、サーバリソースが故障などにより逼迫した場合に、サーバ輻輳が発生する。
【０００４】
輻輳状態になると、サーバの処理能力が低下したり、サーバダウンによるサービスの劣化や停止などが発生したりする。従って、通信システムにおけるセッション制御システムにおいて、輻輳を検出するとともに、輻輳を検出した際、サービスやシステム保護を目的として、その対処機能を備えている。この輻輳検出や、輻輳検出時の対処機能は、一般的に輻輳制御と呼ばれる。
【０００５】
例えば、一般的なサーバ輻輳を検出する方法として、サーバのＣＰＵ使用率が予め設定した閾値を越えているか否かを判定する方法がある。また、検出した輻輳を制御する方法として、サーバが輻輳状態である間、新たに呼を受信すると、輻輳状態であることを理由に意図的にその呼を拒否する方法がある。また電話システムにおいては呼には優先度があり、輻輳状態で拒否するべき呼を優先度に応じて選択する方法もある。ここで呼を拒否する場合、発信端末に呼を拒否する意味を持つ信号を送信する。サーバの負荷を可能な限り低減するため、受信直後に、通常の呼処理ルートから分岐し、信号拒否ルートにおいて、信号を拒否する方法が採られる。これにより、呼を受信したサーバは、輻輳時でも、サーバの信号処理量を低減しつつ、拒否する意味を持つ信号を送信することができる。
【０００６】
また、マルチコアＣＰＵを搭載したサーバが一般的となり、セッション制御システムにおいても、マルチコアＣＰＵを搭載したサーバで、セッション制御サーバが構築される傾向がある。マルチコアＣＰＵを搭載したセッション制御サーバは、複数のコアを有効活用するために、複数のプロセス（もしくはスレッド）に処理を分散させて、並列にその処理を実行する。分散方式の一例として、このセッション制御サーバが、発呼信号を受信する受信処理部と、受信処理部により取得された発呼信号に基づいて呼を処理する呼制御処理部を備える場合がある。
【０００７】
図８を参照して、このようなセッション制御サーバにおける呼の処理を説明する。
【０００８】
まずステップＳ９０１において受信処理部は、発呼信号を受信すると、ステップＳ９０２において自身のサーバが輻輳状態であるか否かを判定する。サーバが輻輳状態でない場合、ステップＳ９０４において受信処理部は、受信した呼を、後続プロセスである呼制御処理部にキューイングする。ステップＳ９０６において呼制御処理部は、キューから呼を取り出して処理し、応答信号を送信する。
【０００９】
一方ステップＳ９０２においてサーバが輻輳状態であると判断された場合、ステップＳ９０３において受信処理部は、受信した呼を拒否するか否かを判定する。ここで受信処理部は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップＳ９０４に進み、ステップＳ９０６において呼が処理される。受信した呼を拒否する場合、ステップＳ９０５において受信処理部は、拒否信号を生成して応答ソケットに書き込み、応答信号が送信される。
【００１０】
このように、セッション制御サーバにおいて、複数のプロセスがシーケンシャルに処理をすることによって、複数のコアを有効活用し、効率的に処理する方法が採られている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特許第４２０８７０３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、マルチコアＣＰＵを搭載したセッション制御サーバにおいて、複数のプロセスに処理を分散させ、シーケンシャルに処理させる場合、各プロセスが一つの信号に対する処理量が異なる場合がある。これにより、一定時間内に処理可能な信号の数も、各プロセスによって異なる場合がある。
【００１３】
マルチコアＣＰＵ環境では、それぞれのプロセスが同時に並列して処理することができるので、大量の信号を処理することができる。しかし、その１信号の処理に要する時間がプロセスによって異なるため、処理の遅いプロセスのみ処理が滞り、輻輳状態になる場合がある。この場合、一部のプロセスのみ輻輳状態となる。このように一部のプロセスのみ輻輳状態のことを、本実施形態においてプロセス輻輳と称する。
【００１４】
このようなプロセス輻輳の状態では、サーバ全体では輻輳状態とは判定されない場合もある。具体的には、プロセス輻輳に陥っているプロセスは、コアを１００％使用している。しかし、処理の早いプロセスは処理量に余裕があり、その他のプロセス輻輳でないプロセスでは、コアを１００％使用することはない。
【００１５】
従来、サーバのＣＰＵの使用率が閾値を越えた場合に、サーバ輻輳が検出されるので、マルチコアＣＰＵのセッション制御サーバにおいては、すべてのコアの使用率の平均値に基づいてサーバ輻輳が検出されてしまう。従って、プロセス輻輳の状態では、個別のプロセスにおいて輻輳が発生していても、そのほかのプロセスでは輻輳状態ではないため、サーバ輻輳が検出されない場合がある。
【００１６】
これにより、呼の集中によりサーバ全体で呼の処理性能が低下しているにもかかわらず、その事象を検出することができない問題がある。
【００１７】
従って本発明の目的は、マルチコアを搭載し、複数のプロセスを同時に並列して処理する制御サーバにおいて、適切に輻輳を制御するセッションセッション制御方法およびセッション制御サーバを提供することである。
【課題を解決するための手段】
【００１８】
上記課題を解決するために、本発明の第１の特徴は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法に関する。すなわち本発明の第１の特徴に係るセッション制御方法は、複数のプロセスが、各プロセスの処理キューに蓄積されたキューを、順次並列に処理するステップと、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視するステップを備える。
【００１９】
ここで、輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。
【００２０】
また、外部から入力された信号を処理するプロセスが輻輳状態の場合、内部から処理がキューイングされるプロセスが処理を拒否する応答信号を出力するステップと、内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップと、外部から入力された信号を処理するプロセスおよび前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップをさらに備えても良い。
【００２１】
本発明の第２の特徴は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するセッション制御サーバに関する。すなわち本発明の第２の特徴に係るセッション制御サーバは、処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスを実現する複数の処理部と、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部を備える。
【００２２】
ここで、輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。
【００２３】
また、プロセスは、外部から入力された信号を処理する受信処理部と、前記受信処理部から入力された信号を処理する呼制御処理部によって実現され、受信処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力し、呼制御処理部が輻輳状態の場合、前記受信処理部が処理を拒否する応答信号を出力し、受信処理部および前記呼制御処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力しても良い。
【発明の効果】
【００２４】
本発明によれば、マルチコアを搭載し、複数のプロセスを同時に並列して処理する制御サーバにおいて、適切に輻輳を制御するセッションセッション制御方法およびセッション制御サーバを提供することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施の形態に係るセッション制御サーバの機能ブロック図の一例である。
【図２】本発明の実施の形態に係る輻輳状態データのデータ構造とデータの一例を説明する図である。
【図３】本発明の実施の形態に係るセッション制御方法において、プロセス輻輳を検出する処理を説明するフローチャートである。
【図４】本発明の実施の形態に係るセッション制御方法を説明するフローチャートである。
【図５】本発明の実施の形態において、受信処理部において輻輳が発生した場合の処理を説明する図である。
【図６】本発明の実施の形態において、呼制御処理部において輻輳が発生した場合の処理を説明する図である。
【図７】本発明の実施の形態において、受信処理部および呼制御処理部において輻輳が発生した場合の処理を説明する図である。
【図８】従来のセッション制御方法を説明するフローチャートである。
【発明を実施するための形態】
【００２６】
次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。
【００２７】
本発明の実施の形態に係るセッション制御サーバ１は、コンピュータに所定の処理を実行するプログラムがインストールされて実現される。セッション制御サーバ１は特に、マルチコアを搭載し、複数のプロセスを同時に並列して処理することのできるコンピュータによって実現される。
【００２８】
図１に示すセッション制御サーバ１は、例えば電話システムなどにおいて、外部から入力された発呼信号２から応答信号３を出力する。
【００２９】
セッション制御サーバ１は、受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０および輻輳監視部５０を備える。受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０および輻輳監視部５０は、それぞれプロセスによって実現される。受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０、第３の呼制御処理部４０および輻輳監視部５０は、それぞれスレッドによって実現されても良い。本実施の形態において、プロセスは、一般的なプロセスとスレッドの意味を含むものとして説明する。ここで、図１に示す例において、セッション制御サーバ１が、３つの呼制御処理部を備える場合について説明するが、呼制御処理部の数は、1つでも４つ以上でも良い。
【００３０】
セッション制御サーバ１の複数のプロセスは、各プロセスの処理キューに蓄積されたキューを、順次並列に処理する。
【００３１】
受信処理部１０は、外部から入力された信号を処理するプロセスを実現する処理部である。受信処理部１０は、受信信号保存キュー１１を備える。セッション制御サーバ１が発呼信号２を受信すると、受信された発呼信号２は、受信信号保存キュー１１に蓄積され、受信処理部１０による処理を待機する。受信処理部１０は、受信信号保存キュー１１から一つずつ呼を取り出して、後続のプロセスのいずれかにキューイングする。ここで図１に示す例において受信処理部１０の後続のプロセスは、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０である。いずれのプロセスにキューイングするかは、所定の手順で決定される。
【００３２】
受信処理部１０から第１の呼制御処理部２０にキューイングされた呼は、第１の呼制御処理部２０の呼制御処理保存キュー２１に蓄積される。第１の呼制御処理部２０は、内部から処理がキューイングされるプロセスを実現する処理部である。第１の呼制御処理部２０は、呼制御処理保存キュー２１から一つずつ呼を取り出して所定の手順で処理し、応答信号３を出力する。
【００３３】
同様に、受信処理部１０から第２の呼制御処理部３０にキューイングされた呼は、第２の呼制御処理部３０の呼制御処理保存キュー３１に蓄積される。第２の呼制御処理部３０は、内部から処理がキューイングされるプロセスを実現する処理部である。第２の呼制御処理部３０は、呼制御処理保存キュー３１から一つずつ呼を取り出して所定の手順で処理し、応答信号３を出力する。受信処理部１０から第３の呼制御処理部４０にキューイングされた呼は、第３の呼制御処理部４０の呼制御処理保存キュー４１に蓄積される。第３の呼制御処理部４０は、内部から処理がキューイングされるプロセスを実現する処理部である。第３の呼制御処理部４０は、呼制御処理保存キュー４１から一つずつ呼を取り出して所定の手順で処理し、応答信号３を出力する。
【００３４】
受信処理部１０は、受信した呼を、後続のプロセスに引き渡すほか、輻輳により呼を拒否する場合、輻輳状態データ５１ａを参照して、受信処理部１０は、その拒否する応答信号を出力させるプロセスを特定する。ここで呼を拒否するか否かは、呼の優先度、信号種などにより、判断される。
【００３５】
受信処理部１０が輻輳状態の場合、受信処理部１０は、拒否応答信号を出力するプロセスとして、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれかを特定する。受信処理部１０は、特定されたプロセスに、拒否する応答信号を出力させる。第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれかが輻輳状態の場合、受信処理部１０は、拒否応答信号を出力するプロセスとして、受信処理部１０自身を特定する。受信処理部１０が処理を拒否する応答信号を出力する。受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれもが輻輳状態の場合、受信処理部１０は、拒否応答信号を出力するプロセスとして、受信処理部１０自身を特定する。受信処理部１０が処理を拒否する応答信号を出力する。
【００３６】
輻輳監視部５０は、セッション制御サーバ１の監視対象のプロセスについて、各プロセスが輻輳状態であるか否かを周期的に監視し、輻輳状態データ５１ａとして輻輳状態記憶部５１に記憶する。ここで、輻輳監視部５０の監視対象プロセスは、受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０の各プロセスである。輻輳監視部５０は、セッション制御サーバ１全体の輻輳状態を監視するとともに、これら各プロセスの輻輳状態を監視する。セッション制御サーバ１全体の輻輳状態は、サーバ全体のＣＰＵ使用率から判定される。
【００３７】
輻輳監視部５０が各プロセスの輻輳状態を監視する際、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、輻輳状態であるか否かが判定される。輻輳監視部５０が、各プロセスの輻輳状態を監視する方法として、（１）プロセスのコア使用率を参照する方法、（２）プロセスの処理キューに蓄積された処理数を参照する方法および（３）プロセスのコア使用率およびプロセスの処理キューに蓄積された処理数を参照する方法が考えられる。輻輳監視部５０は、各プロセスの使用率または／および処理キューに蓄積された処理数を保持し、各プロセスの使用率または／および処理キューに蓄積された処理数が、所定期間閾値を超えた場合に、各プロセスが輻輳状態であると判定する。ここで、所定期間は、１周期でも良い。
【００３８】
（１）の場合、輻輳監視部５０は、監視対象のプロセスのコア使用率が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。輻輳監視部５０は、各プロセスについて、逐次コアの使用率を算出し、そのコア使用率のログを取得する。
【００３９】
（２）の場合、輻輳監視部５０は、監視対象のプロセスの処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。ここで、輻輳監視部５０は、各プロセスについて、逐次各プロセスの処理キューに蓄積された処理数のログを取得する。この処理キューは、各プロセスに対応づけられた処理キューである。図１に示す例において、受信処理部１０のプロセスについて、処理キューは、受信信号保存キュー１１に記憶された受信処理キューである。第１の呼制御処理部２０のプロセスについて、処理キューは、呼制御処理保存キュー２１に記憶された呼制御処理キューである。第２の呼制御処理部３０のプロセスについて、処理キューは、呼制御処理保存キュー３１に記憶された呼制御処理キューである。第３の呼制御処理部４０のプロセスについて、処理キューは、呼制御処理保存キュー４１に記憶された呼制御処理キューである。
【００４０】
（３）の場合、輻輳監視部５０は、監視対象のプロセスのコア使用率が、所定期間連続して閾値を超え、かつ、監視対象のプロセスの処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。輻輳監視部５０は、各プロセスの使用率および処理キューに蓄積された処理数がともに、所定期間閾値を超えたプロセスを、輻輳状態であると判定する。
【００４１】
輻輳監視部５０において、（１）ないし（３）のいずれかの輻輳監視対象、所定期間および閾値が、予め設定される。その設定に従って、輻輳監視部５０は、各プロセスの輻輳状態を監視する。また、輻輳監視部５０がいずれの監視対象、所定期間および閾値を採用するかは、運用時間帯や、セッション制御サーバ１の負荷などに応じて、適宜設定されても良い。また、輻輳監視部５０は、監視対象のすべてのプロセスについて、（１）ないし（３）のうちのいずれか同じ監視対象、所定期間および閾値で輻輳状態を検出しても良い。輻輳監視部５０は、各プロセスについて、（１）ないし（３）のうちそれぞれ異なる監視対象、所定期間および閾値を予め設定し、その設定された監視対象、所定期間および閾値で各プロセスの輻輳状態を取得しても良い。
【００４２】
輻輳監視部５０は、各プロセスおよびサーバについて、定期的に輻輳状態を監視し、輻輳状態データ５１ａを生成し、輻輳状態記憶部５１に記憶する。輻輳状態データ５１ａは、図２に示すように、各プロセスの識別子と、そのプロセスの輻輳状態が関連づけられるとともに、サーバ全体の輻輳状態が含まれている。この輻輳状態は、例えば、各プロセスまたはサーバが、輻輳状態であるか否かのフラグである。輻輳監視部５０は、適宜輻輳状態データ５１ａを更新し、各プロセスおよびサーバの最新の輻輳状態を保持する。この輻輳状態データ５１ａは、受信処理部１０において、輻輳状態のプロセスを特定するとともに、受信した呼を拒否する応答信号を出力させるプロセスを特定するために参照される。
【００４３】
図３を参照して、本発明の実施の形態に係る輻輳監視部５０において、各プロセスの輻輳を検出する処理を説明する。ステップＳ１０１ないしＳ１０７の処理は、例えば一定時間おきに、または、何らかのイベントの発生により実行される。図３に示す例においては、監視対象の各プロセスについて、個別に輻輳監視方法が設定されている場合を説明する。
【００４４】
ステップＳ１０１ないしステップＳ１０６の処理は、各プロセスの輻輳状態を特定するプロセスである、図１に示す構成の場合、輻輳監視部５０は、受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０の輻輳状態を監視する。従って受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０が、輻輳監視部５０の輻輳判定対象となり、これらの各輻輳判定対象について、ステップＳ１０１ないしステップＳ１０７が繰り返される。ステップＳ１０１において、判定対象プロセスごとに設定される輻輳監視方法によって処理が振り分けられる。
【００４５】
まず、処理キューに積まれている処理数に応じてプロセスの輻輳を監視する場合、ステップＳ１０２に進む。ステップＳ１０２において輻輳監視部５０は、判定対象プロセスの監視対象である「処理キューに積まれている処理数」が、所定期間連続して閾値を超えたかを監視する。監視対象が所定期間連続して閾値を超えている場合、ステップＳ１０５において、この判定対象プロセスは輻輳状態であると判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。一方監視対象が所定期間連続して閾値を超えていない場合、ステップＳ１０６において輻輳監視部５０は、この判定対象プロセスは輻輳状態でないと判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。
【００４６】
プロセスのコア使用率に応じてプロセスの輻輳を監視する場合、ステップＳ１０３に進む。ステップＳ１０３において輻輳監視部５０は、判定対象プロセスの監視対象である「コア使用率」が、所定期間連続して閾値を超えたかを監視する。監視対象が所定期間連続して閾値を超えている場合、ステップＳ１０５において、この判定対象プロセスは輻輳状態であると判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。一方監視対象が所定期間連続して閾値を超えていない場合、ステップＳ１０６において輻輳監視部５０は、この判定対象プロセスは輻輳状態でないと判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。
【００４７】
処理キューに積まれている処理数およびプロセスのコア使用率に応じてプロセスの輻輳を監視する場合、ステップＳ１０４に進む。ステップＳ１０４において輻輳監視部５０は、判定対象プロセスの監視対象である「処理キューに積まれている処理数」と「コア使用率」がともに、所定期間連続して閾値を超えたかを監視する。これら監視対象が所定期間連続して閾値を超えている場合、ステップＳ１０５において、この判定対象プロセスは輻輳状態であると判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。一方これら監視対象が所定期間連続して閾値を超えていない場合、ステップＳ１０６において輻輳監視部５０は、この判定対象プロセスは輻輳状態でないと判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。
【００４８】
輻輳監視部５０のすべての判定対象プロセスについてステップＳ１０１ないしステップＳ１０７が繰り返されると、ステップＳ１０８に進み、一定時間スリープする。一定時間経過後、再びステップＳ１０１に戻り、輻輳監視部５０は、すべての判定対象プロセスについてステップＳ１０１ないしステップＳ１０７をそれぞれ繰り返す。
【００４９】
次に図４を参照して、セッション制御サーバ１において、発呼信号２を受信し、応答信号３を送信する処理を説明する。
【００５０】
まずステップＳ２０１において受信処理部１０は、発呼信号２を受信すると、ステップＳ２０２において自身のサーバ，およびサーバ内の複数のプロセスのいずれかが輻輳状態であるか否かを判定する。このとき、受信処理部１０は輻輳状態データ５１ａを参照して、各プロセスおよびサーバの輻輳状態を取得し、輻輳状態のサーバまたはプロセスがあるかを判定する。いずれも輻輳状態でない場合、ステップＳ２０６において受信処理部１０は、受信した発呼信号２を、後続プロセスである呼制御処理部にキューイングする。ステップＳ２０９において呼制御処理部は、キューから呼を取り出して処理し、応答信号３を送信する。
【００５１】
一方ステップＳ２０２において自身のサーバ，およびサーバ内の複数のプロセスのいずれかが輻輳状態であると判定された場合、ステップＳ２０３において、その輻輳状態の発生プロセスに基づいて処理が振り分けられる。
【００５２】
ステップＳ２０２において外部から入力された信号を処理するプロセスで輻輳状態が発生していると判定された場合、ステップＳ２０４に進む。本発明の実施の形態において「外部から入力された信号を処理するプロセス」は、図１の受信処理部１０である。受信処理部１０自身が輻輳状態である場合、ステップＳ２０４において受信処理部１０は、受信した呼を拒否するか否かを判定する。ここで受信処理部１０は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップＳ２０６に進み、ステップＳ２０９において呼が処理される。受信した呼を拒否する場合、ステップＳ２０７において受信処理部１０は、接続拒否を意味する処理を、後続プロセスである呼制御処理部にキューイングする。ステップＳ２１０において呼制御処理部は、拒否信号を生成して応答ソケットに書き込み、応答信号３を送信する。
【００５３】
一方、ステップＳ２０２において内部から処理がキューイングされるプロセスで輻輳状態が発生していると判定された場合、ステップＳ２０５に進む。本発明の実施の形態において「内部から処理がキューイングされるプロセス」は、図１の第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０である。第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０の少なくとも一つ以上が輻輳状態である場合、ステップＳ２０５において受信処理部１０は、受信した呼を拒否するか否かを判定する。ここで受信処理部１０は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップＳ２０６に進み、ステップＳ２０９において呼が処理される。受信した呼を拒否する場合、ステップＳ２０８において受信処理部１０は、ステップＳ２０８において拒否信号を生成して応答ソケットに書き込み、応答信号３を送信する。
【００５４】
ここで、外部から入力された信号を処理するプロセスで輻輳状態が発生する場合を図５に示す。この場合、内部から処理がキューイングされるプロセスが、処理を拒否する応答信号を出力する。受信処理部１０において輻輳状態が発生しているので、受信処理部１０は、拒否信号を送信する処理を、後続の第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれかにキューイングする。キューイングされた呼制御処理部は、拒否する意味の応答信号３を生成して、出力する。
【００５５】
内部から処理がキューイングされるプロセスで輻輳状態が発生する場合を図６に示す。この場合、外部から入力された信号を処理するプロセスが、処理を拒否する応答信号を出力する。第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のうちの少なくともいずれかで輻輳が発生している場合、受信処理部１０は、接続を拒否する意味の応答信号３を生成して、出力する。
【００５６】
ここで、外部から入力された信号を処理するプロセスおよび内部から処理がキューイングされるプロセスで、輻輳状態が発生する場合を図７に示す。この場合、外部から入力された信号を処理するプロセスが、処理を拒否する応答信号を出力する。図１に示す例では、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０が並列に処理している。従って、受信処理部１０で輻輳が発生するとともに、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０少なくともこのいずれかで輻輳が発生している場合、受信処理部１０は、接続を拒否する意味の応答信号３を生成して、出力する。例えば、受信処理部１０および第１の呼制御処理部２０で輻輳が発生している場合、受信処理部１０は、接続を拒否する意味の応答信号３を生成して、出力する。
【００５７】
本発明の最良の実施の形態に係るセッション制御サーバ１は、プロセス単位で輻輳を検出することができる。また、プロセス輻輳により発呼信号２を拒否する場合、プロセス輻輳が生じていないプロセスが、その応答信号３を出力する。これにより、輻輳の生じたプロセスの負荷を軽減しつつ、輻輳の生じていない、余裕のあるプロセスが応答信号３を出力することができる。
【００５８】
このように本発明の最良の実施の形態に係るセッション制御サーバ１によれば、マルチコアＣＰＵを搭載したコンピュータ上に構築された場合でも、複数プロセスを分散させるとともに、各プロセスの輻輳を制御ことができる。
【００５９】
また、従来はサーバ輻輳の状態の場合、発呼信号を受信した後、受信拒否ルートに入って処理されていたが、本発明の最良の実施の形態においては、プロセスの単位で輻輳状態を管理し、プロセスで輻輳が発生した場合、そのほかのプロセスで拒否信号を生成する。これにより、プロセス単位で輻輳が発し得していた場合でも、応答信号の送信速度を向上させ、セッション制御サーバ１全体で信号の意図しない取りこぼしの可能性を低減させることができる。
【００６０】
さらにこのように、信号の応答速度を向上させることにより、輻輳が発生しても、その輻輳が解消するまでの時間を短縮することができ、さらには、サービスの停止の可能性や劣化期間を低減することができる。
【００６１】
このように本発明の最良の実施の形態に係るセッション制御方法によれば、マルチコアＣＰＵを搭載したコンピュータ上で、並列して大量の処理を可能にしつつ、プロセス単位で輻輳を制御することができるので、良質なセッション制御を提供することができる。
【００６２】
（その他の実施の形態）
上記のように、本発明の最良の実施の形態によって記載したが、この開示の一部をなす論述および図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例および運用技術が明らかとなる。
【００６３】
本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【符号の説明】
【００６４】
１ セッション制御サーバ
２ 発呼信号
３ 応答信号
４ 応答信号
１０ 受信処理部
１１ 受信信号保存キュー
２０ 第１の呼制御処理部
２１、３１、４１ 呼制御処理保存キュー
３０ 第２の呼制御処理部
４０ 第３の呼制御処理部
【技術分野】
【０００１】
本発明は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法およびセッション制御サーバに関する。
【背景技術】
【０００２】
一般的に、電話通信システムなど、通信システムにおけるセッション制御システムにおいて、通信システムがその処理能力を超えて呼を受けると、通信システムの接続完了率が低下する状態に陥ってしまう。この状態は、輻輳と呼ばれる。輻輳の形態によって、企画型輻輳、災害型輻輳、サーバ輻輳の３つに分類される。企画型輻輳は、電話によるチケットの予約などにおいて、その予約開始時刻に呼が集中することによって、発生する。災害型輻輳は、災害が発生時などにおいて、住人の安否確認のための呼が集中することによって、発生する。
【０００３】
サーバ輻輳は、呼制御信号の集中やサーバリソースの逼迫により、呼処理能力が低下することによって、発生する。サーバリソースは、例えばサーバのＣＰＵやメモリであって、サーバリソースが故障などにより逼迫した場合に、サーバ輻輳が発生する。
【０００４】
輻輳状態になると、サーバの処理能力が低下したり、サーバダウンによるサービスの劣化や停止などが発生したりする。従って、通信システムにおけるセッション制御システムにおいて、輻輳を検出するとともに、輻輳を検出した際、サービスやシステム保護を目的として、その対処機能を備えている。この輻輳検出や、輻輳検出時の対処機能は、一般的に輻輳制御と呼ばれる。
【０００５】
例えば、一般的なサーバ輻輳を検出する方法として、サーバのＣＰＵ使用率が予め設定した閾値を越えているか否かを判定する方法がある。また、検出した輻輳を制御する方法として、サーバが輻輳状態である間、新たに呼を受信すると、輻輳状態であることを理由に意図的にその呼を拒否する方法がある。また電話システムにおいては呼には優先度があり、輻輳状態で拒否するべき呼を優先度に応じて選択する方法もある。ここで呼を拒否する場合、発信端末に呼を拒否する意味を持つ信号を送信する。サーバの負荷を可能な限り低減するため、受信直後に、通常の呼処理ルートから分岐し、信号拒否ルートにおいて、信号を拒否する方法が採られる。これにより、呼を受信したサーバは、輻輳時でも、サーバの信号処理量を低減しつつ、拒否する意味を持つ信号を送信することができる。
【０００６】
また、マルチコアＣＰＵを搭載したサーバが一般的となり、セッション制御システムにおいても、マルチコアＣＰＵを搭載したサーバで、セッション制御サーバが構築される傾向がある。マルチコアＣＰＵを搭載したセッション制御サーバは、複数のコアを有効活用するために、複数のプロセス（もしくはスレッド）に処理を分散させて、並列にその処理を実行する。分散方式の一例として、このセッション制御サーバが、発呼信号を受信する受信処理部と、受信処理部により取得された発呼信号に基づいて呼を処理する呼制御処理部を備える場合がある。
【０００７】
図８を参照して、このようなセッション制御サーバにおける呼の処理を説明する。
【０００８】
まずステップＳ９０１において受信処理部は、発呼信号を受信すると、ステップＳ９０２において自身のサーバが輻輳状態であるか否かを判定する。サーバが輻輳状態でない場合、ステップＳ９０４において受信処理部は、受信した呼を、後続プロセスである呼制御処理部にキューイングする。ステップＳ９０６において呼制御処理部は、キューから呼を取り出して処理し、応答信号を送信する。
【０００９】
一方ステップＳ９０２においてサーバが輻輳状態であると判断された場合、ステップＳ９０３において受信処理部は、受信した呼を拒否するか否かを判定する。ここで受信処理部は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップＳ９０４に進み、ステップＳ９０６において呼が処理される。受信した呼を拒否する場合、ステップＳ９０５において受信処理部は、拒否信号を生成して応答ソケットに書き込み、応答信号が送信される。
【００１０】
このように、セッション制御サーバにおいて、複数のプロセスがシーケンシャルに処理をすることによって、複数のコアを有効活用し、効率的に処理する方法が採られている。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特許第４２０８７０３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、マルチコアＣＰＵを搭載したセッション制御サーバにおいて、複数のプロセスに処理を分散させ、シーケンシャルに処理させる場合、各プロセスが一つの信号に対する処理量が異なる場合がある。これにより、一定時間内に処理可能な信号の数も、各プロセスによって異なる場合がある。
【００１３】
マルチコアＣＰＵ環境では、それぞれのプロセスが同時に並列して処理することができるので、大量の信号を処理することができる。しかし、その１信号の処理に要する時間がプロセスによって異なるため、処理の遅いプロセスのみ処理が滞り、輻輳状態になる場合がある。この場合、一部のプロセスのみ輻輳状態となる。このように一部のプロセスのみ輻輳状態のことを、本実施形態においてプロセス輻輳と称する。
【００１４】
このようなプロセス輻輳の状態では、サーバ全体では輻輳状態とは判定されない場合もある。具体的には、プロセス輻輳に陥っているプロセスは、コアを１００％使用している。しかし、処理の早いプロセスは処理量に余裕があり、その他のプロセス輻輳でないプロセスでは、コアを１００％使用することはない。
【００１５】
従来、サーバのＣＰＵの使用率が閾値を越えた場合に、サーバ輻輳が検出されるので、マルチコアＣＰＵのセッション制御サーバにおいては、すべてのコアの使用率の平均値に基づいてサーバ輻輳が検出されてしまう。従って、プロセス輻輳の状態では、個別のプロセスにおいて輻輳が発生していても、そのほかのプロセスでは輻輳状態ではないため、サーバ輻輳が検出されない場合がある。
【００１６】
これにより、呼の集中によりサーバ全体で呼の処理性能が低下しているにもかかわらず、その事象を検出することができない問題がある。
【００１７】
従って本発明の目的は、マルチコアを搭載し、複数のプロセスを同時に並列して処理する制御サーバにおいて、適切に輻輳を制御するセッションセッション制御方法およびセッション制御サーバを提供することである。
【課題を解決するための手段】
【００１８】
上記課題を解決するために、本発明の第１の特徴は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法に関する。すなわち本発明の第１の特徴に係るセッション制御方法は、複数のプロセスが、各プロセスの処理キューに蓄積されたキューを、順次並列に処理するステップと、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視するステップを備える。
【００１９】
ここで、輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。
【００２０】
また、外部から入力された信号を処理するプロセスが輻輳状態の場合、内部から処理がキューイングされるプロセスが処理を拒否する応答信号を出力するステップと、内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップと、外部から入力された信号を処理するプロセスおよび前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップをさらに備えても良い。
【００２１】
本発明の第２の特徴は、マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するセッション制御サーバに関する。すなわち本発明の第２の特徴に係るセッション制御サーバは、処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスを実現する複数の処理部と、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部を備える。
【００２２】
ここで、輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定しても良い。
【００２３】
また、プロセスは、外部から入力された信号を処理する受信処理部と、前記受信処理部から入力された信号を処理する呼制御処理部によって実現され、受信処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力し、呼制御処理部が輻輳状態の場合、前記受信処理部が処理を拒否する応答信号を出力し、受信処理部および前記呼制御処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力しても良い。
【発明の効果】
【００２４】
本発明によれば、マルチコアを搭載し、複数のプロセスを同時に並列して処理する制御サーバにおいて、適切に輻輳を制御するセッションセッション制御方法およびセッション制御サーバを提供することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施の形態に係るセッション制御サーバの機能ブロック図の一例である。
【図２】本発明の実施の形態に係る輻輳状態データのデータ構造とデータの一例を説明する図である。
【図３】本発明の実施の形態に係るセッション制御方法において、プロセス輻輳を検出する処理を説明するフローチャートである。
【図４】本発明の実施の形態に係るセッション制御方法を説明するフローチャートである。
【図５】本発明の実施の形態において、受信処理部において輻輳が発生した場合の処理を説明する図である。
【図６】本発明の実施の形態において、呼制御処理部において輻輳が発生した場合の処理を説明する図である。
【図７】本発明の実施の形態において、受信処理部および呼制御処理部において輻輳が発生した場合の処理を説明する図である。
【図８】従来のセッション制御方法を説明するフローチャートである。
【発明を実施するための形態】
【００２６】
次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。
【００２７】
本発明の実施の形態に係るセッション制御サーバ１は、コンピュータに所定の処理を実行するプログラムがインストールされて実現される。セッション制御サーバ１は特に、マルチコアを搭載し、複数のプロセスを同時に並列して処理することのできるコンピュータによって実現される。
【００２８】
図１に示すセッション制御サーバ１は、例えば電話システムなどにおいて、外部から入力された発呼信号２から応答信号３を出力する。
【００２９】
セッション制御サーバ１は、受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０および輻輳監視部５０を備える。受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０および輻輳監視部５０は、それぞれプロセスによって実現される。受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０、第３の呼制御処理部４０および輻輳監視部５０は、それぞれスレッドによって実現されても良い。本実施の形態において、プロセスは、一般的なプロセスとスレッドの意味を含むものとして説明する。ここで、図１に示す例において、セッション制御サーバ１が、３つの呼制御処理部を備える場合について説明するが、呼制御処理部の数は、1つでも４つ以上でも良い。
【００３０】
セッション制御サーバ１の複数のプロセスは、各プロセスの処理キューに蓄積されたキューを、順次並列に処理する。
【００３１】
受信処理部１０は、外部から入力された信号を処理するプロセスを実現する処理部である。受信処理部１０は、受信信号保存キュー１１を備える。セッション制御サーバ１が発呼信号２を受信すると、受信された発呼信号２は、受信信号保存キュー１１に蓄積され、受信処理部１０による処理を待機する。受信処理部１０は、受信信号保存キュー１１から一つずつ呼を取り出して、後続のプロセスのいずれかにキューイングする。ここで図１に示す例において受信処理部１０の後続のプロセスは、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０である。いずれのプロセスにキューイングするかは、所定の手順で決定される。
【００３２】
受信処理部１０から第１の呼制御処理部２０にキューイングされた呼は、第１の呼制御処理部２０の呼制御処理保存キュー２１に蓄積される。第１の呼制御処理部２０は、内部から処理がキューイングされるプロセスを実現する処理部である。第１の呼制御処理部２０は、呼制御処理保存キュー２１から一つずつ呼を取り出して所定の手順で処理し、応答信号３を出力する。
【００３３】
同様に、受信処理部１０から第２の呼制御処理部３０にキューイングされた呼は、第２の呼制御処理部３０の呼制御処理保存キュー３１に蓄積される。第２の呼制御処理部３０は、内部から処理がキューイングされるプロセスを実現する処理部である。第２の呼制御処理部３０は、呼制御処理保存キュー３１から一つずつ呼を取り出して所定の手順で処理し、応答信号３を出力する。受信処理部１０から第３の呼制御処理部４０にキューイングされた呼は、第３の呼制御処理部４０の呼制御処理保存キュー４１に蓄積される。第３の呼制御処理部４０は、内部から処理がキューイングされるプロセスを実現する処理部である。第３の呼制御処理部４０は、呼制御処理保存キュー４１から一つずつ呼を取り出して所定の手順で処理し、応答信号３を出力する。
【００３４】
受信処理部１０は、受信した呼を、後続のプロセスに引き渡すほか、輻輳により呼を拒否する場合、輻輳状態データ５１ａを参照して、受信処理部１０は、その拒否する応答信号を出力させるプロセスを特定する。ここで呼を拒否するか否かは、呼の優先度、信号種などにより、判断される。
【００３５】
受信処理部１０が輻輳状態の場合、受信処理部１０は、拒否応答信号を出力するプロセスとして、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれかを特定する。受信処理部１０は、特定されたプロセスに、拒否する応答信号を出力させる。第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれかが輻輳状態の場合、受信処理部１０は、拒否応答信号を出力するプロセスとして、受信処理部１０自身を特定する。受信処理部１０が処理を拒否する応答信号を出力する。受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれもが輻輳状態の場合、受信処理部１０は、拒否応答信号を出力するプロセスとして、受信処理部１０自身を特定する。受信処理部１０が処理を拒否する応答信号を出力する。
【００３６】
輻輳監視部５０は、セッション制御サーバ１の監視対象のプロセスについて、各プロセスが輻輳状態であるか否かを周期的に監視し、輻輳状態データ５１ａとして輻輳状態記憶部５１に記憶する。ここで、輻輳監視部５０の監視対象プロセスは、受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０の各プロセスである。輻輳監視部５０は、セッション制御サーバ１全体の輻輳状態を監視するとともに、これら各プロセスの輻輳状態を監視する。セッション制御サーバ１全体の輻輳状態は、サーバ全体のＣＰＵ使用率から判定される。
【００３７】
輻輳監視部５０が各プロセスの輻輳状態を監視する際、各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、輻輳状態であるか否かが判定される。輻輳監視部５０が、各プロセスの輻輳状態を監視する方法として、（１）プロセスのコア使用率を参照する方法、（２）プロセスの処理キューに蓄積された処理数を参照する方法および（３）プロセスのコア使用率およびプロセスの処理キューに蓄積された処理数を参照する方法が考えられる。輻輳監視部５０は、各プロセスの使用率または／および処理キューに蓄積された処理数を保持し、各プロセスの使用率または／および処理キューに蓄積された処理数が、所定期間閾値を超えた場合に、各プロセスが輻輳状態であると判定する。ここで、所定期間は、１周期でも良い。
【００３８】
（１）の場合、輻輳監視部５０は、監視対象のプロセスのコア使用率が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。輻輳監視部５０は、各プロセスについて、逐次コアの使用率を算出し、そのコア使用率のログを取得する。
【００３９】
（２）の場合、輻輳監視部５０は、監視対象のプロセスの処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。ここで、輻輳監視部５０は、各プロセスについて、逐次各プロセスの処理キューに蓄積された処理数のログを取得する。この処理キューは、各プロセスに対応づけられた処理キューである。図１に示す例において、受信処理部１０のプロセスについて、処理キューは、受信信号保存キュー１１に記憶された受信処理キューである。第１の呼制御処理部２０のプロセスについて、処理キューは、呼制御処理保存キュー２１に記憶された呼制御処理キューである。第２の呼制御処理部３０のプロセスについて、処理キューは、呼制御処理保存キュー３１に記憶された呼制御処理キューである。第３の呼制御処理部４０のプロセスについて、処理キューは、呼制御処理保存キュー４１に記憶された呼制御処理キューである。
【００４０】
（３）の場合、輻輳監視部５０は、監視対象のプロセスのコア使用率が、所定期間連続して閾値を超え、かつ、監視対象のプロセスの処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、監視対象のプロセスが輻輳状態であると判定する。輻輳監視部５０は、各プロセスの使用率および処理キューに蓄積された処理数がともに、所定期間閾値を超えたプロセスを、輻輳状態であると判定する。
【００４１】
輻輳監視部５０において、（１）ないし（３）のいずれかの輻輳監視対象、所定期間および閾値が、予め設定される。その設定に従って、輻輳監視部５０は、各プロセスの輻輳状態を監視する。また、輻輳監視部５０がいずれの監視対象、所定期間および閾値を採用するかは、運用時間帯や、セッション制御サーバ１の負荷などに応じて、適宜設定されても良い。また、輻輳監視部５０は、監視対象のすべてのプロセスについて、（１）ないし（３）のうちのいずれか同じ監視対象、所定期間および閾値で輻輳状態を検出しても良い。輻輳監視部５０は、各プロセスについて、（１）ないし（３）のうちそれぞれ異なる監視対象、所定期間および閾値を予め設定し、その設定された監視対象、所定期間および閾値で各プロセスの輻輳状態を取得しても良い。
【００４２】
輻輳監視部５０は、各プロセスおよびサーバについて、定期的に輻輳状態を監視し、輻輳状態データ５１ａを生成し、輻輳状態記憶部５１に記憶する。輻輳状態データ５１ａは、図２に示すように、各プロセスの識別子と、そのプロセスの輻輳状態が関連づけられるとともに、サーバ全体の輻輳状態が含まれている。この輻輳状態は、例えば、各プロセスまたはサーバが、輻輳状態であるか否かのフラグである。輻輳監視部５０は、適宜輻輳状態データ５１ａを更新し、各プロセスおよびサーバの最新の輻輳状態を保持する。この輻輳状態データ５１ａは、受信処理部１０において、輻輳状態のプロセスを特定するとともに、受信した呼を拒否する応答信号を出力させるプロセスを特定するために参照される。
【００４３】
図３を参照して、本発明の実施の形態に係る輻輳監視部５０において、各プロセスの輻輳を検出する処理を説明する。ステップＳ１０１ないしＳ１０７の処理は、例えば一定時間おきに、または、何らかのイベントの発生により実行される。図３に示す例においては、監視対象の各プロセスについて、個別に輻輳監視方法が設定されている場合を説明する。
【００４４】
ステップＳ１０１ないしステップＳ１０６の処理は、各プロセスの輻輳状態を特定するプロセスである、図１に示す構成の場合、輻輳監視部５０は、受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０の輻輳状態を監視する。従って受信処理部１０、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０が、輻輳監視部５０の輻輳判定対象となり、これらの各輻輳判定対象について、ステップＳ１０１ないしステップＳ１０７が繰り返される。ステップＳ１０１において、判定対象プロセスごとに設定される輻輳監視方法によって処理が振り分けられる。
【００４５】
まず、処理キューに積まれている処理数に応じてプロセスの輻輳を監視する場合、ステップＳ１０２に進む。ステップＳ１０２において輻輳監視部５０は、判定対象プロセスの監視対象である「処理キューに積まれている処理数」が、所定期間連続して閾値を超えたかを監視する。監視対象が所定期間連続して閾値を超えている場合、ステップＳ１０５において、この判定対象プロセスは輻輳状態であると判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。一方監視対象が所定期間連続して閾値を超えていない場合、ステップＳ１０６において輻輳監視部５０は、この判定対象プロセスは輻輳状態でないと判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。
【００４６】
プロセスのコア使用率に応じてプロセスの輻輳を監視する場合、ステップＳ１０３に進む。ステップＳ１０３において輻輳監視部５０は、判定対象プロセスの監視対象である「コア使用率」が、所定期間連続して閾値を超えたかを監視する。監視対象が所定期間連続して閾値を超えている場合、ステップＳ１０５において、この判定対象プロセスは輻輳状態であると判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。一方監視対象が所定期間連続して閾値を超えていない場合、ステップＳ１０６において輻輳監視部５０は、この判定対象プロセスは輻輳状態でないと判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。
【００４７】
処理キューに積まれている処理数およびプロセスのコア使用率に応じてプロセスの輻輳を監視する場合、ステップＳ１０４に進む。ステップＳ１０４において輻輳監視部５０は、判定対象プロセスの監視対象である「処理キューに積まれている処理数」と「コア使用率」がともに、所定期間連続して閾値を超えたかを監視する。これら監視対象が所定期間連続して閾値を超えている場合、ステップＳ１０５において、この判定対象プロセスは輻輳状態であると判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。一方これら監視対象が所定期間連続して閾値を超えていない場合、ステップＳ１０６において輻輳監視部５０は、この判定対象プロセスは輻輳状態でないと判定し、ステップＳ１０７において輻輳監視部５０は、その旨を輻輳状態データ５１ａに更新する。
【００４８】
輻輳監視部５０のすべての判定対象プロセスについてステップＳ１０１ないしステップＳ１０７が繰り返されると、ステップＳ１０８に進み、一定時間スリープする。一定時間経過後、再びステップＳ１０１に戻り、輻輳監視部５０は、すべての判定対象プロセスについてステップＳ１０１ないしステップＳ１０７をそれぞれ繰り返す。
【００４９】
次に図４を参照して、セッション制御サーバ１において、発呼信号２を受信し、応答信号３を送信する処理を説明する。
【００５０】
まずステップＳ２０１において受信処理部１０は、発呼信号２を受信すると、ステップＳ２０２において自身のサーバ，およびサーバ内の複数のプロセスのいずれかが輻輳状態であるか否かを判定する。このとき、受信処理部１０は輻輳状態データ５１ａを参照して、各プロセスおよびサーバの輻輳状態を取得し、輻輳状態のサーバまたはプロセスがあるかを判定する。いずれも輻輳状態でない場合、ステップＳ２０６において受信処理部１０は、受信した発呼信号２を、後続プロセスである呼制御処理部にキューイングする。ステップＳ２０９において呼制御処理部は、キューから呼を取り出して処理し、応答信号３を送信する。
【００５１】
一方ステップＳ２０２において自身のサーバ，およびサーバ内の複数のプロセスのいずれかが輻輳状態であると判定された場合、ステップＳ２０３において、その輻輳状態の発生プロセスに基づいて処理が振り分けられる。
【００５２】
ステップＳ２０２において外部から入力された信号を処理するプロセスで輻輳状態が発生していると判定された場合、ステップＳ２０４に進む。本発明の実施の形態において「外部から入力された信号を処理するプロセス」は、図１の受信処理部１０である。受信処理部１０自身が輻輳状態である場合、ステップＳ２０４において受信処理部１０は、受信した呼を拒否するか否かを判定する。ここで受信処理部１０は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップＳ２０６に進み、ステップＳ２０９において呼が処理される。受信した呼を拒否する場合、ステップＳ２０７において受信処理部１０は、接続拒否を意味する処理を、後続プロセスである呼制御処理部にキューイングする。ステップＳ２１０において呼制御処理部は、拒否信号を生成して応答ソケットに書き込み、応答信号３を送信する。
【００５３】
一方、ステップＳ２０２において内部から処理がキューイングされるプロセスで輻輳状態が発生していると判定された場合、ステップＳ２０５に進む。本発明の実施の形態において「内部から処理がキューイングされるプロセス」は、図１の第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０である。第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０の少なくとも一つ以上が輻輳状態である場合、ステップＳ２０５において受信処理部１０は、受信した呼を拒否するか否かを判定する。ここで受信処理部１０は、呼の優先度、信号種別などにより、この呼の接続を拒否するか否かを判定する。拒否しない場合、ステップＳ２０６に進み、ステップＳ２０９において呼が処理される。受信した呼を拒否する場合、ステップＳ２０８において受信処理部１０は、ステップＳ２０８において拒否信号を生成して応答ソケットに書き込み、応答信号３を送信する。
【００５４】
ここで、外部から入力された信号を処理するプロセスで輻輳状態が発生する場合を図５に示す。この場合、内部から処理がキューイングされるプロセスが、処理を拒否する応答信号を出力する。受信処理部１０において輻輳状態が発生しているので、受信処理部１０は、拒否信号を送信する処理を、後続の第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のいずれかにキューイングする。キューイングされた呼制御処理部は、拒否する意味の応答信号３を生成して、出力する。
【００５５】
内部から処理がキューイングされるプロセスで輻輳状態が発生する場合を図６に示す。この場合、外部から入力された信号を処理するプロセスが、処理を拒否する応答信号を出力する。第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０のうちの少なくともいずれかで輻輳が発生している場合、受信処理部１０は、接続を拒否する意味の応答信号３を生成して、出力する。
【００５６】
ここで、外部から入力された信号を処理するプロセスおよび内部から処理がキューイングされるプロセスで、輻輳状態が発生する場合を図７に示す。この場合、外部から入力された信号を処理するプロセスが、処理を拒否する応答信号を出力する。図１に示す例では、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０が並列に処理している。従って、受信処理部１０で輻輳が発生するとともに、第１の呼制御処理部２０、第２の呼制御処理部３０および第３の呼制御処理部４０少なくともこのいずれかで輻輳が発生している場合、受信処理部１０は、接続を拒否する意味の応答信号３を生成して、出力する。例えば、受信処理部１０および第１の呼制御処理部２０で輻輳が発生している場合、受信処理部１０は、接続を拒否する意味の応答信号３を生成して、出力する。
【００５７】
本発明の最良の実施の形態に係るセッション制御サーバ１は、プロセス単位で輻輳を検出することができる。また、プロセス輻輳により発呼信号２を拒否する場合、プロセス輻輳が生じていないプロセスが、その応答信号３を出力する。これにより、輻輳の生じたプロセスの負荷を軽減しつつ、輻輳の生じていない、余裕のあるプロセスが応答信号３を出力することができる。
【００５８】
このように本発明の最良の実施の形態に係るセッション制御サーバ１によれば、マルチコアＣＰＵを搭載したコンピュータ上に構築された場合でも、複数プロセスを分散させるとともに、各プロセスの輻輳を制御ことができる。
【００５９】
また、従来はサーバ輻輳の状態の場合、発呼信号を受信した後、受信拒否ルートに入って処理されていたが、本発明の最良の実施の形態においては、プロセスの単位で輻輳状態を管理し、プロセスで輻輳が発生した場合、そのほかのプロセスで拒否信号を生成する。これにより、プロセス単位で輻輳が発し得していた場合でも、応答信号の送信速度を向上させ、セッション制御サーバ１全体で信号の意図しない取りこぼしの可能性を低減させることができる。
【００６０】
さらにこのように、信号の応答速度を向上させることにより、輻輳が発生しても、その輻輳が解消するまでの時間を短縮することができ、さらには、サービスの停止の可能性や劣化期間を低減することができる。
【００６１】
このように本発明の最良の実施の形態に係るセッション制御方法によれば、マルチコアＣＰＵを搭載したコンピュータ上で、並列して大量の処理を可能にしつつ、プロセス単位で輻輳を制御することができるので、良質なセッション制御を提供することができる。
【００６２】
（その他の実施の形態）
上記のように、本発明の最良の実施の形態によって記載したが、この開示の一部をなす論述および図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例および運用技術が明らかとなる。
【００６３】
本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【符号の説明】
【００６４】
１ セッション制御サーバ
２ 発呼信号
３ 応答信号
４ 応答信号
１０ 受信処理部
１１ 受信信号保存キュー
２０ 第１の呼制御処理部
２１、３１、４１ 呼制御処理保存キュー
３０ 第２の呼制御処理部
４０ 第３の呼制御処理部
【特許請求の範囲】
【請求項１】
マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法であって、
複数のプロセスが、各プロセスの処理キューに蓄積されたキューを、順次並列に処理するステップと、
各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視するステップ
を備えることを特徴とするセッション制御方法。
【請求項２】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項１に記載のセッション制御方法。
【請求項３】
前記輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項１に記載のセッション制御方法。
【請求項４】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項１に記載のセッション制御方法。
【請求項５】
外部から入力された信号を処理するプロセスが輻輳状態の場合、内部から処理がキューイングされるプロセスが処理を拒否する応答信号を出力するステップと、
前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップと、
前記外部から入力された信号を処理するプロセスおよび前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップ
をさらに備えることを特徴とする請求項１ないし４のいずれか１項に記載のセッション制御方法。
【請求項６】
マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するセッション制御サーバであって、
処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスを実現する複数の処理部と、
各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部
を備えることを特徴とするセッション制御サーバ。
【請求項７】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項６に記載のセッション制御サーバ。
【請求項８】
前記輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項６に記載のセッション制御サーバ。
【請求項９】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項６に記載のセッション制御サーバ。
【請求項１０】
前記プロセスは、外部から入力された信号を処理する受信処理部と、前記受信処理部から入力された信号を処理する呼制御処理部によって実現され、
前記受信処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力し、
前記呼制御処理部が輻輳状態の場合、前記受信処理部が処理を拒否する応答信号を出力し、
前記受信処理部および前記呼制御処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力する
ことを特徴とする請求項６ないし９のいずれか１項に記載のセッション制御サーバ。
【請求項１】
マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するコンピュータにおけるセッション制御方法であって、
複数のプロセスが、各プロセスの処理キューに蓄積されたキューを、順次並列に処理するステップと、
各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視するステップ
を備えることを特徴とするセッション制御方法。
【請求項２】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項１に記載のセッション制御方法。
【請求項３】
前記輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項１に記載のセッション制御方法。
【請求項４】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項１に記載のセッション制御方法。
【請求項５】
外部から入力された信号を処理するプロセスが輻輳状態の場合、内部から処理がキューイングされるプロセスが処理を拒否する応答信号を出力するステップと、
前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップと、
前記外部から入力された信号を処理するプロセスおよび前記内部から処理がキューイングされるプロセスが輻輳状態の場合、前記外部から入力された信号を処理するプロセスが処理を拒否する応答信号を出力するステップ
をさらに備えることを特徴とする請求項１ないし４のいずれか１項に記載のセッション制御方法。
【請求項６】
マルチコアを搭載し、複数のプロセスを同時に並列して処理し、入力された発呼信号から応答信号を出力するセッション制御サーバであって、
処理キューに蓄積されたキューを、順次並列に処理する複数のプロセスを実現する複数の処理部と、
各プロセスのコア使用率と、当該プロセスの処理キューに蓄積された処理数と、のうち少なくともいずれかから、各プロセスの輻輳状態を監視する輻輳監視部
を備えることを特徴とするセッション制御サーバ。
【請求項７】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項６に記載のセッション制御サーバ。
【請求項８】
前記輻輳状態は、監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項６に記載のセッション制御サーバ。
【請求項９】
前記輻輳状態は、監視対象の前記プロセスのコア使用率が、所定期間連続して閾値を超え、かつ、当該監視対象の前記プロセスの前記処理キューに蓄積された処理数が、所定期間連続して閾値を超えた場合に、当該監視対象のプロセスが輻輳状態であると判定する
ことを特徴とする請求項６に記載のセッション制御サーバ。
【請求項１０】
前記プロセスは、外部から入力された信号を処理する受信処理部と、前記受信処理部から入力された信号を処理する呼制御処理部によって実現され、
前記受信処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力し、
前記呼制御処理部が輻輳状態の場合、前記受信処理部が処理を拒否する応答信号を出力し、
前記受信処理部および前記呼制御処理部が輻輳状態の場合、前記呼制御処理部が処理を拒否する応答信号を出力する
ことを特徴とする請求項６ないし９のいずれか１項に記載のセッション制御サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１７５２６６（Ｐ２０１２−１７５２６６Ａ）
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願番号】特願２０１１−３３５７４（Ｐ２０１１−３３５７４）
【出願日】平成２３年２月１８日（２０１１．２．１８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願日】平成２３年２月１８日（２０１１．２．１８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]