JP5404469B2

JP5404469B2 - メッセージ処理システム、メッセージ処理装置及びメッセージ処理方法

Info

Publication number: JP5404469B2
Application number: JP2010036273A
Authority: JP
Inventors: 雅志金子; 道生入江
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2010-02-22
Filing date: 2010-02-22
Publication date: 2014-01-29
Anticipated expiration: 2030-02-22
Also published as: JP2011170772A

Description

本発明は、メッセージ処理システム、メッセージ処理装置及びメッセージ処理方法に関する。

Ｊａｖａ言語のような一部のプログラミング言語では、メモリ管理の簡便化を目的として、メモリ解放を自動化するガベージコレクション（ＧＣ：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）によるＪａｖａＶＭ３２０のメモリ利用状況の統計データ、アプリケーション３３０における例外の発生状況、アプリケーション３３０のプロセスの死活状態なども管理してもよい。

メッセージ転送部３１１は、アプリケーションの状態に応じて、メッセージを実際に転送するアプリケーション３３０を決定し、メッセージをアプリケーション３３０に転送する。例えば、前述のように、ガベージコレクションによりアプリケーション３３０が一時停止している場合、メッセージ転送部３１１は、他のアプリケーション３３０にメッセージを転送する。また、例えば、ガベージコレクションは発生していないが、アプリケーション３３０の不具合によってメモリの利用率が予め設定しておいた閾値をオーバーした場合などを停止イベントとして、ＧＣイベント発生時と同様に他のアプリケーション３３０にメッセージを転送してもよい。このように、アプリケーション３３０が異常動作を行った場合においてもサービスの継続が可能となる。

＜実施例の効果＞
前述の通り、本発明の実施例では、ガベージコレクションを採用したサーバクラスタシステムにおいて、ガベージコレクションの影響を受けないクラスタ機能３１０をアプリケーション３３０の前段に配備し、ガベージコレクションが発生して停止しているアプリケーション３３０を避けてメッセージが処理される。このため、ガベージコレクションによる影響を抑制することが可能となる。ガベージコレクションなどにより、アプリケーションが一時的に利用不可能になった場合にも、システムの応答時間を改善することができる。

また、ロードバランサ２００がガベージコレクションの発生などを意識する必要が無く、ラウンドロビンのような単純な振り分け方法でメッセージを振り分けることができるため、ロードバランサ２００が性能上のボトルネックとなることを避けることができる。

以上、本発明の実施例について説明したが、本発明は、上記の実施例に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。

説明の便宜上、本発明の実施例に係るシステムは機能的なブロック図を用いて説明しているが、本発明のシステムは、ハードウエア、ソフトウェア又はそれらの組み合わせで実現されてもよい。また、２以上の実施例又は変形例が必要に応じて組み合わせて使用されてもよい。

１００サーバクラスタ
２００ロードバランサ
２１０振り分け機能部
２１１振り分け先制御部
３００サーバ
３１０クラスタ機能部
３１１メッセージ転送部
３１２サーバ状態管理部
３２０ＪａｖａＶＭ
３３０アプリケーション
４００プラットフォーム管理装置
５００ＩＰネットワーク
６００対向装置
７００保守ネットワーク

Claims

ＪａｖａＶＭ上でメッセージを処理するアプリケーションが動作する複数のサーバで構成されたサーバクラスタを含むメッセージ処理システムであって、
所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択する振り分け装置を有し、
前記サーバクラスタは、
各サーバにおけるガベージコレクションの発生状態を管理するサーバ状態管理部と、
前記振り分け先のサーバでガベージコレクションが発生していない場合、前記選択された振り分け先のサーバのアプリケーションに前記メッセージを転送し、前記振り分け先のサーバでガベージコレクションが発生している場合、前記選択された振り分け先のサーバとは異なるサーバに前記メッセージを転送するメッセージ転送部と、
を有し、
前記サーバ状態管理部及び前記メッセージ転送部は、ＪａｖａＶＭ上に実装されないメッセージ処理システム。
ＪａｖａＶＭ上でメッセージを処理する複数のアプリケーションが動作するメッセージ処理装置であって、
所定の規則に基づいて、受信したメッセージの振り分け先のアプリケーションを選択するクラスタ機能部と、
各アプリケーションにおけるガベージコレクションの発生状態を管理するアプリケーション状態管理部と、
前記振り分け先のアプリケーションでガベージコレクションが発生していない場合、前記選択された振り分け先のアプリケーションに前記メッセージを転送し、前記振り分け先のアプリケーションでガベージコレクションが発生している場合、前記選択された振り分け先のアプリケーションとは異なるアプリケーションに前記メッセージを転送するメッセージ転送部と、
を有し、
前記アプリケーション状態管理部及び前記メッセージ転送部は、ＪａｖａＶＭ上に実装されないメッセージ処理装置。
ＪａｖａＶＭ上でアプリケーションが動作する複数のサーバで構成されたサーバクラスタでメッセージを処理するメッセージ処理方法であって、
前記サーバクラスタの外部の振り分け装置により、所定の規則に基づいて、受信したメッセージの振り分け先のサーバを選択するステップと、
前記サーバクラスタのサーバ状態管理部により、各サーバにおけるガベージコレクションの発生状態を管理するステップと、
前記サーバクラスタのメッセージ転送部により、前記振り分け先のサーバでガベージコレクションが発生していない場合、前記選択された振り分け先のサーバのアプリケーションに前記メッセージを転送し、前記振り分け先のサーバでガベージコレクションが発生している場合、前記選択された振り分け先のサーバとは異なるサーバに前記メッセージを転送するステップと、
を有し、
前記サーバ状態管理部及び前記メッセージ転送部は、ＪａｖａＶＭ上に実装されないメッセージ処理方法。