IoTアーキテクチャ、4つの例(1) - 「Device to Cloud」「Using Gateway」

IoTシステム開発の構築方法を悩まれている技術者の方々へ、ヒントを提示すべく始まった本連載も3回目。

概論はわかったから、そろそろ具体的な話をしてくれという声が聞こえてきそうなので、今回は具体的なアーキテクチャの例をご紹介したいと思います。

IoTアーキテクチャについて

前回、IoTのシステムはデータセントリックであり、データの収集/連携が重要なポイントだとご説明しましたが、このようなポイントはIoTシステムの大きな特徴であり、言うまでもなく、その特徴はシステム・アーキテクチャにも反映されています。

つまり、IoTシステムは、どのようにデータを集めるのかというデータ収集/連携の方法によって、システム・アーキテクチャが決まるということです。

実際には、データ収集をした後のクラウド側のアーキテクチャも、もちろん処理によって異なってくるのですが、今までのシステム・アーキテクチャと大きな差はありませんので、今回はデータ収集/連携にフォーカスして説明していきます。

私が関わった、今までのIoTのシステム・アーキテクチャを見ると、大きく以下の4つに分類できます。

1. Device to Cloud
2. Using Gateway
3. Using Mobile
4. Using Server

今回は、このうちの2つをご紹介します。

Device to Cloud - 最も単純パターンだが、電源に課題

このアーキテクチャパターンは、一番簡単で想像しやすいパターンではないでしょうか。

シンプルに、センサーやデバイスから直接クラウドにデータをあげるパターンです。

このパターンの特徴をまとめると以下になります。

[メリット]

• 比較的すぐに始められる
• デバイスが増えてもアーキテクチャの変更が少ない
• クラウド側で柔軟なデータハンドリングが可能

[デメリット]

• デバイスが段階的に増えるときの管理コストが極めて高い
• デバイスごとにデータが異なるときにクラウド側で対応が必要
• 再送処理をデバイス側で対応が必要
• そもそも電池消費量が高く、現実的ではない

Using Gateway - Gateway故障リスクが課題

Device to Cloudのパターンでは、ある程度デバイス側の処理性能を求められるため、利用できるシーンに限りがあります。

センサーチップなどプリミティブなデバイスを利用したい場合には、転送前にIoTゲートウェイを挟み、一旦データを集約してから転送をする方法をとります。そのパターンがこの Using Gateway パターンです。

このパターンの特徴をまとめると以下になります。

[メリット]

• 近距離通信が利用できデバイスの負荷を抑えられる
• デバイス増加時にデバイスのセットアップを最小限にできる
• データ転送をコントロールしやすい(再送、フィルタなど)
• デバイスをグループで管理できる

[デメリット]

• 単純にコストが増える
• デバイスを管理したい場合には別の仕組みが必要
• ゲートウェイが故障するとそのグループのデバイスがすべて使えなくなる

見えてきた2つの課題

今回は、2つのアーキテクチャをご紹介しましたが、IoTの特徴が出ていますね。

IoTシステムは以下のような特徴があると思います。

• データ収集の対象数(デバイス数)が非常に多い
• デバイス側の処理性能は期待できない
• デバイスは壊れる可能性がある(代替可能性を考慮する必要がある)

そのため、IoTシステムは、スケーラブルでかつクラウド集中型のアーキテクチャを作る必要があります。

次回は、残り2つのアーキテクチャをご紹介したいと思います。