1999年に「Internet of Things」という言葉が生まれて18年。今現在、IT業界においてIoTという言葉は、聞かない日はないというほどの盛り上がりを見せています。「果たしてIoTとは何なのか」、IoTの本質を少し紐解いてみたいと思います。　

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

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

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

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

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

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

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

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

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

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

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

[メリット]

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

[デメリット]

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

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

センサーチップなどプリミティブなデバイスを利用したい場合には、転送前にIoTゲートウェイを挟み、

一旦データを集約してから転送をする方法をとります。そのパターンがこの Using Gateway パターンです。

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

[メリット]

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

[デメリット]

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

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

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

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

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

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