JP6770922B2 - データ収集基盤 - Google Patents

Description

本発明は、ゲートウェイ集約型のデータ収集システムに好適なデータ収集基盤に関する。

複数のセンサ情報を、アプリケーションの要求に応じて収集、解析するＩｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）システムは、全てのセンサデータをクラウドサーバに集約して解析するクラウド集約型と、ゲートウェイやエッジサーバで必要な粒度に集約してデータを収集するゲートウェイ集約型とがある。

上記後者のゲートウェイ集約型では、上記前者のクラウド集約型に比して、ネットワークリソースやストレージ資源を節約できるというメリットがある。この種のゲートウェイ集約型のＩｏＴアーキテクチャにおいて、例えばエッジサーバのクラウド全体に対する役割を最適化するための技術が提案されている（例えば、非特許文献１を参照）。

白鳥則郎，北上眞二，菅沼拓夫，菅原研次，嶋本 薫"ＩｏＴアーキテクチャの最新動向"電子情報通信学会誌 Ｖｏｌ．１００，Ｎｏ．３，ｐｐ．２１４−２２１，２０１７年３月。

しかしながら、ゲートウェイ集約型では、予め利用するアプリケーションに応じたモジュール配置設計を行ない、その設計に基づいてモジュールを配置する必要がある。そのため、新たなアプリケーションやセンサを追加する際には、モジュールの再配置の設計、再配置に要する作業が大きく、迅速な対応が困難となるという不具合があった。

本発明は上記のような実情に鑑みてなされたもので、その目的とするところは、ゲートウェイ集約型のデータ収集システムにおいて、配置されるアプリケーションに応じて、データ処理ノード上のモジュール配置を柔軟且つ迅速に行なうことが可能なデータ収集基盤を提供することにある。

本発明の一態様は、１以上のアプリケーションと複数のセンサが、ネットワークにより複数のデータ処理ノードを介して接続されるＩｏＴプラットフォームであって、アプリケーションの要求条件を受け付ける要件管理部と、上記各データ処理ノードの計算資源とネットワーク帯域情報を資源情報として管理する資源管理部と、上記要件管理部で受け付けたアプリケーションの要求条件と上記資源管理部が管理する資源情報とに基づいて、上記複数のデータ処理ノードで当該アプリケーションを実行するモジュールの配置計算を行なう配置計算部と、上記配置計算部での計算の結果に従ってデータ処理ノードにモジュールを配備する配置実行管理部とを有する基盤管理部を備える。

本発明によれば、ゲートウェイ集約型のデータ収集システムにおいて、配置されるアプリケーションに応じて、データ処理ノード上のモジュール配置を柔軟且つ迅速に行なうことが可能となる。

本発明の一実施形態に係るデータ収集基盤の機能構成を示すブロック図。 同実施形態に係る処理の流れと各種ヘルパープログラムの関係を示す図。 同実施形態に係るアプリケーション要件の記載方法を例示する図。 同実施形態に係るアプリケーション要件の記載方法を例示する図。 同実施形態に係るアプリケーションの便益について説明する図。 同実施形態に係るＩｏＴシステムに新たなアプリケーションを追加した際の処理内容を示すシーケンス図。 同実施形態に係る配置計算部が実行する配置計算の処理内容を示すフローチャート。 同実施形態に係る配置計算部が配置したモジュール構成と、その構成を得るために作成するモジュール構成作成プログラム表の内容とを例示する図。 同実施形態に係る最小モジュール取得時のデータ処理ノードの構成と、そのモジュール構成とを例示する図。 同実施形態に係る最小モジュール取得処理時の他のデータ処理ノードの構成と、そのモジュール構成とを例示する図。 同実施形態に係る第１のモジュール共有化処理時のモジュールを共有化した構成と、共有化判定プログラム表、及び上位互換共有化判定プログラム表を例示する図。 同実施形態に係る第１のモジュール共有化処理の第１の例を示す図。 同実施形態に係る第１のモジュール共有化処理の第２の例を示す図。 同実施形態に係る第１のモジュール共有化処理の第３の例を示す図。 同実施形態に係る第１のモジュール共有化処理の第４の例を示す図。 同実施形態に係る等価モジュール展開処理で使用される等価モジュール表及び等価モジュール列算出プログラム表を例示する図。 同実施形態に係る等価モジュール展開処理を捕捉説明する図。 同実施形態に係る第２のモジュール共有化処理時のモジュール構成の例を示す図。 同実施形態に係る実ノードデバイスへの割付処理時のモジュール構成とデータ処理ノード構成とを例示する図。 同実施形態に係る資源管理部で管理するノード情報、モジュール情報、及びセンサ情報の各テーブルを例示する図。 同実施形態に係る実ノードデバイスへの割付処理時のネットワークリソースの割付構成を例示する図。 同実施形態に係る収容可否判定処理時に資源管理部に管理されるリンク情報とリソース使用率のベクトルを例示する図。 同実施形態に係る局所探索法により配置計算を行なう場合の処理過程を簡略化して示す図。 同実施形態に係る動的モニタリングによる必要資源算出の処理の流れを示すシーケンス図。 同実施形態に係る無中断モジュール切替処理を例示する図。 同実施形態に係る異常状態でのモジュール停止の実現方法を例示する図。 同実施形態に係る配置実行管理部による実行可能優先度とモジュールの管理の内容を例示する図。 同実施形態に係るモジュールのチェーン化と等価変換の例を示す図。 同実施形態に係る中間データモジュールの組み換えによるリソース削減の例を示す図。 同実施形態に係る中間データモジュールの組み換えによるリソース削減の第２の例を示す図。 同実施形態に係るモジュール構成の変換を例示する図。 同実施形態に係るモジュール構成の変換を例示する図。

以下、本発明をＩｏＴシステムのデータ収集基盤が備える基盤管理部に適用した一実施形態について、図面を参照して詳細に説明する。

図１は、ＩｏＴシステムのデータ収集基盤の機能構成を示すブロック図である。同図では、ＩｏＴシステムが、その下層側から順に、センサ１，１，…、ゲートウェイ（ＩｏＴ ＧＷ）２，２，…、エッジサーバ３，３，…、及びクラウドサーバ４の４層で構成される場合を例にとって示す。

中層のゲートウェイ２，２，…及びエッジサーバ３，３，…が、それぞれデータ処理ノードとして、後述する配置実行管理部１５によって配備されたモジュールに基づいて直下層からの複数のデータを収集して、直上層に送る。

最上層のクラウドサーバ４は、割り当てられたアプリケーション５に従って、直下層のエッジサーバ３，３，…からのデータを収集、解析する。

上記アプリケーション５は、要件受付インタフェイス６を介して、ＩｏＴプラットフォームであるデータ収集基盤を構成する基盤管理部１０に対して、必要とする要件の情報を予め伝送している。

基盤管理部１０は、基盤管理部１０内で実行する各種プログラムやデータ等を記憶するデータベース１１と、要件管理部１２、資源管理部１３、配置計算部１４、及び配置実行管理部１５とを備える。

要件管理部１２は、アプリケーション５が必要とする要件を要件受付インタフェイス６を介して受付ける。

資源管理部１３は、データ処理ノードとなるゲートウェイ２，２，…やエッジサーバ３，３，…の配置、及びネットワークの帯域や、計算資源の上限等を把握する。

配置計算部１４は、複数のアプリケーションの要件を基に、データ集計処理を行なうモジュールの構成、配置を計算する。

配置実行管理部１５は、配置計算部１４が計算したモジュールの構成、配置に基づいて、実際の各データ処理ノードにモジュールを配備させる。

図２は、主として上記配置計算部１４が実行する処理の流れと、各種ヘルパープログラムの関係を示す図である。配置計算部１４では、各アプリケーション毎に要求されている要件と、ここでは図示しない上記資源管理部１３の資源情報とから、モジュール構成作成プログラム２１が必要となるモジュール構成を作成する。これら複数のモジュール構成を取り纏めて初期モジュール構成とする。

この初期モジュール構成に対して、共有化判定プログラム２２により同様の処理を実行するモジュールの共有化判定を行なって、必要なモジュールの構成を作成する。

こうして作成したモジュール構成に対し、さらに等価モジュール列算出プログラム２３がその内容を精査し、より効率的なモジュール構成に組み替える。

そして、これらのモジュール構成が、割付け、収容可否判定、最適構成選択のためのプログラム２４により再構成された上で、上記配置実行管理部１５により実環境である各データ処理ノードに対して配備される。

図３及び図４は、アプリケーション要件の記載方法を例示する図である。
図３は、「ＳｅｎｓｉｎｇＡｐｐ１」なる名前のアプリケーション要件を記載しており、図示する如く「ｄａｔａ」なる名前のデータチャネルＣＨ１と、「ａｌｅｒｔ」なる名前のデータチャネルＣＨ２の複数のデータチャネルを指定している。

データチャネルＣＨ１においては、単一モジュールとしてのモジュール名（ＡｌｇｏｒｉｔｈｍＮａｍｅ）「ＡＶＧ」とそのパラメータを記載すると共に、当該チャネルの優先度（Ｐｒｉｏｒｉｔｙ）情報が「１」であることを記載している。

同様に、データチャネルＣＨ２においても、当該チャネルの優先度情報が「５」であることを記載している。この場合、優先度情報は数値の大きいものがより優先度が高いものとしている。

図４は、「Ｔｒｉｇｇｅｒ」なる名前のアプリケーション要件を記載している。同図中に示す領域ＡＲ１では、スループット（Ｔｈｒｏｕｇｈｐｕｔ）の性能に係る要件とそのパラメータを記載している。この記載に関しては、他にも、例えば
「ＢｅｎｅｆｉｔＦｕｎｃｔｉｏｎ ： ｆｕｎｃｔｉｏｎ（ｔ）‥‥
ＢｅｎｅｆｉｔＦｕｎｃｔｉｏｎＮａｍｅ ： Ｍｙｆｕｎｃｔｉｏｎ‥‥ 」
のように記載することも考えられる。

次にアプリケーションの便益について説明する。
アプリケーションは、スループットやレイテンシの性能に関する要求条件を便益として記述できる。

図５（Ａ）、図５（Ｂ）は共に、スループットに関するアプリケーションの便益を記載したモデルである。図５（Ａ）では、スループットがｘ１以下では「０（ゼロ）」、ｘ１からｘ２に至る間、便益がｙ１からｙ２まで増加し、ｘ２以上は一定値ｙ２となる。
図５（Ｂ）は、パラメータを３点に増やした場合を示す。

このように、アプリケーションはパラメータ列ｘ１，ｙ１，ｘ２，ｙ２，‥‥で便益を記述することができる。

またアプリケーションは、具体的な便益を求めるプログラム、あるいはそのプログラムの名称を与えるように構成しても良い。

便益の値としては、例えば「１」を受け入れられる最低限の値として取り決めて、例えば、
「Ｂｅｎｅｆｉｔ：“ｆｕｎｃｔｉｏｎ（ｔ）｛ｉｆ（ｔ＜１００）｛ｒｅｔｕｒｎ０｝
ｅｌｓｅ｛ｒｅｔｕｒｎ１｝｝”
あるいは、
「Ｂｅｎｅｆｉｔ：“ｍｙＯｒｉｇｉｎａｌＢｅｎｅｆｉｔＦｕｎｃｔｉｏｎ”」
のような記述により実現できる。

図５（Ｃ）は、性能に関するパラメータがレイテンシである場合を記載したモデルである。ここではレイテンシがｘ１以下では便益が一定値ｙ１、ｘ１からｘ２に至る間、便益がｙ１からｙ２まで減少し、レイテンシがｘ２以上は「０（ゼロ）」となる。

レイテンシの場合、レイテンシが小さい方が便益が高くなるもので、スループットの場合と同様に、アプリケーションはパラメータ列ｘ１，ｙ１，ｘ２，ｙ２，‥‥で便益を記述することができる。

以下、上記実施形態の具体的な動作について順次説明する。
図６は、ＩｏＴシステムで新たなアプリケーションを追加した際の処理内容を示すシーケンス図である。その当初、アプリケーション５が、要件受付インタフェイス６を介して基盤管理部１０の要件管理部１２に対し、上記図３及び図４で説明したような記載方法によるフォーマットの要件のデータを送信する（ステップＳ１０１）。

これを受けた要件管理部１２は、配置計算部１４に対してアプリケーション追加による要件変更が発生したことの通知を行なう（ステップＳ１０２）。

配置計算部１４がこの通知に対応し、要件管理部１２に対して要件の一覧を取得する要求を行ない（ステップＳ１０３）、要件管理部１２からその応答情報を受信する（ステップＳ１０４）。

併せて配置計算部１４は、資源管理部１３に対して資源情報を取得する要求を行ない（ステップＳ１０５）、資源管理部１３からその応答情報を受信する（ステップＳ１０６）。

配置計算部１４は、こうして得られた最新の状況を示す要件の一覧情報と資源情報とにより配置計算の処理を実行する（ステップＳ２００）。配置計算部１４は、この配置計算により、新たに追加された要件を満たす配置構成が得られたかどうかを、再配置可否結果通知として要件管理部１２に送信する（ステップＳ１０７）。

再配置可否結果通知を受けた要件管理部１２では、当該通知に応じて要件の受付可否の回答を、要件受付インタフェイス６を介してアプリケーション５に返答する。

また配置計算部１４は、上記配置計算で新たに追加された要件を満たす配置構成が得られた場合、さらに配置実行管理部１５に対して算出した配置の指示を行なう（ステップＳ１０９）。

この配置計算部１４からの配置の指示に従い、配置実行管理部１５が複数のデータ処理ノード１，２に対してそのノード上で動作させるモジュールの配置指示を通知する（ステップＳ１１０）。

ここで通知される配置指示は、具体的には、モジュール起動、モジュール停止、及びモジュール設定変更の３種類の命令をセットにしたもので構成される。

次に上記配置計算部１４が上記配置計算Ｓ２００により実行する動作手順の詳細について説明する。

図７は、配置計算部１４による処理内容を示すフローチャートである。その当初に配置計算部１４では、アプリケーションの要求から、求められるチャネルを実現する最小構成のモジュール配置を求める。全てのアプリケーションの要求について同様に実行し、それらの結果すべてを足し合わせたモジュール構成Ｃ１を取得する（ステップＳ２０１）。

図８（Ａ）は、このとき配置計算部１４が配置したモジュール構成Ｃ１を例示する図である。３つのセンサ１，１，１の出力データをモジュールＡ，Ｂ，Ｂにより収集し、アプリケーション１，２にチャンネルＣＨ１，ＣＨ２，ＣＨ３で取り纏めている状態を例示している。

このステップＳ２０１の処理を詳細に説明する。配置計算部１４は、まずアプリケーションの要件に記載されているアルゴリズム名と、それに対応した、最小のモジュール構成を作成するプログラム名を、モジュール構成作成プログラム表として記載しておく。

図８（Ｂ）は、このとき作成されるモジュール構成作成プログラム表の内容を例示する図である。アルゴリズム名とプログラム名の対応表であり、アプリケーションの要求の、各チャネルの内部に記載されているアルゴリズム名を上記作成したプログラム表から検索し、対応するプログラム名を得る。ここでプログラム名が記述されているプログラムは、予め上記データベース１１に格納されている。

すなわち、各プログラムは、上記のように得たプログラム名に対して、アプリケーション中の該当チャネル内のパラメータと、資源管理部１３で管理しているデータ処理ノードの構成を追加して与えることで、最小のモジュール構成が取得できるように予め構成された状態で、データベース１１に格納されている。

例えば、下記に示すようなアプリケーション要件
「｛
ｎａｍｅ： ｓａｍｐｌｅ＿ｔｉｍｅ＿ｓｅｒｉｅｓ
Ｐｒｏｃｅｓｓｉｎｇ： ｛
ＡｌｇｏｒｉｔｈｍＮａｍｅ： Ｔｉｍｅ＿Ｓｅｒｉｅｓ＿ＡＶＧ，
ＡｇｇｒｅｔａｔｉｏｎＵｎｉｔ： ３，
ｔａｒｇｅｔＳｅｎｓｏｒｓ： ［ “ＩＤ−１”］
｝」
が与えられたものとする。

図９（Ａ）は、センサ「ＩＤ−１」の出力するデータがノード１により収集され、その上位のノード３でさらに他のデータと取り纏められる場合の、データ処理ノードの構成を例示している。

上記図８（Ｂ）でも示した、この「Ｔｉｍｅ＿Ｓｅｒｉｅｓ＿ＡＶＧ」という名前のアルゴリズムは、時系列データがセンサかに出力された際に、定期的な時間のデータの平均値を得るというものである。

上記定期的な時間は、パラメータとして設定でき、本例では「ＡｇｇｒｅｔａｔｉｏｎＵｎｉｔ」の場所に記載されている「３［秒］」が、時系列データの平均を算出する区間となる。

上記図８（Ｂ）で示したプログラム名「ＧＥＮ＿ＭＯＤＵＬＥ＿ＴＩＭＥ＿ＳＥＲＩＥＳ＿ＡＶＧ」のプログラムに対して、上記のアプリケーション要件内のチャネル部分のデータ、データノード構成を与えることで、モジュール構成が作成されて返される。

図９（Ｂ）にそのモジュール構成を図示するように、返されたモジュール構成では、センサから始まり、１つ以上、上のモジュールを経由して、チャンネル名で指定されるノードまでの接続関係が情報として表現されている。

また異なる例として、例えば下記に示すアプリケーション要件
「｛
ｎａｍｅ： Ｔｏｋｙｏ＿ｔｅｍｐｅｒａｔｕｒｅ，
Ｐｒｏｃｅｓｓｉｎｇ： ｛
ＡｌｇｏｒｉｔｈｍＮａｍｅ： ＡＶＧ＿ＬＡＴＥＳＴ，
ＡｇｇｒｅｔａｔｉｏｎＵｎｉｔ： ６０，
ｔａｒｇｅｔＳｅｎｓｏｒｓＢｙＴｙｐｅ：
“＆（（ｔｙｐｅ＝ｔｅｍｐｅｒａｔｕｒｅ）（ｒｅｇｉｏｎ＝Ｔｏｋｙｏ）”
｝」
が与えられたものとする。

図１０（Ａ）は、このときに渡されるデータ処理ノードの構成を例示するものである。アルゴリズム名「ＡＶＧ＿ＬＡＴＥＳＴ」は、複数のセンサの最新値の平均値を得るものであり、「ＡｇｇｒｅｔａｔｉｏｎＵｎｉｔ」に指定されている「６０［秒］」毎に、各センサの最新値から平均値を算出して、アプリケーションに届けることを示している。

プログラム名「ＧＥＮ＿ＭＯＤＵＬＥ＿ＡＶＧ＿ＬＡＴＥＳＴ」のプログラムに対して、上記のアプリケーション要件内のチャネル部分のデータ、データノード構成を与えることで、モジュール構成が作成されて返される。図１０（Ｂ）にそのモジュール構成を図示する。

上記図９に示した例では、センサのＩＤを直接指定していたのに対し、ここでは要件をセンサの属性により指定している。ここでは、「ＬＤＡＰ Ｆｉｌｔｅｒ」の書式に基づいて記載されており、センサタイプが「温度センサ（ｔｅｍｐｅｒａｔｕｒｅ）」であり、且つ地域（リージョン）が「東京（Ｔｏｋｙｏ）」に配置されているセンサを指定している。

このような指定を可能にすることにより、ＩｏＴシステムで日々追加されていくセンサに対して、アプリケーションはそのアプリケーションを指定する必要がなくなり、なおかつ、新しく追加されたセンサの構成に対応して、モジュールの配置計算を実視できる、という利点が生じることになる。

上記図７のステップＳ２０１における最小モジュールの構成が終了すると、次に配置計算部１４では第１のモジュール共有化処理として、モジュール共有化処理が実施できれば、そのまま実施してモジュール構成Ｃ２を取得する（ステップＳ２０２）。

図１１（Ａ）は、上記図８（Ａ）で示したモジュール構成に対して、２つのモジュールＢを共有化したモジュール構成Ｃ２を例示している。

このステップＳ２０２の処理内では、構成中のモジュールを共有化することで、
（１）処理内容に変更なくモジュール数を減らすことができる場合、及び（２）モジュールの数は減らないが、処理に用いられるリソースを削減できる可能性がある場合を探索する。

構成内の２つのモジュールに注目し、共有できるかどうかをチェックし、共有できる場合はその置換を行なう。さらに、共有化できるモジュールがあれば共有化を行なう、という処理を、それ以上の共有化が不可能であると判断するまで繰返し実行する。

ここであらためて共有化できる場合をケース分類化すると、
（１）同タイプ同設定
（２）同タイプ異設定
（３）上位互換モジュールとの共有化
（４）相互の上位互換モジュール
となる。

上記（１）の同タイプ同設定は、同一の入力を受け取っており、同一のタイプのモジュールで、設定が同一である場合を示す。

上記（２）の同タイプ異設定は、同一の入力を受け取っており、同一のタイプのモジュールで、設定が異なる場合を示す。この場合、図１１（Ｂ）に示す共有化プログラム表で定義される、モジュール名に対応するプログラム名に対応したプログラムを用いて、異なる２種類の設定を渡すことで、当該プログラムにより変換可能な構造の集合が返されるので、返された構造に置換する。

置換の種類が複数可能である場合には、複数の結果が返される。複数ある場合には、それぞれの構造について処理を継続する。また、共有化が不可能な場合や、存在しても非効率な場合は、共有化は行なわないものとして、空集合が返される。

上記（３）の上位互換モジュールとの共有化は、図１１（Ｃ）に示す上位互換共有化判定プログラム表を参照することで、そのモジュール名に対応する上位互換モジュール名と上位互換共有化判定プログラム名があるか否かにより、当該モジュールの上位互換モジュールの有無を判定できる。

注目する２つのモジュールにこの上位互換性の関係がある場合、共有化できる可能性がある。この上位互換共有化判定プログラム表で参照される上位互換共有化判定プログラムに対して、共有に関するモジュール名と設定をパラメータとして問い合わせることで、共有化した後の構造の集合が返される。返された構造の集合が複数ある場合には、それぞれの構造について処理を継続する。

例えば複数のモジュール中に、図１１（Ｃ）に示す上位互換共有化判定プログラム表中の、５［秒］間毎の最大値を算出するモジュール「ＭＡＸ」と、５［秒］間毎の統計を算出するモジュール「ＳＴＡＴ」とが存在した場合、後者の上位互換モジュール「ＳＴＡＴ」の方で共有化できる。

上記（４）の相互の上位互換モジュールは、注目する２つのモジュールに共通する上位互換モジュールが存在する場合に、その上位互換モジュールで共有化できる可能性がある場合を示す。上記（３）の上位互換モジュールとの共有化の場合と同様に、評価から検索した、上位互換共有化判定プログラムに問い合わせて、置換可能なモジュールの構成群を得る。

図１２は、第１のモジュール共有化処理の第１の例を示す図であり、上記（１）の同タイプ同設定の場合を示す。図１２（Ａ）に示すようなモジュール構成があった場合、モジュールＭ１０２とモジュールＭ１０３に注目すると、同一の入力、同一のタイプ、且つ設定が同一であるため、図１２（Ｂ）に示すように、モジュールＭ１０２に共有化できるものとして、モジュールＭ１０３の存在を廃することができる。

図１３は、第１のモジュール共有化処理の第２の例を示す図であり、上記（２）の同タイプ異設定の場合を示す。図１３（Ａ）に示すようなモジュール構成があった場合、モジュールＭ２０２とモジュールＭ２０３に注目すると、同一の入力、同一のタイプ、で設定のみが異なる。ここで、上記図１１（Ｂ）で示したプログラム「ＳＨＡＲＥ＿ＭＡＸ」に問い合わせることで、図１３（Ｂ）中のモジュールＭ２０６に示すような構成が返却される。

すなわち、共有化処理によるモジュール数は変化していないものの、システムの消費リソース数が抑えられるものとなる。

例えば、図中のセンサＩＤ−１が、秒間に１０００個の計測データを出力する場合、図１３（Ａ）に示す構成では、モジュールＭ２０４とモジュールＭ２０５でのメッセージ量は秒間２０００個となる。

一方、図１３（Ｂ）に示す共有化後の構成では、モジュールＭ２０７とモジュールＭ２０６の秒間合計のメッセージ量は１００１個となり、概ね半減することが可能となる。

また計算量においても、共有化前のモジュールＭ２０２とモジュールＭ２０３で秒間２０００回の処理を行なっていたのに対し、共有化後のモジュールＭ２０８とモジュールＭ２１０で秒間１００１回の処理と、計算量も概ね半減できる。

なお上記プログラム「ＳＨＡＲＥ＿ＭＡＸ」は、ＭＡＸモジュールを習熟した開発者によって記載されたプログラムであることを前提とする。

図１４は、第１のモジュール共有化処理の第３の例を示す図であり、上記（３）の上位互換モジュールとの共有化の場合を示す。図１４（Ａ）に示すようなモジュール構成があった場合、モジュールＭ３０２とモジュールＭ３０３に注目すると、上位互換モジュールとの共有化に該当する。ここで、上記図１１（Ｃ）で示したプログラム「ＵＰ＿ＳＨＡＲＥ＿ＣＨＥＣＫ＿ＳＴＡＴ」に問い合わせることで、図１４（Ｂ）中のモジュールＭ３０９に示すような構成が返却される。

ここでは共有化により、モジュール数が増加するものの、システムの消費リソース数が抑えられるものとなる。

図中のモジュールＭ３０２、モジュールＭ３０８に示す「ＳＴＡＴ」は、入力されるデータの統計量を計算するモジュールであり、ＪＳＯＮ（Ｊａｖａ Ｓｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）的な記述フォーマットでは、例えば
「｛
“ｍａｘ”：１２０，
“ｍｉｎ”：１２，
“ａｖｇ”：６０，
“ｎ”：１０００
“ｓｕｍ”：６４０００，
“ｓｕｍ２”：５８８８８００
｝」
（但し、ｍａｘは最大値、ｍｉｎは最小値、ａｖｇは平均値、ｎはデータ個数、ｓｕｍはデータの合計、ｓｕｍ２はデータの二乗和。）
のような記述内容となる。

また図１４（Ｂ）中のモジュールＭ３１３「ＥＸＴＲＡＣＴ」は、「ｐａｒａｍ」として指定されているデータを抽出するモジュールであり、上述したフォーマットを受けると「ｍａｘ」の値１２０を出力する。

例えば、図中のセンサＩＤ−１が、秒間に１０００個の計測データを出力する場合、図１４（Ａ）に示す構成では、モジュールＭ３０４とモジュールＭ３０５でのメッセージ量は秒間２０００個となる。

一方、図１４（Ｂ）に示す共有化後の構成では、モジュールＭ３０７、モジュールＭ３１１、モジュールＭ３１２の秒間合計のメッセージ量は１００２個となり、概ね半減することが可能となる。

また計算量においても、共有化前のモジュールＭ２０２とモジュールＭ２０３で秒間２０００回の処理を行なっていたのに対し、共有化後のモジュールＭ３０８、モジュールＭ３１１、モジュールＭ３１２で秒間１００２回の処理と、計算量も概ね半減できる。

図１５は、第１のモジュール共有化処理の第４の例を示す図であり、上記（４）の相互の上位互換モジュールの場合を示す。図１５（Ａ）に示すようなモジュール構成があった場合、モジュールＭ４０２とモジュールＭ４０３に注目すると、相互の上位互換モジュールで共有化できる。ここで、上記図１１（Ｃ）で示したプログラム「ＵＰ＿ＳＨＡＲＥ＿ＣＨＥＣＫ＿ＳＴＡＴ」に問い合わせることで、図１５（Ｂ）中のモジュールＭ４１２に示すような構成が返却される。

ここで共有化により、モジュール数が増加するものの、システムの消費リソース数が抑えられるものとなる。

ここでは、上記図１４に示した場合と同様に、簡単な統計量を得るモジュール構成の場合について説明したが、本実施形態はこれに限らず、データの例は画像、複合センサの値や、機械学習用に加工したデータなど、ＩｏＴシステム上で様々なものを取扱うことが可能であるものとする。

上記図７のステップＳ２０２における第１のモジュール共有化処理が終了すると、次に配置計算部１４では等価モジュール展開処理として、上記モジュール構成Ｃ２に含まれる各モジュールについて、可能な置き換え処理を実行し、それをモジュール構成の集合Ｃ３として格納する（ステップＳ２０３）。

すなわち、上記モジュール構成Ｃ２に含まれるモジュールについて、等価なモジュール列を求めて、置き換えをおう。ここで等価なモジュールとは、置き換えたとしてもデータ処理上は同一の処理が行なえることを示す。各モジュールについて、置き換え対象が複数ある場合、それらすべてのパターンを置き換える。

例えば、上記図１１（Ａ）で示したモジュール構成Ｃ２で、モジュールＡとモジュールＢの２つのモジュールがあった場合、それぞれに２通りの置き換えパターンがあれば、９種類のモジュール構成をモジュール構成の集合Ｃ３として出力する。

図１７は、この点をあらためて説明する図である。モジュールＡの等価モジュールとしてモジュールＡ１とモジュールＡ２があり、モジュールＢの等価モジュールとしてモジュールＢ１とモジュールＢ２があるものとする。この図１７のモジュール構成の状態を［Ａ，Ｂ］と記述すると、上記ステップＳ２０３での等価モジュール展開処理により、［Ａ，Ｂ］［Ａ，Ｂ１］［Ａ，Ｂ２］［Ａ１，Ｂ］［Ａ１，Ｂ１］［Ａ１，Ｂ２］［Ａ２，Ｂ］［Ａ２，Ｂ１］［Ａ２，Ｂ２］の計９種類のモジュール構成が置き換え可能な等価のモジュール列として出力される。

実際に等価なモジュール列の集合を求める方法は２通り存在する。
第１の方法は、上記図１の基盤管理部１０内のデータベース１１に予め用意する等価モジュール表に記載されたモジュール列を検索することで、等価なモジュール列の集合Ｃ３を求める方法である。

図１６（Ａ）は、この等価モジュール表の内容を例示するものであって、データベース１１を検索することで等価なモジュール列の算出が可能となる。なおこの図１６（Ａ）に示す表では、各モジュールの設定が１つである場合について説明しているが、２つ以上であっても良い。

また図１７では、置換先のモジュールは２個である場合について説明したが、３個以上であっても良い。置換先モジュールが最大ｎとなるような表においても、ｎ未満の数ｋの置換モジュール列を、置換先モジュールｋ＋１の値を空白にすることで表現が可能となる。

また第２の方法は、等価なモジュール列を求めるプログラムが、上記図１の基盤管理部１０内のデータベース１１に予め用意する等価モジュール列算出プログラム表に登録されており、当該表を用いた問い合せを実行することで、等価なモジュール列の集合Ｃ３を得る方法である。

図１６（Ｂ）は、この等価モジュール列算出プログラム表の内容を例示するものであって、ここで示されるプログラムに対して、置換元のモジュール名、及び置換元の設定パラメータを渡すことで、置換先モジュールの配列と、その設定とが当該プログラムから返される。

また上記等価モジュール列算出プログラム表で示されるプログラムに、生成するモジュール数の上限を与えることもできる。等価モジュール展開の目的としては、垂直方向に経由するデータ処理ノード数に対して処理を分散するための候補を得ることと、より基本的なロジックに分解することで、上述したモジュール共有化の実現角度を上げることにある。

したがって、垂直方向に経由するデータ処理ノードの数に対して大きい数の等価モジュールに展開したとしても大きな効用は得られず、無駄に計算時間を消費するという結果が得られるだけとなる。そのため、生成するモジュールの上限としては、垂直方向に並ぶデータ処理ノードの数の２倍程度を与えれば十分であると考えられる。

なお上記図１６（Ｂ）で示した等価モジュール列算出プログラムは、対応するモジュールの性質を習熟した開発者によって記載されたプログラムであることを前提とする。

上記図７のステップＳ２０３における等価モジュール展開処理が終了すると、次に配置計算部１４では第２のモジュール共有化処理として、上記モジュール構成の集合Ｃ３の各要素に対して、モジュール共有化処理が実施できれば、そのまま実施してモジュール構成の集合Ｃ４に加える（ステップＳ２０４）。

なお、上記ステップＳ２０２で説明した共有化処理とほぼ同様の手法で共有化処理を実行するが、上記ステップＳ２０２では見つけた順序に従って共有化処理を行なっていたのに対し、ここでは共有化を行なう順序もバリエーションとして考慮する点で相違する。

すなわち、モジュール構成Ｃ２に含まれるモジュールの内、共有可能なモジュールの組み合せを検索し、その候補毎に共有化した構成を得る。

図１８（Ａ）は、具体的なモジュール構成の例を示している。ここでは、モジュール構成Ｃ２が部分モジュール構成Ｓ３０１，Ｓ３０２を有し、部分モジュール構成Ｓ３０１のモジュールＭ１とモジュールＭ２を共有化してモジュール構成Ｓ３０４、同モジュールＭ２とモジュールＭ３を共有化してモジュール構成Ｓ３０３、モジュールＭ２とモジュールＭ３を共有化してモジュール構成Ｓ３０５をそれぞれ求めるものとする。

この手順を、モジュール構成Ｃ２内の別の部分モジュール構成Ｓ３０２や、上記新たに作成されたモジュール構成Ｓ３０３，Ｓ３０４，Ｓ３０５に適用し、さらに新たなモジュール構成で作成できなくなるまで繰返し実行することで、図１８（Ｂ）に示すようなモジュール構成の集合Ｓ３１０が生成される。

上記ステップＳ２０４で作成するモジュール構成の集合Ｃ４としては、モジュール構成の集合Ｓ３１０に含まれるすべての構成を入れても良いし、また集合Ｓ３１０の端部側に存在する、それ以上共有化が進められない構成と３１１，３１２，Ｓ３１３，Ｓ３１４，Ｓ３１５のみをモジュール構成の集合Ｃ４に入れても良い。

これらは、配置計算部１４による配置計算に要するコストと、最適解の探索の漏れをどの程度許容するかの兼ね合いにより決定される。

上記図７のステップＳ２０４における第２のモジュール共有化処理が終了すると、次に配置計算部１４では実ノードデバイスへの割付処理を実行する（ステップＳ２０５）。

ここで配置計算部１４では、上記モジュール構成の集合Ｃ４の要素である個々のモジュール構成に対して、モジュールを各データ処理ノードに割り付けて、その構成を集合Ｃ５に加えていく。割り当て方法が複数ある場合には、複数の要素として上記集合Ｃ５に加える。

より詳細には、まず注目する構成に対応して、データ処理ノードの構成への割り当てを行なう。図１９（Ａ）は、注目する構成であるモジュールＡ、モジュールＢからなる２つのモジュールを示した例である。図中の「ＶＬ」は仮想的なリンクを意図する接頭語である。

これに対して、図１９（Ｂ）は、データ処理ノードであるノード１〜ノード４の構成を例示している。図中の「ＰＬ」は物理的なリンクを意図する接頭語である。

基本的には、モジュール数とノード数との積の数だけ割付方法が存在するが、その中には明らかに非効率である方法、実行が困難である方法が含まれているので、それらの方法を除いていく。

一方のデータ処理ノードでは、用意されているリソース量や、その保持している特別な機能も管理している。また、例えばＣＰＵのタイプなどのハードウェア上の特性なども管理している。

他方の、データ処理を行なうモジュールについても、最低限必要なリソースや、必要とする特別な機能、必要なＣＰＵのタイプなどのハードウェア上の特性を管理している。

したがって、これらモジュールとデータ処理ノードの各情報に基づいて、割付可能なパターンを生成する。例えば、図１９に示した各構成において、
ノード３←モジュールＡ、且つ
ノード１←モジュールＢ
のパターンと、
ノード３←モジュールＡ、且つ
ノード２←モジュールＢ
のパターンの計２種類のパターンを算出できる。

なお実際に実ノードデバイスへの割り付けを実行するに当たって、配置計算部１４は図２０（Ａ）に示すような、資源管理部１３で管理されるノード情報のテーブルを参照することで、割り付けが困難なモジュールを算出できる。

モジュールが対応しているＣＰＵアーキテクチャでなければそのノードを配置することはできず、モジュールの必要とするリソースが当該データ処理ノードのリソース量を超えている場合も同様に配置は困難となる。

なお、１つのデータ処理ノードでは、共有化により複数のモジュールが動作することになるが、このステップＳ２０５では、他のモジュールに関しては考慮せず、単一のモジュールがそのデータ処理ノードのリソースを占有した場合に配置可能かどうかを判定する。

また資源管理部１３には、図２０（Ｂ）に示すモジュール情報と、図２０（Ｃ）に示すセンサ情報とが併せて管理されている。

このモジュール情報における「１Ｅｖｅｎｔに必要な処理ステップ数」「必要メモリ数」「必要ストレージ量」「データ出力頻度」「出力データサイズ」や、センサ情報における「Ｅｖｅｎｔ発生頻度」「データサイズ」については、固定値のようにして記載しているが、統計的な数値、例えば最小値、最大値、平均値、標準偏差などを記載し、それらの記載内容に基づいて統計的な判断を実施して、割り付けの可否を判定しても良い。

なお、上述した如く、テーブルを探索することで必要なリソース量を見積もる構成とする以外にも、モジュールの開発者によって作成された、別の目的のプログラムであるモジュールのヘルパープログラムに対して、必要なリソース量を問い合わせる仕組みで実現するものとしても良い。

その場合、入力イベント頻度を引数として渡す構成とすることにより、必要リソースが、入力イベント頻度の関数となる場合でも、高い精度で近似することができる。

続いてネットワークのリソースを割り付ける場合について説明する。
ここでは、図２１に示すように示すように、
モジュールＡ：ノード３、且つ
モジュールＢ：ノード１
に割り付ける場合を例にとって説明する。

前のステップＳ２０４で決定されたモジュール間のリンクをマッピングすることで、
ＰＬ４←ＶＬ３
ＰＬ５←ＶＬ４−１
ＰＬ３←ＶＬ４−２
ＰＬ２←ＶＬ４−３＋ＶＬ２
ＰＬ１←ＶＬ１
となる構成を割り付けることができる。ここで、仮想的リンクＶＬ４は、仮想的リンクＶＬ４−１，ＶＬ４−２，ＶＬ４−３の連結として表されている。

上記図７のステップＳ２０５における実ノードデバイスへの割付処理が終了すると、次に配置計算部１４では収容可否の判定処理を実行する（ステップＳ２０６）。

配置計算部１４は、資源管理部１３に問い合わせたリソース量に対して、上記モジュール構成の集合Ｃ５の要素が収容できるかどうかを判定し、可能であると判定した場合に集合Ｃ６に収容する。また、その際に、各リソースの利用率を合わせて算出しておく。

図２２（Ａ）は、資源管理部１３に管理されるリンク情報のテーブルを例示する図である。上記モジュール構成の集合Ｃ５の要素には、物理的なリソースに対する割当構成が含まれている。例えば、
ノード１←モジュールＢ＋モジュールＣ
ノード２←モジュールＡ
ＰＬ４←ＶＬ３
ＰＬ５←ＶＬ４−１
ＰＬ３←ＶＬ４−２
ＰＬ２←ＶＬ４−３＋ＶＬ２
ＰＬ１←ＶＬ１
となる構成が挙げられる。上記記号「←」は、この記号を挟んで右辺側のモジュールあるいは仮想的リンクを左辺側の物理的リンクに割り当てることを示している。

ここで配置計算部１４は、物理的な資源の各要素が、割り当てられる対象の該当要素の総和を上回っていることを確認する。

すべての物理的資源において、上記が満たされているならば割当可能であるものと判定して、上記集合Ｃ６の要素として格納する。

なお、安全係数（ｋ）を「０．９」として、上記の比較を行なうこともできる。この場合、次式
物理的な資源の各要素＊ｋ＜Σ（割当対象の該当する各要素）
が成立するか否かにより、物理的な資源の各要素が、割り当てられる対象の該当要素の総和を上回っていることを確認する。なお、上記安全係数（ｋ）は、リソースの種別毎に異なるベクトルｋ＝（ｋ₁，ｋ₂，‥‥，ｋ_n）を予め用意するものとしても良い。

さらに、上述した如く各要素のリソースの利用率も算出し、ベクトルとして保持しておく。ここで保持する内容は、次式
Σ（割当対象の該当の各要素／物理的資源の各要素＊ｋ）
で表される。図２２（Ｂ）は、このとき配置計算部１４により保持されるリソース使用率のベクトルを例示するものである。

なお、課金モデルも含めて計算を行なうことで、当該構成において一定期間、例えば１ヶ月間運用する場合のコストを算出することもできる。上記リソースの使用率、及びコストの情報を、集合Ｃ６に格納する際の付加情報として併せて格納する。

上記の処理を、上記集合Ｃ５に含まれるすべての要素について実施することで、新たなモジュール構成の集合Ｃ６が作成される。

なお、アプリケーション要件中に性能要件が記載されている場合には、そのアプリケーション要件中の性能要件への適合性の確認も、上記収容可否の判定処理の一部として実施する。

この場合、実際に割り当てられた構成に関して、各モジュールの処理ステップ数、格データ処理ノードの、単位時間当たりの演算可能ステップ数、及び各ネットワークの帯域から、スループットやレイテンシを算出できる。

これによって、各アプリケーションの便益と比較する。便益が１未満となるアプリケーションが存在した場合には、その構成は適合していないものと判断する。

また、アプリケーションの便益を、例えばベクトル「ｂ_app1」「ｂ_app2」‥‥「ｂ_appn」に対応するベクトル値「１．１」「１．２」‥‥「１．５」からなるベクトル列としておき、構成に付属した情報として保持しておくことで、後のステップで利用するものとしても良い。

上記図７のステップＳ２０６における収容可否の判定処理が終了すると、最後に配置計算部１４では、最適構成の選択処理を実行して（ステップＳ２０７）、以上でこの配置計算の処理を終了する。

より詳細には、配置計算部１４は集合Ｃ６の要素と、それに付加されているリソース使用率のベクトル、及び月間等のコストの情報により、最適な構成を判断する。

そのための手法としては、「１．リソース使用率の平均が低いもの」「２．リソース種別に応じて重みを変えたリソース使用率の平均が低いもの」「３．最大のリソース使用率が低いもの」「４．月間コストが最低のもの」「５．アプリケーションの便益が高いもの」のいずれかで判断することが考えられる。

以下、特に上記「１．」乃至「３．」の各手法に関しては、目的関数を例示する。

上記「１．リソース使用率の平均が低いもの」では、例えば目的関数として次式
ａｖｇ(ｒ₁，ｒ₂，‥‥ｒ_n)
を用いる。

上記「２．リソース種別に応じて重みを変えたリソース使用率の平均が低いもの」では、目的関数
ａ＝(ｒ₁，ｒ₂，‥‥ｒ_n)，且つ Σａ_n＝１となるａをｒに乗じた、
ａ・ｒ＝ａ₁×ｒ₁＋ａ₂×ｒ₂＋‥‥＋ａ_n×ｒ_n)
を用いる
上記「３．最大のリソース使用率が低いもの」では、システム全体での安全係数に、目的関数
ｍａｘ(ｒ₁，ｒ₂，‥‥ｒ_n)
を用いる。

さらに、上記「１．」〜「５．」で示した手法を複数組み合わせて判断することによっても、上記ステップＳ２０７での最適構成の選択処理を容易に実現できる。

なお、上記図７以下で説明した配置計算部１４による配置計算の方法では、可能な構成をすべて列挙した後に最良のものをそれらの中から選択する、という方法をとっていた。

一方で、局所探索法というアルゴリズムが知られており、この局所探索法を適用した方法でも最適な構成の配置構成を得ることができる。

図２３は、その処理過程を簡略化して示すものである。上記ステップＳ２０２の第１のモジュール共有化処理で得られた初期構成（Ｓ５０１）を出発点として、等価モジュールの展開処理（Ｅ）や、共有モジュール化処理（Ｓ）の手順を１つずつ進めて、モジュール構成を増やしていく。

その構成について、実ノードデバイスへの割付処理と収容可否の判定処理とを行ない、上述した目的関数による演算を適宜実行して、その構成に対する評価を取得する。

それらの評価値の中で最も高い値となった構成から、さらに等価モジュールの展開処理（Ｅ）や、共有モジュール化処理（Ｓ）を進めるか、あるいは進めるケースが存在しない場合には一旦前のノードに戻り、あるいは、ある程度の目的関数の改悪を許容して、探索するノード構成を全ノード内から選択し直す、などの工程を順次実行する。

これらの手順を、ある程度の回数だけ繰返し実行することで、探索した中から最良の回を得るものである。上記した繰返しの程度としては、予め決められた回数を実行した場合、目的関数の向上が収束した場合、全部の可能な構成を探索した場合、アニーリング法と呼ばれる目的関数の改悪する遷移を許す温度パラメータを用いて判定する場合などのいずれかが選択可能となる。

さらに、上記図２３で示した局所探索法では、一度割付可能な構成を求めた場合に、その構成で一旦データ処理ノードにモジュールを配備して機能提供を開始した後、並行して、より良い構成の探索を行ない、特定の時間が経過したタイミングで、より良い構成に変更する、という手法を採ることも可能となる。

また上記図６のステップＳ１０７において、配置計算部１４から再配置の可否を示す結果の通知を受けた要件管理部１２では、その通知の内容が、リソースが不足しており、割り当てるモジュール構成が存在しないものであった場合に、次の手順を実行するものとしても良い。

すなわち要件管理部１２は、複数のアプリケーション要件のうちで、重要度の低いものを停止させることで、新規アプリケーションを受付けられるかを探索する。新規のアプリケーション要件のうち、最大の優先度となるアプリケーション要件を残して、その他のアプリケーション要件を除外した上で、配置計算部１４に対して再度の配置計算を要求する。この要件を考慮する最低の優先度を「実行可能優先度」と呼称することとする。

例えば、既存のアプリケーション要件とその優先度が、
１０：Ａｐｐ＿Ｃｒｉｔｉｃａｌ
７：Ａｐｐ＿Ｉｍｐｏｒｔａｎｔ
４：Ａｐｐ＿ｓｏｓｏ
１：Ａｐｐ＿ｊｕｓｔ＿ｔｅｓｔ
であり、新規のアプリケーション要件とその優先度が
８：Ａｐｐ＿Ｖｅｒｙ＿Ｉｍｐｏｒｔａｎｔ
５：Ａｐｐ＿ｊｕｓｔ＿ｆｏｒ＿ｆｕｎ
であった場合に、「実行可能優先度」として上記新規側の「８」のアプリケーション要件を選択する。

この状態で配置計算部１４により再度の配置計算が行なわれ、アプリケーション要件を実行可能なモジュール構成が得られない場合は、その通知の内容に従って、上記ステップＳ１０８において、要件管理部１２がアプリケーション５に対して要件受付の可否回答として不可である旨を通知する。

また再度の配置計算の結果、アプリケーション要件を実行可能なモジュール構成が得られた場合、配置計算部１４では実行可能優先度を１減じた上で再度配置計算を実行する、という処理を、アプリケーション要件を実行可能なモジュール構成が得られなくなるまで繰返し実行する。

アプリケーションの示した新規の要件をすべて実行可能であると判定できた場合は全面的に可である旨の通知、一部分であるが実行可能であると判定できた場合は部分的に可である旨の通知を回答として通知する。

また、上記実施形態では説明しなかったが、データ処理ノードにおいて、リソースと動作させているモジュールを管理する小さなエージェントを、例えば利用資源管理部として動作させ、その利用資源管理部で測定された消費リソースを用いて、上記資源管理部１３が管理するモジュール情報中のリソース量を更新設定することで、動的なモニタリングによる必要資源の算出が実現できる。

図２４は、このときのシーケンス図を例示する。例えばデータ処理ノード１が有する利用資源測定部が、予め設定されたタイミングで配置実行管理部１５に対してその時点での資源利用情報を通知する。

これを受けた配置実行管理部１５が、同通知を資源管理部１３に転送することで、資源管理部１３ではモジュール構成に必要なリソース量を更新する処理を実行する。

なお上記の処理は、データ処理ノードでモジュールを１つだけ実行している場合に実行するものとする。

また、モジュールの「資源管理部１３で管理されているモジュール情報」に「精度高く測定されているフラグ」を付与設定することも考えられる。その場合、１つのデータ処理ノードで複数のモジュールが実行されているが、「精度高く測定されているフラグ」が付与されていないモジュールが１つだけである場合は、当該データ処理ノードでの全体の使用量から、「精度高く測定されているフラグ」が付与されているモジュールのリソース量を減算した差を、上記フラグが付与されていないモジュールの使用リソース量と見做して、更新することもできる。

また、モジュールを切り替える際には、切り替え前後のモジュールを同時に配置し、センサデータに付与されている時刻、シーケンス番号に基づいてモジュールの切り替えを実行することにより、センサデータの欠落なしに、より効率的なモジュールへの切り替えを実施できる。

図２５は、このモジュールの切り替え処理を例示する図である。
同図では、センサＩＤ−０からのセンサデータが最初はデータ処理ノードＡを介して、切り替え後はデータ処理ノードＢを介してチャンネル０に入力される場合を例示している。当該センサデータには、タイムスタンプやシーケンス番号が格納されている。

図２５（Ａ）において、配置実行管理部１５はチャンネル０に対し、データ処理ノードＢからの入力を指示があるまで無視するように伝える。

その後、図２５（Ｂ）に示すように、データ処理ノードＢを配備し、データ処理ノードＢからも、直近で受信したセンサＩＤ-０からのデータ中のタイムスタンプ及びシーケンス番号を取得する。

ここで配置実行管理部１５は、チャンネル０に対して、一定の余裕を持った時間、例えば１［秒］乃至５［秒］程度の後の、センサデータ中のタイムスタンプ及びシーケンス番号を通知して、そのタイムスタンプ及びシーケンス番号を越えてデータ処理ノードＡから入力されるデータを無視すると共に、データ処理ノードＢから入力されるデータを使うよう設定する。

このように、センサデータの入力が中断することなく、配置しているモジュールの切り替えを行なうことが可能となる。

次に異常状態でモジュールを停止させる場合について説明する。
上記したように各データ処理ノードが利用資源測定部を有しているものとした場合、当該利用資源測定部は、そのノードで許容する収容上限、例えばリソース容量の８０［％］を越えているかどうかを監視しており、その上限を超えた場合に、利用するアプリケーションのモジュールの優先度が低いモジュールを停止させて、より優先度の高いアプリケーションに影響が出ないように制御する。

図２６は、異常状態でのモジュール停止の実現方法を例示する図である。
図２６（Ａ）に示すように、データ処理ノードでは、利用資源測定部Ｍ６０１において、ＣＰＵ、メモリなどのノード内のリソースを監視している。リソースの使用率が、予め設定された値、例えば８０［％］を越えた場合、図２６（Ｂ）に示すように、例えばデータ処理ノード１から配置実行管理部１５に対して、現在のリソースの使用状況と共にリソースが枯渇した旨の通知を行なう（ステップＳ５０１）。

配置実行管理部１５は、この通知に対応して実行可能優先度の計算と再設定処理を実行した上で（ステップＳ５０２）、各データ処理ノード１，２にモジュール停止命令を送信する（ステップＳ５０３，Ｓ５０４）。

一方で配置実行管理部１５は、要件管理部１２に対して実行可能優先度の変更通知を送信する（ステップＳ５０５）。これを受けた要件管理部１２は、アプリケーション５に対して停止を通知する（ステップＳ５０６）。

上記配置実行管理部１５が、実行可能優先度の計算を行なう方法はいくつかある。例えば、
１．当該データ処理ノードで動作する最低優先度のモジュールに設定されている優先度よりも１だけ高い優先度とする手法、
２．予め、実行可能優先度を変えた場合の、理論的な各リソースのリソース使用率を算出しておき、当該リソースの釣果を解消できるような、実行可能優先度を選択する手法、
等である。

図２７は、配置実行管理部１５による実行可能優先度とモジュールの管理の内容を例示する図である。
配置実行管理部１５は、図示する如くデータ処理ノード毎の「モジュール名」と「対応するアプリケーションの最高優先度」、及び「実行状態」からなるテーブルを管理しており、モジュールが関係するアプリケーションのうち、最高の優先度のものを保持しておく。

システム全体の実行可能優先度が変更された場合、配置実行管理部１５では、上記テーブル中の「対応するアプリケーションの最高優先度」が、「実行可能優先度」以上となるモジュールを起動するよう、各データ処理ノードに命令する。

次に安全係数の変更処理について説明する。
上記配置計算部１４は、各データ処理ノード、各リンクに対して安全係数を設定しておき、全リソース容量に安全係数を乗じた積を越えないように、モジュールの配置を計画する。

また、実際にアプリケーションを実行中、上記安全係数を再設定することを可能とする。この場合、安全係数を変更したい場合には、動作が不可能となるアプリケーションの有無を検討し、そのようなアプリケーションがある場合には、その旨をシステム管理者に提示する。そして、提示した内容が了承される操作がなされた後に、当該アプリケーションに関するモジュールを停止し、実際に安全係数の変更設定に関する処理を実行する。

なお、上記安全係数を変更した後に、上述した実行可能優先度に基づくアプリケーションの選択処理と同様の手順によって配置計算を実行することで、実行可能優先度を算出することができる。

したがって、この実行可能優先度の値以下となるアプリケーションを選択し、システム管理者に提示して確認を求める。システム管理者により確認が得られた場合に、上記安全係数の変更、及び実行可能優先度の変更を実施し、それらに伴うモジュールの停止を実施する。

モジュール構成の配置を決定するタイミングとしては、新たなアプリケーションを追加する場合、及び安全係数を変更する場合を例にとって説明したが、これらの他にも、データ処理ノードが追加された場合、データ処理ノードが仮想化された計算機であって、割り当てられているリソースが変更された場合、ネットワークの容量が変更された場合、アプリケーションの要件が変更になった場合、センサの設置状況が変更された場合にも受信可能であり、これらの各タイミングにおいて同様の方法で実施できる。

また、上記図２５を用いて説明した如く、無中断でデータ処理ノードの切り替えを行なう場合には、一時的に動作させるモジュールの数が多くなる場合がある。その際には、上述した安全係数の変更設定を併せて一時的に実施し、優先度の低いアプリケーションに関するモジュールを停止させて、その後に上記無中断でのデータ処理ノードの切り替えを行なって、切り替え後に再度安全係数を元に戻す変更設定を行なうことで、優先度の高いアプリケーションに関しても、無中断でのモジュールの切り替えを実施することが可能となる。

以下、図２８乃至図３２を用いて、これまでの説明を統括して、モジュール構成の再配置を行なう場合の動作について説明する。

図２８は、モジュールのチェーン化と等価交換の例を示す。図２８（Ａ）に示す、６［秒］毎の統計化を行なうモジュール「データ処理１」は、図２８（Ｂ）に示す、２［秒］毎の統計化を行なうモジュール「データ処理２」、及びデータ３つ単位で統計化を行なうモジュール「データ処理３」の２段構成の列（チェーン）に置換しても、等価交換が成立する。

上記図２８（Ａ）に示したモジュール構成から、図２８（Ｂ）に示すモジュール構成へと配置を変更する場合を考える。

図２９は、中間データモジュールの組み換えによるリソース削減の例を示す。
まず図２９（Ａ）に示すように、６［秒］毎の統計化情報が欲しいアプリケーション１が既存のアプリケーションとして動作しており、そこに、同一のセンサの４［秒］毎の統計化情報が欲しい、新規のアプリケーション２が起動されたものとする。

上述した「最小モジュールの取得」処理により、この図２９（Ａ）に示すような配置計画が実行される。また、上記図２３を用いて説明した「局所探索法の適用」にて記述した方法で実施する場合で、且つ、後述する図２９（Ｂ）の構成を取得するまでに時間を要する場合には、この図２９（Ａ）に示したモジュール構成で、とりあえず実際の運用が開始されるケースもあり得る。

これに対して図２９（Ｂ）に示すように、上記図２９（Ａ）のモジュール構成と等価のモジュール構成に変換し、さらにモジュール構成の共有化を図ることで、センサに対して（最大公約数である）２［秒］毎の統計化を行なうモジュール「データ処理３」と、データ３つ単位で統計化を行なうモジュール「データ処理４」、及びデータ２つ単位で統計化を行なうモジュール「データ処理５」とによる構成に置換することで、所望のモジュール構成を得ることができる。

例えばセンサからのデータが秒間に１００件あるような場合には、図２９（Ｂ）に示すようなモジュール構成に変更することで、データ処理ノードの負荷を大幅に低減できる。

また、アプリケーション１，２には、上記図２９（Ａ）に示した場合と同様の内容の処理データが渡されている。

次に、図３０により、上記図２９で説明した手法に代わる、中間データモジュールの組み換えによるリソース削減の第２の例を示す。

図３０（Ａ）は、アプリケーション１に対して、全国に配置されたセンサからの統計情報を計算して提供している。そこに、特定地域に関する統計情報が欲しいアプリケーション２を新規に追加するものとする。

図３０（Ｂ）は、「最小モジュールの取得」処理による配置変換により、上記図２９（Ａ）と同等のモジュール構成とした場合を示す。

このモジュール構成に対して、複数のセンサが設置された地域に対応して、特定地域の統計化情報が欲しいモジュール「データ処理２」と、それ以外の地域の統計化情報を処理するモジュール「データ処理１」とにセンサ／モジュール間の接続構成を変えた上で、それらの統計化情報を取り纏めて全国の統計化情報を取得するモジュール「データ処理３」を配置するモジュール構成となるように、上述した如く配置計算を行なうことにより、図３０（Ｃ）に示すような、モジュール構成に変換することが可能となる。

なお、上記図３０では、説明を簡略化するためにセンサが４個の場合について図示により説明したが、例えば１００個程度のセンサがあった場合に、上記図３０（Ｂ）で示したモジュール構成に比して、図３０（Ｃ）で示したモジュール構成の方が、使用リソースの量を大幅に削減できることが容易に理解できる。

次に図３１によりモジュール変換の例について説明する。

例えば、各地に配備されているカメラ画像の中から、顔検出処理を行ない、比較対象の顔画像との類似度を算出し、一定の値以上となった、類似度が高いと判断された場合に通知を行なうようなアプリケーションを例にとって説明する。

図３１（Ａ）は、センサであるカメラから得たセンサデータとしての画像データに対し、サーバで類似度比較（ステップＥ１０１）を行なうものとした場合に、カメラからサーバまでのネットワークが、律速段階となる可能性がある。

その場合、図３１（Ｂ）に示すように、ゲートウェイ２上で、比較的軽量な事前処理、具体的には顔検出処理及び顔領域の切り出し処理（ステップＥ１０２）までを行ない、データ量やデータ頻度を下げた上で、上位のサーバによる類似度比較処理（ステップＥ１０３）を行なうものとするようにモジュール構成を変換する。

このようなモジュール構成の変換により、ネットワーク上の転送量を下げて、全体的に使用リソース量を削減できる可能性ができる。

上記類似度比較モジュールが、１つのクラウド上のインスタンスにおいて実行されているものとする。１つのデータ入力に対する実行処理が大きい場合、そのスループットがアプリケーションの要件を満たせなくなる場合もあり得る。

図３２（Ａ）は、上記図３１（Ｂ）と同様のモジュール構成を示すもので、モジュール構成が１つである場合を示している。

このような構成に対して、図３２（Ｂ）は、類似度比較処理（ステップＥ１０３）を複数のデータ処理ノードに分割するものとして、その前段に振り分け処理（ステップＥ１０４）を配置すると共に、その後段に結果集約処理（ステップＥ１０５）を配置して、類似度比較処理（ステップＥ１０３）を複数のノードに分散化して、スループットを改善できる可能性を得るようにした例を示す。

なおこの図３２（Ｂ）に示すモジュール構成では、経由するモジュールの数が増えているため、レイテンシは増加するものと考えられる。

上記実施形態によれば、データをすべてクラウドに集めるのではなく、ネットワーク上の垂直に分散した処理ノードに適切に処理を分散することで、効率的にデータ処理を行なうことが可能となる。

また、モジュールの配置設計が、開発者や運用者ではなく、システムにより機械的に計算されるため、対応の稼働が小さくなると共に、新しいアプリケーションの配備が迅速化し、適時化できるようになる。

このことにより、同一の資源上で複数のアプリケーションを実行させることが容易となる。

さらに、アプリケーションの用件を書くことにより、管理者がモジュール配置の設計や実施を行なう必要がなく、管理コストを抑えて、迅速に対応させることができる。

加えて、トラフィックの増大や、異常プロセスの発生などがあった際に、優先度の低いアプリケーションに関するモジュールを止めることで、優先度の高いアプリケーションの動作を継続させることができる。

なお、以上の説明では、具体的なモジュールの例を用いて説明したが、本発明はモジュールの内容等を限定するものではなく、新たなデータ処理モジュールや、アプリケーション要件に記載される新たなアルゴリズムが導入されたとしても、これらに対して作用させることのできる「モジュール構成の作成プログラム」「共有化判定プログラム」「等価モジュール列の算出プログラム」が提供されれば、対応可能となる。

データ処理モジュールやアルゴリズムについては、アプリケーション側からの需要により非常に多岐にわたるものを作成することができる。また、その仕組みを知るものについては、そのヘルパープログラム（上記した「モジュール構成の作成プログラム」「共有化判定プログラム」「等価モジュール列の算出プログラム」）を作成することは容易に実現できる。

多くのデータ処理モジュールが追加された状況にあっても、上記したように本発明が依然として適用可能となることは勿論である。

その他、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

１…センサ、２…ゲートウェイ（ＩｏＴ ＧＷ）、３…エッジサーバ、４…クラウドサーバ、５…アプリケーション、６…要件受付インタフェイス（Ｉ／Ｆ）、１０…基盤管理部、１１…データベース、１２…要件管理部、１３…資源管理部、１４…配置計算部、１５…配置実行管理部、２１…モジュール構成作成プログラム、２２…共有化判定プログラム、２３…等価モジュール列算出プログラム、２４…割付け、収容可否判定、最適構成選択のためのプログラム。

Claims (7)

1. １以上のアプリケーションと複数のセンサが、ネットワークにより複数のデータ処理ノードを介して接続されるＩｏＴプラットフォームであって、
   アプリケーションの要求条件を受け付ける要件管理部と、
   上記各データ処理ノードの計算資源とネットワーク帯域情報を資源情報として管理する資源管理部と、
   上記要件管理部で受け付けたアプリケーションの要求条件と上記資源管理部が管理する資源情報とに基づいて、上記複数のデータ処理ノードで当該アプリケーションを実行するモジュールの配置計算を行なう配置計算部と、
   上記配置計算部での計算の結果に従ってデータ処理ノードにモジュールを配備する配置実行管理部と
   を有する基盤管理部を備えたデータ収集基盤。
2. 上記要件管理部は、新規に追加されるアプリケーションの要求条件を受け付けて上記配置計算部に通知し、
   上記配置計算部は、新規に追加されるアプリケーションの要求条件に基づいて上記資源管理部が管理する資源情報から新規アプリケーションの接続の可否を判定し、
   上記要件管理部は、上記配置計算部による接続の可否の判定結果を当該新規アプリケーションに応答する、
   請求項１記載のデータ収集基盤。
3. 上記要件管理部が受け付けるアプリケーションの要求条件は優先度の情報を含み、
   上記配置計算部は、既存のアプリケーションの要求条件に含まれる優先度の情報と新規アプリケーションの要求条件に含まれる優先度の情報に基づいて、各アプリケーションの接続の可否を判定する、
   請求項２記載のデータ収集基盤。
4. 上記配置計算部は、既存のアプリケーションを実行中のモジュールの共有化の可否を判定し、共有化できると判定した場合はモジュールの再配置計算を行ない、それまでモジュールで実行された結果を用いて当該アプリケーションの実行を継続させる、請求項１記載のデータ収集基盤。
5. 上記配置計算部は、上記資源管理部で予め管理している資源情報を参照して、アプリケーションを実行するモジュールの配置計算を行なう、請求項１記載のデータ収集基盤。
6. 上記データ処理ノードは、モジュールの動作に伴って利用する資源情報を測定して上記資源管理部に通知する利用資源測定部を備え、
   上記資源管理部は、データ処理ノードから受けた資源情報を更新して管理する、
   請求項１記載のデータ収集基盤。
7. 上記配置実行管理部は、アプリケーション実行中のモジュールの切り替えに際して、切り替え前後のモジュールを同時に配置し、センサからのデータに付与される時刻及びシーケンス番号の少なくとも一方の情報に基づいてモジュールの切り替えを実行する、請求項１記載のデータ収集基盤。