Developes.IO2016に行ってきました

３日連続でイベント参加。

【F-1 趣味でBlackJumboDogを作った Microsoft MVP が、iPhoneアプリ開発者になった話 〜定年自衛官がJOINしました〜 】 * 54歳の誕生日で定年を迎えました。 * 28歳でプログラムを始めて、５年前に定年後はプログラマになろうと決心した。 * 入って２ヶ月の私にここで話をさせるとはクラスメソッドってすごいなあｗ * 興味があれば一生懸命できて楽しい。 * 能力の限界はあるが、年齢の限界はない。

すごいです。

BlackJumboDogの名前の発祥を聞かせていただけました。

• 当初の名前はWinProxy
  • 同名のソフトがあって、海外から訴訟の脅し
  • 友達が「大きな犬がいた！」と大げさに言っていた
  • サーチしたらヒットしない
  • BlackJumboDog！

【A-2 実践IoTシステムで求められる確実なデータ連携】

ラズパイで何か作りました！とかいう話ではなく、実際の案件で考えなきゃいけない泥臭いデータ転送の話をします。というマクラからスタート。

HULFTIoTを絶賛開発中！ →HULFTのクオリティをそのままに、IoTのデータ転送をします。

●IoTには適用範囲によって種類がある。

• テレマティクス
• スマートメーター
• センシング
• リモートモニタリング
• トレース
• 決済
• セキュリティ

●IoTシステムアーキテクチャ

• Type１：Device to Cloud
• デバイス→メッセージブローカー→データストアといったように非同期のアーキテクチャ
• MQTTが多い。
• よいところ
  • デバイスがあればすぐに始められる
  • デバイスが増えてもアーキテクチャの変更が少ない
  • 大量データもクラウドでらくらく
• 悪いところ
  • デバイスが段階的に増えるときの管理コストで死ねる
  • デバイスごとにデータが異なるときに後々面倒。
  • 再送処理どうすんの？
  • 電池が…
• Type2：UsingGateway
  • デバイス→IoTゲートウェイ→メッセージブローカー→データストア
  • よいところ
    • デバイスに負荷をかけない
    • デバイスが増えたときにデバイスに手を入れなくていい
    • 転送をコントロールしやすい
    • デバイスをグループで管理
  • 悪いところ
    • 単純にコストがかかる
    • ゲートウェイが死ぬと全滅
• Type3：UsingMobile
  • よいところ
  • みんなが持っているMobileを流用できる
  • 中継だけでなく他の使い道にも
  • 転送をコントロールしやすい
  • 悪いところ
    • Mobileがデバイスの近くにある必要がある
• Type4：UsingServer
  • デバイス→サーバ／PLC→メッセージブローカー→データストア
    • 製造業で多いパターン
  • よいところ
    • 中継処理でなんでもできる
    • 既存の資産を転用できる
    • 転送をコントロールしやすい
  • 悪いところ
    • そもそもIoTか？
    • モビリティに欠ける

●データ転送で考えること

• 到達保証
• セキュリティ
• 多重度
• 圧縮
• トランザクション

●IoTシステムの大前提

• デバイスには極力負荷をかけない
• スケーラブルなアーキテクチャにする
• デバイスとクラウドは疎結合にする

１．到達保証

• ロストを前提とするとアプリ側も対処がめんどくさい
• HTTP、WebSocketでやろうとすると自前で実装する必要がある
  • MQTTはプロトコルレベルで対応しているので楽。

２．セキュリティ

• 認証
  • MQTTはパスワード認証だけどどうやってデバイスに渡す？
• 暗号化
  • 経路の暗号化
  • 証明書の配付はどうする？
• Soracom beamとEndorseがあれば経路の暗号化はOK。
• 耐タンパー性
  • デバイスそのものを盗まれたときにデータを抜き取られないように

３．多重度

• トラフィックコントロール
  • たとえばスマートメーターが全部同時に発報させたらどうなる？
  • 発報のタイミングを工夫する
• 耐障害性
  • Gatewayが死んでも転送できるように
  • 別経路の確保、経路の多重

４．圧縮

• なるたけデータの転送量は圧縮したい
  • でもデバイスには負荷をかけたくない
• そもそも圧縮しないアプローチ
  • メッセージが小さいから問題ない
  • でも画像やバイナリは…
• 圧縮しながら転送
  • その都度圧縮
  • プロトコルではサポートしていないので開発する必要がある

５．トランザクション

• そもそも必要ない場合も
• 必要になるとっても頭の痛い話
• デバイスとサーバは疎結合なのにどうやって一貫性を担保？
  • 案１： HTTPとかWebSocketでがっちり実装
  • 案２：キューで実装

●MQTT一択なのか？

• プロトコルとしてはIoTと相性はよさそう
• それでもMQTTの気になるところ
  • データをストアするとスケールしづらくなる
  • 大容量データの転送
  • データの順序性の制御
    • MQTTにキューはありません！

●ファイル転送という選択肢

• 古くさく聞こえるけど
• ストアを考えなくてもよい
• 順序性の管理がしやすい
• ファイルでPub／Subっぽいこともできちゃう
• スケールしやすい
• 大容量もOK
• 動画やバイナリもOK

でも…

• 到達保証、整合性検証の仕組みが必要

そこでHULFT IoTですよ！

【La-3 実務で使うAWS Lambda 】

●実務でLambdaを使うのは難しい？

• Lambdaがよさそうなのはわかる
• EC2ではオンプレと同じようにプログラムを実行できた
• Lambdaの使い方はそれとは異なる。
• 納期が決まっているので下手にはまるとつらい。
• 運用時に問題が出ると困る

WorkerでよいものはLambda化しやすい

実用上はメモリと同時実行数とサイズに注意

同期呼び出しは調整されるとエラーが返る

●Lambaバックエンドの並列耐性

• 対策１：スケーラブルなバックエンドを使う
  • DynamoDB
• 対策２：並列度を制御する仕組みを入れる
  • Functionを起動するFunctionを設ける

私は、Lambdaファンクションの実行時間より、起動までの時間が気になってます。

ハッシュタグ付きでTweetしただけでTシャツをいただきました。

SORACOM様のSIMアダプタとシールを。