JP7207145B2 - 情報処理装置、配送プログラムおよび分散処理システム - Google Patents

Description

本発明は、情報処理装置、配送プログラムおよび分散処理システムに関する。

パブリッシュ・サブスクライブモデルのデータ収集方法が知られている。このデータ収集方法では、サブスクライバが、ブローカを介してパブリッシャからのデータを取得する。パブリッシャは、データを提供する側であり、サブスクライバを意識することなく、ブローカにデータを送る。サブスクライバは、データを利用する側であり、パブリッシャを意識することなく、ブローカにデータを要求する。

また、ＩｏＴ（Internet of Things）の進展にともなって、エンドデバイスが生み出すデータ量が増加し、全てのデータの処理やデバイスの制御をクラウドで行うことが難しくなってきている。このため、エッジコンピューティングによる分散処理環境に注目が集まっている。エッジコンピューティングは、コンピュータネットワーク上で、利用者に近い場所に複数のエッジ装置を配置して、負荷の分散と通信の低遅延化を図る技術である。

これに関し、パブリッシュ・サブスクライブモデルにおける負荷分散に関連する技術が知られている。（例えば、特許文献１および特許文献２）

特開２０１７－２２４０３２号公報 特開２００９－１１０１６５号公報

しかしながら、エッジコンピューティングによる分散処理システムにおいて、パブリッシュ・サブスクライブモデルのデータ収集方法を用いる場合に、拠点間でサブスクライブの無駄な通信が発生することがある。

１つの側面では、本発明は、拠点間でのサブスクライブの通信量を削減することを目的とする。

本発明の一つの態様の情報処理装置は、外部拠点に配備されているプロキシからサブスクライブを受信した場合、自拠点内に配備されているブローカと、ブローカで受けているパブリッシュのトピックとを対応づけるブローカ管理情報において、サブスクライブで配送が要求されるトピックに対応づけられているブローカに、サブスクライブを転送する転送部、を含む。

拠点間でのサブスクライブの通信量を削減することができる。

例示的なパブリッシュ・サブスクライブモデルを示す図である。 ブローカの動作例を示す説明図である。 例示的な分散処理システムのシステム構成を示す説明図である。 拠点管理部およびプロキシを配備した例示的な分散処理システムを示す図である。 配送先提供依頼を例示する図である。 例示的な拠点管理情報を示す図である。 プロキシによるメッセージの宛先変更を例示する図である。 例示的な分散処理システムにおけるパブリッシャの増加を示す図である。 配備するプロキシとブローカとを増やした分散処理システムの構成を示す図である。 実施形態に係るサーバの機能ブロック構成を例示する図である。 実施形態に係るプロキシの機能ブロック構成を例示する図である。 実施形態に係る拠点管理情報を例示する図である。 実施形態に係るブローカ管理情報を例示する図である。 実施形態に係る拠点管理部が実行する配送先通知処理の動作フローを例示する図である。 実施形態に係るプロキシの制御部が実行するパブリッシュの配送処理の動作フローを例示する図である。 実施形態に係る代表プロキシに送信されるメッセージを例示する図である。 実施形態に係る代表プロキシとして動作するプロキシによるパブリッシュの配送処理の動作フローを例示する図である。 実施形態に係るプロキシの制御部が実行するサブスクライブの配送処理の動作フローを例示する図である。 実施形態に係る代表プロキシとして動作するプロキシの制御部が実行するサブスクライブの配送処理の動作フローを例示する図である。 実施形態に係る代表プロキシを介したパブリッシュの配送の流れを例示する図である。 実施形態に係る代表プロキシを介したサブスクライブの配送の流れを例示する図である。 実施形態に係るサーバ、エッジ装置ＥＧ、ゲートウェイ装置ＧＷなどを実現するためのコンピュータのハードウェア構成を例示する図である。

以下、図面を参照しながら、本発明のいくつかの実施形態について詳細に説明する。なお、複数の図面において対応する要素には同一の符号を付す。

上述のように、パブリッシュ・サブスクライブモデルのデータ収集方法が知られている。以下、図１および図２を参照して、例示的なパブリッシュ・サブスクライブモデルのデータ収集を説明する。

（パブリッシュ・サブスクライブモデル）
図１は、例示的なパブリッシュ・サブスクライブモデルを示す図である。パブリッシュ・サブスクライブモデルのデータ収集方法では、パブリッシャ１０１がパブリッシュしたデータは、ブローカ１０２を介してサブスクライバ１０３に提供される。

パブリッシャ１０１は、データを提供するものであるが、そのデータに関心のあるサブスクライバ１０３（例えば、アプリケーション）に関する情報は有していなくてもよく、ブローカ１０２のトピックを送信先としてデータを送信する。パブリッシャ１０１は、例えば、工場などに設置される生産機器、組立機器、センサ、カメラなどの機器である。パブリッシャ１０１は、これらの機器で収集されたデータをパブリケーションと呼ばれるメッセージ形式で生成し、これらのメッセージのトピックを定義して、ブローカ１０２に送信する。

また、サブスクライバ１０３は、データを要求するものである。サブスクライバ１０３は、データの収集を行うパブリッシャ１０１に関する情報は有していなくてもよく、ブローカ１０２にトピックの情報の配信を申し込んで、配信を申し込んだトピックに登録されるメッセージの配信を受ける。サブスクライバ１０３は、例えば、パブリッシャ１０１で取集されたデータを用いて実行される処理（アプリケーション）である。

続いて、ブローカ１０２の動作例について説明する。ブローカ１０２は、パブリッシャ１０１とサブスクライバ１０３との間でのデータのやり取りを仲介する。

図２は、ブローカ１０２の動作例を示す説明図である。図２において、各サブスクライバ１０３（＃１～＃４）は、ブローカ１０２に対して、トピックのデータを要求する登録を行う。また、各パブリッシャ１０１（＃１～＃３）は、トピックとデータとを含むメッセージ２０をブローカ１０２宛に送信する。

トピックは、データの特徴を表す情報であり、例えば、データのタイトル、種類、形式などを示す情報であってよい。

ブローカ１０２は、どのサブスクライバ１０３が、どのトピックのデータの配信を申し込んだかを管理している。図２の例では、ブローカ１０２は、トピックとサブスクライバＩＤとを対応付けて記憶する配信管理情報２００を用いて、サブスクライバ１０３とトピックとの対応関係を管理する。サブスクライバＩＤは、サブスクライバ１０３を一意に識別する識別子である。例えば、ブローカ１０２は、サブスクライバ１０３からトピックのデータの配信の申し込みを受けると、そのサブスクライバ１０３のサブスクライバＩＤを、配信の申し込みのあったトピックと対応づけて配信管理情報２００に登録する。

そして、ブローカ１０２は、例えば、パブリッシャ：＃１からのトピック１とデータとを含むメッセージ２０を受け付けると、トピック１のメッセージ・キューにメッセージ２０を入れる。そして、ブローカ１０２は、トピック１のメッセージ・キューに入れたメッセージ２０を先に入れたものから順に、配信管理情報２００を参照して、トピック１のデータを要求したサブスクライバ＃１，＃２宛に送る。

なお、以下の説明では、サブスクライバ１０３が、あるトピックのデータを要求する登録を行うこと、あるいは、あるトピックのデータを要求するメッセージ自体を「サブスクライブ」と呼ぶことがある。また、パブリッシャ１０１が、トピックとデータとを含むメッセージを送信すること、あるいは、トピックとデータとを含むメッセージ自体を「パブリッシュ」と呼ぶことがある。

このようなパブリッシュ・サブスクライブモデルのデータ収集方法は、例えば、データをどのように用いるかは決まっていないものの、次々とデータを収集していくようなシステムなどに利用されている。そして、例えば、図３に示すような、エッジコンピューティングによる分散処理システム３００において、パブリッシュ・サブスクライブモデルのデータ収集方法を用いることがある。

図３は、例示的な分散処理システム３００のシステム構成を示す説明図である。図３において、分散処理システム３００は、拠点Ｂ０～Ｂｎ（ｎ：１以上の自然数）を含む。拠点Ｂ０～Ｂｎは、一例ではネットワークごとに区分されていてよい。例えば、拠点は、インターネット、キャリア網などの広域網とファイアウォールおよびゲートウェイ装置ＧＷを介して接続しているローカル網が設置される場所であってよく、拠点間の通信は外部の広域網を介して行われてよい。例えば、分散処理システム３００において、拠点Ｂ０～Ｂｎの拠点間は、ネットワーク３１０を介して相互に通信可能に接続される。ネットワーク３１０は、例えば、広域通信網（ＷＡＮ：Wide Area Network）、インターネットである。

拠点Ｂ０は、サーバ３０１を含む。サーバ３０１は、例えば、クラウドコンピューティングのサーバコンピュータである。以下の説明では、拠点Ｂ０を「クラウド」と表記する場合がある。

また、拠点Ｂ０を除く拠点Ｂ１～Ｂｎのうちの任意の拠点を「拠点Ｂｉ」と表記する場合がある（ｉ＝１，２，…，ｎ）。拠点Ｂｉは、エッジ装置ＥＧと、ゲートウェイ装置ＧＷとを含む。拠点Ｂｉにおいて、エッジ装置ＥＧと、ゲートウェイ装置ＧＷとは、ネットワーク３２０を介して相互に通信可能に接続される。ネットワーク３２０は、例えば、構内通信網（ＬＡＮ：Local Area Network）である。

ゲートウェイ装置ＧＷは、近距離無線通信または有線通信により、デバイスｄｖから送出されるデータを受信する情報処理装置である。近距離無線通信としては、無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）などを利用した通信が挙げられる。また、ゲートウェイ装置ＧＷは、デバイスｄｖから受信したデータを、他のコンピュータ（例えば、エッジ装置ＥＧ、サーバ３０１）に中継する機能を有する。ゲートウェイ装置ＧＷは、例えば、無線ＬＡＮやＢｌｕｅｔｏｏｔｈ（登録商標）などのアクセスポイントであってよく、また、サーバやパーソナルコンピュータ（ＰＣ）であってもよい。また、デバイスｄｖは、例えば、工場などに設置される生産機器、組立機器、センサ、カメラなどの機器である。

エッジ装置ＥＧは、各種処理を行う情報処理装置である。エッジ装置ＥＧは、エッジコンピューティングにおけるエッジサーバであり、サーバ３０１（クラウド）に比べて、デバイスｄｖやユーザに近い位置に配置される。エッジ装置ＥＧは、例えば、サーバ、ＰＣ、アクセスポイントなどである。

なお、図３の例では、拠点Ｂｉ内のエッジ装置ＥＧおよびゲートウェイ装置ＧＷを、それぞれ１台だけ示しているが、実施形態はこれに限定されるものではない。例えば、拠点Ｂｉは、２台以上のエッジ装置ＥＧおよびゲートウェイ装置ＧＷを含んでいてもよい。また、サーバ３０１は、複数のコンピュータにより実装されてもよい。

そして、例えば、以上のような分散処理システム３００において、デバイスｄｖは、パブリッシャ１０１として動作してよい。また、例えば、サーバ３０１、エッジ装置ＥＧ、およびゲートウェイ装置ＧＷには、サブスクライバ１０３として動作する処理（例えば、アプリケーション）が配備されていてよい。また更に、サーバ３０１、エッジ装置ＥＧ、およびゲートウェイ装置ＧＷには、ブローカ１０２として動作するアプリケーションが配備されていてもよい。

ここで、例えば、以上のような分散処理システム３００において、パブリッシュ・サブスクライブモデルのデータ収集方法を用いる場合に、クラウド上だけでなく、拠点側にもブローカ１０２を配置することが望ましいことがある。

例えば、ある拠点Ｂｉに配置されているパブリッシャ１０１（例えば、デバイスｄｖ）がパブリッシュするデータを利用するサブスクライバ１０３（例えば、処理（アプリケーション））を、クラウド上からその拠点Ｂｉに移動したとする。この場合にも、ブローカ１０２がクラウドにあると、データを一旦クラウドに送ることになり、拠点側にサブスクライバ１０３を移動した効果が得られなくなる恐れがある。そのため、クラウドからサブスクライバ１０３を移動した拠点側にもブローカ１０２を配置することが望ましい。

一方で、パブリッシャ１０１となる各拠点内のデバイス（例えば、デバイスｄｖ）は、メッセージ（パブリッシュ）の宛先を変更することが難しいことがある。例えば、パブリッシャ１０１となる各拠点内のデバイスｄｖは、分散処理システム３００のサーバ３０１からの遠隔制御を受け付けないことがある。この場合、拠点側にブローカ１０２を移動した際に、デバイスｄｖのメッセージ（パブリッシュ）の宛先を、クラウドのブローカ１０２から拠点側のブローカ１０２に変更することが難しいことがある。

このため、例えば、クラウドにメッセージの配送先を管理する拠点管理部４０１を配備し、また、拠点にプロキシ４０２を配備して、プロキシ４０２でメッセージの配送先を制御することが考えられる。

図４は、拠点管理部４０１およびプロキシ４０２を配備した例示的な分散処理システム３００を示す図である。なお、プロキシ４０２は、一例では、サーバ３０１、エッジ装置ＥＧ、およびゲートウェイ装置ＧＷにおいて、アプリケーションとして配備されてよい。

図４の例では、拠点Ｂ０（クラウド）上のサーバ３０１には、拠点管理部４０１、およびプロキシ４０２が配備されている。また、サーバ３０１には、ブローカ１０２と、サブスクライバ１０３としてトピックＢのデータを用いて処理を実行する処理ＢおよびトピックＣのデータを用いて処理を実行する処理Ｃとが配備されている。

また、例えば、図４では、拠点Ｂ１には、パブリッシャ１０１としてセンサＡおよびセンサＢと、ブローカ１０２と、サブスクライバ１０３としてトピックＡのデータを用いて処理を実行する処理Ａと、プロキシ４０２とが配備されている。拠点Ｂ２には、プロキシ４０２と、パブリッシャ１０１としてセンサＣとが配備されている。

続いて、図４を参照して、プロキシ４０２を介したメッセージの配送の流れについて説明する。

（パブリッシュのプロキシを介した配送例）
まず、パブリッシュのプロキシ４０２を介した配送例について説明する。例えば、パブリッシャ１０１は、プロキシ４０２に宛ててメッセージ（パブリッシュ）を送信するように設定されてよい。例えば、図４の拠点Ｂ１では、パブリッシャ１０１であるセンサＡは、センサで検出したデータとそのデータのトピックとを含むパブリッシュをプロキシ４０２に宛てて送信する（図４の（１ａ））。

プロキシ４０２は、例えば、データを受信すると、データの配送先となるブローカ１０２を、クラウドの拠点管理部４０１に問い合わせる（図４の（２ａ））。

図５は、プロキシ４０２がメッセージの配送先を問い合わせるために拠点管理部４０１に送信する配送先提供依頼５００を例示する図である。配送先提供依頼５００は、例えば、メッセージ種別と、拠点ＩＤと、トピックとを含んでよい。メッセージ種別は、プロキシ４０２が配送先の問い合わせを行うメッセージの種別を示す情報である。例えば、パブリッシャ１０１から通知されたパブリッシュの配送先を拠点管理部４０１に問い合わせる場合、プロキシ４０２は、メッセージ種別にパブリッシュを示す情報を登録してよい。また、例えば、サブスクライバ１０３から通知されたサブスクライブの配送先を拠点管理部４０１に問い合わせる場合、プロキシ４０２は、メッセージ種別にサブスクライブを示す情報を登録してよい。拠点ＩＤは、例えば、配送先提供依頼５００の送信元のプロキシ４０２が配備されている拠点を一意に識別する識別子である。トピックは、例えば、メッセージ種別がパブリッシュである場合には、パブリッシャ１０１から通知されたデータのトピックを示す情報であってよい。パブリッシャ１０１から通知されたデータのトピックは、一例では、パブリッシャ１０１から通知されたデータとともに、パブリッシャ１０１から通知されてよい。また、トピックは、例えば、メッセージ種別がサブスクライブである場合には、サブスクライバ１０３から通知されたサブスクライブでデータの配送が要求されるトピックを示す情報であってよい。

そして、図４の（２ａ）において、拠点管理部４０１は、例えば、プロキシ４０２から配送先提供依頼５００を受信すると、受信した配送先提供依頼５００に含まれる情報と、拠点管理情報６００とに基づいて、メッセージの配送先を特定する。

図６は、例示的な拠点管理情報６００を示す図である。拠点管理情報６００は、例えば、各拠点に配備されているプロキシ４０２、ブローカ１０２、サブスクライバ１０３、およびパブリッシャ１０１などに関する情報を管理する情報であってよい。図６では、拠点管理情報６００には、例えば、拠点ＩＤ、プロキシアドレス、ブローカアドレス、サブスクライバ、およびトピックが対応づけられたエントリが登録されている。拠点管理情報６００の拠点ＩＤは、例えば、拠点を一意に識別する識別子である。拠点管理情報６００のプロキシアドレスは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているプロキシ４０２のアドレスである。拠点管理情報６００のブローカアドレスは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているブローカ１０２のアドレスである。なお、ブローカアドレス「－（ｎｕｌｌ）」は、例えば、エントリの拠点ＩＤで識別される拠点に、ブローカ１０２が配備されていないことを示してよい。拠点管理情報６００のサブスクライバは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているサブスクライバ１０３を示す情報である。サブスクライバ「－」は、エントリの拠点ＩＤで識別される拠点にサブスクライバ１０３が配備されていないことを示す。拠点管理情報６００のトピックは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているブローカ１０２が、パブリッシャ１０１から受信しているパブリッシュのトピックを示す情報である。トピック「－」は、エントリの拠点ＩＤで識別される拠点でブローカ１０２が受信しているパブリッシュがないことを示す。

そして、拠点管理情報６００を参照することで、拠点管理部４０１は、配送先提供依頼５００で問い合わせを受けたメッセージの配送先を特定することができる。例えば、拠点管理部４０１は、メッセージ種別がパブリッシュである場合、配送先提供依頼５００の送信元拠点と一致する拠点ＩＤを有する拠点管理情報６００のエントリのブローカアドレスを配送先として特定し、配送先提供依頼５００の送信元のプロキシ４０２に通知する。そして、プロキシ４０２は、拠点管理部４０１からの応答で通知された配送先にメッセージ（パブリッシュ）の宛先を変更してメッセージを送信する（図４の（３ａ））。

図７は、プロキシ４０２によるメッセージの宛先変更を例示する図である。図７（ａ）は、パブリッシュを例示している。センサなどのパブリッシャ１０１から出力されるパブリッシュは、例えば、プロキシアドレス、パブリッシャアドレス、トピック、およびデータを含んでよい。プロキシアドレスは、例えば、パブリッシュの宛先となるプロキシ４０２のアドレスである。パブリッシャアドレスは、パブリッシュの送信元のパブリッシャ１０１のアドレスである。トピックは、パブリッシュのデータのトピックである。データは、パブリッシュの送信元のパブリッシャ１０１で収集されたデータである。

そして、プロキシ４０２は、拠点管理部４０１からの応答で通知された配送先にメッセージ（パブリッシュ）の宛先を変更してメッセージを配送してよい。図７（ｂ）は、宛先の変更後のパブリッシュを例示しており、プロキシアドレスが、拠点管理部４０１からの応答で通知された配送先のブローカアドレスに変更されている。

以上のように、例えば、分散処理システム３００においてブローカ１０２を別の拠点に移動した場合にも、パブリッシャ１０１が送信するパブリッシュの宛先を変更しなくても、パブリッシュをプロキシ４０２を介して適切なブローカ１０２に配送することができる。

なお、拠点Ｂ２のように、ブローカ１０２が配備されていない場合には、拠点管理部４０１は、拠点Ｂ２のプロキシ４０２からの配送先提供依頼５００に対して、クラウド（拠点Ｂ０）に配備されているブローカ１０２のブローカアドレスを通知してよい。この場合、拠点Ｂ２のプロキシ４０２は、クラウド（拠点Ｂ０）のブローカ１０２にパブリッシュを配送してよい（図４の（４ａ））。

（サブスクライブのプロキシを介した配送例）
続いて、サブスクライブのプロキシ４０２を介した配送例を説明する。サブスクライブの配送もプロキシ４０２で制御することができる。例えば、サブスクライバ１０３は、プロキシ４０２に宛ててメッセージ（サブスクライブ）を送信するように設定されていてよい。図４の例では、拠点Ｂ０の処理Ｂのサブスクライバ１０３は、トピックＢのデータを要求するサブスクライブをプロキシ４０２に宛てて送信する（図４の（１ｂ））。

プロキシ４０２は、例えば、サブスクライブを受信すると、サブスクライブの配送先となるブローカ１０２を、クラウドの拠点管理部４０１に問い合わせる（図４の（２ｂ））。例えば、プロキシ４０２は、図５で示した配送先提供依頼５００を拠点管理部４０１に送信して、サブスクライブの配送先を問い合わせてよい。なお、サブスクライブの配送先の問い合わせでは、配送先提供依頼５００のメッセージ種別には、サブスクライブを示す情報が登録されてよい。また、拠点ＩＤは、例えば、配送先提供依頼５００の送信元のプロキシ４０２が配備されている拠点を一意に識別する識別子である。配送先提供依頼５００のトピックには、例えば、サブスクライブで配送が要求されるトピックが登録されてよい。

拠点管理部４０１は、例えば、プロキシ４０２から配送先提供依頼５００を受信すると、配送先提供依頼５００のメッセージ種別が、パブリッシュか、またはサブスクライブかを特定する。そして、例えば、メッセージ種別がサブスクライブである場合、拠点管理部４０１は、配送先提供依頼５００のトピックと一致するトピックを含む拠点管理情報６００のエントリに含まれるブローカアドレスを配送先として特定する。そして、拠点管理部４０１は、特定した配送先のブローカアドレスを、配送先提供依頼５００の送信元のプロキシ４０２に通知する。

そして、プロキシ４０２は、拠点管理部４０１からの応答で通知された配送先にメッセージ（サブスクライブ）の宛先を変更してメッセージを送信する（図４の（３ｂ））。

図７（ｃ）は、サブスクライブを例示している。例えば、サブスクライバ１０３がデータを要求するために発行するサブスクライブは、プロキシアドレス、サブスクライバアドレス、サブスクライバＩＤ、およびトピックを含んでよい。プロキシアドレスは、例えば、サブスクライバ１０３からのサブスクライブの宛先となるプロキシ４０２のアドレスである。サブスクライバアドレスは、例えば、サブスクライブの送信元のサブスクライバ１０３のアドレスである。サブスクライバＩＤ(identifier)は、例えば、サブスクライブの送信元のサブスクライバ１０３を一意に識別する識別情報である。トピックは、例えば、サブスクライブでデータの送信が要求されるトピックを示す情報である。

そして、プロキシ４０２は、拠点管理部４０１からの応答で通知された配送先にメッセージ（サブスクライブ）の宛先を変更してメッセージを配送してよい。図７（ｄ）は、宛先の変更後のサブスクライブを例示しており、プロキシアドレスが、拠点管理部４０１からの応答で通知された配送先のブローカアドレスに変更されている。

以上のように、例えば、分散処理システム３００においてブローカ１０２を別の拠点に移動した場合に、サブスクライバ１０３のサブスクライブの送信先を変更しなくても、サブスクライブをプロキシ４０２を介して適切なブローカ１０２に配送することができる。例えば、図４では、処理Ｂが発行したトピックＢのデータを要求するサブスクライブは、拠点管理情報６００においてトピックにＢが登録されている拠点１に配備されているブローカ１０２（アドレス４）に配送される（図４の（３ｂ））。一方、処理Ｃが発行したトピックＣのデータを要求するサブスクライブは、拠点管理情報６００においてトピックにＣが登録されている拠点０に配備されているブローカ１０２（アドレス３）に配送される（図４の（３ｂ’））。

以上で述べたように、分散処理システム３００においてある拠点から別の拠点へと拠点をまたいでパブリッシャ１０１、ブローカ１０２、およびサブスクライバ１０３の配置を変更したとしても、プロキシ４０２を用いてメッセージを適切な配送先に配送することができる。

しかしながら、近年、例えば、ＩｏＴデバイスなどのセンサを備えるデバイスは増加傾向にあり、それにともない、拠点に配備されるセンサなどのパブリッシャ１０１の数も、図８に示すように、増加することがある。なお、パブリッシャ１０１の増加にともない、それらのパブリッシャ１０１を収容するゲートウェイ装置ＧＷの数も増加してもよい。この場合、パブリッシャ１０１からプロキシ４０２を介してブローカ１０２に配送されるデータの量が増加するため、プロキシ４０２およびブローカ１０２にかかる処理負荷が高くなることがある。その結果、転送遅延などが発生してしまうことがあり、リアルタイム性が要求されるＣＰＳ（Cyber-Physical System）アプリケーションなどでは問題になることがある。

そのため、例えば、センサの数の多い拠点において、プロキシ４０２およびブローカ１０２の数を増やして、処理負荷を分散させることが考えられる。図９は、拠点Ｂ１において配備するプロキシ４０２とブローカ１０２とを増やした分散処理システム３００の構成を示す図である。図９の拠点Ｂ１に示すように、配備するブローカ１０２およびプロキシ４０２を増やすことで、増やしたブローカ１０２およびプロキシ４０２に処理を分散させることができる。そのため、ブローカ１０２およびプロキシ４０２の１つあたりの処理量を削減することが可能になる。

しかしながら、ブローカ１０２を増やすと、サブスクライブの配信先が、増設したブローカ１０２の分増加してしまうことがある。例えば、図９に示すように、拠点Ｂ０（クラウド）に配備されているサブスクライバ１０３：処理ＢがトピックＢのデータの配送を要求するサブスクライブをプロキシ４０２に送信したとする（図９の（１））。プロキシ４０２は、サブスクライブを受信すると、サブスクライブの配送先を拠点管理部４０１に問い合わせる（図９の（２））。ここで、増設したブローカ１０２は、例えば、拠点Ｂ１にもともと設置されているプロキシ４０２と同じトピックを処理するブローカ１０２であるとする。この場合、配送先提供依頼５００に対する応答では、もともと設置されているブローカ１０２のブローカアドレスに加えて、増設されたブローカ１０２のブローカアドレスも通知される。その結果、拠点Ｂ０のプロキシ４０２は、拠点Ｂ１のブローカ１０２と、増設されたブローカ１０２の双方に、トピックＢのデータの配送を要求するサブスクライブを送信する（図９の（３））。この場合、拠点Ｂ０（クラウド）から１つの拠点Ｂ１に対して同じサブスクライブを複数送信しており、重複したデータを同じ拠点間で複数送信することは無駄な拠点間の通信となる。そのため、拠点間での重複したサブスクライブの配送を抑制することのできる技術の提供が望まれている。

以下で述べる実施形態では、プロキシ４０２は、拠点管理部４０１に問い合わせて特定したサブスクライブの配送先が、自拠点とは異なる外部拠点である場合、配送先の拠点を代表する代表プロキシにサブスクライブを送信する。そのため、例えば、図９の（３）において、拠点間で複数のブローカ１０２に対して配送しているサブスクライブを、代表プロキシに集約して配送することができため、拠点間での重複したサブスクライブの配送を抑制することができる。なお、代表プロキシは、サブスクライブを受信すると、代表プロキシと同じ拠点に配備されているブローカ１０２にサブスクライブを配送する。以下、実施形態を更に詳細に説明する。

図１０は、実施形態に係るサーバ３０１の機能ブロック構成を例示する図である。サーバ３０１は、例えば、制御部１００１、記憶部１００２、および通信部１００３を含む。制御部１００１は、例えば拠点管理部４０１などとして動作する。また、制御部１００１は、例えば、サーバ３０１に配備されているブローカ１０２、サブスクライバ１０３、およびプロキシ４０２として動作してもよい。サーバ３０１の記憶部１００２は、例えば、後述する拠点管理情報１２００などの情報を記憶していてよい。これらの各部の詳細及び記憶部１００２に格納されている情報の更なる詳細については後述する。

図１１は、実施形態に係るプロキシ４０２の機能ブロック構成を例示する図である。なお、プロキシ４０２は、例えば、サーバ３０１、エッジ装置ＥＧ、およびゲートウェイ装置ＧＷなどに実装されてよい。プロキシ４０２は、例えば、制御部１１０１、記憶部１１０２、および通信部１１０３を含む。制御部１１０１は、例えば転送部１１１１および取得部１１１２などとして動作する。プロキシ４０２の記憶部１１０２は、例えば、後述するように、代表プロキシとして動作する場合には、ブローカ管理情報１３００などの情報を記憶していてよい。これらの各部の詳細及び記憶部１１０２に格納されている情報の更なる詳細については後述する。

図１２は、実施形態に係る拠点管理情報１２００を例示する図である。拠点管理情報１２００は、例えば、各拠点に配備されているプロキシ４０２、ブローカ１０２、サブスクライバ１０３、およびパブリッシャ１０１などに関する情報を管理する情報であってよい。図１２の例では、拠点管理情報１２００には、拠点ＩＤ、代表プロキシアドレス、ブローカアドレス、サブスクライバ、およびトピックが対応づけられたエントリが登録されている。拠点管理情報１２００の拠点ＩＤは、例えば、拠点を一意に識別する識別子である。拠点管理情報１２００の代表プロキシアドレスは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているプロキシ４０２を代表する代表プロキシのアドレスである。拠点管理情報１２００のブローカアドレスは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているブローカ１０２のアドレスである。なお、ブローカアドレス「－（ｎｕｌｌ）」は、例えば、エントリの拠点ＩＤで識別される拠点にブローカ１０２が配備されていないことを示してよい。拠点管理情報１２００のサブスクライバは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているサブスクライバを示す情報である。サブスクライバ「－」は、エントリの拠点ＩＤで識別される拠点にサブスクライバ１０３が配備されていないことを示す。拠点管理情報１２００のトピックは、例えば、エントリの拠点ＩＤで識別される拠点に配備されているブローカ１０２が、パブリッシャ１０１から受信しているパブリッシュのトピックを示す情報である。トピック「－」は、エントリの拠点ＩＤで識別される拠点でブローカ１０２が受けるパブリッシュがないことを示す。なお、拠点に複数のブローカ１０２が配備される場合、拠点管理情報１２００のブローカアドレスには、拠点に配備された全てのブローカ１０２のブローカアドレスが登録されてよい。例えば、ユーザが分散処理システム３００において、拠点Ｂ１にブローカ１０２を追加して配備する場合、ユーザは、拠点管理情報１２００の拠点ＩＤ：Ｂ１のエントリのブローカアドレスに、追加して配備したブローカ１０２のブローカアドレスを追加してよい。

また、図１３は、ブローカ管理情報１３００を例示する図である。ブローカ管理情報１３００は、例えば、代表プロキシとして動作するプロキシ４０２の記憶部１１０２に記憶されていてよい。ブローカ管理情報１３００には、例えば、ブローカアドレスおよびトピックが対応付けられたエントリが登録されている。ブローカ管理情報１３００のブローカアドレスには、例えば、ブローカ管理情報１３００を記憶する代表プロキシと同じ拠点に配備されているブローカ１０２のブローカアドレスが登録されてよい。また、ブローカ管理情報１３００のトピックには、エントリのブローカアドレスで識別されるブローカ１０２で受信されるパブリッシュのトピックを示す情報が登録されてよい。

続いて、実施形態に係る拠点管理部４０１が実行する配送先通知処理を説明する。図１４は、実施形態に係る拠点管理部４０１が実行する配送先通知処理の動作フローを例示する図である。例えば、拠点管理部４０１は、プロキシ４０２から配送先提供依頼５００を受信すると、図１４の動作フローを開始してよい。

ステップ１４０１（以降、ステップを“Ｓ”と記載し、例えば、Ｓ１４０１と表記する）において拠点管理部４０１は、受信した配送先提供依頼５００のメッセージ種別がパブリッシュであるか、サブスクライブであるかを判定する。配送先提供依頼５００のメッセージ種別がパブリッシュである場合、フローはＳ１４０２に進む。

Ｓ１４０２において拠点管理部４０１は、拠点管理情報１２００を参照し、配送先提供依頼５００の送信元拠点と拠点管理情報１２００において対応づけられている代表プロキシと、ブローカアドレスとを特定する。なお、Ｓ１４０２において拠点管理部４０１は、配送先提供依頼５００の送信元拠点を含む拠点管理情報１２００のエントリに、配送先提供依頼５００で通知されたトピックが登録されていない場合、配送先提供依頼５００で通知されたトピックを登録してよい。

Ｓ１４０３において拠点管理部４０１は、特定した代表プロキシと、ブローカアドレスとを含む応答を、配送先提供依頼５００を送信してきたプロキシ４０２に返信し、本動作フローは終了する。

一方、Ｓ１４０１において配送先提供依頼５００のメッセージ種別がサブスクライブである場合、フローはＳ１４０４に進む。

Ｓ１４０４において拠点管理部４０１は、拠点管理情報１２００を参照し、配送先提供依頼５００のトピックと拠点管理情報１２００において対応づけられている拠点と代表プロキシアドレスとブローカアドレスとを特定する。

Ｓ１４０５において拠点管理部４０１は、特定した拠点と代表プロキシアドレスとブローカアドレスとを含む応答を、配送先提供依頼５００を送信してきたプロキシ４０２に返信し、本動作フローは終了する。

以上で述べたように、図１４の動作フローによれば、拠点管理部４０１は、配送先提供依頼５００に応じて、メッセージの配送先に関する情報をプロキシ４０２に提供することができる。

また、図１５は、実施形態に係るプロキシ４０２の制御部１１０１が実行するパブリッシュの配送処理の動作フローを例示する図である。プロキシ４０２の制御部１１０１は、例えば、パブリッシャ１０１からパブリッシュを受信すると、図１５の動作フローを開始してよい。

Ｓ１５０１においてプロキシ４０２の制御部１１０１は、受信したパブリッシュからトピックの情報を抽出する。Ｓ１５０２においてプロキシ４０２の制御部１１０１は、受信したパブリッシュの配送先を拠点管理部４０１に問い合わせる。例えば、プロキシ４０２の制御部１１０１は、Ｓ１５０１で抽出したトピックを含む配送先提供依頼５００を生成して拠点管理部４０１に送信し、パブリッシュの配送先を問い合わせてよい。

Ｓ１５０３においてプロキシ４０２の制御部１１０１は、拠点管理部４０１からの応答から、プロキシ４０２が配備されている拠点に複数のブローカ１０２が配備されているか否かを判定する。例えば、拠点管理部４０１からの応答に複数のブローカアドレスが含まれている場合、プロキシ４０２の制御部１１０１は、Ｓ１５０３においてＹｅｓと判定してよく、フローはＳ１５０４に進む。

Ｓ１５０４においてプロキシ４０２の制御部１１０１は、拠点管理部４０１からの応答に含まれる代表プロキシアドレスを用いて、代表プロキシとして動作するプロキシ４０２にパブリッシュ１６０１を送信し、本動作フローは終了する。

図１６は、実施形態に係る代表プロキシに送信されるメッセージを例示する図である。図１６（ａ）は、Ｓ１５０４でプロキシ４０２の制御部１１０１が、代表プロキシアドレスに送信するパブリッシュ１６０１を例示している。パブリッシュ１６０１は、例えば、代表プロキシアドレス、ブローカアドレス、パブリッシャアドレス、トピック、およびデータを含んでよい。パブリッシュ１６０１の代表プロキシアドレスは、拠点管理部４０１からの応答で通知された代表プロキシアドレスである。また、パブリッシュ１６０１のブローカアドレスは、例えば、拠点管理部４０１からの応答で通知されたブローカアドレスである。パブリッシュ１６０１のパブリッシャアドレス、トピック、データはそれぞれ、例えば、図７（ａ）のパブリッシュのパブリッシャアドレス、トピック、データと同様の情報であってよい。

一方、Ｓ１５０３において例えば、拠点管理部４０１からの応答に含まれるブローカアドレスが１つである場合、Ｓ１５０３においてＮｏと判定してよく、フローはＳ１５０５に進む。

Ｓ１５０５においてプロキシ４０２の制御部１１０１は、応答で通知されたブローカアドレスにパブリッシュを送信し、本動作フローは終了する。Ｓ１５０５で送信されるパブリッシュは、例えば、図７（ｂ）に示すパブリッシュであってよい。

以上で述べたように、プロキシ４０２の制御部１１０１は、パブリッシュを受信した場合に、パブリッシュの配送先のブローカ１０２が拠点内に複数ある場合には、代表プロキシにパブリッシュを転送する。一方、プロキシ４０２の制御部１１０１は、パブリッシュの配送先のブローカ１０２が拠点内に１つである場合には、そのブローカ１０２にパブリッシュを配送する。

続いて、代表プロキシとして動作するプロキシ４０２の制御部１１０１が、他のプロキシ４０２からパブリッシュ１６０１を受信した場合に実行するパブリッシュの配送処理について説明する。図１７は、実施形態に係る代表プロキシとして動作するプロキシ４０２によるパブリッシュの配送処理の動作フローを例示する図である。

Ｓ１７０１においてプロキシ４０２の制御部１１０１は、パブリッシュ１６０１に含まれるブローカアドレスおよびトピックの情報を読み出す。

Ｓ１７０２においてプロキシ４０２の制御部１１０１は、読み出したブローカアドレスおよびトピックを含むエントリが、記憶部１１０２に記憶されているブローカ管理情報１３００に登録されているか否かを判定する。読み出したブローカアドレスおよびトピックを含むエントリが、ブローカ管理情報１３００に登録されていない場合（Ｓ１７０２がＮｏ）、フローはＳ１７０３に進む。

Ｓ１７０３においてプロキシ４０２の制御部１１０１は、ブローカ管理情報１３００に、読み出したブローカアドレスおよびトピックを対応づけたエントリを登録し、フローはＳ１７０４に進む。なお、例えば、パブリッシュ１６０１から読み出したブローカアドレスを含むエントリが既にブローカ管理情報１３００に含まれている場合には、プロキシ４０２の制御部１１０１は、そのエントリにパブリッシュ１６０１から読み出したトピックを追加してよい。

また、Ｓ１７０２において読み出したブローカアドレスおよびトピックを含むエントリが、ブローカ管理情報１３００に登録されている場合（Ｓ１７０２がＹｅｓ）、フローはＳ１７０４に進む。

Ｓ１７０４においてプロキシ４０２の制御部１１０１は、パブリッシュ１６０１で指定されるトピックとブローカ管理情報１３００において対応づけられているブローカアドレスのブローカ１０２にパブリッシュ１６０１を配送し、本動作フローは終了する。なお、パブリッシュ１６０１で指定されるトピックとブローカ管理情報１３００において対応づけられているブローカアドレスが複数登録されている場合には、プロキシ４０２の制御部１１０１は、パブリッシュ１６０１を複数のブローカ１０２のうちの一部に送信してもよい。一例では、プロキシ４０２の制御部１１０１は、所定期間に処理するパブリッシュ１６０１の数が均一に近づくように、複数のブローカ１０２のうちのいずれかにパブリッシュ１６０１を振り分けてよい。それにより、拠点内の複数のブローカ１０２が処理するパブリッシュ１６０１の数を平均化して、負荷を分散させることができる。

以上の図１７で述べた動作フローによれば、代表プロキシとして動作するプロキシ４０２の制御部１１０１は、パブリッシュ１６０１を拠点内のブローカ１０２に配送することができる。また、図１７の動作フローによれば、代表プロキシとして動作するプロキシ４０２の制御部１１０１は、拠点内のブローカ１０２と、拠点内のパブリッシャ１０１が送信したパブリッシュのトピックの情報とを、ブローカ管理情報１３００に登録することができる。

続いて、プロキシ４０２の制御部１１０１が実行するサブスクライブの配送処理について説明する。

図１８は、実施形態に係るプロキシ４０２の制御部１１０１が実行するサブスクライブの配送処理の動作フローを例示する図である。例えば、プロキシ４０２の制御部１１０１は、サブスクライブを受信すると、図１８の動作フローを開始してよい。

Ｓ１８０１においてプロキシ４０２の制御部１１０１は、受信したサブスクライブの配送先を問い合わせる配送先提供依頼５００を拠点管理部４０１に送信し、その応答としてサブスクライブの配送先の情報を受信する。なお、拠点管理部４０１は、例えば、上述の図１４の動作フローのＳ１４０４～Ｓ１４０５の処理で応答を、配送先提供依頼５００を送付したプロキシ４０２に返信してよい。また、この応答は、例えば、サブスクライブで要求されるトピックと拠点管理情報１２００において対応づけられている拠点ＩＤと、代表プロキシアドレスと、ブローカアドレスとを含んでよい。

Ｓ１８０２においてプロキシ４０２の制御部１１０１は、応答で通知されるサブスクライブの配送先に自拠点が含まれるか否かを判定する。例えば、プロキシ４０２の制御部１１０１は、記憶部１１０２に記憶されている自拠点を識別するための拠点ＩＤと一致する拠点ＩＤが、拠点管理部４０１から受信した応答に含まれているか否かに基づいて、サブスクライブの配送先に自拠点が含まれるか否かを判定してよい。記憶部１１０２に記憶されている自拠点を識別するための拠点ＩＤと一致する拠点ＩＤが、拠点管理部４０１から受信した応答に含まれていない場合（Ｓ１８０２がＮｏ）、フローはＳ１８０４に進む。一方、記憶部１１０２に記憶されている自拠点を識別するための拠点ＩＤと一致する拠点ＩＤが、拠点管理部４０１から受信した応答に含まれている場合（Ｓ１８０２がＹｅｓ）、フローはＳ１８０３に進む。

Ｓ１８０３においてプロキシ４０２の制御部１１０１は、拠点管理部４０１から受信した応答に含まれるブローカアドレスにサブスクライブを配送し、フローはＳ１８０４に進む。なお、プロキシ４０２の制御部１１０１は、例えば、図７（ｄ）のサブスクライブを配送先のブローカ１０２に送信してよい。

Ｓ１８０４においてプロキシ４０２の制御部１１０１は、サブスクライブの配送先に外部拠点が含まれるか否かを判定する。例えば、プロキシ４０２の制御部１１０１は、記憶部１１０２に記憶されている自拠点を識別するための拠点ＩＤと異なる拠点ＩＤが、拠点管理部４０１から受信した応答に含まれているか否かに基づいて、サブスクライブの配送先に外部拠点が含まれるか否かを判定してよい。記憶部１１０２に記憶されている自拠点を識別するための拠点ＩＤと異なる拠点ＩＤが、拠点管理部４０１から受信した応答に含まれていない場合（Ｓ１８０４がＮｏ）、本動作フローは終了する。一方、記憶部１１０２に記憶されている自拠点を識別するための拠点ＩＤと異なる拠点ＩＤが、拠点管理部４０１から受信した応答に含まれている場合（Ｓ１８０４がＹｅｓ）、フローはＳ１８０５に進む。

Ｓ１８０５においてプロキシ４０２の制御部１１０１は、拠点管理部４０１から受信した応答に含まれている外部拠点の代表プロキシアドレスに、サブスクライブ１６０２を転送する。

図１６（ｂ）は、Ｓ１８０５でプロキシ４０２の制御部１１０１が、代表プロキシアドレスに転送するサブスクライブ１６０２を例示している。サブスクライブ１６０２は、例えば、代表プロキシアドレス、サブスクライバアドレス、サブスクライバＩＤ、およびトピックを含んでよい。サブスクライブ１６０２の代表プロキシアドレスは、例えば、拠点管理部４０１からの応答で通知された代表プロキシアドレスである。また、サブスクライブ１６０２のサブスクライバアドレス、サブスクライバＩＤ、トピックはそれぞれ、例えば、図７（ｄ）のサブスクライブのサブスクライバアドレス、サブスクライバＩＤ、トピックと同様の情報であってよい。

以上の図１８の動作フローによれば、プロキシ４０２の制御部１１０１は、サブスクライブを受信すると、自拠点内のブローカ１０２にサブスクライブを配送し、また、外部拠点の代表プロキシにサブスクライブを転送することができる。

続いて、代表プロキシとして動作するプロキシ４０２の制御部１１０１によるサブスクライブの配送処理を説明する。図１９は、代表プロキシとして動作するプロキシ４０２の制御部１１０１が実行するサブスクライブの配送処理の動作フローを例示する図である。例えば、プロキシ４０２の制御部１１０１は、外部拠点のプロキシ４０２からサブスクライブ１６０２を受信すると、図１９の動作フローを開始してよい。

Ｓ１９０１においてプロキシ４０２の制御部１１０１は、サブスクライブ１６０２のトピックと対応するブローカ１０２のブローカアドレスを特定する。例えば、プロキシ４０２の制御部１１０１は、サブスクライブ１６０２のトピックと一致するトピックが登録されているブローカ管理情報１３００のエントリのブローカアドレスを特定してよい。

Ｓ１９０２においてプロキシ４０２の制御部１１０１は、特定したブローカアドレスのブローカ１０２にサブスクライブを配送し、本動作フローは終了する。なお、プロキシ４０２の制御部１１０１は、例えば、図７（ｄ）のサブスクライブを配送先のブローカ１０２に送信してよい。

以上の図１９の動作フローによれば、代表プロキシとして動作するプロキシ４０２の制御部１１０１は、外部拠点から転送されてきたサブスクライブ１６０２を、自拠点内のブローカ１０２に配送することができる。

続いて、図２０は、上述した実施形態に係る代表プロキシを介したパブリッシュの配送の流れを例示する図である。

例えば、図２０の拠点Ｂ１においてプロキシ４０２（アドレス５）が、センサＡおよびセンサＢなどのパブリッシャ１０１からトピックＡのパブリッシュを受信したとする（図２０の（１））。

この場合、プロキシ４０２（アドレス５）は、拠点管理部４０１に配送先提供依頼５００を送信し、パブリッシュの配送先を問い合わせる（図２０の（２））。

プロキシ４０２（アドレス５）は、拠点管理部４０１からの問い合わせに対する応答に基づいてパブリッシュの配送先のブローカ１０２が複数あるか否かを判定する。そして、パブリッシュの配送先のブローカ１０２が複数ある場合、プロキシ４０２（アドレス５）は、拠点管理情報１２００に代表プロキシとして登録されているプロキシ４０２（アドレス１）にパブリッシュを転送する（図２０の（３））。

代表プロキシとして動作するプロキシ４０２（アドレス１）は、ブローカ管理情報１３００を参照し、拠点内のブローカ１０２（アドレス４．０，アドレス４．１）にパブリッシュを振り分けて配送する（図２０の（４））。

そのため、代表プロキシを介して、拠点内のブローカ１０２（アドレス４．０，アドレス４．１）にパブリッシュを分配することができ、拠点内のブローカ１０２のパブリッシュの処理にかかる負荷を低減することができる。

続いて、図２１は、上述した実施形態に係る代表プロキシを介したサブスクライブの配送の流れを例示する図である。

例えば、図２１の拠点Ｂ０（クラウド）においてプロキシ４０２（アドレス０）が、処理Ｂのサブスクライバ１０３からトピックＢのサブスクライブを受信したとする（図２１の（１））。

この場合、プロキシ４０２（アドレス０）は、拠点管理部４０１に配送先提供依頼５００を送信し、サブスクライブの配送先を問い合わせる（図２１の（２））。

プロキシ４０２（アドレス０）は、拠点管理部４０１からの応答で通知される配送先が外部拠点の拠点Ｂ１である場合、拠点管理情報１２００に代表プロキシとして登録されている拠点Ｂ１のプロキシ４０２（アドレス１）にサブスクライブを転送する（図２１の（３））。

代表プロキシとして動作するプロキシ４０２（アドレス１）は、ブローカ管理情報１３００に登録されているブローカ１０２のうちでトピックＢが登録されているブローカ１０２（アドレス４．０，アドレス４．１）にサブスクライブを配送する（図２１の（４））。

以上のように、拠点間でサブスクライブを配送する場合に、代表プロキシにサブスクライブを転送し、代表プロキシから拠点内のブローカ１０２にサブスクライブを配送することで、拠点間で通信されるサブスクライブの数を削減することができる。従って、実施形態によれば、例えば、拠点間でのサブスクライブの通信量を削減することができる。

なお、例えば、図２１の拠点Ｂ１においてプロキシ４０２（アドレス１）が、処理Ａのサブスクライバ１０３からトピックＡのサブスクライブを受信したとする（図２１の（１’））。

この場合、プロキシ４０２（アドレス１）は、拠点管理部４０１に配送先提供依頼５００を送信し、サブスクライブの配送先を問い合わせる（図２１の（２’））。

プロキシ４０２（アドレス０）は、拠点管理部４０１からの問い合わせに対する応答に基づいてサブスクライブの配送先が自拠点の拠点Ｂ１であるか否かを判定する。そして、サブスクライブの配送先が自拠点の拠点Ｂ１である場合、プロキシ４０２は、応答で受信したブローカアドレスのブローカ１０２（アドレス４．０，アドレス４．１）にサブスクライブを転送する（図２１の（３’））。

以上で述べたように、プロキシ４０２は、自拠点内のブローカ１０２にサブスクライブを配送する場合には、ブローカ１０２に直接サブスクライブを配送してよい。

以上で述べた上述の実施形態では、サブスクライブが拠点間で通信される場合、配送先に代表プロキシを用い、代表プロキシに拠点内でのブローカ１０２への配送を実行させる。即ち、例えば、外部ネットワークからのサブスクライブの受信は代表プロキシが代表して行い、代表プロキシがローカルネットワーク内のブローカに配送する。そのため、例えば、拠点内に複数のブローカ１０２が配備されている場合にも、拠点間でのサブスクライブの通信量を削減することができる。

以上において、実施形態を例示したが、実施形態はこれに限定されるものではない。例えば、上述の動作フローは例示であり、実施形態はこれに限定されるものではない。可能な場合には、動作フローは、処理の順番を変更して実行されてもよく、別に更なる処理を含んでもよく、又は、一部の処理が省略されてもよい。例えば、図１８のＳ１８０２からＳ１８０３の処理と、Ｓ１８０４からＳ１８０５の処理とは順序を入れ替えて実行してもよい。

また、上述の実施形態では、パブリッシュの配送先のブローカ１０２が複数ある場合に、自拠点内の代表プロキシにパブリッシュを転送し、代表プロキシがパブリッシュをブローカ１０２に振り分ける例を述べている。例えば、代表プロキシがパブリッシュをブローカ１０２に振り分けることで、拠点内の複数のブローカ１０２が処理するパブリッシュの数を均一にすることが可能である。しかしながら、別の実施形態では、プロキシ４０２は、拠点管理部４０１からの応答において、配送先のブローカ１０２が複数含まれている場合には、応答を受信したプロキシ４０２がパブリッシュを複数のブローカ１０２のいずれかに振り分けてもよい。

また、上述の実施形態において、拠点管理情報１２００の代表プロキシアドレスは、例えば、分散処理システム３００の管理者がサーバ３０１を介して登録してもよい。或いは、別の実施形態では、拠点管理情報１２００のエントリの拠点ＩＤで識別される拠点のプロキシ４０２から、拠点管理部４０１が初めてパブリッシュの配送先を問い合わせる配送先提供依頼５００を受信したとする。この場合に、拠点管理部４０１は、配送先提供依頼５００の送信元のプロキシ４０２のアドレスを、その拠点ＩＤのエントリの代表プロキシアドレスに登録してよい。この様に、最初にパブリッシュの配送先を問い合わせたプロキシ４０２を代表プロキシとすることで、分散処理システム３００の管理者が拠点管理情報１２００に代表プロキシを登録する手間を省くことができる。

また、上述の実施形態では、プロキシ４０２は、パブリッシュおよびサブスクライブなどのメッセージを受信すると、メッセージの配送先を拠点管理部４０１に問い合わせる例を述べているが、実施形態はこれに限定されるものではない。例えば、別の実施形態では、プロキシ４０２は、メッセージの宛先を拠点管理部４０１に問い合わせて、配送先の情報を得ると、その配送先を記憶部１１０２に記憶し、以降はその配送先に対象のメッセージを送信するように動作してよい。例えば、この様にすることで、メッセージの宛先を拠点管理部４０１に問い合わせる処理を削減することが可能である。

また、上述の実施形態では、拠点Ｂ０（クラウド）に配備されるサーバ３０１にサブスクライバ１０３、拠点管理部４０１、およびプロキシ４０２などが実装される例を述べているが、実施形態はこれに限定されるものではない。例えば、上述の実施形態でサーバ３０１が実行する処理は、複数の装置で分担して実行されてもよい。

また、上述の実施形態では、拠点Ｂ０（クラウド）から、拠点Ｂ１にサブスクライブを配送する際に、代表プロキシに転送する例を述べているが、実施形態はこれに限定されるものではない。別の例では、拠点Ｂｉから拠点Ｂ０へ配送されるサブスクライブの通信量が削減されてもよい。即ち、例えば、図２１において、拠点Ｂ０（クラウド）にもトピックＡのデータを提供するセンサＡなどのパブリッシャ１０１が配備されているとする。そして、プロキシ４０２（アドレス１）が、処理Ａのサブスクライバ１０３からトピックＡのデータを要求するサブスクライブを受信して、その配送先を拠点管理部４０１に問い合わせた際に、配送先に拠点Ｂ０（クラウド）のブローカ１０２が含まれているとする。この場合に、プロキシ４０２（アドレス１）は、外部の拠点Ｂ０（クラウド）の代表プロキシにサブスクライブを転送してよい。以上のように、実施形態では、例えば、拠点間でサブスクライブを転送する場合に、代表プロキシにサブスクライブを転送するため、配送先の拠点に複数のブローカ１０２が含まれている場合にも、拠点間で行われるサブスクライブの通信量を削減することができる。

図２２は、実施形態に係るサーバ３０１、エッジ装置ＥＧ、ゲートウェイ装置ＧＷなどを実現するためのコンピュータ（情報処理装置）２２００のハードウェア構成を例示する図である。なお、サーバ３０１、エッジ装置ＥＧ、ゲートウェイ装置ＧＷには、例えば、上述のブローカ１０２、サブスクライバ１０３、拠点管理部４０１、プロキシ４０２が配備され得る。また、一例では、サーバ３０１、エッジ装置ＥＧ、ゲートウェイ装置ＧＷに、パブリッシャ１０１が配備されてもよい。

図２２のコンピュータ２２００のハードウェア構成は、例えば、プロセッサ２２０１、メモリ２２０２、記憶装置２２０３、読取装置２２０４、通信インタフェース２２０６、及び入出力インタフェース２２０７を備える。なお、プロセッサ２２０１、メモリ２２０２、記憶装置２２０３、読取装置２２０４、通信インタフェース２２０６、入出力インタフェース２２０７は、例えば、バス２２０８を介して互いに接続されている。

プロセッサ２２０１は、例えば、シングルプロセッサであっても、マルチプロセッサやマルチコアであってもよい。プロセッサ２２０１は、メモリ２２０２を利用して例えば上述の動作フローの手順を記述したプログラムを実行することにより、上述したブローカ１０２、サブスクライバ１０３、拠点管理部４０１、プロキシ４０２などの各機能部の一部または全部の機能を提供する。例えば、サーバ３０１のプロセッサ２２０１は、記憶装置２２０３に格納されているプログラムを読み出して実行することで、拠点管理部４０１として動作する。また、例えば、プロキシ４０２が実装されるサーバ３０１、エッジ装置ＥＧ、ゲートウェイ装置ＧＷのプロセッサ２２０１は、記憶装置２２０３に格納されているプログラムを読み出して実行することで、転送部１１１１および取得部１１１２として動作する。

メモリ２２０２は、例えば半導体メモリであり、ＲＡＭ領域及びＲＯＭ領域を含んでいてよい。記憶装置２２０３は、例えばハードディスク、フラッシュメモリ等の半導体メモリ、又は外部記憶装置である。なお、ＲＡＭは、Random Access Memoryの略称である。また、ＲＯＭは、Read Only Memoryの略称である。

読取装置２２０４は、プロセッサ２２０１の指示に従って着脱可能記憶媒体２２０５にアクセスする。着脱可能記憶媒体２２０５は、例えば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ－ＲＯＭ、ＤＶＤ等）などにより実現される。なお、ＵＳＢは、Universal Serial Busの略称である。ＣＤは、Compact Discの略称である。ＤＶＤは、Digital Versatile Diskの略称である。

また、上述の記憶部１００２および記憶部１１０２は、例えばメモリ２２０２、記憶装置２２０３、及び着脱可能記憶媒体２２０５を含んでよい。例えば、サーバ３０１の記憶装置２２０３には、拠点管理情報１２００が格納されている。また、例えば、代表プロキシとして動作するエッジ装置ＥＧまたはゲートウェイ装置ＧＷの記憶装置２２０３には、ブローカ管理情報１３００が格納されている。

通信インタフェース２２０６は、プロセッサ２２０１の指示に従ってネットワークを介してデータを送受信する。通信インタフェース２２０６は、例えば、上述の通信部１００３および通信部１１０３の一例である。

入出力インタフェース２２０７は、例えば、入力装置及び出力装置との間のインタフェースであってよい。入力装置は、例えばユーザからの指示を受け付けるキーボードやマウスなどのデバイスである。出力装置は、例えばディスプレーなどの表示装置、及びスピーカなどの音声装置である。

実施形態に係る各プログラムは、例えば、下記の形態でサーバ３０１、エッジ装置ＥＧ、ゲートウェイ装置ＧＷに提供される。
（１）記憶装置２２０３に予めインストールされている。
（２）着脱可能記憶媒体２２０５により提供される。
（３）プログラムサーバなどのサーバから提供される。

なお、図２２を参照して述べたサーバ３０１、エッジ装置ＥＧ、ゲートウェイ装置ＧＷを実現するためのコンピュータ２２００のハードウェア構成は、例示であり、実施形態はこれに限定されるものではない。例えば、上述の機能部の一部または全部の機能がＦＰＧＡ及びＳｏＣなどによるハードウェアとして実装されてもよい。なお、ＦＰＧＡは、Field Programmable Gate Arrayの略称である。ＳｏＣは、System-on-a-chipの略称である。

以上において、いくつかの実施形態が説明される。しかしながら、実施形態は上記の実施形態に限定されるものではなく、上述の実施形態の各種変形形態及び代替形態を包含するものとして理解されるべきである。例えば、各種実施形態は、その趣旨及び範囲を逸脱しない範囲で構成要素を変形して具体化できることが理解されよう。また、前述した実施形態に開示されている複数の構成要素を適宜組み合わせることにより、種々の実施形態が実施され得ることが理解されよう。更には、実施形態に示される全構成要素からいくつかの構成要素を削除して又は置換して、或いは実施形態に示される構成要素にいくつかの構成要素を追加して種々の実施形態が実施され得ることが当業者には理解されよう。

１０１ ：パブリッシャ
１０２ ：ブローカ
１０３ ：サブスクライバ
２００ ：配信管理情報
３００ ：分散処理システム
３０１ ：サーバ
３１０ ：ネットワーク
３２０ ：ネットワーク
４０１ ：拠点管理部
４０２ ：プロキシ
１００１ ：制御部
１００２ ：記憶部
１００３ ：通信部
１１０１ ：制御部
１１０２ ：記憶部
１１０３ ：通信部
１１１１ ：転送部
１１１２ ：取得部
２２００ ：コンピュータ
２２０１ ：プロセッサ
２２０２ ：メモリ
２２０３ ：記憶装置
２２０４ ：読取装置
２２０５ ：着脱可能記憶媒体
２２０６ ：通信インタフェース
２２０７ ：入出力インタフェース
２２０８ ：バス
ＥＧ ：エッジ装置
ＧＷ ：ゲートウェイ装置
ｄｖ ：デバイス

Claims (5)

1. 外部拠点に配備されているプロキシからサブスクライブを受信した場合、自拠点内に配備されているブローカと、該ブローカで受けているパブリッシュのトピックとを対応づけるブローカ管理情報において、前記サブスクライブで配送が要求されるトピックに対応づけられているブローカに、前記サブスクライブを転送する転送部、
   を含む、情報処理装置。
2. 前記自拠点内に配備されているサブスクライバから第２のサブスクライブを受信した場合、前記第２のサブスクライブで配送が要求されるトピックの情報を用いて、前記第２のサブスクライブの配送先を示す情報を取得する取得部、
   を更に含み、
   前記転送部は、前記取得部で取得した前記配送先を示す情報に他の拠点が含まれている場合、前記他の拠点に配備されているプロキシを代表する代表プロキシに前記第２のサブスクライブを転送する、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記転送部は、前記取得部で特定した前記配送先に前記自拠点が含まれている場合、前記自拠点に配備されているブローカのうちで、前記取得部で取得した前記配送先のブローカに前記第２のサブスクライブを転送する、
   ことを特徴とする請求項２に記載の情報処理装置。
4. 外部拠点に配備されているプロキシからサブスクライブを受信した場合、拠点内に配備されているブローカと、該ブローカで受けているパブリッシュのトピックとを対応づけるブローカ管理情報において、前記サブスクライブで配送が要求されるトピックに対応づけられているブローカに、前記サブスクライブを転送する、
   処理をコンピュータに実行させる配送プログラム。
5. 第１の拠点に配備されている第１のプロキシと、
   前記第１の拠点とは異なる第２の拠点に配備されているプロキシを代表する第２のプロキシと、
   を含む、分散処理システムであって、
   前記第１のプロキシは、
   サブスクライバからサブスクライブを受信した場合、前記サブスクライブで配送が要求されるトピックの情報を用いて、前記サブスクライブの配送先を示す情報を取得し、
   前記配送先を示す情報に前記第２の拠点が含まれている場合、前記第２の拠点に配備されているプロキシを代表する前記第２のプロキシに前記サブスクライブを転送し、
   前記第２のプロキシは、
   前記第１のプロキシから前記サブスクライブを受信した場合、前記第２の拠点内に配備されているブローカと、前記ブローカで受けているパブリッシュのトピックとを対応づけるブローカ管理情報において、前記サブスクライブで配送が要求されるトピックに対応づけられているブローカに、前記サブスクライブを配送する、
   ことを特徴とする、分散処理システム。

Images