JP7070710B2 - 分散処理支援装置、分散処理支援方法およびプログラム - Google Patents

Description

この発明の一態様は、複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置、分散処理支援方法、およびプログラムに関する。

近年、ＩｏＴ（モノのインターネット（Internet-of-Things））の普及とともに、身近にある様々な機器がインターネットにつながるようになり、それらの機器が取得した情報を収集し、利活用することが容易となってきている。

このような背景のもと、情報収集の効率化や応答時間の高速化を実現するために、関数やクラスなどの複数のアプリケーションロジック（入力データに対して何らかの処理を行い、データを出力するものを指し、以下では単に「ロジック」と言う）を、地理的に分散されたマシンに配置して実行する分散アプリケーションへの期待が高まっている。

例えば、ＩｏＴ機器が送信した情報を集約するロジックを中継サーバに配置することで、情報収集に要する通信量を削減することができる。また、アプリケーションの利用者に地理的に近いサーバに、利用者の端末と頻繁に通信するロジックを配置することで、アプリケーションの応答時間を短縮することができる。

ここで、アプリケーションを複数のマシンで分散的に動作させるためには、アプリケーションを複数のロジックに分割し、各マシンに分散配置する必要がある（例えば、非特許文献１参照）。

ここで、アプリケーションをどのように分割し、どのように分散配置するかによって、アプリケーションの性能は大きく変化する。これは、ロジック間の通信がマシン間の通信で行われるようになることや、ロジックの処理時間がそれを動作させるマシンの性能に強く依存することに起因する。そのため、アプリケーション性能を最大化させるためには、最適なアプリケーション分割および配置を決定する技術が必要となる。

後者の最適な配置の決定に関しては、アプリケーション性能（マシン間のトラヒック、スループット、処理時間など）の最大化を目的関数とする線形計画問題に変換し、この最適解を計算することで最適な配置を得ることが一般的である。しかし、分割対象のアプリケーションやその動作環境が巨大な場合、配置のパターン数が膨大な数になってしまい、実時間で最適解を計算できなくなるという課題がある。例えば、分割後の処理が１００個、配置先候補のマシンが３つの場合、その配置パターン数は５．２×１０^４７通り存在する。

このような課題を、焼きなまし法や遺伝的アルゴリズムなどの近似解法を用いることによって解決する技術が知られている（例えば、非特許文献２参照）。近似解法では、探索する配置パターンを限定するため、すべての配置パターンを探索する単純な方法よりも短い時間でアプリケーション配置の解を得ることができる。このような従来のアプリケーション分割および配置では、まず、アプリケーションのソースコード内で定義されている関数を１つのロジックとして分割し、その後、配置先候補のマシンと各関数の配置パターンを計算して、その中で最もアプリケーション性能が高くなる配置パターンの近似解（準最適解）を選出する。

より具体的には、従来技術では、まず、入力されたソースコードの中からロジック（例えば、関数やクラスなど）が識別され、このロジックごとにソースコードが分割される。これにより、ロジックと配置先候補マシンの組み合わせパターンが複数生み出される。次いで、これらの各配置パターンにおけるアプリケーション性能が計測される。例えば、各配置パターンについて、分割された各ロジックを各マシンにインストールして複数回動作させ、全体処理が終了するまでに要した平均時間をその関数の処理時間、すなわち当該配置パターンでの性能値とする。このようにして得られた性能値をもとに、線形計画問題（例えば、非特許文献３参照）をはじめとする最適化問題を、焼きなまし法や遺伝的アルゴリズムなどの近似解法によって解くことによって、要求される性能が高くなるロジックの配置を計算する。例えば、各配置パターンでの通信トラヒック、全体の処理時間、マシン間のネットワーク遅延をもとに、「５００ミリ秒以内の処理時間になる配置の中で、最もマシン間のトラヒックが小さくなる配置」を最適解として、この近似解を計算する。

Alex Reznik, et al., "Developing Software for Multi-Access Edge Computing," ETSI White Paper, No.20, Sept. 2017. Jieyao Liu, et al., "Application Partitioning Algorithms in Mobile Cloud Computing: Taxonomy, Review and Future Directions," Journal of Network and Computer Applications, vol. 48, 2015. IBM ILOG CPLEX, [online], インターネット<URL：http://www.ilog.com/products/cplex/>

上記のように、従来技術を用いることで、アプリケーション性能が最も高くなる配置パターンの近似解を高速に計算することができる。しかしながら、従来技術では、近似解法を用いているため、解の最適性が保証されていない。

この課題を解決するためには、最適解を取りこぼすことなく、効率的にアプリケーションの配置を計算する方式が必要である。

この発明は上記事情に着目してなされたもので、その目的とするところは、アプリケーションの分散処理のための最適な配置を効率的に決定するための技術を提供することにある。

上記課題を解決するためにこの発明の第１の態様は、複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置にあって、上記アプリケーションのソースコードを取得するソースコード取得部と、上記ソースコードを複数のロジックに分割するソースコード分割部と、上記アプリケーションにおける上記複数のロジックの処理順序と、上記複数の情報処理装置の動作環境に関する情報とに基づいて、上記複数の情報処理装置のいずれかに上記複数のロジックを分散配置するときの当該複数のロジックの配置パターンの候補を抽出する候補抽出部と、上記抽出された配置パターンの候補の中から最適な配置パターンを決定する最適パターン決定部とを具備するようにした。

上記第１の態様によれば、複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置において、アプリケーションのソースコードが複数のロジックへと分割され、分割されたロジックの処理順序と情報処理装置の動作環境に関する情報とに基づいて、情報処理装置に対するロジックの配置パターンの候補が抽出され、その候補の中から最適な配置パターンが決定される。このように、分割されたロジックの配置パターンの候補を抽出してから、最適な配置パターンを決定するようにしているので、すべての組合せに係る配置パターンから最適解を決定する場合に比べて効率的に最適な配置パターンを決定することができる。

すなわちこの発明によれば、アプリケーションの分散処理のための最適な配置を効率的に決定するための技術を提供することができる。

図１は、この発明の一実施形態に係る分散処理支援装置を含むシステムの一例を示す概略構成図である。 図２は、この発明の一実施形態に係る分散処理支援装置の機能構成を示すブロック図である。 図３は、図２に示した分散処理支援装置による処理手順と処理内容を示すフローチャートである。 図４は、図２に示した分散処理支援装置による処理フローのイメージを示す略図である。 図５は、図２に示した分散処理支援装置による配置パターンの候補の抽出に用いられる有向グラフのイメージを示す図である。 図６は、非最適な配置パターンの一例を示す図である。 図７は、最適解である可能性のある配置パターンの一例を示す図である。 図８は、図２に示した分散処理支援装置で用いられる、配置パターンの候補を抽出するためのアルゴリズムの一例を示す図である。 図９は、図８に示したアルゴリズム内で使用される記号の説明を示す図である。 図１０は、図８に示したアルゴリズムを説明するデータフローグラフの一例を示す図である。 図１１は、図８に示したアルゴリズムを説明するグルーピングの一例を示す図である。 図１２は、図２に示した分散処理支援装置の各機能部による処理フローを示すブロック図である。 図１３は、従来技術および一実施形態に係る分散処理支援装置を用いた実験による、最適探索の対象となる配置パターン数の比較結果を示す図である。 図１４は、従来技術および一実施形態に係る分散処理支援装置を用いた実験による、最適探索の精度の比較結果を示す図である。 図１５は、この発明の一実施形態に係る分散処理支援装置を、閉路を含むデータフローグラフに適用する例を示す図である。

以下、図面を参照してこの発明に係わる実施形態を説明する。

［一実施形態］
（構成）
（システムの構成）
図１は、この発明の一実施形態に係る分散処理支援装置を含むシステムの一例を示す概略構成図である。
このシステムは、データの収集元または入力元装置としての端末デバイス群ＴＤ１～ＴＤｉ（以下、まとめて「端末デバイスＴＤ」とも言う）およびセンサ群ＳＳ１～ＳＳｊ（以下、まとめて「センサＳＳ」とも言う）と、これらの装置からネットワークＮＷを介してデータを取得可能な複数のクラウドサーバＣＳＶ１～ＣＳＶｎ（以下、まとめて「クラウドサーバＣＳＶ」とも言う）と、端末デバイスＴＤおよびセンサＳＳとクラウドサーバＣＳＶとの間に配置された複数のエッジサーバＥＳＶ１～ＥＳＶｍ（以下、まとめて「エッジサーバＥＳＶ」とも言う）と、これら種々の装置とネットワークＮＷを介して通信可能な、一実施形態に係る分散処理支援装置１とを備えている。

ネットワークＮＷには、例えばインターネット等の公衆網と、この公衆網にアクセスするためのアクセス網とが含まれる。アクセス網には、エッジサーバＥＳＶ間を接続するエッジネットワークＥＮＷも含まれる。エッジネットワークＥＮＷは、例えばＬＡＮ（Local Area Network）または無線ＬＡＮにより構成される。ただし、エッジサーバＥＳＶは、エッジネットワークＥＮＷを介さずに直接インターネットに接続されてもよい。

端末デバイスＴＤは、通信機能を有し、１または複数のエッジサーバＥＳＶを介してクラウド上のアプリケーションを利用可能な情報処理装置で、例えば、スマートフォンやパーソナルコンピュータである。センサＳＳには、自動車、その他のＩｏＴ機器が含まれる。センサＳＳにより計測または検出されたセンシングデータは、ＬＡＮや無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の省電力無線データ通信規格を採用した無線インタフェースを介して、あるいは端末デバイスＴＤを経由して、あらかじめ送信先として設定されたエッジサーバＥＳＶへ送信される。図示した端末デバイスＴＤおよびセンサＳＳは一例にすぎず、固定式装置であっても移動式装置であってもよく、任意の個数の多種多様な装置を含み得る。なお、端末デバイスＴＤおよびセンサＳＳは、必ずしもエッジサーバＥＳＶまたはエッジネットワークＥＮＷを経由する必要はなく、ネットワークＮＷを介して直接クラウドサーバＣＳＶにアクセスすることもできる。

エッジサーバＥＳＶは、大規模データセンタ上に展開されたクラウド環境に対し、ユーザのより近くに配置された小規模データセンタを構成し、例えば、サーバコンピュータやパーソナルコンピュータなど種々の情報処理装置を含む。

クラウドサーバＣＳＶは、クラウドコンピュータ等の情報処理装置からなり、エッジサーバＥＳＶから送信されるセンシングデータをネットワークＮＷを介して受信し、蓄積する。

クラウドサーバＣＳＶはまた、クラウド環境で利用可能なアプリケーションを提供する。クラウドサーバＣＳＶが提供するアプリケーションには、分散アプリケーションが含まれる。分散アプリケーションは、当該クラウドサーバＣＳＶに加えて、任意の数のエッジサーバＥＳＶおよび端末デバイスＴＤによる分散処理が可能である。

分散処理支援装置１は、そのような分散アプリケーションの配置先を決定することによりアプリケーションの分散処理を支援するもので、システム管理者等が操作可能なサーバコンピュータやパーソナルコンピュータである。

図２は、図１に示した一実施形態に係る分散処理支援装置１の機能構成を示す。
分散処理支援装置１は、通信インタフェースユニット１０と、処理ユニット２０と、記憶ユニット３０とを備えている。

通信インタフェースユニット１０は、例えば有線または無線インタフェースを有しており、ネットワークＮＷを介して、クラウドサーバＣＳＶ、エッジサーバＥＳＶ、または端末デバイスＴＤとの間で情報の送受信を可能にする。

記憶ユニット３０は、記憶媒体として例えばＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）等の随時書込および読み出しが可能な不揮発性メモリを用いたものであり、この実施形態を実現するために必要な記憶領域として、プログラム記憶部の他に、アプリケーション情報記憶部３１と、分割ルール記憶部３２と、動作環境情報記憶部３３とを備えている。

アプリケーション情報記憶部３１は、分散処理の対象となるアプリケーションに関する情報を記憶するために使用される。アプリケーションに関する情報としては、例えば、アプリケーションのソースコード中に含まれる関数の処理順序や、当該アプリケーションの入出力に関する情報が含まれる。

分割ルール記憶部３２は、アプリケーションの分割に係るルールを記憶するために使用される。アプリケーションの分割に係るルールは、例えば、アプリケーションの開発者が定義した関数等の情報に基づく、分割可能なロジックを識別するために使用されるルールである。アプリケーションの分割に係るルールは、あらかじめシステム管理者等によって分割ルール記憶部３２に格納されてもよいし、ネットワークＮＷを介して分割対象のアプリケーション情報とともに取得されてもよい。

動作環境情報記憶部３３は、分散処理に関与し得る情報処理装置（以下、「マシン」とも言う）の動作環境に関する情報を記憶するために使用される。動作環境情報記憶部３３は、例えば、あらかじめシステム管理者等により入力された、複数のマシンの各々についての計算能力、記憶領域、現在位置などに関する情報を格納する。これらの情報は、ネットワークＮＷを介して取得された最新の情報により更新されるようにしてもよい。

ただし、上記記憶部３１～３３は、必ずしも分散処理支援装置１に内蔵されたものでなくてもよく、例えば、ＵＳＢメモリなどの外付け記憶媒体や、クラウドに配置されたデータベースサーバ等の記憶装置に設けられたものであってもよい。分散処理支援装置１は、例えば通信ネットワークＮＷを介して上記クラウドのデータベースサーバにアクセスすることにより、必要なデータを取得し使用することができる。

処理ユニット２０は、図示しないＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等のハードウェアプロセッサと、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）等のメモリとを有し、この実施形態を実施するために必要な処理機能として、ソースコード取得部２１と、ソースコード分割部２２と、配置パターン候補抽出部２３と、最適パターン決定部２４とを備えている。これらの処理機能は、いずれも上記記憶ユニット３０に格納されたプログラムを上記プロセッサに実行させることにより実現される。処理ユニット２０は、また、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（field-programmable gate array）などの集積回路を含む、他の多様な形式で実現されてもよい。

ソースコード取得部２１は、通信インタフェースユニット１０を介して、分散処理の対象とすべきアプリケーションのソースコードを取得する処理を行う。ソースコード取得部２１は、例えば、クラウド上に配置されたアプリケーションを管理する管理サーバ（図示せず）から、ネットワークＮＷを介してソースコードを受信するように構成されてもよいし、図示しない入力デバイスを介してシステム管理者等により入力されたソースコードを取得するように構成されてもよい。ソースコード取得部２１はまた、取得したソースコードをもとに、対象アプリケーションに関する情報を抽出して、アプリケーション情報記憶部３１に格納する処理を行う。

ソースコード分割部２２は、分割ルール記憶部３２に格納された分割ルールをもとに、ソースコード取得部２１により取得されたソースコードの中から分割可能なロジック（関数やクラスなど）を識別し、識別されたロジックごとにソースコードを分割する処理を行う。

配置パターン候補抽出部２３は、ソースコード分割部２２により分割されたロジックと配置先マシンの配置パターンのうち、最適解である可能性がある配置パターンの候補を抽出する処理を行う。

最適パターン決定部２４は、配置パターン候補抽出部２３により抽出された配置パターンの候補のうち最適な配置パターンを決定するもので、アプリ性能計測部２４１と、最適パターン選出部２４２とを備えている。

アプリ性能計測部２４１は、配置パターン候補抽出部２３により抽出された配置パターンの候補の各々について、アプリケーション（アプリ）の性能を計測または算出する処理を行う。

最適パターン選出部２４２は、上記計測または算出されたアプリケーション性能に基づいて、最適な性能が得られる配置パターンを最適な配置パターンとして選出する処理を行う。

（動作）
次に、以上のように構成された分散処理支援装置１による情報処理動作を説明する。図３はその処理手順と処理内容を示すフローチャートである。

（１）開始トリガの受信
分散処理支援装置１は、ステップＳ１により、アプリケーションの分散配置を決定する処理を開始するためのトリガの有無を監視している。この状態で、例えばアプリケーション開発者またはシステム管理者等が管理用端末（図示せず）を通じて分散配置決定の開始要求を入力し、この開始要求をトリガとして受け取ると、分散処理支援装置１は以下の処理を実行する。

（２）ソースコードの取得
分散処理支援装置１は、ステップＳ２において、処理ユニット２０の制御の下、ソースコード取得部２１により、例えばネットワークＮＷを介してアプリケーション管理サーバ（図示せず）から、分散処理の対象であるアプリケーションのソースコードを取得する。ソースコード取得部２１は、取得したソースコードをソースコード分割部２２に渡すとともに、当該ソースコードまたは当該アプリケーションに関する情報をアプリケーション情報記憶部３１に記憶させることができる。アプリケーションに関する情報には、アプリケーションのソースコードに含まれる関数の処理順序や、アプリケーションへの入力データおよび入力元マシン、アプリケーションからの出力データおよび出力先マシンに関する情報が含まれる。なお、アプリケーションのソースコードを、アプリケーション開発者またはシステム管理者が使用する管理用端末から取得するようにしてもよい。

（３）ソースコードの分割
次いで分散処理支援装置１は、ステップＳ３において、処理ユニット２０の制御の下、ソースコード分割部２２により、分割ルール記憶部３２にあらかじめ記憶された分割ルールをもとに、取得されたソースコード中の分割可能なロジック（例えば、関数、クラスなど）を識別し、ソースコードを複数のロジックに分割する。

（４）配置パターンの候補の抽出
次いで分散処理支援装置１は、ステップＳ４において、処理ユニット２０の制御の下、配置パターン候補抽出部２３により、最適である可能性のある配置パターンを配置パターンの候補として抽出する処理を行う。以下、この処理について詳細に説明する。

（４－１）抽出処理の概要
対象アプリケーションにおけるロジックの処理順序やデータの入出力先マシンの情報が定まっており、かつアプリケーションの処理時間短縮やマシン間の通信量の削減を目的とする場合、明らかに最適ではない配置パターンが存在する。

一実施形態に係る分散処理支援装置１は、配置パターンの候補の抽出にあたり、アプリケーション中のロジックの処理順序ならびに分割対象のアプリケーションへデータを入力する入力元マシンおよび当該アプリケーションからのデータの出力先マシンの情報に基づいて、明らかに最適ではない配置パターンをあらかじめ除外し、重要なパターンのみから最適な解を算出する。このような抽出処理により、最適解をとりこぼすことなく、配置パターンの候補の数を削減することができる。

（４－２）有向グラフに基づく非最適な配置パターンの除外
図４は、一実施形態に係る分散処理支援装置１による処理フローのイメージを示す略図である。ここでは、ロジック（関数）の処理順およびデータの入力用のマシンと出力用のマシンとが決まっており、かつマシンＺ、マシンＹ、マシンＸの順に計算能力が高い（すなわち、マシンＸ，Ｙ，Ｚの中では、マシンＺが最も計算能力が高く、マシンＸが最も計算能力が低い）という前提で説明する。

図４において、アプリケーションＰのソースコードＳＣｐが、関数ｍａｉｎ、関数Ａ、関数Ｂ、関数Ｃに分割される。これらの関数の処理順序は、ｍａｉｎ，Ａ，Ｂ，Ｃの順である。また、関数ｍａｉｎはデータを入力する関数であり、データの入力元マシンはマシンＸ（例えば、スマートフォンＴＤ）、データの出力先マシンはマシンＺ（例えば、クラウドサーバＣＳＶ）である。マシンＹは、入出力用のマシンＸおよびマシンＺ以外の配置先候補マシンであり、たとえばエッジサーバＥＳＶである。

分割された関数がマシンに配置される配置パターンには、多数のパターンＰ１～Ｐｎが考えられ、これらの配置パターンの中から最適解（図４に示した例ではパターンＰ５９）が選択されることになる。

しかし、上記前提において、アプリケーション全体の処理時間を向上させたい場合には、図４に示した配置パターンのうち配置パターンＰ３は最適な配置パターンではないことがわかる。これは、配置パターンＰ１またはＰ２に比べて、関数Ａの次に処理されるべき関数Ｂが、計算能力の高いマシンＺから計算能力の低いマシンＸへオフロードされているような配置パターンとなっており、配置パターンＰ３の処理時間が、配置パターンＰ１またはＰ２よりも長くなることが明確なためである。パターンＰ４やパターンＰｎについても、上述と同様の理由により、最適ではない配置パターンとして除外（枝刈り）することができる。

この最適ではない配置パターン（以下、「非最適な配置パターン」と言う）を一般化すると、以下のように表現することができる。

＜非最適な配置パターン＞
ある配置パターンにおいて、関数の処理順にマシン間を有向辺で結んだグラフ（以下、「処理フローグラフ」と言う）が、以下のグラフＧ１またはＧ２のいずれとも合致しない場合、その配置パターンは最適な配置ではない。
（Ｇ１）データを入力する関数が配置されているマシン（データ入力元マシン）と、データを出力する関数が配置されているマシン（データ出力先マシン）とが異なる場合：データ入力元マシンを始点、データ出力先マシンを終点として、配置先候補マシンを計算能力が低い順に１回以下通る最短有向道群
（Ｇ２）データ入力元マシンとデータ出力先マシンが同じ場合：配置先候補マシンを計算能力が低い順に１回以下通る最短有向閉路群

図５は、非最適な配置パターンであるか否かの判断例を示す略図であり、図４の例における配置先候補マシンの最短有向道群（有向道１および２（いずれも上記Ｇ１に該当））ならびに配置パターンＰ３の処理フローグラフを示している。図５から、配置パターンＰ３の処理フローグラフは、最短有向道１とも最短有向道２とも合致しないため（また上記Ｇ２にも該当しないため）、非最適な配置パターンと判定される。

（４－３）非最適な配置パターンであることの証明
ここで、ロジックの処理順序、ならびにデータ入力元マシンおよびデータ出力先マシンが決まっており、かつアプリケーションの処理時間短縮や通信量削減を目的とする環境において、上記グラフＧ１またはＧ２のいずれとも合致しない配置パターンが最適ではないことの証明について以下で説明する。

［仮定］
データ入力元マシンを始点、データ出力先マシンを終点として、配置先候補マシンを計算能力が低い順に１回以下通る最短有向道群または最短有向閉路群のいずれとも合致しない処理フローグラフを持つ配置パターンＡが最適解であると仮定する。図６は、このような配置パターンＡの一例を示す。

［証明］
図６に示した配置パターンＡにおいて、実際にロジックが配置されているマシンの集合をＭとする。配置パターンＡの処理フローグラフは、最短有向道・閉路群のいずれにも合致しないため、集合Ｍに含まれるマシンを節点とする最短有向道・閉路群とは逆向きの有向辺ｅを１つ以上持つ。この有向辺ｅに沿ってデータを送信するロジックをｌ_ａ、データを受信するロジックをｌ_ｂとする。また、ｌ_ａが配置されているマシン（すなわちｅの始点に当たるマシン）をｍ_ａ、ｌ_ｂが配置されているマシン（すなわちｅの終点に当たるマシン）をｍ_ｂとする。

ここで配置パターンＡにおける逆向きの有向辺ｅがなくなるように、ロジックｌ_ｂをマシンｍ_ｂからｍ_ａへ移動させた配置パターンをＡ’とする。図７は、そのような配置パターンＡ’の一例を示す。

最短有向道・閉路群では、各マシンが処理順に有向辺で結ばれており、ｍ_ａの計算能力はｍ_ｂより高い。そのため、配置パターンＡ’は、配置パターンＡと比較して、ロジックｌ_ｂの処理時間が短く、かつ有向辺ｅに沿って流れていたデータ量分の通信量が少ない。つまり、配置パターンＡ’は、配置パターンＡより処理時間が短く、通信量も少ない配置パターンとなるため、配置パターンＡが最適解であるという仮定に矛盾する。

以上より、データ入力元マシンを始点、データ出力先マシンを終点として、配置先候補マシンを計算能力が低い順に１回以下通る最短有向道群または最短有向閉路群のいずれとも合致しない処理フローグラフを持つ配置パターンは、最適な配置パターンではない（非最適な配置パターンである）と言える。

（４－４）アルゴリズム例
図８は、一実施形態に係る分散処理支援装置１で用いられる、最適解の可能性がある配置パターンを抽出するためのアルゴリズムの一例として、アルゴリズム１を示す。
図９は、図８に示したアルゴリズム１内で使用される記号の説明を示す。

図８に示したアルゴリズム１の５，７行目の“ comb (A, i) ”は、集合Ａからｉ個選び出した時の組み合わせの計算を示している。すなわち、図８のアルゴリズムでは、以下の手順で配置パターンの抽出を行っている。

（ｉ）入力元マシン・出力先マシン以外の配置先候補マシン数を確認する（２行目）。

（ｉｉ）配置先候補マシンの中から、Ｌ_ＩＯ （データの入出力処理が含まれるロジック群）以外のロジックを配置するマシンをｉ台選出する（４行目）。この各組み合わせに入出力マシンを加えたものを ＭＣ_ｉ とする（５，６行目）。例えば、配置先候補マシンＸ，Ｙ，Ｚの３台の中から入出力マシンであるＸ，Ｚを除いて０台を選ぶ場合、ＭＣ_０＝｛（Ｘ，Ｚ）｝となり、１台選ぶ場合、ＭＣ_１＝｛（Ｘ，Ｙ，Ｚ）｝となる。

（ｉｉｉ）手順（ｉｉ）と同様に、データフローグラフ（関数の処理順に関数間を有向辺で結んだグラフ）の辺から、ｉ＋１個の辺を選出する（７行目）。この辺は、抽出される配置パターンの処理フローグラフの辺になる。図１０は、データフローグラフの一例を示す図である。図１０に示すデータフローグラフから２個の辺を選出する場合、ＥＣ_２＝｛（ｅ_１，ｅ_２），（ｅ_２，ｅ_３），（ｅ_１，ｅ_３）｝となる。

（ｉｖ）データフローグラフの節点にあたる各ロジックを、手順（ｉｉｉ）で選出したデータフローグラフの辺の始点側のロジック群と終点側のロジック群に分ける（８行目）。図１１は、ｅ_２，ｅ_３が選出された場合のデータフローグラフの一例を示す。図１１では、各ロジック（関数）群を、ｅ_２の始点側のグループ１と終点側（ｅ_３の始点側）のグループ２、ｅ_３の終点側のグループ３に分けている。この処理を、手順（ｉｉｉ）で計算した辺の組み合わせごとに行う。

（ｖ）Ｌ_ＩＯ に含まれるロジックは、それぞれ入力元マシン、出力先マシンにしか配置できないという前提のもと、手順（ｉｉ）で得られたマシンの組み合わせと、手順（ｉｖ）で得られたロジックのグループの組み合わせの直積を計算することにより、配置パターンを計算する。例えば、マシンの組み合わせが（Ｘ，Ｚ），（Ｘ，Ｙ，Ｚ）の２通りで、ロジックのグループの組み合わせが、以下の６通りである場合：
（ｇ１）：（ｍａｉｎ），（Ａ，Ｂ，Ｃ）
（ｇ２）：（ｍａｉｎ，Ａ），（Ｂ，Ｃ）
（ｇ３）：（ｍａｉｎ，Ａ，Ｂ），（Ｃ）
（ｇ４）：（ｍａｉｎ），（Ａ），（Ｂ，Ｃ）
（ｇ５）：（ｍａｉｎ，Ａ），（Ｂ），（Ｃ）
（ｇ６）：（ｍａｉｎ），（Ａ，Ｂ），（Ｃ）
配置パターンとして以下の６通りが得られる。
（ｐ１）：（Ｘ，Ｚ），（（ｍａｉｎ），（Ａ，Ｂ，Ｃ））
・・・ｍａｉｎをマシンＸに、Ａ，Ｂ，ＣをマシンＺに配置
（ｐ２）：（Ｘ，Ｚ），（（ｍａｉｎ，Ａ），（Ｂ，Ｃ））
・・・ｍａｉｎ，ＡをマシンＸに、Ｂ，ＣをマシンＺに配置
（ｐ３）：（Ｘ，Ｚ），（（ｍａｉｎ，Ａ，Ｂ），（Ｃ））
・・・ｍａｉｎ，Ａ，ＢをマシンＸに、ＣをマシンＺに配置
（ｐ４）：（Ｘ，Ｙ，Ｚ），（（ｍａｉｎ），（Ａ），（Ｂ，Ｃ））
ｍａｉｎをマシンＸに、ＡをマシンＹに、Ｂ，ＣをマシンＺに配置
（ｐ５）：（Ｘ，Ｙ，Ｚ），（（ｍａｉｎ，Ａ），（Ｂ），（Ｃ））
ｍａｉｎ，ＡをマシンＸに、ＢをマシンＹに、ＣをマシンＺに配置
（ｐ６）：（Ｘ，Ｙ，Ｚ），（（ｍａｉｎ），（Ａ，Ｂ），（Ｃ））
ｍａｉｎをマシンＸに、Ａ，ＢをマシンＹに、ＣをマシンＺに配置

（５）最適配置パターンの決定
以上のように配置パターンの候補が抽出されたら、続いて分散処理支援装置１は、図３のステップＳ５において、処理ユニット２０の制御の下、最適パターン決定部２４のアプリ性能計測部２４１により、抽出された配置パターンの候補の各々について分散アプリケーションを動作させたときのアプリケーション性能を計測または算出する。一実施形態では、アプリ性能計測部２４１は、アプリケーション性能として、当該アプリケーションの全処理が終了するまでに要する時間、マシン（情報処理装置）間のトラヒック量、およびマシン間のネットワーク遅延のうちの少なくとも１つを計測または算出する。

次いで、分散処理支援装置１は、ステップＳ６において、最適パターン決定部２４の最適パターン選出部２４２により、計測または算出されたアプリケーション性能に基づいて、最適な性能が得られる配置パターンを最適な配置パターンとして決定する。例えば、最適パターン選出部２４２は、アプリ性能計測部２４１によって算出された、全処理が終了するまでに要する時間に基づき、その時間が最も短い配置パターンを最適な配置パターンとして選出するように構成される。あるいは、最適パターン選出部２４２は、マシン間のトラヒック量が最も少ない配置パターン、またはマシン間のネットワーク遅延が最も少ない配置パターンを、最適パターンとして選出するように構成される。このように、最適パターン決定部２４の構成をシステム管理者等が任意に設定することにより、分散処理システムの目的に応じた最適な配置パターンを決定することが可能である。

図１２は、アプリケーションの性能を向上させる配置パターンが決定されるまでの各機能部の処理フローの一例を示す。

一実施形態に係る分散処理支援装置１は、まずステップＳ１０１において、ソースコード分割部２２の制御の下、入力されたアプリケーションＰのソースコードの中からロジック（例えば、関数やクラスなど）を識別し、このロジックごとにソースコードを分割する。

次いで、分散処理支援装置１は、ステップＳ１０２において、配置パターン候補抽出部２３の制御の下、分割された各ロジックとアプリケーションの動作環境の情報（配置先候補マシンとその計算能力）をもとに、最適解である可能性がある配置パターンのみを候補として抽出する。ここでは、例えば、図８に示したアルゴリズム１を用いて最適解である可能性がある配置パターンを抽出することにより、非最適な配置パターンを枝刈りすることができる。

次いで、分散処理支援装置１は、ステップＳ１０３において、アプリ性能計測部２４１の制御の下、抽出された配置パターンの各々において分散アプリケーションを実行した場合のアプリケーション性能値を計測する。

次いで、分散処理支援装置１は、ステップＳ１０４において、最適パターン選出部２４２の制御の下、計測されたアプリケーション性能値に基づき、抽出された配置パターンのみを全探索することによって、要求される性能が最も高くなるロジックの配置パターンを選出することができる。

図１２に示した例では、図４に示した最適パターンＰ５９のように、マシンＸに対してｍａｉｎ関数および関数Ａ、マシンＹに対して関数Ｂ、マシンＺに対して関数Ｃが配置される配置パターンが、最適解として決定される。

（有効性の検証）
以上で説明した技術の有効性を確認するために、以下の環境を想定したシミュレーション実験を行った。
・配置先候補マシンは５台で、入力元マシンは最も計算能力が低いマシン、出力先マシンは最も計算能力が高いマシンとする。
・分割・配置対象のアプリケーションは、２～１０個の関数を持つアプリケーションで、各関数は順番に呼び出されるものとする。入力処理が含まれる関数はデータフローグラフの根に当たる関数で、出力処理が含まれる関数はデータフローグラフの葉に当たる関数である。
・各関数の処理時間は、計算能力が高いマシンに配置されるほど短くなるようにランダムに設定する。関数間の通信量はランダムに設定し、マシン間の通信遅延は、通信量が多いほど大きくなるように設定する。

以上の環境において、乱数を毎回変えながら１００回の試行を行い、以下の指標の平均値を計算した。
（指標１）配置パターン数：各関数と配置先候補マシンとの組み合わせ数
（指標２）精度：配置パターンの中に最適解が含まれる割合。含まれる場合を１、含まれない場合を０とする。

また、比較手法として、すべての配置パターンを探索する単純方式（ｎａｉｖｅ）と、焼きなまし法（ＳＡ）（Verbelen, Tim, et al., “Graph partitioning algorithms for optimizing software deployment in mobile cloud computing,” Future Generation Computer Systems, vol.29, No.2, pp.451-459, 2013. 参照）を適用した。焼きなまし法は、ランダムに選んだ初期解から、その性能が良くなる解が得られる方向に探索を行い、一定回数探索したときに得られる解を近似解として出力する方式である。本実験では、焼きなまし法における探索回数を、発明技術で得られる配置パターン数と同じ値に設定して評価を行った。

図１３は、単純方式（ｎａｉｖｅ）と、一実施形態に係る分散処理支援装置１による提案方式（ｐｒｏｐｏｓｅｄ）とを用いたときの、指標１の比較結果を示す図である。横軸は関数の数、縦軸は最適探索の対象となる配置パターンの数を示す。図１３に示したように、全配置パターンを探索する単純方式（ｎａｉｖｅ）と比較して、提案方式（ｐｒｏｐｏｓｅｄ）では大幅に配置パターン数を削減できることがわかる。特に、配置パターン数が多い関数１０個の場合においては、単純方式（ｎａｉｖｅ）によるすべての配置パターン数が３９０，６２５通りであるのに対し、提案方式（ｐｒｏｐｏｓｅｄ）を用いて抽出された配置パターン数は４９５通りとなり、配置パターン数を９９％以上削減することができた。

図１４は、焼きなまし法（ＳＡ）と、一実施形態に係る分散処理支援装置１による提案方式（ｐｒｏｐｏｓｅｄ）とを用いたときの、指標２の比較結果を示す図である。横軸は関数の数、縦軸は最適探索の精度を示す。図１４に示したように、焼きなまし法（ＳＡ）では、関数の数が２個のときには高い精度（１．０）が得られたが、関数の数が３個になると精度が０．２まで落ち込み、関数の数が４個以上になると精度が著しく低下した。このように、焼きなまし法（ＳＡ）では、関数の数が多くなるほど、最適解の取得が困難になっていることがわかる。一方、提案方式（ｐｒｏｐｏｓｅｄ）の場合、関数の数が増加した場合でも、精度は１を維持しており、上記（４－３）で証明したとおり、すべての試行において最適解を取得することができた。

なお、データフローグラフ内に閉路が存在する場合にも、上記実施形態を適用することができる。例えば、データフローグラフを複数の有向道に分割し、そのそれぞれに対して上記実施形態を適用することにより、配置パターン数を削減することができる。

図１５は、そのような、閉路が存在するデータフローグラフへの上記実施形態の適用手順の一例を示す。この例では、Ａを始点、Ｆを終点とするデータフローグラフＦＧ１内に、Ｂで分岐しＥで合流する閉路が存在する。はじめに、データフローグラフＦＧ１を分割し、ＦＧ２に示されるように、２つの有向道（有向道１’および２’）を得る。そして、まず有向道１’に対して上記実施形態を適用する。

実施形態を適用した結果、ＦＧ３に示されるように、有向道１’の最適な配置パターンＰ１’が決まったとする。この例では、Ａ，ＢがマシンＸに配置され、Ｃ，Ｄ，ＥがマシンＹに配置され、ＦがマシンＺに配置される。有向道１’の最適な配置パターンＰ１’が決まれば、有向道２’のデータ入力元マシン（Ｂを処理するマシン）およびデータ出力先マシン（Ｅを処理するマシン）も同時に決まることになる。そこで、これらの入力元マシンおよび出力先マシンを前提として、次に有向道２’に対して実施形態を適用することができる。図１５の例では、有向道２’について、ＢがマシンＸに配置され、ＥがマシンＹに配置される。有向道２’に含まれるＧ，Ｈ，Ｉは、まだ配置が決定されていないので破線で図示されている。

このように、データフローグラフ内に閉路が存在する場合においても、上記実施形態を容易に適用することができる。

（効果）
以上詳述したように、この発明の一実施形態では、アプリケーションのソースコードが取得され、該ソースコードが複数のロジックへと分割され、アプリケーションにおけるこれら複数のロジックの処理順序と複数の情報処理装置の動作環境に関する情報とに基づいて、情報処理装置のいずれかに複数のロジックを分散配置するときの配置パターンの候補が抽出される。そして、この抽出された候補の中から、分散アプリケーションの各ロジックを配置するための最適な配置パターンが決定される。

分散アプリケーションの性能を向上させるために必要な、アプリケーションの各ロジックの配置問題を最適化問題として解く場合、通常、解の最適性と探索する配置パターン数の間にはトレードオフが存在する。従来の近似解法を用いて最適な配置パターンを計算しようとする場合には、高速計算が可能となるが、解の最適性が保証されず、最適な配置パターンを取得することが困難であった。

この課題に対し、一実施形態では、アプリケーション内のロジックの処理順序、配置先候補マシンの計算能力、およびアプリケーションの配置問題における目的関数の関係性に着目することにより、最適解を残しつつ、探索する配置パターン数を大幅に削減することに成功した。すなわち、最適である可能性のある配置パターンのみを抽出し（逆に言えば、可能性のない配置パターンを除外（枝刈り）し）、探索する配置パターン数を大幅に削減するようにしているので、最適解を取りこぼすことなく、最適なアプリケーションの分散配置を効率的にかつ高速に計算することができる。

また、上記のように、データフローグラフ内に閉路が存在する場合においても、実施形態を適用でき、最適解を取りこぼすことなく配置パターン数を削減することができる。

［他の実施形態］
なお、この発明は上記実施形態に限定されるものではない。
例えば、上記実施形態では、分散アプリケーションの配置先としてマシンＸ，マシンＹ，マシンＺを挙げて説明した。特に上記実施形態では、マシンＸがスマートフォンなどの端末デバイスＴＤであり、マシンＹがエッジサーバＥＳＶであり、マシンＺがクラウドサーバＣＳＶである例を挙げて説明したが、これに限定されるものではない。例えば、分散アプリケーションの配置先のマシンＸ，マシンＹ，マシンＺすべてを、クラウドサーバＣＳＶ、エッジサーバＥＳＶ、またはスマートフォンとすることも可能であり、さらに分散アプリケーションの配置先のマシンＸ，マシンＹ，マシンＺをクラウドサーバＣＳＶ、エッジサーバＥＳＶ、およびスマートフォンのうちの２つにすることも可能である。

配置先マシンの数は、２個または３個に限定されるものではなく、望まれるアプリケーション性能に応じて任意の数を設定することができる。

同様に、ソースコードの分割ルールについても、アプリケーションの開発者が定義した関数単位での分割に限定されるものではなく、任意の基準を設定して、より大きな単位またはより小さな単位に分割されるようにしてもよい。

あるいは、分散処理支援装置１が備える各部２１～２４を、クラウドコンピュータ、エッジルータ等に分散配置し、これらの装置が互いに連携することにより上記処理を行うようにしてもよい。

その他、最適解である可能性がある配置パターンの候補を抽出するためのアルゴリズムの詳細等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。

例えば、上記実施形態の第１の態様として、複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置（１）が、上記アプリケーションのソースコードを取得するソースコード取得部（２１）と、上記ソースコードを複数のロジックに分割するソースコード分割部（２２）と、上記アプリケーションにおける上記複数のロジックの処理順序と、上記複数の情報処理装置の動作環境に関する情報とに基づいて、上記複数の情報処理装置のいずれかに上記複数のロジックを分散配置するときの当該複数のロジックの配置パターンの候補を抽出する候補抽出部（２３）と、上記抽出された配置パターンの候補の中から最適な配置パターンを決定する最適パターン決定部（２４）とを具備するようにし得る。

第２の態様として、上記第１の態様において、上記候補抽出部（２３）が、上記複数の情報処理装置をノードとし、上記アプリケーションにおける上記複数のロジックの処理順序を特定する有向辺を経路とした有向グラフを用いて、非最短経路の配置パターンを除外することによって、上記配置パターンの候補を抽出するようにし得る。

第３の態様として、上記第１の態様において、上記候補抽出部（２３）が、上記複数の情報処理装置を計算能力が低いものから高いものへと順に並べたものをノードとし、上記アプリケーションにおける上記複数のロジックの処理順序を特定する有向辺を経路とした有向グラフを用いて、最短経路の配置パターンを上記配置パターンの候補として抽出するようにし得る。

第４の態様として、上記第１の態様において、上記最適パターン決定部（２４）が、上記抽出された配置パターンの候補の各々について上記アプリケーションを動作させたときの全処理に係るアプリケーション性能を計測する性能計測部（２４１）と、上記アプリケーションの性能の計測結果に基づいて上記配置パターンの候補の中から最良の性能をもたらす配置パターンを選出する最適パターン選出部（２４２）とを備えるようにし得る。

第５の態様として、上記第４の態様において、さらに上記性能計測部（２４１）が、上記アプリケーション性能として、全処理が終了するまでに要する時間、上記情報処理装置間のトラヒック量、および上記情報処理装置間のネットワーク遅延のうちの少なくとも１つを計測するようにし得る。

上記実施形態によれば、複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置において、アプリケーションのソースコードが複数のロジックへと分割され、分割されたロジックの処理順序と情報処理装置の動作環境に関する情報とに基づいて、情報処理装置に対するロジックの配置パターンの候補が抽出され、その候補の中から最適な配置パターンが決定される。このように、分割されたロジックの配置パターンの候補を抽出してから、最適な配置パターンを決定するようにしているので、すべての組合せに係る配置パターンから最適解を決定する場合に比べて効率的に最適な配置パターンを決定することができる。

また上記実施形態によれば、分割されたロジックの配置先である情報処理装置をノードとし、ロジックの処理順序を有向辺で示した有向グラフを用いて、非最短経路を除外することによって配置パターンの候補が抽出される。このように、最適解である可能性のない非最短経路を除外（枝刈り）することにより、最適解である可能性のある配置パターンを候補として維持しつつ、探索対象の数を削減して、効率的な最適探索を実行することができる。

また上記実施形態によれば、情報処理装置を計算能力の低いものから高いものへと順に並べたものをノードとし、ロジックの処理順序を有向辺で示した有向グラフを用いて、最短経路をとる配置パターンが配置パターンの候補として抽出される。このように、有向グラフのノードとして、情報処理装置を計算能力が高くなる順に並べたノードを用いて最短経路を候補として抽出しているので、ロジックの処理が進むにつれて計算能力の高い情報処理装置から計算能力の低い情報処理装置へとオフロードされるような非最適解を除外することができ、効率的な最適探索を実行することができる。

また上記実施形態によれば、抽出された配置パターンの候補の各々についてアプリケーションを動作させたときのアプリケーション性能が計測され、その計測結果に基づいて最適な配置パターンが選出される。このように、抽出された配置パターンの候補の中から、アプリケーションの性能に基づいて最適な配置パターンが選出されるので、信頼性の高い最適解の探索を行うことができる。

また上記実施形態によれば、アプリケーション性能として、全処理に要する時間、情報処理装置間のトラヒック量、およびネットワーク遅延のうちの少なくとも１つが計測される。このように、抽出された配置パターンの候補の中から、アプリケーション全体としての処理時間、トラヒック量、またはネットワーク遅延に基づいて最適な配置パターンが決定されるので、分散処理の目的に応じた最適な性能をもたらす、信頼性の高い最適解の探索を行うことができる。

以上で特定の実施形態について説明したが、これらの実施形態は、例示の目的で提示したにすぎず、発明の範囲を限定することを意図したものではない。実際、本明細書に記載された新規な実施形態は、他の様々な形態で具体化され得る。さらに、発明の範囲から逸脱することなく、本明細書に記載された実施形態の形態に対し、様々な省略、置換および変更を加えることもできる。添付の請求項およびそれらと等価のものは、本発明の主旨および範囲内に含まれるそのような形態および変形形態に及ぶことが意図されている。

１…分散処理支援装置
１０…通信インタフェースユニット
２０…処理ユニット
３０…記憶ユニット
２１…ソースコード取得部
２２…ソースコード分割部
２３…配置パターン候補抽出部
２４…最適パターン決定部
２４１…アプリ性能計測部
２４２…最適パターン選出部
３１…アプリケーション情報記憶部
３２…分割ルール記憶部
３３…動作環境情報記憶部

Claims (7)

1. 複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置であって、
   前記アプリケーションのソースコードを取得するソースコード取得部と、
   前記ソースコードを複数のロジックに分割するソースコード分割部と、
   前記アプリケーションにおける前記複数のロジックの処理順序と、前記複数の情報処理装置の動作環境に関する情報とに基づいて、前記複数の情報処理装置のいずれかに前記複数のロジックを分散配置するときの当該複数のロジックの配置パターンの候補を抽出する、候補抽出部と、
   前記抽出された配置パターンの候補の中から最適な配置パターンを決定する、最適パターン決定部とを具備し、
   前記候補抽出部は、前記複数の情報処理装置をノードとし、前記アプリケーションにおける前記複数のロジックの処理順序を特定する有向辺を経路とした有向グラフを用いて、非最短経路の配置パターンを除外することによって、前記配置パターンの候補を抽出する、分散処理支援装置。
2. 複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置であって、
   前記アプリケーションのソースコードを取得するソースコード取得部と、
   前記ソースコードを複数のロジックに分割するソースコード分割部と、
   前記アプリケーションにおける前記複数のロジックの処理順序と、前記複数の情報処理装置の動作環境に関する情報とに基づいて、前記複数の情報処理装置のいずれかに前記複数のロジックを分散配置するときの当該複数のロジックの配置パターンの候補を抽出する、候補抽出部と、
   前記抽出された配置パターンの候補の中から最適な配置パターンを決定する、最適パターン決定部とを具備し、
   前記候補抽出部は、前記複数の情報処理装置を計算能力が低いものから高いものへと順に並べたものをノードとし、前記アプリケーションにおける前記複数のロジックの処理順序を特定する有向辺を経路とした有向グラフを用いて、最短経路の配置パターンを前記配置パターンの候補として抽出する、分散処理支援装置。
3. 前記最適パターン決定部は、
   前記抽出された配置パターンの候補の各々について前記アプリケーションを動作させたときの全処理に係るアプリケーション性能を計測する、性能計測部と、
   前記アプリケーションの性能の計測結果に基づいて前記配置パターンの候補の中から最良の性能をもたらす配置パターンを選出する、最適パターン選出部とを備える、請求項１または２に記載の分散処理支援装置。
4. 前記性能計測部は、
   前記アプリケーション性能として、全処理が終了するまでに要する時間、前記情報処理装置間のトラヒック量、および前記情報処理装置間のネットワーク遅延のうちの少なくとも１つを計測する、請求項３に記載の分散処理支援装置。
5. 複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置が実行する、分散処理支援方法であって、
   前記アプリケーションのソースコードを取得する過程と、
   前記ソースコードを複数のロジックに分割する過程と、
   前記アプリケーションにおける前記複数のロジックの処理順序と、前記複数の情報処理装置の動作環境に関する情報とに基づいて、前記複数の情報処理装置のいずれかに前記複数のロジックを分散配置するときの当該複数のロジックの配置パターンの候補を抽出する過程と、
   前記抽出された配置パターンの候補の中から最適な配置パターンを決定する過程とを具し、
   前記抽出する過程は、前記複数の情報処理装置をノードとし、前記アプリケーションにおける前記複数のロジックの処理順序を特定する有向辺を経路とした有向グラフを用いて、非最短経路の配置パターンを除外することによって、前記配置パターンの候補を抽出する、分散処理支援方法。
6. 複数の情報処理装置によるアプリケーションの分散処理を支援する分散処理支援装置が実行する、分散処理支援方法であって、
   前記アプリケーションのソースコードを取得する過程と、
   前記ソースコードを複数のロジックに分割する過程と、
   前記アプリケーションにおける前記複数のロジックの処理順序と、前記複数の情報処理装置の動作環境に関する情報とに基づいて、前記複数の情報処理装置のいずれかに前記複数のロジックを分散配置するときの当該複数のロジックの配置パターンの候補を抽出する過程と、
   前記抽出された配置パターンの候補の中から最適な配置パターンを決定する過程とを具し、
   前記抽出する過程は、前記複数の情報処理装置を計算能力が低いものから高いものへと順に並べたものをノードとし、前記アプリケーションにおける前記複数のロジックの処理順序を特定する有向辺を経路とした有向グラフを用いて、最短経路の配置パターンを前記配置パターンの候補として抽出する、分散処理支援方法。
7. 請求項１乃至請求項４のいずれか一項に記載の装置の各部による処理をプロセッサに実行させるプログラム。
   

Images