以前、
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/
アクセス
トータル
ランキング
