JPWO2020045269A1 - システム、情報処理方法、及びプログラム - Google Patents

Abstract

異種混在の複数のデバイスを用いた場合であっても、中間コード等を用いずに情報処理の速度を向上させることができるシステム、情報処理方法、及びプログラムを提供する。システム１は、ソースコードを取得するソース取得部２００と、所定のＡＰＩを用い、演算ロジックをソースコード中から特定する演算ロジック特定部２０２と、ソースコードに基づいて指定されるプロセッサーのコンパイラに演算ロジックを供給する演算ロジック供給部２０８と、オブジェクトストレージ４００が、指定されるプロセッサーのコンパイラによってコンパイルされた結果を実行イメージとして格納し、オブジェクトストレージ４００に格納されている指定されるプロセッサーにおける実行イメージへのパスと、指定されるプロセッサーとを対応付けたプロセッサー対応表を作成してオブジェクトストレージ４００に格納する対応表作成部２１０と、演算ロジック供給部２０２が供給した演算ロジックと、オブジェクトストレージ４００に格納されているプロセッサー対応表の保存パスとを対応付けた対応関係をオブジェクトストレージ４００に格納する対応関係決定部２１２とを備える。

Description

本発明は、システム、情報処理方法、及びプログラムに関する。特に、本発明は、演算ロジックを各種ストレージ上で直接実行させることができるシステム、情報処理方法、及びプログラムに関する。

従来、複数の計算機を備え、ジョブを複数の計算機に分散して実行させる負荷分散システムにおいて、複数の計算機がジョブを実行するためにアクセスするストレージと、複数の計算機のうち、負荷が少ない計算機にジョブを実行させる、第１の管理装置と、複数のジョブを受付け、当該受付けた複数のジョブをキューイングして、第１のジョブキューに順番に格納する、第２の管理装置と、第１のジョブキューのジョブを順番に取り出し、計算機が取り出したジョブを実行するのに必要なデータに対する処理をストレージ装置に対して実行する第３の管理装置と、処理が終了した複数のジョブを、計算機によって実行されることを待つ実行待ちジョブとして順番に格納する、第２のジョブキューとを備え、第１の管理装置は、第２のジョブキューから複数のジョブを順番に取り出し、当該取り出したジョブを計算機に実行させる負荷分散システムが知られている（例えば、特許文献１参照。）。特許文献１に記載の負荷分散システムによれば、計算機能力を最大限に使用してジョブを実行するための処理時間を短縮することができる。

特開２００８−１５８８８号公報

特許文献１に記載のような従来の負荷分散システムにおいては、処理対象のデータ分割サイズによってはデータ処理効率が低下する。例えば、従来の負荷分散システムにおいては、ストレージからコンピューターのプロセッサーにデータを供給し、ジョブを実行させるので、数キロバイト程度に分割されたデータを用いる場合はともかく、数ギガバイト以上の連続した大容量データではデータ処理効率は大幅に低下する。

したがって、本発明の目的は、数ギガバイト以上の連続した大容量データを用いた場合においてデータ処理効率を低下させないために、各種ストレージ上で直接、データ処理を実行させることができるシステム、情報処理方法、及びプログラムを提供することにある。

本発明は、上記目的を達成するため、オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムであって、ソースコードを取得するソース取得部と、所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用い、演算ロジックをソースコード中から特定する演算ロジック特定部と、ソースコードに基づいて指定されるプロセッサーのコンパイラに演算ロジックを供給する演算ロジック供給部と、オブジェクトストレージが、指定されるプロセッサーのコンパイラによってコンパイルされた結果を実行イメージとして格納し、オブジェクトストレージに格納されている指定されるプロセッサーにおける実行イメージへのパスと、指定されるプロセッサーとを対応付けたプロセッサー対応表を作成してオブジェクトストレージに格納する対応表作成部と、演算ロジック供給部が供給した演算ロジックと、オブジェクトストレージに格納されているプロセッサー対応表の保存パスとを対応付けた対応関係をオブジェクトストレージに格納する対応関係決定部とを備えるシステムが提供される。

本発明に係るシステム、情報処理方法、及びプログラムによれば、数ギガバイト以上の連続した大容量データを用いた場合においてデータ処理効率を低下させないために、各種ストレージ上で直接、データ処理を実行させることができるシステム、情報処理方法、及びプログラムを提供できる。

本実施形態に係るシステムのアーキテクチャの概要図である。 本実施形態に係るシステムの機能構成ブロック図である。 本実施形態に係るユーザーアプリケーション、プロセッサー対応表、及び対応関係の構成の概要図である。 本実施形態に係るシステムにおける処理のフロー図である。 本実施形態に係るシステムにおける処理のフロー図である。 本実施形態に係るシステムにおける処理のフロー図である。 （ａ）は従来のＡｐａｃｈｅ Ｓｐａｒｋの演算の概要図であり、（ｂ）は本実施形態の他の例に係るシステムにおける演算の概要図である。

［実施の形態］
＜システム１の概要＞
従来の負荷分散システムにおいては、１つ以上のストレージからデータを読み込み、複数のプロセッサーを用いて分散処理する。つまり、所定のストレージから所定のコンピューターのプロセッサーにデータを供給し、ジョブを実行させる。したがって、数キロバイト程度の小容量データを扱う場合（例えば、ビックデータを扱う場合）においては従来の負荷分散システムであってもデータ処理効率は低下しにくい。しかしながら、数ギガバイト以上の連続した大容量データを扱う場合、従来の負荷分散システムではデータ処理効率が大幅に低下する。すなわち、従来の負荷分散システム（例えば、特開２００８−１５８８８号公報記載のシステム等）においては、ストレージから所定のコンピューターがデータを読み込み、このコンピューターが読み込んだデータを更に他のコンピューターが連続して読み込むことでジョブを実行していくので、大容量データを扱う場合のデータ処理効率は大幅に低下する。

そこで、本発明者は発想を転換し、データの供給方向（すなわち、ルーチン若しくはジョブの供給方向）を逆にすることに想到した。例えば、ユーザーアプリケーションから所定のコンピューターにルーチン若しくはジョブを供給し、当該コンピューターからストレージにルーチン若しくはジョブを供給して当該ストレージ上でルーチン若しくはジョブを直接処理することでデータ処理効率の向上を実現できることに想到した。すなわち、本発明に係るシステムは、ユーザーアプリケーション内のデータを扱うルーチンの実行コードをストレージ上のＩＯコントローラーに供給し、ストレージ上でデータ処理を直接実行するという構成であり、ユーザーアプリケーションが動作するクラウドとルーチンが実行されるエッジとの双方で同時に分散処理されるシステムである。

従来はエッジで扱われる異種混在の様々なデバイスに対応するため従来の仮想ハードウエア等で用いる中間コードを生成する必要があったが、本発明者が想到した構成によれば、中間コードを用いることを必ずしも要せず、所定のデータ処理用の実行コードをクラウドで生成することができるので（なお、実行コードはクラウドにおいて保存可能である。）、中間コードより処理効率の高い実行コード（すなわち、ストレージ用のジョブ・ルーチン）をクラウド上のユーザーアプリケーションより切り出して、ストレージ上でデータ処理を直接、実行することができる。

なお、複数のデバイス（なお、デバイスにはストレージを含む）のプロセッサーのそれぞれに所定の演算ロジックを実行させる場合、当該デバイスの種類により機械語が異なるので、当該演算ロジックが一のデバイスで実行できたとしても他のデバイスで実行できるとは限らない。そのため、従来は、仮想ハードウエアを定義し、仮想ハードウエアで実行される中間コードに演算ロジックをコンパイルすることで異種混在のデバイスでこの演算ロジックが動作するようにしている。つまり、異種混在の様々なデバイスのプロセッサーは、仮想ハードウエアを実現するバーチャルマシンを実装し、バーチャルマシンで中間コードを読み込こんで演算ロジックを実行する。

しかし、係る方式においてはバーチャルマシンを経由する分、処理速度が低下する。そのため、従来の方式においては、演算ロジックを実行する前に中間コードのすべてをプロセッサー向けの機械語に変換する特定のコンパイラ（例えば、Ｊｕｓｔ−ｉｎ−ｔｉｍｅ（ＪＩＴ）コンパイラ）を用いることで処理速度を高速化している。但し、係る方式であっても、中間コードを必須とするため、高速化には限界がある。

一方、本発明者が想到した構成によれば、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを用いる場合に、演算ロジックをソースコードのままクラウドで保持し、複数のデバイスのプロセッサーのそれぞれにおいて、複数のデバイス用に演算ロジックをコンパイルすることで実行イメージを予め作成し、作成した実行イメージをクラウドに保存して、演算ロジックの実行指示がなされたときにこの保存してある実行イメージをデバイスにダウンロードして実行させることもできる。

よって、従来の形式とはデータの供給方向を逆にした本実施形態に係るシステム１は、オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムである。そして、本実施形態に係るシステム１は、演算ロジックをソースコードのまま保持し、複数のデバイスのプロセッサーのそれぞれにおいて、複数のデバイス用に演算ロジックをコンパイルすることで実行イメージを作成し、作成した実行イメージをオブジェクトストレージに格納しておき、演算ロジックが複数のデバイスのうちの一のデバイスに呼び出された場合、一のデバイス用に作成された実行イメージをオブジェクトストレージから一のデバイスに供給して実行させるシステム（以下、「実行イメージ供給システム」と称する場合がある。）である。

本実施形態に係るシステム１によれば、数ギガバイトの連続した大容量データを用いる場合であっても、ストレージ上で直接、演算処理を実行できるので、データ処理効率を従来技術よりも大幅に向上させることができる。また、システム１によれば、バーチャルマシンを経由しないので処理速度が大幅に向上する。更に、本実施形態に係るシステム１によれば、例えば、Ｊａｖａ（登録商標）等におけるオーバーヘッドをなくすことができることから処理速度を更に向上させることができ、また、ハードウエアの機能を完全に活用することもできる。

＜システム１の詳細＞
図１は、本発明の実施の形態に係るシステムのアーキテクチャの概要の一例を示す。また、図２は、本発明の実施の形態に係るシステムの機能構成の概要の一例を示す。

［システム１のアーキテクチャの概要］
図１及び図２に示すように、本実施形態に係るシステム１は、プロキシ側システム２と、スタブ側システム３と、オブジェクトストレージ４００に格納されシステム１（具体的には、プロキシ側システム２）に呼び出されるユーザーアプリケーション６００とを備え、異種混在の複数のデバイス５の少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムである。ユーザーアプリケーション６００は、予め定められた演算ロジックをソースコード中に有する。

なお、図２では説明を簡略化するためデバイス５は１つのみ図示しているが、デバイス５は複数存在していてもよく、複数のデバイス５はそれぞれ、異なる機械語で動作するデバイスであってよい。デバイス５は、例えば、各種の格納装置や記録装置（すなわち、ストレージ）、周辺装置を制御部やプロセッサーに接続して制御するＩＯコントローラー等である。また、ユーザーアプリケーション６００としては、様々な処理を実行するアプリケーションが挙げられ、例えば、各種のユーティリティアプリケーション、各種の計算用アプリケーション、静止画や動画の画像処理アプリケーション、プログラミング用アプリケーション等が挙げられる。

図１に示すように、プロキシ側システム２は、制御部５０を有し、スタブ側システム３において消費されるメモリ量を測定若しくは推定する機能（消費メモリ測定・推定機能）と、異種混在の複数のデバイスそれぞれのプロセッサーに所定の演算ロジックを供給してコンパイルさせて得られる実行イメージをオブジェクトストレージ４００やＧＰＧＰＵ ＳａａＳ４１０に格納させる機能（変換処理機能）と、複数のデバイスのうちいずれのデバイスについて実行イメージを既に作成しているか否かを管理する機能（デバイス管理機能）と、スタブ側システム３にキュー１０等を用いて所定の情報を供給する機能（送信処理機能）と、演算ロジックからオブジェクトストレージ４００等の格納部へのデータアクセスに不正な構文が存在するか否かを確認する機能（ストレージ統合管理機能）とを有する。プロキシ側システム２に読み込まれたユーザーアプリケーション６００は、所定のＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）１００によって演算ロジックの特定等の処理が施される。そして、システム１は、ＳＹＣＬ及びＯｐｅｎＣＬ等の言語を用い、演算ロジックを、制御部５０によって実行できる形式に変換することもできる。なお、オブジェクトストレージ４００及びＧＰＧＰＵ ＳａａＳ４１０は、Ｐｕｂｌｉｃ ＰａａＳ４である。

また、スタブ側システム３は、プロキシ側システム２からの情報を受け取る機能（受信処理機能）と、ストレージを管理する機能（ストレージ機能）と、演算ロジックが実行される環境を準備する機能（メモリ管理機能）と、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を管理する機能（ＵＲＩ管理機能）とを有する。スタブ側システム３は、プロキシ側システム２から受け取った情報に基づいて、演算ロジックを実行先（例えば、ＡＲＭ Ｍａｌｉ、ＦＰＧＡ、Ｘｅｏｎ Ｐｈｉ、ｎＶｉｄｉａ ＧＰＵ等のデバイス。なお、ｎＶｉｄｉａ ＧＰＵ１６は、専用バス１４を介してスタブ側システム３から情報を受け取る。）で実行させる。例えば、スタブ側システム３は、メモリ管理機能が準備した実行環境において、受信処理機能において受信した実行イメージに基づいてＯｐｅｎＣＬ、Ｃｅｐｈ及びＲＡＤＯＳ等を利用して実行先のデバイスで演算ロジックに基づいた処理を実行させる。実行先のデバイスとしては、例えば、ＳＳＤが挙げられ、ＳＳＤはＳＳＤ Ｃｏｎｔｒｏｌｌｅｒ２０に制御される。また、ＳＳＤからＮＶＭ Ｅｘｐｒｅｓｓ（ＮＶＭｅ３０）に基づいた論理デバイスに演算結果等を供給することもできる。なお、プロキシ側システム２とスタブ側システム３とは、例えば、分散ストレージソフトウエア（Ｃｅｐｈ１２）によって互いにデータのやり取りを実行できる。

［システム１で用いられるデータの指定方法の概要］
まず、本実施形態に係るシステム１においては、データの指定方法として特定の指定方法を採用することが好ましい。

すなわち、従来のコンピュータープログラムは、複数のルーチンがポインタと呼ばれる物理アドレスを受け渡し、Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＤＲＡＭ）上のデータを複数のルーチン間で共有して利用したり、加工したりして動作する。そのため、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）等のメモリヒエラルキー下層のデータを一度、ＤＲＡＭに転送することを要する。ここで、ＤＲＡＭとＳＳＤとの間で扱うデータ量が増大すると、従来の方式では十分な転送速度を確保できず、ＤＲＡＭへのデータ転送がデータ処理のボトルネックとなっている。

そこで、システム１においては、上記ボトルネックを解消する観点から、物理アドレスでの管理ではなく、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）での管理を用いることが好ましい。すなわち、システム１は、制御部５０と、データ位置（例えば、物理アドレスや各種の格納部の番地、ＩＯコントローラーの番号等）で示される番地にデータを格納する格納部（例えば、ＤＲＡＭやＳＳＤ等、及びオブジェクトストレージ４００等）とを備える。

システム１では、データへアクセスするポインタとして、所定のスキームと所定の区切り（例えば、「：」（コロン）等）の後にスキーム毎に定義された書式によるリソースとが対応付けられているＵＲＩを用いる。つまり、本実施形態に係るシステム１においては、コンピューター内部のデータ位置を指し示すポインタを物理アドレスからＵＲＩに変更若しくは置換して用いることで、制御部５０が処理できるデータの位置を「拡張」する。換言すれば、システム１においては、データ位置の代わりにＵＲＩを用いる。なお、ポインタは、コンピュータープログラムが、ルーチン間で処理するデータの位置を受け渡す場合に用いる付票である。

（制御部５０）
制御部５０は、システム１のプロキシ側システム２における各種のデータ処理等を制御する。制御部５０は格納部に働きかけて、格納部に格納されているデータの転送、処理等、及び所定のアプリケーション（例えば、ユーザーアプリケーション６００）の制御を実行する。制御部５０は、例えば、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）の論理回路を有して構成される。

制御部５０は、ＵＲＩに対応付けられているスキームによって指定される所定のアプリケーションを制御して起動させる。そして、制御部５０は、ＵＲＩのリソースをアプリケーションに渡す。続いて、アプリケーションは、リソースに基づいてＵＲＩをデータ位置として用い、ＵＲＩで指定されて格納部に格納されるデータを制御する。なお、制御部５０は、ＵＲＩに対応付けられているスキームに基づいて、複数のアプリケーションを制御して起動させることもできる。

なお、ＵＲＩは、予め定められた一定の書式によってリソース（資源）を指し示す識別子である。本実施形態に係るＵＲＩにおいては、目的とするデータがシステム１内に存在しない場合をも考慮し、制御部５０若しくはアプリケーションによるアクセスを可能にするためのリソースをも指し示すことができるものとする。また、ＵＲＩが指し示すリソースに制御部５０やアプリケーションがアクセスすることができるようにすることを目的として、ＵＲＩを、実際の格納部における物理アドレスに変換することを要するので、同一の物理アドレスを複数のＵＲＩが指し示すこともあるものとする。なお、ＵＲＩの物理アドレスへの変換若しくは置換は、ＵＲＩに対応付けられているスキームが指定するアプリケーションが実行する。

また、ＵＲＩは、例えば、「スキーム：／／リソース」の形式で記述され、リソースは、スキーム毎に定義された書式で記述される。そして、リソースの例としては、例えば、「目的のデータが存在するディスク番号、ディレクトリ、ファイル、シーク」、「目的のデータが存在するＤＲＡＭメモリアドレス」、「目的のデータが存在しない場合の対応、リトライ、コールバック」等が挙げられる。

（格納部）
格納部は、所定の形式のデータ位置に所定のデータを格納可能に設けられる。格納部は、各種のデータを格納する機能を有する限り様々な記憶媒体を用いることができ、例えば、レジスタ、キャッシュ、Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＤＲＡＭ）、ビデオメモリ、Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ（ＳＳＤ）、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）、テープドライブ、Ｃｏｍｐａｃｔ Ｄｉｓｃ（ＣＤ）やＤｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ（ＤＶＤ）等の光学記録媒体、光磁気記憶媒体、及び磁気記録媒体等である。格納部は、クラウド上の格納部であってもよく、データサイズやデータ数の保存制限がなく、大容量データの保存に適し、オブジェクト単位でデータを保存するオブジェクトストレージであってもよい。これらの格納部には、互いに異なる形式のデータ位置が割り当てられている。

一例として、レジスタ、キャッシュ、ＤＲＡＭにおいては、データ位置は物理アドレスを用いて指定される。具体的に、レジスタにおいては、レジスタ名若しくは番号でデータ位置が指定される。キャッシュにおいては、先頭から順列に沿って数えたアドレスによってデータ位置が指定される。ＤＲＡＭにおいても、先頭から順列に沿って数えたアドレスでデータ位置が指定される。ただし、ＤＲＡＭにおいては、データ位置の指定は物理的にキャッシュとは異なる。

［システム１のデータ指定方法の詳細］
本実施形態に係るシステム１は、ＵＲＩによってデータが指定される格納部を備える。そして、制御部５０がＵＲＩに対応付けられているスキームに応じたアプリケーションを起動させ、起動されたアプリケーションに当該ＵＲＩのリソースが渡される。そして、アプリケーションは、渡されたリソースに基づいてＵＲＩをデータ位置に変換する。これにより、格納部がどのような種類の格納部であっても、制御部５０による格納部の直接的、統一的な制御を可能とする。

例えば、従来のＣＰＵではレジスタ、キャッシュ、及びＤＲＡＭまでを直接、制御する。そして、従来のＣＰＵは、メモリヒエラルキーにおけるＳＳＤ以下の格納部を直接制御することができない。ＤＲＡＭからＳＳＤにデータを転送する経路における転送速度がメモリヒエラルキーにおけるＤＲＡＭ以上の格納部における転送速度より低速であることから、ＤＲＡＭ以上におけるデータ転送等がいかに高速であっても、ＤＲＡＭからＳＳＤへのデータ転送が転送速度の観点からボトルネックになる。これは、従来のコンピューターでは格納部毎に異なる形式を用い、データ位置を物理アドレスで指定していることに起因する。

一方、本実施形態に係るシステム１は、物理アドレスの代わりにＵＲＩをポインタとして用いる。そのため、ＤＲＡＭから下層の格納部であるＳＳＤ等を制御部５０によって直接、制御することができる。具体的に、本実施形態に係る制御部５０において、制御部５０が各格納部にアクセスする場合、制御部５０の命令によってアクセス可能な範囲は、レジスタ、キャッシュ、ＤＲＡＭ、及びＩＯチャネルのＩＯコントローラー等である。そして、制御部５０が、レジスタ、キャッシュ、ＤＲＡＭ、及びＩＯチャネルのＩＯコントローラーに保持されているデータ位置等の数値を制御し、ＩＯコントローラーに保持されている数値が制御部５０によって書き換えられることにより、ＩＯコントローラーから先のＳＳＤ、ＨＤＤ、及びテープドライブ等の格納部が制御部５０によって直接制御される。

その結果、例えば、ＤＲＡＭをデータの転送先・共有場所としてではなく、キャッシュより容量が大きなキャッシュとして扱えるので、システム１におけるデータ処理速度を大幅に向上させることができる。

より具体的には、制御部５０は、例えばオブジェクトストレージ４００に格納されている所定のデータのＵＲＩを参照し、ＵＲＩに対応付けられているスキームが指定するアプリケーションを起動する。制御部５０は、アプリケーションにＵＲＩの区切りの後ろのリソースを渡す。アプリケーションは、リソースに基づいて、物理アドレスの代わりにＵＲＩをデータ位置として用い、ＵＲＩで指定されている格納部に格納されているデータにアクセスする。これにより、ＵＲＩを用いてＳＳＤ等へのアクセスを、制御部５０により一元管理できる。

例えば、制御部５０によって起動されるアプリケーションがＳＳＤ制御ルーチンであれば、ＳＳＤ制御ルーチンがリソースに基づいてＳＳＤコントローラー機器の物理アドレスや、ＳＳＤコントローラー上のＳＳＤメモリ空間の物理アドレスを生成する。これにより制御部５０が、ＳＳＤを制御することができる。

なお、アプリケーションは、複数の格納部のそれぞれに格納されるデータをＵＲＩに基づいて指定することもできる。すなわち、アプリケーションは、制御部５０に制御され、複数の格納部にそれぞれ異なる形式の物理アドレスで指定された位置・番地に格納されている複数のデータそれぞれを、ＵＲＩを用いることで統一的に取り扱うこともできる。これにより、本実施形態に係るシステム１によれば、複数の格納部間でのデータ位置の指定をＵＲＩで拡張し、その結果、統一的に扱うことができる。

以下においては、本実施形態に係るシステム１である実行イメージ供給システムに好適な構成を中心に説明する。

図２に示すように、本実施形態に係るシステム１は、概略、プロキシ側システム２と、スタブ側システム３とを備える。システム１は、システム１外にあるオブジェクトストレージ４００に所定の情報を格納する。そして、システム１は、所定のデバイス５に所定の処理を実行させることができる。すなわち、システム１は、オブジェクトストレージ４００に格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイス５の少なくとも１つに演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムである。なお、デバイス５は、デバイス５の動作を制御する１つ以上のプロセッサー５００を有する。

［プロキシ側システム２］
プロキシ側システム２は、所定のユーザーアプリケーションを一般的に用いられているコンパイラでコンパイルする前に、所定の処理を当該所定のユーザーアプリケーションに施すシステムである。

プロキシ側システム２は、ソースコードを取得するソース取得部２００と、ソースコード中の演算ロジックを特定する演算ロジック特定部２０２と、１つ以上のデバイス５を管理するデバイス管理部２０４と、演算ロジックによるデータアクセスに関する処理を実行するストレージ統合管理部２０６と、１つ以上のデバイス５に演算ロジックを供給する演算ロジック供給部２０８と、実行イメージへのパスと当該実行イメージが実行されるプロセッサー５００とを対応付けたプロセッサー対応表を作成する対応表作成部２１０と、プロセッサー対応表の保存パスと当該プロセッサー対応表を用いる演算ロジックとを対応付けた対応関係を決定する対応関係決定部２１２と、実行用コンテキストを作成する実行用コンテキスト作成部２１４と、スタブ側システム３に所定の情報を供給する送信処理部２１６と、プロキシ側システム２の各構成の動作を制御する制御部５０とを有する。

（ソース取得部２００）
ソース取得部２００は、所定のアプリケーション（例えば、ユーザーアプリケーション６００）のソースコードを取得する。ここで、所定のアプリケーションはオブジェクトストレージ４００に格納されており、ソース取得部２００は、オブジェクトストレージ４００から所定のアプリケーションのソースコードを取得する。すなわち、オブジェクトストレージ４００、すなわちクラウドに当該ソースコードは格納されており、ソース取得部２００は、クラウドからソースコードを取得することになる。なお、アプリケーションは、ソースコード中に演算ロジックを有している。ソース取得部２００は、所定のアプリケーションのソースコードを読み込み、読み込んだソースコードを演算ロジック特定部２０２に供給する。

（演算ロジック特定部２０２）
演算ロジック特定部２０２は、所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を呼び出し、ＡＰＩが、ソースコード中から演算ロジックを特定する。本実施形態において演算ロジックは、分散処理に用いられることが好ましい。

（デバイス管理部２０４）
デバイス管理部２０４は、ソースコードに基づいて指定されるプロセッサー５００が、システム１において用いることができる使用可能プロセッサーであるか否かを確認する。すなわち、デバイス管理部２０４は、ソースコードによって指定されるプロセッサー５００が、システム１において対応済みのプロセッサーであるか否かを確認する。デバイス管理部２０４は、確認結果を演算ロジック供給部２０８に供給する。

（ストレージ統合管理部２０６）
ストレージ統合管理部２０６は、演算ロジック特定部２０２が特定した演算ロジックから所定のデータを除く他のデータへのアクセスが存在するか否かを確認する。例えば、ストレージ統合管理部２０６は、特定された演算ロジックにおいて、不正なＵＲＩ構文が存在するか否かを確認する。また、ストレージ統合管理部２０６は、アクセスするデータへのアクセス権がシステム１に存在するか否かを確認することができる。この場合、ストレージ統合管理部２０６は、システム１にアクセス権が存在するデータのみ、演算ロジックから当該データへのアクセスを許可する。

ここで、デバイス管理部２０４は、ストレージ統合管理部２０６において他のデータへのアクセスが存在しないと判断された場合に、ソースコードに基づいて指定されるプロセッサー５００がシステム１において用いることができる使用可能プロセッサーであるか否かの確認を実行する。

（演算ロジック供給部２０８）
図３は、本実施形態に係るユーザーアプリケーション、プロセッサー対応表、及び対応関係の構成の概要の一例を示す。

図３（ａ）に示すように、ユーザーアプリケーション６００は、１つ以上の演算ロジック（例えば、演算ロジックａ、演算ロジックｂ・・・等）を含むソースコードを有して構成されている。ソースコードには、演算ロジックがアクセスするデータ、演算ロジックが実行されるデバイス５やプロセッサー５００等を特定若しくは指定する情報も含むことができる。

演算ロジック供給部２０８は、ソースコードに基づいて指定されるプロセッサー５００のコンパイラに演算ロジックを供給する。より具体的に、演算ロジック供給部２０８は、デバイス管理部２０４が使用可能プロセッサーの存在を確認した場合（すなわち、指定されたプロセッサー５００が使用可能プロセッサーであると確認した場合）、ユーザーアプリケーション６００のソースコード中の演算ロジックを使用可能プロセッサーに供給する。ここで、ソースコードに基づいて指定されるプロセッサー５００は複数であってもよい。すなわち、ソースコードに基づいて指定されるデバイス５が複数であってもよい。この場合、演算ロジック供給部２０８は、複数の指定されたプロセッサーのコンパイラのそれぞれに、演算ロジックを供給する。

演算ロジックが供給されたプロセッサー５００は、プロセッサー５００が有するコンパイラを用い、受け取った演算ロジックをコンパイルする。プロセッサー５００のコンパイラによるコンパイルは、クラウド上で実行される。そして、プロセッサー５００は、コンパイルした結果を実行イメージとしてオブジェクトストレージ４００に格納する。演算ロジックが供給されるプロセッサーが複数である場合は、複数のプロセッサーのそれぞれが、受け取った演算ロジックをコンパイルし、コンパイルした結果である実行イメージそれぞれをオブジェクトストレージ４００に格納する。なお、プロセッサーのコンパイラは従来公知のコンパイラを用いることができる。また、実行イメージは、例えば、ＯｐｅｎＣＬのＫｅｒｎｅｌ Ｉｍａｇｅを利用することで作成できる。

（対応表作成部２１０）
対応表作成部２１０は、オブジェクトストレージ４００が、ソースコードに基づいて指定されるプロセッサー５００のコンパイラによってコンパイルされた結果を実行イメージとして格納した場合に、オブジェクトストレージ４００に格納されている当該指定されるプロセッサー５００における実行イメージへのパスと、当該指定されるプロセッサーとを対応付けたプロセッサー対応表６１０を作成する。

ユーザーアプリケーション６００は複数の演算ロジックを有することができるので、演算ロジックごとにプロセッサーと当該プロセッサー用の実行イメージのパスとが対応付けられる。具体的に、図３（ｂ）に示すように、プロセッサー対応表６１０は、演算ロジックごとに、１つ以上のプロセッサーのそれぞれと、各プロセッサーのコンパイラによってコンパイルされた結果である実行イメージへのパスとを対応付けた表であり、オブジェクトストレージ４００は、この表に関するデータをプロセッサー対応表６１０として格納する。図３（ｂ）の例では、演算ロジックａが供給されたプロセッサーＡに、プロセッサーＡのコンパイラでコンパイルされて作成された実行イメージへのパスａが対応付けられている（プロセッサーＢ、プロセッサーＣ、・・・等も同様である。）。対応表作成部２１０は、作成したプロセッサー対応表をオブジェクトストレージ４００に格納する。なお、プロセッサー対応表６１０は、演算ロジックごとに別々の表であっても、同一の表であってもよい。

（対応関係決定部２１２）
対応関係決定部２１２は、演算ロジック供給部２０８が供給した演算ロジックと、オブジェクトストレージ４００に格納され、当該演算ロジックに対応するプロセッサー対応表の保存パスとを対応付けた対応関係６２０をオブジェクトストレージ４００に格納する。図３（ｃ）に示すように、対応関係６２０は、演算ロジックに、当該演算ロジックが供給されたプロセッサーにおいて作成された実行イメージへのパスを格納しているプロセッサー対応表６１０への保存パスを対応付けた表である。図３（ｃ）の例では、演算ロジックａにプロセッサー対応表への保存パスＡが対応付けられている（演算ロジックｂ等の他の演算ロジックについても同様である。）。

（実行用コンテキスト作成部２１４）
実行用コンテキスト作成部２１４は、演算ロジックにおいて実行される実行用コンテキストを作成する。具体的には、オブジェクトストレージ４００が、異種混在の複数のデバイスに関するデバイス情報を予め格納する。デバイス情報は、例えば、デバイスの位置、種類、プロセッサー５００の種類等に関する情報である。そして、ユーザーアプリケーション６００は、ユーザーアプリケーション６００の実行が開始された場合、ユーザーアプリケーション６００の演算ロジックがアクセスするデータを指定すると共に、演算ロジックが実行されるデバイスを指定する。そして、実行用コンテキスト作成部２１４は、指定されたデータに基づいて実行用コンテキストを作成する。

より具体的には、まず、ユーザーアプリケーション６００がデータを指定する場合に、ストレージ統合管理部２０６は、指定されたデータ、すなわち、アクセスが要求されたデータへのアクセス権がシステム１にあるか否かを確認し、アクセス権がある場合に、当該データの指定を許可する。

そして、デバイス管理部２０４は、ユーザーアプリケーション６００が指定したデバイスに関するデバイス情報をオブジェクトストレージ４００から取得してデータ処理が実行される対象プロセッサーを特定する。続いて、実行用コンテキスト作成部２１４は、オブジェクトストレージ４００に格納されているプロセッサー対応表及び対応関係を参照し、演算ロジックに対応付けられたプロセッサー対応表における対象プロセッサーに対応付けられている実行イメージへのパスを実行用コンテキストに書き込む。これにより、実行用コンテキスト作成部２１４は、外部に提供する実行用コンテキストを作成する。

（送信処理部２１６）
送信処理部２１６は、ユーザーアプリケーション６００が演算ロジックの実行を指示した場合、パスが書き込まれた実行用コンテキストを外部（すなわち、スタブ側システム３）に供給するためにストレージキューに書き込む。送信処理部２１６は、ストレージキューを介して実行用コンテキストをスタブ側システム３に供給する。

［スタブ側システム３］
スタブ側システム３は、プロキシ側システム２から供給される実行用コンテキストに基づいて、所定のデバイス５に所定の処理を実行させる。なお、実行された処理の結果はオブジェクトストレージ４００に格納することができる。

スタブ側システム３は、プロキシ側システム２から所定の情報を受け取る受信処理部３００と、物理的なメモリを管理するメモリ管理部３０２と、実行イメージを取得する実行イメージ取得部３０４と、演算ロジックを実行する演算ロジック実行部３０６と、演算ロジックの結果をオブジェクトストレージ４００に格納させる結果格納実行部３０８と、ＵＲＩを管理するＵＲＩ管理部３１０と、ストレージ機能を管理するストレージ機能管理部３１２とを有する。

（受信処理部３００）
受信処理部３００は、送信処理部２１６からパスが書き込まれた実行用コンテキストを受信する。また、受信処理部３００は、受信した実行用コンテキストを解読する。

（メモリ管理部３０２）
メモリ管理部３０２は、受信処理部３００において解読された実行用コンテキスト内のデバイス情報に基づいて、演算ロジックが実行される物理メモリ等の実行環境を準備する。

（実行イメージ取得部３０４）
実行イメージ取得部３０４は、受信処理部３００において解読された実行用コンテキスト内の実行イメージへのパスに基づいて、オブジェクトストレージ４００から実行イメージを取得する。すなわち、実行イメージ取得部３０４は、解読された実行用コンテキストによって指定される実行イメージを、オブジェクトストレージ４００からダウンロードする。

（演算ロジック実行部３０６）
演算ロジック実行部３０６は、受信処理部３００において解読された実行用コンテキスト内で指定されるデータを引数として設定する。そして、演算ロジック実行部３０６は、メモリ管理部３０２が準備した実行環境において実行イメージを用いて演算ロジックを実行する。

（結果格納実行部３０８）
結果格納実行部３０８は、演算ロジック実行部３０６において演算ロジックが実行された結果をオブジェクトストレージ４００に格納する。オブジェクトストレージ４００に格納された当該結果は、所定の出力装置から出力することや、他の情報処理に再利用すること等、様々な用途に用いることができる。

（ＵＲＩ管理部３１０）
ＵＲＩ管理部３１０は、演算ロジック実行部３０６において演算ロジックが実行された結果について、当該結果を必要とするデバイスのアクセス先を振り分ける。

（ストレージ機能管理部３１２）
ストレージ機能管理部３１２は、オブジェクトストレージ４００、及び／又はローカルストレージ（例えば、システム１が備える所定の格納部（図示しない））への情報の格納や情報の演算等を制御・管理する。例えば、ストレージ機能管理部３１２は、結果格納実行部３０８を制御して、演算ロジックが実行された結果をオブジェクトストレージ４００に格納する。

［システム１における処理の流れ］
図４〜図６はそれぞれ、本実施の形態に係るシステムにおける処理の流れの概要の一例を示す。具体的に、図４は、システム１による複数種類のプロセッサーへの対応を可能にする処理の流れを示す。また、図５は、ユーザーアプリケーションを実行する場合におけるプロキシ側システム２における処理の流れを示し、図６は、ユーザーアプリケーションを実行する場合におけるスタブ側システム３における処理の流れを示す。なお、図４〜図６において、ユーザーアプリケーションを「ユーザーアプリ」と表記する場合があり、ソースコードを「ソース」と表記する場合がある。

まず、図４を参照する。初めに、プロキシ側システム２においてユーザーアプリの登録が開始される（ステップ１０。以下、ステップを「Ｓ」と表す。）。ソース取得部２００は、オブジェクトストレージ４００に格納されているユーザーアプリケーション６００のソースコードを取得し（Ｓ１２）、ソースコードをシステム１に読み込む（Ｓ１４）。続いて、システム１は、システム１において用いられるＡＰＩを呼び出し、ＡＰＩを用いて分散処理する演算ロジックを、読み込まれたソースコードに基づいて特定する（Ｓ１６）。

次に、ストレージ統合管理部２０６は、特定された演算ロジックから所定のデータを除く他のデータへのアクセスが存在するか否かについて、ＵＲＩに基づくポインタを用いて確認する（Ｓ１８）。ストレージ統合管理部２０６は、他のデータへのアクセスが存在すると判断した場合（Ｓ１８のＹｅｓ）、エラー処理を実行する（Ｓ４２）。例えば、ストレージ統合管理部２０６は、システム１の処理の実行を停止する。一方、ストレージ統合管理部２０６は、他のデータへのアクセスが存在しないと判断した場合（Ｓ１８のＮｏ）、他のデータへのアクセスが存在しない旨を示す情報をデバイス管理部２０４に供給するか、若しくはデバイス管理部２０４に処理の実行を継続させる。

デバイス管理部２０４は、ストレージ統合管理部２０６において他のデータへのアクセスが存在しないと判断された場合に、ソースコードに基づいて指定されたプロセッサーが、システム１において用いることができる使用可能プロセッサーであるか否かを確認する（Ｓ２０）。すなわち、デバイス管理部２０４は、指定されたプロセッサーについて、既にプロセッサー対応表及び対応関係を作成したか否かを確認する。デバイス管理部２０４は、プロセッサー対応表及び対応関係が作成されていないと判断した場合、指定されたプロセッサーが使用可能でないと判断し（Ｓ２０のＮｏ）、エラー処理を実行する（Ｓ４２）。エラー処理は上記と同様であってよい。一方、デバイス管理部２０４は、プロセッサー対応表及び対応関係が作成されていると判断した場合（Ｓ２０のＹｅｓ）、演算ロジック供給部２０８に指定されたプロセッサーへの演算ロジックの送信を実行させる（Ｓ２２）。

演算ロジックを受信したプロセッサー５００は、受け取った演算ロジックのコンパイルを自身のコンパイラに実行させる（Ｓ２４）。演算ロジック供給部２０８は、指定されたプロセッサーが複数存在する場合、複数のプロセッサーのそれぞれに演算ロジックを供給する。そして、この場合、複数のプロセッサーのそれぞれが、それぞれのコンパイラを用いて受け取った演算ロジックのコンパイルを実行する。一つ若しくは複数のプロセッサーのそれぞれは、コンパイルした結果を実行イメージとする（Ｓ２６）。そして、一つ若しくは複数のプロセッサーのそれぞれは、実行イメージをオブジェクトストレージ４００に供給してオブジェクトストレージ４００に格納させる（Ｓ２８）。

そして、対応表作成部２１０は、オブジェクトストレージ４００から各実行イメージへのパスを一つ若しくは複数のプロセッサーごとに受け取り（Ｓ３０）、プロセッサー対応表を作成して、プロセッサー対応表に実行イメージへのパスを書き込む（Ｓ３２）。すなわち、対応表作成部２１０は、プロセッサーと当該プロセッサーにおいて作成された実行イメージのオブジェクトストレージ４００における格納位置を示すパスとを対応付けたプロセッサー対応表を作成する。

ここで、ユーザーアプリケーション６００は複数の演算ロジックを有することができる。この場合、本実施形態に係るシステム１においては、複数の演算ロジックごとにＳ１８〜Ｓ３２を実行し、プロセッサー対応表を作成する。したがって、複数の演算ロジックが存在する場合、プロセッサー対応表は複数の演算ロジックごとに作成される。

続いて、対応関係決定部２１２は、演算ロジック供給部２０８が供給した演算ロジックと、オブジェクトストレージ４００に格納されているプロセッサー対応表への保存パスとを対応付けた対応関係を作成し（Ｓ３４）、この対応関係に関する情報をプロセッサー対応表と共にオブジェクトストレージ４００に供給する（Ｓ３６）。オブジェクトストレージ４００は、プロセッサー対応表及び対応関係を格納する（Ｓ３８）。そして、ユーザーアプリケーション６００は、従来公知のコンパイラでコンパイルされる（Ｓ４０）。

次に、図５を参照する。まず、所定の機能を有するユーザーアプリケーション６００の実行が開始される（Ｓ５０）。ユーザーアプリケーション６００は、自身のソースコードに含まれる演算ロジックがアクセスするデータの指定をプロキシ側システム２に要求する。ストレージ統合管理部２０６は、要求されたデータに対するアクセス権がユーザーアプリケーション６００にあるか否かを確認する（Ｓ５２）。ストレージ統合管理部２０６がユーザーアプリケーション６００にアクセス権があると判断した場合、ユーザーアプリケーション６００は、演算ロジックがアクセスするデータを指定する（Ｓ５４）。一方、ストレージ統合管理部２０６は、要求されたデータに対するアクセス権がないと判断した場合、データへのアクセスを拒否して処理を終了する。

実行用コンテキスト作成部２１４は、指定されたデータを利用し、演算ロジックの実行用コンテキストを作成する（Ｓ５６）。実行用コンテキスト作成部２１４は、実行用コンテキストを作成した場合、実行用コンテキストを作成したことを示す情報をユーザーアプリケーション６００に通知する（Ｓ５８）。ユーザーアプリケーション６００は、この通知に応じ、演算ロジックを実行するデバイスを指定する（Ｓ６０）。デバイス管理部２０４は、ユーザーアプリケーション６００が指定したデバイスに関する情報（デバイス情報）をオブジェクトストレージ４００から取得する（Ｓ６２）。そして、デバイス管理部２０４は、デバイス情報に基づいてデータ処理が実行される対象のプロセッサーである対象プロセッサーを特定する（Ｓ６４）。

デバイス管理部２０４は、対象プロセッサーを特定したことを示す情報をユーザーアプリケーション６００に供給する（Ｓ６６）。また、実行用コンテキスト作成部２１４は、オブジェクトストレージ４００に格納されているプロセッサー対応表及び対応関係を参照し（Ｓ６８）、演算ロジックに対応付けられたプロセッサー対応表における対象プロセッサーに対応付けられている実行イメージへのパスを実行用コンテキストに書き込む（Ｓ７０）。

ユーザーアプリケーション６００は、対象プロセッサーを特定したことを示す情報を取得した後、演算ロジックの実行命令をプロキシ側システム２に供給する（Ｓ７２）。プロキシ側システム２の制御部５０は、当該情報を受け取った後、パスが書き込まれた実行用コンテキストをスタブ側システム３に供給するためにストレージキューに当該実行用コンテキストを書き込む（Ｓ７４）。なお、実行用コンテキスト作成部２１４は、実行用コンテキストに、演算ロジックが実行される環境を指定する実行環境情報を含ませることもできる。そして、送信処理部２１６は、ストレージキュー内の各種情報をスタブ側システム３に供給する（Ｓ７６）。

続いて図６を参照する。受信処理部３００は、プロキシ側システム２の送信処理部２１６から実行用コンテキストを受信する（Ｓ８０）。受信処理部３００は、受信した実行用コンテキストを解読する（Ｓ８２）。メモリ管理部３０２は、受信処理部３００によって解読された実行用コンテキスト内のデバイス情報、及び／又は実行環境情報等に基づいて、演算ロジックが実行される物理メモリ等の実行環境を準備する（Ｓ８４）。そして、実行イメージ取得部３０４は、解読された実行用コンテキスト内の実行イメージへのパスに基づいて、オブジェクトストレージ４００に格納されている実行イメージをダウンロードする（Ｓ８８）。

そして、演算ロジック実行部３０６は、解読された実行用コンテキスト内で指定されるデータを引数として設定し（Ｓ８８）、実行環境においてダウンロードした実行イメージを用いて演算ロジックを実行する（Ｓ９０）。そして、ＵＲＩ管理部３１０は、データのアクセス先を振り分けるＵＲＩ管理処理を実行する（Ｓ９２）。また、ストレージ機能管理部３１２は、結果格納実行部３０８の機能を用い（Ｓ９４）、演算ロジックの実行結果をオブジェクトストレージ４００に格納する（Ｓ９６）。この実行結果は、システム１の内外から必要に応じ、参照される。ストレージ機能管理部３１２は、システム１がローカルストレージを備えている場合、当該ローカルストレージ（図示しない）に実行結果を格納することもできる。

（実施の形態の効果）
本実施形態に係るシステム１においては、演算ロジックをソースコードのまま保持し、デバイス５のプロセッサー５００において予め当該デバイス５用にコンパイルした実行イメージをオブジェクトストレージ４００に格納することができる。すなわち、複数の互いに異なるデバイスのプロセッサーのそれぞれに合わせた実行イメージを、オブジェクトストレージ４００に予め格納することができる。そして、システム１においては、演算ロジックがユーザーアプリケーション６００の動作に応じて呼び出されると、当該ユーザーアプリケーション６００が指定するデバイス５のプロセッサー５００に適した実行イメージがオブジェクトストレージ４００からダウンロードされて実行される。すなわち、本実施形態に係るシステム１においては、ユーザーアプリケーション６００によってプロキシ側システム２に実行イメージが供給され、プロキシ側システム２がスタブ側システム３を介してストレージに当該実行イメージを供給し、ストレージ上でデータ処理を直接実行させることができる。これにより、本実施形態に係るシステム１は、例えば、人工知能（ＡＩ）が扱うＬｏｗ Ｃｏｎｔｅｘｔで小容量のデータに分割することが困難な大容量データを扱う場合であっても、データ処理効率を大幅に向上させることができる。

したがって、本実施形態に係るシステム１によれば、例えば、従来の負荷分散システムでは処理が困難である防犯カメラの動画像や録音した環境音当等処理する場合に用いるＬｏｗ Ｃｏｎｔｅｘｔ ＤａｔａやＢＬＯＢ（Ｂｉｎａｒｙ Ｌａｒｇｅ Ｏｂｊｅｃｔ）を効率よく処理できる。なお、Ｌｏｗ Ｃｏｎｔｅｘｔ Ｄａｔａはファイル分割が困難であり、１つの処理を大型化するＳｃａｌｅ Ｕｐ対応が要求されるので、従来の方式ではメモリ帯域により処理速度に制限がかかることによるデータ処理効率の低下が発生する。

本実施形態に係るシステム１においては、スタブ側システム３はオブジェクトストレージ４００から実行イメージをダウンロードするだけで所定の処理を実行でき、実行イメージのサイズを小さくすることができるので、データ転送量を大幅に低減することができる。更に、システム１は、複数のプロセッサーそれぞれのコンパイラを用いて実行イメージを作成するので、移植の手間がかかる従来のＪａｖａ（登録商標）等と比べ、新たなプロセッサーが開発されても、新たなプロセッサーへの対応が容易になる。

また、本実施の形態に係るシステム１においては、従来のＪａｖａ（登録商標）のような中間コードのオーバーヘッドやバーチャルマシンを要さず、処理速度を向上させることができ、異種混在の複数デバイスへの対応が可能で、ハードウエアの機能を完全に活用することができる。

更に、本実施形態に係るシステム１においては、オブジェクトストレージ４００、すなわち、クラウドにユーザーアプリケーション６００のソースコードを格納し、そのソースコードをそのままクラウド中でコンパイルすることができるので、実質的にソースコードが外部に漏洩することがなく、かつ、中間コード等の複雑な処理を必要とせずにソースコードを実行イメージにコンパイルするだけなので、情報セキュリティについても優れている。

また、本実施の形態に係るシステム１においては、複数のルーチンで受け渡されるポインタとして、ＵＲＩをデータ位置（物理アドレス）の代わりに用いたので、ＤＲＡＭをキャッシュより容量の大きなキャッシュとして用いることができる。すなわち、システム１においては、データ処理に用いるデータのすべてをＤＲＡＭに転送することを必ずしも要さず、ＳＳＤ等のメモリヒエラルキーの下層の格納部に格納されているデータのデータ処理に要する一部だけにアクセスして処理ができ（部分アクセス）、また、ＳＳＤ等のメモリヒエラルキーの下層の格納部から所定のデータを読み取る場合において、データ処理に要する演算を組み込む処理（ストリーム処理等）をすることができる。

したがって、従来の物理アドレスによる管理では格納部毎にポインタが異なるのに対し、本実施形態に係るシステム１によれば、ＵＲＩを用いることで同一のポインタで同一のデータを指し示すことができることから、すべての格納部のデータを統一的に管理できるので、データ量が転送速度に対して増大した場合であっても、部分アクセスやストリーム処理等のデータ処理の高速化技術を様々なアプリケーションに組み込むことで、従来のアドレス管理よりも高速化したデータ処理を実現することができる。すなわち、本実施形態に係るシステム１によれば、無駄なデータ転送の削減、データ転送ルーチンの共通化、及びデータ転送ルーチンへの拡張を実現することができる。

以上の説明において、システム１の各部は、ハードウエアにより実現されてもよく、ソフトウエアにより実現されてもよい。また、ハードウエアとソフトウエアとの組み合わせにより実現されてもよい。プログラムは、コンピューター読み取り可能な媒体又はネットワークに接続された記憶装置から、システム１を構成するコンピューターにインストールされてもよい。

コンピューターにインストールされ、コンピューターを本実施形態に係るシステム１として機能させるプログラムは、ＣＰＵ等に働きかけて、コンピューターをシステム１として機能させる。プログラムに記述された情報処理は、コンピューターに読込まれることにより、ソフトウエアとシステム１のハードウエア資源とが協働した具体的手段として機能する。そして、これらの具体的手段によって、本実施形態におけるコンピューターの使用目的に応じた情報の処理を実現することにより、使用目的に応じた特有のシステム１を構成できる。

また、システム１は、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信インターフェース等を有するデータユニットと、キーボード、タッチパネル、マイク等の入力ユニットと、ディスプレイ、スピーカ等の出力ユニットと、メモリ、ＨＤＤ等の記憶ユニットとを備える構成の情報処理装置において、システム１の各部の動作を規定したソフトウエア又はプログラムを起動することにより実現してもよい。

システム１用のプログラムは、インターネット等の通信ネットワーク、又は磁気記録媒体、光学記録媒体等の記録媒体を介してシステム１に提供し得る。そして、システム１に格納されたシステム１用のプログラムは、ＣＰＵ等により実行される。プログラムを格納している記録媒体は、ＣＤ−ＲＯＭやＤＶＤ等の非一過性の記録媒体であってもよい。

［実施の形態の他の例］
本実施形態の他の例に係るシステムは、通信帯域の制限を受けずに大容量データを扱うためのＣＰＵ、ＧＰＵ、及びＦＰＧＡをまたがった分散処理のシステムに用いることができる。

具体的に、本発明者は、Ｓｐｅｅｃｈ Ｔｏ Ｔｅｘｔ対応インターホン開発時に、僻地対応のため通信帯域の制限を受けずにクラウド内のＸｅｏｎとＩｏＴの組み込みプロセッサー（Ｒａｐｓｂｅｒｒｙ Ｐｉ３）とにおける分散処理を検討したところ、ＯｐｅｎＣＬ Ｋｅｒｎｅｌファイルを転送して利用する方法について知見を得た。この知見に基づいて、本実施形態の他の例に係るシステムを構築できることを見出した。

まず、係るシステムの背景を説明する。すなわち、記憶装置における速度を上下、容量を左右とするメモリヒエラルキーは、ムーアの法則に従って鼓型に変形し、中央部の転送速度が不足することが知られている。半導体プロセスが進化することにより、メモリヒエラルキーの上下はより高くなり（つまり、速度が速くなり）、底辺はより広くなる（つまり、容量が増加する。）ためである。ただし、転送速度の進化を表すギルダーの法則はムーアの法則より遅く、１０年で相対速度が１／１０となる。そのため、慢性的な転送速度不足が発生している。

ここで、転送速度対策としては、データの発生源から極力データを移動させずに処理を行うＩｎ Ｓｔｏｒａｇｅ Ｐｒｏｃｅｓｓｉｎｇが考えられる。しかし、多種プロセッサーに対応したデータ処理指向のプラットフォームが存在せず、コンテナ技術等を利用して独自に開発する必要がある。

そこで、本実施形態の他の例に係るシステムにおいては、データアクセスに関するプログラムをＯｐｅｎＣＬで記述し、システムに存在する機器に合わせて事前にＯｐｅｎＣＬ Ｋｅｒｎｅｌ Ｉｍａｇｅを作成し、データアクセス時にテータが存在する機器に対応するＫｅｒｎｅｌ Ｉｍａｇｅを転送して実行する形態を採用する。

使用言語は、例えば、対象となるプロセッサー対応が豊富であるＯｐｅｎＣＬ １．２を採用できる。なお、開発対象としてＡｚｕｒｅのＸｅｏｎとＲａｐｓｂｅｒｒｙ Ｐｉ３ （ＶｉｄｅｏＣｏｒｅ ＩＶ）を用いる場合、ＯｐｅｎＣＬ １．２が好ましい。また、Ｄｏｃｋｅｒを利用してクラウドからＲａｐｓｂｅｒｒｙ Ｐｉ３に処理を渡してもよい。ただし、Ｄｏｃｋｅｒを利用する場合、僻地の通信環境ではＤｏｃｋｅｒ Ｉｍａｇｅの転送に時間がかかる場合があることから、ＯｐｅｎＣＬのＫｅｒｎｅｌだけを転送させる手法を採用することが好ましい。ＯｐｅｎＣＬのＫｅｒｎｅｌだけを転送させる手法によれば、大容量データ処理の多くのケースで有効であるためである。

具体的に、Ａｌｌ Ｆｌａｓｈ Ａｒｒａｙ等の高速ストレージでは、大容量データは複数のｉｎｏｄｅに分割されて保存されている。ファイルの読み出し時には、ｉｎｏｄｅが集約（Ａｇｇｒｅｇａｔｉｏｎ）され、整列（Ｓｏｒｔ）され、ファイル転送可能な形式に変換（Ｅｎｃｏｄｅ）される。仮にＯｐｅｎＣＬ Ｋｅｒｎｅｌ Ｉｍａｇｅをストレージ機器自身のプロセッサーで動作させれば、上記の三つの処理を経由せずに直接ｉｎｏｄｅを操作可能となり、系全体の実行効率を上昇させることができる。

図７（ａ）は、従来のＡｐａｃｈｅ Ｓｐａｒｋの演算の概要図であり、図７（ｂ）は、本実施形態の他の例に係るシステムにおける演算の概要図である。

従来の方法では１−ａでファイル読み取りが開始され、１−ｃで複数ｉｎｏｄｅの集約（Ａｇｇｒｅｇａｔｉｏｎ）と整列（Ｓｏｒｔ）とが発生する。続いて１−ｄでオブジェクトストレージ形式への変換（Ｅｎｃｏｄｅ）がなされる。一方、図７（ｂ）においては、クラウド内の仮想プロセッサーに２−ａで処理が渡され、ＯｐｅｎＣＬ Ｋｅｒｎｅｌ Ｉｍａｇｅが２−ａ−ｘで転送される。３−ａ．．ｅにてＡｇｇｒｅｇａｔｉｏｎ、Ｓｏｒｔ、Ｅｎｃｏｄｅをせずにデータ処理され、４−ｃで結果のみがクラウドに戻される。

表１は、図７における処理の各ステップにおける見積もり時間を示す。

Ｌｅｇａｃｙが従来手法における見積もり時間を示し、Ｐｒｏｐｏｓａｌが本実施形態の他の例に係るシステムにおける見積もり時間である。１０Ｍのファイルを１００個、北米のデータセンターと日本国内とでやり取りした場合がＨｙｂｒｉｄであり、同ファイル数を同一ＬＡＮ配下で実行した場合がＰｕｂｌｉｃである。Ｉｓｓｕｅ−ｆｉｎｉｓｈが実際の処理時間である。従来手法が最悪ケースで１３秒かかっているのに対し、本実施形態の他の例に係るシステムにおいては、２６０ｍｓｅｃで完了する見込みとなる。処理時間のほとんどは１−ｄのデータ転送にかかっており、仮にデータ転送がないとすると、従来手法は１３０ｍｓｅｃとＯｐｅｎＣＬ Ｋｅｒｎｅｌ Ｉｍａｇｅ転送がない分だけ有利となる。しかし、現実にはデータ転送が存在するため、本実施形態の他の例に係るシステムの方が多くの場合に有利と考えられる。

以下、本実施形態の他の例に係るシステムの実験例を示す。

実情ではクラウド内では高性能ＧＰＵが用いられ、エッジでは一般的なプロセッサーが使われると考えられる。そこで、以下の環境にて実験した。

Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ
クラウド内ＧＰＧＰＵ：ｎＶｉｄｉａ Ｔｅｓｌａ Ｋ８０（５．６１Ｔｆｌｏｐｓ）
エッジプロセッサー：Ｉｎｔｅｌ Ｓｋｙｌａｋｅ ５３０（０．４４Ｔｆｌｏｐｓ）

表２には、データサイズ×転送速度における（従来手法の処理時間）／（本実施形態の他の例に係るシステムの処理時間）の比較（ただし、見積もり）を示す。

１０Ｍのファイル×１００を３．５Ｇｂｐｓの帯域環境で処理したところ、従来手法における場合の処理では３０．４９秒かかり、本実施形態の他の例に係るシステムにおける処理では３．５６秒かかった。すなわち、本実施形態の他の例に係るシステムにおいては従来手法より８．５６倍、高速化した。これは、理論値の９．２７倍には届かなかったが十分な高速化である。

なお、ＯｐｅｎＣＬ自体にはデータアクセスの手法が存在せず、ホストアプリケーションが読み取ったデータを共有メモリにて引き渡し処理をするため、本実施形態の他の例に係るシステムを用いる場合、ホストアプリケーションをプログラムごとに改編することが好ましい。上記実験ではホストアプリケーションをデータごとに組み替えて対応した。

また、ＧＰＵのメモリ空間を拡張するためにＰａｇｅ Ｆａｕｌｔ時に仮想メモリを読み込む技術が存在し、係る技術はＧＰＵメモリを拡張している。ここで、本実施形態の他の例に係るシステムにおいては読み込み先に処理を振り分けているので、係る技術と共存可能と考えられる。

また、ＯｐｅｎＭＣＣＡというＮＶＤＩＭＭ等のＨｅｔｅｒｏｇｅｎｅｏｕｓ Ｍｅｍｏｒｙを仮想メモリ空間にマップして統一的にアクセスを可能にする技術が存在する。本実施形態の他の例に係るシステムにおいては単一のメモリ空間を用いず、既存のストレージの名前空間上で、実際にファイルが存在するデバイス名を取得し、そこに処理を転送するものであり、スケールアップ型のＯｐｅｎＭＣＣＡに対し、本実施形態の他の例に係るシステムにおいてはスケールアウト型と考えられる。

以上、本発明の実施の形態を説明したが、上記に記載した実施の形態は特許請求の範囲に係る発明を限定するものではない。また、実施の形態の中で説明した特徴の組合せの全てが発明の課題を解決するための手段に必須であるとは限らない点に留意すべきである。更に、上記した実施形態の技術的要素は、単独で適用されてもよいし、プログラム部品とハードウエア部品とのような複数の部分に分割されて適用されるようにすることもできる。

１ システム
２ プロキシ側システム
３ スタブ側システム
４ Ｐｕｂｌｉｃ ＰａａＳ
５ デバイス
１０ キュー
１２ Ｃｅｐｈ（セフ）
１４ 専用バス
１６ ｎＶｉｄｉａ ＧＰＵ
２０ ＳＳＤ Ｃｏｎｔｒｏｌｌｅｒ
３０ ＮＶＭｅ
５０ 制御部
１００ ＡＰＩ
２００ ソース取得部
２０２ 演算ロジック特定部
２０４ デバイス管理部
２０６ ストレージ統合管理部
２０８ 演算ロジック供給部
２１０ 対応表作成部
２１２ 対応関係決定部
２１４ 実行用コンテキスト作成部
２１６ 送信処理部
３００ 受信処理部
３０２ メモリ管理部
３０４ 実行イメージ取得部
３０６ 演算ロジック実行部
３０８ 結果格納実行部
３１０ ＵＲＩ管理部
３１２ ストレージ機能管理部
４００ オブジェクトストレージ
４１０ ＧＰＧＰＵ ＳａａＳ
５００ プロセッサー
６００ ユーザーアプリケーション
６１０ プロセッサー対応表
６２０ 対応関係

Claims (13)

1. オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムであって、
   前記ソースコードを取得するソース取得部と、
   所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用い、前記演算ロジックを前記ソースコード中から特定する演算ロジック特定部と、
   前記ソースコードに基づいて指定されるプロセッサーのコンパイラに前記演算ロジックを供給する演算ロジック供給部と、
   前記オブジェクトストレージが、前記指定されるプロセッサーの前記コンパイラによってコンパイルされた結果を実行イメージとして格納し、前記オブジェクトストレージに格納されている前記指定されるプロセッサーにおける前記実行イメージへのパスと、前記指定されるプロセッサーとを対応付けたプロセッサー対応表を作成して前記オブジェクトストレージに格納する対応表作成部と、
   前記演算ロジック供給部が供給した前記演算ロジックと、前記オブジェクトストレージに格納されている前記プロセッサー対応表の保存パスとを対応付けた対応関係を前記オブジェクトストレージに格納する対応関係決定部と
   を備えるシステム。
2. 前記ソースコードに基づいて指定されるプロセッサーが、前記システムにおいて用いることができる使用可能プロセッサーであるか否かを確認するデバイス管理部、
   を更に備え、
   前記演算ロジック供給部が、前記デバイス管理部が前記使用可能プロセッサーの存在を確認した場合、前記演算ロジックを前記使用可能プロセッサーに供給する請求項１に記載のシステム。
3. 特定した前記演算ロジックから所定のデータを除く他のデータへのアクセスが存在するか否かを確認するストレージ統合管理部
   を更に備え、
   前記デバイス管理部が、前記ストレージ統合管理部において前記アクセスが存在しないと判断した場合に、前記ソースコードに基づいて指定されるプロセッサーが、前記システムにおいて用いることができる使用可能プロセッサーであるか否かを確認する請求項１又は２に記載のシステム。
4. 前記ソースコードに基づいて複数のプロセッサーが指定され、
   前記演算ロジック供給部が、複数の前記指定されたプロセッサーのコンパイラのそれぞれに前記演算ロジックを供給する請求項１〜３のいずれか１項に記載のシステム。
5. 前記システムが、制御部
   を更に備え、
   前記オブジェクトストレージが、前記所定のデータのデータ位置に基づいて前記所定のデータを格納し、
   前記システムが、前記所定のデータへアクセスするポインタとして、所定のスキームと所定の区切りの後に前記スキーム毎に定義された書式によるリソースとが対応付けられているＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を前記データ位置の代わりに用い、
   前記制御部が、前記ＵＲＩに対応付けられている前記スキームが指定するアプリケーションを制御して起動させ、前記ＵＲＩの前記リソースを前記アプリケーションに渡し、
   前記アプリケーションが、前記リソースに基づいて前記ＵＲＩを前記データ位置として用い、前記ＵＲＩで指定されて前記オブジェクトストレージに格納されるデータを制御する請求項１〜４のいずれか１項に記載のシステム。
6. 前記オブジェクトストレージが、前記異種混在の複数のデバイスに関するデバイス情報を格納し、
   前記ユーザーアプリケーションが、前記ユーザーアプリケーションの実行が開始された場合、前記ユーザーアプリケーションの前記演算ロジックがアクセスするデータを指定し、かつ、前記演算ロジックが実行されるデバイスを指定し、
   前記指定されたデータに基づいて、前記演算ロジックにおいて実行される実行用コンテキストを作成する実行用コンテキスト作成部
   を更に備え、
   前記デバイス管理部が、前記ユーザーアプリケーションが指定した前記デバイスに関する前記デバイス情報を前記オブジェクトストレージから取得してデータ処理が実行される対象プロセッサーを特定し、
   前記実行用コンテキスト作成部が、前記プロセッサー対応表及び前記対応関係を参照し、前記演算ロジックに対応付けられた前記プロセッサー対応表における前記対象プロセッサーに対応付けられている前記実行イメージへの前記パスを前記実行用コンテキストに書き込む請求項１〜５のいずれか１項に記載のシステム。
7. 前記ユーザーアプリケーションが前記演算ロジックの実行を指示した場合、前記パスが書き込まれた前記実行用コンテキストを外部に供給するためにストレージキューに書き込む送信処理部
   を更に備える請求項６に記載のシステム。
8. 前記送信処理部から前記パスが書き込まれた前記実行用コンテキストを受信し、当該実行用コンテキストを解読する受信処理部と、
   解読された実行用コンテキスト内の前記デバイス情報に基づいて、前記演算ロジックが実行される実行環境を準備するメモリ管理部と、
   解読された実行用コンテキスト内の前記実行イメージへの前記パスに基づいて、前記オブジェクトストレージから前記実行イメージを取得する実行イメージ取得部と、
   解読された実行用コンテキスト内で指定される前記データを引数として設定し、前記実行環境において前記実行イメージを用いて前記演算ロジックを実行する演算ロジック実行部と
   を更に備える請求項７に記載のシステム。
9. 前記演算ロジック実行部において前記演算ロジックが実行された結果を前記オブジェクトストレージに格納する結果格納実行部
   を更に有する請求項８に記載のシステム。
10. 前記演算ロジックが、分散処理に用いられる請求項１〜９のいずれか１項に記載のシステム。
11. オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムであって、
    前記演算ロジックをソースコードのまま保持し、
    前記複数のデバイスのプロセッサーのそれぞれにおいて、前記複数のデバイス用に前記演算ロジックをコンパイルすることで実行イメージを作成し、
    前記実行イメージを前記オブジェクトストレージに格納し、
    前記演算ロジックが前記複数のデバイスのうちの一のデバイスに呼び出された場合、前記一のデバイス用に作成された前記実行イメージを前記オブジェクトストレージから前記一のデバイスに供給するシステム。
12. オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステムにおける情報処理方法であって、
    前記ソースコードを取得するソース取得段階と、
    所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用い、前記演算ロジックを前記ソースコード中から特定する演算ロジック特定段階と、
    前記ソースコードに基づいて指定されるプロセッサーのコンパイラに前記演算ロジックを供給する演算ロジック供給段階と、
    前記オブジェクトストレージが、前記指定されるプロセッサーの前記コンパイラによってコンパイルされた結果を実行イメージとして格納し、前記オブジェクトストレージに格納されている前記指定されるプロセッサーにおける前記実行イメージへのパスと、前記指定されるプロセッサーとを対応付けたプロセッサー対応表を作成して前記オブジェクトストレージに格納する対応表作成段階と、
    前記演算ロジック供給段階において供給された前記演算ロジックと、前記オブジェクトストレージに格納されている前記プロセッサー対応表の保存パスとを対応付けた対応関係を前記オブジェクトストレージに格納する対応関係決定段階と
    を備える情報処理方法。
13. オブジェクトストレージに格納され、予め定められた演算ロジックをソースコード中に有するユーザーアプリケーションを備え、異種混在の複数のデバイスの少なくとも１つに前記演算ロジックを実行させて所定のデータに所定の処理を施すことを可能にするシステム用のプログラムであって、
    コンピューターに、
    前記ソースコードを取得するソース取得機能と、
    所定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を用い、前記演算ロジックを前記ソースコード中から特定する演算ロジック特定機能と、
    前記ソースコードに基づいて指定されるプロセッサーのコンパイラに前記演算ロジックを供給する演算ロジック供給機能と、
    前記オブジェクトストレージが、前記指定されるプロセッサーの前記コンパイラによってコンパイルされた結果を実行イメージとして格納し、前記オブジェクトストレージに格納されている前記指定されるプロセッサーにおける前記実行イメージへのパスと、前記指定されるプロセッサーとを対応付けたプロセッサー対応表を作成して前記オブジェクトストレージに格納する対応表作成機能と、
    前記演算ロジック供給機能において供給された前記演算ロジックと、前記オブジェクトストレージに格納されている前記プロセッサー対応表の保存パスとを対応付けた対応関係を前記オブジェクトストレージに格納する対応関係決定機能と
    を実現させるプログラム。

Images