Download to read offline
![方式の評価結果
• エッジでの折返しが非常に遅い事が判明
→エッジノード自体が遅い 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ノード
コンテキストブローカー
コンテキストブローカー](https://image.slidesharecdn.com/dicomopresentation-20190703-190704093446/75/Fog-9-2048.jpg)
Uploaded byShunsuke Kikuchi
ノード間通信の優位性評価を目的としたFogコンピューティングテストベッドの構築に関する一検討
ノード間通信の優位性評価を目的としたFogコンピューティングテストベッドの構築に関する一検討, 情報処理学会, DICOMO2019 での発表資料です。
ノード間通信の優位性評価を目的としたFogコンピューティングテストベッドの構築に関する一検討
- 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 Pi3B+をベースにした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