サーバレスアーキテクチャで柔軟なIoTプラットフォームの構築
2021年03月05日 金曜日
CONTENTS
はじめまして。
2019年11月より、IIJ IoTビジネス事業部新規事業推進課にJoinした増田と申します。今回初めて本ブログに記事を投稿します。
まず簡単に自己紹介させていただきます。かなり雑多な経歴でして、Webサービスや観測システムの開発のほか、南極観測越冬隊に参加してレーダーを作りに行ったりしていました。そうしてフォークリフトと第一級陸上無線技術士とLPICの免許を持った妙な人になりました。
フォークリフトの運転は滅茶苦茶下手くそですが、もう使わないと思われるので問題ありません。日本にはフォークリフトが得意な人がたくさんいますから、私に重機は使わせないのが世のため人のためでしょう。
こういう経歴なので、現場仕事も多くありましたが、やりたいことは一貫して開発でした。もちろんそれぞれの現場でやりがいはあって、レーダーの仕事ではモノをいじることが多かったですが、そんな機会でもなければハードウェアに関わることもなかったと思うので、長い目で見るとよかったのかなと思います。その後はWebサービスの開発もやりましたが、ソフトウェアだけというのはなんだか物足りなく感じられました。なので、こうしてIIJでIoTのサービス開発に携われているのはとても幸運なことだと思います。
さて、今回の記事はIoTプラットフォームの構築についてです。私の経歴から考えると、あまり直接の関係はないようにも思えますが、そんなことはありません。私が過去の仕事から学んだことの一つは、一見異なるように見えるものも、同じような見方ができることがあるということです。IoTプラットフォームも、それが何をするものなのかについて考えれば、これまでにやってきたことと類似性を見いだせます。
水管理プラットフォームについて
私が担当しているのは水田水管理プラットフォームの開発です。水田水管理とは、稲作における水管理です。つまり農業IoTです。
農業はやったことがないので、中干しだの代掻きだのと言われてとりあえず戸惑うのですが、まぁ耳慣れない言葉を聞くのには慣れていますので、なんとかかんとか勉強しつつ、これまで積み重ねてきた実証実験をもとに開発を始めました。
昨年は新型コロナの影響もあり、現場にあまり行くことができず、農業について学ぶ機会が少なかったのはとても残念でした。しかしそれでも、水管理のためのプラットフォーム開発はできます。というのも、水管理プラットフォームというのは、結局のところセンサーの値を入力して保存し、保存したデータを出力するシステムだと解釈できるからです。
このざっくりとした捉え方だと、たとえば私が以前携わっていた大気観測レーダーも同じようなものと考えられます。被測定物→アンテナ→システム→データ分析です。
同じ絵が描けます。つまり農業=レーダーです。嘘です。
もちろん違うんですけれども、システムとしては同じように考えられるものです。デジタルの世界では、現実世界の差が吸収されるのが面白いところだと思います。デジタル値において、電力も、音声も、脳波も、水田の水位も、それらはすべて時系列な一次元の信号です。そうなってしまえば、扱い方は一緒です。
実際のアーキテクチャ
ということで、やりたいことは農業の水田水管理ではあるんですけれど、システムとして落とし込むと、得られた一次元の信号をクラウド上に保存し、インターネット経由で自由にデータを取り出せること、となります。であれば、イマドキはAWSなど使ってサーバレスなアーキテクチャでサクッとそれっぽいものができます。
恐らく、考えられるもっともシンプルなアーキテクチャではないでしょうか。API Gateway + Lambda FunctionによってREST APIを作成し、DynamoDBにデータを保存し、Applicationからのリクエストに応じて、データを取り出す。インフラ面についてはほとんどAWSが面倒を見てくれます。
これでもいいと思います。使用するセンサーが、たとえばIIJで販売している水田センサーであれば、30分に1回、データを飛ばすだけのシンプルなものですし、保存すべきデータの量もしれていますから、データベース設計もそう難しくはありません。
しかし、実際にサービスを運用しようと思えば、バックアップや監視のことも考えないわけにはいきません。すると、当然上の系だけでは不十分です。より機能を追加する必要があります。そこで、以下のようにサービスのシステムを構築します。
少し複雑になりました。元々のApiの系は残しつつ、機能毎に系を分散させています。マイクロサービス的な考え方ですね。
一見面倒そうに見えますが、AWS SAMを利用してインフラのリソースをコードで記述・管理することで、容易に機能を足したり引いたりすることができます。
増えるユースケース
しかし、実際に運用を始めると、やっぱりこれでも足りません。セキュリティ大丈夫なのとか、Gateway落ちたらどうするとか、データがあるなら分析や詳細な監視もしたいよねとか、もっと色々なセンサを使いたいとか、色々な要求が出てきます。
水管理プラットフォームの枠組みを超えているようにも思いますが、一般化して考えると、このシステムはデータを出し入れする入れ物のようなものです。であれば、水管理以外の様々なユースケースに対応できるのではないか、と考えるのは自然なことでしょう。
とはいえ、分析しようと思えば、制約の強いDynamoDBでは対応できそうにありませんし、デバイスが増えれば、バイナリデータのパースや、デバイスとの通信についても新たに考える必要があります。特に最近、本ブログに掲載された「LoRaWAN®で高解像度の画像は送れるか？ 」の記事にある、LoRaWANカメラのような複雑なものに対応することが求められると、ちょっと上の系じゃ対応できそうにありません。
で、上の要求を要件として取り込んでいくと、以下のようにシステムが膨れ上がっていくわけです。
だいぶごちゃごちゃしてきました。IIJのSIMとIIJ IoTサービスを使うことで、GatewayからIIJ IoTまで閉域のネットワークを構築してセキュリティを担保しつつ、IIJ IoTの機能でGatewayの監視も実施し、その後段のAWSでは、データを受けた後に分析や監視など種々の系に飛ばすようにしています。全体としては、前のシステムの形を残しつつ必要に応じて系を増やしていっているわけです。
分析、AnalysisのところでしれっとEC2があってサーバレスじゃなくなっていますが、これは時系列データを扱う高速なDB（PostgreSQL + TimescaleDB）を扱うためです。昨年11月、Amazon Timestreamがついに一般提供されはじめましたので、これがうまくはまれば、サーバレスなアーキテクチャに近づけることができるでしょう。
実際の水管理プラットフォームは、通知や実証実験で使うような特殊なデバイス対応などもあって、もっとごちゃごちゃしています。最初の頃は、API対応とバックアップくらいしかしていなかったのですが、一年で随分と変わりました。
変化するシステム
まぁでも、そうだろうなぁと。3年の実証実験を経て、満を持して開発された水管理プラットフォームなので、水田水管理についてはある程度確たるユースケースを見いだせています。しかし、水田水管理だけが農業ではありません。水管理プラットフォームという名ではありますが、より多くのユースケースにまで目を向けています。
そうすると、水管理で用いる水位と水温だけではない、様々なデータを取り扱うことになる。それらはデジタル的には同じ一次元のデータで、同じように扱えるかもしれませんが、現実には異なるものです。まったく同じようには扱えません。また水管理についてもより応用的な使われ方があるはずです。
何が求められるのか、それは現実にやって初めてわかることだと思います。すると、既存のシステムを運用しながら、そのノウハウをもとに、新たなサービスを開発していくことになりますから、システムが変わっていくのも当然のことです。
……と言いつつ、それにしてもダイナミックに変わるなぁと思います。IoT、私たちもまだまだ手探りです。マイクロサービス的な考え方で設計・開発を進めましたが、これはIoTに実に適していると思います。
これからも、システムはどんどん変わっていくでしょう。それはつまり、私たちが現場をよく理解するということでもあります。フォークリフトの使い方はもはや覚えていませんけれど、フォークリフトをうまく使えなくて苦労したことは、よく覚えています。忘れられないですね。IoTのシステムは、そうした現場の苦労に寄り添って作られるものだと思います。
ということで、変わりゆくユースケースにも水管理プラットフォームは対応し続けますので、安心してご利用をご検討くださいというところで、今後ともよろしくお願い致します。
