メッセージ処理システム、メッセージ処理装置及びメッセージ処理方法
【課題】ガベージコレクションに伴うシステム応答時間の悪化を回避することを目的とする。
【解決手段】メッセージを処理するアプリケーションが動作する複数のサーバで構成されたサーバクラスタを含むメッセージ処理システムは、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する振り分け装置を有し、前記サーバクラスタは、各サーバの状態を管理するサーバ状態管理部と、前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するメッセージ転送部と、を有する。
【解決手段】メッセージを処理するアプリケーションが動作する複数のサーバで構成されたサーバクラスタを含むメッセージ処理システムは、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する振り分け装置を有し、前記サーバクラスタは、各サーバの状態を管理するサーバ状態管理部と、前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するメッセージ転送部と、を有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージ処理システム、メッセージ処理装置及びメッセージ処理方法に関する。
【背景技術】
【０００２】
Ｊａｖａ言語のような一部のプログラミング言語では、メモリ管理の簡便化を目的として、メモリ解放を自動化するガベージコレクション（ＧＣ：Garbage Collection）が採用されている。ガベージコレクションは利便性の高い機能であるが、その反面、メモリの自動解放処理中にシステムが一時停止するなどの影響がある。
【０００３】
特許文献１では、メソッド内部でのみ利用されるオブジェクトをガベージコレクション対象外の領域に格納することにより、ガベージコレクションの影響を抑えようとしている。しかし、この方式ではメソッドをまたがって存在するようなオブジェクトが多く存在する場合には効果が得られない。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−７８７５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記のように、ガベージコレクションは、システムの一時停止などにより、システム応答時間に影響を及ぼす。電話サービスのように高品質なサービスが要求されるサーバにおいてガベージコレクションを適用すると、システムの一時停止によってサービス品質が低下する恐れがある。
【０００６】
本発明は、ガベージコレクションに伴うシステム応答時間の悪化を回避することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明のメッセージ処理システムは、
メッセージを処理するアプリケーションが動作する複数のサーバで構成されたサーバクラスタを含むメッセージ処理システムであって、
所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する振り分け装置を有し、
前記サーバクラスタは、
各サーバの状態を管理するサーバ状態管理部と、
前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するメッセージ転送部と、
を有することを特徴とする。
【０００８】
また、本発明のメッセージ処理装置は、
メッセージを処理する複数のアプリケーションが動作するメッセージ処理装置であって、
各アプリケーションの状態を管理するアプリケーション状態管理部と、
各アプリケーションの状態に応じて、受信したメッセージを転送するアプリケーションを決定するメッセージ転送部と、
を有することを特徴とする。
【０００９】
また、本発明のメッセージ処理方法は、
アプリケーションが動作する複数のサーバで構成されたサーバクラスタでメッセージを処理するメッセージ処理方法であって、
前記サーバクラスタの外部の振り分け装置により、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択するステップと、
前記サーバクラスタにより、各サーバの状態を管理するステップと、
前記サーバクラスタにより、前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するステップと、
を有することを特徴とする。
【発明の効果】
【００１０】
本発明の実施例によれば、システム応答時間を改善することが可能になる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施例に係るシステムの全体構成を示す図
【図２】本発明の実施例に係るサーバクラスタの構成を示す図
【図３】図２に示す振り分け機能部及びクラスタ機能部を詳細に示す図
【図４】本発明の実施例に係る動作シーケンスを示す図（ガベージコレクションが発生していない場合）
【図５】本発明の実施例に係る動作シーケンスを示す図（ガベージコレクションが発生している場合）
【図６】本発明の変形例に係るサーバの構成を示す図
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の実施例について説明する。
【００１３】
本発明の実施例では、ガベージコレクションを採用した複数のサーバで構成されたサーバクラスタを含むシステムについて説明する。他サーバ又は端末などの対向装置からのメッセージは、サーバクラスタの各サーバにより処理される。
【００１４】
このため、本実施例のシステムは、メッセージをサーバクラスタの各サーバに振り分ける振り分け装置（ロードバランサ）を含む。ロードバランサは、対向装置からメッセージを受信し、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する。
【００１５】
ガベージコレクションの発生状況は、ガベージコレクションの影響を受けない外部機能（クラスタ機能部）によって管理されており、ガベージコレクションの発生状況のようなサーバの状態に応じて、受信したメッセージは、適切なサーバのアプリケーションに転送される。例えば、ロードバランサで選択された振り分け先のサーバでガベージコレクションが発生している場合に、クラスタ機能部は、ガベージコレクションの発生していないサーバにメッセージを転送する。
【００１６】
このようにして、ロードバランサに負荷を集中させることなく、ガベージコレクションに伴う応答時間の悪化を回避することができる。
【００１７】
＜システムの全体構成＞
図１は、本発明の実施例に係るシステムの全体構成を示す図である。本実施例のシステムは、サーバクラスタ１００と、対向装置６００とを有する。サーバクラスタ１００は、ＩＰ（Internet Protocol）ネットワーク５００のような通信網を介して、他サーバ６１０や端末６２０のような対向装置６００に対してサービスを提供する。
【００１８】
具体的には、サーバクラスタ１００は、ロードバランサ２００と、サーバ群３００と、プラットフォーム管理装置４００とで構成される。
【００１９】
ロードバランサ２００は、他サーバ６１０及び端末６２０からのメッセージを各サーバに振り分ける装置である。なお、メッセージとは、サーバ３００上のアプリケーションで処理される対向装置６００からの信号であり、例えば、対向装置６００から送信されたリクエストと、各サーバ３００からのリクエストに対して対向装置６００から送信されたレスポンスとを含む。
【００２０】
各サーバ３００上では、メッセージを処理するアプリケーションが動作している。各サーバ３００には、ガベージコレクションが採用されており、アプリケーションが動的に確保したメモリ領域のうち、不要になった領域は自動的に解放される。
【００２１】
プラットフォーム管理装置４００は、サーバクラスタ１００を管理する装置である。プラットフォーム管理装置４００は、保守ネットワーク７００に接続されており、保守者はプラットフォーム管理装置４００を利用してサーバクラスタの管理を行うことができる。
【００２２】
＜サーバクラスタの構成＞
図２は、本発明の実施例に係るサーバクラスタ１００の構成を示す図である。前述のようにサーバクラスタ１００には、ロードバランサ２００とサーバ群３００とが含まれる。
【００２３】
具体的には、ロードバランサ２００は、振り分け機能部２１０を有する。対向装置６００は、振り分け機能部２１０がオープンするＵＤＰ（User Datagram Protocol）ポート又はＴＣＰ（Transmission Control Protocol）ポートをサーバクラスタ１００への宛先ポートとして認識している。振り分け機能部２１０は、対向装置６００から送信されたメッセージを受信し、サーバ群３００に振り分ける。例えば、対向装置６００から送信されるＨＴＴＰ（Hypertext Transfer Protocol）又はＳＩＰ（Session Initiation Protocol）のリクエストや、各サーバ３００からのリクエストに対する応答メッセージは、ロードバランサ２００上の振り分け機能部２１０で受信され、サーバ群３００に振り分けられる。
【００２４】
サーバ３００は、クラスタ機能部３１０によってサーバクラスタを構成している。各サーバ３００では、ＪａｖａＶＭ（Java Virtual Machine）３２０上で動作するアプリケーション３３０が稼働している。ＪａｖａＶＭ３２０とは、Ｊａｖａアプリケーション３３０を実行する環境を提供するソフトウェアであり、ガベージコレクションは、ＪａｖａＶＭ３２０上で発生する。アプリケーション３３０は、振り分け機能部２１０及びクラスタ機能部３１０を介して、対向装置６００からのメッセージを受信する。クラスタ機能部３１０は、ＪａｖａＶＭ３２０上に実装しないこととする。このため、クラスタ機能部３１０においてガベージコレクションは発生しない。アプリケーション３３０がクラスタ機能部３１０と連携して動作するために、アプリケーション３３０は、ＪＮＩ（Java Native Interface)又はＲＰＣ（Remote Procedure Call）などを利用して、ＪａｖａＶＭ３２０の外部の機能を呼び出してもよい。
【００２５】
図３は、振り分け機能部２１０とクラスタ機能部３１０とを詳細に示す図である。
【００２６】
振り分け機能部２１０は、振り分け先制御部２１１を有する。振り分け先制御部２１１は、所定の規則に基づいて、対向装置６００から受信したメッセージ（ＩＰパケット）をサーバクラスタ１００の各サーバ３００に振り分ける。例えば、振り分け先制御部２１１は、ラウンドロビン、重み付けラウンドロビン、又は負荷の少ないサーバ３００を選択する方法などに基づいて、受信したメッセージの振り分け先のサーバを選択する。
【００２７】
クラスタ機能部３１０は、メッセージ転送部３１１とサーバ状態管理部３１２とを有する。
【００２８】
サーバ状態管理部３１２は、プラットフォーム管理装置４００からクラスタ構成の設定に関する情報を受信すると共に、各サーバ３００の状態を管理する。サーバ状態管理部３１２は、プラットフォーム管理装置４００から、例えば、サーバクラスタが何台のサーバで構成されているか、どのサーバがメッセージ処理に利用可能であるかなどを受信する。また、サーバ状態管理部３１２は、各サーバ３００の状態として、例えば、アプリケーション３３０の死活状態及び障害発生状況、サーバ３００の負荷状態、ＪａｖａＶＭ３２０のＧＣ状態などを管理する。ＧＣ状態とは、ガベージコレクションによるアプリケーション３３０の稼働・停止状態を示すデータである。ＧＣ状態の取得は、ＪａｖａＶＭ３２０が提供するＪＶＭＴＩ（Java Virtual Machine Tool Interface）によって取得可能である。
【００２９】
メッセージ転送部３１１は、振り分け機能部２１０で選択されたサーバの状態に応じて、メッセージを実際に転送するサーバを決定し、メッセージをアプリケーション３３０に転送する。例えば、振り分け機能部２１０で選択されたサーバでガベージコレクションが発生している場合、メッセージ転送部３１１は、他のサーバにメッセージを転送する。また、アプリケーション３３０のプロセスが停止している場合、アプリケーション３３０に障害が発生している場合、メモリの利用率が予め設定しておいた閾値をオーバーした場合、又はサーバ３００の負荷が高い場合にも、メッセージ転送部３１１は、他のサーバにメッセージを転送してもよい。メッセージ転送先のサーバは、サーバ状態管理部３１２を参照して決定されてもよい。例えば、メッセージ転送先のサーバは、ガベージコレクションが発生していないサーバでもよく、予め決められた予備のサーバでもよく、負荷の少ないサーバでもよい。
【００３０】
また、メッセージ転送部３１１は、メッセージ処理結果のような信号を対向装置６００に返信する。対向装置６００とサーバクラスタ１００が信号を送受信する場合、実際にアプリケーション３３０の処理を実行しているのは分散されたサーバ３００上であるが、対向装置６００にはロードバランサ２００上の振り分け機能部２１０と信号をやりとりしているように見せる。このようにして、内部サーバ構成が隠蔽される。従って、各サーバ３００上のアプリケーション３３０が信号を送信する場合も、対向装置６００に対して直接ＩＰパケットを送信するのではなく、メッセージ転送部３１１及び振り分け機能部２１０を介して信号を送信する。
【００３１】
＜サーバクラスタの動作シーケンス＞
図４及び図５は本発明の実施例に係る動作シーケンスを示す図である。
【００３２】
図４は、振り分け機能部２１０で選択されたサーバ（１）３００でガベージコレクションが発生していない場合に相当する。対向装置６００からメッセージを受信すると、振り分け機能部２１０（振り分け先制御部２１１）は、所定の規則に基づいて振り分け先のサーバ（１）３００を選択し、受信したメッセージを振り分け先のサーバ（１）３００上のメッセージ転送部３１１に転送する（Ｓ４０１）。メッセージ転送部３１１は、自サーバ（１）のサーバ状態管理部３１２にアプリケーション３３０の状態を問い合わせる（Ｓ４０２）。サーバ状態管理部３１２から特に問題がないとの応答が返ってきた場合（Ｓ４０３）、メッセージ転送部３１１は、アプリケーション３３０にメッセージを渡して動作を開始させる。アプリケーション３３０が処理の結果として対向装置６００へのメッセージの送信を要求する場合（Ｓ４０５）、メッセージ転送部３１１は、振り分け機能部２１０を介してメッセージを対向装置６００へ送信する（Ｓ４０６）。
【００３３】
図５は、振り分け機能部２１０で選択されたサーバ（１）でガベージコレクションが発生している場合に相当する。サーバ（１）上のＪａｖａＶＭ３２０がガベージコレクションを開始すると、アプリケーション３３０の動作が一時停止する。このように、ガベージコレクションが発生すると、サーバ（１）のサーバ状態管理部３１２はＧＣ発生イベントを受信する（Ｓ５０１）。この状態で振り分け機能部２１０（振り分け先制御部２１１）が対向装置６００からメッセージを受信し、振り分け先のサーバ３００としてサーバ（１）３００を選択すると、受信したメッセージは、振り分け先のサーバ（１）３００上のメッセージ転送部３１１に転送される（Ｓ５０２）。メッセージ転送部３１１は、自サーバ（１）のサーバ状態管理部３１２にアプリケーション３３０の状態を問い合わせると（Ｓ５０３）、サーバ状態管理部３１２から「ＧＣ実施中」との応答を受ける（Ｓ５０４）。従って、メッセージ転送部３１１は、予め決められたサーバ３００の中から転送先のサーバ（２）３００を決定し、メッセージを転送する（Ｓ５０５）。メッセージを受信した転送先のサーバ（２）３００では、メッセージ転送部３１１がメッセージを受信し、アプリケーション３３０にメッセージを渡す（Ｓ５０６）。アプリケーション３３０が対向装置６００への信号の送信を要求する場合（Ｓ５０７）、メッセージ転送部３１１は、転送元のメッセージ転送部３１１及び振り分け機能部２１０を介して対向装置６００へ信号を送信する（Ｓ５０８、Ｓ５０９）。
【００３４】
＜変形例＞
本発明の概念は、サーバクラスタだけではなく、単一サーバによるシステムにおいても適用可能である。図６は、本発明の概念を単一サーバに適用した場合の変形例に係るサーバの構成を示す図である。
【００３５】
図６に示すように、サーバ３００上に同一のアプリケーション３３０を複数起動し、クラスタ機能部３１０でそれぞれのアプリケーション３３０の状態を監視させる。この場合も同様に、クラスタ機能部３１０は、ＪａｖａＶＭ３２０上に実装しないこととする。このため、クラスタ機能部３１０においてガベージコレクションは発生しない。
【００３６】
ＪａｖａＶＭ３２０のガベージコレクションなどによってアプリケーション３３０が停止した場合には、クラスタ機能部３１０が他のアプリケーション３３０にメッセージを転送する。例えば、他のＪａｖａＶＭ３２０のプロセスにメッセージをサーバ３００内部で振り分けてもよい。このようにして、ガベージコレクションによる影響を回避することができる。
【００３７】
クラスタ機能部３１０は、基本的にはラウンドロビンなどの所定の規則に基づいて、メッセージを振り分け、ガベージコレクションが発生している場合には、ガベージコレクション発生中のＪａｖａＶＭ３２０を避けて振り分けてもよい。また、クラスタ機能部３１０は、通常時はメッセージを振り分けない予備のアプリケーション３３０を起動させておき、メッセージを処理しているアプリケーション３３０でガベージコレクションが発生した場合に、予備のアプリケーション３３０に振り分けてもよい。
【００３８】
具体的には、クラスタ機能部３１０は、図３に示すように、メッセージ転送部３１１とサーバ状態管理部３１２とを有する。
【００３９】
サーバ状態管理部３１２は、各アプリケーションの状態を管理する。例えば、サーバ状態管理部３１２は、前述のようにＪＶＭＴＩを利用したＧＣ発生イベントを管理してもよく、更に、ＪＭＸ（Java Management Extensions）によるＪａｖａＶＭ３２０のメモリ利用状況の統計データ、アプリケーション３３０における例外の発生状況、アプリケーション３３０のプロセスの死活状態なども管理してもよい。
【００４０】
メッセージ転送部３１１は、アプリケーションの状態に応じて、メッセージを実際に転送するアプリケーション３３０を決定し、メッセージをアプリケーション３３０に転送する。例えば、前述のように、ガベージコレクションによりアプリケーション３３０が一時停止している場合、メッセージ転送部３１１は、他のアプリケーション３３０にメッセージを転送する。また、例えば、ガベージコレクションは発生していないが、アプリケーション３３０の不具合によってメモリの利用率が予め設定しておいた閾値をオーバーした場合などを停止イベントとして、ＧＣイベント発生時と同様に他のアプリケーション３３０にメッセージを転送してもよい。このように、アプリケーション３３０が異常動作を行った場合においてもサービスの継続が可能となる。
【００４１】
＜実施例の効果＞
前述の通り、本発明の実施例では、ガベージコレクションを採用したサーバクラスタシステムにおいて、ガベージコレクションの影響を受けないクラスタ機能３１０をアプリケーション３３０の前段に配備し、ガベージコレクションが発生して停止しているアプリケーション３３０を避けてメッセージが処理される。このため、ガベージコレクションによる影響を抑制することが可能となる。ガベージコレクションなどにより、アプリケーションが一時的に利用不可能になった場合にも、システムの応答時間を改善することができる。
【００４２】
また、ロードバランサ２００がガベージコレクションの発生などを意識する必要が無く、ラウンドロビンのような単純な振り分け方法でメッセージを振り分けることができるため、ロードバランサ２００が性能上のボトルネックとなることを避けることができる。
【００４３】
以上、本発明の実施例について説明したが、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。
【００４４】
説明の便宜上、本発明の実施例に係るシステムは機能的なブロック図を用いて説明しているが、本発明のシステムは、ハードウエア、ソフトウェア又はそれらの組み合わせで実現されてもよい。また、２以上の実施例又は変形例が必要に応じて組み合わせて使用されてもよい。
【符号の説明】
【００４５】
１００ サーバクラスタ
２００ ロードバランサ
２１０ 振り分け機能部
２１１ 振り分け先制御部
３００ サーバ
３１０ クラスタ機能部
３１１ メッセージ転送部
３１２ サーバ状態管理部
３２０ ＪａｖａＶＭ
３３０ アプリケーション
４００ プラットフォーム管理装置
５００ ＩＰネットワーク
６００ 対向装置
７００ 保守ネットワーク
【技術分野】
【０００１】
本発明は、メッセージ処理システム、メッセージ処理装置及びメッセージ処理方法に関する。
【背景技術】
【０００２】
Ｊａｖａ言語のような一部のプログラミング言語では、メモリ管理の簡便化を目的として、メモリ解放を自動化するガベージコレクション（ＧＣ：Garbage Collection）が採用されている。ガベージコレクションは利便性の高い機能であるが、その反面、メモリの自動解放処理中にシステムが一時停止するなどの影響がある。
【０００３】
特許文献１では、メソッド内部でのみ利用されるオブジェクトをガベージコレクション対象外の領域に格納することにより、ガベージコレクションの影響を抑えようとしている。しかし、この方式ではメソッドをまたがって存在するようなオブジェクトが多く存在する場合には効果が得られない。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−７８７５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記のように、ガベージコレクションは、システムの一時停止などにより、システム応答時間に影響を及ぼす。電話サービスのように高品質なサービスが要求されるサーバにおいてガベージコレクションを適用すると、システムの一時停止によってサービス品質が低下する恐れがある。
【０００６】
本発明は、ガベージコレクションに伴うシステム応答時間の悪化を回避することを目的とする。
【課題を解決するための手段】
【０００７】
上記の課題を解決するため、本発明のメッセージ処理システムは、
メッセージを処理するアプリケーションが動作する複数のサーバで構成されたサーバクラスタを含むメッセージ処理システムであって、
所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する振り分け装置を有し、
前記サーバクラスタは、
各サーバの状態を管理するサーバ状態管理部と、
前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するメッセージ転送部と、
を有することを特徴とする。
【０００８】
また、本発明のメッセージ処理装置は、
メッセージを処理する複数のアプリケーションが動作するメッセージ処理装置であって、
各アプリケーションの状態を管理するアプリケーション状態管理部と、
各アプリケーションの状態に応じて、受信したメッセージを転送するアプリケーションを決定するメッセージ転送部と、
を有することを特徴とする。
【０００９】
また、本発明のメッセージ処理方法は、
アプリケーションが動作する複数のサーバで構成されたサーバクラスタでメッセージを処理するメッセージ処理方法であって、
前記サーバクラスタの外部の振り分け装置により、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択するステップと、
前記サーバクラスタにより、各サーバの状態を管理するステップと、
前記サーバクラスタにより、前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するステップと、
を有することを特徴とする。
【発明の効果】
【００１０】
本発明の実施例によれば、システム応答時間を改善することが可能になる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施例に係るシステムの全体構成を示す図
【図２】本発明の実施例に係るサーバクラスタの構成を示す図
【図３】図２に示す振り分け機能部及びクラスタ機能部を詳細に示す図
【図４】本発明の実施例に係る動作シーケンスを示す図（ガベージコレクションが発生していない場合）
【図５】本発明の実施例に係る動作シーケンスを示す図（ガベージコレクションが発生している場合）
【図６】本発明の変形例に係るサーバの構成を示す図
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の実施例について説明する。
【００１３】
本発明の実施例では、ガベージコレクションを採用した複数のサーバで構成されたサーバクラスタを含むシステムについて説明する。他サーバ又は端末などの対向装置からのメッセージは、サーバクラスタの各サーバにより処理される。
【００１４】
このため、本実施例のシステムは、メッセージをサーバクラスタの各サーバに振り分ける振り分け装置（ロードバランサ）を含む。ロードバランサは、対向装置からメッセージを受信し、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する。
【００１５】
ガベージコレクションの発生状況は、ガベージコレクションの影響を受けない外部機能（クラスタ機能部）によって管理されており、ガベージコレクションの発生状況のようなサーバの状態に応じて、受信したメッセージは、適切なサーバのアプリケーションに転送される。例えば、ロードバランサで選択された振り分け先のサーバでガベージコレクションが発生している場合に、クラスタ機能部は、ガベージコレクションの発生していないサーバにメッセージを転送する。
【００１６】
このようにして、ロードバランサに負荷を集中させることなく、ガベージコレクションに伴う応答時間の悪化を回避することができる。
【００１７】
＜システムの全体構成＞
図１は、本発明の実施例に係るシステムの全体構成を示す図である。本実施例のシステムは、サーバクラスタ１００と、対向装置６００とを有する。サーバクラスタ１００は、ＩＰ（Internet Protocol）ネットワーク５００のような通信網を介して、他サーバ６１０や端末６２０のような対向装置６００に対してサービスを提供する。
【００１８】
具体的には、サーバクラスタ１００は、ロードバランサ２００と、サーバ群３００と、プラットフォーム管理装置４００とで構成される。
【００１９】
ロードバランサ２００は、他サーバ６１０及び端末６２０からのメッセージを各サーバに振り分ける装置である。なお、メッセージとは、サーバ３００上のアプリケーションで処理される対向装置６００からの信号であり、例えば、対向装置６００から送信されたリクエストと、各サーバ３００からのリクエストに対して対向装置６００から送信されたレスポンスとを含む。
【００２０】
各サーバ３００上では、メッセージを処理するアプリケーションが動作している。各サーバ３００には、ガベージコレクションが採用されており、アプリケーションが動的に確保したメモリ領域のうち、不要になった領域は自動的に解放される。
【００２１】
プラットフォーム管理装置４００は、サーバクラスタ１００を管理する装置である。プラットフォーム管理装置４００は、保守ネットワーク７００に接続されており、保守者はプラットフォーム管理装置４００を利用してサーバクラスタの管理を行うことができる。
【００２２】
＜サーバクラスタの構成＞
図２は、本発明の実施例に係るサーバクラスタ１００の構成を示す図である。前述のようにサーバクラスタ１００には、ロードバランサ２００とサーバ群３００とが含まれる。
【００２３】
具体的には、ロードバランサ２００は、振り分け機能部２１０を有する。対向装置６００は、振り分け機能部２１０がオープンするＵＤＰ（User Datagram Protocol）ポート又はＴＣＰ（Transmission Control Protocol）ポートをサーバクラスタ１００への宛先ポートとして認識している。振り分け機能部２１０は、対向装置６００から送信されたメッセージを受信し、サーバ群３００に振り分ける。例えば、対向装置６００から送信されるＨＴＴＰ（Hypertext Transfer Protocol）又はＳＩＰ（Session Initiation Protocol）のリクエストや、各サーバ３００からのリクエストに対する応答メッセージは、ロードバランサ２００上の振り分け機能部２１０で受信され、サーバ群３００に振り分けられる。
【００２４】
サーバ３００は、クラスタ機能部３１０によってサーバクラスタを構成している。各サーバ３００では、ＪａｖａＶＭ（Java Virtual Machine）３２０上で動作するアプリケーション３３０が稼働している。ＪａｖａＶＭ３２０とは、Ｊａｖａアプリケーション３３０を実行する環境を提供するソフトウェアであり、ガベージコレクションは、ＪａｖａＶＭ３２０上で発生する。アプリケーション３３０は、振り分け機能部２１０及びクラスタ機能部３１０を介して、対向装置６００からのメッセージを受信する。クラスタ機能部３１０は、ＪａｖａＶＭ３２０上に実装しないこととする。このため、クラスタ機能部３１０においてガベージコレクションは発生しない。アプリケーション３３０がクラスタ機能部３１０と連携して動作するために、アプリケーション３３０は、ＪＮＩ（Java Native Interface)又はＲＰＣ（Remote Procedure Call）などを利用して、ＪａｖａＶＭ３２０の外部の機能を呼び出してもよい。
【００２５】
図３は、振り分け機能部２１０とクラスタ機能部３１０とを詳細に示す図である。
【００２６】
振り分け機能部２１０は、振り分け先制御部２１１を有する。振り分け先制御部２１１は、所定の規則に基づいて、対向装置６００から受信したメッセージ（ＩＰパケット）をサーバクラスタ１００の各サーバ３００に振り分ける。例えば、振り分け先制御部２１１は、ラウンドロビン、重み付けラウンドロビン、又は負荷の少ないサーバ３００を選択する方法などに基づいて、受信したメッセージの振り分け先のサーバを選択する。
【００２７】
クラスタ機能部３１０は、メッセージ転送部３１１とサーバ状態管理部３１２とを有する。
【００２８】
サーバ状態管理部３１２は、プラットフォーム管理装置４００からクラスタ構成の設定に関する情報を受信すると共に、各サーバ３００の状態を管理する。サーバ状態管理部３１２は、プラットフォーム管理装置４００から、例えば、サーバクラスタが何台のサーバで構成されているか、どのサーバがメッセージ処理に利用可能であるかなどを受信する。また、サーバ状態管理部３１２は、各サーバ３００の状態として、例えば、アプリケーション３３０の死活状態及び障害発生状況、サーバ３００の負荷状態、ＪａｖａＶＭ３２０のＧＣ状態などを管理する。ＧＣ状態とは、ガベージコレクションによるアプリケーション３３０の稼働・停止状態を示すデータである。ＧＣ状態の取得は、ＪａｖａＶＭ３２０が提供するＪＶＭＴＩ（Java Virtual Machine Tool Interface）によって取得可能である。
【００２９】
メッセージ転送部３１１は、振り分け機能部２１０で選択されたサーバの状態に応じて、メッセージを実際に転送するサーバを決定し、メッセージをアプリケーション３３０に転送する。例えば、振り分け機能部２１０で選択されたサーバでガベージコレクションが発生している場合、メッセージ転送部３１１は、他のサーバにメッセージを転送する。また、アプリケーション３３０のプロセスが停止している場合、アプリケーション３３０に障害が発生している場合、メモリの利用率が予め設定しておいた閾値をオーバーした場合、又はサーバ３００の負荷が高い場合にも、メッセージ転送部３１１は、他のサーバにメッセージを転送してもよい。メッセージ転送先のサーバは、サーバ状態管理部３１２を参照して決定されてもよい。例えば、メッセージ転送先のサーバは、ガベージコレクションが発生していないサーバでもよく、予め決められた予備のサーバでもよく、負荷の少ないサーバでもよい。
【００３０】
また、メッセージ転送部３１１は、メッセージ処理結果のような信号を対向装置６００に返信する。対向装置６００とサーバクラスタ１００が信号を送受信する場合、実際にアプリケーション３３０の処理を実行しているのは分散されたサーバ３００上であるが、対向装置６００にはロードバランサ２００上の振り分け機能部２１０と信号をやりとりしているように見せる。このようにして、内部サーバ構成が隠蔽される。従って、各サーバ３００上のアプリケーション３３０が信号を送信する場合も、対向装置６００に対して直接ＩＰパケットを送信するのではなく、メッセージ転送部３１１及び振り分け機能部２１０を介して信号を送信する。
【００３１】
＜サーバクラスタの動作シーケンス＞
図４及び図５は本発明の実施例に係る動作シーケンスを示す図である。
【００３２】
図４は、振り分け機能部２１０で選択されたサーバ（１）３００でガベージコレクションが発生していない場合に相当する。対向装置６００からメッセージを受信すると、振り分け機能部２１０（振り分け先制御部２１１）は、所定の規則に基づいて振り分け先のサーバ（１）３００を選択し、受信したメッセージを振り分け先のサーバ（１）３００上のメッセージ転送部３１１に転送する（Ｓ４０１）。メッセージ転送部３１１は、自サーバ（１）のサーバ状態管理部３１２にアプリケーション３３０の状態を問い合わせる（Ｓ４０２）。サーバ状態管理部３１２から特に問題がないとの応答が返ってきた場合（Ｓ４０３）、メッセージ転送部３１１は、アプリケーション３３０にメッセージを渡して動作を開始させる。アプリケーション３３０が処理の結果として対向装置６００へのメッセージの送信を要求する場合（Ｓ４０５）、メッセージ転送部３１１は、振り分け機能部２１０を介してメッセージを対向装置６００へ送信する（Ｓ４０６）。
【００３３】
図５は、振り分け機能部２１０で選択されたサーバ（１）でガベージコレクションが発生している場合に相当する。サーバ（１）上のＪａｖａＶＭ３２０がガベージコレクションを開始すると、アプリケーション３３０の動作が一時停止する。このように、ガベージコレクションが発生すると、サーバ（１）のサーバ状態管理部３１２はＧＣ発生イベントを受信する（Ｓ５０１）。この状態で振り分け機能部２１０（振り分け先制御部２１１）が対向装置６００からメッセージを受信し、振り分け先のサーバ３００としてサーバ（１）３００を選択すると、受信したメッセージは、振り分け先のサーバ（１）３００上のメッセージ転送部３１１に転送される（Ｓ５０２）。メッセージ転送部３１１は、自サーバ（１）のサーバ状態管理部３１２にアプリケーション３３０の状態を問い合わせると（Ｓ５０３）、サーバ状態管理部３１２から「ＧＣ実施中」との応答を受ける（Ｓ５０４）。従って、メッセージ転送部３１１は、予め決められたサーバ３００の中から転送先のサーバ（２）３００を決定し、メッセージを転送する（Ｓ５０５）。メッセージを受信した転送先のサーバ（２）３００では、メッセージ転送部３１１がメッセージを受信し、アプリケーション３３０にメッセージを渡す（Ｓ５０６）。アプリケーション３３０が対向装置６００への信号の送信を要求する場合（Ｓ５０７）、メッセージ転送部３１１は、転送元のメッセージ転送部３１１及び振り分け機能部２１０を介して対向装置６００へ信号を送信する（Ｓ５０８、Ｓ５０９）。
【００３４】
＜変形例＞
本発明の概念は、サーバクラスタだけではなく、単一サーバによるシステムにおいても適用可能である。図６は、本発明の概念を単一サーバに適用した場合の変形例に係るサーバの構成を示す図である。
【００３５】
図６に示すように、サーバ３００上に同一のアプリケーション３３０を複数起動し、クラスタ機能部３１０でそれぞれのアプリケーション３３０の状態を監視させる。この場合も同様に、クラスタ機能部３１０は、ＪａｖａＶＭ３２０上に実装しないこととする。このため、クラスタ機能部３１０においてガベージコレクションは発生しない。
【００３６】
ＪａｖａＶＭ３２０のガベージコレクションなどによってアプリケーション３３０が停止した場合には、クラスタ機能部３１０が他のアプリケーション３３０にメッセージを転送する。例えば、他のＪａｖａＶＭ３２０のプロセスにメッセージをサーバ３００内部で振り分けてもよい。このようにして、ガベージコレクションによる影響を回避することができる。
【００３７】
クラスタ機能部３１０は、基本的にはラウンドロビンなどの所定の規則に基づいて、メッセージを振り分け、ガベージコレクションが発生している場合には、ガベージコレクション発生中のＪａｖａＶＭ３２０を避けて振り分けてもよい。また、クラスタ機能部３１０は、通常時はメッセージを振り分けない予備のアプリケーション３３０を起動させておき、メッセージを処理しているアプリケーション３３０でガベージコレクションが発生した場合に、予備のアプリケーション３３０に振り分けてもよい。
【００３８】
具体的には、クラスタ機能部３１０は、図３に示すように、メッセージ転送部３１１とサーバ状態管理部３１２とを有する。
【００３９】
サーバ状態管理部３１２は、各アプリケーションの状態を管理する。例えば、サーバ状態管理部３１２は、前述のようにＪＶＭＴＩを利用したＧＣ発生イベントを管理してもよく、更に、ＪＭＸ（Java Management Extensions）によるＪａｖａＶＭ３２０のメモリ利用状況の統計データ、アプリケーション３３０における例外の発生状況、アプリケーション３３０のプロセスの死活状態なども管理してもよい。
【００４０】
メッセージ転送部３１１は、アプリケーションの状態に応じて、メッセージを実際に転送するアプリケーション３３０を決定し、メッセージをアプリケーション３３０に転送する。例えば、前述のように、ガベージコレクションによりアプリケーション３３０が一時停止している場合、メッセージ転送部３１１は、他のアプリケーション３３０にメッセージを転送する。また、例えば、ガベージコレクションは発生していないが、アプリケーション３３０の不具合によってメモリの利用率が予め設定しておいた閾値をオーバーした場合などを停止イベントとして、ＧＣイベント発生時と同様に他のアプリケーション３３０にメッセージを転送してもよい。このように、アプリケーション３３０が異常動作を行った場合においてもサービスの継続が可能となる。
【００４１】
＜実施例の効果＞
前述の通り、本発明の実施例では、ガベージコレクションを採用したサーバクラスタシステムにおいて、ガベージコレクションの影響を受けないクラスタ機能３１０をアプリケーション３３０の前段に配備し、ガベージコレクションが発生して停止しているアプリケーション３３０を避けてメッセージが処理される。このため、ガベージコレクションによる影響を抑制することが可能となる。ガベージコレクションなどにより、アプリケーションが一時的に利用不可能になった場合にも、システムの応答時間を改善することができる。
【００４２】
また、ロードバランサ２００がガベージコレクションの発生などを意識する必要が無く、ラウンドロビンのような単純な振り分け方法でメッセージを振り分けることができるため、ロードバランサ２００が性能上のボトルネックとなることを避けることができる。
【００４３】
以上、本発明の実施例について説明したが、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。
【００４４】
説明の便宜上、本発明の実施例に係るシステムは機能的なブロック図を用いて説明しているが、本発明のシステムは、ハードウエア、ソフトウェア又はそれらの組み合わせで実現されてもよい。また、２以上の実施例又は変形例が必要に応じて組み合わせて使用されてもよい。
【符号の説明】
【００４５】
１００ サーバクラスタ
２００ ロードバランサ
２１０ 振り分け機能部
２１１ 振り分け先制御部
３００ サーバ
３１０ クラスタ機能部
３１１ メッセージ転送部
３１２ サーバ状態管理部
３２０ ＪａｖａＶＭ
３３０ アプリケーション
４００ プラットフォーム管理装置
５００ ＩＰネットワーク
６００ 対向装置
７００ 保守ネットワーク
【特許請求の範囲】
【請求項１】
メッセージを処理するアプリケーションが動作する複数のサーバで構成されたサーバクラスタを含むメッセージ処理システムであって、
所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する振り分け装置を有し、
前記サーバクラスタは、
各サーバの状態を管理するサーバ状態管理部と、
前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するメッセージ転送部と、
を有するメッセージ処理システム。
【請求項２】
前記サーバがガベージコレクションを採用する場合、
前記メッセージ転送部は、前記振り分け先のサーバでガベージコレクションが発生している場合に、前記振り分け先のサーバとは異なるサーバに前記メッセージを転送する、請求項１に記載のメッセージ処理システム。
【請求項３】
前記サーバ状態管理部及び前記メッセージ転送部は、ガベージコレクションが発生しない環境に実装される、請求項２に記載のメッセージ処理システム。
【請求項４】
メッセージを処理する複数のアプリケーションが動作するメッセージ処理装置であって、
各アプリケーションの状態を管理するアプリケーション状態管理部と、
各アプリケーションの状態に応じて、受信したメッセージを転送するアプリケーションを決定するメッセージ転送部と、
を有するメッセージ処理装置。
【請求項５】
アプリケーションが動作する複数のサーバで構成されたサーバクラスタでメッセージを処理するメッセージ処理方法であって、
前記サーバクラスタの外部の振り分け装置により、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択するステップと、
前記サーバクラスタにより、各サーバの状態を管理するステップと、
前記サーバクラスタにより、前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するステップと、
を有するメッセージ処理方法。
【請求項１】
メッセージを処理するアプリケーションが動作する複数のサーバで構成されたサーバクラスタを含むメッセージ処理システムであって、
所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する振り分け装置を有し、
前記サーバクラスタは、
各サーバの状態を管理するサーバ状態管理部と、
前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するメッセージ転送部と、
を有するメッセージ処理システム。
【請求項２】
前記サーバがガベージコレクションを採用する場合、
前記メッセージ転送部は、前記振り分け先のサーバでガベージコレクションが発生している場合に、前記振り分け先のサーバとは異なるサーバに前記メッセージを転送する、請求項１に記載のメッセージ処理システム。
【請求項３】
前記サーバ状態管理部及び前記メッセージ転送部は、ガベージコレクションが発生しない環境に実装される、請求項２に記載のメッセージ処理システム。
【請求項４】
メッセージを処理する複数のアプリケーションが動作するメッセージ処理装置であって、
各アプリケーションの状態を管理するアプリケーション状態管理部と、
各アプリケーションの状態に応じて、受信したメッセージを転送するアプリケーションを決定するメッセージ転送部と、
を有するメッセージ処理装置。
【請求項５】
アプリケーションが動作する複数のサーバで構成されたサーバクラスタでメッセージを処理するメッセージ処理方法であって、
前記サーバクラスタの外部の振り分け装置により、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択するステップと、
前記サーバクラスタにより、各サーバの状態を管理するステップと、
前記サーバクラスタにより、前記振り分け先のサーバの状態に応じて、前記メッセージを転送するサーバを決定するステップと、
を有するメッセージ処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−１７０７７２（Ｐ２０１１−１７０７７２Ａ）
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願番号】特願２０１０−３６２７３（Ｐ２０１０−３６２７３）
【出願日】平成２２年２月２２日（２０１０．２．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年９月１日（２０１１．９．１）
【国際特許分類】
【出願日】平成２２年２月２２日（２０１０．２．２２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]