北九州市立大学 山崎 進
Nerves on Cloud は，次の理由で二酸化炭素を減らす効果的な解決策になると考えている: (1) Nerves はシステムを再現可能にすることで，十分にスケーラビリティと再起動時の同一の挙動を保証することができる (2) Nervesはシステムを最小化することで，十分に計算資源と消費電力を減らすことができる (3) Nerves はI/Oを制御できるので，デバイスの電源をオンオフできる．この事例では，Nervesカーネル上のそれぞれのNervesアプリケーションを仮想化することで，Nerves on Cloud を実現する試行を詳細に説明する．
Nerves on Cloud will be an effective solution to reduce carbon dioxide, because (1) Nerves makes a system be reproducible enough to ensure scalability and the same behavior when restarted; (2) Nerves enables a system be minimized enough to reduce computer resources and electricity; and (3) Nerves can control I/O that enables power of devices turn on and off. This case study explains a trial to realize Nerves on Cloud by virtualizing each Nerves application on a Nerves kernel, in detail.
[Andrae and Edler 2015]によれば，コンピュータデバイスにかかる電力消費量は，2030年時点の予想平均ケースで世界の電力供給量の21%，最悪ケースで世界の電力供給量の51%にも及ぶ可能性があり，中でも固定網やデータセンターの電力消費量が伸びる可能性が高い としている．ここでは，5Gの普及，機械学習などの計算量の増大などにより，インフラストラクチャー側の負荷が急上昇するというシミュレーション結果が描かれている．最善の予想でも，コンピュータの電力消費量は伸び続けるとしている．この驚くべき量の電力は，基本的に全て熱として大気中に排出される．もちろん，膨大な電力を生み出すために二酸化炭素が相当量排出される．よってコンピュータは地球温暖化の問題に無縁ではない．
そこで，IoTフレームワークであるNervesを用いてクラウドシステムを構築するNerves on Cloudを提案する．Nerves on Cloudは，コンピュータの素子であるトランジスタの消費する電力は，電圧の2乗とトランジスタ数とクロック周波数の積に比例する[Hennessy and Patterson 2017]ことに着目し，次のようなアプローチで消費電力を削減する:
- 使わないモジュールのクロックを停止するなど電源コントロールをこまめに行うようにする． 使わないモジュールのクロックを停止すれば，そのモジュールの消費電力を0に近づけることができる．Nervesの持つI/O制御機能により電源コントロールを実現する．
- 並列処理を最大限に生かして計算能力を高め，かつできるだけ同期・排他制御で計算が停止しないようにする． コアが複数ある場合，1つのコアだけに処理を集中させてクロック周波数を上げて処理するよりも，複数のコアに処理を分散させてクロック周波数を下げた方が，消費電力あたりの計算能力を向上させることが容易である．低CPUクロックの複数のマルチコア・コンピュータ・ユニットで並列分散させる．Nervesの基盤となっているプログラミング言語Elixirと，その超並列処理系Pelemayにより，並列処理を容易に記述できる．Nervesによる電源コントロールでコンピュータ・ユニットやコア数の稼働率を制御する．
- 目的を達成するのに必要なクロック数を削減する．すなわち無駄な命令を実行しない． コンパイル・最適化されたネイティブコードで実行する方が，最適化されていないインタプリタ実行よりも，同じことをするのに必要な電力消費を抑えられる．超並列処理系Pelemayにより達成できる．
しかし，IoT向けであるNervesはシングルユーザーモードで動かすことが一般的であるため，複数のユーザーのプログラムが同一マシン上で動作することが一般的なクラウドで稼働させるには問題がある．そこで，本発表では，Nervesをマルチユーザでセキュアに実行するための仮想化技術を提案する．
本発表のこの後の構成は次のとおりである: 第2章でNervesの特徴について概説し，第3章で本発表で提案するNerves on Cloudの利点を説明する．第4章でMuonTrapを用いてNervesをマルチユーザでセキュアに実行するための仮想化を実現する方針について説明し，第5章で考察を述べ，第6章でまとめる．
[山崎 2020]にてまとめたNervesの特徴を再掲する:
NervesはNerves Projectが開発した，IoTデバイス群を迅速かつ大規模に構築，デプロイし，安全に管理するために必要なオープンソースのプラットフォームでありソフトウェア基盤である[Nerves]．Nervesは，プログラミング言語ElixirとLinuxを採用しており，Raspberry Piシリーズをはじめとする様々なIoTボードで動作する．
Nervesはクロスコンパイル環境を提供している．Nervesの特徴の1つとして，同じソースコードで，ホストとターゲットデバイスで実行することができる．Elixirのインタラクティブシェルであるiexを使い，iex -S mixというように起動すると，ホスト上でデバッグできる．実行できることを確認したのち，環境変数MIX_TARGETにてターゲットデバイスのIoTボード種類(Raspberry Pi 3など)を指定し，mix firmwareコマンドを実行することで，ターゲットデバイス向けのファームウェアを生成する．ファームウェアはmix firmware.burnコマンドを実行することで，micro SDカード等にファームウェアをインストールする．一旦ファームウェアをターゲットデバイスにインストールした後は，SSH経由でファームウェアをアップデートすることもできる．そのためのスクリプトをmix firmware.gen.scriptで生成し，その後は./upload.shを実行することで，SSH経由でファームウェアをアップデートできる．
Nervesでは，できるだけフットプリントを小さくするように，Linuxカーネルは必要最小限のモジュールのみを結合して生成されており，ファイルシステム中にも必要最小限のコマンドしか存在しないようにしている．必要なモジュールの指定は，別途設定ファイルで明示的に指定する．
ファイルシステムの配置のしかたが特徴的で，読込み専用のシステム用パーティション2セットと，読書き可能なデータ用パーティション1セットから構成される．システム用パーティションについては，起動時にどちらか一方がアクティブになり，もう一方はマウントされない状態で起動する．システムをアップデートする時には，起動時にマウントされていなかった方のシステム用パーティションを書換え，正常に書換えが終了した場合に，書換えた方のパーティションをアクティブにした状態で再起動する．この時に正常に起動できなかった場合には，元のパーティションをアクティブにしなおして再起動する．このようにファイルシステムを構成することで，耐障害性を高めることができる．
またシステム用パーティションを読込み専用にすることで，システム動作の再現性を高めることができる．
NervesHubというサーバーを配置することで，NervesHubに新しいファームウェアをアップロードすると，Nervesの各デバイスがファームウェアを自動的にアップデートして再起動するという機能も備わっている．NervesHubとの通信は，NervesKeyという暗号化LSIを用いて確立するので，セキュアである．Raspberry Piを用いる場合でも，NervesKeyを半田付け等することでNervesHubを利用することができる．NervesHubはクラウド上に配置することも，オンプレミスのサーバーとして配置することも可能である．この利点により，システムのアップデートをリモートからセキュアかつ一斉に実施することができるのが，Nervesの大きな特徴の1つである．
第2章で説明した特徴を有するNervesをクラウドサーバーとして用いることで，次のように消費電力を減らすことができる．
- Nerves はシステムを再現可能にすることで，十分にスケーラビリティと再起動時の同一の挙動を保証することができる．これにより，省電力化のためシステムを一時停止しても，再起動時に不具合が生じる可能性を減らせる．
- Nerves はシステムを最小化することで，十分に計算資源と消費電力を減らすことができる．
- Nerves はI/Oを制御できるので，デバイスの電源をオンオフできる．これによりその時々に応じた必要最小限のシステム構成で稼働することができる．
コントロールグループ(cgroup)は，Linuxカーネル2.6.24からサポートされるようになった[Corbet 2007]，プロセスグループがCPU，メモリ，ディスクI/Oなどのリソースを利用することを制限したり隔離したりするLinuxカーネルの機能である．
MuonTrapは，ErlangやElixirから起動するプログラムやデーモン，アプリケーションを隔離して正常に動作させるための機構である[MuonTrap]．MuonTrapの中核機能は，コントロールグループを設定して子プロセスを起動し，起動したErlangやElixirとは異なるユーザーやグループでOSプロセスを起動することである．
これらを利用し，次のように隔離されたプロセスを実現する:
- MuonTrapでコントロールグループを指定することで，メモリやCPUの利用を制限することができる．これを利用して，メモリやCPUの利用を適切に制限した，ユーザーごとのデーモンプロセスを起動する．MuonTrapではこのデーモンプロセスの監視や，不具合時の再起動を行うことができる．
- MuonTrapで生成したデーモンプロセスに
chrootを用いてファイルシステムのルートを与えることで，デーモンプロセスに事実上の個別のファイルシステムを与える．この際にOverlayFSを使用することで，共通ファイル群と差分ファイル群をそれぞれ別のディレクトリに格納した状態で，結合した仮想的なファイルシステムを作ることができるので，効率が良いファイルシステムを構築できる． - [NervesSSH]を用いることで，ポート番号を指定してSSHデーモンを作ることができる．これを通して，ユーザーごとのデーモンプロセスへのアクセス手段を設けることができる．
ただし次のような制限がある．
- ユーザーごとのデーモンプロセスだけが使用するファイル群を変更しただけの場合でも，ファームウェア全体の更新とシステム再起動を必要とする．そのため，ユーザーアプリケーションを書き換える度に，他のユーザープロセスも巻き込んで再起動することになってしまい，かつダウンタイムが生じてしまう．これを回避するためには，システムを多重化して再起動のタイミングをずらすことでダウンタイムをなくす必要がある．
Nerves on Cloudを設計するにあたり，シングルユーザのNervesを複数並列にクラウドに展開する代替案と比較検討した．これには次のような方式が考えられる．
- それぞれのNervesを実マシンにインストールする
- それぞれのNervesを，VirtualBoxのようなフル仮想化した仮想機械にインストールする
- それぞれのNervesを，DockerのようなOSレベル仮想化した仮想機械にインストールする
- シングルユーザのNerves上で，Dockerによる仮想機械を構築する
1は，実現が容易であるが，ユーザー数と同数の実マシンを用意する必要があり，かつ一対一に対応させる必要がある．これによって，クラウドの利点の1つであるスケーラビリティが損なわれる．
2を実現するためには，Nervesの主たる構成要素の1つとして組込みLinuxが含まれているため，対応するイメージファイルを用意する必要があるが，現状では提供されていない．提供していたこともあったそうであるが，パフォーマンスが悪かったため，現在では提供していないとのことである．CPU，メモリ，ストレージの効率の面で，難点があることは想像に難くない．
3が実現できるかは不分明である．一方，4を実現することは現状で出来ている．3,4に対する優位性があるのかどうかを今後議論していく必要があるかと考えている．
クラウド上のコンピュータシステムの消費電力を減らし，管理をしやすくするために，Nerves on Cloudを提案した．本発表ではMuonTrapを用いてユーザーごとに仮想化できることを示した．将来課題としては，DockerなどのOSレベル仮想化による仮想機械にNervesをインストールした場合と比べた時の優位性について見極める必要がある点と，具体的に実装してライブラリを提供することが挙げられる．これを人工衛星からの膨大な画像を処理するコンピュータ・クラスタ・システム[Yamazaki 2020]に応用することを目指している．
本研究成果は、科学技術振興機構研究成果展開事業研究成果最適展開支援プログラム A-STEP トライアウト JPMJTM20H1 の支援を受けた．執筆にあたって，Troodon Software LLC および Nerves Project の Frank Hunleth 氏，Tombo Works代表の衣川 亮太氏，そしてJaremy Creechley氏には特に有益な助言をいただいた．