Elixir/NervesHubによるエッジコンピューティング環境実現に関する検討
0. 概要
さくらインターネット研究所および筆者は、将来的に、超分散システム（超個体型データセンター）の実現を目指し、その中間段階としてのエッジコンピューティングの実現性について調査検討を進めている。超個体性を持ったエッジコンピューティングシステム・アーキテクチャを実現するために、組み込み系にルーツを持つElixir/Nerves環境を調査検討している。そこで、Elixir/Nervesがエッジコンピューティングを実現するために適合可能であるかを客観的に判断できるように、エッジコンピューティングの実現要件を抽出定義し、その上でElixir/Nervesやその他の代替手段（Kubernetes/Servicemesh）がどの程度適合するか評価した（し始めた）。その結果、Elixir/Nervesでエッジコンピューティングシステムを構築することに優位性がある場合もあることがわかった（わかってきつつある）。一方でElixir/Nervesはクラウドおよび仮想化との親和性が高くないため、そこに改善の余地があることがわかった。また、Elixirが採用するアクターモデルについては超個体型システムへの適合性があることもわかった（わかってきつつある）。
1. はじめに
さくらインターネット研究所においては、コンピュータ・ネットワークシステムの今後のあるべき形として、我々の生活する空間（現場）の様々な場所にコンピューティングリソースが溶け込んだ分散型のコンピューティング・ネットワークシステムインフラストラクチャを想定し、これを「超個体型データセンター」ビジョンとして提唱し、その実現に向けた研究・開発活動を推進している。
超個体型データセンター的分散型システムには段階を経て到達すると想定しており、現在の、クラウド（大規模データセンター）を主体としたシステムモデルから、まず現場に近いところにコンピューティングリソースを配置するエッジコンピューティングの段階を経て、更に分散度が高まっていくという経過となると考えている。
そのため、さくらインターネット研究所および筆者らは、エッジコンピューティングの現実的な実現形態およびその実現方法・手段について検討を進めてきた。
エッジコンピューティングは、データセンターをエンドユーザに物理的に近いところに（再）設置しただけのシステム・アーキテクチャではなく、エンドデバイス（端末）も含めて、クライアント・サーバのモデル、その通信方式、ネットワークの構成、データの取得・通信・蓄積・利用の仕方などについて、システム・アーキテクチャの変更を伴うものであると考えている。
具体的には、エンドデバイスは人が使うPCやスマートフォンだけでなく現場に設置されるIoT機器（センサ・アクチュエータなど）になり、通信のデータサイズやシーケンスは小さく、簡潔になっていく。また近隣のデバイス間での相互連携（通信）が増え、また、制御のためのデータ、蓄積・分析のためのデータなど通信・データの種類が分化していく。（全てのデータをクラウドに集める必要はなく、現場で必要なデータを現場で完結させる通信・データ利用形態を、データ地産地消と呼んでいる。） 更に、制御対象となる現場の状況に応じて装置の稼働状態を変更させたり（例：人がいないところの装置は停止させる、人に追従して装置の稼働場所を変える）、装置の故障や入れ替えなどから、高い頻度でシステムの構成が変化していく、という特徴もある。これらに対応するため、システム・アーキテクチャを変化させていく必要がある。
本検討では、このように人間のみならずIoT利用形態も想定した最適なエッジコンピューティングのシステム・アーキテクチャについて、既存のWeb System Archtectureを見直し、特にシステムモデルおよびデータ通信モデルの観点においてその課題とそこで求められる要件、そしてそれを満たす新しい実現形態・手段について、調査・試行している。
本稿では、エッジコンピューティングをいくつかのタイプに分類した上で、そのうちの特にIoTを想定した利用形態に合うシステム・アーキテクチャの候補として、組込みシステムとしての特徴を持つプログラミング言語・開発運用環境であるElixirとNervesHubに注目しそれらをエッジコンピューティングに適用したシステムモデルの、特徴や課題点等について調査、検討した内容について報告する。
研究会においては、Elixir/NervesHubに留まらず、エッジコンピューティングのシステム・アーキテクチャ形態、実現手段そのものについても議論を深めていきたい。
2. 関連研究
- 超個体型データセンターコンセプト
- エッジコンピューティング
- ElixirとNervesHub
- Elixir
- NervesHub
- 高瀬先生、山崎先生既存検討
3. 要件定義
まず、（関連研究の項目[2]でも紹介しているが）エッジコンピューティングをタイプの異なる以下の４つに分類した上で、特にIoTを想定ターゲットとしてエッジコンピューティングのシステムアーキテクチャについて考えていく。その上で、そこでの要件を抽出していく。
3.1 エッジコンピューティングの分類
- Micro-DataCenterタイプ
汎用サーバをエッジ領域に設置して利用する。不特定多数向けのコンテンツ提供、大量のデータを集めて機械学習する等の、大量のコンピューティングリソース、ストレージを必要とする用途を想定。
- 自動車(V2X)タイプ
自動車等向けのサービス提供を想定したもの。エンドデバイス（自動車）自身がエッジ相当で高度な処理を担当。かつネットワーク側からも車車間連携や道路情報の提供などのサービスを提供。通信速度・性能などの要件が厳しいものを想定。
- エッジAIタイプ
エンドデバイスがエッジノード相当で、デバイス内で主目的の処理（カメラ画像処理など）を実施してしまうもの。ネットワーク側にエッジノードを必要としない。（エッジコンピューティングとしては考慮対象外としてよい。）
- センサ収容、スモールエッジタイプ(IoTタイプ)
センサ・アクチュエータなどを収容する。エッジノードもそれらのデータを中継したり簡単な処理を実施するなどで、小型のものを想定する。
3.2 エッジコンピューティングのシステム・アーキテクチャ
上記分類を総合した上での、構成要素に分解したエッジコンピューティングシステム・アーキテクチャは以下のように整理されると考えられる。
- エンドデバイス
センサ・アクチュエータなど単機能・低機能なものと、PCやスマートフォン等の人間が操作することを想定したリッチデバイスの２種類が併存する（（考慮外でよいが）エッジAI向けデバイスも、様々な物があるがどちらかに分類可能と考える）。エンドデバイスは、電源投入状態や位置（物理位置、ネットワーク接続位置）が常に変動する。
- エッジノード
センサ・アクチュエータなどのデータを仲立ちする、現場に近いところに設置するスモールエッジノードと、大量のデータを集め処理・保存するビッグエッジノードの２種類。前者はエンドデバイスに近いハードウェア構成をとり、後者はクラウドに近い構成をとる。エッジデバイスは、電源投入状態や位置が常に変動する（特にスモールエッジノードにおいて）。
- スモールシステム
エンドデバイスとエッジノードの組み合わせで、ある現場領域において意味のある処理（アプリケーション）を実施する構成単位をスモールシステムと定義する。一例として、センサとアクチュエータおよびそのHubとなるエッジノードで構成され人の接近を検出して照明を点灯させるアプリケーションを実行するスモールシステム、など。スモールシステムは適切な権限管理の下で互いに連携したりより上位のスモールシステムに包含されるなどの関係などを持つ（部屋のスモールシステムを束ねて家として管理するなど）。スモールという名称だが構成要素が離れて設置されていても良い（エンドデバイスとクラウド上のノードの組み合わせなど）。スモールシステムの構成要素は、構成要素やその状態、またスモールシステム間の関係が常に変動する。
- クラウド
エッジノードのさらに後段に位置するコンピューティングリソース。スモールシステムはクラウドを利用可能（利用しなくても良い）。クラウドは位置が動かず状態の変動も少ない。構成は任意に変更・増減可能。
- ネットワーク
メディアにより特性は様々だが、ここでは大きくLANとWANに分類する。LANはエンドデバイス-エッジノード間で単一メディアで直接通信可能な範囲のもの、WANは複数メディアを経由して遠距離をつなぐものとする。
- システム記述言語（ソフトウェアスタック）
デバイスを制御可能かつスモールシステムを構成可能（アプリケーション動作機能、通信機能、権限管理機能）なシステムソフトウェア。デバイスドライバ、OS、アプリケーションなどのレイヤで構成される。エッジノード、クラウド等のリソースが潤沢な環境ではそれらのノードは仮想化され、物理的には１台のノードに於いて複数の仮想ノード（ソフトウェアスタック）が稼働していても良い。現場で利用される特性から（従来までのPC等に対して）より高い安定性、即時稼働性能が要求される。エンドデバイスにおいては消費電力などハードウェア制約を大きく受ける。
- 運用管理機能
運用管理機能は、大きく３つの機能を持つ。(1)エンドデバイス、エッジノード、スモールシステムの状態を把握し制御できる。(2)スモールシステムで稼働させるアプリケーションの状態を把握し制御できる。(3)ネットワークを制御し、デバイス間あるいはデバイスーエッジノード間が通信可能であるようにする経路制御機能およびデバイスディスカバリ機能（必須ではなくオプショナル機能）。
（なお、これらの定義は、IICやEdge X Foundry、その他が定義するシステムアーキテクチャを精査してもう一度考え直す必要がある。）
3.3 エッジコンピューティングに求められる要件
（上記と重複する部分もあるが）エッジコンピューティングシステムに求められる要件は以下のうように整理できる。（この項目要追記）
- 高速性・リアルタイム性
スモールシステムはリアルタイム性を持たなければならない。アプリケーションの応答速度として10msec以下を実現する。（自動車タイプではより高度なリアルタイム性が要求される。以下省略。）
- 低消費電力性
エンドデバイス、スモールエッジノードではハードウェア制約から低消費電力性能が要求される。電池駆動・ソーラーパネル駆動も考えられる。このようなハードウェアにおいてはプロセッサの間欠駆動が要求される可能性もある。
ビッグエッジノード、クラウドノードではノード単位での低消費電力性はそれほど要求されないが、経済性・対環境性側面からインフラ全体としての低消費電力性能は常に要求される。
- 信頼性
スモールシステムは高い信頼性をもち継続的かつ長い期間（年単位）動作可能でなければならない。
- 動的構成変更可能性（可用性）
スモールシステムは動的な構成変更に対応可能でなければならない。当初想定される通信相手と通信ができない場合にもハングアップせず動作を継続し、代替構成をとれるか、一時停止後に元の状態もしくは新しい状態に復帰できなければならない。スモールシステム自身が自律的に構成変更できることが理想だが、外部に設置されたコントローラ（運用管理機能）からの指示に応じて構成変更する形態でもよい。
- 相互接続性、階層構造性
スモールシステムは、適切な権限管理の下で相互に接続可能でなければならない。またスモールシステム自体を１ノードとしてより大きなスモールシステムを構成可能でなければならない。相互接続・階層構造はスモールシステム自身が自律的に実施できることが理想だが、外部に設置されたコントローラ（運用管理機能）からの指示に応じる形で実施するのでも良い。
- スモールシステム性
必要最小限のノードでスモールシステムが構成できなければならない。
4. 既存の方式の分析と問題点の抽出
なお本検討では、すべての場合において以下の想定システムを前提としている。
前節で挙げた要件を満たすシステムを、既存手段・技術で実現する場合について考える。
4.1 想定するシステム（ユースケース）
Raspberry Pi_1にセンサを、同_2にアクチュエータを接続し、_1からセンシングデータをHubとなるエッジノードに送信し、何らかの処理（内容分析および保存）を施した上で、加工データを現場（_2）に送り返してアクチュエータを制御するシステム。保存されたデータは別途統計的に利用する。
4.2 従来方式で実現する場合
スモールエッジノードとしてセンサ・アクチュエータと同様にRaspberry Pi(_3)を利用する。かつデータ保存・分析用にパブリッククラウド上にインスタンス(_4)を起動して利用する。
Raspberry Pi(_1〜_3)にはUbuntu派生のRaspbian OSをインストールし、その上でPythonで記述したアプリを実行させるものとする。クラウド上のインスタンス(_4)においてもLinuxベースOSを実行させ、その上でPython等で記述されたデータ保存および分析・閲覧アプリケーション(Flask/Python Django等のフレームワークを利用したもの)を実行させるものとする。
このようなシステムを想定した場合、上述した要件に対して以下のように充当すると考えられる。
- 高速性・リアルタイム性：難あり（RaspbianOSはリアルタイム性を保証せず、大きな遅延が発生する可能性がある。）
- 低消費電力性：中（RaspbianOSはLinuxベースシステムであり消費電力は組み込み系システムと比較して大きい）
- 信頼性：中（RaspbianOSはLinuxベースシステムであり、またハードウェア制約からも長期安定稼働は難しい。クラウドインスタンスは高信頼システムと考えられる。）
- 動的構成変更可能性（可用性）：難あり（決め打ちのシステム構成になりがち）
- 相互接続性、階層構造性：難あり（決め打ちのシステム構成になりがち）
- スモールシステム性：良い（最小構成要素で構築可能）
何らかの（有償の）システムミドルウェア（ベンダーサービス等）を利用しないとした場合には、個々の構成要素を手で組み合わせることになり、動的構成変更可用性や相互接続性などに難のあるシステムが完成する可能性が高い。また、ベースとしているOS、フレームワーク等の特徴を引き継ぐことになる。
5. 調査・評価
3節で挙げた要件項目を満たす手段として、前節で挙げた課題を考慮しながら、エッジコンピューティングシステムとして以下の技術・手法を利用する場合の可能性を調査した（継続中）。
5.1 Elixir/NervesHub
人感センシングデータをスモールエッジノードに中継させアクチュエータに渡しLEDを点灯させる系をスモールシステム１、またスモールエッジノードからデータをクラウドに送信し蓄積、そのログを可視化・分析する系をスモールシステム２とする。
スモールシステム１を構成するエンドデバイス（センサ・アクチュエータ）とスモールエッジノードのRaspberry Piには、Elixir/Nervesにより開発したファームウェア（OS+アプリケーション）をインストールして利用する。ファームウェアの管理にはNervesHubサービスを利用する。
スモールシステム２はスモールエッジノードとクラウドインスタンスにより構成する。クラウドインスタンスをNervesHubで管理させることはできない（クラウドノードのアプリをElixir/Phoenixで記述し、スモールシステム１と連携させることは可能）。
このようなシステムを想定した場合、要件に以下のように充当する。
- 高速性・リアルタイム性：○（ElixirはPython等に対して高速に動作する。）
- 低消費電力性：○（ElixirはOSレイヤが薄く、低消費電力で動作する。）
- 信頼性：○（Elixirは高信頼システムである。）
- 動的構成変更可能性（可用性）：○（NervesHub機能により構成変更可能である。またアクターモデル採用により構成変更への対応性は高い。）
- 相互接続性、階層構造性：△（アクターモデル採用により柔軟性はあるが、Nervesは主信号には関与せず、現状では相互接続性機能などは持っていない。）
- スモールシステム性：○（最小構成要素で構築可能である）
5.2 Kubernetes / ServiceMesh
前節と同様の構成をKubernetesベースで構築することを考える。
スモールシステム１について、エンドデバイス、スモールエッジノードにてKubernetesを稼働させアプリケーションを管理させることは可能である。アプリケーション記述には高級言語（Python等）を使用できるが、ハードウェア制御には特別な設定が必要である。
スモールシステム２は、Kubernetesそのものもしくはそのエッジ適用向け派生であるKubeEdgeを利用することでクラウドとスモールエッジノードを管理配下にすることができるが、エンドデバイスを配下に入れられるか不明である（スモールシステム１のようにそれ専用で組めばできるが、クラウドからリーチさせるときにハードウェア制御等ができるか不明）。またこの環境はスモールエッジ１と併存は出来ない。
このため、Kubernetesによる管理は、スモールエッジ１を取りクラウド側は独自に管理するか、スモールエッジ２を取りエンドデバイスを独自に管理するかのどちらかになる。
この場合の要件充当は以下の通り。
- 高速性・リアルタイム性：△（Linuxベースでありリアルタイム性を保証しない。）
- 低消費電力性：×（Linuxベースであり、また、稼働コンポーネントも多く消費電力は大きい。）
- 信頼性：△（Linuxベースのため。）
- 動的構成変更可能性（可用性）：△（ServiceMeshにより主信号を動的に構成変更可能である。ただしServiceMeshが利用可能な系に限る。）
- 相互接続性、階層構造性：×（Kubernetesクラスタを外れるた外側とは相互接続は出来ない。）
- スモールシステム性：△（必要コンポーネントは多い）
（Elixir（Erlang）プロトコルとHTTP(S)のプロトコルの比較。ヘッダサイズやシーケンスの違いなど。）
（ネットワークについて書いていない。）
6. 評価結果に関する考察
組み込み系システムから派生したElixir/NervesHubはクラウドまでリーチできず、クラウド系テクノロジであるKubernetesはエンドデバイスにリーチできない（かも）ということでどちらも一長一短がある。
一方で、組み込みシステムの特性からElixir/NervesHubによるシステム記述は低消費電力性や可用性、信頼性などの面でKubernetesに対して優位性がある面がある。
7. まとめ
任意の構成要素（エンドデバイス、エッジノード、クラウド）でスモールシステムを構築でき、その各スモールシステム間を相互接続可能にしていけるシステムアーキテクチャ記述言語・環境が必要である。
いくつかの実現可能性がある事がわかった。一つはElixir/NervesHubをラージエッジおよびクラウドに適用していく方法である。もう一つは、Kubernetes/ServiceMeshをエンドデバイスまで包含する形に拡張していく方法である。
また、Elixir/NervesHubでは主信号系を扱うことができないので、その点についても調査していく。
更に、相互接続性、階層構造性については現状どちらの実装であっても満足するものがないので、実現方法を調査検討していく。
この記事が気に入ったらサポートをしてみませんか？