JP5544521B2 - 状態管理方法、処理装置、および状態管理プログラム - Google Patents

Description

本発明は、分散処理を行う分散システムにおける負荷分散の技術に関する。

分散システムは、複数の処理装置（サーバ）を含み、例えば、これらの処理装置を仮想化することで、所定のセッション制御を実現する。なお、非特許文献２には、分散処理を行うクラスタシステムの技術が開示されている。また、分散システムは、一般的には、複数の振り分け装置を含む。振り分け装置は、端末（クライアント）からセッション接続要求などのメッセージを受信すると、所定の方法に従ってメッセージを処理装置に振り分ける。各処理装置は、振り分けられたメッセージを呼処理し、端末に対して所定のサービスを提供する。

前記所定の方法としては、例えば、コンシステント・ハッシュ法がある。なお、非特許文献１は、コンシステント・ハッシュ法について開示している。コンシステント・ハッシュ法は、処理装置を識別する処理装置識別子および処理装置に振り分けるメッセージに含まれ、呼処理の対象となるデータの実体を識別するデータ識別子に基づいて、どの処理装置にどのメッセージを振り分けるかを決定する方法である。

具体的に、どのようにしてメッセージの振り分けが決定されるかを、図７を参照して説明する。図７は、コンシステント・ハッシュ法を説明するための識別子空間の概念図である。処理装置識別子は、例えば、処理装置のＩＰ（Internet Protocol）アドレス、処理装置名などに、ハッシュ関数を作用させて得られた値である。なお、処理装置識別子を得て、識別子空間に配置することを、処理装置識別子を「払い出す」と表現する場合がある。処理装置識別子の払い出しは、振り分け装置が実行する。

識別子空間は、図７に示すようにリング状で描写されるハッシュ空間である。処理装置識別子は、例えば、その値に基づいて識別子空間において時計回りに昇順に配置される。データ識別子は、その値に基づいてハッシュ空間に写像して配置される、つまり振り分けられる。データ識別子も、その値に基づいて識別子空間において時計回りに昇順に配置される。

このとき、処理装置は、自身の処理装置識別子の直近の処理装置識別子の配置場所から自身の処理装置識別子の配置場所まで時計回りに辿る円弧上に配置されるデータ識別子を含むメッセージを呼処理する。ここで、「直近の処理装置識別子」とは、識別子空間において、対象の処理装置識別子の値よりも小さな値を持つ処理装置識別子のうち最も大きな値を持つ処理装置識別子を意味する。しかし、対象の処理装置識別子の値が識別子空間において、最も小さな値を持つ場合には、直近の処理装置識別子は、識別子空間において、最も大きな値を持つこととする。すると、直近の処理装置識別子の配置場所から対象の処理装置識別子の配置場所まで時計回りに辿る円弧が、対象の処理装置識別子で識別される処理装置がメッセージの呼処理を担当する領域である。

図７によれば、処理装置識別子Ａ、Ｂ、Ｃの値にＡの値＜Ｂの値＜Ｃの値という関係があるので、時計回りにＡ→Ｂ→Ｃの順番に処理装置識別子が配置される。また、データ識別子Ｘの値は、Ａの値＜Ｘの値＜Ｂの値という関係を満たすので、処理装置識別子Ａおよび処理装置識別子Ｂの間に配置される。よって、データ識別子Ｘを含むメッセージは、処理装置識別子Ｂで識別される処理装置が呼処理する。なお、処理装置識別子Ａで識別される処理装置は、処理装置識別子Ｃの配置場所から処理装置識別子Ａの配置場所まで時計回りに辿る円弧上に配置されるデータ識別子を含むメッセージを呼処理する。

David Karger、外５名、"Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web"、［online］、［平成２３年５月３１日検索］、インターネット〈URL：http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf〉 "JBoss Enterprise Application Platform 5.0"、［online］、［平成２３年５月３１日検索］、インターネット〈URL：http://docs.redhat.com/docs/ja-JP/JBoss_Enterprise_Application_Platform/5.0/html-single/JBoss_Cache_User_Guide/index.html〉

ところで、処理装置は、メッセージの呼処理を行うために、セッションが開始したことや、セッションが確立中であることなどを示す呼状態を管理する必要がある。元々分散システムに含まれ、呼状態を管理してきた処理装置は、新たなメッセージが振り分けられても、管理してきた呼状態に基づいてそのメッセージの呼処理を行う。しかし、分散システムに新たに増設した処理装置は、コンシステント・ハッシュ法により呼処理の担当が決まったメッセージが振り分けられても、呼状態を持たないために呼処理を行うことができない。

そこで、増設した処理装置は、元々呼処理を担当していた処理装置から呼状態を知る。具体的には、増設した処理装置は、分散システムを構成する処理装置のそれぞれに要求を出力し、元々呼処理を担当していた処理装置を探し出す。元々呼処理を担当していた処理装置は、増設した処理装置に対して応答を出力し、呼状態を通知する。

しかし、上記した方法では、分散システムを構成する処理装置の数が多くなるにつれ、前記要求も多くなる。その結果、処理装置の呼処理の遅延化を招き、スケーラビリティの確保が困難になる。
このような事情に鑑みて、本発明は、分散システムにおける処理装置の呼処理の遅延化を抑制することを目的とする。

前記課題を解決するため、請求項１に記載の発明は、クライアントにサービスを提供する複数の処理装置と、コンシステント・ハッシュ法により前記クライアントから得られるメッセージを前記処理装置に振り分ける複数の振り分け装置と、が通信可能に接続されている分散システムの処理装置における状態管理方法であって、前記分散システムに増設した処理装置が、前記コンシステント・ハッシュ法により、当該増設した処理装置を含む処理装置ごとに払い出された処理装置識別子を含む管理情報を、前記振り分け装置から取得する管理情報取得ステップと、前記振り分け装置から前記メッセージを取得すると、前記取得した管理情報から、当該増設した処理装置に払い出された処理装置識別子を削除する削除ステップと、前記削除後の管理情報に基づいて、前記取得したメッセージの呼処理を担当していた処理装置を特定する担当特定ステップと、前記特定した処理装置から、前記取得したメッセージの呼処理の進捗を示す呼状態データを取得する呼状態データ取得ステップと、を実行することを特徴とする。

請求項２に記載の発明は、請求項１に記載の発明において、前記増設した処理装置が、第１の処理装置と、第２の処理装置と、を少なくとも含み、前記第１の処理装置が、前記管理情報取得ステップにおいて、前記第１の処理装置に払い出された処理装置識別子、および前記第２の処理装置に払い出された処理装置識別子を含む前記管理情報を、前記振り分け装置から取得し、前記削除ステップにおいて、前記第１の処理装置に払い出された処理装置識別子だけでなく、前記呼状態データ取得ステップを実行しても前記振り分け装置から取得したメッセージに対応する呼状態データを取得できなかったことにより、増設した処理装置であると確認された前記第２の処理装置に払い出された処理装置識別子も、前記管理情報から削除することを特徴とする。

請求項３に記載の発明は、クライアントにサービスを提供する複数の処理装置と、コンシステント・ハッシュ法により前記クライアントから得られるメッセージを前記処理装置に振り分ける複数の振り分け装置と、が通信可能に接続されている分散システムの処理装置であって、前記分散システムに増設した処理装置が、前記コンシステント・ハッシュ法により、当該増設した処理装置を含む処理装置ごとに払い出された処理装置識別子を含む管理情報を、前記振り分け装置から取得する管理情報取得制御と、前記振り分け装置から前記メッセージを取得すると、前記取得した管理情報から、当該増設した処理装置に払い出された処理装置識別子を削除する削除制御と、前記削除後の管理情報に基づいて、前記取得したメッセージの呼処理を担当していた処理装置を特定する担当特定制御と、前記特定した処理装置から、前記取得したメッセージの呼処理の進捗を示す呼状態データを取得する呼状態データ取得制御と、を実行することを特徴とする。

請求項４に記載の発明は、請求項３に記載の発明において、前記増設した処理装置が、第１の処理装置と、第２の処理装置と、を少なくとも含み、前記第１の処理装置が、前記管理情報取得制御において、前記第１の処理装置に払い出された処理装置識別子、および前記第２の処理装置に払い出された処理装置識別子を含む前記管理情報を、前記振り分け装置から取得し、前記削除制御において、前記第１の処理装置に払い出された処理装置識別子だけでなく、前記呼状態データ取得制御を実行しても前記振り分け装置から取得したメッセージに対応する呼状態データを取得できなかったことにより、増設した処理装置であると確認された前記第２の処理装置に払い出された処理装置識別子も、前記管理情報から削除することを特徴とする。

請求項５に記載の発明は、クライアントにサービスを提供する複数の処理装置と、コンシステント・ハッシュ法により前記クライアントから得られるメッセージを前記処理装置に振り分ける複数の振り分け装置と、が通信可能に接続されている分散システムの処理装置を、コンピュータとして機能させる状態管理プログラムであって、前記分散システムに増設した処理装置に、前記コンシステント・ハッシュ法により、当該増設した処理装置を含む処理装置ごとに払い出された処理装置識別子を含む管理情報を、前記振り分け装置から取得する管理情報取得処理と、前記振り分け装置から前記メッセージを取得すると、前記取得した管理情報から、当該増設した処理装置に払い出された処理装置識別子を削除する削除処理と、前記削除後の管理情報に基づいて、前記取得したメッセージの呼処理を担当していた処理装置を特定する担当特定処理と、前記特定した処理装置から、前記取得したメッセージの呼処理の進捗を示す呼状態データを取得する呼状態データ取得処理と、を実行させることを特徴とする。

請求項６に記載の発明は、請求項５に記載の発明において、前記増設した処理装置が、第１の処理装置と、第２の処理装置と、を少なくとも含み、前記第１の処理装置に、前記管理情報取得処理において、前記第１の処理装置に払い出された処理装置識別子、および前記第２の処理装置に払い出された処理装置識別子を含む前記管理情報を、前記振り分け装置から取得させ、前記削除処理において、前記第１の処理装置に払い出された処理装置識別子だけでなく、前記呼状態データ取得処理を実行しても前記振り分け装置から取得したメッセージに対応する呼状態データを取得できなかったことにより、増設した処理装置であると確認された前記第２の処理装置に払い出された処理装置識別子も、前記管理情報から削除させることを特徴とする。

請求項１、３、５に記載の発明によれば、分散システムにおける処理装置の呼処理の遅延化を抑制することができる。

請求項２、４、６に記載の発明によれば、複数の処理装置を同時増設した場合であっても、呼状態データを持っていないと見込まれる処理装置には元々要求しない。よって、複数の処理装置を同時増設した場合であっても、処理装置の呼処理の遅延化を抑制することができる。

本発明によれば、分散システムにおける処理装置の呼処理の遅延化を抑制することができる。

分散システムの構成図である。 （ａ）振り分け装置で使用されるソフトウェアおよび（ｂ）処理装置で使用されるソフトウェアの構成図である。 （ａ）処理装置管理テーブルのデータ構造および（ｂ）呼状態管理テーブルのデータ構造を示す図である。 処理装置の増設時に、呼状態データを持つ処理装置を特定する様子の説明図である。 ２つの処理装置の同時増設時に、呼状態データを持つ処理装置を特定する様子の説明図である。 増設した処理装置における処理を示すフローチャートである。 コンシステント・ハッシュ法を説明するための識別子空間の概念図である。

次に、本発明を実施するための形態（以下、「実施形態」という。）について、適宜図面を参照しながら説明する。

≪構成≫
まず、本実施形態の構成について説明する。
図１は、分散システムの構成図である。この分散システムは、振り分け装置１、処理装置２、クライアント３およびロードバランサ４を含む。この分散システムは、複数の処理装置２などのコンピュータ資源を仮想化し、複数の処理装置２が協調してセッション制御を行い、クライアント３に所定のサービスを提供するクラスタシステムである。前記セッション制御は、例えば、呼制御であり、ＳＩＰ（Session Initiation Protocol）を使用して、インターネット電話などのサービスが提供される。

振り分け装置１は、ロードバランサ４から受信したメッセージを例えばコンシステント・ハッシュ法によって、処理装置２に振り分ける。前記メッセージは、例えばＳＩＰ信号であり、セッション接続要求などを含む。
処理装置２は、振り分け装置１から振り分けられたメッセージを呼処理し、クライアント３にサービスを提供する。
クライアント３は、メッセージをロードバランサ４に送信し、処理装置２が提供するサービスを利用する。
ロードバランサ４は、クライアント３から受信したメッセージを、例えばラウンドロビンによって、振り分け装置１のそれぞれに振り分ける。

振り分け装置１、処理装置２、クライアント３およびロードバランサ４はいずれも、入力部、出力部、制御部および記憶部といったハードウェアを含むコンピュータである。入力部は、例えば、入力インタフェースから構成される。出力部は、例えば、出力インタフェースから構成される。制御部は、例えば、ＣＰＵ（Central Processing Unit）や専用回路から構成される。記憶部は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリの記憶媒体から構成される。前記制御部がＣＰＵから構成される場合、その制御部を含むコンピュータによる情報処理は、ＣＰＵによるプログラム実行処理で実現する。また、そのコンピュータが含む記憶部は、ＣＰＵが指令し、そのコンピュータの機能を実現するためのプログラム（状態管理プログラムを含む）を記憶する。これによりソフトウェアとハードウェアの協働が実現される。

本実施形態は、前記情報処理を実行させるプログラムによって実現することができ、そのプログラムをコンピュータによる読み取り可能な記録媒体（例：ＣＤ−ＲＯＭ）に記憶して提供することが可能である。また、そのプログラムを、インターネットのネットワークを通して提供することも可能である。

本実施形態の分散システムで使用されるソフトウェアについて説明する。
図２は、（ａ）振り分け装置で使用されるソフトウェアおよび（ｂ）処理装置で使用されるソフトウェアの構成図である。振り分け装置１は、処理装置検出部１０１、テーブル取得応答部１０２および処理装置管理テーブルＴ１、といった構成要素を備える。また、処理装置２は、増設通知部２０１、テーブル取得要求部２０２、呼状態データ取得要求部２０３、呼状態データ取得応答部２０４、処理装置管理テーブルＴ３、および呼状態管理テーブルＴ２、といった構成要素を備える。

まず、振り分け装置１について説明する。
処理装置検出部１０１は、分散システムに処理装置２が増設された旨を検出する。増設された処理装置２については、所定のアルゴリズムに従って、対応する処理装置識別子が払い出される。前記所定のアルゴリズムは、例えば、処理装置のＩＰアドレスや処理装置名などに、ハッシュ関数を作用させるものである。払い出された処理装置識別子は、処理装置管理テーブルＴ１に追加される。振り分け装置１は、増設した処理装置２に対し、自身のＩＰアドレスを通知する。

テーブル取得応答部１０２は、処理装置２のテーブル取得要求部２０２からの処理装置管理テーブルＴ１を取得する要求に応答し、その処理装置２に処理装置管理テーブルＴ１の内容を通知する。基本的には、増設した処理装置２に通知する処理装置管理テーブルＴ１の内容には、増設した処理装置２の処理装置識別子が追加されている。

処理装置管理テーブルＴ１（管理情報）は、分散システムを構成する処理装置２を管理する。スケーラビリティを確保するため、振り分け装置１は、それぞれ処理装置管理テーブルＴ１を持つ。処理装置管理テーブルＴ１の詳細は、後記する。

次に、処理装置２について説明する。
増設通知部２０１は、処理装置２が増設されたとき、マルチキャストにより分散システムを構成するすべての振り分け装置１に対して増設の旨を通知する。増設した処理装置２は、増設の旨を通知する際に、自身のＩＰアドレスを通知する。また、振り分け装置１は、振り分け装置１自身のＩＰアドレスを増設した処理装置２に通知する。なお、増設の旨、および場合によっては自身のＩＰアドレスは、他の処理装置２に通知してもよい。この場合、他の処理装置２は、他の処理装置２自身のＩＰアドレスを増設した処理装置２に通知してもよい。

テーブル取得要求部２０２は、振り分け装置１に対し、処理装置管理テーブルＴ１を要求し、振り分け装置１のテーブル取得応答部１０２による応答により取得する。処理装置管理テーブルＴ１の要求は、例えば、振り分け装置１から通知された振り分け装置１自身のＩＰアドレスを用いて実行される。

呼状態データ取得要求部２０３は、他の処理装置２に対し、呼状態データを要求し、他の処理装置２の呼状態データ取得応答部２０４による応答により取得する。呼状態データの要求は、振り分け装置１から振り分けられたメッセージに含まれ、当該呼状態データに対応するデータ識別子を用いて実行される。呼状態データについては、後記する。
呼状態データ取得応答部２０４は、他の処理装置２からの呼状態データを取得する要求に応答し、当該他の処理装置２に呼状態データを通知する。

処理装置管理テーブルＴ３は、テーブル取得要求部１０２により、振り分け装置１から取得した処理装置管理テーブルＴ１である。
呼状態管理テーブルＴ２は、呼状態データ取得要求部２０３により、他の処理装置２から取得した呼状態データを管理する。呼状態管理テーブルＴ２の詳細は、後記する。

処理装置管理テーブルＴ１および呼状態管理テーブルＴ２について説明する。
図３は、（ａ）処理装置管理テーブルのデータ構造および（ｂ）呼状態管理テーブルのデータ構造を示す図である。

まず、処理装置管理テーブルＴ１について説明する。なお、この説明は、処理装置管理テーブルＴ３にも当てはまる。
処理装置管理テーブルＴ１は、「処理装置識別子」および「処理装置ＩＰアドレス」といったフィールドを含み、処理装置２ごとにレコードが作成される。
「処理装置識別子」フィールドには、処理装置検出部１０１により払い出された処理装置識別子の値が格納される。
「処理装置ＩＰアドレス」フィールドには、処理装置２のＩＰアドレスの値が格納される。

次に、呼状態管理テーブルＴ２について説明する。
呼状態管理テーブルＴ２は、「データ識別子」および「呼状態」といったフィールドを含み、呼状態データごとにレコードが作成される。
「データ識別子」フィールドには、振り分け装置１から振り分けられたメッセージに含まれるデータ識別子の値が格納される。なお、先述したとおり、データ識別子は、呼処理の対象となるデータの実体を識別する。データ識別子は、例えば、トランザクションＩＤ（Identifier）である。あるメッセージの呼処理を担当する処理装置２は、通常、その呼処理の対象となるデータの実体を記憶部に記憶しており、呼処理を実行するときは、そのデータの実体を書き換える。
「呼状態」フィールドには、主に、セッションの状態を示す値が呼状態として格納される。クライアント３から次々と受信するメッセージの呼処理を実行すると、呼状態が変わる。セッションの状態には、例えば、セッションの開始、セッション確立中、セッション解放中などがある。

上記の説明から、「呼状態データ」は、呼状態管理テーブルＴ２のレコードを構成するデータであるといえる。呼状態データは、呼状態データが持つデータ識別子を含むメッセージの呼処理の進捗を示すデータとなる。呼状態データの具体例としては、セッションの状態、メッセージ（またはセッション）のシーケンス番号、データ識別子としてのトランザクションＩＤなどが挙げられる。これらの他にも、例えば、クライアント３からメッセージが送信された時刻を示すタイマ値を含めてもよい。処理装置２は、メッセージが振り分けられると、メッセージに含まれるデータ識別子を参照して、対応するデータの実体を書き換える。
また、メッセージには、呼状態を遷移させるための情報が含まれている。処理装置２は、その情報を参照して、データ識別子に対応する「呼状態」フィールドに格納される値を変え、呼状態管理テーブルＴ２を更新する。これらの処理がなされることにより、メッセージの呼処理が実行される。

次に、増設した処理装置２が、振り分け装置１から振り分けられたメッセージの呼処理を実行するために、呼状態を知る手順について説明する。
図４は、処理装置の増設時に、呼状態データを持つ処理装置を特定する様子の説明図である。図４の（ａ）は、処理装置の増設前の識別子空間の概念図であり、図４の（ｂ）は、処理装置の増設後の識別子空間の概念図である。

図４の（ａ）において、Ａ、Ｂ、Ｃは、処理装置識別子であり、それらの値には、Ｃの値＜Ａの値＜Ｂの値という関係がある。よって、時計回りにＣ→Ａ→Ｂの順番に処理装置識別子が配置される。また、Ｘは、データ識別子であり、データ識別子Ｘの値は、Ｃの値＜Ｘの値＜Ａの値＜Ｂの値という関係を満たす。よって、データ識別子Ｘは、処理装置識別子Ｃおよび処理装置識別子Ａの間に配置される。データ識別子Ｘを含むメッセージは、処理装置識別子Ａの処理装置２に振り分けられる。つまり、処理装置識別子Ａの処理装置２が、データ識別子Ｘを含むメッセージの呼処理を担当する。

図４の（ｂ）は、処理装置識別子Ｉの処理装置２が増設した場合を示す。処理装置識別子Ｉは、Ｃの値＜Ｘの値＜Ｉの値＜Ａの値という関係を満たす。よって、処理装置識別子Ａの処理装置２ではなく、処理装置識別子Ｉの処理装置２が、データ識別子Ｘを含むメッセージの呼処理を担当する。

増設したばかりの処理装置識別子Ｉの処理装置２は、振り分け装置１から処理装置管理テーブルＴ１の取得を要求し、処理装置管理テーブルＴ３を持つ。処理装置管理テーブルＴ３には、処理装置識別子Ｉの処理装置２自身のレコードが追加されている。しかし、処理装置識別子Ｉの処理装置２は、データ識別子Ｘに対応する呼状態を知らない。よって、処理装置識別子Ｉの処理装置２は、振り分け装置１から振り分けられたデータ識別子Ｘを含むメッセージを呼処理することができない。

そこで、処理装置識別子Ｉの処理装置２は、データ識別子Ｘに対応する呼状態を知る処理装置２を探す。そのために、処理装置識別子Ｉの処理装置２は、自身が増設する前の識別子空間を想定し、その識別子空間において、データ識別子Ｘを含むメッセージの呼処理を担当していた処理装置２を特定する。

具体的には、まず、処理装置識別子Ｉの処理装置２は、処理装置管理テーブルＴ３に追加された自身のレコードを一時的に削除する。そして、削除後の処理装置管理テーブルＴ３に基づいて、コンシステント・ハッシュ法により、データ識別子Ｘを含むメッセージの呼処理を担当していた処理装置２を特定する。図４の（ｂ）では、処理装置識別子Ａの処理装置２を、データ識別子Ｘを含むメッセージの呼処理を担当していた処理装置２として特定する。

処理装置識別子Ｉの処理装置２は、処理装置識別子Ａの処理装置２に対し、データ識別子Ｘを含む呼状態データの取得を要求する。処理装置識別子Ａの処理装置２は、基本的には、データ識別子Ｘを含む呼状態データを持っているので、その呼状態データを処理装置識別子Ｉの処理装置２に通知する。処理装置識別子Ｉの処理装置２は、通知された呼状態データを用いて、呼状態管理テーブルＴ２を更新する。また、処理装置識別子Ｉの処理装置２は、振り分け装置１からデータ識別子Ｘを含むメッセージが振り分けられた場合、そのメッセージの呼処理を実行する。
なお、処理装置識別子Ａの処理装置２は、基本的には、データ識別子Ｘで識別されるデータの実体を記憶している。よって、処理装置識別子Ｉの処理装置２は、処理装置識別子Ａの処理装置２から、そのデータの実体を取得する。処理装置識別子Ｉの処理装置２は、呼処理を実行においては、そのデータの実体を書き換える。

また、複数の処理装置２が同時に増設した場合について説明する。なお、以下の説明は、同時増設する処理装置２が３以上であってもあてはまる。また、増設が「同時」であるとは、複数の処理装置２が所定の短期間内に増設するという意味である。

図５は、２つの処理装置の同時増設時に、呼状態データを持つ処理装置を特定する様子の説明図である。図５の（ａ）は、処理装置の同時増設前の識別子空間の概念図であり、図５の（ｂ）は、処理装置の同時増設後の識別子空間の概念図である。図５の（ａ）の識別子空間は、図４の（ａ）のそれと同一である。特に断らない限り、図４で説明した事項と共通する事項については説明を省略する。

図５の（ｂ）は、処理装置識別子Ｉ、Ｊの処理装置２（第１の処理装置、第２の処理装置）が同時増設した場合を示す。処理装置識別子Ｉ、Ｊは、Ｃの値＜Ｘの値＜Ｉの値＜Ｊの値＜Ａの値という関係を満たす。よって、処理装置識別子Ａの処理装置２ではなく、処理装置識別子Ｉの処理装置２が、データ識別子Ｘを含むメッセージの呼処理を担当する。
なお、処理装置識別子Ｉ、Ｊの処理装置２がそれぞれ持つ処理装置管理テーブルＴ３には、処理装置識別子Ｉ、Ｊの処理装置２の２つのレコードが追加されている。

処理装置識別子Ｉの処理装置２は、データ識別子Ｘに対応する呼状態を知らない。よって、処理装置識別子Ｉの処理装置２は、データ識別子Ｘに対応する呼状態を知る処理装置２を探す。処理装置識別子Ｉの処理装置２は、処理装置管理テーブルＴ３に追加された自身のレコードを一時的に削除する。そして、削除後の処理装置管理テーブルＴ３に基づいて、コンシステント・ハッシュ法により、処理装置識別子Ｊの処理装置２を、データ識別子Ｘを含むメッセージの呼処理を担当していた処理装置２として特定する。

処理装置識別子Ｉの処理装置２は、処理装置識別子Ｊの処理装置２に対し、データ識別子Ｘを含む呼状態データの取得を要求する。ところが、処理装置識別子Ｊの処理装置２も増設したばかりであるため、データ識別子Ｘを含む呼状態データを持っていない。また、基本的には、処理装置識別子Ｉの処理装置２は、処理装置識別子Ｊの処理装置２が増設したばかりであることは知りえない。結果的に、処理装置識別子Ｉの処理装置２は、データ識別子Ｘを含む呼状態データの取得に失敗する。

ただ、処理装置識別子Ｉの処理装置２は、呼状態データの取得を失敗することで、処理装置識別子Ｊの処理装置２が増設したばかりの処理装置２であるとみなす（確認する）ことができる。そこで、処理装置識別子Ｉの処理装置２は、処理装置管理テーブルＴ３において、処理装置管理テーブルＴ３に追加された、処理装置識別子Ｊの処理装置２のレコードを一時的に削除する。処理装置識別子Ｉの処理装置２は、その削除後の処理装置管理テーブルＴ３に基づいて、コンシステント・ハッシュ法により、処理装置識別子Ａの処理装置２を、データ識別子Ｘを含むメッセージの呼処理を担当していた処理装置２として改めて特定する。

処理装置識別子Ｉの処理装置２は、処理装置識別子Ａの処理装置２に対し、データ識別子Ｘを含む呼状態データの取得を要求する。処理装置識別子Ｉの処理装置２は、処理装置識別子Ａの処理装置２から、その呼状態データを取得することで、データ識別子Ｘを含むメッセージの呼処理を実行することができる。
処理装置識別子Ｉの処理装置２は、基本的には、所望の呼状態データを取得できるまで、他の処理装置２への取得要求を繰り返す。

≪処理≫
次に、本実施形態の処理について説明する。具体的には、処理装置２の増設に関わる処理について説明する。この処理の主体は、処理装置２の制御部である。
図６は、増設した処理装置における処理を示すフローチャートである。この処理は、処理装置２が分散システムに増設した後に行われる。また、この処理は、増設した後から所定期間経過した後であっても、この処理装置２が分散システムを構成しているうち、つまり生存しているうちは定期的に行ってもよい。この処理は、ステップＳ０１から開始する。

ステップＳ０１において、増設した処理装置２の制御部は、増設通知部２０１により、自身の増設の旨を振り分け装置１に通知する。もし、増設した後から所定期間経過した後にステップＳ０１の処理を行う場合は、自身の生存の旨が通知される。ステップＳ０１の後、ステップＳ０２に進む。

ステップＳ０２において、増設した処理装置２の制御部は、テーブル取得要求部２０２により、振り分け装置１に対し、処理装置管理テーブルＴ１を要求し、取得する。増設した処理装置２は、取得した処理装置管理テーブルＴ１を、処理装置管理テーブルＴ３として管理する。なお、増設した処理装置２の制御部は、増設した処理装置２が生存している間は、振り分け装置１から最新の処理装置管理テーブルＴ１を定期的に取得してもよい。ステップＳ０２の後、ステップＳ０３に進む。

ステップＳ０３において、増設した処理装置２の制御部は、振り分け装置１から振分けられたメッセージを取得する。ステップＳ０３の後、ステップＳ０４に進む。

ステップＳ０４において、増設した処理装置２の制御部は、取得したメッセージがセッション開始メッセージであるか否かを判定する。「セッション開始メッセージ」とは、セッションの状態がセッションの開始であることを示すメッセージであり、具体例としては、ini-INVITEメッセージがある。取得したメッセージがセッション開始メッセージであれば（ステップＳ０４でＹｅｓ）、ステップＳ０９に進む。取得したメッセージがセッション開始メッセージでなければ（ステップＳ０４でＮｏ）、ステップＳ０５に進む。

なお、セッション開始メッセージを取得した場合（ステップＳ０４でＹｅｓ）とは、例えば、クライアント３がはじめてサービスを利用する場合である。この場合は、分散システムを構成するいずれの処理装置２も、該当する呼状態データを持たない。つまり、いずれの処理装置２もそのメッセージの呼処理を担当していない。よって、増設した処理装置２は、後記するステップＳ０９の処理により該当する呼状態データを新たに生成し、呼状態管理テーブルＴ２に追加登録する。

ステップＳ０５において、増設した処理装置２の制御部は、取得したメッセージ、つまりセッション開始メッセージ以外のメッセージ（非ini-INVITEメッセージ）の呼処理をするために、該当する呼状態データがあるか否か判定する。具体的には、増設した処理装置２が持つ呼状態管理テーブルＴ２に、取得したメッセージに含まれているデータ識別子の呼状態データが登録されているか否か判定する。該当する呼状態データがあれば（ステップＳ０５でＹｅｓ）、ステップＳ０９に進む。該当する呼状態データがなければ（ステップＳ０５でＮｏ）、ステップＳ０６に進む。

なお、該当する呼状態データがある場合（ステップＳ０５でＹｅｓ）とは、例えば、
（１）増設した処理装置２自身が図６の処理により、事前にセッション開始メッセージの呼処理をし、該当する呼状態データを生成し、その後ステップＳ０４でセッション開始メッセージ以外のメッセージを取得した場合、
（２）増設した処理装置２自身が図６の処理により、他の処理装置２から該当する呼状態データをすでに取得し、その後ステップＳ０４でセッション開始メッセージ以外のメッセージを取得した場合、がある。

ステップＳ０６において、増設した処理装置２の制御部は、処理装置管理テーブルＴ３を用いて、取得したメッセージの呼処理を元々担当していた処理装置２を特定する。前述したとおり、処理装置２を特定するときには、処理装置管理テーブルＴ３において、自身のレコードを一時的に削除する。ステップＳ０６の後、ステップＳ０７に進む。
なお、ステップＳ０６の処理では、後記するステップＳ０８で呼状態データを取得しなかった処理装置２に関し、処理装置管理テーブルＴ３からその処理装置２のレコードも一時的に削除する。

ステップＳ０７において、増設した処理装置２の制御部は、呼状態データ取得要求部２０３により、ステップＳ０６で特定した処理装置２に対し、呼状態データを要求する。ステップＳ０７の後、ステップＳ０８に進む。

ステップＳ０８において、増設した処理装置２の制御部は、ステップＳ０６で特定した処理装置２から該当する呼状態データを取得したか否か判定する。つまり、ステップＳ０６で特定した処理装置２は、ステップＳ０３取得したメッセージの呼処理を元々担当していた処理装置２であったかどうかを判定する。該当する呼状態データを取得したときは（ステップＳ０８でＹｅｓ）、基本的には、ステップＳ０６での特定が正しかったことを意味し、ステップＳ０９に進む。該当する呼状態データを取得しなかったときは（ステップＳ０８でＮｏ）、基本的には、ステップＳ０６での特定が誤りであったことを意味し、ステップＳ０６に戻る。

なお、ステップＳ０６での特定が誤りであった場合としては、例えば、同時増設によって、図６の処理を実行する増設した処理装置２自身の他にも同時に増設した処理装置２を特定してしまった場合がある。よって、この場合には、前述したとおり、処理装置管理テーブルＴ３において、同時に増設した処理装置２のレコードを削除して、ステップＳ０６において、新たな処理装置２を特定する。基本的には、ステップＳ０８の処理は、ステップＳ０５での特定が正しかったと判定されるまで繰り返す。

ステップＳ０９において、増設した処理装置２の制御部は、ステップＳ０８で取得した呼状態データを用いて、ステップＳ０８で取得したメッセージを呼処理する。ステップＳ０９の処理が終了することにより、図６の処理全体が終了する。

≪まとめ≫
本実施形態によれば、分散システムにおける処理装置２の呼処理の遅延化を抑制することができる。
従来技術によれば、増設した処理装置２は、呼状態データを取得するために、分散システムを構成する処理装置２それぞれに要求を出力していた。このため、呼状態データの取得に要する処理の処理量がＯ（Ｎ）の規模に及んでしまう（Ｎは、分散システムを構成する処理装置２の数）。結果的に、とりわけ分散システムを構成する処理装置２の数が多くなると、処理装置２の呼処理の遅延化を招いていた。
本実施形態によれば、取得すべき呼状態データを持つ処理装置２を事前に特定するので、呼状態データを取得するための要求は、基本的には１度で済み、呼状態データの取得に要する処理の処理量はＯ（１）の規模に抑えられる。結果として、分散システムを構成する処理装置２の数が多くなっても、処理装置２の呼処理の遅延化を抑制することができる。

また、複数の処理装置２を同時増設した場合であっても、増設した処理装置２からの誤った要求は、基本的には、同時増設した他の処理装置２になされるだけであり、呼状態データを持っていないと見込まれる既存の処理装置２には元々要求しない。よって、呼状態データの取得に要する処理の処理量はＯ（１）の規模とあまり変わらない。結果として、複数の処理装置２を同時増設した場合であっても、処理装置２の呼処理の遅延化を抑制することができる。
≪その他≫
前記実施形態は、本発明を実施するために好適のものであるが、その実施形式はこれらに限定されるものでなく、本発明の要旨を変更しない範囲内において種々変形することが可能である。

例えば、本実施形態は、処理装置管理テーブルＴ１、Ｔ３において、処理装置２のＩＰアドレスを用いた。また、増設した処理装置２が振り分け装置１に増設の旨を通知するときに自身のＩＰアドレスを用いたり、処理装置２が処理装置管理テーブルＴ１を要求するときに振り分け装置１のＩＰアドレスを用いたりした。しかし、前記したＩＰアドレスの代わりに、例えばＭＡＣ（Media Access Control address）アドレスを用いてもよい。また、ＩＰアドレスやＭＡＣアドレスのように、分散システムのネットワーク上で処理装置２や振り分け装置１などの装置を特定できる機能を持つのであればどのような種類のアドレスを用いてもよい。

また、本発明に関しては、分散システムにおいてロードバランサ４を省略してもよい。必要であれば、振り分け装置１は、ロードバランサ４が備える機能（例：ラウンドロビン）を備えてもよい。

また、分散システムを構成する既存の処理装置２は、例えば、振り分け装置１から定期的に処理装置管理テーブルＴ１を要求し、取得してもよい。振り分け装置１は、例えば、定期的に処理装置管理テーブルＴ１を更新しており、処理装置２が増設した場合には、その処理装置２のレコードを追加する。既存の処理装置２は、振り分け装置１から定期的に最新の処理装置管理テーブルＴ１を取得する。既存の処理装置２が、処理装置管理テーブルＴ１から、増設した処理装置２の存在を知れば、コンシステント・ハッシュ法により、既存の処理装置２自身が呼処理を担当していたメッセージが、増設した処理装置２に振り分けられるかどうかを知ることができる。もし、そのメッセージが振り分けられるのであれば、増設した処理装置２からの要求が無くとも、前記既存の処理装置２は、増設した処理装置２に対し、そのメッセージの呼処理に必要となる呼状態データを通知することができる。増設した処理装置２は、前記既存の処理装置２に呼状態データを要求せずとも、振り分けられたメッセージの呼処理を行うことができる。

また、複数の処理装置２を同時増設した場合において、増設した処理装置２はそれぞれ、自身が増設した旨を、振り分け装置１からメッセージを振り分けられる前に、増設した他の処理装置２に通知してもよい。これにより、増設した処理装置２は、振り分け装置１からメッセージを振り分けられたときに、同時に増設した他の処理装置２の存在を知ることができる。よって、振り分けられたメッセージの呼処理を担当していた処理装置２を特定するときに（図６のステップＳ０６）、処理装置管理テーブルＴ３において、自身のレコードを削除するだけでなく、同時に増設した他の処理装置２のレコードも削除することができる。その結果、増設した処理装置２は、同時に増設した他の処理装置２に対し、誤って呼状態データを要求することは無い。

また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。

その他、ハードウェア、ソフトウェア、テーブル、フローチャートなどの具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１ 振り分け装置
２ 処理装置
３ クライアント
４ ロードバランサ
１０１ 処理装置検出部
１０２ テーブル取得応答部
２０１ 増設通知部
２０２ テーブル取得要求部
２０３ 呼状態データ取得要求部
２０４ 呼状態データ取得応答部
Ｔ１、Ｔ３ 処理装置管理テーブル（管理情報）
Ｔ２ 呼状態管理テーブル

Claims (6)

1. クライアントにサービスを提供する複数の処理装置と、コンシステント・ハッシュ法により前記クライアントから得られるメッセージを前記処理装置に振り分ける複数の振り分け装置と、が通信可能に接続されている分散システムの処理装置における状態管理方法であって、
   前記分散システムに増設した処理装置が、
   前記コンシステント・ハッシュ法により、当該増設した処理装置を含む処理装置ごとに払い出された処理装置識別子を含む管理情報を、前記振り分け装置から取得する管理情報取得ステップと、
   前記振り分け装置から前記メッセージを取得すると、前記取得した管理情報から、当該増設した処理装置に払い出された処理装置識別子を削除する削除ステップと、
   前記削除後の管理情報に基づいて、前記取得したメッセージの呼処理を担当していた処理装置を特定する担当特定ステップと、
   前記特定した処理装置から、前記取得したメッセージの呼処理の進捗を示す呼状態データを取得する呼状態データ取得ステップと、を実行する
   ことを特徴とする状態管理方法。
2. 前記増設した処理装置は、第１の処理装置と、第２の処理装置と、を少なくとも含み、
   前記第１の処理装置が、
   前記管理情報取得ステップにおいて、前記第１の処理装置に払い出された処理装置識別子、および前記第２の処理装置に払い出された処理装置識別子を含む前記管理情報を、前記振り分け装置から取得し、
   前記削除ステップにおいて、前記第１の処理装置に払い出された処理装置識別子だけでなく、前記呼状態データ取得ステップを実行しても前記振り分け装置から取得したメッセージに対応する呼状態データを取得できなかったことにより、増設した処理装置であると確認された前記第２の処理装置に払い出された処理装置識別子も、前記管理情報から削除する
   ことを特徴とする請求項１に記載の状態管理方法。
3. クライアントにサービスを提供する複数の処理装置と、コンシステント・ハッシュ法により前記クライアントから得られるメッセージを前記処理装置に振り分ける複数の振り分け装置と、が通信可能に接続されている分散システムの処理装置であって、
   前記分散システムに増設した処理装置が、
   前記コンシステント・ハッシュ法により、当該増設した処理装置を含む処理装置ごとに払い出された処理装置識別子を含む管理情報を、前記振り分け装置から取得する管理情報取得制御と、
   前記振り分け装置から前記メッセージを取得すると、前記取得した管理情報から、当該増設した処理装置に払い出された処理装置識別子を削除する削除制御と、
   前記削除後の管理情報に基づいて、前記取得したメッセージの呼処理を担当していた処理装置を特定する担当特定制御と、
   前記特定した処理装置から、前記取得したメッセージの呼処理の進捗を示す呼状態データを取得する呼状態データ取得制御と、を実行する
   ことを特徴とする処理装置。
4. 前記増設した処理装置は、第１の処理装置と、第２の処理装置と、を少なくとも含み、
   前記第１の処理装置が、
   前記管理情報取得制御において、前記第１の処理装置に払い出された処理装置識別子、および前記第２の処理装置に払い出された処理装置識別子を含む前記管理情報を、前記振り分け装置から取得し、
   前記削除制御において、前記第１の処理装置に払い出された処理装置識別子だけでなく、前記呼状態データ取得制御を実行しても前記振り分け装置から取得したメッセージに対応する呼状態データを取得できなかったことにより、増設した処理装置であると確認された前記第２の処理装置に払い出された処理装置識別子も、前記管理情報から削除する
   ことを特徴とする請求項３に記載の処理装置。
5. クライアントにサービスを提供する複数の処理装置と、コンシステント・ハッシュ法により前記クライアントから得られるメッセージを前記処理装置に振り分ける複数の振り分け装置と、が通信可能に接続されている分散システムの処理装置を、コンピュータとして機能させる状態管理プログラムであって、
   前記分散システムに増設した処理装置に、
   前記コンシステント・ハッシュ法により、当該増設した処理装置を含む処理装置ごとに払い出された処理装置識別子を含む管理情報を、前記振り分け装置から取得する管理情報取得処理と、
   前記振り分け装置から前記メッセージを取得すると、前記取得した管理情報から、当該増設した処理装置に払い出された処理装置識別子を削除する削除処理と、
   前記削除後の管理情報に基づいて、前記取得したメッセージの呼処理を担当していた処理装置を特定する担当特定処理と、
   前記特定した処理装置から、前記取得したメッセージの呼処理の進捗を示す呼状態データを取得する呼状態データ取得処理と、を実行させる
   ことを特徴とする状態管理プログラム。
6. 前記増設した処理装置は、第１の処理装置と、第２の処理装置と、を少なくとも含み、
   前記第１の処理装置に、
   前記管理情報取得処理において、前記第１の処理装置に払い出された処理装置識別子、および前記第２の処理装置に払い出された処理装置識別子を含む前記管理情報を、前記振り分け装置から取得させ、
   前記削除処理において、前記第１の処理装置に払い出された処理装置識別子だけでなく、前記呼状態データ取得処理を実行しても前記振り分け装置から取得したメッセージに対応する呼状態データを取得できなかったことにより、増設した処理装置であると確認された前記第２の処理装置に払い出された処理装置識別子も、前記管理情報から削除させる
   ことを特徴とする請求項５に記載の状態管理プログラム。

Images