WO2020171234A1

WO2020171234A1 - オフロードサーバのソフトウェア最適配置方法およびプログラム

Info

Publication number: WO2020171234A1
Application number: PCT/JP2020/007255
Authority: WO
Inventors: 山登　庸次
Original assignee: 日本電信電話株式会社
Priority date: 2019-02-22
Filing date: 2020-02-21
Publication date: 2020-08-27
Also published as: JP2020137017A; US20220188086A1; US11614927B2; JP7063289B2

Abstract

【課題】アプリケーションを環境に合わせて適応させるとともに、高性能にアプリケーションを動作させる。【解決手段】配置先環境に合わせたコード変換をするオフロードパターン作成部１１５と、コード変換されたアプリケーションをコンパイルして、検証用マシン１４に配置し、検証用マシン１４にオフロードした際の性能測定用処理を実行する検証環境用性能測定部１１９と、を反復し、実行ファイル配置後、本番環境性能測定テスト抽出部１２２が抽出した性能試験項目を、運用装置１５を用いて自動実行する本番環境性能測定テスト実行部１２３と、コード変換ステップ、リソース量設定ステップ、配置場所選択ステップ、性能測定ステップ、性能測定テストステップのいずれか一つ以上のステップを実行する環境適応処理を行う制御部１１と、を備える。

Description

オフロードサーバのソフトウェア最適配置方法およびプログラム

　本発明は、機能処理をＧＰＵ（Graphics Processing Unit）等のアクセラレータに自動オフロードするオフロードサーバのソフトウェア最適配置方法およびプログラムに関する。

　近年、ＩｏＴ（Internet of Things）技術が進展しており、デバイス側で収集したデータをネットワークを介してクラウド技術を用いて分析し可視化するといったアプリケーションが続々と出現している。
　従来ＩｏＴのサービスは、デバイスからネットワーク、アプリケーションまで一体構築されたサイロ型が多かった。しかし、よりコストを下げ多様なサービスを提供するため、デバイスを複数アプリケーションで共有し、クラウド、ネットワーク、デバイスのリソースをダイナミックに連携してサービス化するOpenＩｏＴの概念が注目されている。

　OpenＩｏＴでは、街中の複数団体が持つ監視カメラを共有し、迷子の探索やテロリストの発見等、複数の用途に使うことが期待される。しかし、この例で、カメラ映像の画像処理を複数の用途で用いることは、デバイス側、クラウド側のどこで分析するとしても、ＣＰＵ計算リソースが膨大になる。

　一方、近年、ＩｏＴ等多彩な分野に対応するため、ＣＰＵ以外のヘテロな計算リソースを用いることが増えている。例えば、ＧＰＵ（Graphics Processing Unit）(アクセラレータ)を強化したサーバで画像処理を行ったり、ＦＰＧＡ（Field Programmable Gate Array）(アクセラレータ)で信号処理をアクセラレートすることが始まっている。Amazon Web Services (AWS)（登録商標）では、ＧＰＵインスタンス、ＦＰＧＡインスタンスが提供されており、オンデマンドにそれらリソースを使うこともできる。Microsoft（登録商標）は、ＦＰＧＡを用いて検索を効率化している。

　OpenＩｏＴ環境では、サービス連携技術等を用いて、多彩なアプリケーションの創出が期待されるが、更に進歩したハードウェアを生かすことで、動作アプリケーションの高性能化が期待できる。しかし、そのためには、動作させるハードウェアに合わせたプログラミングや設定が必要である。例えば、ＣＵＤＡ（Compute Unified Device Architecture）、 OpenＣＬ（Open Computing Language）といった多くの技術知識が求められ、ハードルは高い。

　ＧＰＵやＦＰＧＡをユーザのＩｏＴアプリケーションで容易に利用できるようにするため下記が求められる。すなわち、動作させる画像処理、暗号処理等の汎用アプリケーションをOpenＩｏＴ環境にデプロイする際に、OpenＩｏＴのプラットフォームがアプリケーションロジックを分析し、ＧＰＵ、ＦＰＧＡに自動で処理をオフロードすることが望まれる。

（ＧＰＵへのオフロード）
　ＧＰＵの計算能力を画像処理以外にも使うＧＰＧＰＵ（General Purpose GPU）のための開発環境ＣＵＤＡが発展している。ＣＵＤＡは、ＧＰＧＰＵ向けの開発環境である。また、ＧＰＵ、ＦＰＧＡ、メニーコアＣＰＵ等のヘテロハードウェアを統一的に扱うための標準規格としてOpenＣＬも登場している。

　ＣＵＤＡやOpenＣＬでは、Ｃ言語の拡張によるプログラミングを行う。ただし、ＧＰＵ等のデバイスとＣＰＵの間のメモリコピー、解放等を記述する必要があり、記述の難度は高い。実際に、ＣＵＤＡやOpenＣＬを使いこなせる技術者は数多くはいない。

　簡易にＧＰＧＰＵを行うため、ディレクティブベースで、ループ文等の並列処理すべき個所を指定し、ディレクティブに従いコンパイラがデバイス向けコードに変換する技術がある。技術仕様としてOpenＡＣＣ（Open Accelerator）等、コンパイラとしてＰＧＩコンパイラ（登録商標）等がある。例えば、OpenＡＣＣを使った例では、ユーザはC/C++/Fortran言語で書かれたコードに、OpenＡＣＣディレクティブで並列処理させる等を指定する。ＰＧＩコンパイラは、コードの並列可能性をチェックして、ＧＰＵ用、ＣＰＵ用実行バイナリを生成し、実行モジュール化する。IBM JDK（登録商標）は、Java（登録商標）のlambda形式に従った並列処理指定を、ＧＰＵにオフロードする機能をサポートしている。これらの技術を用いることで、ＧＰＵメモリへのデータ割り当て等を、プログラマーは意識する必要がない。

　このように、OpenＣＬ、ＣＵＤＡ、OpenＡＣＣ等の技術により、ＧＰＵへのオフロード処理が可能になっている。
　しかし、ＧＰＵ処理は行えるようになっても、高速化には課題が多い。マルチコアＣＰＵ向けには、例えば、Intelコンパイラ（登録商標）等の自動並列化機能を持つコンパイラがある。自動並列化時は、プログラム上のfor文（繰り返し文）等の並列可能部を抽出するが、ＧＰＵを用いる場合は、ＣＰＵ-ＧＰＵメモリ間のデータ転送オーバヘッドのため性能が出ないことも多い。ＧＰＵを用いて高速化する際は、スキル者が、ＣＵＤＡでのチューニングや、ＰＧＩ（登録商標）コンパイラ等で適切な並列処理部を探索することが必要になっている（非特許文献１参照）。
　このため、スキルが無いユーザがＧＰＵやＦＰＧＡを使ってアプリケーションを高性能化することは難しいし、自動並列化技術等を使う場合も並列処理可否の試行錯誤や高速化できない場合があった。

　ＩｏＴデバイスに関しては、計算リソース等が限られているＩｏＴデバイスでは、細かい制御を行う際は、アセンブリ等の組み込みソフトウェアの知識が必要になるのが現状である。Rasberry Pi（登録商標）等のシングルボードコンピュータでは、リソース量は限られるものの、Linux（登録商標）やJava等が動作するため、Rasberry PiをＧＷ（gateway）として複数のＩｏＴデバイスからデータを収集したり制御したりする等の自由度が開発者に出てくる。しかし、ＩｏＴデバイスを何台収容するかや、ＩｏＴデバイスとシングルボードコンピュータでどのように処理を分担するか等は、アプリケーション、利用形態によって異なり、環境に合わせた設計が必要である。

Y. Yamato, T. Demizu, H. Noguchi and M. Kataoka, "Automatic GPU Offloading Technology for Open IoT Environment," IEEE Internet of Things Journal, DOI: 10.1109/JIOT.2018.2872545, Sep. 2018. K. Shirahata, H. Sato and S. Matsuoka, "Hybrid Map Task Scheduling for GPU-Based Heterogeneous Clusters,"IEEE Second International Conference on Cloud Computing Technology and Science (CloudCom), pp.733-740, Dec. 2010. Y. Yamato, "Automatic verification technology of software patches for user virtual environments on IaaS cloud," Journal of Cloud Computing, Springer, 2015, 4:4, DOI: 10.１１９6/s13677-015-0028-6, Feb. 2015. Y. Yamato, M. Muroi, K. Tanaka and M. Uchimura, "Development of Template Management Technology for Easy Deployment of Virtual Resources on OpenStack," Journal of Cloud Computing, Springer, 2014, 3:7, DOI: 10.１１９6/s13677-014-0007-3, June 2014. Y. Yamato, "Server Selection, Configuration and Reconfiguration Technology for IaaS Cloud with Multiple Server Types," Journal of Network and Systems Management, Springer, DOI: 10.1007/s10922-017-9418-z, Aug. 2017.

　近年、クラウドファーストという言葉もあるように、アプリケーションをクラウド等の事業者設備で動作させることは一般的となっている。その際に、ユーザはアプリケーションを低コストで高性能に運用することを求めている。アプリケーションを動作させる場合にコストや性能に大きく影響する点として以下の考慮が必要である。

　（１）まず、ＧＰＵやＦＰＧＡ等のアクセラレータを使う方が性能、コストで効果がある場合にそれらの利用が考えられる。勿論、通常のＣＰＵ向けに作られたコードではそれらのアクセラレータは使えないため、画像処理やＦＦＴ（Fast Fourier Transform）処理といった、ＧＰＵやＦＰＧＡに適した処理を、それらハードウェアにオフロードするコードに変換やライブラリ呼び出しを行う必要がある。コード変換は、ＩｏＴデバイスの制御等の処理を、Rasberry Piのようなシングルボードコンピュータに切り出して、配置する際も必要である。

　（２）動作させるアプリケーションのコードが決まると、どの程度のリソース量を確保するかの決定が必要である。例えば、ＣＰＵとＧＰＵで動作させるアプリケーションの場合に、ＣＰＵ処理が１０００秒で、ＧＰＵ処理が１秒等の場合は、仮想マシンのＣＰＵリソースを増強した方がシステムとして性能が出ることが期待できる。

　（３）アプリケーションを実行する場所も性能に影響する。例えば、ＩｏＴカメラの画像分析で不審者探索を０．５ｓｅｃ以内に行いたい場合に、クラウドまでデータを上げてから画像分析していては遅延が大きくなるので、カメラデータを集約するゲートウェイや、ＮＷの端点であるエッジサーバで画像分析することが必要になる等、処理場所の考慮が必要である。また、画像分析をエッジサーバで行い、不審者がいる場合だけ詳細画像をクラウドに送る場合でも、処理場所によって、計算量、通信トラフィックが変わるため、コストも変化する。

　（４）ハードウェアに合わせたコード変換、リソース量調整、配置場所調整が終わり、アプリケーションの運用を開始しても、運用中にリクエスト特性が大きく変わった場合など、開始当初の性能が保てなくなる場合がある。そういった際は、運用中に構成を変更することで、システムとしての性能、コストを改善することも考慮が必要である。

　このような点に鑑みて本発明がなされたのであり、アプリケーションを環境に合わせて適応させるとともに、高性能にアプリケーションを動作させることができるオフロードサーバのソフトウェア最適配置方法およびプログラムを提供することを課題とする。

　前記した課題を解決するため、請求項１に記載の発明は、アプリケーションの特定処理をアクセラレータにオフロードするオフロードサーバのソフトウェア最適配置方法であって、前記オフロードサーバは、アプリケーションのソースコードを分析するアプリケーションコード分析ステップと、前記アプリケーションの並列処理可能なループ文、特定処理の機能ブロック、ライブラリ呼び出しを含むオフロード可能な処理を特定するオフロード処理指定ステップと、配置先環境に合わせたコード変換をするコード変換ステップと、コード変換された前記アプリケーションをコンパイルして、アクセラレータ検証用装置に配置し、前記アクセラレータ検証用装置にオフロードした際の性能測定用処理を実行する検証環境用性能測定ステップと、を反復し、前記配置先環境に合わせたリソース量の設定を行うリソース量設定ステップと、前記コード変換ステップがコード変換した変換コードを、前記リソース量設定ステップが設定したリソース量を確保して配置する際に、性能およびコストをもとに配置先を計算して配置場所を選択する配置場所選択ステップと、本番環境配置後に、前記アプリケーションをコンパイルして、運用装置に配置し、前記運用装置にオフロードした実際の性能測定テストを実行する性能測定テストステップと、を備え、前記コード変換ステップ、前記リソース量設定ステップ、前記配置場所選択ステップ、前記検証環境用性能測定ステップ、前記性能測定テストステップのいずれか一つ以上のステップを実行することを特徴とするオフロードサーバのソフトウェア最適配置方法とした。

　このようにすることで、例えば、ＧＰＵ，ＦＰＧＡ，ＩｏＴデバイス等環境が多様になる中で、アプリケーションを環境に合わせて適応させとともに、ＧＰＵやＦＰＧＡを適切に活用し、高性能にアプリケーションを動作させることができる。また、一度記述したソフトウェアを、異なる環境でも高性能に動作させることができる。

　請求項２に記載の発明は、コンパイルエラーが出るループ文に対して、オフロード対象外とするとともに、コンパイルエラーが出ないループ文に対して、オフロード処理するかしないかの指定を行うオフロード処理パターンを作成するオフロードパターン作成ステップと、所定回数繰り返された、性能測定結果をもとに、複数のオフロードパターンから最高処理性能のオフロードパターンを選択し、最高処理性能のオフロードパターンをコンパイルして実行ファイルを作成する実行ファイル作成ステップと、をさらに有し、前記オフロード処理指定ステップにおいて、遺伝的アルゴリズムに基づき、コンパイルエラーが出ないループ文の数を遺伝子長とし、前記オフロードパターン作成ステップにおいて、アクセラレータ処理をする場合を１または０のいずれか一方、しない場合を他方の０または１として、アクセラレータ処理可否を遺伝子パターンにマッピングし、前記遺伝子の各値を１か０にランダムに作成した指定個体数の前記遺伝子パターンを準備し、前記性能測定ステップにおいて、各個体に応じて、前記アクセラレータにおける並列処理指定文を指定したアプリケーションコードをコンパイルして、前記アクセラレータ検証用装置に配置し、前記アクセラレータ検証用装置において性能測定用処理を実行し、前記実行ファイル作成ステップにおいて、全個体に対して、性能測定を行い、処理時間の短い個体ほど適合度が高くなるように評価し、全個体から、前記適合度が所定値より高いものを性能の高い個体として選択し、選択された個体に対して、交叉、突然変異の処理を行い、次世代の個体を作成し、指定世代数の処理終了後、最高性能の前記オフロードパターンを解として選択することを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法とした。

　このように、最初に並列可能なループ文のチェックを行い、次に並列可能繰り返し文群に対してＧＡ（Genetic Algorithm：遺伝的アルゴリズム）を用いて検証環境で性能検証試行を反復し適切な領域を探索する。並列可能なループ文（例えばfor文）に絞った上で、遺伝子の部分の形で、高速化可能なオフロードパターンを保持し組み換えていくことで、取り得る膨大なオフロードパターンから、効率的に高速化可能なパターンを探索できる。

　請求項３に記載の発明は、前記配置先環境が、前記アクセラレータとしてＦＰＧＡ（Field Programmable Gate Array）を備え、前記オフロード処理指定ステップにおいて、機能ブロック処理、ライブラリ呼び出しを含むアプリケーションの処理構造から、コードパターンＤＢを参照して、機能ブロック処理、ライブラリ呼び出しを含む前記ＦＰＧＡにオフロード可能な処理を特定し、前記コードパターンＤＢからオフロードに該当する中間言語の定義情報を、アプリケーションソースコードに置換することを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法とした。

　このようにすることで、機能ブロック処理、ライブラリ呼び出しを含むＦＰＧＡにオフロード可能な処理を特定して、アプリケーションソースコードに置換することができる。

　請求項４に記載の発明は、前記リソース量設定ステップにおいて、アプリケーションテストケースの処理時間から、ＣＰＵとオフロード先の処理時間が同等のオーダーになるように、ＣＰＵとオフロード先のリソース比を定め、前記リソース比の決定後は、想定するテストケースの処理性能が、要求性能およびコスト要求を満たすように前記リソース比はキープしつつ、リソース量を設定することを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法とした。

　このように、ＣＰＵとオフロード先のリソース比を定めて、要求性能およびコスト要求を満たした上で、リソース量を設定することができる。

　請求項５に記載の発明は、前記配置場所選択ステップにおいて、アプリケーションテストケースの結果から、アプリケーションを配置した際の計算量と発生トラフィックを算出し、クラウド、エッジ、Home ＧＷ（gateway）を含むリンク関係をモデル化し、アプリケーションを特定のノードに配置した際に、コストが要求条件に収まることを制約条件に、処理遅延および／またはスループットの性能を最大化する配置、あるいは性能が要求条件を満たす形でコストが最低になる配置のいずれかを計算することを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法とした。

　このようにすることで、処理遅延、スループットの性能の最大化、または性能が要求条件を満たす形でコストが最低になる配置場所を選択することができる。

　請求項６に記載の発明は、アプリケーション運用開始後に、当初期待していた性能が出ない場合に、ソフトウェア設定を再構成する再構成実行ステップを有し、前記再構成実行ステップにおいて、ソフトウェア設定の変更では、リソース量設定、配置場所選択の試行計算を周期的、または、性能がある閾値以下となった場合に試行模擬し、性能向上やコスト低減度合を計算し、リソース量の変更や配置場所の変更で性能やコストが改善できる見込みがある場合に、ユーザに再構成を提案し、ユーザ了承を得て、再構成を実行する場合に、リソースを変更する再構成先構築ステップと、配置場所変更の際、移行先環境を複製して、そこに移行元からアプリケーション実行環境をマイグレーションするマイグレーション処理ステップと、を実行することを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法とした。

　このようにすることで、ユーザに再構成を提案して、ユーザ了承を得た場合には、アプリケーション実行環境をマイグレーションすることができる。

　請求項７に記載の発明は、前記再構成実行ステップにおいて、コード変換処理を、周期的、または、性能がある閾値以下となった場合に試行模擬し、コード変換して、ＧＰＵオフロードのソフトロジック変更および／またはＦＰＧＡ（Field Programmable Gate Array）のハードロジックの変更で、性能やコストが改善できる見込みがある場合は、ユーザに再構成を提案し、ユーザ了承を得て、再構成を実行する際に、ＧＰＵオフロードするソフトロジックの変更を行い、ソフトウェア構成の変更の場合は、前記マイグレーション処理ステップが、更新する実行ファイルを起動する環境を複製後、アプリケーションのデータのマイグレーションを行い、ＦＰＧＡのハードロジックを変更する場合は、前記マイグレーション処理ステップにおいて、移行先にハードロジックを構成済みのＦＰＧＡを準備し当該ＦＰＧＡを制御するコンテナのマイグレーションを行う、もしくは、前記再構成実行ステップにおいて、当該ＦＰＧＡのハードロジックを再構成することを特徴とする請求項６に記載のオフロードサーバのソフトウェア最適配置方法とした。

　このようにすることで、ユーザに再構成を提案して、ユーザ了承を得た場合、ソフトウェア構成の変更のときは、アプリケーションのデータのマイグレーションを、またハードロジックを構成済みのＦＰＧＡを準備しＦＰＧＡを制御するコンテナ等をマイグレーションすることができる。

　請求項８に記載の発明は、コンピュータを、請求項１乃至請求項７のうちいずれか１項に記載のオフロードサーバとして機能させるためのオフロードプログラムとした。

　このようにすることにより、一般的なコンピュータを用いて、請求項１乃至請求項７のいずれか１項に記載のオフロードサーバの各機能を実現させることができる。

　本発明によれば、アプリケーションを環境に合わせて適応させるとともに、高性能にアプリケーションを動作させることができるオフロードサーバのソフトウェア最適配置方法およびプログラムを提供することができる。

本発明の実施形態に係るオフロードサーバを含むシステムを示す図である。上記実施形態に係るオフロードサーバの構成例を示す機能ブロック図である。上記実施形態に係るオフロードサーバのソフトウェア最適配置処理を示すフローチャートである。上記実施形態に係るオフロードサーバのＧＡを用いた自動オフロード処理を示す図である。上記実施形態に係るオフロードサーバのSimple GAによる制御部（環境適応機能部）の探索イメージを示す図である。上記実施形態に係るオフロードサーバのＣＰＵからＧＰＵへのデータ転送する場合のループ文において、ＣＰＵプログラム側で定義した変数とＧＰＵプログラム側で参照する変数が重なる場合の例を示す図である。上記実施形態に係るオフロードサーバのＧＰＵからＣＰＵへのデータ転送する場合のループ文において、ＣＰＵプログラム側で定義した変数とＧＰＵプログラム側で参照する変数が重なる場合の例を示す図である。上記実施形態に係るオフロードサーバの実装の動作概要を説明するフローチャートである。上記実施形態に係るオフロードサーバの実装の動作概要を説明するフローチャートである。

　次に、本発明を実施するための形態（以下、「本実施形態」と称する。）における、オフロードサーバ１等について説明する。
　図１は、本実施形態に係るオフロードサーバ１を含むシステムを示す図である。
　本実施形態に係るシステムは、オフロードサーバ１を含むことを特徴とする。オフロードサーバ１は、アプリケーションの特定処理をアクセラレータにオフロードするオフロードサーバである。また、オフロードサーバ１は、クラウドレイヤ２、ネットワークレイヤ３、デバイスレイヤ４の３層に位置する各装置と通信可能に接続される。クラウドレイヤ２にはデータセンタ（ＤＣ：data center）３０が、ネットワークレイヤ３にはネットワークエッジ２０が、デバイスレイヤ４にはゲートウェイ１０が、それぞれ配設される。

　そこで、本実施形態に係るオフロードサーバ１を含むシステムでは、デバイスレイヤ２、ネットワークレイヤ３、クラウドレイヤ４のそれぞれのレイヤにおいて、機能配置や処理オフロードを適切に行うことによる効率化を実現する。主に、機能を３レイヤの適切な場所に配置し処理させる機能配置効率化と、画像分析等の機能処理をＧＰＵやＦＰＧＡ等のヘテロハードウェアにオフロードすることでの効率化を図る。クラウドレイヤでは、ＧＰＵやＦＰＧＡ等のヘトロジニアスなＨＷ（ハードウェア）（以下、「ヘトロデバイス」と称する。）を備えたサーバが増えてきている。例えば、Microsoft（登録商標）社のBing検索においても、ＦＰＧＡが利用されている。このように、へトロデバイスを活用し、例えば、行列計算等をＧＰＵにオフロードしたり、ＦＦＴ（Fast Fourier Transform）計算等の特定処理をＦＰＧＡにオフロードしたりすることで、高性能化を実現している。

　以下、本実施形態に係るオフロードサーバ１が、ユーザ向けサービス利用のバックグラウンドで行うオフロード処理を行う際の構成例について説明する。

　図２は、本発明の実施形態に係るオフロードサーバ１の構成例を示す機能ブロック図である。
　オフロードサーバ１は、アプリケーションの特定処理をアクセラレータに自動的にオフロードする装置である。
　図２に示すように、オフロードサーバ１は、制御部１１と、入出力部１２と、記憶部１３と、検証用マシン１４（Verification machine）(アクセラレータ検証用装置)と、運用装置１５と、を含んで構成される。

　入出力部１２は、クラウドレイヤ２、ネットワークレイヤ３およびデバイスレイヤ４に属する各デバイス等との間で情報の送受信を行うための通信インタフェースと、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースとから構成される。

　記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等により構成される。
　この記憶部１３には、テストケースＤＢ（Test case database）１３１、コードパターンＤＢ１３２、および設備リソースＤＢ１３３が記憶されるとともに、制御部１１の各機能を実行させるためのプログラム（オフロードプログラム）や、制御部１１の処理に必要な情報（例えば、中間言語ファイル(Intermediate file)１３４）が一時的に記憶される。

　テストケースＤＢ１３１には、性能試験項目が格納される。テストケースＤＢ１３１は、性能試験項目に対応した、価格（例えば、ＩｏＴサービスの課金情報）、性能（アクセラレータの計算リソース）等のデータを格納する。

　コードパターンＤＢ１３２には、ＦＰＧＡにオフロード可能な処理のライブラリ呼び出しや機能ブロックと、オフロードするＦＰＧＡの処理ロジックをOpenCLやHDLで記述したコードを、登録している。

　設備リソースＤＢ１３３には、ネットワークやコンピュータの設備などのリソース情報を蓄積する。設備リソースＤＢ１３３を参照することで、ネットワークやコンピュータの設備などのリソースを割り当てることができる。また、分散システムや記憶装置等のリソースを仮想化技術によって一つのリソースとみなし、必要な時に必要な分だけオンデマンドでリソースを割り当てることができる。

　検証用マシン１４は、検証環境用としてのＣＰＵ・ＧＰＵ・ＦＰＧＡ(アクセラレータ)・ＩｏＴＧＷである。検証用マシン１４は、後記検証環境用性能測定部１１９が行う検証環境で、適切なコードパターン生成時の性能測定のために用いられる。

　運用装置１５は、本番環境としてのユーザ宅のHome ＧＷやそれがつながるエッジルータ等である。運用装置１５は、本番環境配置後に、後記本番環境性能測定テスト実行部１２３が実際にどのくらいの性能が出るかを見せる性能測定のために用いられる。

<制御部１１>
　制御部１１は、オフロードサーバ１全体の制御を司る環境適応機能部である。制御部１１は、例えば、記憶部１３に格納されたプログラム（オフロードプログラム）を不図示のＣＰＵ（Central Processing Unit）が、ＲＡＭに展開し実行することにより実現される。
　制御部１１は、アプリケーションコード指定部（Specify application code）１１１と、アプリケーションコード分析部（Analyze application code）１１２と、データ転送指定部１１３と、オフロード処理指定部１１４と、オフロードパターン作成部１１５（コード変換部）と、リソース量計算部１１６（リソース量設定部）と、リソース量指定部１１７（リソース量設定部）と、配置先計算部１１８（配置場所選択部）と、検証環境用性能測定部１１９と、実行ファイル作成部１２０と、本番環境配置部（Deploy final binary files to production environment）１２１と、本番環境性能測定テスト抽出実行部（Extract performance test cases）１２２と、本番環境性能測定テスト実行部（Run performance test cases automatically）１２３と、再構成必要性定期チェック部１２４と、再構成シミュレーション試算部１２５と、再構成実行部１２６と、ユーザ提供部（Provide price and performance to a user to judge）１２７と、を備える。

　制御部１１は、環境適応機能部として、後記する、コード変換ステップ、リソース量設定ステップ、配置場所選択ステップ、性能測定ステップ、性能測定テストステップのいずれか一つ以上のステップを実行する。

<アプリケーションコード指定部１１１>
　ユーザは動作させたいアプリケーションコードと利用を想定したテストケース、要望する性能とコストを、アプリケーションコード指定部１１１に指定する。アプリケーションコード指定部１１１は、入力されたアプリケーションコードの指定を行う。具体的には、アプリケーションコード指定部１１１は、ユーザに提供しているサービスの処理機能（画像分析等）を特定する。

<アプリケーションコード分析部１１２>
　アプリケーションコード分析部１１２は、アプリケーションのコードを分析するアプリケーションコード分析ステップを実行する。アプリケーションコード分析部１１２は、処理機能のソースコードを分析し、ループ文や変数の参照関係、処理する機能ブロック（ＦＦＴ：Fast Fourier Transform処理）等、コードの構造を把握する。

<データ転送指定部１１３>
　データ転送指定部１１３は、アプリケーションのループ文の中で用いられる変数の参照関係を分析し、ループ外でデータ転送してよいデータについては、ループ外でのデータ転送を明示的に指定する明示的指定行（#pragma acc data copyin/copyout/copy(a[…])　ただし、変数ａ）を用いたデータ転送指定を行う。

　データ転送指定部１１３は、ＣＰＵからＧＰＵへのデータ転送を明示的に指定する明示的指定行（#pragma acc data copyin (a[…])）と、ＧＰＵからＣＰＵへのデータ転送を明示的に指定する明示的指定行（#pragma acc data copyout (a[…])）と、同じ変数に関してＣＰＵからＧＰＵへの転送とＧＰＵからＣＰＵへの転送とが重なる場合、データコピーの往復をまとめて明示的に指定する明示的指定行（#pragma acc data copy(a[…])）と、を用いたデータ転送指定を行う。

　データ転送指定部１１３は、ＣＰＵプログラム側で定義した変数とＧＰＵプログラム側で参照する変数が重なる場合、ＣＰＵからＧＰＵへのデータ転送の指示を行い、データ転送を指定する位置を、ＧＰＵ処理するループ文かそれより上位のループ文で、該当変数の設定、定義を含まない最上位のループとする。また、データ転送指定部１１３は、ＧＰＵプログラム側で設定した変数とＣＰＵプログラム側で参照する変数とが重なる場合、ＧＰＵからＣＰＵへのデータ転送の指示を行い、データ転送を指定する位置を、ＧＰＵ処理するループ文か、それより上位のループ文で、該当変数の参照、設定、定義を含まない最上位のループとする。

<オフロード処理指定部１１４>
　オフロード処理指定部１１４は、アプリケーションのループ文（繰り返し文）や特定処理の機能ブロック、ライブラリ呼び出しを含むオフロード可能な処理を特定するオフロード処理指定ステップを実行し、各ループ文に対して、アクセラレータにおける並列処理指定文を指定してコンパイルする。
　具体的には、オフロード処理指定部１１４は、機能ブロック処理、ライブラリ呼び出しを含むアプリケーションの処理構造から、コードパターンＤＢ１３２を参照して、機能ブロック処理、ライブラリ呼び出しを含むＦＰＧＡにオフロード可能な処理を特定し、コードパターンＤＢからオフロードに該当する中間言語の定義情報を、アプリケーションソースコードに置換する。

　オフロード処理指定部１１４は、オフロード可能部抽出部（Extract offloadable area）１１４ａと、中間言語ファイル出力部（Output intermediate file）１１４ｂと、を備える。
　オフロード可能部抽出部１１４ａは、ループ文やＦＦＴ等、ＧＰＵ・ＦＰＧＡにオフロード可能な処理を特定し、オフロード処理に応じた中間言語を抽出する。オフロード可能部抽出部１１４ａは、アプリケーションコードの並列処理可能なループ文やＦＦＴ処理の機能ブロック、ライブラリ呼び出し等のオフロード可能な処理をコードパターンＤＢ１３２を参照して特定し、オフロード先に応じた中間言語（OpenCL等）を抽出する。

　中間言語ファイル出力部１１４ｂは、抽出した中間言語ファイル１３４を出力する。中間言語抽出は、一度で終わりでなく、適切なオフロード領域探索のため、実行を試行して最適化するため反復される。なお、中間言語抽出は一度で終わりでなく、適切なオフロード領域探索のため、実行試行して最適化するため反復（例えば、ＧＡの２０世代、１００回試行など）される。

<オフロードパターン作成部１１５>
　オフロードパターン作成部１１５は、配置先環境に合わせたコード変換であるコード変換ステップを実行する。本実施形態では、オフロードパターン作成部１１５は、コンパイルエラーが出るループ文（繰り返し文）に対して、オフロード対象外とするとともに、コンパイルエラーが出ない繰り返し文に対して、並列処理するかしないかの指定を行うオフロードパターンを作成するオフロードパターン作成ステップを実行する。

<リソース量計算部１１６>
　リソース量計算部１１６は、配置先環境に合わせたリソース量の設定を行う。具体的には、リソース量計算部１１６は、アプリケーションテストケースの処理時間から、ＣＰＵとオフロード先の処理時間が同等のオーダーになるように、ＣＰＵとオフロード先のリソース比を定め、前記リソース比を決定後は、想定するテストケースの処理性能が、要求性能およびコスト要求を満たすように前記リソース比はキープしつつ、リソース量を設定であるリソース量設定ステップを実行する。

　図４を参照して、リソース量計算部１１６の機能を説明する。リソース量計算部１１６は、図４のステップＳ２１，Ｓ２２のコードパターンを決定後、適切なリソース量の設定を行う。具体的には、図４のステップＳ２１，Ｓ２２の検証環境性能測定で取得される、想定するテストケースの処理時間の中で、ＣＰＵ処理時間とＧＰＵ等のＣＰＵ以外ハードウェアの処理時間を分析し、適切なリソース比を定める。上記リソース比は、ＣＰＵとＧＰＵ等ハードウェアの確保するリソースの比である。例えば、リソースの比は、ｖＣＰＵコア：仮想ＧＰＵ＝４：１が適切であるとする。次に、リソース量計算部１１６は、ユーザの要望する性能、コストと適切なリソース比を鑑みて、実際に確保するリソース量を定める。例えば、リソース量は、ｖＣＰＵコアが「８」で仮想ＧＰＵが「２」の場合、性能およびコストを満たす量であるとする。

　このように、リソース量計算部１１６は、まずリソース比を定め、その上でリソース比を鑑みて、実際に確保するリソース量を定める。これにより、ＣＰＵとオフロード先のリソース比を定めて、要求性能およびコスト要求を満たした上で、リソース量を設定することができる。

<リソース量指定部１１７>
　リソース量指定部１１７は、リソース量計算部１１６で計算したリソース量を実行ファイルに指定する。

<配置先計算部１１８>
　配置先計算部１１８は、オフロードパターン作成部１１５がコード変換した変換コードを、リソース量計算部１１６が計算したリソース量を確保して配置する際に、性能およびコストをもとに配置先を計算して配置場所を選択する配置場所選択ステップを実行する。
　具体的には、配置先計算部１１８は、アプリケーションテストケースの結果から、アプリケーションを配置した際の計算量と発生トラフィックを算出し、クラウド、エッジ、Home ＧＷを含むリンク関係をモデル化し、アプリケーションを特定のノードに配置した際に、コストが要求条件に収まることを制約条件に、処理遅延および／またはスループットの性能を最大化する配置、あるいは性能が要求条件を満たす形でコストが最低になる配置のいずれかを線形計画手法を用いて計算する。

　図４を参照して、配置先計算部１１８の機能を説明する。配置先計算部１１８は、図４のステップＳ２１，Ｓ２２で定めたコードパターン（図２のコードパターンＤＢ１３２に格納されている）の実行ファイルを、図４のステップＳ１４，Ｓ１５で定めたリソース量を確保して配置する際に、性能およびコストが適切になる場所を計算し配置先を決める。配置先計算部１１８は、実行するアプリケーションの想定するテストケースの特性、設備リソースＤＢ１３３（図２参照）の情報から、性能とコストが適切になる配置場所を計算する。
　例えば、ＩｏＴカメラの画像情報を分析して不審者を見つける処理を、０．５ｓｅｃ以内の遅延で行いたいような場合は、ＩｏＴカメラに近いエッジサーバを特定して、配置する。ここで、配置したい場所には、リソース量制限から、必要なリソースを確保できない場合等は、リソース量や場所を再調整するため、図４のステップＳ１４に処理を戻す場合がある。

<検証環境用性能測定部１１９>
　検証環境用性能測定部１１９は、オフロードパターンのアプリケーションをコンパイルして、検証用マシン１４に配置し、アクセラレータにオフロードした際の性能測定用処理である検証環境用性能測定ステップを実行する。
　検証環境用性能測定部１１９は、バイナリファイル配置部（Deploy binary files）１１６ａを備える。バイナリファイル配置部１１９ａは、検証環境用として、ＧＰＵやＦＰＧＡ、ＩｏＴデバイス用ＧＷ等を備えた検証環境用である検証用マシン１４に、中間言語から導かれる実行ファイルをデプロイ(配置)する。

　検証環境用性能測定部１１９は、ＧＰＵやＦＰＧＡを備えた検証環境（例えば、通信事業者の実験室等）で、検証用マシン１４を用いて、for文のＧＰＵ処理パターンを試行錯誤する際の性能測定を行う。

　具体的には、検証環境用性能測定部１１９は、配置したファイルを起動し、想定するテストケースを実行して、オフロードした際の性能を測定するとともに、性能測定結果を、オフロード可能部抽出部１１４ａに戻す。この場合、オフロード可能部抽出部１１４ａは、別のオフロードパターン抽出を行い、中間言語ファイル出力部１１４ｂは、抽出された中間言語をもとに、性能測定を試行する（後記図４の符号ｅ参照）。
　上記検証環境での性能測定を繰り返し、最終的に配置するコードパターンを決定する。

　ここで、オフロードパターン作成部１１５による配置先環境に合わせたコード変換であるコード変換ステップと、検証環境用性能測定部１１９による、コード変換されたアプリケーションをコンパイルして、検証用マシン１４に配置しアクセラレータにオフロードした際の検証環境用性能測定ステップと、を反復する。すなわち、検証環境用性能測定は、コード変換と繰り返すように反復される。

<実行ファイル作成部１２０>
　実行ファイル作成部１２０は、所定回数繰り返された、性能測定結果をもとに、複数のオフロードパターンから最高処理性能のオフロードパターンを選択し、最高処理性能のオフロードパターンをコンパイルして実行ファイルを作成する実行ファイル作成ステップを実行する。

<本番環境配置部１２１>
　本番環境配置部１２１は、作成した実行ファイルを、ユーザ向けの本番環境に配置する（「最終バイナリファイルの本番環境への配置」）。本番環境配置部１２１は、最終的なオフロード領域を指定したパターンを決定し、ユーザ向けの本番環境に配置（デプロイ）する本番環境配置ステップを実行する。

<本番環境性能測定テスト抽出部１２２>
　本番環境性能測定テスト抽出部１２２は、実行ファイル配置後、テストケースＤＢ１３１から性能試験項目を抽出する（「最終バイナリファイルの本番環境への配置」）。

<本番環境性能測定テスト実行部１２３>
　本番環境性能測定テスト実行部１２３は、実行ファイル配置後、ユーザに性能を示すため、本番環境性能測定テスト抽出部１２２が抽出した性能試験項目を、運用装置１５を用いて自動実行する（「最終バイナリファイルの本番環境への配置」）。ここで、運用装置１５は、本番環境としてのユーザ宅のHome ＧＷやそれがつながるエッジルータ等である。本番環境性能測定テスト実行部１２３は、本番環境（ユーザ宅のHome ＧＷやそれがつながるエッジルータ等）に実行ファイルを配置後に、性能測定を実行してその結果をユーザに見せる。

　図４を参照して、本番環境性能測定テスト抽出部１２２の機能を説明する。本番環境性能測定テスト抽出部１２２は、図４のステップＳ１５で定めた商用環境配置場所に、図４のステップＳ２１，Ｓ２２で定めたコードパターンの実行ファイルを、図４のステップＳ１４で定めたリソース量を確保して配置すると、期待通りの動作となるかを動作検証する。具体的には、ユーザが指定した想定テストケースや、テストケースＤＢ１３１に保持されているアプリケーションリグレッションテストケースを用いて、動作検証する。この際に、想定テストケースの商用環境での実際の性能を、確保した全リソースのスペックやコストも含めて、ユーザに提示し、ユーザにサービス開始判断をしてもらい、ＯＫの場合にアプリケーションの運用を開始する。

<再構成必要性定期チェック部１２４>
　再構成必要性定期チェック部１２４は、再構成必要性を定期的にチェックする。

<再構成シミュレーション試算部１２５>
　再構成シミュレーション試算部１２５は、再構成必要性がある場合、再構成をシミュレーション試算する。
　図４を参照して、再構成シミュレーション試算部１２５の機能を説明する。再構成シミュレーション試算部１２５は、図４のステップＳ２３で開始したアプリケーション運用にて、リクエスト特性変化等で当初期待していた性能が出ない場合に、ソフトウェア設定、ソフトウェア／ハードウェア構成を再構成する。ソフトウェア設定とは、リソース量や配置場所の再変更を意味しており、例えば、ＣＰＵとＧＰＵの処理時間バランスが悪い場合に、リソースの比を変更したり、リクエスト量が増え応答時間が劣化してきた場合に、リソースの比はキープして量を増やす。あるいは、配置する場所を別のクラウドに変えるなどである。ソフトウェア／ハードウェア構成とは、コード変換から行い、ＧＰＵであればオフロード処理するロジックを変更したり、ＦＰＧＡのようにハードウェアロジックを運用中に変更できる場合はハードウェアロジックを再構成することを意味している。例えば、後者で、ＳＱＬＤＢとＮｏＳＱＬのＤＢを両運用している場合に、元々ＳＱＬリクエストが多かったが、ＮｏＳＱＬリクエストが一定よりも増えてきた場合に、ＮｏＳＱＬをアクセラレートするＦＰＧＡにロジックを再構成する。

　ここで図４のステップＳ２５で、環境適応に必要な、コード変換、リソース量調整、配置場所調整、運用中再構成を一括して行う処理フローを説明したが、行いたい処理だけ切出すことも可能である。例えば、ＧＰＵ向けにコード変換だけ行いたい場合は、図４のステップＳ１１－Ｓ１３だけ行い、環境適応機能部１１や検証環境等必要な部分だけ利用すればよい。

<再構成実行部１２６>
　再構成実行部１２６は、アプリケーション運用開始後に、当初期待していた性能が出ない場合に、ソフトウェア設定を再構成する。
　再構成実行部１２６は、再構成先構築部１２６ａと、マイグレーション処理部１２６ｂと、を備える。

　再構成先構築部１２６ａは、ソフトウェア設定の変更において、リソース量設定、配置場所選択の試行計算を周期的、または、性能がある閾値以下となった場合に試行模擬し、性能向上やコスト低減度合を計算し、リソース量の変更や配置場所の変更で性能やコストが改善できる見込みがある場合に、ユーザに再構成を提案し、ユーザ了承を得て、再構成を実行する場合に、リソースを変更する再構成先構築ステップを実行する。
　マイグレーション処理部１２６ｂは、配置場所変更の際、移行先環境を複製して、そこに移行元からアプリケーション実行環境をマイグレーションするマイグレーション処理ステップを実行する。

　再構成実行部１２６は、コード変換処理を、周期的、または、性能がある閾値以下となった場合に試行模擬し、コード変換して、ＧＰＵオフロードのソフトロジック変更やＦＰＧＡのハードロジックの変更で、性能やコストが改善できる見込みがある場合は、ユーザに再構成を提案し、ユーザ了承を得て、再構成を実行する際に、ＧＰＵオフロードするソフトロジックの変更を行う。
　ソフトウェア構成の変更の場合は、マイグレーション処理部１２６ｂが、更新する実行ファイルを起動する環境を複製後、アプリケーションのデータのマイグレーションを行い、ＦＰＧＡのハードロジックを変更する場合は、マイグレーション処理部１２６ｂが、移行先にハードロジックを構成済みのＦＰＧＡを準備しＦＰＧＡを制御するコンテナ等をマイグレーションを行う、もしくは、再構成実行部１２６が、ＦＰＧＡのハードロジックを再構成する。

<ユーザ提供部１２７>
　ユーザ提供部１２７は、性能試験結果を踏まえた、価格・性能等の情報をユーザに提示する（「価格・性能等の情報のユーザへの提供」）。テストケースＤＢ１３１には、性能試験項目に対応した、価格、性能等のデータが格納されている。ユーザ提供部１２７は、テストケースＤＢ１３１に格納された試験項目に対応した、価格、性能等のデータを読み出して、上記性能試験結果と共にユーザに提示する。ユーザは、提示された価格・性能等の情報をもとに、ＩｏＴサービスの課金利用開始を判断する。ここで、本番環境への一括デプロイには、非特許文献３の既存技術を、また、性能自動試験には、非特許文献４の既存技術を用いればよい。

<性能測定>
　上述したように、制御部１１（環境適応機能部）が行う性能測定は２種類ある。
（１）検証環境で、適切なコードパターン生成時の性能測定
　ＧＰＵとかＦＰＧＡを備えた検証環境（通信事業者の実験室等）で、for文のGPU処理パターンを試行錯誤する際の性能測定。本実施形態では、検証環境用性能測定部１１９が検証用マシン１４を用いて行う。

（２）本番環境配置後に、実際にどのくらいの性能が出るかを見せるための性能測定
　本番環境（ユーザ宅のＨＧＷやそれがつながるエッジルータ等）に実行ファイルを配置後に、性能測定してその結果をユーザに見せる。本実施形態では、本番環境性能測定テスト抽出部１２２が、実行ファイル配置後、テストケースＤＢ１３１から性能試験項目を抽出し、本番環境性能測定テスト実行部１２３が運用装置１５を用いて行う。

［遺伝的アルゴリズムの適用］
　オフロードサーバ１は、オフロードの最適化にＧＡを用いることができる。ＧＡを用いた場合のオフロードサーバ１の構成は下記の通りである。
　すなわち、オフロード処理指定部１１４は、遺伝的アルゴリズムに基づき、コンパイルエラーが出ないループ文（繰り返し文）の数を遺伝子長とする。オフロードパターン作成部１１５は、アクセラレータ処理をする場合を１または０のいずれか一方、しない場合を他方の０または１として、アクセラレータ処理可否を遺伝子パターンにマッピングする。

　オフロードパターン作成部１１５は、遺伝子の各値を１か０にランダムに作成した指定個体数の遺伝子パターンを準備し、検証環境用性能測定部１１９は、各個体に応じて、アクセラレータにおける並列処理指定文を指定したアプリケーションコードをコンパイルして、検証用マシン１４に配置する。検証環境用性能測定部１１９は、検証用マシン１４において性能測定用処理を実行する。

　ここで、検証環境用性能測定部１１９は、途中世代で、以前と同じオフロードパターンの遺伝子が生じた場合は、当該オフロードパターンに該当するアプリケーションコードのコンパイル、および、性能測定はせずに、性能測定値としては同じ値を使う。
　また、検証環境用性能測定部１１９は、コンパイルエラーが生じるアプリケーションコード、および、性能測定が所定時間で終了しないアプリケーションコードについては、タイムアウトの扱いとして、性能測定値を所定の時間（長時間）に設定する。

　実行ファイル作成部１２０は、全個体に対して、性能測定を行い、処理時間の短い個体ほど適合度が高くなるように評価する。実行ファイル作成部１２０は、全個体から、適合度が所定値（例えば、全個数の上位ｎ％、または全個数の上位ｍ個　ｎ，ｍは自然数）より高いものを性能の高い個体として選択し、選択された個体に対して、交叉、突然変異の処理を行い、次世代の個体を作成する。実行ファイル作成部１２０は、指定世代数の処理終了後、最高性能のオフロードパターンを解として選択する。

　以下、上述のように構成されたオフロードサーバ１のソフトウェア最適配置方法について説明する。
［最適配置動作］
　図３は、オフロードサーバ１のソフトウェア最適配置処理を示すフローチャートである。
　ステップＳ１で制御部１１のアプリケーションコード分析部１１２は、アプリケーションの処理機能のソースコードを分析し、ループ文や変数の参照関係、処理する機能ブロック等、コードの構造を把握する。
　ステップＳ２でオフロード処理指定部１１４は、アプリケーションの並列処理可能なループ文、特定処理の機能ブロック、ライブラリ呼び出しを含むオフロード可能な処理を特定する。オフロード処理指定部１１４は、各ループ文に対して、アクセラレータにおける並列処理指定文を指定してコンパイルする。

　ステップＳ３でオフロードパターン作成部１１５は、配置先環境に合わせたコード変換をする。
　ステップＳ４でリソース量計算部１１６は、配置先環境に合わせたリソース量の設定を行う。リソース量計算部１１６は、アプリケーションテストケースの処理時間から、ＣＰＵとオフロード先の処理時間が同等のオーダーになるように、ＣＰＵとオフロード先のリソース比を定め、リソース比を決定後は、想定するテストケースの処理性能が、要求性能およびコスト要求を満たすようにリソース比はキープしつつ、リソース量を設定する。

　ステップＳ５で配置先計算部１１８は、オフロードパターン作成部１１５がコード変換した変換コードを、リソース量計算部１１６およびリソース量指定部１１７が設定したリソース量を確保して配置する際に、性能およびコストをもとに配置先を計算して配置場所を選択する。具体的には、配置先計算部１１８は、アプリケーションテストケースの結果から、アプリケーションを配置した際の計算量と発生トラフィックを算出し、クラウド、エッジ、Home ＧＷを含むリンク関係をモデル化し、アプリケーションを特定のノードに配置した際に、コストが要求条件に収まることを制約条件に、処理遅延および／またはスループットの性能を最大化する配置、あるいは性能が要求条件を満たす形でコストが最低になる配置のいずれかを最適化手法（例えば、線形計画手法等）を用いて計算する。

　ステップＳ６で検証環境用性能測定部１１９は、コード変換されたアプリケーションをコンパイルして、検証用マシン１４に配置し、アクセラレータにオフロードした際の性能測定用処理を実行する。
　ステップＳ７で制御部（環境適応機能部）１１は、コード変換ステップ、リソース量設定ステップ、配置場所選択ステップ、性能測定ステップのいずれか一つ以上のステップを実行する環境適応処理を行い本フローの処理を終了する。

［自動オフロード動作］
　本実施形態のオフロードサーバ１を、ユーザアプリケーションロジックの、ＧＰＵ自動オフロード技術に適用した例について説明する。
　図４は、オフロードサーバ１のＧＡを用いた自動オフロード処理を示す図である。
　図４に示すように、オフロードサーバ１は、制御部（環境適応機能部）１１と、テストケースＤＢ１３１と、コードパターンＤＢ１３２と、設備リソースＤＢ１３３と、中間言語ファイル１３４と、検証用マシン１４と、を有している。
　オフロードサーバ１は、ユーザが利用するアプリケーションコード（Application code）１３０を取得する。

　ユーザは、OpenＩｏＴリソース（OpenＩｏＴResources）１５を利用する。OpenＩｏＴリソース１５は、例えば、各種デバイス（Device）としてＩｏＴＧＷ１５１、ＣＰＵ-ＧＰＵを有する装置１５２、ＣＰＵ-ＦＰＧＡを有する装置１５３、ＣＰＵを有する装置１５４である。オフロードサーバ１は、機能処理をＣＰＵ-ＧＰＵを有する装置１５２、ＣＰＵ-ＦＰＧＡを有する装置１５３のアクセラレータに自動オフロードする。

　以下、図４のステップ番号を参照して各部の動作を説明する。
<ステップＳ１１：Specify application code>
　ステップＳ１１において、アプリケーションコード指定部１１１（図２参照）は、ユーザに提供しているサービスの処理機能（画像分析等）を特定する。具体的には、アプリケーションコード指定部１１１は、入力されたアプリケーションコードの指定を行う。

<ステップＳ１２：Analyze application code>
　ステップＳ１２において、アプリケーションコード分析部１１２（図２参照）は、処理機能のソースコードを分析し、ループ文やＦＦＴライブラリ呼び出し等の構造を把握する。

<ステップＳ１３：Extract offloadable area>
　ステップＳ１３において、オフロード処理指定部１１４（図２参照）は、アプリケーションのループ文（繰り返し文）を特定し、各繰り返し文に対して、アクセラレータにおける並列処理指定文を指定してコンパイルする。具体的には、オフロード可能部抽出部１１４ａ（図２参照）は、ループ文やＦＦＴ等、ＧＰＵ・ＦＰＧＡにオフロード可能な処理を特定し、オフロード処理に応じた中間言語を抽出する。

<ステップＳ１４：Output intermediate file>
　ステップＳ１４において、中間言語ファイル出力部１１４ｂ（図２参照）は、中間言語ファイル１３４を出力する。中間言語抽出は、一度で終わりでなく、適切なオフロード領域探索のため、実行を試行して最適化するため反復される。

<ステップＳ１５：Compile error>
　ステップＳ１５において、オフロードパターン作成部１１５（図２参照）は、コンパイルエラーが出るループ文に対して、オフロード対象外とするとともに、コンパイルエラーが出ない繰り返し文に対して、並列処理するかしないかの指定を行うオフロードパターンを作成する。

<ステップＳ２１：Deploy binary files>
　ステップＳ２１において、バイナリファイル配置部１１９ａ（図２参照）は、ＧＰＵ・ＦＰＧＡ・ＩｏＴＧＷを備えた検証用マシン１４に、中間言語から導かれる実行ファイルをデプロイする。

<ステップＳ２２：Measure performances>
　ステップＳ２２において、検証環境用性能測定部１１９（図２参照）は、配置したファイルを実行し、オフロードした際の性能を測定する。
　オフロードする領域をより適切にするため、この性能測定結果は、オフロード可能部抽出部１１４ａに戻され、オフロード可能部抽出部１１４ａが、別パターンの抽出を行う。そして、中間言語ファイル出力部１１４ｂは、抽出された中間言語をもとに、性能測定を試行する（図４の符号ａ参照）。

　図４の符号ａ，ｂに示すように、制御部１１は、上記ステップＳ１２乃至ステップＳ２２を繰り返し実行する。制御部１１の自動オフロード機能をまとめると、下記である。すなわち、オフロード処理指定部１１４は、アプリケーションのループ文（繰り返し文）を特定し、各繰返し文に対して、ＧＰＵでの並列処理指定文を指定して、コンパイルする。そして、オフロードパターン作成部１１５は、コンパイルエラーが出るループ文を、オフロード対象外とし、コンパイルエラーが出ないループ文に対して、並列処理するかしないかの指定を行うオフロードパターンを作成する。そして、バイナリファイル配置部１１９ａは、該当オフロードパターンのアプリケーションをコンパイルして、検証用マシン１４に配置し、検証環境用性能測定部１１９が、検証用マシン１４で性能測定用処理を実行する。実行ファイル作成部１２０は、所定回数繰り返された、性能測定結果をもとに、複数のオフロードパターンから最高処理性能のパターンを選択し、選択パターンをコンパイルして実行ファイルを作成する。

<ステップＳ２３：Deploy final binary files to production environment>
　ステップＳ２３において、本番環境配置部１２１は、最終的なオフロード領域を指定したパターンを決定し、ユーザ向けの本番環境にデプロイする。

<ステップＳ２４：Extract performance test cases and run automatically>
　ステップＳ２４において、本番環境性能測定テスト抽出部１２２は、実行ファイル配置後、ユーザに性能を示すため、性能試験項目をテストケースＤＢ１３１から抽出し、抽出した性能試験を自動実行する。

<ステップＳ２５：Provide price and performance to a user to judge>
　ステップＳ２５において、ユーザ提供部１２７は、性能試験結果を踏まえた、価格・性能等の情報をユーザに提示する。ユーザは、提示された価格・性能等の情報をもとに、ＩｏＴサービスの課金利用開始を判断する。

　上記ステップＳ１１～ステップＳ２５は、ユーザのＩｏＴサービス利用のバックグラウンドで行われ、例えば、仮利用の初日の間に行う等を想定している。また、コスト低減のためにバックグラウンドで行う処理は、機能配置最適化とＧＰＵ・ＦＰＧＡオフロードのみを対象としてもよい。

　上記したように、オフロードサーバ１の制御部（環境適応機能部）１１は、機能処理のオフロードのため、ユーザが利用するアプリケーションのソースコードから、オフロードする領域を抽出して中間言語を出力する（ステップＳ１１～ステップＳ１５）。制御部１１は、中間言語から導かれる実行ファイルを、検証用マシン１４に配置実行し、オフロード効果を検証する（ステップＳ２１～ステップＳ２２）。検証を繰り返し、適切なオフロード領域を定めたのち、制御部１１は、実際にユーザに提供する本番環境に、実行ファイルを配置（デプロイ）し、サービスとして提供する（ステップＳ２３～ステップＳ２５）。

［ＧＡを用いたＧＰＵ自動オフロード］
　ＧＰＵ自動オフロードは、ＧＰＵに対して、図４のステップＳ１２～ステップＳ２２を繰り返し、最終的にステップＳ２３でデプロイするオフロードコードを得るための処理である。

　ＧＰＵは、一般的にレイテンシーは保証しないが、並列処理によりスループットを高めることに向いたデバイスである。ＩｏＴで動作させるアプリケーションは、多種多様である。ＩｏＴデータの暗号化処理や、カメラ映像分析のための画像処理、大量センサデータ分析のための機械学習処理等が代表的であり、それらは、繰り返し処理が多い。そこで、アプリケーションの繰り返し文をＧＰＵに自動でオフロードすることでの高速化を狙う。

　しかし、従来技術で記載の通り、高速化には適切な並列処理が必要である。特に、ＧＰＵを使う場合は、ＣＰＵとＧＰＵ間のメモリ転送のため、データサイズやループ回数が多くないと性能が出ないことが多い。また、メモリデータ転送のタイミング等により、並列高速化できる個々のループ文（繰り返し文）の組み合わせが、最速とならない場合等がある。例えば、１０個のfor文（繰り返し文）で、１番、５番、１０番の３つがＣＰＵに比べて高速化できる場合に、１番、５番、１０番の３つの組み合わせが最速になるとは限らない等である。

　適切な並列領域指定のため、ＰＧＩコンパイラを用いて、for文の並列可否を試行錯誤して最適化する試みがある。しかし、試行錯誤には多くの稼働がかかり、ＩｏＴサービスとして提供する際に、ユーザの利用開始が遅くなり、コストも上がってしまう問題がある。

　そこで、本実施形態では、並列化を想定していない汎用プログラムから、自動で適切なオフロード領域を抽出する。このため、最初に並列可能for文のチェックを行い、次に並列可能for文群に対してＧＡを用いて検証環境で性能検証試行を反復し適切な領域を探索すること、を実現する。並列可能for文に絞った上で、遺伝子の部分の形で、高速化可能なオフロードパターンを保持し組み換えていくことで、取り得る膨大なオフロードパターンから、効率的に高速化可能なパターンを探索できる。

［Simple GAによる制御部（環境適応機能部）１１の探索イメージ］
　図５は、Simple GAによる制御部（環境適応機能部）１１の探索イメージを示す図である。図５は、処理の探索イメージと、for文の遺伝子配列マッピングを示す。
　ＧＡは、生物の進化過程を模倣した組合せ最適化手法の一つである。ＧＡのフローチャートは、初期化→評価→選択→交叉→突然変異→終了判定となっている。
　本実施形態では、ＧＡの中で、処理を単純にしたSimple GAを用いる。Simple GAは、遺伝子は１、０のみとし、ルーレット選択、一点交叉、突然変異は１箇所の遺伝子の値を逆にする等、単純化されたＧＡである。

<初期化>
　初期化では、アプリケーションコードの全for文の並列可否をチェック後、並列可能for文を遺伝子配列にマッピングする。ＧＰＵ処理する場合は１、ＧＰＵ処理しない場合は０とする。遺伝子は、指定の個体数Ｍを準備し、１つのfor文にランダムに１、０の割り当てを行う。
　具体的には、制御部（環境適応機能部）１１（図２参照）は、ユーザが利用するアプリケーションコード（Application code）１３０（図４参照）を取得し、図５に示すように、アプリケーションコード１３０のコードパターン（Code patterns）１４１からfor文の並列可否をチェックする。図５に示すように、コードパターン１４１から５つのfor文が見つかった場合（図５の符号ｃ参照）、各for文に対して１桁、ここでは５つのfor文に対し５桁の１または０をランダムに割り当てる。例えば、ＣＰＵで処理する場合０、ＧＰＵに出す場合１とする。ただし、この段階では１または０をランダムに割り当てる。
　遺伝子長に該当するコードが５桁であり、５桁の遺伝子長のコードは２^５＝３２パターン、例えば１０００１、１００１０、…となる。なお、図５では、コードパターン１４１中の丸印（○印）をコードのイメージとして示している。

<評価>
　評価では、デプロイとパフォーマンスの測定（Deploy & performance measurement）を行う（図５の符号ｄ参照）。すなわち、検証環境用性能測定部１１９（図２参照）は、遺伝子に該当するコードをコンパイルして検証用マシン１４にデプロイして実行する。検証環境用性能測定部１１９は、ベンチマーク性能測定を行う。性能が良いパターン（オフロードパターン）の遺伝子の適合度を高くする。

<選択>
　選択では、適合度に基づいて、高性能コードパターンを選択（Select high performance code patterns）する（図５の符号ｅ参照）。検証環境用性能測定部１１９（図２参照）は、適合度に基づいて、高適合度の遺伝子を、指定の個体数選択する。本実施形態では、適合度に応じたルーレット選択および最高適合度遺伝子のエリート選択を行う。
　図５では、選択されたコードパターン（Select code patterns）１４２の中の丸印（○印）が、３つに減ったことを探索イメージとして示している。

<交叉>
　交叉では、一定の交叉率Ｐｃで、選択された個体間で一部の遺伝子をある一点で交換し、子の個体を作成する。
　ルーレット選択された、あるパターン（オフロードパターン）と他のパターンとの遺伝子を交叉させる。一点交叉の位置は任意であり、例えば上記５桁のコードのうち３桁目で交叉させる。

<突然変異>
　突然変異では、一定の突然変異率Ｐｍで、個体の遺伝子の各値を０から１または１から０に変更する。
　また、局所解を避けるため、突然変異を導入する。なお、演算量を削減するために突然変異を行わない態様でもよい。

<終了判定>
　図５に示すように、クロスオーバーと突然変異後の次世代コードパターンの生成（Generate next generation code patterns after crossover & mutation）を行う（図５の符号ｆ参照）。
　終了判定では、指定の世代数Ｔ回、繰り返しを行った後に処理を終了し、最高適合度の遺伝子を解とする。
　例えば、性能測定して、速い３つ１００１０、０１００１、００１０１を選ぶ。この３つをＧＡにより、次の世代は、組み換えをして、例えば新しいパターン（オフロードパターン）１０１０１（一例）を作っていく。このとき、組み換えをしたパターンに、勝手に０を１にするなどの突然変異を入れる。上記を繰り返して、一番早いパターンを見付ける。指定世代（例えば、２０世代）などを決めて、最終世代で残ったパターンを、最後の解とする。

<デプロイ（配置）>
　最高適合度の遺伝子に該当する、最高処理性能のオフロードパターンで、本番環境に改めてデプロイして、ユーザに提供する。

<補足説明>
　ＧＰＵにオフロードできないfor文（ループ文；繰り返し文）が相当数存在する場合について説明する。例えば、for文が２００個あっても、ＧＰＵにオフロードできるものは３０個くらいである。ここでは、エラーになるものを除外し、この３０個について、ＧＡを行う。
　OpenＡＣＣには、ディレクティブ #pragma acc kernelsで指定して、ＧＰＵ向けバイトコードを抽出し、実行によりＧＰＵオフロードを可能とするコンパイラがある。この#pragmaに、for文のコマンドを書くことにより、そのfor文がＧＰＵで動くか否かを判定することができる。

　例えばC/C++を使った場合、C/C++のコードを分析し、for文を見付ける。for文を見付けると、OpenＡＣＣで並列処理の文法である #pragma acc kernelsを使ってfor文に対して書き込む。詳細には、何も入っていない #pragma acc kernels に、一つ一つfor文を入れてコンパイルして、エラーであれば、そのfor文はそもそも、ＧＰＵ処理できないので、除外する。このようにして、残るfor文を見付ける。そして、エラーが出ないものを、長さ（遺伝子長）とする。エラーのないfor文が５つであれば、遺伝子長は５であり、エラーのないfor文が１０であれば、遺伝子長は１０である。なお、並列処理できないものは、前の処理を次の処理に使うようなデータに依存がある場合である。
　以上が準備段階である。次にＧＡ処理を行う。

　for文の数に対応する遺伝子長を有するコードパターンが得られている。始めはランダムにオフロードパターン１００１０、０１００１、００１０１、…を割り当てる。ＧＡ処理を行い、コンパイルする。その時に、オフロードできるfor文であるにもかかわらず、エラーがでることがある。for文が階層になっている（どちらか指定すればＧＰＵ処理できる）場合である。この場合は、エラーとなったfor文は、残してもよい。具体的には、処理時間が多くなった形にして、タイムアウトさせる方法がある。

　検証用マシン１４でデプロイして、ベンチマーク、例えば画像処理であればその画像処理でベンチマークする、その処理時間が短い程、適応度が高いと評価する。例えば、処理時間の逆数、処理時間１０秒かかるものは１、１００秒かかるものは０．１、１秒のものは１０とする。
　適応度が高いものを選択して、例えば１０個のなかから、３～５個を選択して、それを組み替えて新しいコードパターンを作る。作成途中で、前と同じものができる場合がある。この場合、同じベンチマークを行う必要はないので、前と同じデータを使う。本実施形態では、コードパターンと、その処理時間は記憶部１３に保存しておく。

　以上で、Simple GAによる制御部（環境適応機能部）１１の探索イメージについて説明した。次に、データ転送の一括処理手法について述べる。

［データ転送の一括処理手法］
　上述したように、遺伝的アルゴリズムを用いることで、ＧＰＵ処理で効果のある並列処理部を自動チューニングしている。しかしながら、ＣＰＵ-ＧＰＵメモリ間のデータ転送によっては高性能化できないアプリケーションもあった。このため、スキルが無いユーザがＧＰＵを使ってアプリケーションを高性能化することは難しいし、自動並列化技術等を使う場合も並列処理可否の試行錯誤が必要であり、高速化できない場合があった。

　そこで、本実施形態では、より多くのアプリケーションを、自動でＧＰＵで高性能化することを狙うとともに、ＧＰＵへのデータ転送回数を低減できる技術を提供する。

　次に、本実施形態のオフロードサーバ１によるデータ転送の一括処理手法について説明する。
　図６および図７は、本実施形態の環境適応機能部が処理するアプリケーションのソースコードのループ文を示す図であり、ＣＰＵプログラム側で定義した変数とＧＰＵプログラム側で参照する変数が重なる場合の例である。
　本実施形態の制御部（環境適応機能部）１１（図２参照）は、データ転送指定部１１３を備えている。

《本実施形態のＣＰＵからＧＰＵへのデータ転送》
　本実施形態では、ＣＰＵプログラム側で設定、定義した変数とＧＰＵプログラム側で参照する変数が重なる場合は、ＣＰＵからＧＰＵへのデータ転送が必要として、データ転送指定を行う。
　データ転送を指定する位置は、ＧＰＵ処理するループ文かそれより上位のループ文で、かつ、該当変数の設定、定義を含まない最上位のループとする（図６参照）。データ転送指示行の挿入位置は、for，do，while等のループの直前に行う。

　図６は、ＣＰＵからＧＰＵへのデータ転送する場合のループ文において、ＣＰＵプログラム側で定義した変数とＧＰＵプログラム側で参照する変数が重なる場合の例である。
　図６に示す本実施形態のループ文は、ＣＰＵプログラム側で記述され、
(1) ループ〔 for｜do｜while 〕 {
}
の中に、
　(2) ループ〔 for｜do｜while 〕 {
　}
があり、さらにその中に、
　　(3) ループ〔 for｜do｜while 〕 {
　　}
があり、さらにその中に、
　　　(4) ループ〔 for 〕 {
　　　}
がある。

　また、(1) ループ〔 for｜do｜while 〕 {
}で、変数ａが設定され、(4) ループ〔 for 〕 {
}で、変数ａが参照される。

　さらに、(3) ループ〔 for｜do｜while 〕 {
}で、ＰＧＩコンパイラによるfor文等の並列処理可能処理部を、OpenＡＣＣのディレクティブ #pragma acc kernels（並列処理指定文）で指定している（詳細後記）。

　図６に示す本実施形態のループ文では、図６の符号ｍに示す位置に、データ転送指示行、ここでは変数ａの copyin 節の #pragma acc data copyin(a[…])を挿入する。
　上記 #pragma acc data copyin(a[…])は、変数ａの設定、定義を含まない最上位のループ（ここでは、(1) ループ〔 for｜do｜while 〕の中）に指定され、その挿入位置は、for，do，while等のループの直前（ここでは、(2) ループ〔 for｜do｜while 〕の前）である。

　このように、ＣＰＵからＧＰＵへのデータ転送において、変数ａの copyin 節の #pragma acc data copyin(a[…])を、上述した位置に挿入することによりデータ転送を明示的に指示する。これにより、できるだけ上位のループでデータ転送を一括して行うことができ、ループ毎に毎回データを転送する非効率な転送を避けることができる。

《本実施形態のＧＰＵからＣＰＵへのデータ転送》
　本実施形態では、ＧＰＵプログラム側で設定した変数とＣＰＵプログラム側で参照、設定、定義する変数または大域変数（グローバル変数：全ての関数から直接アクセスすることができる変数）とが重なる場合は、ＧＰＵからＣＰＵへのデータ転送が必要として、データ転送指定を行う。
　データ転送を指定する位置は、ＧＰＵ処理するループ文か、それより上位のループ文で、かつ、該当変数の参照、設定、定義を含まない最上位のループとする（後記図７参照）。データ転送指示行の挿入位置は、for，do，while等のループの直前に行う。

　ここで、「設定」まで含めるのは、その設定がif文等で実行されたり、されなかったりするケースを考慮するためである。また、条件にＣＰＵ側で「定義」も含めているのは、変数のスコープ外に展開しないためのガードである。大域変数は、解析対象ソース外で「参照」される可能性があるため、条件に含める。

　図７は、ＧＰＵからＣＰＵへのデータ転送する場合のループ文において、ＣＰＵプログラム側で定義した変数とＧＰＵプログラム側で参照する変数が重なる場合の例である。
　図７に示す本実施形態のループ文は、ＣＰＵプログラム側で記述され、
(1) ループ〔 for｜do｜while 〕 {
}
の中に、
　(2) ループ〔 for｜do｜while 〕 {
　}
があり、さらにその中に、
　　(3) ループ〔 for｜do｜while 〕 {
　　}
があり、さらにその中に、
　　　(4) ループ〔 for 〕 {
　　　}
がある。

　また、(3) ループ〔 for｜do｜while 〕 {
}で、ＰＧＩコンパイラによるfor文等の並列処理可能処理部を、OpenＡＣＣのディレクティブ #pragma acc kernels（並列処理指定文）で指定している。

　さらに、(4) ループ〔 for 〕 {
}で、変数ａが設定され、(2) ループ〔 for｜do｜while 〕 {
}で、変数ａが参照される。

　図７に示す本実施形態のループ文では、図７の符号ｎに示す位置に、データ転送指示行、ここでは変数ａの copyout 節の #pragma acc data copyout(a[…])を挿入する。
　上記 #pragma acc data copyout(a[…])は、変数ａの参照、設定、定義を含まない最上位のループ（ここでは、(1) ループ〔 for｜do｜while 〕の中）に指定され、その挿入位置は、for，do，while等のループの直前（ここでは、(2) ループ〔 for｜do｜while 〕の前）である。

　上記copyout 動作が実行されるのは、図７の符号ｏに示すように、ループ終了後である。

　このように、ＧＰＵからＣＰＵへのデータ転送において、変数ａの copyout 節の #pragma acc data copyout(a[…])を、上述した位置に挿入することによりデータ転送を明示的に指示する。これにより、できるだけ上位のループでデータ転送を一括して行うことができ、ループ毎に毎回データを転送する非効率な転送を避けることができる。

《本実施形態のＣＰＵからＧＰＵへのデータ転送と、ＧＰＵからＣＰＵへのデータ転送の往復》
　同じ変数に関して、ＣＰＵからＧＰＵへの転送と、ＧＰＵからＣＰＵへの転送が重なる場合は、データコピーの往復にまとめて指示する。
　具体的には、前記図６に示す本実施形態のループ文の #pragma acc data copyin(a[…])に代えて、#pragma acc data copy (a[…])を挿入する。
　上記 #pragma acc data copy(a[…])は、変数ａの設定、定義を含まない最上位のループ（ここでは、(1) ループ〔 for｜do｜while 〕の中）に指定され、その挿入位置は、for，do，while等のループの直前（ここでは、(2) ループ〔 for｜do｜while 〕の前）である。

　このように、ＣＰＵからＧＰＵへのデータ転送と、ＧＰＵからＣＰＵへのデータ転送の往復において、変数ａの copy 節の #pragma acc data copy(a[…])を、上述した位置に挿入することによりデータ転送を明示的に指示する。また、上記 #pragma acc data copy(a[…])を用いることで、前記図７に示す上記 #pragma acc data copyout(a[…])を挿入を省略することができる。

　以上、本実施形態では、できるだけ上位のループでデータ転送を一括して行うように、データ転送を明示的に指示することで、ループ毎に毎回データを転送する非効率な転送を避けることができる。

［ＧＰＵオフロード処理］
　上述したデータ転送の一括処理手法により、オフロードに適切なループ文を抽出し、非効率なデータ転送を避けることができる。
　ただし、上記データ転送の一括処理手法を用いても、ＧＰＵオフロードに向いていないプログラムも存在する。効果的なＧＰＵオフロードには、オフロードする処理のループ回数が多いことが必要である。

　そこで、本実施形態では、本格的なオフロード処理探索の前段階として、プロファイリングツールを用いて、ループ回数を調査する。プロファイリングツールを用いると、各行の実行回数を調査できるため、例えば、５０００万回以上のループを持つプログラムをオフロード処理探索の対象とする等、事前に振り分けることができる。以下、具体的に説明する（前記図５で述べた内容と一部重複する）。

　本実施形態では、まず、オフロード処理部を探索するアプリケーションを分析し、for，do，while等のループ文を把握する。次に、サンプル処理を実行し、プロファイリングツールを用いて、各ループ文のループ回数を調査し、一定の値以上のループがあるか否かで、オフロード処理部探索を本格的に行うか否かの判定を行う。

　探索を本格的に行うと決まった場合は、ＧＡの処理に入る（前記図５参照）。初期化ステップでは、アプリケーションコードの全ループ文の並列可否をチェックした後、並列可能ループ文をＧＰＵ処理する場合は１、しない場合は０として遺伝子配列にマッピングする。遺伝子は、指定の個体数が準備されるが、遺伝子の各値にはランダムに１，０の割り当てをする。

　ここで、遺伝子に該当するコードでは、ＧＰＵ処理すると指定されたループ文内の変数データ参照関係から、データ転送の明示的指示（#pragma acc data copyin/copyout/copy）を追加する。

　評価ステップでは、遺伝子に該当するコードをコンパイルして検証用マシンにデプロイして実行し、ベンチマーク性能測定を行う。性能が良いパターンの遺伝子の適合度を高くする。遺伝子に該当するコードは、上述のように、並列処理指示行とデータ転送指示行（例えば、図６の符号ｌ、図７の符号ｍ参照参照）が挿入されている。

　選択ステップでは、適合度に基づいて、高適合度の遺伝子を、指定の個体数選択する。本実施形態では、適合度に応じたルーレット選択および最高適合度遺伝子のエリート選択を行う。交叉ステップでは、一定の交叉率Ｐｃで、選択された個体間で一部の遺伝子をある一点で交換し、子の個体を作成する。突然変異ステップでは、一定の突然変異率Ｐｍで、個体の遺伝子の各値を０から１または１から０に変更する。

　突然変異ステップまで終わり、次の世代の遺伝子が指定個体数作成されると、初期化ステップと同様に、データ転送の明示的指示を追加し、評価、選択、交叉、突然変異ステップを繰り返す。

　最後に、終了判定ステップでは、指定の世代数、繰り返しを行った後に処理を終了し、最高適合度の遺伝子を解とする。最高適合度の遺伝子に該当する、最高性能のコードパターンで、本番環境に改めてデプロイして、ユーザに提供する。

　以下、図２に示すオフロードサーバ１の制御部（環境適応機能部）１１の動作について、図４を参照して説明する。
<ＦＰＧＡ向けオフロード>
　ＧＰＵでは高速化は、ループ文等の並列処理が中心であった。一方、ＦＰＧＡでは、並列処理とパイプライン処理を活用して高速化するのが一般的であり、オフロードの自由度は高いが、機械がオフロード用のロジックを自動生成することは難しいのが現状である。そこで、ＦＰＧＡのオフロードでは、今までにプログラマーが蓄積したノウハウ（Well-knownパターン）を活かして、大きな単位でオフロードする。

　具体的には、図４のステップＳ１１のコード分析で把握した、類似コード検出等を用いたコード機能ブロックが、例えばＦＦＴ処理である場合や、ライブラリ呼び出しでＦＦＴ処理を呼び出している場合に、ＦＦＴ処理で既に定義されているＦＰＧＡロジックに置換して、オフロードを行う。この置換のために、コードパターンＤＢ１３２は、ＦＰＧＡにオフロード可能な処理のライブラリ呼び出しや機能ブロックと、オフロードするＦＰＧＡの処理ロジックをOpenCLやHDLで記述したコードを、登録している。制御部（環境適応機能部）１１は、コード分析結果と、コードパターンＤＢ１３２を照合し、オフロード可能な処理を、ＦＰＧＡにオフロードする処理ロジック記述に置換する。

<リソース量調整>
　図４のステップＳ１４，Ｓ１５のリソース量調整については、まず適切なリソース比を決め、次に性能、コスト要件に合うリソース量に設定する。アプリケーションをＣＰＵとＧＰＵで動作させるようオフロードするコードに、図４のステップＳ１１－Ｓ１３で変換したとして、コード自体は適切であっても、ＣＰＵとオフロード先であるＧＰＵとのリソース量が適切なバランスでない場合は、性能が出ない。例えば、ある処理を行う際に、ＣＰＵの処理時間が１０００秒，ＧＰＵの処理時間が１秒では、ＣＰＵがボトルネックとなるっている。非特許文献２では、ＣＰＵとＧＰＵを使ってMapReduceフレームワークで処理している際に、ＣＰＵとＧＰＵの実行時間が同じになるようMapタスクを配分することで、全体の高性能化を図っている。本実施形態では、リソース比を決める際は、何れかのハードウェアでの処理がボトルネックとなる配置を避けるため、想定するテストケースの処理時間から、リソース量計算部１１６が、ＣＰＵとオフロード先の処理時間が同等のオーダーになるように、リソース比を決定する。

　リソース比を決定後は、想定するテストケースの処理性能が、図４のステップＳ１４，Ｓ１５でユーザが指定した要求性能およびコスト要求を満たすように、リソース量計算部１１６が、リソース比をキープして、リソース量を決定する。

<配置場所調整>
　図４のステップＳ１５の配置場所調整では、性能、コストが適切になる場所を計算し配置先を決める。適切な配置先を決める手法については、最適化計算を用いた手法をとる。配置先を決めるための情報としては、配置するアプリケーションの想定するテストケースの性能情報（処理遅延やスループット）と、システムで利用できる設備リソース情報（クラウド、エッジ、Home ＧＷ等の計算リソース、ノード間帯域、およびその既に利用されている量と、利用した際のコスト）がある。

　配置先を決定するロジックは、以下のようになる。想定テストケースの性能結果から、アプリケーションを配置した際の計算量と発生トラフィックを算出する。併せて、クラウド、エッジ、Home ＧＷ等のリンク関係をモデル化しておく。アプリケーションを特定のノードに配置した際に、コストが要求条件に収まることを制約条件に、処理遅延やスループット等の性能を最大化する配置、あるいは性能が要求条件を満たす形でコストが最低になる配置を、最適化手法（例えば、線形計画手法等）を用いて導く。ここで、アプリケーションが、エッジとクラウドのように分割される場合は、その組み合わせに対して最適計算を行う。

<配置場所調整>
　図４のステップＳ２３の動作検証では、図４のステップＳ１２，Ｓ１３で決まった実行ファイルを図４のステップＳ１４の指定リソース量で図４のステップＳ１５の指定場所に配置した後に、期待通りの動作であることを、性能検証テストケースやリグレッションテストケースを実行することで確認する。性能検証テストケースは、ユーザが指定した想定テストケースをJenkins等の試験自動実行ツールを用いて行い、処理時間やスループット等を測定する。リグレッションテストについては、システムにインストールされるミドルウェアやＯＳ等のソフトウェアの情報を取得して、それらに対応するリグレッションテストをJenkins等を用いて実行する自動検証技術（非特許文献３参照）を用いる。

　動作検証の結果として、性能検証テストケースの処理時間やスループット、リグレッションテストの実行結果の情報が、ユーザに提示される。ユーザには合わせて、確保したリソース（仮想マシンスペックや数等）とその価格が提示されており、それら情報を参照してユーザは運用開始を判断する。

<運用中再構成>
　アプリケーション運用において、図４のステップＳ２３の運用開始後、リクエスト特性の変化等で当初期待していた性能が出ない場合に、再構成シミュレーション試算部１２５は、ソフトウェア設定、ソフトウェア／ハードウェア構成を再構成する。再構成の判断は、運用開始前に想定したテストケースでなく、現在の実運用にマッチするテストケースを元に、図４のステップＳ１１－Ｓ１５のコード変換、リソース量調整、配置場所調整を試行模擬し、性能、コストが、ユーザの期待を満たす場合に、ユーザ提供部１２７が、再構成をユーザに提案し、ユーザ了承後、再構成する。再構成は、再構成実行部１２６の再構成先構築部１２１ａ（図２参照）が実行する。

<ソフトウェア設定>
　ソフトウェア設定の変更は、図４のステップＳ１４，Ｓ１５の処理を、周期的、または、性能がある閾値以下となった場合に試行模擬し、性能向上やコスト低減度合を計算する。リソース量の変更や配置場所の変更で性能やコストが改善できる見込みがある場合は、ユーザに再構成を提案する。ユーザ了承を得て、再構成を実施する場合に、リソースを変更する際は、クラウド関連技術により、メモリサイズ等の変更であれば断時間は無く変更できることが多い。

<マイグレーション>
　配置場所変更の際は、一括プロビジョニング技術（OpenStack Heatを使った手法等（非特許文献４参照）を用いて、移行先環境を複製しておき、そこに移行元からマイグレーションを行う。マイグレーションは、再構成実行部１２６のマイグレーション処理部１２６ｂ（図２参照）が行う。
　配置場所変更で、ディスクが共用でよい場合は、OpenStack等でサポートされる仮想マシンの移行を行うライブマイグレーションを行う。また、配置場所が大きく変わりディスク情報も含めて移行する場合は、ブロックマイグレーションを行う。ＧＰＵ等のハードウェアは仮想マシンでなく、コンテナで制御する場合が多いため、コンテナの移行時は、ＬＸＤ等のコンテナ管理技術を使ってマイグレーションを行う。

<ソフトウェア／ハードウェア構成>
　ソフトウェア／ハードウェア構成の変更は、図４のステップＳ１２，Ｓ１３の処理を、周期的、または、性能がある閾値以下となった場合に試行模擬し、コード変換して、ＧＰＵオフロードのソフトロジック変更やＦＰＧＡのハードロジックの変更で、性能やコストが改善できる見込みがある場合は、ユーザに再構成を提案する（非特許文献５参照）。ユーザ了承を得て、再構成を実行する際に、ＧＰＵオフロードするソフトロジックの変更等や、ソフトウェア構成の変更の場合には、更新する実行ファイルを起動する環境を複製後、アプリケーション実行中のデータをマイグレーションする。

<ハードロジック変更>
　再構成を実行する際に、ＦＰＧＡ等のハードロジックを変更する場合は、ソフトウェア構成の変更時と同様に移行先にハードロジックを構成済みのＦＰＧＡを準備し、アプリケーション実行中のデータをマイグレーションする方法と、ＦＰＧＡのハードロジックを運用中に再構成する方法とがある。ＦＰＧＡのハードロジック構成の再構成は、近年のAltera，Xilinxのツールを用いると、運用中の数秒単位での再構成が可能である。ハードロジックの変更は、ＳＱＬＤＢとＮｏＳＱＬのＤＢを両運用している場合に、当初ＳＱＬリクエストが多かったが、ＮｏＳＱＬリクエストが一定よりも増えてきた場合に、ＮｏＳＱＬをアクセラレートするＦＰＧＡにロジックを再構成する等がある。

　以下、オフロードサーバ１の実装を説明する。本実装は、本実施形態の有効性を確認するためのものである。
<実装の動作概要>
　実装の動作概要を説明する。
　実装はPerl 5（Perlバージョン5）で行い、以下の処理を行う。
　下記図８のフローの処理を開始する前に、高速化するアプリケーションとそれを性能測定するベンチマークツールを準備する。

　実装では、アプリケーションの利用依頼があると、まず、アプリケーションのコードを解析して、for文を発見するとともに、for文内で使われる変数データ等の、プログラム構造を把握する。構文解析には、LLVM/Clangの構文解析ライブラリ（libClangのpython binding）等を使用する。

　実装では、最初に、そのアプリケーションがＧＰＵオフロード効果があるかの見込みを得るため、ベンチマークを実行し、上記構文解析で把握したfor文のループ回数を把握する。ループ回数把握には、GNUカバレッジのgcov等を用いる。プロファイリングツールとしては、「GNUプロファイラ(gprof)」、「GNUカバレッジ(gcov)」が知られている。双方とも各行の実行回数を調査できるため、どちらを用いてもよい。実行回数は、例えば、１０００万回以上のループ回数を持つアプリケーションのみ対象とするようにできるが、この値は変更可能である。

　ＣＰＵ向け汎用アプリケーションは、並列化を想定して実装されているわけではない。そのため、まず、ＧＰＵ処理自体が不可なfor文は排除する必要がある。そこで、各for文一つずつに対して、並列処理の#pragma acc kernels ディレクティブ挿入を試行し、コンパイル時にエラーが出るかの判定を行う。コンパイルエラーに関しては、幾つかの種類がある。for文の中で外部ルーチンが呼ばれている場合、ネストfor文で異なる階層が重複指定されている場合、break等でfor文を途中で抜ける処理がある場合、for文のデータにデータ依存性がある場合等がある。アプリケーションによって、コンパイル時エラーの種類は多彩であり、これ以外の場合もあるが、コンパイルエラーは処理対象外とし、#pragmaディレクティブは挿入しない。

　コンパイルエラーは自動対処が難しく、また対処しても効果が出ないことも多い。外部ルーチンコールの場合は、#pragma acc routineにより回避できる場合があるが、多くの外部コールはライブラリであり、それを含めてＧＰＵ処理してもそのコールがネックとなり性能が出ない。for文一つずつを試行するため、ネストのエラーに関しては、コンパイルエラーは生じない。また、break等で途中で抜ける場合は、並列処理にはループ回数を固定化する必要があり、プログラム改造が必要となる。データ依存が有る場合はそもそも並列処理自体ができない。

　ここで、並列処理してもエラーが出ないループ文の数がａの場合、ａが遺伝子長となる。遺伝子の１は並列処理ディレクティブ有、０は無に対応させ、長さａの遺伝子に、アプリケーションコードをマッピングする。

　次に、初期値として、指定個体数の遺伝子配列を準備する。遺伝子の各値は、図５で説明したように、０と１をランダムに割当てて作成する。準備された遺伝子配列に応じて、遺伝子の値が１の場合は並列処理を指定するディレクティブ #pragma acc kernels をC/C++コードに挿入する。この段階で、ある遺伝子に該当するコードの中で、ＧＰＵで処理させる部分が決まる。上記Clangで解析した、for文内の変数データの参照関係をもとに、上述したルールに基づいて、ＣＰＵからＧＰＵへのデータ転送、その逆の場合のディレクティブ指定を行う。
　具体的には、ＣＰＵからＧＰＵへのデータ転送が必要な変数は、 #pragma acc data copyinで指定し（図６参照）、ＧＰＵからＣＰＵへのデータ転送が必要な変数は、 #pragma acc data copyoutで指定する（図７参照）。同じ変数に関して、copyinとcopyoutが重なる場合は、#pragma acc data copyで纏め、記述をシンプルにする。

　並列処理およびデータ転送のディレクティブを挿入されたC/C++コードを、ＧＰＵを備えたマシン上のＰＧＩコンパイラでコンパイルを行う。コンパイルした実行ファイルをデプロイし、ベンチマークツールで性能を測定する。

　全個体数に対して、ベンチマーク性能測定後、ベンチマーク処理時間に応じて、各遺伝子配列の適合度を設定する。設定された適合度に応じて、残す個体の選択を行う。選択された個体に対して、交叉処理、突然変異処理、そのままコピー処理のＧＡ処理を行い、次世代の個体群を作成する。

　次世代の個体に対して、ディレクティブ挿入、コンパイル、性能測定、適合度設定、選択、交叉、突然変異処理を行う。ここで、ＧＡ処理の中で、以前と同じパターンの遺伝子が生じた場合は、その個体についてはコンパイル、性能測定をせず、以前と同じ測定値を用いる。

　指定世代数のＧＡ処理終了後、最高性能の遺伝子配列に該当する、ディレクティブ付きコードを解とする。

　この中で、個体数、世代数、交叉率、突然変異率、適合度設定、選択方法は、ＧＡのパラメータであり、別途指定する。提案技術は、上記処理を自動化することで、従来、専門技術者の時間とスキルが必要だった、ＧＰＵオフロードの自動化を可能にする。

　図８Ａ－Ｂは、上述した実装の動作概要を説明するフローチャートであり、図８Ａと図８Ｂは、結合子で繋がれる。

<コード解析>
　ステップＳ１０１で、アプリケーションコード分析部１１２（図２参照）は、アプリのコード解析を行う。

<ループ文特定>
　ステップＳ１０２で、オフロード処理指定部１１４（図２参照）は、アプリのループ文、参照関係および機能ブロックを特定する。

<ループ文の並列処理可能性>
　ステップＳ１０３で、オフロード処理指定部１１４は、各ループ文の並列処理可能性をチェックする。

<ループ文の繰り返し>
　制御部（環境適応機能部）１１は、ステップＳ１０４のループ始端とステップＳ１０７のループ終端間で、ステップＳ１０５－Ｓ１０６の処理についてループ文の数だけ繰り返す。
　ステップＳ１０５で、オフロード処理指定部１１４は、各ループ文に対して、中間言語でパイプライン処理を指定してコンパイルする。なお、パイプライン処理の一つに並列処理がある。
　ステップＳ１０６で、オフロード処理指定部１１４は、エラー時は、該当ループ文は、対象外とする。
　ステップＳ１０８で、オフロード処理指定部１１４は、コンパイルエラーが出ないループ文の数と機能ブロック数をカウントし、遺伝子長とする。

<指定個体数パターン準備>
　次に、初期値として、オフロード処理指定部１１４は、指定個体数の遺伝子配列を準備する。ここでは、０と１をランダムに割当てて作成する。
　ステップＳ１０９で、オフロード処理指定部１１４は、アプリコードを、遺伝子にマッピングし、指定パターン数準備を行う。
　準備された遺伝子配列に応じて、遺伝子の値が１の場合は並列処理を指定するディレクティブをコードに挿入する（例えば図５（ｂ）の#pragmaディレクティブ参照）。

　制御部（環境適応機能部）１１は、ステップＳ１１０のループ始端とステップＳ１１８のループ終端間で、ステップＳ１１１－Ｓ１１８の処理について指定世代数繰り返す。
　また、上記指定世代数繰り返しにおいて、さらにステップＳ１１１のループ始端とステップＳ１１５のループ終端間で、ステップＳ１１２－Ｓ１１４の処理について指定個体数繰り返す。すなわち、指定世代数繰り返しの中で、指定個体数の繰り返しが入れ子状態で処理される。

<データ転送指定>
　ステップＳ１１２で、データ転送指定部１１３は、変数参照関係をもとに、データ転送指定し、特定パターンで並列、パイプライン処理、機能ブロックのオフロードを指定したアプリの中間言語を作成する。
　上記ステップＳ１１２において、ループ文特定するところまでは共通処理であり、その後、ＧＰＵ、ＦＰＧＡ、パイプライン処理、またはＦＦＴ処理などの機能ブロックに対応した処理を行う。例えば、ＧＰＵの際は並列処理を行う、ＦＰＧＡの際は並列処理やパイプライン処理を行う、ＦＦＴ処理などの機能ブロックであればオフロード用の中間言語を作成する。
　なお、パイプライン処理の一つである並列処理を例にとり、明示的指示行（#pragma acc data copy/in/out）を用いたデータ転送指定について、図６－図７により説明した。

<コンパイル>
　ステップＳ１１３で、検証環境用性能測定部１１９（図２参照）は、ＣＰＵ-ＧＰＵ搭載の検証用マシン１４に、中間言語をもとに実行ファイルを配置する。
　ステップＳ１１４で、検証環境用性能測定部１１９は、配置したバイナリファイルを実行し、テストケース性能を測定する。

　ここで、途中世代で、以前と同じパターンの遺伝子については測定せず、同じ値を使う。つまり、ＧＡ処理の中で、以前と同じパターンの遺伝子が生じた場合は、その個体についてはコンパイルや性能測定をせず、以前と同じ測定値を用いる。
　ステップＳ１１６で、実行ファイル作成部１２０（図２参照）は、処理時間が短いパターンほど適合度が高くなるように評価し、性能の高いパターンを選択する。

　ステップＳ１１７で、実行ファイル作成部１２０は、選択パターンに対して、交叉、突然変異の処理を行い、次世代のパターンを作成する。次世代のパターンに対して、コンパイル、性能測定、適合度設定、選択、交叉、突然変異処理を行う。
　すなわち、全個体に対して、ベンチマーク性能測定後、ベンチマーク処理時間に応じて、各遺伝子配列の適合度を設定する。設定された適合度に応じて、残す個体の選択を行う。選択された個体に対して、交叉処理、突然変異処理、そのままコピー処理のＧＡ処理を行い、次世代の個体群を作成する。

　ステップＳ１１９で、実行ファイル作成部１２０は、指定世代数のＧＡ処理終了後、最高性能の遺伝子配列に該当するコード（最高性能のオフロードパターン）を解とする。

<ＧＡのパラメータ>
　上記、個体数、世代数、交叉率、突然変異率、適合度設定、選択方法は、ＧＡのパラメータである。ＧＡのパラメータは、例えば、以下のように設定してもよい。
　実行するSimple GAの、パラメータ、条件は例えば以下のようにできる。
　遺伝子長：並列可能ループ文数
　個体数Ｍ：遺伝子長以下
　世代数Ｔ：遺伝子長以下
　適合度：(処理時間)^(-1/2)
　この設定により、ベンチマーク処理時間が短い程、高適合度になる。また、適合度を、処理時間の(-1/2)乗とすることで、処理時間が短い特定の個体の適合度が高くなり過ぎて、探索範囲が狭くなるのを防ぐことができる。また、性能測定が一定時間で終わらない場合は、タイムアウトさせ、処理時間１０００秒等の時間（長時間）であるとして、適合度を計算する。このタイムアウト時間は、性能測定特性に応じて変更させればよい。
　選択：ルーレット選択
　ただし、世代での最高適合度遺伝子は交叉も突然変異もせず次世代に保存するエリート保存も合わせて行う。
　交叉率Ｐｃ：０．９
　突然変異率Ｐｍ：０．０５

<コストパフォーマンス>
　自動オフロード機能のコストパフォーマンスについて述べる。
　NVIDIA Tesla（登録商標）等の、ＧＰＵボードのハードウェアの価格だけを見ると、ＧＰＵを搭載したマシンの価格は、通常のＣＰＵのみのマシンの約２倍となる。しかし、一般にデータセンタ等のコストでは、ハードウェアやシステム開発のコストが１／３以下であり、電気代や保守・運用体制等の運用費が１／３超であり、サービスオーダ等のその他費用が１／３程度である。本実施形態では、暗号処理や画像処理等動作させるアプリケーションで時間がかかる処理を２倍以上高性能化できる。このため、サーバハードウェア価格自体は２倍となっても、コスト効果が十分に期待できる。

　本実施形態では、gcov，gprof等を用いて、ループが多く実行時間がかかっているアプリケーションを事前に特定して、オフロード試行をする。これにより、効率的に高速化できるアプリケーションを見つけることができる。

<本番サービス利用開始までの時間>
　本番サービス利用開始までの時間について述べる。
　コンパイルから性能測定1回は３分程度とすると、２０の個体数、２０の世代数のＧＡで最大２０時間程度解探索にかかるが、以前と同じ遺伝子パターンのコンパイル、測定は省略されるため、８時間以下で終了する。多くのクラウドやホスティング、ネットワークサービスではサービス利用開始に半日程度かかるのが実情である。本実施形態では、例えば半日以内の自動オフロードが可能である。このため、半日以内の自動オフロードであれば、最初は試し利用ができるとすれば、ユーザ満足度を十分に高めることが期待できる。

　より短時間でオフロード部分を探索するためには、複数の検証用マシンで個体数分並列で性能測定することが考えられる。アプリケーションに応じて、タイムアウト時間を調整することも短時間化に繋がる。例えば、オフロード処理がＣＰＵでの実行時間の２倍かかる場合はタイムアウトとする等である。また、個体数、世代数が多い方が、高性能な解を発見できる可能性が高まる。しかし、各パラメータを最大にする場合、個体数×世代数だけコンパイル、および性能ベンチマークを行う必要がある。このため、本番サービス利用開始までの時間がかかる。本実施形態では、ＧＡとしては少ない個体数、世代数で行っているが、交叉率Ｐｃを０．９と高い値にして広範囲を探索することで、ある程度の性能の解を早く発見するようにしている。

　以上説明したように、本実施形態に係るオフロードサーバ１（図２参照）は、アプリケーションのソースコードを分析するアプリケーションコード分析部１１２と、アプリケーションの並列処理可能なループ文、特定処理の機能ブロック、ライブラリ呼び出しを含むオフロード可能な処理を特定するオフロード処理指定部１１４と、配置先環境に合わせたコード変換をするオフロードパターン作成部１１５（コード変換部）と、コード変換されたアプリケーションをコンパイルして、検証用マシン１４に配置し、検証用マシン１４にオフロードした際の性能測定用処理を実行する検証環境用性能測定部１１９と、を反復し、配置先環境に合わせたリソース量の設定を行うリソース量指定部１１７と、オフロードパターン作成部１１５がコード変換した変換コードを、リソース量指定部１１７が設定したリソース量を確保して配置する際に、性能およびコストをもとに配置先を計算して配置場所を選択する配置先計算部１１８と、実行ファイル配置後、本番環境性能測定テスト抽出部１２２が抽出した性能試験項目を、運用装置１５を用いて自動実行する本番環境性能測定テスト実行部１２３と、コード変換ステップ、リソース量設定ステップ、配置場所選択ステップ、性能測定ステップ、性能測定テストステップのいずれか一つ以上のステップを実行する環境適応処理を行う制御部１１（環境適応機能部）と、を備える。

　この構成により、ＧＰＵ，ＦＰＧＡ，ＩｏＴデバイス等環境が多様になる中で、アプリケーションを環境に合わせて適応させ、ＧＰＵやＦＰＧＡを適切に活用し、高性能にアプリケーションを動作させることができる。また、一度記述したソフトウェアを、異なる環境でも高性能に動作させることができる。

　本実施形態では、オフロード処理指定部１１４は、遺伝的アルゴリズムに基づき、コンパイルエラーが出ないループ文の数を遺伝子長とし、オフロードパターン作成部は、アクセラレータ処理をする場合を１または０のいずれか一方、しない場合を他方の０または１として、アクセラレータ処理可否を遺伝子パターンにマッピングし、遺伝子の各値を１か０にランダムに作成した指定個体数の遺伝子パターンを準備し、検証環境用性能測定部１１９は、各個体に応じて、アクセラレータにおける並列処理指定文を指定したアプリケーションコードをコンパイルして、検証用マシン１４に配置し、検証用マシン１４において性能測定用処理を実行する。実行ファイル作成部１２０は、全個体に対して、性能測定を行い、処理時間の短い個体ほど適合度が高くなるように評価し、全個体から、適合度が所定値より高いものを性能の高い個体として選択し、選択された個体に対して、交叉、突然変異の処理を行い、次世代の個体を作成し、指定世代数の処理終了後、最高性能のオフロードパターンを解として選択する。

　このように、最初に並列可能なループ文のチェックを行い、次に並列可能繰り返し文群に対してＧＡを用いて検証環境で性能検証試行を反復し適切な領域を探索する。並列可能なループ文（例えばfor文）に絞った上で、遺伝子の部分の形で、高速化可能なオフロードパターンを保持し組み換えていくことで、取り得る膨大なオフロードパターンから、効率的に高速化可能なパターンを探索できる。

　本実施形態では、配置先環境がＦＰＧＡを備え、オフロード処理指定部１１４は、機能ブロック処理、ライブラリ呼び出しを含むアプリケーションの処理構造から、コードパターンＤＢを参照して、機能ブロック処理、ライブラリ呼び出しを含むＦＰＧＡにオフロード可能な処理を特定し、コードパターンＤＢからオフロードに該当する中間言語の定義情報を、アプリケーションソースコードに置換する。

　本実施形態では、リソース量指定部１１７は、アプリケーションテストケースの処理時間から、ＣＰＵとオフロード先の処理時間が同等のオーダーになるように、ＣＰＵとオフロード先のリソース比を定め、リソース比を決定後は、想定するテストケースの処理性能が、要求性能およびコスト要求を満たすようにリソース比はキープしつつ、リソース量を設定する。

　本実施形態では、配置先計算部１１８は、アプリケーションテストケースの結果から、アプリケーションを配置した際の計算量と発生トラフィックを算出し、クラウド、エッジ、Home ＧＷを含むリンク関係をモデル化し、アプリケーションを特定のノードに配置した際に、コストが要求条件に収まることを制約条件に、処理遅延および／またはスループットの性能を最大化する配置、あるいは性能が要求条件を満たす形でコストが最低になる配置のいずれかを線形計画手法を用いて計算する。

　この構成により、処理遅延、スループットの性能の最大化、または性能が要求条件を満たす形でコストが最低になる配置場所を選択することができる。

　本実施形態では、アプリケーション運用開始後に、当初期待していた性能が出ない場合に、ソフトウェア設定を再構成する再構成実行部１２６を備える。

　この構成により、ユーザに再構成を提案して、ユーザ了承を得た場合には、アプリケーション実行環境をマイグレーションすることができる。

　本実施形態では、再構成実行部１２６が、コード変換処理を、周期的、または、性能がある閾値以下となった場合に試行模擬し、コード変換して、ＧＰＵオフロードのソフトロジック変更やＦＰＧＡのハードロジックの変更で、性能やコストが改善できる見込みがある場合は、ユーザに再構成を提案し、ユーザ了承を得て、再構成を実行する際に、ＧＰＵオフロードするソフトロジックの変更を行う。ソフトウェア構成の変更の場合は、マイグレーション処理部１２６ｂが、更新する実行ファイルを起動する環境を複製後、アプリケーションのデータのマイグレーションを行い、ＦＰＧＡのハードロジックを変更する場合は、マイグレーション処理部１２６ｂが、移行先にハードロジックを構成済みのＦＰＧＡを準備しＦＰＧＡを制御するコンテナ等をマイグレーションを行う、もしくは、再構成実行部が、ＦＰＧＡのハードロジックを再構成する。

　この構成により、ユーザに再構成を提案して、ユーザ了承を得た場合、ソフトウェア構成の変更のときは、アプリケーションのデータのマイグレーションを、またハードロジックを構成済みのＦＰＧＡを準備しＦＰＧＡを制御するコンテナ等をマイグレーションすることができる。

　また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手作業で行うこともでき、あるいは、手作業で行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。

　また、本実施形態では、組合せ最適化問題を、限られた最適化期間中に解を発見できるようにするため、遺伝的アルゴリズム（ＧＡ）の手法を用いているが、最適化の手法はどのようなものでもよい。例えば、local search（局所探索法）、Dynamic Programming（動的計画法）、これらの組み合わせでもよい。

　また、本実施形態では、C/C++向けOpenＡＣＣコンパイラを用いているが、ＧＰＵ処理をオフロードできるものであればどのようなものでもよい。例えば、Java lambda（登録商標） GPU処理、IBM Java 9 SDK（登録商標）でもよい。なお、並列処理指定文は、これらの開発環境に依存する。
　例えば、Java（登録商標）では、Java 8よりlambda形式での並列処理記述が可能である。IBM（登録商標）は、lambda形式の並列処理記述を、ＧＰＵにオフロードするJITコンパイラを提供している。Javaでは、これらを用いて、ループ処理をlambda形式にするか否かのチューニングをＧＡで行うことで、同様のオフロードが可能である。

　また、本実施形態では、繰り返し文（ループ文）として、for文を例示したが、for文以外のwhile文やdo-while文も含まれる。ただし、ループの継続条件等を指定するfor文がより適している。

　１　オフロードサーバ
　１１　制御部
　１２　入出力部
　１３　記憶部
　１４　検証用マシン（アクセラレータ検証用装置）
　１５　運用装置
　１５　OpenＩｏＴリソース
　１１１　アプリケーションコード指定部
　１１２　アプリケーションコード分析部
　１１３　データ転送指定部
　１１４　オフロード処理指定部
　１１４ａ　オフロード可能部抽出部
　１１４ｂ　中間言語ファイル出力部
　１１５　オフロードパターン作成部
　１１６　リソース量計算部（リソース量設定部）
　１１７　リソース量指定部（リソース量設定部）
　１１８　配置先計算部（配置場所選択部）
　１１９　検証環境用性能測定部
　１２０　実行ファイル作成部
　１２１　本番環境配置部
　１２２　本番環境性能測定テスト抽出部
　１２３　本番環境性能測定テスト実行部
　１２４　再構成必要性定期チェック部
　１２５　再構成シミュレーション試算部
　１２６　再構成実行部
　１２６ａ　再構成先構築部
　１２６ｂ　マイグレーション処理部
　１２７　ユーザ提供部
　１３０　アプリケーションコード
　１３１　テストケースＤＢ
　１３２　コードパターンＤＢ
　１３３　設備リソースＤＢ
　１３４　中間言語ファイル
　１５１　ＩｏＧＷを有する装置
　１５２　ＣＰＵ-ＧＰＵを有する装置
　１５３　ＣＰＵ-ＦＰＧＡを有する装置
　１５４　ＣＰＵを有する装置

Claims

　アプリケーションの特定処理をアクセラレータにオフロードするオフロードサーバのソフトウェア最適配置方法であって、
　前記オフロードサーバは、
　アプリケーションのソースコードを分析するアプリケーションコード分析ステップと、
　前記アプリケーションの並列処理可能なループ文、特定処理の機能ブロック、ライブラリ呼び出しを含むオフロード可能な処理を特定するオフロード処理指定ステップと、
　配置先環境に合わせたコード変換をするコード変換ステップと、
　コード変換された前記アプリケーションをコンパイルして、アクセラレータ検証用装置に配置し、前記アクセラレータ検証用装置にオフロードした際の性能測定用処理を実行する検証環境用性能測定ステップと、を反復し、
　前記配置先環境に合わせたリソース量の設定を行うリソース量設定ステップと、
　前記コード変換ステップがコード変換した変換コードを、前記リソース量設定ステップが設定したリソース量を確保して配置する際に、性能およびコストをもとに配置先を計算して配置場所を選択する配置場所選択ステップと、
　本番環境配置後に、前記アプリケーションをコンパイルして、運用装置に配置し、前記運用装置にオフロードした実際の性能測定テストを実行する性能測定テストステップと、を備え、
　前記コード変換ステップ、前記リソース量設定ステップ、前記配置場所選択ステップ、前記検証環境用性能測定ステップ、前記性能測定テストステップのいずれか一つ以上のステップを実行する
　ことを特徴とするオフロードサーバのソフトウェア最適配置方法。
　コンパイルエラーが出るループ文に対して、オフロード対象外とするとともに、コンパイルエラーが出ないループ文に対して、オフロード処理するかしないかの指定を行うオフロード処理パターンを作成するオフロードパターン作成ステップと、
　所定回数繰り返された、性能測定結果をもとに、複数のオフロードパターンから最高処理性能のオフロードパターンを選択し、最高処理性能のオフロードパターンをコンパイルして実行ファイルを作成する実行ファイル作成ステップと、をさらに有し、
　前記オフロード処理指定ステップにおいて、遺伝的アルゴリズムに基づき、
　コンパイルエラーが出ないループ文の数を遺伝子長とし、
　前記オフロードパターン作成ステップにおいて、アクセラレータ処理をする場合を１または０のいずれか一方、しない場合を他方の０または１として、アクセラレータ処理可否を遺伝子パターンにマッピングし、
　前記遺伝子の各値を１か０にランダムに作成した指定個体数の前記遺伝子パターンを準備し、
　前記性能測定ステップにおいて、各個体に応じて、前記アクセラレータにおける並列処理指定文を指定したアプリケーションコードをコンパイルして、前記アクセラレータ検証用装置に配置し、
　前記アクセラレータ検証用装置において性能測定用処理を実行し、
　前記実行ファイル作成ステップにおいて、全個体に対して、性能測定を行い、処理時間の短い個体ほど適合度が高くなるように評価し、
　全個体から、前記適合度が所定値より高いものを性能の高い個体として選択し、
　選択された個体に対して、交叉、突然変異の処理を行い、次世代の個体を作成し、
　指定世代数の処理終了後、最高性能の前記オフロードパターンを解として選択する
　ことを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法。
　前記配置先環境が、前記アクセラレータとしてＦＰＧＡ（Field Programmable Gate Array）を備え、
　前記オフロード処理指定ステップにおいて、
　機能ブロック処理、ライブラリ呼び出しを含むアプリケーションの処理構造から、コードパターンＤＢを参照して、機能ブロック処理、ライブラリ呼び出しを含む前記ＦＰＧＡにオフロード可能な処理を特定し、前記コードパターンＤＢからオフロードに該当する中間言語の定義情報を、アプリケーションソースコードに置換する
　ことを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法。
　前記リソース量設定ステップにおいて、
　アプリケーションテストケースの処理時間から、ＣＰＵとオフロード先の処理時間が同等のオーダーになるように、ＣＰＵとオフロード先のリソース比を定め、
　前記リソース比の決定後は、想定するテストケースの処理性能が、要求性能およびコスト要求を満たすように前記リソース比はキープしつつ、リソース量を設定する
　ことを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法。
　前記配置場所選択ステップにおいて、
　アプリケーションテストケースの結果から、アプリケーションを配置した際の計算量と発生トラフィックを算出し、
　クラウド、エッジ、Home ＧＷ（gateway）を含むリンク関係をモデル化し、アプリケーションを特定のノードに配置した際に、コストが要求条件に収まることを制約条件に、処理遅延および／またはスループットの性能を最大化する配置、あるいは性能が要求条件を満たす形でコストが最低になる配置のいずれかを計算する
　ことを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法。
　アプリケーション運用開始後に、当初期待していた性能が出ない場合に、ソフトウェア設定を再構成する再構成実行ステップを有し、
　前記再構成実行ステップにおいて、
　ソフトウェア設定の変更では、リソース量設定、配置場所選択の試行計算を周期的、または、性能がある閾値以下となった場合に試行模擬し、性能向上やコスト低減度合を計算し、リソース量の変更や配置場所の変更で性能やコストが改善できる見込みがある場合に、ユーザに再構成を提案し、ユーザ了承を得て、再構成を実行する場合に、リソースを変更する再構成先構築ステップと、
　配置場所変更の際、移行先環境を複製して、そこに移行元からアプリケーション実行環境をマイグレーションするマイグレーション処理ステップと、を実行する
　ことを特徴とする請求項１に記載のオフロードサーバのソフトウェア最適配置方法。
　前記再構成実行ステップにおいて、コード変換処理を、周期的、または、性能がある閾値以下となった場合に試行模擬し、コード変換して、ＧＰＵオフロードのソフトロジック変更および／またはＦＰＧＡ（Field Programmable Gate Array）のハードロジックの変更で、性能やコストが改善できる見込みがある場合は、ユーザに再構成を提案し、ユーザ了承を得て、再構成を実行する際に、ＧＰＵオフロードするソフトロジックの変更を行い、
　ソフトウェア構成の変更の場合は、前記マイグレーション処理ステップが、更新する実行ファイルを起動する環境を複製後、アプリケーションのデータのマイグレーションを行い、
　ＦＰＧＡのハードロジックを変更する場合は、前記マイグレーション処理ステップにおいて、移行先にハードロジックを構成済みのＦＰＧＡを準備し当該ＦＰＧＡを制御するコンテナのマイグレーションを行う、もしくは、前記再構成実行ステップにおいて、当該ＦＰＧＡのハードロジックを再構成する
　ことを特徴とする請求項６に記載のオフロードサーバのソフトウェア最適配置方法。
　コンピュータを、請求項１乃至請求項７のうちいずれか１項に記載のオフロードサーバのソフトウェア最適配置方法として機能させるためのプログラム。