JP7669769B2 - システム及び方法 - Google Patents

Description

本発明は、システム及び方法に関する。

工場やプラント等に設置されているエッジコントローラ等の端末をサーバで管理するシステムが従来から利用されている。これらの端末上では様々なアプリケーションが実行されており、各端末を管理するサーバによってその負荷分散が実現されていることが一般的である。負荷分散とは或る端末で実行されるアプリケーション処理を他の端末に実行させることで、そのアプリケーション処理の負荷を各端末で分散させることである。

特開２０１０－２０４８７５号公報 国際公開第２０１０／０６４２９４号

しかしながら、負荷分散を実現するためには各端末を管理するサーバが必要であるため、例えば、災害やインシデント等によりサーバが利用できなくなった場合には負荷分散もできなくなる。また、オンプレミス型のサーバを利用した場合には設置コストや管理コスト等が発生し、クラウド型のサーバを利用した場合であってもサーバ利用に関するコストが発生する。

本発明の一実施形態は、上記の点に鑑みてなされたもので、各端末間の負荷分散を実現することを目的とする。

上記目的を達成するため、一実施形態に係るシステムは、１以上のアプリケーションを実行する複数の端末が含まれるシステムであって、前記端末は、自身が有する演算装置の負荷率が所定の閾値を超えた場合、前記アプリケーションの実行に必要な条件を示すアプリ条件情報を他の端末に送信する条件送信部と、前記アプリ条件情報に対する返信として、前記条件を満たすか否かを示す情報が含まれる返答情報を他の端末から受信する返答受信部と、前記返答情報に基づいて、前記他の端末の中から、前記アプリケーションを実行させる他の端末を選択する選択部と、選択された前記他の端末に対して、前記アプリケーションと、前記アプリケーションの実行に必要な情報とを送信するアプリ送信部と、を有する。

各端末間の負荷分散を実現することができる。

第一の実施形態に係るシステムの全体構成の一例を示す図である。 第一の実施形態に係る端末のハードウェア構成の一例を示す図である。 第一の実施形態に係る分散機能部の詳細な機能構成の一例を示す図である。 所属端末情報の一例を示す図である。 アプリ環境条件情報の一例を示す図である。 第一の実施形態に係る負荷分散処理の流れの一例を説明するための図である。 第一の実施形態に係る端末確認処理の流れの一例を説明するための図である。 第一の実施形態に係る負荷検知処理の流れの一例を説明するための図である。 第一の実施形態に係るアプリ環境条件依頼処理の流れの一例を説明するための図である。 送信用アプリ環境条件情報の一例を示す図である。 第一の実施形態に係る環境条件返答処理の流れの一例を説明するための図である。 環境条件返答情報の一例を示す図である。 第一の実施形態に係る分散先選択処理の流れの一例を説明するための図である。 環境条件返答情報一覧の一例を示す図である。 第一の実施形態に係るアプリ分散処理（分散元側）の流れの一例を説明するための図である。 アプリ実行情報の一例を示す図である。 第一の実施形態に係るアプリ分散処理（分散先側）の流れの一例を説明するための図である。 第一の実施形態に係るアプリ削除処理（分散先側）の流れの一例を説明するための図である。 第一の実施形態に係るアプリ削除処理（分散元側）の流れの一例を説明するための図である。 第二の実施形態に係るシステムの全体構成の一例を示す図である。 第二の実施形態に係る分散機能部の詳細な機能構成の一例を示す図である。 第二の実施形態に係る認証機能部の詳細な機能構成の一例を示す図である。 第二の実施形態に係る新規参加処理の流れの一例を説明するための図である。 第二の実施形態に係る負荷分散処理の流れの一例を説明するための図である。 デフォルト処理時と分散処理時の一例を説明するための図である。 第二の実施形態に係る分散情報作成及び送信処理の流れの一例を説明するための図である。 分散情報の一例を示す図である。 第二の実施形態に係るデータ確認処理の流れの一例を説明するための図である。

以下、本発明の一実施形態について説明する。本実施形態では、各端末を管理するサーバを用いずに、端末群のみで各端末間の負荷分散を実現することができるシステム１について説明する。

［第一の実施形態］
以下、第一の実施形態について説明する。

＜全体構成＞
まず、本実施形態に係るシステム１の全体構成について、図１を参照しながら説明する。図１は、第一の実施形態に係るシステム１の全体構成の一例を示す図である。

図１に示すように、本実施形態に係るシステム１には、複数の端末１０（図１に示す例では、端末１０Ａ、端末１０Ｂ、端末１０Ｃ及び端末１０Ｄ）がローカルネットワークＮ１内に存在する。また、各端末１０は、インターネットＮ２を介して、データ収集サーバ２０と通信可能に接続される。なお、ローカルネットワークＮ１とは、例えば、工場内やプラント内、又は或る企業内等のローカルなネットワーク環境のことである。

端末１０はエッジコントローラや各種組込み機器等であり、アプリ実行環境１００と、当該アプリ実行環境上で実行されるアプリケーション１１０（以下、「アプリ１１０」ともいう。）と、他の端末１０との間で負荷分散を実現する分散機能部２００とを有している。

アプリ実行環境１００とはアプリ１１０を実行するための実行環境のことであり、例えば、ＯＳ（Operating System）上に構築されたコンテナ等である。アプリ１１０は、端末１０の配下にある機器（例えば、各種センサ等）から収集したデータや他の端末１０から受信したデータ等に対して何等かの処理を実行するアプリケーションプログラムである。図１に示す例では、端末１０Ａはデータ加工処理を実行するアプリ１１０Ａを有している。同様に、端末１０Ｂはデータ解析処理を実行するアプリ１１０Ｂ、端末１０Ｃはデータ表示処理を実行するアプリ１１０Ｃ、端末１０Ｄはデータ収集サーバ２０へのデータ送信処理を実行するアプリ１１０Ｄを有している。

これにより、図１に示す例では、例えば、端末１０の配下にある機器から収集したデータを端末１０Ａのアプリ１１０Ａで加工した後、端末１０Ｂのアプリ１１０Ｂで解析し、その解析結果を示すデータを端末１０Ｃのアプリ１１０Ｃで表示させると共に、端末１０Ｄのアプリ１１０Ｄでデータ収集サーバ２０へ送信する、といった処理が実現される。なお、図１に示す例では各端末１０は１つのアプリ１１０のみを有しているが、これは一例であって、各端末１０は複数のアプリ１１０を有していてもよい。

また、分散機能部２００は、アプリ１１０の実行を他の端末１０に分散させる機能を実現する。このとき、分散機能部２００は、アプリ１１０の処理負荷が高くなった場合に、他の端末１０で当該アプリ１１０が実行可能か否かや他の端末１０の負荷状況等を考慮して、当該アプリ１１０を他の端末１０に実行させる。これにより、本実施形態に係るシステム１では、端末１０を管理するサーバを用いずに、各端末１０間で負荷分散を実現することができる。

＜ハードウェア構成＞
次に、本実施形態に係る端末１０のハードウェア構成について、図２を参照しながら説明する。図２は、第一の実施形態に係る端末１０のハードウェア構成の一例を示す図である。

図２に示すように、本実施形態に係る端末１０は、入力装置５０１と、表示装置５０２と、外部Ｉ／Ｆ５０３と、通信Ｉ／Ｆ５０４と、プロセッサ５０５と、メモリ装置５０６とを有する。これらの各ハードウェアは、それぞれがバス５０７を介して通信可能に接続されている。

入力装置５０１は、例えば、各種ボタンやタッチパネル等である。表示装置５０２は、例えば、表示パネル等である。外部Ｉ／Ｆ５０３は、記録媒体５０３ａ等の外部装置とのインタフェースである。なお、記録媒体５０３ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等がある。

通信Ｉ／Ｆ５０４は、他の端末１０やデータ収集サーバ２０等と通信するためのインタフェースである。プロセッサ５０５は、例えば、ＣＰＵ（Central Processing Unit）等の各種演算装置である。メモリ装置５０６は、例えば、ＳＳＤ（Solid State Drive）やＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等の各種記憶装置である。

本実施形態に係る端末１０は、図２に示すハードウェア構成を有することにより、各種処理を実現することができる。なお、図２に示すハードウェア構成は一例であって、端末１０は、他のハードウェア構成を有していてもよい。例えば、端末１０は、複数のプロセッサ５０５を有していてもよいし、複数のメモリ装置５０６を有していてもよい。

＜分散機能部２００の詳細な機能構成＞
次に、本実施形態に係る分散機能部２００の詳細な機能構成について、図３を参照しながら説明する。図３は、第一の実施形態に係る分散機能部２００の詳細な機能構成の一例を示す図である。

図３に示すように、本実施形態に係る分散機能部２００には、端末確認部２０１と、負荷検知部２０２と、アプリ環境条件依頼部２０３と、環境条件返答部２０４と、分散先選択部２０５と、アプリ分散部２０６と、アプリ削除部２０７とが含まれる。なお、分散機能部２００は、例えば、端末１０にインストールされた１以上のプログラムがプロセッサ５０５に実行させる処理により実現される。

端末確認部２０１は、ローカルネットワークＮ１内に存在する端末１０（つまり、ローカルネットワークＮ１に所属する他の端末１０）を確認し、所属端末情報を作成する。所属端末情報とは、ローカルネットワークＮ１内に存在する他の端末１０の端末ＩＤとＩＰ（Internet Protocol）アドレスとを対応付けた情報である。所属端末情報の一例を図４に示す。図４に示す所属端末情報では、端末ＩＤ「Ｔ００２」とそのＩＰアドレス、端末ＩＤ「Ｔ００３」とそのＩＰアドレス、端末ＩＤ「Ｔ００４」とそのＩＰアドレスがそれぞれ対応付けられている。なお、所属端末情報には自身（つまり、自端末１０）の端末ＩＤとそのＩＰアドレスは含まれていないものとするが、これは一例であって含まれていてもよい。

負荷検知部２０２は、自端末１０におけるアプリ１１０のＣＰＵ負荷率を取得する。また、負荷検知部２０２は、当該アプリ１１０のＣＰＵ負荷率が高いか否か（具体的には、後述する負荷率閾値以内であるか否か）を判定する。

アプリ環境条件依頼部２０３は、アプリ１１０のＣＰＵ負荷率が高い場合に、ローカルネットワークＮ１内の他の端末１０に対して、当該アプリ１１０の実行に必要な条件を示す情報（以下、「送信用アプリ環境条件情報」ともいう。）を送信する。ここで、送信用アプリ環境条件情報は、アプリ環境条件情報から作成される。アプリ環境条件情報の一例を図５に示す。図５に示すアプリ環境条件情報は、アプリＩＤ「ＡＰ０１」のアプリ環境条件情報である。なお、端末１０が複数のアプリ１１０を有している場合は、各アプリ１１０に対してそれぞれアプリ環境条件情報が存在する。

図５に示すように、アプリ環境条件情報には、アプリＩＤの他に、ＯＳ、ミドルウェア、必要ＨＷリソース、想定負荷率、現在の負荷率、負荷率閾値、分散フラグ、分散先等の項目が含まれる。項目「アプリＩＤ」には、アプリ１１０を一意に識別する識別情報が設定される。項目「ＯＳ」には、当該アプリ１１０の実行に必要なＯＳ名等が設定される。項目「ミドルウェア」には、当該アプリ１１０の実行に必要なミドルウェア名等が設定される。項目「必要ＨＷリソース」には、当該アプリ１１０の実行に必要なハードウェアリソース（例えば、必要なメモリ容量等）が設定される。項目「想定負荷率」には、当該アプリ１１０を実行した際に想定されるＣＰＵ負荷率が設定される。項目「現在の負荷率」には、当該アプリ１１０の現在のＣＰＵ負荷率が設定される。項目「負荷率閾値」には、当該アプリ１１０の負荷率閾値が設定される。項目「分散フラグ」には、当該アプリ１１０を負荷分散の対象とするか否かを表す値が設定される。分散フラグは０のとき負荷分散の対象でない、１のとき負荷分散の対象であることを表し、負荷検知部２０２によってＣＰＵ負荷率が高いと判定された場合に１が設定される。項目「分散先」には、当該アプリ１１０の負荷分散先となる他の端末１０の端末ＩＤが設定される。この端末ＩＤは分散先選択部２０５によって設定される。

環境条件返答部２０４は、他の端末１０から送信用アプリ環境条件情報を受信した場合に、この送信用アプリ環境条件情報に含まれる各条件を満たすか否かと自端末１０の端末ＩＤと現在のＣＰＵ負荷率とが含まれる環境条件返答情報を返信する。

分散先選択部２０５は、他の端末１０から環境条件返答情報を受信した場合、これらの環境条件返答情報から環境条件返答情報一覧を作成し、負荷分散対象のアプリ１１０を実行させる他の端末１０を選択する。この際、分散先選択部２０５は、他の端末１０で当該アプリ１１０が実行可能か否かや他の端末１０の負荷状況（ＣＰＵ負荷率）等を考慮して、当該アプリ１１０の実行させる他の端末１０を選択する。

アプリ分散部２０６は、自端末１０が分散元である場合、分散先選択部２０５によって選択された他の端末１０に対して、アプリ１１０とアプリ実行情報とを送信する。アプリ実行情報とはアプリ１１０の実行時に必要な各種情報であり、例えば、当該アプリ１１０に入力する入力データのパス、当該アプリ１１０の処理結果の転送有無、転送する場合の転送先ＩＰアドレス等の情報が含まれる。

また、アプリ分散部２０６は、自端末１０が分散先である場合、他の端末１０から受信したアプリ１１０とアプリ実行情報とを用いて当該アプリ１１０を実行する。

アプリ削除部２０７は、自端末１０が分散先である場合、分散元の他の端末１０から受信したアプリ１１０を削除すると共に、当該他の端末１０に対して当該アプリ１１０の実行が完了したことを通知する。また、アプリ削除部２０７は、自端末１０が分散元である場合、他の端末１０からの通知に応じて、アプリ環境条件情報の分散フラグや分散先等をリセットする。

＜負荷分散処理の流れ＞
次に、ローカルネットワークＮ１内に存在する複数の端末１０間で負荷分散処理を行う場合の流れについて、図６を参照しながら説明する。図６は、第一の実施形態に係る負荷分散処理の流れの一例を説明するための図である。この負荷分散処理は、定期的（例えば、数秒～数十秒等の予め決められた時間間隔毎）に繰り返し実行される。

以下では、アプリ１１０の実行を他の端末１０に分散する端末１０を「分散元端末１０」といい、分散元端末１０以外の端末１０（つまり、当該アプリ１１０の分散先又はその候補となる端末１０）を「分散先端末１０」という。また、分散元端末１０の端末ＩＤは「Ｔ００１」であるものとする。なお、「分散元」、「分散先」との語は相対的なものであり、或る端末１０が同時に分散元端末１０かつ分散先端末１０となり得る。

まず、分散元端末１０の端末確認部２０１は、端末確認処理を実行する（ステップＳ１０１）。端末確認処理では、ローカルネットワークＮ１内に存在する他の端末１０の端末ＩＤとＩＰアドレスを対応付けることで所属端末情報が作成される。なお、端末確認処理の詳細については後述する。

次に、分散元端末１０の負荷検知部２０２は、負荷検知処理を実行する（ステップＳ１０２）。負荷検知処理では、分散元端末１０のアプリ１１０のＣＰＵ負荷率が高いか否かが判定される。なお、負荷検知処理の詳細については後述する。

次に、負荷検知処理でアプリ１１０のＣＰＵ負荷率が高いと判定された場合、分散元端末１０のアプリ環境条件依頼部２０３は、アプリ環境条件依頼処理を実行する（ステップＳ１０３）。アプリ環境条件依頼処理では、送信用アプリ環境条件情報が分散先端末１０に送信される。なお、アプリ環境条件依頼処理の詳細については後述する。

各分散先端末１０の環境条件返答部２０４は、環境条件返答処理をそれぞれ実行する（ステップＳ１０４）。環境条件返答処理では、環境条件返答情報が分散元端末１０に返信される。なお、環境条件返答処理の詳細については後述する。

分散元端末１０の分散先選択部２０５は、分散先選択処理を実行する（ステップＳ１０５）。分散先選択処理では、各分散先端末１０から返信された環境条件返答情報を用いて、負荷分散対象のアプリ１１０を実行させる分散先端末１０を選択する。なお、分散先選択処理の詳細については後述する。

分散元端末１０のアプリ分散部２０６は、アプリ分散処理（分散元側）を実行する（ステップＳ１０６）。アプリ分散処理（分散元側）では、上記のステップＳ１０５で選択された分散先端末１０に対して、負荷分散対象のアプリ１１０とアプリ実行情報とを送信する。なお、アプリ分散処理（分散元側）の詳細については後述する。

分散先端末１０のアプリ分散部２０６は、アプリ分散処理（分散先側）を実行する（ステップＳ１０７）。アプリ分散処理（分散先側）では、アプリ実行情報を用いてアプリ１１０が実行される。なお、アプリ分散処理（分散先側）の詳細については後述する。

分散先端末１０のアプリ削除部２０７は、アプリ削除処理（分散先側）を実行する（ステップＳ１０８）。アプリ削除処理（分散先側）では、分散元端末１０から送信されたアプリ１１０が削除されると共にその完了通知が分散元端末１０に送信される。なお、アプリ削除処理（分散先側）の詳細については後述する。

分散元端末１０のアプリ削除部２０７は、アプリ削除処理（分散元側）を実行する（ステップＳ１０９）。アプリ削除処理（分散元側）では、アプリ環境条件情報の分散フラグや分散先等がリセットされる。なお、アプリ削除処理（分散元側）の詳細については後述する。

≪端末確認処理の流れ≫
図６のステップＳ１０１の端末確認処理の流れについて、図７を参照しながら説明する。図７は、第一の実施形態に係る端末確認処理の流れの一例を説明するための図である。

分散元端末１０の端末確認部２０１は、ローカルネットワークＮ１に対して疎通確認をブロードキャストする（ステップＳ２０１）。これにより、疎通確認を受信した端末１０から、端末ＩＤとＩＰアドレスとが含まれる応答が分散元端末１０に返信される。

次に、分散元端末１０の端末確認部２０１は、各端末１０から受信した応答に含まれる端末ＩＤとＩＰアドレスとを対応付けて所属端末情報を作成する（ステップＳ２０２）。これにより、現時点でローカルネットワークＮ１内に存在する各端末１０の端末ＩＤ及びＩＰアドレスが所属端末情報として得られる。

≪負荷検知処理の流れ≫
図６のステップＳ１０２の負荷検知処理の流れについて、図８を参照しながら説明する。図８は、第一の実施形態に係る負荷検知処理の流れの一例を説明するための図である。

分散元端末１０の負荷検知部２０２は、自身が有する各アプリ１１０のＣＰＵ負荷率を取得する（ステップＳ３０１）。このＣＰＵ負荷率は、当該アプリ１１０のアプリＩＤが設定されているアプリ環境条件情報の項目「現在の負荷率」に設定される。なお、アプリ１１０のＣＰＵ負荷率とは、例えば、当該アプリ１１０のＣＰＵ使用率（単位は％）のことである。

次に、分散元端末１０の負荷検知部２０２は、すべてのアプリ１１０のＣＰＵ負荷率が閾値以内であるか否かを判定する（ステップＳ３０２）。ここで、閾値は、当該アプリ１１０のアプリＩＤが設定されているアプリ環境条件情報に含まれる負荷率閾値のことである。したがって、ＣＰＵ負荷率の閾値はアプリ１１０毎に異なり得る。

上記のステップＳ３０２ですべてのアプリ１１０のＣＰＵ負荷率が閾値以内であると判定された場合、分散元端末１０は、負荷分散処理を終了する（ステップＳ３０３）。この場合、アプリ１１０の処理を分散させる必要はないためである。したがって、この場合、図６のステップＳ１０３以降の処理は実行されない。

一方で、上記のステップＳ３０２ですべてのアプリ１１０のＣＰＵ負荷率が閾値以内であると判定されなかった場合（つまり、ＣＰＵ負荷率が閾値を超えるアプリ１１０が存在する場合）、分散元端末１０の負荷検知部２０２は、ＣＰＵ負荷率が閾値を超えるアプリ１１０のアプリＩＤが設定されているアプリ環境条件情報に含まれる分散フラグを１に設定する（ステップＳ３０４）。これにより、当該アプリ１１０が負荷分散の対象となる。なお、端末１０が複数のアプリ１１０を有する場合は複数のアプリ１１０が負荷分散の対象となり得るが、以降では、簡単のため、或る１つのアプリ１１０が負荷分散の対象となった場合について説明する。複数のアプリ１１０が負荷分散の対象となった場合は、負荷分散の対象となったアプリ１１０毎に、図６のステップＳ１０３以降の処理を繰り返せばよい。

≪アプリ環境条件依頼処理の流れ≫
図６のステップＳ１０３のアプリ環境条件依頼処理の流れについて、図９を参照しながら説明する。図９は、第一の実施形態に係るアプリ環境条件依頼処理の流れの一例を説明するための図である。

分散元端末１０のアプリ環境条件依頼部２０３は、分散フラグに１が設定されているアプリ環境条件情報から送信用アプリ環境条件情報を作成する（ステップＳ４０１）。ここで、送信用アプリ環境条件情報は負荷分散対象のアプリ１１０の実行に必要な条件を示す情報であり、例えば、アプリ環境条件情報からアプリＩＤ、ＯＳ、ミドルウェア、必要ＨＷリソース及び想定負荷率を抽出した情報である。図５に示すアプリ環境条件情報から作成された送信用アプリ環境条件情報を図１０に示す。

次に、分散元端末１０のアプリ環境条件依頼部２０３は、ローカルネットワークＮ１内に他の端末１０が存在するか否かを判定する（ステップＳ４０２）。これは、図６のステップＳ１０１で作成された所属端末情報を参照して、自端末１０の端末ＩＤ以外の端末ＩＤとＩＰアドレスが存在するか否かを判定すればよい。

上記のステップＳ４０２でローカルネットワークＮ１内に他の端末１０が存在すると判定されなかった場合、分散元端末１０は、負荷分散処理を終了する（ステップＳ４０３）。この場合、負荷分散先となる他の端末１０が存在しないためである。したがって、この場合、図６のステップＳ１０４以降の処理は実行されない。

一方で、上記のステップＳ４０２でローカルネットワークＮ１内に他の端末１０が存在すると判定された場合、分散元端末１０のアプリ環境条件依頼部２０３は、ローカルネットワークＮ１内に他の端末１０（分散先端末１０）に対して送信用アプリ環境条件情報を送信する（ステップＳ４０４）。

≪環境条件返答処理の流れ≫
図６のステップＳ１０４の環境条件返答処理の流れについて、図１１を参照しながら説明する。図１１は、第一の実施形態に係る環境条件返答処理の流れの一例を説明するための図である。なお、この環境条件返答処理は各分散先端末１０でそれぞれ実行されるが、以下では、簡単のため、或る分散先端末１０が環境条件返答処理を実行する場合の流れについて説明する。

分散先端末１０の環境条件返答部２０４は、送信用アプリ環境条件情報を受信する（ステップＳ５０１）。

次に、分散先端末１０の環境条件返答部２０４は、自身のアプリ実行環境１００及びＣＰＵ負荷率等に基づいて環境条件返答情報を作成する（ステップＳ５０２）。環境条件返答情報は、自身の端末ＩＤと、送信用アプリ環境条件情報に含まれる各条件を満たすか否かと、自身の現在のＣＰＵ負荷率とが含まれる情報である。図１０に示す送信用アプリ環境条件情報に対応する環境条件返答情報を図１２に示す。図１２に示す環境条件返答情報には、端末ＩＤ「Ｔ００２」、ＯＳ「ＯＳ」、ミドルウェア「ＯＫ」、必要ＨＷリソース「ＯＫ」、想定負荷率「ＯＫ」、現在負荷率「２０」が含まれている。これは、端末ＩＤ「Ｔ００２」の分散先端末１０は、負荷分散対象のアプリ１１０を実行するために必要なＯＳの条件、ミドルウェアの条件、ハードウェアリソースの条件及び想定負荷率を満たしている（つまり、負荷分散対象のアプリ１１０を実行するために必要なアプリ実行環境１００を有しており、かつ、必要なハードウェアリソースと必要なＣＰＵリソースを有している）ことを表している。また、当該分散先端末１０の現在のＣＰＵ負荷率は「２０」であることを表している。なお、図１２に示す環境条件返答情報は、送信用アプリ環境条件情報に含まれるすべての条件を満たしている例であるが、或る条件を満たさない場合はその条件に対応する項目に「ＮＧ」が設定される。

そして、分散先端末１０の環境条件返答部２０４は、上記のステップＳ５０２で作成した環境条件返答情報を分散元端末１０に返信する（ステップＳ５０３）。これにより、分散元端末１０は、各分散先端末１０から環境条件返答情報を受信することになる。

≪分散先選択処理の流れ≫
図６のステップＳ１０５の分散先選択処理の流れについて、図１３を参照しながら説明する。図１３は、第一の実施形態に係る分散先選択処理の流れの一例を説明するための図である。

分散元端末１０の分散先選択部２０５は、各分散先端末１０から返信された環境条件返答情報を用いて、環境条件返答情報一覧を作成する（ステップＳ６０１）。環境条件返答情報一覧とは、各分散先端末１０から環境条件返答情報の返信があったか否か、返信があった場合はその応答時間、送信用アプリ環境条件情報に含まれる各条件を満たすか否か、現在のＣＰＵ負荷率が含まれる情報である。環境条件返答情報一覧の一例を図１４に示す。

図１４に示すように、環境条件返答情報一覧には、端末ＩＤ、返信有無、応答時間、ＯＳ、ミドルウェア、必要ＨＷリソース、想定負荷率、現在の負荷率、選択フラグ等の項目が含まれる。項目「端末ＩＤ」には、所属端末情報に含まれる端末ＩＤ（つまり、分散先端末１０の端末ＩＤ）が設定される。項目「返信有無」には、当該端末ＩＤの分散先端末１０から環境条件返答情報の返信があったか否かを示す情報（ＯＫ／ＮＧ）が設定される。また、返信有無に「ＯＫ」が設定されている場合、項目「ＯＳ」、「ミドルウェア」、「必要ＨＷリソース」、「想定負荷率」及び「現在の負荷率」には、環境条件返答情報に含まれる同一項目の値が設定される。また、返信有無に「ＯＫ」が設定されている場合、項目「応答時間」には、分散元端末１０が送信用アプリ環境条件情報を送信した後、当該端末ＩＤの分散先端末１０から環境条件返答情報を受信するまでの経過時間が設定される。このような経過時間は分散元端末１０で計測される。

一方で、返信有無に「ＮＧ」が設定されている場合、項目「応答時間」、「ＯＳ」、「ミドルウェア」、「必要ＨＷリソース」、「想定負荷率」及び「現在の負荷率」には値が設定されない。

項目「選択フラグ」には、当該端末ＩＤの分散先端末１０を負荷分散先とするか否かを表す値が設定される。選択フラグは０のとき負荷分散先でない、１のとき負荷分散先であることを表し、デフォルト値は０に設定されている。

なお、以下では、便宜上、環境条件返答情報一覧を構成する各行（レコード）の集まりを「レコード群」という。例えば、ローカルネットワークＮ１内に存在する端末１０の数がＮ台（つまり、自端末１０以外の他の端末１０の数はＮ－１台）である場合、レコード群はＮ－１件のレコードの集まりである。

次に、分散元端末１０の分散先選択部２０５は、上記のステップＳ６０１で作成した環境条件返答情報一覧を用いて、負荷分散先とする分散先端末１０を絞り込む（ステップＳ６０２）。このとき、分散先選択部２０５は、環境条件返答情報一覧を構成するレコード群を絞り込むことで、負荷分散先とする分散先端末１０を絞り込む。ここで、分散先選択部２０５は、例えば、以下の手順１～手順６により負荷分散先とする分散先端末１０を絞り込めばよい。

手順１：まず、分散先選択部２０５は、環境条件返答情報一覧を構成するレコード群の中から、項目「返信有無」にＮＧが設定されているレコードを除外する。

手順２：次に、分散先選択部２０５は、上記の手順１で除外後のレコード群の中から、項目「応答時間」に設定されている値が所定の第１の閾値以上のレコードを除外する。なお、当該第１の閾値は予め決められた値である。

手順３：次に、分散先選択部２０５は、上記の手順２で除外後のレコード群の中から、項目「ＯＳ」及び項目「ミドルウェア」の少なくとも一方にＮＧが設定されているレコードを除外する。

手順４：次に、分散先選択部２０５は、上記の手順３で除外後のレコード群の中から、項目「必要ＨＷリソース」にＮＧが設定されているレコードを除外する。

手順５：次に、分散先選択部２０５は、上記の手順４で除外後のレコード群の中から、項目「想定負荷率」にＮＧが設定されているレコードを除外する。

手順６：そして、分散先選択部２０５は、上記の手順５で除外後のレコード群の中から、項目「現在の負荷率」に設定されている値が所定の第２の閾値以上のレコードを除外する。なお、当該第２の閾値は予め決められた値である。

これにより、環境条件返答情報一覧を構成するレコード群が絞り込まれ、その結果、絞り込み後のレコード群に含まれるレコードに対応する分散先端末１０に負荷分散先が絞り込まれたことになる。

ただし、上記の手順１～手順６によりレコード群を絞り込むことは一例であって、これらの手順１～手順６のうちの一部の手順によりレコード群を絞り込んでもよい。例えば、手順２は行わずに、手順１と手順３～手順６によりレコード群を絞り込んでもよい。又は、例えば、手順６は行わずに、手順１～手順５によりレコード群を絞り込んでもよいし、手順２と手順６は行わずに、手順１と手順３～手順５によりレコード群を絞り込んでもよい。

次に、分散元端末１０の分散先選択部２０５は、分散可能な分散先端末１０があるか否か（つまり、上記のステップＳ６０２で絞り込み後の分散先端末１０が１台以上あるか否か）を判定する（ステップＳ６０３）。

上記のステップＳ６０３で分散可能な分散先端末１０があると判定されなかった場合、分散元端末１０は、負荷分散処理を終了する（ステップＳ６０４）。この場合、負荷分散対象のアプリ１１０の処理を分散させることが可能な他の端末１０が存在しないためである。したがって、この場合、図６のステップＳ１０６以降の処理は実行されない。

一方で、上記のステップＳ６０３で分散可能な分散先端末１０があると判定された場合、分散元端末１０の分散先選択部２０５は、環境条件返答情報一覧を構成するレコードのうち、分散可能な分散先端末１０の端末ＩＤが設定されているレコードの選択フラグを１に設定する（ステップＳ６０５）。このとき、分散可能な分散先端末１０に対応するレコードが複数存在する場合（つまり、上記のステップＳ６０２で絞り込み後の分散先端末１０が２台以上ある場合）、分散元端末１０の分散先選択部２０５は、これら複数のレコードのうちのいずれか１つのレコードの選択フラグのみを１に設定する。この際、当該複数のレコードのうちのどのレコードの選択フラグを１に設定するかは、例えば、最も応答時間が短いレコードの選択フラグを１に設定してもよいし、最も現在の負荷率が低いレコードの選択フラグを１に設定してもよいし、又はランダムに選択したレコードの選択フラグを１に設定してもよい。これにより、選択フラグに１を設定したレコードに対応する分散先端末１０が、負荷分散対象のアプリ１１０の負荷分散先として選択されたことになる。

次に、分散元端末１０の分散先選択部２０５は、負荷分散対象のアプリ１１０のアプリＩＤが設定されているアプリ環境条件情報の項目「分散先」に対して、上記のステップＳ６０５で選択フラグを１に設定したレコードに含まれる端末ＩＤを設定する（ステップＳ６０６）。

≪アプリ分散処理（分散元側）の流れ≫
図６のステップＳ１０６のアプリ分散処理（分散元側）の流れについて、図１５を参照しながら説明する。図１５は、第一の実施形態に係るアプリ分散処理（分散元側）の流れの一例を説明するための図である。

分散元端末１０のアプリ分散部２０６は、分散フラグに１が設定されているアプリ環境条件情報に対応するアプリ１１０（つまり、負荷分散対象のアプリ１１０）のアプリ実行情報を作成する（ステップＳ７０１）。アプリ実行情報とは、上述したように、アプリ１１０の実行時に必要な各種情報であり、例えば、当該アプリ１１０に入力する入力データのパス、当該アプリ１１０の処理結果の転送有無、転送する場合の転送先ＩＰアドレス等の情報が含まれる。アプリ実行情報の一例を図１６に示す。図１６に示すアプリ実行情報は、アプリＩＤ「ＡＰ０１」のアプリ１１０の実行時に必要な情報であり、転送有無、転送先ＩＰ及び入力データパス等の項目が含まれる。項目「転送有無」には、当該アプリ１１０の処理結果を転送するか否かを示す情報が設定される。項目「転送先ＩＰ」には、当該アプリ１１０の処理結果を転送する場合にその転送先となるＩＰアドレスが設定される。項目「入力データパス」には、当該アプリ１１０を実行する際に入力されるデータのパスが設定される。なお、これらの項目は一例であって、これら以外にも、アプリ１１０の実行時に必要な情報が設定される様々な項目が含まれていてもよい。

次に、分散元端末１０のアプリ分散部２０６は、当該アプリ環境条件情報（つまり、負荷分散対象のアプリ１１０のアプリ環境条件情報）の分散先に設定されている端末ＩＤを取得する（ステップＳ７０２）。

そして、分散元端末１０のアプリ分散部２０６は、負荷分散対象のアプリ１１０と上記のステップＳ７０１で作成したアプリ実行情報とを、上記のステップＳ７０２で取得した端末ＩＤの分散先端末１０に送信する（ステップＳ７０３）。なお、アプリ１１０の送信には、例えば、Ｄｏｃｋｅｒコンテナ等の既知の技術を利用すればよい。

≪アプリ分散処理（分散先側）の流れ≫
図６のステップＳ１０７のアプリ分散処理（分散先側）の流れについて、図１７を参照しながら説明する。図１７は、第一の実施形態に係るアプリ分散処理（分散先側）の流れの一例を説明するための図である。

分散先端末１０のアプリ分散部２０６は、負荷分散対象のアプリ１１０とそのアプリ実行情報とを受信する（ステップＳ８０１）。

次に、分散先端末１０のアプリ分散部２０６は、当該アプリ１１０とそのアプリ実行情報とをアプリ実行環境１００上に展開する（ステップＳ８０２）。

そして、分散先端末１０のアプリ分散部２０６は、アプリ実行環境１００上で当該アプリ実行情報を用いて当該アプリ１１０を実行する（ステップＳ８０３）。例えば、分散先端末１０のアプリ分散部２０６は、当該アプリ実行情報に含まれる入力データパスに設定されているパスから入力データを取得した上で、この入力データを入力として当該アプリ１１０を実行する。これにより、負荷分散対象のアプリ１１０が分散先端末１０で実行されたことになる。

≪アプリ削除処理（分散先側）の流れ≫
図６のステップＳ１０８のアプリ削除処理（分散先側）の流れについて、図１８を参照しながら説明する。図１８は、第一の実施形態に係るアプリ削除処理（分散先側）の流れの一例を説明するための図である。

分散先端末１０のアプリ削除部２０７は、図１７のステップＳ８０３におけるアプリ１１０の実行が終了したか否かを判定する（ステップＳ９０１）。

上記のステップＳ９０１でアプリ１１０の実行が終了したと判定されなかった場合、分散先端末１０は、ステップＳ９０１に戻る。すなわち、分散先端末１０は、当該アプリ１１０の実行終了待ち状態となる。

一方で、上記のステップＳ９０１でアプリ１１０の実行が終了したと判定された場合、分散先端末１０のアプリ削除部２０７は、当該アプリ１１０をアプリ実行環境１００から削除する（ステップＳ９０２）。

次に、分散先端末１０のアプリ削除部２０７は、当該アプリ１１０の処理結果の転送が必要であるか否かを判定する（ステップＳ９０３）。これは、アプリ実行情報の転送有無から判定される。

上記のステップＳ９０３で転送が必要であると判定された場合、分散先端末１０のアプリ削除部２０７は、当該アプリ１１０の処理結果を転送する（ステップＳ９０４）。すなわち、分散先端末１０のアプリ削除部２０７は、当該アプリ実行情報の転送先ＩＰに設定されているＩＰアドレスに対して、当該アプリ１１０の処理結果を転送する。これにより、例えば、アプリ実行情報の転送先ＩＰに設定されているＩＰアドレスがデータ収集サーバ２０のＩＰアドレスであれば、当該アプリ１１０の処理結果はデータ収集サーバ２０に送信される。また、例えば、アプリ実行情報の転送先ＩＰに設定されているＩＰアドレスが分散元端末１０のＩＰアドレスであれば、当該アプリ１１０の処理結果は分散元端末１０に送信される。また、例えば、当該アプリ１１０がデータ加工処理を実行するアプリケーションプログラムである場合には、データ解析処理を実行するアプリ１１０Ｂを有する端末１０ＢのＩＰアドレスが転送先ＩＰとして設定され、当該アプリ１１０の処理結果は端末１０Ｂに送信される。このように、転送先ＩＰはシステム１全体でのアプリ１１０の処理順に応じて設定される。

なお、アプリ実行情報の転送先ＩＰには２つ以上のＩＰアドレスが設定されていてもよく、この場合は２つ以上のＩＰアドレス宛にアプリ１１０の処理結果が送信されることになる。

上記のステップＳ９０３で転送が必要であると判定されなかった場合又はステップＳ９０４に続いて、分散先端末１０のアプリ削除部２０７は、負荷分散対象のアプリ１１０の処理が完了したことを示す完了通知を分散元端末１０に送信する（ステップＳ９０５）。

≪アプリ削除処理（分散元側）の流れ≫
図６のステップＳ１０９のアプリ削除処理（分散元側）の流れについて、図１９を参照しながら説明する。図１９は、第一の実施形態に係るアプリ削除処理（分散元側）の流れの一例を説明するための図である。

分散元端末１０のアプリ削除部２０７は、分散先端末１０から完了通知を受信する（ステップＳ１００１）。

そして、分散元端末１０のアプリ削除部２０７は、負荷分散対象のアプリ１１０のアプリＩＤが設定されているアプリ環境条件情報の分散フラグ及び分散先をリセット（つまり、分散フラグに０を設定すると共に分散先をブランクに設定）する（ステップＳ１００２）。これにより、当該アプリ１１０の負荷分散が完了する。

［第二の実施形態］
以下、第二の実施形態について説明する。第一の実施形態ではローカルネットワークＮ１内に存在する複数の端末１０（以下、端末群ともいう。）で負荷分散を行う場合について説明した。しかしながら、ローカルネットワークＮ１には様々な端末１０が参加し得る（つまり、端末群には様々な端末１０が追加され得る）ため、不正な端末がローカルネットワークＮ１に参加してしまう可能性がある。また、不正な端末との間で負荷分散が行われた場合は、不正なデータの送受信が発生する可能性がある。

そこで、本実施形態では、端末１０がローカルネットワークＮ１に参加する際にその端末１０を他の端末１０が認証する仕組みを導入し、不正な端末がローカルネットワークＮ１に参加してしまう事態を防止する。また、データ送受信の際にそのデータが不正なデータであるか否かを確認する仕組みを導入し、万が一、不正な端末がローカルネットワークＮ１に参加してしまった場合であっても、不正なデータでアプリ１１０が実行されてしまったり、不正なデータにより正規の端末１０が攻撃されてしまったりする事態を防止する。

なお、第二の実施形態では、主に、第一の実施形態との相違点について説明し、第一の実施形態と同様の構成要素についてはその説明を省略する。

＜全体構成＞
まず、本実施形態に係るシステム１の全体構成について、図２０を参照しながら説明する。図２０は、第二の実施形態に係るシステム１の全体構成の一例を示す図である。

図２０に示すように、本実施形態に係るシステム１には、第一の実施形態で説明した端末１０及びデータ収集サーバ２０に加えて、認証装置３０が更に含まれている。

認証装置３０は端末１０を管理する事業者のサーバ等のコンピュータ又はコンピュータシステムであり、認証機能部３００を有する。認証機能部３００は、端末１０がローカルネットワークＮ１に参加する際にその端末１０（以下、新規参加端末１０ともいう。）を、ローカルネットワークＮ１に既に参加している端末１０（以下、参加済端末１０ともいう。）が認証するための秘密鍵を管理する。この秘密鍵はシステム１全体で一意な情報であり、新規参加端末１０に配布される（したがって、参加済端末１０も秘密鍵を所持している。）。各参加済端末１０は、新規参加端末１０が自身と同一の秘密鍵を所持していることを検証することで、当該新規参加端末１０検証することができる。なお、後述するように、この検証は、新規参加端末１０の端末ＩＤと秘密鍵とに関するハッシュ値の同一性を検証することで行われる。

また、本実施形態に係る端末１０が有する分散機能部２００は、当該端末１０が分散元端末１０のアプリ１１０を実行する場合、自身が所持する秘密鍵を用いて、当該アプリ１１０の実行に用いるデータが不正なデータであるか否かを確認する。この確認は、後述するように、分散情報と秘密鍵とに関するハッシュ値の同一性を検証することで行われる。分散情報とは、負荷分散対象のアプリ１１０のアプリＩＤや分散元端末１０の端末ＩＤ、分散先端末１０の端末ＩＤ、当該アプリ１１０の実行に用いるデータの送信元、当該アプリ１１０の実行結果を示すデータの送信先、分散開始時刻等が含まれる情報のことである。分散情報の具体例については後述する。

＜分散機能部２００の詳細な機能構成＞
次に、本実施形態に係る分散機能部２００の詳細な機能構成について、図２１を参照しながら説明する。図２１は、第二の実施形態に係る分散機能部２００の詳細な機能構成の一例を示す図である。

図２１に示すように、本実施形態に係る分散機能部２００には、第一の実施形態で説明した各部に加えて、新規参加部２０８と、参加検証部２０９と、データ確認部２１０とが含まれる。

新規参加部２０８は、ローカルネットワークＮ１に参加する場合（つまり、自身が新規参加端末１０である場合）に、自身の端末ＩＤを認証装置３０に通知する。また、新規参加部２０８は、自身の端末ＩＤと、認証装置３０から通知された秘密鍵とから所定のハッシュ関数によりハッシュ値を算出し、そのハッシュ値を参加済端末１０に送信する。

参加検証部２０９は、認証装置３０から通知された端末ＩＤ（新規参加端末１０の端末ＩＤ）と、自身が所持する秘密鍵とから所定のハッシュ関数によりハッシュ値を算出し、このハッシュ値と、新規参加端末１０から通知されたハッシュ値とが一致するか否かを検証する。そして、参加検証部２０９は、これらのハッシュ値が一致する場合は新規参加端末１０の端末ＩＤを所属端末情報に追加し、そうでない場合は異常を通知する。これにより、ハッシュ値が一致する場合（つまり、新規参加端末１０が秘密鍵を所持している正規の端末１０である場合）にのみ、新規参加端末１０の端末ＩＤが、各参加済端末１０の所属端末情報に追加される。

データ確認部２１０は、自身が分散元端末１０である場合、分散情報を作成した上で、所定の端末１０と負荷分散対象のアプリ１１０を実行させる端末１０とに対して、当該分散情報を送信する。

また、データ確認部２１０は、負荷分散対象のアプリ１１０を実行する分散先端末１０に対してそのアプリ１１０の実行に用いられるデータを送信する場合、自身が所持する分散情報と秘密鍵とから所定のハッシュ関数によりハッシュ値を算出した上で、そのデータと共に当該分散先端末１０に送信する。

また、データ確認部２１０は、自身が分散元端末１０の負荷分散対象のアプリ１１０を実行する場合、自身が所持する秘密鍵と、分散元端末１０から受信した分散情報とから所定のハッシュ関数によりハッシュ値を算出する。そして、データ確認部２１０は、当該アプリ１１０の実行に用いるデータの送信元の端末１０から受信したハッシュ値と、自身が算出したハッシュ値とが一致するか否かを検証する。その後、データ確認部２１０は、これらのハッシュ値が一致する場合はアプリ分散部２０６により当該データを入力データとして当該アプリ１１０を実行し、そうでない場合は異常を通知する。これにより、ハッシュ値が一致する場合（つまり、当該アプリ１１０の実行に用いるデータの送信元の端末１０が秘密鍵と分散情報を所持している正規の端末１０である場合）にのみ、分散元端末１０から受信したアプリ１１０（負荷分散対象のアプリ１１０）を実行される。

なお、以下では、負荷分散対象のアプリ１１０に用いられるデータの送信元の端末１０を「データ送信側端末１０」ともいう。また、このデータを用いて当該アプリ１１０を実行する端末１０（つまり、分散元端末１０の負荷分散対象のアプリ１１０を実行する分散先端末１０）を「データ受信側端末１０」ともいう。

＜認証機能部３００の詳細な機能構成＞
次に、本実施形態に係る認証機能部３００の詳細な機能構成について、図２２を参照しながら説明する。図２２は、第二の実施形態に係る認証機能部３００の詳細な機能構成の一例を示す図である。

図２２に示すように、本実施形態に係る認証機能部３００には、認証部３０１が含まれる。なお、認証機能部３００は、例えば、認証装置３０にインストールされた１以上のプログラムが、ＣＰＵ等のプロセッサに実行させる処理により実現される。

認証部３０１は、新規参加端末１０から端末ＩＤを受信した場合、当該新規参加端末１０に対して秘密鍵を通知する。また、認証部３０１は、参加済端末情報を参照して、当該新規参加端末１０の端末ＩＤを各参加済端末１０に通知する。ここで、参加済端末情報とは、ローカルネットワークＮ１に参加している正規の端末１０（つまり、秘密鍵を所持している端末１０）の端末ＩＤのリストである。

そして、認証部３０１は、どの参加済端末１０からも異常が通知されなかった場合、新規参加端末１０の端末ＩＤを参加済端末情報に追加する。これにより、新規参加端末１０が参加済端末１０として認証装置３０に登録されたことになる。

＜新規参加処理の流れ＞
次に、或る新規参加端末１０がローカルネットワークＮ１に新たに参加する場合の処理の流れについて、図２３を参照しながら説明する。図２３は、第二の実施形態に係る新規参加処理の流れの一例を説明するための図である。

新規参加端末１０の新規参加部２０８は、自身の端末ＩＤを認証装置３０に通知（送信）する（ステップＳ１１０１）。

認証装置３０の認証部３０１は、新規参加端末１０からの端末ＩＤを受信する（ステップＳ１１０２）。

次に、認証装置３０の認証部３０１は、参加済端末情報を参照して、この参加済端末情報に含まれる端末ＩＤの端末１０（つまり、参加済端末１０）に対して、新規参加端末１０の端末ＩＤを通知（送信）する（ステップＳ１１０３）。

次に、認証装置３０の認証部３０１は、秘密鍵を新規参加端末１０に通知（送信）する（ステップＳ１１０４）。

新規参加端末１０の新規参加部２０８は、認証装置３０からの秘密鍵を受信する（ステップＳ１１０５）。

次に、新規参加端末１０の新規参加部２０８は、ローカルネットワークＮ１に参加する（ステップＳ１１０６）。すなわち、新規参加端末１０の新規参加部２０８は、ローカルネットワークＮ１に接続する。

次に、新規参加端末１０の新規参加部２０８は、自身の端末ＩＤと、上記のステップＳ１１０５で受信した秘密鍵とから所定のハッシュ関数によりハッシュ値を算出する（ステップＳ１１０７）。

そして、新規参加端末１０の新規参加部２０８は、上記のステップＳ１１０７で算出したハッシュ値を参加済端末１０に通知（送信）する（ステップＳ１１０８）。なお、新規参加端末１０の新規参加部２０８は、ローカルネットワークＮ１内に存在する各端末１０に対して、上記のステップＳ１１０７で算出したハッシュ値をブロードキャストすればよい。

一方で、参加済端末１０の参加検証部２０９は、新規参加端末１０の端末ＩＤを認証装置３０から受信する（ステップＳ１１０９）と、この端末ＩＤと、自身が所持する秘密鍵とから所定のハッシュ関数によりハッシュ値を算出する（ステップＳ１１１０）。

次に、参加済端末１０の参加検証部２０９は、上記のステップＳ１１１０で算出したハッシュ値と、新規参加端末１０からのハッシュ値とが一致するか否かを検証する（ステップＳ１１１１）。

そして、参加済端末１０の参加検証部２０９は、上記のステップＳ１１１１の検証の結果、ハッシュ値が一致する場合は新規参加端末１０の端末ＩＤを所属端末情報に追加し、そうでない場合は認証装置３０に異常を通知する（ステップＳ１１１２）。

最後に、認証装置３０の認証部３０１は、どの参加済端末１０からも異常が通知されなかった場合、新規参加端末１０の端末ＩＤを参加済端末情報に追加する（ステップＳ１１１３）。なお、本ステップは、例えば、上記のステップＳ１１０４が実行された後、所定の時間の経過後に実行すること等が考えられる。これにより、新規参加端末１０が参加済端末１０として認証装置３０に登録される。

なお、例えば、上記のステップＳ１１１２で各参加済端末１０の参加検証部２０９は、ハッシュ値が一致する場合に新規参加端末１０の端末ＩＤを所属端末情報に追加すると共に、正常である旨を認証装置３０に通知してもよい。この場合、例えば、認証装置３０の認証部３０１は、全ての参加済端末１０から正常である旨の通知を受信したときに、上記のステップＳ１１１３を実行すればよい。

＜負荷分散処理の流れ＞
次に、ローカルネットワークＮ１内に存在する複数の端末１０間で負荷分散処理を行う場合の流れについて、図２４を参照しながら説明する。図２４は、第二の実施形態に係る負荷分散処理の流れの一例を説明するための図である。

以下では、一例として、ローカルネットワークＮ１内には端末１０Ａ（端末ＩＤ「Ｔ００１」）～端末１０Ｅ（端末ＩＤ「Ｔ００５」）の５台の端末１０が存在するものとする。そして、デフォルト処理時（つまり、負荷分散を行っていない時）には、図２５の上図に示すように、機器から収集したデータを端末１０Ａのアプリ１１０Ａで加工し、その加工後のデータを端末１０Ｂのアプリ１１０Ｂで解析し、その解析結果を示すデータを端末１０Ｃのアプリ１１０Ｃでデータ収集サーバ２０に送信する、といった一連の処理を行っているものとする。なお、以下では、デフォルト処理時に一連の処理を構成する各処理を実行する端末１０を「関連端末１０」ともいう。図２５の上図に示す例では、端末１０Ａ、端末１０Ｂ、及び端末１０Ｃが関連端末１０に該当する。

このとき、以下では、図２５の下図に示すように、端末１０Ｂを分散元端末１０として、端末１０Ｅに負荷分散対象のアプリ１１０Ｂを実行させる場合について説明する。すなわち、分散処理時には、機器から収集したデータを端末１０Ａのアプリ１１０Ａで加工し、その加工後のデータを端末１０Ｅのアプリ１１０Ｂで解析し、その解析結果を示すデータを端末１０Ｃのアプリ１１０Ｃでデータ収集サーバ２０に送信する、といった一連の処理を行うものとする。

まず、分散元端末１０（端末１０Ｂ）の端末確認部２０１は、図６のステップＳ１０１と同様に、端末確認処理を実行する（ステップＳ１２０１）。ただし、図７のステップＳ２０２では、例えば、認証装置３０が所持する参加済端末情報（又は、認証装置３０から取得した参加済端末情報）に含まれない端末ＩＤは、所属端末情報に追加しないようにする。

次に、分散元端末１０（端末１０Ｂ）の負荷検知部２０２は、図６のステップＳ１０２と同様に、負荷検知処理を実行する（ステップＳ１２０２）。

次に、負荷検知処理でアプリ１１０（アプリ１１０Ｂ）のＣＰＵ負荷率が高いと判定された場合、分散元端末１０（端末１０Ｂ）のアプリ環境条件依頼部２０３は、図６のステップＳ１０３と同様に、アプリ環境条件依頼処理を実行する（ステップＳ１２０３）。

各分散先端末１０（端末１０Ａ、端末１０Ｃ～端末１０Ｅ）の環境条件返答部２０４は、図６のステップＳ１０４と同様に、環境条件返答処理をそれぞれ実行する（ステップＳ１２０４）。

分散元端末１０（端末１０Ｂ）の分散先選択部２０５は、図６のステップＳ１０５と同様に、分散先選択処理を実行する（ステップＳ１２０５）。上述したように、ここでは、負荷分散対象のアプリ１１０（アプリ１１０Ｂ）を実行させる分散先端末１０として端末１０Ｅが選択されたものとする。

分散元端末１０（端末１０Ｂ）のデータ確認部２１０は、分散情報作成及び送信処理を実行する（ステップＳ１２０６）。分散情報作成及び送信処理では、分散情報が作成され、自身以外の各関連端末１０に当該分散情報が送信される。なお、分散情報作成及び送信処理の詳細については後述する。

次に、分散元端末１０（端末１０Ｂ）のアプリ分散部２０６は、アプリ分散処理（分散元側）を実行する（ステップＳ１２０７）。このアプリ分散処理（分散元側）では、図１５のステップＳ７０１～ステップＳ７０２は第一の実施形態と同様であるが、図１５のステップＳ７０３で負荷分散対象のアプリ１１０（アプリ１１０Ｂ）とそのアプリ実行情報と共に、上記のステップＳ１２０６で作成された分散情報も分散先端末１０（端末１０Ｅ）に送信される。

分散先端末１０（端末１０Ｅ）のアプリ分散部２０６は、アプリ分散処理（分散先側）を実行する（ステップＳ１２０８）。このアプリ分散処理（分散先側）では、図１７のステップＳ８０２～ステップＳ８０３は第一の実施形態と同様であるが、図１７のステップＳ８０１で負荷分散対象のアプリ１１０（アプリ１１０Ｂ）とそのアプリ実行情報と共に分散情報も受信される。また、図１７のステップＳ８０３でアプリ１１０Ｂが実行される際には、データ送信側端末１０（端末１０Ａ）から受信したデータが不正なデータであるか否かを確認した上で、当該データを入力データとしてアプリ１１０Ｂが実行される。このデータ確認処理の詳細については後述する。

分散先端末１０（端末１０Ｅ）のアプリ削除部２０７は、アプリ削除処理（分散先側）を実行する（ステップＳ１２０９）。このアプリ削除処理（分散先側）では、図１８のステップＳ９０１～ステップＳ９０４は第一の実施形態と同様であるが、ステップＳ９０５で分散元端末１０（端末１０Ｂ）だけなく、端末１０Ｂ以外の関連端末１０（端末１０Ａ及び端末１０Ｃ）にも完了通知が送信される。また、ステップＳ９０５が実行された後、分散情報が削除される。なお、各関連端末（端末１０Ａ、端末１０Ｂ、端末１０Ｃ）では、完了通知を受信した後に、この完了通知に対応するアプリ１１０に関する分散情報が削除される。

分散元端末１０（端末１０Ｂ）のアプリ削除部２０７は、アプリ削除処理（分散元側）を実行する（ステップＳ１２１０）。このアプリ削除処理（分散先側）では、図１９のステップＳ１００１～ステップＳ１００２は第一の実施形態と同様であるが、ステップＳ１００２が実行された後に分散情報が削除される。

≪分散情報作成及び送信処理の流れ≫
図２４のステップＳ１２０６の分散情報作成及び送信処理の流れについて、図２６を参照しながら説明する。図２６は、第二の実施形態に係る分散情報作成及び送信処理の流れの一例を説明するための図である。

分散元端末１０（端末１０Ｂ）のデータ確認部２１０は、負荷分散対象のアプリ１１０（アプリ１１０Ｂ）の分散情報を作成する（ステップＳ１３０１）。ここで、分散情報は負荷分散対象のアプリ１１０に関する情報のことであり、上述したように、負荷分散対象のアプリ１１０のアプリＩＤ、分散元端末１０の端末ＩＤ、分散先端末１０の端末ＩＤ、当該アプリ１１０の実行に用いるデータの送信元、当該アプリ１１０の実行結果を示すデータの送信先、分散開始時刻等が含まれる情報のことである。分散情報の具体例を図２７に示す。図２７に示す例は、アプリＩＤ「ＡＰ０２」、分散元端末ＩＤ「Ｔ００２」、分散先端末ＩＤ「Ｔ００５」、データ送信元「Ｔ００１」、データ送信先「Ｔ００３」、分散開始時刻「２０２０１１０１１０１０」が含まれる分散情報である。この分散情報は、負荷分散対象のアプリ１１０のアプリＩＤは「ＡＰ０２」、分散元端末１０の端末ＩＤは「Ｔ００２」、分散先端末１０の端末ＩＤは「Ｔ００５」、当該アプリ１１０の実行に用いるデータの送信元は「Ｔ００１」、当該アプリ１１０の実行結果を示すデータの送信先は「Ｔ００３」、負荷分散の開始時刻は２０２０年１１月０１日１０時１０分であることを表している。

ただし、上記の分散情報は一例であって、アプリＩＤ、分散元端末ＩＤ、分散先端末ＩＤ、データ送信元、データ送信先、分散開始時刻以外の任意の情報が含まれていてもよい。

次に、分散元端末１０（端末１０Ｂ）のデータ確認部２１０は、自身以外の他の関連端末１０（端末１０Ａ及び端末１０Ｃ）に対して、上記のステップＳ１３０１で作成した分散情報を送信する（ステップＳ１３０２）。これにより、各関連端末１０は分散情報を保持することになる。

≪データ確認処理の流れ≫
次に、図１７のステップＳ８０３で分散先端末１０が負荷分散対象のアプリ１１０Ｂを実行する際に、データ送信側端末１０（端末１０Ａ）から受信したデータが不正なデータであるか否かを確認する場合のデータ確認処理の流れについて、図２８を参照しながら説明する。図２８は、第二の実施形態に係るデータ確認処理の流れの一例を説明するための図である。

データ送信側端末１０（端末１０Ａ）のデータ確認部２１０は、自身が所持する分散情報と秘密鍵から所定のハッシュ関数によりハッシュ値を算出する（ステップＳ１４０１）。

次に、データ送信側端末１０（端末１０Ａ）のデータ確認部２１０は、分散情報を参照して、当該アプリ１１０Ｂの実行に用いられるデータと、上記のステップＳ１４０１で算出されたハッシュ値とをデータ受信側端末１０（端末１０Ｅ）に送信する（ステップＳ１４０２）。なお、データ受信側端末１０の端末ＩＤは、分散情報に含まれる分散先端末ＩＤから特定することができる。

データ受信側端末１０（端末１０Ｅ）のデータ確認部２１０は、データ送信側端末１０（端末１０Ａ）からのデータ及びハッシュ値を受信する（ステップＳ１４０３）。

次に、データ受信側端末１０（端末１０Ｅ）のデータ確認部２１０は、自身が所持する分散情報と秘密鍵から所定のハッシュ関数によりハッシュ値を算出する（ステップＳ１４０４）。

次に、データ受信側端末１０（端末１０Ｅ）のデータ確認部２１０は、上記のステップＳ１４０３で受信したハッシュ値と、上記のステップＳ１４０４で算出したハッシュ値とが一致するか否かを検証する（ステップＳ１４０５）。

そして、データ受信側端末１０（端末１０Ｅ）のデータ確認部２１０は、上記のステップＳ１４０５の検証の結果、ハッシュ値が一致する場合は上記のステップＳ１４０３で受信したデータを入力データとしてアプリ分散部２０６により当該アプリ１１０（アプリ１１０Ｂ）を実行し、そうでない場合は異常を通知する（ステップＳ１４０６）。これにより、データ送信側端末１０が秘密鍵と分散情報を所持している正規の端末１０である場合にのみ、このデータ送信側端末１０から受信したデータを入力データとして負荷分散対象のアプリ１１０が実行される。したがって、不正なデータを用いてアプリ１１０が実行されてしまう事態を防止することが可能となる。

＜まとめ＞
以上のように、第一の実施形態に係るシステム１に含まれる複数の端末１０は、ローカルネットワークＮ１内に存在する他の端末１０に自身のアプリ１１０を実行させることで、負荷分散を実現することができる。しかも、この際に、各端末１０は、他の端末１０が当該アプリ１１０を実行することができるか否かに加えて、当該他の端末１０の現在の負荷状況や通信状況等を考慮して、負荷分散先の他の端末１０を選択する。これにより、本実施形態に係るシステム１は、各端末１０を管理するサーバを必要とせずに、各端末１０だけで適切な負荷分散を実現することが可能となる。

また、第二の実施形態に係るシステム１では、認証装置３０を導入することで、不正な端末がローカルネットワークＮ１に参加してしまう事態を防止することができる。また、万が一、不正な端末がローカルネットワークＮ１に参加してしまったとしても、負荷分散対象のアプリ１１０に用いられるデータを受信したときに、当該データが不正なデータであるか否かを確認することができるため、不正なデータにより当該アプリ１１０が実行されてしまう事態を防止することが可能となる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。

１ システム
１０ 端末
２０ データ収集サーバ
１００ アプリ実行環境
１１０ アプリ
２００ 分散機能部
２０１ 端末確認部
２０２ 負荷検知部
２０３ アプリ環境条件依頼部
２０４ 環境条件返答部
２０５ 分散先選択部
２０６ アプリ分散部
２０７ アプリ削除部
５０１ 入力装置
５０２ 表示装置
５０３ 外部Ｉ／Ｆ
５０３ａ 記録媒体
５０４ 通信Ｉ／Ｆ
５０５ プロセッサ
５０６ メモリ装置
５０７ バス
Ｎ１ ローカルネットワーク
Ｎ２ インターネット

Claims (8)

1. １以上のアプリケーションを実行する複数の端末と、認証装置とが含まれるシステムであって、
   前記端末は、
   自身が有する演算装置の負荷率が所定の閾値を超えた場合、前記アプリケーションの実行に必要な条件を示すアプリ条件情報を他の端末に送信する条件送信部と、
   前記アプリ条件情報に対する返信として、前記条件を満たすか否かを示す情報が含まれる返答情報を他の端末から受信する返答受信部と、
   前記返答情報に基づいて、前記他の端末の中から、前記アプリケーションを実行させる他の端末を選択する選択部と、
   選択された前記他の端末に対して、前記アプリケーションと、前記アプリケーションの実行に必要な情報とを送信するアプリ送信部と、
   前記認証装置は、
   新たな端末が前記システムに参加する場合、前記新たな端末に対して秘密鍵を送信する秘密鍵送信部と、
   前記新たな端末の識別情報を、前記システムに既に参加している端末に送信する識別情報送信部と、を有し、
   前記新たな端末は、
   前記認証装置から送信された秘密鍵と自身の識別情報とから算出されたハッシュ値を、前記システムに既に参加している端末に送信するハッシュ値送信部、を有し、
   前記端末は、
   前記新たな端末から受信したハッシュ値が、自身が持つ秘密鍵と前記認証装置から送信された識別情報とから算出されたハッシュ値と一致するか否かを検証する第１の検証部と、を更に有し、
   前記条件送信部は、
   前記第１の検証部によって前記ハッシュ値が一致することが検証された他の端末に前記アプリ条件情報を送信する、システム。
2. 前記選択部は、
   すべての前記条件を満たすことを示す情報が含まれる返答情報を返信した他の端末の中から、前記アプリケーションを実行させる他の端末を選択する、請求項１に記載のシステム。
3. 前記返答情報には、該返答情報を返信した他の端末が有する演算装置の負荷率が更に含まれ、
   前記選択部は、
   前記返答情報に含まれる負荷率が所定の閾値を超えていない他の端末の中から、前記アプリケーションを実行させる他の端末を選択する、請求項１又は２に記載のシステム。
4. 前記選択部は、
   前記アプリ条件情報の送信後、前記返答情報を受信するまでの経過時間が所定の閾値を超えていない他の端末の中から、前記アプリケーションを実行させる他の端末を選択する、請求項１乃至３の何れか一項に記載のシステム。
5. 前記アプリ条件情報には、前記アプリケーションの実行に必要なＯＳに関する条件、ミドルウェアに関する条件、ハードウェアリソースに関する条件、及び演算装置の使用率に関する条件の少なくとも１つ以上の条件が含まれる、請求項１乃至４の何れか一項に記載のシステム。
6. 前記端末が所属するネットワーク内に対して疎通確認をブロードキャストする確認部を有し、
   前記条件送信部は、
   前記疎通確認に対して応答があった他の端末に対して、前記アプリ条件情報を送信する、請求項１乃至５の何れか一項に記載のシステム。
7. 前記端末は、
   前記アプリケーションの処理に関連する他の端末と、前記選択部によって選択された他の端末とに対して、前記アプリケーションの負荷分散に関する情報を送信する分散情報送信部、を有し、
   前記アプリケーションの処理に関連する他の端末のうち、前記アプリケーションの実行に用いられるデータを送信する端末は、
   前記アプリケーションの負荷分散に関する情報と自身が持つ秘密鍵とから算出されたハッシュ値と、前記データとを、前記選択部によって選択された他の端末に送信するデータ送信部、を有し、
   前記選択部によって選択された他の端末は、
   前記アプリケーションの実行に用いられるデータを送信する端末から受信したハッシュ値が、前記アプリケーションの負荷分散に関する情報と自身が持つ秘密鍵とから算出されたハッシュ値と一致するか否かを検証する第２の検証部と、
   前記第２の検証部によって前記ハッシュ値が一致することが検証された場合、前記データを入力データとして前記アプリケーションを実行するアプリ実行部と、を有する請求項１乃至６の何れか一項に記載のシステム。
8. １以上のアプリケーションを実行する複数の端末と、認証装置とが含まれるシステムに用いられる方法であって、
   前記端末が、
   自身が有する演算装置の負荷率が所定の閾値を超えた場合、前記アプリケーションの実行に必要な条件を示すアプリ条件情報を他の端末に送信する条件送信手順と、
   前記アプリ条件情報に対する返信として、前記条件を満たすか否かを示す情報が含まれる返答情報を他の端末から受信する返答受信手順と、
   前記返答情報に基づいて、前記他の端末の中から、前記アプリケーションを実行させる他の端末を選択する選択手順と、
   選択された前記他の端末に対して、前記アプリケーションと、前記アプリケーションの実行に必要な情報とを送信するアプリ送信手順と、を実行し、
   前記認証装置が、
   新たな端末が前記システムに参加する場合、前記新たな端末に対して秘密鍵を送信する秘密鍵送信手順と、
   前記新たな端末の識別情報を、前記システムに既に参加している端末に送信する識別情報送信手順と、を実行し、
   前記新たな端末が、
   前記認証装置から送信された秘密鍵と自身の識別情報とから算出されたハッシュ値を、前記システムに既に参加している端末に送信するハッシュ値送信手順、を実行し、
   前記端末が、
   前記新たな端末から受信したハッシュ値が、自身が持つ秘密鍵と前記認証装置から送信された識別情報とから算出されたハッシュ値と一致するか否かを検証する第１の検証手順と、を更に実行し、
   前記条件送信手順は、
   前記第１の検証手順によって前記ハッシュ値が一致することが検証された他の端末に前記アプリ条件情報を送信する、方法。

Images