MODE JAPAN Blog

IoTを活用したデジタルトランスフォーメーションのための情報、開発の現場から技術的な情報や取り組みについてお届けします。

【開発の裏側】MODE Robot Cloudにファイル転送機能を追加

2022年2月28日、MODEは「IoTにおける「デバイス〜クラウド間」での双方向のファイル送受信が可能に 〜MODE Robot Cloudにファイル転送機能を追加〜」というプレスリリースを発表しました。

今日は、CEOの上田と開発を担当したソフトウェアエンジニアの篠田の2名に、新機能について話を聞きました。

f:id:etoamode:20220225141853j:plain

左から上田、篠田

ファイル転送機能とは?

 

-- 元々デバイスとのデータのやり取りはあったと思いますが、普通にやり取りするのと、ファイル転送機能とは何が違うのでしょうか?

 

篠田: 今までは小さいデータをやり取りしてたんですよね。今、何が起こったか、何が起こってないかっていう、ただそれだけの情報なんですよ。今回のファイル転送機能が取り扱うのは比較的大きなファイルで、そうしたファイルの送受信という操作が発生する点でこれまでと異なります。大きいデータって、IoTのような通信が不安定な場所で考えなしに流し込むと色々な問題が発生することがあるのですが、それをできるようにしたのがファイル転送機能です。

 

-- 具体的にはどういった構造になっていますか?

 

篠田: ファイル転送機能は現在MODE Robot Cloudの機能です。一言で表すと、ファイルを転送する機能。どういうことかというと、多くの人が考えるインターネットは、サーバーと手元のPCで動いているウェブブラウザがあります。一方、IoTのインターネットはウェブブラウザとサーバーとエッジコンピュータで構成されています。エッジコンピュータはMODEの場合はゲートウェイを指します。

f:id:etoamode:20220301085453j:plain



ファイル転送機能は、ユーザーがゲートウェイとファイルをやりとりする機能です。しかし、ゲートウェイと手元のPCが普通にやりとりするのは困難なので、クラウドを仲介することでファイルをやりとりします。

 

例えば Google ドライブ。Google ドライブにファイルを置いてチームメンバーと共有するとか、手元のパソコンの代わりにどこかのクラウドに保存するだとかっていうことをみんな期待して使ってるじゃないですか。あれのゲートウェイ版みたいなものだと思っていただければ良いんですよね。ユーザーが持っているファイルをゲートウェイに配置したり、ゲートウェイに配置されてるファイルを手元に持ってきたりといった用途で使われる機能です。


IoT開発の裏側

 

-- ファイル転送機能はどういう経緯で作ることになったんですか?

 

篠田: お客様が使っているロボットが、エラーを起こした時にデバッグログを出力するので、それをカスタマーサポートの人が解析に回したり依頼したりするのに、簡単にダウンロードしたいというご要望をいただきました。また、遠隔にある機器のファームウェアの更新や送信をしたいというご要望もありました。

 

上田: ファームウェアを送るのはOTAのサービスがありますが、OTAって台数の多いデバイスのファームウェアを一括で効率よく管理するための仕組みだから、PoCとか研究のように早い段階でフレキシブルにやりたいっていうのにはあまり向いていないですね。なので、ファイルを送り込むための仕組みが欲しかったということですね。つまり、双方向のファイル送信システムなんですね。

パターン1 デバイスからクラウド:デバッグログを集めたい

パターン2 クラウドからデバイス:ファームウェアを送りたい

柔軟に多用途に使えるような双方向ファイル送信システムということですね。

 

 

-- 開発をする中で感じた課題や苦労した点はありましたか?

 

篠田: 開発中の課題としては、デバイスとの通信には携帯電話回線を使うので、長時間アップロードとかダウンロードで回線を占有するとプツンと切れてしまうんですね。常時接続してる通常のプロセスのコネクションの帯域まで圧迫しちゃうんで。その切れやすさは、配置している場所によって変わってきます。

 

上田: ここは僕らが毎回苦労するところですね。携帯電話のデータ通信って思ったほど送れないと言うか、インターネット接続だからと言って、普通のプログラムみたいに書いたら全然ダメですよね。

 

篠田: ダメですね。エラーハンドリングも、エラーが起こった時に止めずにとりあえずデータを置いておいて、うまくいきそうになったら転送を進めるとか、そういった特殊な処理をさせないといけない。

 

上田: これ、 IoT の開発の難しさだと思うんです。普通のプログラムって「エラーです」とダイヤログ出して、人間に対して再入力してもらうようにリクエストできるんですけど、それが許されないのがIoTの難しさ。レベルが1段か2段上がっちゃう。エラーハンドリング全部ちゃんと書かないと、だめですよね。

 

篠田: IoTの場合、遠隔地にデバイスが置いてあるので、誰かがエラーが起きたことを検知して、リセットボタンを押すというのは、かなりナンセンスだと思うんですよね。だからシステムにはとりあえず走り続けてもらう。その中で、いくつかはリカバリ可能であろうっていうのがMODEの特長の一つ「100%到達保証」だったりするので、そうした別の仕組みで再復帰させることを常に意識しながら書く必要があります。



-- 設計上、注意した点はありますか?

f:id:etoamode:20220225142050j:plain

 

篠田: アップロードの帯域制御でしょうか。回線をずっと占有しないように、データを細切れに送って、他の通信に隙間を空けてあげるというのをやっています。ゲートウェイとクラウドは、「お前生きてるか?」って言う小さい通信をずっとしてるんですよね。その小さい通信まで妨げるようなファイルを転送すると、ゲートウェイもクラウドも、お互い「こいつ死んだ」って勘違いするんですよ。だからそういう小さい通信を妨げないように、大きいファイルをちょろちょろ流し続けるようにしています。

 

ZIPの展開は危ない!

 

-- セキュリティはどうなっていますか?

 

篠田: ZIPファイルの内部構造って、アンジップしたときに、上位ディレクトリとか指定できるんですよね。そうすると、いらないところを書き換えられないようにしています。すごく地味ですよね。あとは、特定のディレクトリしか許可できないような設定もできます。

 

上田: いけるディレクトリは結構制限しちゃっている感じなんですね?

 

篠田: デフォルトではOSに関わるディレクトリは操作しないようにしています。

 

上田: 今のって地味だけど、知らないでやったらセキュリティホールになっちゃうやつですね。

 

篠田: ZIPファイルの展開は気を付けないと結構危ないです。

 

ユースケース1:既存システムとのレトロフィット

f:id:etoamode:20220225142124j:plain

 

-- ファイル転送機能にはどういう事例/ ユースケースがありますか?

 

上田:既存システムのレトロフィットの場面では結構ある感じですね。既存のシステムや機器で、インターネットに繋がっていないものがすでに現場で動いているじゃないですか。それを IoT化したいという要望は多いです。すでにあるコンピュータシステムに対して、レトロフィットのためにゲートウェイが来て、本当は繋がってないシステムや機器を繋いでくれる代わりをしてくれるんです。

 

-- 新しく導入するものばかりではないのですね?

 

上田: そうですね。工場とかの機械って、一回作ったら10年とか20年とか動くものなので、IoT化したいから工場建てましょうっていうのも、もちろん中にはあるんですけど、もうすでにあるものをレトロフィットするって案件の方が多いんですよね。

 

篠田: すでにどこかの機器にデータが吐かれていて、それを吸い込んで欲しいというのが、よくある要求なんですね。で、吐かれているのがだいたいCSVだったりする。そういうのはパースしてデータとして送り直すように書けば良いんだけど、そうじゃないデータフォーマットで、なおかつ時系列データベース(TSDB)に向いていないとかなると、そういう要求はどんどん増えてくるし、ブラウザベースじゃなくて自動的に上げるだとか、もう少し抽象的なファイル転送の仕組みのようなものは、もっと必要になってくると思いますね。そうなると、用途は無限にあると思います。

 

ユースケース2:機械学習後のAIなどの大量配布

-- 他にも事例/ ユースケースがあると聞きましたが?

 

篠田: 一例としては、ゲートウェイにカメラがついていて、それを使って人物を認識しなくてはいけない。こういう場合、大抵は機械学習で作られてるので、学習済みデータを定期的に更新したいのだけど、ゲートウェイの上では学習させられない。そこで、別のところで機械学習させ、学習済みファイルを各ゲートウェイに配布させるといった使い方もあります。

 

上田: 「AIを鍛える」とか「AIを学習させる」という言い方をするんですけど、膨大な量のデータを見せてトレーニングしないといけないんですよ。でもゲートウェイは小さくて低速なコンピューターなので、機械学習には向いていないんですよね。だから大きいコンピュータや、大量のコンピュータを使うのが一般的なんです。機械学習した結果の脳みそ(モデル)だけ配ってあげるといった話なんですよ。

例えば100ヶ所にシステムを設置した場合、性能を良くしようとしたら、100ヶ所に置き直しに回らないといけないじゃないですか。AI会社さんはそこまでは請け負ってくれないので、新しく賢くなったシステムを作っても、100ヶ所に誰かが置きに行かないといけない。MODEのファイル転送機能を使えば、学習済みファイルを100ヶ所に展開するのが簡単に出来る。

 

今後に向けて

 

篠田: CTOのイーサンは、今のMODEには大容量データ用にはアップロードの口しかないので、ダウンロードの口も新設して、もう少し通信経路を整理したいというのは言っていました。

 

上田: 携帯などの通信で、データが必ずしも確実に送れないような環境でも、クラウドと機械の間でデータをやり取りできるもの、上から下、下から上と、両方ともできるものを一般化して作りたいですよね。

 

篠田: そうですね。あとはゲートウェイ自体もありますけども、各デバイスとストレージもデバイスじゃないですか。なので各デバイスのプロトコルも、ある程度アドオンで作れるようにして。 

 

上田: なんか土管みたいな感じ。

 

篠田: ブラウザはただのインプットの一つみたいな感じで、入力出力を全部抽象化して、ブラウザが一つのデバイスみたいにしたい。というか、そうしないと色々な要求に答えられないと思う。

 

上田: めちゃめちゃ非同期で、リクエストしたらすぐに返ってくるわけではないんですよね。

 

篠田: そう、何かのプロトコルにのっかって、そこの通信経路だけを実装しちゃった方が良いのかもしれないですけど、何かしらそういう抽象化がいる。

要するに向こう側とこっち側が、いろんなものを使えるようにしたいと思っています。ゲートウェイに繋がっているものは何でも良いんですけど、時系列データベース(TSDB)に向かないデータを簡単に吸い上げて。自分のデスクトップとか別のシステムに投げられるようにしたいのが一つ。

もう一つは、別のブラウザーやシステムから、向こう側にある別のコンピューターやセンサとかに送れるようにしたい。だからこっちとこっちが何であっても、簡単に対応できるようにしたい。

 

--分かりやすく言うと、どう言うことでしょうか?

 

上田: MODEがもともと構造化されてるデータを扱うシステムだったんだけど、非構造化データのやり取りのための、ジェネリックなインフラになりそうだなと思っています!ってことですね。

 

篠田: そうですね。難しく言うとそんな感じです(笑)

今、データ転送の世界がどうなってるかと言うと、基本的にはクラウド to クラウドとか、サーバー to クラウドとか、データセンターに設置されたコンピュータ同士の通信しかしてないんですよ。それを山奥とか、ルンバの箱の中とか、そういったところまでコンピューター間通信のコネクティヴィティ(接続性)を広めたいんです。今までなぜそうなっていないかと言うと、とにかく面倒臭いんですよね。データセンターにあるコンピュータや、机の上で使うコンピュータは、普通は安定した通信の上に動いているので、ちゃんと接続するんですよ。

 

上田: それにサーバー間だったら時間かかるかもしれないけど、必ず届く。けれど携帯電話網で繋がった先のコンピュータには、普通に送ったら届かないことがかなりあります。だけど IoT をやる上では、携帯電話網の向こう側に繋がっているものも多くあるので、これができないと、山奥などにあるコンピューターがインターネットに繋がらず、システムの一員になれないんです。そういう課題を解決できそうだということですね。

今までは、データ収集にすごく特化していたんですけど、もう少し遠隔マネジメントみたいなことができるようになる。MODE Robot Cloudは遠隔マネジメントなんですけど、そのケイパビリティがすごく上がった感じですね。