ノード間通信の優位性評価を目的としたFogコンピューティングテストベッドの構築に関する一検討, 情報処理学会, DICOMO2019 での発表資料です。

1. ノード間通信の優位性評価を目的とした
Fogコンピューティングテストベッドの
構築に関する一検討
菊地 俊介†、佐々木 健‡、大木 裕介‡、松本 亮介†
†：さくらインターネット株式会社 さくらインターネット研究所
‡：フリーランス
2019/07/03 さくらインターネット株式会社 さくらインターネット研究所 上級研究員 菊地 俊介
(C) Copyright 1996-2016 SAKURA Internet Inc

2. 本資料（発表）の構成
• 本研究の目的
• 既存検討・背景
• 問題意識
• 提案方式
• アーキテクチャ
• 評価結果
• 課題
• 今後の検討方針
2

3. この研究の目的
• エッジコンピューティングを研究中
• 実際上のエッジコンピューティングの普及にむけた課題の発見
• 「超個体型データセンタービジョン」を想定した、クラウド・
エッジ・現場を柔軟に組み合わせたシステムモデルの確立
• 実際に作りながら、課題を抽出し解決していく
• Fogテストベッドを構築
• アプリを載せて動かし検討を進める
4

4. 既存検討・背景
• 「エッジコンピューティング」は、それを語る人のバックグラウンドに
よって内容が異なり定義は曖昧。ここではこのように分類する。
5
分類 MEC型 IIC型 クラウド延伸型
説明
携帯電話の基地局の
コンピューティング
リソースを活用
産業システムを母体に
エッジの標準化を目指す
クラウドのエコシステム
をエッジ領域に延伸しよ
うとするもの
推進団体・
組織
MEC (Multiaccess
Edge Computing)
IIC (Industrial Internet
Consortium),
EdgeX Foundry
AWS Greengrass,
Azure IoT Edge,
Google Cloud Iot Edge
階層
3
（クラウド、エッジ、
デバイス）
3〜
（クラウド、エッジxN段、
デバイス）
2〜
（クラウド、エッジxN
段、デバイス(0〜N段)）
エッジの
所有者
携帯電話事業者など。
単一事業者。
そのエッジ領域の管理者
（工場管理者等）
個々のエッジシステム
（小領域）の所有者
備考
OpenFogコンソーシアム
などもここに入る
• 飯田勝吉 : エッジコンピューティング研究開発の現状と 今後の課題 (インターネットアーキテクチャ)，信学技報， Vol. 117, No. 187, pp. 25–30 (2017).
• 秋山豊和, 他 ：エッジコンピューティング環境を考慮したDataflow platformにおけるコンポーネント管理方式と配備戦略, Webシステムアーキテクチャ研
究会, 2019/04/13

5. 分類 MEC型 IIC型 クラウド延伸型
説明
携帯電話の基地局の
コンピューティング
リソースを活用
産業システムを母体に
エッジの標準化を目指す
クラウドのエコシステム
をエッジ領域に延伸しよ
うとするもの
推進団体・
組織
MEC (Multiaccess
Edge Computing)
IIC (Industrial Internet
Consortium),
EdgeX Foundry
AWS Greengrass,
Azure IoT Edge,
Google Cloud Iot Edge
階層
3
（クラウド、エッジ、
デバイス）
3〜
（クラウド、エッジxN段、
デバイス）
2〜
（クラウド、エッジxN
段、デバイス(0〜N段)）
エッジの
所有者
携帯電話事業者など。
単一事業者。
そのエッジ領域の管理者
（工場管理者等）
個々のエッジシステム
（小領域）の所有者
備考
OpenFogコンソーシアム
などもここに入る
既存研究・背景
• 本研究では、普及への道筋の現実性などから、クラウド延伸型を前提
として研究・検討を実施
6
• 飯田勝吉 : エッジコンピューティング研究開発の現状と 今後の課題 (インターネットアーキテクチャ)，信学技報， Vol. 117, No. 187, pp. 25–30 (2017).
• 秋山豊和, 他 ：エッジコンピューティング環境を考慮したDataflow platformにおけるコンポーネント管理方式と配備戦略, Webシステムアーキテクチャ研
究会, 2019/04/13

6. • 独立したエッジシステムが徐々につながる、という経過をたど
るのではないか（仮説）
• エッジ・クラウド双方での「繋がりやすさ」が重要
• →独立したエッジシステムが繋がれるようにする（=相互接続性）
• →低レイテンシで相互接続（連携）できるようにする（=高速性）
問題意識 : 現実的なエッジコンピューティングの普及の形態とは？
7
クラウド
エッジ
システム
……
ある一つの現場 ある一つの現場
１テナント １テナント

7. 提案方式（Fogコンピューティング テストベッド）
• 提案アーキの特徴
【相互接続性】
• オープン規格のNGSIを採用
【高速性】
• ローカル（エッジ）コンテキ
ストブローカーとグローバル
（クラウド）のコンテキスト
ブローカーを併用
8
FogNode
App
Control Plane
Data Plane
Context
Broker
Cloud Node
Context
Broker
App
FogNode
Control Plane
Control Plane
App
Interoperability
Inter-
operability
Data Plane
NGSI NGSI
NGSI NGSI
FIWARE
Data
Model
図：提案方式のアーキテクチャ
エッジ・クラウドでアプリが縦横に接続可能なシステム形態を
Fogコンピューティングと定義し、そのアーキテクチャを設計
NGSI : Next Generation Service Interface -
http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-
A/OMA-AD-NGSI-V1_0-20120529-A.pdf

8. 試作した実際のシステム構成
• Raspberry Pi 3B+をベースにしたFogノードを構築
9
Analyze
Fog Node
Aisle
De-
tect
Cloud
Aisle
Lights up
テストベッドノード諸元：
Fog Node : Raspberry Pi 3B+, 赤外線人感センサー（PIR）、LEDアレイ x6台
Fog Node（CB用）: Intel Compute Stick BOXSTICK1A8LFC（ATOM, 1GB Mem）
Cloud Node : さくらのクラウド VM（石狩） （1Core, 2GB Mem）
Cloud Node（SSH Proxy用）: さくらのクラウド VM（石狩） （1Core, 2GB Mem）
Context
Broker
サンプルアプリケーション「光る通路案内」

9. 方式の評価結果
• エッジでの折返しが非常に遅い事が判明
→エッジノード自体が遅い 10
ターゲット RTT（単純折返し） RTT(処理あり) ping結果 推定処理時間
エッジ
コンテキスト
ブローカー
8.90 13.97 6.32 7.65
クラウド(石狩)
コンテキスト
ブローカー
20.01 20.26 19.71 0.55
テスト環境（東京）のFogノードからの折返し時間の計測結果（[msec]）
20.26 [msec]
13.96 [msec]
実験環境（東京） さくらインターネット
石狩データセンタ
……
Fogノード
コンテキストブローカー
コンテキストブローカー

10. 明らかになった（その他の）問題点
• Firewallに起因する問題
（通信方式、データモデル上では、クラ
ウドもエッジも同一だが、実際には
Firewallとトンネルが存在している）
• データプレーン
• SSHトンネルが許可されないケースが想
定される。
• Context Brokerに投入する設定（ノー
ド登録、通知設定）が、クラウドとエッ
ジで二重管理になる。
（クラウド側から見えるエッジのアドレス
と、エッジ側でエッジ自身のアドレスが異
なることによる）
• コントロールプレーン
• クラウドとエッジが別の管理システムに
なっている
11
FogNode
App
Cloud Node
FogNode
k3s worker
Deploy Control
k3s master
Monitoring
Job Deploy
Job Deploy
App
App
Manage Prog.
App
App
App
Cloud Program
Fog Program
EventOutput
NGSI
NGSI
Context Broker
Context
Broker
Fog Program
SSH Tunnel
Firewall
通信モデルとSSHトンネル
コントロールプレーンとFirewall
Firewall

11. まとめ、今後の検討方針
• 現実的なエッジコンピューティングの普及形態（＝少システムが徐々につ
ながっていく）を仮定し、そこに向けた課題抽出を目的として調査研究を
実施した。
• 1. NGSIを採用し相互接続性を確保、2. エッジとクラウドの双方に相互接
続点（コンテキストブローカー）を配置、という特徴を持ったアーキテク
チャを採用。
• 試作システムを作成し、評価した。
• 評価結果：
• クラウド折返しに対してエッジ折返しが高速であることは確認
• エッジ折返しが（期待より）遅い→ネットワーク層やエッジノードの性能が重要
• その他の問題：Firewallに起因して、データプレーン、コントールプレー
ン双方が単一システムになっていない。
• 今後は、求められるエッジコンピューティングの実像に合う実装を考える。
• クラウド・エッジ併用のシステムモデル、その相互接続モデルを確立して
いく。
12