3Gを使ったIoTという選択

以前、

IoTはRaspberryPiだという人が爆死する根拠
http://blog.goo.ne.jp/xmldtp/e/14e14a792223a04f23e47f4391b5d50b

というので、IoTシステムの３つのパターンを書いた。
あのときは、ゲートウェイが、インターネット（有線ないしは無線LAN)で
クラウドにデータを送るという構造だったが、３Gで送るということも出来る。
今日はその話。



【方式１】センサーとゲートウェイを直結。3Gで直接クラウド

　
　スマホアプリのデータをクラウドに送る場合がこれに相当する。
　加速度センサーの値や、時刻（はセンサーか？）、GPSの位置情報（はセンサーか？）
をスマホアプリからクラウドに送る場合、この構成になっている。

　このほかにも、SORACOMさんが出てきてくれたおかげで、このソリューションは、
　実現可能になってきている。

具体的には、

Raspberry PiでSORACOM SIMを使う(ZTE MF120, MF112)
http://qiita.com/osada9000/items/012962f6ed92b501bed5

にあるように、
・Raspberry Piにセンサーを付けて
・Raspberry Piに、3Gモデム（中にSORACOMのSIMを入れる）をいれて、
・センサーデータをRaspberry Piから３G経由でクラウドに送る
というソリューションがありえる。

　これは、Raspberry Piにあたるゲートウェイ部分がある程度の範囲で
移動するようなとき（スマホも移動する）に有効な手段。



【方式２】センサーとゲートウェイ間が通信、３Gで直接クラウド

ただ、センサー直結より、センサーとゲートウェイ間を無線で結んだほうが
やりやすい。こんなかんじ

理屈上は、RFモジュール直結で、サーバー側から、リモートで値を取得する

もあるけど、上のほうが便利かな？

　スマートフォンがBluetooth経由で、何か情報を集める場合（２－２のように見えるけど、
　実際はセンサー側にプロセッサが入っていて２－１ということで）これらのケースにあたる

　この方式は、方式１のようにゲートウェイが移動するものにも便利だけど、
　　・センサー部分は固定（ビーコンみたいなもの）
　　・ゲートウェイ部分が移動して
　　・その結果をクラウドで集計する
　などというのにも向いている



■これらの方式のいいとき、悪いとき

　広範囲に移動し、そこそこのデータ収集時間の場合、
　３Gで直接というこれらのアプローチはいいかもしれない。

・逆に狭い範囲ないしは動かないのであれば（＝無線LANが通る範囲）、
　わざわざ３G使わなくても・・
・頻度が余りにも高いと、パケット的にどうなのとかあるかも・・

　なお、このように３Gで直接クラウドにアクセスできる場合、
　クラウドのサービスに直接アクセスするという2Tierアーキテクチャ
　が使えるが、その場合、端末側が壊れたり、クラウドサービスのIPアドレス
　やサービスのURIが変わった場合について「注意する」

　・たとえば、クラウド側のサービスのURLが変わったとする。
　　すると、３tireだったら、集約サーバーの設定を変えればいいものを、
　　2Tierにしたので、すべての端末の設定を変えなければいけなくなるとか、

　・端末が壊れた場合、集約サーバーがあれば、そこの端末情報を変更すればいいだけだが、
　　2Tierにしたので、クラウドの情報を修正しないといけなくなり、
　　その上、すべての端末情報がクラウドにあるので、（いつも、どの端末かは壊れている
　　という場合）、しょっちゅうクラウドをいじってないといけなくなる

　などという事態が起こりえる。これを悪いことととらえるか、集中管理
できて、いいことととらえるかは、場合によってちがうが、いずれにせよ、
こういうことがありえると注意することは、必要。

※2Tierについては、こちら

【セッションレポート】モバイルアプリ向けAWSネイティブアーキテクチャ
http://dev.classmethod.jp/event/cmdevio2015-report-d3/