JP6886874B2 - エッジ装置、データ処理システム、データ送信方法、及びプログラム - Google Patents

Description

本発明は、ＩｏＴ機器等の端末装置から、データをクラウドにアップロードする技術に関連するものである。

一般に、画像あるいは映像のような大容量データを扱うＩｏＴ機器（例：ＮＷに接続された監視カメラ等）から、データをクラウドに送信する場合、取得したデータを全て送ることはコスト高となり難しいため、トラフィック量を低減させる処理が必要になる。例えば、送信するデータの選択、圧縮、画質やフレームレートの調整、等の処理が行われる。

従来、これらの処理は、主にＩｏＴ機器上（もしくはＩｏＴ機器に接続されたローカルマシン）のアプリケーションが実行していた。

特開２００４−３３６３０９号公報

ＩｏＴ機器から、映像のような容量の大きなデータをクラウドにアップロードする場合、通常その間のＮＷについての帯域と遅延の問題を考慮しなければならない。ＮＷの設備が最適に利用されていなければ、遅延が増大し、また、これを無理に設備増強で解決しようとするとコストが高くなってしまうという問題が生じる。

一般的に、ＩｏＴ機器から送信されたデータは、モバイル網、及び有線キャリア網を抜けてクラウド（具体的にはデータセンタにおけるサーバであり、クラウド装置と称してもよい）に到達するので、それぞれの網内／網間でトラフィックの増加を抑えることができれば、設備コストを下げることが可能である。

しかし、従来技術では、データのアップロードにおいて、ＩｏＴ機器からクラウドまでのＮＷには機能を持たせず単純なトンネルとして扱われる。この方法では、ＩｏＴ機器とクラウド間のＮＷ負荷の総量を削減することは可能であるが、ＮＷ構造を考慮した際に、各ＮＷ内及びＮＷ間接続のコスト構造も考慮した上で最適化されたデータ送信を実現することはできなかった。つまり、モバイル網や有線キャリア網のキャパシティの差を考慮した最適化ができないため、設備を有効に使い切ることができず、コスト増となる。

また、ＩｏＴ機器から見てデータのアップロード先まで経由する網が多いため、ＩｏＴ機器からみたデータアップロード先までの通信遅延が生じ易いが、従来技術におけるデータ容量そのものを削減する方法では、経由する網に関わる遅延を小さくすることはできなかった。

また、送信時に削減してしまった部分については、それが必要となった時のためにＩｏＴ機器に一定期間データを残しておく仕様になることも多く、その場合にバッファできるデータ量はＩｏＴ機器（もしくはＩｏＴ機器に接続されたローカルマシン）のストレージに依存してしまい、ＩｏＴ機器側のコスト高に繋がっていた。

上記のように、ＩｏＴ機器等の端末装置からクラウド装置にデータを送信する従来技術は、遅延が大きかったり、余計なコストがかかる等、非効率であった。

本発明は上記の点に鑑みてなされたものであり、ＩｏＴ機器等の端末装置からクラウド装置等のサーバへのデータ送信を効率的に行うことを可能とする技術を提供することを目的とする。

開示の技術によれば、端末装置から出力されたデータをサーバに送信するための処理を実行するエッジ装置であって、
前記端末装置から出力されたデータを受信し、当該データが、すぐに前記サーバに送信すべきデータであるか否かを判定する判定手段と、
前記判定手段により、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信する送信手段と、
前記判定手段により、すぐに前記サーバに送信すべきであると判定されなかったデータを格納する非送信データ格納手段と、
前記非送信データ格納手段に格納したデータの識別情報を、データの所在情報及びデータの識別情報を管理するメタデータ管理装置に送信する手段と、を備え、
前記送信手段は、前記メタデータ管理装置からデータの所在情報を取得した前記サーバからのリクエストに応じて、前記非送信データ格納手段からデータを読み出し、読み出したデータを前記サーバに送信する
ことを特徴とするエッジ装置が提供される。

開示の技術によれば、ＩｏＴ機器等の端末装置からクラウド装置等のサーバへのデータ送信を効率的に行うことを可能とする技術が提供される。

本発明の実施の形態におけるデータ処理システム（例１）の構成図である。 本発明の実施の形態におけるデータ処理システム（例２）の構成図である。 本発明の実施の形態におけるデータ処理システム（例３）の構成図である。 各装置の構成を示す図である。 各装置のハードウェア構成例を示す図である。 ヘルスチェック時の動作手順を説明するためのシーケンス図である。 ＬＢ／ＤＮＳにおける機器・エッジ間マップ格納部に格納される情報の例を示す図である。 データアップロード時の動作手順を説明するための図である。 メタデータ管理装置におけるデータマップ格納部に格納される情報の例を示す図である。 データリクエスト時の動作手順を説明するための図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（実施の形態の概要）
まず、本実施の形態の概要を説明する。本実施の形態では、ＩｏＴ機器から画像や映像等のデータを直接クラウド上の蓄積サーバ（これをクラウド装置と呼んでもよい）まで送るのではなく、モバイル網（モバイルコア網と基地局網からなる網）と有線キャリア網における中間層がデータを受信し、クラウド上のサーバへは必要なデータだけに絞って送信する。もしくは、クラウド上のサーバが必要に応じてデータを中間層から吸い上げる。このような仕組みにより、ＩｏＴ機器からの通信遅延を削減できるだけでなく、モバイル網から有線キャリア網へのトラフィックを減少させることや、有線キャリア網からクラウドのサーバへのトラフィックを減少させることができる。

中間層においてデータのバッファリングを行うため、例えば中間層に追加の装置（エッジ装置と呼び、物理的な装置でもよいし、仮想的な装置でもよい）を設置し、当該エッジ装置にデータの受信やバッファリング等の機能を持たせる。エッジ装置は物理的な距離やＮＷを考慮して分散して配置する。

ＩｏＴ機器からエッジ装置へのデータ送信に際して、まずＩｏＴ機器から付近の基地局の選択が生じるが、ここは一般的なモバイル網の経路最適化を利用することができる。エッジ装置がＩｏＴ機器からデータを受信し、確実に必要とされたデータをクラウドに送った後は、クラウドからのリクエストに応じてバッファしたデータをクラウド側に追加で送信する。

ＩｏＴ機器から（基地局からでもよい）エッジ装置に対して遅延を含む様々なヘルスチェックを定常的に行うことで、遅延情報を保持しておき、当該遅延情報に基づいて最適なエッジ装置を選定することを可能としている。エッジ装置の選定は例えばＩｏＴ機器側がＤＮＳに問い合わせる方法等で実現できる。エッジ装置は分散ファイルシステムもしくは分散ＤＢとしての機能も有している。可用性を担保するためにデータ（ファイル）のレプリケーションをエッジ装置に設定することも可能である。その場合、近傍のエッジ装置間でレプリケートのトラフィックが発生する。

エッジ装置は、ＩｏＴ機器から受け取ったデータのうち、例えばプライオリティが高いものをクラウドに対して送信する。プライオリティの違いの識別方法としては、例えば、ＩｏＴ機器側で指定する方法（例：データにフラグを付して送信）、クラウド側で指定する方法（クラウド側からエッジ装置にルールを設定）がある。また、リソース消費は増えるが、ＩｏＴ機器が、データに、より情報量の多いメタデータを追加し、エッジ装置がメタデータをもとにある程度複雑なロジックで決定することも可能である。また、これら以外の方法を用いてもよい。

また、本実施の形態では、データの所在（例：エッジ装置、クラウド等）を把握できる仕組みが備えられている。当該仕組みとして、例えば、一般的な分散ファイルシステムのように、エッジ装置のデータを含めたデータのマップ情報を保持し、当該マップ情報に基づき、データの所在を把握する方法がある。クラウド側では、当該仕組みを利用することで、ユーザからのリクエスト等に応じて、適宜のエッジ装置に対してデータのリクエストを送信することが可能である。なお、ユーザからのリクエストに対し、データそのものではなく接続先を返すこととしてもよい。

また、エッジ装置に保存されるデータは大量であるため、本実施の形態では、予め定めた期間を過ぎたら（又はデータ量が閾値を超えたら）エッジ装置はデータを破棄することとしている。予め定めた期間とは例えば数日間、数週間等、ユースケースにより異なってくる。予め定めた期間の情報はエッジ装置に設定してもよいし、ＩｏＴ機器がデータ自身に当該期間の情報を付加して送信することとしてもよい。

また、エッジ装置はデータの暗号化と圧縮の機能、及びデータの送信先とするクラウドのサーバを選定する機能を備えてもよい。これにより、エッジ装置からクラウドまでのトラフィック量を軽減することができる。なお、エッジ装置をどこに設置するにしても、ＩｏＴ機器やクラウドのサーバ（とそのアプリケーション）からエッジ装置にＩＰで接続できるようにする。ただし、これに限られるわけではなく、ＩＰ以外の方法で接続を実現してもよい。

以下、本実施の形態におけるシステム構成及び動作の例をより詳細に説明する。

（システム構成）
図１は、本実施の形態における例１のデータ処理システムの構成図である。図１に示すように、例１のデータ処理システムは、ＩｏＴ機器１００、基地局網を構成する基地局１、モバイルコア網３と有線キャリア網４とを接続するＧＷ（ゲートウェイ）２、エッジ装置２００、及びクラウド装置３００を含む。後述するように、本実施の形態では、ＬＢ／ＤＮＳ（Ｌｏａｄ Ｂａｌａｎｃｅｒ／Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）４００、及び、メタデータ管理装置５００も使用される。これらの装置はそれぞれ、これを利用する他の装置と通信が可能であれば、どこに備えられていてもよい。例えば、クラウド装置３００と同様に有線キャリア網４に備えられてもよいし、モバイルコア網３に備えられてもよい。

本実施の形態における基地局１には、張り出し局となる無線部（アンテナ等）が光ファイバ等で接続されており、各ＩｏＴ機器１００は、当該無線部と無線通信を行う。各ＧＷ２は、例えばＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）で識別される。

例１では、エッジ装置２００は、ＧＷ２側に備えられている。エッジ装置２００がＧＷ２側に備えられているとは、例えば、エッジ装置２００がＧＷ２と物理的に近い距離で接続されいることを含む。また、エッジ装置２００の機能が、ＧＷ２内に備えられていてもよい。つまり、ＧＷ２がエッジ装置２００であってもよい。クラウド装置３００は、例えば、ＤＣ（データセンタ）に備えられているサーバである。

図２は、例２のデータ処理システムの構成図である。例２では、エッジ装置２００が、ＧＷ２側ではなく、基地局１側に備えられている点が例１と異なる。エッジ装置２００が基地局１側に備えられているとは、例えば、エッジ装置２００が基地局１と物理的に近い距離で接続されていることを含む。また、エッジ装置２００の機能が、基地局１内に備えられていてもよい。つまり、基地局１がエッジ装置２００であってもよい。

図３は、例３のデータ処理システムの構成図である。例３では、エッジ装置２００が、ＧＷ２側と基地局１側の両方に備えられている。つまり、例３では、エッジ装置２００が２段構成になっている。

なお、例１〜例３は一例に過ぎない。エッジ装置２００は、ＩｏＴ機器１００とクラウド装置３００との間のどこに設置してもよい。また、ＩｏＴ機器１００は、モバイル網の他、無線ＬＡＮ網に接続されてもよい。この場合、例えば、エッジ装置２００を、無線ＬＡＮのアクセスポイント側に備えることとしてもよい。

以下、例１あるいは例２のように、エッジ装置２００が１段構成である場合について、各装置の構成の詳細、及び、動作例を説明するが、多段構成であっても、エッジ装置２００の動作は、基本的に以下で説明する動作と同様である。例えば、多段構成において、ある段に位置するエッジ装置２００がその下位の段のエッジ装置２００からデータを受信し、その上位の段のエッジ装置２００にデータを送信する動作は、１段構成におけるエッジ装置２００が、ＩｏＴ機器１００からデータを受信し、クラウド装置３００にデータを送信する動作と基本的に同様である。

（各装置の構成）
図４に、各装置の機能構成を示す。各装置間を接続する矢印付きの線は、後述する動作説明における動作に対応している。以下では、各装置の構成を説明し、装置を構成する各機能部の動作については、後述する動作説明の中で説明する。

ＩｏＴ機器１００は、データの発生源となる端末装置であり、例えばカメラである。ＩｏＴ機器１００が、ＰＣ、スマートフォン等の一般的なユーザ端末であってもよい。図４に示すように、ＩｏＴ機器１００は、データ送信部１１０、ヘルスチェック部１２０、チェック結果送信部１３０、及び接続先検索部１４０を含む。

エッジ装置２００は、前述した中間層を構成する装置である。図４に示すように、エッジ装置２００は、データ受信部２１０、データバッファ部２２０、データマップ生成部２３０、ヘルスチェック部２４０、データ送信部２５０、非送信データストア２６０、リクエスト受信部２７０、データマップ送信部２８０を含む。

ＬＢ／ＤＮＳ４００は、ＩｏＴ機器１００とエッジ装置２００間の距離（例：遅延で表わされる距離）を保持・更新し、ＩｏＴ機器１００からの問い合わせに対して近傍のエッジ装置２００を返す等の処理を実行する装置である。図４に示すように、ＬＢ／ＤＮＳ４００は、データ受信部４１０、機器・エッジ間マップ格納部４２０を含む。

クラウド装置３００は、ＩｏＴ機器１００から出力され、エッジ装置２００から送信されたデータを受信し、保存する等の処理を行う装置である。図４に示すように、クラウド装置３００は、データ受信部３１０、データストア３２０、データリクエスト部３３０、リクエストデータ接続先検索部３４０を含む。

メタデータ管理装置５００は、ＩｏＴ機器１００から出力されたデータが、どのエッジ装置２００に格納されているか等のデータマップ情報を管理する装置である。図４に示すように、メタデータ管理装置５００は、各エッジデータマップ受信部５１０、データマップ格納部５２０を含む。

上述したＩｏＴ機器１００、エッジ装置２００、クラウド装置３００、ＬＢ／ＤＮＳ４００、メタデータ管理装置５００はいずれも、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。図５は、各装置のハードウェア構成例を示す図である。図５の装置は、それぞれバスＢで相互に接続されているドライブ装置１５０、補助記憶装置１５２、メモリ装置１５３、ＣＰＵ１５４、インタフェース装置１５５、表示装置１５６、及び入力装置１５７等を有する。

当該装置（ＩｏＴ機器１００、エッジ装置２００、クラウド装置３００、ＬＢ／ＤＮＳ４００、又は、メタデータ管理装置５００）での処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体１５１によって提供される。プログラムを記憶した記録媒体１５１がドライブ装置１５０にセットされると、プログラムが記録媒体１５１からドライブ装置１５０を介して補助記憶装置１５２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１５１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１５２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１５３は、プログラムの起動指示があった場合に、補助記憶装置１５２からプログラムを読み出して格納する。ＣＰＵ１５４は、メモリ装置１５３に格納されたプログラムに従って当該装置に係る機能を実現する。インタフェース装置１５５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１５６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１５７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。なお、各装置において表示装置１５６及び／又は入力装置１５７を備えないこととしてもよい。

なお、ＬＢ／ＤＮＳ４００は、例えばモバイル網が５Ｇであれば、モバイル網内の仮想スライスの中にある仮想ファンクションであってもよい。

（データ処理システムの動作）
以下、シーケンス図等を参照して、本実施の形態におけるデータ処理システムの動作を説明する。なお、各シーケンス図におけるステップ番号に対応するステップ番号が図４にも記載されている。以下の説明は、シーケンス図を参照して行うが、機能部間の情報送受信等に関しては、図４も適宜参照されたい。

＜ヘルスチェック時の動作手順＞
複数のＩｏＴ機器１００と複数のエッジ装置２００が存在する本実施の形態に係る構成において、各ＩｏＴ機器１００がどのエッジ装置２００に近いかを管理するために、各ＩｏＴ機器１００は、複数のエッジ装置２００との間でヘルスチェックを実施する。なお、本実施の形態におけるヘルスチェックは、遅延のチェックも含むものである。

ヘルスチェック時の動作手順を図６を参照して説明する。図６は、１つのＩｏＴ機器１００と１つのエッジ装置２００に着目した図である。

ＩｏＴ機器１００のヘルスチェック部１２０は、エッジ装置２００のヘルスチェック部２４０に対し、ヘルスチェック用データを送信する（ステップＳ１０１）。ヘルスチェック用データの送信は、例えば一定時間間隔で定常的に行われる。ヘルスチェック用データを受信したエッジ装置２００のヘルスチェック部２４０は、応答を返す（ステップＳ１０２）。

ＩｏＴ機器１００のヘルスチェック部１２０は、当該応答を受信することで、エッジ装置２００が動作していることを確認するとともに、ＩｏＴ機器１００とエッジ装置２００間の遅延を把握する。

一例として、ヘルスチェック用データは、ｐｉｎｇ等で使用されるＩＣＭＰパケットである。ＩｏＴ機器１００のヘルスチェック部１２０は、ＩＣＭＰパケットを送信してから、その応答を受信するまでの時間を遅延時間として把握することができる。また、ヘルスチェック用データが、ＩＣＭＰパケット以外の軽量のチェック用データであってもよい。その場合、例えば、エッジ装置２００のヘルスチェック部２４０が、チェック用データを受信した時刻を含む応答をＩｏＴ機器１００のヘルスチェック部１２０に返すことで、ＩｏＴ機器１００のヘルスチェック部１２０は、チェック用データを送信した時刻と、応答に含まれる時刻とから、上り方向の遅延を把握することができる。

ＩｏＴ機器１００のチェック結果送信部１３０は、ヘルスチェックの結果をＬＢ／ＤＮＳ４００に送信する。ヘルスチェックの結果には、例えば、ＩｏＴ機器１００の識別情報、ヘルスチェックの対象となったエッジ装置２００の識別情報、及び遅延（遅延の値）が含まれる。なお、これらの識別情報はそれぞれ、ＩＰアドレスであってもよいし、ＭＡＣアドレス等の装置固有の情報であってもよいし、装置に割り当てられたＩＤ等であってもよいし、その他の情報であってもよい。

ＬＢ／ＤＮＳ４００のデータ受信部４１０は、ヘルスチェックの結果を受信すると、当該ヘルスチェックの結果を、機器・エッジ間マップ（各エッジ装置２００と各ＩｏＴ機器１００間の主に遅延で表される距離を逐次更新しているマップ）として、機器・エッジ間マップ格納部４２０に格納する。なお、該当のＩｏＴ機器１００とエッジ装置２００の組に関して、既に情報が格納されている場合、距離の情報が更新される。

図７に、機器・エッジ間マップ格納部４２０に格納される情報の例を示す。図７に示すとおり、ＩｏＴ機器の識別情報と、エッジ装置の識別情報と、距離（遅延）とが対応付けて格納される。

＜データアップロード時の動作手順＞
次に、ＩｏＴ機器１００が、データをアップロードする際の動作手順を図８を参照して説明する。

まず、ＩｏＴ機器１００の接続先検索部１４０が、データの送信先の問い合わせ（メッセージ）をＬＢ／ＤＮＳ４００に送信する（ステップＳ２０１）。問い合わせを受信したＬＢ／ＤＮＳ４００は、機器・エッジ間マップ格納部４２０を参照することで、問い合わせの送信元のＩｏＴ機器１００との間の遅延が小さいエッジ装置２００（１つ又は複数）を特定し、当該エッジ装置２００の識別情報（例：ＩＰアドレス）を当該ＩｏＴ機器１００に返す（ステップＳ２０２）。なお、ＩｏＴ機器１００との間の遅延が小さいエッジ装置２００とは、例えば、ＩｏＴ機器１００が遅延測定を実施した複数のエッジ装置２００のうちの遅延が最小のエッジ装置２００である。

上記ステップＳ２０１、Ｓ２０２の処理は、例えば、通常のＤＮＳと同じく、ＦＱＤＮで問い合わせを受け付けて、ＩＰアドレスを返すことであってもよい。

ＩｏＴ機器１００は、ＬＢ／ＤＮＳ４００から指定されたエッジ装置２００を宛先としてデータを送信する（ステップＳ２０３）。なお、ＬＢ／ＤＮＳ４００から複数のエッジ装置２００が指定された場合、例えば、ＩｏＴ機器１００は任意に選択した１つのエッジ装置２００にデータを送信する。例えば、データの送信が開始されると、ある期間（例：ある時間長の映像データの送信が完了するまで）、データ（パケット）が連続的に送信される。

エッジ装置２００のデータ受信部２１０が、ＩｏＴ機器１００から送信されたデータを受信すると、データ受信部２１０は、当該データをデータバッファ部２２０に一時的に格納（バッファ）する。データバッファ部２２０は、バッファ機能とともに、バッファしたデータのうち、すぐにクラウド装置３００に送信するデータと、それ以外のデータとを判別する機能を含み、当該機能により、すぐにクラウド装置３００に送信するデータと、それ以外のデータとを判別する。

なお、エッジ装置２００は、順次データ(パケット)を受信するが、データバッファ部２２０に蓄積するデータ量に関し、例えば、データバッファ部２２０は、１つのパケットを蓄積したら、当該パケットについて、すぐにクラウド装置３００に送信するか否かの判定、及び判定に伴う処理（送信／格納）を行うこととしてもよいし、データバッファ部２２０は、予め定めたデータ量だけ複数パケットを蓄積し、当該複数パケットのそれぞれについて、すぐにクラウド装置３００に送信するか否かの判定、及び判定に伴う処理（送信／格納）を行うこととしてもよい。

データバッファ部２２０は、すぐにクラウド装置３００に送信すると判断したデータをデータバッファ部２２０からデータ送信部２５０に送る。データ送信部２５０は、当該データをクラウド装置３００に送信する（ステップＳ２０４）。クラウド装置３００のデータ受信部３１０が、当該データを受信し、データストア３２０に格納する（ステップＳ２０６）。

データバッファ部２２０は、すぐにクラウド装置３００に送信すると判断したデータ以外のデータを非送信データストアに保存（格納）する（ステップＳ２０５）。

すぐにクラウド装置３００に送信するデータと、それ以外のデータとを判別する機能に関して、例えば、ＩｏＴ機器１００から送信されるデータのヘッダに、すぐにクラウド装置３００に送信するデータと、それ以外のデータとを識別するフラグが付けられる。例えば、フラグとしてのあるビットが１であればすぐにクラウド装置３００に送信するデータであり、ビットが０であればそれ以外のデータであるとする。この場合、データバッファ部２２０は、バッファしたデータのフラグのビットを確認し、１であれば当該データをデータ送信部２５０によりすぐにクラウド装置３００に送信し、０であれば当該データを非送信データストア２６０に格納する。

また、ＩｏＴ機器１００から送信されるデータにフラグ等を付さず、エッジ装置２００において、すぐにクラウド装置３００に送信するデータと、それ以外のデータとを判別することとしてもよい。この場合、例えば、エッジ装置２００に対し、すぐにクラウド装置３００に送信するデータと、それ以外のデータとを判別するためのルール（メタデータと称してもよい）を設定（格納）しておく。例えば、アプリケーションＡのデータであればすぐにクラウド装置３００に送信し、それ以外のアプリケーションのデータであれば非送信データストア２６０に格納する、ことを示すルールが設定される場合において、データバッファ部２２０は、バッファしたデータからアプリケーションを判別し、当該アプロケーションがアプリケーションＡであればデータをすぐにクラウド装置３００に送信し、それ以外のアプリケーションであればデータを非送信データストア２６０に格納する。

データマップ生成部２３０は、データ送信元のＩｏＴ機器１００、データ発生時刻、どのデータをクラウド装置３００に送信し、どのデータを非送信データストア２６０に保存したか、等を示す情報をデータマップとして生成する。一例として、ここで生成されるデータマップには、データ送信元のＩｏＴ機器１００の識別情報、データ送信先のクラウド装置３００の識別情報、データ発生時刻（日時）、クラウド装置３００に送信したデータの識別情報（例：映像であればフレーム番号等）、非送信データストア２６０に保存したデータの識別情報（例：映像であればフレーム番号等）が含まれる。

データマップ送信部２８０は、データマップ生成部２３０により生成されたデータマップをメタデータ管理装置５００に送信する（ステップＳ２０７）。なお、前述したとおり、各エッジ装置２００はデータを分散させて保持する機能を含む。例えば、あるエッジ装置２００が、自身が非送信データストア２６０に保存すべきと判断したデータの一部を他のエッジ装置２００に渡す場合、当該データに係るマップデータも当該他のエッジ装置２００に渡すこととしてもよい。これにより、各エッジ装置２００は、分散機能により保持するデータについてもデータマップを保持することができ、当該データマップをメタデータ管理装置５００に送信することができる。

メタデータ管理装置５００のエッジデータマップ受信部５１０が、データマップをエッジ装置２００から受信し、データマップ格納部５２０に格納する（ステップＳ２０８）。データマップ格納部５２０には、各エッジ装置２００から受信したマップデータが集約されて格納される。

図９に、データマップ格納部５２０に格納されるデータマップの情報の例を示す。図９の例では、データマップ格納部５２０には、データマップとして、データを識別する識別情報（ここでは、「ＩＤ」）、データが格納されている場所を示す所在情報、データが発生した発生時刻、その他の情報が格納される。

データを識別する識別情報は、そのデータを送信したＩｏＴ機器１００の識別情報であってもよいし、データをあるサイズのブロックに分割して扱う場合における当該ブロックの番号であってもよいし、データに順番が付けられる場合における当該順番であってもよいし、映像のフレーム番号であってもよいし、これら以外の情報であってもよいし、これらの組み合わせでも良い。

所在情報は、例えば、該当データを格納している装置（エッジ装置２００、クラウド装置３００等）の識別情報である。また、所在情報に、当該装置の識別情報に加えて、装置内の格納場所が含まれていてもよい。

発生時刻は、例えば、ＩｏＴ機器１００から送信されるデータにタイムスタンプが付される場合における当該タイムスタンプ、あるいは、エッジ装置２００がデータを受信した時刻等である。その他の情報は、例えば、該当データに関わるアプリケーション名、該当データの所有者（例：企業名）等である。

なお、図８のステップＳ２０４において、エッジ装置２００からクラウド装置３００にデータを送信するに際して、どのクラウド装置３００にデータを送信するかについては、ＩｏＴ機器１００とエッジ装置２００との間での処理と同様にして、予め各クラウド装置３００との間でヘルスチェックにより遅延を測定しておいて、当該遅延に基づき決定する。また、ＩｏＴ機器１００とエッジ装置２００との間での処理と同様に、遅延の情報をＤＮＳに保持しておき、ＤＮＳからの回答として制御することとしてもよい。

あるいは、エッジ装置２００とクラウド装置３００との間は、有線であることもあり、例えばホップ数等である程度固定で決めておくこととしてもよい。また、業務要件等により、データ保存先となるクラウド装置３００を、ＩｏＴ機器１００毎に決定することとしてもよい。

＜データリクエスト時の動作手順＞
次に、データリクエスト時の動作手順の例を図１０を参照して説明する。ステップＳ３０１において、クラウド装置３００が、データストア３２０に格納されたデータに基づいて異常を検知する。この異常検知は、クラウド装置３００自身が行うこととしてもよいし、クラウド装置３００に格納されたデータを遠隔で利用するユーザが行うこととしてもよい。後者の場合、クラウド装置３００は、当該ユーザのユーザ端末から、異常を通知されることで異常検知を行う。

一例として、ＩｏＴ機器１００が監視カメラであり、格納するデータが映像データである場合において、異常を示す映像が検知された場合に異常検知となる。異常が検知されると、データリクエスト部３３０からエッジ装置２００に対して不足データのリクエストを送信する。リクエスト内容は、例えば、普段はフレームを間引いたものをクラウド装置３００に保存していれば、残りのフレームをリクエストするといったものである。

上記のようなリクエストを実行するために、まず、クラウド装置３００のリクエストデータ接続先検索部３４０が、異常検知したデータが、どのエッジ装置２００に保存されているかをメタデータ管理装置５００に問い合わせる（ステップＳ３０２）。この問い合わせには、データを識別する情報（例：データの送信元のＩｏＴ機器１００の識別情報、データの番号等）が含まれる。

問い合わせを受信したメタデータ管理装置５００は、データマップ格納部５２０に格納されているデータマップを検索し、当該データの所在情報（例：データを格納するエッジ装置２００の識別情報）を返す（ステップＳ３０３）。なお、メタデータ管理装置５００において、分散格納されたデータへのアクセスを実現するために、例えばＨＤＦＳのネームノード等の技術を適用してもよい。

データリクエスト部３３０は、データを格納しているエッジ装置２００に対してデータリクエスト（例：前述したフレームの要求）を送信する（ステップＳ３０４）。エッジ装置２００のリクエスト受信部２７０が当該データリクエストを受信すると、データ送信部２５０は、当該データリクエストに応じたデータを非送信データストア２６０から読み出し、当該データをクラウド装置３００に送信する。なお、データ送信部２５０は、当該データそのものではなく、当該データにアクセスするための接続先をクラウド装置３００に送信することとしてもよい。

エッジ装置２００では、例えばリクエスト受信部２７０が、クラウド装置３００からのリクエストに基づき送信したデータを非送信データストア２６０から削除する（ステップＳ３０６）。また、非送信データストア２６０は、非送信データストア２６０に格納したデータのうち、格納してから予め定めた時間が経過したデータを順次削除する。また、非送信データストア２６０は、非送信データストア２６０のデータ容量が逼迫した場合（例：閾値に達した場合）には、データを削除する。この場合、例えば、最も古いデータ（格納してから経過した時間が最も長いデータ）から削除する。なお、データ容量が逼迫した場合に古いデータから削除することは一例に過ぎない。例えば、データの種類（アプリケーションの種類等）に応じて優先度を定めておき、最も優先度の低いデータから削除することとしてもよい。

なお、上記の例では、エッジ装置２００は、クラウド装置３００からリクエストを受信した場合に、非送信データストア２６０に格納しておいたデータをクラウド装置３００に送信しているが、これは非送信データストア２６０に格納しておいたデータを送信する場合の一例である。

例えば、データ送信部２５０に予めルールを設定しておき、データ送信部２５０が当該ルールに従って、非送信データストア２６０に格納しておいたデータをクラウド装置３００に送信することとしてもよい。また、送信したデータを非送信データストア２６０から削除する。ルールとしては、例えば、エッジ装置２００とクラウド装置３００との間のNW負荷の少ない時間帯（予め設定する時間帯）に非送信データストア２６０に格納しておいたデータを送信すること等がある。また、データ送信部２５０に、エッジ装置２００とクラウド装置３００との間のNW負荷の値（例：遅延）を取得する機能を備え、データ送信部２５０が、NW負荷の値が所定閾値以下となったことを検出した場合に、非送信データストア２６０に格納しておいたデータを送信することとしてもよい。なお、非送信データストア２６０に格納しておいたデータの送信先はクラウド装置３００に限られない。例えば、データの送信元のＩｏＴ機器１００のユーザにより予め指定された宛先（例：ユーザ所有のサーバ）であってもよい。

（実施の形態の効果）
従来技術では、ＩｏＴ機器１００等から画像や映像のような大量データをアップロードするシステムを構築する際に、遅延の影響や回線コストを抑えるための方法として、主にＩｏＴ機器１００側の制御を行うこととしていた。例えば、単純にデータを圧縮する以外に、普段はビットレートや解像度を下げたデータを送信し、特別なイベント（異常時等）の時だけ、高画質データを送信することで全体として網にかかるトラフィックを削減する方法がとられていた。

一方、本実施の形態に係る技術を用いることで、上記のような制御を行うことなく、エッジ装置２００の置き場所を適宜変えることによって、ＩｏＴ機器１００からみた遅延削減や各網でのトラフィック量を削減することができる。例えば、エッジ装置２００をモバイルコア網３と有線キャリア網４との間の接続ポイントであるＧＷ２付近のモバイルコア網３内に設置した場合、ＧＷ２を通って有線キャリア網４へ抜けるトラフィックを抑えることができる。また、モバイルコア網３内のトラフィックを抑えたければ基地局１付近にも設置し、多段構成にすれば良い。トラフィックを抑えることにより、コスト削減及び遅延削減が実現される。

また、従来技術では、過去のデータに遡って詳細データが欲しいときに、ＩｏＴ機器１００等に保存しておいたデータを追加で取得する方法しかとれず、通常貧弱であるＩｏＴ機器１００のストレージ容量に大きく依存するばかりか、モバイルコア網３に突発的な負荷をかけることになったが、本実施の形態に係る技術を用いることで、エッジ装置２００として高集約のストレージを備えることが可能であるため、ＩｏＴ機器１００の種類によらず、ある程度の容量のデータをバッファリングしておくことが可能である。これにより、ＩｏＴ機器１００のコスト削減が可能である。

上記のように、本実施の形態に係る技術により、ＩｏＴ機器等の端末装置からクラウド装置へのデータ送信を効率的に行うことができるようになる。

（実施の形態のまとめ）
以上、説明したとおり、本実施の形態によれば、端末装置から出力されたデータをサーバに送信するための処理を実行するエッジ装置であって、前記端末装置から出力されたデータを受信し、当該データが、すぐに前記サーバに送信すべきデータであるか否かを判定する判定手段と、前記判定手段により、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信する送信手段と、前記判定手段により、すぐに前記サーバに送信すべきであると判定されなかったデータを格納する非送信データ格納手段とを備えることを特徴とするエッジ装置が提供される。

データバッファ部２２０、データ送信部２５０、及び非送信データストア２６０はそれぞれ、判定手段、送信手段、非送信データ格納手段の例である。

前記判定手段は、前記端末装置から出力されたデータに付されたフラグに基づいて前記判定を行う、又は、データに関する予め定めたルールに基づいて前記判定を行うこととしてもよい。

所定の条件が満たされた場合に、前記送信手段は、前記非送信データ格納手段からデータを読み出し、当該データを前記サーバに送信する、又は、前記非送信データ格納手段に格納されたデータにアクセスするための接続先を前記サーバに送信することとしてもよい。なお、「所定の条件が満たされた場合」とは、例えば、サーバからリクエストを受信した場合、現在時刻が所定の時間帯になった場合、あるいはＮＷ品質が良好である場合、等であるが、これらに限定されるわけではない。

エッジ装置は、前記サーバに送信したデータと、前記非送信データ格納手段に格納したデータに関する情報を生成し、当該情報をメタデータ管理装置に送信する手段を更に備えることとしてもよい。なお、データマップ生成部２３０及びデータマップ送信部２８０は、当該手段の例である。

また、エッジ装置は、前記非送信データ格納手段に格納されたデータから、所定の条件を満たすデータを削除する手段を更に備えてもよい。「所定の条件を満たすデータ」とは、例えば、格納してから予め定めた時間が経過したデータ、データ容量が閾値に達した場合における最も古いデータや最も優先度の低いデータ、等であるが、これらに限られるわけではない。

また、本実施の形態により、端末装置から出力されたデータをサーバに送信するための処理を実行する複数のエッジ装置と、前記サーバとを備えるデータ処理システムであって、各エッジ装置と前記端末装置との間の遅延に基づいて、前記複数のエッジ装置の中から選択されたエッジ装置が、前記端末装置から出力されたデータを順次受信し、前記エッジ装置は、前記端末装置から順次受信するデータのうち、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信し、前記サーバは、前記エッジ装置から送信された前記データを受信し、格納することを特徴とするデータ処理システムが提供される。

また、本実施の形態により、コンピュータを、エッジ装置における各手段として機能させるためのプログラムが提供される。

＜付記＞
（第１項）
端末装置から出力されたデータをサーバに送信するための処理を実行するエッジ装置であって、
前記端末装置から出力されたデータを受信し、当該データが、すぐに前記サーバに送信すべきデータであるか否かを判定する判定手段と、
前記判定手段により、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信する送信手段と、
前記判定手段により、すぐに前記サーバに送信すべきであると判定されなかったデータを格納する非送信データ格納手段と
を備えることを特徴とするエッジ装置。
（第２項）
前記判定手段は、前記端末装置から出力されたデータに付されたフラグに基づいて前記判定を行う、又は、データに関する予め定めたルールに基づいて前記判定を行う
ことを特徴とする第１項に記載のエッジ装置。
（第３項）
所定の条件が満たされた場合に、前記送信手段は、
前記非送信データ格納手段からデータを読み出し、当該データを前記サーバに送信する、又は、
前記非送信データ格納手段に格納されたデータにアクセスするための接続先を前記サーバに送信する
ことを特徴とする第１項又は第２項に記載のエッジ装置。
（第４項）
前記サーバに送信したデータと、前記非送信データ格納手段に格納したデータに関する情報を生成し、当該情報をメタデータ管理装置に送信する手段
を更に備えることを特徴とする第１項ないし第３項のうちいずれか１項に記載のエッジ装置。
（第５項）
前記非送信データ格納手段に格納されたデータから、所定の条件を満たすデータを削除する手段
を更に備えることを特徴とする第１項ないし第４項のうちいずれか１項に記載のエッジ装置。
（第６項）
端末装置から出力されたデータをサーバに送信するための処理を実行する複数のエッジ装置と、前記サーバとを備えるデータ処理システムであって、
各エッジ装置と前記端末装置との間の遅延に基づいて、前記複数のエッジ装置の中から選択されたエッジ装置が、前記端末装置から出力されたデータを順次受信し、
前記エッジ装置は、前記端末装置から順次受信するデータのうち、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信し、
前記サーバは、前記エッジ装置から送信された前記データを受信し、格納する
ことを特徴とするデータ処理システム。
（第７項）
端末装置から出力されたデータをサーバに送信するための処理を実行するエッジ装置におけるデータ送信方法であって、
前記端末装置から出力されたデータを受信し、当該データが、すぐに前記サーバに送信すべきデータであるか否かを判定する判定ステップと、
前記判定ステップにより、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信するステップと、
前記判定ステップにより、すぐに前記サーバに送信すべきであると判定されなかったデータを非送信データ格納手段に格納するステップと
を備えることを特徴とするデータ送信方法。
（第８項）
コンピュータを、第１項ないし第５項のうちいずれか１項に記載のエッジ装置における各手段として機能させるためのプログラム。
以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１００ ＩｏＴ機器
１１０ データ送信部
１２０ ヘルスチェック部
１３０ チェック結果送信部
１４０ 接続先検索部
２００ エッジ装置
２１０ データ受信部
２２０ データバッファ部
２３０ データマップ生成部
２４０ ヘルスチェック部
２５０ データ送信部
２６０ 非送信データストア
２７０ リクエスト受信部
２８０ データマップ送信部
３００ クラウド装置
３１０ データ受信部
３２０ データストア
３３０ データリクエスト部
３４０ リクエストデータ接続先検索部
４００ ＬＢ／ＤＮＳ
４１０ データ受信部
４２０ 機器・エッジ間マップ格納部
５００ メタデータ管理装置
５１０ 各エッジデータマップ受信部
５２０ データマップ格納部
１５０ ドライブ装置
１５１ 記録媒体
１５２ 補助記憶装置
１５３ メモリ装置
１５４ ＣＰＵ
１５５ インタフェース装置
１５６ 表示装置
１５７ 入力装置

Claims (7)

1. 端末装置から出力されたデータをサーバに送信するための処理を実行するエッジ装置であって、
   前記端末装置から出力されたデータを受信し、当該データが、すぐに前記サーバに送信すべきデータであるか否かを判定する判定手段と、
   前記判定手段により、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信する送信手段と、
   前記判定手段により、すぐに前記サーバに送信すべきであると判定されなかったデータを格納する非送信データ格納手段と、
   前記非送信データ格納手段に格納したデータの識別情報を、データの所在情報及びデータの識別情報を管理するメタデータ管理装置に送信する手段と、を備え、
   前記送信手段は、前記メタデータ管理装置からデータの所在情報を取得した前記サーバからのリクエストに応じて、前記非送信データ格納手段からデータを読み出し、読み出したデータを前記サーバに送信する
   ことを特徴とするエッジ装置。
2. 前記判定手段は、前記端末装置から出力されたデータに付されたフラグに基づいて前記判定を行う、又は、データに関する予め定めたルールに基づいて前記判定を行う
   ことを特徴とする請求項１に記載のエッジ装置。
3. 所定の条件が満たされた場合に、前記送信手段は、
   前記非送信データ格納手段からデータを読み出し、当該データを前記サーバに送信する、又は、
   前記非送信データ格納手段に格納されたデータにアクセスするための接続先を前記サーバに送信する
   ことを特徴とする請求項１又は２に記載のエッジ装置。
4. 前記非送信データ格納手段に格納されたデータから、所定の条件を満たすデータを削除する手段
   を更に備えることを特徴とする請求項１ないし３のうちいずれか１項に記載のエッジ装置。
5. 端末装置から出力されたデータをサーバに送信するための処理を実行するエッジ装置におけるデータ送信方法であって、
   前記端末装置から出力されたデータを受信し、当該データが、すぐに前記サーバに送信すべきデータであるか否かを判定する判定ステップと、
   前記判定ステップにより、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信するステップと、
   前記判定ステップにより、すぐに前記サーバに送信すべきであると判定されなかったデータを非送信データ格納手段に格納するステップと、
   前記非送信データ格納手段に格納したデータの識別情報を、データの所在情報及びデータの識別情報を管理するメタデータ管理装置に送信するステップと、
   前記メタデータ管理装置からデータの所在情報を取得した前記サーバからのリクエストに応じて、前記非送信データ格納手段からデータを読み出し、読み出したデータを前記サーバに送信するステップと
   を備えることを特徴とするデータ送信方法。
6. 端末装置から出力されたデータをサーバに送信するための処理を実行するエッジ装置と、データの所在情報及びデータの識別情報を管理するメタデータ管理装置とを備えるデータ処理システムであって、
   前記エッジ装置は、
   前記端末装置から出力されたデータを受信し、当該データが、すぐに前記サーバに送信すべきデータであるか否かを判定する判定手段と、
   前記判定手段により、すぐに前記サーバに送信すべきであると判定されたデータを前記サーバに送信する送信手段と、
   前記判定手段により、すぐに前記サーバに送信すべきであると判定されなかったデータを格納する非送信データ格納手段と、
   前記非送信データ格納手段に格納したデータの識別情報を、前記メタデータ管理装置に送信する手段と、を備え、
   前記メタデータ管理装置は、
   データの所在情報及びデータの識別情報を格納する格納手段と、
   前記サーバからのデータの識別情報に基づく問い合わせに応じて、前記サーバにデータの所在情報を返す手段と、を備え、
   前記送信手段は、前記メタデータ管理装置からデータの所在情報を取得した前記サーバからのリクエストに応じて、前記非送信データ格納手段からデータを読み出し、読み出したデータを前記サーバに送信する
   ことを特徴とするデータ処理システム。
7. コンピュータを、請求項１ないし４のうちいずれか１項に記載のエッジ装置における各手段として機能させるためのプログラム。

Images