Elixir/NervesHubによるエッジコン ピューティング環境実現に関する検討 Web System Architecture研究会 第７回 2020/11/13 (C) Copyright 1996-2020 SAKURA Internet Inc さくらインターネット研究所 上級研究員 菊地 俊介 さくらインターネット株式会社

⾃⼰紹介 2 菊地 俊介 （東京都出⾝、品川区在住） 所属 さくらインターネット研究所 学歴 早稲⽥⼤学⼤学院 理⼯学研究科 電⼦・情報通信学専攻 修⼠課程修了 早稲⽥⼤学⼤学院 国際情報通信研究科 博⼠課程単位取得退学 職歴 富⼠通（株）富⼠通研究所に就職 ネットの研究やったり、SEやったり、 NICTに出向したり、トイレIoT作ったり さくらインターネットに転職 データ流通（FIWARE, NGSI）、OpenFogコンソーシアム（標準化）、 量⼦（アニーリング）コンピュータ、 AR/VR、モビリティ、RISC-V 専⾨ エッジ・Fogコンピューティング（分散系システムのあたり） ビジョナリーとして技術・社会、会社の将来を思い描く 趣味 新技術調査、鉄道、読書（主にSF）、最近はガンプラ作り @kikuzokikuzo https://note.mu/kikuzokikuzo https://www.facebook.com/ kikuzokikuzo

発表内容、本資料の構成 1. はじめに（前提） 1. 超個体型データセンター 2. エッジコンピューティング 2. エッジスモールシステムのシステム・アーキテク チャ 3. エッジスモールシステムの要件 4. 想定システムと従来⽅式 5. 調査・評価 • Elixir/NervesHub • Kubernetes/ServiceMesh 6. 考察 7. まとめ 3

1. 研究所ビジョン 超個体型データセンターコンセプト （1/2） 超個体型データセンター : Super Organism Data Center 序⽂ • クラウド時代の⼀極集中構造が限界に達し、エッジコンピュー ティングによる半集中の階層構造を利⽤しつつも、さらに分散 化が進み、あらゆるデバイスや場所にデータセンター的な機能 が溶け込んでいく。 • しかし、各コンピューティングは独⽴した個体として機能しな がらも、総体としては統率されているようにみえたり、⼩・中 規模データセンターがハブとなって結果的に全体がうまく繋が れ、構成されていく。その様は、分散された各個体と集中する 各個体が群体をなしており「超個体的」であるといえる。 • 各コンピューティングが⾃律的に分散と集中のハイブリッド構 造をとるような環境を「超個体型のデータセンター」、各デー タセンターを総体として透過的に扱えるOSを「超個体型データ センターOS」と定義する。 4

1. 研究所ビジョン 超個体型データセンターコンセプト （2/2） 1. 現在はデータセンターに巨⼤なコンピューティングリソースが存在してい るが、今後は、レイテンシ・セキュリティ・コスト等の要件から、あらゆ る場所や社会（組織）にコンピューティングリソースが溶け込んでいくこ とになる。 2. それら分散したコンピューティングリソースは、単独でコンピューティン グパワーを提供するにとどまらず、その場所や社会の要求に応じて、⾃律 的に、分散あるいは有機的に結合し、現場・クラウドそれぞれが縦横に結 びついたハイブリッド構造をとれるように機能する。 3. そのようなシステムにより実現されるものは、⼈々の⾝近に存在し、リア ルタイムかつインテリジェンスにユーザを⽀えながら、しかし同時にバッ クエンド側が有機的に結合することにより、かつてないマシンパワーとリ ソース量を動員することで現場最適かつ全体最適をも実現するSuper Organism Worldである。 4. さくらインターネット研究所はこのようなビジョンのもと、Super Organism Worldを実現する超個体型データセンターシステムやそれを統 括管理する超個体型データセンターOS等の研究開発を推進していく。 5

1. 様々なタイプのエッジコンピューティング ※ Z. Zhou et al.: Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge computing, Proceedings of the IEEE, Vol. 107, 1738 2019. 6 本検討で注⽬したいのは「センサ収容、スモールエッジタイプ」 センサ収容、スモー ルエッジタイプ エッジAIタイプ ⾃動⾞(V2X) タイプ Micro-DataCenterタイプ

1. エッジコンピューティングとはなにか、その要件 エッジコンピューティングの（究極の）⽬標 • 現場での制限なしのコンピューティングの利⽤、その環境の構築 • コンピューティングおよびネットワーク利⽤の最適化（地産地消化） エッジコンピューティングの（より現実的な）⽬標 • エッジとクラウドをシームレスに使えるコンピューティング環境の実現 • クラウド、エッジそれぞれの特徴を活かす 7 地域IP網 =フレッツ網 コア網＝ インターネット網 携帯電話網 クラウド クラウド クラウド ⾃営網 オンプレ設備 （有線）キャリアネットワーク 携帯ネットワーク クラウドをエッジに延伸することで、 クラウドエコシステムを活かす リソース・性能を⾃由・動的に 選択・組み合わせ可能に 移動に対応する アクセスネットワークの機能を取り込む …

• 独⽴したエッジスモールシステムが徐々につながる、という経 過をたどるのではないか（仮説） • エッジ・クラウド双⽅での「繋がりやすさ」を重視する • →独⽴したエッジスモールシステムが繋がれるようにする • →⾼速、簡単に相互接続（連携）できるようにする 2. エッジスモールシステムによるエッジコンピューティングの実現 8 クラウド エッジ スモール システム …… ある⼀つの現場 ある⼀つの現場 １テナント １テナント 連携 センサ アクチュ エータ Hub 連携 エッジ スモール システム withクラウド

エンドデバイス • センサ・アクチュエータなど単機能・低機能なものと、PCやスマートフォン等の⼈間が操作するこ とを想定したリッチデバイスの２種類。電源投⼊状態や位置（物理位置、ネットワーク接続位置） が常に変動する。 エッジノード(Hub) • センサ・アクチュエータなどのデータを仲⽴ちする、現場に近いところに設置するスモールエッジ ノードと、⼤量のデータを集め処理・保存するビッグエッジノードの２種類。電源投⼊状態や位置 が常に変動する（特にスモールエッジノードにおいて）。 スモールシステム • エンドデバイスとエッジノードの組み合わせで、ある現場領域において意味のある処理（アプリ ケーション）を実施する構成単位 クラウド • エッジノードのさらに後段に位置するコンピューティングリソース。 ネットワーク • メディアにより特性は様々だが、ここでは⼤きくLANとWANに分類する。LANはエンドデバイス- エッジノード間で単⼀メディアで直接通信可能な範囲のもの、WANは複数メディアを経由して遠距 離をつなぐもの。 システム記述⾔語（ソフトウェアスタック） • デバイスを制御可能かつスモールシステムを構成可能（アプリケーション動作機能、通信機能、権 限管理機能）なシステムソフトウェア。現場で利⽤される特性から（従来までのPC等に対して）よ り⾼い安定性、即時稼働性能が要求される。エンドデバイスにおいては消費電⼒などハードウェア 制約を⼤きく受ける。 運⽤管理機能 • (1)エンドデバイス、エッジノード、スモールシステムの状態を把握し制御できる。(2)スモールシ ステムで稼働させるアプリケーションの状態を把握し制御できる。(3)ネットワークを制御し、デバ イス間あるいはデバイスーエッジノード間が通信可能であるようにする経路制御機能およびデバイ スディスカバリ機能（必須ではなくオプショナル機能）。 2. エッジスモールシステムのシステム・アーキテクチャ 9 クラウド エッジ スモール システム センサ アクチュ エータ Hub エッジ スモール システム withクラウド

3. エッジスモールシステムの要件 ⾼速性・リアルタイム性 • スモールシステムはリアルタイム性を持たなければならない。アプリケーションの応答速度として10msec以下 を実現する。 低消費電⼒性 • エンドデバイス、スモールエッジノードではハードウェア制約から低消費電⼒性能が要求される。電池駆動・ ソーラーパネル駆動も考えられる。このようなハードウェアにおいてはプロセッサの間⽋駆動が要求される可能 性もある。 • ビッグエッジノード、クラウドノードではノード単位での低消費電⼒性はそれほど要求されないが、経済性・対 環境性側⾯からインフラ全体としての低消費電⼒性能は常に要求される。 信頼性 • スモールシステムは⾼い信頼性をもち継続的かつ⻑い期間（年単位）動作可能でなければならない。 動的構成変更可能性（可⽤性） • スモールシステムは動的な構成変更に対応可能でなければならない。当初想定される通信相⼿と通信ができない 場合にもハングアップせず動作を継続し、代替構成をとれるか、⼀時停⽌後に元の状態もしくは新しい状態に復 帰できなければならない。スモールシステム⾃⾝が⾃律的に構成変更できることが理想だが、外部に設置された コントローラ（運⽤管理機能）からの指⽰に応じて構成変更する形態でもよい。 相互接続性、階層構造性 • スモールシステムは、適切な権限管理の下で相互に接続可能でなければならない。またスモールシステム⾃体を １ノードとしてより⼤きなスモールシステムを構成可能でなければならない。相互接続・階層構造はスモールシ ステム⾃⾝が⾃律的に実施できることが理想だが、外部に設置されたコントローラ（運⽤管理機能）からの指⽰ に応じる形で実施するのでも良い。 スモールシステム性 • 必要最⼩限のノードでスモールシステムが構成できなければならない。 10

4. 想定システムと従来⽅式 11 クラウド VMインスタンス 現場 Linux OS Pythonプロセス Linux OS Pythonプロセス センサ アクチュエータ 評価項⽬ 評価結果 （内容） ⾼速性・ リアルタイム性 ×（難あり） RaspbianOSはリアルタイム性を保 証せず、⼤きな遅延が発⽣する可能 性がある。 低消費電⼒性 ×（難あり） RaspbianOSはLinuxベースシステ ムであり消費電⼒は組み込み系シス テムと⽐較して⼤きい。 信頼性 △ RaspbianOSはLinuxベースシステ ムであり、またハードウェア制約か らも⻑期安定稼働は難しい。クラウ ドインスタンスは⾼信頼システムと 考えられる。 動的構成変更 可能性（可⽤性） ×（難あり） 決め打ちのシステム構成になりがち 相互接続性・ 階層構造性 ×（難あり） 決め打ちのシステム構成になりがち スモールシステム性 ○ 最⼩構成要素で構築可能である。

従来⽅式 レイヤ構成 12 VM OS Hardware App OS Hardware App OS Hardware App エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス

5.1 Elixir/NervesHubによる実現 13 クラウド VMインスタンス 現場 センサ アクチュエータ 評価項⽬ 評価結果 （内容） ⾼速性・ リアルタイム性 ○ ElixirはPython等に対して⾼速に 動作する。 低消費電⼒性 ○ ElixirはOSレイヤが薄く、低消費 電⼒で動作する。 信頼性 ○ Elixirは⾼信頼システムである。 動的構成変更 可能性（可⽤性） ○ NervesHub機能により構成変更可 能である。またアクターモデル採 ⽤により構成変更への対応性は⾼ い。 相互接続性・ 階層構造性 △ アクターモデル採⽤により柔軟性 はあるが、Nervesは主信号には関 与せず、現状では相互接続性機能 などは持っていない。 スモールシステム 性 ○ 最⼩構成要素で構築可能である。 VMインス タンス NervesHub Linux OS Elixirプロセス (/with OS) 評価内容は仮説（2020/11⽉現在）

Elixir / NervesHubでのレイヤ構成 14 VM Hardware App Hardware App OS Hardware エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス OS OS App App NervesHub

Elixir / NervesHubでのレイヤ構成 15 VM Hardware App Hardware App OS Hardware エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス OS OS App App NervesHub Nerves 動かせない︖ （アクターモデル採⽤で） 容易に組み換え可能︖ 主信号の制御 できない︖

5.2 Kubernetes / ServiceMeshによる実現 16 評価項⽬ 評価結果 （内容） ⾼速性・ リアルタイム性 × Linuxベースでありリアルタイム 性を保証しない。 低消費電⼒性 × Linuxベースであり、また、稼働 コンポーネントも多く消費電⼒は ⼤きい。 信頼性 △ Linuxベースのため。 動的構成変更 可能性（可⽤性） △ ServiceMeshにより主信号を動的 に構成変更可能である。ただし ServiceMeshが利⽤可能な系に限 る。 相互接続性・ 階層構造性 × Kubernetesクラスタを外れるた外 側とは相互接続は出来ない。 スモールシステム 性 △ 必要コンポーネントは多い。 クラウド VMインスタンス 現場 センサ アクチュエータ kube- master kube- master アプリケーションプロセス サイドカープロセス OS (Linux) (どちらか) 評価内容は仮説（2020/11⽉現在）

Kubernetes / Service Meshでのレイヤ構成 17 VM OS Hardware App OS Hardware App OS Hardware App エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス App Sidecar Sidecar Sidecar Sidecar App Kubernetes Kubernetes

Kubernetes / Service Meshでのレイヤ構成 18 VM OS Hardware App OS Hardware App OS Hardware App エンドデバイス エッジノード クラウド Hypervisor OS Hardware App エンドデバイス App Sidecar Sidecar Sidecar Sidecar App Kubernetes Kubernetes 容易に組み 換え可能︖ クラウド側から エンドデバイス を制御配下に⼊ れられる︖

6. 考察 19 評価項⽬ 結果 考察 従来 Elixir/NervesHub Kubernets/ ServiceMesh ⾼速性・ リアルタイム性 ×（難あり） ○ △ 低消費電⼒性 ×（難あり） ○ × 信頼性 △ ○ △ 動的構成変更 可能性（可⽤性） ×（難あり） ○ △ 相互接続性・ 階層構造性 ×（難あり） △ × 良いソリュー ションが欲しい スモールシステム性 ○ ○ △

7. まとめ • 任意の構成要素（エンドデバイス、エッジノード、クラウド） でスモールシステムを構築でき、その各スモールシステム間を 相互接続可能にしていけるシステムアーキテクチャ記述⾔語・ 環境が必要である。 • いくつかの実現可能性がある事がわかった。 • ⼀つはElixir/NervesHubをラージエッジおよびクラウドに適⽤していく ⽅法である。 • もう⼀つは、Kubernetes/ServiceMeshをエンドデバイスまで包含する 形に拡張していく⽅法である。 • Elixir/NervesHubは⾼速性・省電⼒性には優れたソリューショ ンである。ただクラウドとの親和性は良くない。 • また、Elixir/NervesHubでは主信号系を扱うことができないの で、その点についても調査していく。 • 更に、相互接続性、階層構造性については現状どちらの実装で あっても満⾜できる状態ではないので、実現⽅法を調査検討し ていく。 20