超個体性をもったエッジコンピューティング実現に向けたElixir/Nerves環境の適合性評価

さくらインターネット研究所および筆者は、超個体型データセンターの実現を目指し、クラウド・エッジに加えエンドデバイスも包含して扱うことのできるシステム・アーキテクチャについて調査検討している。本検討では、組み込みシステムに親和性の高いElixir/Nerves (言語) 環境の特徴がエッジコンピューティングにどのように適合するか、またその他の実現手段 (Kubernetes/サービスメッシュ等) に対してどのような得失を持っているかを評価・報告する。
本資料は、ITRC RICC-PIoT workshop 2021の発表資料です。

Transcript

1. 超個体性をもったエッジコンピューティング 実現に向けた Elixir/Nerves環境の適合性評価 ITRC RICC-PIoT workshop 2021 2021/03/06 (C) Copyright 1996-2021 SAKURA Internet Inc さくらインターネット研究所 上級研究員 菊地俊介 さくらインターネット株式会社
2. はじめに • さくらインターネット研究所では、超個体性を持ったコン ピュータネットワークインフラストラクチャ(超個体型データセ ンター)の実現を⽬指し、クラウド・エッジに加えエンドデバイ スも包含して扱うことのできるシステム・アーキテクチャにつ いて研究を進めている。 • クラウドとエッジ・エンドを統合して扱う際に求められる要件 を抽出した上で、それに合うシステムアーキを提案していく。 • 適合するシステム例（案）としてElixir/Nervesを調査検討中。 • 本資料の構成 • エッジ環境に求められる要件とは • 様々なシステム • 課題定義と仮説 • Elixir/Nerves評価 2
3. 【参考】エッジコンピューティングの概要 ※ Z. Zhou et al.: Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge computing, Proceedings of the IEEE, Vol. 107, 1738 2019. 3 エッジコンピューティングも様々なタイプがあり、求められる要件や適合するシステム構成も様々。 センサ収容、スモー ルエッジタイプ エッジAIタイプ ⾃動⾞(V2X) タイプ Micro-DataCenterタイプ(ビッグエッジ)
4. 本検討にて検討対象とするエッジ環境の例１ スマートホーム • 現状では、エッジ環境内での装置間直接連携はしない • 装置とクラウド上のサービスがつながる • クラウド上のサービスとサービスがつながる • 制御はすべてクラウドから • 同⼀エッジ環境内にある装置間であっても連携はクラウドで • 装置ベンダーのサービスにがっちり紐付け 4 エンドデバイス エッジ環境 サービス クラウドノード クラウド
5. 本検討にて検討対象とするエッジ環境の例２ ⾃前IoT • エンドデバイスとその制御システムを⾃前で構築、 エッジ環境内で直接連携可能だが管理⼯数は⼤きい • 管理系としてKubernetesなどのオーケストレータを導 ⼊することは可能 • クラウド側から管理する、エッジ環境内で閉じるなどいくつ かのパターン有り 5 エンドデバイス エッジ環境 管理サービス (Kubernetes) 管理サービス (Kubernetes) エッジノード クラウドノード クラウド
6. 対象とするシステム構成 エンド-クラウドでもなく、分散システムでもない、 エンド・エッジ・クラウドの3要素からなるシステム 7 クラウドでの サービス エッジノード 現場とエッジ、現場とエッジとクラウド、での管理システムに 現場 （エンドデバイス） 現場 （エンドデバイス） クラウドでの サービス ワークノード 管理サービス ワークノード 管理サービス
7. 求められる機能・性能（概要） • （超個体型データセンターを⾒据え、）クラウド・エッジ・エンドの階層型かつ、 エッジ-エッジ間など横にもつながる、分散型のシステム • （これまでのようなInternet/IPということにとどまらず、）IoTに特有の特徴を カバーする機能・性能をもたせる 8 クラウド エッジ スモール システム センサ アクチュ エータ Hub エッジ スモール システム withクラウド ノード単体機能・性能 • ⾼速・リアルタイム • 低消費電⼒ • ⾼信頼・⾼可⽤ システム構成管理 • 繋げやすい • 柔軟性（動的構成変更可能） • OTAアップデート可能 • 初期導⼊が容易 • デバイスディスカバリ機能 セキュリティ • 認証認可 • 侵⼊防⽌ • プライバシー（データ流出防⽌） センサ アクチュ エータ Hub →これは何かといえば、Fogなのでは︖ 移動する NATに対応 ライフタイム が⻑い
8. 候補となりそうな技術体系１ • Edge X Foundary • https://www.edgexfoundry.org/ 9
9. 候補となりそうな技術体系２ • FIWARE : www.fiware.org • 主信号系の標準化（NGSI, FIWAREデータモデル）に焦点 • 管理系は弱い • オーケストレータの例︓ FogFlow (NEC) 10 • B. Cheng, G. Solmaz, F. Cirillo, E. Kovacs, K. Terasawa, and A. Kitazawa, “FogFlow : Easy Programming of IoT Services Over Cloud and Edges for Smart Cities,” IEEE Internet of Things Journal, vol.5, no. 2, pp.696–707, 2018. • 菊地（さくら）, 正木, 三谷, 山根, 高浦(日立), “クラウド・エッジでの自在な機器接続を目指したFogコンピュー ティングテストベッドの構築”, 信学会SC研究会, https://www.ieice.org/ken/paper/202103197C3b/, Mar, 2021.
10. 候補となりそうな技術体系２ • FIWARE/NGSI • 典型的Pub/Subモデル • 管理機能は後付け 11 VM OS Hardware Context Broker OS Hardware App OS Hardware Context Broker エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス アプリケーションプロセス OS (Linux) NGSI NGSI NGSI
11. 候補となりそうな技術体系３ • ⾃前IoT • 汎⽤であるがゆえに作りやすいが⾮機能要件は満たしにくい • 管理機能は後付けになる 12 VM OS Hardware App OS Hardware App OS Hardware App エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス アプリケーションプロセス OS (Linux)
12. 候補となりそうな技術体系３.1 • ⾃前IoT/k8s/サービスメッシュ • 汎⽤であるがゆえに作りやすいが⾮機能要件は満たしにくい • Kubernetes / Service Meshにより管理機能・主信号制御機 能を付与 13 VM OS Hardware App OS Hardware App OS Hardware App エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス Mgr. Sidecar Sidecar Sidecar Sidecar Kubernetes アプリケーションプロセス サイドカープロセス OS (Linux)
13. 候補となりそうな技術体系４ • Elixir/Nerves • （ElixirはErlangをベースにした関数型、アクターモデル採⽤⾔語） • （NervesはIoT向け統合開発環境） • （Nerves-Hubはデプロイ・端末管理環境） • ⾔語仕様に組み込みの、管理機能（親⼦プロセス監視、ログ送信等） • アクターモデルは、DB依存度合いを下げる 14 VM Hardware Hardware App OS Hardware エンドデバイス エッジノード クラウド Hypervisor OS OS Mgr. Nerves-Hub Linux OS(汎⽤) Elixirプロセス OS Linux OS BEAM App App BEAM BEAM Erlang仮想マシン BEAM Nervesでは1パッケージ化して扱う Hardware App OS BEAM エンドデバイス
14. 各システム機能⽐較 • すべての項⽬について⽐較評価することは実際には難しい • 理由︓共通の評価尺度を規定できない、適⽤できない 15 ノード単体機能・性能 システム構成管理 セキュリティ ⾼ 速・ リア ルタ イム 低消費 電⼒ ⾼信頼・ ⾼可⽤ 繋げや すい 柔軟性 （構成変 更可能） OTA- Update 初期導 ⼊容易 デバイス ディスカ バリ 認証 認可 侵⼊ 防⽌ プライ バシー FIWARE/NGSI /w FogFlow △ △ △ ◦ ◦ ◦ × × ◦ ︖ ◦ ⾃前 (Linux/k8s/ ServiceMesh) △ △ △ △ ◦ ◦ × × ◦ △ ◦ Elixir/Nerves ◦ ◦ ◦ ◦ ◦ ◦ △ ︖ ◦ ◦ ◦ スマート ホーム (Google Home) ︖ ? ? △ △ ◦ ◦ × ◦ ◦ × AWS Greengrass △ △ △ △ △ ◦ △ × ◦ ◦ ◦ EdgeX ? ? ? ? ? ? ? ? ? ? ?
15. 要件定義と調査項⽬ • 求められる機能・性能（今回注⽬したい対象） • システム構成管理 • 繋げやすい • 柔軟性（構成変更可能） • OTAアップデート可能 • 初期導⼊が容易 • デバイスディスカバリ機能 • 要件 • 管理機能はクラウド側に置く（置ける） • 理由︓エッジ環境は不安定、管理機能は安定した側に置きたい • データはエッジ内で折り返し利⽤できる • 理由︓プライバシーデータを外に出したくない、通信量削減、早い応答速度 • 評価項⽬ • クラウドからOTAでエッジ・エンドをアップデートできるか︖ • クラウドからエッジ・エンドを初期導⼊できるか︖ • エッジ内折返しで連携（データ通信）できるか︖ →可否の確認と、難しさ、課題の抽出 16
16. Elixir/Nerves-Hub評価 17 Hardware VM Hardware VM BEAM App Mgr.Nerves-Hub App クラウド エッジ User-Terminal Hardware VM User-Terminal Mgr. App Nerves-Hub App BEAM Mgr.Nerves-Hub ノード構成 NervesHubで想定 されている構成 クラウド利⽤構成 （作りたい構成） アプリ登録 OTA-Update Firmware作成 (SDCard) 開発マシンで初期Firmware作成、 以降アプリはOTAでUpdate User-Terminal アプリ登録 OTA-Update Firmware作成 (SDCard) クラウド上でアプリ開発・登録、 OTAでUpdate。 （初期Firmwareどう焼く︖） • クラウドからOTAでエッジ・エンドをアップデートできるか︖ • クラウドからエッジ・エンドを初期導⼊できるか︖ ⾃宅
17. Elixir/Nerves-Hub評価 18 % mix nerves.new hello_nerves_hub （プロジェクト作成） % mix deps.get （関係ライブラリ等取得） % mix nerves_hub.user register （Nerves-Hubにユーザ登録） % mix nerves_hub.user auth （Nerves-Hubユーザ認証） % mix nerves_hub.key create devkey （デバイス認証キー作成） % mix nerves_hub.product create （プロダクト（Firmwareの入れ物）作成） % mix nerves_hub.device create （Nerves-Hubにデバイス登録） % mix nerves_hub.device cert create ID （サーバ証明書生成・取得） % mix firmware （Firmware作成） % export NERVES_SERIAL_NUMBER ID % export NERVES_HUB_CERT xxx % export NERVES_HUB_KEY yyy % fwup -a -i firmware.fw -t complete （FirmwareのSDカード焼付） Hardware VM User-Terminal Mgr. Nerves-Hub firmwareと サーバ証明書 をコピー SDCardを Hardwareに挿⼊ • SDカード焼付のため にローカル端末での 作業必要 • それ以外はクラウド 側で環境構築・開発 できる App
18. Elixir/Nerves-Hub評価 19 % vi mix.exs （プログラム更新） % mix deps.get （関係ライブラリ等取得） % mix nerves_hub.firmware publish --key devkey （更新ファームウェアの登録） （Nerves-Hub上でGUI操作によりUpdate実行） Hardware VM User-Terminal Mgr. Nerves-Hub • OTA-Updateはクラウドから 問題なく可能 App
19. Elixir/Nerves-Hub評価 • Linux/k8s/ServiceMeshとの⽐較 20 Hardware VM BEAM App Mgr.Nerves-Hub App User-Terminal × クラウド利⽤構成 （Elixir/NervesHub） Hardware VM User-Terminal Linux App Sidecar Linux Mgr. k8s(Master) App クラウド利⽤構成 （Linux/k8s/SM） トンネルを通すためのNAT設定 k8s環境でもOTA-Update可能だが、初期設定やネットワーク設定が必要 初期設定（OSセット アップ、k8s設定） 要調査 : KubeEdgeなら︖
20. Elixir/Nerves-Hub評価 • FIWARE/NGSI/FogFlowとの⽐較 21 Hardware VM BEAM App Mgr.Nerves-Hub App User-Terminal × クラウド利⽤構成 （Elixir/NervesHub） Hardware VM User-Terminal Linux App Linux Mgr. FogFlow クラウド利⽤構成 （FIWARE/NGSI/ FogFlow） トンネルを通すためのNAT設定 初期設定（OSセット アップ、FogFlow設定） Context Broker 調査不十分
21. まとめ • 評価結果 • Elixir/Nervesでクラウド開発環境を構築することは可能（動く） • ただし、現時点ではローカル開発端末依存を完全に排除できない • 通信開始の⽅向性依存等がある可能性も • 鍵管理などが煩雑 • エンドデバイスの秘密鍵・公開鍵両⽅をローカル開発端末にコピーする必要が あるなど • 今後の検討の⽅向性 • より踏み込んだ管理⽅式の調査・検討 • ネットワーク⾯では、NAT対応可否、NAT超えての横連携の可否など • セキュリティ関連については、公開鍵を使う⽅式の他に、MACアドレスを 利⽤する⽅式などもある • クラウド開発環境を⽤意してさくらからトライアル提供したい • エッジ開発の敷居を下げるため • そのために必要となる要素技術開発をすすめる 22
22. おまけ︓さくらで作りたい構成 • Elixir/Nerves⽤クラウド環境 • エンド・エッジデバイスに向けてFirmware導⼊、状態監視、 ログ閲覧、リモートログインができるように • サーバサイドサービス(Phoenixアプリ)も実⾏できる 23 VM Hardware Hardware App OS Hardware エンドデバイス エッジノード クラウド (x86) Hypervisor OS OS Mgr. NervesHub (⾃前) BEAM App App BEAM OTAアップデート BEAM SSHd SSH リモートトンネル