HTML5 Webook

112/116

著者らはこの問題に対応するため、インフラ資源配置を抽象化する「仮想リージョン」と階層間インタフェースの提案を行った（図5）。「仮想リージョン」は具体的には、許容遅延内で通信可能で、利用可能なエッジサーバを共通に持つ無線基地局のグループである。IoTサービス事業者の許容遅延とエッジサーバの空き状況を基に、インフラ所有者が作成する。IoTサービス事業者は、ネットワークのトポロジやエッジサーバの配置場所を参照する代わりに、仮想リージョンを参照することで、グループに属する無線基地局の接続ユーザ数のみに基づき、要求VM台数を決定することができる。仮想リージョンごとに要求されたVM台数に基づき、インフラ所有者は、省電力性も考慮したVM配置を行う。提案方式により、従来手法では両立できなった、階層間の制御メッセージ量の削減と省電力性が両立できることを確認した[6]。4.3IoT エッジコンピューティングプラットフォーム本節では、プラットフォームレイヤに相当するPaaSの機能要素について述べる。前記、エッジコンピューティングにおける「分散化に伴う課題」、「動的な状況変動の課題」に対応するものである。本プラットフォームはIoTのデータフローを処理するための機能要素について主に扱っている。4.3.1データフローフレームワークIoTのアプリケーションを簡単に作成することを目指し、実行するデータ処理の流れを、「データフロー」のパラダイムによって定義するフレームワークがいくつか提案されている[7][8]。これらのフレームワークには、データフローを構成する処理のコンポーネントの詳細を知らずとも、一連の処理をフローとして定義できる利点がある。しかし、既存のデータフローフレームワークは、一度データフローを定義すると、基本的に次にデータフロー定義者が更新するまで、フローの構造は変化しない。したがって、エッジコンピューティング環境において想定すべき動的な状況変動に対応するには、データフロー定義者がデータフローの定義を更新するか、ピーク時に必要なネットワークや計算機の資源を常に確保し、それらを用いるよう、あらかじめデータフローを定義しなければならない。関連技術として、クラウド上で連続的に生成されるストリームデータを分散処理するフレームワークもいくつか提案されている[9][10]。これらは、専用プログラムの記述が必要であり、データフローフレームワークのように個々の処理の詳細に立ち入らずに全体の処理フローを定義できない。また、基本的にマスタスレーブ型でシステムが構成されるため、データ送信時にクラウド上のサーバへの問い合わせが必要となり、伝送遅延によって配信遅延が大きくなる問題や、問い合わせの集中に伴い負荷が増大してしまう問題がある。著者らはこれら課題に対処すべく、データの処理を行うコンポーネント間の接続を Topic-Based Pub/Sub ⼈物領域検出⼊退室管理混雑度ログ照合特徴抽出カウントデータフローグラフ:図6　データフローの例IoTサービス事業者インフラ所有者仮想リージョン2仮想リージョン1仮想リージョン3物理ネットワーク・物理サーバ許容遅延以内で通信可能①仮想リージョン閲覧要求仮想リージョン1仮想リージョン2仮想リージョン3②仮想リージョン作成③仮想リージョン提示VMVMVMVMVMVMVM④仮想リージョンごとのVM台数決定・要求EC-IaaS InterfaceVMVMVMVMVMVMVM⑤VM配置物理サーバ決定図5　仮想リージョンに基づくVM取得手順108　　　情報通信研究機構研究報告 Vol. 64 No. 2 （2018）6　ネットワークの効率的な資源配分を目指す研究開発