JP6839673B2 - アプリケーション分割装置、方法およびプログラム - 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/〉 Github, Inc.、顔認識：Plain Face Detector & Gender Recognizer、[online]、インターネット〈URL：https://github.com/MinhasKamal/GenderRecognizer〉 Jeanne Ferrante, et al.、「The Program Dependence Graph and Its Use in Optimization」、ACM Transactions on Programming Languages and Systems, vol.9, no.3, pp.319-349, 1987

アプリケーション分割および配置に関する従来の技術では、アプリケーションを複数のロジックに分割し、各マシンに分散配置する際、開発者が定義した関数を１つのロジックとして扱うため、次のような問題をかかえている。

第１に、開発者が定義した関数が、アプリケーション性能を最大化する上で最適な形になっていない場合（例えば、すべての処理を１つの関数の中に記述した場合など）、開発者が定義した関数を１つのロジックとして扱う従来技術では、アプリケーション性能を向上しきれない場合がある。

第２に、アプリケーションの開発時に関数がアプリケーション性能を最大化する上で最適な形になるように開発者に要求することは、関数間で受け渡しされるデータ量や、各関数の処理時間など、様々な性能指標について意識しながら開発することを開発者にしいることになり、開発時の負担が大きくなる。

この発明は、上記事情に着目してなされたもので、その目的とするところは、開発者による関数定義に依存せずに関数をさらに複数のロジックへ分割できるようにするアプリケーション分割装置、方法、およびプログラムを提供することにある。

上記課題を解決するためにこの発明の第１の態様は、複数の情報処理装置によって分散処理されるアプリケーションを複数のロジックに分割するアプリケーション分割装置にあって、前記アプリケーションのソースコードを取得する取得部と、前記ソースコード内で定義される複数の関数を識別し、前記ソースコードを前記複数の関数に分割する第１の分割部と、分割された前記関数の各々について、あらかじめ設定されたルールに従い、さらに分割可能か否かを判定する判定部と、分割可能であると判定された場合、前記関数が複数のロジックから成ると判定され、１または複数の行を含む複数の関数として分割する第２の分割部とを具備するようにしたものである。

この発明の第２の態様は、前記第１の分割部および前記第２の分割部により分割された複数の関数を前記複数の情報処理装置に割り当てる分散配置部をさらに具備するようにしたものである。

この発明の第３の態様は、前記分散配置部が、前記ソースコード内で定義される複数の関数のうち、前記第２の分割部により分割されていない関数についてはその関数単位で、前記第２の分割部により分割された関数については分割後の関数単位で、前記複数の情報処理装置への最適な分散配置を決定する配置決定部を備えるようにしたものである。

この発明の第４の態様は、前記判定部が、前記ルールに従い、２つの処理の間にデータ依存関係および制御依存関係が存在しないと判定されたことに基づいて、前記２つの処理が分割可能であると判定するようにしたものである。

この発明の第５の態様は、前記判定部が、前記ルールに従い、２つの処理の間にデータ依存関係または制御依存関係が存在するが前記２つの処理を分割した場合に実行順序の逆転がないと判定されたことに基づいて、前記２つの処理が分割可能であると判定するようにしたものである。

この発明の第６の態様は、前記判定部が、前記ルールに従い、２つの処理が、直列化および直列化復元可能に標準設定されていないデータ型によるデータ依存関係があると判定されたことに基づいて、前記２つの処理が分割可能でないと判定するようにしたものである。

この発明の第１の態様によれば、複数の情報処理装置によって分散処理されるアプリケーションのソースコードが取得され、ソースコード内で定義される複数の関数が識別され、ソースコードが複数の関数に分割される。そして、分割された関数の各々について、あらかじめ設定されたルールに従い、さらに分割可能か否かが判定され、分割可能であると判定された場合、関数が複数のロジックから成るものと判定され、１または複数の行を含む複数の関数へと分割される。これにより、開発者による関数定義に依存せず、開発者が定義した関数をさらに複数のロジック（関数）へと分割することができる。

この発明の第２の態様によれば、分割された複数の関数および分割された複数のロジックが複数の情報処理装置に割り当てられる。これにより、アプリケーションの分割処理から、分割された複数の関数を複数の情報処理装置に分散配置する処理までを、開発者またはシステムの運用者の操作に依存せずに自動的に行うことが可能となる。

この発明の第３の態様によれば、ソースコード内で定義される複数の関数のうち、分割されていない関数についてはその関数単位で、分割された関数については分割後の関数単位で、複数の情報処理装置への最適な分散配置が決定される。これにより、開発者による関数定義に依存せず、分割された関数の分散配置をより詳細な条件下で最適化して、アプリケーションの最適な分散処理を実現することができる。

この発明の第４の態様によれば、２つの処理の間にデータ依存関係および制御依存関係が存在しないと判定されたことに基づいて、当該２つの処理が分割可能であると判定される。これにより、開発者による関数定義に依存せず、処理間の依存関係の有無の判定に基づいて、関数をさらに分割可能か否か判定することができる。

この発明の第５の態様によれば、２つの処理の間にデータ依存関係または制御依存関係が存在する場合でも２つの処理を分割した場合に実行順序の逆転がないと判定されたことに基づいて、当該２つの処理が分割可能であると判定される。これにより、開発者による関数定義に依存せず、実行順序の逆転の有無の判定に基づいて、関数をさらに分割可能か否か判定することができる。

この発明の第６の態様によれば、２つの処理が、直列化および直列化復元可能に標準設定されていないデータ型によるデータ依存関係があると判定されたことに基づいて、当該２つの処理が分割可能でないと判定される。これにより、開発者による関数定義に依存せず、２つの処理がどのようなデータ型によるデータ依存関係にあるかの判定に基づいて、関数をさらに分割可能か否か判定することができる。

すなわちこの発明の各態様によれば、開発者による関数定義に依存せずに関数をさらに複数のロジックへ分割できるようにしたアプリケーション分割装置、方法、およびプログラムを提供することができる。

図１は、この発明の一実施形態に係るアプリケーション分割装置を含むシステムの一例を示す概略構成図である。 図２は、図１に示したアプリケーション分割装置の機能構成を示すブロック図である。 図３は、図２に示したアプリケーション分割装置による処理手順の一例を示すフローチャートである。 図４は、図３に示した処理のうち分割可否の判定処理の一例を示すフローチャートである。 図５は、行単位の分割が不可能な箇所の一例を示す図である。 図６は、一実施形態に係るアプリケーション分割装置による関数の分割および配置のイメージを示す図である。 図７は、一実施形態に係るアプリケーション分割装置による関数の分割および配置フローを示す図である。

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

［一実施形態］
（構成）
図１は、この発明の一実施形態に係るアプリケーション分割装置を含むシステムの一例を示す概略構成図である。
このシステムは、通信ネットワークＮＷを介して通信可能なアプリケーション分割装置１と、アプリケーションの分散処理を担うエッジサーバＥＳＶ１，ＥＳＶ２，…ＥＳＶｉ（まとめてエッジサーバＥＳＶと言う）と、１または複数のエッジサーバＥＳＶを介してクラウド上のアプリケーションを利用可能なユーザ端末ＵＴ１，ＵＴ２，ＵＴ３，ＵＴ４，…ＵＴｊ（以後まとめてユーザ端末ＵＴと言う）を備えている。ユーザ端末ＵＴには、例えば、スマートフォン、ラップトップコンピュータ、自動車、その他のＩｏＴ機器が用いられる。なお、図示したユーザ端末ＵＴは一例にすぎず、固定端末であっても移動端末であってもよく、任意の数の様々な機器を含み得る。また、ユーザ端末ＵＴは、必ずしもエッジサーバＥＳＶを経由する必要はなく、エッジサーバＥＳＶを経由せずに通信ネットワークＮＷを介してクラウド上に配置されたアプリケーションを利用することもできる。

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

通信ネットワークＮＷは、例えばインターネットに代表されるＩＰ（Internet Protocol）網と、このＩＰ網に対しアクセスするための複数のアクセス網とから構成される。アクセス網としては、光ファイバを使用した有線網はもとより、例えば３Ｇ又は４Ｇ等の規格の下で動作する携帯電話網や、無線ＬＡＮ（Local Area Network）等が用いられる。

アプリケーション分割装置１は、一実施形態に係るアプリケーション分割装置であり、システム管理者等が操作可能なサーバコンピュータやパーソナルコンピュータである。

図２は、図１に示したアプリケーション分割装置１の機能構成を示すブロック図である。
アプリケーション分割装置１は、通信インタフェースユニット１１と、処理ユニット１２と、記憶ユニット１３とを備えている。

通信インタフェースユニット１１は、例えば有線または無線インタフェースを有しており、通信ネットワークＮＷを介して、クラウド上に配置されたアプリケーション（アプリ）管理サーバ（図示省略）およびエッジサーバＥＳＶとの間での情報の送受信を可能にする。なお、アプリ管理サーバの機能とアプリケーション分割装置１の機能が１つのクラウドコンピュータに設けられる構成であってもよい。

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

判定ルール記憶部１３１は、開発者が定義した関数をさらに分割可能か否かを判定する際に使用される判定ルールを記憶する。判定ルールについては後に詳しく説明する。

エッジサーバ情報記憶部１３２は、位置情報や動作環境、処理性能など、エッジサーバＥＳＶに関する情報を記憶する。

なお、判定ルール記憶部１３１と、エッジサーバ情報記憶部１３２は、必ずしもアプリケーション分割装置１に内蔵されたものでなくてもよく、例えばクラウドに配置されたアプリ管理サーバやデータベースサーバ等の外部の記憶装置に設けられたものでもよい。この場合アプリケーション分割装置１は、通信ネットワークＮＷを介して上記クラウドのデータベースサーバ等にアクセスすることにより、必要なデータを取得し使用する。

処理ユニット１２は、図示しないＣＰＵ（Central Processing Unit）等のハードウェアプロセッサと作業用メモリとを有し、この実施形態を実施する上で必要な処理機能として、ソースコード取得部１２１と、ソースコード分割部１２２と、判定部１２３と、関数分割部１２４と、分散配置部１２５とを備える。これらの制御機能は、上記記憶ユニット１３のプログラム記憶部に格納されたプログラムを上記ハードウェアプロセッサに実行させることにより実現される。

ソースコード取得部１２１は、例えばアプリ管理サーバから分散処理の対象となるアプリケーションのソースコードを取得する。

ソースコード分割部１２２は、取得されたソースコード内で定義される複数の関数を識別し、ソースコードを複数の関数に分割する。

判定部１２３は、分割された関数の各々について、判定ルール記憶部１３１に記憶された判定ルールに従い、さらに分割可能な箇所があるか否かを判定する。

関数分割部１２４は、関数にさらに分割可能な箇所があると判定された場合に、その関数を分割可能な箇所で複数のロジック（関数）へと分割する。このときの分割単位はソースコードの行となる。

分散配置部１２５は、性能計測部１２５１と、配置決定部１２５２とを備える。

性能計測部１２５１は、分散処理の対象となる関数の各々に関し、動作環境における性能を計測する。

配置決定部１２５２は、計測された性能と、エッジサーバ情報記憶部１３２に記憶された各エッジサーバの配置位置や処理性能等を表す情報を含む属性情報に基づいて、要求される性能が最も高くなるロジック（関数）の配置を決定する。

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

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

（２）ソースコードの取得
アプリケーション分割装置１は、ステップＳ３１において、ソースコード取得部１２１の制御の下、例えばアプリ管理サーバから分散処理の対象であるアプリケーションのソースコードを取得する。なお、アプリケーションのソースコードを、アプリ開発者またはシステム管理者が使用する管理用端末から取得するようにしてもよい。

（３）ソースコードを関数に分割
アプリケーション分割装置１は、ステップＳ３２において、ソースコード分割部１２２の制御の下、ソースコード内で定義される複数の関数を識別し、ソースコードを複数の関数に分割する。

（４）行ごとの分割可否の判定
アプリケーション分割装置１は、ステップＳ３３において、分割された関数の各々について、複数の行を含むか否かを判定する。関数が１行の処理からなる場合、さらなる分割は実行されず、ステップＳ３７に移行する。関数が複数の行を含む場合、ステップＳ３４に移行する。

アプリケーション分割装置１は、ステップＳ３４において、判定部１２３の制御の下、分割された関数の各々について、判定ルール記憶部１３１に記憶された判定ルールに従い、さらに行ごとに分割可能か否かを判定する。

（４−１）判定ルール
ここで、アプリケーションを異なるマシンに分散配置することを前提として、関数を行単位の処理に分割しようとする場合、関数は単純に１行ごとに分割することができない。これは、ソースコード内に分割が可能な箇所と不可能な箇所が存在するためである。例えば図５において、図中左のｆｏｒ文を図のように分割し、上の処理から順番に実行したとすると、Ｌ２の処理とＬ３の処理の実行順序が変わってしまい、ａ［ｉ］に格納される数値が変わってしまう。これはＬ３の出力データがＬ２の入力データになっている（データ依存関係にある）ためである。このような分割は、元の関数の出力結果、ひいてはアプリケーション全体の動作を変えてしまいかねないため、行うべきではない。また、ｉｆ文やｂｒｅａｋ文など、当該処理の結果によって、それ以降の処理を実行するか否かが決まる処理、つまり制御依存関係にある処理も、実行順序が逆転するとアプリケーションの動作が変わってしまう場合があるため、分割時には注意する必要がある。

さらに、処理間でやり取りされるデータの型も、行単位の分割が困難な場所を形成している。これは、異なるマシン間で送信できるように、つまり直列化できるように標準設定されているデータ型と、これが標準設定されていないデータ型とがあるためである。直列化が標準設定されていないデータ型については、処理を追加することによって直列化することは不可能ではない。しかし、一般に公開されているライブラリ内のデータ型などの他の開発者が定義したデータ型については、開発言語によっては、ライブラリ自体がコンパイルされており、直列化のための処理の追加が非常に困難な場合がある。

このような条件に対応するため、この発明の一実施形態では、関数の分割における３つのルール（判定ルール）を定義した。
ルール１） 互いにデータ依存関係および制御依存関係がない２つの処理は分割可能
ルール２） 互いにデータ依存関係または制御依存関係にある２つの処理において、分割による実行順序の逆転がなければ、その処理は分割可能
ルール３） 互いにデータ依存関係にある２つの処理において、直列化および直列化復元が標準設定されているデータ型で依存している場合、その処理は分割可能
上記ルールを用いることによって、開発者が定義した関数を、異なるマシンに配置できる形で、かつアプリケーション全体の動作を変えることなく分割することができる。

（４−２）判定フロー
図４は、図３のステップＳ３４において判定部１２３により実行される判定処理の一例を示すフローチャートである。判定部１２３は、上記判定ルールに従い、２つの処理が分割可能か否かを判定することにより、各関数について、さらに分割可能な箇所を識別する。

先ずステップＳ３４１において、判定部１２３は、２つの処理の間にデータ依存関係があるか否かを判定する。データ依存関係があると判定された場合、ステップＳ３４２に移行する。

ステップＳ３４２において、判定部１２３は、２つの処理の間のデータ依存関係が、標準で直列化可能なデータによるものであるか否かを判定する。データ依存関係が標準で直列化可能なデータによるものであると判定された場合、ステップＳ３４３に移行する。

ステップＳ３４３において、判定部１２３は、２つの処理を分割したときに実行順序の逆転があるか否かを判定する。実行順序の逆転がないと判定された場合、ステップＳ３４４に移行し、２つの処理が分割可能と判定し、判定を終了する。一方、ステップＳ３４３において、実行順序の逆転があると判定された場合、判定部１２３は、ステップＳ３４５に移行し、２つの処理が分割不可能と判定し、判定を終了する。

ステップＳ３４２において、２つの処理の間のデータ依存関係が、標準で直列化可能なデータによるものでないと判定された場合、判定部１２３は、ステップＳ３４５に移行し、２つの処理が分割不可能と判定し、判定を終了する。

ステップＳ３４１において、２つの処理の間にデータ依存関係がないと判定された場合、判定部１２３は、ステップＳ３４６に移行し、２つの処理の間に制御依存関係があるか否かを判定する。制御依存関係があると判定された場合、判定部１２３は、ステップＳ３４３に移行し、前述したように、２つの処理を分割したときに実行順序の逆転があるか否かを判定する。一方、ステップＳ３４６において、制御依存関係がないと判定された場合、判定部１２３は、ステップＳ３４４に移行し、２つの処理が分割可能と判定し、判定を終了する。

判定部１２３は、判定対象の関数について、分割可能な箇所と分割不可能な箇所とを識別するため、上記判定処理を繰り返し実行する。

（５）関数の分割
アプリケーション分割装置１は、ステップＳ３５において、ステップＳ３４の判定結果を受け取り、対象の関数について分割可能な箇所があったか否かを判定する。分割可能な箇所があった場合、アプリケーション分割装置１は、ステップＳ３６に移行して、関数分割部１２４の制御の下、分割可能な箇所で関数をさらに複数の関数へと分割する。ステップＳ３５において、分割可能な箇所がないと判定された場合、ステップＳ３６をスキップしてステップＳ３７に移行する。

アプリケーション分割装置１は、ステップＳ３７において、取得されたソースコード内で定義されるすべての関数についてさらなる分割の可否の判定（および分割可能な場合には分割処理）が行われたか否かを判定する。すべての関数について判定が終了していないと判定された場合、ステップＳ３３に戻り、判定が終了していない関数についてステップＳ３３〜Ｓ３６の処理を繰り返す。ステップＳ３７において、すべての関数について判定が終了したと判定された場合、ステップＳ３８に移行する。

（６）ロジック（関数）の配置の決定
次いで、アプリケーション分割装置１は、ステップＳ３８において、分散配置部１２５の制御の下、アプリケーションを複数のマシンで分散的に動作させるため、各マシンへの関数の最適な分散配置を決定する。すなわち、アプリケーションのソースコード内で定義されたすべての関数について、ステップＳ３６において複数の関数へと分割された関数は分割後の関数ごとに、分割されなかった関数はその関数ごとに、要求される性能を最大化できる配置先マシンを決定する。

図６は、一実施形態に係るアプリケーション分割装置１による関数の分割および配置のイメージを示す図である。ここでは、関数Ａが４行の処理から成り、その他の関数が１行の処理から成るケースを想定して説明する。まず、通信ネットワークＮＷ等を介してアプリケーションＰのソースコードが取得され、アプリケーションＰのソースコード内で定義されている関数がそれぞれ１つのロジックとして分割される。その後、各関数について各行の処理を異なる関数として分割し、これらの関数に対して、要求される性能を最大化できる配置先マシンを決定する。そのため図６に示した例では、関数Ａがさらに４つの関数（関数ａ１〜ａ４）に分割され、それぞれが異なるマシンに配置されている。このように、一実施形態では、開発者が定義した関数（関数Ａ）がさらに複数のロジック（関数ａ１〜ａ４）に分割され、複数のマシンに分散配置される。

図７は、一実施形態に係るアプリケーション分割装置１による関数の分割および配置フローの一例を示す図である。まず、ステップＳ７１において、ソースコード分割部により、取得されたソースコード中の関数が識別され（ステップＳ７１１）、ソースコードが関数ごとに分割される（図６における関数Ａ，Ｂ，Ｃ）。これらが関数分割部に出力され、ステップＳ７２において、関数分割部により、関数内の処理間のデータ依存関係および制御依存関係が解析される（ステップＳ７２１）。その後、解析結果に対して上述のルールが適用され（ステップＳ７２２）、分割可能箇所が識別される。得られた分割可能箇所に基づいて、各関数（図６における関数Ａ）が、複数の関数（図６における関数ａ１〜ａ４）として分割される（ステップＳ７２３）。こうして、ソースコードが関数（ロジック）ごとに分割される。

次いで、ステップＳ７３において、性能計測部により、動作環境における各関数の性能が計測される。例えば、マシンＺ上での処理時間を計測する場合、各関数をマシンＺ上で複数回動作させ、処理終了までに要した平均時間をその関数の処理時間、すなわちマシンＺ上での性能値のひとつとする。このようにして得られた性能値、およびマシン間のネットワーク遅延や各マシンのメモリなどの動作環境情報をもとに、ステップＳ７４において、配置決定部により、上述したような線形計画問題をはじめとする最適化問題を解くことによって、要求される性能が最も高くなるロジックの配置が計算される。

例えば、各関数の入出力データ量、各配置先候補のマシン上での処理時間、マシン間のネットワーク遅延をもとに、「５００ミリ秒以内の処理時間になる配置の中で、最もマシン間のトラヒックが小さくなる配置」が計算される。また、他の例として、各関数の入出力データ量、各関数の各配置先候補のマシン上でのメモリ使用量、各マシンのメモリをもとに、「各マシン上でのメモリ使用量が７０％を超えない配置の中で、最もマシン間のトラヒックが小さくなる配置」を計算することも考えられる。

（７）システムの検証
一実施形態に係るアプリケーション分割装置１によりアプリケーションが分散配置されたシステムの有効性を確認するために、例えば、インターネットのＧｉｔｈｕｂ．ｃｏｍ（https://github.com/MinhasKamal/GenderRecognizer）で公開されている顔認識アプリケーションを用い、以下の環境を想定して比較検証を行った。
（ｉ）スマートフォンやノートＰＣなどのユーザ端末と、クラウドの、２種類のマシンが存在する。
（ｉｉ）ユーザ端末が所持している画像に対して顔認識を行い、性別情報が付与された顔の写真のみをクラウド上に保存する。（そのため、顔の写真をマシン上に出力する処理はクラウドを想定したマシン以外には配置できないという条件がある。）
（ｉｉｉ）最大化するアプリケーション性能は、ユーザ端末とクラウドとの間の、アプリケーション層におけるトラヒックとする。
（ｉｖ）顔認識を行う対象は、２５人の人物が写っている集合写真（４２３［ＫＢ］）とする。

ここで、上記顔認識アプリケーションのソースコードでは、主に以下の関数が定義されている。
（関数１）ｓｎｉｐＦａｃｅ関数：顔検出を行い、写真からその部分だけ切り取る。
（関数２）ｐｒｅｄｉｃｔ関数：入力された顔写真に写っている人が、男性か女性かを認識する。
（関数３）ｍａｉｎ関数：ｓｎｉｐＦａｃｅ関数を呼び出して顔写真の枚数をカウントし、すべての顔写真に対してＰｒｅｄｉｃｔ関数を呼び出し、その結果を顔写真に付与してマシン上に出力する。

従来技術を用いた場合、上記の各関数を１つのロジックとして分割したソースコードが出力される。しかし、画像をマシン上に出力する処理をクラウドにしか配置できない状況では、ｍａｉｎ関数をクラウド上にしか配置できなくなるため、配置決定部において、すべての関数をクラウド上に配置する組み合わせが最もトラヒックが小さくなると算出される。この場合、ユーザ端末とクラウドとの間のトラヒックは集合写真サイズの４２３［ＫＢ］となる。

一方、一実施形態を用いた場合、従来技術と同様に関数を識別した後、関数分割部において、各関数を行単位に分割するため、従来技術ではボトルネックとなっていたｍａｉｎ関数を、各関数を呼び出す関数群と、顔の写真をマシン上に出力する関数とに分割できる。このため、配置決定部において、ｓｎｉｐＦａｃｅ関数およびｓｎｉｐＦａｃｅ関数を呼び出して顔写真の枚数をカウントする関数をユーザ端末に配置し、その他の関数をクラウドに配置する組み合わせが最もトラヒックが小さくなると算出される。この場合、ユーザ端末とクラウドとの間のトラヒックは、顔写真の合計サイズ、およびその枚数情報のサイズを加算した７１［ＫＢ］となり、従来技術と比較して８５％のトラヒック削減が可能となる。

このように、一実施形態に係るアプリケーション分割装置１を用いると、関数単位で分割を行うよりも詳細な条件下で最適化できる。さらに、開発者が定義した関数をさらに細かく分割するため、すべての処理がひとつの関数に書かれているソースコードのような、細かく関数が分かれていないものに対しても、アプリケーション性能を最大化できるアプリケーション分割および配置を行うことができる。そのため、開発者は関数間で受け渡しされるデータ量や各関数の処理時間などの性能を意識することなく開発できるようになる。

（効果）
以上詳述したように、この発明の一実施形態では、アプリケーションのソースコードが取得され、該ソースコード内で定義される複数の関数が識別され、該ソースコードが先ず複数の関数に分割される。そして、分割された関数の各々について、あらかじめ設定された判定ルールに従い、さらに行単位で分割可能か否かが判定され、行単位で分割可能であると判定された場合、関数がさらに行単位で複数のロジック（関数）へと分割される。

したがって、一実施形態によれば、開発者による関数定義に依存せず、取得されたソースコード内で定義される関数をさらに行単位のロジックへと分割することができる。すなわち、分散アプリケーションの開発時に開発者に不要な負担をしいることなく、開発者が定義した関数を、異なるマシンに配置できる形で、かつアプリケーション全体の動作を変えることなく、分割することができる。

また、一実施形態によれば、分割された関数の各々が複数のマシンＸ，Ｙ，Ｚに割り当てられる。これにより、開発者による関数定義に依存せず、より細分化された関数を用いて、アプリケーションのより効率的な分散処理を実現することができる。

また、一実施形態によれば、ソースコード内で定義される複数の関数のうち、分割されていない関数については関数ごとに、分割された関数については分割後の関数ごとに、複数のマシンＸ，Ｙ，Ｚへの最適な分散配置が決定される。これにより、アプリケーションの分散処理にあたり、各関数の配置先について、より細分化された関数を用いて最適化問題を解くことができ、より良いアプリケーション性能を達成することができる。また、アプリケーションの分割処理から、分割された複数のロジックを複数のマシンＸ，Ｙ，Ｚに分散配置する処理までを、開発者またはシステムの運用者の操作に依存せずに自動的に行うことが可能となる。

また、一実施形態によれば、ルール１に従い、２つの処理の間にデータ依存関係および制御依存関係が存在しないと判定されたことに基づいて、当該２つの処理が分割可能であると判定される。これにより、開発者による関数定義に依存せず、処理間の依存関係の有無を判定するという簡潔な手法で、関数をさらに行単位の処理に分割可能か否か判定することができる。

また、一実施形態によれば、ルール２に従い、２つの処理の間にデータ依存関係または制御依存関係が存在するが２つの処理を分割した場合に実行順序の逆転がないと判定されたことに基づいて、当該２つの処理が分割可能であると判定される。これにより、開発者による関数定義に依存せず、実行順序の逆転の有無を判定するという簡潔な手法で、データ依存関係または制御依存関係が存在する場合でも関数をさらに行単位の処理に分割可能か否かを判定することができる。

また、一実施形態によれば、ルール３に従い、２つの処理が、直列化および直列化復元可能に標準設定されていないデータ型によるデータ依存関係があると判定されたことに基づいて、当該２つの処理が分割可能でないと判定される。これにより、開発者による関数定義に依存せず、２つの処理間にデータ依存関係がある場合にも、データ依存関係に関与するデータの型に基づいて、関数をさらに行単位の処理に分割可能か否かを判定することができる。

開発者が定義した関数がアプリケーション性能を最大化する上で最適な形になっていない場合（例えば、すべての処理を１つの関数の中に記述した場合など）、従来技術では、アプリケーション性能を最大化できるアプリケーション分割および配置を行うことは不可能であった。そのような場合にも、一実施形態によれば、上記のように、開発者が定義した関数をさらに行単位の処理に分割し、それらの処理群に対して、性能を最大化できる処理の配置を計算することで、開発者による関数定義に依存しない最適なアプリケーション分割と配置を決定することができる。

また開発者が、関数間で受け渡しされるデータ量や各関数の処理時間などの性能指標を意識せずに開発したとしても、一実施形態に係る発明の適用によって、アプリケーション性能を最大化できるアプリケーション分割および配置を計算できるため、分散アプリケーション開発時の開発者の負担が減少する。

開発者が定義した関数を分割する際に、単純に１行ごとの処理に分割してしまうと、アプリケーションの動作が変わってしまう可能性があるため、分散処理を正しく行えないという問題がある。そのような問題についても、一実施形態によれば、実行順序、データ依存関係、制御依存関係、およびデータの型を考慮したルールを設定し、分割してもアプリケーションの動作が変わらない箇所と、動作が変わる箇所を識別することによって解消することができた。これにより、開発者による関数定義に依存せず、開発者が定義した関数を、異なるマシンに配置できる形で、かつアプリケーション全体の動作を変えることなく分割することができる。

［他の実施形態］
なお、この発明は上記実施形態に限定されるものではない。
例えば、図１に示した実施形態では、エッジサーバＥＳＶ１，ＥＳＶ２，…ＥＳＶｉがアプリケーションの分散処理を担うものとして説明したが、図６に例示されるように、分割されたアプリケーションロジックがアプリケーションを利用するユーザ端末ＵＴ上で実行されるものとすることもできる。同様に、分割されたアプリケーションロジックがクラウド上で実行されることもできる。

また、ユーザ端末ＵＴは必ずしもエッジサーバＥＳＶを経由してアプリケーションを利用しなければならないわけではなく、インターネットを通じてクラウド上に配置されたアプリケーションを利用することも可能である。

その他、ルール１〜３の判定順序についても、図示したフローに限定されるものではなく、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。

要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１…アプリケーション分割装置、１１…通信インタフェースユニット、１２…処理ユニット、１３…記憶ユニット、１２１…ソースコード取得部、１２２…ソースコード分割部、１２３…判定部、１２４…関数分割部、１２５…分散配置部、１３１…判定ルール記憶部、１３２…エッジサーバ情報記憶部、１２５１…性能計測部、１２５２…配置決定部。

Claims (7)

1. 複数の情報処理装置によって分散処理されるアプリケーションを複数のロジックに分割するアプリケーション分割装置であって、
   前記アプリケーションのソースコードを取得する取得部と、
   前記ソースコード内で定義される複数の関数を識別し、前記ソースコードを前記複数の関数に分割する第１の分割部と、
   分割された前記関数の各々について、あらかじめ設定されたルールに従い、さらに分割可能か否かを判定する判定部と、
   分割可能であると判定された場合、前記関数を１または複数の行を含む複数の関数に分割する第２の分割部と、
   前記第１の分割部および前記第２の分割部により分割された複数の関数を前記複数の情報処理装置に割り当てる分散配置部と
   を具備するアプリケーション分割装置。
2. 前記分散配置部は、
   前記ソースコード内で定義される複数の関数のうち、前記第２の分割部により分割されていない関数については関数単位で、前記第２の分割部により分割された関数については分割後の関数単位で、前記複数の情報処理装置への最適な分散配置を決定する配置決定部を備える、請求項１に記載のアプリケーション分割装置。
3. 前記判定部は、前記ルールに従い、２つの処理の間にデータ依存関係および制御依存関係が存在しないと判定されたことに基づいて、前記２つの処理が分割可能であると判定する、請求項１に記載のアプリケーション分割装置。
4. 前記判定部は、前記ルールに従い、２つの処理の間にデータ依存関係または制御依存関係が存在するが前記２つの処理を分割した場合に実行順序の逆転がないと判定されたことに基づいて、前記２つの処理が分割可能であると判定する、請求項１に記載のアプリケーション分割装置。
5. 前記判定部は、前記ルールに従い、２つの処理が、直列化および直列化復元可能に標準設定されていないデータ型によるデータ依存関係があると判定されたことに基づいて、前記２つの処理が分割可能でないと判定する、請求項１に記載のアプリケーション分割装置。
6. 複数の情報処理装置によって分散処理されるアプリケーションを複数のロジックに分割するアプリケーション分割装置が実行する、アプリケーション分割方法であって、
   前記アプリケーションのソースコードを取得する過程と、
   前記ソースコード内で定義される複数の関数を識別し、前記ソースコードを前記複数の関数に分割する第１の分割過程と、
   分割された前記関数の各々について、あらかじめ設定されたルールに従い、さらに分割可能か否かを判定する過程と、
   分割可能であると判定された場合、前記関数を１または複数の行を含む複数の関数に分割する第２の分割過程と、
   前記第１の分割過程および前記第２の分割過程において分割された複数の関数を前記複数の情報処理装置に割り当てる過程と
   を具備するアプリケーション分割方法。
7. 請求項１乃至請求項５のいずれかに記載の装置の各部による処理をプロセッサに実行させるプログラム。