「マルチメディア，分散，協調とモバイル(DICOMO2019)シンポジウム」 令和元年7月

ノード間通信の優位性評価を目的とした
Fog コンピューティングテストベッドの構築に関する一検討菊地 俊介†1,a)

佐々木 健†2

大木 裕介†2

松本 亮介†1

概要：IoT においてクラウドのリッチなコンピューティングリソースを利用する際には，現場とクラウド間の通信遅延が大きな問題となる．この問題を解決するためのエッジコンピューティングの研究開発が盛んである．筆者らは，エッジコンピューティングの実際上の導入・普及プロセスは，個々の現場にそれぞれの裁量の範囲での小さいシステムが導入され，それが徐々に有機的に結合されていく形態ではないかと考え，エッジコンピューティングにおけるノード間での相互接続性を重視した Fog コンピューティングに注目している．今回，相互接続性を考慮した Fog コンピューティングテストベッドを作成し，Fog ノード間接続の対クラウド接続に対する優位性を確認するための基礎的な性能計測を実施した．本稿では，Fogコンピューティングテストベッドのアーキテクチャ紹介と併せてその結果を報告する．
キーワード：Fog コンピューティング, テストベッド, クラウド, エッジ, 使い分け, RTT

A Study on Building a Fog Computing Testbed forAssessing the Superiority of Inter-Node Communication
Shunsuke Kikuchi†1,a)

Ken Sasaki†2

Yusuke Ohgi†2

Ryosuke Matsumoto†1

ソースを現場に導入しようとすると，遠方にあるデータセ

1. はじめにンターとの通信遅延（レイテンシ），通信帯域，またその通長年に渡りユビキタス，アンビエント，IoT，サイバー信に伴う費用などが必ずしも現場で求められる要件に適合

フィジカルシステム [1] 等と名前を変えながらも，我々のしないという問題が想定されるようになってきた．このこ生活環境（=現場）の中にコンピュータのサポートが入るとから，クラウドコンピューティングの形態をベースとしことでより便利で快適な生活を実現しようとする，次世代つつも現場（あるいは現場近傍）（＝エッジ）にも限定されコンピューティング環境の研究開発が続けられてきた．

た形のコンピューティングリソースを配置し，クラウドと一方で，ネットワーク経由でコンピューティングリソー

現場のコンピューティングリソースを組み合わせることでスを利用するクラウドコンピューティングは登場以来飛躍

それらの問題を解決しようとする「エッジコンピューティ的な発展を続けており，電力調達の優位性等から都市部かング」が提唱され，研究開発されてきている [2]．

ら離れた場所に超大規模なデータセンターを設立し，そこ一方筆者らは，エッジコンピューティングの次世代コンからもたらされるリッチなコンピューティングリソースをピューティング環境への適用においては，現場デバイス-利用して高度なサービス・アプリを実現する形態が一般化

エッジ-クラウドというエッジコンピューティングの縦連携している．

だけではなく，現場におけるデバイスやシステム間の横連

しかし，クラウドによるリッチなコンピューティングリ携もなければ高度でかつスムーズなサービス・アプリは実現できないのではないかと考え，エッジでのノード間の横†1†2a)

現在，さくらインターネット株式会社 さくらインターネット研
究所
Presently with SAKURA Internet Research Center,
SAKURA Internet Inc.
現在，フリーランス
s-kikuchi@sakura.ad.jp

連携機能を備えたエッジコンピューティングの拡張，すな
わち「Fog コンピューティング」の実現に向けた実際的な検討を進めている [3][4][5]．今回筆者らは，Fog コンピューティングの実現に向けて，実際に使えるサービス・アプリ

c 2019 Information Processing Society of Japan⃝― 97 ―

を作り出すためにはどのような課題があるのかを抽出することを目的に「Fog コンピューティングテストベッド」を設計・実装した．

3. エッジコンピューティング普及における問題意識

本稿では，作成した Fog コンピューティングテストベッ

筆者らは，前述のエッジコンピューティングの複数の形ドの概要を紹介するとともに，実装したサンプルとなるア態のうちのクラウド主導型のエッジコンピューティングをプリケーション，それを用いて実施した現場-クラウド間と前提として，次世代コンピューティング環境，つまり生活現場のノード間での通信遅延の比較，それらを通じて得た環境 (現場) の改善にコンピューティングを利用する際に，Fog コンピューティングの実現に向けた課題等について報エッジコンピューティングは実際の利用・普及に際してど告する．のような実装形態をたどり，そこにはどのような課題があ本稿は以下の構成を取る．まず第 2 節で関連研究を参照しながらエッジコンピューティングを整理し，第 3 節でるか，を調査・検討・解決することを目的に研究開発を推進している．

エッジコンピューティングに対する問題意識と筆者らのエッジコンピューティングの研究においては，エッジ

Fog コンピューティングについての考え方について述べ，ノードにジョブを割り当てる方法や動的なメッセージルー

そこから，第 4 節にて今回作成した Fog コンピューティン

ティングの方法などについての検討がよくなされている．

グテストベッドの設計意図を説明，続いて第 5 節で Fog コ

これらは，エッジノードが単一の管理ポリシー下にありそ

ンピューティングテストベッドの実装方式とその上で稼働こに複数のジョブを動的に割り当ててコンピューティングさせたアプリケーションを紹介，第 6 節で実施した通信遅リソースを共有するモデルを前提としている．これは前述

延計測とその結果について報告し，第 7 節では Fog コンのエッジコンピューティングの形態のうちキャリア主導モピューティング実現上の課題について説明し，最後，第 8デルであれば妥当な想定である．しかしながら一般的な企節でまとめる．

業や組織が IoT やサイバーフィジカルシステムの観点から現場に何らかのサービス・アプリを導入することを想定し

2. 関連研究た時，費用面などから，本来目的とするジョブを実行する

エッジコンピューティングは，検討の母体となる組織・ためのリソースを超える余剰リソースを持ったエッジノー

団体のバックグラウンドやターゲット領域の差異などからドを現場に導入することは考えづらく，また展開するエッ形態が多岐に渡っており，議論に際しては具体的にどの形

ジ領域も自身の管理下にある限られた範囲に限定されるも態を対象としているかに注意が必要である．ここでは [6]のと考えられる．

を元に大別するが，a) ネットワークキャリア（特に携帯次世代コンピューティング環境を実現するためには，一キャリア）が推進しネットワークの内部（携帯基地局）につの空間に様々なサービス・アプリが多層的に導入されてコンピューティングリソースを設置してサービス提供あるいることが望ましいし，空間的にも広い範囲をカバーしていは利用を目指すもの（MEC[7]），b) 産業領域で工場のいる必要がある．ある特定のセンサしか使えず特定のデーシステムの高度化などを想定しているもの（OpenFog[8],タしか取得できない，あるいは，この部屋ではこの制御はIIC[9] など），c) クラウドベンダーによるクラウドから現場できるが違う部屋ではできない，という状態は望ましくなへの伸長を目指して検討されるもの（これにはプロプライい．しかしながら前述のように現場へのサービス・アプリエタリなものだけでなくオープン規格によるものも含む）の導入は局所的に進むことが想定されるため，目的とする（AWS Greengrass[10], Azure IoT Edge[11], Cloudlet[12]環境を実現するためには，管理している企業・組織が異ななど）などがある．それぞれクラウドの存在を前提としたる個々の現場のサービス・アプリをシームレスに連携させ上で現場にコンピューティングリソースを提供するノードていくことで最終的に多層的かつ広範囲の環境を形成して「エッジノード」を設置し，現場のコンピューティング環いくというのが現実的に想定される道筋ではなかろうか．

境の高度化のために両者を補完的に使うという点は共通でつまり個々の現場サービス・アプリが互いに連携可能であるが，想定するエッジノードの規模や性能，実行させるあることが重要であり，これはすなわち，API やデータ形アプリケーション，そしてエッジノードを誰が所有・管理式（データモデル）における相互接続性がある，というこするのか等が異なっている．MEC はネットワークキャリとが重要になると考えられる．

アによりエッジノードを物理的に広い範囲に設置し，統一また，サービス・アプリ間の連携方法を考えた時に現状的なポリシーの下で管理，利用することを想定している．

で一般的なのは，クラウドに設置したサーバにおいて API

IIC は主にはエンタープライズを対象として工場や建物なを公開しそこを通じて互いに通信・データ交換を実施する

どにエッジノードを設置・管理・利用することを想定，クという方法である．しかし，現場のサービス・アプリ間でラウド主導型ははっきりした範囲の想定はないが，比較的の連携を想定する場合，そもそものエッジノードの導入の小規模な範囲でのエッジノード設置も可能な構成である．

理由が現場での処理能力の高度化でありすなわちクラウド

c 2019 Information Processing Society of Japan⃝― 98 ―

までの往復の通信遅延やデータ量の多さなどの問題の解NGSI の標準化を推進する標準化組織であり，同時にそれを決のためであったことを考えると，クラウドを経由した連実装したソフトウェア群の名称でもある．NGSI/FIWARE携では目的を満たせないと考えられる．したがって現場のを採用することで，同じ方式に準拠しているサービス・ア

サービス・アプリ間の連携では，クラウドではなくエッジプリ間や FIWARE の既存ソフトウェア資産との相互接続内での相互接続が求められると考えられる．

が可能になる．既存のソフトウェア資産とは例えば，セン

これらの点から筆者らは，エッジコンピューティングにサデータの一般公開（マーケットプレイス）機能コンポーおいてエッジノード上でのジョブの間の相互接続を可能にネントや，データのグラフ表示や地図上での表示を可能にすることが必要であり，エッジコンピューティングに相互するコンポーネントなどである．

接続性機能を追加した拡張を「Fog コンピューティング」と*1

スマートシティ・スマートビルディングの検討は現在，定義している ．そして Fog コンピューティングの実現，特に自治体等が保有する公共データ等の公開などに留まっ言い換えれば個々のエッジサービス・アプリの相互接続のているが [16][17]，本来は現場の状態把握や制御を目指す実現における，実装形態や課題の調査・検討・解決をよりものであり現場の高度化を目指す次世代コンピューティン具体的な問題意識と設定している．

グと本質的には目指すものは同じであるため，その規格等これに加えて現実的なエッジコンピューティングの普及を採用することには合理性があると考えている．

を想定した際の問題意識として，クラウドと比較してエッNGSI 及び FIWARE データモデルは，仕様を理解しそジノードの不安定さを考慮して何らかの高可用性対応が必れに従ってメッセージングを使えるようになるまでに若干要と考えられることも問題意識の一つである．の学習コストが必要であるが，ベースは REST 形式の通信

これらをまとめると以下の様になる．

プロトコルであり理解は容易である．本テストベッド用に( 1 ) 単一管理ポリシー配下でのエッジノード展開ではな
く局所的なサービス・アプリ，エッジノードの集合になることを想定し，異なるサービス・アプリ間での連携を可能にする独自の通信仕様を定義することも可能であるが結局学習コストが必要であることを考えると，汎用性の高い方式を採用することがより良いと考えた．

4.2 データプレーンのメッセージングでクラウド/エッジ( 2 ) サービス・アプリ間連携をクラウドではなくエッジ折返しを併用するノードで実施可能にする

NGSI ではコンポーネント間のデータ交換（メッセージ( 3 ) エッジノードの不安定さを考慮し，エッジ実行ジョブの可用性を高めるング）はコンテキストブローカーと呼ばれるハブとなるコンポーネントを経由することで実施される．各コンポーネント間が直接通信するのではない．Fog コンピューティン

4. Fog コンピューティングテストベッドの設計意図

グテストベッドではコンテキストブローカーをクラウド上およびエッジノードの双方に配備し，サービス・アプリがそれぞれを併用可能な構成にしている．これにより，低遅前節で述べた問題意識をもとに，筆者らは以下のような延でのサービス・アプリ間の通信も可能であり，同時に，ク特徴を組み込んだ Fog コンピューティングテストベッドをラウド上に設置されたリッチなコンピューティングリソー設計した．なお以下の各項目は，前節のそれぞれの問題意ス（計算能力や永続化ストレージ）の利用も可能になる．

識に対応している．

4.3 ノード管理のためのコントロールプレーンの導入
4.1 NGSI および FIWARE データモデルの採用

Fog ノード（Fog コンピューティングテストベッドにおFog コンピューティングテストベッドではサービス・アけるエッジノード）は現場に設置されるノードであり，小プリ間連携のための API とデータモデルに，欧州を中心に型・軽量であることを想定としている．このため所謂 PC開発されスマートシティやスマートビルディング等のシスのようなキーボードや画面などを持たず，その管理はリテムにおいて使用が始まっている NGSI - Next Generation

モート接続によるもの（=ヘッドレス運用）となる．またService Interfaces[13] と，FIWARE データモデル [14] を現場に多数設置され，かつ個々のノードは長期の安定可動採用した．NGSI はデータ交換を担うコンテキストブローを求められない想定である．このため，Fog ノード (群) のカーをハブとした Pub/Sub 型通信モデルで，仕様はオーリモートでの管理のための仕組み（=コントロールプレープンであり，OSS の実装も存在している．FIWARE[15] はン）が必要である．

*1

なお Fog コンピューティングの定義も使用者によって曖昧で定まっていないが，このエッジにおける横連携は OpenFog Consortium における Fog コンピューティングの定義 [8] にほぼ準拠する．

Fog コンピューティングテストベッドのコントロールプ
レーンには大きく２つの機能を持たせる必要があると考えている．１点目はノードへのジョブの配備機能，もう１点

c 2019 Information Processing Society of Japan⃝― 99 ―

クラウドノード VM1 台（さくらのクラウド上）1 コはノード自身の状態把握・管理機能である．

ア 2GB メモリ

ジョブ配備機能については，前項にて現実的なエッジコ
ンピューティングでは複数ジョブの動的配備は考えにくい

SSH Proxy ノード VM1 台（さくらのクラウド上）と述べたが，単一ジョブを利用するだけの想定であっても，1 コア 2GB メモリジョブ（を構成するプログラム）のアップデートを容易に実施するためのジョブデプロイ機能は必要であろう．また• エッジ側サービス・アプリ間の通信のためのデータプレーンを実現

Fog ノード Raspberry Pi 3B+ 4 台，入力デバイスするためのコンテキストブローカーコンポーネント自身もとして赤外線人感検出 (PIR) センサー，出力デバイ一つのジョブであるため，その配備ができる必要がある．

スとして LED アレイを搭載．

Fog ノード (補) Intel

また後者については，コントロールプレーンは各 Fog

BOXSTCK1A8LFC

ノード上に存在しアドレスやその稼働状態を把握し，動作Compute
1 台

Stick

Atom コ ア 1GB メ

モリ

不調等がある場合には再起動や他の Fog ノードへの機能振替等の管理操作を実施する．

SSH Proxy ノードは実装上必要なノードで，FW 内に設これら各ポイントを纏めたシステム構成図（アーキテクチャ図）を図 1 に示す．

置する Fog ノードにクラウド（グローバルアドレス空間）からアクセス可能にするために設定するの SSH トンネル
エントリーポイントを提供する．Fog ノード（補）は，デーApp

タプレーンを構成するコンテキストブローカーが ARM プFIWARE
Data
Model

ロセッサでは動作しないため，Intel x86 プロセッサを搭載
Interoperability

Data Plane
Context
NGSI Broker

したノードとして用意したものである．

NGSI

5.2 データプレーン

Control Plane

Fog コンピューティングテストベッドでは，データプ
Cloud Node

レーンとして実際にメッセージ交換を担うコンテキストブ
ローカーと，サービス・アプリを実現するプログラムは，同じユーザランドのジョブとして扱われる．

AppAppContext

Data Plane

最終的に実現したい現場改善のためのサービス・アプリ
Interoperability

は，クラウド上で実行される「クラウドプログラム」と，エッジの Fog ノード上で実行される「Fog プログラム」のNGSI Broker NGSIControl Plane

Control Plane

FogNodeFogNode

図 1

組み合わせにより構成される．両者を合わせて「Fog アプリケーション」と呼ぶ．なお，各プログラムは Docker コンテナとして構成する．

Fog アプリケーションを構成するクラウドプログラムは

テストベッドシステム構成

クラウドノードに，Fog プログラムは Fog ノードにそれぞれ配備される．Fog アプリケーションのプログラムとは独

なお，Fog コンピューティングとしては本来セキュリ立に，クラウドノード，Fog ノード（のうちの１台）にはティ要件の考慮も重要であるが，これについては今後の検コンテキストブローカーが配備・実行されている．Fog ア

討予定としている．

プリケーションの両プログラムはそれぞれ何らかのイベント発生（センサの検出など）を契機に，他の Fog プログラ

5. テストベッドの実装方式

ムやクラウドプログラムとコンテキストブローカーを経由

本節では，作成した Fog コンピューティングテストベッしてメッセージを交換し，目的の処理を実行できる．

ドの具体的な実装について説明する．

Fog アプリケーションのクラウド・Fog ノード上の各プ

Fog コンピューティングテストベッドは，前節までで説明したようにデータプレーンとコントロールプレーン，さログラム間の通信は，NGSI 準拠の Pub/Sub 型通信モデルにより実施する．
各プログラムは起動時に自分自身をコンテキストブローらにそれらを稼働させる物理的なノード，の３パートによって構成される．それぞれについて説明する．

カーに登録する．これはコンテキストブローカーに対する Subscription 設定の登録として実行される．この Sub-

5.1 ノード構成

scription 登録を実施しないと，当該プログラムは他のプロ• クラウド側

グラムからのメッセージを受信することができない．

c 2019 Information Processing Society of Japan⃝― 100 ―

Fog アプリケーションのプログラムモデルについて図 2

Appに示す．

Job Deploy
Deploy Control

OutputEvent

Cloud Program

Manage Prog.

Cloud Node

AppNGSI
Context Broker

App
Fog ProgramApp

Fog ProgramNGSI

Job Deploy
k3s masterApp

FogNode図 3

Fog アプリケーションプログラムモデル

本テストベッドの特徴として，コンテキストブローカーをクラウド側とエッジ側に２台配置することで，プログラ
ム間のメッセージング経路をクラウド側とエッジ側の２本構成していることが挙げられる．これにより Fog アプリ
ケーションは，低レイテンシでの Fog ノード間通信と，クラウド側でのリッチなコンピューティングリソースの使用や外部のシステムとの連携を自由に使い分けることが可能になっている．
なお，コンテキストブローカーのソフトウェアとしてはOSS の Orion[18], [19] を使用している．

コントロールプレーンの構成

現在 k3s マスターノード自体の選定・設定は静的だが，クラウド側コントロールプレーンからの設定自動化に対応させる予定である．

5.4 アプリケーション
本検討にあたっては，Fog コンピューティングテストベッド上で稼働させるサンプルアプリケーションとして，「光る通路案内」を作成した．人感センサー及び LED が搭載された Fog ノード群を居室廊下等に設置し，人が来たことを検出した場合には LED を光らせることで他の通行者ベント (人物検出) が他の Fog ノード上に高速に伝搬してコントロールプレーンは２つの機能（ジョブ配備機能とノード管理機能）を持つ必要があるが，本テストベッドではこれらは Kubernates（実際にはミニセットの k3s[20]）により実現している．Fog ノード群から任意に選択した１台を k3s マスターノードとして実行させる．k3s マスター
ノードは自身を含めた Fog ノード群を kubernates Nodesとして管理下に置く．クラウド側コントロールプレーンから k3s マスターノードに対して Fog プログラムのコンテナイメージの配備を指示することで，k3s マスターノードがいく形態を持ったアプリケーションを想定してこのようなサンプルを作成した．現状は Fog ノード間での連携だけであるが，データをクラウド側に送信・蓄積し機械学習等により分析させる等で，通行者通知だけでなく進行・停止指示や迂回路提示などの交通案内動作をさせることも想定している．
サンプルアプリケーションの動作について図 4 に示す．
また Fog ノードの実際の様子を図 5 に示す．

6. テストベッドアーキの効果計測

各 Nodes にコンテナイメージを配備する．併せて，k3s マスターノードは各 Nodes の生死状態を把握し，ノード障害が発生した場合には，復帰したときに Fog プログラムを再登録する．
クラウド側コントロープレーンは Kubernates ではなく単一の管理プログラムで，クラウドノード自体にクラウドコントロールプレーン構成について図 3 に示す．

FogNodeに知らせる，というものである．ある Fog ノード上でのイ5.3 コントロールプレーンプログラムを配備する．

k3s worker

Monitoring

ContextBroker

図 2App

本テストベッドでは，エッジ側での高速なノード間連携とリッチなクラウドリソースの利用やクラウド経由での外部連携の実現を想定して，データプレーンを２つ構成している．まずは，この２つのデータプレーンの有効性を検証する必要がある．このため，２つのデータプレーンについて，基礎的な通信遅延とデータ量に関する計測を実施した．

• Fog ノード上でデータ参照リクエストをコンテキスト

c 2019 Information Processing Society of Japan⃝― 101 ―

CloudAnalyze

Fog Node
DetectAisle

Lights up

Aisle
図 4

Fog アプリケーションの構成（光る通路案内）

図 5

実際の Fog ノードの写真

ブローカーに送信し，それが折り返ってくるまでの時おく．ゆらぎの原因はネットワークに起因するものと，ロー間を計測

カルコンテキストブローカー自体の双方に存在していると• 送信するコンテキストブローカーをエッジ側，クラウド側と切り替えてそれぞれの経過時間を計測見られる．Fog ノードからローカルコンテキストブローカーまでの ping 計測の結果について参考までに記載しておく．

(rtt min/avg/max/mdev = 3.335/6.324/9.465/2.201• Fog ノードおよびエッジ側コンテキストブローカーの設置場所はさくらインターネット東京オフィス内• クラウド側コンテキストブローカーの設置場所はさくms)

7. Fog コンピューティングテストベッドの今後

らのクラウド (石狩) データセンタ

本節では，本 Fog コンピューティングテストベッドの設• コンテキストブローカーでの処理遅延を推定するため，各ケースにおいて処理内容の異なるデータ参照リクエ

計及び実装を通じて見えてきた課題と今後の展開について説明する．

ストと，それらと別に ping による応答遅延時間も計測
計 測 結 果 に つ い て 表 1 に 示 す ．計 測 内 容 に お け る

RTT(nop) はコンテキストブローカーにおいて実際のデー
タベースアクセスを伴わないバージョン取得コマンド，RTT(op) はデータベースアクセスを伴う subscription 登
録内容取得コマンドに対応している．
クラウドとの間では RTT 20[msec] と，エッジ折返しの場合（13.97 [msec]）のおよそ 1.4 倍の応答遅延が掛かっていることが計測された．したがって，クラウド折返しではなくエッジ内折返しを利用したほうが高速にノード間連携が実施できることが確認できた．
しかしながらクラウド折返しとエッジ内折返しの差は僅差とも言える．これは，エッジ内折返しにおいて Fog ノードが接続している無線 LAN での折返しの遅延が大きいことや，ローカルコンテキストブローカーの処理時間が大きいこと，また逆に，クラウドまでの通信遅延が小さいこと（実際上弊社内に閉じた経路のため有利）などが考えられる．
もう一点，エッジコンテキストブローカーとの通信においては，計測時にジッタが大きかったことも特徴として挙げて本テストベッドの設計と実装の過程で明らかになった課
題としてまず挙げられるのは，エッジ環境側が FW 下のプライベート空間にあることで，直接接続やシームレスな制御・管理ができないということである．具体的には以下のような点が明らかになった．

1) データプレーンにおいてクラウドからエッジへは直接接続できない．現在の実装では SSH トンネルを構築して接続可能にしているが，ここはセキュリティ観点から検討が必要であろう．2) データプレーンを構成するための Subscription 設定がクラウド側とエッジ側で２重管理になっている．クラウド側のコンテキストブローカーに投入する Subscription 設定は，SSH トンネルの外側アドレス（グローバルアドレス）を指定するのに対し，エッジ側のコンテキストブローカーに投入する Subscription 設定は，LAN 内アドレスを指定するため，設定内容を共有できない．3) クラウドとエッジ間でコントロールプレーンが途切れている．エッジ側の Fog ノード群の管理のためにKubernetes(k3s) を用いているが，そのマスターノードもFog ノード上にあり，クラウド側からマスターノードに対する指示は独自プロトコルに依っている．

c 2019 Information Processing Society of Japan⃝― 102 ―

表 1 Fog ノードからのエッジ内折返し，クラウド折返しの計測結果 (単位はいずれも [msec])
ターゲット

RTT(nop)

RTT(op) ( ∆ )ping ( δ )推定処理時間 ( ∆ − δ )エッジコンテキストブローカー

8.90

13.97

6.32

7.65

クラウドコンテキストブローカー (石狩)

20.01

20.26

19.71

0.55

また別の課題として設定の自動化が不十分な点も挙げられる．設定自動化はテストベッドとしての使い勝手に直として，現場デバイスを連携させたシステムにおける設計指標を得ることができた．

結し，また可用性の面からも重要である．また最終的にはまた，テストベッドの設計・実装を通じ，FW 下にある

Fog コンピューティングの普及に大きく影響するので十分

エッジ環境をクラウド側とシームレスに接続させる点やそな検討と対応が必要と考えている．a) データプレーンのれを考慮した上での設定自動化方法についての課題点を実体であるコンテキストブローカーの配備が現状手動であ得た．
今後はこのテストベッド上で様々なアプリ・サービスをる．b) エッジ側コントロールプレーンの k3s マスターノー実装・実行させ相互接続性についての知見を深めながら，ドの設定は現在静的構成である．
特にエッジ側の自動化は，上述の FW 環境下での接続に同時に上述の課題解決方法についての検討・実装，さらな関する問題と関係するため，今後早急に検討を進めたいとる評価を進めていく予定である．現場に溶け込んだ次世代考えている．

コンピューティング環境におけるより一般的な機能要件・使い分けは，求められるレイテンシ，必要帯域，通信コ性能要件の抽出とその解決手段の開発を進める予定である．

ストや，将来的に想定される動的なプログラムデプロイ等を考慮して，何らかの判定基準により自律的に決定される参考文献ことが望ましい．現時点では，そもそもどのようなアプリ[1]

ケーション想定でどの程度の遅延が求められる/許容されるのか，またデータ通信量がどの程度になるか，などが明[2]らかになっておらず判定基準を議論できる段階に至っていない．この点から，メッセージングの基礎的なデータを収[3]集すべく実際に計測を実施した．この内容については第 6節で説明した．
[4]

8. まとめ[5]

本研究に置いて筆者らは，サイバーフィジカルコンピューティングなど次世代コンピューティング環境の実現に向けて，エッジコンピューティングを現場環境に投入することを前提に，システム・アプリ間の連携，局所的な小さいシ[6]ステム間の相互接続を重視し，それに対応した Fog コン
ピューティングテストベッドを設計・開発した．
筆者らが開発した Fog コンピューティングテストベッ[7]

ドでは，現場エッジの Fog ノード，クラウド上でクラウドノードを組み合わせた Fog アプリケーションを稼働させる[8]ことができる．またデータプレーンとしてクラウド上に配備したコンテキストブローカー，Fog ノードに配備したコ[9]ンテキストブローカーによる２経路のメッセージ交換が可能である．また，それらアプリケーションを配備・稼働させるため，およびノード管理ための，コントロールプレーンを構成・（部分的に）実装し，その必要要素を抽出した．
今回は，テストベッドのアプリとして人感センサー反応

[10]
[11]
[12]を契機にした光る道案内サービスを試作し，人検出からデバイスの表示器が光るまでの応答速度について，クラウド経由，エッジ内経由での差異について評価した．その結果[13]c 2019 Information Processing Society of Japan⃝― 103 ―

岩野和生，高島洋典： サイバーフィジカルシステムと IoT(モノのインターネット) 実世界と情報を結びつける，情報管理， Vol. 57, No. 11, pp. 826–834 (2015).
Satyanarayanan, M.: The emergence of edge computing,Computer, Vol. 50, No. 1, pp. 30–39 (2017).
さ く ら イ ン タ ー ネ ッ ト： さ く ら イ ン タ ー ネ ッ ト 、フ ォ グ コ ン ピ ュ ー テ ィ ン グ を 推 進 す る「OpenFog Consortium」に加入，https://www.sakura.ad.jp/
information/pressreleases/2016/04/13/90130/.
菊地俊介： Fog コンピューティングのご紹介，https://research.sakura.ad.jp/2017/12/08/intro-fog/.
さくらインターネット： さくらインターネット、「FogWorld Congress 2018」で 実 施 す る フ ォ グ コ ン ピ ュ ーテ ィ ン グ の 日 中 台 相 互 接 続 デ モ に「 さ く ら の ク ラ ウド」を提供，https://www.sakura.ad.jp/information/pressreleases/2016/04/13/90130/.
飯田勝吉： エッジコンピューティング研究開発の現状と今後の課題 (インターネットアーキテクチャ)，電子情報通信学会技術研究報告= IEICE technical report: 信学技報， Vol. 117, No. 187, pp. 25–30 (2017).
ETSI:
Multi-access
EdgeComputing(MEC),
https://www.etsi.org/technologies/
multi-access-edge-computing.
OFC:OpenFog
Consortium,
https://www.openfogconsortium.org/what-we-do/#definition-of-fog-computing.
IIC: Industrial Internet Consortium, https://www.
iiconsortium.org/.
AWS: AWS IoT Greengrass, https://aws.amazon.com/jp/greengrass/.
Microsoft:Azure IoT Edge, https://azure.
microsoft.com/ja-jp/services/iot-edge/.
Satyanarayanan, M., Bahl, P., Caceres, R. and Davies,
N.: The case for vm-based cloudlets in mobile computing, IEEE pervasive Computing, No. 4, pp. 14–23(2009).
Jose Manuel Cantera Fonseca, Fermin Galan Marquez, T. J.:
FIWARE-NGSI v2 Specification,
http://telefonicaid.github.io/fiware-orion/

[14]
[15]
[16]
[17]

[18]

[19]
[20]

api/v2/stable/.
FIWARE: FIWARE DATA MODELS, https://www.
fiware.org/developers/data-models/.
FIWARE: FIWARE, https://www.fiware.org/.
国土交通省： スマートシティの実現に向けて【中間とりまとめ】，http://www.mlit.go.jp/common/001249774.pdf.
総 務 省： 総 務 省 に お け る ス マ ー ト シ テ ィ の 展 開 について，https://www.kantei.go.jp/jp/singi/tiiki/
kokusentoc/supercity/dai2/shiryou2.pdf.
telefonicaid:
An implementation of the Publish/Subscribe Context Broker GE, providing NGSIinterfaces.,
https://github.com/telefonicaid/fiware-orion.
Telefonica: Welcome to Orion Context Broker., https://fiware-orion.readthedocs.io/en/master/.
LABS, R.: Lightweight Kubernetes, https://k3s.io/.

c 2019 Information Processing Society of Japan⃝― 104 ―